[02:13] <mybalzitch> https://help.ubuntu.com/lts/serverguide/firewall.html#ip-masquerading those ufw nat instructions don't actually work
[02:16] <mybalzitch> https://pastebin.com/sUrTm9ZK
[02:25] <mybalzitch> deleting and readding the commit line several times fixed it? nice parser.
[04:56] <samba35> i have messup with my ubuntu 18.04 server with grub loader there is now only memory test entry are there there is no linux-version entry
[04:56] <samba35> how do i fix this problem ?
[06:32] <cpaelzer> good morning
[06:32] <cpaelzer> samba35: that seems that no kernel at all was found on your last update grub
[06:33] <cpaelzer> samba35: there might be more options, but I'd try to boot from USB/CD
[06:33] <cpaelzer> samba35: then chroot into your actual system
[06:33] <cpaelzer> and then check why there is no kernel, fix that up
[06:33] <cpaelzer> and eventually run sudo update-grub
[06:33] <cpaelzer> that should then detect the kernel that you made available and update the boot tables as needed
[06:34] <cpaelzer> then cross fingers, reboot and done
[06:34] <cpaelzer> samba35: I think the live CD also has a boot-repair option that fixes most common issues
[06:40] <samba35> sorry cpaelzer
[06:41] <cpaelzer> for what samba35?
[06:41] <samba35> i try to boot from dvd and mount it but it give erros
[06:41] <cpaelzer> well then, disk broken maybe
[06:41] <cpaelzer> what kind of errors
[06:42] <samba35> error with dpkg and unable to find some files
[06:42] <cpaelzer> provide a pastebin of the commands you tried and maybe the logs and dmesg that was created along
[06:42] <cpaelzer> hmm
[06:42] <cpaelzer> are those dpdk errors after mount+chroot?
[06:42] <cpaelzer> did you bind mount /proc, ss and dev ?
[06:42] <samba35> is it possible to boot from another harddisk and make broken disk as a slave and try to repiar ?
[06:42] <samba35> no
[06:42] <cpaelzer> samba35: that is exactly what you already do with the CD
[06:43] <cpaelzer> CD is the "other disk"
[06:43] <cpaelzer> and you try to repair from there right
[06:43] <samba35> currenty i am on 16.04 and broken disk as a slave
[06:43] <samba35> will i able to fix this now ?
[06:44] <cpaelzer> no one can tell you that in advance, but give it a try
[06:44] <cpaelzer> before you chroot you should like
[06:44] <cpaelzer> 1. mount the disk on /mnt
[06:45] <cpaelzer> 2. for f in proc sys dev ; do mount --bind /$f /mnt/$f ; done
[06:45] <cpaelzer> 3. chroot /mnt
[06:45] <cpaelzer> then you are as if you'd be in your hard disk's system
[06:45] <cpaelzer> not sure if you need network tricks, but that would be a start
[06:45] <cpaelzer> there check /boot and if there is a kernel as it should be
[06:45] <cpaelzer> then run sudo update-grub what does it say ...
[06:45] <samba35> ok
[06:45] <samba35> let me try
[06:54] <samba35> sda1 is mount as a /media/tesuser/some numbers
[06:55] <samba35> what is ss ?
[06:58] <samba35>  mount /media/tesuser/637d0aee-9232-11e8-9c61-2ed34b5b4932/proc/  /current (from where i have booted ) that drive any mount point or old salave disk mount point ?
[06:59] <samba35> mount:  /media/tesuser/637d0aee-9232-11e8-9c61-2ed34b5b4932/proc is not a block device
[06:59] <samba35> ok
[07:00] <samba35> done
[07:00] <samba35> with --bind
[07:04] <cpaelzer> yeah it just means "be also available there for when I late chroot"
[07:05] <samba35> from where i have to run update-grub  ?
[07:06] <samba35> salave /18.04 disk or currnt 16.04 disk
[07:09] <samba35> ok let me boot from cdrom and try
[07:10] <samba35> cpaelzer, thanks i will be back later after trying this
[07:11] <cpaelzer> samba35: you want to do that "inside" the chroot which is on the disk you want to fix
[07:11] <samba35> ok
[07:17] <samba35> chroot: failed to run command '/bin/bash': No such file or directory
[07:23] <samba35> in old disk in /boot i can see initrd.img-4.15.0-42-generic.dpkg-bak
[07:23] <samba35> initrd.img-4.15.0-42-lowlatency.dpkg-bak
[07:23] <samba35> initrd.img-4.19.2-041902-generic.dpkg-bak
[07:24] <samba35> and when i run update-grub here i show currnt disk kernl 3.x
[07:28] <samba35>  w /usr/sbin/grub-mkconfig: 37: /usr/share/grub/grub-mkconfig_lib: cannot create /dev/null: Permission denied
[07:29] <samba35> mount but why ?
[07:29] <samba35> a /usr/sbin/grub-probe: error: cannot find a device for / (is /dev mounted?).
[07:36] <samba35> cpaelzer, a /usr/sbin/grub-probe: error: failed to get canonical path of `/dev/mapper/ubuntu-root'.
[07:36] <samba35> now this error
[07:38] <cpaelzer> hmm seems like lvm root
[07:38] <cpaelzer> righ tnow I'm not sure without checking myself what special consideration apply
[07:38] <samba35> ok
[07:38] <cpaelzer> your list of kernel/initrd mentions only backup files
[07:39] <cpaelzer> no actual kernel/initrd there ?!
[07:39] <samba35> yes
[07:39] <cpaelzer> well, whatever the reason is that is at least part of your issue
[07:39] <samba35> there was error with dpkg and i google some site and mess up
[07:39] <cpaelzer> you'd want to install at least one kernel
[07:39] <samba35> yes
[07:40] <samba35> will booting from 18.04 dvd will help ?
[07:40] <cpaelzer> yeah the case look half-broken already, this gets hard to fix-by-remote-hints
[07:40] <samba35> and rescue mode
[07:40] <cpaelzer> booting a different DVD will not make it any different IMHO
[07:40] <samba35> ic
[07:40] <cpaelzer> you still need to install a proper kernel on the main disk in the chroot
[07:40] <cpaelzer> and then update-grub
[07:41] <cpaelzer> and sort out whatever the lvm setup makes you need in additon
[07:41] <samba35> ok
[07:46] <samba35> thanks cpaelzer back soon thanks
[09:02] <lordievader> Good morning
[09:46] <kstenerud> Does anyone know how to generate a control file from a control.in file?
[09:48] <mwhudson> kstenerud: there's no one way, make -f rules control ?
[10:01] <samba35> E: Sub-process /usr/bin/dpkg returned an error code (1)
[10:01] <samba35> how to fix this
[10:29] <LeMike> Would this be the right place for some rsync things? I tried using --filter=":e- .gitignore" but unfortunately it still downloads all files instead of ignoring some. Why could that be?
[10:37] <LeMike> damn it. forget about this. the ":" is a directory merge so the .gitignore of the sender will be used (and not mine as receiver).
[11:09] <ahasenack> good morning
[11:27] <peetaur2> I don't know when or how, but at some point, vsftpd and LDAP were working fine, and now it fails.   with lftp client, it started doing this:    ls: Login failed: 500 OOPS: cannot locate user entry:username
[11:28] <peetaur2> and if I change it to use the sshd pam service instead, it then says     ls: Login failed: 530 Login incorrect.
[11:35] <ahasenack> you need to checkout which ldap searches are being done, and what their result is
[11:35] <ahasenack> peetaur2: ^
[11:46] <peetaur2> I basically did that.
[11:46] <peetaur2> but restarting nslcd fixed it .... :/
[11:46] <peetaur2> why should getent, ssh, etc. all work fine using nslcd, but vsftpd needed it restarted? silly thing
[11:47] <ahasenack> ah, the cache?
[11:48] <peetaur2> nslcd does caching, yes
[16:53] <ahasenack> rbasak: hey, I just saw something interesting in a debian package
[16:54] <ahasenack> rbasak: debian builds samba with glusterfs support, so their samba-vfs-modules package ships /usr/lib/x86_64-linux-gnu/samba/vfs/glusterfs.so
[16:54] <ahasenack> and that links with libglusterfs.so.0, which comes from glusterfs-common
[16:54] <ahasenack> rbasak: but their samba-vfs-modules package has no dependency on glusterfs-common. Instead, they have a Recommends
[16:54] <ahasenack> root@oriented-mastodon:~# dpkg -s samba-vfs-modules|grep gluster
[16:54] <ahasenack> Recommends: glusterfs-common, libcephfs2 (>= 12.2.8), libdbus-1-3 (>= 1.9.14)
[16:55] <ahasenack> is that a valid trick?
[16:55] <ahasenack> shlibs didn't seem to have picked up the linkage between /usr/lib/x86_64-linux-gnu/samba/vfs/glusterfs.so (samba-vfs-modules) and /usr/lib/x86_64-linux-gnu/libglusterfs.so.0 (glusterfs-common)
[16:58] <ahasenack> in the package's description:
[16:58] <ahasenack>  Note: The runtime dependencies of vfs_ceph, vfs_glusterfs and vfs_snapper are
[16:58] <ahasenack>  moved to Recommends.
[17:01] <nacc> ahasenack: so if you install samba-vfs-modules (but not it's recommends) and then configure samba to use gluster, does it segfault/crash?
[17:01] <ahasenack> nacc: it would definitely fail to load that module. I think it still starts up, but I would have to check
[17:01] <rbasak> Plugin modules are weird
[17:02] <rbasak> It might be reasonable to leave it as a recommends or even a suggests
[17:02] <ahasenack> also, what does ubuntu do, since it installs recommends by default? What does it do when it cannot find a recommends?
[17:03] <rbasak> I think it will not take any action on a recommends it cannot fulfil. But that might need checking.
[17:03] <rbasak> "The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality."
[17:03] <rbasak> From policy
[17:04] <rbasak> For something like samba-vfs-modules, glusterfs may not be treated as "significant".
[17:04] <ahasenack> right
[17:04] <ahasenack> but the question is, what would britney do? :)
[17:04] <rbasak> It doesn't know so it doesn't care.
[17:05] <ahasenack> I mean, at migration time
[17:05] <ahasenack> if it would treat recommends as depends or not
[17:05] <ahasenack> or "whatever apt would do" is the answer
[17:05] <rbasak> Oh
[17:05] <rbasak> I see what you're asking now. I don't know. Good question.
[17:06] <ahasenack> I'll find out
[17:06] <ahasenack> we could drop that bit of delta if this works and is acceptable
[21:13] <cpaelzer> coreycb: jamespage: is that nova test error anything you triggered or could fix<EMAIL_ADDRESS>?
[21:13] <cpaelzer> the libvirt upload I did certainly didn't trigger that
[21:14] <cpaelzer> was a s390x only one line change to vfio handling
[21:14] <cpaelzer> so I wonder if there is anything going on that you know avoiding that I have to debug and find out on my own tomorrow
[21:14]  * cpaelzer is lazy before going to bed and hope the world fixes my issues
[21:15] <evit> I was thinking the other day. It would be awesome if apt update would notify if you needed to reboot or not like it does on the desktop.
[21:16] <sdeziel> evit: motd is updated with the reboot needed notice
[21:17] <coreycb> cpaelzer: I've been trying to figure it out all day. I made a little progress at https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1807262
[21:19] <evit> sdeziel, I'm talking about after you do a manual apt update && apt upgrade
[21:20] <evit> @sdeziel, I disabled MOTD
[21:20] <coreycb> cpaelzer: something changed w sqlite
[21:20] <sdeziel> evit: I guess you could have a post-apt hook to do what the motd in question was doing
[21:21] <cpaelzer> coreycb: if you don't find something towards your EOD
[21:22] <cpaelzer> would you mind filing a force-badtest for now to unblcok me and potentially others
[21:22] <cpaelzer> that would give you tim eto sort it out
[21:22] <sdeziel> evit: if you are looking for something to let you know which services would need a restart (more frequent than reboot-needed), you may want to look at https://github.com/simondeziel/check-deleted-libs/blob/master/check-deleted-libs </self promotion>
[21:22] <cpaelzer> thanks for the bug reference, I'll refresh tomorrow what your last state on this was
[21:26] <coreycb> cpaelzer: haven't done that before but will look into it
[21:27] <cpaelzer> thanks coreycb I'd appreciate that
[21:28] <cpaelzer> ok, cu tomorrow where I'll recheck the latest updates to that bug
[21:51] <evit> Silly question. I've updated my .bashrc to include my FQDN with /H but I don't see it upon logging back in. Any ideas?
[21:52] <evit> I mean \
[21:52] <evit> \H sorry
[21:52] <lordcirth> evit, to include it in $PS1, you mean?
[21:53] <evit> lordcirth, Yes
[21:53] <lordcirth> evit, what line exactly did you put in .bashrc?
[21:54] <evit> PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\H\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
[21:54] <evit> else
[21:54] <evit>     PS1='${debian_chroot:+($debian_chroot)}\u@\H:\w\$ '
[21:54] <evit> fi
[21:54] <evit> unset color_prompt force_color_prompt
[21:55] <evit> hostname produces www. Is there somewhere else I need to change that?
[22:00] <lordcirth> debian_chroot?
[22:00] <lordcirth> ah, nvrm
[22:00] <lordcirth> evit, you might have run into this bug: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1276796
[22:01] <lordcirth> A workaround is to use $(hostname -f) instead of \H
[22:06] <evit> lordcirth, Gracias! =)
[22:07] <lordcirth> np


[09:07] <infinity> fabbione: The next glibc upload will be in an hour or two.
[09:07] <infinity> fabbione: I'll warn you before I do it.
[09:08] <infinity> fabbione: Oh, wait.  I should read more closely.  You got it done ages ago.  I won't warn you. :0
[09:08] <fabbione> infinity: i have it all ccached :)
[09:08] <fabbione> just go ahead and do it
[09:09] <infinity> Oh, I changed a base type header, so your whole cache will probably invalidate.
[09:10] <infinity> (Kidding, by the way)
[09:11] <fabbione> i will never believe something like that :)
[09:11] <fabbione> but i need to flush my ccache anyway
[09:12] <fabbione> the 40GB partition allocated to it is almost full
[09:12] <infinity> Hey, even fixing a typo in a header that almost everything includes (in)directly will invalidate your whole cache.
[09:12] <infinity> ccache is fun that way.
[09:12] <fabbione> yeah i know
[09:12] <infinity> And I'm sure I can find a typo that needs fixing. :)
[09:12] <fabbione> i am sure i can find something that wants to enter your deepest holes :P
[09:13] <infinity> Oo, I hope it's pumpkin pie.
[09:13] <fabbione> you wish :)=
[09:17] <infinity> Man, glibc has way too many passes on i386...
[09:17] <infinity> I probably have time to write a best selling novel while this compile is happening.
[09:18] <fabbione> infinity: jbailey was setting a concurrency level to 500 and it took only 4 minutes to build
[09:18] <fabbione> (on ronne)
[09:18] <fabbione> so perhaps you might want to give it a shot?
.. I have other stuff to do anyway, so I don't really care.
[09:20] <infinity> And I'd prefer to keep all the building happening on machines/chroots I have complete control over, since this is a bootstrap build.
[09:22] <doko> why on i386 and powerpc?
[09:29] <infinity> Err, s/i386/amd64/ ... I'm passing out in the heat here, forgive me.
[09:29] <infinity> And yes, it takes twice as long to build on i386.
[09:29] <infinity> But getting bad on amd64 too.
[09:29] <infinity> (not AS bad, though)
[10:26] <infinity> Okay, one last test build and I upload.
[04:09] <doko> infinity: still alive^B^B^B^Bwake?


[00:24] <abentley> poolie: I'm up for a call.
[00:28] <poolie> hi
[00:28] <poolie> on skype or something, if you like?
[00:37] <abentley> poolie: http://code.aaronbentley.com/bzr/bzrrepo/288751-pack-deltas
[00:52] <jbalint> how do i handle "Contents conflict", the file has been renamed in the current tree
[00:58] <thumper> how do I change the format of a branch from BranchFormat7 to BranchFormat6?
[01:00] <jbalint> maybe bzr upgrade?
[01:01] <spiv> jbalint: see "bzr help conflicts"
[01:01] <spiv> jbalint: a contents conflict is when bzr sees conflicting changes to a non-text file.
[01:02] <awilkins> Or the addition of a file with the same path
[01:02] <jbalint> hrm, these shouldnt be nontext
[01:02] <awilkins> In two seperate branches
[01:02] <jbalint> one is .h, its the exact files taht are renamted
[01:04] <spiv> awilkins: Hmm, "bzr help conflicts" suggests that would reported differently.
[01:05] <spiv> Note that symlinks and directories count as non-text files...
[01:05] <awilkins> I've never seen a "path" conflict, only content ones
[01:06] <awilkins> And these are for ASCII text files
[01:06] <awilkins> Maybe it's a windows thing?
[01:06] <spiv> Maybe, I wouldn't know.
[01:47] <kingfishr> what is the shortest sequence of commands to give me the equivalent of hg addremove?
[01:51] <spiv> kingfishr: something like "bzr add; bzr commit" IIRC  (commit will automatically remove missing files by default, I think).
[01:52] <kingfishr> oh really?
[01:52] <kingfishr> that's convenient
[01:52] <kingfishr> i wasn't aware of that
[01:53] <spiv> I think --strict will disable that behaviour.  Try it out, it's easy to experiment :
[01:53] <spiv> :)
[02:21] <poolie> jam, are you still around? did you do a patch towards bug 300177, i don't remember
[02:38] <synic> I want to write a clone of gitosis for bzr, I'm just wondering if anyone is already doing this (other than bzr_access)?
[02:39] <james_w> I had heard tell that gitosis may support bzr
[02:39] <james_w> or maybe I'm thinging of something else
[02:40] <synic> hrmm, not in it's current state
[02:42] <spiv> bzr_access is the closest I know if.
[02:42] <spiv> s/if/of/
[02:43] <synic> ok, cool
[05:22] <vila> Gooood morning all
[05:26] <spiv> vila: good morning.
[05:26] <spiv> vila: you seem to be around early today :)
[05:26] <vila> spiv: no, check your clock :)
[05:26] <vila> kidding, I dropped my girlfriend to the airport :)
[05:31] <army> hi ,i have a problem with bzr-svn,
[05:33] <army> bzr 1.9 bzr-svn 0.4.15, check out http://www.prestashop.com/publicsvn ,error
[08:18] <kisielk_home> As a new user to bazaar, I have a few question about repositories. In order to use an sftp:// repository, does bazaar actually have to be installed on the host?
[08:18] <kisielk_home> or is it enough to have it just on the client?
[08:20] <luks> kisielk_home: no, it doesn't have to be on the server
[08:21] <luks> kisielk_home: only for bzr+ssh or bzr+http protocols
[08:21] <kisielk_home> nice
[08:21] <kisielk_home> yeah, I just want to keep some configuration files on my web server
[08:21] <kisielk_home> and sync them to the machines I use
[08:21] <kisielk_home> but it's shared hosting, so no bzr installed there
[08:21] <luks> should work fine
[08:22] <kisielk_home> cool
[08:34] <vila> jam: When you'll come online, have a look at the last comment in bzrlib.tests.test_log.TestShowlog.test_simple_log :-/
[10:55] <robsta> hi
[10:55] <robsta> what's the best changelog script with bzr, prepare-ChangeLog.pl seems not to handle it
[11:54] <robsta> jelmer: thanks for the fresh bzr-svn deb on the ppa, i can now clone my svn repo and `bzr check' works
[11:56] <jelmer> robsta: n/p
[11:57] <jelmer> robsta: what's prepare-ChangeLog.pl exactly, is it GNOME-specific?
[11:57] <robsta> nothing, it doesn't do bzr at all
[11:57] <robsta> (my version at least)
[11:58] <jelmer> I think there was a plugin that could write GNU-like ChangeLog entries
[11:58] <robsta> interesting
[11:58] <robsta> i'm really only using the script to create commit messages
[11:59] <jelmer> ah, it creates commit messages from the changelog rather than the other way around?
[12:00] <jelmer> in that case, the plugin won't be of much use to you
[12:00] <robsta> i run prepare-ChangeLog.pl, then paste it when committing
[12:00] <robsta> the changelog is just a side-product of that
[12:13] <asabil> robsta: you probably want to use moap instead of prepare-ChangeLog.pl
[12:13] <asabil> I have a patched version of moap that produces the exact same output
[12:13] <robsta> asabil: with function names?
[12:14] <asabil> ah, no I don't think so :/
[12:15] <robsta> :(
[12:15] <robsta> seems like maintainer.py doesn't to bzr either
[12:16] <asabil> well, I only used moap with Vala, so I don't know if it tries to extract function names for C code
[12:28] <robsta> heck, how hard can it be to hack prepare-ChangeLog.pl ...
[14:07] <Sadr> Bazaar is mainly designed for code, correct? But, could it be also used for, say, model/asset revisions tied up with a web-based GUI?
[15:04] <Sadr> second try... any examples of Bazaar being used for *files* (e.g. a .blend or .max) ?
[15:05] <Sadr> we're looking into maybe using Bazaar as an advanced file manager for our open source website
[15:05] <jelmer> Sadr: hi
[15:05] <jelmer> Sadr: The obvious problem with binary files is merging - bazaar does line-based merging
[15:05] <jelmer> other than that, it should work fine
[15:07] <Sadr> I see
[15:08] <awilkins> Ok ; here's a talking point ; tags
[15:10] <awilkins> All tags are replicated between branches on a push, pull, branch, even if they are on dead revisions
[15:10] <awilkins> e.g.
[15:11] <awilkins> bzr init one ; cd one ; echo one > one ; bzr add ; bzr commit -m "One ; bzr tag ONE ; bzr uncommit --force ; bzr commit -m "Two" ; bzr tag TWO ; cd .. ; bzr branch one two ; cd two ; bzr tags
[15:12] <awilkins> Dang, missing a quote
[15:12] <jelmer> awilkins: I think it's intentional to keep those
[15:12] <awilkins> jelmer: But then you have a tag that marks a revision that potentially does not exist in the target branch / repo
[15:12] <awilkins> jelmer: Dead revisions are not branched to the other branch, what's the sense in identifying them.
[15:14] <awilkins> In my case, I then ran into tag conflicts with new revisions (the tags are being generated by a script for metadata purposes)
[15:14] <Odd_Bloke> awilkins: 'bzr branch -rtag:dead-revision <original branch>'?
[15:15] <awilkins> Odd_Bloke: 'spose... :-)    it does seem rather marginal
[15:16] <Odd_Bloke> awilkins: Sure, but if the tag disappears, you don't know that you haven't got all of the revisions that were tagged.
[15:16] <Odd_Bloke> And presumably the tag still existed for a reason.
[15:16] <awilkins> I shouldn't run into it again, my script now overwrites the tags ; and people shouldn't push before they are sure they are not going to uncommit.
[15:17] <awilkins> The tag exists to identify live revisions that represent places to do a fancy diff report
[15:17] <jelmer> wow, has_revision() really profits from the 1.9 formats..
[15:20] <vila> jam: ping
[15:25] <derekS> hi all. just a quick question. what is the difference between committing to a local branch and pushing to a local folder?
[15:26] <derekS> not used to this dvcs :)
[15:26] <Odd_Bloke> derekS: You push commits.
[15:26] <Odd_Bloke> You commit changes.
[15:27] <Odd_Bloke> So push recreates your branch wherever you push to.
[15:27] <Odd_Bloke> Your branch doesn't include anything that hasn't been committed.
[15:27] <derekS> Odd_Bloke: so pushing a commit just merges it upstream?
[15:28] <awilkins> derekS: pushing only works if no merge is required :-)
[15:28] <Odd_Bloke> Nope, merging is a different concept.
[15:28] <derekS> so, pushing just puts my branch upstream?
[15:28] <derekS> so it copies my branch to the one i pushed to?
[15:28] <Odd_Bloke> What do you mean by 'upstream'?  Pushing just puts your branch wherever you're pushing to.
[15:29] <awilkins> pushing sends your revisions to the target branch, if it has no revisions that are children of the common ancestor you share
[15:29] <derekS> hmm gotcha
[15:29] <derekS> sorry, i am gjust trying to figure out how i can switch my svn to bzr
[15:29] <derekS> the owrkflow part
[15:29] <derekS> i use svn right now as a pseudo document management system :)
[15:30] <derekS> for my personal files
[15:30] <awilkins> Heh, I found it liberated me from the workflow of svn :)
[15:30] <awilkins> No having-to-be-in-the-office or on-the-vpn
[15:30] <awilkins> Started off with SVK and when that had a major oops, moved onto bazaar
[15:30] <derekS> awilkins: yeah :) i like it
[15:31] <derekS> just trying to create my workflow
[15:32] <awilkins> That reminds me... I was going to have a crack at bzr-svn 0.5 on this monster repo to see how it does compared to 0.4
[15:32]  * awilkins gets busy downloading stuff
[15:32] <derekS> have fun!
[17:29] <pickscrape> Is it possible to create a patch using bzr send which is against an earlier revision on the branch without having to bzr branch -r that revision out temporarily?
[17:30] <pickscrape> e.g. I have a branch that I submitted at r50, and I commit 5 more changes (to r51) and want to submit those 5 changes as a new patch but not including the work up to r50.
[17:30] <LeoNerd> Presumablly -r50..51 ?
[17:31] <pickscrape> Doesn't defining a range like that create a cherry pick?
[17:31] <LeoNerd> Yes. But that's what you're doing here
[17:32] <pickscrape> OK, asking my colleague to try that. Thanks :)
[17:33] <pickscrape> Related question, but when using a loom is there a simple way to say "send this thread" or does that also require looking at log and specifying the relevant revisions?
[17:38] <jam> vila: pong, sorry about the delay
[17:39] <vila> jam: np, just a quick chat about but #300055
[17:39] <vila> jam: np, just a quick chat about bug #300055
[17:39] <vila> gee ubottu, can't you see that I mixed up your nick and bug ?
[17:40] <vila> jam: So, as said in the bug comments, I commited 2 fixes already, cleaned up the tests (finding a semi-bogus one on the way)
[17:41] <vila> And I'm now to the point where I realized there are still problems lying around
[17:41] <jam> well, making things better than they are now is worth merging
[17:42] <jam> even if you don't have an absolute solution
[17:43] <vila> That was my feeling but I wanted to discuss a bit to clarify my mind, I want to send the submission with some explanations to start the discussion
[17:44] <vila> Roughly, we tend to enlarge the revision ranges to include the mainline revisions
[17:46] <vila> I think this is motivated by two facts: 1) that made the programming easier (wrong reason :), 2) we display dotted revnos *after* the mainline revisions they are merge into
[17:46] <vila> 2) does not play play well for several reasons
[17:48] <vila> a) it makes the code *harder* as soon as the revision ranges are not "complete" (as including the mainline revision and all its merged revisions)
[17:48] <synic> what is the equivalent of "bzr checkout" in bzrlib?  WorkingTree doesn't have a 'checkout' method
[17:49] <vila> b) the display is ill-defined when the range is not complete
[17:49] <jam> synic: Branch.create_checkout, IIRC, you can look in 'builtins.py' for the 'cmd_checkout' class
[17:49] <synic> ok
[17:50] <vila> The root cause being that reverse_by_depth works in one direction only and this went unnoticed until now, so many cases are not covered
[17:50] <vila> err, scratch that
[17:51] <jam> so let's start at the beginning
[17:51] <vila> The root cause being that reverse_by_depth works in one direction only, this went unnoticed until now but it was used in several places ignoring that fact
[17:51] <jam> "we tend to enlarge the revision ranges to include the mainline revisions"
[17:51] <vila> ok
[17:51] <jam> we want to go from a revision in the ancestry
[17:51] <jam> and track where it was merged until we get down to mainline
[17:51] <jam> merge-sorted revisions have this information easily available
[17:52] <jam> reversed... not so much
[17:52] <jam> I couldn't actually work out an obvious answer once they have been reversed.
[17:52] <vila> I argue that we may not want to do that unconditionally
[17:53] <jam> vila: perhaps, but for now it was chosen as the best trade off
[17:53] <jam> between showing all cases where the change was merged into
[17:53] <jam> and showing none
[17:53] <jam> it is logically an optional thing
[17:53] <jam> but to make it *actually* optional
[17:53] <jam> requires updating the UI
[17:53] <jam> and passing the parameters across the stack
[17:53] <jam> which is generally non-trivial
[17:54] <jam> It most certainly *can* be done. It wasn't worth my time
[17:54] <jam> and I would argue it isn't worth your time *right now*
[17:54] <jam> changing log so that it doesn't have to access as much ancestry would be a better thing to work on
[17:54] <jam> and that may restructure the code anwyay
[17:54] <jam> anyway
[17:55] <vila> jam: sorry, phone, back in a few minutes
[17:56] <vila> jam: back
[17:57] <jam> np
[17:57] <vila> Ok, I see your point. Yet, the case reported, starting at a dotted revno and fixed as of today allows to avoid showing a bunch of revisions (~50 or 100) so there is some motivation to handle it to respect user request
[17:59] <vila> But, you're right, I may submit the actual fixes and just add a note that some more work may be needed, the fixes themselves provides a better solution but doesn't address all the cases either
[18:01] <vila> Oh, re-reading your comments, I don't argue that we must not include the mainline revs, just that we don't have to include them if they are outside the requested range, i.e. at start/end only. But doing so raises some problems in the way we display them:
[18:02] <vila> We can display hanging revisions (without their mainline) at start, but we can't to that at end, because there isn't a mainline rev to aggregate them there
[18:02] <jam> vila: I don't quite see how you can get a revision that is in the ancestry that never ends up merged to a mainline revision
[18:03] <jam> it... wouldn't be in your ancestry if that was the case
[18:03] <vila> So doing 'log x.n.m..y.p.q' and 'log x.n.m..y.p.q --forward' can't display the same revisions
[18:03] <vila> the revision *is* in the ancestry but the range *excludes* it
[18:03] <jam> well, we only do the projection to mainline revs if you are logging a file
[18:05] <vila> Look at lp:~/vila/bzr/300055-log-forward, bzrlib/tests/test_log.py TestGetViewRevisions.test_file_id_for_range for an example or try the reported case with my fix
[18:06] <vila> in the reported case, the first required revision is 1616.70.54 which was merged in 1627
[18:06] <vila> Yet, with my fix and --forward, we don't display 1627
[18:07] <vila> but we display it *without* --forward
[18:07] <vila> A bit hard to explain :-/
[18:08] <jam> no, I understand what you mean
[18:08] <jam> IMO being consistent would be nice
[18:08] <jam> and I would probably go for "always show it"
[18:09] <jam> because I think it would be easier
[18:09] <vila> :-)
[18:11] <vila> Right, now, we understand each other I think :-) Easier for the dev may not be what the user is wanting, but the user may want other things first ! Does that summarize the discussion ?
[18:21] <jam> vila: yep
[18:21] <jam> Getting a "correct if suboptimal" result for log
[18:21] <jam> is the most important
[18:21] <jam> and getting other stuff done is better than optimizing the rest of log
[18:23] <vila> ok. I call it a day then (started a 6h30 this morning :)
[18:23] <vila> have a nice week-end !
[18:25] <LarstiQ> vila: you too!
[18:37] <jam> you too vila
[20:21] <jam> does anyone know if LP can handle 1.9 format branches yet?
[20:22] <beuno> jam, IIRC, it only has up to 1.8
[20:23] <beuno> actually, it's on 1.7.1rc1
[20:23] <beuno> so... only if used through sftp maybe?
[20:24] <beuno> I don't know how picky the smart server is about formats it doesn't know
[20:24] <jam> I don't think it can mirror branches from sftp => http side if it doesn't understand them
[20:25] <jam> and I don't think it can mirror a branch on my webserver if I upgraded it to 1.9 either
[20:25] <beuno> right, the puller will probably b0rk
[20:25] <jam> you would be able to *push* to bzr+ssh the first time
[20:25] <jam> and then future access will likely give "Unknown Format" errors
[20:25] <Peng_> Yeah, the puller can't mirror from 1.9 branches.
[20:25] <Peng_> (on external web servers, I mean)
[20:25] <jam> Perhaps if you used nosmart+bzr+ssh or some other crazy workaround like that
[20:27] <jam> which I suppose isn't terrible considering if you were using 1.9 it would trigger the auto-stack from LP, and we know that is a little bit buggy right now
[20:27] <jam> I'm trying to finish up Martin's fix and get it merged.
[20:29] <beuno> oh, that would be great
[20:29] <beuno> then we just push everyone to use nightly
[20:36] <jam> well, I think Martin wants to make sure things are going smooth
[20:36] <jam> and then have it all in 1.10rc1  which will be on Friday
[20:36] <jam> (1 week)
[21:34] <synic> how can I create a hook that only runs when a certain branch is pushed to?
[21:45] <freewilly1> Client-side? Use post_push. For server-side, you'll have to use post_change_branch_tip
[21:47] <freewilly1> I bet there's a way to check which branch is being operated on, but I don't know enough to answer that
[21:48] <synic> ok, yeah, that's what I'm looking for is which branch it is
[23:29] <synic> jam: ping
[23:37] <jfroy|work> Anyone here has setup some manner of automated Subversion Bazaar mirroring solution?
[23:38] <jfroy|work> Curious about people's experience, solutions, gotchas, and so on.


