[02:57] <guiverc2> sorry qa-test of menu items (all items), i have parole playing music in background minimized.  if not running it loads on selecting on menu, if inactive window it becomes active, if minimized selecting it at menu does nothing; is this an issue?  (I'd suspect not ideal)
[02:57] <guiverc2> 19.10 daily ^
[07:56] <vinze> Hey all, long time no see (as in: more than half a decade...). I'm not sure who administers the xubuntu-devel mailinglist, but I just sent an email there that needs approval because I'm not a subscriber anymore - it's about transferring ownership of the Xubuntu subreddit.
[07:58] <Unit193> vinze: Approved, as for team members, https://launchpad.net/~xubuntu-team
[07:59] <Unit193> (Howdy!)
[08:05] <vinze> Thanks Unit193!
[08:05] <Unit193> No reddit account here, can't help you with that.
[08:05] <vinze> Actually still quite a few people from way back when, that's good to see :)
[08:06] <Unit193> I'd like to think I'm too new for that, but...I'm not. >_<
[08:07] <vinze> Seven years is quite a time - far longer than I was involved, I think. I just checked that I unsubscribed from the mailinglist in 2013, but was probably inactive for a while before that
[08:58] <Unit193> Nobody ever gave me a sock...
[08:58] <knome> good old vinnl
[08:59] <knome> pleia2, you on reddit?
[13:21] <pleia2> knome: no, it's terrible
[15:43] <pleia2> replied anyway
[16:53] <flocculant> bluesabre: re screensaver - am I right in gathering that to not have it working - you have to enable it and then set when idle to off?
[16:53] <flocculant> that's how it seems to work
[16:53] <flocculant> rather un-intuitive perhaps
[18:14] <flocculant> bluesabre: oh - with light-locker - which I believe chucks you to vt9 or something - screen locks etc - got music playing - it's then not audible - if it's still going, it's on vt8 (I think)
[18:15] <flocculant> I just accidentally locked - music still playing
[18:15] <flocculant> not sure it'd be a bug per se - just maybe a thing that happens that people didn't get before


[01:02] <Unit193> Well that's interesting, same upstream version of webkitgtk in both Xenial and Yakkety, but an application only segfaults on the latter (and unstable.)
[05:26] <pitti> Good morning
[05:27] <tsimonq2> o/ pitti
[05:28] <jbicha> pitti: good morning
[05:28] <tsimonq2> o/ jbicha
[05:28] <jbicha> the autopkgtest machines seem to be having trouble :(
[05:29] <pitti> hey tsimonq2, hello jbicha
[05:29] <tsimonq2> how are you pitti?
[05:30] <pitti> jbicha: indeed, I have lots of worker failure mails in my mbox :(
[05:30] <pitti> Welcome to [1mUbuntu 16.10[0m!
[05:30] <pitti> [    2.184796] systemd[1]: Set hostname to <16fad193-3c64-481d-9183-e3a7910315d0-adt-prepare>.
[05:30] <pitti> [    2.218417] systemd[1]: unhandled signal 4 at<PHONE_NUMBER>c6f370 nip<PHONE_NUMBER>c6f370 lr<PHONE_NUMBER>c721f4 code 30001
[05:30] <pitti> [    2.218730] systemd[1]: Caught <ILL>, core dump failed (child 553, code=killed, status=4/ILL).
[05:30] <pitti> !healthy :(
[05:31] <pitti> lcy and lgw often time out but at least caught up, but ppc64 is FUBAR
[06:01] <pitti> tracking in bug 1616743, FTR
[06:38] <pitti> ok, they are catching up
[07:18] <LocutusOfBorg> pitti, hi, you seem the best person to ask removal of runit-sysv package :) described in lp: #1595485
[08:04] <pitti> LocutusOfBorg: it only exists in yakkety-proposed, got reintroduced in your merge :)
[08:05] <pitti> LocutusOfBorg: current version just builds runit
[08:05] <pitti> LocutusOfBorg: so the merge needs to be updated to drop that binary, then it'll be NBS and get removed semi-automatically
[08:24] <LocutusOfBorg> pitti, I don't get, yes I have introduced it, but it failed to migrate because the runtime dependency was dropped in Ubuntu
[08:24] <LocutusOfBorg> so I removed it again
[08:25] <LocutusOfBorg> but now it is NBS, but not autodecrufted
[08:25] <LocutusOfBorg> https://launchpad.net/ubuntu/+source/runit/2.1.2-6ubuntu1
[08:25] <LocutusOfBorg> yes, you have to remove it only from proposed, this is true
[08:25] <LocutusOfBorg> and the latest merge is not building it anymore, from my point of view
[08:33] <infinity> pitti: NBS in proposed isn't tracked by anything but britney.
[08:33]  * infinity fixes.
[08:34] <infinity> LocutusOfBorg: Removed.
[08:34]  * infinity goes to bed for realz.
[08:46] <LocutusOfBorg> have a good night infinity :)
[08:46] <LocutusOfBorg> and thanks
[09:11] <mardy> yofel: hi! Do you think you could help with pushing the fix for bug 1451728?
[09:13] <yofel> if someone gives me ready made debdiffs for what I'm supposed to upload, maybe yes
[10:18] <seb128> dpm, hey, did you get any news from wgrant/cjwatson/pitti about langpacks in yakkety?
[10:19] <dpm> hi seb128, no, I didn't
[10:19] <seb128> :-(
[10:19] <cjwatson> it does need to be set up per https://wiki.canonical.com/Launchpad/Translations/UbuntuOpenings, I just haven't had time
[10:19] <cjwatson> (and won't this week)
[10:20] <seb128> cjwatson, ok, thanks ... can somebody else do that?
[10:20] <cjwatson> William may have time, I don't know
[10:20] <seb128> k
[10:20] <seb128> let's see if he replies
[11:28] <pitti> mwhudson: still here?
[11:29] <LocutusOfBorg> pitti, will pthon-pysam run for cython on amd64/proposed aswell? I see it in ppc64el, but not amd64
[11:30] <LocutusOfBorg> strange
[11:45] <pitti> LocutusOfBorg: kicked; pysam/i386 can't succeed as it isn't built any more; I'll sort that out once the rest of the tests get green
[11:54] <LocutusOfBorg> ta
[12:01] <LocutusOfBorg> pysam/armhf seems to have the same issue
[12:01] <LocutusOfBorg> and cbsuite/i386
[12:53] <pitti> slangasek, xnox: are there some tricks how to debug shutdown problems with upstart? I tried to run upstart-monitor (http://paste.ubuntu.com/23088846/), but this doesn't really tell me anything; after "reboot" it stops some stuff, but ssh etc. continues to run and it does not really reboot
[12:54] <xnox> running upstart in debug mode, and capturing console log is one way to do it.
[12:54] <pitti> if I stop /etc/init/systemd.conf manually there are no processes left, but it still doesn't shut down; so I figure starting the deputy systemd in trusty chagnes the system state somehow, but I don't know enough about how shutdown works with upstart to say which, I'm afraid
[12:55] <xnox> pitti, upstart doesn't do shutdown....
[12:55] <xnox> after it's done, it hands over to sysvinit to shutdown everything.
[12:56] <xnox> i'm guessing you will nit init.d script to stop subordinate systemd.
[12:56] <pitti> xnox: well, it should at least stop all jobs, no?
[12:56] <xnox> i'm guessing you will need init.d script to stop subordinate systemd.
[12:56] <pitti> xnox: that's not it -- as I said, I already ran "initctl stop systemd" and everythign is gone
[12:56] <xnox> nah, it doesn't stop all the jobs.... only those with "stop on" conditions
[12:56] <pitti> and after that, reboot just does http://paste.ubuntu.com/23088846/ but http://paste.ubuntu.com/23088865/ is still left
[12:56]  * xnox re-reads
[12:57] <pitti> xnox: a lot of things are "stop on stopping dbus", dbus itself is "stop on deconfiguring-networking"; all of these are still running
[12:58]  * xnox did say "init.d" script to stop systemd, not "init" - upstart job. probably sysvinit killall is failing to killall, and things have respawned or some such.
[12:59] <xnox> pitti, is there a way for me to get trusty VM with such systemd-delegate in an easy manner?
[13:00] <pitti> xnox: yes; let me upload the current git to a PPA
[13:03] <pitti> xnox: I used "autopkgtest-buildvm-ubuntu-cloud -r trusty" to build a trusty VM, and then scp over the .debs; dpkg -iO *.deb, then install libsystemd-journal0.deb and systemd.deb, that's it
[13:03] <pitti> building in https://launchpad.net/~pitti/+archive/ubuntu/systemd/+packages now
[13:03] <xnox> cool, tah.
[13:04] <pitti> if your local sbuild can beat it, it's in https://git.launchpad.net/~ubuntu-core-dev/+git/systemd-trusty :)
[13:05] <pitti> xnox: so, sometimes I notice that the deputy systemd changes utmp and then runlevel is "unknown"; but it also hangs if it is 2 as expected, so that's not it either
[13:05] <xnox> meh, i'm currently in round 2 match against juju reactive layers =)
[13:31] <pitti> xnox: ah, it finished building
[14:32] <LocutusOfBorg> pitti, I think you can ignore python-pysam failing testsuites now?
[15:35] <pitti> rharper: hm, do you still remember how you did DHCP over VLAN? I'm trying to run dnsmasq on a vlan interface and it jusjt fails with "no such interface" although it clearly exists in "ip a" and /sys/class/net
[15:35] <pitti> and that has poor google juice :/
[15:36] <rharper> pitti: it was done with switched based vlans
[15:36] <pitti> rharper: this is mostly for writing a more demanding test case; my current integration test case just adds static addresses and works, but I thought I'd give it a try
[15:37] <rharper> pitti: does it show up under ifconfig or ip list ? (the interface?)
[15:37] <rharper> the ip output shows interface-name@vlan_raw_interface
[15:37] <pitti> 115: nptestsrv@veth43: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
[15:37] <pitti>     link/ether ca:d8:4f:d0:f1:9e brd ff:ff:ff:ff:ff:ff
[15:37] <pitti> oh, it's DOWN -- that's not good I think
[15:37] <rharper> and you're telling dnsmasq interface is 'ntptestsrv' right ?
[15:37] <rharper> versus ntptestsrv@veth43
[15:38] <pitti> right
[15:38] <rharper> huh
[15:38] <pitti> dnsmasq --keep-in-foreground --log-queries --log-facility=- --log-queries --conf-file=/dev/null --dhcp-leasefile=/tmp/l  --bind-interfaces --interface=nptestsrv --except-interface=lo --enable-ra --dhcp-range=<IP_ADDRESS>,<IP_ADDRESS>
[15:38] <pitti> rharper: anyway, for my other test interfaces I up them first and give them some IP, I forgot to do that for this one
[15:39] <pitti> rharper: so, probably just PEBCAK, and the usual "find the reason right after you ask in public"
[15:39] <rharper> pitti: =)
[15:39]  * pitti is still amazed how often this works -- enlightenment through embarrasment
[15:41] <pitti> rharper: works like a charm \o/
[15:41] <rharper> nice!
[15:41] <pitti> which is a cooler test than with static addresses :)
[15:47] <infinity> pitti: I'm not sure if it's enlightenment through embarrasment or just putting yourself in another mindset by asking the question.
[15:47] <infinity> pitti: I find asking leads me to the answer myself surprisingly often.
[15:47] <pitti> infinity: in a lot of cases it's actually that
[15:47] <pitti> not for this case, I just spotted what I previously didn't look at
[15:48] <infinity> pitti: It's also a weird skill not everyone has.   The above example specifically, actually.
[15:48] <infinity> pitti: Commonly, you'll find yourself pasting a log or typescript saying "LOOK, IT DOESN'T WORK BECAUSE... Oh.  Hah.  I can read, really."
[15:49] <infinity> pitti: Lots of people seem to be incapable of spotting the error on countless reads.
[15:49] <pitti> we call  that "Scheuklappen-Effect" ("blinker effect")
[15:49] <infinity> Germans really do have a word for everything.
[15:49] <pitti> not sure if "blinker" is right, the things that horses wear on their eyes
[15:49] <infinity> Blinders.
[15:50] <pitti> you look at one thing from one angle for so long that you forget other perspectives
[15:50] <infinity> Akin to tunnel vision.
[15:50] <pitti> right, that
[15:51] <infinity> They say English is the most expressive language (and with the number of languages we've ripped off, we bloody well should be), but no one seems to come up with nouns and noun phrases that describe precise situations and emotions as well as Germans.
[15:52] <pitti> we can build arbitrarily long words :)
[15:52] <infinity> That's probably it.  You can turn a noun phrase into a single noun.
[15:52] <infinity> And we're stuck with the phrase.
[15:52] <infinity> So, an English idiom is a German word.
[15:53] <pitti> and I now learned how vlans work
[15:53] <pitti> they are a thing now in netplan for networkd; now off to teach it the equivalent thing for NM
[15:54] <infinity> I still say Fausthandschuhe is my favourite German word.
[15:54] <pitti> actually no -- off to making dinner
[15:54] <infinity> Just the absurdity of it.
[15:54] <pitti> infinity: wow, that's the weirdest one you found?
[15:54] <infinity> pitti: No, there are much weirder, but I love the literal derivation of that one.
[15:54] <infinity> Gloves are hand shoes.  And mittens are fist hand shoes.
[15:54] <tsimonq2> LOL that translates to "mittens"
[15:54] <infinity> tsimonq2: Yes. :)
[15:55] <infinity> tsimonq2: Literally "fist hand shoes".
[15:55] <tsimonq2> so complicated for that word that's kinda little in English
[15:55] <tsimonq2> LOL
[15:55] <pitti> oh, wow -- so far I had interpreted "mitten" as a thick glove you use for taking things out of the oven
[15:55] <ogra_> hmm, now that talk about vlan made me hungry ... (reminding me of https://en.wikipedia.org/wiki/Vla )
[15:55] <infinity> pitti: That's a mitt.  Confusingly enough, we have a distinction.
[15:55] <Laney> Oven glove
[15:55] <infinity> pitti: Mitts are thick mittens used for things like ovens and baseball.
[15:55] <pitti> ogra_: yummy
[15:55] <infinity> pitti: Mittens are winter clothing without fingers.
[15:55] <tsimonq2> http://img.ctrlv.in/img/16/08/25/57bf1507aa7ed.png
[18:50] <nacc> mdeslaur: re: LP: #1612089, based upon the last comment, do we need to do a revert in the cloud-archive version too?
[18:50] <mdeslaur> nacc: yes, the regression is being worked on on qemu-devel
[18:50] <mdeslaur> nacc: no fix yet besides the revert
[18:51] <nacc> mdeslaur: right, i meant more if you already had a handle on the cloud-archive revert, or if i should follow up on that myself )
[18:51] <mdeslaur> nacc: I don't touch the cloud-archive
[18:52] <nacc> mdeslaur: ok :)
[18:52] <mdeslaur> nacc: thanks
[18:52] <nacc> jgrimm: --^ who should i follow up with?
[18:52] <jgrimm> nacc, jamespage or coreycb
[18:53] <nacc> jgrimm: ack, thanks
[18:53] <jgrimm> np
[18:54] <nacc> jamespage: coreycb: just fyi, re: LP: #1612089, i'm trying to find the changelog for that version mentioned in c7, but it might need the same revert done in the primary archive
[19:09] <nacc> coreycb: i think it was your upload based upon https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/liberty-staging/+packages?field.name_filter=qemu&field.status_filter=published&field.series_filter= and the solution is to disable debian/patches/CVE-2016-5403.patch. Do you want a patch for that?
[19:33] <coreycb> nacc, I'll handle the cloud archive bits, thanks for the nudge
[19:33] <nacc> coreycb: thanks!
[19:34] <nacc> jgrimm: afaict, with that --^, we can unsub ubuntu-server from the bug, right?
[19:35] <jgrimm> nacc, i guess, tho we don't usually, just let it ride out to closure
[19:38] <nacc> jgrimm: oh ok


[11:54] <janimo> apw, are there any scripts or docs to help me get started with a config syncup for the nexus7? I am hoping there is a cleverer way than going through the file line by line
[11:59] <apw> janimo, what are you going to sync it to, its a completely different version
[11:59] <janimo> apw, I was hoping to get an answer to that to :)
[11:59] <apw> janimo, but in answer, there are scripts to compare configs indeed and highlight relevant changes; if you have something to compare to
[11:59] <janimo> would a 3.1 based previous Ubuntu mainline kernel be much different from Raring's?
[12:00] <apw> janimo, we use them for our cycle configuration reviews
[12:00] <apw> janimo, yeah, tons different
[12:00] <apw> they change configuration options all the time
[12:00] <apw> i guess you should compare to 3.2 as that is at least close, but that is before we did a lot of the harmonisation work
[12:00] <janimo> so mostly name changes but in spirit our configs are similar across relelases?
[12:01] <janimo> I feel this harmonisation will be painful
[12:01] <apw> in spirit yes, in implementation less so, it has taken us 4-5 cycles to get our configs in good order
[12:02] <apw> janimo, though i think if i was doing it i would only be caring about the common options
[12:02] <janimo> something I hope can be leveraged fir the nexus7 task as I don't think we want to spend quite so much time on it
[12:02] <janimo> apw, common as in those kept in ubuntu.config.common?
[12:02] <apw> janimo, no, as in those pulled out as particularly interesting in the config review: http://kernel.ubuntu.com/~kernel-ppa/configs/raring/reviews/UDS.html
[12:03] <janimo> I was thinking if we had some higer level description like : LXC support, Overlay support, All Webcams Ever, etc. Which would then be used as a source to generate actual config options for various kernels
[12:03] <janimo> does that sound implausible?
[12:03] <apw> we do not have that
[12:03] <apw> we have some slightly lower level rules
[12:04] <ogra-cb_> hmm, did we update the nexus kernel to something newer ?
[12:04] <janimo> would that be something worth having or it was considered and abandoned?
[12:04] <janimo> ogra-cb_, 4.2 android branch
[12:04] <ogra-cb_> there seem to be tons of issues with the latest kernel
[12:04] <janimo> rtg did it
[12:04] <ogra-cb_> under android that is
[12:04] <apw> we are working towards that, but we do not have it yet
[12:05] <apw> we have components of it, but its not in any useful form you can apply to a system
[12:05] <ogra-cb_> (draining your battery fast, several kernel oppses etc)
[12:05] <apw> ogra-cb_, sounds awsome
[12:05] <janimo> ogra-cb_, you mean Android 4.2 on the nexus has issues because of the new kernel?
[12:05] <ogra-cb_> well, it has issues
[12:05] <ogra-cb_> and if there are ioopses i would blame the kernel, yeah
[12:06] <ogra-cb_> -i
[12:06] <janimo> there were very few changes in the kernel - not that they could not be invasive
[12:06] <ogra-cb_> well, i guess we'll see
[12:06] <apw> ogra-cb_, is that with the android build, or with ours
[12:06] <ogra-cb_> but a battery life cut in half sounds a bit scary
[12:06] <janimo> ogra-cb_, well userland or firmware can cause oopses no?
[12:07] <apw> janimo, anyhow if you get me a config i can get a basic report done for it
[12:07] <janimo> if it manifests on the ubuntu images we should worry I agree
[12:07] <ogra-cb_> apw, android kernel under android 4.2, the google error tracker is ful of nexus7 and 10 probs
[12:07] <ogra-cb_> i guess a lot are userspace as well
[12:07] <apw> ogra-cb_, nasty nasty
[12:07] <janimo> apw, so if I get you a config file (the current say) you can make a report highlighting what may need to be added?
[12:07] <apw> i can make a report, we can then see if it is useful
[12:07] <ogra-cb_> well, i just flashed mz first raring image to the nexus7, lets see if the even boots at all
[12:07] <janimo> ogra-cb_, since nexus 10 is a different SoC it may indeed be userland
[12:08] <ogra-cb_> janimo, yeah, thats why i mentioned that
[12:08] <janimo> apw, thanks, I'll paste you a config shortly
[12:08] <ogra-cb_> yay
[12:08] <ogra-cb_> it boots !
[12:08]  * ogra-cb_ is in initrd, tarball is being verified
[12:09] <ogra-cb_> heh, and flashing from the chromebook is possible :)
[12:25] <janimo> apw this is the current config http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-nexus7.git;a=blob_plain;f=debian.linaro/config/config.common.ubuntu;h=b4f6b5b5cbf53b8188bb90c3c0d5cceff79362c4;hb=HEAD
[12:44] <apw> smb, cking, ogasawara, a new toy for you: https://launchpad.net/~/+upcomingwork
[12:45] <apw> a _live_ indication of your milestoned workitems and bugs
[12:45] <cking> nice, that's more helpful than burndowns
[12:45] <smb> apw, Damn, that is too useful and makes it kind of hard to claim one did not know...
[12:46] <apw> the only wrinkle is blueprings need to be milestoned correctly for it to show them
[12:46] <apw> i am working through ours now to fix them
[12:46] <cking> +1 for apw
[13:01] <apw> cking, ok your list looks much less well :)
[13:01] <cking> much less?
[13:01] <apw> you have a lot more stuff now
[13:02] <cking> sad trombone sound applies
[13:02] <janimo> apw, is the link I pasted enough?
[13:02] <apw> janimo, i will sort it out
[13:03] <janimo> ok thanks
[13:30] <apw> ogasawara, oh and for you as owner of blueprints see all of the work items you are responsible for even if you arn't the assignee, nice
[13:45] <Kano> hi, why is kernel-wedge not in sync with sid for raring?
[13:46] <Kano> i thought you rebase the system every 6 month on sid
[13:47] <ogra-cb_> janimo, apw, FYI the nexus kernel from teh archive works fine
[13:47] <apw> ogra-cb_, heh ... thats something
[13:48] <apw> Kano, things which have delta do not automatically sync
[13:48] <ogra-cb_> if only userspace would be so well too
[13:48] <Kano> apw: then do it manually
[13:48] <Kano> its boring to do that everytime on my own
[13:49] <apw> or perhaps as it does what i need as it is i could not do it
[13:49] <Kano> it is bad when the version is lower than sid
[13:50] <Kano> and you do not even provide a patch file as it is a native package
[13:51] <Kano> ubuntu patches are often down in a very stupid way
[13:51] <Kano> everything in diff
[13:51] <Kano> well in that case there is not even a diff
[13:51] <Kano> efibootmgr is patched without quilt
[13:52] <cking> is that "do it manually so my distro can benefit too" kinda plea?
[13:52] <Kano> no good maintainer would do that
[13:53] <apw> for a native package like that the archive versions are the version control
[13:54] <Kano> and for efibootmgr?
[13:56] <apw> efibootmgr only exists in debian because someone in ubuntu actually maintains it there
[13:56] <Kano> sure and without ubuntu debian would not exist
[13:57] <Kano> or what
[13:57] <apw> my point was more that the delta is minor and to do with the fact that we maintain it there too
[13:57] <apw> so every debian derivative benefit
[13:57] <apw> my point was only that we do what we can to keep debian as the gold standard
[13:57] <apw> and only carry delta like that when we need to to not affect debian
[13:58] <apw> and i am struggling to find your point
[13:58] <Kano> usally the point is to make changes upstream which fix things
[13:58] <apw> right but efibootmgr is different cause we do not have the same list of architecture
[13:59] <Kano> debian never had lpia
[14:00] <Kano> what you changed is pure ubuntu specific
[14:00] <apw> well all i can say is the two packages you picked out have very active debian centric people as their maintainers
[14:01] <Kano> so active that no patch is in debian
[14:02] <apw> for those two packages maybe, but for the 100s of others i can assure you there ar
[14:02] <apw> are, your presumption that we don't care about debian is plain unreasonable
[14:02] <apw> the delts in kernel-wedge is a kernel related issue whering our useage and theirs does not match
[14:03] <apw> as we have differnet kernels, it is not upstreamable
[14:03] <Kano> the -w fix is for upstream
[14:03] <Kano> and should not be in a diff
[14:05] <Kano> http://packages.ubuntu.com/source/raring/kernel-wedge
[14:05] <Kano> why is there no ubuntu git shown?
[14:06] <apw> we don't mantain the delta in version control perhaps
[14:42] <herton> apw, can bug 1075181 can be marked verified for linux-lts-quantal? Just want to make sure the precise package was tested
[14:42] <ubot2> Launchpad bug 1075181 in ubiquity (Ubuntu Precise) "Backport UEFI Secure Boot support for Ubuntu 12.04.2" [High,Triaged] https://launchpad.net/bugs/1075181
[14:42] <herton> *precise proposed package
[15:12]  * herton -> lunch
[16:01] <hggdh> infinity: panda tests in progress (one done); armada depends on a bit of hacking, still looking at all the data rbasak gave me
[16:13] <ogasawara> rtg: heading in now
[16:59] <apw> ogasawara, rtg, heads up for the next upload, kernel-wedge has been updated -- should be benign but you never know
[16:59] <ogasawara> apw: ack
[17:20]  * ppisati -> gym
[17:23] <rtg> apw, I upgraded the raring chroots on gomeisa and tangerine. I noticed that kernel-wedge is still the same version as quantal. still building ?
[17:26] <apw> rtg, still briney-ing
[17:27] <rtg> apw, ah
[17:39] <apw> rtg, ogasawara, that reminds me, i have pushed the first stage of the autopkgtest tests we have been asked for by pitti
[17:40] <rtg> apw, saw that
[17:41] <rtg> apw, I'm still busily ripping out duplicate firmware
[17:41] <apw> rtg, i am loving that
[17:41] <apw> rtg, i see a heap of it is hitting mainline too, nice
[17:42] <rtg> apw, there was a surprising amount of resistance to some of those patches. go figure.
[17:48] <apw> rtg its most perlexing and no mistake
[18:38]  * apw moans about the publisher taking _ages_ todayu
[20:56] <apw> rtg, ogasawara, ok i have just built some kernels with the new kernel-wedge, they look within the noise the same to me
[21:07] <ogasawara> apw: ack, thanks
[21:20] <apw> rtg, ogasawara, ok just tested overlayfs and aufs on the 3.7.0-3 kernel (amd64 and i386) and all is well
[21:21] <rtg> apw, ack
[22:29] <infinity> Whoever owns /home/kernel/kteam-bugs/code/reports/auto-reports-mako on lillypilly, it desperately needs locking.  There are a dozen copies running right now.
[22:30] <infinity> herton: ^-- That something you know about?
[22:31] <bryce> infinity, maybe brad or bdmurray?
[22:32] <infinity> bryce: I see no brad, and bdmurray isn't kernel.
[22:50] <herton> infinity, sorry, I don't know about this one
[22:54] <sconklin> infinity: looking. It's brad's but he's on the road, I should have perms to deal with it
[22:55] <sconklin> someone most have already killed them
[22:59] <sconklin> infinity, herton: I see nothing the the logs indicating a problem, and only two copies running (which is still a problem). I'm going to just remove it from the crontab and email brad, as I'm about to bail for the holiday. Probably no one will notice if it doesn't regenerate bug reports until Monday, and Brad may get to it before then
[23:00] <herton> sconklin, ack
[23:01] <infinity> sconklin: Thanks.  I suspect a bit of trivial locking wouldn't be hard.  Or one could ask IS to install run-one on lillypilly, and wrap it with that.
[23:02] <sconklin> infinity: agreed What I suspect happened is that it runs every half hour, and it just reached a runtime of over that.
[23:02] <infinity> sconklin: Well, the desktop team had a script throwing the machine into swap death, so it handily exposed everyone else who had scripts that failed to lock. ;)
[23:02] <sconklin> haha, ok


