[00:28] <slangasek> pitti: did you still need an owncloud-client ignore?
[00:38] <slangasek> pitti: seems so - hint added now
[02:24] <lolcat> Has it ever been considered to make aptitude use bitorrent?
[02:31] <tarpman> lolcat: https://wiki.debian.org/DebTorrent
[02:41] <lolcat> cool
[02:44] <lolcat> tarpman: So it isn't feasible?
[02:45] <lolcat> 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] <RAOF> lolcat: In the meantime, running an apt-proxy is pretty simple.
[03:00] <RAOF> lolcat: See squid-deb-proxy-client + squid-deb-proxy/apt-cacher-ng etc.
[03:01] <lolcat> Hard to install on freeBSD
[03:01] <RAOF> Why would you install it on freeBSD?
[03:01] <RAOF> (And I'd be amazed if squid was hard to install on FreeBSD!)
[03:02] <lolcat> Because I have three computers with ubuntu
[03:02] <lolcat> They are not on at the same time always
[03:02] <lolcat> How would I set it up so they know which has the package?
[03:02] <lifeless> lolcat: pkg_add squid; done - no ?
[03:03] <RAOF> There's apt-zeroconf for that, if you don't have a machine that'd be mostly-on.
[03:03] <lifeless> lolcat: squid-deb-proxy uses zeroconf
[03:03] <RAOF> Welcome, squid-highlighting friends!
[03:03] <RAOF> :)
[03:03] <lolcat> ah
[03:04] <lolcat> I guess Ill just upgrade to 100mbps and forget about it
[03:04] <lifeless> *blink*
[03:05] <RAOF> 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.
[03:07] <RAOF> 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] <RAOF> (I've probably asked that before)
[03:11] <lifeless> RAOF: cache_peer and list all the peers
[03:11] <lifeless> RAOF: IIRC digests (bloom filter API) are on by default, so you'll get that behaviour
[03:11] <lifeless> should be easy enough to wire a config generator into zeroconf and do that
[03:11] <RAOF> Hm, yeah. Interesting.
[03:12] <lifeless> of course, trust is an issue, as you're basically saying 'hey, use me for transit!'
[03:12] <RAOF> Well, there's apt's signing mechanism on top.
[03:12] <lifeless> for the special case of safe-over-http content, sure
[03:13] <RAOF> So you shouldn't be able to silently break stuff.
[03:13] <lifeless> just saying :)
[03:13] <lifeless> you could silently withhold security updates
[03:13] <RAOF> Don't we https:// them yet?
[03:13] <RAOF> No, we don't. Sadface (:
[03:14] <lifeless> and also they don't exist for the open release
[03:14] <RAOF> True.
[03:14] <RAOF> We could always turn off proxying for Packages.gz
[03:17] <RAOF> Actually, I suspect the default config works for that; setting all 0s for refresh_pattern on Packages should do that?
[03:18] <lifeless> no
[03:18] <lifeless> that affects heuristics
[03:18] <lifeless> explicit timing data from servers takes precedence
[03:18] <lifeless> unless you actually explicitly override which IIRC requires a compile time option to enable RFC violations
[03:19] <lifeless> I'm not really worried about someone withholding updates
[03:19] <RAOF> There's presumably a squid key to disable caching and always got to the server?
[03:19] <lifeless> it was just an observation
[03:19] <lifeless> yes
[03:21] <RAOF> 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] <lifeless> its not secure now
[03:21] <lifeless> in this sense
[03:21] <lifeless> because I can plug an unprivileged machine in and advertise
[03:21] <lifeless> so - no new hole
[03:22] <lifeless> the difference is that you want to share the cache
[05:55] <pitti> Good morning
[05:55] <pitti> slangasek: yes, doko_ asked for it; thanks
[05:57] <Noskcaj> pitti, The g-s-t merge should be ready for you to look at
[05:58] <Noskcaj> (finally)
[05:58] <pitti> Noskcaj: yes, thanks muchly! I have it in a tab to review this morning
[05:58] <Noskcaj> :) Then i can nag you about the other 50 packages i have that need sponsoring
[06:00] <darkxst> hey pitti
[06:06] <pitti> hey darkxst, how are you?
[06:07] <darkxst> yeh good, finally it has cooled down here!
[06:08] <Unit193> mvo: Howdy.  Did you happen to see my comment before you left last night?
[06:08] <darkxst> pitti, would you be able to add an endorsment to my PPU/MOTU application? (Planning on attending the next meeting 27th)
[06:09] <pitti> darkxst: sure, will do
[06:09] <darkxst> thanks
[06:14] <pitti> 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] <Noskcaj> Probably. I think bzr had a conflict there that i must have done wrong. oops
[06:15] <pitti> Noskcaj: FYI, debclean will update debian/control from control.in
[06:15] <Noskcaj> This is why i hate packaging one thing over many days
[06:16] <Noskcaj> ok
[06:16] <pitti> (no worries)
[06:20] <mvo> Unit193: i didn't, sorry - could you please paste it to me again?
[06:21] <Unit193> 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] <mvo> Unit193: I think I can, could you please give me the bugnumber again?
[06:34] <Unit193> mvo: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1060543
[06:41] <Noskcaj> Could someone help me with refreshing a patch to argyll?
[06:41] <Noskcaj> ty for the syncs pitti
[06:41] <pitti> Noskcaj: yw
[06:43] <Noskcaj> I need help re-adding a patch to https://code.launchpad.net/~noskcaj/ubuntu/trusty/argyll/merge
[06:43] <Noskcaj> xnox, I think you made the  original
[06:44] <Noskcaj> drop-usb-db.patch
[06:53] <Unit193> mvo: Danke!
[06:54] <mvo> Unit193: your welcome .)
[06:54] <mvo> 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] <Unit193> mvo: Heh, it's 01:55, I'm watching Castle then going to bed. :P  But sure, next time.
[06:56] <mvo> Unit193: wehh, these timezones .) yeah, lets talk tomorrow, have a good night
[07:01] <Unit193> Indeed.
[07:30] <dholbach> good morning
[09:21] <xnox> Noskcaj: be careful, in debian I think they dropped the db usage completely, which I don't think is correct.
[09:22] <Noskcaj> xnox, ok. Is there any chance you could try and finish the merge, since it's beyond my understanding
[09:23] <xnox> yeah, i will.
[09:23] <Noskcaj> thanks
[09:51] <apw> 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] <pitti> apw: not really in linux itself, as that autopkgtest has no idea when/why it gets called
[09:52] <apw> pitti, so i don't get offered the name of the trigger'er or anything
[09:52] <pitti> apw: we could perhaps change eglibc's autopkgtest to try and build linux, not itself
[09:53] <pitti> apw: no, britney/jenkins are way higher up in the stack than autopkgtest, I'm afraid
[09:53] <apw> pitti, i thought that way lay madness or something, as every package had to list all possible packages
[09:53] <pitti> apw: i. e. instead of trying to build itself, packages could try and build the others in the "toolchain" set except themselves
[09:53] <pitti> right
[09:53] <pitti> and it doesn't parallelize that way
[09:53] <pitti> which is why we did it this way around and live with the overhead
[09:53] <brendand> ponder - launchpadlib in python3
[09:54] <apw> so it sounds like something fundamental to the /control level to say "but not for me"
[09:54] <brendand> rebuilt on requests
[09:54] <pitti> 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] <pitti> 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] <pitti> and fail less often
[09:54] <pitti> apw: how do you mean?
[09:55] <pitti> apw: they succeed often, but also used to timeout often
[09:55] <pitti> https://jenkins.qa.ubuntu.com/job/trusty-adt-linux/?
[09:55] <apw> pitti, all the ones i have followed through have failed on one arch out of the two i think
[09:55] <apw> but that would be only on upload, not ones triggered say but eglibc or whatever
[09:56] <pitti> ah, tar freaking out again with "File removed before we read it
[09:56] <apw> 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 <half worked
[09:56] <pitti> apw: exactly
[09:57] <apw> ok so by my cound 60% are failing
[09:57] <jibel> apw, timeout increased to 2000s. It may still fail depending on IO contention on the servers.
[09:57] <pitti> apw: ah, that's still the timeout apparently
[09:57] <pitti> from copyupdown
[09:57] <pitti> jibel: thanks
[09:58] <pitti> jibel, apw: retried
[09:58] <jibel> pitti, yes, now set to 2000s we could as well drop it completely
[09:59] <apw> 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] <pitti> apw: no, unfortuantely not
[10:00] <pitti> apw: that's autopkgtest copying the source package/source tree into its temp dir in the runner
[10:00] <pitti> apw: and aldebaran's disk is just awfully slow
[10:01] <pitti> 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] <directhex> pitti, exclusively on disk? or ram overflowing to disk?
[10:03] <jibel> pitti, this machine is quite good but if at the same time it runs smoke tests they eat all resources available
[10:03] <pitti> ah
[10:03] <pitti> directhex: exclusively on disk; can qemu-img do this kind of hybrid mode?
[10:05] <directhex> 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] <directhex> maybe bcache
[10:11] <pitti> 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] <pitti> apw: the issue is that df says that /dev/vda1 (which is root) is 100% full, it's 5.9 GB
[10:11] <directhex> am asking the engineer who did it if he documented it anywhere
[10:11] <pitti> apw: but du -hcx / only reports some 800 MB being used
[10:12] <pitti> 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] <pitti> 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] <lifeless> pitti: out of inodes?
[10:13] <pitti> lifeless: nope, checked that already
[10:13] <pitti> Block count:              1572608
[10:13] <pitti> Free blocks:              1340686
[10:13] <pitti> Free inodes:              332101
[10:13] <Laney> jodh: just got the reboot again
[10:14] <pitti> # du -hsx /
[10:14] <lifeless> pitti: so clearly has free blocks
[10:14] <pitti> 832M/
[10:14] <lifeless> pitti: what about quotas?
[10:14] <pitti> /dev/vda1       5.9G  5.9G     0 100% /
[10:14] <pitti> lifeless: they aren't set up
[10:14] <lifeless> oh, I see, df thinks its full
[10:14] <pitti> but even if they were, they shouldn't affect root and df?
[10:14] <lifeless> the free blocks is what 80%
[10:14] <pitti> lifeless: yes, and everything else fails on ENOSPC too
[10:14] <pitti> lifeless: right
[10:15] <pitti> I'm running out of ideas what could be wrong
[10:15] <lifeless> I smell a bug :)
[10:15] <pitti> neither cloud-init nor cloud-utils changed recently, nor the ext tools
[10:15] <pitti> I suspected hidden or deleted files, but I don't find any
[10:15] <lifeless> pitti: they would use up free blocks
[10:16] <lifeless> pitti: so it can't be that
[10:16] <pitti> true that
[10:16] <TJ-> pitti: sparse allocation maybe?
[10:16] <Laney> jodh: what logs do you want?
[10:16] <Laney> I was doing an apt update in the host and inside an lxc container simultaneously
[10:16] <jibel> pitti, lifeless and after a reboot used space on /dev/vda1 is 15%
[10:16] <pitti> TJ-: perhaps; I'm not entirely sure how the cloud images' root fs are put together
[10:17] <pitti> qemu-img resize $DISKPATH +${DISKSIZE}
[10:17] <pitti> jibel: ^ is that it?
[10:17] <jibel> pitti, yes
[10:18] <pitti> last qemu update was on Jan 3, the next upload is still stuck in -proposed, so not that either
[10:18] <jibel> then cloud-init resizes it to the maximum size available
[10:18] <jibel> it = rootfs
[10:20] <Laney> jodh: the last thing in my apt log is Setting up libselinux1:amd64 (2.2.2-1) ...
[10:20] <Laney> libselinux1's postinst does telinit u
[10:22] <jodh> 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] <Laney> would it be logged?
[10:23] <Laney> anyway, that should certainly not cause the machine to reboot
[10:24] <jodh> Laney: yes, if you're running in debug mode (--debug).
[10:24] <jodh> 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] <TJ-> 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] <cjwatson> jodh: looking shortly
[10:27] <jodh> cjwatson: thanks!
[10:27] <lifeless> pitti: jibel: is it possible that online resize is being used, and is broken ?
[10:27] <jibel> 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] <lifeless> anything in dmsg
[10:27] <pitti> TJ-: I just wanted to check this, and I made an interesting observation
[10:28] <pitti> $ sudo du -hsxc /tmp
[10:28] <pitti> 4,0K/tmp
[10:28] <pitti> tmpfs                  7,8G    5,7G  2,1G   74% /tmp
[10:28] <pitti> that's on my workstation (not in qemu)
[10:28] <pitti> $ sudo du -hsxc /run
[10:28] <pitti> 1,3M/run
[10:29] <pitti> tmpfs                  1,6G    1,2M  1,6G    1% /run
[10:29] <pitti> err, no, run-adt-test is using /run/shm, right?
[10:29] <pitti> anyway, I have 4K files in /tmp/, but df says 5.7 GB are used in /tmp
[10:29] <cjwatson> jodh: r=me, sorry for the delay
[10:29] <pitti> so it might very well be that qemu has no space because on my host /dev/shm/ is full
[10:30] <pitti> although it isn't, /run/shm/ has 7.3 GB free
[10:30] <pitti> just /tmp/ is really wrong
[10:30] <Laney> jodh: oh cool, thanks
[10:30] <pitti> 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] <Laney> grr
[10:31] <pitti> jibel: well, I'll try booting with 3.13.0-3 and compare
[10:31] <Laney> stgraber: got any ideas how we can make the ssh-agent script less racy?
[10:32] <jodh> cjwatson: thanks!
[10:32] <jibel> pitti, it uses what you set as BASEDIR in ~/.adtrc and defaults to /tmp
[10:32] <pitti> BASEDIR=/home/martin-scratch/adt
[10:33] <TJ-> pitti: Isn't it pressure on RAM? tmpfs is backed by swap space
[10:34] <pitti> 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] <pitti> (/tmp is on tmpfs)
[10:35] <smb> pitti, jibel Note that the 3.13.0-3 kernel very likely has an accounting bug for tmpfs
[10:35] <pitti> smb: I didn't have the cloud-init problem on -3; it just started maybe two days ago
[10:35] <smb> 3.13.0-4 (currently in proposed is believed to fix this)
[10:36] <pitti> could coincide with -4
[10:36] <pitti> smb: you mean -3 → -4 and -4 → -5 ?
[10:36] <pitti> smb: I'm currently downloading -5 from -proposed and will test that
[10:36] <smb> pitti, Err yeah I probably do
[10:37] <smb> pitti, Versions changing so quickly, sorry.
[10:37] <cjwatson> what's up with the linux autopkgtest?
[10:37] <pitti> 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] <pitti> cjwatson: it keeps timing out on copying the sources into its tmp dir; jibel just bumped the timeout again
[10:38] <cjwatson> ah, /me reads scrollback.  so is somebody retrying the test?
[10:39] <cjwatson> we need to get this in for the alpha
[10:39] <pitti> cjwatson: already did
[10:39] <cjwatson> ok, good
[10:39] <cjwatson> sorting d-i now
[10:41] <pitti> 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] <pitti> at least df now looks sensible in my hosts' /tmp/
[10:41] <pitti> smb: ^
[10:42] <darkxst> cjohnston, hey, I am applying for upload rights on ubuntu GNOME packageset but there isnt one!
[10:42] <cjwatson> pitti: good, hopefully it'll fix d-i too
[10:42] <darkxst> cjwatson, ^^
[10:42] <cjwatson> darkxst: I'm no longer on the TB so I don't operate packagesets any more
[10:42] <cjwatson> darkxst: though you probably actually want to ask the DMB
[10:43] <darkxst> cjwatson, Laney told me to ask you
[10:43] <cjwatson> darkxst: Laney is wrong :)
[10:43] <Laney> haha
[10:43] <Laney> Can we drive those scripts?
[10:43] <smb> 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] <cjwatson> I *think* it needs the TB, but you can try
[10:43] <cjwatson> lp:~cjwatson/+junk/packageset - there's a component you need to run on lillypilly
[10:44] <pitti> smb: right, let's wait until this is in trusty and we have a cloud-image with -5
[10:44] <Laney> == All uploaders for package set 'ubuntugnome' in 'trusty' (owned by 'Ubuntu Technical Board') ==
[10:44] <cjwatson> (or I suppose just anywhere with a full mirror)
[10:44] <Laney> DMB cannot manage that
[10:44] <pitti> smb: it's all very confusing ATM, and tests on various host and guest configurations give contradicting results
[10:45] <smb> 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] <darkxst> Laney, cjwatson, so I am applying for a non-existent packageset ? atlest MOTU will be useful ;)
[10:45] <Laney> stgraber is in the intersection
[10:46] <apw> if it is the percpu fix we are talking about you would need that everywhere, as /dev is one
[10:46] <Laney> he might be interested in learning how to run this process
[10:46] <cjwatson> Laney: I was planning to hand it over at the core sprint next week
[10:47] <pitti> 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] <pitti> 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] <Laney> cjwatson: nod
[10:47] <cjwatson> Laney: when people can throw tomatoes at me for it in person
[10:47] <cjwatson> (it's really dreadful code)
[10:47] <apw> pitti, indeed, but i would test with everything updated rather than hurt your mind with the infinite possibilities
[10:48] <pitti> apw: right; apparently -5 on the host and -4 in the qemu guest doesn't fix it yet
[10:48] <smb> pitti, Quite expectedly
[10:48] <pitti> apw: conversely, with a raring kernel on the host and -4 as a qemu guest it seems to work
[10:48] <pitti> apw: but curiously this is on a qemu-img backed on ext4, not tmpfs
[10:49] <pitti> oh well *shrug* kernel mystics .. /me goes and investigates the equally mysterious bug 1220681
[10:49] <apw> the issue is in per cpu counters, its not tmpfs related just that is very sensitive to it
[10:50] <apw> given the bug, i am amazed the kernel boots with it at all under any circumstances
[10:50] <pitti> apw: ah, so it could break just about anything
[10:50] <cjwatson> apw: I guess it effectively means it never clears any references to anything
[10:50] <cjwatson> probably uses a shitload of memory
[10:50] <apw> and pretty much everything, i had all sorts of random things going on on -4, -5 seems better to me
[10:50] <pitti> that now also explains why my apt-get was so glacially slow yesterday
[10:50] <apw> leaking like hell at least i recon
[11:14] <pitti> apw: hm, something isn't quite  right -- why does the autopkgtest build it *twice*?
[11:17] <pitti> apw: nevermind, I mislooked; all good (i386 succeeded)
[11:31] <pitti> stgraber: is it possible to set a different default container dir (than /var/lib/lxc) in /etc/lxc/default.conf or ~/.lxc<something>? man lxc.conf doesn't mention it, nor does it mention what the actual config files are
[11:32] <pitti> stgraber: so that I don't need to use -P all the time
[11:41] <pitti> apw, cjwatson: linux autopkgtest succeeded now, BTW
[11:42] <pitti> "Not touching package due to block request by freeze "
[11:42] <pitti> but excuses still says "autopkgtest for linux 3.13.0-5.20: FAIL"; I hope it's just out of date
[11:45] <apw> pitti, i don't think it ever notices when you rerun a test does it ?
[11:45] <pitti> apw: actually I think jibel fixed that a while ago
[11:45] <apw> it just need ignoring the test i think there
[11:46] <pitti> apw: if it didn't update after the next run, I'll fix the history file
[11:46] <pitti> apw: ah, it just did
[11:46] <pitti> apw: all good now, it's just the release team blocker that holds it back now
[11:46] <pitti> (a2 freeze)
[11:47] <apw> and possibly d-i
[11:47] <apw> oh no that is there too ... ok
[11:47] <cjwatson> I uploaded d-i
[11:47] <pitti> not blocked by itself, it' sjust waiting on linux
[11:47] <apw> thanks
[12:24] <xnox> 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] <xnox> ?
[12:25] <xnox> sudo sh -c "echo exec su - -c adbd > /etc/init/android-tools-adbd.override"
[12:25] <xnox> that actually?
[12:32] <jibel> xnox, it was not with me, sorry.
[12:36] <xnox> ok. i'll search my logs then...
[13:13] <shadeslayer> is there a reason why I would not have com.upstart.Ubuntu?
[13:14] <shadeslayer> over dbus that is
[13:15] <Laney> shadeslayer: firstly it's com.ubuntu.Upstart
[13:16] <Laney> assuming you just typoed, then I don't know :-)
[13:16] <shadeslayer> qdbus com.ubuntu.Upstart gives me Service 'com.ubuntu.Upstart' does not exist.
[13:18] <shadeslayer> Laney: I don't suppose there's a way to actually start that interface by hand?
[13:19] <shadeslayer> Laney: also, i'm on Kubuntu if that makes a difference
[13:21] <Laney> shadeslayer: sorry, I don't know - I was under the impression that it should always be there
[13:21] <Laney> maybe #upstart can help you
[13:21] <shadeslayer> aha, I'll ask
[13:52] <smoser> 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] <cjwatson> smoser: will follow up to the dormant mail thread, this IRC channel is too narrow
[13:58] <smoser> ok thank you.
[14:00] <pitti> cjwatson: FYI, ubiquity autopkgtest failed on i386 FTBFS of webkit-gtk (causing uninstallability)
[14:06] <doko> 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] <doko> pitti, please overwrite this test. blocks a package removal
[14:07] <doko> pitti, libocsync-plugin-owncloud, waits for owncloud-client to go to trusty
[14:07] <pitti> doko: err, yes, I know -- that looks like a replay?
[14:07] <pitti> doko: slangasek added the override, it's in trusty
[14:07] <doko> pitti, oh, is it overwritten?
[14:08] <xnox> doko: any ~ubuntu-release can commit adt overrides in britney hints.
[14:08] <pitti>  libocsync-plugin-owncloud | 0.90.4-1        | trusty/universe | amd64, arm64, armhf, i386, powerpc, ppc64el
[14:08] <doko> still see
[14:08] <doko> libocsync-plugin-owncloud
[14:08] <doko>    	python-owncloud	universe	amd64 i386 arm64 armhf powerpc ppc64el
[14:08] <pitti> doko: ^ is that the version you are looking for? (nothign in -proposed)
[14:09] <cjwatson> 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] <pitti> I don't see any "croc" in component-mismatches, NBS, or britney
[14:09] <pitti> cjwatson: no, it was just a FYI (as you probably got the mail)
[14:10] <pitti> ah no, xnox got it
[14:10] <cjwatson> that explains my confusion :)
[14:10] <pitti> cjwatson: sorry, in my mind "ubiquity" is still "Colin"
[14:11] <pitti> so for once an autopkgtest failure today was not due to the test machinery *sigh*
[14:11] <xnox> pitti: i'm not on top of my post-vacation unread mail threads yet, especially those from robots =)
[14:11] <pitti> xnox: no worries, and welcome back :)
[14:19] <xnox> 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] <xnox> 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] <pitti> 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] <xnox> 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] <pitti> so we need to do that transition for trusty now
[14:21] <xnox> 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] <xnox> pitti: barry did submit a few merge proposals, but not all of them are merged yet.
[14:22] <pitti> xnox: right, I added it to the agenda of our QA sprint as well (mid-Feb)
[14:23] <pitti> 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] <pitti> which in turn was blocked by some discussion how to package/name them
[14:23] <xnox> 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] <pitti> 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] <xnox> 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] <doko> pitti, yes
[14:24] <pitti> 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] <doko> it's dpkg
[14:25] <pitti> xnox: still needs things like bug 1253627 fixed first
[14:25] <pitti> doko: ah, so perhaps dh_python[23] need to generate pre-depends for that?
[14:26] <pitti> doko: well, this is rather complex, I'll create a bug report and a small reproducer first
[14:26] <doko> pitti, won't help, I don't that any python-* module has misc:pre-depends
[14:26] <pitti> yeah, we'd need to either add them, or don't use misc:pre-depends
[14:27] <pitti> bbiab, will investigate this in detail later
[14:27] <pitti> doko: thanks, will try with old and new dpkg then
[14:41] <stgraber> pitti: lxc.lxcpath = in /etc/lxc/lxc.conf or ~/.config/lxc/lxc.conf
[14:42] <stgraber> 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] <mdeslaur> chiluk: unfortunately, I once again superseded your mysql packages in -proposed. Sorry.
[15:02] <pitti> stgraber: works perfectly, merci !
[15:03] <mdeslaur> 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] <mdeslaur> or is there something better?
[15:04] <mdeslaur> (with dh_python2)
[15:04] <xnox> mdeslaur: there is "pybuild" which will run stock: configure, build, test, install for all python2 / 3 versions et.al.
[15:04] <barry> 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] <xnox> mdeslaur: dh_python2, is a pure packaging helper that does correct extension renaming at the end.
[15:05] <xnox> 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] <xnox> (dh_python2 doesn't build/configure/install anything)
[15:06] <xnox>  * mostly true.
[15:06] <mdeslaur> xnox, barry: ok, thanks, so I'll stick with what I used
[15:07] <mdeslaur> thanks!
[15:07] <barry> sure!
[16:45] <ara> hello!
[16:46] <ara> any member of the sru team could have a look to these two verified bugs, please?
[16:46] <ara> https://bugs.launchpad.net/ubuntu/+source/notify-osd/+bug/404658
[16:46] <ara> https://bugs.launchpad.net/oem-priority/+bug/1253591
[16:46] <ara> thanks!
[16:50] <caribou> infinity: did you notice the email I sent a while ago about the merging of makedumpfile ,
[16:50] <caribou> ?
[16:51] <caribou> 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] <pitti> jibel: FYI, I filed bug 1271237 to track investigations
[17:00] <cjwatson> pitti: followed up with what might be a useful link
[17:00] <pitti> cjwatson: right, it very much sounds like that
[17:01] <pitti> python:any isn't satisfied yet, but apt doesn't upgrade python to satisfy it
[17:01] <pitti> cjwatson: many thanks for the link
[17:01] <cjwatson> np
[17:02] <cjwatson> seb128: could you check that the newer grub in trusty-proposed fixes your timeout problem?
[17:02] <pitti> 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] <cjwatson> pitti: similarly, could you check that grub in trusty-proposed still works with SB for you?  another commenter spotted a bug that would affect from-scratch installs on SB
[17:02] <cjwatson> pitti: right, but that's more tractable, u-m could force that
[17:02] <cjwatson> (if it doesn't already)
[17:02] <pitti> *nod*
[17:02] <cjwatson> I guess I mean u-r-u
[17:03] <pitti> cjwatson: yes, I'm happy to update grub again, but it'd be an upgrade, not from scratch
[17:03] <cjwatson> right, just want to check that I didn't break anything else in the process
[17:03] <pitti> cjwatson: unless I can emulate a new installation by purging and reinstalling grub? (I can do that)
[17:03] <seb128> cjwatson, sure
[17:03] <cjwatson> no, you'd have to do manual stuff to your EFI System Partition - an upgrade is fine for this purpose
[17:04] <cjwatson> you could maybe run "sudo grub-install -v" after the upgrade to check that it copies shim to the right place
[17:04] <pitti> cjwatson: ah, that's -4 now -- that should also get rid of the menu again, right?
[17:04] <cjwatson> i.e. /boot/efi/EFI/ubuntu/shimx64.efi not /boot/efi/EFI/ubuntu/grubx64.efi
[17:04] <cjwatson> pitti: yep
[17:11] <pitti> argh, laggy german mirror
[17:11] <pitti>  *** 2.02~beta2-2 0
[17:11] <pitti>         500 http://archive.ubuntu.com/ubuntu/ trusty-proposed/main amd64 Packages
[17:11] <pitti> WTH
[17:15] <pitti> cjwatson: downloaded debs from LP, installed; no failure; with -v: http://paste.ubuntu.com/6792642/
[17:15] <pitti> grub-install: Info: copying `/usr/lib/shim/shim.efi.signed' -> `/boot/efi/EFI/ubuntu/shimx64.efi'.
[17:15] <pitti> grub-install: Info: copying `/usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed' -> `/boot/efi/EFI/ubuntu/grubx64.efi'.
[17:16] <alkisg> Hi, I'm seeing 100% usage of overlayfs (squashfs nbd + tmpfs) file systems, while it should be 0%, it happened in some of the latest trusty kernels, and I'm guessing it should also affect the live CDs (other than LTSP), is it a known issue or should I try to pinpoint it more precisely?
[17:19] <cjwatson> pitti: great, thanks
[17:19] <cjwatson> alkisg: 3.13.0-5 will fix it
[17:19] <pitti> cjwatson: I'll reboot once my container upgrades are done
[17:19] <alkisg> Thank you cjwatson
[17:22] <pitti> cjwatson: booted fine, menu gone \o/
[17:22] <cjwatson> great
[17:23] <cjwatson> it's not totally without reported glitches but I think it's close enough that I'm inclined to push it to trusty after alpha-2
[17:23] <cjwatson> so far
[17:24] <jibel> pitti, postgresql upgrade fails from P>T, I'll file a bug. http://d-jenkins.ubuntu-ci:8080/view/Upgrade/job/upgrade-ubuntu-precise-trusty-server-tasks-amd64/5/
[17:24] <pitti> jibel: thanks
[17:25] <Laney> are those tests on public jenkins?
[17:26] <pitti> there certainly ought to be; it's a bit hard to link to logs ATM
[17:26] <jibel> Laney, they should be, I'll check the configuration.
[17:27] <pitti> update-alternatives: error: alternative pg_basebackup.1.gz can't be slave of psql.1.gz: it is a slave of postmaster.1.gz
[17:27] <Laney> I usually try s/<private host>/jenkins.qa.u.c/ but it failed in this case
[17:27] <Laney> thanks jibel
[17:27] <pitti> jibel: ^ ah, that, rings a bell
[17:27] <jibel> pitti, and a false positive http://d-jenkins.ubuntu-ci:8080/view/Upgrade/job/upgrade-ubuntu-precise-trusty-server-lts-saucy-amd64/6
[17:27] <pitti> jibel: I thought that was fixed already, but apparently it needs some further nudging
[17:27] <jibel> ^ fails during the removal phase
[17:27] <pitti> jibel: I don't see a psql bug there?
[17:28] <pitti> jibel: oh nice, that's precise with an LTS enablement stack; I guess these fall over pretty hard still
[17:28] <jibel> pitti, last bug is not postgresql, it is in xserver-common-lts-saucy and u-r-u
[17:29] <pitti> jibel: right, I discussed that with mlankhorst the other day; we need these -lts-* metapackags as transitionals in trusty, which move back to the standard stack
[17:29] <jibel> because upgrade aborted but the release-upgrader terminates without error
[17:30] <mlankhorst> pitti: oh right I need to create some
[17:30] <pitti> good night everyone!
[17:31] <cff> I'm trying to dual boot CM Android 4.2.2 on a Galaxy Nexus with Ubuntu but after I downloaded the Ubuntu image with the Android app and click reboot to Ubuntu I'm rebooted to recovery mode. What can I do to see what's wrong?
[17:31] <cff> (is this the right channel to ask this question?)
[17:32] <cff> ah, didn't realize there is an #ubuntu-touch channel
[17:53] <chiluk> mdeslaur
[17:54] <chiluk> mdeslaur can you have a look at 1121874
[17:54] <chiluk> mdeslaur it looks like your recent security update for mysql-5.5 updated the package
[17:54] <chiluk> mdeslaur, and maintained the fix for 1121874, but removed it's changelog entry..
[17:55] <chiluk> mdeslaur... I really think you should add the changelog entry back *(not sure if that's really doable.)
[17:55] <chiluk> I'm verifying s, and t right now.
[17:55] <mdeslaur> chiluk: what release are you talking about?
[17:55] <chiluk> p,q,s,t
[17:56] <mdeslaur> trusty has the fix, and includes the changelog
[17:57] <chiluk> I just looked at p and q... and they have the fix... but not the changelog entry.
[17:57] <mdeslaur> chiluk: not sure what you're looking at, but my packages definitely don't contain the fix
[17:58] <chiluk> the fix is in debian/mysql*.init
[17:59] <chiluk> mdeslaur also why did you just blindly remove the fix like that
[17:59] <mdeslaur> chiluk: huh? https://launchpadlibrarian.net/159968670/lp1121874.saucy.debdiff
[17:59] <mdeslaur> chiluk: no fix in .init there
[17:59] <chiluk> mdeslaur.. one sec... I think I missed the series arg to pull-lp-sourcfe
[17:59] <mdeslaur> chiluk: your package was in -proposed, I can't include a fix that hasen't been qa verified
[18:00] <chiluk> mdeslaur, I guess I'm just pissed because this is the third time that I'm having to rebase debdiffs because of security team.
[18:01] <chiluk> and the sru team taking too long to upload/sru approve this fix.
[18:01] <chiluk> this is insane.
[18:01] <mdeslaur> chiluk: yeah, the -proposed process sucks
[18:01] <infinity> (The SRU team doesn't do uploads)
[18:01] <mdeslaur> chiluk: I'll rebase and upload them today
[18:01] <mdeslaur> chiluk: and I'll get someone from SRU team to push them to -proposed right away
[18:01] <chiluk> thanks.
[18:02] <chiluk> i was going to verify them today.
[18:02] <chiluk> so I guess I'll get that done as soon as this gets figured out..
[18:02] <mdeslaur> chiluk: again, sorry about that...bad timing
[18:03] <chiluk> mdeslaur, it's always bad timing... this bug has been fixed since October, and it's wasted too much of a lot of peoples time.
[18:03] <mdeslaur> I definitely agree
[18:06] <mdeslaur> chiluk: mind if I keep your name in the changelog, and just change the version and date?
[18:06] <chiluk> that's fine.
[18:06] <chiluk> mdeslaur.. I just checked precise.. and the fix is definitely in the precise version just not in the changelog
[18:07] <infinity> caribou: I don't see much point in merging makedumpfile in Ubuntu at all.  Looking at the changes, those are all things you should want in Debian, so I'd merge in the other direction, if I were you, and then just sync-with-force back to Ubuntu.
[18:07] <mdeslaur> chiluk: I don't see it
[18:08] <rbasak> chiluk: if it's any consolation, I have also found it hard to get any SRUs into mysql in the past. I think I went round three times once.
[18:08] <chiluk> mdeslaur the fix is mostly thesse lines   # check for diskspace shortage
[18:08] <chiluk>   datadir=`mysqld_get_param datadir`
[18:08] <chiluk>   if LC_ALL=C BLOCKSIZE= df --portability $datadir/. | tail -n 1 | awk '{ exit ($4>4096) }'; then
[18:08] <chiluk>     log_failure_msg "$0: ERROR: The partition with $datadir is too full!"
[18:08] <chiluk>     echo                "ERROR: The partition with $datadir is too full!" | $ERR_LOGGER
[18:08] <chiluk>     exit 1
[18:08] <chiluk>   fi
[18:09] <mdeslaur> chiluk: yeah, I don't see that in the precise package
[18:09] <chiluk> one of us is doing something wrong *(probably me)
[18:13] <chiluk> mdeslaur .. I run pull-lp-source mysql-5.5 precise, and look at debian/mysql-server-5.5.mysql.init
[18:13] <chiluk> and the fix is definitely sitting there.
[18:14] <chiluk> mdeslaur is there a chance the fix got pushed back into debian, as is now coming full circle?
[18:16] <mdeslaur> chiluk: you're looking at the .init file, you need to look at the .upstart file
[18:16] <mdeslaur> chiluk: that's where the bug is
[18:16] <chiluk> crap...
[18:16] <chiluk> see it's been so long ..
[18:16] <mdeslaur> hehe :)
[18:17] <chiluk> mdeslaur..see I knew i was doing something wrong..
[18:18] <chiluk> mdeslaur... the debdiffs should still mostly just apply ... aside from the changelog entries.. do you need anything from me to get that uploaded?  or are you just going to take care of it.
[18:20] <mdeslaur> chiluk: I'm almost done uploading, and then I'll ping someone from SRU to get it pushed to -proposed right away
[18:20] <chiluk> cool thanks.
[18:20] <mdeslaur> chiluk: np
[18:20] <chiluk> well at least it looks like the debian people have been paying attention and pulled my fix into the init script.
[18:21] <chiluk> and I use the term "fix" loosely ... I just want to see this thing gone.
[18:30] <mdeslaur> bdmurray: I just uploaded updated mysql packages to -proposed for bug 1121874, do you think you could push them today, please?
[18:31] <bdmurray> mdeslaur: sure
[18:32] <mdeslaur> bdmurray: thanks!
[18:36] <xnox> tkamppeter: recently I was able to use llvmpipe / gallium 3d on an openstack instance. But with current trusty I can't.
[18:36] <xnox> I get:
[18:36] <xnox> $ LIBGL_DEBUG=verbose xvfb-run glxinfo
[18:36] <xnox> name of display: :99
[18:36] <xnox> libGL: OpenDriver: trying /usr/lib/i386-linux-gnu/dri/tls/swrast_dri.so
[18:36] <xnox> libGL: OpenDriver: trying /usr/lib/i386-linux-gnu/dri/swrast_dri.so
[18:36] <xnox> libGL: driver does not expose __driDriverGetExtensions_swrast(): /usr/lib/i386-linux-gnu/dri/swrast_dri.so: undefined symbol: __driDriverGetExtensions_swrast
[18:36] <xnox> libGL: Can't open configuration file /home/ubuntu/.drirc: No such file or directory.
[18:36] <xnox> libGL: Can't open configuration file /home/ubuntu/.drirc: No such file or directory.
[18:36] <xnox> libGL error: failed to load driver: swrast
[18:36] <xnox> Error: couldn't find RGB GLX visual or fbconfig
[18:36] <xnox> Error: couldn't find RGB GLX visual or fbconfig
[18:37] <xnox> tkamppeter: is that known?
[18:38] <seb128> xnox, hum, why do you ping our printer maintainer about graphic stack issues? are you sure you don't want mlankhorst or tjaalton?
[18:38] <xnox> seb128: good catch!
[18:38] <xnox> tkamppeter: sorry about that.
[18:39] <xnox> mlankhorst: tjaalton: any idea about above ^^^
[18:40] <seb128> xnox, btw I get the same output on my desktop (but followed by the glxinfo one)
[18:40] <xnox> and there haven't been any changes to mesa recently...
[18:41] <xnox> seb128: does it tell you "Vendor" ?
[18:41] <seb128> xnox, no
[18:41] <xnox> seb128: in my case, i don't GPU acceleration, so the swrast better load....
[18:42] <seb128> xnox, that undef symbol looks wrong in any case
[18:42] <xnox> seb128: well on my desktop i get:
[18:42] <xnox> OpenGL vendor string: Intel Open Source Technology Center
[18:42] <xnox> OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Desktop x86/MMX/SSE2
[18:42] <xnox> (among the rest of the stuff glxinfo prints)
[18:42] <seb128> $ ldd -r /usr/lib/i386-linux-gnu/dri/swrast_dri.so
[18:42] <seb128> ..
[18:42] <xnox> seb128: and on headless systems I used to get "Gallium 3D vendor" now I get nothing.
[18:42] <seb128> undefined symbol: _glapi_tls_Dispatch	(/usr/lib/i386-linux-gnu/dri/swrast_dri.so)
[18:42] <seb128> etc
[18:43] <seb128> xnox, seems like the software rendering backend is having issues
[18:44] <xnox> seb128: here is full, working pastebin from my computer http://paste.ubuntu.com/6793108/
[18:44] <seb128> xnox, right, that has hardware support
[18:46] <seb128> though "LIBGL_ALWAYS_SOFTWARE=1 glxinfo" works on my desktop
[18:48] <xnox> seb128: mlankhorst: tjaalton: actually nevermind me it does work after all.
[18:49] <kees> doko: why was debian bug 27363 re-opened? I added --with autoreconf and a dep on dh-autoreconf. what is missing?
[18:50] <kees> sorry, debian bug 727363
[18:52] <cjwatson> that looks like a mistake - it builds just fine on ppc64el
[18:53] <kees> okay, cool
[18:53] <cjwatson> I think doko was mass-operating on all those bugs and hadn't noticed that that one had already been fixed in the more comprehensive way
[18:54] <kees> yeah, that's what I suspected, but I wanted to double-check. thanks!
[20:00] <Noskcaj> Could someone help me fix an FTBFS in xchat-gnome? just get https://code.launchpad.net/~noskcaj/ubuntu/trusty/xchat-gnome/merge and build it
[20:01] <Noskcaj> doko, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727373 can be closed, ppc64el builds fine
[20:01] <Noskcaj> and i'm doing the merge now
[20:06] <Ampelbein> Noskcaj: What failure do you get?
[20:06] <Ampelbein> (with xchat-gnome)
[20:07] <Noskcaj> Ampelbein, just let me re-branch it. It's been a few days since i worked on it
[20:12] <hallyn> infinity: mdeslaur is asking about qemu in trusty's ftbfs on powerpc.  have you had any luck there?  or should we just dump the aarch64 patchset?
[20:14] <infinity> hallyn: I was sick all weekend and yesterday, haven't had a chance to look at all.
[20:15] <hallyn> infinity: ok;  i'm out today;  maybe i can use a qemu-ppc to try the build tomorrow :)
[20:16] <hallyn> mdeslaur: so if you need the debdiff reverted to have it build please do so;  i'll then push when we figure out what went wrong
[20:16] <infinity> hallyn: I shouldn't think you'd need a PPC machine to build on.  I imagine if you build that ppc64-softmmu target on *any* arch, it will fail the same.
[20:17] <infinity> THough maybe not.  Hrm.
[20:18] <infinity> No, okay, that gets built on x86 and works.  That makes this so much more confusing.
[20:19] <hallyn> infinity: all right well maybe it'll be obvious to me once i take a closer look tomorrow.  thanks, get better!  /me out
[20:22] <Noskcaj> Ampelbein, http://paste.ubuntu.com/6793607/
[20:27] <Ampelbein> Noskcaj: gnome-doc-utils.make is missing, are you running autogen.sh ? That should call gnome-doc-prepare and create it.
[20:29] <Ampelbein> Noskcaj: Just checked out the branch (unrelated: What switch can I use to tell bzr that I only want to checkout the files at current state, not the entire history?).
[20:30] <Ampelbein> Noskcaj: I'd do it like in debian, with DEB_CONFIGURE_SCRIPT := ./autogen.sh
[20:31] <Noskcaj> I'll test that now
[20:32] <tarpman> Ampelbein: are you looking for 'bzr checkout --lightweight'?
[20:35] <Noskcaj> Ampelbein, The error still appears
[20:35] <Ampelbein> tarpman: Well, basically the equivalent of git clone --depth=!
[20:35] <Ampelbein> *depth=1
[20:38] <Ampelbein> Noskcaj: mc
[20:38] <Ampelbein> ups
[20:39] <Noskcaj> ?
[20:39] <Ampelbein> clumsy fingers.
[20:45] <Ampelbein> Noskcaj: http://paste.debian.net/77688/ makes it build.
[20:45] <Ampelbein> You probably still had autoreconf.mk in your rules file.
[20:45] <Noskcaj> yeah
[20:47] <Noskcaj> Can i drop the autoreconf build dep then?
[20:47] <Ampelbein> No, it still gets run.
[20:48] <Noskcaj> ok. thanks. I'll just test build it myself then propose the merge
[21:38] <Logan_> how can I add extra usertags with submittodebian? (cc doko)
[21:47] <doko> Logan_, I didn't check, sorry. never used that
[21:47] <Logan_> hmm, alright
[21:47] <Logan_> I might have to tag retroactively for every bug :/
[22:05] <doko> Logan_, see my email, you can do this with a single email to control@bugs.debian.org
[22:05] <Logan_> okay, I'll do that
[22:24] <Noskcaj> Can someone please sync xfce4-weather-plugin from debian stable to precise? it would fix bug 1244629
[22:24] <Noskcaj> which is making it unusable
[22:24] <Logan_> Un momento.
[22:24] <Logan_> Oh, precise?
[22:25] <Noskcaj> yeah
[22:25] <Logan_> You didn't subscribe ~ubuntu-sru.
[22:25] <Logan_> Er. Hold up. There was already an SRU upload?
[22:26] <Noskcaj> no, and no
[22:26] <Logan_> http://launchpadlibrarian.net/162524610/xfce4-weather-plugin_0.7.4-3ubuntu1_source.changes
[22:26] <Noskcaj> i've just subscribed SRU
[22:26] <Logan_> It hasn't been approved yet.
[22:26] <Noskcaj> and it shouldn't be approved. It's broken
[22:26] <Logan_> Oh.
[22:27] <infinity> Broken how?
[22:27] <Noskcaj> which is why i was waiting for -5 to ask
[22:27] <Noskcaj> https://bugs.launchpad.net/ubuntu/precise/+source/xfce4-weather-plugin/+bug/1244629/comments/23
[22:28] <infinity> Noskcaj: We're not going to sync a new upstream from Debian to precise.
[22:28] <Noskcaj> Not a new upstream. two new debian stable uploads
[22:28] <Noskcaj> although i can change that to one ubuntu upload if you'd prefer
[22:29] <infinity> Erm.  0.7.4-3 in precise, versus.  Oh, I see, you mean from wheezy.
[22:30] <infinity> I misread.
[22:30] <Noskcaj> :)
[22:31] <infinity> We, we *could* sync that, though it wouldn't have the LP bug reference in it, which makes it a bit harder to track.
[22:31] <infinity> If someone's willing to verify the SRU as soon as it's built, I wouldn't be against just syncing it.  I just wouldn't want it to get lost/forgotten in proposed forever.
[22:31] <infinity> Noskcaj: Would you be okay with doing a verification pretty much immediately?
[22:32] <Noskcaj> we've got a fair few affected users. We'll find people
[22:32] <Logan_> shouldn't we get rid of the current one in the queue first?
[22:32] <Noskcaj> I think some of the other xubuntu devs have a precise machine
[22:32] <Noskcaj> Logan_, yes
[22:32] <infinity> Logan_: This would supersede that, so meh.
[22:32] <infinity> But I can reject it right now.
[22:32] <Logan_> sweet
[22:35] <infinity> LP hasn't picked up the new wheezy upload yet, so couldn't sync it even if I wanted to.
[22:36] <Noskcaj> ok, let me know when it does and i'll find some people to test