[15:38] <lordjj> Hey, can someone tell me how to disable Write Caching on my External USB Hard Drive in Ubuntu? Also will this disable it locally on my machine, or will it affect the external HDD such that wherever I connect it write caching will be disabled?
[16:38] <Armageddon> lordjj
[16:39] <lordjj> Hey whatsup
[16:39] <Armageddon> what do you need again ?
[16:40] <lordjj> I just bought an external Seagate 1TB usb hard drive
[16:40] <Armageddon> ok
[16:41] <lordjj> I read that disabling write caching would be safer, to avoid corrupted files in case of power out or sudden removal
[16:42] <lordjj> But its file system is NTFS, and I read NTFS doean't have that problem; that connecting it to a windows system and running diskcheck would fix any problems
[16:42] <lordjj> But I don't know, so far I've been told by some that you can disable write caching on it, and by others that I can not
[16:42] <Armageddon> not always
[16:43] <Armageddon> I was talking about the checkdisk
[16:44] <lordjj> Well is it possible to disable write cache on an NTFS drive?
[16:45] <Armageddon> from windows yes
[16:46] <lordjj> By changing the drives policies right?
[16:46] <lordjj> Does that apply to the drive? Or just in the Windows system?
[16:46] <lordjj> I mean when I connect the drive to another system will write cache be disabled?
[16:47] <Armageddon> in windows ?
[16:48] <Armageddon> you just to go to the hmm what's it called where you see your installed drivers
[16:48] <lordjj> Yeah driver manager
[16:48] <Armageddon> yea, and right click on your hard drive
[16:48] <lordjj> Bas my question is will it change settings in the actual drive?
[16:48] <Armageddon> should be there somewhere
[16:49] <lordjj> I mean when I connect the drive to another PC with Ubuntu, will write cache be disabled?
[16:50] <Armageddon> I'm not sure what write cache is, cause GNU/Linux works differently
[16:51] <lordjj> hm, well ok, in LInux, how is data copied onto a drive? Directly?