[00:08] <bob2> why did you version things you don't want to keep
[08:09] <mgz> morning
[08:25] <jam> hi mgz
[08:57] <jelmer> jam, mgz: hi
[09:01] <mgz> morning jelmer, feeling any better this morning?
[09:02] <jelmer> mgz: Somewhat, fever seems to be gone  but still having an aching head.
[09:02] <mgz> cut it off!
[09:03] <fullermd> Cut off his head, or cut off his body?
[09:04] <mgz> just the achy bit
[09:12] <vila> doh, sorry about that jelmer, I didn't know that kind of virus can propagate via IRC...
[09:12] <jelmer> :P
[09:16] <mgz> vila: on bug 996401
[09:16] <vila> yes ?
[09:16] <mgz> as far as I can see, there's still no way for gordon to store the line needed for the merge tool without config trying to expand things that don't exist when just using `bzr config OPTION`?
[09:17] <vila> let's split your remark into 1) no way to store 2) just using bzr config OPTION
[09:17] <vila> 1) is not true, there is no expansion when storing a value
[09:17] <mgz> there's no way of quoting the { to say "this is a { in the option, not an config template"?
[09:18] <vila> 2) is not applicable for a template that will provide the missing options
[09:18] <vila> there is no need for quoting
[09:19] <vila> the trick is that most options are expanded by default, but *some* should not (templates for examples)
[09:19] <mgz> currently it seems like any config option that might have {} in it will behave oddly in some circumstances
[09:19] <vila> hehe, name one :)
[09:20] <mgz> well, the merge tool, it's using {} for its own templating, not done by config
[09:20] <vila> but that's a template so when dealing with config you should ask for no expansion
[09:20] <vila> that's the point of templates...
[09:21] <mgz> but it's not a *config* template, it's a string config stores that happens to be a template
[09:21] <vila> config provide (now, not when gordon wrote his stuff) .expand_options() for exactly this purpose
[09:22] <mgz> ah, so you now want the config lookup to do the resolution?
[09:22] <vila> dig the review of gordon's proposal, it was a known missing feature and I didn't want to block him
[09:22] <mgz> that's a little complicated by merge needing to know what arguments are present to know what files to create on disk
[09:22] <mgz> as different merge tools expect different inputs
[09:23] <vila> no, templates should use expand_options(string, env={the needed additional options that are not config options})
[09:24] <vila> the additional options do not need to be registered, each template can define whatever it sees fit
[09:25] <vila> the only drawback is that 'bzr config TEMPLATE' needs to specify --all to *avoid* expansion, small price to pay for an edge case IMHO
[09:26] <mgz> right, but merge tool needs to know what the additional options are specifically (which vary for different merge tools), before doing work
[09:26] <vila> err, it cannot deduce unknown options from thin air, there is only a limited supported set
[09:27] <vila> it's unrelated to config but specific to mergetool
[09:27] <mgz> right
[09:27] <mgz> so, mergetool should really have a way of just escaping the templating entirely...
[09:27] <vila> it has, config.get('template', expand=False)
[09:28] <vila> and I'm pretty sure it already uses it
[09:28] <mgz> this is an edge case, but having magicstring  syntax without a way to say in the string that the next bit isn't syntax is odd
[09:28] <vila> YAGNI
[09:28] <vila> so better keep that stuff simple
[09:29] <mgz> it'd be like having \0 mean something but \\0 meaning \ + NUL rather than \ + 0
[09:29] <vila> yeah, I know the rationale and generally dislike the absence of escape notation, but there is just no need here
[09:30] <vila> at least I've yet to see a case where it's needed
[09:37] <mgz> I find the story from the question linked to that bug a pretty persuasive one, and it's not fixable from the mergetool side
[09:37] <jelmer> mgz: still there?
[09:37] <vila> mgz: url ?
[09:37] <vila> mgz: sry, missed 'from the bug'
[09:38] <mgz> https://answers.launchpad.net/bzr/+question/196441 <- ftr
[09:39] <vila> right, the misunderstanding there is that template can be used with 'bzr config TEMPLATE' as said above, that's an edge case where you should indeed use 'bzr config --all TEMPLATE'
[09:40] <vila> why will an escape mechanism address that ?
[09:40] <vila> you may as well say that templates should use a different reference format
[09:40] <vila> and a different expansion framework
[09:41] <mgz> but from the user perspective, that series of steps seems sensible, but the output makes it look like you've messed up
[09:42] <vila> doc bug then
[09:42] <mgz> it's not really, why should they read documentation for that?
[09:42] <vila> where did they hear about mergetool ?
[09:43] <vila> how would they find which parameters they need to provide to their new mergetool without a description of {this} {other} {result} {tmp-whatever-I-can-never-remember-that-one}
[09:44] <mgz> what do we add to <http://doc.bazaar.canonical.com/bzr.2.5/en/user-reference/configuration-help.html#bzr-mergetool-name> to make it clear that using mergetool breaks config?
[09:45] <vila> oh come on, using mergetool do not break config, mergetool *cannot* be used without config
[09:45] <vila> and you just found where the fix should go :)
[09:46] <vila> also note that this piece of doc mentions that some arguments need to be quoted (yeah, a different issue than the config escape mechanism)
[09:47] <vila> I mean, I'd rather add an escape mechanism to config than deal with users confusion when they need to use it :)
[09:50] <vila> bah, bzr.mergetool.kdiff3 is not even registered :-/
[09:54] <vila> mgz: https://pastebin.canonical.com/74784/
[09:56] <mgz> vila: in unrelatedness, the progress bar config option is nice
[09:57] <vila> in itself you mean ? Or how the proposal fixes the bug so trivially ?
[09:57] <mgz> both!
[09:58] <vila> right, you know, my new config proposal started with: "Not all needs can be addressed by the default values used inside bzr and
[09:58] <vila> bzrlib, no matter how well they are chosen (and they are ;)."
[09:59] <vila> progress bar is the canonical example: we went through several iterations to dwim... but in the end, there are always edge cases where the user should be able to set the Right Thing
[10:00] <vila> ... and without needing to write a single line of code
[10:03] <mgz> vila: so, apart from "the following will (rightly) break"... that doc change is okay
[10:04] <vila> hehe
[10:04] <vila> so s/(rightly)// ?
[10:04] <vila> https://code.launchpad.net/~vila/bzr/mergetool-doc/+merge/125150
[10:04] <vila> by the way
[10:05] <mgz> I'm not sure you want to give the broken example at all
[10:05] <fullermd> If we don't give broken examples, how will people know it's open source software?
[10:06] <vila> well, then the working one makes less sense as --all requirement is less clear
[10:06] <vila> fullermd: pff
[10:06] <mgz> if we don't give "you're doing it wrong you silly user" documentation, how will people know...
[10:07] <fullermd> ... that they're using git?  But this is for bzr, isn't it?
[10:07] <vila> well, I'm pretty sure simone (the guy/girl) asking the question read that doc you cited and mergetool templates can be tricky...
[10:07]  * fullermd has got his snark burner running on overdrive tonite.
[10:08] <vila> lunch break, bbl, daughters hate it when they prepare it and I'm late ;)
[10:08] <mgz> girl I think, but that sounds so much more condecending that guy
[10:08] <mgz> there's not a good equivalent, so guy should just become gender neutral
[10:09] <fullermd> "motile sack of mostly water"?
[10:10] <vila> I think simone can be a male italian first name
[10:11] <fullermd> Anyway, it's English; the masculine has always been the gender mixed-or-indeterminate form for pronouns, at least up 'till the last couple decades of rampaging.
[10:11] <mgz> ...blasted continentals, I'm still not used to andrea being a male name, or anne
[10:12] <fullermd> Many years ago, in my youth, I knew this guy named Jamie, who was dating this girl named Jamie.
[10:12] <mgz> everyone needs sensible, obviously masculine names, like matthew.
[10:12] <fullermd> (I'm pretty sure that was the _only_ reason they dated, briefly as it was)
[10:13] <fullermd> No, only the most handsome and brilliant people should have named like Matthew.
[10:13] <bob2> haha
[10:14] <bob2> I knew a couple of James's
[10:43] <ant384> Hello.
[10:44] <mgz> hey
[10:45] <ant384> Just starting with Bazaar. I set up a repository on a server, checked out a trunk, and now I'm playing with stuff. I managed to get info on all subjects except creating a header with keywords such as $Date$, $Author$, etc. I installed bzr-keywords, but can't figure out how to make it work. I used the version-info command to generate a version.py, but don't know where to place it. Please help. :)
[10:46] <mgz> so, in general keywords are a bad habit from older vcses that you want to drop for other ways of doing things with a dvcs
[10:47] <fullermd> For the former, the keywords plugin functions mostly at a PoC level.  For the latter, it depends what you want to do with the version.py   ;)
[10:47] <mgz> putting that info into your build system rather than your versioned source is generally advisable
[10:50] <ant384> I'm only working on python and shell scripts so far, so I'd like to have a header in them, in order to know what I'm testing / working on. Is it a bad idea in itself ?
[10:51] <mgz> ant384: yes, you can just get that info from the vcs itself
[10:51] <mgz> with a fancy editor, you can even have a call out to bzr to display that stuff to you alongside the file
[10:51] <mgz> fullermd may have suggestions on that front
[10:52] <ant384> So if I have a script that does X things on serveral machines, how do I make sure it's updated to the last version, if all I see is the code itself, with no version information ?
[10:52] <fullermd> In probably a good 75% or so of the cases where you'd use keywords in CVS, there are better choices in modern systems.
[10:52] <fullermd> In the other 25 or 20 or 10 or whatever percent...   well, you suffer.
[10:54] <mgz> ant384: so, for example in that case, seeing the revno/date of last commit to the branch you're working on by the file would solve that
[10:58] <ant384> So simply compare the script creation date with the date of the last commit to the branch ?
[10:59] <fullermd> That wouldn't tell you anything definitive, at least absent very particularly constrained workflows.
[11:00] <fullermd> One common simple setup would just be that you don't throw the script around by itself, you just have real branches or checkouts or whatever of it on each system, so you have all the VCS info right there to see.
[11:00] <ant384> Aiee.
[11:02] <ant384> Well, here's my current situation: maintaining / developing some bash and python scripts for my employer, aside from my real job. They're generally unique to the machine they're deployed on. I "develop" on my workstation, and use "header" type information in each file. Now I got a server that's usable as a central repository for code (among other things).
[11:03] <ant384> The idea was to get everything on that server in Bazaar, then checkout scripts when I work on them, commit, and then deploy.
[11:03] <ant384> Are you suggesting that it's a sane (you can tell I'm not really a programmer :) ) solution to check out each script on each machine it's used on ?
[11:04] <mgz> what would you do otherwise, scp?
[11:04] <fullermd> It can be.  A very situational thing.
[11:04] <mgz> the real question is whether it's sane to have a branch per independant script
[11:04] <mgz> and I do do that for some things (again, with a few helpers to making using bzr-as-rcs a bit nicer)
[11:05] <ant384> Some of the scripts get very large. I would love to use a versioning system to track changes and plan work.
[11:05] <fullermd> The alternative, assuming the keywords PoC isn't sufficiently there for you (which I expect it isn't) is that the "deploy" process has to do whatever rewriting to stash the info somewhere convenient.
[11:06] <ant384> I see.
[11:06] <fullermd> (e.g., with sed(1), as I do in one project)
[11:06] <ant384> So instead of linking version info to the source file, I should link it to the deployment process, and only generate it as needed.
[11:07] <mgz> yes, or just have checkouts as your deployment
[11:09] <ant384> I'll give it some more thought. Thanks a lot for the opinions, guys. :)
[13:48] <SamB_MacG5> okay, I've got a run_bzr()-based test, and I want to look at the output of a bzr command for debugging purposes ... what can I stick into the test temporarily to do that ?
[13:48] <SamB_MacG5> hmm, "assert False" after a selft.run_bzr *almost* works, but it has "\n"s instead of actual newlines
[13:51] <mgz> so, run_bzr returns (out, err) as strings
[13:51] <mgz> one way to develop is to do `out, err =  self.run_bzr(...); self.debug()`
[13:52] <mgz> which will drop you into pdb and you can look at the locals
[13:52] <mgz> or you can `self.assertEqual("", out)` and work from there
[13:58] <SamB_MacG5> ah, cool
[14:21] <SamB_MacG5> darn, something is wrong with "bisect run" ...
[14:22]  * SamB_MacG5 wonders if he can have broken it?
[14:53] <mgz> SamB_MacG5: more specifically? or have you worked it out?
[15:00] <SamB_MacG5> Well, at least, I'm confused about my attempts to write a grep-using testcase for the -r feature I'm adding ...
[15:01] <mgz> SamB_MacG5: if you stick some code in a branch or pastebin I'd be happy to give pointers
[15:02] <mgz> the hiccough is probably that the current tests aren't that great
[15:04] <SamB_MacG5> well, it doesn't seem to make a difference whether I tell it to run "grep one test_file_append" or "grep -v one test_file_append" in my attempt at a test ...
[15:05] <SamB_MacG5> lp:~naesten/bzr-bisect/683822-bisect-start-range-argument/ and https://gist.github.com/3750150
[15:05] <SamB_MacG5> and yes, I know it's kind of silly to use gist for bzr stuff, but I had an Emacs command for it handy, so ...
[15:05]  * SamB_MacG5 has to run
[15:06]  * SamB_MacG5 will check back for tips later, though: thanks for offfering!
[15:07] <SamB_MacG5> mgz: so long!
[15:08] <mgz> later!
[15:12] <mgz> SamB_MacG5: so, run_bzr doesn't actually start a shell subprocess, so you can't just use grep
[15:12] <mgz> bisect has support for running a script, but that's as a seperate command
[15:13] <mgz> ...which you're using, but not with an actual script, but directly?
[15:13] <mgz> bisect is somewhat arcane here, what's it actually doing
[15:35] <mgz> SamB_MacG5: your grep is just wrong I think, you want it to only match on rev 3 but not rev 4 and 5
[15:36] <mgz> but test_file_append alwasy has 'one' in it... it gets appended to, not replaced
[15:42] <mgz> SamB_MacG5: and more specifically, -v is not useful because there's always at least one line that doesn't match -> returncode 0
[16:03] <ls3_> Hello. How can I find out where 'bzr push' is going to push to by default?  (ie with no push args)
[16:04] <LeoNerd> bzr info
[16:04] <ls3_> ah wow, thanks.
[16:05] <mgz> what LeoNerd said, or `bzr config push_location` for just that
[16:05] <ls3_> Do you mean 'parent_location' ?  I get push_location does not exist.
[16:06] <mgz> right, that. :)
[16:06] <mgz> hm, no, push_location
[16:06] <mgz> but it might not be set
[16:07] <mgz> in which case `bzr push` will tell you that
[18:16] <SamB_MacG5> mgz: oh, duh, always one line that doesn't match ...
[18:16] <SamB_MacG5> thanks!
[18:17] <SamB_MacG5> oh, he's gone
[18:17] <jelmer> ... and there's no wgz atm :(
[18:18] <SamB_MacG5> anyway, yes, the documentation for "bzr bisect run" should mention that the command is run through the shell...
[23:16] <delinquentme> hey all .. I want to add a single file to a commit
[23:16] <delinquentme> and bzr decided to add every file that was changed to the commit
[23:16] <delinquentme> i used $ bzr add /path/to/file.rb
[23:17] <delinquentme> and then $ bzr commit -m "som merssage"
[23:18] <delinquentme> then i get this: https://gist.github.com/60ff7b7c9c6f886e1946
[23:18] <delinquentme> am I doing something wrong here?
[23:18] <SamB_MacG5> delinquentme: bzr assumes you want to commit everything unless told otherwise
[23:19] <SamB_MacG5> lately I've been using the qcommit command, which lets you uncheck what you don't want
[23:19] <delinquentme> how can I only add files which I specify to be committed
[23:20] <SamB_MacG5> "bzr help commit" probably says?
[23:21] <delinquentme> looking ...
[23:21] <delinquentme> and how about to drop back to the previous commit?
[23:22] <delinquentme> something akin to $ git reset --hard HEAD^
[23:23]  * SamB_MacG5 forgot
[23:26] <delinquentme> bzr help qcommit giving me nothing
[23:34] <delinquentme> in the event of a conflict
[23:34] <delinquentme> which file is the one that is .moved
[23:35] <delinquentme> the one which was previously committed to the repo is the normal one ... right?
[23:35] <delinquentme> and the local copy which differed... is renamed with .moved
[23:39] <fullermd> As for the former, you're reading 'add' in a git way.  In bzr it just adds the file to the list of those being tracked.  If you want to commit only a subset, you list them in the commit command line.
[23:40] <fullermd> "previous committed to the repo" is pretty ambiguous.  .moved comes about because a new file (dir, etc) was created independently in the local and the remote branch.  I believe the one called .moved is the one that came about locally.
[23:41] <lifeless> git add really should be git stage
[23:42] <lifeless> calling it add just breaks folks brains if they use svn/cvs/bzr/hg/monotone/tla/darcs
[23:42] <fullermd> Sure, but it's great for those p4 people!
[23:42] <lifeless> all three of them?
[23:43] <fullermd> It's a question of quality over quantity.  At least, it better be...
[23:52] <bjp> is there a way to specify a revision range after (but not including) a tag?
[23:53] <bjp> like -rtag:sometag..  without the tag
[23:53] <bjp> *without the tagged revision
[23:59] <delinquentme> fullermd, example of the "  If you want to commit only a subset, you list them in the commit command line. "
[23:59] <delinquentme> ?


