[00:08] <nashant> Hi guys. Can anyone tell me where to find the python indicator api docs? Every link I go to gives me a 404
=== emma_ is now known as emma
=== lifeless_ is now known as lifeless
=== doko_ is now known as doko
[02:31] <cyphermox> smagoun: there will be a package in my PPA for you to test. I'd like to get your input on it before I upload to the archive, just in case what I'm reproducing isn't quite the same issue as you're seeing on your system.
[02:31] <cyphermox> I updated bug 1224040 with the explanation and the link
[02:31] <ubottu> bug 1224040 in network-manager (Ubuntu) "13.10: Multiple network manager authentication dialogs for saved network" [Medium,In progress] https://launchpad.net/bugs/1224040
[02:32] <cyphermox> the fix is for trusty, since you mentioned testing on it, but you should be able to safely install the package on saucy as well
[02:37] <GunnarHj> robert_ancell: ping?
[02:37] <robert_ancell> GunnarHj, hi
[02:38] <GunnarHj> robert_ancell: Hello
[02:38] <GunnarHj> robert_ancell: Does lightdm check gsettings to determine if the guest session feature shall be disabled? I'm asking because of this change I just proposed to the desktop guide description of guest session: http://bazaar.launchpad.net/~gunnarhj/ubuntu-docs/addremove/revision/325
[02:38] <robert_ancell> GunnarHj, lightdm only checks it's own config, not gsettings
[02:39] <GunnarHj> robert_ancell: Thanks, that's what I thought.
[02:39] <robert_ancell> GunnarHj, btw I just moved that file a few hours ago to /usr/share/lightdm/lightdm.conf.d/50-ubuntu.conf
[02:40] <robert_ancell> You should get the user to edit /etc/lightdm/lightdm.conf with custom settings - that will override the other settings
[02:40] <robert_ancell> or create a new file, e.g. /etc/lightdm/lightdm.conf.d/50-disable-guest.conf
[02:40] <robert_ancell> I'd prefer the latter
[02:40] <GunnarHj> robert_ancell: Ok... I thought you had deprecated lightdm.conf. Which would you recommend?
[02:41] <GunnarHj> robert_ancell: Saw your answer.
[02:41] <robert_ancell> LightDM loads files from /usr/share/lightdm/lightdm.conf.d first, then /etc/lightdm/lightdm.conf.d then /etc/lightdm/lightdm.conf
[02:41] <robert_ancell> /usr/share contains package configuration (not editable) and /etc sysadmin config
[02:42] <GunnarHj> robert_ancell: Is one line enough, or must [SeatDefaults] be there?
[02:42] <robert_ancell> must have a seat defaults
[02:42] <robert_ancell> all config is in a section
[02:43] <GunnarHj> robert_ancell: I see.
[02:43] <robert_ancell> GunnarHj, I'd like to split out the guest sessions into separate .desktop files, then it will just become "sudo apt-get remove unity-guest-session"
[02:43] <robert_ancell> It's on my list of nice-to-haves to implement for 14.04
[02:43] <robert_ancell> because this is such a common case and a pita to currently configure
[02:44] <robert_ancell> automatic logins is the next pita
[02:44] <GunnarHj> robert_ancell: Thanks for letting me know. (suppose you mean separate .deb files)
[02:44] <robert_ancell> GunnarHj, I'd love feedback on things that are hard to document - good cases for improving lightdm
[02:44] <robert_ancell> yes
[02:52] <GunnarHj> robert_ancell: Since you are there, and I'm still awake, are you waiting for Jonathan's review of https://code.launchpad.net/~gunnarhj/lightdm/guest-dialog-kubuntu/+merge/199490 ?
[02:53] <robert_ancell> GunnarHj, yes, does he know about it?
[02:53] <GunnarHj> robert_ancell: I have sent him a couple of emails too, but no response.
[02:53] <robert_ancell> I just don't want to land something and break kubuntu
[02:54] <robert_ancell> other than that I'm happy
[02:54] <GunnarHj> robert_ancell: Actually, I did test on Kubuntu, so the review request was more to be polite.
[02:54] <GunnarHj> robert_ancell: It wouldn't break anything.
[02:55] <robert_ancell> GunnarHj, I think we've given him sufficient time, are you happy to land without a formal review?
[02:55] <GunnarHj> robert_ancell: Yes.
[02:56] <GunnarHj> robert_ancell: But before merging you'd better take a look at the /media/guest-XXXXXX code I added.
[02:56] <robert_ancell> I did look, it seemed fine
[02:56] <GunnarHj> Ok, great!
[02:56] <robert_ancell> btw, you should really make multiple MPs for different fixes like that
[02:56] <robert_ancell> makes it easier to diagnose if problems later
[02:57] <GunnarHj> robert_ancell: Ok, noted.
=== jono is now known as Guest91841
=== RAOF_ is now known as RAOF
[03:08] <Fudge> thanks robert_ancell  for the lightdm unity-greeter back button work
[03:08] <robert_ancell> Fudge, np, thanks for finding it!
[03:09] <Fudge> my pleasure, very glad to find little bugs like that to increase the user experience :D
[03:19] <smagoun> cyphermox: that is great news about 1224040. I will test that out tomorrow when I'm back at the office with the misbehaving machine
[03:19] <cyphermox> sure
[03:20] <cyphermox> so far it seems to work here, but I only tested pretty quickly considering... it was only left unattended two hours
[03:20] <smagoun> cyphermox: I can usually reproduce 2-3 times/day, so we should know for sure this week
[03:20] <cyphermox> but it definitely should have popped up multiple dialogs during that time, and there was only one as the patch should be doing
[04:37] <Mirv> mitya57: did you get an confirmation from doko yet on whether hrw is right in that the aarch64 atomics patches can be dropped with Qt 5.2?
[04:38] <Mirv> mitya57: the latest news is what I wrote before Christmas - everything needs to build against the new Qt, and the dependency chain is currently stopped at gsettings-qt (while dbusmock was now fixed)
[04:49] <mitya57> Mirv: no, still waiting for doko's response on that
[05:23] <pitti> Good morning, happy new year everyone!
[05:34] <darkxst> doko, would you have any idea about Bug 1266605
[05:34] <ubottu> bug 1266605 in matplotlib (Ubuntu) "matplotlib crashes after recent tcl/tk update" [Undecided,New] https://launchpad.net/bugs/1266605
[05:34] <darkxst> it seemed to break the other day when tcl8.5-lib got removed
=== Zic is now known as Guest9648
[05:43] <pitti> infinity: so 12.04.4 is on Feb 6th; should I already do a langpack refresh now? it's been a while since precise got new langpacks (we forgot it for .3), so they can get some more testing time (just in case)
[05:43] <pitti> I just got a full export in LP
[05:44] <infinity> pitti: Sounds like a plan.
=== apachelogger_ is now known as apachelogger
=== OutOfControl is now known as benonsoftware
=== tjaalton_ is now known as tjaalton
=== Tm_K is now known as Tm_T
[06:28] <Fudge> is the context menu in the launcher called a lense?
=== ivoks_ is now known as ivoks
=== wgrant_ is now known as wgrant
[08:09] <dholbach> good morning
=== gnuoy` is now known as gnuoy
[08:27] <pitti> infinity: uploading, looking good (they'll land in unapproved)
[08:36] <pitti> infinity: can self-accept, if you don't mind; buildds are rather calm ATM
[08:41] <infinity> pitti: Go nuts.
[08:42] <tseliot> davmor2: I probably forgot to tell you that nvidia-persistenced is now part nvidia-331 in 14.04. So you can enable persistence mode from the configuration file
[08:42] <pitti> hey tseliot, happy new year!
[08:42] <tseliot> pitti: happy new year to you :)
[08:43] <pitti> tseliot: wrt. bug 1126234, ISTR that there was some work going on to support intel+nvidia at the same time
[08:43] <ubottu> bug 1126234 in ubuntu-drivers-common (Ubuntu) "Does not show nvidia driver if intel card is active" [High,Triaged] https://launchpad.net/bugs/1126234
[08:43] <pitti> tseliot: do we need to change that special case in ubuntu-drivers to hide the nivida driver if intel is active?
[08:43] <pitti> tseliot: or does hybrid graphics still only work with the free drivers?
[08:45] <tseliot> pitti: we can enable the nvidia drivers on some systems (not desktops) with new nvidia drivers and intel. The same can be done with amd
[08:45] <smb> Looking at bug 1244176 I am wondering... I know respinning Saucy images is really really unlikely. Not sure about the netboot mini isos. Alternatively is there a simple replace kernel in iso howto we could point to?
[08:45] <ubottu> bug 1244176 in linux (Ubuntu Trusty) "Server 13.10 Install Fails with USB Keyboard (Appears to Hang)" [High,Fix released] https://launchpad.net/bugs/1244176
[08:45] <pitti> tseliot: ah, so in general that behaviour is still adequate?
=== dholbach_ is now known as dholbach
[08:47] <tseliot> pitti: yes, kind of. I need to make sure that we do that only when we really need it, and otherwise enable nvidia. Feel free to assign that bug report to me
[08:47] <pitti> tseliot: thanks for the heads-up; so it's still mostly correct
[08:48] <pitti> tseliot: well, I set the bug to triaged, but I don't see that we can do much about it until the nvidia driver changes fundamentally?
[08:49] <tseliot> pitti: yes, but, in most cases, if you install the nvidia driver manually, it just works (whether you have hybrid graphics or not), as I added some logics in the nvidia-prime package
[08:50] <pitti> tseliot: right, but I guess that disables the intel card then, right?
[08:51] <tseliot> pitti: not really, it keeps using the intel card (using the modesetting driver) to drive the monitors and offloads rendering to nvidia. So it uses both GPUs
[08:52] <tseliot> pitti: then, thanks to my work, you can also choose to switch off the nvidia GPU from the nvidia-settings panel
[08:52] <tseliot> (to save power)
[08:52] <pitti> oh, amazing!
[08:52] <tseliot> :)
[08:52] <pitti> tseliot: that actually sounds like we should drop that explicit hiding?
[08:52] <pitti> or at least refine it to only apply to older driver versions which don't support that yet?
[08:52] <tseliot> pitti: yes, I'd like to implement the same logic from the nvidia-prime package
[08:53] <tseliot> it will be mostly a matter of clever copying and pasting ;)
[08:55] <pitti> tseliot: great; I assigned the bug to you then, but I'm happy to help with the implementation if you tell me what needs to be checked
[08:57] <tseliot> pitti: this is something I also need to refine in Jockey for 12.04.4, so I was planning to work on both implementations. I'll let you know if I have any doubts or if I need help. Also, I'll show you the final commit when it's ready.
[08:57] <pitti> tseliot: thanks
=== psivaa_ is now known as psivaa
=== lan3y is now known as Laney
=== Laney is now known as Guest1882
=== Guest1882 is now known as Laney
=== sgnb` is now known as sgnb
=== ochosi_ is now known as ochosi
=== masACC is now known as maswan
=== tkamppeter_ is now known as tkamppeter
=== j_f-f_ is now known as j_f-f
=== greyback_ is now known as greyback
[10:15] <doko> mlankhorst, mesa question. by simply including GL/GLwMDrawA.h, how is GLAPI supposed to become defined?
[10:28] <mlankhorst> doko: erm no idea :)
[10:29] <doko> ... says the mesa packager ;p
[10:30] <mlankhorst> glapi is internal, why?
[10:36] <doko> mlankhorst, hacked around it: http://launchpadlibrarian.net/161786200/arb_5.5-5_5.5-5ubuntu1.diff.gz
=== Guest9648 is now known as Zic
[10:47] <mlankhorst> doko: that's even more terrible than the ld -static -fPIE -pie hack I had to do..
[10:49] <mlankhorst> bug #1266492
[10:49] <ubottu> bug 1266492 in binutils (Ubuntu) "ld:i386 crashes with -static -fPIE -pie" [High,Confirmed] https://launchpad.net/bugs/1266492
[10:55] <pitti> roaksoax: hey Andres, happy new year!
[10:55] <pitti> roaksoax: do you have some time estimate for bug 1254053?
[10:55] <ubottu> bug 1254053 in MAAS "Installing MAAS on trusty gives a big warning about deprecated postgresql 9.1" [High,Triaged] https://launchpad.net/bugs/1254053
[11:03] <infinity> pitti: Hey, speaking of postgres and osolescence, can you prod upstream about that oom_adj thing that stalled?  I read through the mailing list debate on how to fix it a few years ago, and then people just stopped talking about it.
[11:03] <infinity> pitti: Seems a bit silly for it to *still* be tripping that ringbuffer spam after all these years.
[11:03] <pitti> infinity: indeed; will do
[11:04] <pitti> infinity: debian bug 646245, I'll fix that in Debian and send the patch upstreamwards
[11:04] <ubottu> Debian bug 646245 in postgresql-9.3 "postgresql-9.1: Writes obsolete /proc/pid/oom_adj instead of /proc/pid/oom_score_adj" [Minor,Open] http://bugs.debian.org/646245
[11:06] <infinity> pitti: Oh, you had a patch you liked for it?
[11:07] <infinity> pitti: Upstream's longwinded mailing list thread on the topic seemed to cover a lot of ground. :P
[11:07] <pitti> infinity: not yet; that's the "will" part
[11:07] <pitti> infinity: ah, I need to read that then
[11:07] <pitti> it seems rather simple, if oom_score_adj exists, that should be used, otherwise fall back to oom_adjj
[11:08] <infinity> pitti: Linked from https://bugs.launchpad.net/ubuntu/+source/postgresql-9.1/+bug/991725
[11:08] <ubottu> Ubuntu bug 991725 in postgresql-9.1 (Ubuntu) "postgres is using deprecated /proc/PID/oom_adj" [Low,Triaged]
[11:08] <infinity> http://www.postgresql.org/message-id/29121.1316185073@sss.pgh.pa.us
[11:08] <infinity> pitti: It's pointed out that the two files mean different things.  But if you're always setting to 0, that means the same tihng for both.
[11:10] <pitti> infinity: right, in postgresql-common I use -900 for oom_score_adj and -16 for oom_adj
[11:11] <infinity> http://www.postgresql.org/message-id/CAEik5nPuNBHZgOGX3-baU=WKD353Hrw5qnWrw8dr6iViQ6553A@mail.gmail.com has a patch (and a fix) to just dupe the Linux adjust calculations, so you can have just the one value in postgres.
[11:11] <infinity> But that, as rightfully pointed out, is duplicating kernel code that could change.
[11:11] <infinity> Then again, if it changed, your values are wrong regardless, and I suspect it *won't* change.
[11:14] <infinity> pitti: I think I personally like that patch, and find the "duplicating kernel interfaces" argument to be silly, given that it's one simple arithmetic transformation from one range to another range that is almost certainly not going to change without a third interface being added to the kernel.
[11:14] <infinity> pitti: As pointed out in the thread before it died, this might just be a "he who does the work wins" thing, so maybe just committing that would end the suffering. :P
[11:14] <pitti> infinity: right, just stumbled over that; for a Debian-only patch it can even become simpler, as we know we don't change the value in our package
=== cjwatson_ is now known as cjwatson
[11:15] <pitti> but the scale change seems simple enough, it's not going to change
=== _salem is now known as salem_
=== rbasak_ is now known as rbasak
[13:02] <mlankhorst> hm, am I going to need a MIR for libxshmfence and x11proto-dri3?
[13:19] <pitti> hallyn: hey Serge, how are you? happy new year!
[13:20] <pitti> hallyn: latest qemu dropped pci_add; do you know how to translate "pci_add auto storage file=$PATH,if=virtio,index=2,readonly" to current qemu?
[13:20] <pitti> hallyn: there is just about zero documentation for device_add, and the ",help" output doesn't help much either :(
[13:21] <pitti> hallyn: i. e. I want to do the equivalent of "-drive file=..." at hotplug time (through the monitor)
=== barry` is now known as barry_
=== barry_ is now known as barry
[13:24] <davmor2> tseliot: how do I enable persistence in the conf?
=== Trewas666 is now known as trewas
=== trijntje__ is now known as trijntje
[13:31] <trijntje> ping cjwatson: can I draw your attention to bug 1265297
[13:32] <ubottu> bug 1265297 in syslinux-themes-ubuntu (Ubuntu) "Please release package for trusty" [Undecided,New] https://launchpad.net/bugs/1265297
[13:32] <cjwatson> trijntje: sure
[13:33] <trijntje> cool, I was hoping to create localised Dutch iso's  for trusty using ubuntu-defaults-builder, but the build process requires syslinux-themes-ubuntu-trusty
[13:40] <cjwatson> trijntje: uploaded, but the build will need manual processing by an archive admin since it introduces a new package.  shouldn't take too long and the bug will be closed once it happens
[13:42] <trijntje> cjwatson: awesome, thanks a lot!
[13:51] <tseliot> davmor2: in /etc/init/nvidia-persistenced.conf you should simply replace "/usr/bin/nvidia-persistenced --user nvidia-persistenced" with "/usr/bin/nvidia-persistenced --user nvidia-persistenced --persistence-mode"
[13:53] <roaksoax> pitti: Hi Martin... i tought i had fixed that already. i'll double check and close the bug! thabk you for noticing!
[13:54] <pitti> roaksoax: oh, indeed; it was still there in December; thanks!
[13:55] <pitti> roaksoax: indeed http://launchpadlibrarian.net/160048328/maas_1.4%2Bbzr1693%2Bdfsg-0ubuntu3_1.4%2Bbzr1789%2Bdfsg-0ubuntu1.diff.gz drops the postgresql-9.1 dep
[13:56] <pitti> roaksoax: bug updated, thanks!
[13:57] <roaksoax> pitti: sorry about that then (not closing the bug report). thanks though!
[14:01] <davmor2> tseliot: will do
[14:06] <knocte> Cimi: ping
=== ricmm|sick is now known as ricmm
=== bregma_ is now known as bregma
[14:26] <hallyn> pitti: hey.  My patch to qrt to deal with that change is http://people.canonical.com/~serge/qrt-qemu.diff.  So it would look like:
[14:27] <hallyn> drive_add 0 file=$PATH,if=none,id=disk1
[14:27] <hallyn> device_add virtio-scsi-pci,id=disk1
[14:27] <hallyn> pitti: I really wish pci_add would stay around
[14:29] <pitti> hallyn: ah, jibel tried something like that in http://paste.ubuntu.com/6709139/ but said that it would fail for virtio with an error, it just works for a scsi disk
[14:29] <pitti> hallyn: thanks for the pointer!
[14:31] <Cimi> knocte, pong
[14:32] <knocte> Cimi: hello, happy new year!, can you review/merge https://code.launchpad.net/~knocte/ubuntu-themes/bring-back-zebra-striping/+merge/200429 when you got a chance?
[14:36] <Cimi> knocte, happy new year, thanks!
[14:36] <Cimi> done
[14:36] <knocte> merci!
[14:39] <hallyn> pitti: np - happy new year to you too :)
[14:45] <pitti> jamespage: FYI, I uploaded http://launchpadlibrarian.net/161802756/waitress_0.8.8-1ubuntu2_0.8.8-1ubuntu3.diff.gz to complete dropping the autopkgtest (your upload is stuck in -proposed due to that)
[14:46] <jamespage> pitti, indeed it did - I move the autopkg tests into the actual package build
[14:47] <jamespage> they did not really need to be DEP-8 tests IMHO
[14:47] <jamespage> pitti, so it was just the missed header holding it up?
[14:47] <pitti> jamespage: yes, when trying to run adt-run on a package without tests you get errors
[14:47] <pitti> jamespage: https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-waitress/14/ARCH=i386,label=adt/console
[14:47] <jamespage> pitti, well that makes sense :- )
[14:47] <jamespage> pitti, I'd spotted the error - but missed what was causing the problem
[14:50] <pitti> jamespage: FTR, running upstream tests against the build tree is certainly wrong in autopkgtest; but having some smoke-test in autopkgtest against the installed binaries is valuable to ensure newer dependencies don't break your package
[14:50] <pitti> jamespage: and also to ensure that your packaging didn't break and forget a library, dependency, some other file, etc.
[14:50] <jamespage> pitti, agreed - have alot of packages that do that already
[14:50] <pitti> jamespage: I'll let that build/publish and remove the jenkins job, so it should promote later today
[14:51]  * pitti bbl
[14:51] <jamespage> pitti, thanks
=== rickspencer3__ is now known as rickspencer3
[15:23] <robotfuel> Mirv: ping
=== zyga_ is now known as zyga
[16:09] <barry> doko, xnox python-apt rebuild for 3.4 is stuck in proposed due to autopkgtest failures.  looks shallow (missing test dependency probably) and i can fix it if you guys aren't already working on it.  don't want to step on your toes here: https://jenkins.qa.ubuntu.com/view/Releases/view/Trusty/job/trusty-adt-python-apt/30/ARCH=amd64,label=adt/console
[16:10] <pitti> /tmp/adt-run.dSXkJy/dsc0-build/python-apt-0.9.1build2/debian/tests/run-tests: 7: /tmp/adt-run.dSXkJy/dsc0-build/python-apt-0.9.1build2/debian/tests/run-tests: python3.4: not found
[16:10] <xnox> barry: i thought i fixed that...
[16:10] <pitti> needs to test-dep on python-all?
[16:10] <barry> and python3-all
[16:11] <xnox> pitti: oh python3-all, yeah that is probably indeed the piece that i missed.
[16:11] <pitti> if it runs its tests against all python versions, instead of just the default one, that si
[16:11] <pitti> s/si/is/
[16:11] <barry> xnox, pitti yep.  i'll fix
[16:11]  * barry will test it locally first :)
[16:11] <pitti> FTR, I'm looking at apport's failures
[16:12]  * xnox only did the local test, in an unclean environment.....
[16:12] <xnox> pitti: oh, yeah. thanks a lot.
[16:12] <barry> pitti: dholbach's build failure pointed me here
[16:12] <pitti> the 3.4 change causes a lot of python* packages to break (which is reflected in their autopkgtest failures)
[16:12]  * ogra_ hands xnox a mop and a bottle of mr.clean
[16:12] <pitti> so we have some work cut out :)
=== dames is now known as thedac
[16:13] <xnox> ogra_: if only scrubbing dishes, would solve all autopackage test failures..... =)
[16:13] <ogra_> :)
[16:15] <pitti> ah, that might explain the FileNotFoundError: [Errno 2] No such file or directory: 'crash-digger'
[16:15] <pitti> i. e. it probably wants to tell me "python 3.4 not found" or so
[16:16] <barry> pitti: sometimes these are caused by failing imports in tests, ultimately caused because a library wasn't built for 3.4 and thus can't be imported.  this was dholbach's problem
[16:16] <pitti> hm, is that only me? I suddenly get Debian bug email like 10 times, a new copy every few hours
[16:18] <cjwatson> somebody decided to bounce old stuff
[16:18] <cjwatson> look for mcafee.int in the headers?
[16:18] <cjwatson> I assume it's some crazy misconfigured gateway
[16:18] <pitti> To: 725951@mcafee.int, [...]
[16:18] <pitti> ah
[16:18] <pitti> I got a lot from systemd bug reports, as well as from entirely unrelated stuff like debian bug 711831
[16:18] <ubottu> Debian bug 711831 in wnpp "RFA: libgphoto2 -- gphoto2 digital camera library" [Normal,Open] http://bugs.debian.org/711831
[16:18] <pitti> cjwatson: thanks
[16:22] <pitti> barry: ah, I know; I iterate over for python in $(shell py3versions -r); for building/installing
[16:22] <pitti> barry: so 3.4 gets last, which changes the hashbangs into the non-default version
[16:22] <pitti> (just in case this hits some other packages, too)
[16:22] <xnox> tedg: re:app-launching i'm monkey patching autopilot to bump timeouts from 10s to 30s, because underclocked CPUs make emulator's llvmpipe/GL run really slow =) as, e.g. the case of the openstack cloud instances ;-)
[16:22] <pitti> barry: the hashbangs shouldn't be /usr/bin/python3.4, but just /usr/bin/python3, right?
[16:23] <barry> pitti: this is essentially what pyapt runs: (/usr/bin/pyversions "$@"; /usr/bin/py3versions "$@"; ) | tr '\n' ' '
[16:23] <barry> pitti: right.  but then pyapt runs this: +for python in $(utils/pyversions -r); do
[16:23] <barry>      $python tests/test_all.py -q
[16:23] <barry>  done
[16:23] <barry>  
[16:24] <pitti> barry: that's the autopkgtest?
[16:24] <barry> so it does run tests/test_all.py over all supported pythons (explicitly, ignoring shebangs)
[16:24] <barry> pitti: essentially yep
[16:24] <pitti> barry: ack, then test-depending on python3-all sounds like it'd do the trick
[16:24] <pitti> (and would be correct)
[16:24] <barry> pitti: yep.  but i'm also going to add an explicit python-all for py2
[16:24] <tedg> xnox, Oh, wow.  The cloud, the future is slow.  :-)
[16:24] <barry> pitti, xnox, doko and i'm going to label this 0.9.1ubuntu1 and send a patch to debian
[16:25] <dholbach> barry, that's for python-apt?
[16:26] <barry> that is, if my autopkgtest vm ever starts :/
[16:26] <xnox> tedg: =)))) well, emulator is single-threaded/sigle-core, and without a GPU it does depend  on a single core clock-speed... one can have 30x core cloud instance but that won't help =)))))
[16:26] <barry> dholbach: yep
[16:26] <dholbach> mvo, barry has a patch for python-apt for you ^ :)
[16:26] <pitti> barry: hm, my setup.py already sets hashbangs like "python3" -- could it be that dh_python3 is overzealous and changes them to python3.4?
[16:26] <xnox> tedg: yeah future does seem to be slow, slow cloud IO, slow cpu-core clock-speed...
[16:27] <barry> mvo!  http://paste.ubuntu.com/6709877/  (not yet tested)
[16:27] <xnox> tedg: 3 minutes for first boot to run click hooks.....
[16:28] <pitti> for python in $(utils/pyversions -r); do
[16:28] <pitti> xnox, mvo: ^ why utils/? shouldn't this use the official pyversions and py3versions?
[16:28] <barry> pitti: it could be.  there are still some outstanding issues with py3.4 and the build tools, but i haven't had time since break to fully catch up on them
[16:28] <pitti> i. e. for python in `pyversions -s` `py3versions -s`; ?
[16:28] <xnox> pitti: i'm not involved in that =)
[16:29] <barry> pitti: here's utils/pyversions: http://paste.ubuntu.com/6709884/
[16:29] <barry> so, yeah, i'm not sure why the maintainers are doing it that way ;)
[16:29] <pitti> barry: ah, heh; the tr seems unnecessary, but it does use the official py[3]versions then, thanks
[16:40] <barry> pitti, xnox, dholbach hmm, my local run-adt-test seems quite unhappy today (it just hangs).  if the pastebin i provided above looks good to you, i can just go ahead and upload it.  can't be any worse than the current situation ;)
[16:40] <pitti> barry: hang on, that's due to a removed feature in qemu
[16:41] <pitti> barry: please apply http://paste.ubuntu.com/6709951/ to your bin/run-adt-test
[16:41] <pitti> barry: (i. e. comment out the "Making pristine VM available" stanza)
[16:41] <pitti> barry: I need to find out how to replace that functionality with device_add; hallyn gave me some hints, but I didn't get to test them yet
[16:41] <barry> pitti: cool, will do.  will you be applying that to the trunk branch soon?
[16:41]  * barry nods
[16:41] <pitti> barry: well, I hope I can actually fix it
[16:41] <barry> pitti: ;)  cool, thanks!  testing...
[16:41] <pitti> barry: unfortunately qemu removed pci_add without any documented replacement :(
[16:42] <barry> lovely
[16:42] <pitti> sorry for the trouble
[16:43] <barry> pitti: happy again!  thanks
[16:45] <pitti> jamespage: ok, waitress is in
[16:46] <jamespage> pitti, excellent - thanks
=== micahg_ is now known as micahg
[17:10] <mvo> barry: ohh, thanks! if it works I can upload in a bit - you mentioned you are testing it?
=== and`_ is now known as and`
[17:11] <xnox> pitti: there is documented replacement on the mailing list, i think it had the patch to remove pci_add as well.
[17:11] <barry> mvo: hi!  yep, works locally, just uploaded to ubuntu.  see debian bug 734500 -- i can syncpackage it if you upload the fix to debian (but might want to wait to see if it clears jenkins first)
[17:11] <ubottu> Debian bug 734500 in python-apt "python-apt: DEP-8 debian/tests/control dependencies missing" [Normal,Open] http://bugs.debian.org/734500
[17:12] <xnox> hallyn: what was the "proper" way of doing pci_add ? device_add ? pitti  is asking about it.
[17:12] <mvo> barry: sounds good, thanks! I will merge, there is more good stuff happening in python-apt currently test-wise, so +1 for this one
[17:14] <pitti> xnox: hallyn responded some 2.5 hours ago here
[17:15] <xnox> pitti: oh, i see.
[17:16] <mvo> barry: merged
[17:16] <mvo> ta
=== davmor2_ is now known as davmor2
=== balloons_ is now known as balloons
[17:38] <barry> mvo: thanks!
=== bfiller is now known as bfiller_afk
[17:40] <mvo> barry: well, thank *you* :)
=== stgraber_ is now known as stgraber
=== Snow-Man_ is now known as Snow-Man
=== superm1_ is now known as superm1
=== Claudinux is now known as Guest33318
[17:52] <pitti> Jenkins Fixed - trusty-adt-python-apt 31
[17:53] <pitti> barry, xnox, mvo: ^ joy!
[17:53] <pitti> I just uploaded a fixed apport, too
=== balloons is now known as Guest99854
=== LoganCloud_ is now known as LoganCloud
=== seiflotfy__ is now known as seiflotfy_
=== LoganCloud is now known as Guest4645
[17:55] <pitti> jibel: ah, the recent python-apt upload is another example of disappearing tests in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html, in case it's useful
[17:55] <pitti> only the two FAILed ones remained, but it's actually triggering some 10
[18:12] <pitti> it's doing that again right now
[18:15] <mapreri> Hi. licenseutils fail to build in the ubuntu buildd (and PPAs), but build simple fine in pbuilder, sbuild or a local system. Even in debian (the package is synced) build fine.
[18:15] <mapreri> https://launchpad.net/ubuntu/+source/licenseutils/0.0.7-2      https://buildd.debian.org/status/package.php?p=licenseutils
[18:16] <mapreri> Have some of you an idea of what happened in these ftbfs??
[18:18] <mapreri> s/an/any/
=== balloons_ is now known as balloons
[18:36] <cjwatson> mapreri: Perhaps it would be a good idea to arrange to cat the test-suite.log files on failure?
[18:37] <xnox> mapreri: cjwatson: If the variable ‘VERBOSE’ is set, test-suite.log file is output after the summary upon failure.
[18:37]  * xnox guesses I should propose that change to debhelper.
[18:41] <mapreri> cjwatson: good idea, I'll try it. I had not thought this.... perhaps also catting the diff could be helpful. Thanks
[18:41] <cjwatson> mapreri: My first guess was that you were tripping over not having a valid $HOME, but your package seems to handle that.  It's probably quickest to just set VERBOSE=1, reupload, and see what the next build gives you
[18:42] <mapreri> cjwatson: I'll try too, I'm going to upload to a ppa, since it file also there
[18:42] <cjwatson> Lack of external networking is another standard reason but that presumably doesn't apply here
[18:42] <mapreri> yes, the $HOME is set by the script
[18:43] <mapreri> there is no network activity while building that package
[18:43] <cjwatson> And it doesn't look as though it'd care much about not having a UTF-8 locale
[18:44] <cjwatson> So you presumably have an interesting problem :-)
[18:50] <mapreri> cjwatson: this package already rose a lot of problem, look at http://bugs.debian.org/733314 (https://buildd.debian.org/status/logs.php?pkg=licenseutils&ver=0.0.7-1&suite=sid) for the worst, for example... :)
[18:50] <ubottu> Debian bug 733314 in licenseutils "licenseutils: Please fix symbols file for powerpcspe (and other arches)" [Wishlist,Fixed]
[18:51] <cjwatson> Symbols files have nothing to do with this problem though
[18:53] <mapreri> cjwatson: yes, they are totally unrelated, but this is a reply "So you presumably have an interesting problem", since this package already gave me interesting issues
[18:53] <dobey> mapreri: the failing test suite isn't obvious enough?
[18:54] <cjwatson> Hm.  umockdev fails on ppc64el in a way that looks rather like its scary ioctl wrapping kludge is corrupting the stack
[18:56] <mapreri> dobey: I (and others already tried to) can't understand why that test fail, only in ubuntu buildd, that's the issue
[18:57] <dobey> well, i don't know that code, but my guess would be network or something common, as already suggested. you'll have to debug
[19:15] <cjwatson> pitti: You probably want to pull umockdev 0.4.7-1ubuntu2.  Let me know if you need it forwarded more formally.
[19:20] <cjwatson> pitti: It's possible that the preloaded wrapper ideally ought to be declared with varargs as well, though as you note in the comment you can't make it work with full generality
[19:20] <cjwatson> But you could at least pull one arg with va_arg
=== ssweeny` is now known as ssweeny
=== salem_ is now known as _salem
=== bfiller_afk is now known as bfiller
[20:58] <doko> directhex, Laney: what's the merge status of mono?
[20:59] <directhex> i'd... like a newer upstream release when 14.04 ships. but i think the current debian experimental package is worth having over what's currently in the archive
[21:00] <directhex> i've been bugging upstream for about 2 months for a newer stable release
[21:01] <directhex> i'm reasonably sure the merge can be replaced with a sync. Laney?
[21:03] <xnox> directhex: if it builds in trusty, it should fine. I'd recommend you to create a ppa, sync from experimental into ppa & copy all reverse-dependencies to check how bad the fallout is.
[21:03] <xnox> directhex: is it compatiblish or an ABI/API transition?
[21:03] <directhex> that's not a bad idea
[21:05] <directhex> xnox, there's a technical ABI transition (shouldn't really matter, apps are executed against the new ABI even if the dependencies imply it was built against the old one - just a minor space concern which is irrelevant now we're not on the CD)
[21:10] <directhex> oh, the default GC has changed in this release. a few apps might break, but we should have time to catch & patch (or worst case, make the app force the old GC)
[21:11] <directhex> xnox, this release adds armhf by the way
[21:11] <xnox> directhex: i don't want a pile of packages be stuck in -proposed, or indroduce a gazzilion FTBFS. =) do you want me to quickly run rebuild tests against mono from experimental?
[21:11] <xnox> directhex: which packages do i need to take?
[21:14] <directhex> oh, there's the dbus#2 stuff too to worry about. grr. do we have an easy way to track this stuff?
[21:15] <directhex> xnox, basically there'd be value in testing all packages which the mono maintainers have delegated upload rights for against mono in debian experimental, which i just sent to a PPA
[21:16] <directhex> there'd also be value in me remembering which url is a handy reference for "version in debian" against "version in ubuntu"
[21:16] <xnox> directhex: so the way i do things is compare versions with: rmadison -u ubuntu -S package; vs rmadison -u debian -S package
[21:17] <xnox> directhex: (source package names gives results for all arches & binary packages)
[21:17] <xnox> directhex: and in ubuntu-archive-tools there is script copy-package which let's me copy source packages (without binaries) from any distributions/suits into my ppa. So i typically copy or upload "base things", e.g. mono in this case.
[21:18] <xnox> directhex: wait for it build & publish, then mass copy-package of all $ reverse-depend --list -b src:mono
[21:18] <directhex> huh, never heard of copy-package. sounds sorta pointless vs. syncpackage
[21:18] <directhex> xnox, can you manipulate build score?
[21:18] <xnox> directhex: (baring PPA size limits / number of packages, so at times not _all_ but a useful set of packages)
[21:19] <xnox> directhex: and then watch how much of it builds in a PPA.
[21:19] <xnox> directhex: copy-package and syncpackage are two different things =)))))
[21:19] <xnox> directhex: syncpackage is for: debian -> ubuntu-archive.
[21:20] <xnox> directhex: copy-package can be: ppa -> ubuntu, ubuntu -> ppa, debian -> ppa, or whatever you want, just source (to trigger rebuilds) or with binaries (to simply republish, e.g. to different series)
[21:21] <directhex> yeah, i just mean syncpackage could be "exec copy-package --foo --bar" by the sound of it. never mind, getting off topic
[21:21] <directhex> when my ppa build of mono finishes (hopefully before i go to bed) i can throw a bunch of packages at it
[21:22] <xnox> directhex: well, syncpackage uses the same api on the back of things, copy-package just exposes more of the raw api. syncpackage has convenient wrappers to close bugs, force-override ubuntu delta, sponsor-for somebody else, sanity-checking, etc.
[21:22] <directhex> although i've been waiting about a month for a build on debian armhf/experimental...
[21:23] <directhex> which is insanity. a month! how am i supposed to get a reasonable iteration on fixes going if builds take a month?
[21:23] <xnox> directhex: i can build some things on fast arm box, but not like all of mono reverse depends.
[21:23] <directhex> xnox, i'm told the mono experimental package is Fine(tm), it's been pushed out on raspbian to replace earlier monos in all versions
[21:24] <directhex> but mono's been broken in armhf for years. long story.
[21:27] <Laney> directhex: I don't really remember what the ubuntu changes are
[21:28] <Laney> oh that armv6 thing - I guess that's already fixed upstream
[21:28] <directhex> yeah, the arm fixes katamari which fixed armhf
[21:31] <directhex> hmph, ben ignoring --archs flag
[21:42] <smaresca> ddebs.ubuntu.com  - is there a recommended/supported means of mirroring the repository --- rsync or apt-mirror or similar?
[21:44] <xnox> smaresca: i use apt-cacher-ng to ondemand mirror things for me...
[21:45] <mdeslaur> +1 apt-cacher-ng
[21:45] <smaresca> xnox, i do too typically for normal things like local PXE installes, etc
[21:46] <smaresca> here, I have a bit of an unusual case: I have some research requiring debug symbols, and I'd like to crunch *all* available packages not just lazy-caching them as needed
[21:52] <xnox> smaresca: well, apt-cacher-ng has options to mirror things ahead of time, one just needs to configure which repositories / suits / arches / etc.
=== Ursinha is now known as Guest50378
=== Ursinha-afk is now known as Ursinha
[22:25] <directhex> gah, builds pushed back by an hour
[22:25] <directhex> unlikely to get anything done today, in that case
[22:27] <xnox> directhex: lp estimates are a bit dubious. leave it over night.
[22:28] <xnox> directhex: (41 builders are actually across both i386/amd64 of all jobs together these days, and some of the jobs are recipes that generate new build-records)
[22:29] <directhex> xnox, i was hoping src:mono would build before bed so i could push a bunch of packages to build up there ovbernight
[22:30] <stgraber> directhex: link to the build?
[22:31] <directhex> um... https://launchpad.net/~directhex/+archive/mono-rebuild/+build/5421967 and https://launchpad.net/~directhex/+archive/mono-rebuild/+build/5421968
[22:31] <directhex> i guess i386 is the important one, since it's always the preferred arch for arch:all packages
[22:31] <stgraber> looks like they're building
[22:32] <directhex> ... huh. i swear it just said 1 hour!
[22:34] <RAOF> A non-ancient Mono in Trusty? Yay!
[22:34] <RAOF> directhex: FWIW, I've been running a locally-built copy of mono from experimental in Trusty for some time; nothing I use has broken.
[22:35] <directhex>  *** 3.0.6+dfsg-1~exp1~pre1 0
[22:35] <directhex>         100 /var/lib/dpkg/status
[22:35] <directhex> :D
[22:37] <doko> directhex, worth a testbuild on the other archs too?
[22:40] <RAOF> 3.0.6? Not 3.2.7?
[22:40] <directhex> 3.2.7 is another PCL-only update
[22:40] <directhex> doko, i don't think it'd tell me anything new. i mean, an armhf build would be great, but i'm reasonably sure that works, given the raspberry pi case
[22:40] <directhex> unless you have decent mipsel builders :p
[22:44] <Snow-Man> so, uhm, what's the deal w/ CVE-2013-4353 … ?
[22:44] <ubottu> ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4353)
[22:44] <Snow-Man> it's published, you dingle-bat bot
[22:45] <Snow-Man> or rather, there's a fixed for it release by Debian, heh.
[22:46] <jdstrand> Snow-Man: it's being tracked. we should have an update soon
[22:46] <Snow-Man> k, thanks.
[22:54] <knocte> directhex: I guess you meant 3.2.6, as 3.2.7 hasn't been tagged yet
[22:55] <directhex> there's a 3.2.7 in xamarin's QA pipeline. it might be a mac-only installer update, which wouldn't get a corresponding git tag
[22:55] <directhex> either way, urgh]
=== manjo` is now known as manjo
[23:02] <mterry_> pitti, do you know much about getting debug output from systemd?  I'm trying to look into why the phone's logind doesn't apply acl's to sound devices when a user logs in
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
[23:39] <directhex> ok i've managed to get ben working, and got a few rebuilds going
[23:39] <directhex> if these are fine, i'm inclined to just throw it at the archive. will see tomorrow
=== _salem is now known as salem_
=== salem_ is now known as _salem