[00:18] <bassamt> hi, cloud-init is failing on init for me with the following error UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8d in position 0: invalid start byte
[00:19] <bassamt> version 0.7.7 from an Ubuntu 15.10 AMI.
[00:20] <bassamt> any ideas for how I can debug the issue? user-data in AWS does look weird (and not something I can change)
[06:29] <SuperLag> this is all I have in my cloud.cfg file http://pastebin.com/FrWTnHLf and when I try to SSH, it still asks for a password. What am I doing wrong? :/
[08:08] <SuperLag> I've changed it to be the stock file with only the stuff I needed included. It still doesn't work.
[08:08] <SuperLag> I clearly don't have a clue, and I'm at the end of my rope.
[08:08] <SuperLag> I'd be *happy* to pay someone to help me figure this out.
[11:30] <xael> hello all, i am Alex from Bigstep, currently working on adding a new datasource for the Bigstep cloud service and to also port our templates into using cloudinit
[11:31] <Odd_Bloke> xael: Hola!  (I'm Dan Watkins from Canonical. :)
[11:32] <xael> currently, I am having a problem with changing the password for the root user on a CentOS 6.6 machine running cloud-init 0.7.5
[11:32] <xael> by sending it in a hashed form, not plaintext
[11:36] <xael> the way in which i managed to do it was to add an 'hashed_passwd' option in distros/__init__ and use the existing set_password with the hashed parameter set
[11:44] <Odd_Bloke> xael: Can you pastebin the patch?  (Probably easier for me to grok that way :)
[11:46] <xael> http://pastebin.com/1j1yzxYB here you go, i pasted the whole function
[11:49] <Odd_Bloke> xael: That looks pretty sensible. :)
[11:52] <xael> what do you mean by sensible?:))
[11:52] <Odd_Bloke> xael: I mean: That looks like a change we should include in cloud-init. ^_^
[11:53] <xael> :D
[11:56] <xael> Odd_Bloke: did you manage to look over the datasource I sent you before the holidays?
[12:17] <Odd_Bloke> xael: I didn't, I think that must have got lost in the shuffle, I'm afraid.
[12:17] <Odd_Bloke> xael: Could you send it over again?
[12:20] <xael> of course
[12:21] <Odd_Bloke> xael: Sorry about that!
[12:21] <xael> no problem :D
[12:25] <xael> sent, could you please tell me if you received it?
[12:29] <Odd_Bloke> xael: Received; thanks. :)
[12:29] <Odd_Bloke> xael: I doubt I'll be able to get to it today, but I'll try to have a look on Monday. :)
[12:31] <xael> no rush
[12:36] <Odd_Bloke> :)
[12:51] <atonal> Hello, is user-data supposed to merge with stuff from /etc/cloud/cloud.cfg?
[12:51] <atonal> I have merge_type: 'list(append)+dict(recurse_array)+str()' in the user-data, but merge doesn't seem to happen
[13:08] <larsks> atonal: what in particular are you trying to merge?
[13:20] <atonal> larsks: some users
[14:28] <atonal> If I have two separate configs in the heat template with merge_type, they merge together fine, but stuff from /etc/cloud/cloud.cfg is missing
[14:28] <atonal> And if I remove the configs from the heat template, I get the stuff from /etc/cloud/cloud.cfg
[14:29] <smoser> atonal, can you show what you have in user data ?
[14:48] <larsks> smoser: I think I can replicate the problem.  I'm using this: http://chunk.io/f/6d69899a5f95470a8248256b731848bf
[14:48] <larsks> smoser: that seems to be *replacing* the users: block in /etc/cloud/cloud.cfg, rather than merging.
[14:48] <atonal> yes, that's close to what I have
[14:49] <larsks> (on my test systems, the users: block in cloud.cfg contains only "- default"
[14:49] <larsks> )
[14:51] <larsks> atonal: for what it's worth, I've always found the merging support in cloud-init to be confusing at best.  smoser and I have had several discussions where the outcome was "huh, I guess that won't work".
[14:51] <atonal> Confusing it definitely is.
[14:54] <smoser> larsks, i agree with you
[14:54] <smoser> :)
[14:55] <smoser> the merging is fairly straight forward for dict
[14:55] <smoser> and generally does the right thing
[14:55] <smoser> but for lists, its wierd. and by default it just replaces lists.
[14:57] <atonal> But in general, merging user data and /etc/cloud/cloud.cfg _should_ work? Or is this some undefined-behavior-land?
[15:00] <smoser> yeah.. but ther are some caviats.
[15:00] <smoser> caveats
[15:00] <smoser> atonal, for testing you can do this
[15:00] <smoser> PYTHONPATH=$PWD ./tools/ccfg-merge-debug config/cloud.cfg cc.cfg  > out.1
[15:00] <smoser> just from trunk. it will output a merged file.
[15:00] <larsks> atonal: I have never been able to successfully merge something with cloud.cfg, although i was trying to modify things like cloud_init_modules which if I recall are simply parsed too early in the process or something like that.
[15:01] <smoser> i did hyave to change the config/cloud.cfg to have '#cloud-config' at the top or it doesn't get considered cluod-config.
[15:01] <smoser> init_modules is parsed too early
[15:01] <smoser> but config_modules and final_modules can work..
[15:02] <larsks> ...although those are lists, like users:, and since the users merge doesn't seem to be working even with list(append), I'm wondering if those will work.  I guess that's a quick test...
[15:04]  * larsks tests.
[15:06] <smoser> actually... init_modules should be able to be re-written too.
[15:07] <larsks> smoser: you and I had looked at something like that in the past and discovered that I think it wouldn't work.  I thought.
[15:07] <larsks> I'd have to see if I still have the irc logs...
[15:09] <smoser> yeah. i think there is an issue with merging over builtin configs.
[15:09] <smoser> but i thoguth i would have ahd a bug on it and i dont see it.
[15:11] <larsks> smoser: so, e.g, this appears to just override cloud_config_modules rather than appending: http://chunk.io/f/f3325b6193234a87a8ac4c1fa9604966
[15:14] <SuperLag> I am still having issues getting my config to work. I just want to specify a user, and set up specific SSH keys for that user, and have that go into each instance I spin up. My config is at http://pastebin.com/ekjhZAEr.
[15:16] <SuperLag> Do you need to include every section in your cloud.cfg, and just leave the non-relevant parts blank? or do you only include the parts that you need?
[15:18] <smoser> larsks, yeah, thats the issue. the merges only apply to config coming in in user-data.
[15:18] <smoser> which would also be why the users dont work as expected.
[15:18] <smoser> could you open a bug, just point to your data. i'd like to fix that.
[15:19] <larsks> smoser: sure.
[15:22] <larsks> smoser: https://bugs.launchpad.net/cloud-init/+bug/1532234
[15:22] <smoser> SuperLag, the data you have there is not valid yaml
[15:23] <smoser> there is probably a WARN message to this affect in /var/log/cloud-init.log
[15:23] <smoser> but you can easily test yaml just with:
[15:23] <smoser>  python -c 'import yaml, sys; yaml.load(open(sys.argv[1]).read())' foo.yaml
[15:23] <smoser> now, that said, i'm not certain that ssh keys are added to a user if the user is not created. let me check
[15:24] <smoser> it should.
[15:24] <smoser> larsks, that is awell written bug report
[15:24] <smoser> thank you.
[23:10] <openstackgerrit> Joshua Harlow proposed openstack/cloud-init: Change stackforge to openstack  https://review.openstack.org/256684
[23:10] <openstackgerrit> Joshua Harlow proposed openstack/cloud-init: Update .gitreview for new namespace  https://review.openstack.org/236289
[23:11] <openstackgerrit> Joshua Harlow proposed openstack/cloud-init: Update stackforge to openstack  https://review.openstack.org/237452
[23:19] <openstackgerrit> Merged openstack/cloud-init: py26 is no longer supported by Infra's CI  https://review.openstack.org/261718
[23:26] <openstackgerrit> Merged openstack/cloud-init: Deprecated tox -downloadcache option removed  https://review.openstack.org/256694
[23:49] <openstackgerrit> Merged openstack/cloud-init: Update stackforge to openstack  https://review.openstack.org/237452


[15:06] -queuebot:#ubuntu-ci-eng- LocutusOfBorg Juliank, https://bileto.ubuntu.com/#/ticket/3141 Preparing packages
[15:30] -queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3142 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[15:42] -queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3142 Ready to build
[20:42] -queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3142 Abandoning ticket
[21:04] -queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3143 Failed to build (bionic/datalad, bionic/python-asgi-ipc). Pending binary packages (bionic/msgpack-python)
[21:24] -queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3143 Diff missing (bionic/msgpack-python). Failed to build (bionic/datalad, bionic/python-asgi-ipc)


[18:31] <qwebirc56516> hello
[18:31] <qwebirc56516> how do i determine the version of mythtv
[18:32] <qwebirc56516> i am having a problem setting up kodi mythbox addon