=== salem_ is now known as _salem === timrc-afk is now known as timrc [00:28] pitti: did you still need an owncloud-client ignore? [00:38] pitti: seems so - hint added now === freeflying is now known as freeflying_away === freeflying_away is now known as freeflying === echevemaster_afk is now known as echevemaster [02:24] Has it ever been considered to make aptitude use bitorrent? === freeflying is now known as freeflying_away [02:31] lolcat: https://wiki.debian.org/DebTorrent [02:41] cool [02:44] tarpman: So it isn't feasible? [02:45] I would love for it to use bittorrent on the local network in addittion to a web seed. SO if bandwidth is thight it gets it from local computers [03:00] lolcat: In the meantime, running an apt-proxy is pretty simple. [03:00] lolcat: See squid-deb-proxy-client + squid-deb-proxy/apt-cacher-ng etc. [03:01] Hard to install on freeBSD [03:01] Why would you install it on freeBSD? [03:01] (And I'd be amazed if squid was hard to install on FreeBSD!) [03:02] Because I have three computers with ubuntu [03:02] They are not on at the same time always [03:02] How would I set it up so they know which has the package? [03:02] lolcat: pkg_add squid; done - no ? [03:03] There's apt-zeroconf for that, if you don't have a machine that'd be mostly-on. [03:03] lolcat: squid-deb-proxy uses zeroconf [03:03] Welcome, squid-highlighting friends! [03:03] :) [03:03] ah [03:04] I guess Ill just upgrade to 100mbps and forget about it [03:04] *blink* [03:05] Oh, apt-zeroconf is dead-dead. That's a bit of a shame; the other caching solutions don't quite cover the distributed-cache usecase. === baba is now known as fire_ [03:07] lifeless: There's no trivial configuration to turns squid into a distributed cache solution, right? (ie: multiple squid caches on the network, dispatch to appropriate cache if cache has file, otherwise download locally and cache) [03:10] (I've probably asked that before) [03:11] RAOF: cache_peer and list all the peers [03:11] RAOF: IIRC digests (bloom filter API) are on by default, so you'll get that behaviour [03:11] should be easy enough to wire a config generator into zeroconf and do that [03:11] Hm, yeah. Interesting. [03:12] of course, trust is an issue, as you're basically saying 'hey, use me for transit!' [03:12] Well, there's apt's signing mechanism on top. [03:12] for the special case of safe-over-http content, sure [03:13] So you shouldn't be able to silently break stuff. [03:13] just saying :) [03:13] you could silently withhold security updates [03:13] Don't we https:// them yet? [03:13] No, we don't. Sadface (: [03:14] and also they don't exist for the open release [03:14] True. [03:14] We could always turn off proxying for Packages.gz [03:17] Actually, I suspect the default config works for that; setting all 0s for refresh_pattern on Packages should do that? [03:18] no [03:18] that affects heuristics [03:18] explicit timing data from servers takes precedence [03:18] unless you actually explicitly override which IIRC requires a compile time option to enable RFC violations [03:19] I'm not really worried about someone withholding updates [03:19] There's presumably a squid key to disable caching and always got to the server? [03:19] it was just an observation [03:19] yes [03:21] Well, if I were to, say, update the default squid-deb-proxy configuration to handle this I'd want to make sure it's approximately as secure :) [03:21] its not secure now [03:21] in this sense [03:21] because I can plug an unprivileged machine in and advertise [03:21] so - no new hole [03:22] the difference is that you want to share the cache === mwhudson is now known as zz_mwhudson === freeflying_away is now known as freeflying [05:55] Good morning [05:55] slangasek: yes, doko_ asked for it; thanks [05:57] pitti, The g-s-t merge should be ready for you to look at [05:58] (finally) [05:58] Noskcaj: yes, thanks muchly! I have it in a tab to review this morning [05:58] :) Then i can nag you about the other 50 packages i have that need sponsoring [06:00] hey pitti === zz_frobware is now known as frobware [06:06] hey darkxst, how are you? [06:07] yeh good, finally it has cooled down here! [06:08] mvo: Howdy. Did you happen to see my comment before you left last night? [06:08] pitti, would you be able to add an endorsment to my PPU/MOTU application? (Planning on attending the next meeting 27th) [06:09] darkxst: sure, will do [06:09] thanks === frobware is now known as zz_frobware [06:14] Noskcaj: hm, did you update debian/control manually? curious how the "XSBC-Original-Maintainer: Maintainer: [...]" oddity came in here (will fix that during merge) [06:15] Probably. I think bzr had a conflict there that i must have done wrong. oops [06:15] Noskcaj: FYI, debclean will update debian/control from control.in [06:15] This is why i hate packaging one thing over many days [06:16] ok [06:16] (no worries) [06:20] Unit193: i didn't, sorry - could you please paste it to me again? [06:21] I ended up commenting before you responded. I saw several marked as dupes of that bug so just figured there was proper, then noticed I couldn't re-open. Is there a chance you can do that? [06:33] Unit193: I think I can, could you please give me the bugnumber again? [06:34] mvo: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1060543 [06:34] Ubuntu bug 1060543 in software-properties (Ubuntu) "Additional Drivers is not discoverable in Quantal" [Critical,Fix released] [06:41] Could someone help me with refreshing a patch to argyll? [06:41] ty for the syncs pitti [06:41] Noskcaj: yw [06:43] I need help re-adding a patch to https://code.launchpad.net/~noskcaj/ubuntu/trusty/argyll/merge [06:43] xnox, I think you made the original [06:44] drop-usb-db.patch [06:53] mvo: Danke! [06:54] Unit193: your welcome .) [06:54] Unit193: I will try to look at your diff today, if nothing has happend by lunchtime please gently nudge me again (have to do some other stuff first) [06:55] mvo: Heh, it's 01:55, I'm watching Castle then going to bed. :P But sure, next time. [06:56] Unit193: wehh, these timezones .) yeah, lets talk tomorrow, have a good night [07:01] Indeed. === zz_frobware is now known as frobware [07:30] good morning === oSoMoN_ is now known as oSoMoN === frobware is now known as zz_frobware === zz_frobware is now known as frobware [09:21] Noskcaj: be careful, in debian I think they dropped the db usage completely, which I don't think is correct. [09:22] xnox, ok. Is there any chance you could try and finish the merge, since it's beyond my understanding [09:23] yeah, i will. [09:23] thanks === doko_ is now known as doko [09:51] pitti, autopkgtests ... the one we did for linux ... this is a compile test basically which is great when gcc changes, but makes no sense to fire when the package in question is linux itself as we just did that. is this something we can codify in the test? [09:52] apw: not really in linux itself, as that autopkgtest has no idea when/why it gets called [09:52] pitti, so i don't get offered the name of the trigger'er or anything [09:52] apw: we could perhaps change eglibc's autopkgtest to try and build linux, not itself [09:53] apw: no, britney/jenkins are way higher up in the stack than autopkgtest, I'm afraid [09:53] pitti, i thought that way lay madness or something, as every package had to list all possible packages [09:53] apw: i. e. instead of trying to build itself, packages could try and build the others in the "toolchain" set except themselves [09:53] right [09:53] and it doesn't parallelize that way [09:53] which is why we did it this way around and live with the overhead [09:53] ponder - launchpadlib in python3 [09:54] so it sounds like something fundamental to the /control level to say "but not for me" [09:54] rebuilt on requests [09:54] apw: we have enough build slaves, after all; the unnerving thing are the failures [09:54] * apw has yet to see a kernel make it through testing i think [09:54] apw: we recently found a too small copy timeout for linux (on one node, copying the sources takes more than 5 mins, yay slow disks); so it ought to get better now [09:54] and fail less often [09:54] apw: how do you mean? [09:55] apw: they succeed often, but also used to timeout often [09:55] https://jenkins.qa.ubuntu.com/job/trusty-adt-linux/? [09:55] pitti, all the ones i have followed through have failed on one arch out of the two i think [09:55] but that would be only on upload, not ones triggered say but eglibc or whatever [09:56] ah, tar freaking out again with "File removed before we read it [09:56] pitti, so you pointed me at a jenkins page which is like shoving hot needles in my brain, but making the foolish assumption that red == bad and green == good down the left there, my head says apw: exactly [09:57] ok so by my cound 60% are failing [09:57] apw, timeout increased to 2000s. It may still fail depending on IO contention on the servers. === Laney changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 1 released! | Archive: alpha 2 freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [09:57] apw: ah, that's still the timeout apparently [09:57] from copyupdown [09:57] jibel: thanks [09:58] jibel, apw: retried [09:58] pitti, yes, now set to 2000s we could as well drop it completely [09:59] pitti, what is this copy, is it someting i need and can i ask for it not to be so copied in my test stanza [10:00] apw: no, unfortuantely not [10:00] apw: that's autopkgtest copying the source package/source tree into its temp dir in the runner [10:00] apw: and aldebaran's disk is just awfully slow [10:01] apw: most tests are run on tmpfs (this machine has 64 GB RAM or so), but it's not enough to build linux; so linux and libreoffice run on a disk overlay instead of RAM [10:02] pitti, exclusively on disk? or ram overflowing to disk? [10:03] pitti, this machine is quite good but if at the same time it runs smoke tests they eat all resources available [10:03] ah [10:03] directhex: exclusively on disk; can qemu-img do this kind of hybrid mode? [10:05] pitti, i think we hammered it into working for a project at work. trying to remember the details. it involved using nbd to create a ram block device (not using tmpfs) but i don't remember which service was used to overflow to an LV [10:05] maybe bcache [10:11] apw: hey, perhaps you have an idea about that: since recently (few days, could be with the new -4 kernel), preparing our autopkgtest VMs fail due to ENOSPC [10:11] apw: the issue is that df says that /dev/vda1 (which is root) is 100% full, it's 5.9 GB [10:11] am asking the engineer who did it if he documented it anywhere [10:11] apw: but du -hcx / only reports some 800 MB being used [10:12] apw: I already checked /proc/*/fd/ and lsof for deleted files, there are none at all; and tune2fs says the journal is only 32 MB [10:12] apw: do you happen to know anything else which could eat up disk space which doesn't appear in df or in deleted files? [10:13] pitti: out of inodes? [10:13] lifeless: nope, checked that already [10:13] Block count: 1572608 [10:13] Free blocks: 1340686 [10:13] Free inodes: 332101 [10:13] jodh: just got the reboot again [10:14] # du -hsx / [10:14] pitti: so clearly has free blocks [10:14] 832M/ [10:14] pitti: what about quotas? [10:14] /dev/vda1 5.9G 5.9G 0 100% / [10:14] lifeless: they aren't set up [10:14] oh, I see, df thinks its full [10:14] but even if they were, they shouldn't affect root and df? [10:14] the free blocks is what 80% [10:14] lifeless: yes, and everything else fails on ENOSPC too [10:14] lifeless: right [10:15] I'm running out of ideas what could be wrong [10:15] I smell a bug :) [10:15] neither cloud-init nor cloud-utils changed recently, nor the ext tools [10:15] I suspected hidden or deleted files, but I don't find any [10:15] pitti: they would use up free blocks [10:16] pitti: so it can't be that [10:16] true that [10:16] pitti: sparse allocation maybe? [10:16] jodh: what logs do you want? [10:16] I was doing an apt update in the host and inside an lxc container simultaneously [10:16] pitti, lifeless and after a reboot used space on /dev/vda1 is 15% [10:16] TJ-: perhaps; I'm not entirely sure how the cloud images' root fs are put together [10:17] qemu-img resize $DISKPATH +${DISKSIZE} [10:17] jibel: ^ is that it? [10:17] pitti, yes [10:18] last qemu update was on Jan 3, the next upload is still stuck in -proposed, so not that either [10:18] then cloud-init resizes it to the maximum size available [10:18] it = rootfs [10:20] jodh: the last thing in my apt log is Setting up libselinux1:amd64 (2.2.2-1) ... [10:20] libselinux1's postinst does telinit u [10:22] Laney: I think you'll find that you have an invalid conf file that is triggering the crash. alsa-utils is the most recent package that had invalid jobs, but that has now been fixed. [10:22] would it be logged? [10:23] anyway, that should certainly not cause the machine to reboot [10:24] Laney: yes, if you're running in debug mode (--debug). [10:24] Laney: of course :) I've now fixed the bug but am awaiting an upstart developer to review the fix: lp:~jamesodhunt/upstart/bug-1269731. Maybe xnox or cjwatson could take a look? [10:25] pitti: doesn't make sense though; df uses the block allocation maps, so if it reports 100% the host is using sparse allocation and has run out of space [10:27] jodh: looking shortly [10:27] cjwatson: thanks! [10:27] pitti: jibel: is it possible that online resize is being used, and is broken ? [10:27] pitti, I reprovisioned a VM with a disk size of 12G and df is still reporting it is full on first boot. /dev/vda1 12G 12G 0 100% / [10:27] anything in dmsg [10:27] TJ-: I just wanted to check this, and I made an interesting observation [10:28] $ sudo du -hsxc /tmp [10:28] 4,0K/tmp [10:28] tmpfs 7,8G 5,7G 2,1G 74% /tmp [10:28] that's on my workstation (not in qemu) [10:28] $ sudo du -hsxc /run [10:28] 1,3M/run [10:29] tmpfs 1,6G 1,2M 1,6G 1% /run [10:29] err, no, run-adt-test is using /run/shm, right? [10:29] anyway, I have 4K files in /tmp/, but df says 5.7 GB are used in /tmp [10:29] jodh: r=me, sorry for the delay [10:29] so it might very well be that qemu has no space because on my host /dev/shm/ is full [10:30] although it isn't, /run/shm/ has 7.3 GB free [10:30] just /tmp/ is really wrong [10:30] jodh: oh cool, thanks [10:30] jibel: ^ does prepare-testbed use /tmp? that might explain why it's full during prepare-testbed, but works after a reboot when it uses /run/shm [10:31] grr [10:31] jibel: well, I'll try booting with 3.13.0-3 and compare [10:31] stgraber: got any ideas how we can make the ssh-agent script less racy? [10:32] cjwatson: thanks! [10:32] pitti, it uses what you set as BASEDIR in ~/.adtrc and defaults to /tmp [10:32] BASEDIR=/home/martin-scratch/adt [10:33] pitti: Isn't it pressure on RAM? tmpfs is backed by swap space [10:34] TJ-: well, I still don't know why it would run out of RAM; but the lost 5.7 GB in my /tmp/ are certainly curious [10:34] (/tmp is on tmpfs) [10:35] pitti, jibel Note that the 3.13.0-3 kernel very likely has an accounting bug for tmpfs [10:35] smb: I didn't have the cloud-init problem on -3; it just started maybe two days ago [10:35] 3.13.0-4 (currently in proposed is believed to fix this) === _salem is now known as salem_ [10:36] could coincide with -4 [10:36] smb: you mean -3 → -4 and -4 → -5 ? [10:36] smb: I'm currently downloading -5 from -proposed and will test that [10:36] pitti, Err yeah I probably do [10:37] pitti, Versions changing so quickly, sorry. [10:37] what's up with the linux autopkgtest? [10:37] that at least would also explain why we don't get that problem in the DC where we have precise or saucy as a host OS [10:38] cjwatson: it keeps timing out on copying the sources into its tmp dir; jibel just bumped the timeout again [10:38] ah, /me reads scrollback. so is somebody retrying the test? [10:39] we need to get this in for the alpha [10:39] cjwatson: already did [10:39] ok, good [10:39] sorting d-i now [10:41] jibel: ok, so with -5 on the host I still get the bug in the VM; we might need to get -5 into the cloud image [10:41] at least df now looks sensible in my hosts' /tmp/ [10:41] smb: ^ [10:42] cjohnston, hey, I am applying for upload rights on ubuntu GNOME packageset but there isnt one! [10:42] pitti: good, hopefully it'll fix d-i too [10:42] cjwatson, ^^ [10:42] darkxst: I'm no longer on the TB so I don't operate packagesets any more [10:42] darkxst: though you probably actually want to ask the DMB [10:43] cjwatson, Laney told me to ask you [10:43] darkxst: Laney is wrong :) [10:43] haha [10:43] Can we drive those scripts? [10:43] pitti, Probably needs to move to updates. But then I should read more scrollback on what exactly your tmpfs problem is after changing the latest kernel [10:43] I *think* it needs the TB, but you can try [10:43] lp:~cjwatson/+junk/packageset - there's a component you need to run on lillypilly [10:44] smb: right, let's wait until this is in trusty and we have a cloud-image with -5 [10:44] == All uploaders for package set 'ubuntugnome' in 'trusty' (owned by 'Ubuntu Technical Board') == [10:44] (or I suppose just anywhere with a full mirror) [10:44] DMB cannot manage that [10:44] smb: it's all very confusing ATM, and tests on various host and guest configurations give contradicting results [10:45] pitti, With the tmpfs bug, anything that actually makes use of it has a chance to fail. So it could be something ending up in tmpfs on the host but also and probably more often when using anything inside the guest [10:45] Laney, cjwatson, so I am applying for a non-existent packageset ? atlest MOTU will be useful ;) [10:45] stgraber is in the intersection [10:46] if it is the percpu fix we are talking about you would need that everywhere, as /dev is one [10:46] he might be interested in learning how to run this process [10:46] Laney: I was planning to hand it over at the core sprint next week [10:47] apw: originally it was the "/dev/vda1 is 100% full although it isn't" issue in qemu, then I noticed the "df gives bogus tmpfs usage" on my host; they might or might not be releated [10:47] apw: so I guess we'll let -5 propoagate and get a cloud image with it, then I'll try again; let's hope it's all good then [10:47] cjwatson: nod [10:47] Laney: when people can throw tomatoes at me for it in person [10:47] (it's really dreadful code) [10:47] pitti, indeed, but i would test with everything updated rather than hurt your mind with the infinite possibilities [10:48] apw: right; apparently -5 on the host and -4 in the qemu guest doesn't fix it yet [10:48] pitti, Quite expectedly [10:48] apw: conversely, with a raring kernel on the host and -4 as a qemu guest it seems to work [10:48] apw: but curiously this is on a qemu-img backed on ext4, not tmpfs [10:49] oh well *shrug* kernel mystics .. /me goes and investigates the equally mysterious bug 1220681 [10:49] bug 1220681 in espeak (Ubuntu) "package espeak-data 1.46.02-2ubuntu1 failed to install/upgrade: unable to move aside `./usr/lib/i386-linux-gnu/espeak-data/voices/en' to install new version: Invalid cross-device link" [Undecided,Confirmed] https://launchpad.net/bugs/1220681 [10:49] the issue is in per cpu counters, its not tmpfs related just that is very sensitive to it [10:50] given the bug, i am amazed the kernel boots with it at all under any circumstances [10:50] apw: ah, so it could break just about anything [10:50] apw: I guess it effectively means it never clears any references to anything [10:50] probably uses a shitload of memory [10:50] and pretty much everything, i had all sorts of random things going on on -4, -5 seems better to me [10:50] that now also explains why my apt-get was so glacially slow yesterday [10:50] leaking like hell at least i recon === timrc is now known as timrc-afk [11:14] apw: hm, something isn't quite right -- why does the autopkgtest build it *twice*? [11:17] apw: nevermind, I mislooked; all good (i386 succeeded) === timrc-afk is now known as timrc [11:31] stgraber: is it possible to set a different default container dir (than /var/lib/lxc) in /etc/lxc/default.conf or ~/.lxc? man lxc.conf doesn't mention it, nor does it mention what the actual config files are [11:32] stgraber: so that I don't need to use -P all the time [11:41] apw, cjwatson: linux autopkgtest succeeded now, BTW [11:42] "Not touching package due to block request by freeze " [11:42] but excuses still says "autopkgtest for linux 3.13.0-5.20: FAIL"; I hope it's just out of date [11:45] pitti, i don't think it ever notices when you rerun a test does it ? [11:45] apw: actually I think jibel fixed that a while ago [11:45] it just need ignoring the test i think there [11:46] apw: if it didn't update after the next run, I'll fix the history file [11:46] apw: ah, it just did [11:46] apw: all good now, it's just the release team blocker that holds it back now [11:46] (a2 freeze) [11:47] and possibly d-i [11:47] oh no that is there too ... ok [11:47] I uploaded d-i [11:47] not blocked by itself, it' sjust waiting on linux [11:47] thanks === MacSlow is now known as MacSlow|lunch === tkamppeter_ is now known as tkamppeter [12:24] jibel: (i think we discussed this ~1.5 weeks ago) have you tried running tests under utah with this change applied to the base image: sudo sh -c "echo exec su - -c adbd > $OUT/mnt/etc/init/android-tools-adbd.override" [12:24] ? [12:25] sudo sh -c "echo exec su - -c adbd > /etc/init/android-tools-adbd.override" [12:25] that actually? [12:32] xnox, it was not with me, sorry. [12:36] ok. i'll search my logs then... === PeterS_ is now known as PeterSchwaller [13:13] is there a reason why I would not have com.upstart.Ubuntu? [13:14] over dbus that is [13:15] shadeslayer: firstly it's com.ubuntu.Upstart [13:16] assuming you just typoed, then I don't know :-) [13:16] qdbus com.ubuntu.Upstart gives me Service 'com.ubuntu.Upstart' does not exist. [13:18] Laney: I don't suppose there's a way to actually start that interface by hand? [13:19] Laney: also, i'm on Kubuntu if that makes a difference === Sweetsha1k is now known as Sweetshark [13:21] shadeslayer: sorry, I don't know - I was under the impression that it should always be there [13:21] maybe #upstart can help you [13:21] aha, I'll ask === MacSlow|lunch is now known as MacSlow === arun_ is now known as arunpyasi [13:52] cjwatson, i'm thinking about memtest86+ as part of ubuntu standard. how would you recommend re-ordering things so that I can get that out of cloud images? [13:58] smoser: will follow up to the dormant mail thread, this IRC channel is too narrow [13:58] ok thank you. [14:00] cjwatson: FYI, ubiquity autopkgtest failed on i386 FTBFS of webkit-gtk (causing uninstallability) [14:06] pitti: I usually use severity serious for broken autopkg tests by design. it's nice if people add them, but things like this should never happen in the first place [14:06] pitti, please overwrite this test. blocks a package removal [14:07] pitti, libocsync-plugin-owncloud, waits for owncloud-client to go to trusty [14:07] doko: err, yes, I know -- that looks like a replay? [14:07] doko: slangasek added the override, it's in trusty [14:07] pitti, oh, is it overwritten? [14:08] doko: any ~ubuntu-release can commit adt overrides in britney hints. [14:08] libocsync-plugin-owncloud | 0.90.4-1 | trusty/universe | amd64, arm64, armhf, i386, powerpc, ppc64el [14:08] still see [14:08] libocsync-plugin-owncloud [14:08] python-owncloud universe amd64 i386 arm64 armhf powerpc ppc64el [14:08] doko: ^ is that the version you are looking for? (nothign in -proposed) [14:09] pitti: is that something we (ubiquity developers) need to do anything about? I'd expect it to be retried once webkitgtk is fixed [14:09] I don't see any "croc" in component-mismatches, NBS, or britney [14:09] cjwatson: no, it was just a FYI (as you probably got the mail) [14:10] ah no, xnox got it [14:10] that explains my confusion :) [14:10] cjwatson: sorry, in my mind "ubiquity" is still "Colin" [14:11] so for once an autopkgtest failure today was not due to the test machinery *sigh* [14:11] pitti: i'm not on top of my post-vacation unread mail threads yet, especially those from robots =) [14:11] xnox: no worries, and welcome back :) [14:19] pitti: re:autopilot. last time i was talking with thomi & barry, we were thinking to add a "python2" flag to all existing clicks (cause their tests run from $PWD), and for deb tests simply try module import with python3 to see if it should be run with python3. [14:20] pitti: once all tests are converted to python3. A python2 flag can be dropped from clicks (one by one) and for deb tests try python3 import will no longer be needed. [14:20] xnox: right; I just don't quite like the metapackage pulling in both the py2 and py3 stacks, as that's quite some overhead for the phone [14:20] pitti: thus we should arrive at not having any "X-Run-Me-Python3" in the long term, once all is converted. Without an explicit flag day. [14:20] so we need to do that transition for trusty now [14:21] pitti: which should be all done and dusted next week, at the core sprint when barry will be there + the rest of CI etc peoples =) [14:21] pitti: barry did submit a few merge proposals, but not all of them are merged yet. [14:22] xnox: right, I added it to the agenda of our QA sprint as well (mid-Feb) [14:23] xnox: I have patches for dialer-app and messaging-app here, but when I did them they were blocked on splitting out emulators for python3 for some packages [14:23] which in turn was blocked by some discussion how to package/name them [14:23] pitti: i think the next piece that is missing, is for phablet-test-run / utah-runners to do the "try python3" tests. And there is a rejected merge proposal that I saw in my emails. [14:24] doko: in our precise → trusty upgrade tests, several packages failed due to a missing python:any; what particularly provides that :any magic, new dpkg? [14:24] pitti: once we have ability to run tests under python3 in jenkins it should be all easy and quick to transition things one by one. [14:24] pitti, yes [14:24] doko: or new python metapackages? it seems python:any deps now get autogenerated, but there is no Pre-Depends: or somethign like that on dpkg/python-defaults/etc. [14:24] it's dpkg [14:25] xnox: still needs things like bug 1253627 fixed first [14:25] bug 1253627 in ubuntu-ui-toolkit (Ubuntu) "Needs to provide emulators for Python3" [Undecided,New] https://launchpad.net/bugs/1253627 [14:25] doko: ah, so perhaps dh_python[23] need to generate pre-depends for that? [14:26] doko: well, this is rather complex, I'll create a bug report and a small reproducer first [14:26] pitti, won't help, I don't that any python-* module has misc:pre-depends [14:26] yeah, we'd need to either add them, or don't use misc:pre-depends [14:27] bbiab, will investigate this in detail later [14:27] doko: thanks, will try with old and new dpkg then [14:41] pitti: lxc.lxcpath = in /etc/lxc/lxc.conf or ~/.config/lxc/lxc.conf [14:42] pitti: those are currently undocumented because lxc.conf refers to the container's configuration, not the system config... I have a todo item for this week to create lxc.system.conf and lxc.container.conf manpages and have the lxc.conf one just explain what the two files are for and what their respective manpage is [14:51] chiluk: unfortunately, I once again superseded your mysql packages in -proposed. Sorry. [15:02] stgraber: works perfectly, merci ! === barry` is now known as barry_ === barry_ is now known as barry [15:03] barry: quick question: would this be the right way to run 'python setup.py configure' in a rules file? http://paste.ubuntu.com/6792046/ [15:04] or is there something better? [15:04] (with dh_python2) [15:04] mdeslaur: there is "pybuild" which will run stock: configure, build, test, install for all python2 / 3 versions et.al. [15:04] mdeslaur: interesting. configure isn't a standard command, so i'm guessing the setup.py has added this. in that case, dh_python2 probably won't help [15:05] mdeslaur: dh_python2, is a pure packaging helper that does correct extension renaming at the end. [15:05] mdeslaur: and you are playing with highly non-standard libvirt build machinery, so i'm not sure there is anything better for you than what you wrote. [15:05] (dh_python2 doesn't build/configure/install anything) [15:06] * mostly true. [15:06] xnox, barry: ok, thanks, so I'll stick with what I used [15:07] thanks! [15:07] sure! === salem_ is now known as _salem === rcj` is now known as rcj [16:45] hello! [16:46] any member of the sru team could have a look to these two verified bugs, please? [16:46] https://bugs.launchpad.net/ubuntu/+source/notify-osd/+bug/404658 [16:46] Ubuntu bug 404658 in OEM Priority Project precise "notification summary doesn't change for synchronous messages" [Critical,In progress] [16:46] https://bugs.launchpad.net/oem-priority/+bug/1253591 [16:46] thanks! [16:46] Ubuntu bug 1253591 in OEM Priority Project "Display switch and Radio enable/disable hotkey icons" [High,In progress] [16:50] infinity: did you notice the email I sent a while ago about the merging of makedumpfile , [16:50] ? [16:51] infinity: if it's ok with you, I'll merge it & do my best to get the debian side I package in sync [16:58] jibel: FYI, I filed bug 1271237 to track investigations [16:58] bug 1271237 in python-defaults (Ubuntu) "precise → trusty upgrade; several packages fail due to python:any dependency" [Undecided,New] https://launchpad.net/bugs/1271237 [17:00] pitti: followed up with what might be a useful link [17:00] cjwatson: right, it very much sounds like that [17:01] python:any isn't satisfied yet, but apt doesn't upgrade python to satisfy it [17:01] cjwatson: many thanks for the link [17:01] np [17:02] seb128: could you check that the newer grub in trusty-proposed fixes your timeout problem? [17:02] cjwatson: I'll backport that and test an upgrade with that; the next question is of course whether apt gets upgraded before that [17:02]