[00:23] <racoon_> thanks holstein, ubot2, and stlsaint for your help. No luck today. Getting the firmware on a linux is tough. I'll try again next weekend.
[01:11] <txtzttm> hi all. can anyone help me out with issues mounting a hfs+ external HDD using 11.10?
[01:14] <deper29> txtzttm, try joining #ubuntu if you can't find a solution here
[01:14] <txtzttm> I'm getting "wrong fs type, bad option, bad superblock on /dev/sdb,..." when I try to mounting
[01:14] <txtzttm> No luck in #ubuntu so far..
[01:20] <txtzttm> anyone?
[01:54] <holstein> txtzttm: maybe the drive is bad.. i would test it, then maybe try repairing... if it has no data, just reformat it. if not, you can try photorec from the test disk suite
[01:59] <txtzttm> It works fine when accessed from my mac
[02:00] <txtzttm> I did try reformatting using both gparted and also my mac's drive utility, but same result
[04:03] <boxODER> join #ubuntu-beginners-team
[14:32] <boxODER> hi
[14:33] <boxODER> what is the difference between NAT adapter and bridged adapter
[14:33] <boxODER> i c this option in a oracle virtual box.
[14:54] <duanedesign> boxODER:helo
[14:55] <boxODER> hi
[15:11] <genupulas> cprofitt:  hi i got problem