#ubuntu-release 2010-05-31
<pitti> Good morning
 * pitti re-enables cron jobs, the uninstallabilities from last email report should all be gone now
<pitti> ok, needs livecd-base first, which needs the linux kernel NEWed first, doing that now
<pitti> cjwatson: sorry for the initial d-i FTBFS spam (NEWed kernel wasn't published yet), it's building now
<ara> pitti, ping
<pitti> hey ara, good morning!
<ara> pitti, morning :-)
<ara> pitti, quick question, for alpha-1, are we releasing only ubuntu alt?
<pitti> ara: I don't know yet; I'm waiting for the publisher to get d-i updated, then I'll build a first set of images and see what breaks
<ara> pitti, OK, thanks. Please, keep me posted :-)
<pitti> ara: if they build and work, I think we should release desktops, too; they're great for testing on various hw, etc.
<ara> pitti, what about other flavours?
<pitti> I expect at least Kubuntu, not sure about the others
<pitti> (and server)
<ara> pitti, OK, thanks!
<pitti> I guess we'll build them all, post them to the tracker, and see what sticks?
<pitti> is that ok with you?
<ara> pitti, sure, if they build... :)
<pitti> ah, live cd base finally built
 * pitti boldly starts an ubuntu live build
<pitti> meh, failed with an empty log
<pitti> cjwatson: do you know why http://cdimage.ubuntu.com/daily/20100531.1/source/ also has a lucid-src?
<pitti> ok, missioncontrol uninstallability sorted out
<pitti> but what I don't understand is why the daily ubuntu and server .isos don't show up, just their reports.html
<pitti> cjwatson: FTR, all "Release minus 6 days" stuff should be done now, except the marketing team bit
<pitti> so, I fixed the seeds for the -5 kernel, but that shouldn't stop cron.daily from building at least a broken iso, or does it?
<pitti> ah, seems it does, sorry
<pitti> debian-installer has kernel ABI 2.6.34-5-generic, but no corresponding udebs are on the CD!
<pitti> make: *** [/srv/cdimage.ubuntu.com/scratch/ubuntu/daily/tmp/maverick-amd64/bootable-stamp] Error 1
<pitti> http://cdimage.ubuntu.com/daily/20100531.2/ for your testing pleasure
<pitti> ara: ^FYI
 * pitti rsyncs and does a smoketest first
<ara> pitti, thanks
<pitti> ara: I grab the amd64 one, just to see how far we'll get with a default install
<ara> pitti, OK, I'll do the i386 one
<pitti> ttx: FYI, http://cdimage.ubuntu.com/ubuntu-server/daily/20100531.1/ is the first maverick server build ever; mind doing a quick smoketest? (or delegating to someone :) )
<pitti> I don't know why lucid images are there as well
<pitti> ara, all: http://cdimage.ubuntu.com/daily-live/20100531/ good for first smoketest (beware, oversized)
<ara> pitti, OK, thanks. I will start syncing
<pitti> I'll drop langpacks for tomorrow's daily
<pitti> Riddell: http://cdimage.ubuntu.com/kubuntu/daily/20100531/ -> for first smoketest
<pitti> building kubuntu desktop now
<ttx> pitti: sure
<ara> pitti, alt i386 installs correctly and reboots correctly (spanish; no-network)
<pitti> ara: thanks; desktop doesn't start for me, hangs forever on usplash; will have a look after lunch
<ara> pitti, same thing here (i386)
<ttx> pitti: anything special to explain the suddenly oversized CD ? Looking at the package list I don't see anything that would explain +30Mb
 * ttx will dig deeper when the ISO will be downloaded
<pitti> ara: ah, booting without splash/quiet reveals it: kernel oops in aufs
 * pitti files bug
<ara> pitti, cool, thanks
<ttx> pitti: tracked sudden size inflation it down to pool/main/l/linux/linux-image-2.6.34-5-virtual_2.6.34-5.12_amd64.deb
<ttx> 12110 -r--r--r--  4 root root 12399730 2010-04-16 16:05 pool/main/l/linux/linux-image-2.6.32-21-virtual_2.6.32-21.32_amd64.deb
<ttx> 31782 -r--r--r-- 2 root root 32544062 2010-05-31 08:05 pool/main/l/linux/linux-image-2.6.34-5-virtual_2.6.34-5.12_amd64.deb
<ttx> it's no longer a leaner kernel :)
<pitti> ara_: filed as bug 587888 FYI, for the kernel team's enjoyment
<ubot4> Launchpad bug 587888 in linux (Ubuntu Maverick) (and 1 other project) "aufs oops in au_do_open() on maverick live system boot (affects: 1) (heat: 6)" [Critical,Triaged] https://launchpad.net/bugs/587888
 * pitti waves to apw
<ttx> pitti: filed bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/587893
<ubot4> Launchpad bug 587893 in linux (Ubuntu) "linux-image-2.6.34-5-virtual is oversized, results in oversized server ISO (affects: 1)" [Undecided,New]
<ttx> pitti: is an oversized CD a blocker for alpha1 ?
<pitti> ttx: well, not a really critical one, but this seems easy to fix
<pitti> looks like a bad dependency in a metapackage somewhere?
<pitti> ttx: oh, misunderstood you -- I thought you used ls on the CD pool/ to show that the CD now ships two kernels (lucid and maverick)
<ttx> pitti: no, it's just the -virtual kernel that more than doubled in size
<ttx> it may or may not be simple
<pitti> right
<ttx> pitti: I'll talk to john about it tomorrow, but if you want it fixed you should also mark it against alpha1
<pitti> ttx: is there something else we could temporarily take off the CD?
<ttx> nothing easy that would spare us ~20Mb.
<doko> ubuntu-archive: please accept llvm-2.7 in NEW
<ttx> pitti: server CD mostly in good shape, spotted a syntax error when logging in
<pitti> ttx: not bad for the very first maverick image ever
<ttx> some bash-completion issue, will file bug
<ttx> ev: bug 587910
<ubot4> Launchpad bug 587910 in bash-completion (Ubuntu) "[maverick] Syntax error in bash-completion.d/apt prints ugly messages at every login (affects: 1)" [Undecided,New] https://launchpad.net/bugs/587910
<ScottK> cjwatson: Around?
<ogra> pitti, please skip arm images for A1 (or even dailies) we're re-rolling the build scripts for omap between A1 and A2
<pitti> ogra: right, they have a horrible list of uninstallability anyway
<ogra> oh ?
 * ogra doesnt see anything image relevant on the ftbfs list
<ogra> hmm, but i also dont see any ubuntu-netbook build logs for maverick
<pitti> ogra: http://people.canonical.com/~ubuntu-archive/testing/maverick_probs.html
<pitti> ogra: although most of it should just be Kubuntu due to a very low-level package (qt?)
<ogra> right
<ogra> there is nothing on the list that would prevent the armel netbook image on a quick look
<ogra> (no armel under netbook-meta)
<ScottK> qt4-x11 just got fixed on armel, so KDE should be buildable now, it's just a question of how long it will take.
<ScottK> Speaking of which, pitti: would you please rescore phonon on armel?
<pitti> ScottK: done
<ScottK> pitti: Thanks.
 * ScottK is going to see how far he can get on getting the stack built....
#ubuntu-release 2010-06-01
<pitti> Good morning
<ara> good morning
<pitti> hey ara, good morning
<ara> pitti, when do we expect to have the first images in the tracker?
<pitti> ara: in about 15 minutes, I think
<pitti> I'm currently building all alternates/servers
<ara> pitti, nice :-)
<pitti> and I prepared the tracker for maverick a1
<ara> pitti, yes, I saw that ;-)
<pitti> we won't have desktops due to bug 587888
<ubot4> Launchpad bug 587888 in linux (Ubuntu Maverick) (and 1 other project) "aufs oops in au_do_open() on maverick live system boot (affects: 1) (heat: 6)" [Critical,Triaged] https://launchpad.net/bugs/587888
<ara> pitti, that's the one we hit yesterday, isn't it?
<pitti> right
<ara> "It's not the end of the world if we release alpha-1 without desktop images" :D
<pitti> ScottK, Riddell: I suppose http://people.canonical.com/~ubuntu-archive/livefs-build-logs/maverick/kubuntu/20100601/livecd-20100601-i386.out will hit alternate installs as well?
<pitti> seems this needs a kdeplasma-addons rebuild against libqalculate5
<pitti> ok, so kdeplasma-addons failed on libmarble-dev, which needs kdeedu to build, which again needs glew in main
<pitti> I re-promoted glew, it was in main until jaunty
<pitti> but it also needs avogadro in main
<pitti> filed as bug 588150
<ubot4> Launchpad bug 588150 in kdeedu (Ubuntu Maverick) (and 1 other project) "build-depends on avogadro, which is in universe (affects: 1)" [High,New] https://launchpad.net/bugs/588150
<pitti> ara: ok, added some images to the tracker now
<ara> pitti, OK, thanks, I'll sync now
<pitti> kubuntu alternate still building, but it'll be uninstallable anyway
<ara> pitti, :)
<pitti> ah, it just finished building, too
<pitti> I fixed the xubuntu oversizedness in the seeds, next build shold be okay
<pitti> Riddell, ScottK ^ same for kubuntu, I dropped pt
<pitti> I reported two RC bugs for the Kubuntu issues now
<ara> pitti, any reason why "rescue mode" now is called "alternative desktop environments" in the menu?
<ara> pitti, or is it a bug?
<pitti> ara: that doesn't sound related at all
<ara> pitti, ok, I'll ask ev and file a bug
<pitti> thanks
<ara> my installation of ubuntu alternate i386 in my mini9 is taking ages...
<pitti> on ext4? soudns like the dpkg performance regression?
<ara> pitti, yes, ext4 (full disk, no manual partitioning)
<ara> pitti, is there a bug number for that?
<pitti> ara: bug 570805
<ubot4> Launchpad bug 570805 in dpkg (Ubuntu Lucid) (and 3 other projects) "[regression] dpkg fsync cause massive regression in Ubuntu Server and Alternate installation times (affects: 11) (dups: 1) (heat: 86)" [High,Triaged] https://launchpad.net/bugs/570805
<ara> pitti, it has to be, because it is taking very very long
<pitti> seb128, Riddell: I prepared https://wiki.ubuntu.com/MaverickMeerkat/TechnicalOverview for alpha-1; if you have something to mention for GNOME/KDE, please do
<pitti> I'll add the "known bugs" based on the iso tracker feedback
 * Riddell removes kdebase-plasma from kubuntu seed
<Riddell> looks like kdeplasma-addons needs a recompile for that qalculate issue
<pitti> hey Riddell, good morning
<pitti> Riddell: kdeplasma-addons is FTBFS on too old libmarble-dev (kdeedu), which is dep-wait on avogadro -> bug 588150
<ubot4> Launchpad bug 588150 in kdeedu (Ubuntu Maverick) (and 1 other project) "build-depends on avogadro, which is in universe (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/588150
<pitti> Riddell: but seems the libqualculate4 rdepends is plasma-widgets-addons
<pitti> (for unseeding?)
<Riddell> unseeding would be the quick workaround
<pitti> if it's working without, sure
<Riddell> doing
<pitti> Riddell: so this would also work around bug 588163 at the same time, as it seems?
<ubot4> Launchpad bug 588163 in kdebase (Ubuntu Maverick) (and 1 other project) "kdebase-plasma and plasma-widget-folderview depend and conflict on each other (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/588163
<Riddell> kdebase-plasma is obsolete, I removed it already from the seed
<pitti> ah, good, so 588163 can be closed with a kubuntu-meta rebuild
<Riddell> kubuntu-meta 1.176 uploaded
<pitti> Riddell: thanks; buildds are clogged, so won't make this publisher run, I'm afraid; but we aren't under high pressure yet
<cjwatson> pitti: cdimage carries over images from the previous build, but it doesn't know to get rid of the images from the previous release cycle when we s/lucid/maverick/g - I'm going through and cleaning up the stale lucid-* images now
<pitti> cjwatson: is that a configuration change, or just rm in www.full?
<cjwatson> I'm going through with rm
<pitti> ah, good to know for next time, tanks
<pitti> "thanks"
<cjwatson> done
<cjwatson> pitti: aufs: tempting to reintroduce unionfs-fuse temporarily ...
<pitti> cjwatson: how much effort would that be?
<cjwatson> some
<cjwatson> hopefully: re-promote unionfs-fuse temporarily, and re-seed it
<cjwatson> of course we don't know for sure that it still works
<cjwatson> but it hasn't changed since karmic
<pitti> it can hardly get any worse
<pitti> but don't we also need to change casper for it?
<ogra> i think it has the code still
<cjwatson> yes, I left it there as a fallback
<cjwatson> precisely in anticipation of this kind of problem :-)
<pitti> cjwatson: ah, so if it's there, it uses and prefers it?
<cjwatson> oh, actually, only if aufs *isn't* there
<cjwatson> so we'd have to add union=unionfs-fuse as a kernel argument too
<pitti> ok, kubuntu-meta is published, I build a new kubuntu alternate to verify that it's installable now
<pitti> I'll rebuild the rest (xubuntu etc.) once new d-i lands; new xubuntu will fix the oversizedness
<pitti> cjwatson: ok, want me to give this unionfs a try, or are you on it already? that'd go into platform/live-common?
<pitti> oh, and needs a cdimage change for the kernel argument
<pitti> http://cdimage.ubuntu.com/kubuntu/daily/20100601.2/report.html \o/ -> empty
<pitti> ara, Riddell: kubuntu alternates posted to tracker for smoketesting
<ara> pitti, ok, thanks!
<cjwatson> pitti: I'm not on it just now
<cjwatson> live-common seems plausible
<pitti> cjwatson: does that also need a publisher run? (I guess not, doesn't sound like a task)
<cjwatson> it will do, it's incorporated into the live task
<cjwatson> well, all the live tasks
<cjwatson> so it'll need two publisher runs
<pitti> ah, ok
<pitti> committed, I'll verify the Tasks: headers in two hours then and attempt a build
<pitti> cjwatson: does that go to KERNEL_PARAMS in CONF.sh or debian/CONF.sh?
<pitti> ah, not debian/, that's old
<cjwatson> no no not KERNEL_PARAMS
<cjwatson> let me do it :) it goes in the tools/boot stuff
<pitti> ok, thank you
<apw> cjwatson, pitti, is there an aufs issue?
<pitti> apw: yes, see bug 587888
<ubot4> Launchpad bug 587888 in linux (Ubuntu Maverick) (and 1 other project) "aufs oops in au_do_open() on maverick live system boot (affects: 2) (heat: 12)" [Critical,Triaged] https://launchpad.net/bugs/587888
<apw> pitti, oh was the first CD yesterday then
<apw> pitti, do you have a recipe for what casper does when it mounts ?
 * pitti RTFS
<pitti> mount -t aufs -o noatime,dirs=/cow=rw:/rofs:rr aufs "$rootmnt"
<pitti> apw: ^ something liek that
<pitti> for the record, rebuilding xubuntu to fix oversizedness
<charlie-tca> Thanks
<pitti> charlie-tca: I unseeded some langpacks earlier on, but wanted to wait for the new d-i
<pitti> ara: did you already invest a lot in ubuntu alternates?
<charlie-tca> no problem
<pitti> ara: your "rescue mode" bug got fixed, but would need a respin
<pitti> not that bugs of this magnitude would matter much right now
<pitti> charlie-tca: http://cdimage.ubuntu.com/xubuntu/daily/20100601.1/
<pitti> added to tracker now
<charlie-tca> thank you. downloading
<charlie-tca> well, rsyncing, anyway
<ara> pitti, so, are we respining?
<pitti> ara: did anything else turn up in testing so far which we need to fix?
<ara> pitti, not really, only minor issues, update-notifier shows the systray icon, i.e.
<pitti> ara: I think we'll respin in any case; if we don't have other bugs (ugh, how unusal), then "because we can" :)
<pitti> ara: nice
<pitti> ara: we'll still try to build desktops, but that'll still take ~ 3 hours
<ara> pitti, OK
<mvo> for the record, update-notifier with fix is uploaded
<apw> Pitti, is there an easy way to make a squashfs filesystem
<pitti> apw: certainly, but why not just take the one from the CD?
<apw> pitti, DOH
<apw> pitti, cause i am terminally stupid
<pitti> apw: the magic runes are in the livecd-rootfs package, FYI
<pitti> in case you want to play with a very small one
<pitti> apw: does it work with two normal directories?
<pitti> apw: i. e. does it only crash on aufs-on-squashfs, not on aufs-on-dirs?
<apw> pitti, well i just tested with two local directories and its ok there
<pitti> (or aufs-on-loop or whatnot)
<apw> hense my question :)
<pitti> ah, ok
<pitti> apw: perhaps the ubuntu squashfs has exactly the wrong combination of bits then? :-/
<apw> aufs                  75210728   3580784  67809464   6% /root/ROOT
<apw> so now i want to swap in the right sorts of FS and see if that changes things
<apw> i have an update for aufs which i want to test, but i need to reproduce first
<pitti> apw: mksquashfs /tmp/mychroot/ /tmp/img.squashfs -sort filelist
<pitti> apw: so, doesn't seem to be rocket science either, in case you need it
<apw> sounds good
<apw> pitti, ok so i can mount a squashfs foo under an ext4 filesystem ok
<apw> whats the top layer
<apw> tmpfs ?
<pitti> I suppose
<pitti> apw: do you get the crash as well if you boot that ubuntu CD?
<apw> hrm ...
<apw> pitti, you arn't the only person who has reported the disk as bad
<apw> and an aufs2 crash into the bargain
<pitti> apw: happened to ara, too
<apw> so i am sure its real, just not managing to get it to pop yet
<apw> /dev/loop0                 128       128         0 100% /root/RO
<apw> tmpfs                  1021280        20   1021260   1% /root/RW
<apw> aufs                   1021280        20   1021260   1% /root/ROOT
 * pitti -> TB meeting
<charlie-tca> xubuntu appears to have three panel applets flashing in the middle of the desktop now. jockey, gnome-volume-control, and network-manager. They are icon sized windows that won't quit flashing over and over
<Riddell> well Kubuntu installs but then boot doesn't get past plymouth (in virtualbox)
<pitti> cjwatson, Riddell: I need to leave in ~ 10 minutes (sorry, working on early hours this week, will be back to normal next week)
<pitti> cjwatson: unionfs-fuse seems to have Task: ubuntu-live, edubuntu-dvd-live now, but not yet Kubuntu
<pitti> can someone please trigger desktop builds later on, and check if they now work with unionfs-fuse?
<cjwatson> that's odd, they should be simultaneous
<cjwatson> hm, kubuntu live doesn't have the right Task-Seeds.  Let me check the effects of fixing that
<cjwatson> fixed in kubuntu, but I'll check the other derivatives too
<ara> pitti, so, the respin is happening tomorrow, I guess
<cjwatson> we can do Ubuntu today - I'll take care of that
<cjwatson> just waiting for a baseline image to finish downloading here
<apw> pitti, is there a trivial way to inject a new kernel into an iso image?
<apw> pitti, this is on a writable media obviously
<cjwatson> is it ABI-compatible with the one you're replacing?
<cjwatson> if so, overwrite /casper/vmlinuz
<apw> cjwatson, it is abi numbered the same, though its the modules i am moding
<apw> am trying a kernel-replacement now
<apw> but remaking the initrd is prooving painfully slow
<ogra> apw, use a chroot (with casper installed in it)
<ogra> for mount testing that should suffice
<apw> ogra, well i need it to do the testing as it works perfectly in any testing i do
<ogra> right, create a chroot, install casper inside and there install your test .deb and run update-initramfs ... then replace the initramfs and vmlinuz in the image
<apw> ogra, so where will it make the casperiszed initramfs's ?
<ogra> in 7boot inside the chroot
<ogra> */boot
<apw> making the normal ones unbootable (normally) or making additional ones
<ogra> *inside* the chroot
<ogra> it doesnt write to your /boot if you are chrooted
<apw> ogra, yeah, but if i installed it outside a chroot, it would eat my real initramfs ?
<ogra> it doesnt do any harm
<apw> just working out how it works, in my head
<ogra> boot=casper is needed to actually tell init to use casper
<ogra> else you just bloat the initrd
<ogra> with the casper scripts
<apw> ah
<apw> then i can just install casper on this test box then
<apw> as i can live with a bit of bloat on there
<ogra> indeed
<apw> more than i can be bothered to make a new initrd
<apw> chroot even
<apw> cjwatson, pitti, ok it looks like an aufs update could well sort out the CD booting ... did you switch over to fuse already?
<cjwatson> yes (pending rebuilds), but it's easy to revert that
<cjwatson> I'd rather stick with aufs if it's easy
<apw> cjwatson, i am currently booted off of of my kernel with the aufs update, boy was it a bugger to get in there, but it seems to be booted ok on an amd64, which was showing the panics before
<apw> cjwatson, the problem is a kernel respin takes about 14 hours these days
<cjwatson> it's not a major deal if a1 is a bit late
<apw> cjwatson, ok i'll get the patches out to our list and let ogasawara know etc etc
<pitti> re
<cjwatson> I think I'd rather have slightly late with aufs than on time with unionfs-fuse
<apw> ok
<pitti> apw: you can also break in casper's initramfs and insmod it manually; I think I did something similar in the past in a similar case
<cjwatson> we can leave unionfs-fuse in there for the time being as insurance in case it breaks, and remove that after a1
<pitti> apw: 14 hours on i386/amd64 as well? we don't care about armel for a1 yet
<apw> pitti, no they are more like 5
<pitti> cjwatson: right, now we can just toggle in cdimage, no seed/task changes necessary, right?
<pitti> cjwatson: so we could even switch (for testing) on one and the same iso
<apw> if you can do that, then i think its very easy for me to offer up these patches
<apw> as if they don't work we're no worse off and still can say 'use fuse dude' and it'll work ... if i am understanding you
<cjwatson> yes, in fact er cough I think I forgot to make the cdimage change before respinning
<cjwatson> too many distractions
<cjwatson> I'll not bother now then :-)
<ogra> apw, you shuld know that nobody uploaded any omap kernel yet :) so armel is out of the question
<pitti> apw: *nod*
<apw> ogra, you sure?  i thought that omap3 was standard in our main kernel now, and indeed why it takes so long to build
<ogra> apw, oh, i wasnt aware
 * ogra checks binaries
<ogra> i was looking for omap3 uploads
<ogra> apw, heh, indeed !
<apw> there should be an omap flavour
<ogra> yeah
<ogra> i wonder if it works on the XM and zoom2
<ogra> anyway, dinner time
<pitti> apw: so if that kernel won't change anything else, it wouldn't need an ABI bump, right? otherwise we'll have to change a ton of other stuf
<pitti> f
<apw> pitti, indeed, i built it here without a bump and noone would use the interfaces it might change anyhow, they are aufs interfaces so a forced not-bump would likely be appropriate anyhow
<pitti> cjwatson, apw: so, sounds great to me; I'll get up early tomorrow again (0430 UTC) and can start wrestling and testing early
<apw> pitti, that sounds awful
<pitti> apw: if you can tell me the version of the package upload, I can set up a trigger on cdimage to build live images once that kernel hits
<apw> pitti, ok i expect it would be the just an increment of the upload number
<apw> will need to confirm with ogasawara
<ogasawara> apw: yah, lets mumble after our irc meeting and get everything coordinated
<apw> ogasawara, ack
<pitti> apw: 2.6.32-22.34 ?
<apw> pitti, this would be a 2.6.34 kernel
<pitti> erk, of course
<cjwatson> there's an error inserting ramzswap that shows up briefly while booting the live CD, too
<cjwatson> is that known broken
<cjwatson> ?
<cjwatson> trying to boot with union=unionfs-fuse at the moment to confirm the fallback option
<pitti> apw: 2.6.34-5.13 I mean
<apw> cjwatson, i wonder if thats cause we have both now in .34
<apw> pitti, that looks right to me
<cjwatson> hmm, "unknown parameter `disksize_kb'"
<cjwatson> maybe the interface changed
<cjwatson> in which case it's probably appropriate to lob in a casper fix
<cjwatson> or initramfs-tools or wherever it is that lives
<apw> cjwatson, i think there was an interface change coming, i think we knew about it ... i seem to remember us updating it during lucid and you spotted the difference and we backed it out for lucid
<cjwatson> I don't remember that but brain like a thing with holes in
<lamont> ScottK: I'm curious now... have we actually hit any cases of builds taking too long where it _didn't_ come down to "excessively abusive use of lzma where it should not be" ?
<ScottK> lamont: I don't know of any that weren't lzma builds.
<pitti> cjwatson, apw: ok, I set a trigger for 2.6.34-5.13 which then builds all live CDs; if something bad happens, just kill the wait-for-package process on antimony
<pitti> since I need to leave now
<lamont> ScottK: I find I'm starting to lean towards "fix this when it's actually an issue" then.  or should some of the failing lzma builds not fail and still be lzma?
<ScottK> lamont: Can you do an ia64 test build for me if I give you a package?
<lamont> ScottK: sure
<ScottK> OK.  I'll continue fiddling.
<ScottK> The only place I've seen the timeouts is on armel and there space tends not to be an issue.
<ScottK> So in theory lzma should work there, but in practice it's just some added complexity in the packages to not do lzma on armel.
 * pitti waves goodbye now; please don't hesitate to call my mobile on any urgencies
<cjwatson> ramzswap change is non-trivial, requires pulling in a package with rzscontrol; I won't do that for a1
<ScottK> cjwatson: Please let me know when you have a few minutes free.  I still have my question for 'the release manager' from last Friday.
<cjwatson> ScottK: oh, sorry, I just reached the end of my day
<ScottK> cjwatson: No problem.  It's still not a rush.
<smoser> marjo, slangasek i would like data from http://uec-images.ubuntu.com/maverick/20100601/ uploaded to tracker
<marjo> smoser: ack
<marjo> smoser: hggdh will work with you on this request
<slangasek> smoser, marjo: I'll take care of it; quicker for me to do it with the script
<marjo> slangasek: ok, thx
<slangasek> smoser: is ap-southeast-1 meant to be posted to the tracker at this stage?
<smoser> slangasek, yes.
<smoser> sorry for failure to raise that.
<smoser> we will need those additional 4 entries (2 arch * 2 roots)
<slangasek> ok, let me get those in the db then :)
<slangasek> stgraber, marjo: has anything changed regarding the db setup of iso.qa that I'm not aware of?  My changes to the qatracker_testcase table on quandong aren't being reflected on the website
<slangasek> and indeed, Maverick Alpha 1 isn't in this db
<slangasek> iso.qa seems to point to cranberry, which I don't have access to, so I can't add the new Asia-Pacific EC2 products smoser needs
<elmo> slangasek: limequat
<elmo> it was the release day madness, not yet reversed
<slangasek> elmo: ah, thanks - can I assume that if and when it's reversed, you guys'll take care of the db migration?
<marjo> elmo: may i leave this issue in your capable hands?
<elmo> no, please don't
<elmo> I have no idea what to do with the DB
<elmo> but if slangasek had access to the DB for, he still does
<elmo> on limequat
<marjo> elmo: ack
<elmo> s/for/before/
<elmo> (if he doesn't/didn't, I can puppet for someone and/or give them access)
<slangasek> smoser, marjo, elmo: all done, Asia-Pacific is posted to the tracker
<smoser> thank you
<ogasawara> cjwatson, pitti, apw: just fyi, the 2.6.34-5.13 kernel with the aufs update is uploaded.  looks like the i386 build has already started and amd64 has an ETA of about and hour to begin building.
<cjwatson> thanks - I'm going to watch a film and I'll give things a poke later on
<apw> cjwatson, excellent thanks
<apw> ogasawara, fingers crossed :)
<lamont> slangasek: oh btw, I broke your armel/live machine until londontime tomorrow.  (needs a good powerstabbing)
<lamont> well, the /I/ in that is supposition on my part, but I fear I'm right.  unless you were hammering on the poor thing a little while ago
<slangasek> lamont: wasn't me
<lamont> well, that just makes it near certain it was me then
<lamont> :(
#ubuntu-release 2010-06-02
<stgraber> elmo: I don't seem to be able to connect to limequat (getting connection time out from both Canada and Germany). Could you make sure that I have access to whatever the host of the ISO tracker is ? (IIRC during the release madness it had to be moved and I lost access which should have either been restored on limequat or the website moved to quandong where I already have ssh access)
<stgraber> marjo: ^ FYI
<pitti> Good morning
<pitti> ah, so my trigger worked and all live CDs built
<pitti> argh, ubuntu/amd64 still has the old kernel
<pitti> I fixed the netbook oversizedness, will respin as well
<ScottK> pitti: It's very late here and I need to go pass out, but it looks like in the kubuntu-common seed kdebase-plasma recommends needs to be replaced with plasma-widget-folderview.  That should fix the latest Kubuntu Netbook ISO failure (and I suspect Kubuntu Desktop as well).
<pitti> ScottK: ah, I was just going to look at why kubuntu failed to build
<ScottK> If not, Riddell ^^^ could you have a look if pitti can't get to it?
<ScottK> Great.
<pitti> ScottK: oh, sure I can
<pitti> yes, that was the one we tried to get rid of yesterday
<ScottK> We need to totally drop that transitional package, but it can wait until after the milestone if we just get it unseeded.
<pitti> I'll change the seeds/rebuild/etc.
<pitti> ScottK: hm, I don't see kdebase-plasma any more in the seeds, anywhere
 * ScottK looks again
<pitti> but the -meta package still pulls it in
<pitti> might just need a rebuild?
<ScottK> pitti: Do the seeds lag on people.canonical.com?
 * pitti just looking at bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/kubuntu.maverick/
<pitti> ScottK: anyway, I'll track it down
<ScottK> OK.  On p.c.c it still shows in kubuntu-common.
<ScottK> Good night.
<pitti> ah, no, meta is ok; I was looking at lucid's
<pitti> ok, now I need to wait for the next publisher run to get the new amd64 kernel; back in an hour
<pitti> cjwatson: kdebase-plasma still has "Task: kubuntu-desktop, kubuntu-netbook", but it doesn't appear at all in lp:~ubuntu-core-dev/ubuntu-seeds/kubuntu.maverick, nor does it have any rdepends; any idea?
<ara> morning all!
<ara> pitti, morning
<ara> pitti, how is alpha 1 going? I guess we are respining, aren't we?
<pitti> hey ara
<pitti> ara: still waiting for the amd64 kernel to publish, then I can build desktop CDs
<pitti> my amd64 desktop test install (with unionfs-fuse) is almost done; I wanted to do a smoketest before
<ara> pitti, what about the alternates? I've seen in the tracker that they are yesterday's builds
<pitti> ara: not sure about them; they seem to work quite well
<ara> pitti, OK, nice :)
<pitti> ara: we can respin to grab the newer d-i to fix the rescue mode thing
<pitti> but otherwise I don't see major fixes for them, do you?
<ara> pitti, no, I don't. I think we can release note the rescue mode bug
<pitti> that's what I thought
<pitti> we should concentrate our efforts on testing the desktops, I think
<ara> I agree
<apw> pitti, did the kernels make it through onto cd images ok ?
<pitti> apw: i386 did, amd64 is just being published; apparently building it took a while
<pitti> or the buildds were clogged
<apw> hrm ... about 10 last night it was looking to be starting in 54 mins
<apw> (my time)
<pitti> i386 works and boots, and I verified that amd64 also works with unionfs-fuse
<pitti> apw: thanks so much for the quick fix!
<pitti> ah, and my amd64 test install with unionfs-fuse just succeeded \o/
<apw> pitti, was more luck than judgement, it was my first stab
<apw> pitti, the testing i did with my built kernel was aufs on am64, so that is likely to work if i386 does
<apw> but having both available rocks
<pitti> right
<pitti> amd64 should hit the mirrors any minute now
<apw> pitti, got a checksum for it so i can tell when i've got the right one
<apw> pitti, ahh the build took 7 hours, starting around midnight my time, would put it about when you said ... just slow builds
<pitti> there it is
 * pitti starts ubuntu xubuntu ubuntu-netbook desktop builds
 * apw resync's his CDs
<pitti> ttx: hm, seems that someone added the EC2 bits to the iso tracker; was that on purpose?
<pitti> http://cdimage.ubuntu.com/daily-live/20100602.2/
<pitti> ara, apw ^ there, go wild :)
 * pitti adds to tracker
<ttx> pitti: smoser must have pushed them since they were missing
<ttx> pitti: any reason why he shouldn't have ?
<ara> pitti, thanks! I wiill sync now
<pitti> ttx: no, I was just wondering; I didn't build anything for EC2 (nor do I know how :) )
<ttx> ara: any idea why we don't receive email notifications anymore ?
<ttx> pitti: we have daily builds for EC2/UEC images, and smoser/ara can promote one build as the milestone candidate
<apw> pitti, ara, can i rsync these images ?
<pitti> ttx: nice, thanks
<pitti> apw: sure
<ttx> pitti: http://uec-images.ubuntu.com/maverick/
<ttx> pitti,ara: we should also have a amd64/i386 UEC image candidate
<ttx> currently only the EC2 stuff shows up
<ttx> does any of you have the keys to promote http://uec-images.ubuntu.com/maverick/20100601/ as the UEC images ?
<pitti> ttx: if you are addressing me, I'm afraid I need some further docs; I never did that
<pitti> apw: maverick-desktop-amd64.iso boots fine here \o/
 * pitti hugs rsync and his phat pipe this week
 * apw cheers!
<pitti> DSL 16K is something I could get used to..
<ttx> I wonder if ara can do it
<ttx> It's just a question of having "Ubuntu Server UEC amd64 (20100601)" in the ISO tracker
<ara> ttx, I can
<ttx> (and i386)
 * ttx hugs ara
<ara> ttx, done
 * ara hugs ttx back
<pitti> meh, xubuntu still oversized; why do my seed changes have no effect?
<apw> pitti, yay, amd64 boots and even claims to be using aufs :)
<pitti> cjwatson: ok, seems the kdebase-plasma and the eternal xubuntu oversizedness (as well as netbook) are related: it seems that Tasks: headers just don't get updated, and there were plenty of publisher cycles with new maverick packages in between
<apw> ara, who owns the iso-tracker test definitions ?
<apw> ara, for example the live testing does not know about the 'burning man' and so there are now two paths that need testing there
<ara> apw, it is a wiki, anyone can edit
<ara> apw, http://testcases.qa.ubuntu.com/Install/
<apw> ara, is there a scheme for the Case ID: numbering ?
<ara> apw, just 3 letters + 3 numbers
<ara> apw, for installations, normally, the 3 letters are ins
<ara> apw, is it a new test case? or changing an existing one?
<apw> ok, so i can just use a free -nnn number, i assume existing ones should be left alone
<apw> as there is 'ignore the burning man' and 'hit a key during the burning man' i guess i need to add a new one
<apw> and fix the old one to mention the burning man
<apw> ara, any idea if it matters if the numbers are sequential, as it feels wrong to change the numbers of the existing ones, but the logical place for the new one is second
<ara> apw, they are sequential, place it in second place in the wiki, but call it ins-next_available
<apw> ara, perfect, that is the logical way to do it :)  phew
<ara> apw, :)
<apw> pitti, i note that at least the non-plymouth splash is still saying 10.04
<ara> Riddell, around?
<slangasek> there's a non-plymouth splash?
<pitti> well, plymouth text plugin, I suppose
<slangasek> ah yes, I suppose that 10.04 is hard-coded in the source
<cjwatson> pitti: oddly, kdebase-plasma is showing up as directly seeded in kubuntu-common, but clearly isn't there
<cjwatson> the germinate output is up to date
<pitti> cjwatson: is it possible that germinate crashes in the publisher on in the cronjob?
<pitti> cjwatson, slangasek: good morning
<cjwatson> pitti: it doesn't seem to be crashing, based on the logs
<slangasek> pitti: morning-ish :)
<cjwatson> that wa one thing I checked for
<cjwatson> *was
<cjwatson> no, the problem is that the seed update job has got stuck
<cjwatson> it runs as ubuntu-archive@people, and occasionally it gets stuck on a bzr lock or something for some reason
<cjwatson> I've fixed that now
<cjwatson> it'll need another publisher run and then some package or other flushed through a second publisher run
<cjwatson> that indeed accounts for your Xubuntu trouble as well
<cjwatson> actually, why don't I just run cron.germinate by hand to speed things up
<pitti> cjwatson: so I'll find a package to publish to maverick main in the meantime?
<cjwatson> doesn't need to be main
<cjwatson> just maverick somewhere
<pitti> hah, I've got the perfect one
 * pitti uploads postgresql-common
<pitti> cjwatson: next publisher in 20 mins will be ok? or the one after that?
<pitti> ready to upload
<cjwatson> will tell you in a minute
<pitti> if that fails, I also have an apport upload (also fast to build)
<pitti> fails> if we need another publisher, I mean
<cjwatson> pitti: go ahead and upload
<pitti> done
<pitti> cjwatson: ok, it's built and accepted
<pitti> thanks for sorting this out
<pitti> cjwatson: for checking in the future, is that bin/update-germinate on lillypilly?
<Riddell> ara: yes
<ara> Riddell, I was installing KVM OEM (alt) and on reboot it freezes the screen: just a white screen with the pointer and the notifications
<Riddell> OEM?  have you tested a normal install?
<ara> Riddell, no, just OEM
<Riddell> it's alpha 1, I care very little about OEM compared to it installing and booting at all
<ara> Riddell, I'll try again with normal installation and will get back to you
<pitti> seb128: do you see anything worth mentioning in the tech overview wrt. GNOME? new GNOME components, new evolution, etc?
<pitti> Riddell: likewise, any new KDE version to point out, etc?
<seb128> pitti, I guess you can mention new GNOME platform stack
<Riddell> yes, 4.5 beta
<seb128> ie updated glib with gsettings, gtk, dconf ready
<seb128> (it's in universe now)
<seb128> new evo stack
 * pitti removes the only "known issues" entry again (broken aufs)
<ara> a tester is reporting that when unlocking encrypted server installations, each time he presses a key, the "Unlocking message" gets repeated
<ara> http://img15.imageshack.us/gal.php?g=unencr2.png
<ara> what package should he file against?
<pitti> seb128, Riddell: I added some initial comments to https://wiki.ubuntu.com/MaverickMeerkat/TechnicalOverview, please refine as appropriate
<seb128> pitti, ok thanks
<cjwatson> pitti: update-seeds
<cjwatson> ara: probably cryptsetup to start with
<ara> cjwatson, thanks, it was reported back in Lucid, but it was wrongly assigned to plymouth
<ara> https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/566818
<ubot4> Launchpad bug 566818 in plymouth (Ubuntu) "[Lucid] cryptsetup passphrase prompt during boot: every character typed repeats the prompt (affects: 5) (dups: 1) (heat: 45)" [Medium,Confirmed]
<pitti> cjwatson: yay, Tasks are correct now
 * pitti turns crank to rebuild images
<ara> pitti, rebuilding? which images are we rebuilding?
<pitti> kubuntu kubuntu-netbook ubuntu-netbook xubuntu
<pitti> (desktops, not alternates)
<pitti> ubuntu desktop seems okay already
<ara> pitti, ah, ok, thanks
<pitti> ara: kubuntu didn't build at all so far, and netbook/xubuntu are still oversized due to outdated tasks
<ara> pitti, the "headlines" of conversations at #u-release are worth posting at #u-testing, so people testing can be aware of what's going on
<pitti> sure, /me joins
<pitti> ara: I gave a quick overview, and will post new images there as they appear
<ara> pitti, thanks :-)
<cjwatson> pitti: cool
<cjwatson> ara: I didn't say plymouth was definitely wrong
<cjwatson> ara: if somebody knowledgeable assigned it to plymouth, then that's probably a better target for it
 * Riddell cheers as Kubuntu Maverick installs and boots to desktop
<pitti> http://cdimage.ubuntu.com/ubuntu-netbook/daily-live/20100602.3/ up for testing
<pitti> ara: is there a bug for Kubuntu OEM?
<pitti> I have a luxury problem: I don't yet have anything to add to "known problems" section :)
<ara> pitti, no, I was waiting to see if it reproduces on normal installations
<ara> pitti, I will get back to you and Ridell when done
<pitti> ara: ok, thanks
<pitti> eww, current netbook in KVM boots into GNOME desktop
<ara> pitti, oops
<pitti> could just be kvm, I'll investigate and check with Didier
<ara> pitti, btw, in known issues you can add the "rescue mode" bug ;-)
<pitti> right :)
<pitti> ara: but it does work, right? it's just mislabeled
<pitti> ah, netbook/kvm works with -vga vmware
<pitti> http://cdimage.ubuntu.com/kubuntu-netbook/daily-live/20100602/ ready for testing, added to tracker
<pitti> Riddell: ^ crossing fingers :)
<pitti> this isn't shown as oversized, it has a larger limit?
<pitti> bbiab, booting netbook live system on my laptop
<ScottK> pitti: It does.
<ScottK> We went with the idea people would install from USB, so who cares about 700MB limit.
 * Riddell grabs kubuntu-netbook
<ScottK> pitti: If it wouldn't interfere with anything else, could you spin up a powerpc image for Kubuntu desktop?  I think I have both all the needed packages built and someone to test.
<pitti> re
<pitti> ScottK: sure, can do
<pitti> ScottK: I started powerpc powerpc+ps3 builds for kubuntu and then ubuntu
<ScottK> Thanks.
<pitti> argh, it ate my wiki edit
<pitti> Error: no livefs builds succeeded.
<pitti> ScottK: ^ hm, will have a look in a bit
<Riddell>  linux-powerpc: Depends: linux-image-powerpc (= 2.6.34.4.1) but it is not going to be installed
<pitti> LP is going offline in a few minutes
<pitti> http://cdimage.ubuntu.com/kubuntu/daily-live/20100602/ for your testing pleasure
<pitti> and xubuntu _still_ oversized; WTF?
<pitti> ah, it's still building
<pitti> http://cdimage.ubuntu.com/xubuntu/daily-live/20100602.3/ ready for testing
<pitti> lunch, bbl
<pitti> ScottK, Riddell: ah, kdebase-plasma is on NBS with 0 rdepends, so I'll remove it once LP is back up
<Riddell> ta
<apw> have we really planned a LP maintenance window in the two days before a milestone again?  surley this can be avoided
<Riddell> kubuntu netbook is a work of perfection, let's release 10.10 before we screw it up
<ogra> apw, to late :P
<ogra> (for avoidance that is)
<ogra> Riddell, make it run on ARM !
<apw> ogra, yeah i more meant, they have done this three milestones in a row, and its stupid
<ogra> agreed
<apw> they did it release week i think, wh
<ogra> seb128 just brought it up in another channel
<ara> pitti, do we have a bug number to une showing gnome desktop?
<pitti> ara: it wasn't real; it works fine with -vga vmware (2D) and on real iron (3D)
<pitti> kvm's default graphics is known-broken with netbook-launcher
<ara> pitti, I can reproduce in a mini9
<ara> it shows UNE desktop, but it ALSO shows the panel
<pitti> ara: ah, please file a bug then; it works just fine here
<ara> or is the panel now part of UNE?
<pitti> ara: yes, it's supposed to show the panel
<pitti> ara: it's always been
<pitti> we need the indicators, etc.
<pitti> it's just not supposed to show the applications menu
<ara> pitti, ah, OK. THen, it shows the Applications menu :-)
<ara> pitti, that was it was strange
<ara> it is showing the menu
<pitti> ara: I think it's the same error as why favourites are empty
<pitti> just talked about it with Didier
<pitti> didrocks | pitti: we also got the two panels and not the dedicated applets. Do you know what changed so that the postinst of ubuntu-netbook-default-settings doesn't seem  to have been executed? (I don't remember to add anything to casper about that)
<pitti> ara: it's bug 588675
<ubot4> Launchpad bug 588675 in ubuntu-netbook-default-settings (Ubuntu Maverick) (and 1 other project) "[Maverick Alpha-1] Empty favourites (affects: 1)" [Medium,New] https://launchpad.net/bugs/588675
<pitti> i. e. due to the same root cause
<pitti> not that we could update the bug right now.. :-(
<ara> pitti, I will put a comment in the tracker and I will try to remember to update the bug when lp is again writable
<pitti> cheers
 * pitti updates the "known issues"
<ara> Riddell, I get the same error in normal mode and OEM mode (white screen)
<ara> Riddell, it is a KVM, though
<ara> Riddell, any idea which package should I file the bug against?
<Riddell> ara: nothing else shown before?  linux? plymouth? X?
<ara> Riddell, X starts, but white screen and notifications
<ara> Riddell, let me pastebin the screenshot
<ara> Riddell, http://imagebin.org/99517
<Riddell> weirdness
<ara> plymouth appears correctly, kdm appears correctly and I log in correctly
<ara> and then, once it logs, that's what it shows
<Riddell> ara: can you do alt-f2 and start an application (e.g. konsole)?
<ara> Riddell, gggr, it does not allow me. Normally I would do Ctrl+alt+2 and then sendkey, but it is not working now
<ara> (kvm, I mean)
<pitti> oh, LP seems to be back?
<ara> Riddell, I will restart that virtual machine with virt-manager
<Riddell> ara: well I'd guess it's an issue either with plasma or kwin and both are in kdebase-workspace so that would be as good a place as any to report
<ara> Riddell, OK, thanks
<ScottK> pitti: Can we SRU a metapackage change?  This kdebase-plasma mess has caused me to notice we still have it seeded in lucid also.  I think it should be dropped in the seeds and the package that replaces it, plasma-widget-folderview, seeded directly.  I think it'd be good to have for 10.04.1.
<ScottK> cjwatson: ping a little earlier in the day this time.  Still not urgent, but when you have 5 minutes.
<pitti> ScottK: it would be a no-op for upgrades, right? sounds fine to me
<ScottK> pitti: At most it would be the transitional package is available for autoremoval.
<pitti> which sounds just fine
 * ScottK marks it on his TODO.
<cjwatson> ScottK: go ahead
<ScottK> cjwatson: I wanted to ask about getting special permission to respin Kubuntu Netbook for 10.04.1.
<cjwatson> I have no problem with respins for point releases as long as there are testing resources available
<ScottK> Great.
<cjwatson> from the RM side they're quite straightforward and if it goes wrong we can always not release the builds
<ScottK> I know we can do almost all of it out of community resources.  The one place I may need help is with wubi testing.
<ScottK> Because Kubuntu netbook is so close to Kubuntu desktop in package selection we'd otherwise end up in the position that the lowest bandwidth requirement install method for Netbook would be to install destkop and then convert it.
<ScottK> Thanks.
<cjwatson> nice to have easy questions. :-)
<ScottK> I didn't think it would be hard, just wanted to make sure to have the conversation early enough not to cause a rush.
<apw> ogra, hey was there a bug for that omap udebs not existing error?
<ogra> apw, not yet
<ara> is there a bug number for text version of plymouth having 10.04 hardcoded?
<cjwatson> bug 588633
<cjwatson> ara: ^-
<ubot4> Launchpad bug 588633 in plymouth (Ubuntu) "textual splash says 10.04 for maverick (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/588633
<ara> cjwatson, many thanks
<cjwatson> ara: if you notice that sort of thing, can you make sure that it's in the checklist of packages that need to be changed for each new release in https://wiki.ubuntu.com/NewReleaseCycleProcess?
<ara> cjwatson, sure, I didn't notice, but I was triaging some of the bugs filed in the tracker and I saw a duplicate
<ara> cjwatson, I'll add it to the list
<pitti> need to leave now
<pitti> cjwatson: I'm on vac tomorrow, can I pass the release baton to you now?
<cjwatson> pitti: yes, what needs to be done still?
<pitti> cjwatson: https://wiki.ubuntu.com/MaverickMeerkat/TechnicalOverview should reasonably up to date, and tracker is looking ok for now
<pitti> cjwatson: so basically all things up to "release day -1" onhttps://wiki.ubuntu.com/MilestoneProcess are done
<cjwatson> ok.  I've been keeping an eye on the tracker but there doesn't seem to be any showstoppers
<pitti> cjwatson: so what's left is the publishing, announcement text, and what's probably most difficult, finding a nice quote for the announcement :)
<pitti> cjwatson: right, I think it's well under control now, and the images are good
<pitti> took a while, sorry for bothering you with all those questions
<slangasek> pitti: acquire a copy of John McCain's autobiography and take a quote from it
<cjwatson> sounds like you've done most of it, so don't apologise
<pitti> slangasek: heh
<ogra> apw, https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/588805 for you
<ubot4> Launchpad bug 588805 in linux (Ubuntu) "no udebs for omap flavour in maverick (affects: 1) (heat: 6)" [Undecided,New]
<bjf> on maverick (an upgrade from lucid) I just tried to "sudo apt-get install mplayer" and got: "mplayer: Depends: libdirectfb-1.2-0 but it is not going to be installed"
<bjf> what's the right thing to do here?
<Riddell> bjf: upload mplayer to compile against the new libdirectfb version or file a bug requesting the same
<bjf> Riddell, since I don't know how to upload an mplayer to comiple against the new libdirectfb, i'll file a bug
<bjf> Riddell, thanks
<Riddell> all Kubuntu images are good to go for me
<ogasawara> cjwatson: not sure you're the right person to ask but ... I've got a kernel fix to resolve bug 587893
<ubot4> Launchpad bug 587893 in linux (Ubuntu Maverick) (and 1 other project) "linux-image-2.6.34-5-virtual is oversized, results in oversized server ISO (affects: 1) (heat: 8)" [High,In progress] https://launchpad.net/bugs/587893
<ogasawara> cjwatson: would uploading a new kernel for this type of fix qualify for violating the alpha1 soft freeze?
<cjwatson> ogasawara: Thanks for the fix.  I think we can probably afford to just stage that for immediately after alpha-1, and release-note the problem.  For a later alpha I'd probably say differently but I don't think an oversized server image on the first alpha is worth the hassle of a respin
<ogasawara> cjwatson: ack
#ubuntu-release 2010-06-03
<ScottK> cjwatson: We had an unexpected upload of kdegames which will make kubuntu-netbook slightly out of date.  Also, I'd say, not worth respining for.
<ara> good morning all!
<ttx> ara: good morning !
<ara> morning ttx
<cjwatson> morning
<cjwatson> anyone know of any showstoppers?  otherwise I'll start working my way through publication/announcement processes and such
<ttx> cjwatson: not blocker from me
<ttx> cjwatson: my only gripe is the lousy test coverage %
<ttx> (server side)
<cjwatson> mm, I normally figure we're lucky to get any on a1, this is much better than I'm used to :)
<ttx> ok, works for me :)
<ttx> I think we caught what made sense anyway (UEC / basic boot behavior / virtual kernel size issue)
<cjwatson> gah, sabdfl picks these release names just to make it difficult to find a first milestone quote, doesn't he
<cjwatson> there is ... a bit of a dearth of meerkat-related fiction
<ttx> cjwatson: that's an unexplored field of literature, I suspect.
<elmo> cjwatson: has the kernel security upload been pocket copied to releases?  if not, could it be please?
<cjwatson> elmo: YM updates?
<elmo> I do, sorry
<elmo> monkey see release in IRC channel name, monkey type release
<cjwatson> elmo: that's automatic now unless there's a conflict in updates - and yes, it's been done
<elmo> cjwatson: ok, thanks
<cjwatson> thank cron ;-)
<elmo> well presumably cron didn't cron itself
<cjwatson> there is that
<elmo> or if it did, I'm impressed
<cjwatson> though have you checked the skynet status lately
<cjwatson> ?
<cjwatson> nagios alert: dangerously close to sentience
<elmo> no, but I'll send Nafallo into one of the DCs and see if they let the puny human live
<elmo> (kind of mixing my sci-fi metaphors there, but oh well)
<ara> ttx, is pitti working today?
<ttx> ara: haven't seen him yet
<ara> apw, hello gentleman
<apw> ara, hellooo
<ara> apw, in the current alpha 1 desktop images, linux metapackage version is 2.6.34.5.4, but the rest of kernel packages are 2.6.34-5.13
<apw> ara, the version number of meta is not entirly tied to the kernel package version numbers
<apw> the 2.6.34 is the same, and the .5 matches the kernel -5 to make the correct linkage, the last digit in each case though is a upload number for that package
<apw> so the last digit will be different between them
<apw> does that make any sense ?
<ara> apw, yes :-) thanks!
<apw> ara, how is testing going?  must be busy for you
<ara> apw, well, yes, but alpha 1 is quite relaxed, although I hope to see pitti arriving soon...
<apw> he was working some odd hours yesterday to help get the cd-respins we needed done, but it is a national holiday in .de i think
<ara> apw, ah, ok, and who's managing the release?
<ara> I thought it was him
<apw> ara, well yes, i didi think it was him, so it does seem unlikely he would forget about it
<ara> apw, :)
<cjwatson> pitti isn't doing the last steps, I am
<cjwatson> though I've been a bit distracted this morning
<cjwatson> huh, we didn't respin for the rescue-mode menu fix
<cjwatson> oh well
<ScottK> FWIW, one of the main characters in "The Lion King" is a Meerkat.
<ScottK> (Timon)
<slangasek> the haquna matata release?
<slangasek> hakuna
<cjwatson> y'all are preempting my quote ;-)
<slangasek> :-)
<ara> cjwatson, charlie-tca wanted this bug (and the workaround explain in the bug report release noted):
<ara> http://launchpad.net/bugs/586012
<ubot4> Launchpad bug 586012 in xfce4-panel (Ubuntu) (and 1 other project) "[Maverick] XFCE system tray became unusable after upgrade to libgtk2.0-0 2.21.0-1ubuntu2 (affects: 9) (dups: 3) (heat: 60)" [Undecided,Confirmed]
<ara> cjwatson, it is a Xubuntu bug
<cjwatson> ara: ok, can he write up suitable text?
<cjwatson> ara: he can feel free to add it to MaverickMeerkat/TechnicalOverview, actually
<ara> cjwatson, he's not around, but the text he provided in the bug description seems to be good enough. I will add it to the TechnicalOverview
<cjwatson> thanks!
<cjwatson> ara: do you know if any mythbuntu testing has happened?  for some reason it isn't on the tracker
<cjwatson> but there's a daily build from yesterday morning
<ara> cjwatson, I think they had some problems (not sure which) and they decided not to release alpha 1
<ara> cjwatson, I can try to discover more details
<cjwatson> ok, at your leisure
<cjwatson> so I think the releasable images are: Ubuntu desktop+alternate+server amd64+i386; Ubuntu netbook i386; UEC/EC2 amd64+i386; Kubuntu desktop+alternate amd64+i386; Kubuntu netbook i386; Xubuntu desktop+alternate amd64+i386; Ubuntu Studio alternate amd64+i386
<cjwatson> I see no releasable armel images
<cjwatson> does anyone see anything incorrect here?
<cjwatson> speak now or hold your peace until alpha-2
<ara> this is the xubuntu release note item: https://wiki.ubuntu.com/MaverickMeerkat/TechnicalOverview?action=diff&rev2=13&rev1=12
<cjwatson> thanks
<cjwatson> starting publishing
<ara> I asked around #ubuntu-mythtv and apparently they haven't made any changes yet in the myth* world, so they decided not to test alpha 1
<cjwatson> ok
<cjwatson> thanks
<cjwatson> smoser: could you do the EC2/UEC alpha-1 publishing, please?  I've not done it before and am not sure now is the time for me to learn
<cjwatson> (would I even have the necessary permissions?)
<cjwatson> could somebody please test the alpha-1 torrents, e.g.  http://cdimage.ubuntu.com/releases/maverick/alpha-1/maverick-desktop-i386.iso.torrent  ?
<cjwatson> NAT here makes it difficult for me to do so
<Laney> I added it but it sees no peers
<Laney> at least the tracker appears to know about it
<cjwatson> elmo: ^- does the tracker seem to be operating as normal?
 * cjwatson expects the response "no, actually, it seems to be working"
<Laney> oh, there's one now
<cjwatson> ah yes, it's downloading here too
<cjwatson> gosh, my NAT firewall must work better than I thought
<cjwatson> all right, in that case I'm just waiting for newz2000 to publish /testing on the website
<cjwatson> I have the announcement text in an editor window here
<smoser> cjwatson, we're pre-published. are you ready to publish publicly ?
<smoser> ah. i see, yes you are.
<cjwatson> yep
<apw> is it me or is launchpad down again
<Laney> wfm
<apw> i had the 'read-only' stuff up for a while there
<apw> but its just gone away on reload ... hrm
<apw> though all the queue depths on the builders are 'unknown' hrm, something is wibble
<smoser> cjwatson, images are public now, but http://uec-images.ubuntu.com/releases/ isn't getting populated with 'maverick' and 10.10 directories.  i've asked in #is for help on that.
<smoser> cjwatson, and http://uec-images.ubuntu.com/releases/maverick/alpha-1/ is there now.
<cjwatson> great, thanks
<Laney> I appear to already have seeded several gigs of A1 :)
<robbiew> cjwatson: nice work on alpha 1 sir....thanks you and everyone else for pitching in
<cjwatson> glad it's out ...
<cjwatson> now we have, what, four weeks to alpha 2?
<charlie-tca> cjwatson: I realize you are very busy. Thanks for the xubuntu release note!
<slangasek> cjwatson: haha, how did I miss the warthog connection there?  Nice touch - and congrats on getting alpha-1 out
<cjwatson> slangasek: it was serendipitous - I'd given up on getting any better quote, and then I found that
<cjwatson> charlie-tca: thank ara
#ubuntu-release 2010-06-04
<ttx> Good morning
<wgrant> [A9
<apw> cjwatson, am i right in thinking there is not a release meeting today ?
<cjwatson> apw: starts next week I think
<apw> cjwatson, thanks thats handy
<apw> cjwatson, i think robbiew may have inadvertandly deleted all of the entries for the whole cycle when he cancelled the one
<cjwatson> robbiew: ^-
<cjwatson> I didn't look too hard at those calendar mails :)
<cjwatson> mind you, I see an entry for next week
<cjwatson> and the week after, etc.
<apw> hrm, mine was empty i thought
<apw> yeah i don't seem to have nay anymore ... will hastle robbiew
<ogra> i have an entry for next week too
<apw> hmmm i am unloved
 * ogra pats apw 
 * apw sheds a tear
<cjwatson> sometimes you need to log back into calendar
<cjwatson> it gets a bit confused on occasion ime
<robbiew> cjwatson: apw: no release meeting today
<robbiew> I set them to start next week
<apw> robbiew, hrm, i had them briefly yesterday when they started this week, then i had a cancel for what appeared to be all of them, and now i have none
<apw> perhaps i fell off the invite lst
<robbiew> oh yeah
<robbiew> I figured leann was covering
<robbiew> I can add you back
<robbiew> sorry
<apw> ahh handy to have more than one of us aware
<apw> she will be the owner primarily
<robbiew> apw: done
<apw> robbiew, thanks -- and there it is
#ubuntu-release 2010-06-06
<slangasek> lamont: ENOSPC errors on edubuntu-dvd builds (i386)?
<lamont> yeah. you need livecd-rootfs 1.117 :-(
<lamont> 5GB+ image, 3GB RAM, 2GB swap.. ENOSPC
<lamont> tmpfs is not always your friend
<slangasek> right :) I see 1.117 in the archive, so is this auto-fixed for the next run?
<slangasek> (5GB+ image... sounds like the DVD needs pruned, besides?)
<lamont> well, that's 5GB+ of disk space (last I looked in my test back when, it was 5GB, that was before it finished, includes the downloaded debs, etc)
<lamont> manually upgraded i386 chroot for maverick. enjoy
<slangasek> cheers
<lamont> generally, it updates daily, fwiw
<lamont> at 02:15 london
#ubuntu-release 2011-05-30
<doko> cjwatson, ScottK: my mistake, didn't realize that the binary packages came from the *same* source package
<ScottK> doko: Thanks.
<ScottK> cjwatson: Would you please arrange for me to get the ISO and live failure logs/notifications for all Kubunt images?
<ScottK> That's one thing I forgot I'd need with Riddell on rotation.
<cjwatson> ScottK: done
<ScottK> cjwatson: Thanks, I think.
<cjwatson> heh
#ubuntu-release 2011-05-31
<jibel> Are alternate images ready for publication on the tracker ?
<cjwatson> I think we have a bit of work yet before that's the case
<cjwatson> at a minimum they'll need rebuilt for apt 0.8.14.1ubuntu5
<jibel> cjwatson, thanks
<cjwatson> jibel: and we really ought to have a new ubiquity (waiting for bug 790547)
<ubot4`> Launchpad bug 790547 in python-xklavier (Ubuntu) "[MIR] python-xklavier (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/790547
<Laney> is it easier for me to say 'please sync everything you can from http://people.canonical.com/~ubuntu-archive/transitions/ghc.html', or to file bugs? :-)
<Laney> I mean just the 'bad' packages
<cjwatson> easier to file bugs if you don't mind, then our tools help
<Laney> yep
<cjwatson> don't worry too much about the descriptions though
<Laney> doing then
<Laney> I remember giving james_w the input to the sync script once, but I forgot the syntax now
<Laney> sync spam ahoy
<cjwatson> ok, processing
<Laney> ty
<Laney> 3 more left that are blocked on other people
<pitti> whoops, seems I left this channel since my last server reboot, sorry
<doko> cjwatson: python-xklavier in main now (except for arm)
<ev> yay, thanks doko
<cjwatson> https://wiki.ubuntu.com/IncidentReports/2011-05-31-pam-security-update-breaks-cron
<ev> cjwatson: might be worth adding a "please RT" in the future to maximize the spread of such tweets
<cjwatson> ev: didn't have room
<ev> ah, fair enough
<cjwatson> note that this means that changes to oneiric will not be published at the moment
<cjwatson> this will probably affect alpha-1 publication until we get it sorted out
<cjwatson> mdeslaur: do you need any further assistance for the moment?
<mdeslaur> cjwatson: I've prepared updated packages which I am about to test...but my hardy one fails to compile...could you take a look?
<cjwatson> sure (modulo sorting out my hardy chroot)
<mdeslaur> cjwatson: the issue is the security update introduced an ABI change, a couple of new symbols, which in other updates is acceptable, but in pam, not good
<cjwatson> that's the issue that broke cron?
<mdeslaur> cjwatson: I've gotten rid of the ABI change, but it doesn't want to link in hardy
<cjwatson> ok
<cjwatson> debootstrapping now
<mdeslaur> cjwatson: yes, cron has libpam loaded already, and a dynamically loaded pam module from the new version can't find the symbols in the old one cron has loaded
<cjwatson> that makes sens
<cjwatson> e
<mdeslaur> I'm kicking myself for not thinking that that could happen
<cjwatson> cf. https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-pam-restarts
<cjwatson> (sorry, I don't have a local hardy mirror any more so a little slow)
<mdeslaur> cjwatson: so, look at the change to Linux-PAM/libpam/Makefile.am in my debdiff, that's the new private lib
<mdeslaur> cjwatson: I _very_ much appreciate your help
<cjwatson> you said you couldn't get in touch with Kees; have you tried Rick?
<cjwatson> both west coast though
<mdeslaur> cjwatson: jamie is my manager, he is on vacation today, and Rick doesn't appear online yet
<cjwatson> or Matt for that matter
<cjwatson> oh, sorry, manager not tech lead.  I knew that *headdesk*
<cjwatson> I'd notify mdz if I were you
<cjwatson> standard rules, escalate immediately until you find a victim :)
<mdeslaur> cjwatson: yes, thanks for that, I just pinged him
 * cjwatson has never had to go all the way up to Jane ... yet
<mdeslaur> cjwatson: stop scaring me :P
<doko> the incident report doesn't mention any distro series
<cjwatson> feel free to edit that in
<mdeslaur> I'll add it
<ev> anyone else ending up with the initramfs bailing with no log?
<jibel> ev, yes, i'm investigating.
<jibel> ev, I can't reproduce on i386, I'm installing a fresh amd64
<cjwatson> try debug=
<cjwatson> or just 'debug' and then look in /dev/.initramfs/initramfs.debug
<ev> will do
<ev> (was unaware of that trick)
<ev> ah, can't find the root device (either by uuid or by block device)
 * ev digs
<jibel> the problem comes from udev 171
<jibel> pitti, ^
<pitti> jibel: hi
<pitti> ev: you get a boot failure with udev 171?
<pitti> ev: what kind of boot device do you have?
<pitti> I only have a fairly standard system here, ext4 /, oneiric du jour
<jibel> pitti, hi, yes, reproducible on a fresh installation of Oneiric in VM.
<ev> pitti: just confirming that udev 170 fixes it
<jibel> pitti, just upgrade udev, libgudev and libudev
<pitti> ev: to confirm, if you keep libudev/libgudev at 171 and only downgrade udev, does it still work?
<ev> pitti: testing exactly that now
<jibel> pitti, still broken with udev at 170 and libs at 171
<cjwatson> /usr/bin/ld: cannot find -lpamprivs
<cjwatson> mdeslaur: is that the same failure you're referring to?
<pitti> jibel: ok, as expected; thanks!
<mdeslaur> cjwatson: yes
<jibel> :)
<pitti> I'll start an install in a VM now and see what happens
<cjwatson> mdeslaur: can you pass me a working debdiff for some other release?  I'd like to compare
<mdeslaur> cjwatson: sure, one sec
<mdeslaur> cjwatson: pam_1.1.1-2ubuntu5.3.debdiff in ~/mdeslaur
<pitti> jibel: OOI, how do you test in kvm? the current dailies don't really get me to a working desktop or ubiquity
<pitti> jibel: with the server isos?
<jibel> pitti, alternate
<pitti> ah
 * pitti goes to download that the
<pitti> ...n
<ev> yeah, for what it's worth, downgrading all the udev packages fixes it for me too.  Thanks jibel!
<cjwatson> cocoplum -> archive/ports syncing re-enabled now
<cjwatson> mdeslaur: (still working on this, but I have a call now)
<mdeslaur> cjwatson: thanks
<ev> doko: if you have time for one more, I'd appreciate a look at MIR bug 790725
<ubot4`> Launchpad bug 790725 in pyflakes (Ubuntu) "[MIR] pyflakes (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/790725
<mdeslaur> cjwatson: any progress?
<cjwatson> sorry, still otp
<pitti> FTR, 20110532 alternate amd64 installs just fine in kvm; caveat: need to select "GNOME classic" as a session, unity-2d is crashing
<pitti> erm, 20110531 obviously
<mdeslaur> cjwatson: ah, I think I got it
<doko> ev: done
<ev> doko: nice, thanks!
<cjwatson> mdeslaur: oh, good, I was stuck in the guts of libtool
<jdstrand> mdeslaur: I'm here now. is there something I can do to help?
<mdeslaur> jdstrand: ah! hello
<mdeslaur> jdstrand: sorry for doing this on your day off :)
<mdeslaur> jdstrand: I think everything is under control
<mdeslaur> jdstrand: packages for lucid, maverick, natty are built, and I'm satisfied that they solve the issue
<mdeslaur> jdstrand: I'm putting the final touch on the hardy package which I'll upload in a few minutes
<mdeslaur> jdstrand: once I'm satisfied, I'll publish a -2
<cjwatson> mdeslaur: what did you do, just hit it with -Wl?  I'd got as far as noticing that libtool wasn't passing -L through to gcc, but hadn't figured out the proper fix
<cjwatson> and my libtool is rusty
<mdeslaur> cjwatson: I'll let you know in a sec if my crowbar worked :P
<jdstrand> mdeslaur: thanks. I have read all backscroll. do you need help with testing? with usn publication?
<mdeslaur> jdstrand: I'm ok at this point
<mdeslaur> jdstrand: thanks for the offer!
<jdstrand> mdeslaur: ack
<jdstrand> cjwatson: I know mdeslaur already did, but I'd like to also thank you for all the help :)
<mdeslaur> jdstrand: cjwatson rocks!
<jdstrand> yes, he does :)
<cjwatson> np
<cjwatson> http://www.welikeballs.com/2010/04/misue-of-language-pt-372-rock-star.html
<mdeslaur> lol :)
<jdstrand> hehe
<skaet> :)
<mdeslaur> cjwatson: crowbar:
<mdeslaur> -	-L$(top_builddir)/libpam -lpam
<mdeslaur> +	-L$(top_builddir)/libpam $(top_builddir)/libpam/libpamprivs.a -lpam
<cjwatson> OK, that was one of the crowbars I was considering
<cjwatson> cool
<cjwatson> Laney: ooh, big pile of libghc6-* just fell out of NBS
<Laney> \o/
<Laney> are you still doing new-source runs? there's a lot of new stuff being uploaded to Debian currently
<cjwatson> from time to time, yes
<Laney> seems clint is becoming a haskell fan
 * cjwatson processes 'new-source | grep haskell'
<Laney> but for the transition, gitit is getting some new depends
<cjwatson> ah, that would be actually important then
<cjwatson> flushed a load through for you now; let me know if you care about stuff that isn't haskell-*
<Laney> thanks
<Laney> not aware of anything else currently :-)
 * Laney hopes joeyh follows through on his ikiwiki-haskell threat
<jdstrand> fyi, I took the liberty of updating https://wiki.ubuntu.com/IncidentReports/2011-05-31-pam-security-update-breaks-cron a little
<cjwatson> that's fine, I didn't go back through all the history
<cjwatson> mdeslaur: give me a shout when it's published enough to be worth updating ubuntustatus
<mdeslaur> cjwatson: sure, I've got about a half-hour of testing left to do, and then I'll let you know and release the updates
<cjwatson> mdeslaur: does any of this affect oneiric (for alpha 1)?
<jdstrand> mdeslaur: so, pam got new symbols which prevented cron from working (module is unknown)
<jdstrand> mdeslaur: question-- people who do *not* have auto updates should have been prompted for the services restart, correct? it is only people who have auto updates (and those that chose not to restart) that are affected. correct?
<mdeslaur> jdstrand: nobody should have been prompted for the services restart
<jdstrand> huh, I thought that was something I always saw when doing an upgrade (at least, do-release-upgrade)
<mdeslaur> jdstrand: yes, pam has that in the postinst conditional on certain versions, but the update didn't update that and trigger it
<jdstrand> ah, I see
<mdeslaur> jdstrand: so, desktop users won't get an update-manager popup until they reboot, server users who installed it won't get automatic updates until they either reboot, restart cron, or do an apt-get dist-upgrade
<jdstrand> mdeslaur, cjwatson: since things seem to be well in hand (thanks again!) I am going back to my day off. I am available by phone/email in case you need me. I've asked kees to keep an eye on things. We can do the postmortem tomorrow/later this week
<jdstrand> cjwatson: that last part was more for mdeslaur than you :)
<cjwatson> mkay
<ev> ubiquity 2.7.2 uploaded which should hopefully, finally fix the ftbfs issues
<skaet> cjwatson,  was talking to pitti, and it looks like udev is going to need some bisecting.   Any downsides of falling back to last version of udev for the alpha-1 images?
<pitti> no, we don't really depend on 171 right now
<cjwatson> skaet: how would we do that?
 * cjwatson doesn't like rolling back libraries
<cjwatson> although at least libudev0's shlibs aren't strict
<skaet> cjwatson,  not sure how else to work around the fact that udev is failing for some, and not for other,  and based on the backscroll - prior version seems to make it stable.   Recommendations?
<cjwatson> pitti still seems to be debugging on #ubuntu-devel - we have a little while yet
<pitti> I'm preparing/testing a revert right now
<pitti> and ask people to bisect in parallel
<pitti> being able to reproduce would of course help :-(
<cjwatson> would it help to have CD builds with 171?
<pitti> cjwatson: it would be interesting to see whether it makes a difference
<pitti> cjwatson: but having fresh desktops would be interesting in its own right, now that apt is fixed
<pitti> udev won't hit the archive for another 100 minutes, 'nuff time to build a set in between?
<cjwatson> I've kicked some off on x86, let's see what happens
<pitti> I asked in #udev, kay is not aware of problems with 171, so we need to debug this ourselves
<pitti> they have a vastly different initrd/systemd/etc, of course
<pitti> ok, reverted udev builds, installs, upgrades, boots
<pitti> uploaded
<pitti> I bumped build score on amd64, but it's still a bit crowded; so amd64 will likely miss the next publisher
<pitti> oh, building now
<skaet> :)
<pitti> ok, amd64 done, i386 well into the build, so they should hit the archive in 70 mins
<skaet> thanks pitti
<jibel> udev 171-0ubuntu2 is OK on amd64
<ScottK> It looks like all the Kubuntu LiveFS builds failed last night.  All but one due exclusively to problems fetching packages files.  Is this a known problem or is there something I need to do about it?
<pitti> jibel: *phew*, thanks muchly for bearing with me!
<ev> yet another ubiquity making its way through
<pitti> good enough for a1
<cjwatson> ScottK: known, fixed in latest apt
<ScottK> cjwatson: Thanks.
<cjwatson> it broke all flavours
<ScottK> Did you do respins after the fix?
<cjwatson> no
<cjwatson> there were other things in progress anyway ...
<ScottK> OK.  Still are, so I guess no point.
<cjwatson> I'm respinning Ubuntu right now, but that's just in case it helps with debugging udev
<mdeslaur> cjwatson: I've just released the updated packages
<ScottK> We've got quite a number of uploads in progress at the moment, so I suspect it'll be about the time the next spin happens anyway when stuff calms down.
<cjwatson> mdeslaur: OK, are all the binaries in place?
<pitti> good night everyone!
<mdeslaur> cjwatson: at the next publisher run they will be
<mdeslaur> cjwatson: publisher has published the binaries
<cjwatson> mdeslaur: great, thanks.  want to close the main task on that bug?
 * cjwatson dents
<mdeslaur> thanks cjwatson
<cjwatson> would anyone like to figure out what's up with all the KDE stuff on http://people.canonical.com/~ubuntu-archive/testing/oneiric_probs.html?
<ScottK> Sure
<cjwatson> looks like an argument between kdepim-runtime and akonadi at first glance, but I only looked at one of the uninstallables
<ScottK> That wouldn't explain all of it.
<ScottK> -pim runtime was just uploaded though.
<ScottK> I'm at a conference for $WORK this week and I think we just killed the hotel Internet when everyone signed on the wifi.
<ScottK> Not nearly the service lamont gives here.
<ScottK> (so it may take awhile)
<lamont> ScottK: I haven't had much to do with the UDS wifi layout in forever
<ScottK> lamont: OK.  Canonical IS then.
<lamont> +1
<cjwatson> pitti: new CDs built
<pitti> cjwatson: ah, thanks; with the new udev 171-0ubuntu2?
<slangasek> cjwatson, pitti: I've seen lots of mail about image build failures due to not finding /var/lib/apt/lists, but no discussion about it in scrollback; is this problem understood / already solved, or is it something I should dig into for alpha-1?
<cjwatson> pitti: no, 0ubuntu1
<pitti> slangasek: yes, it was a regression in apt, fixed today
<cjwatson> pitti: deliberately, so that you can see if the problems people were reporting are reproducible with that
<slangasek> ah, ok
<pitti> cjwatson: right, thanks
 * pitti -> off again, see you tomorrow!
<slangasek> 'night, pitti :)
<slangasek> cjwatson: skaet says you're working on fixing a ubiquity problem yet; anything else I need to know about image status for a1?
<slangasek> skaet: should there be an email reminder of the a1 freeze, btw?
<skaet> slangasek,  was sent, but appears blocked waiting for an approver to ubuntu-devel-announce ;)
<slangasek> hmm!
<slangasek> skaet: message accepted
<skaet> lol
<skaet> thanks!
<cjwatson> slangasek: that's the only thing I *know* of right now
<ScottK> cjwatson: I think I figured it out (KDE packages).  Solution will take a bit of work though.
<cjwatson> oh, wait, I need to do a d-i rebuild to pick up a netcfg fix from earlier
 * cjwatson nods
<cjwatson> well, I can at least reproduce the ubiquity failure in pbuilder
<cjwatson> new d-i uploaded
<charlie-tca> cjwatson: I heard I owe more than a beer now. Thanks for helping us out.
<cjwatson> np, but don't say that until you see a successful build :P
<cjwatson> OK, I see the ubiquity problem
<skaet> cjwatson,  thats good - will it be a straight forward fix?
<cjwatson> one-liner
<skaet> :D
<cjwatson> uploading now
<skaet> excellent.  :)
<cjwatson> http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/revision/4740
<cjwatson> beer o'clock, back later
<skaet> single character even...  enjoy the beer.
<jibel> udev problem is reproducible with latest desktop iso: dropped into a busybox shell after installation and reboot.
<cjwatson> pitti: ^-
<cjwatson> we can have another build in a bit with current udev, now that ubiquity has built
<cjwatson> slangasek: I'm done here - ubiquity is published on amd64/i386, so you can probably start spinning images at this point and see what breaks
<cjwatson> ubiquity/armel is accepted, ubiquity/powerpc is building and looks nearly finished
<cjwatson> (though powerpc in general is behind at the moment)
<cjwatson> I don't think I have any other pending status
<slangasek> ok
<slangasek> will take it from here :)
<cjwatson> thanks!
<ScottK> slangasek: No rush on any Kubuntu images.  Still beating stuff into shape.
<slangasek> ack
#ubuntu-release 2011-06-01
<slangasek> ubuntu alternates are available for smoketesting (oversized, though)
 * stgraber rsyncs
<slangasek> desktop also posted, also oversized...
<stgraber> nice, getting a steady 80Mb/s from cdimage.u.c :)
<cjwatson> oh, which reminds me, I was going to try for a backport of the lintian change that switches to using libdpkg-perl
<cjwatson> I haven't done the sums, but that might well get us either back within limits or very close
<slangasek> cjwatson: something to include in tomorrow's images, maybe?
<cjwatson> yeah, I'm build-testing and will see if it looks reasonable
<cjwatson> the lintian tests don't half take forever to run
<slangasek> :)
<slangasek> server up
<slangasek> ScottK: haven't queued anything for kubuntu yet, per your earlier comment; please let me know when I should
<charlie-tca> I see Xubuntu images are new; are they really ready to smoke test?
<micahg> skaet: ping, it seems like we have an issue with the firefox homepage, bug 790469
<ubot4`> Launchpad bug 790469 in firefox (Ubuntu Oneiric) (and 1 other project) "invalid security certificate 11.10 (affects: 1) (heat: 6)" [High,Triaged] https://launchpad.net/bugs/790469
<micahg> I milestoned it for alpha1 since it seems bad, feel free to move if you think it's not worth respins
<micahg> skaet: there's also bug 790617, I'll see if I can find someone to look at that
<ubot4`> Launchpad bug 790617 in firefox (Ubuntu) (and 1 other project) "about:startpage returns 404 Not Found (affects: 2) (dups: 1) (heat: 16)" [Undecided,Invalid] https://launchpad.net/bugs/790617
<micahg> skaet: re start page, I pinged newz2000 about it, but he probably won't see it until morning US
<slangasek> micahg: there will be respins before alpha1 regardless, and if you have a fix that you can upload now it's probably worth doing - but the threshold for alpha1 is "boots, installs, golden" so if you don't have the fix we aren't going to sweat it
<ScottK> slangasek: I just accepted kdebase-workspace, so once that publishes I think it's worth a shot.
<slangasek> ok
<micahg> slangasek: I have no idea what the fix could be at this point aside from disabling the extension, chrisccoulson should be up in a few hours and I'll ask him to take a look
<ScottK> micahg: For an Alpha 1, I think that's not a real concern.  Fixing is good, but don't kill anyone.  This is a marathon, not a sprint and we're just getting started.
<micahg> ScottK: ok
<stgraber> is there a planned rebuild of edubuntu ? current daily is 20110530 and at least in my case, doesn't boot. I'd like to see if that got fixed somehow (as I doubt it's Edubuntu-specific)
<slangasek> stgraber: yes - was provisionally waiting for smoketesting of the images already built before spinning edubuntu, but I can kick it off now
<stgraber> would be great. I was hoping for 20110531 to improve the situation in our case but it failed because of an issue with archive.u.c ...
<pitti> cjwatson: I already dropped the lintian dependency yesterday, it removed 7 MB from the dailies
<pitti> cjwatson: I quickly discussed with Michael, we said it'd be better to install lintian on demand once the user actually enables a third-party repo
<pitti> oh, kvm -vga std actually makes unity-2d work nicely
<cjwatson> pitti: OK, it'll still be good for it not to pull in build-essential
<cjwatson> pitti: I've been working on that with the Debian maintainers on and off since UDS
<pitti> yes, absolutely
<pitti> and once it's small, we might even bring it back
<cjwatson> but if it's not on the images, I won't worry about it today
<cjwatson> well, it'll inevitably have a perl dependency
<pitti> even now we are still some 15 MB oversized
<cjwatson> (-modules)
<cjwatson> if we're ever shooting for losing perl-modules, we can't have lintian on the images
<pitti> we can get back 5 from gnome-icon-theme surgery
<cjwatson> we'll get 5 more in alpha 2 from live-build
<pitti> and I think you mentioned some 5 MB due to better squashfs from live-helper
<cjwatson> any chance of losing gnome-system-tools this cycle?
<pitti> Johan said that the AppArmor parts which need perl are only the administration bits
<pitti> which we actually could not instlal by default
<pitti> cjwatson: already happened
<pitti> it's not on the alphas any more, or at least shouldn't be
 * pitti checks
<cjwatson> ok
<pitti> yep
<pitti> then the only thing which will still bind a lot of perl is debconf-gtk
<pitti> that and AppArmor were the two main things which hold a lot of perl modules
<cjwatson> there are a few other things
<pitti> yes, indeed
<pitti> but these two are the hardest to get rid of
<cjwatson> I don't see debconf's gnome frontend ever not depending on perl-modules; I suppose we might eventually be able to switch to cdebconf, although that's a long road
<pitti> the rest is just some busy work with making stuff work with perl-base only
<pitti> but no point in doing more of that as long as we have AA/debconf-gtk
<pitti> right, unless we make a stronger decision to just use the text frontend in a vte widget
<pitti> at some point this stuff needs to be ported to GTK 3 anyway
<pitti> and I don't think a gtk3-perl exists right now
<pitti> https://live.gnome.org/GTK2-Perl/Introspection sounds promising, though
<pitti> ah, and gnome classic session also dropped from CDs now
<cjwatson> pitti: yeah, looks like Glib::Object::Introspection et al just need to be packaged
<jibel> bug 791139, looks like something with udev
<ubot4`> Launchpad bug 791139 in ubiquity (Ubuntu) "When booting from an ISO, a shell is displayed for 2 min before the graphics environment starts (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/791139
<ScottK> It looks like uninstallables for Kubuntu are fixed.
<ScottK> cjwatson: AFAICT the Kubuntu images didn't get respun yesterday (which is fine, it would have failed), but I think from a Kubuntu perpsective nowish is a good time.
<pitti> ScottK: cjwatson is on holiday today; let me trigger new Kubuntu images
<ScottK> pitti: Thanks.
<pitti> ScottK: running desktop + alternate; do you want the armels as well?
<ScottK> pitti: No point in armel or powerpc.
<pitti> *nod*
<jibel> skaet, ping
<skaet> jibel, Slangasek,  waiting for Pete.
<jibel> skaet, ok, I thought you enjoyed the great tune on the phone
 * slangasek jams along with the music
<skaet> jibel,  lets just go through things here.
<jibel> skaet, k
<skaet> jibel,  how do things look from the smoke tests over last 12 hours?
<slangasek> pitti: you mentioned lintian had already been uploaded; so these oversized images *already* have the benefit of that change?
<pitti> slangasek: not lintian itself, just aptdaemon
<pitti> yes
<pitti> dropped some 7 MB
<slangasek> oh
<jibel> skaet, no failures with the installer (d-i and ubiquity)
<jibel> major issues are crashes mainly with unity-2d
<pitti> my test runs on i386 (real iron) and amd64 (kvm) also look good
<jibel> e.g bug 791213 , bug 791127
<ubot4`> Launchpad bug 791213 in unity-2d (Ubuntu) (and 1 other project) "unity-2d-places crashed with SIGSEGV in QMetaObject::metacall() (affects: 3) (dups: 1) (heat: 18)" [Undecided,Confirmed] https://launchpad.net/bugs/791213
<ubot4`> Launchpad bug 791127 in unity-2d (Ubuntu) (and 1 other project) "unity-2d-places crashed with SIGSEGV in QTJSC::Structure::materializePropertyMap() (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/791127
<pitti> jibel: FYI, I installed some debug symbols for that and reported it as bug 791127
<pitti> heh
<jibel> 2 other very common crashes: bug 788714 , bug 788710
<ubot4`> Launchpad bug 788714 in gnome-user-share (Ubuntu) "gnome-user-share crashed with SIGABRT in g_option_context_parse() (affects: 9) (dups: 7) (heat: 76)" [Medium,Confirmed] https://launchpad.net/bugs/788714
<ubot4`> Launchpad bug 788710 in gnome-settings-daemon (Ubuntu) "gnome-settings-daemon crashed with SIGSEGV in exit() (affects: 5) (dups: 1) (heat: 36)" [Medium,Confirmed] https://launchpad.net/bugs/788710
<jibel> and still 1 report about the udev failure we had yesterday but no confirmation from other testers
<jibel> bug 791121
<ubot4`> Launchpad bug 791121 in udev (Ubuntu) (and 1 other project) "user dropped into busybox shell after installation (affects: 1) (heat: 8)" [High,Incomplete] https://launchpad.net/bugs/791121
<jdstrand> pitti, cjwatson: regarding apparmor/perl: we are in the process of fixing that. mdeslaur is working on it-- he rewrote a tool in python and we need to get it uploaded and iirc, adjust a seed. bottom line, it will be fixed
<jibel> coverage is low (61.76%) but we started to test really late
<jibel> no coverage at all of ppc and amd64+mac images
<pitti> jibel: yay!
<jdstrand> pitti, cjwatson: not sure about the status for alpha-1 though (ask mdeslaur)
<pitti> jdstrand: I don't think we particularly care about a1 oversizedness
<skaet> jibel,  are the unity-2d issues on kvm?  can't tell from a quick glance at the bug.
<jdstrand> cool
<jibel> upgrades are ok for all flavors (auto-upgrade-testers reports failures, => needs investigation)
<skaet> jdstrand, pitti,  - yes, oversize is not blocker on alphas.
<pitti> skaet: if you use kvm -vga std or -vga vmware, it works; it's only for the default emulated card (cirrus)
<jibel> skaet, yes
<pitti> well, FSVO "works"
<skaet> pitti,  so there is a workaround then - cool.
<pitti> unity-2d crashes if you look at it the wrong way
<pitti> but install works
<slangasek> pitti: do we think we have a clear path to right-sized images for alpha2?
<pitti> slangasek: not there yet :/ we'll get about 5 MB from icons, and 5 MB from switching to live-builder
<mdeslaur> pitti, jdstrand: the package is ready now if you want it for alpha-1
<jibel> and talking about udev, there's a strange behavior of i386 images on vbox: bug 791139, need someone to confirm.
<ubot4`> Launchpad bug 791139 in ubiquity (Ubuntu) "When booting from an ISO, a shell is displayed for 2 min before the graphics environment starts (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/791139
<pitti> slangasek: the rest is lots of work in little pieces, like downsizing kernel, etc.
<pitti> we have WIs for it, but haven't seen much action on this yet
<pitti> slangasek: I'm already happy that we reduced it by 15 MB already
<slangasek> we still have an extra python on there that we want to get rid of, but then we also want to add python3, so that's no use to you :)
<pitti> right, that should come out as near zero sum, hopefully
<slangasek> s/an extra python/python extensions built for a python we don't want/
<skaet> jibel, has anyone else been able to reporduce 791121?
<jibel> skaet, no, I think that's a pebkac
<skaet> jibel,  not worrying about ppc and amd64+mac images for this alpha1 - we'll see if we can get that lined up for alpha 2.
<skaet> pebkac??
<jibel> http://en.wikipedia.org/wiki/User_error
<skaet> jibel,  heh.  :)
<skaet> ok,  so sounds like standard ugliness for this point in the cycle, but no real blockers at the moment?
<jibel> about other flavors, it will be tested by tomorrow, and waiting for kubuntu.
<jibel> no blocker.
<jibel> ..
<skaet> pitti, jibel, slangasek - net seems to be we're ok with these images,  waiting for kubuntu to land.
<skaet> pitti, slangasek - anything we feel *must* get added?
<slangasek> pitti: kubuntu alternates seem to be built, shall I post them to the tracker?
<pitti> please do
<pitti> desktops are building
<slangasek> skaet: nothing in there that sounds like an alpha blocker to me, yeah
<ScottK> I'm looking for testers now.
<skaet> ScottK,  thanks.
<jibel> btw list of bugs reported by iso testers: http://reports.qa.ubuntu.com/reports/isotesting/oneiric/opened.html
<skaet> slangasek,  jibel, pitti - ok,  sounds like we'll go ahead with the images we've got unless something critical comes up later today.
<skaet> https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview
<jibel> what about dvds ?
<ScottK> Don't worry about dvds for Alpha 1.
<jibel> ok
<skaet> ScottK,  is that a Kubuntu or general statement?
<ScottK> skaet: We don't generally bother with them this early
<ScottK> The Kubuntu one I know won't build, but I'd suggest generally not worrying about it.
<skaet> ScottK,  ok.
<skaet> Ok,  seems like plan forward is:
<skaet> 1) continue testing current images
<skaet> 2) add Kubuntu as they emerge and test them
<skaet> 3) document in the TechOverview the workarounds for the worrisome bugs
<skaet> 4) check where we are later today re: bugs, and decide if respin makes sense.
<skaet> s/makes sense/essential/ ...   ;)
<skaet> slangasek, pitti, ScottK, jibel - anything forgotten?
<ScottK> Seems reasonable.
<pitti> sounds good to me
<pitti> not that we'd actually have a solution for any of the unity-2d or udev problems right now
 * skaet nods
<ScottK> Also it's pretty normal to have oversize issues in this milestone.  I wouldn't worry much about that.
<ScottK> skaet: I need to correct something I said in the last release meeting.  I said we'd have KDE 4.7 beta 1 packaged before Alpha 2.  I need to take that back.  Upstream is waffling about tarball layout for the 4.7 series so we've stepped back a bit to wait and see how it works out.
<skaet> ScottK,  understood.
<skaet> jibel,  give me a ping towards the end of your day,  and we'll do a quick assessment.
<slangasek> skaet: nothing else from me
<skaet> If there is anything critical,  we'll regather here to discuss.
<jibel> skaet, will do
<skaet> slangasek,  pitt, ScottK, jibel   - thanks!!
<didrocks> jibel: on bug #791213, it's the merge with debian which brought the regression (seems it was uploaded yesterday). I'm trying to make a dicho an cherry-picked debian patches right now (but qt takes 5 hours and half here to build)
<ubot4`> Launchpad bug 791213 in unity-2d (Ubuntu) (and 1 other project) "unity-2d-places crashed with SIGSEGV in QMetaObject::metacall() (affects: 3) (dups: 1) (heat: 18)" [Undecided,Confirmed] https://launchpad.net/bugs/791213
 * skaet ... heads back to finishing of EOL dapper,  then on to tech overview prep...
<jibel> didrocks, good to know that you already found the cause. Thanks!
<didrocks> jibel: well, the dicho will take some times (large choice between 15 guilty patches, just trying to pick the right one, but will take time)
 * ScottK says +1 on Dapper EOL.
<pitti> http://cdimage.ubuntu.com/kubuntu/daily-live/20110601/
<pitti> ScottK, slangasek ^
<ScottK> Cool.  Thanks.
<ScottK> pitti: Once Alpha 1 is done, we made need some help on CD size for Kubuntu.  Debian qt-kde switched from cdbs to dh7 rules so we may have lost some of your shrinking magic.
<pitti> ScottK: -> #u-devel?
<stgraber> pushed a seed change for edubuntu to include gnome-session-fallback and a new edubuntu-artwork to update our gdm tricks to set it as default
<stgraber> in my tests, it's not pretty but it "works" (as in, I can start ubiquity)
<pitti> pretty is for post-a1, I'm afraid :/
<stgraber> so we'll need a rebuild once the seed change and the new edubuntu-artwork are in the archive
<stgraber> highvoltage: ^ just so you know we'll ship with gnome-session-fallback for alpha-1 :)
<highvoltage> what's that? gnome 3 fallback mode or a gnome 2 session?
<stgraber> gnome 3 fallback
<slangasek> pitti: yep, just posted it to the tracker :)
<highvoltage> ok
<stgraber> highvoltage: in my tests, gnome-classic (our current default) gives you only a blue wallpaper, unity-2d is impossible to use in kvm, unity-3d won't start because of compiz. So that was gnome-session-fallback or using xterm :)
<highvoltage> heh, so we were quite close to just completing our kde session eh?
<stgraber> actually, it probably would have pulled less packages on the DVD to go with a KDE session :)
<highvoltage> yeah I wondered about that :)
<highvoltage> but if we did that OMG!ubuntu would probably post something like "OMG Edubuntu switches to KDE by default!"
<micahg> skaet: I apologize for being frantic crazy about alpha1, I'm usually not in here until the end of the cycle
<skaet> micahg, no worries.  :)   glad to have you around and getting the issues raise up (and dealt with) nice and early in the cycle.
<chrisccoulson> micahg, so, bug 790469 will be fixed shortly. not sure if we need to track that in oneiric now though
<ubot4`> Launchpad bug 790469 in firefox (Ubuntu Oneiric) (and 2 other projects) "invalid security certificate 11.10 (affects: 4) (dups: 2) (heat: 24)" [High,Triaged] https://launchpad.net/bugs/790469
<chrisccoulson> it doesn't require any more action from me :)
<smoser> skaet, can you populate tracker with oneiric images: http://uec-images.ubuntu.com/server/oneiric/20110601/
<skaet> slangasek, ^^  ?
 * skaet dealing with Dapper EOL at the moment...
 * slangasek has a look
<slangasek> posted
<micahg> chrisccoulson: cool, I'll see if I can untrack it
 * micahg guesses that's not possible, so moves the milestone forward
<slangasek> micahg: "untrack" is marking the release task as 'wontfix' IIRC, which leaves a default non-release-targeted task open in its place; but I think it's fine to have it targeted to the release given that we certainly want it fixed for 11.10...
<micahg> slangasek: can you add a transition for me to the transition tracker?
<slangasek> micahg: I don't know the answer to that question :-)
<slangasek> I haven't seen that I've been added as a member of the committer team; maybe it happened silently
<micahg> slangasek: ubuntu-release owns it :)
<slangasek> does it own the branch, or just the publishing?
<micahg> the team, you commit files to the branch and it's auto published at :55 after
<slangasek> ok - what do you need tracked?
<micahg> libnotify, I have a .ben file, http://bazaar.launchpad.net/~micahg/+junk/transition-tracker-libnotify-oneiric/view/head:/ubuntu/monitor/libnotify.ben
<micahg> the title should probably be libnotify1 -> libnotify4
<seb128> micahg, what's the interest to track those there rather than watching NBS?
<seb128> I've been pondering asking for the libnotify things to be tracker but since NBS has an updated list I didn't see the point to do it
<seb128> tracked
<slangasek> seb128: the transition tracker helps figure out build ordering, for one thing
<seb128> well there is no order in this case
<micahg> seb128: hmm, I figured since it's a transition it should go in the transition tracker, I guess it's true that NBS has the info
<slangasek> micahg: committed
<micahg> slangasek: thanks
<seb128> micahg, well the question is me trying to figure what the transition tracker provide
<seb128> should every soname change go there?
<seb128> if it does can we automate that?
<seb128> it doesn't seem to make sense to have to track sonames update manually to add them
<micahg> well, anything that requires a bit of coordination IMHO should go in the transition tracker, I saw about 30+ rdepends for libnotify and figured it was a good candidate
<micahg> but I'm just a happy contributor
<slangasek> for the moment, I'm happy to have the tracker track those things that developers want tracked
<slangasek> automatically tracking every soname change would be too much, at least until we have an index page...
<seb128> ok, I think I just don't see the point for libnotify
<seb128> but if it's useful to other people
<seb128> I've been using the NBS list for it and it does the job
<micahg> seb128: ah, the advantage is that it shows build-depends issues as well, not just binary
<micahg> so, libnotify4-dev > libnotify-dev
<seb128> ok
<skaet> micahg,  slangasek -   FYI.  there will be some info on the transition tracker and how to add to it in the release notes tomorrow courtesy of Laney.  :)    I agree if we could get index into place (completed, active? transitions) it would help.
<Laney> micahg: could you have come up with an is_good line there? :-) .depends ~ /libnotify4/ or similar?
<micahg> Laney: maybe, I didn't check to see if that always happens
<Laney> I'd prefer we have them in general as an extra check (I know I'm guilty of missing it out for boost though)
<micahg> Laney: boost was my model :)
<micahg> Laney: does it just show unknown if it doesn't match the good string?
<Laney> yeah, unknown is "affected and neither good or bad"
<micahg> Laney: k, I can prepare another merge then
<Laney> cool
<micahg> Laney: BTW, if there was an actual project, we could propose actual merges :)
<Laney> I didn't know you couldn't propose merges against normal branches
<micahg> Laney: maybe it's an LP bug, here's my new branch BTW, https://code.launchpad.net/~micahg/%2Bjunk/transition-tracker/
<Laney> ty
<Laney> can always tweak it later if that turns out to be insufficient
<ScottK> The tracker helps for stuff that's not yet NBS.  See for an example.
<ScottK> sdee http://people.canonical.com/~ubuntu-archive/transitions/boost1.46.html
<ScottK> sdee/see
 * ScottK should just eat lunch and quit trying to eat and IRC.
<micahg> Laney: can you pull in another revision please? https://code.launchpad.net/~micahg/%2Bjunk/transition-tracker/ (affected was too broad)
<ScottK> skaet, slangasek, whoever: bug 791487 may be a bit of a showstopper for Kubuntu (investigating).  If we can get a fix, can we have a Ubiquity upload?
<ubot4`> Launchpad bug 791487 in ubiquity (Ubuntu) "Kubuntu crashed during installation from Live Desktop (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/791487
<slangasek> no objection here; skaet ?
<elmo> skaet: we're going to get and/or have an RT about dapper, right?
<elmo> skaet: specifically moving it off archive/ports/security/releases
<Laney> micahg: done
<micahg> Laney: thanks
<skaet> elmo,  can send an RT if you want it done that way.
<elmo> skaet: well - someone needs to send one for it to happen ;-)  if you don't want to for some reason, I can
<skaet> elmo,  thanks.   Will update the process to make it explicit in future.
<skaet> ScottK,  just respin the Kubuntu ones?   or will all the images need respinning?
<slangasek> skaet: if there's time to test, it would be better to respin all desktop images
<ScottK> Depends on if you care about Ubiquity being out of date on the Ubuntu and related images
<slangasek> so we get assurance that the fix doesn't regress !kubuntu
<skaet> jibel, ^^  do you have time to do a full retest, if they can get a fix in?
<slangasek> I don't think we should care about out-of-dateness per se, though, so if the code change is isolated to the kubuntu ubiquity frontend, we could forgo it
<ScottK> maco is looking to see if she can fix it, but I don't have an ETA.
<ScottK> I don't think it is.
<ScottK> The bug is caused by Ubiquity trying to speak gtk to Qt.
<maco> its in ubi-prepare.py
<skaet> ScottK,  ok,   will stay with what we have until we know a fix is ready,  then decide.
<ScottK> Apparently it's easy to reproduce (as in can't avoid it).
<skaet> :(
<GrueMaster> Speaking of respins, I may need a respin of preinstalled netbook for omap.  Headless as well, but less critical.  It appears that usb is completely broken.  No keyboard/mouse or ethernet.
<GrueMaster> I'm booting headless now to see if I can see what is wrong.  If it is a kernel config option, easy fix.  Otherwise I will have to fail the netbook image.
 * slangasek nods
<jibel> skaet, when would the new images be available ?
<stgraber> slangasek, skaet: Apparently Edubuntu is ready for a rebuild (edubuntu-live just got published)
<skaet> jibel,  not known right now,   see comments from ScottK ^^
<jibel> I need ~3 to 4 hours to replay all tests on all desktop images
<slangasek> stgraber: ok, scheduled
<stgraber> thanks
<skaet> thanks slangasek
<slangasek> skaet: fallback option could be to release the existing !kubuntu desktop images with the previous ubiquity, but still go through the QA process on the images that include the ubiquity revved for kubuntu so that we get our regression-test and don't have any time pressure
<maco> either charlie or john the taco is testing a patch now, i think
<skaet> slangasek,  seems reasonable.
<ScottK> slangasek: The live Kubuntu images really aren't releasable I don't think.
<ScottK> As long as we test the patch in a gtk session, I think the regression risk is low.
<slangasek> ScottK: I'm assuming they will be after a ubiquity fix is available
<maco> assuming charlie doesnt find more bugs :)
<ScottK> We have a draft patch.  The real question is as maco says.  Now that we peel this layer of the onion, how many are left.
<charlie-tca> I might have typed wrong. ubi-console-setup crashed
<charlie-tca> exit code 141
<charlie-tca> going check my patch
<jibel> maco, dinner is over, I'm available for testing, where can I get the patch ?
<maco> jibel: http://paste.ubuntu.com/616043/ apply to /usr/lib/ubiquity/plugins/ubi-prepare.py
<jibel> maco, thanks
<maco> jibel: john the taco says the patch worked for that part, but he hit the same farther-along bug charlie-tca did
<jibel> yup running with -d
<jibel> maco, http://paste.ubuntu.com/616060/
<maco> jibel: i think they only tested in kubuntu though. so do have to be sure it doesnt break ubuntu
<jibel> pb with keyboard layout
<jibel> testing ubuntu in parallel
<maco> thanks jibel
 * ScottK wonders how sharp slangasek's debconf foo is.
<ScottK> slangasek: Any thoughts on jibel's pastebin?
<slangasek> hum, looking
<maco> oh wow, PageGtk and PageKde handle getting the list of countries for the kbd WAY differently
<GrueMaster> Hmmm.  Need to figure out how to file a bug on the omap3 kernel usb failure with no keyboard and no apport in the headless image.
<stgraber> GrueMaster: just a thought, can't you: 1) mount the sdcard on a laptop 2) install apport on it 3) boot it 4) remove the sdcard again 5) grab /var/crash/* ?
<GrueMaster> Would be nice if it was the same arch.
<GrueMaster> I'm working it through my babbage3.
<ScottK> No ssh?
<stgraber> yeah, you'd need to copy /usr/bin/qemu-arm-static to the sdcard too before doing a chroot if you do it from x86
<stgraber> ScottK: my guess is that the NIC is usb too :)
<ScottK> That would complicate things.
<slangasek> ScottK: aside from the EPERM on /var/cache/debconf/passwords.dat, which doesn't make sense to me unless debconf is running as the wrong user, I don't see anything amiss with the actual debconf output
<ScottK> maco: ^^^
<ScottK> slangasek: Thanks.
<maco> the stacktrace from jibel shows that its not finding France in the keyboard_names thing
<maco> at least, thats what i think it shows ;)
<maco> hmm it shows in line 833 of his pastebin
<slangasek> GrueMaster: qemu
<slangasek> GrueMaster: qemu-arm-static is surely a better option than /usr/lib/apt/methods/zmodem
<GrueMaster> I'm using chroot on babbage3.
<GrueMaster> Works better than qemu.
<slangasek> maco: so the actual backtrace is because keyboard_names.lang[l]['layouts'] doesn't contain the key u'France', AFAICS
<maco> right thats what i thought
<slangasek> so where does keyboard_names etc. come from?
<jibel> maco, your patch breaks ubiquity in ubuntu
<jibel> it skips partman step
<maco> jibel: crap. can you add "print type(self.prepare_download_updates)"  right before the first if to findo ut what *should* go in the quotes?
<maco> (or whatever that variable name is in case im retyping it wrong)
<maco> hm i guess youd have to comment the if's out too
<maco> to get it to run that print
<slangasek> fwiw, I would think the right way to fix the ubi-prepare bit would be to have prepare_download_updates subclass GtkCheckButton / QCheckBox as needed and provide a common method
<slangasek> I think this is already being done in ubiquity/gtkwidgets.py, ubiquity/qtwidgets.py for classes such as StateBox
<maco> that would probably be less hacky, yeah
<maco> im confused
<slangasek> where at?
<maco> oh nvm. keyboard_names comes from d-i/source/console-setup/Keyboard/MyKeyboardNames.pl apparently. keyboard_names.py is built from it
<slangasek> is language set to C in this context?
<slangasek> ah, here we go; it's France vs. French
<slangasek> is this an API change in d-i?
<maco> so should i just subclass QCheckBox and give it set_sensitive() and set_active() just like gtk has?
<maco> (and then of course set the .ui file to use my new subclass instead)
<slangasek> in a nutshell, yes
<slangasek> is set_sensitive needed for QCheckBox?
<slangasek> er
<slangasek> set_active, I mean
<maco> Gtk has those 2 and QCheckBox doesn't. both are used in ubi-prepare.py
<slangasek> oh, of course it is, those are the two exact methods being called
<slangasek> yeah, ignore me, I'm losing track of method names
<maco> get_active is also used, so will do that one too
<maco> http://paste.ubuntu.com/616084/
<slangasek> looks good to me
<slangasek> also happens to mean we're not touching the common code, so Ubuntu should be fine :)
<maco> yep
<slangasek> the same applies to the prepare_nonfree_software QCheckBox, FWIW
<slangasek> for that we have set_active(), set_property() being called
<slangasek> + get_active()
<slangasek> oh, that may be in a Gtk-specific class though
<slangasek> yeah, that's all done in PageGtk
<maco> ok
<slangasek> so, hmm, maybe I've steered you wrong to suggest subclassing QCheckBox; it looks like the more conventional approach here is to override check_returncode() in PageKDE
<slangasek> set_download_updates() and get_download_updates() are already done that way
<slangasek> well, honestly though, check_returncode() is an awful lot of non-ui-specific code to duplicate
<maco> set_download_updates is def'd after check_returncode, not inside it
<slangasek> yep, that's not actually a problem
<maco> i dont really know what check_returncode is doing
<slangasek> the method definition exists by the time check_returncode() is called, so it would be fine for it to refer to set_download_updates() despite being defined later
<slangasek> so I think what we want is for check_returncode to call set_download_updates() instead of set_active(), and maybe we need a new method defined to abstract self.prepare_download_updates.set_sensitive
<maco> oh. i was looking at teh *other* check_returncode definition. there are two in that file.
 * slangasek facepalms
<maco> this code reminds me a bit of italian food
<slangasek> so PageKde.check_returncode() calls the PreparePageBase.check_returncode(), then does some extra kde-specific handling
<slangasek> the problem being that PreparePageBase.check_returncode() is not UI-independent
<maco> i think the subclassing of QCheckBox seems somewhat less like spaghetti than adding more overrides scattered throughout this file
<slangasek> I'm inclined to agree, but it does defy the existing convention in the code so I'd be reluctant to upload that change without signoff from the ubiquity maintainers
<jibel> maco, http://paste.ubuntu.com/616092/ with patch http://paste.ubuntu.com/616084/ applied
<maco> jibel: it has to berebuilt for changes to the .ui file to have an effect
<maco> qt doesnt use .ui files straight. it has a ui->py compiler
<slangasek> maco: well, QCheckBox also needs to be added to the import line at the top of ubiquity/qtwidgets.py
<slangasek> jibel: ^^
<jibel> maco, ok, how do I recompile a ui file ?
<maco> slangasek: oh so it does
<maco> using pykdeuic4 or pyuic4....grepping for how the ubiquity build process calls it
<jibel> slangasek, thanks, much better with an import.
<maco> oh, did that work without redoing the ui->py thing?
<maco> oh, kde_ui.py import uic, so maybe it could do it
<jibel> maco, there's no more prepare step
<maco> with what applied?
<stgraber> slangasek: hmm, from what I see from the logs the Edubuntu rebuilt is 20110601.1 but so is our current build :) It apparently ended up overwritting the previous build logs, not sure what will happen on cdimage.u.c
<jibel> http://paste.ubuntu.com/616084/ + import QCheckBox
<slangasek> stgraber: it's not done building yet
<slangasek> stgraber: are you saying that the livefs build logs were overwritten?
<slangasek> oh wait
<slangasek> no
<slangasek> so the 20110601.1 ISO build includes the 20110601 livefs build
<slangasek> the 20110601.1 livefs build will go into 20110601.2 ISO... or if there's a mirror sync problem again, 20110601.3
<slangasek> (the 2011601.1 was an ISO-only respin because antimony's mirror was out of sync again)
<stgraber> ah, ok, so we'll get 20110601.2 with the 20110601.1 livefs :) not confusing at all ;)
<maco> jibel: and without the previous patch that had the if type() stuff
<maco> ?
<stgraber> anyway, good to know everything works as expected. /me goes back to waiting for 20110601.2 to show up on cdimage.u.c
<jibel> maco, yes, and then another exit 141 when entering the keyboard step
<maco> jibel: slangasek is working on the 141 thing i think.
<maco> slangasek: is there anything like "perl -c" for python?
<slangasek> I've never heard of -c, what's that?
<maco> jibel: or at least he figured out it was France v. French...and it sounds like it's in d-i itself, not ubiquity
<maco> slangasek: syntax check
<maco> ot
<maco> baj
<maco> technically its for "compile" but...eh...
<slangasek> ah; no idea
<ScottK> Don't think there is.
<slangasek> console-setup itself hasn't changed since natty
<maco> the thing where it skips over broken pages instead of letting you debug them is annoying
<maco> jibel: any debug info anywhere? /var/log/installer maybe?
<slangasek> jibel: was the keyboard layout crash only reproducible with kubuntu?
<jibel> slangasek, yes.
<jibel> maco, http://people.canonical.com/~j-lallement/junk/installer.tgz
<jibel> cjwatson, fixed a similar issue during natty
<maco> slangasek: the gtk version doesnt, afaict, use keyboard_names at all
<slangasek> well, doh
<maco> jibel: on pubi-prepare.py line 198, says
<maco> from ubiquity.qtwidgets import StateBox
<maco> make that   StateBox, CheckBox
<maco> *ubi-prepare.py
<maco> new wrist/hand braces, feels like relearning to type a bit
<slangasek> so the generated keyboard_names.py is completely different between natty and oneiric, despite console-setup being at the same version
<slangasek> ah, but xkb-data is not at the same version
<slangasek> yep, deliberate upstream change in xkb-data, sigh
<slangasek> -            <_description>France - Breton</_description>
<slangasek> +            <_description>French (Breton)</_description>
<slangasek> -            <_description>France - Occitan</_description>
<slangasek> +            <_description>French (Occitan)</_description>
<slangasek> this under the justification "description fixes that make the layout configuration correspond more closely to language and script instead of national boundaries." :P
<slangasek> maco, ScottK: I can offer no quick fix for the keyboard problem; I think the xkb-data upstream changes are probably wrong, but also not easy to revert; and I don't particularly understand the gtk code so don't imagine I can translate that for KDE
<ScottK> OK.
 * ScottK hopes maco will have it solved soon then.
<ScottK> I guess if we have to we can release note "Use live if you want to play with it, use alternate if you want to install".
#ubuntu-release 2011-06-02
<ScottK> maco: I'll be offline for a bit, but I can upload later tonight if you get a fix and no one else is around.
<stgraber> wow, Edubuntu actually installed fine!
<stgraber> and "works" after reboot!
<stgraber> ok, seems like we'll get an alpha then ;)
<skaet> stgraber,  :)
<skaet> Please add a description of what's new and changing in the Edubuntu section of https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview
<stgraber> yep, will do. Though I guess the only "feature" is that we "switched" to gnome-fallback for now ;)
<skaet> ScottK,  can you add the overview of what's changing on the Kubuntu side, and the advice on what's ok to play with, and what to avoid.
<slangasek> GrueMaster: any fixes for armel?
<stgraber> skaet: what's the magic tag for bugs on the wiki again? I thought it was bug:<number> but that doesn't seem to work
<skaet> stgraber,  that should work.
<skaet> go ahead and put it in, and I'll tweak it as I do the rest of the edits if its not working.
<stgraber> skaet: ok, done with my edits.
<skaet> stgraber,  thanks!  :)
<GrueMaster> slangasek: None.
<maco> ScottK: for the kbd thing, if slangasek's stuck, like hell i'm getting any further on
 * maco pulls down daily live build to test against
<slangasek> I'm afk for the next three hours; happy to trigger respins when I return if there's any forward motion on ubiquity
<slangasek> maco: and I think you overestimate my ability to maneuver my way through modern GUI code
<maco> slangasek: you're more likely than i am to figure out the xkb-data part
<maco> the backend did a *thing* and it was wrong!
<maco> ^ this is as far as i got
<slangasek> heh
<maco> now if this iso would download a bit faster i could try again on that patch i gave jibel, but this time with that one other change i said after, i presume, he went to bed
<ScottK> skaet: Kubuntu alternates are fine.  Kubuntu live runs a live session, but no install. If you want to play with it, use the live and if you want to install it, use the alternate.
<maco> im pretty stuck
<maco> ive even got two people who are actually *good* at python getting confused
<ScottK> I think to understand Ubiquity is not a job for casual inspection of the code no matter how good you are.
<maco> well the fact that ubiquity's failure mode is "oh look i hit some python that doesnt make sense in this page. i'll just skip the page instead of doing anything interactive-like that could help debug it" is rather unhelpful
<ScottK> No doubt.
<maco> ScottK: spiv & rockstar are both guessing there's something Qt wants that normal python doesn't care about
<ScottK> Possible.
<ScottK> Maybe you could just look at what the gtk parts use to not need that information and do that instead?
<maco> its that the new derived widget class isnt being recognised
<ScottK> Oh.
<ScottK> I would have guessed that'd be totally pythonic.
<maco> im getting "Unknown Qt widget: CheckBox"
<maco> ScottK: http://bazaar.launchpad.net/~maco.m/ubiquity/791446/revision/4742?start_revid=4742   if you wanna see the current state of my attempt
<maco> though given the keyboard thing, even if i sort this out tonight, the live installs are still buggered
<ScottK> Yeah.
<maco> ScottK: looking at help(uic), i dont think loadUi()
<maco> *can* use custom widgets
<ScottK> Well that might explain it.
<maco> the one other widget defined in qtwidgets.py (StateBox) isnt actually used in any of the qt .ui files
<maco> so i think im back to the "if gtk, do X; if kde, do Y" code
<ScottK> Lovely.
<ScottK> Without a solution to the keyboard problem, I think it's not a rush.
<slangasek> maco: there are other custom widgets in the .ui file, to be sure
<maco> slangasek: there's one, and its unused
<slangasek> oh, heh
<slangasek> wait, no it isn't
<maco> er i mean in qtwidgets.py, there's one, and it's unused
<maco> StateBox's *gtk* version is used in the gtk .ui files
<slangasek> oh
<maco> StateBox is not used in the qt .ui files at all
<slangasek> well, doh
<maco> guess its just totally left out of the ui file and then programmatically added later
<slangasek> right, so overriding the PreparePageBase in the subclass seems to be the way to go?
<maco> http://bazaar.launchpad.net/~maco.m/ubiquity/791446/revision/4744?start_revid=4741&remember=4741&compare_revid=4741 well this is what appears to be *working*
<maco> its same as the one that was confirmed to work in kubuntu but not in ubuntu, except now with the correct string being compared to type()'s output so that the ubuntu one works too now
<ScottK> Does the keyboard thing affect everyone or just people in france?
<ScottK> maco: ^^^
<maco> taco and charlie both hit it
<ScottK> OK.
<maco> but they dont have tracebacks
<maco> well actually
<maco> i suspect if they looked in /var/log/installer/debug instead of just in syslog, maybe they'll have one?
<maco> im booting a kubuntu iso now
<ScottK> Cool.
<Laney> can someone do autosync and (after it's all built) new-binary-debian-universe and new-source | grep haskell in the absence of Colin? :-)
 * Laney doesn't ask for much
<ScottK> Laney: I think we won't do autosync until after Alpha 1 is released.
<Laney> forgot about that. Isn't that today?
<ScottK> Sometime.
<Laney> fair
<ScottK> skaet: It looks like no chance we'll get installs using ubiquity-kde working for Alpha 1, so the status I gave you last night is the 'final' one.  Is there anything else you need from me?
<charlie-tca> Should there be a note in the overview about the oversized images (can use DVD or USB) ?
<ScottK> Probably.
 * ScottK wishes there was an equivalent of aptitude why to answer the question 'why is package foo in packageset bar'.
<charlie-tca> skaet: no significant changes for Xubuntu. Release Notes done.
<skaet> good morning.
<skaet> charlie-tca,   Thanks!
<skaet> ScottK,  If you could add in an overview, and things to avoid (ie. status last night)  to the https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview,  that would be appreciated
<ScottK> Will do.
<charlie-tca> You are welcome
<ScottK> skaet: Done.
<ScottK> Let me know how that is.
 * skaet looking
<skaet> ScottK:  looks good.   Thanks!
<ScottK> Great.  You're welcome.
<micahg> ScottK: if a packageset is wrong, it can be changed
<ScottK> micahg: Agreed, but sometimes ones I thought were wrong turned out to make sense once I understood the dependency relationship.
<ScottK> The current process "ping cj watson and ask" doesn't scale very well.
<micahg> ScottK: well, I think I started filing bugs for my changes, maybe we should make that the procedure
<ScottK> Maybe, but the thing I'm after is making it easier to figure out why.
<ScottK> The current case in point is why tracker is in the Kubuntu packageset?
<micahg> that really sounds like a goof...
<ScottK> Exactly.
<ScottK> I suspect once the dependency path is analyzed it'll make some kind of sense.
<cjwatson> the reason you're finding it hard to analyse is that there used to be a reason but it has gone away
<cjwatson> I've pushed a refreshed copy of the package set data to LP, removing tracker from Kubuntu
<cjwatson> (though I agree this doesn't solve the general problem)
 * micahg wonders what happened to cjwatson
<micahg> oops
<maco> are the packagesets kept in bzr?
<micahg> cjwatson's vacation :)
<cjwatson> my vacation is part housework and part misc Debian catchup
<cjwatson> when I get bored of housework I sit down for a bit
<ScottK> cjwatson: Thanks.
<cjwatson> maco: no, they're derived from the archive
<cjwatson> well, there are a few exceptions in a bzr tree that I *really* should push somewhere publicly at some point, along with the scripts to derive from the archive
<skaet> ScottK,  have pruned down the images in the iso tracker - can you please confirm that the kubuntu ones still there are the ones to ship for Alpha 1?
<ScottK> Looking.
<ScottK> I see the package set update got tracker off my list, but got me hunspell-dict-ko
<ScottK> So the mystery continues.
<NCommander> morning all
<ScottK> skaet: The right images are there.  I note there's no Kubuntu upgrade on the tracker.  Not a concern for Alpha 1, but should be fixed.
<skaet> ScottK,  fixed.  Kubuntu upgrade added onto the tracker.    Are we going to be able to get more testing on the Kubuntu images today, or are we good to go with them now?
<ScottK> skaet: I think for Alpha 1 they are tested enough.
<ScottK> I'd rather push them out the door and get to work on the stuff we're running behind on.
<ScottK> Actually I think having a live image at all for Alpha 1 is above average.
<maco> it is
<maco> normally live isnt til alpha 2
<skaet> :)   (and we have ARM images this time around too..... ;) )
<ogra_> one less than in natty
<ogra_> natty A1 had both subarches :)
<skaet> ah well...
<ogra_> skaet, btw, https://lists.launchpad.net/ac100/msg00015.html in case you are intrested :)
 * skaet breaks out in a big grin...  looking forward to playing this weekend.  :)
<skaet> NCommander, ogra_ -  I'm about to drop the omap3 images from the ship list, based on the fact that they're non functional.  Any reason not to?
<ogra_> no reason
<ogra_> go ahead
<NCommander> push the button
<skaet> :)
<skaet> ogra_, Ncommander - omap3 images pulled.
<ogra_> thanks
<skaet> slangasek, cjwatson,  could you disable the alpha-1 milestone now in https://launchpad.net/ubuntu/oneiric
<slangasek> done
<skaet> thanks!
<skaet> Alpha 1 is has been released.    Thank you all.  :)
<barry> skaet: \o/
<highvoltage> yay
<highvoltage> edubuntu is weird since it's probably the only distribution ever to ship with the gnome 3 fallback mode as default
<skaet> :)
#ubuntu-release 2011-06-03
<cjwatson> Laney: http://people.canonical.com/~ubuntu-archive/transitions/ghc.html has stopped looking very healthy
<Laney> cjwatson: yeah :(
<Laney> I uploaded a new GHC :(
<cjwatson> did its provides get bumped or something?  can they be unbumped? :)
<Laney> I already did my ritual cathartic moan about Launchpad getting binNMU support
<cjwatson> yeah, good luck with that
<Laney> no they can't I'm afraid, the ABI hashes have all changed (I presume because this one is built with ghc 7 instead of ghc 6)
<cjwatson> (I did the autosync and new-source, but given that, I don't know how much it will help)
<Laney> likely not much
<cjwatson> well, I'm going out for a while, but let me know if you want help with mass no-change uploads ...
<Laney> at least it's no-change rebuilds this time
<Laney> the tracker should be easier than the graph in this regard
<cjwatson> yeah
<cjwatson> just mass-upload a level at a time
<Laney> yep
 * Laney sighs
<charlie-tca> Are we going to kick daily builds on again now?
<skaet> charlie-tca, yes, they should be on again.
<charlie-tca> They didn't build today
<skaet> slangasek, cjwatson, ^ could one of you look into this?
 * charlie-tca making trouble again :-(
<skaet> lol,  good sort of trouble.  Thanks charlie-tca!
<charlie-tca> no problem
<cjwatson> skaet,charlie-tca: done
<charlie-tca> cjwatson: Thank you
#ubuntu-release 2011-06-04
<charlie-tca> Xubuntu alternate images failed to build today, many of the same errors in the build log:
<charlie-tca> W: Failed to fetch file:/srv/cdimage.ubuntu.com/ftp-universe/dists/oneiric/main/binary-amd64/Packages.bz2  Hash Sum mismatch
<charlie-tca> make: *** [apt-update] Error 100
<ScottK> charlie-tca: Usually those are transient.  Unless if happens tonight too, I wouldn't worry about it.
<charlie-tca> Thanks, ScottK. I didn't know if they would have to do anything to the server to make it work
<ScottK> Usually that's just a timing issue where the packages file is out of sync.
#ubuntu-release 2011-06-05
<ScottK> I would appreciate it if someone could point me to where the final Kubuntu powerpc image for Natty landed?
 * tumbleweed waves, probably should have stuck my nose in here a while ago
#ubuntu-release 2012-05-28
<bjf> cjwatson: i was just copying kernel packages from the ppa to -proposed and ran into an error
<bjf> cjwatson: the error indicates that apw doesn't have upload rights for linux-meta-lts-backport-oneiric
<stgraber> bjf: unless someone poked me or cjwatson, it's indeed pretty likely that this source isn't in the kernel packageset
<apw> stgraber, hrm, yeah that one is definatly one we need added if you are able
<stgraber> right, the linux-lts-backport-* entries are there but linux-meta-lts-backport-oneiric is missing
<stgraber> added
<apw> thanks :)
<bjf> stgraber: is that per dev or is there the devs added to a "kernel packageset" team
<cjwatson> bjf: https://launchpad.net/~ubuntu-kernel-uploaders
<stgraber> bjf: it's a package set, so when added, anyone who's in the ubuntu-kernel-uploaders team gets upload rights for these
<bjf> thanks
<Laney> ScottK: we're supposed to DIY backports now, using backportpackage
<Laney> oops, please reject 0ad-data
<Laney> I borked the changed-by
<Laney> that one should be better
<cjwatson> Laney: rejected the old 0ad-data - don't have time to look at the new one just now though
<Laney> ok, thanks
#ubuntu-release 2012-05-29
<xnox>  -queuebot:#ubuntu-release- New source: boost-mpi-source1.49 (quantal-release/primary) [1.49.0-3ubuntu1]
<xnox> Can somebody accept ^^^^, this is the 'universe' edition of the boost1.49 package to build mpi dependant debs.
<xnox> I prepared the package, ScottK reviewed & sponsored it.
<xnox> It will fix a few ftbfs & will help with boost1.49 transition, which I was hoping to finish before Alpha 1.
<infinity> xnox: I'll look at it.
<xnox> infinity: thank you.
<infinity> xnox: I assume it's pretty much just a version bump of boost-mpi-source1.46?
<xnox> infinity: yes.
<xnox> build from the matching complete version of boost1.49
<xnox> (hence the errors from lintain about using matching source-version number, when the other debs are, in fact, in the main/boost1.49)
<infinity> xnox: Accepted, BTW.  queuebot was away and didn't tell you. :P
<xnox> infinity: thanks =)
<xnox> queuebot: wakey wakey =)
<xnox> infinity: I've marked bug #1005179 as fix released
<ubot2> Launchpad bug 1005179 in boost-mpi-source1.46 "Please upload boost-mpi-source1.49" [Wishlist,Fix released] https://launchpad.net/bugs/1005179
<ogra_> infinity, any progress wrt arm livefs-builder chroots ?
<seb128> could software-center from precise-proposed be moved to updates earlier than the week period? it fixes a regression from the previous SRU (which moved to updates) which is the most reported bug on errors.ubuntu.com
<seb128> SpamapS, RAOF, slangasek, other SRU members: ^
<seb128> SpamapS, RAOF, slangasek, other SRU members: ^
<infinity> seb128: See the bug, it seems to still be lacking verification.
<ogra_> infinity, !
<ogra_> infinity, did you see my ping above ?
<seb128> infinity, it's ridiculous to let a regression which reached -updates and is our most reported bug non solved this way...
<infinity> ogra_: I did, yeah.  Remind me when it's not 10pm? ;)
<ogra_> since you are at connect, can you tell me who to work with to get these chroots fixed ?
<ogra_> and we need to talk about the flash-kernel sync/merge/move ... i would like to do it before A1
<infinity> seb128: Uhm, I'm happy to move it early, but the bug doesn't show that anyone's tested that the upload actually fixed the bug.
<infinity> seb128: Hint, you could do that. :P
<seb128> infinity, well, it comes down on "do you prefer to keep a regression in updates that trust mvo's fix and try if that fixes it"?
<infinity> seb128: In the time you're spending arguing about it, you could have installed the update and reproduced the bug (or not) surely?
<seb128> infinity, yeah, I could, I'm a bit annoyed that mvo asked here on friday (or thurday) that we fix up the screwage and that we let the regression sit in for 5 days
<seb128> infinity, right, that would not solve the issue that people are happy to keep regression in -updates that way though
<ogra_> wasnt there an emergency process for such cases since we blew up xorg in dapper in an SRU ?
<infinity> seb128: I would have happily pushed it through same-day, if it had been tested.
<seb128> shrug
 * ogra_ thinks there was something about this on the canonical wiki
<infinity> ogra_: Even in the most extreme cases, we still require a light bit of QA/verification before we just jam it down user's throats.
<cjwatson> Blowing up xorg in dapper is what prompted the introduction of the heavyweight SRU process in the first place.
<seb128> I'm testing it now, but options were to either keep a regression unresolved and sit on it or to try a fix from the maintainer
<ogra_> infinity, true
<seb128> infinity, I guess another option would have been to roll the SRU out in some way
<seb128> infinity, still I would like to figure why we considered fine to keep things in that state rather than chasing a tester if that's what blocked the regression fix
<infinity> seb128: No one's "sitting on it", we're happy to move, if people actually tested it.  That's really the bottom line here.  I won't argue that we don't need more people testing (we do), but if you have a personal interest in an SRU, doing the testing yourself isn't all that much to ask?
<seb128> infinity, I don't have a personal interest in it
<infinity> You seem to have made it personal. ;)
<seb128> infinity, I've a personal interest it us not letting regression in LTS stable update unaddressed
<infinity> Anyhow, I've been barely around since it was accepted, so I'm going to feign ignorance about what's happened in the last few days, all I can go by is the bug log.
<seb128> infinity, yeah, because I though that issue was handled last week and I still see it on top of the reported issues list today
<cjwatson> "why we considered fine to keep things in that state rather than chasing a tester" - you're assuming agency where there is none, I think
<infinity> Anyhow.  I'm going to wander out for a smoke.  If you've managed to reliably verify it by the time I get back, I'll happily promote it.
<cjwatson> i.e. the problem is that nobody took ownership of the fact that there was a regression
<cjwatson> Nobody is sitting at their desk cackling malevolently at how they get to keep the regression in place :-)
<infinity> This all reminds me that I need to write up some bits and bobs based on the mishmash of stuff we got out of the agile-sru session.
<seb128> cjwatson, right, I guess the bottom line is "should we have somebody taking ownership of regressions"
<cjwatson> Yes!  That was the point of dealingwithcrisis and friends
<infinity> One of those things involves making sure that uploaders stay active in the life of an SRU.
<seb128> cjwatson, and if the reply is "yes", who and do we have a process?
<cjwatson> The answer isn't to compound the problem by promoting furthere fixes without testing.
<ogra_> dealingwithcrisis ! that was the name i couldnt remember before
<cjwatson> https://wiki.canonical.com/UbuntuEngineering/DealingWithCrisis
<cjwatson> seb128: ^-
<seb128> cjwatson, right, I get I see it as a failure that mvo asked for help there last week and nobody picked it up
<seb128> cjwatson, I'm not sure I consider that bug important enough to warrant doing the full crisis stuff
<cjwatson> I think it's possible/reasonable to follow parts of that process without the whole thing
<seb128> cjwatson, but for sure it should have been tracked closely to resolution
<cjwatson> We don't have to do the whole business of suppressing further distribution of the update if the bug doesn't warrant that
<cjwatson> But it has useful advice/process on making sure that somebody stays on top of the problem
<seb128> ok, noted for next time, I though that process was for real crisis
<seb128> I'm not sure I qualify software-center have a regression lot of users hit but which doesn't break the software to be one
<seb128> but it's an issue and an annoyance for sure
<infinity> There are varying degrees of crisis.
<cjwatson> We haven't really executed that process for some time (which is a good thing), but one of its virtues is that if somebody has the baton on dealing with it right now, they don't get to finish their day without handing off to somebody else.
<seb128> well anyway, the bug report about the regression has no steps to reproduce and mvo is not around
<infinity> Anyhow, the big issue here is just that people needed to stay on top of it.
<seb128> it's just a frequently showing on errors.ubuntu.com
<seb128> so not sure how to drive it to verification-done...
<cjwatson> As a minimum we should have regression testing.
<seb128> I would assume that mvo knows what he's doing (and he got review for the fix as well)
<infinity> If it's not too easy to reproduce, waiting on mvo might be fine.  (and this is a reason we need test cases...)
<cjwatson> You know, it's still actually possible to use software-center, that kind of thing.
<seb128> infinity, we can't always come with testcases for apport bugs
<xnox> what's the bug number I can verify - I have precise VM on & I think software-centre bug is affecting me as well
<seb128> cjwatson, right, I assume that having it in 5 days in proposed without new issues reported is a good indication that we didn't break it much
<infinity> xnox: https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/1002271
<ubot2> Launchpad bug 1002271 in software-center "REGRESSION: crash in cell renderer" [Medium,In progress]
<cjwatson> Not without an explicit ack, no.
<infinity> xnox: You tried to verify it on quantal, apparently, which went poorly for you. :P
<cjwatson> We have no measurements of who's using what in -proposed.  That's a verification-by-prayer approach.
<xnox> infinity: aha =) so yeah I am affected.
<cjwatson> The aging period was meant as additional insurance, not as an end in itself.
<infinity> seb128: And yeah, I feel the pain with backtrace bugs.  I know I've fixed my fair share of segfaults in C based on backtraces that I couldn't reproduce, I'm sure python's no different.  Still, it would be nice if somene could reproduce it.
<infinity> seb128: But failing that, as Colin notes, regression testing would at least be nice.
<seb128> infinity, right, I've been cross posting on #ubuntu-devel,desktop,bugs
<seb128> I can ack it still works for me
 * xnox goes to try again, but in the precise VM this time.
<infinity> That's helpful data.
<seb128> but let's see if I can get a few extra feedback and maybe somebody who has the issue to confirm the fix
<infinity> Hopefully, xnox can actually reproduce and verify.
 * infinity goes for that smoke now.
<xnox> 5.2.2 crashes in Precise VM
<xnox> wait, that was quantal
<xnox> sorry =)
 * xnox downloading stuff
<seb128> xnox, for the record bug #1000238 is the quantal issue you have been hitting
<ubot2> Launchpad bug 1000238 in software-center "Software-Center crashes on starting" [High,In progress] https://launchpad.net/bugs/1000238
<xnox> thanks.
<infinity> mdeslaur: Should I assume from your comment on the software-center bug that you can't browse categories with 5.2.2, but you can with 5.2.2.1?
<mdeslaur> infinity: I didn't experience the bug with 5.2.2, but my understanding is that simply browsing categories makes the bug occur.
<infinity> Hrm.  Yeah, I can't get 5.2.2 to die here. :/
<seb128> infinity, cjwatson, mdeslaur: hggdh had the issue and confirms that the update fixes it
<mdeslaur> ah, good
<infinity> \o/
<infinity> Good enough for me.
<hggdh> marked -done on it
<hggdh> go for the kill
 * infinity decides it's time to go watch cartoons and fall asleep.
 * SpamapS reads backscroll on software-center issue and is bummed out because its mostly just that we, the SRU team, are a bit behind
<seb128> SpamapS, hey, don't get bummed, it was not especially a SRU team issue, rather a miscommunication which did lead to move the buggy version to -updates and then lack of follow up on the update which fixed that issue (which is a release team issue as much as a SRU team one) ... well anyway being sorted at the end, next team we will do proper escalation when that happens so things are better tracked
<ScottK> skaet: It might be useful to take a look back after 12.04.1 and see how much SRU activity can be tied back to late feature additions in precise.  It might give us a gauge on if we're being too aggressive.
<ScottK> (I'm mentioning this, since I just found such a case)
<skaet> ScottK,   yeah,  keeping a list of this as we go along would be interesting data for the next feedback meeting.     Possibly one for the Precise LTS  (in addition to the Quantal) may well be appropriate.
 * skaet pondering best method for capturing. 
<ScottK> OK.  It looks like Bug #993672  is tied to the new data downloader.
<ubot2> Launchpad bug 993672 in update-notifier "Ships malformed interactive upgrade hook which causes translations to be shown in the dialog" [High,Fix committed] https://launchpad.net/bugs/993672
<ScottK> So there's one for you.
<skaet> Thanks.
<knome> skaet, hey :)
<knome> skaet, want to approve xubuntu blueprints? :)
<slangasek> seb128: so I approved the updated software-center in based on a conversation with Gary, and I told him that yes, we would ignore the aging requirement for this SRU - but that we still needed SRU verification
<slangasek> not following the SRU verification process is how the *previous* regression made it to -updates
<skaet> knome,  bounce me the links in a pm, and I'll work through them now.
<seb128> slangasek, I guess my main concern is that nobody actively tracker a tester or talked to qa about needing to get that one tested
<slangasek> qa doesn't test SRUs
<seb128> slangasek, so we stayed with a regression from -updates topping errors.ubuntu.com when we had a fix available that we were not able to deploy
<slangasek> my understanding was that Gary was going to follow up to get it tested
<slangasek> no one had verified that it was actually a fix yet, or that it didn't introduce other regressions
<ogra_> probably QA should get resources to actually do the SRU testing then :)
<ogra_> at least for main
<seb128> slangasek, well, qa doesn't test SRUs, but we ought to find the resources somewhere to deal with regression we land in -updates especially in a LTS
<slangasek> yes, and it was my understanding that Gary was doing that
<slangasek> so evidently there was a misunderstanding on this point
<seb128> slangasek, ok, I will check with him what went wrong there
<seb128> slangasek, I still think that sru regressions (especially in a lts) should be release team tracked as well
<seb128> slangasek, I guess what went wrong there is that nobody considered that important enough to escalate it as a real incident, seems that was wrong to not do so after fact
<seb128> slangasek, since without that we didn't get proper tracking and dropped the ball
<utlemming> so it looks like http://changelogs.ubuntu.com is not being updated for Precise. LP: #1005985
<cjwatson> utlemming: I believe mvo is about the only person who can do anything about that
<cjwatson> unless IS can
<scott-work> skaet: did you get a chance to make the topic-q-ubuntu-studio blueprint?  i was hoping to add our blueprints to it
<knome> scott-work, you can create that yourself too :)
<scott-work> can i?  i shall!
<skaet> scott-work,  yup you can,  but I just did it.
<skaet> https://blueprints.launchpad.net/ubuntu/+spec/topic-quantal-flavor-ubuntustudio
<knome> heh. :)
<scott-work> oh, outstanding, i'll quit the one i was making :)
 * knome notes scott-work that he's last, again; https://blueprints.launchpad.net/ubuntu/+spec/topic-quantal-flavor-xubuntu ;)
<scott-work> lols, yep
<stgraber> SRUs!
<knome> skaet, you there?
<stgraber> bdmurray: I thought we agreed at UDS to get rid of the stable/development fix section and just check the bug tasks? (added the sections to my pending srus anyway...)
<bdmurray> stgraber: the comment didn't mention either of those only 'statement of impact, test case and regression potential'
<bdmurray> stgraber: slangasek should be updateing the SRU wiki page sometime
<stgraber> bdmurray: I guess I should have read the comment, just clicked on the URL :)
<bdmurray> stgraber: well they really should agree with each otherâ¦
<cjwatson> xnox: before I forget - I got the LP Debian import cron jobs moved one hour later, which should have the effect of reducing the mean latency by around four to five hours, I think
<ScottK> Please don't accept the qt4-x11 binaries before we get a fixed i386 build.
<maxb>   
#ubuntu-release 2012-05-30
<infinity> ScottK: What will fix x86? A new upload?
<infinity> ScottK: If so, you can just reject the other binaries.
<infinity> ScottK: Oh, hrm, I wonder why our gcc appears to be upset about -fuse-ld...
<ScottK> infinity: I think -fuse-ld is fine, it's -fuse-ld=gold that's trouble.
<ScottK> New upload is on the way.
<ScottK> Rejected the old one.
<ScottK> New qt4-x11 on the way.  That should be OK to accept once it's built.
<infinity> ScottK: The whole point of -fuse-ld is to pass =gold. :P
<ScottK> Oh.
<infinity> But that patch might not be upstream yet, it might only be in some dists.  I'll talk to doko when we're not being quiet in a session.
<infinity> doko: Or, you could read up and comment on this, despite the fact that you're sitting next to me. :P
<doko> infinity, you should use -B/usr/lib/compat-ld/ instead
<infinity> doko: Is there a reason we're not carrying the -fuse-ld patch?
<infinity> doko: More and more upstream code seems to be using it, and we've patched it out here and there.
<xnox> cjwatson: ok, thanks. =))) quicker debian imports are always good.
<ogra_> infinity, so whom do i have to talk to about the arm chroots ?
<ogra_> (we really need to get the images building and i also want to switch to the new flash-kernel for A1)
<infinity> ogra_: Chasing webops now.
<ogra_> infinity, whom do you talk to over there, i'll happily take over if you want
<infinity> Whoever the current vanguard is.
<ogra_> is there a special channel or just #is ?
<infinity> #webops
<ogra_> oh, ok
<ogra_> infinity, k, now that this part is off my table, how about doing a plain sync of flash-kernel, then changing the packaging for the db and watch the fallout ?
<infinity> That sounds potentially messy...
<ogra_> (server team is warned about it and i think robbie already looks into the debian f-k)
<ogra_> well, the arches we used to support should all work OOTB
<ogra_> and i think we need images to work with to test changes properly
<infinity> Except armada and highbank.
<ogra_> right
<ogra_> but i warned the server team already
<infinity> omap/omap4, mx5, and ac100 should all be good?
<ogra_> and i plan to write an announcement mail to ubuntu-devel
<ogra_> yeah
<infinity> I'm not sure an announce is worth the effort.
<infinity> I don't announce every scary sync/merge I do. ;)
<ogra_> mx5 is debians buildd platform for hf, so that should definitely work, ac100 was ported (and improved) from my hacks in ubuntu, omap and omap4 should work too
<infinity> Debian may not install mx5 the same way we do.
<ogra_> well, i know that people like TI realy on their f-k hacks
<infinity> I wouldn't count on it.
<ogra_> *rely
<ogra_> so they should be informed that the old script is gone
<ogra_> i count on nothing ;) thats why i want the time to test it with actual images before A1
<ogra_> it would all break anyway once we switch to live ... i dont think flash-kernel-installer has all bits and pieces for all aarches yet, not even in our version
<ogra_> so i think doing the big step first is the best move and wont cause more havoc than not switching (and i dont want to have to fix our old f-k)
<tkamppeter> Anyone around from the SRU team? Can someone approve my ptouch-driver and system-config-printer SRUs? I get lots of bug reports of users due to printing problems.
<xnox> How often do transition trackers update?
<cjwatson> Half-hourly IIRC
<xnox> thanks
<xnox> Page generated on Wed, 30 May 2012 08:54:43 +0000
<xnox> every 4hours based on 'debian dinstall'? =)))
 * cjwatson blames something else
<cjwatson> Need to finish deploying the new tracker anyway, argh.  Probably not much point nitpicking the current one.
<xnox> =))))) yes please
<xnox> we will get the overview page and the % trackers =))))
<xnox> it updated just now.
<xnox> infinity: thanks for boost ;-) another one bites to dust.
<infinity> s/boost/glob2/ ?
<xnox> infinity: well yeah, helpgin boost transition.
 * xnox my left hand is faster than my right hand
<infinity> No comment.
 * xnox 'gin' vs 'ing' typpo.
 * ogra_ tries to get a bottle of acid in his right ear to clean out the images in his brain now
 * infinity goes back to relaxing with a movie.
<infinity> ogra_: *snicker*
<xnox> jamespage: about java7 transition: do we have a tracker for that? (if one is possible) e.g. http://people.canonical.com/~ubuntu-archive/transitions/boost1.49.html
<jamespage> xnox, I've been trying to think of a good way track the transition - I think part of it could be covered by the transition tracker (anything that depends on openjdk-6-*)
<jamespage> but tracking anything that depends on the default-* packages does not work that way (I think).
<xnox> jamespage: source build-dep and/or binary depends ?
<jamespage> xnox, spot on
<xnox> jamespage: we also have .edos-check installable?
<xnox> would that help?
 * xnox knows little java packaging intrisics
<jamespage> xnox, what does that do?
<xnox> jamespage: e.g. http://people.canonical.com/~ubuntu-archive/transitions/ocaml.html
<xnox> let me try to explain, one sec.
<tumbleweed> do things that build-depend on default-* need any attention at all?
<xnox> jamespage: explaination / definition is here http://edos.debian.net/edos-debcheck/
<xnox> jamespage: something like `if you attempt to apt-get install $pkg, the said $pkg may succeed in installing, as in it has no conflicts`
<jamespage> xnox, ah - I see
<jamespage> xnox, probably of limited value
<xnox> does that help? or does the default-* stuff will simply install fine, but will not work.
<xnox> jamespage: we can check for min dependency. Does the new default-* stuff generate 'depends: default-* (>> 7.X.Y)'
<jamespage> tumbleweed, xnox: with regards anything that BD's on  default-jdk its really just a no-change rebuild to ensure it still builds
<tumbleweed> you don't need to no-change rebuild for thta
<jamespage> xnox, no - packages don't generate a versioned dependency in that way
<jamespage> tumbleweed, I agree that an upload is not required specifically to check it builds
<xnox> jamespage: have you seen http://qa.ubuntuwire.com/ftbfs/ ? a couple java packages are there.
<tumbleweed> I thought javahelper did do things like that. It creates dependencies like java6-runtime
 * tumbleweed has been fixing a couple of those FTBFS pcakages (places where the debian maintainer build-deps on openjdk 6)
<jamespage> tumbleweed, yes it does - but javahelper only accounts for a small percentage of the total number of java packages
<tumbleweed> true
<jamespage> xnox, yeah - been working through main first - nearly there - on the last few hard ones at the moment
<jamespage> have to admit that `reverse-depends -b default-jdk -c universe -l | wc -l` was a bit larger than I anticipated
<jamespage> 788 packages - yikes
<ogra_> pfft, thats less than 1% of the archive
<jamespage> xnox, tumbleweed: is there a way to pull a straight list of packages which FTBFS? I'd like to cross reference those against the r-b-d's of default-jdk
 * xnox sorry no clue
<tumbleweed> jamespage: http://people.ubuntuwire.org/~stefanor/lp-ftbfs-report/historical/primary-quantal.csv
 * ogra_ thinks the ubuntuwire page is the most reliable way to find FTBFS
<ogra_> unless you write a script with lplib that loops over all recent uploads and checks them or some such
<jamespage> tumbleweed, ta
<tumbleweed> look at lp:svammel if you want to file bugs / do something with the things programmatically
<Laney> infinity: Do you know if you'll be able to get to bug #888665 at some point soon? I think perhaps ignoring NotAutomatic for backports builds is fine. micahg?
<ubot2> Launchpad bug 888665 in launchpad "Backports can't build-depend on other backports" [Critical,Triaged] https://launchpad.net/bugs/888665
<Laney> We're hitting it relatively often now
<cjwatson> bdmurray: rejecting your duplicate apport sync to precise-updates
<bdmurray> cjwatson: duplicate? oh I'd run sru-release and then asked slangasek to approve it
<cjwatson> well it'd been published and there was also a sync in the queue
<slangasek> oh
<cjwatson> LP isn't too good at avoiding dups here
<slangasek> so running sru-release puts it in the approval queue (even) if you're not a member of ubuntu-sru?
<bdmurray> slangasek: yes, clint approved a couple for me yesterday
<slangasek> ack
<cjwatson> yep, anyone can copy
<cjwatson> well anyone with upload rights to the package
<cjwatson> same rules as syncing from Debian
<tkamppeter> slangasek, cjwatson, I have rather urgent SRUs for printing, I am getting many bug reports about these problems. Can you approve my ptouch-driver and system-config-printer SRUs? And can you move cups-filters to -updates?
<xnox> cjwatson: add two factoroids about this new feature? And pipe it to everyone who asks? =)
<cjwatson> xnox: can't say I was ever a fan of losing information in IRC bots' brains
<xnox> =)
<cjwatson> not all the cups-filters bugs have been verified, according to the report
<cjwatson> and I don't see your ptouch-driver upload in the queue
<cjwatson> I'm sure there must be a more pythonic approach to that sort than a giant list of if statements, but well, maybe not for SRU
<cjwatson> accepted system-config-printer
<tkamppeter> cjwatson, the two cups-filters bugs which are not verified are simply not verified because the original reporter is not available for one bug and the other is a private support bug and probably not visible for the original reporter. Should I decaouple these somehow from the SRU? And how should I do it?
<cjwatson> There are four unverified bugs, according to the report
<knome> skaet, ? :)
<skaet> knome,  hiya
<skaet> ?
<knome> hey! may i PM?
<tkamppeter> cjwatson, forgot the dput for ptouch-driver. Done now.
<skaet> knome,  k
<tkamppeter> cjwatson, ptouch-driver has arrived now.
<cjwatson> tkamppeter: bug 668800, where the original reporter says that the fix doesn't help him, although it also doesn't appear to regress; bug 862167 which is private but the reporter is in Canonical Support and should be pressed to follow up on verifying that; bug 992982 which is a dup and as you say the original reporter is unavailable right now; and bug 997728 which you disconnected
<ubot2> Launchpad bug 668800 in cups-filters "Printing speed problem" [High,Fix committed] https://launchpad.net/bugs/668800
<ubot2> Launchpad bug 992982 in cups "Network printing fails. Worked before upgrade to 12.04 (dup-of: 973270)" [High,Fix committed] https://launchpad.net/bugs/992982
<ubot2> Launchpad bug 973270 in system-config-printer "Printer does not provide REQUIRED job history." [High,Fix committed] https://launchpad.net/bugs/973270
<ubot2> Launchpad bug 997728 in cups-filters "Ubuntu port of acroread degrades images (works on Win7)" [High,Invalid] https://launchpad.net/bugs/997728
<cjwatson> tkamppeter: so I don't quite know, how much is 862167 just another instance of an identical bug somewhere else?  I haven't read through all these
<tkamppeter> cjwatson, bug 668800: person for whom I linked it is Lorenzo Bettini (bettini), comment #42, but seems to have disappeared. What to do?
<ubot2> Launchpad bug 668800 in cups-filters "Printing speed problem" [High,Fix committed] https://launchpad.net/bugs/668800
<cjwatson> but the original reporter was oliver-raincode
<cjwatson> So I think it doesn't fix his problem and you'll need to reopen the bug after this change goes to -updates - correct?
<tkamppeter> cjwatson, for oliver-raincode it turned out that his problem is different, he has no PostScript printer, what to do then.
<cjwatson> because it's his bug, not Lorenzo's
<cjwatson> Lorenzo was just randomly dogpiling a bug, he doesn't get to take ownership of it
<tkamppeter> cjwatson, should I reupload the package with these four bugs removed from debian/changelog?
<cjwatson> So, as I say, I think you should reopen 668800 after this update goes out (there's no real way to stop it auto-closing the bug now)
<cjwatson> No, don't reupload, waste of time
<cjwatson> What about 862167?
<tkamppeter> cjwatson, so I will reopen these four bugs (or make cups-filters invalid in them if it has turned out to be not actually cups-filters.
<cjwatson> Basically I need a clear statement that all the bugs are either verified or have been made no worse, that being the point of the verification period
<cjwatson> This is easy if the report is all green
<cjwatson> If that's not the case then the uploader needs to help out by clarifying the situation
<tkamppeter> Bug 862167 is a private support bug. It seems that the original reporter of the bug is a support person and not the person who has the problem. And the support person did not forward the question about testing to the customer. I think I make the cups-filter task invalid here, too.
<tkamppeter> cjwatson, on none of the bug reports I got an answer that the situation got worse, everyone who answered and was really affected by this bug answered that his problem got solved.
<tkamppeter> cjwatson, bug 997728 turned out to be a bug in Acroread and I have marked it invalid for cups-filters earlier.
<ubot2> Launchpad bug 997728 in cups-filters "Ubuntu port of acroread degrades images (works on Win7)" [High,Invalid] https://launchpad.net/bugs/997728
<cjwatson> right, as I said
<cjwatson> OK, it sounds like it's good to copy
<tkamppeter> cjwatson, marked cups-filters tasks for Precise in the four mentioned bugs as invalid.
<tkamppeter> cjwatson, thanks.
<tkamppeter> cjwatson, I will sort out the answers for the CUPS SRU soon. There are also no new regressions, but also bugs which did not get fixed by the SRU (and for which I did the system-config-printer SRU).
<cjwatson> those cups-filters tasks were marked Fix Released as a result of accepting the upload into -updates; perhaps you could set them back to Invalid
<seb128> @SRU team: could you copy gtk+3.0 as well? the bugs listed are verified and it is in proposed for 9 days
<cjwatson> it's better to wait until the copy to -updates is done :)
<seb128> it would make room for another upload, I've other fixes I would like to upload
<cjwatson> seb128: yeah, it was next on my list ...
<seb128> cjwatson, thanks ;-)
<tkamppeter> cjwatson, will do, as soon as I get "Fix Released" notifications.
<slangasek> cjwatson: bug #863741> looks like we need a no-change rebuild of rpcbind after all to fix this, as even though the priority is bumped in the precise-updates Packages file, apt entirely ignores the second source for the same package and takes the prio info from the first record it finds :P
<ubot2> Launchpad bug 863741 in nfs-utils "apt doesn't want to replace portmap with rpcbind on upgrade" [Medium,Fix released] https://launchpad.net/bugs/863741
<cjwatson> slangasek: right
<cjwatson> irritating
<slangasek> cjwatson: I'm wondering if I should upload straight to -updates for this considering it's a no-change rebuild?  Or do you think it's better to go through -proposed anyway just to guard against misbuilds?
<cjwatson> slangasek: I think I'd still rather see it go through -proposed with the fixed override and test that that actually fixes the upgrade
<slangasek> cjwatson: ok
<slangasek> rpcbind uploaded
<slangasek> Unable to find rpcbind_0.2.0.orig.tar.gz in upload or distribution.
 * slangasek glares at pristine-tar
 * xnox pristine-tar glares at bzr-builddeb removing files from the tree before commiting delta and not being able to reconstruct files needed for reconstructing a tarball
<slangasek> mm?
<slangasek> I haven't seen that one
<cjwatson> waitaminute when did *PPH get an API-exported requestDeletion method?!
<cjwatson> I was expecting to have to do that
 * cjwatson goes to write a client for that to see how well it works
<micahg> Laney: infinity: I think we wanted backports to work like Debian experimental in that the backports version is used if it's needed
<slangasek> well, bug #1002336 is a fun one
<ubot2> Launchpad bug 1002336 in smokeqt "SRU tracking bug for KDE SC 4.8.3" [Undecided,Fix released] https://launchpad.net/bugs/1002336
<slangasek> ScottK: do those KDE 4.8.3 SRUs need to go all in one batch?
<stgraber> good to see the SRU list shrink!
<ScottK> slangasek: Looks like your question is OBE now, but there would be some uninstallability in a few cases if they don't go in ~together.
<cjwatson> Looks like they all landed in the same publisher run
<cjwatson> (So good
<cjwatson> )
<debfx> isn't 4 days a bit early to move KDE 4.8.3 to -updates?
<slangasek> ScottK: yah... since they looked on review to all be ready to go in, I played it safe and did them in one run :)
<slangasek> debfx: 7 day waiting period?
<slangasek> debfx: there were a few packages that had been in there 4 or 5 days, but there was nothing to suggest there was actually going to be separate regression-testing for these packages between now and then given that they're comparatively minor components
#ubuntu-release 2012-05-31
<ScottK> slangasek: kde-workspace got missed.  (or maybe infinity)
<slangasek> blast
<slangasek> fixing
<ScottK> Thanks.
<slangasek> sorry, must've been highway hypnosis while reading http://people.canonical.com/~ubuntu-archive/pending-sru.html
<ScottK> Easy enough.  There are a lot of them.
<cjwatson> rah, API removals work
 * cjwatson commits a new remove-package client
<cjwatson> so that should be usable by non-Canonical archive admins now
 * ScottK smiles.
<cjwatson> shows up in exactly the same way in +publishinghistory as old removals; no longer possible to override the remover name, but that's probably a good thing
<cjwatson> (if you're removing on behalf of somebody else, you can name them in the comment)
<ScottK> Nice.
<cjwatson> fixing up the reports and ancillary stuff now
<cjwatson> please update lp:ubuntu-archive-tools if you're doing anything remotely related to removals
<cjwatson> I'll be removing the old facilities on cocoplum soon
<cjwatson> (this is way faster too, actually)
<cjwatson> ArchiveAdministration updated
<infinity> cjwatson: Faster is nice.
<cjwatson> mostly because it doesn't do stupid locking
<cjwatson> and probably also the execute_zcml_for_scripts crap
<cjwatson> Maybe depends how you define faster.  It's slower if you run it on lots of packages at once, at the moment.  Probably some optimisation potential.
<cjwatson> Startup time is better.
<cjwatson> Minor semantic change: it's no longer possible to remove source without removing binaries built by that source too (I believe that check is safe against binaries being taken over by other packages).  This is probably good.
<ScottK> cjwatson: I noticed in the diff for your last ArchiveAdministration page update that neither of the people listed as reviewers for Partner packages work for Canonical anymore.
<cjwatson> Yes, I was meaning to do something about it as soon as I figured out who the replacements should be.
<cjwatson> bdmurray: your sru-report changes are live
<cjwatson> (as of the next run)
 * cjwatson decommissions the last traces of the old ssh cocoplum sync-backend hac
<cjwatson> k
<cjwatson> nothing in ubuntu-archive-tools depends on ssh access any more
<cjwatson> (which is not to say there aren't still Canonical-only tools, there just aren't annoying tentacles between the two worlds any more)
<ScottK> cjwatson: If you have a bit of spare context, would you please accept qt4-x11 from binary New for me?  I've reviewed it and I think it's fine, but libqt4-dev-bin needs an override to Main and I don't think I can do that without overriding all the Universe binaries to Main too.
<cjwatson> You can't yet, no
<cjwatson> My somewhat terrifying http://paste.ubuntu.com/1015825/ would permit that but needs to be redesigned
<cjwatson> Actually maybe it wouldn't yet
<cjwatson> I don't have an override-one-binary thing hooked up yet
<ScottK> No rush.  It doesn't actually come up that often and if I'm in a real rush, I just override everything and let component mismatches sort it later.  Not ideal, but it works.
<cjwatson> ScottK: I've done the override for you - go ahead and accept it
<ScottK> Thanks.
 * cjwatson confirms by example (libextlib-ruby) that the way the API form of requestDeletion auto-removes binaries on source removal is safe against binaries being taken over by other sources
<ogra_> infinity, haha, so you flipped the behavior with the lve builder fix, now all subarches but ac100 build
<cjwatson> I'd appreciate thoughts on https://bugs.launchpad.net/launchpad/+bug/1006871
<ubot2> Launchpad bug 1006871 in launchpad "Copying packages to -updates always goes through unapproved queue, even when copying user is privileged" [Undecided,New]
<Daviey> cjwatson: I see you added the squashfs et al features to live-installer udeb.. what is left to do?
<Daviey> (i'd quite like A1 to be squashfs based.. and don't mind doing the work, but guidance on what is to be done would be appreciated)
<infinity> ogra_: I'll look at that when I'm less drunk. :P
<doko> the evening just did start ...
<ogra_> infinity, no hurry really, i can live with ac100 missing A1
<infinity> doko: We got an early start.
<xnox> infinity: well done =)
<xnox> doko: make sure infinity doesn't do this: http://xkcd.com/364/
<cjwatson> Daviey: I'm really tired and I'm not sure I'm coherent; but a rough estimate is that you need to (a) change livecd-rootfs/live-build/auto/config to pare back the ubuntu-server squashfs to just the base system (+ maybe standard) rather than assuming that it's OK to install grub as well, since d-i probably isn't smart enough to deal with removing packages in the case of needing an alternative; (b) make whatever adjustments ...
<cjwatson> ... to the seed structure and cdimage/bin/list-seeds and so on are needed to get the right sets of packages in the right places; (c) tell cdimage to use CDIMAGE_LIVE=1 for server builds; (d) almost certainly a load of other stuff like fiddling with tools/boot/quantal/boot-*
<cjwatson> Daviey: I suspect the simplest answer is actually to build a test image with DEBUG=1 set in the environment (so that cdimage doesn't publish it), copy it off nusakan directly, and iterate until it works
<cjwatson> hmm, you have to choose between bootstrap-base and live-installer, I think, which will be seedily awkward
<cjwatson> perhaps a temporary cdimage hack to sed the seeds
<cjwatson> it shouldn't be *that* hard, but finding all the stuff you need to change up-front is nearly equivalent to doing the work :-)
<Daviey> cjwatson: that i plenty to get me started, appreciated
<cjwatson> cool - look at how the other live images are done for general structure, obviously
<Daviey> right
<cjwatson> slangasek: accepted rpcbind, but I may have to remember to override it to standard in -proposed, depending on what LP does with it; hopefully I'll remember around the right time
<cjwatson> slangasek: actually, rpcbind is a separate source package from nfs-utils - would you mind fixing up the bug tasks on bug 863741 to something that makes sense and will cause things to be properly Fix Released on -> -updates?
<ubot2> Launchpad bug 863741 in nfs-utils "apt doesn't want to replace portmap with rpcbind on upgrade" [Medium,Fix committed] https://launchpad.net/bugs/863741
<cjwatson> I only noticed after manually setting to Fix Committed *why* I'd had to do that
<scott-work> not sure this is the right place, but i am being asked by leann (kernel team) to provide download information for ubuntu studio. can anyone offer suggestions on where i might gather such information?
<scott-work> i imagine that i cannot accurately track torrent downloads, however i presume that cd image downloads would be acquirable
<cjwatson> you'd have to ask Canonical sysadmins; try #canonical-sysadmin to start with
<Daviey> scott-work: is cd image your primary mirror network?
<Daviey> http://ubuntustudio.org/downloads no precise?
<Daviey> (and brokem images?)
<scott-work> cjwatson: thank you for the information. how are you today?
<cjwatson> sleepy.  woke up at 1:30am, back to sleep at 5am, up again around 8:30am.
<scott-work> Daviey: yes, the cd image is our primary mirror network, to my knowledge it is our only mirror
<cjwatson> so kind of drifting in and out of sanity
<scott-work> Daviey: that website is suffering incredible bitrot and is in process to be replaced, although i did update the home page to reflect precise's release and link
<scott-work> cjwatson: hehe, some maintain that state without a lack of adequate sleep
<slangasek> cjwatson: bug tasks fixed, thanks
<slangasek> cjwatson: could I ask you to have a look at the update-notifier in -proposed?  The bug that's verification-needed seems unlikely to get it for at least another week, but the other bugs are all fairly high-priority; would you like me to back out that change, or do you think it can be promoted as-is?
<cjwatson> slangasek: How well do you think testing for the other three bugs will have covered at least regression-testing here?
<bdmurray> cjwatson: I updated my ubuntu-archive-tools branch / merge proposal and tested it on lillypilly
<cjwatson> bdmurray: in response to pitti's comments?
<cjwatson> bdmurray: I already fixed it
<bdmurray> cjwatson: yes
<cjwatson> sorry, I should have mentioned on the MP
<bdmurray> oh, okay
<cjwatson> I took a rather more sledgehammer approach in case there were other things using len()
<slangasek> cjwatson: it would be incomplete regression coverage, since the code in question only triggers when someone has a hook failing for three days consecutively... however, any possible regression is low-impact as a result
<slangasek> sorry, no
<slangasek> the code triggers the second time you run the hook and it fails
<slangasek> but the impact of a regression is either marking a failing hook as a permanent failure when it shouldn't, or vice-versa
<cjwatson> Is it not possible to fiddle the system time to test this fairly quickly?
<slangasek> or to timestamp in the past, sure :)
<slangasek> I can do a quick test then
<cjwatson> I think it'd be worth *somebody* trying, even if not Loic
<stgraber> I know the bug report is rather long and confusing but from what I can see libgcrypt11 should be copied to -updates in precise
<stgraber> it's been in the queue for 13 days and has been verified for precise (though not shown in the report as the bug affects multiple releases)
<skaet> doing a survey of the blueprints, and some scrubbing is clearly needed.
<Daviey> skaet: the feature reaper ?
<skaet> Daviey,  gap analysis anyway.
<ScottK> cjwatson: Removals definitely work with mere mortal archive-admin privileges: https://launchpad.net/ubuntu/+source/plasma-widget-daisy/+publishinghistory - Thanks again.
<slangasek> cjwatson: fwiw I've set the rpcbind priority now
<tkamppeter> cjwatson, hi
<cjwatson> ScottK: yay
<cjwatson> slangasek: cool, thanks
<cjwatson> tkamppeter: I'm in the pub, can't do anything complicated right now :)
<ScottK> skaet: Is pitti still the right person for the size limit work item?
<skaet> ScottK,  I think its been decided already,  will ask tomorrow in the meeting.   seb128 should know.   Will adjust after I hear back.
<tkamppeter> cjwatson, OK, will contact you tomorrow.
<cjwatson> tkamppeter: if it's for SRU handling, there are other SRU/archive-admin types around
<cjwatson> ScottK: FWIW process-removals.py can mirror Debian removals in bulk or individually (-s pkg)
<ScottK> Good to know.
<cjwatson> does require some care
<ScottK> No doubt.
<cjwatson> I tend to think hard about things with Ubuntu modifications
<ScottK> That one hasn't actually been removed yet, but it was a good opportunity for a test.
<cjwatson> Ah
<ScottK> I figured I'm the case of the least privilege for which a removal ought to succeed, so it was worth verifying.
<cjwatson> I made some progress on queue today (was too sleepy to work on what I was actually supposed to be doing).
#ubuntu-release 2012-06-01
<skaet> slangasek, any insight into who might have updated klibc-utils without updating initramfs-tools?   seems to be breaking the overnight builds based on what
<skaet> is sync-ing in from debian.
<ScottK> I'm trying to figure out who sync'ed klibc ^^^ and got stuck by Bug #1007235.  Any other suggestions on who to talk to?
<ubot2`> Launchpad bug 1007235 in launchpad "No way to see who sync'ed a pacakge" [Undecided,New] https://launchpad.net/bugs/1007235
<infinity> ScottK: I synced it.
<infinity> ScottK: How is it breaking things?
<ScottK> klibc-utils : Breaks: initramfs-tools (< 0.103) but 0.99ubuntu13 is to be installed
<infinity> Oh.
<infinity> I didn't do the current sync that introduced that breakage.
<infinity> That was probably an autosync.
<ScottK> I'm sure it was.
<ScottK> It just seemed suprising we'd suddenly be able to sync klibc.
<ScottK> ... surprising ...
<infinity> We merged it all upstream.
<infinity> So...
<infinity> Yay sync.
<infinity> Until now. :P
<ScottK> Great.
<ScottK> Since you TIL, then I think you get to keep both halves of the installability problem ... (I'm certainly not touching initramfs-tools - way beyond me).
<micahg> a proper breaks could be merged upstream if they'll take a control.in file w/rules
<infinity> I have a break in the next hour, I'll look at either cherry-picking the initramfs-tools bit required to make that breaks valid, or drop the breaks. for now.
<infinity> I was going to merge initramfs-tools anyway, but that might not be a one hour job.
<infinity> Let me poke.
<micahg> err..not control.in, but anyways, I"m just making noise here
<ScottK> infinity: Thanks.
<infinity> As soon as I find somewhere with halfway reliable wireless, I'll mangle this.
<ScottK> For the release team meeting tomorrw: http://www.chrisharding.net/wetherobots/comics/2007-11-12-Delegate.jpg.pagespeed.ce.FnV4r2Ng4x.jpg
<ScottK> ;-)
<skaet> ScottK, lol.
<infinity> ScottK: Cherry-picked pseudo-merge uploaded for now for firefighting reasons, I'll look into doing a proper full merge later when I'm not headless chickening here in Hong Kong.
<ScottK> Sounds good.
<ScottK> skaet: ^^^
<skaet> thanks infinity, Scottk
<ScottK> It would be really nice if we could tell who did the sync...
<infinity> Like I said, it was almost certainly an autosync, since I synced previously.
<infinity> http://paste.ubuntu.com/1017328/ <-- I already uploaded that, but a quick post-review for me? :P
<ScottK> I'm sure.  I just couldn't figure out who had done the manual sync.
<infinity> Oh, I did the manual sync.
<infinity> That should be scrapable from -changes.
<infinity> Not sure if there's any other sane location to find that.
 * infinity looks.
<ScottK> No .changes file for this one.
<infinity> Yeah, native syncs seem to kinda break the audit trail there a bit. :/
<ScottK> Which is why I filed Bug #1007235.
<ubot2`> Launchpad bug 1007235 in launchpad "No way to see who sync'ed a pacakge" [Undecided,New] https://launchpad.net/bugs/1007235
<ScottK> Maybe if you whine in the bug a bit too.
<micahg> ScottK: that's a dupe
<ScottK> Of?
<micahg> bug 861488
<ubot2`> Launchpad bug 861488 in launchpad "Mention sync requester on package version page" [High,In progress] https://launchpad.net/bugs/861488
<ScottK> Thanks.
<infinity> micahg: Want to eyeball the diff above for me?
<micahg> infinity: sure
<micahg> infinity: looks sane enough assuming those files are properly put there in quantal
<infinity> ScottK: And yeah, like I thought, manual syncs do still hit -changes.
<infinity> ScottK: https://lists.ubuntu.com/archives/quantal-changes/2012-May/001674.html
<infinity> micahg: Hence the klibc-utils dependency bump.
<micahg> infinity: ah, I wasn't sure what created those files ;)
<ScottK> Interesting.
<ScottK> https://launchpad.net/ubuntu/quantal/+source/klibc/2.0~rc5-1 says "No changes file available."
<infinity> ScottK: There isn't one.
<infinity> ScottK: The message on -changes agrees. :P
<ScottK> OK.
<infinity> ScottK: But LP's mails to -changes are LP-specific faff, with .changes appednded (if available).  The first bit still gets sent.
<ScottK> Ah.  Right.
<infinity> appednded!  Typing is hard.
<wgrant> ScottK, infinity: The bug lies; it is visible through the API
<wgrant> See creator_link on https://api.launchpad.net/devel/ubuntu/+archive/primary?ws.op=getPublishedSources&distro_series=/ubuntu/quantal&source_name=klibc&version=2.0~rc5-1
<wgrant> Although it may not have been at the time the bug was filed.
<wgrant> Because the implementors of the original feature apparently didn't care about making anything traceable in the slightest :)
<ScottK> So now we just need an Ubuntuish version of who-uploads.
<ScottK> tumbleweed: ^^^ Maybe you'd be up for that?
<micahg> we already have who can upload :) (and in Ubuntu it should rather be called something like who-uploaded)
<slangasek> infinity: so, ah, by faking up the version number for initramfs-tools, you've made https://merges.ubuntu.com/i/initramfs-tools/REPORT go away
<slangasek> infinity: and the package has been failing to import into bzr
 * micahg had assumed that infinity would take care of that when he was free to do so
<micahg> he even said so himself :)
<micahg> slangasek: the problem is the more appropriate 0.103~ubuntu0 wouldn't have validated the breaks in klibc
<slangasek> yes, so we didn't we just fix the breaks in klibc?
<slangasek> s/we/why/
<micahg> not sure, seemed like the saner thing to do would've been to temporarily drop it
<infinity> slangasek: I intend to merge it shortly anyway, I didn't see the point in having a delta in klibc.
<micahg> wait, sorry, not really saner (a little tired over here)
<infinity> slangasek: And the breaks was valid regardless (as in, I needed to do the cherry-pick and/or merge).
<infinity> slangasek: As for the package failing to import, I'm not entirely sure why that would be.
<micahg> slangasek: the import failure is a couple months old: http://package-import.ubuntu.com/status/initramfs-tools.html#2012-04-11%2000:19:27.544309
<micahg> meh, that's not for trunk
 * ScottK wonders if micahg should go to bed ...
<ScottK> Happy mailmain day (just got my first one).
<ScottK> main/man
<ScottK> barry: ^^^
<micahg> ScottK: well, I'm just testing stuff ATM, so critical thinking isn't pertinent
<micahg> slangasek: and apparently the importer was already broke for that branch as you just imported the last revision that infinity did (for precise)
<micahg> ScottK: I've got about another hour or so before bed
<ScottK> OK.
<ScottK> Back when we were discussing merging the SRU and release teams, I volunteered to join the SRU team to help out.  I got a "thanks", but I've no idea what the next step is on that?
<RAOF> ScottK: I think the next step would be to get you some SRU training.
<RAOF> Which wouldn't necessarily be much; it just requires a little organisation.
<micahg> RAOF: what about bzr in quantal?
<RAOF> micahg: Grrr. The time when I *don't* check that the "fix released" in quantal really means fix released in quantal...
<micahg> RAOF: I thought someone said they were going to modify the script to check the version in the dev release
<RAOF> Yes, that was probably me.
<micahg> RAOF: well, you can poke jelmer to do an upload :) (and to not close tasks that aren't done)
<RAOF> Yeah, I will.
<slangasek> infinity: the package fails to import because the importer fails? :)  not saying it's your fault, just pointing out that we're now lacking in tools to help with the merge
<tkamppeter> cjwatson, hi
<Laney> I'm trying to work on the bug to display sync uploaders on +source/package
<Laney> but, well, LP.
<tumbleweed> ScottK: yeah, I've also been thinking we need a who-uploaded tool
<Laney> hmm
<Laney> tumbleweed: could it be that seeded-in-ubuntu gives a false negaitive when binaries are OOD?
<Laney> negative
<tumbleweed> yes
<tumbleweed> known issue
<Laney> ok
<tumbleweed> (well, known to me. no bug filed)
<Laney> ta
<tumbleweed> source<->binary resolution is tricky with lplib when the most recent build failed
<Laney> could you go back in history until you hit a build with binaries?
<xnox> tumbleweed: is it just me, or is it unreasonable that binary-publishing-history doesn't have an (optional) field/link to source-publishing-history
<xnox> in the lplib
<xnox> api
<tumbleweed> that would be handy
 * xnox comes from OpenERP background, where the ORM layer trivially supports one2many and many2one back references which are not stored in the database, but computed on-the-fly and servered to the API consumers
 * xnox wants that from lplib
 * tumbleweed can't say it's been an issue for me, though
<Daviey> xnox: openerp experience you say.... fancy reviewing an openerp packaging branch?
<Laney> he's all over that
<xnox> Daviey: I have been, from the sidelines =)))) I have been mentoring yolanda privately to update and fix packaging. I want her to become contributing developer and make sure she helps maitnaining the package.
<xnox> It's my dream to upload openerp =) in a sane way.
<tumbleweed> pish, don't bother with contributing developer. It's not useful just membership
<Laney> DM :-)
<xnox> tumbleweed: it did mean a lot to her =)))))
<xnox> Laney: that as well.
<Daviey> xnox: So i've been trying to help Yolanda aswell.. but time has been an issue.. Have you reviewed her latest branch, post-NEW-rejection?
<xnox> Daviey: not sure. I have been going back and forth with her. I have seen her branch from 2 days ago I believe.
<xnox> Daviey: I said to Yolanda, that I will consider uploading it to Debian. But from my point of view it is not ready yet.
<xnox> Also note. https://bugs.launchpad.net/bugs/+bugs?field.tag=affects-openerp-itp
<Daviey> xnox: So, i haven't had a chance to look at the branch from 2 days ago.. but do you think it is ok?  I'mn happy to NEW review it, but i don't want to get too involved in the packaging now, if i am doing that.
<xnox> Daviey: I understand. My concerns are: (I) should we embed javascript libraries or not? (II) should we support 5.0/6.0/7 series or simply conflict?
<Daviey> xnox: Personally, if embedding can be avoided, it should be done.. But there are a host of packages that embed.. so it shouldn't be a blocker if reasonable effort has been done to avoid it... version numbers?  You mean versoned package names?  Meh, i don't have an opinion either way
<xnox> Daviey: OpenERP S.A. employes a business model - pay to upgrade. So those who are running 5.0/6.0/7 are stuck with it. Unless they do database migration/ETL themselves. So should we ship /usr/share/openerp/ or should we ship /usr/share/openerp/6.1/
<xnox> in case we will provide other versions in the future.
<Daviey> ahh, ISWYM.. yeah, in that case, versioned does indeed make sense.
<xnox> Daviey: ok.
<phillw> hi guys, we have a problem with the Mac iso's for lubuntu. The testers cannot ascertain fully what is causing it as there are no logs that they can use to view the issues?
<phillw> http://pastebin.com/hq5EhQcn
<cjwatson> "Nothing in the logs" - sometimes if you aren't familiar with the installer you can miss things.  That's why I always encourage people to post logs even if they don't see anything in them themselves
<phillw> cjwatson: hiyas, the guys reporting it are experienced testers. I've asked that they raise a bug, but as it is not installing such details are not going to be there!
<phillw> if it cannot even partition, then there will be no logs :/
<cjwatson> phillw: Untrue
<tkamppeter> cjwatson, hi
<cjwatson> tkamppeter: hello
<jibel> phillw, logs are stored during installation in /var/log/syslog and /var/log/installer/*
<cjwatson> phillw: And /var/log/partman
<jibel> phillw, -> #ubuntu-testing
<tkamppeter> cjwatson, I have sorted out the CUPS SRU for Precise now. All referenced bugs are either verified for the Precise SRU or reopned/made invalid for Quantal as it turned out that the changes do not cover them.
<tkamppeter> cjwatson, regressions did not turn up.
<cjwatson> Great, thans
<cjwatson> *thanks
<cjwatson> ^- FWIW that last one was an API accept
<cjwatson> I need to make at least one more improvement to the API before I'm prepared to get people to start using a client tool for that, though
<cjwatson> (At the moment, there's no sensible way to filter getPackageUploads short of iterating over everything it returns)
<brendand> skaet, is the release meeting in 20 minutes?
<seb128> brendand, no, 1:20
<brendand> why oh why can't google calendar cope with time zones!
<brendand> or DST, whatever it needs to deal with
 * tumbleweed has no trouble with it
<tumbleweed> (these days)
 * ogra_ neither ... it properly shows the meeting at 5pm central european time here 
<tumbleweed> (then again, I also live in a country that doesn't bother with DST, so the meeting time does move around a bit for me)
<infinity> slangasek: I tend to merge packages like that fairly manually anyway, as they require a pretty careful audit, so I'm not really fussed about automated tools having a sad.
<xnox> infinity: afterall, as long as we have all the relevant .dsc merge is possible ;-)
<xnox> tumbleweed: brendand: on the foundations team wiki I have put this (to work around google calendar's brokeness): Held weekly at 1600 UK time BST/GMT (Afternoon tea time) Wednesdays on #ubuntu-meeting @ freenode.
<xnox> http://en.wikipedia.org/wiki/Tea_(meal)#Afternoon_tea
<brendand> xnox, what's weird is if i actually add it to my calendar it says 1600!
<brendand> xnox, but in the creation screen it still says 1500
<xnox> brendand: yeap. Internally google calendar stores the meetings in the timezone of the event creator, respecting DST changes.
 * xnox bets that screws over the meeting times for anyone in like china/japan/australia
<tumbleweed> at least it's obviously a foreign time when its several hours out
<herton> cjwatson, hi, I used copy-proposed-kernel.py to try to sync precise ti-omap4 from bug 1004555, from kernel ppa to -proposed, but since yesterday it's sitting on the queue (https://launchpad.net/ubuntu/precise/+queue?queue_state=1). Is there something someone should do to complete it?
<ubot2`> Launchpad bug 1004555 in linux-ti-omap4 "linux-ti-omap4: 3.2.0-1414.19 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1004555
<cjwatson> herton: Yes, an archive admin needs to accept it.  I'm looking now.
<herton> cjwatson, thanks
<cjwatson> skaet: FWIW, regarding "who might have updated klibc-utils" - yes, it was an auto-sync.  I'm not going to get into manually reviewing auto-syncs for possible problems.  Also, shouldn't we be thinking first about getting the problem solved, and only a distant second about whom to blame? :-)
<cjwatson> (Glad to see the problem's solved, anyway)
<skaet> cjwatson,  certainly don't expect manual reviewing of the auto-syncs. ;)   just trying to figure out who might have a clue about how to sort it.  Infinity handled,  all good.
<Daviey> I'll admit, when syncing out Ubuntu delta's.. i don't tend to look *too* closely if the Debian version is going to introduce issues.. as the way i see it, if it didn't have a Ubuntu delta, it would have been auto-sync'd.
<cjwatson> There's that
<cjwatson> Oh, regarding auto-syncs
<cjwatson> I'm going to be away for the weekend; I'll have my phone with me, but I haven't managed to get launchpadlib authentication working when sshed into my laptop, so I don't know whether I'll be able to run auto-syncs
<cjwatson> Perhaps somebody who's going to be around could occasionally run it?
<cjwatson> And by "the weekend", I mean "until Tuesday", since we have a double bank holiday here
<bdmurray> I was gonna look at the SRU queue.  If I say what I want approved will someone do it?
<cjwatson> I just blacklisted most of the stuff that's whining regularly, so you don't have to be aware of that; there are a couple of packages that have been removed and it's not clear whether they should be reintroduced, but auto-sync defaults to "no" for those so if you just hit enter it should DTRT
<skaet> bdmurray,  yeah, post in the channel here,  and one of us will handle.
<bdmurray> I'd accept unity-lens-video
<cjwatson> Due to bug 1006917, which I discovered when trying to automate this, you do need to be in ubuntu-core-dev as well as in ubuntu-archive to run auto-syncs.
<ubot2`> Launchpad bug 1006917 in launchpad "Distribution archive owners cannot necessarily copy packages" [Low,Triaged] https://launchpad.net/bugs/1006917
<Daviey> bdmurray: i'd suggest publishing SRU's over the weekend has bad karma attached to it.. heck, even Friday's.
<bdmurray> Daviey: even to -proposed?
<skaet> Daviey,  good point.    bdmurray,  batch up a list for -release and we'll clean them up on monday?
<Daviey> bdmurray: no, -proposed seems safe to me.. Are you now ~ubuntu-sru ?
<cjwatson> ... please wait two minutes and ask that question again ...
<cjwatson> ... he is now :-)
<cjwatson> (I had a pending mail to get round to)
<Daviey> cjwatson: gotta love open processes :)
<cjwatson> hey, the existing team trained him, said he was ready
<Daviey> works for me!
<tkamppeter> cjwatson, anything still missing for the CUPS SRU to go to -updates?
<cjwatson> tkamppeter: err - oh, I thought you were talking about the cups-filters upload?
<cjwatson> You mean cups itself?
<mvo> if someone could reject the 5.2.3 upload of software-center to precise-proposed that would be nice, there is a 5.2.2.2 with a trivial tweak to the startup time query to the software-center-agent data uploaded now. this is important for the humble bundle integration and really trivial (just tweaking the delay from 30s to 3s)
<mvo> and a review of 5.2.2.2 if possible, it will improve the user experience quite a bit for the humble bundle buyeers
<Daviey> mvo: 5.2.3 rejected
<mvo> ta
<cjwatson> tkamppeter: OK, cups published now.  The janitor will close the bugs you've "disconnected", so you'll need to reopen them after it's done that
<stgraber> SRU: I just spotted a regression in the lxc package currently in -proposed. I fixed that regression in quantal and uploaded a new version of the package to -proposed. The fix is trivial (reversed logic in shell script), so would really appreciate it if it could go in ASAP, thanks.
<stgraber> oh, but I forgot to use -v for that upload ....
 * stgraber reuploads
<skaet> :)
<stgraber> please reject ^
<stgraber> another one is coming in a few seconds :)
<skaet> lxc rejected
<seb128> mvo, do you need 5.3 rejected or just do be delayed to after 0.5.2.2 is dealt with?
<seb128> oh, Daviey already rejected it so ignore that ;-)
<cjwatson> seb128: doesn't matter since we can unreject anyway
<stgraber> and the good one ^
<seb128> cjwatson, right
<seb128> did anyone in the SRU team saw mvo's request earlier to review the 5.2.2.2 update and can get to it today?
<seb128> would be a shame to delay the fix to next week when those games got advertized around and probably quite some users will install them ;-)
<seb128> mvo, you probably want a bug report associated with the upload
<seb128> (just looked to the diff)
<seb128> mvo, the changelog doesn't have one
<ogra_> skaet, bug 1007512 ... i made it low prio though
<ubot2`> Launchpad bug 1007512 in live-build "building arm livefs proceeds even though flash-kernel is unavailable" [Low,New] https://launchpad.net/bugs/1007512
<herton> cjwatson, linux-ti-omap4 3.2.0-1414.19 also ended in universe in -proposed instead of main (bug 1004555), similar to what happened to ti-omap4 in oneiric
<ubot2`> Launchpad bug 1004555 in linux-ti-omap4 "linux-ti-omap4: 3.2.0-1414.19 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1004555
<cjwatson> herton: already fixed, see bug
<herton> cjwatson, cool, thanks
<mvo> seb128: yeah, there is no bugreport right now, I can fix that, but really its a trivial one line diff from -30s to +3s
<seb128> mvo, I'm trying to help you, they started rejecting any SRU which doesn't have a testcase, regression potential and impact on its description
<seb128> mvo, so I guess one without bug reference has no chance to get approved
<seb128> mvo, i.e not my call but I suggest you get a bug with the things I list in the description
<mvo> seb128: right ok
<slangasek> cjwatson: so bdmurray was asking about direct queue access as an SRU team member... are we putting people through full AA training for that?
<ScottK> slangasek: I thought not, but with an understanding that they wouldn't touch New stuff.  IIRC SpamapS started out that way.
 * slangasek nods
<slangasek> I see that RAOF and SpamapS are both in ~ubuntu-archive
<cjwatson> they got full training AIUI though?
<cjwatson> or maybe I'm misremembering
<slangasek> RAOF, SpamapS: did you get full AA training? :)
<cjwatson> We don't have much more flexibility until I get bug 648611 fixed
<ubot2`> Launchpad bug 648611 in launchpad "ubuntu-sru either have too much or too little permission as queue admins" [High,Triaged] https://launchpad.net/bugs/648611
<slangasek> yep
<cjwatson> Although the DB patch for that has landed, so maybe I can move that up
<bdmurray> I thought not based off the release team consolidation email
<cjwatson> (lp:launchpad/db-devel r11604)
<mvo> seb128: thanks again for your input, I uploaded a new 5.2.2.2 now, with proper instructions etc etc
<seb128> mvo, thanks
<seb128> SpamapS, cjwatson, slangasek: could one of you review the s-c SRU mvo just did today, it's a 1 liner and as he described "it will improve the user experience quite a bit for the humble bundle buyeers"
<seb128> i.e would be nice to get it in proposed before the w.e
<mvo> I added some more context info the bug description, hope its clear now what the beneifts are
<slangasek> bdmurray: ^^ any chance you could review this?  I'm happy to push the button, but don't have time at the moment to look
<SpamapS> seb128: does it supersede the big one uploaded yesterday?
<seb128> SpamapS, yes
<seb128> SpamapS, the one from yesterday got rejected to let that trivial one in first
<SpamapS> seb128: gotchya. It also needs to be uploaded to quantal.
<seb128> mvo, ^
<SpamapS> rmadison may be lying to me tho
<mvo> SpamapS: there is no quantal version yet, so it can just be copied
<seb128> mvo, they stopped doing pocket copies
<SpamapS> mvo: we're pretty late in the cycle. Are you sure thats still safe?
<mvo> oh, ok
<mvo> in this case I can upload it
<slangasek> well, it is safe in this case because it's arch: all python
<mvo> no problem
<SpamapS> toolchain changes and all
<slangasek> but it's simpler if mvo can just upload
<mvo> I will do anything that helpls this SRU
<mvo> (anyone wants a cup of tea?)
<SpamapS> debhelper has advanced too.. not sure if that really matters. :-P
<slangasek> it really shouldn't
<slangasek> :)
<seb128> mvo, just change the changelog target, debuild -S and dput :p
<slangasek> target /and version number/ ;)
<mvo> old school, bzr-buildpackage ;)
<seb128> hehe
<SpamapS> bdmurray: ^^ review away sir
<SpamapS> oh and there are two different ones in the proposed queue.. one from 2 hours ago, one from 15 min or so
<mvo> right, the 15min version has a bugnumber
<seb128> SpamapS, the most recent one has a bug reference that the previous didn't have
<seb128> i.e reject the old one
<SpamapS> ok
<mvo> seb128 correctly pointed out I should do it the right way
<slangasek> rejected
<seb128> thanks
<mvo> uploaded for quantal is building now too
<bdmurray> queue isn't showing it yet
<bdmurray> er queuediff
<tkamppeter> cjwatson, thank you very much.
<seb128> bdmurray, SpamapS, slangasek: can we get that SRU in before it's w.e?!
<seb128> bdmurray, SpamapS, slangasek: it's a one liner and we get through several update rounds to avoid issues, what's blocking it?
<seb128> the bug should be in shape, the update is a one liner, the fix is in quantal ... what is missing?
<bdmurray> the diff shows as pending but I guess we could *gasp* manually do it
<bdmurray> in the queue page
<bdmurray> I'm looking at it
<seb128> bdmurray, thanks
<bdmurray> and w.e.? I have four hours or so left
<seb128> bdmurray, well, I know how things are going, I'm sure 90% of the SRU queue will still be there on monday ;-)
<seb128> we just want to make sure that one goes in today
<bdmurray> slangasek: I'd approve software-center if I could
<bdmurray> SpamapS: ^
<seb128> bdmurray, thanks ;-)
<seb128> mvo, ^
<slangasek> bdmurray: accepted
<seb128> slangasek, bdmurray, mvo: thanks
<slangasek> bdmurray: any idea why the diff never showed up?
<bdmurray> slangasek: it just says pending in the queue - so does euca2ools
<bdmurray> nautilus which is #3 works
 * mvo hugs slangasek and bdmurray
<slangasek> bdmurray: hmm; I guess that needs following up on
<slangasek> maybe it's due to load from the humble bundle :P
<bdmurray> heh
<bdmurray> slangasek: did you run sru-accept?  I've a local change I wanted to test
<slangasek> I hadn't, I just did the queue accept
<slangasek> what's the bug #?
<bdmurray> I'll do it
<slangasek> oh, you have a local change, right :)
<slangasek> please go ahead
<skaet> mvo,  can you do a GnomeAppInstallDesktopDatabaseUpdate
<skaet> Alpha 1 next week...
<mvo> skaet: will monday be good enough?
 * mvo will also do command-not-found and a debian-package-description update
<skaet> mvo,  wanted to get the monday images having it if possible.
<skaet> (from the overnight dailies),  so testing can start.
<skaet> if you can't get it done today,   first thing on monday?
<mvo> skaet: heh :) I start the extraction run now, if it finishes before my bedtime I do it today, otherwise monday morning. deal?
<skaet> deal. :)
<skaet> mvo,  post in the channel when you've done it.   so we know we can build images then.  :)
<mvo> oki
<mvo> it usually takes some time (~1-4h depending on the amount of data it needs to download)
<stgraber> mvo, cjwatson: Any progress on getting do-release-upgrade working by alpha1?
<mvo> stgraber: it should be close now, I prepeared the meta-release-development update and the new version works for me(tm) and is uploaded, but I think there was a ftbfs
<cjwatson> wah, how can u-m ftbfs
<cjwatson> sigh, nvidia rearrangements
<mvo> yeah, just noticed that too, I have no clue what happend with the "obsolete" nvidia pkg names if it just got killed entirely or just reshuffled :/
<cjwatson> I'm looking
<cjwatson> Leave it with me if you like, it's earlier here than there ...
<mvo> hrm, hrm, it looks like its simply not installing it, the textfile is still in the 0.2.44 tarball
<mvo> cjwatson: thanks a lot, that would be great, its really getting late(ish)
<cjwatson> but current version is .53
<cjwatson> (moved into ubuntu-drivers-common)
<mvo> heh :)
<cjwatson> ah, looks like it's just moved to /usr/share/ubuntu-drivers-common/obsolete
<mvo> good point!
<mvo> cjwatson: are you fixing it alreay in u-m or shall I? now that I know the updated location its pretty quick for me, but if you have stated already I am happy of course
<cjwatson> I've started
<mvo> cool, I leave it for you then
<mvo> thanks again!
<cjwatson> though quick review?
<cjwatson> http://paste.ubuntu.com/1018468/
<cjwatson> (thought I might as well update the name of the local copy too)
<mvo> cjwatson: looks excellent!
<cjwatson> OK, uploading shortly then
<cjwatson> ta
<cjwatson> bdmurray: sru-accept-web-links might have been better branched fresh from lp:ubuntu-archive-tools rather than from your previous branch - it has conflicts
<cjwatson> bdmurray: but I'll merge it and drop out the conflicts
<bdmurray> cjwatson: yeah, I'll sort out my local branch
<mvo> skaet: still running, but I call it a day now, monday morning it will be
 * mvo waves
<skaet> thanks mvo
 * skaet appears to have missed him.   
<skaet> stgraber,  looks like monday morning manual is the plan.  ^
<stgraber> skaet: k
<mdeslaur> hey 12.04.1 team, how do I mark a bug that should get fixed in 12.04.1?
<mdeslaur> ie: bug 755842
<ubot2`> Launchpad bug 755842 in compiz-wall-plugin "Non-maximized windows which sit on the border of a workspace move when called" [Medium,Fix committed] https://launchpad.net/bugs/755842
<skaet> mdeslaur,  milestone it to 12.04.1 and nominate it to series precise
<mdeslaur> skaet: am I allowed to do that for bugs that are obviously for other teams?
<skaet> that should get it on the radar,  other teams will decide what they'll fix.
<mdeslaur> skaet: ok, thanks!
<stgraber> Could an SRU team member copy libgcrypt11 from precise-proposed to precise-updates? It's been confirmed in the bug (verification-done-precise) and is 14 days old. Thanks
<cjwatson> doing
<stgraber> cjwatson: thanks, that one was bothering me every time I'd go through the pending SRUs (as its status was essentially inaccurate) :)
<cjwatson> done
<cjwatson> I'll remove that tag once the janitor has noticed
<cjwatson> (maybe somebody could extend sru-report to support the verification-done-$RELEASE scheme?)
<stgraber> I guess that'd be good yes, might do it next week, can't be too difficult
<tkamppeter> cjwatson, all cups bugs disconnected from the SRU are corrected now, except bugs which are marked duplicate, as there I do not get the menu to change status.
<cjwatson> right, that's fine - thanks
#ubuntu-release 2012-06-02
<cjwatson> ^- should fix zh_CN image builds
 * cjwatson runs out of time to fix update-manager and sends mail about it to mvo/slangasek :-/
#ubuntu-release 2012-06-03
<micahg> skaet: are we ok with Firefox 13 beta 6 on the alpha1 images?
<stgraber> hmm, looks like something quite wrong is happening with https://launchpad.net/ubuntu/+source/update-manager/1:0.161/+build/3542556
<Laney> yeah it's been noticed
<stgraber> good :)
<Laney> someone should kill it
<Laney> c jwatson said he couldn't get online until Tuesday iirc
<stgraber> it's currently creating an archive skew that's preventing all !i386 media from building
<stgraber> which is a bit annoying when we want to build the first batch of alpha1 candidates :)
<micahg> our friends in the far east should be coming online in a few hours, was going to ping them for it
<Daviey> stgraber: have you notified ops?
<stgraber> Daviey: nope, though killing the build won't solve our problem, we need someone to figure out what's wrong with the current package, fix it and upload it... until then we'll have an archive skew
<Daviey> stgraber: did you see cjwatson's statement in -devel earlier?
<stgraber> Daviey: nope, but I have now. I'm quite busy at the moment but might give it a shot later today, otherwise mvo will likely fix it early in the european morning.
<stgraber> we were already planning a mass respin early tomorrow US/Canada eastern time, so we should pick up the fix then
<stgraber> (I poked ops to have the build killed)
<Daviey> mass respin?  give back all faild builds?
<stgraber> respinning all ISO images and marking these as alpha-1 candidates, then start testing from that point
<Daviey> ok
#ubuntu-release 2013-05-27
<infinity> cjwatson: FWIW, the current level of the haskell transition is stuck on asn1-types being in Debian/NEW.
<infinity> cjwatson: I was thinking of just packaging it from upstream+darcs and giving it a non-ubuntu version, so it can be synced over.
<infinity> (and done)
<cjohnston> knome: and anyone else. For a blueprint for UDS (and summit.ubuntu.com), it needs to be <track>-<cycle/uds(s/1305)>-name. For status, naming doesn't matter unless it's a topic. If it's a topic it should be topic-s-<category>-name where category would be something like flavor, unity, community, etc.
<cjohnston> knome: when you come online, please ping me
 * infinity curses haskell-conduit's FTBFS on armhf.
<infinity> Laney: Any insight into the above?
<infinity> cjwatson: I nudged the haskell transition along a fair bit, but stalled it intentionally at dep level 24ish, since half the rest of the world build-deps on conduit, which is FTBFS on armhf.
<StevenK> ... dep level 24.
<Mirv> the 6 unity raring SRU packages are still hopeful of getting in. I understood two weeks ago that the scripts would be up to the task in theory, but please let us know if we should do something more regarding the first raring SRU.
<Mirv> up to the task since it's the new style sync requests from the daily process PPA
<cjwatson> infinity: Well, that's just boring.  (Thanks)
<knome> cjohnston, ping
<knome> cjohnston, our umbrella blueprint is https://blueprints.launchpad.net/ubuntu/+spec/topic-saucy-flavor-xubuntu. shall i go and change the name?
<cjwatson> infinity: conduit fails with the LLVM backend on i386 too, it seems - it's just that armhf is our only architecture that requires that
<cjwatson> I think it's something to do with the way it handles variadic open
<cjwatson> Ah yes, works if I avoid that
<cjohnston> knome: hey, still here?
<knome> cjohnston, now i am
<cjohnston> knome: I think that the name is fine
<knome> cjohnston, ok. let me know if we need to change some stuff :)
<cjohnston> knome: my question is that xubuntu-dev doesn't seem to be used... http://status.ubuntu.com/ubuntu-s/xubuntu-dev.html  it all seems to be going to xubuntu-team...
<cjohnston> Can we remove xubuntu-dev from status?
<knome> cjohnston, at the moment, yes.
<knome> cjohnston, i don't think we need that to show in the status specifically though
<knome> cjohnston, i'm trying to avoid assigning to teams where possible, but... meh. :)
<cjohnston> The BP as a whole should be assigned to a team normally, that way any work items that may not be 'spoken for' are assigned to the team
<cjohnston> So I will remove xubuntu-dev and leave xubuntu-team
<knome> cjohnston, yes, agreed with the assigning stuff :) thanks
<cjohnston> ty
<zequence-s> cjohnston, Are you the man to talk to about approving blueprints for saucy? - I'd like to set up blueprints for Ubuntu Studio soonish
<cjohnston> infinity: would you like to handle this, or do you want me to?
<knome> cjohnston, i understand it's not possible to have userpages for "everybody", but would it be too hard to pick the launchpad "realnames" to listings like "Status by assignee" here: http://status.ubuntu.com/ubuntu-s/xubuntu-team.html ?
<cjwatson> infinity: OK, haskell-conduit 1.0.5-2 will fix this when it's autosynced
<cjohnston> knome: your talking for noskaj?
<knome> cjohnston, and xubuntu-team
<knome> cjohnston, i mean i'm not asking to create those userpages.
<knome> cjohnston, just that the LP nicks would be replaced with LP realnames in all listings generally
<knome> consider as wishlist
<cjohnston> knome: I don't know why xubuntu-team does, as xubuntu-team is a team that is being imported.. as far as for users, if you could file a bug http://launchpad.net/launchpad-work-items-tracker please
<knome> i'll do that sometime this week. cheers!
<cjohnston> ty
<zequence-s> I need to log out for a while, so will come back about blueprints..
<knome> cjohnston, i just wish it was written in PHP so i could help with it...
<cjohnston> ;-)
<cjohnston> I want to rewrite it using django
<ogra_> cjwatson, could you take a look at http://paste.ubuntu.com/5706604/ .... the target is to keep a clean tarball but generate boot images per subarch
<cjwatson> ogra_: looks mostly ok; the two things I noticed are that the wildcards in that rm line won't be expanded because you have them inside the quotes (fix: just move the -* outside the quotes), and that perhaps you could make it faster by running update-initramfs for just the appropriate -k rather than -k all
<cjwatson> some kind of quoting and error handling around the assignment to kpkg would be a good idea too
<ogra_> well, getting the version for -k would add some extra code i wanted to avoid
<cjwatson> ogra_: you've already gone to most of the effort there in assigning to kpkg
<cjwatson> isn't it just ${kpkg#linux-image-} ?
<ogra_> hmm, indeed it is
<cjwatson> alternatively: refactor the loop to install all the kernel packages you care about, update the initramfses for all of them, and copy them all out in one go
<cjwatson> should save you time apt-get installing and removing stuff each time round the loop
<ogra_> well, but that would leave me with two loops ... one for installing, one for removing, i guess it will be the same time wise in the end ... i could split off the crda and wireless-regdb stuff though
<ogra_> whopps, the apt-get calls need to be chrooted indedd
<ogra_> *indeed
<cjwatson> If nothing else you could save installing/removing crda and wireless-regdb over and over
<cjwatson> Yeah
<cjwatson> I was just thinking that it would allow you to use -k all if you wanted
<tseliot> infinity, cjwatson: can you approve the following packages in NEW please? nvidia-graphics-drivers-319 nvidia-settings-319 nvidia-modprobe nvidia-persistenced and nvidia-prime
<tseliot> or Laney ^
<Laney> I cannot
<ogra_> try harder
<tseliot> :D
<ogra_> gar
<ogra_> so seems my kver stuff also needs to be chrooted :P
<infinity> cjwatson: Ooo, that conduit made it just under the publisher wire too.  I'll get back to tossing builds back in a bit too, you can blissfully ignore it again.
<infinity> cjwatson: (Seems like a good use of my Monday morning brain)
<cjwatson> I'll be around for a bit, already have the first batch queued up :)
<cjwatson> But yeah, I'll ignore it this evening after this
<cjwatson> I think the only other piece of manual work needed is a sync of haskell-hakyll *after* I manage to construct a working source+binary upload to Debian (build-deps are uninstallable in unstable at the moment)
<cjwatson> I really have very little brain today anyway
<infinity> I need to go renew my passport today too, or I'm not travelling anywhere this summer.
<cjwatson> infinity: Actually, don't rush.  Joachim just did another 13 uploads to bring us up to the current upstream haskell-platform release, so that'll be some rebuilds :-/
<infinity> cjwatson: Heh.
<infinity> cjwatson: My assumption is that if we finish off our self-imposed ABI transition, any subsequent syncs/uploads will Just Work without any babysitting.
<cjwatson> Any new upstream of haskell-$foo is an ABI change for all the stuff that depends on it.
<infinity> Oh, right.
<cjwatson> Or any interface change in a patch.
<infinity> Such an awesome design.
<cjwatson> Since Debian was uploading everything anyway, it was actually easier to force a compiler ABI change at the same time; it meant that everything failed until its deps were ready, rather than requiring 0-change uploads.
<cjwatson> So we could rush and get this one done before the next auto-sync, but meh if we're going to have to do all of haskell-text's rdeps again anyway
<cjwatson> And it was all going so well ...
<infinity> Right, time to wake up and shower and see if I can go for a third passport photo in a row where I mysteriously look exactly the same as I did 11 years ago.
<phillw> cjwatson: just a quick question... can launchpad ppa area compile up a PPC version from source if asked?
<stgraber> phillw: devirt PPA can be used for that but they're restricted to Canonical employees as they use the same builders as the distro
<cjwatson> And because they have effectively no (or very weak) security against a malicious user installing some kind of persistent process that fiddles about with future builds.
<phillw> stgraber: thanks. It's just the PPC guys have asked to have a play with xombrero which julien does keep at https://launchpad.net/~lubuntu-dev/+archive/non-official-apps whilst Luis Henriques battles with licensing issues to have the new version accepted into debian :)
<cjwatson> This is really a #launchpad question, but the answer is going to be no due to long-standing policy, I'm afraid.
<phillw> cjwatson: thanks, it was worth asking :)
<phillw> one of the ppc guys is going to have to learn https://help.ubuntu.com/community/CompilingEasyHowTo one of them has offered, but he is busy in RL for a couple of weeks. No worries, it is of very low urgency (aka wish-list).
<cjwatson> Eh, just have somebody set up sbuild, not that hard
<phillw> cjwatson: but does it not have to build on a PPC machine?
<cjwatson> Install sbuild package, 'mk-sbuild saucy', fiddle with /etc/schroot/chroot.d/<whatever the new file is called> if need be, sbuild -d saucy foo.dsc
<cjwatson> phillw: Yes, in general.  But one might hope that your ppc guys have such things.
<cjwatson> ("in general" because it is possible to play tricks with qemu and/or cross-building in some cases.)
<cjwatson> (but I wouldn't recommend starting there.)
<phillw> cjwatson: they do, but none of the devs have. Would it be possible using  https://wiki.ubuntu.com/Lubuntu/Testing/PPC%26Mac64#How_to_test_on_any_architectures_.28using_qemu.29
<cjwatson> "CompilingEasyHowTo" seems designed to make it sound as scary as possible.
<cjwatson> phillw: In principle you could do it in a VM, sure.  It would be very slow.
<phillw> h eh, do you know of better documentation?
<phillw> more than 12 hours?
<phillw> as in slow ^^
<cjwatson> That would obviously rather depend on the package!
<cjwatson> https://help.ubuntu.com/community/SbuildLVMHowto - if you don't have LVM set up then drop the --vg=blah argument
<cjwatson> 'mk-sbuild --arch=powerpc saucy' will have a go at setting things up with qemu user-mode emulation.  Might work.  Known to have trouble with sufficiently complicated packages that rely on decent threading support during the build, but works with a fair number of simpler things.
 * infinity notes that quantal has a higher version than raring in that PPA.
<phillw> thanks, that gives various options. shame that openbios-ppc is only there as a .deb. I'd run a VM on my server area, but it is CentOS (red-hat)
<cjwatson> It's perfectly possible to pick apart .debs on RH machines.
<phillw> not for me, it isn't :D
<infinity> Or just install it on an Ubuntu machine, and grab the binary you want from /usr/share/openbios-ppc
<cjwatson> Ten seconds' googling found http://www.thegeekstuff.com/2010/04/view-and-extract-packages/ (e.g.)
<phillw> cjwatson: I did have a try, but my knowledge is insufficient. I managed a compile of pcmanfm with a LOT of help.
<phillw> infinity: if I cp that over, would virt-manager be able to use it?
<infinity> No idea, I don't use either virt-manager or RHEL.
<cjwatson> Might be more sensible to ask in some RHish channel ...
<phillw> infinity: thanks, I'll go do some digging, but TBH. centos people are not the most helpful on irc :)
<cjwatson> Ubuntu people aren't going to be helpful about CentOS, I'm afraid.
<cjwatson> Your problem :)
<phillw> unless I have a bug fix for a kernel problem from red-hat :D
<phillw> I do understand. But when I'm on there, it is for CentOS issues :)
<infinity> phillw: http://lucifer.0c3.net/~adconrad/xombrero/
<infinity> phillw: Enjoy.
<infinity> (That was built on raring)
<phillw> infinity: PPC?
<cjwatson> Try looking at the directory listing ...
<infinity> Yes...
<phillw> infinity / cjwatson you people are stars of the 1st magnitude. Thanks!
 * cjwatson wonders whether this would work in qemu, and tries.
<tumbleweed> qemu's PPC emulation seems *very* slow
<cjwatson> I mean user mode.  I can't be bothered with full-system emulation.
<phillw> tumbleweed: it is, but it has a lot to do!
<infinity> tumbleweed: Is it even worse, clock-for-clock than ARM (I'd expect it to be, I guess, given that people emulate ARM for a reason, emulating PPC just means you're too cheap to buy a computer)
<phillw> tumbleweed: many years ago, windows would run faster in the newest PPC chipsets than it could on the intel based ones. That was REALLY weird (But we talking win 3.1 as to how long ago).
<phillw> +under emulation
<tumbleweed> yeah, user-mode
<infinity> phillw: Nothing all that weird about it, PPC740/750 was wildly faster than the Pentiums of the time.
<infinity> (POWER7 and the upcoming POWER8 still eat Intel's lunch too, for that matter, as long as you don't mind running a trunk cable from the local nuclear reactor to your living room)
<phillw> But, I have distracted you all for far too long. Many thanks for all the information and I'll let the PPC testers know of the xombrero link for them to try. At least that way they can decide if they want to give time and effort into testing it.
<phillw> infinity: lol ^^ :D
<stgraber> infinity: hey, aware of any script that lets you grab the latest lp-buildd chroots from the API and set them up as local sbuild chroots?
<stgraber> would like to cron something like that on some of my boxes so I don't have to care about updating my chroots and can ensure I'm relatively close to our buildd chroots
<infinity> stgraber: No, but if you're doing sbuild backed by tarballs, the chroots from the API should just feed in unmodified.
<infinity> (Oh, they might also barf on CurrentlyBuilding not being set up, you might want a setup.d snippet to make that happen)
<infinity> stgraber: I had always meant to do an lp-buildd emulation wrapper for sbuild to do basically what you're talking about.
<infinity> stgraber: Though, it would work even better if you mixed it up with a local nameserver that gimped name resolution the same way the DC does, as that's a cause of some curious build failures.
<stgraber> infinity: yeah, currently the only things I changed here are removing CurrentlyBuilding and /etc/apt/sources.list.d/bootstrap.list and then update sources.list to include all the bits I want (typically all 4 components for the release and updates pocket)
<infinity> stgraber: The last bit I handle with Andy's handy dandy setup snippet.
<infinity> stgraber: http://paste.ubuntu.com/5708191/
<infinity> stgraber: That allows one to override if you don't want all components or don't want proposed, or whatever.
<stgraber> oh, nice
<infinity> (And means the base chroot can stay as main/release, so upgrading it doesn't accidentally pollute it)
<infinity> Which is the big reason I use this.
<infinity> cjwatson: Did you ever get anywhere interesting with automating cdimage archival, or should I go ahead and do oneiric by hand?
<infinity> cjwatson: (IS informs me they have migrated to a machine with room and they're ready now)
<cjwatson> infinity: Not started on it yet, sorry - do it by hand, and just keep the notes in EOLProcess up to date so they get as close as possible to an algorithm
<cjwatson> I hear syncproxy is low enough on space that I'd better not block
<infinity> cjwatson: Mmkay.  I'll go ahead and do the manual archival dance.
 * infinity chuckles at today's xkcd.
#ubuntu-release 2013-05-28
<plars> cjwatson, infinity: no desktop images since Saturday?
<cjwatson> plars: being fixed
<cjwatson> was due to bug 1184927
<ubot2> Launchpad bug 1184927 in libnet-smtp-ssl-perl (Ubuntu) "[MIR] libnet-smtp-ssl-perl" [High,Fix released] https://launchpad.net/bugs/1184927
<cjwatson> in fact I was just about to kick off a rebuild
<plars> cjwatson: how did libmailtools with the new dep make it through proposed with the missing dep? I was thinking there were pieces already in place to prevent things like this.
<cjwatson> plars: -proposed doesn't guard against component mismatches
<cjwatson> since they only break image builds, not (typically) upgrades, I don't mind too much
<plars> ok, good to know
<plars> thanks
<cjwatson> (also, in practice the bulk of component mismatches cause package build failures, because the -dev isn't available to the build - doesn't apply to interpreted languages though)
<ogra_> argl ... grmbl ...
 * doko looks up Brehms Tierleben
<ogra_> heh
 * ogra_ forgot to move the PPA stuff out of the way when rolling ubuntu touch initrds .... another 2h waiting for a 2 line change until i can trigger a new build 
<ogra_> can someone let android-tools-adbd out of binary NEW please
<seb128> ogra_, looking
<ogra_> thx
<plars> https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1185053 seems to be affecting server cd images, yesterday's worked fine but todays does not
<ubot2> Ubuntu bug 1185053 in plymouth (Ubuntu) "Saucy server images do not boot for 20130528" [Undecided,New]
<plars> I suspect desktop images that just landed are going to have the same problem
<cjwatson> plars: I'm looking at that right now; on the contrary I have no reason to believe desktop will be affected right now
<cjwatson> And it sure isn't plymouth
<plars> cjwatson: the builds seem to still get published to both pending and current, so we may want to switch the current for server at least back to yesterday's image
<cjwatson> Let me investigate first
<plars> cjwatson: ok, if there's anything I can do from my side let me know.
<cjwatson> well, ok, yesterday's is there
<cjwatson> symlink switched back
<plars> cjwatson: indeed, the desktop install seems to be progressing
 * ogra_ scratches head 
<ogra_> The following packages have unmet dependencies:
<ogra_>  ubuntu-touch : Depends: android-tools-adbd but it is not installable
<ogra_> android-tools-adbd was approved 90min ago ... so it should eb available
<seb128> ogra_, not sure if the publisher is slow or something, it took over 2 hours for the gnome-desktop binaries to go from "accepted" to "available" this morning
<ogra_> well, it was already in -propsed, wasnt it ? so it should only need one run
<seb128> well, accepted from NEW to proposed should have been one run only as well
<ogra_> i'm used to 2h for a full loop ....  but for -propsed to archive it shouldnt take that long
<seb128> dunno what's going on, it's just an observation that things are being weird today
<ogra_> jenkins seems to be broken
<ogra_> but that shouldnt affect us i would think
<cjwatson> seb128: there was a downtime for a database upgrade
<cjwatson> which I think went on a bit longer than usual due to a new op rotating in
<seb128> cjwatson, ah ok, that would explain it, thanks
<cjwatson> I was watching at the time and there was nothing else odd
<cjwatson> oh, one publisher run ran long
<ogra_> https://launchpad.net/ubuntu/saucy/+queue?queue_state=3&queue_text=android
<ogra_> that looks a bit weird
<ogra_> the new binary wants to go to main ?
<xnox> Can the i386 build of https://launchpad.net/ubuntu/+source/yade/0.97.0-1ubuntu1 be forced on a host with loads of free RAM?
<xnox> "virtual memory exhausted: Cannot allocate memory"
<cjwatson> xnox: I don't know that there's any difference between the available i386 builders in terms of RAM.  infinity might
<cjwatson> xnox: A compile run that runs our builders out of memory is pretty unreasonable, though.  Consider splitting the translation unit - we've done that to packages in the past
<slangasek> ogra_: the source is in main because of android-tools-fsutils; so unless someone overrode it at NEW time, the new binary package goes to the same component as the source; it can be demoted via component-mismatches, but OTOH, if it's seeded in ubuntu-touch, it probably should be in main?
<slangasek> (I realize your comment implies that ubuntu-touch is currently not pinned to main, but that seems like something to fix)
<ogra_> slangasek, it surely shall be in main at some point
<ogra_> but wasnt urgent in the first place since we are building with a ton of universe packages anyway atm
<slangasek> sure
<ogra_> and i dont see anyone filing a ton of MIRs until we actually use saucy and people upload saucy etc etc
<xnox> cjwatson: hmm... I think there was a builder with 12GB of ram, but yade was trying to build -j3. I'll flip it back to -j1 and try again at some point later.
<cjwatson> On i386 you won't get 12GB of RAM for a single process anyway
<slangasek> ogra_: yes - that's the #1 priority right now.
<ogra_> right
<ogra_> working on it :)
<xnox> cjwatson: good point, i wonder if it's hitting the RAM limit in a translation unit as you suggested. Is it the case of adding intermediate convenience libraries to reduce the ram usage?
<ogra_> the container flip will be done by friday ...  but cdimage wont be able to spit out the android zip we need yet ...
<ogra_> (will be aa bit fiddly to install in the beginning due to that)
<xnox> obviously on amd64 with 32GB it compiles just fine here & on the builds.
<cjwatson> xnox: I don't know the source but you usually don't need convenience libraries, since these are typically objects that eventually get linked together anyway, so just splitting up the source file is often enough
<cjwatson> ogra_: android-tools is out of date on powerpc so proposed-migration isn't promoting it to release
<ogra_> hmpf
<ogra_> can we override that
<ogra_> ?
<cjwatson> but since the last version built it should be quick to narrow down
<cjwatson> Yes but I greatly prefer never to override such things
<cjwatson> hm, can't easily remove the package because it will render livecd-rootfs uninstallable
<xnox> ogra_: looks like adbd is failing on powerpc, and as far as I can tell adbd shouldn't need to be build on powerpc.
<ogra_> yeah
<ogra_> looks like a variable length issue
<ogra_> in some usb code
<cjwatson> it's a non-constant initialiser
<cjwatson> which is not valid C
 * xnox wonders is someone is planning to commercialise androidPOWER =) ..... nintendo?!
<cjwatson> Though I thought GNU C permitted non-constant initialisers
<ogra_> heh
<cjohnston> infinity: ping
<cjwatson> Oh, only for automatic variables, which this isn't
<cjwatson> I love how this code goes to great care to handle endianness in such a way that if the endian conversion is non-trivial then it will fail to compile
<tumbleweed> talking of builders and RAM, pypy has been stuck timing out for hours now https://launchpad.net/ubuntu/+source/pypy/2.0.2+dfsg-1/+build/4608301. don't know if it needs a boot
<cjwatson> Simplest fix is probably just to build adbd only on the architectures you care about, indeed
<ogra_> yeah
<ogra_> can you make britney let it in as a one time so i dont have to wait for another 2h while the fix builds ?
<cjwatson> tumbleweed: I've asked webops
<ogra_> *one timer
<tumbleweed> cjwatson: ta. unfortunately it'll have to be retried, unless we delete the current armhf binary
<tumbleweed> it should build, it does on my chromebook
<cjwatson> ogra_: done, but only for this version
<ogra_> thanks !
<cjwatson> you'll have to fix it if you want any further changes
<ogra_> yeah, thats fine
<cjwatson> tumbleweed: do you want it to retry straight away?
<ogra_> i just want to trigger a new image while the fix builds
<tumbleweed> cjwatson: sure
<cjwatson> ogra_: you'll have to wait a publisher run or two anyway
<ogra_> yeah
<ogra_> ugh, two ?
<ogra_> ok
<tumbleweed> cjwatson: thanks. /me -> dinner
<cjwatson> depends on timing of proposed-migration vs. publisher
<cjwatson> yeah, given current proposed-migration runtime I can't make it finish before the next publisher even if I run it by hand
<ogra_> yeah, dont bother
<cjwatson> so ETA an hour
<ogra_> yup
<lamont> cjwatson: tumbleweed: it's removing the build tree now -- back over to you guys
<cjwatson> ta, though I don't know whether it will need processes killing too
<cjwatson> we'll see
 * cjwatson fixes the Kubuntu image build failure
<infinity> xnox: As cjwatson points out, that probably has nothing to do with available RAM, and everything to do with 32-bit addressing.
<zul> can someone de-binary-new python3-testtools please?
<Laney> I'd appreciate someone NEWing gtksourceview3 when it arrives tonight so that I can do the transition quickly in the morning tomorrow
<Laney> pre-req-ish of eds which I'll be doing later in the week
<Laney> seb128: ^ if you happen to be around
<seb128> Laney, gtksourceview3? didn't we just transition that?
<Laney> erm, sorry, gtkspell3
<seb128> Laney, ah ok, will do
<Laney> too many transitions on the brain
<seb128> ;-)
<seb128> the gnome-desktop3 one should be complete btw
<Laney> this one is only like 4 packages
<Laney> ah good
 * tumbleweed prays to the buildd gods and retries pypy
<stgraber> ;)
<infinity> tumbleweed: It may work slightly better when we get some new buildd hardware in place.
<infinity> tumbleweed: Its biggest issue is RAM usage and swap-death, right?
<tumbleweed> infinity: yeah
<tumbleweed> builds in 7 hours on a chromebook with 2GB RAM
<tumbleweed> (once I switched to the 3/1GB memory layout)
<infinity> tumbleweed: Kay, so it might not go too badly on highbank with 4G.
<tumbleweed> yeah
<infinity> tumbleweed: Does it parallelize too?
<tumbleweed> no
<tumbleweed> only the gcc bit
<infinity> Kay.  So, the 4 cores are useless to it, but highbank's a bit faster than Panda, per-core.
<infinity> And all that yummy RAM and fast(er) disk.
<tumbleweed> the majority of build time is rpython -> C translation - one big serial python process
#ubuntu-release 2013-05-29
<ScottK> Is pending-sru known to be broken?  It's rather empty ATM>
<infinity> ScottK: Fun.  I'll clear the cache and see if it fixes itself.
<ScottK> Thanks.
<NCommander> infinity, cjwatson, ping, can one of you reset or remove the expiration on my membership in ~ubuntu-release
 * NCommander isn't even sure why he's set to expire
<ogra_> NCommander, thats a default on LP for moderated teams
<ogra_> user expiration is pre-set to 1 year iirc
 * ogra_ cries 
 * xnox ponders if "* ogra_ cries" correlates with britney migrating new fuse to saucy-release.
<ogra_> xnox, heh, nope, it just correlates with my incompetence :)
<ogra_> (forgot to make sure the chroot on the builder has  /etc/resolv.conf before trying to install a package during build)
<ScottK> infinity: That didn't do it.
<ogra_> ARGH !
 * ogra_ stamps his foot
<ogra_> Ign http://ftpmaster.internal main Release
<ogra_> Err http://ftpmaster.internal main/universe armhf Packages
<ogra_>   404  Not Found
<ogra_> Ign http://ftpmaster.internal main/universe Translation-en
<ogra_> W: Failed to fetch http://ftpmaster.internal/ubuntu/dists/main/universe/binary-armhf/Packages  404  Not Found
<ogra_> godamnit ... !
 * gema brings ogra_ a coffee to set the mood right again!
<ogra_> heh, its fine ... its just that i have to wait for 2h for such a minor typo
<ogra_> (and another 2h to check it is fixed)
<gema> hence the coffee :D
<ogra_> i wish the livefs builders would just pull livecd-rootfs dircetly from proposed
<zul>  can an archive admin promote d2t1o (#1183825) and python-pbr (#1183826) please we have a couple of packages that are dep-waited because of them
<bdmurray> what has happened to the pending sru report?
<NCommander> ogra_, then why am I and skaet the only two with an expiration date?
<ogra_> no idea
<ogra_> i'm not in that team
<stgraber> pending-sru appears to be broken. The cronjob was running twice on lillypilly.
<stgraber> I'm disabling the cron entry and running it by hand see if it's just taking a longer time than usual (> 30min) or if there's actually something wrong with it
<ogra_> does britney have a hiccup ?
<ogra_> livecd-rrotfs sits idling in proposed since over 1h now
<infinity> ogra_: Which hiccup would that be?
<ogra_> i usually get a migration mail after about 30-45min
<infinity> It's more likely that lillypilly's just overloaded or something.
<ogra_> ah well
<infinity> load average: 56.58, 46.09, 57.73
<infinity> Never a good sign.
<ogra_> oh sigh
 * ogra_ might need one more livecd-rootfs upload today before being done ... would be nice if that actually could happen today :)
<infinity> doko: Are you using lillypilly as a lintian lab? :P
<ogra_> on the whole archive ?
<ogra_> :)
<doko> infinity, doing an archive search
<infinity> That's more or less what I meant, yes. :/
<doko> but the load without my processes goes up to 50 as well
<infinity> Except that it was 80 a few minutes ago.
<doko> so what?
<doko> I did open a ticket in the past, and it was closed
<slangasek> is there an iorenice?
<slangasek> doko: "so what" --> monopolizing the machine's IO means lots of other things are failing to work because of timeouts
<infinity> I think it's called "not unpacking multiple packages in parallel".
<doko> slangasek, I'm just using the for-archive tools from the security team
<slangasek> doko: well, these tools are clearly doing a number on lillypilly.  I don't know if the security team has somewhere else that they run them?
<doko> slangasek, and no, even without this task the machine is overloaded
<infinity> Yes, we know it's overloaded even without it, adding to the problem doesn't help.
<doko> well, I would like to know which packages are broken in the archive
<doko> slangasek, for-archive already does:
<doko> # Try to stay out of the way of the rest of the system
<doko> ionice -c 2 -n 7 -p $$
<slangasek> hmm :/
<slangasek> doko: I'm not saying that running the scan isn't worthwhile, I'm saying it's a problem to do this on lillypilly
<slangasek> is that the only machine we have a mirror on?
<doko> afaik, yes
<ogra_> ha !
<ogra_> seems at least britney got some cycles
<ogra_> my package finally moved out pf proposed after 2h now
 * ogra_ curses
<ogra_> so why is the groouper kernel behaving completely different from manta, maguro and mako
<ogra_>     for subarch in $touchsubarches; do
<ogra_>         kpkg="$(Chroot chroot apt-cache depends linux-image-$subarch|grep Depends|sed -e 's/  Depends: //')"
<ogra_>         kver=${kpkg#linux-image-}
<ogra_>         Chroot chroot "apt-get -y install $kpkg
<ogra_> why would:
<ogra_> Chroot chroot "env FLASH_KERNEL_SKIP=1 update-initramfs -k $kver -c -v"
<ogra_> fail ?
<ogra_> it works fine for the other kernels
<ogra_> but all i get is ...
<ogra_> update-initramfs: Generating /boot/initrd.img-3.1.10-2-grouper
<ogra_> df: Warning: cannot read table of mounted file systems: No such file or directory
<ogra_> Setting up linux-firmware (1.109) ...
<ogra_> Invalid argument for option -k
 * ogra_ doesnt get it ... the versioning scheme is the same for all of them
<bdmurray> 'Rejected by Brian Murray: A regression potential statement was not provided in the bug being fixed by this upload.'
<bdmurray> \o/
<infinity> bdmurray: Oh, and I just committed to ubuntu-archive-tools to force rejection comments from the queue tool.  I'll email people about this shortly.
<NCommander> infinity, ping, can you reset (or better yet) remove the expiration from me on ~ubuntu-release?
<jamespage> ^^ any sru team members that keystone upload fixes a time based FTBFS that happened between upload and accept.
<infinity> jamespage: That's disconcerting.
<jamespage> infinity, test certificates expired between my original upload and it actually building
<jamespage> I'm always amazed at how often this actually happens
<jamespage> 2nd time in a year (different projects - the other was tomcat7)
<infinity> jamespage: So, is that an ongoing concern?  These test certs surely shouldn't have expiries, or it's a pain for future security updates, etc.
<infinity> jamespage: Given that they're snakeoil anyway, can you either get upstream to generate them with insane future expiry dates (like, 2099), or generate them at build-time?
<jamespage> infinity, they now all expire in 2023
<jamespage> if anyone is still using folsom by then they are insane
<infinity> jamespage: Ahh, indeed some of these say 2112 even.  That works.
<infinity> jamespage: 2023 isn't actually that far off, in software bitrot terms, but it's certainly past any of our LTS commitments, so good enough for me.
<infinity> bdmurray: So, on the one hand, I want to try out your new SRU tool.  On the other hand, I'm afraid I'll hate it and bombard you with feature requests/changes and/or spend hours fixing it myself. :P
<bdmurray> infinity: great, now I'm afraid of you trying it out ;-)
<infinity> bdmurray: *grin*
<infinity> bdmurray: The intro mail scared me a bit.  It doesn't force me to open all bugs in web browsers before I start, does it?
<bdmurray> infinity: it does open the bugs in a web browser - it looks like that was suggested by someone " - the ability to open all the bugs (by default)"
<infinity> bdmurray: That (by default) may have been misread.
<infinity> bdmurray: I'd read it as "Open (all) bugs in browser? [y/n/A]", and y could perhaps give me a list and ask which one(s).
 * bdmurray feels bombarded
<infinity> bdmurray: Gets increasingly irritating if I'm processing an SRU that's been uploaded for 3 series' and I have to "review" the bugs three times, though the first pass was good enough.
<bdmurray> hey, but you don't have to check the box anymore and click accept!
<bdmurray> plus you can reject with a message!
<stgraber> s/can/have to/
<bdmurray> Seriously though, I understand the bugs idea better now
 * ogra_` curses
<ogra_`> i really dont get that error ... damnit
<infinity> ogra_`: Which?
<ogra_`> infinity, cadejo.buildd/~buildd/LiveCD/saucy/ubuntu-touch/latest/
<ogra_`> have a look at the end
<ogra_`> i have a loop that installs the four kernels (and removes them)  and calls update=initramfs and abootimg in each loop to create bootimg's
<infinity> Is that you calling update-initramfs, or the linux-firmware postinst?
<ogra_`> the first two loops run fine
<ogra_`> the third (grouper) fails with "invalid option to -k" from update-initramfs
<ogra_`> http://paste.ubuntu.com/5714938/
<ogra_`> thats the code
<infinity> Oh, that looks obvious to me, but let me confirm my suspicion.
<ogra_`> obviously $kver works fine for maguro and mako
<ogra_`> the version schema is identical
<ogra_`> just different numbers and chars but always the same setup
<infinity> What's the fourth?  I get confused with the fish..
<ogra_`> touchsubarches="maguro manta grouper mako"
<infinity> http://paste.ubuntu.com/5714943/
<ogra_`> hmm
<infinity> And I'd probably make that awk, just cause I hate the grep|sed pipe.
<ogra_`> i cant imagine what the 10 would make different
<ogra_`> no no, that part works fine
<infinity> for subarch in maguro manta grouper mako; do apt-cache depends linux-image-$subarch| awk '/Depends: linux-image/ {print $2}'; done
<ogra_`> kver=${kpkg#linux-image-}
<ogra_`> that part doesnt
<infinity> Huh?  It's not the 10 that's different, it's the linux-firmware.  You didn't read the paste. :P
<ogra_`> or rather Chroot chroot "env FLASH_KERNEL_SKIP=1 update-initramfs -k ${kver} -c -v"
<infinity> The first is your code, the second mine.  Notice the two fewer lines in the results.
<ogra_`> uh oh !
<infinity> Shall I just commit my fix to livecd-rootfs for you? :)
<ogra_`> ok
<ogra_`> yeah, please
<infinity> ogra_`: Have any other fixes you want, or shall I tag and upload?
<ogra_`> no, i actually thourgh i was done already, no mre fixes
<ogra_`> i just hope my assumption that all this doesnt land inside the tarball is correct :)
<ogra_`> but if not, thats something for tomorrow
<infinity> Oh, wait.  Escaping hell might make that awk print fail in live-build's Chroot function.
<infinity> Ahh, looks like I've used that construct before and it didn't break. :P
<ogra_`> i stole a lot from aabove code :)
<infinity> ogra_`: Uploaded.
 * ogra_` hugs infinity 
#ubuntu-release 2013-05-30
<ScottK> stgraber: Did you forget to turn the cron job back on for pending-sru?
<stgraber> ScottK: yes and no, I was waiting for the load to become reasonable so the job had time to finish in its allocated time (last manual run took 102min), I see that the load is now way lower than it used to be, so I'll turn it back on
<ScottK> OK.  Thanks.
<stgraber> done
<ScottK> Nice.  Pending-sru is empty again.
<infinity> Grr.
<StevenK> infinity: It being empty makes you cross?
<infinity> StevenK: It does when it's empty because lillypilly is overloaded.
<StevenK> Pfft, overloaded. Its load is still two digits.
<infinity> platform 31651 33.9 20.0 2381772 1223392 ?     Sl   04:00   2:10 python versions.py
<infinity> HATE that script with such a passion.
<infinity> StevenK: CPU load isn't the issue, it's I/O contention and swap death.
<StevenK> infinity: Then kill it horribly?
<infinity> I do that occasionally.  Then it gets re-enabled.  It's a constant battle.
<infinity> Maybe I should rewrite it in Perl for the desktop team.
 * StevenK quits less before his eyes start bleeding heavily.
<infinity> I've never read it.  But I can't sort out a good reason why the memory usage would be that high except either (a) it was poorly written, (b) it's something Python is bad at, or (c) both.
<infinity> Both seems likely.
<StevenK> infinity: It creates bunches of threads
<StevenK> One thread per package, if I'm reading this right.
<infinity> MAX_THREADS = 30
<infinity> I wonder if dropping that would magically make it less sad.
<StevenK> MAX_THREADS = 1? :-)
<infinity> Or maybe, y'know, 8, to go with the number of cores the machine has.
<StevenK> infinity: Pfft, sense has no place here.
 * infinity commits that.
 * infinity ... and kills the current one.
<infinity> If that's all it takes to fix this problem, I'll be annoyed that I never read it until today.
<ScottK> Will you be even more annoyed it took StevenK reading it first?
<ScottK> Now at least part of the page is there....
<infinity> ScottK: Oh, fun.
<infinity> ScottK: Also, we should collapse kde-l10n* the same way we do language-pack*
<infinity> ScottK: Can I make the same assumption there, that any kde-l10n-* upload will include kde-l10n-en, and I can just keep that one as a placeholder?
<stgraber> infinity: might be worth adding some kind of lock file so that we don't end up having multiple instance of pending-sru running. I wanted to do that this afternoon but with lillypilly having a load of 80 or so and vim taking 5min to load I ended up doing something else and forgetting about it ;)
<infinity> stgraber: Absolutely should be flocked, yes.
<infinity> stgraber: Can just be wrapped in a flock in the cronjob, that's what the kernel team does, instead of altering every script.
<infinity> ScottK: Oh, there is no kde-l10n-en ... Why do you people hate my freedom?
<infinity> ScottK: Fair to say there'd always be a -de?
<ScottK> probably
<infinity> Okay, committed.  Next run will only show kde-l10n-de.
<infinity> stgraber: Flocked at the cron level, assuming I didn't typo.
 * infinity kills the current sru-report run so this can be a clean test at :10
<infinity> Alright, flock magic looks good.  Now it just needs to complete some day.
<infinity> (Which could take awhile since I also blew away the potentially corrupt cache...)
<wgrant> cjwatson, infinity: https://code.launchpad.net/~wgrant/ubuntu-archive-tools/ddebs/+merge/166456 skips ddebs in change-override/remove-package. It won't even list them, but I'm not sure if that bit is desirable from your side.
<infinity> wgrant: Are they 100% tied to their binary mate?
<infinity> wgrant: If that's guaranteed, I'm not sure if we care if they're listed.
<wgrant> infinity: Yes, they're 100% tied
<wgrant> The copier will explode if they're not copied in pairs
<wgrant> It's impossible to override, supersede or delete them directly
<infinity> wgrant: Kay.  I mean, I feel like I personally care that they're somehow visible to me, but that's probably just me not trusting the magic.
<infinity> wgrant: If they're effectively metadata, not seeing them in those teels seems like it's probably right.
<infinity> s/teels/tools/
<infinity> WTF is a teel?
<infinity> Seriously, fingers?
 * StevenK cackles at some of the reasons infinity lists in his mail.
<StevenK> infinity: Awwww, you spoilt the fun with the PS. :-(
<wgrant> No email for me? :(
<wgrant> infinity: Yeah, IMO they're basically metadata
<wgrant> They can't be manipulated independently.
<infinity> wgrant: They do, I assume, show up on the "binaries produced in this build" download pages in the web UI and such, right?  They're not completely metadata? :P
<wgrant> infinity: They appear as normal publications apart from being unmodifiable, yes.
<wgrant> https://dogfood.launchpad.net/ubuntu/+source/hello-debhelper/2.8-1+df1
<infinity> wgrant: Lovely.
<ogra_`> bah, my last livecd-rootfs upload was nonsense ... sigh
<ogra_`> cjwatson, i'm looking for the least effort way to make cdimage publish multiple bootimg files, i wonder if thats doable through clever naming without having to change cdimage
<ogra_`> (i know i could change download_live_items, but i wonder if there isnt a better way)
<cjwatson> I don't think you should be afraid of changing cdimage here
<cjwatson> It's deliberately quite strict about which files it chooses to publish
<ogra_`> cjwatson, mind taking a look ? http://paste.ubuntu.com/5716730/
<cjwatson> ogra_`: some tests would be nice
<ogra_`> phew ... thats throw away stuff ... is that really needed ?
<cjwatson> ogra_`: and I think it might be good to move some of this logic into download_live_items(..., "bootimg")
<cjwatson> ogra_`: Given how many goes all this has taken, yes
<ogra_`> k
<cjwatson> Plus I find it unlikely that you've run the test suite on this at all :)
<cjwatson> (Pretty sure there are syntactic problems here ...)
<ogra_`> (the files will vanish as soon as we integrate them in the zips during build)
<cjwatson> Yep, your syntax is definitely invalid in places.
<ogra_`> hmm
<cjwatson> So if nothing else writing some tests will force you to run the test suite. :-P
<cjwatson> Also worth installing pep8 and pyflakes, which the test suite will use
<tseliot> didrocks: are you around?
<didrocks> tseliot: in a hangout, but around
<tseliot> didrocks: ok, I was wondering if you could approve nvidia-prime in saucy (it's a small package)
<didrocks> tseliot: any urgency? Not sure i'll be around to do a full review today
<tseliot> didrocks: well, yes, we need it by the end of this week i.e. tomorrow
<didrocks> tseliot: that's fine, i'll have a look (probably tomorrow)
<tseliot> didrocks: ok, thanks
<didrocks> yw ;)
<ogra_`> cjwatson, pep8 clean now ... http://paste.ubuntu.com/5716852/ i noticed a lot of tracebacks for unrelated tests here though ...
<ogra_`> cjwatson, from a logical POV, what would you like me to move download_live_items(..., "bootimg") additionally to the code thast there already
<mlankhorst> can someone move the lts-raring packages and llvm-3.2 out of NEW? https://launchpad.net/ubuntu/precise/+queue?queue_state=0
<mlankhorst> needs to be approved or something :)
<cjwatson> ogra_`: I'll withdraw my point about download_live_items, as I think I've changed my mind
<ogra_`> ueu, ok
<ogra_`> err
<ogra_`> heh
<cjwatson> ogra_`: All the tests pass for me.  Make sure you have everything listed in run-tests installed, and otherwise pastebin the output for me?
<ogra_`> i did install with --no-install-recommends since i definitely dont want an mta on this machine, might be related
<cjwatson> Shouldn't need an MTA
<cjwatson> The dependencies there are meant to be direct
<cjwatson> So what are the failures?
<ogra_`> one sec
<ogra_`> http://paste.ubuntu.com/5716886/
<cjwatson> Well, several of those are directly related to your change
<cjwatson> The test_prepare_squashfs_base failure suggests you're missing squashfs-tools
<cjwatson> (which is listed in run-tests)
<ogra_`> and installed here
<cjwatson> And the test_extract_debootstrap failure indicates that you're missing dctrl-tools, so I've added that to the list in run-tests now
<cjwatson> Ah, that was the test_prepare_squashfs_base too
<cjwatson> *failure too
<ogra_`> ogra@chromebook:~/branches/cdimage$ dpkg -l squashfs-tools|grep ii
<ogra_`> ii  squashfs-tools                            1:4.2+20121212-1                                 armhf        Tool to create and append to squashfs filesystems
 * ogra_` installs dctrl-tools
<cjwatson> Yeah, I misread the test_prepare_squashfs_base failure first time round
<ogra_`> ok, looks better
<ogra_`> 4 failures with .bootimg-manta left
<cjwatson> For the other failures, you need to use a loop variable that isn't "extension"
<cjwatson> Because that comes from "extension = self.detect_image_extension(source_prefix)" above and must be preserved
<cjwatson> In publish_binary, that is
<seb128> hum
<seb128> https://launchpadlibrarian.net/141099296/upload_4627413_log.txt
<seb128> "INFO Upload was rejected:
<seb128> INFO 	Server said: "
<cjwatson> seb128: transient librarian failure, retry
<seb128> thanks launchpad, that's useful info :p
<seb128> cjwatson, thanks
<bdmurray> slangasek: the other day we talked about identifying SRU bugs that could possibly be verified by checking errors.ubuntu.com to ensure there are no crashes with the new version of the package. For example I'd tag bug 1104435 "errors-watch" and update sru-report to display something different (probably color) for bugs with that tag.  Does that seem reasonable?
<ubot2> Launchpad bug 1104435 in xfce4-session (Ubuntu Raring) "xfce4-session crashed with SIGSEGV in g_slice_alloc()" [Undecided,In progress] https://launchpad.net/bugs/1104435
<slangasek> bdmurray: sounds good to me
<xnox> bdmurray: for that bug it would be very awesome!
<ogra_`> cjwatson, hmpf ... http://paste.ubuntu.com/5717429/ do you have any idea where the dashes come from ? (teh files clearly exist on cadejo, but indeed without the suffixed dash)
<ogra_`> oh, i see, it wants to attach the regular subarch  which we dont really have for touch
<cjwatson> Indeed, flavours() wants a subarch
<cjwatson> I think you should probably have separate handling for bootimg*
<cjwatson> Which can then handle ubuntu-touch specially
<cjwatson> You can leave kernel and initrd alone since they aren't in the output on cadejo anyway
<ogra_`> right, sigh
 * ogra_` wanted to be done yesterday ... 
<infinity> Hrm, shouldn't all that lts-raring stuff be in main?  Someone NEWed it all to universe. :/
<ogra_`> cjwatson, http://paste.ubuntu.com/5717478/ ?
<cjwatson> ogra_`: I'd prefer if you split all the bootimg* ones into a separate if branch, and put that logic there
<cjwatson> ogra_`: But the rest is OK
<ogra_`> heh, which rest :)
<cjwatson> Well, I mean the logic you added
<cjwatson> I'd just like it to be in a separate if branch so that the kernel/initrd case stays fairly simple
<ogra_`> ok
<cjwatson> Since AIUI you don't need to change kernel/initrd behaviour
<ogra_`> right, the ac100 bootimg was in there
<ogra_`> which is handled the same way as initrd/kernel ...
<ogra_`> i'll add an extra if for the extended bootimg-* stuff
<ogra_`> cjwatson, http://paste.ubuntu.com/5717500/ is what you meant i guess
<cjwatson> Depends whether you want bootimg for ubuntu-touch too.
<ogra_`> nope, i dont
<cjwatson> OK, in that case that's fine
<ogra_`> what were the runes to prevent cdimage from doing an actual live build ?
 * ogra_` always forgets 
<ogra_`> i only want to test the publishing
<cjwatson> Omit --live
<ogra_`> thx
<ogra_`> hmm, i have the feeling that was the wrong place ... nothing changed
<cjwatson> Write a test case
<cjwatson> Seriously, it's way easier than battering away at things in production
<cjwatson> Or at least use DEBUG=1 so that it doesn't mail people and doesn't try to actually publish to cdimage.u.c
<cjwatson> You can use pdb too
 * ogra_` will do
<ogra_`> ah, heh
<ogra_`> so i fixed tree.py which actually wasnt my probelm
<ogra_`> ate least i will handle botimg-* in both places now :P
<ogra_`> yay, finally
<ogra_`> hmm, except that it doesnt publish them
 * ogra_` digs in again
<ogra_`> hmm, i dont get it, theoretically nothing should prevent them from being published
<ogra_`> argh
<ogra_`> so the generic bootimg is handled in debian-cd ... not really what i want :(
<ogra_`> sigh
<ogra_`> cjwatson, you dont happen to be still around by chance ? i'm stuck with a test
<ogra_`> cjwatson, http://paste.ubuntu.com/5717951/ is the code change http://paste.ubuntu.com/5717953/ is the failure
<ogra_`> i dont really understand where to add the "armhf.bootimg-*" files in the test code
<ogra_`> (i actually thought the first addition to the tests would be enough)
<ogra_`> ot infinity ^^^ if you have a clue about cdimage test code
<ogra_`> *or
<stgraber> ogra_`: so it looks like the input file isn't there when the test runs. Where are those downloaded, how do you mock that in the tests?
<stgraber> ogra_`: the error and the code you listed make it look like "<rootfs>.raw" exists in the test environment (second shutil.copy2) but the *.bootimg-* don't, so when calling fetch_side_effect the copy fails
<ogra_`> well, in  real life "armhf.bootimg-*" files are there too
<ogra_`> how would i mock that in the test
<ogra_`> the files live in the respective scratch dir on cdimage indeed
<stgraber> looking
<ogra_`> note that i'm running the test in my local bzr tree
<ogra_`> so there arent any physical files indeed
<stgraber> ogra_`: so the problem is that fetch_side_effect isn't called for those files
<ogra_`> oh
<stgraber> trying to fix that now
<stgraber> ogra_`: http://paste.ubuntu.com/5718031/ is closer to what you want thought still failing (for another reason)
<ogra_`> hmm, but why is that needed ?
<stgraber> ogra_`: that code essentially mocks copy2 to create the target if it's one of those files you want to copy
<ogra_`> ok
<stgraber> because the source file doesn't exist
<stgraber> I'm very not familiar with that part of the code, but fetch_side_effect is related to the fetch() command which does the wget. Your code change doesn't use wget, so adding the entries there wasn't doing anything.
<stgraber> I suspect that the source files don't exist because they aren't technically retrieved at any point so obviously can't be copied.
<stgraber> My change makes the copy work (as long as it's in the whitelist) by touching the target, but that's causing a failure a bit later on now as the listdir() doesn't appear to match what's expected
<ogra_`> well, neither is rootfs.tar.gz
<stgraber> but the rootfs is downloaded through fetch() isn't it? if so, then it's being touched by the mocked version of fetch()
<ogra_`> not on my chromebook, no
<infinity> Why isn't it all gotten via fetch/fetch_side_effect?
<infinity> Surely, this is all published on a livefs builder the same as any other image/kernel/initrd/etc.
<ogra_`> i'm just running ./run-tests on a machine that doesnt have any running cdimage environment to have the code checked
<infinity> And so should be fetched the same way.
<ogra_`> right
<ogra_`> it doesnt fail for rootfs.tar.gz ... why would it for any of the other nonexisting files
<ogra_`> thats what confuses me
<stgraber> here are the calls to fetch() and copy2(): http://paste.ubuntu.com/5718054/
<infinity> Right, so the testsuite is right.  You're failing to fetch the bootimg files.
<infinity> Also, those kernel- and initrd- bits look suspect...
<cjwatson> Those aren't a problem and can be ignored
<ogra_`> right
<cjwatson> Did you remember to set CDIMAGE_PREINSTALLED in the test config?
<cjwatson> I would be inclined to suggest stepping through the test with pdb at this point, anyway.
<stgraber> note that http://paste.ubuntu.com/5718061/ passes the tests properly, but I'm not sure it's right (well, I'm pretty sure it's wrong)
<cjwatson> Put 'import pdb; pdb.set_trace()' just before the bit in the code you want to step through
<cjwatson> e.g. whatever ends up calling download_live_filesystems
<ogra_`> k
 * cjwatson considers decamping to the pub for a bit
<slangasek> hmmm; lintian gives me a bunch of errors on udev about init.d scripts that aren't in the package at all.  Guess the lintian checks need improving
 * cjwatson rebuilds ubuntukylin images (transient failure)
#ubuntu-release 2013-05-31
 * infinity giggles at motif finally being free, loooong after it's completely irellevant.
<ogra_> yay ... finally
<ogra_> http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/current/
<ogra_> and it even works !!!
<infinity> ogra_: \o/
<ogra_> and indded it was a super silly error
<infinity> If only I had a phone that it works on.
<StevenK> infinity: Oh, Motif has finally been released under a free license?
<infinity> StevenK: Yeah.
<ogra_> (missing the source path in the copy_
<ogra_> )
<infinity> StevenK: In a big, yawning, "who cares anymore anyway" moment.
<ogra_> infinity, make a port !
<cjwatson> ogra_: oh, hooray, well done
<StevenK> infinity: But even five years ago would have had the same reaction. :-)
<infinity> ogra_: Yeah.  If I do, it would be on a 2.6.32ish ginggerbread kernel, cause all attempts so far to make this phone work with a more modern kernel have led to vicious arguments with the RIL.
<infinity> ogra_: If our bits all work flawlessly with GB kernels and drivers, I might play at that.
<ogra_> infinity, hmm, not sure, depends if your kernel can have all the lxc options we want i guess
<cjwatson> StevenK: http://motif.ics.com/article/news
<ogra_> usually its only a matter of adjusting the config ... but the oldest kernel i have used yet is a 3.0 one
<infinity> ogra_: Oh.  Yeah.  lxc in 2.6.32 could be somewhat anaemic.
<ogra_> you could indeed go with raring .... that doesnt use lxc
<ogra_> but will stop getting upgraded indeed
<infinity> ogra_: Well, I could test and play with a 3.4 JB kernel, I just wouldn't be able to make phone calls or (entertainingly) check my battery level.
<infinity> ogra_: Given that this is my primary phone, that would be a non-starter, but if I get a new phone, I might try the above on the old one.
<infinity> (Right now, this phone is running a JB userspace on a GB kernel, it's a mess)
<ogra_> yeah, i did the same with my galayx S2
<cjwatson> After "GB" I tried to read "JB" as a size unit.
<cjwatson> Jiggabytes.
<ogra_> but never managed to get rild to work
<infinity> JigglyBytes!
<cjwatson> Except if it were jiggabytes then the only permissible number in front of it would be 1.21.
<StevenK> But only in 1955?
<cjwatson> I fear any mobile phone would not be desperately useful in 1955.
<infinity> All you need is one tower and a few phones, and you get to be the coolest kids on the block.
<infinity> And for a few blocks in any direction.
<infinity> Until you walk in an elevator.
<infinity> I used to joke that Nokia had wasted far too much money on their clean-room-in-the-basement faraday cage setup with their private cell that couldn't bleed to the outside world (which was, to be fair, a wildly cool setup).
<infinity> Cause they could have just done all their testing in elevators.
<infinity> The mobile phone's natural enemy.
<StevenK> infinity: Except for the iPhone 4, whose natural enemy was a hand holding it.
<ogra_> can someone let that in please
<ogra_> ^^^^
<ogra_> cjwatson, infinity ... would one of you mind to let lxc-android-config out of NEW so i can seed it
 * ogra_ would like to finish the container flip ... thats the last remaining bit
<cjwatson> ogra_: Done; you'll probably want to do the MIR thing as well
<seb128> ogra_, you need to start using the current copyright format btw :p
<ogra_> seb128, the machine readable thingie ?
<seb128> yeah
<ogra_> k
<seb128> ogra_, http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
<ogra_> yep, got it open from last time
<ogra_> i just forgot to do it with all my cdimage wrangling
<seb128> ogra_, also, detail, but why not using compat 9 for a new source?
<ogra_> seb128, lazy copy paste, will update that as well
<ogra_> (i need to update my debian/ skeleton that i use)
<ogra_> yay, thanks
<cjwatson> GHC 7.6.3 and the associated Haskell package upgrade/rebuild should land after the next publisher run.  I may put run-proposed-migration on manual, though, in order to try to ensure that all the copies fit into one publisher.
<cjwatson> Otherwise it does work eventually but all gets a bit confusing.
<Laney> excellent
<bdmurray> slangasek: could you review my apport SRU uploads today?  They change the crash signature calculation for apport-package bugs
<slangasek> bdmurray: yep, will do
<infinity> cjwatson: Hrm.  Curious.  You got ghc to transition alright, but the tracker still claims 3 broken packages?
<infinity> They must have been NEW.
<infinity> Hrm, no, the agda stuff wasn't...
<Laney> agda wasn't available on armhf before
<cjwatson> Right.  There's an arch all package there.
<cjwatson> Usual problem with those.
<cjwatson> And haskell-gloss is new.
<infinity> Ahh, check.  Didn't notice the arch:all thing.
<infinity> I really should sleep some time today, instead of trying to be useful.
<cjwatson> The run that moved ghc to release was a pretty impressively enormous publisher run.  11 seconds under an hour.
<cjwatson> Starting with nearly 20 minutes of "yup, I've got all those on disk already".
<infinity> Yeah, that process is wildly efficient.
<cjwatson> And then around 10 minutes of domination.
<infinity> I wonder if we could improve the publisher by lolcatting the log.
<infinity> That first bit would consist of "I haz?  I haz!"
<infinity> The second bit would be a lot of "DO NOT WANT".
<cjwatson> Actually, I'm looking at the wrong run.  3331s, so more like 56 minutes.
<xnox> when shall we start the apache2.4 transition?
<xnox> debian started it and we are getting depwait things through slowly.
<xnox> or shall we wait for them to finish it?
<infinity> xnox: Shouldn't hurt for us to start it now.  I suspect I have a merge or two to do to kick that off.
<cjwatson> xnox: Hm, I don't see it on http://release.debian.org/transitions/
<cjwatson> xnox: But anyway, it'd be nice to get libgd2 and net-snmp through first (they're intertangled; libgd2 still needs some help; I don't know if apache2.4 would overlap with either of them but it seems plausible), but after that I wouldn't mind
<cjwatson> xnox: http://lists.debian.org/debian-release/2013/05/msg00078.html is not desperately encouraging ...
<cjwatson> Ah, yes, apache2 and libgd2 are linked via php5
<infinity> I was just about to say that.
<cjwatson> It might be helpful to have demotion to -proposed working properly, from the sound of that Apache transition mail.  I'll see if I can get that LP patch done ...
#ubuntu-release 2013-06-01
<infinity> tumbleweed: Do me a favor and don't retry pypy on armhf until we have buildds with 4G of RAM to throw at the problem.
<infinity> tumbleweed: (If you feel strongly about it being in the release pocket, I can pull the old armhf binaries for now, but I'm just as happy with leaving it in proposed for a few weeks while we sort the hardware situation)
<tumbleweed> infinity: ah, new buildds that soon? No objection from me
<infinity> tumbleweed: That's the hope.  They're in the mail, apparently.
<tumbleweed> heh
 * infinity smiles at sagari's libreoffice build time.
#ubuntu-release 2013-06-02
<Laney> yeah, LO/sagari was pleasantly impressive
#ubuntu-release 2014-05-26
<asac> Logan_: didnt know connman would be synched. what are we missing now?
<ari-tczew> asac: I guess it has been already explained: http://irclogs.ubuntu.com/2014/05/24/%23ubuntu-devel.html
<tapani_> Are there any news on when 14.04 server for arm will be available?
<infinity> tapani_: A month ago.
<tapani_> infinity: the download page at http://www.ubuntu.com/download/server/arm says "available soon"
<tapani_> maybe I am looking at the wrong page?
<infinity> tapani_: I'm not terribly involved in the marketing side, but I think that's (perhaps badly) refering to specific platform support for systems that don't exist yet.
<infinity> tapani_: Netboot for a few platforms exists here: http://cdimage.ubuntu.com/netboot/trusty/
<tumbleweed> I see the admin UI on the queue pages for saucy and trusty. I assume that means we left the release team ACLs on those series?
<Laney> laney@iota> edit-acl -t admin -p stefanor -S trusty query                                                                             ~/temp
<Laney> == All rights for stefanor ==
<Laney> Queue Administration Rights for ubuntu-release: archive 'primary', pocket 'Updates' in trusty
<tumbleweed> Laney: yeah, I thought those were supposed to go away, post release
<Laney> I guess so
<tumbleweed> missing step in new release wiki page
<shadeslayer> ScottK: when you have the time, usb-creator could do with some accepting from the trusty queue :)
<mlankhorst> infinity: xorg-server-lts-trusty? :D
<infinity> mlankhorst: Nope.
#ubuntu-release 2014-05-27
<dpm> cjwatson, Laney: I was looking at opening translations in LP and I think the process of copying over translations from the previous release in LP has not yet been started. I think usually someone from the release team requests that, but I'm not sure how it works. Is there a wiki with the procedure, where I could add a note for translations, so that it's part of the process?
<cjwatson> dpm: wgrant knows the details, but I thought that it had been done here
<cjwatson> dpm: https://wiki.ubuntu.com/NewReleaseCycleProcess and it's there already
<dpm> cjwatson, ah, yeah, I see the step there. I'll check with wgrant on the status on the LP side.
<wgrant> Oh yeah, forgot about that.
<wgrant> package-import breakage distracted me.
<wgrant> Let's see.
<cjwatson> Yeah, I'd have poked about it if I had realised it wasn't done :)
<shadeslayer> can someone remove that ^^
<shadeslayer> I accidentally uploaded to trusty
<shadeslayer> Riddell: ^^
<Riddell> shadeslayer: looking
<Riddell> shadeslayer: in the bin
<robru> infinity, cjwatson: hey guys, I just hit publish on unity8, are we still doing that version bump thing?
<infinity> robru: Nope, Colin hacked around that to automate itself.
<robru> infinity, oh, saweeeeeeet. cjwatson thanks a ton!
<cjwatson> robru: yw :)
<cjwatson> (it was my fault to start with, of sorts)
<shadeslayer> cjwatson: btw any news on the new ISO infrastructure?
<cjwatson> shadeslayer: complete locally, awaiting review at this point, hopefully will be able to start in on QA in the next couple of weeks
<cjwatson> shadeslayer: you can basically see it all linked off the bug
<shadeslayer> cjwatson: don't see one in the email sent to ubuntu-devel
<cjwatson> shadeslayer: https://bugs.launchpad.net/bugs/1247461
<cjwatson> you're right, I apparently forgot to link to that
<shadeslayer> thanks! :)
<marrusl> Hello, just wanted to check in on the trusty X stack backport to precise (in the new queue).   I know people eager to test it as soon as it hits proposed.  :)  Thanks!
#ubuntu-release 2014-05-28
<pete-woods> cjwatson: hi, as the guy who tends to push my HUD uploads into proposed, I just wondered if you could take a look at the HUD upload in the trusty queue? (the current version in proposed has a stupid crash bug in it)
<pete-woods> alternatively (as someone who is pretty new to the process) if I'm supposed to wait longer, that's also fine
<cjwatson> pete-woods: am I?  I think I did it once or twice :)
<cjwatson> pete-woods: but sure, I can have a look
<pete-woods> cjwatson: you are that guy :) and it has been much appreciated in the past
<cjwatson> pete-woods: the changelog delta looks like http://paste.ubuntu.com/7534921/ and doesn't actually correspond to the changes in the package in any way ...
<cjwatson> pete-woods: would it be possible to redo this in a way that actually branches from the previous version in trusty?  this is really confusing
<cjwatson> and then specifically describes what changes in this upload
<cjwatson> pete-woods: http://paste.ubuntu.com/7534932/ is the full diff I'm seeing here, and I would expect to see a changelog that describes that
<pete-woods> cjohnston: sure, I can include that change, I hadn't realised we'd had a non-ci-train upload to trusty
<pete-woods> cjwatson: ^ whoops
<pete-woods> obviously this is going to add a couple of days on for me to get the whole thing all the way through ci-train again
<cjwatson> pete-woods: ok, thanks, rejected for now then, sorry for the inconvenience/delay
<cjwatson> hopefully it won't be as bad as a couple of days, depending on silo availability
<pete-woods> cjwatson: I think the reason that it's really confusing is that I was basically told my the CI guys just to imagine that the proposed upload never happened
<cjwatson> but I don't think that upload would have worked with our SRU tracking tools
<pete-woods> *by
<cjwatson> well, maybe, but the changelog needs to describe what's changed!
<pete-woods> sure, will make sure that happens
<cjwatson> reading that changelog diff, the only interpretation I can derive from it is that it's a no-change rebuild
<cjwatson> which clearly wasn't the case
<didrocks> cjwatson: http://people.canonical.com/~ubuntu-archive/cicopy.log FYI
<didrocks> cjwatson: stgraber: also, I restricted the copy list to the silos ppas and reject otherwise any other source
<didrocks> cjwatson: any errors/reject from latest run will show up there, at least, it will enable to know for now if the process is stuck
<didrocks> sil2100: FYI ^
<cjwatson> didah, cool, thanks
<cjwatson> oh, he left
<cjwatson> DIDAH
<cjwatson> Laney: trying an ubuntu-desktop-next image build now
<cjwatson> let's see how excitingly it fails :)
<Laney> cjwatson: oh, cool
<Laney> did that second cdimage branch get merged?
<cjwatson> Laney: oh ... er, cough, I might have forgotten that
<Laney> :)
<cjwatson> NOPE
<Laney> do you understand the failure?
<cjwatson> haven't looked yet, will do
 * Laney uploads livecd-rootfs
<Laney> s/metapackage/task/
<cjwatson> was that the failure, or something else?
<Laney> E: Unable to locate package linux-mx5
<Laney> E: Unable to locate package linux-omap
<Laney> not sure where that comes from
<infinity> Laney: In which build?
<Laney> -desktop-next
<cjwatson> perhaps wrong --linux-flavours or however it's spelled
<cjwatson> since
<cjwatson> /usr/share/live/build/functions/defaults.sh:                    LB_LINUX_FLAVOURS="${LB_LINUX_FLAVOURS:-mx5 omap}"
<infinity> Hrm, if this log existed somewhere, that would help.
<infinity> Anyhow, yeah, we always specify ARM flavours by hand.
<cjwatson> so I think livecd-rootfs needs an ubuntu-desktop-next block that sets KERNEL_FLAVOURS
<ogra_> well
<cjwatson> ubuntu-touch sets KERNEL_FLAVOURS=none so that's not an issue there
<ogra_> it shouldnt go down that code path for x86 builds at all
<cjwatson> should we actually be building ubuntu-desktop-next for armhf at all?
<cjwatson> ogra_: this is an ubuntu-desktop-next/armhf failure
<cjwatson> we possibly just shouldn't build that
<ogra_> definitely not
<ogra_> we wouldnt have any drivers anyway
<cjwatson> -ubuntu-desktop-next    *                       *                       amd64 armhf i386
<cjwatson> +ubuntu-desktop-next    *                       *                       amd64 i386
<cjwatson> right, so that?
<ogra_> ++
<cjwatson> Laney: ?
<cjwatson> (just to double-check)
<Laney> works for me
<cjwatson> ok, committed
<cjwatson> trying the non-livefs bit again
<cjwatson> volid too long, figures
<cjwatson> Laney: can we s/Ubuntu-Desktop-Next-Preview/Ubuntu-Desktop-Next/?
<cjwatson> I think the Next in there is enough
<cjwatson> and it would make the volume ID fit
<Laney> cjwatson: okay, seems fine - I was cribbing from touch there
<Laney> could you document the size limit?
<cjwatson> It varies a lot but I can at least explain the general parameters
<cjwatson> well, a bit
<cjwatson> Laney: documented in a comment
<cjwatson> and retrying
<Laney> vielen dank
<cjwatson> KeyError: "Product 'Ubuntu Desktop (Unity 8) amd64' not found"
<cjwatson> is that on the tracker?
<Laney> iso tracker I guess
<Laney> let me try to make that
<cjwatson> indeed, I thought it had been created
<Laney> does that look okay?
<cjwatson> Laney: yep, posted
<cjwatson> Laney: though no download links
<cjwatson> Laney: http://cdimage.ubuntu.com/ubuntu-desktop-next/daily-live/current/ but you'll need to look from outside the sprint network
<cjwatson> for now
<Laney> I think I'm not being proxied because I can see that :)
<Laney> cheers
<cjwatson> ok, cool
<cjwatson> will leave the rest to you then
<Laney> should be enough to get going
<RAOF> infinity: Going to book a time for AA training for arges and me?
<mlankhorst> Anonymous Alcoholics?
<infinity> RAOF: Maybe.  Are you quite meetingy?
<RAOF> infinity: I have moderate meetingyness.
<RAOF> A couple of meetings a day.
<stgraber> AA training meeting, location: the bar :)
<ogra_> ++
<infinity> RAOF: Kay, shouldn't be too hard for us to meet up, then.
<RAOF> Yeah.
<xnox> stgraber: or cjwatson: can you run britney manually? (to kick the adt job result refresh and possible migration?!)
<cjwatson> xnox: running
<xnox> ta
<cjwatson> final: libunicode-collate-perl,miniupnpd
<cjwatson> doesn't sound like what you wanted, but :)
<cjwatson> nut's still saying regression?
<xnox> cjwatson: strange http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#lsb yet nut is green in both public and private
<xnox> cjwatson: and openvswitch should be ignored.
<cjwatson> how about I try rerunning that job
<cjwatson> sometimes it fails to notice
<xnox> cjwatson: nut, is very very flaky
<cjwatson> "should be ignored" - as in you want somebody to force it?
<xnox> cjwatson: it already has been, by stgraber
<cjwatson> err
<cjwatson> not shown as such
<cjwatson> stgraber: wrong openvswitch version
<cjwatson> I've retried nut, let's hope
<cjwatson> adt-britney is still a bit buggy sometimes :-/
<xnox> cjwatson: stgraber: probably mid-air collision. =) i did binNMU upload just after stgraber commited the ignore =(
<cjwatson> the versions are pretty radically different
<cjwatson> so unless you binNMUed 2.1.2-0ubuntu1 as 2.0.1+git20140120-0ubuntu2
<cjwatson> in which case I may have to hurt you
<xnox> force-badtest openvswitch/2.1.2-0ubuntu1 vs 2.1.2-0ubuntu2
<xnox> cjwatson: does one skip version in -release, or in -proposed?
<cjwatson> "autopkgtest for openvswitch 2.0.1+git20140120-0ubuntu2: Regression (Jenkins: public, private)"
<xnox> cjwatson: oh, that's from the times when britney used to "forget" the tests.
<cjwatson> I'd say release unless openvswitch is migrating at the same time
<cjwatson> oh, but that's the trusty version
<cjwatson> wtf
<cjwatson> I have no idea, maybe we'll have to force-skiptest lsb once the rest is ready
<stgraber> cjwatson: oh, I copy/pasted from rmadison, I wonder how I messed that up...
<apw> cjwatson, that .html has been getting the wrong version in those lines recently, i think jibel is aware
<cjwatson> stgraber: don't think you did, looks like an infra failure
<apw> (if we are talking about test versions in failures)
<cjwatson> apw: yeah.  oww.  thanks
<apw> cjwatson, i believe if you look at the result it is for the right version, just the text
<cjwatson> yeah but that would also confuse force versioning
<xnox> cjwatson: given that all tests are fine, can we whitelist sysv to go in, please?
<xnox> (to unblock building in the ppas)
<cjwatson> we need to get lsb done for that
<xnox> yeap, both lsb + sysv.
<cjwatson> stgraber: could you hack the version to match the wrong thing in excuses?
<cjwatson> under http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#lsb
<cjwatson> maybe even add that version as another hint line
<cjwatson> it's not helping that http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/job/utopic-adt-openvswitch/lastBuild/ARCH=amd64,label=adt/console is still running, but ...
<stgraber> cjwatson: sure
<cjwatson> ta
<cjwatson> rerunning
<pitti> stgraber: oops, I've been meaning to be there, I blame my server reboot a few days ago; sorry
<stgraber> :)
<pitti> stgraber: I can also edit the history file, if that helps
<cjwatson> too late (hopefully)
<cjwatson> let's see about this run
<xnox> "Overriding force-badtest[openvswitch] = ('2.1.2-0ubuntu1', 'stgraber', 'None') with ('2.0.1+git20140120-0ubuntu2', 'stgraber', 'None')"
<xnox> \o/ lsb accepted.
<cjwatson> very slow for some reason but it is working on lsb
<cjwatson> and friends
<pitti> it's got a lot of friends by now :)
<pitti> cjwatson: thanks
<cjwatson> final: acpid,at,autofs,avahi,bluez,console-setup,cryptsetup,cups,gdm,ifupdown,lightdm,lsb,munin,openssh,openvswitch,procps,pulseaudio,rpcbind,rsyslog,slim,systemd,sysvinit
<pitti> so mysql and friends are straggling due to taking long to build, but the above looks good already
<xnox> \o/
<xnox> cron would be nice, no?!
<RAOF> bregma: The unity diff would have been smaller if you didn't have nonfunctional changes in it.
<rcj> infinity, Would you be able to review the SRU in bug #1275656?  Stephane helped me with this last week but is unavailable.
<infinity> rcj: He's about as available as I am..
<infinity> stgraber: If you have recent context on the above, can you help out?
<rcj> infinity, no problem.  I didn't see stgraber online (because I can't read).
<rcj> stgraber, I corrected the version for the precise package and changed the naming from *hwe to *lts-trusty for SRU in bug #1275656
<xnox> Verifying ubuntu/utopic-desktop-i386.iso
<xnox> !!! Verification failed !!!
<xnox> that's pulling current/ image.
<cjwatson> sassenfrassen
<xnox> ditto server
<cjwatson> will look properly later
 * xnox ponders to add static image/shasum verification to utah to catch these in qa
<xnox> oh, proposed are fine, and static validation doesn't run against current/ probably.
<tgm4883> Is 12.10 still supported? It's marked as such on launchpad
<tgm4883> specifically, it got changed from obsolete to supported
<cjwatson> tgm4883: there's going to be one last kernel publication, which is why I changed it back to supported; and then it will be obsolete after that.
<tgm4883> cjwatson: ah ok, when is that going to happen?
<cjwatson> though I see that kernel was published yesterday, apparently
<cjwatson> I'll check with Adam on that
<cjwatson> tgm4883: why does it matter though? :)
<cjwatson> the short answer is you can stop caring about quantal
<cjwatson> regardless of the LP status
<tgm4883> cjwatson: it's not a big thing, but we have a graphic that gets updated via the launchpad API when our MythTV daily builds happen and it's publically available at   http://www.mythbuntu.org/repos
<cjwatson> well, please don't ask in #launchpad for this again, it broke us :P
<infinity> Very soon.
<tgm4883> cjwatson: is this just a one off or something that is going to happen for future releases as well?
<cjwatson> I don't know
<cjwatson> hopefully a one-off
<tgm4883> cjwatson: fair enough. I'll just stick with how we're pulling the data. I dug into it because I thought somehow our build scripts were wrong
<zul> can a SRU team member please look at https://bugs.launchpad.net/nova/+bug/1297962 please
<gaughen> infinity, slangasek, cjwatson, somebody?  could we get some love on zul's SRU request for nova compute ( https://bugs.launchpad.net/nova/+bug/1297962). pretty please?
#ubuntu-release 2014-05-29
<darkxst> ubuntu gnome live cd builds are failing ;( http://pastebin.com/QcAZAZxC
<stgraber> rcj: I'll take a look if I can find sufficient time in a row for a proper review. I'm sprinting this week with a crazy amount of meetings so finding even 30min in a row isn't that easy :)
<cjwatson> gaughen,zul: done, but I echo Brian's implied request on the bug to get this into utopic ASAP (even if it involves backporting in advance of a new upstream release)
<mlankhorst> can someone accept xorg-server-lts-trusty?
<Laney> cjwatson: how often are the Task fields regenerated?
<cjwatson> Laney: every publisher run
<cjwatson> Laney: it can take two runs to settle though
<Laney> cool
<Laney> I was worried it might be daily
<rtg> If I have a package in utopic with version 2.0.18-0ubuntu8 and I want to backport that version to trusty, is 2.0.18-0ubuntu8~1 the right way to version it ?
<cjwatson> ~ubuntu14.04.1 I'd say
<ogra_> is there anything manual that needs to be done to get lxc off the excuses page now that the kernel migrated ?
<ogra_> (and cgmanager )
<cjwatson> xnox: I believe I've fixed the checksumming bug for good now.
<cjwatson> ogra_: There's an autopkgtest regression, according to excuses.
<ogra_> *sniff*
<cjwatson> ogra_: Are you saying the autopkgtest should pass if retried?
<ogra_> cjwatson, well, the kernel bug was fixed so i would guess so, yes
<cjwatson> The failure was only 30 minutes ago
<ogra_> yes, mterry re-ran it
<cjwatson> Wouldn't it need the testbed to be upgraded?
<ogra_> (see #ubuntu-touch)
<cjwatson> Yes, and it failed
<ogra_> oh, yeah, to the new kernel indeed
<ogra_> whom do i poke for that ? CI team ?
<cjwatson> pitti,jibel: ^- Can you help with the autopkgtest testbed upgrade, if that's what's needed here?
<cjwatson> ogra_: jibel's going to look into it
<ogra_> cjwatson, thanks !
<cjwatson> (slightly non-trivial because we don't have up-to-date cloud images, apparently)
<ogra_> (and jibel too indeed)
<ogra_> cjwatson, well, what we are trying to land is only sitting there for 3 months now ... always being held up but such probs ... i guess mterry slowly gets used to it :P ... another few additional hours wont hurt
<ogra_> (well, wont hurt more than the 3 months already did)
<jibel> ogra_, I'm rebuilding the base VMs for autopkgtest with latest sysvinit and kernel, then retry lxc
<ogra_> thanks !
<xnox> stgraber: was debhelper get reverted as well?! (the bit that calls updaterc.d...)
<xnox> doesn't look like. that's good.
<stgraber> xnox: we only changed sysvinit
<xnox> stgraber: lsb-base does not declare breaks/replaces on upstart.....
<xnox> no it does.... hm.
<rcj> stgraber, thanks for the update
#ubuntu-release 2014-05-30
<mdeslaur> how do I get jenkins to retry this: https://jenkins.qa.ubuntu.com/job/utopic-adt-click-apparmor/19/ARCH=amd64,label=adt/artifact/results/
<xnox> mdeslaur: login with openid launchpad.
<xnox> mdeslaur: go to top level of the job, click build now.
<mdeslaur> xnox: I need to reach the private instance to do that, right?
<xnox> mdeslaur: and as stgraber said, use private url.
<xnox> mdeslaur: yeap.
<stgraber> (said in person)
<xnox> (out loud)
<mdeslaur> hrm, I guess I'll have to set up the vpn at some point :P
<xnox> ah =)
<xnox> mdeslaur: i can click it for you.
<mdeslaur> xnox: pleeze :)
<xnox> mdeslaur: it's running on private
<xnox> mdeslaur: i386 passed
<mdeslaur> xnox: I'd offer you a maltese beer, but apparently it's not considered valid currency
<mdeslaur> xnox: thanks
<xnox> mdeslaur: is it meant to take 1h44min though?!
<mdeslaur> xnox: uhm, probably not no
<mdeslaur> kill it with fire
<xnox> mdeslaur: build #20 killed, build #21 started
<mdeslaur> xnox: thanks!
#ubuntu-release 2015-05-25
<hyperair> infinity: ^
<infinity> hyperair: Accepted, built, and copied forward: https://launchpad.net/ubuntu/+source/sigx/2.0.2-3ubuntu1/+publishinghistory
<hyperair> yay thanks
<mdeslaur> infinity: could you please kill the virtinst source package in wily, the binary has been superseded by the virt-manager package since utopic
<cjwatson> mdeslaur,infinity: done
<mdeslaur> thanks cjwatson
#ubuntu-release 2015-05-26
<wgrant> ubuntu-touch wily armhf builds are killing buildds again. http://paste.ubuntu.com/11363499/
<wgrant> infinity: ^^
<infinity> wgrant: Is that killing the host somehow, not just making the build explode?
<wgrant> infinity: Host stops responding to ICMP.
<wgrant> (and everything else)
<infinity> Impressive.
<infinity> wgrant: Guessing it's a live-build bug in that it's not correctly (or at all) cleaning up virtual FS mounts on error/exit.
<infinity> wgrant: But not loving that that can crash a host.
<infinity> wgrant: I guess we could perhaps blame buildlivefs instead, and say it should try a umount-chroot in the live-build working chroot dir.
<infinity> Or livecd-rootfs/live-build/auto/build could trap exit and attempt a umount.
<infinity> Maybe I'll give that a quick spin.
<infinity> wgrant: Untested (yeehaw), but I think this should fix it: https://launchpad.net/ubuntu/+source/livecd-rootfs/2.302
<infinity> wgrant: Can you sort out exactly what it was trying to build, so we can map it to an API call to try to kill off some more nodes with testing?
<wgrant> infinity: It was just a normal ubuntu-touch armhf build for wily.
<infinity> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-touch
<infinity> Right, the lack of logs on those failures seems to match up with dead hosts. :P
<sil2100> Hello release team! I'll be disabling the image importer in nusakan for a short while if you don't mind
 * ogra_ smells arale on the horizon
#ubuntu-release 2015-05-27
<sil2100> Hello release team! I need to again disable the image importer on nusakan for a moment
<sil2100> Importer re-enabled o/
#ubuntu-release 2015-05-28
<ahoneybun> infinity: I hear from wxl that you need some help with release?
<infinity> ahoneybun: I do?  Wait, context? :P
<ahoneybun> <wxl> anyone interested in helping release team this cycle for alpha, beta? https://wiki.ubuntu.com/WilyWerewolf/ReleaseTaskSignup
<ahoneybun> <wxl> ahoneybun: infinity is probably your best bet
<infinity> ahoneybun: Oh.  Generally, I'd like those roles filled by flavour tech leads (ie: the same sort of people who would give me a go/no-go on ISOs before we release).
<ahoneybun> ok np
<ahoneybun> just was asking
<wxl> infinity: oh boo. i'm trying to cross train ;)
<infinity> ahoneybun: Yeah, that's cool.  I mean, if you want to learn how it all happens, feel free to hang out and such, and if you find yourself at a point where you're happy taking responsibility for a milestone, I'm happy to give people a shot at it. ;)
<ahoneybun> thanks infinity I'll be around hopefully
 * ahoneybun is in the Kubuntu camp
<infinity> ahoneybun: Ahh, so my recommendation would be for you to ask ScottK to mentor you on how to be a good little release manager for one of the milestones.  Let you do the work, but let him take responsibility for it and double-check for sanity.
<infinity> ahoneybun: Ideally, a milestone that Kubuntu intends to participate in, but hey, if you want to be nice to other flavours even when you're not playing, that's cool too.
<ahoneybun> I'll ask around, thanks for the info infinity
<bdmurray> infinity: Do you know if releasing SRUs will be affected by the prodstack4 issue?
<wgrant> bdmurray: Yes, Soyuz is offline until PS4 Swift is recovered.
<wgrant> LP is missing about 25TB of data, which could be considered problematic.
<bdmurray> Hunh, okay then.
<infinity> wgrant: A moderate inconvenience.
<wgrant> Quite.
#ubuntu-release 2015-05-29
<oSoMoN> hello release masters, I got informed by psivaa that Â« Failures in boottesting with oxide-qt is known and iirc, the release team does add hint for that to be forced Â», is that correct?
<Laney> oSoMoN: I thought that was supposed to be fixed
<oSoMoN> Laney, it apparently isnât, see https://jenkins.qa.ubuntu.com/job/wily-boottest-oxide-qt/lastBuild/console
<Laney> I can see that, but it is *supposed* to be
<Laney> So we should first find out what is wrong
<Laney> Oh. It's not that unity greeter thing. Man, this output is confusing.
<oSoMoN> if I read correctly the output, the test that failed is getpkgsrc, but Iâm not really sure what that does
<Laney> Possibly fixed the test instead (#ubuntu-ci-eng) if any other release team members come along and get tempted to skip it.
<Laney> Waiting for review then we can retry this.
<quadrispro> tjaalton, hi there! do you have time for this? https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1449892
<ubot93> Launchpad bug 1449892 in xserver-xorg-video-intel (Ubuntu Vivid) "yuv to rgb translation is faulty for Intel Generation 8 Graphics" [Medium,In progress]
<tjaalton> quadrispro: not before monday
<quadrispro> alright thx
<tjaalton> i'll upload it then
<quadrispro> tjaalton, I've uploaded it already to vivid-proposed, AFAIK needs review
<tjaalton> quadrispro: hm ok, i need to import it to git then
<barry> infinity: i'm looking at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html  -- esp. python-pip and python-pluggy.  are these blocked because of the recent infrastructure outage or something else?
<infinity> barry: pluggy is in NEW.
<barry> infinity: oh of course
<infinity> barry: pip looks like it's blocked on the python DEP-8 tests sucking.
<barry> infinity: i'm looking at the amd64 console output.  looks to me like an infrastructure failure
<barry> https://jenkins.qa.ubuntu.com/job/wily-adt-python3.4/lastBuild/ARCH=amd64,label=adt/console
<infinity> barry: For amd64 yeah, for i386, not so much.
<barry> infinity: ack
<infinity> barry: In fact, on i386, the failures look very much related to pip...
<infinity> ImportError: No module named 'ensurepip'
<barry> yay
<infinity> Well, some of the failures anyway.
<infinity> That testsuite looks to be a mess.
<barry> infinity: indeed.  ok, thanks, i'll stare at doko
 * barry hugs infinity 
<doko> infinity, barry: how's that? these are all networking failures
<barry> doko: and now network is cut off in dep-8 tests :(
<infinity> The importerror is a network failure?
<doko> barry, is this a final decision?
<doko> infinity, which one?
<barry> doko: i think it already happened, but i'm not positive, and i don't know whether it will be reversed.  i already disabled some network tests in the system-image dep-8 tests
<doko> adt-run [16:32:38]: test failing-tests:  - - - - - - - - - - results - - - - - - - - - -
<doko> failing-tests        PASS
<doko> infinity, known failing tests are run, but ignored
<infinity> That's not confusing.  Kay.
<infinity> Right, so it's just the connectivity stuff.
<infinity> That conversation is still ongoing.
#ubuntu-release 2016-05-30
<LocutusOfBorg> hi, if an archive admin is available, I would like to discuss and ask removals for libpng/vtk/insighttoolkit, all already gone from Debian
<LocutusOfBorg> they should just break a couple of packages or arch to go away
<cjwatson> LocutusOfBorg: Try again when you don't have to add that qualifier.
<michi> ginggs: thumbnailer is building in silo 8 with the copyright test fix.
<mapreri> LocutusOfBorg: yeah, i'm not aware of any instance of "should just break a couple of packages" in ubuntu.  but probably they should just be removed as well?
<mapreri> (except in way more rare circumstances, like on of the last perl upgrades, iirc)
<LocutusOfBorg> cjwatson, e.g. libpng can be removed without any issues
<LocutusOfBorg> but I can't be sure, because I don't know how to ask dak
<cjwatson> LocutusOfBorg: Not so.
<cjwatson> LocutusOfBorg: reverse-depends src:libpng; reverse-depends -b src:libpng
<LocutusOfBorg> this is interesting
<LocutusOfBorg> http://people.canonical.com/~ubuntu-archive/transitions/html/libpng.html
<cjwatson> *shrug*
<LocutusOfBorg> why they are green then?
<cjwatson> Sometimes there are slight discrepancies or the tracker conditions aren't quite right or something
<cjwatson> In any event you can't rely solely on transition trackers for removals
<LocutusOfBorg> at least I have some work to do, thanks
<cjwatson> (Also the tracker doesn't tend to consider Build-Depends)
<ginggs> michi: thanks!
<michi> ginggs: No problem. Thanks for letting me know. I wish licensecheck wouldnât change behavior with every new release :(
<LocutusOfBorg> mmm I can't understand why gemrb is not migrating...
<LocutusOfBorg> gemrb/amd64 unsatisfiable Depends: gemrb-data (= 0.8.4-1)
<LocutusOfBorg> but what?
<LocutusOfBorg> oh multiverse vs universe mismatch? how to fix that?
<michi> ginggs: did you push a change to trunk for thumbnailer? My silo build just failed because of a missing changelog entry.
<ginggs> michi: not me
<michi> OK, thanks!
<ginggs> probably this https://launchpad.net/ubuntu/+source/thumbnailer/2.4+16.04.20160321-0ubuntu2
<michi> Looking...
<michi> Christâ¦ :(
<michi> This really stuffs us up something majorly each and every time.
<michi> doko: Can you please refrain from push to our trunk without telling us?
<michi> It breaks our silo builds every time someone does that.
<michi> Itâs OK to do this to keep stuff moving, but not without telling us.
<cjwatson> LocutusOfBorg: I've moved gemrb's binaries to multiverse.
<LocutusOfBorg> thanks!
<LocutusOfBorg> cjwatson, should libpgplot-perl have the same faith? (pgplot5 is in multiverse)
<LocutusOfBorg> BTW almost all the packages shown with reverse-depends have a control file "libpng-dev | libpng12-dev", so I guess there is no need to patch them
<maxiberta> hi. Looks like https://wiki.ubuntu.com/LTS is outdated; should include xenial at least in that time chart?
<sergiusens> infinity hey, arges told me snapcraft in xenial-proposed should be good to go and to ping the right guy on the SRU list on Monday. I guess that's you (from the wiki at least)
<sergiusens> any chance it can get the last ack?
<infinity> sergiusens: That was snapd, not snapcraft, but I can do both.
<sergiusens> infinity heh not sure what went on with snapd, but ok ;-)
#ubuntu-release 2016-05-31
<tseliot> is aptdaemon broken in yakkety?
<tseliot> or, rather, is it a known issue? https://launchpadlibrarian.net/262461537/buildlog_ubuntu-yakkety-amd64.ubuntu-drivers-common_1%3A0.4.19_BUILDING.txt.gz
<Odd_Bloke> infinity: This is your semi-regular reminder about https://code.launchpad.net/~daniel-thewatkins/livecd-rootfs/enable-backports/+merge/295059 :)
<cjwatson> infinity: Would you mind having a look at python-libnacl and pymacaroons in xenial-proposed?  New packages, will be needed for snapcraft in the nearish future.
<Laney> Can someone clear up abiword nbs in y-proposed please?
<cjwatson> Laney: done
<Laney> cjwatson: thanks
<Laney> I think evolution-ews might want removing, checking
 * Laney is clearing out libical
<ginggs> hi could someone give me some direction with http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#suitesparse please?  does libmetis5 need MIR, or is it possible for libcholmod3 to go to universe? in other words: do all suitesparse's binaries need to be in main?
<cjwatson> ginggs: this is listed on http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.html
<cjwatson> ginggs: that report thinks that metis needs an MIR
<cjwatson> ginggs: (which implies that it also thinks libcholmod3 needs to stay in main)
<ginggs> cjwatson: thanks, so shall i write up an MIR for metis then?
<cjwatson> ginggs: That looks like the next step, indeed
<Laney> Okay, yeah, please remove evolution-ews from yakkety-proposed so I can upload a rebuild of 3.18.5-1
<Mirv> could someone hint qt4-x11 qtbase-opensource-src qtchooser to go in together to release pocket in yakkety? I don't see anything worrying in the remaining red autopkgtests either, KDE release breakage and such, so maybe with proper nudging they could migrate now
<Mirv> there are stuck status information for a couple of autopkgtests though, they are not really "in progress"
#ubuntu-release 2016-06-01
<cjwatson> Could somebody have a look at python-libnacl and pymacaroons in xenial-proposed NEW for me, please?
<Laney> bah, thought that worked for channel notices
<Laney> stgraber: ^-
<stgraber> Laney: looking
<stgraber> Laney: why the +b though, just kicking it would have been enough
<stgraber> Laney: now I've got to unban it and restart it again
<Laney> I thought that +b was enough to mute it
<Laney> should have removed it when that didn't work
<Laney> soz
<stgraber> nah, +b only applies at join time I think
<Laney> I think it applies to real messages
<Laney> at least on some ircds it does
<Laney> testy mctestface
<cyphermox> nah, b just means you can't get back in
<cyphermox> you want +q
<cyphermox> (to mute someone)
<Laney> :)
<Laney> Depends what other modes are in effect; by default +b stops you from speaking but it's overridden by various things
 * Laney just wasted time checking
<apw> stgraber, Laney ^
<stgraber> gah
<stgraber> it's lplib blowing up by the looks of it but I'm not sure why exactly
<stgraber> restarted with added logging, so if it happens again I should be able to track exactly what's making it unhappy
<stgraber> that bit of code hasn't changed in over a year, so my guess is that there's something slightly different on LP which is confusing it
<slangasek> hmm. why was cgmanager demoted in yakkety?
 * slangasek undoes the demotion
<seb128> would be nice to have launchpad records of who is doing those
<slangasek> certainly would
<slangasek> would also be nice to know why a package is being demoted in contradiction with component-mismatches
<slangasek> And did something change recently to put the ubuntu-touch seed in main?  It's good to have that fixed, but I remember there actually being quite a bit more delta of ubuntu-touch packages not yet in main than what I'm seeing now
<seb128> there is probably quite a stack still
<slangasek> seb128: not according to http://people.canonical.com/~ubuntu-archive/component-mismatches
<seb128> weird
<slangasek> so I wonder if someone has batch-promoted things
<seb128> http://paste.ubuntu.com/16735785/ is the list of packages used by the unity8 desktop session (not including recommends) that needs to be promoted
<slangasek> hmm
<seb128> the touch seed for sure needs a good part of those
<seb128> that list is from friday
<slangasek> ok, so I'm not sure why ubuntu-app-launch is in main at all then; unless c-m is just confused because it /is/ in main, and therefore thinking gir1.2-ubuntu-app-launch-2 is a reason to keep it in main?  (Because Extra-Include: gir1.2-*)
<seb128> slangasek, I promoted u-a-l earlier because indicator-datetime depends on its lib and that was blocking the libical transition, and u-a-l was in main in wily
<slangasek> ah
<seb128> seems that has worked, libical migrated ;-)
<seb128> though I'm not sure I understand your comment, is that on the demotion list?
<slangasek> makes perfect sense, but somehow 'reverse-depends' and 'seeded-in-ubuntu' aren't telling me this... guess it's a timing issue
<slangasek> seb128: no, the other binaries were in the promotion list and I couldn't figure out why
<seb128> k
<seb128> I just promoted the binary that was needed
<slangasek> now it makes sense, but it's still an MIR issue because ubuntu-app-launch has new dependencies since the last time it was in main
<seb128> oh :-/
<seb128> which ones?
<slangasek> ust, liburcu, libertine
<seb128> sorry I overlooked that
<slangasek> so this probably breaks image builds until it's resolved?
<seb128> :-/
<seb128> so britney just look at direct depends?
<seb128> indicator-datetime was not installable because of libubuntu-app-launcher missing
<seb128> but promoting it unblocked the transition even if it's un-installable in main
<slangasek> yes, britney probably doesn't try to figure out recursive installability in main, just whether the direct deps are satisfied
<slangasek> xnox: ^^ is that true?
<seb128> well, those eventually needed to be MIRed, so we just need to push people to file those requests now
<seb128> sorry about that
<slangasek> ust, liburcu were previously in main also, so we can repromote
<slangasek> libertine is new, I think
<slangasek> I'll do the repromotion of ust,liburcu
<seb128> thanks
<seb128> tedg, ^ can you MIR the new depends?
<tedg> Ah, sure, I may harass people to do them for me :-)
<tedg> So reading the back log? Do I need a MIR for UAL?
<tedg> It was next on my TODO, but if I can avoid that one, I'd be happy :-)
<slangasek> tedg: only for libertine; with some urgency because the desktop image now has unsatisfiable-in-main deps
<tedg> slangasek: Yeah, talking with ChrisTownsend about it now
<tedg> slangasek: We have a question about splitting up a package between main and universe
<tedg> slangasek: Libertine has a module it builds that has a lot of chroot deps that is a Suggests in the end for the main package.
<tedg> slangasek: Can the source be in main and a binary in universe?
<tedg> (one of the binaries)
<doko> tedg, yes
<ChrisTownsend> Ok, afaict, only python3-libertine-chroot has dependencies in universe all other binary packages have dependencies in main.
<ChrisTownsend> doko: Do I make a note in the MIR for libertine that python3-libertine-chroot will stay in universe and all other binary packages are eligible for main?
<slangasek> tedg, ChrisTownsend: no need to mention it at all; http://people.canonical.com/~ubuntu-archive/component-mismatches already directs us to DTRT
<slangasek> (and shows that python3-libertine-chroot is not a candidate for promotion)
<ChrisTownsend> slangasek: Ah, cool, ok
<ginggs> infinity (or anyone else), what can be done about LP: #1562480 ?  Can fpc powerpc be removed in xenial and yakkety?  it is not installable anyway
<ubot5> Launchpad bug 1562480 in glibc (Ubuntu) "fp-compiler not installable on powerpc since glibc 2.23" [High,New] https://launchpad.net/bugs/1562480
<ChrisTownsend> slangasek: tedg: I believe this is what is needed: https://bugs.launchpad.net/ubuntu/+source/libertine/+bug/1588050
<ubot5> Launchpad bug 1588050 in libertine (Ubuntu) "[MIR] libertine" [Undecided,New]
<tedg> Thanks ChrisTownsend !
<ChrisTownsend> tedg: You're welcome
#ubuntu-release 2016-06-02
 * ogra_ glares at https://launchpadlibrarian.net/262865016/buildlog_ubuntu_xenial_ppc64el_ubuntu-core-system-image_BUILDING.txt.gz
<cjwatson> ogra_: Looks like just the usual slight unreliability of ppc64el builders.
<ogra_> yeah, i'll just kick a re-build ... seems no other ppc64el images failed tonight
<Odd_Bloke> stgraber: ^ It's happening again. :)
<stgraber> Odd_Bloke: thanks
<stgraber> looking at the log now
<stgraber> changed the handling of that failure a bit, added debugging and restarted
<stgraber> so hopefully it won't cause that kind of mess again and I'll have more information to figure out what's confusing it
<tsimonq2> or
<tsimonq2> whoops
<bdmurray> slangasek: Here's a change to the SRU tools to add release tasks https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/add-release-tasks/+merge/296374
#ubuntu-release 2016-06-03
<LocutusOfBorg> hi cjwatson did the gemrb demote to multiverse fail? I still don't see it migrating
<LocutusOfBorg> hi folks, what is missing to see liquidsoap migrate? I'm honestly lost in the ocaml stuff
<LocutusOfBorg> BTW with liquidsoap and gemrb migrated, I think we are good wrt libpng12 removal
<LocutusOfBorg> everything else seems false positive (libpng-dev | libpng12-dev in b-d)
<mapreri> Depends: liquidsoap yojson (not considered)
<mapreri> which is because of 'Depends: yojson biniou (not considered)'
<mapreri> which is because of 'autopkgtest for botch 0.16-2ubuntu2: ppc64el: Regression â» , s390x: Regression â»'
<mapreri> LocutusOfBorg: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#biniou is your friend.
<LocutusOfBorg> yes, but botch is utterly broken, also in debian
<LocutusOfBorg> I saw that, but I guess some force-hints seems needed
<LocutusOfBorg> or demote
<mapreri> LocutusOfBorg: then why do you came here with "why liquidsoap doesn't migrate" instead of asking for a kick for src:biniou directly? :)
<LocutusOfBorg> because I don't feel good in giving orders, I like to mask them under a stupid question :)
<mapreri> :>
<cjwatson> LocutusOfBorg: oh right, need to do it in yakkety-proposed as well as yakkety.  done
<LocutusOfBorg> thanks! I was wondering about how long would it take to be effective :)
<LocutusOfBorg> can anybody please help hunspell migrate? I think goldendict failing on s390x is the only reason for it not migrating
<cjwatson> half an hour or so, bit longer for the proposed-migration cycle
<LocutusOfBorg> but it is broken in debian too
<LocutusOfBorg> cjwatson, nope, I was wondering that before asking again today, not now :)
<infinity> LocutusOfBorg: What "help" were you hoping for?  You could help it by fixing goldendict...
<infinity> LocutusOfBorg: If it's a helpful hint, the failure doesn't look to be s390x-specific, but rather 64-bit-big-endian (sparc64 failed the same way, and ppc64 probably would if it had been attempted)
<LocutusOfBorg> infinity, is adding a cast https://sources.debian.net/src/goldendict/1.5.0%7Egit20160508.g92b5485-1/ripemd.cc/#L176
<LocutusOfBorg> a reasonable solution?
<LocutusOfBorg> thanks for the *useful* hint, I didn't think about 64 bits
<LocutusOfBorg> I excluded BE because others were fin
<LocutusOfBorg> I'm testing on a debian porterbox
<LocutusOfBorg> well, count is uint64_t, I can't cast to 32 bits
<LocutusOfBorg> forwarded upstream
<LocutusOfBorg> infinity, I guess it is a qt issue, because on debian/s390x is building now fine
<infinity> LocutusOfBorg: The last build log disagrees.  Or did you just try on a porter?
<LocutusOfBorg> infinity, I tried in a Debian porterbox and asked a give back on debian buildd
<LocutusOfBorg> not sure why ubuntu failed again
<LocutusOfBorg> the qt4 stuff is mostly in sync
<LocutusOfBorg> do you want to see a build?
<LocutusOfBorg> zelenka.debian.org has an ongoing build
<infinity> LocutusOfBorg: Different qt versions between the last Debian failure and your recent attempt?
<infinity> Not that I see much interesting in the qt4-x11 changelog.
<LocutusOfBorg> exactly, even symbols file arent showing differences
<LocutusOfBorg> moreover I already took the latest qt4 in my last attempt
<LocutusOfBorg> I'm seeing something interesting now
<LocutusOfBorg> "-DHAVE_X11" < is not passed in the porterbox
<LocutusOfBorg> but I see a -DQT_WEBKIT instead
<LocutusOfBorg> damn, the apt-get source is getting the testing version
<LocutusOfBorg> blah something is bad with unstable mirrors
<LocutusOfBorg> infinity, does it sound ok for you? http://paste.ubuntu.com/16946618/
<LocutusOfBorg> I took some bits from libavutil
<LocutusOfBorg> https://ffmpeg.org/doxygen/2.3/bswap_8h_source.html
<LocutusOfBorg> actually that file is coming from there, so I guess we are good
<infinity> LocutusOfBorg: That seems like an odd hack to work around qFromLittleEndian() breaking, if that's the real bug.
<LocutusOfBorg> infinity, seems that qFromLittleEndian doesn't exist for 64 bit data types
<infinity> LocutusOfBorg: But it worked previously?  I mean, this is just a rebuild.
<LocutusOfBorg> no infinity
<LocutusOfBorg> this is a new upstream release
<LocutusOfBorg> the old one was #include <libavutil/file.h> now they embedded it there
<LocutusOfBorg> with some changes, including this one
<infinity> LocutusOfBorg: Ahh.
<LocutusOfBorg> https://github.com/goldendict/goldendict/commit/a04917833c4fca355123157c4a03ea706fa31c19
<infinity> LocutusOfBorg: Okay, that makes more sense.
<LocutusOfBorg> and more sadness
<LocutusOfBorg> https://github.com/goldendict/goldendict/issues/714
<ogra_> infinity, mind takeing a look at this ? https://wiki.ubuntu.com/QATeam/OSSnapPromotion ... i have some issues to solve and wonder if you know an easy way that doesnt require to much cdimage hackery
<infinity> LocutusOfBorg: Casting count to a 32-bit type would possibly also fix it, but gross either way.  But if this code is stolen from libav and libav has a fix, that seems reasonable to me.
<ogra_> essentially we want to build three types of xenial images from different archives, while that is easy to achieve with cdimage vars and different crontab entries, i have no idea how i should actually reflect that on cdimage wrt output dirs ... i dont want all of them in the same www dir
<LocutusOfBorg> infinity, already uploaded on Ubuntu, and on deferred/5 for debian
<infinity> LocutusOfBorg: Shiny.
<LocutusOfBorg> I don't care about upstream code :)
<LocutusOfBorg> they want to embed stuff, they have to handle it
<LocutusOfBorg> and now I want hunspell to migrate :D
<infinity> LocutusOfBorg: FWIW, the goldendict maintainer is listed in the LowNMU table, you could delete the delayed upload and just upload straight to the queue.
<LocutusOfBorg> well, ubuntu is fixed, so I don't care too much about some days
<LocutusOfBorg> but I'll consider it
<infinity> Release Candidate: xenial-archive + xenial-security/-updates + snapd stable PPA
<infinity> ogra_: ^-- Why a PPA there?  We're SRUing snapd intentionally to keep it up to date.
<ogra_> infinity, yeah, thats apparently not desired anymore
<infinity> ogra_: ...
<cjwatson> Any chance somebody could look at python-libnacl and pymacaroons in xenial-proposed NEW?  Straight backports from yakkety, needed to avoid vendored code in snapcraft
<ogra_> instead snapd will be a dummy package (an installer for the ubuntu-core snap) and just use the executable from inside the snnap
<infinity> Oookay.
<ogra_> (there was a long and heated discussion about SRUing ... i kind of lost :/ )
<ogra_> the original wikipage only said "archive + -updates/-security" for the last image ...
<infinity> ogra_: So, I think our best bet here might be to invent a concept of sub-series in cdimage.  So you can do xenial-edge, xenial-beta, and xenial builds.
<infinity> ogra_: Then everything will end up in a pleasant subdir in the tree.
<ogra_> yeah, but that sounds like a lot of work ... i was wondering of there isnt something in place already that i could abuse
<ogra_> (something i dont know about)
<infinity> Not that I can think of off the top of my head.
<ogra_> i'm also not sure we want to expose the snaps on cdimage at all in the end ... once there is proper store integration everywhere
<infinity> cjwatson: I can have a look.  Bug paperwork all looks good, etc?
<ogra_> so the "switch" would only define the channel to upload to
<cjwatson> infinity: Hopefully; it's bug 1586770
<ubot5> bug 1586770 in python-libnacl (Ubuntu Xenial) "Add pymacaroons to xenial" [High,In progress] https://launchpad.net/bugs/1586770
<ogra_> instead of exposing it on cdimage at all
<infinity> ogra_: Right, I'm equally unconvinced about publishing them to the www tree.  And, indeed, if that's something we can avoid today, then this is almost a moot point.
<infinity> ogra_: Cause your cronjobs would just be '$var $var for-project thing && upload-to-store thing $channel'
<ogra_> right, they would have to go directly to the store instead ... though that still needs some kind fo "channel-selector" based on the archives used
<ogra_> ah
<infinity> ogra_: And then we need no knowledge of any of this.  You're just triggering a build and vacuuming the result.
<ogra_> you would separate the uploader ... clever
<ogra_> yeah, good idea ... i'll play with that idea. thanks !
<LocutusOfBorg> infinity, can you please remove vmtk/powerpc? insighttookit is going to be removed, and insighttookit4 is not powerpc ready
<LocutusOfBorg> Debian dropped it too
<infinity> cjwatson: I see that's all in universe.  No ongoing MIR for snapcraft?
<LocutusOfBorg> I guess also insighttookit can be removed, reverse-depends shows nifti2dicom and vmtk but only for powerpc (does it need to migrate first?)
<cjwatson> infinity: Not AFAIK ...
<infinity> cjwatson: Kay.  Well, if one happens, we can retroactively promote in xenial too.
<infinity> cjwatson: Lemme do some differy and get back to you.
<infinity> cjwatson: Oh, and add a bit to the bug about how you intend to test these, please.
<cjwatson> infinity: added
<infinity> cjwatson: ^^
<cjwatson> yay, thanks
<infinity> cjwatson: Will babysit binary NEW, but if I get distracted, feel free to self-accept.
<infinity> cjwatson: I'm not reviewing the new binaries for sanity, do be a dear and make sure your testplan involves at least importing both py2 and py3 modules to make sure they exist on disk and such. ;)
<cjwatson> Picky, picky.
<infinity> Yeah, I know. :)
<infinity> cjwatson: Oh, and given the regression potential is <= 0, if you need this ASAP for $reasons, I'm fine with fast-tracking the promotion once you've tested.
<cjwatson> I think next week is probably fine.  They seem to have temporarily vendored it anyway, but obviously want to get rid of that pretty soon.
<jbicha> could I get a yes or no on bug 1584522 please?
<ubot5> bug 1584522 in One Hundred Papercuts "[UIFe] Don't show GNOME Books by default" [Medium,Triaged] https://launchpad.net/bugs/1584522
<infinity> jbicha: Seems entirely reasonable to me, +1
<slangasek> bdmurray: lp:~brian-murray/ubuntu-archive-tools/add-release-tasks merged; I do note a lot of code duplication between sru-accept and sru-review which is suboptimal and ought to be refactored, but no sense in blocking on that right now
<sergiusens> slangasek hey, quick question, will this get stuck in xenial when I want to SRU/MRE it as well https://launchpad.net/ubuntu/yakkety/+queue?queue_state=0&queue_text=snapcraft ?
<slangasek> sergiusens: if you are following https://wiki.ubuntu.com/SnapcraftUpdates, it should not get stuck
<sergiusens> slangasek yeah, we are following that, it's just that this is the first time snapcraft gets stuck in the 'new' queue
<slangasek> oh
<slangasek> sergiusens: so it will also have to go through binary new, but it shouldn't get "stuck" beyond possibly you having to whack an archive admin into action ;)
<sergiusens> slangasek I just checked and you happen to be one :-)
<slangasek> yes
<sergiusens> not sure I should whack anyone though :-P
<slangasek> sergiusens: 'lintian -I snapcraft_2.10+16.10_amd64.changes' has a few things to say
 * sergiusens checks
<slangasek> no blockers, but best practice is to look at lintian output for both the source and binary packages
<slangasek> ^^ and, accepted for yakkety
<sergiusens> slangasek well my plan is to upload the same thing for X so if it is going to be blocked I'd like to know what would block it
<sergiusens> slangasek some are really easy to fix and I can
<slangasek> sergiusens: nope, none of those are blockers for xenial either
<sergiusens> slangasek thanks btw!
<sergiusens> slangasek ok, I'll log a bug against snapcraft to fix those for 2.11
<sergiusens> and get you to review
<sergiusens> thanks!
#ubuntu-release 2017-05-29
<teward> ooh wow pymssql landed in artful o.O
-queuebot:#ubuntu-release- New binary: vala [s390x] (artful-proposed/universe) [0.36.3-1~git1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: vala [amd64] (artful-proposed/universe) [0.36.3-1~git1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: vala [ppc64el] (artful-proposed/universe) [0.36.3-1~git1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: vala [i386] (artful-proposed/universe) [0.36.3-1~git1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: vala [arm64] (artful-proposed/universe) [0.36.3-1~git1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: vala [armhf] (artful-proposed/universe) [0.36.3-1~git1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted htmlmin [amd64] (artful-proposed) [0.1.10-1]
-queuebot:#ubuntu-release- New: accepted pymssql [amd64] (artful-proposed) [2.1.3+dfsg-1]
-queuebot:#ubuntu-release- New: accepted pymssql [armhf] (artful-proposed) [2.1.3+dfsg-1]
-queuebot:#ubuntu-release- New: accepted pymssql [ppc64el] (artful-proposed) [2.1.3+dfsg-1]
-queuebot:#ubuntu-release- New: accepted slick-greeter [amd64] (artful-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted slick-greeter [armhf] (artful-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted slick-greeter [ppc64el] (artful-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted node-stream-array [amd64] (artful-proposed) [1.1.2-1]
-queuebot:#ubuntu-release- New: accepted pymssql [i386] (artful-proposed) [2.1.3+dfsg-1]
-queuebot:#ubuntu-release- New: accepted slick-greeter [arm64] (artful-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted slick-greeter [s390x] (artful-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted pymssql [arm64] (artful-proposed) [2.1.3+dfsg-1]
-queuebot:#ubuntu-release- New: accepted slick-greeter [i386] (artful-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted pymssql [s390x] (artful-proposed) [2.1.3+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: libzen (zesty-proposed/universe) [0.4.34-1 => 0.4.34-1ubuntu0.16.04.1] (no packageset)
<LocutusOfBorg> [02:18:41 AM] <rbasak> mapreri: looking, but also, that sounds like a missing Breaks clause then, no?
<LocutusOfBorg> ^^ wrt virtualbox, rbasak did you spot an issue I'm not aware of?
<LocutusOfBorg> BTW thanks for releasing the update so quickly :)
-queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (zesty-proposed) [2.0.8-0ubuntu1~17.04.1]
<rbasak> <mapreri> rbasak: Gianfranco asked me to tell you please move virtualbox-ext-pack to release too, not only virtualbox (as otherwise update in systems with both installed is broken)
<rbasak> ...
<rbasak> <rbasak> mapreri: looking, but also, that sounds like a missing Breaks clause then, no?
<rbasak> LocutusOfBorg: ^
<rbasak> Also, thank infinity. I didn't touch Zesty wrt. these packages I don't think.
<LocutusOfBorg> I read the discussion log, but I don't understand where is the missing break... in ext-pack?
<rbasak> I don't know, but if a user updates an SRU package A that without also installing the SRU for B causes B to break, then surely there needs the SRU for A needs to declare a "Breaks: B (<< sru-version)"?
<rbasak> In other words, we should never end up in that situation (if we know of it in advance, of course) because the SRU package should always be able to declare a Breaks to ensure proper ordering.
-queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (yakkety-proposed) [2.0.8-0ubuntu1~16.10.1]
<LocutusOfBorg> the problem is: virtualbox *works* without the ext pack
<LocutusOfBorg> but if you save a machine, uninstall the ext pack, start it again, you loose the saved state, because a running machine can't unplug devices (e.g. usb) without rebooting
<LocutusOfBorg> so, I can't force people having the ext pack, and if they already have, they are forced to 1) upgrade it, 2) remove it
<LocutusOfBorg> not sure how britney let vbox migrate by breaking ext-pack
-queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (xenial-proposed) [2.0.8-0ubuntu1~16.04.1]
<LocutusOfBorg> I'm pretty sure if I don't update the ext pack, vbox can't migrate (e.g. in artful)
-queuebot:#ubuntu-release- Unapproved: rejected apt [source] (zesty-proposed) [1.4.2~17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [source] (zesty-proposed) [3.24.2-0ubuntu0.1]
<rbasak> LocutusOfBorg: no britney for SRUs.
<LocutusOfBorg> ok names sense
<rbasak> LocutusOfBorg: so it sounds like a newer virtualbox package in updates should Breaks all older ext packs?
<rbasak> LocutusOfBorg: then apt would not update until both are available.
<rbasak> (unless the user has none installed)
<LocutusOfBorg> actually it is the ext pack that breaks older vbox
<LocutusOfBorg> s/break/depends on a strict version
<rbasak> Perhaps I don't understand what the actual problem was then.
<LocutusOfBorg> you are probably right, you understood the problem
<LocutusOfBorg> I should suggest the ext pack, and break for older versions
<LocutusOfBorg> but again, the ext pack is not installable if the version is not the same, so it just gets removed
<LocutusOfBorg> since it is optional
<LocutusOfBorg> I can't force people installing it, because non-free
 * LocutusOfBorg goes back to dailywork
-queuebot:#ubuntu-release- Unapproved: accepted vlan [source] (zesty-proposed) [1.9-3.2ubuntu2.17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted vlan [source] (yakkety-proposed) [1.9-3.2ubuntu2.16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted vlan [source] (xenial-proposed) [1.9-3.2ubuntu1.16.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted vlan [source] (trusty-proposed) [1.9-3ubuntu10.2]
<jbicha> sil2100: I replied on LP: #1672175
<ubot5> Launchpad bug 1672175 in gnome-shell (Ubuntu Yakkety) "gnome-shell should recommend chrome-gnome-shell" [Low,In progress] https://launchpad.net/bugs/1672175
-queuebot:#ubuntu-release- Unapproved: percona-xtradb-cluster-5.5 (trusty-proposed/universe) [5.5.37-25.10+dfsg-0ubuntu0.14.04.2 => 5.5.37-25.10+dfsg-0ubuntu0.14.04.3] (no packageset)
<sil2100> jbicha: thanks, looking!
<sil2100> jbicha: all clear, thanks, didn't read it fully it seems - I guess we might want to think about switching the main gnome-shell task to something different than Fix Released
<sil2100> jbicha: since otherwise it might give the wrong info
<sil2100> That being said, all's good otherwise
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [source] (yakkety-proposed) [3.20.4-0ubuntu3]
<slashd> sil2100, good day could you please have a look at LP: 1657256 ? it is waiting in the Trusty upload queue  : https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=percona-xtradb-cluster-5.5
<ubot5> Launchpad bug 1657256 in percona-xtradb-cluster-5.5 (Ubuntu Trusty) "Percona crashes when doing a a 'larger' update" [Medium,In progress] https://launchpad.net/bugs/1657256
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [source] (xenial-proposed) [3.18.5-0ubuntu0.3]
<sil2100> slashd: hey! Sure thing
<slashd> sil2100, thanks, much appreciated
-queuebot:#ubuntu-release- Unapproved: accepted percona-xtradb-cluster-5.5 [source] (trusty-proposed) [5.5.37-25.10+dfsg-0ubuntu0.14.04.3]
-queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (trusty-proposed) [1.0.10-0ubuntu1]
<slashd> thanks sil2100
<sil2100> yw!
<slashd> sil2100, can I ask you to sponsor a patch in devel release ? I only have the right for stable release ?
<sil2100> slashd: sure, I can take a look at it and see if I can help - what's the bug number?
<slashd> sil2100, https://bugs.launchpad.net/ubuntu/artful/+source/ebtables/+bug/1645324 patch: https://launchpadlibrarian.net/319813794/artful_lp1645324.debdiff
<ubot5> Ubuntu bug 1645324 in ebtables (Ubuntu Artful) "ebtables: Lock file handling has races" [Medium,In progress]
<slashd> sil2100, It has been made by a colleague of mine before he goes to paternity leave, it look good on my side but note that upstream project of ebtables is almost dead in favour of nft, and debian upstream doesn't answer to our request to include the patch in debian, I talked to apw, and he said that he didn't see a problem for us to upload it in Ubuntu
<slashd> sil2100, so the patch will be in ubuntu only and hopefull debian if they respond to the bug
<sil2100> slashd: ok, will dive in in a minute, just need to finish up some tasks while my SRU hat is still on
<slashd> sil2100, sure thanks
<sil2100> slashd: I'm very liberal in such cases, so as long as it's been submitted to Debian I'm fine with releasing to Ubuntu - sooner or later we'll just get rid of the delta
<sil2100> And sometimes it's taking a bit too long
<slashd> sil2100, yep it was submitted to Debian via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860590
<ubot5> Debian bug 860590 in ebtables "ebtables: Use real locking in ebtables (LP: #1645324)" [Normal,Open]
<sil2100> Yeah, saw that, also saw not much movement, so in my eyes that's even more of a +1 - anyway, looking at the debdiff now
<slashd> sil2100, ok
<sil2100> slashd: all good, uploading - I just added a Bug-Debian field to the dep-3 header of the patch
<slashd> sil2100, ok thanks again, enough request for me today ;)
<sil2100> slashd: no worries, I'm here to help ;)
-queuebot:#ubuntu-release- Unapproved: libzen (zesty-proposed/universe) [0.4.34-1 => 0.4.34-1ubuntu0.17.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libzen (yakkety-proposed/universe) [0.4.33-3 => 0.4.33-3ubuntu0.16.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libzen (xenial-proposed/universe) [0.4.32-1 => 0.4.32-1ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ebtables (trusty-proposed/main) [2.0.10.4-3ubuntu1 => 2.0.10.4-3ubuntu1.14.04.1] (ubuntu-desktop, ubuntu-server)
<slashd> For SRU, I took over a bug from someonelse and I have uploaded a fix for something that has been already uploaded accidentally, could you please, if possible, remove the one uploaded in "2017-04-03" and keep the one I did a few minutes ago ? https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=ebtables
<slashd> infinity^
-queuebot:#ubuntu-release- Unapproved: ebtables (zesty-proposed/main) [2.0.10.4-3.5ubuntu1 => 2.0.10.4-3.5ubuntu1.17.04.1] (edubuntu, ubuntu-server)
<infinity> slashd: I'm sure I can manage that.
-queuebot:#ubuntu-release- Unapproved: rejected ebtables [source] (trusty-proposed) [2.0.10.4-3ubuntu1.14.04.1]
<slashd> infinity, thank you sorry for the inconvenient
-queuebot:#ubuntu-release- Unapproved: lxc (xenial-proposed/main) [2.0.8-0ubuntu1~16.04.1 => 2.0.8-0ubuntu1~16.04.2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ebtables (yakkety-proposed/main) [2.0.10.4-3.5ubuntu1 => 2.0.10.4-3.5ubuntu1.16.10.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lxc (zesty-proposed/main) [2.0.8-0ubuntu1~17.04.1 => 2.0.8-0ubuntu1~17.04.2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lxc (yakkety-proposed/main) [2.0.8-0ubuntu1~16.10.1 => 2.0.8-0ubuntu1~16.10.2] (ubuntu-server)
<stgraber> those lxc uploads are follow-up to the previous round of SRUs, works around a build failure on ppc64el with older gcc/glibc (not sure which is to blame but it builds fine in artful)
-queuebot:#ubuntu-release- Unapproved: ebtables (xenial-proposed/main) [2.0.10.4-3.4ubuntu1 => 2.0.10.4-3.4ubuntu2] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: unittest++ [i386] (artful-proposed/universe) [2.0.0-1~exp2] (no packageset)
-queuebot:#ubuntu-release- New binary: unittest++ [s390x] (artful-proposed/universe) [2.0.0-1~exp2] (no packageset)
-queuebot:#ubuntu-release- New binary: unittest++ [ppc64el] (artful-proposed/universe) [2.0.0-1~exp2] (no packageset)
-queuebot:#ubuntu-release- New binary: unittest++ [amd64] (artful-proposed/universe) [2.0.0-1~exp2] (no packageset)
-queuebot:#ubuntu-release- New binary: unittest++ [arm64] (artful-proposed/universe) [2.0.0-1~exp2] (no packageset)
-queuebot:#ubuntu-release- New binary: unittest++ [armhf] (artful-proposed/universe) [2.0.0-1~exp2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-safe-buffer [amd64] (artful-proposed/none) [5.0.1-2] (no packageset)
#ubuntu-release 2017-05-30
-queuebot:#ubuntu-release- New: accepted node-safe-buffer [amd64] (artful-proposed) [5.0.1-2]
-queuebot:#ubuntu-release- New: accepted unittest++ [arm64] (artful-proposed) [2.0.0-1~exp2]
-queuebot:#ubuntu-release- New: accepted unittest++ [i386] (artful-proposed) [2.0.0-1~exp2]
-queuebot:#ubuntu-release- New: accepted unittest++ [s390x] (artful-proposed) [2.0.0-1~exp2]
-queuebot:#ubuntu-release- New: accepted unittest++ [amd64] (artful-proposed) [2.0.0-1~exp2]
-queuebot:#ubuntu-release- New: accepted unittest++ [ppc64el] (artful-proposed) [2.0.0-1~exp2]
-queuebot:#ubuntu-release- New: accepted unittest++ [armhf] (artful-proposed) [2.0.0-1~exp2]
<LocutusOfBorg> hello, why is vivid still marked as "supported"?
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/mosquitto
<LocutusOfBorg> also precise
<cjwatson> vivid was because phone, though can probably go now.  that would be on infinity
<cjwatson> precise is like that because otherwise ESM would be a pain
<darkxst> can someone please reject libgweather from zesty sru queue, I messed up the bug reference in the changelog
<LocutusOfBorg> ok but I have a CVE to fix... should I prepare debdiffs for them too?
-queuebot:#ubuntu-release- New binary: plasma-discover [ppc64el] (artful-proposed/universe) [5.10.0-0ubuntu1] (kubuntu)
<jbicha> LocutusOfBorg: I believe the answer is 'no', you don't need to worry about precise or vivid
-queuebot:#ubuntu-release- New binary: plasma-discover [s390x] (artful-proposed/universe) [5.10.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: plasma-discover [i386] (artful-proposed/universe) [5.10.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: plasma-discover [amd64] (artful-proposed/universe) [5.10.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: plasma-discover [arm64] (artful-proposed/universe) [5.10.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: plasma-discover [armhf] (artful-proposed/universe) [5.10.0-0ubuntu1] (kubuntu)
<LocutusOfBorg> I guess so, thanks
-queuebot:#ubuntu-release- New binary: kwin [ppc64el] (artful-proposed/universe) [4:5.10.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kwin [amd64] (artful-proposed/universe) [4:5.10.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: rope [amd64] (artful-proposed/universe) [0.10.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kwin [i386] (artful-proposed/universe) [4:5.10.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kwin [s390x] (artful-proposed/universe) [4:5.10.0-0ubuntu1] (kubuntu)
<LocutusOfBorg> cjwatson, can I cherry-pick this change http://launchpadlibrarian.net/179677049/dput_0.9.6.4ubuntu2_0.9.6.4ubuntu3.diff.gz in dupload too?
<LocutusOfBorg> s/can/should
-queuebot:#ubuntu-release- New binary: kwin [armhf] (artful-proposed/universe) [4:5.10.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kwin [arm64] (artful-proposed/universe) [4:5.10.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: rejected libgweather [source] (zesty-proposed) [3.24.0-0ubuntu2.1]
<apw> darkxst, ^
-queuebot:#ubuntu-release- New: accepted kwin [amd64] (artful-proposed) [4:5.10.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kwin [armhf] (artful-proposed) [4:5.10.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kwin [ppc64el] (artful-proposed) [4:5.10.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kwin [arm64] (artful-proposed) [4:5.10.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kwin [s390x] (artful-proposed) [4:5.10.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kwin [i386] (artful-proposed) [4:5.10.0-0ubuntu1]
<acheronUK> TY ^^^ :)
-queuebot:#ubuntu-release- New: accepted plasma-discover [amd64] (artful-proposed) [5.10.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted plasma-discover [armhf] (artful-proposed) [5.10.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted plasma-discover [ppc64el] (artful-proposed) [5.10.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted plasma-discover [arm64] (artful-proposed) [5.10.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted plasma-discover [s390x] (artful-proposed) [5.10.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted plasma-discover [i386] (artful-proposed) [5.10.0-0ubuntu1]
<apw> acheronUK, accepting those modulo our discussion
<acheronUK> apw: thankyou. I will formally report that upstream and seek a resolution
-queuebot:#ubuntu-release- New: accepted rope [amd64] (artful-proposed) [0.10.5-1]
<bdmurray> apw: Could you look at releaseing ubuntu-release-upgrader fixing bug 1692092?
<ubot5> bug 1692092 in ubuntu-release-upgrader (Ubuntu Zesty) "not possible to upgrade from Xenial and jump over an unsupported release" [High,Fix committed] https://launchpad.net/bugs/1692092
<apw> bdmurray, yep
<apw> bdmurray, looks good, and released
<bdmurray> apw: great, thanks
-queuebot:#ubuntu-release- Packageset: Added linux-azure to kernel in artful
-queuebot:#ubuntu-release- Packageset: Added linux-azure to kernel in xenial
-queuebot:#ubuntu-release- Packageset: Added linux-meta-azure to kernel in xenial
-queuebot:#ubuntu-release- Packageset: Added linux-azure to kernel in yakkety
-queuebot:#ubuntu-release- Packageset: Added linux-meta-azure to kernel in yakkety
-queuebot:#ubuntu-release- Packageset: Added linux-azure to kernel in zesty
-queuebot:#ubuntu-release- Packageset: Added linux-meta-azure to kernel in zesty
-queuebot:#ubuntu-release- Unapproved: rejected nplan [source] (xenial-proposed) [0.22~16.04.1]
-queuebot:#ubuntu-release- Packageset: Added linux-meta-azure to kernel in artful
-queuebot:#ubuntu-release- Unapproved: grub2 (artful-proposed/main) [2.02~beta3-4ubuntu5 => 2.02~beta3-4ubuntu5] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (artful-proposed/main) [2.02~beta3-4ubuntu5 => 2.02~beta3-4ubuntu5] (core)
<slangasek> infinity, xnox, bdmurray: should the ddeb archive key be included in the ubuntu-keyring package?
<Ukikie> LP: #643623
<ubot5> Launchpad bug 643623 in ubuntu-keyring (Ubuntu) "Should ubuntu-keyring include the debug archive key?" [Undecided,Confirmed] https://launchpad.net/bugs/643623
<Ukikie> (I'd say so.)
<infinity> slangasek: Maybe.  Or in its own package.
-queuebot:#ubuntu-release- Unapproved: rejected libzen [source] (zesty-proposed) [0.4.34-1ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: vlan (trusty-proposed/main) [1.9-3ubuntu10.2 => 1.9-3ubuntu10.3] (core)
-queuebot:#ubuntu-release- Unapproved: vlan (xenial-proposed/main) [1.9-3.2ubuntu1.16.04.2 => 1.9-3.2ubuntu1.16.04.3] (core)
-queuebot:#ubuntu-release- Unapproved: vlan (zesty-proposed/main) [1.9-3.2ubuntu2.17.04.1 => 1.9-3.2ubuntu2.17.04.2] (core)
-queuebot:#ubuntu-release- Unapproved: vlan (yakkety-proposed/main) [1.9-3.2ubuntu2.16.10.1 => 1.9-3.2ubuntu2.16.10.2] (core)
<slangasek> xnox: what's the purpose of SHA512SUMS.txt.asc in ubuntu-keyring source, given that the source package as a whole is signed?
<slashd> For SRU, vlan pkg found in -proposed for T/X/Y/Z has a regression, a new fix (fixing the regression) has been uploaded ^^ in respective upload queues (with incremented version). So the new version can overwrite/replace the actual -proposed one.
<bdmurray> wxl: I forget were you going to do some research into bug 1693038 and xubuntu?
<ubot5> bug 1693038 in software-properties (Ubuntu) "needs to support restart on Lubuntu and Xubuntu" [Medium,Triaged] https://launchpad.net/bugs/1693038
<wxl> bdmurray: sorry i dont do much with xubuntu. check with flocculant
<bdmurray> wxl: Sorry I meant lubuntu.
<wxl> been busy but i'll look into it eventually. ma want to check with tsimonq2 in the meanwhile
<flocculant> bdmurray: is that for reboot after nvidia for example?
<flocculant> if so pretty sure it didn't work last time I looked at that
<bdmurray> flocculant: right, it'll only work for gnome and I'm happy to fix it but need to know what to use in Xubuntu / Lubuntu
<flocculant> bdmurray: ack - then I would believe what unit193 said
<flocculant> as it stands in Xubuntu I see absolutely nothing following installing nvidia
<flocculant> well - all I could do is close
<jbicha> gnome-user-docs & gnome-getting-started-docs were promoted to main but could we get all of their binary pkgs in main too for the other languages?
<jbicha> so maybe we just need to add those pkgs to the supported seed?
<cyphermox> how would they normally get installed? via langpacks?
<GunnarHj> cyphermox: No, pulled via pkg_depends in language-selector.
<cyphermox> yeah, that's pretty much what I meant
<jbicha> or equivalent in gnome-control-center/gnome-software if we end up not needing language-selector
-queuebot:#ubuntu-release- Unapproved: yubikey-piv-manager (zesty-proposed/universe) [1.3.0-1 => 1.3.0-1+ubuntu17.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: yubikey-piv-manager (zesty-proposed/universe) [1.3.0-1 => 1.3.0-1+ubuntu17.04.1] (no packageset)
<bdmurray> cjwatson: Is there anyway to speed this getPublishedSources query up? https://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/view/head:/phased-updater#L581
#ubuntu-release 2017-05-31
<tsimonq2> infinity, slangasek, Laney: Any volunteers for Nusakan tracking for Artful Alpha 1? :) https://wiki.ubuntu.com/ArtfulAardvark/ReleaseTaskSignup (not urgent because the release is in a little less than a month, but I'd still like to get that squared away...)
<infinity> tsimonq2: Ask stgraber first.  He usually does A1 if he's not travelling.
<tash> any chance to get collectd version 5.5 on Trusty? Looks like Xenial has it, but Trusty doesn't.
<tash> https://packages.ubuntu.com/search?keywords=collectd
<cjwatson> bdmurray: That query itself is fast enough (i.e. it returns the first batch in a reasonable time), but by iterating over the whole collection you're asking Launchpad to iterate over everything published to certain series since 2013-06-21, which is just a lot of data.  Why do you have to iterate over all of that every time?
 * apw can vouch for the usefulness (in a performance sense) of caching with the created since thing
<cjwatson> order_by_date=True helps a lot, but you still don't want to iterate over years of data.
-queuebot:#ubuntu-release- Unapproved: walinuxagent (zesty-proposed/main) [2.2.9-0ubuntu1 => 2.2.12-0ubuntu1~17.04.1] (ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: walinuxagent (trusty-proposed/main) [2.2.9-0ubuntu1~14.04.1 => 2.2.12-0ubuntu1~14.04.1] (ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: walinuxagent (yakkety-proposed/main) [2.2.9-0ubuntu1~16.10.1 => 2.2.12-0ubuntu1~16.10.1] (ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: walinuxagent (xenial-proposed/main) [2.2.9-0ubuntu1~16.04.1 => 2.2.12-0ubuntu1~16.04.1] (ubuntu-cloud, ubuntu-server)
<sil2100> To anyone from the SRU team - could you please take a look at the new walinuxagent in the queues? ^
<sil2100> apw: ^ would you have a moment to take a look at those? Those are kinda special (plain backports), so reviewing them usually is quite fast
 * apw can shortly yes ...
<sil2100> Thanks! :)
<darkxst> apw, thanks!
<apw> sil2100, it is reasonable to state that this daemon need to be kept up to date to keep it in step with the azure substrate, right ?
<sil2100> apw: yeah
<apw> sil2100, this seems to have a new systemd unit in it, i have not seen anything for upstart for trusty ?
<sil2100> apw: you mean the init/arch/waagent.service addition?
<apw> sil2100, lyeah
<sil2100> apw: it's only for arch linux, it's not relevant for us - we have the .service file in init/ubuntu/ + we ship upstart configs through the packaging
<apw> sil2100, ack thanks
-queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (zesty-proposed) [2.2.12-0ubuntu1~17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (yakkety-proposed) [2.2.12-0ubuntu1~16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (xenial-proposed) [2.2.12-0ubuntu1~16.04.1]
<sil2100> apw: thank you!
-queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (trusty-proposed) [2.2.12-0ubuntu1~14.04.1]
<ogra_> * #ubuntu-devel :Cannot join channel (+r) - you need to be identified with services
<ogra_> huh ?
<ogra_> since when is that in place ?
<Laney> spam attack the other day, maybe since then
<ogra_> hmpf
-queuebot:#ubuntu-release- Unapproved: zfs-linux (zesty-proposed/main) [0.6.5.9-5ubuntu4 => 0.6.5.9-5ubuntu4.1] (core)
-queuebot:#ubuntu-release- Unapproved: zfs-linux (yakkety-proposed/main) [0.6.5.8-0ubuntu4.2 => 0.6.5.8-0ubuntu4.3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: zfs-linux (xenial-proposed/main) [0.6.5.6-0ubuntu16 => 0.6.5.6-0ubuntu17] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected yubikey-piv-manager [source] (zesty-proposed) [1.3.0-1+ubuntu17.04.1]
<apw> ^ duplicate in the queue, replaced by one with a bug number
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (zesty-proposed) [0.6.5.9-5ubuntu4.1]
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (yakkety-proposed) [0.6.5.8-0ubuntu4.3]
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (xenial-proposed) [0.6.5.6-0ubuntu17]
<slashd> Good day rbasak, could you please look at both packages waiting in the upload queue... #1 pkg: vlan releases: t/x/y/z (LP: #1573272) - The fix is in -proposed, but a regression has been found, and we re-upload a modified patch to fix it, so the current -proposed can be overwritten. #2 pkg: ebtables releases: t/x/y/z (LP :#1645324), upstream project is un-maintained in favour of nft. We submitted the patch to Debian, no
<slashd> merge yet, but I talked with sil2100 which sponsor the patch in devel release and was okay for me to go ahead with the upload in stable releases.
<ubot5> Launchpad bug 1573272 in vlan (Ubuntu Zesty) "default gateway route not installed for bond interfaces through reboot" [Medium,In progress] https://launchpad.net/bugs/1573272
-queuebot:#ubuntu-release- Unapproved: python-werkzeug (trusty-proposed/main) [0.9.4+dfsg-1.1ubuntu2 => 0.9.4+dfsg-1.1ubuntu2.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-werkzeug (xenial-proposed/main) [0.10.4+dfsg1-1ubuntu1 => 0.10.4+dfsg1-1ubuntu1.1] (ubuntu-server)
<Laney> autopkgtest queues are more or less empty - mass retrying the regressions
 * apw nods
<Laney> ohhh yeahhhh that's the stuff
<bdmurray> cjwatson: While I don't have to that specific date I want to find out which packages have SRUs that are still phasing and that could be quite old e.g. trusty mugshot SRU from 947 days ago.
<bdmurray> cjwatson: Is there some better way to find those packages or should I just be caching the ones still phasing?
<cjwatson> hmmm
<cjwatson> do file a bug against LP about this, but I think maybe we should extend Archive.getPublishedBinaries to let you query only the ones with non-None phased_update_percentage?
<slangasek> SRU team have any opinions on LP: #1686183 and forward-copying to post-precise?  I think my intent had been to binary copy it forward since it's currently a trivial shell script, any objections?
<ubot5> Launchpad bug 1686183 in ubuntu-meta (Ubuntu) "Ship ubuntu-advantage in ubuntu-minimal" [Undecided,New] https://launchpad.net/bugs/1686183
<cjwatson> you'd then have to aggregate those into source packages, but it would be a much smaller data set
<bdmurray> I also think the complete query is faster if the release is trusty instead of xenial.
<cjwatson> that seems backwards, but who knows - I doubt that will be a productive avenue of investigation TBH
<cjwatson> an orders-of-magnitude reduction in the size of the data set is going to beat anything like that
<bdmurray> Sure, I just think there might be another issue if trusty really is faster than xenial.
<cjwatson> I'd expect the size of the xenial set to be smaller, but is that in fact the case?
<cjwatson> also, xenial had one more architecture; that might make a difference
<cjwatson> you have one bit where you're making per-binary queries
<cjwatson> at least one that I immediately see
<cjwatson>                     for allpb in archive.getPublishedBinaries(
<cjwatson>                             exact_match=True, pocket='Updates',
<cjwatson>                             binary_name=pbs[0].binary_package_name):
<cjwatson>                         if allpb.distro_arch_series.distroseries == release:
<cjwatson> you could optimise that by either (a) doing string manipulations on allpb.distro_arch_series_link so that you don't have to go to the webservice to fetch the contents of the link, or (b) keeping a local cache of distro_series objects and evaluating that yourself
<cjwatson> I think this is a bit of a gotcha in lazr.restfulclient
<bdmurray> cjwatson: Thanks, I'll have a look at that and file the LP bug you suggested.
<cjwatson> yep, quick local test says that the chunk of code above is actually two webservice GETs per binary
<cjwatson> so fixing that will make a big difference
<cjwatson> (one for the distroarchseries, one for the distroseries)
-queuebot:#ubuntu-release- Unapproved: rejected lxd [source] (xenial-proposed) [2.0.10-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: lxd (xenial-proposed/main) [2.13-0ubuntu3~ubuntu16.04.1 => 2.0.10-0ubuntu1~16.04.1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: nplan (xenial-proposed/universe) [0.21~16.04.1 => 0.22~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: chrome-gnome-shell (xenial-proposed/universe) [9-0ubuntu1~ubuntu16.04.2 => 9-0ubuntu1~ubuntu16.04.3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: chrome-gnome-shell (yakkety-proposed/universe) [9-0ubuntu1~ubuntu16.10 => 9-0ubuntu1~ubuntu16.10.1] (no packageset)
<jbicha> any SRU Team member have time to look at those chrome-gnome-shell updates? ^ it fixes a regression-proposed
 * valorie goes outside
-queuebot:#ubuntu-release- Unapproved: nplan (yakkety-proposed/main) [0.12 => 0.22~16.10.1] (no packageset)
<tsimonq2> stgraber: Hey there :)
<tsimonq2> stgraber: Are you able to help with Nusakan for Alpha 1?
-queuebot:#ubuntu-release- Unapproved: nplan (zesty-proposed/main) [0.20 => 0.22~17.04.1] (core)
<stgraber> tsimonq2: know the dates?
<tsimonq2> stgraber: June 29th is that Thursday
<stgraber> tsimonq2: yeah, I'll take care of the nusakan bits, not travelling that week
<tsimonq2> stgraber: Ok, want to add yourself to the ReleaseTaskSignup page or do you want me to?
<stgraber> I'll do it
<tsimonq2> Ok
<nacc> infinity: how do deletions from debian get propogated to ubuntu? src:php-arc was being held in ubuntu (it's been deleted in Debian), because it was removed without fixing its revdeps there. I fixed the revdeps in ubuntu in artful, and now src:php-arc has none and can be removed.
<jbicha> nacc: if a package has Ubuntu-specific changes, it's a lot more difficult for it to be noticed
<jbicha> you can file a removal bug when you find those and subscribe ubuntu-archive
<nacc> jbicha: yes, i understand
<jbicha> those bugs are usually reviewed at least once near the end of the release cycle
<nacc> jbicha: ack, thanks
#ubuntu-release 2017-06-01
-queuebot:#ubuntu-release- Unapproved: accepted ebtables [source] (zesty-proposed) [2.0.10.4-3.5ubuntu1.17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted ebtables [source] (yakkety-proposed) [2.0.10.4-3.5ubuntu1.16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted ebtables [source] (xenial-proposed) [2.0.10.4-3.4ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ebtables [source] (trusty-proposed) [2.0.10.4-3ubuntu1.14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted vlan [source] (zesty-proposed) [1.9-3.2ubuntu2.17.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted vlan [source] (yakkety-proposed) [1.9-3.2ubuntu2.16.10.2]
-queuebot:#ubuntu-release- Unapproved: accepted vlan [source] (xenial-proposed) [1.9-3.2ubuntu1.16.04.3]
-queuebot:#ubuntu-release- Unapproved: accepted vlan [source] (trusty-proposed) [1.9-3ubuntu10.3]
<slashd> thanks sil2100 for the ebtables and vlan
<slashd> bdmurray, Good morning, sil2100 if you have some time today could you please look at the following -proposed Green packages (verified) -- https://people.canonical.com/~ubuntu-archive/pending-sru.html) for "sssd" (Trusty) & "openssl" (Zesty/Yakkety/Xenial) ?
<jbicha> also, could you look at the chrome-gnome-shell unapproved SRUs today to fix a regression-proposed issue?
<infinity> jbicha: X and Y?
<jbicha> yes
-queuebot:#ubuntu-release- Unapproved: accepted chrome-gnome-shell [source] (xenial-proposed) [9-0ubuntu1~ubuntu16.04.3]
<infinity> jbicha: Done and done.
<jbicha> thank you
-queuebot:#ubuntu-release- Unapproved: accepted chrome-gnome-shell [source] (yakkety-proposed) [9-0ubuntu1~ubuntu16.10.1]
<sil2100> slashd: will look in a minute :)
<sil2100> slashd: hmmm, I'm looking at the openssl bits and I'm a bit concerned
<sil2100> slashd: two things:
<sil2100> slashd: 1) I see autopkgtest regressions in xenial and yakkety - are those documented somehow on the bug? If those are expected to fail, could you mention  that in the bug?
<sil2100> slashd: 2) There was an automated 'verification-failed' posted to the bug as per reports from the version in -proposed but the tags are getting removed - what's the reason for those auto-failures being reported? Is it unrelated? Not an issue?
<sil2100> slashd: also, woudl be nice if someone included some info about the tests performed and version numbers - our new SRU procedures require/recommend putting test details during verification
<LocutusOfBorg> Laney, https://code.launchpad.net/~costamagnagianfranco/+recipe/boinc-upstream-daily
<LocutusOfBorg> seems your latest debhelper upload is to blame?
<LocutusOfBorg> I don't see the automatic autoreconf being run, and the difference is just in toolchain
<jbicha> LocutusOfBorg: as a workaround, try updating debian/compat to 10 ?
<LocutusOfBorg> it would probably break older builds :)
<jbicha> LocutusOfBorg: how far back are you building for? yakkety has dh 10 and xenial-backports does too
<LocutusOfBorg> yeah probably time to move to compat 10, but parallel builds are broken, so I'm forced to add some --no-parallel
<LocutusOfBorg> anyhow, I don't care about artful, as long as Laney knows about the issue :)
<Laney> sec
<Laney> if you've got time, please try it on Debian too, and report a bug there?
<jbicha> I think it would be more important for you to tell Debian's dh maintainers about the issue :)
<LocutusOfBorg> Laney, sure, experimental ongoing
<LocutusOfBorg> sigh, I can't blame Laney anymore :p http://debomatic-amd64.debian.net/distribution#experimental/boinc/7.6.33+dfsg-12/buildlog
<LocutusOfBorg> so... RC bug?
<slashd> sil2100, the regression are recurring failure for quite some time. wgrant can you document the testing you have made in bug (LP: #1674399) the new SRU procedures require/recommend putting test details during verification. (see sil2100 comment above)
<ubot5> Launchpad bug 1674399 in openssl (Ubuntu Zesty) "OpenSSL CPU detection for AMD Ryzen CPUs" [Medium,Fix committed] https://launchpad.net/bugs/1674399
<slashd> sil2100, most of them, I'll review them one by one to make sure
<rbasak> sil2100, slashd: IMHO, the procedures haven't changed; we just started pushing people to actually follow them :)
<sil2100> rbasak: sure, right
<slashd> rbasak, which is good
<slashd> rbasak, I normally do it, I haven't notice for that particular one that the details wasn't there.
<sil2100> Indeed, your bugs usually are very detailed in regards to testing
<sil2100> A +1 on that
<slashd> sil2100, thanks, so I'll have another look at openssl, and will get back to you. what about "sssd" ?
<sil2100> slashd: I released it before moving on to openssl :)
<slashd> sil2100, thanks you very much
<sil2100> yw!
<slashd> sil2100, do you know how can I find the test before two versions if not listed in here : http://autopkgtest.ubuntu.com/packages/p/postgresql-9.5/xenial/armhf. For instance, I see it passed for "openssl/1.0.2g-1ubuntu4.3" and failed for "openssl/1.0.2g-1ubuntu4.7", but it seems like I don't have the test inbetween
-queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.29 => 2.29.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapcraft (yakkety-proposed/universe) [2.29+16.10 => 2.29.2+16.10] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapcraft (zesty-proposed/universe) [2.29+17.04 => 2.29.2+17.04] (no packageset)
<LocutusOfBorg> debian bug: #863887 opened
<ubot5> Debian bug 863887 in src:debhelper "debhelper: not running autoreconf anymore with compat level 9" [Normal,Open] http://bugs.debian.org/863887
<Laney> thx
<Laney> I know what the bad commit is
<kyrofa> apw, snapcraft 2.29.2 is up
-queuebot:#ubuntu-release- Unapproved: fwupdate (xenial-proposed/main) [0.5-2ubuntu4 => 9-1ubuntu0.16.04.1] (core)
<LocutusOfBorg> Laney, would you mind sharing it in the bug report? :p
<Laney> NO I'm keeping it to myself. :P
<LocutusOfBorg> https://anonscm.debian.org/git/debhelper/debhelper.git/commit/?id=cb5054c507c0c76d1c47ce5f55605586e57405bf ?
<Laney> ok, ok, I posted
<LocutusOfBorg> thanks!
<kyrofa> slangasek, upstream setuptools busted all python2 and 3 projects using snapcraft. The fix is in snapcraft 2.29.2. Could you accept that into proposed for x y and z, please?
<sergiusens_> btw, this might not be as urgent anymore -> â[16:16] â<âjamespageâ>â "python-setuptools 36.0.1 has been released and now making its way into jobs"
<sergiusens_> kyrofa: ^
<kyrofa> sergiusens_, ...
<jamespage> that pretty much broke the world ;)
<kyrofa> It was awful, yeah
<slangasek> ok, so is this fixed upstream and no urgency on the SRU?
<kyrofa> And they seemingly did it with full knowledge of what they were doing
<kyrofa> slangasek, hold off for a sec, verifying
<cjwatson> https://github.com/pypa/setuptools/pull/1043 was the upstream fix
<cjwatson> I'd tend to agree that that shouldn't be separately worked around unless snapcraft independently requires six (which I don't think it does)
<cjwatson> looks not so much like "no urgency" as "reject" to me?
<sergiusens_> slangasek: yeah, let's hold off on the SRU, I just checked the diff and reverted the `import six` they had in there ... https://github.com/pypa/setuptools/pull/1043/files
<slangasek> ok
<sergiusens_> cjwatson: it doesn't... I was under the impression they wouldn't fix it (sorry, I wasn't on top of this one)
<slangasek> kyrofa, sergiusens_: are we agreed that I can reject these?
<sergiusens_> I am +1 for not doing this if not needed
<sergiusens_> slangasek: yeah, please
<sergiusens_> to be specific, please reject
-queuebot:#ubuntu-release- Unapproved: rejected snapcraft [source] (zesty-proposed) [2.29.2+17.04]
-queuebot:#ubuntu-release- Unapproved: rejected snapcraft [source] (yakkety-proposed) [2.29.2+16.10]
-queuebot:#ubuntu-release- Unapproved: rejected snapcraft [source] (xenial-proposed) [2.29.2]
<Laney> LocutusOfBorg: try 'deb https://swift.canonistack.canonical.com/v1/AUTH_e8074875467b46b7ab3c41ac60ccfbe7/ubuntu artful main'?
<kyrofa> Indeed, tests pass without the patch. sergiusens, jamespage: good catch, thank you
<LocutusOfBorg> looking
<Laney> signed with my key, you can find that in keyring.d.o
<LocutusOfBorg> Laney, [trusted=yes] for your repo :p
<LocutusOfBorg> works
<LocutusOfBorg> at least it is autoreconfiguring
<LocutusOfBorg> ta
<Laney> shocking
<LocutusOfBorg> thanks, the build is good, I will kill it
<Laney> k, guess I'll upload that revert then
<LocutusOfBorg> ta
<Laney> .
-queuebot:#ubuntu-release- New binary: ubuntu-settings [amd64] (artful-proposed/main) [17.10.2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New: rejected ubuntu-settings [amd64] (artful-proposed) [17.10.2]
-queuebot:#ubuntu-release- New binary: thunderbird [ppc64el] (artful-proposed/main) [1:52.1.1+build1-0ubuntu1] (mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.26.1 => 2.26.4] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.26.1+16.10 => 2.26.4+16.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (zesty-proposed/main) [2.26.1+17.04 => 2.26.4+17.04] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.26.1~14.04 => 2.26.4~14.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected nplan [source] (xenial-proposed) [0.22~16.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected nplan [source] (yakkety-proposed) [0.22~16.10.1]
-queuebot:#ubuntu-release- Unapproved: rejected nplan [source] (zesty-proposed) [0.22~17.04.1]
-queuebot:#ubuntu-release- New binary: thunderbird [amd64] (artful-proposed/main) [1:52.1.1+build1-0ubuntu1] (mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: thunderbird [i386] (artful-proposed/main) [1:52.1.1+build1-0ubuntu1] (mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: live-build (trusty-proposed/main) [3.0~a57-1ubuntu11.3 => 3.0~a57-1ubuntu11.4] (desktop-core)
 * cyphermox pokes queuebot
<cyphermox> where's my livecd-rootfs upload?
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (trusty-proposed/main) [2.208.13 => 2.208.14] (desktop-core)
<cyphermox> ah, there we go
-queuebot:#ubuntu-release- New binary: thunderbird [arm64] (artful-proposed/main) [1:52.1.1+build1-0ubuntu1] (mozilla, ubuntu-desktop)
#ubuntu-release 2017-06-02
-queuebot:#ubuntu-release- Unapproved: mir (yakkety-proposed/main) [0.24.0+16.10.20160815.3-0ubuntu2 => 0.26.3+16.10.20170531-0ubuntu1] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: mir (zesty-proposed/main) [0.26.2+17.04.20170322.1-0ubuntu2 => 0.26.3+17.04.20170531-0ubuntu1] (kubuntu, ubuntu-desktop) (sync)
<Saviq> seb128, hey, could you please approve these into proposed â SRU is bug #1685186
<ubot5> bug 1685186 in mir (Ubuntu Zesty) "[SRU] Mir needs to be updated to 0.26 in 16.04LTS" [High,In progress] https://launchpad.net/bugs/1685186
 * apw looks at snapd
<seb128> Saviq, hey, sorry but I'm not part of the SRU team
<Saviq> seb128, hmm, this is just about acking the upload to proposed, thought it didn't require SRU membership... thanks anyways
<seb128> Saviq, it doesn't but the SRU team members have special scripts and stuff to accept uploads that add comments to the bug etc and I'm not familiar with those
<seb128> Saviq, technically I can press the button if we really don't have someone from the SRU team around though
 * apw looks up ...
<apw> Saviq, is that fixing up the mir in xenial trying to be newer than later releases ?
<Saviq> apw, yes
<apw> now i see why noone wants to review it, it is a sync for one
<apw> Saviq, the yakkety update causes two (i think) library transitions, are you handling those ?
<Saviq> alan_g, can you comment, please â
<alan_g> apw: you mean there are newer libs? (They can live alongside.)
<apw> right it has 3-4 newer libs if i am reading the control right
<alan_g> I don't think there's a problem to handle - both can be installed
<apw> ok thanks
<alan_g> yw
<sergiusens> slangasek: hey, about bileto, this is what I get on "Create new ticket" -> "The server could not verify that you are authorized to access the URL requested. You either supplied the wrong credentials (e.g. a bad password), or your browser doesn't understand how to supply the credentials required."
<slangasek> hmm!
<slangasek> sergiusens: do you see that immediately upon clicking?
<sergiusens> slangasek: yes
<slangasek> sergiusens: ok, not reproducible for me; system doesn't appear to be completely broken
<slangasek> sergiusens: upper right hand shows you as logged in as you?
<sergiusens> slangasek: may be related to the fact this is the first time I am going to use this
<sergiusens> yes, logged in
 * sergiusens rinses and repeats
<slangasek> sergiusens: well there's your problem, you're not a member of https://launchpad.net/~bileto-users/+members ! how long's it been since you used this last? :-)
<sergiusens> slangasek: I never used it ;-)
<slangasek> hah
<sergiusens> yeah I mentioned that :-P
<slangasek> sergiusens: but you know what you're doing?  I've added you now, so shift reload or something
<slangasek> sergiusens: AIUI you're landing a branch to click, so the key field to fill out (besides the required fields) is 'Merge Proposal URLS'
<sergiusens> sounds good, I used the train before, I suppose this is almost similar expect that I will only land the MP for artful given the comments from yesterday
 * sergiusens goes to board a flight back home
<sergiusens> thanks
<slangasek> ok
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (artful-proposed) [2.02~beta3-4ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (artful-proposed) [2.02~beta3-4ubuntu5]
-queuebot:#ubuntu-release- New: accepted thunderbird [amd64] (artful-proposed) [1:52.1.1+build1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted thunderbird [i386] (artful-proposed) [1:52.1.1+build1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted thunderbird [arm64] (artful-proposed) [1:52.1.1+build1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted thunderbird [ppc64el] (artful-proposed) [1:52.1.1+build1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (artful-proposed/main) [4.11.0-5.10] (core, kernel)
-queuebot:#ubuntu-release- New binary: libaria [s390x] (artful-proposed/universe) [2.8.0+repack-1.2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (artful-proposed) [4.11.0-5.10]
-queuebot:#ubuntu-release- New binary: libaria [ppc64el] (artful-proposed/universe) [2.8.0+repack-1.2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libaria [amd64] (artful-proposed/universe) [2.8.0+repack-1.2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libaria [i386] (artful-proposed/universe) [2.8.0+repack-1.2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libaria [arm64] (artful-proposed/universe) [2.8.0+repack-1.2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libaria [armhf] (artful-proposed/universe) [2.8.0+repack-1.2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cockpit (zesty-backports/universe) [140-1~ubuntu17.04.1 => 141-2~ubuntu17.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (zesty-backports) [141-2~ubuntu17.04.1]
-queuebot:#ubuntu-release- Unapproved: cockpit (yakkety-backports/universe) [140-1~ubuntu16.10.1 => 141-2~ubuntu16.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (yakkety-backports) [141-2~ubuntu16.10.1]
-queuebot:#ubuntu-release- Unapproved: cockpit (xenial-backports/universe) [140-1~ubuntu16.04.1 => 141-2~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (xenial-backports) [141-2~ubuntu16.04.1]
-queuebot:#ubuntu-release- Unapproved: nagios-images (zesty-proposed/main) [0.9.1 => 0.9.1ubuntu0.1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: parsedatetime [amd64] (artful-proposed/main) [2.3-1] (ubuntu-server)
#ubuntu-release 2017-06-03
-queuebot:#ubuntu-release- Unapproved: libgweather (zesty-proposed/main) [3.24.0-0ubuntu2 => 3.24.0-0ubuntu2.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: postfix (zesty-proposed/main) [3.1.4-4 => 3.1.4-4ubuntu1] (core)
<ahoneybun> kirkland: any reason my blog is linked on the ubuntu iso?
<jbicha> ahoneybun: it comes from https://motd.ubuntu.com/ do you object to being featured?
<ahoneybun> just wondering why it was picked jbicha
<ahoneybun> tho if it could be updated to my new domain that would be cool
<jbicha> ahoneybun: I suggest sending an email about any concerns you have
<ahoneybun> to whom?
<jbicha> I don't know who has access to make changes to that message, but I believe Canonical's Community Team should be able to help you find out
<jbicha> you could also try opening a RT ticket https://rt.ubuntu.com/
<ahoneybun> eww
-queuebot:#ubuntu-release- Unapproved: postfix (yakkety-proposed/main) [3.1.0-5 => 3.1.0-5ubuntu1] (core)
<slangasek> ahoneybun: which is the new domain that should be used?  MPs possible at lp:ubuntu-motd/
<ahoneybun> ahhh did not know that
<slangasek> ah, but everything is link shortened to ubu.one, so I guess if you want that redirector to point to a different domain, you need kirkland
<ahoneybun> yea lol
<slangasek> does seem it would be sporting to let community members know what's going on before they get their blogs linked there :-)
<ahoneybun> not even sure why I was picked tbh
-queuebot:#ubuntu-release- New: accepted libaria [amd64] (artful-proposed) [2.8.0+repack-1.2ubuntu1]
-queuebot:#ubuntu-release- New: accepted libaria [armhf] (artful-proposed) [2.8.0+repack-1.2ubuntu1]
-queuebot:#ubuntu-release- New: accepted libaria [ppc64el] (artful-proposed) [2.8.0+repack-1.2ubuntu1]
-queuebot:#ubuntu-release- New: accepted libaria [arm64] (artful-proposed) [2.8.0+repack-1.2ubuntu1]
-queuebot:#ubuntu-release- New: accepted libaria [s390x] (artful-proposed) [2.8.0+repack-1.2ubuntu1]
-queuebot:#ubuntu-release- New: accepted libaria [i386] (artful-proposed) [2.8.0+repack-1.2ubuntu1]
#ubuntu-release 2017-06-04
-queuebot:#ubuntu-release- New: accepted parsedatetime [amd64] (artful-proposed) [2.3-1]
#ubuntu-release 2018-05-28
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525 => 2.525.1] (desktop-core)
<ginggs> slangasek: thanks, I'll look today
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.13.0-44.49~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.13.0-44.49~16.04.1]
<sil2100> hmmm
<sil2100> sforshee: hey, I'm looking at your wireless-regdb upload and I'm a bit worried about the fact of no longer building the bits from source anymore
<sil2100> I might need someone more experienced to take a look at this SRU
<cpaelzer> sil2100: did you have success re-enabling tests on bileto for >=Bionic?
<tjaalton> sil2100: mind having a look at tomcat8 again?
<cpaelzer> bdmurray: I started with britney hints MPs to you as your file was the one with old related entries
<cpaelzer> bdmurray: in the meantime more changes piled up and are grouped, but I kept you to have all changes related to the same context discussed with just one person
<ginggs> infinity: can we get debhelper 11.3 merged please?  it's needed by the new dh-r and there's a big R transition coming
<sil2100> tjaalton: sure, I guess I had some questions last week with that but forgot to actually ask them
<sil2100> Anyway, on it in a moment
<sil2100> cpaelzer: I actually tested that on Friday and I can fix it now
<ginggs> slangasek: I think have a workaround for numpy, are you around?
<sil2100> cpaelzer: ok, I think it might be working in some minutes
<sil2100> cpaelzer: anyway, in case there's some problem with Bileto you notice, ping me here or by e-mail
<sil2100> I only do bare maintenance of it but yeah
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-128.154]
<cpaelzer> sil2100: thanks to know who to ping from now on
<cpaelzer> sil2100: is this enough commitment that I can mention to all of my team that a) it should work again and b) you are the person to ping about it?
<sil2100> b) yes, a) well... it *should* work, this needs someone to verify it properly ;p
<cpaelzer> good enough
<cpaelzer> thanks sil2100
-queuebot:#ubuntu-release- Unapproved: update-manager (bionic-proposed/main) [1:18.04.11 => 1:18.04.11.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted wireless-regdb [source] (bionic-proposed) [2018.05.09-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted wireless-regdb [source] (xenial-proposed) [2018.05.09-0ubuntu1~16.04.1]
<sil2100> cpaelzer: in case you'll verify Bileto working/still-not-working, give me a sign
<cpaelzer> sil2100: I had no current case in flight to test
<cpaelzer> and would have done so when I have one
<cpaelzer> I'll test Cosmic likely tomorrow I'd think
<sil2100> Thanks
-queuebot:#ubuntu-release- Unapproved: newt (bionic-proposed/main) [0.52.20-1ubuntu1 => 0.52.20-4ubuntu1] (core)
<juliank> sil2100: ^ needs a reject
<juliank> was for cosmic
<juliank> that's what I get for uploading a merge I started preparing before we had a name/archive...
<sil2100> juliank: done
-queuebot:#ubuntu-release- Unapproved: rejected newt [source] (bionic-proposed) [0.52.20-4ubuntu1]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [ppc64el] (xenial-proposed/main) [4.15.0-23.25~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [amd64] (xenial-proposed/main) [4.15.0-23.25~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-128.154~14.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: pg-checksums [ppc64el] (cosmic-proposed/none) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php-respect-validation [amd64] (cosmic-proposed/none) [1.1.15-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-checksums [s390x] (cosmic-proposed/none) [0.2-1] (no packageset)
<juliank> sil2100: thanks
-queuebot:#ubuntu-release- New binary: pg-checksums [arm64] (cosmic-proposed/none) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-checksums [armhf] (cosmic-proposed/none) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-checksums [amd64] (cosmic-proposed/none) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php-illuminate-contracts [amd64] (cosmic-proposed/none) [5.6.22-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php-robmorgan-phinx [amd64] (cosmic-proposed/none) [0.9.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-geometry2 [s390x] (cosmic-proposed/universe) [0.6.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: php-illuminate-container [amd64] (cosmic-proposed/none) [5.6.22-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-geometry2 [ppc64el] (cosmic-proposed/universe) [0.6.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: php-illuminate-support [amd64] (cosmic-proposed/none) [5.6.22-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php-raintpl [amd64] (cosmic-proposed/none) [3.1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-std-msgs [amd64] (cosmic-proposed/universe) [0.5.11-3] (no packageset)
-queuebot:#ubuntu-release- New binary: php-react-child-process [amd64] (cosmic-proposed/none) [0.5.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-checksums [i386] (cosmic-proposed/none) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php-illuminate-database [amd64] (cosmic-proposed/none) [5.6.22-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libseqlib [amd64] (cosmic-proposed/universe) [1.1.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: smart-mode-line [amd64] (cosmic-proposed/none) [2.11.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cl-asdf-flv [amd64] (cosmic-proposed/none) [2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-geometry2 [arm64] (cosmic-proposed/universe) [0.6.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-catkin [amd64] (cosmic-proposed/universe) [0.7.12-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-geometry2 [armhf] (cosmic-proposed/universe) [0.6.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: php-react-http [amd64] (cosmic-proposed/none) [0.8.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-geometry2 [amd64] (cosmic-proposed/universe) [0.6.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-geometry2 [i386] (cosmic-proposed/universe) [0.6.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-xarray [amd64] (cosmic-proposed/universe) [0.10.4-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-128.154~14.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [ppc64el] (xenial-proposed) [4.15.0-23.25~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [amd64] (xenial-proposed) [4.15.0-23.25~16.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected maas [source] (bionic-proposed) [2.4.0-6981-g011e51b7a-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted tomcat8 [source] (bionic-proposed) [8.5.30-1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: rejected budgie-extras [source] (bionic-proposed) [0.4.4-0ubuntu1.1]
<sil2100> fossfreedom: hey! Could you add the SRU template information to bug LP: #1755831 ?
<ubot5> Launchpad bug 1755831 in budgie-desktop-environment (Ubuntu Bionic) "ibus not working properly" [Wishlist,Triaged] https://launchpad.net/bugs/1755831
-queuebot:#ubuntu-release- Unapproved: accepted im-config [source] (bionic-proposed) [0.34-1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-calendar [source] (bionic-proposed) [3.28.2-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted heat [source] (bionic-proposed) [1:10.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (bionic-proposed) [2:12.0.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (bionic-proposed) [2:17.0.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted bolt [source] (bionic-proposed) [0.3-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.525.1]
-queuebot:#ubuntu-release- Unapproved: rejected gnutls28 [source] (trusty-proposed) [3.2.11-2ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted gnutls28 [source] (trusty-proposed) [3.2.11-2ubuntu1.2]
<Odd_Bloke> If anyone feels like sponsoring an upload, I think http://paste.ubuntu.com/p/68jfk2GCvV/ will allow python-flask to migrate.
<Odd_Bloke> (Should also help with matplotlib.)
<ginggs> Odd_Bloke: why not send a patch to Debian?
<Odd_Bloke> ginggs: Fair point.
<Odd_Bloke> ginggs: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900310 :)
<ubot5> Debian bug 900310 in src:python-ase "python-ase test suite fails with latest python-flask" [Normal,Open]
-queuebot:#ubuntu-release- New: accepted cl-asdf-flv [amd64] (cosmic-proposed) [2.1-1]
-queuebot:#ubuntu-release- New: accepted pg-checksums [amd64] (cosmic-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted pg-checksums [armhf] (cosmic-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted pg-checksums [ppc64el] (cosmic-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted libseqlib [amd64] (cosmic-proposed) [1.1.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted pg-checksums [i386] (cosmic-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted pg-checksums [arm64] (cosmic-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted pg-checksums [s390x] (cosmic-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted php-illuminate-container [amd64] (cosmic-proposed) [5.6.22-1]
-queuebot:#ubuntu-release- New: accepted php-illuminate-database [amd64] (cosmic-proposed) [5.6.22-1]
-queuebot:#ubuntu-release- New: accepted php-raintpl [amd64] (cosmic-proposed) [3.1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted php-react-http [amd64] (cosmic-proposed) [0.8.3-2]
-queuebot:#ubuntu-release- New: accepted php-robmorgan-phinx [amd64] (cosmic-proposed) [0.9.2-1]
-queuebot:#ubuntu-release- New: accepted ros-catkin [amd64] (cosmic-proposed) [0.7.12-2]
-queuebot:#ubuntu-release- New: accepted ros-geometry2 [arm64] (cosmic-proposed) [0.6.2-2]
-queuebot:#ubuntu-release- New: accepted ros-geometry2 [i386] (cosmic-proposed) [0.6.2-2]
-queuebot:#ubuntu-release- New: accepted ros-geometry2 [s390x] (cosmic-proposed) [0.6.2-2]
-queuebot:#ubuntu-release- New: accepted php-illuminate-contracts [amd64] (cosmic-proposed) [5.6.22-1]
-queuebot:#ubuntu-release- New: accepted php-react-child-process [amd64] (cosmic-proposed) [0.5.2-1]
-queuebot:#ubuntu-release- New: accepted python-xarray [amd64] (cosmic-proposed) [0.10.4-1]
-queuebot:#ubuntu-release- New: accepted ros-geometry2 [armhf] (cosmic-proposed) [0.6.2-2]
-queuebot:#ubuntu-release- New: accepted ros-std-msgs [amd64] (cosmic-proposed) [0.5.11-3]
-queuebot:#ubuntu-release- New: accepted php-illuminate-support [amd64] (cosmic-proposed) [5.6.22-1]
-queuebot:#ubuntu-release- New: accepted ros-geometry2 [amd64] (cosmic-proposed) [0.6.2-2]
-queuebot:#ubuntu-release- New: accepted php-respect-validation [amd64] (cosmic-proposed) [1.1.15-1]
-queuebot:#ubuntu-release- New: accepted ros-geometry2 [ppc64el] (cosmic-proposed) [0.6.2-2]
-queuebot:#ubuntu-release- New: accepted smart-mode-line [amd64] (cosmic-proposed) [2.11.0-1]
-queuebot:#ubuntu-release- New binary: flask-cache [amd64] (cosmic-proposed/none) [0.13.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbrola-ar2 [amd64] (cosmic-proposed/none) [0.0.20001015-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbrola-de8 [amd64] (cosmic-proposed/none) [0.0.20040811-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbrola-ar1 [amd64] (cosmic-proposed/none) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbrola-es3 [amd64] (cosmic-proposed/none) [0.0.20141124-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbrola-ca2 [amd64] (cosmic-proposed/none) [0.0.20031022-1] (no packageset)
<ginggs> Odd_Bloke: ta! I'll upload that now
-queuebot:#ubuntu-release- New binary: autodeb [amd64] (cosmic-proposed/none) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbrola-bz1 [amd64] (cosmic-proposed/none) [0.99-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbrola-fr2 [amd64] (cosmic-proposed/none) [2.060-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbrola-fr7 [amd64] (cosmic-proposed/none) [2.00b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbrola-hb2 [amd64] (cosmic-proposed/none) [0.0.20040902-1] (no packageset)
-queuebot:#ubuntu-release- New binary: evenement [amd64] (cosmic-proposed/none) [3.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mbrola-fr5 [amd64] (cosmic-proposed/none) [2.060-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbrola-cn1 [amd64] (cosmic-proposed/none) [0.0.201111-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbrola-hb1 [amd64] (cosmic-proposed/none) [0.0.20000308-1] (no packageset)
-queuebot:#ubuntu-release- New binary: autodeb [ppc64el] (cosmic-proposed/none) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbrola-cz1 [amd64] (cosmic-proposed/none) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbrola-fr3 [amd64] (cosmic-proposed/none) [2.060-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbrola-hn1 [amd64] (cosmic-proposed/none) [4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: reactphp-dns [amd64] (cosmic-proposed/none) [0.4.13-2] (no packageset)
-queuebot:#ubuntu-release- New binary: reactphp-socket [amd64] (cosmic-proposed/none) [0.8.11-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mbrola-ca1 [amd64] (cosmic-proposed/none) [1.00-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbrola-fr6 [amd64] (cosmic-proposed/none) [0.0.20010330-1] (no packageset)
-queuebot:#ubuntu-release- New binary: reactphp-promise-stream [amd64] (cosmic-proposed/none) [1.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mbrola-es4 [amd64] (cosmic-proposed/none) [0.0.20020903-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wig [amd64] (cosmic-proposed/none) [0.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbrola-in1 [amd64] (cosmic-proposed/none) [0.0.20010206-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbrola-in2 [amd64] (cosmic-proposed/none) [0.0.20010202-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbrola-jp2 [amd64] (cosmic-proposed/none) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbrola-nl3 [amd64] (cosmic-proposed/none) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ratchet-rfc6455 [amd64] (cosmic-proposed/none) [0.2.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: tup [ppc64el] (cosmic-proposed/none) [0.7.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbrola-it2 [amd64] (cosmic-proposed/none) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbrola-tl1 [amd64] (cosmic-proposed/none) [0.0.20010627-1] (no packageset)
-queuebot:#ubuntu-release- New binary: turing [amd64] (cosmic-proposed/none) [0.10~beta-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbrola-ma1 [amd64] (cosmic-proposed/none) [0.0.20040816-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ratchetphp [amd64] (cosmic-proposed/none) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: autodeb [i386] (cosmic-proposed/none) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbrola-jp1 [amd64] (cosmic-proposed/none) [0.0.20000314-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbrola-nz1 [amd64] (cosmic-proposed/none) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbrola-it1 [amd64] (cosmic-proposed/none) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbrola-jp3 [amd64] (cosmic-proposed/none) [0.0.20021022-1] (no packageset)
-queuebot:#ubuntu-release- New binary: autodeb [s390x] (cosmic-proposed/none) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tup [amd64] (cosmic-proposed/none) [0.7.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mbrola-nl1 [amd64] (cosmic-proposed/none) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tup [i386] (cosmic-proposed/none) [0.7.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: autodeb [arm64] (cosmic-proposed/none) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: autodeb [armhf] (cosmic-proposed/none) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tup [arm64] (cosmic-proposed/universe) [0.7.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tup [armhf] (cosmic-proposed/universe) [0.7.6-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gnome-split (bionic-proposed/universe) [1.2-2 => 1.2-2build0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: mlpack [s390x] (cosmic-proposed/universe) [3.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mlpack [ppc64el] (cosmic-proposed/universe) [3.0.1-2] (no packageset)
<slangasek> ginggs: 6am on a bank holiday: nope ;-)  what's the workaround?
<ginggs> slangasek: replace '*((@type@ *)ov)=temp;' with 'memcpy(ov, &temp, sizeof(@type@));'
<ginggs> slangasek: but i sent that upstream https://github.com/numpy/numpy/issues/11088 and found the actual cause
<ubot5-ng> numpy bug 11088 in numpy "1.14.3 on sparc64: numpy.core.tests.test_multiarray.TestMethods.test__complex__should_not_work ... Bus error" (comments: 27) [05 - Regression, Open]
<ubot5> bug 11088 in Ubuntu "scm: new changes from Debian require merging" [Wishlist,Invalid] https://launchpad.net/bugs/11088
<ginggs> s/found/they found/
<slangasek> oh excellent
<slangasek> then I won't waste my time fighting with a bisect
-queuebot:#ubuntu-release- New binary: mlpack [i386] (cosmic-proposed/universe) [3.0.1-2] (no packageset)
#ubuntu-release 2018-05-29
-queuebot:#ubuntu-release- New binary: mlpack [amd64] (cosmic-proposed/universe) [3.0.1-2] (no packageset)
<ginggs> slangasek: I'm going to upload numpy to ubuntu now with upstream's patch, hopefully it unblocks some things
-queuebot:#ubuntu-release- New binary: mlpack [arm64] (cosmic-proposed/universe) [3.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mlpack [armhf] (cosmic-proposed/universe) [3.0.1-2] (no packageset)
<handsome_feng> slangasek: Hi, could you help merge lp:~ubuntukylin-members/+junk/update-seeds to lp:~ubuntu-archive/+junk/scripts? Thanks!
<tsimonq2> slangasek: Bump on moving that to an actual branch so flavors don't have to bother more when they convert their seeds. :P
<slangasek> handsome_feng: done, thanks.  Please also see my review on the cdimage MP
<slangasek> tsimonq2: unfortunately moving it to an actual branch means creating an actual LP project, and that resembles actual work, so I haven't done it yet
<handsome_feng> slangasek: OK, :)
<tsimonq2> slangasek: That resembles actual work? Ooh, sounds fun.
<tsimonq2> slangasek: I can JFDI and then pass off to you, so the resemblance to actual work is gone. :P
<slangasek> then you will own the project that owns the branch, which doesn't help
<tsimonq2> Ah. I can't pass that off?
<slangasek> you can, but finding and fixing all the acls in the LP UI to be confident it's correctly transferred is, for me, as much work as setting it up in the first place :)
<tsimonq2> Darn.
<tsimonq2> slangasek: The Staging Launchpad instance disagrees.
-queuebot:#ubuntu-release- New: accepted autodeb [amd64] (cosmic-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted autodeb [armhf] (cosmic-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted autodeb [ppc64el] (cosmic-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted evenement [amd64] (cosmic-proposed) [3.0.1-2]
-queuebot:#ubuntu-release- New: accepted mbrola-ar1 [amd64] (cosmic-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted mbrola-bz1 [amd64] (cosmic-proposed) [0.99-1]
-queuebot:#ubuntu-release- New: accepted mbrola-ca2 [amd64] (cosmic-proposed) [0.0.20031022-1]
-queuebot:#ubuntu-release- New: accepted mbrola-cz1 [amd64] (cosmic-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted autodeb [arm64] (cosmic-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted autodeb [s390x] (cosmic-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted mbrola-ar2 [amd64] (cosmic-proposed) [0.0.20001015-1]
-queuebot:#ubuntu-release- New: accepted mbrola-cn1 [amd64] (cosmic-proposed) [0.0.201111-1]
-queuebot:#ubuntu-release- New: accepted autodeb [i386] (cosmic-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted mbrola-ca1 [amd64] (cosmic-proposed) [1.00-1]
-queuebot:#ubuntu-release- New: accepted flask-cache [amd64] (cosmic-proposed) [0.13.1-1]
-queuebot:#ubuntu-release- New: accepted mbrola-de8 [amd64] (cosmic-proposed) [0.0.20040811-1]
-queuebot:#ubuntu-release- New: accepted mbrola-es3 [amd64] (cosmic-proposed) [0.0.20141124-1]
-queuebot:#ubuntu-release- New: accepted mbrola-fr2 [amd64] (cosmic-proposed) [2.060-1]
-queuebot:#ubuntu-release- New: accepted mbrola-fr5 [amd64] (cosmic-proposed) [2.060-1]
-queuebot:#ubuntu-release- New: accepted mbrola-fr7 [amd64] (cosmic-proposed) [2.00b-1]
-queuebot:#ubuntu-release- New: accepted mbrola-hb2 [amd64] (cosmic-proposed) [0.0.20040902-1]
-queuebot:#ubuntu-release- New: accepted mbrola-in1 [amd64] (cosmic-proposed) [0.0.20010206-1]
-queuebot:#ubuntu-release- New: accepted mbrola-it1 [amd64] (cosmic-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted mbrola-jp1 [amd64] (cosmic-proposed) [0.0.20000314-1]
-queuebot:#ubuntu-release- New: accepted mbrola-jp3 [amd64] (cosmic-proposed) [0.0.20021022-1]
-queuebot:#ubuntu-release- New: accepted mbrola-es4 [amd64] (cosmic-proposed) [0.0.20020903-1]
-queuebot:#ubuntu-release- New: accepted mbrola-fr6 [amd64] (cosmic-proposed) [0.0.20010330-1]
-queuebot:#ubuntu-release- New: accepted mbrola-hn1 [amd64] (cosmic-proposed) [4-1]
-queuebot:#ubuntu-release- New: accepted mbrola-it2 [amd64] (cosmic-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted mbrola-ma1 [amd64] (cosmic-proposed) [0.0.20040816-1]
-queuebot:#ubuntu-release- New: accepted mbrola-fr3 [amd64] (cosmic-proposed) [2.060-1]
-queuebot:#ubuntu-release- New: accepted mbrola-in2 [amd64] (cosmic-proposed) [0.0.20010202-1]
-queuebot:#ubuntu-release- New: accepted mbrola-hb1 [amd64] (cosmic-proposed) [0.0.20000308-1]
-queuebot:#ubuntu-release- New: accepted mbrola-jp2 [amd64] (cosmic-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted mbrola-nl1 [amd64] (cosmic-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted mbrola-nz1 [amd64] (cosmic-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted mlpack [amd64] (cosmic-proposed) [3.0.1-2]
-queuebot:#ubuntu-release- New: accepted mlpack [armhf] (cosmic-proposed) [3.0.1-2]
-queuebot:#ubuntu-release- New: accepted mlpack [ppc64el] (cosmic-proposed) [3.0.1-2]
-queuebot:#ubuntu-release- New: accepted ratchet-rfc6455 [amd64] (cosmic-proposed) [0.2.4-2]
-queuebot:#ubuntu-release- New: accepted reactphp-dns [amd64] (cosmic-proposed) [0.4.13-2]
-queuebot:#ubuntu-release- New: accepted mbrola-nl3 [amd64] (cosmic-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted mlpack [arm64] (cosmic-proposed) [3.0.1-2]
-queuebot:#ubuntu-release- New: accepted mlpack [s390x] (cosmic-proposed) [3.0.1-2]
-queuebot:#ubuntu-release- New: accepted mbrola-tl1 [amd64] (cosmic-proposed) [0.0.20010627-1]
-queuebot:#ubuntu-release- New: accepted ratchetphp [amd64] (cosmic-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted mlpack [i386] (cosmic-proposed) [3.0.1-2]
-queuebot:#ubuntu-release- New: accepted reactphp-promise-stream [amd64] (cosmic-proposed) [1.1.1-2]
-queuebot:#ubuntu-release- New: accepted turing [amd64] (cosmic-proposed) [0.10~beta-1]
-queuebot:#ubuntu-release- New: accepted reactphp-socket [amd64] (cosmic-proposed) [0.8.11-2]
-queuebot:#ubuntu-release- New: accepted wig [amd64] (cosmic-proposed) [0.6-1]
<tsimonq2> slangasek: https://launchpad.net/ubuntu-archive-scripts <-- I literally can't touch anything.
<tsimonq2> ACLs seem pretty sound to me.
-queuebot:#ubuntu-release- New binary: procps [amd64] (cosmic-proposed/main) [2:3.3.15-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: procps [ppc64el] (cosmic-proposed/main) [2:3.3.15-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: procps [i386] (cosmic-proposed/main) [2:3.3.15-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: procps [arm64] (cosmic-proposed/main) [2:3.3.15-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: procps [armhf] (cosmic-proposed/main) [2:3.3.15-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: procps [s390x] (cosmic-proposed/main) [2:3.3.15-1ubuntu1] (core)
<acheronuk> ginggs: thanks for python-numpy. appears to just reveal the next layer of brokenness, but progress is progress
<ginggs> acheronuk: np
<rbalint> ^3 i've prepared the rebuilds for the procps transition, please let it in when feasible
<apw> rbalint, that isn't going to entwine with perl is it ?
<rbalint> apw, please don't accept it yet
<rbalint> apw, please reject it instead, it needs an other fix
<rbalint> apw, i asked doko the other day, he did not object, but it can also wait
<apw> rbalint, if do-ko is happy i am happy; to confirm you want the procps binaries rejected ?
<rbalint> apw, yes, please reject them, the -dev pkg is broken (like in Debian), i'd like to fix that
-queuebot:#ubuntu-release- New: rejected procps [amd64] (cosmic-proposed) [2:3.3.15-1ubuntu1]
-queuebot:#ubuntu-release- New: rejected procps [armhf] (cosmic-proposed) [2:3.3.15-1ubuntu1]
-queuebot:#ubuntu-release- New: rejected procps [ppc64el] (cosmic-proposed) [2:3.3.15-1ubuntu1]
-queuebot:#ubuntu-release- New: rejected procps [arm64] (cosmic-proposed) [2:3.3.15-1ubuntu1]
-queuebot:#ubuntu-release- New: rejected procps [s390x] (cosmic-proposed) [2:3.3.15-1ubuntu1]
-queuebot:#ubuntu-release- New: rejected procps [i386] (cosmic-proposed) [2:3.3.15-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted tup [amd64] (cosmic-proposed) [0.7.6-1]
-queuebot:#ubuntu-release- New: accepted tup [armhf] (cosmic-proposed) [0.7.6-1]
-queuebot:#ubuntu-release- New: accepted tup [ppc64el] (cosmic-proposed) [0.7.6-1]
-queuebot:#ubuntu-release- New: accepted tup [arm64] (cosmic-proposed) [0.7.6-1]
-queuebot:#ubuntu-release- New: accepted tup [i386] (cosmic-proposed) [0.7.6-1]
<cpaelzer> sil2100: cosmic tests on bileto work for me today, thanks ++
<cpaelzer> sil2100: I'll let you know once I stumble over something.
<doko> apw: doesn't make sense if nobody is working on that transition
<apw> doko, i am reading that as "to wait on perl if noone is working on that transition@
<ginggs> would an archive admin please remove the old NBS binaries from wine1.6? LP: #1769649
<ubot5> Launchpad bug 1769649 in wine1.6 (Ubuntu) "wine1.6: migrate from wine-stable -> wine" [Undecided,Triaged] https://launchpad.net/bugs/1769649
<apw> ginggs, if they are NBS and unreferenced they would appear on my nbs report for removal and they do not
<apw> ginggs, or are you talking about in -proposed
<ginggs> apw: yes, in -proposed
<ginggs> sorry
<apw> ginggs, ok you are removing these packages and not replacing them ... right?  and they have a reverse-depends so i cannot remove them
<apw> ginggs, q4wine
<apw> ginggs, ahh ok that is a | reverse-recommends
<apw> ginggs, zapped
<ginggs> apw: ta!
<LocutusOfBorg> ginggs, nice work on numpy!
<LocutusOfBorg> lets move gdal a little further
<ginggs> LocutusOfBorg: :)
-queuebot:#ubuntu-release- Unapproved: gdm3 (bionic-proposed/main) [3.28.0-0ubuntu1.1 => 3.28.2-0ubuntu1.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gdm3 (bionic-proposed/main) [3.28.0-0ubuntu1.1 => 3.28.2-0ubuntu1.1] (ubuntu-desktop)
<Laney> That second one has proper LP-Bugs-Fixed.
<Laney> And it's supposed to fix a v-failed previous attempt, so if someone has a minute to take a look we might get some happy users
<sil2100> Laney: ok, rejecting the first one then
<sil2100> And I'll look at it now
<Laney> ð
 * Laney needs to eat eat eat
-queuebot:#ubuntu-release- Unapproved: rejected gdm3 [source] (bionic-proposed) [3.28.2-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (bionic-proposed/main) [1:18.04.18 => 1:18.04.19] (core)
<Odd_Bloke> ginggs: Oh, _now_ I see why you were interested in the Debian patch for python-ase. ;)
<ginggs> Odd_Bloke: :)
<LocutusOfBorg> apw, old binaries left on amd64: libpdal-plugin-numpy (from 1.7.2-1)
<LocutusOfBorg> is this something feasible please? :)
<LocutusOfBorg> NBS proposed cleanup or something like that?
<LocutusOfBorg> same for qgis probably
<apw> LocutusOfBorg, will have a look in a sec
<LocutusOfBorg> thanks!
<LocutusOfBorg> no hurries :)
<apw> LocutusOfBorg, stroked
<LocutusOfBorg> both? awesome!
<apw> yep
-queuebot:#ubuntu-release- Unapproved: skytools3 (xenial-proposed/universe) [3.2.6-4 => 3.2.6-4ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: skytools3 (artful-proposed/universe) [3.2.6-5 => 3.2.6-5ubuntu0.1] (no packageset)
<sil2100> Laney: any reason the version number is 0ubuntu1.1 instead of 0ubuntu0.1 ? I know the cosmic one was 1ubuntu1, but it feels a bit strange
<Laney> sil2100: Mainly because it has to be 0 if it needs to be less than ubuntu1, and this isn't the case here so 1... is fine
<Laney> I can change it if you want though
<Laney> The policy seems to leave it up to the uploader, but if it is in fact firmer than this then it'd be good to update it
<sil2100> It's good, just strange
<sil2100> Approving with a small shrug
<sil2100> ;)
<Laney> :P
-queuebot:#ubuntu-release- Unapproved: accepted gdm3 [source] (bionic-proposed) [3.28.2-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted python-pip [source] (bionic-proposed) [9.0.1-2.3~ubuntu1]
<juliank> Laney: linux on arm64 fails with No space, but the other archs are ignored failure; what can we do about that?
<juliank> And chrony fails with fatal: unable to access 'https://github.com/mlichvar/clknetsim/': Failed to connect to github.com port 443: Connection timed out on s390x, but works everywhere else
<juliank> (it's git clone-ing a repo)
<Laney> does it really run out of space or is it a problem on the host?
<Laney> run chrony interactively, see what's up, sounds like a cloud problem too
<Laney> assuing you retried it already
<Laney> is that bos01 or bos02 or both?
<juliank> oh yeah, that makes sense
<juliank> The chrony failure is on both bos01 and bos02
<Laney> https_proxy should be set I think
<juliank> we do pass -e ''"'"'https_proxy=http://squid.internal:3128'"'"''
<Laney> if not that's a problem, or maybe it's not being respected for some reason
<Laney> right, it should be in /etc/environment
<Odd_Bloke> ginggs: I just happened to check PyPI around 7 minutes after that release happened. :p
<ginggs> Odd_Bloke: and just in time, too.  it is schedulded for autoremoval from Debian tomorrow
<juliank> Laney: manual retry worked...
<juliank> of chrony/s390x
<juliank> I'm confused
<juliank> though it might be different security groups, since we probably did not create the one we ran it in
 * juliank will do more digging tomorrow
 * tsimonq2 puts on a Kubuntu hat. 
<tsimonq2> rbasak, slangasek: Do we have a policy for new source packages in a stable release? Of course, I would consider it a prerequisite for it to be in the development release first (and thus passing AA checks)...
<acheronuk> tsimonq2: https://wiki.ubuntu.com/StableReleaseUpdates
<rbasak> tsimonq2: https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases "For Long Term Support releases we sometimes want to introduce new features" maybe?
<acheronuk> "For Long Term Support releases we sometimes want to introduce new features. They must not change the behaviour on existing installations (e. g. entirely new packages are usually fine)."
<acheronuk> snap!
<tsimonq2> But this would be seeded.
<Laney> juliank: It's probably something to do with cloud-init - check /var/log/cloud-init*
<Laney> the environment is shipped in via user-data
<tsimonq2> rbasak: Thus changing, or perhaps "adding to", the default behavior.
<rbasak> Seeded for what purpose? To include in a point release installer image?
<tsimonq2> rbasak: For LTS -> LTS purposes.
<tsimonq2> https://cgit.kde.org/distro-release-notifier.git/ is what we're looking at.
<rbasak> What does it do?
<tsimonq2> acheronuk can probably answer that much better than I can, but the short of it is, a Plasma-integrated LTS -> LTS upgrade notification.
<acheronuk> rbasak: https://i.imgur.com/CrwE6bR.png
<acheronuk> notifier for that
<rbasak> It's fairly common for SRUs to happen for upgrade purposes.
<acheronuk> we had that function in our software centre, but KDE ripped the code out :/
<rbasak> Less common for a new package to be installed by default in a point release I think, excepting HWE.
<rbasak> Maybe ask ubuntu-release@
<tsimonq2> Sure.
<rbasak> It doesn't seem unreasonable to me, but it does seem odd that people would have a different LTS upgrade experience depending on whether they installed from an 18.04 image or an 18.04.1 image.
<rbasak> You'd have to support both paths which seems like extra effort.
<tsimonq2> A kubuntu-meta upload would follow, pulling that in.
<rbasak> That would be better I think but would bring in some extra QA requirements as it would carry more regression risk.
<rbasak> IMHO it all seems reasonable. I'm not sure if it's within the ~ubuntu-sru remit to make a decision though.
<acheronuk> if it's done that way, it's not crucial to go in for 18.04.1. just some time before upgrades from 18.04 -> new release are turned on
<rbasak> Yep
<acheronuk> so we have time to explore the idea
<tsimonq2> Right, I was also going to ask which team can make this decision.
<rbasak> I propose that ~ubuntu-sru make the decision under "For Long Term Support releases we sometimes want to introduce new features" but give others the opportunity to nack that on the ML.
<teward> can someone check and see why both perl and nginx have not yet released from proposed?  update_excuses shows them both listed as "valid candidate"
<tsimonq2> rbasak: Sounds good.
<tsimonq2> Thanks.
<rbasak> It's probably easiest to just propose it and take it to the TB if anyone objects.
<tsimonq2> Right.
<rbasak> (I mean from the team decision perspective)
<cjwatson> teward: both entangled in a non-trivial transition in progress
<teward> ah
<cjwatson> you can search for "trying: perl" in https://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt to see details
<teward> cjwatson: not sure how to interpret that.  it's a little bit annoying that the system is nagging me about nginx though every few days.  At one point it nagged me daily :/
<cjwatson> https://wiki.ubuntu.com/ProposedMigration
<cjwatson> yes that will happen for big transitions.  hopefully the result is that one of the multiple people who get nagged will do something about it :)
<teward> true, but it makes no sense to nag when it says it's a valid candidate and isn't failing any of the autopkgtests (or the ones where it did fail are being ignored)
<acheronuk> there is still a reason though, and it may be due to a transition you are part of, and/or is fixable by you
<teward> *shrugs*
<teward> cjwatson: is that the Perl transition, or some other transition?  (I'm assuming Perl)
<Laney> juliank: I think the '"'"'"'"'"' stuff is being quoted wrongly now but I'm not sure what changed
<Laney> juliank: if you look at /etc/environment it's wrong, then check env -i curl http://169.254.169.254/openstack/latest/user_data and you can see the printf bit is messed up
<Laney> not sure why this works sometimes, or what changed
<Laney> hmm no, that's not true, I changed the quoting and it still broke
<Laney> ls -l /etc/environment
<Laney> -rw-r--r-- 1 root root 96 Apr 26 05:09 /etc/environment
<Laney> so it got reset by "something"?
-queuebot:#ubuntu-release- New binary: libheif [ppc64el] (cosmic-proposed/universe) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libheif [s390x] (cosmic-proposed/universe) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libheif [amd64] (cosmic-proposed/universe) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libheif [armhf] (cosmic-proposed/universe) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libheif [arm64] (cosmic-proposed/universe) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libheif [i386] (cosmic-proposed/universe) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libzypp [ppc64el] (cosmic-proposed/none) [17.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libzypp [s390x] (cosmic-proposed/none) [17.3.1-1] (no packageset)
<Laney> juliank: got to go, still not sure, but probably something cloud-initish
-queuebot:#ubuntu-release- New binary: libzypp [i386] (cosmic-proposed/none) [17.3.1-1] (no packageset)
<cjwatson> teward: I would have thought that a transition involving perl might reasonably be referred to as the Perl transition, but what do I know
-queuebot:#ubuntu-release- New binary: libzypp [armhf] (cosmic-proposed/none) [17.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libzypp [arm64] (cosmic-proposed/none) [17.3.1-1] (no packageset)
<Laney> juliank: (try some bionic runs maybe, and see if any of them get the messed up /etc/environment; seems limited to cosmic AFAICS but I didn't test very extensively)
-queuebot:#ubuntu-release- New binary: libzypp [amd64] (cosmic-proposed/none) [17.3.1-1] (no packageset)
<slangasek> ginggs: so which of these terrible autopkgtest timeouts with python-numpy are reproducible without the inclusion of that latest upstream patch? :/
-queuebot:#ubuntu-release- Unapproved: pollinate (bionic-proposed/main) [4.31-0ubuntu1 => 4.33-0ubuntu1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (xenial-proposed/universe) [4.13.0-1029.32] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (xenial-proposed) [4.13.0-1029.32]
<Odd_Bloke> ginggs: Not sure if you're taking lead on python-numpy, but https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=899019 has a patch that should fix the getfem++ autopkgtest failures.
<ubot5> Debian bug 899019 in src:getfem++ "getfem++ FTBFS: FAIL demo_laplacian.py" [Serious,Open]
<tsimonq2> sil2100: Hey :)
<tsimonq2> sil2100: bug 1774067 has another VLC point release.
<ubot5> bug 1774067 in vlc (Ubuntu Bionic) "[SRU] Update to bugfix release 3.0.3 in Bionic" [Medium,Confirmed] https://launchpad.net/bugs/1774067
<tsimonq2> sil2100: I know you took care of the initial work for the last one; it'd be good to get your eyes on this one too.
<slangasek> infinity, cjwatson: fwiw per above discussion w/ tsimonq2, lp:~ubuntu-archive/+junk/scripts is now lp:ubuntu-archive-scripts. I've updated snakefruit and am nuking the old branch in LP to avoid confusion
<tsimonq2> \o/ thanks
-queuebot:#ubuntu-release- Unapproved: vlc (bionic-proposed/universe) [3.0.2-0ubuntu0.1 => 3.0.3-1ubuntu0.1] (kubuntu, mozilla)
<tsimonq2> slangasek: I have that server ready if you have those old ISOs, b the way.
<tsimonq2> *by
-queuebot:#ubuntu-release- Unapproved: falkon (bionic-proposed/universe) [3.0.0-0ubuntu3 => 3.0.1-0ubuntu0.1] (kubuntu)
<cjwatson> slangasek: thanks
<cjwatson> (and to tsimonq2)
<tsimonq2> :)
<slangasek> tsimonq2: I don't "have" them; as I said, they're in cold storage - I would need to submit an RT to request them be brought back up
<slangasek> tsimonq2: you might want to give me a prioritized list of what you want
<tsimonq2> slangasek: ack
<tsimonq2> slangasek: I'll go through things before the end of the week and shoot you an email
-queuebot:#ubuntu-release- New binary: biosyntax [amd64] (cosmic-proposed/none) [0.1~beta4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-multcompview [amd64] (cosmic-proposed/none) [0.1-7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: morty [amd64] (cosmic-proposed/none) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hypopg [amd64] (cosmic-proposed/none) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-gmm [amd64] (cosmic-proposed/none) [1.6-2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hypopg [i386] (cosmic-proposed/none) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ucminf [amd64] (cosmic-proposed/none) [1.1-4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: opam-file-format [amd64] (cosmic-proposed/none) [2.0.0~rc2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: opam-file-format [i386] (cosmic-proposed/none) [2.0.0~rc2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gigalomania [amd64] (cosmic-proposed/none) [1.0+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: morty [ppc64el] (cosmic-proposed/none) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pgpool2 [amd64] (cosmic-proposed/none) [3.7.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-bh [amd64] (cosmic-proposed/none) [1.66.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpsm2 [amd64] (cosmic-proposed/none) [10.3-37-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pgpool2 [i386] (cosmic-proposed/none) [3.7.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: opam-file-format [ppc64el] (cosmic-proposed/none) [2.0.0~rc2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gigalomania [ppc64el] (cosmic-proposed/universe) [1.0+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ucminf [i386] (cosmic-proposed/universe) [1.1-4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jsonhyperschema-codec [amd64] (cosmic-proposed/universe) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ucminf [ppc64el] (cosmic-proposed/universe) [1.1-4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: morty [i386] (cosmic-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-openxlsx [amd64] (cosmic-proposed/universe) [4.0.17-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hypopg [ppc64el] (cosmic-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-openxlsx [i386] (cosmic-proposed/universe) [4.0.17-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-manipulatewidgets [amd64] (cosmic-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sqlalchemy-i18n [amd64] (cosmic-proposed/universe) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gigalomania [i386] (cosmic-proposed/universe) [1.0+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pgpool2 [ppc64el] (cosmic-proposed/universe) [3.7.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libdsk [ppc64el] (cosmic-proposed/universe) [1.5.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: morty [armhf] (cosmic-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: opam-file-format [armhf] (cosmic-proposed/universe) [2.0.0~rc2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: morty [arm64] (cosmic-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-openxlsx [ppc64el] (cosmic-proposed/universe) [4.0.17-1] (no packageset)
-queuebot:#ubuntu-release- New binary: opam-file-format [arm64] (cosmic-proposed/universe) [2.0.0~rc2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gigalomania [arm64] (cosmic-proposed/universe) [1.0+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libdsk [amd64] (cosmic-proposed/universe) [1.5.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gigalomania [armhf] (cosmic-proposed/universe) [1.0+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: morty [s390x] (cosmic-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gigalomania [s390x] (cosmic-proposed/universe) [1.0+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: simulide [ppc64el] (cosmic-proposed/universe) [0.1.7+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: opam-file-format [s390x] (cosmic-proposed/universe) [2.0.0~rc2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hypopg [arm64] (cosmic-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: simulide [amd64] (cosmic-proposed/universe) [0.1.7+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pgpool2 [arm64] (cosmic-proposed/universe) [3.7.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: simulide [i386] (cosmic-proposed/universe) [0.1.7+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hypopg [armhf] (cosmic-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ucminf [armhf] (cosmic-proposed/universe) [1.1-4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libdsk [i386] (cosmic-proposed/universe) [1.5.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pgpool2 [s390x] (cosmic-proposed/universe) [3.7.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ucminf [arm64] (cosmic-proposed/universe) [1.1-4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pgpool2 [armhf] (cosmic-proposed/universe) [3.7.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ucminf [s390x] (cosmic-proposed/universe) [1.1-4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hypopg [s390x] (cosmic-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libdsk [armhf] (cosmic-proposed/universe) [1.5.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libdsk [arm64] (cosmic-proposed/universe) [1.5.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-openxlsx [arm64] (cosmic-proposed/universe) [4.0.17-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libdsk [s390x] (cosmic-proposed/universe) [1.5.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-openxlsx [armhf] (cosmic-proposed/universe) [4.0.17-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-openxlsx [s390x] (cosmic-proposed/universe) [4.0.17-1] (no packageset)
-queuebot:#ubuntu-release- New binary: simulide [s390x] (cosmic-proposed/universe) [0.1.7+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: simulide [arm64] (cosmic-proposed/universe) [0.1.7+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: simulide [armhf] (cosmic-proposed/universe) [0.1.7+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nlohmann-json3 [amd64] (cosmic-proposed/universe) [3.1.2-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected maas [source] (bionic-proposed) [2.4.0~beta3-6929-g62682abf5-0ubuntu1]
#ubuntu-release 2018-05-30
-queuebot:#ubuntu-release- New binary: rocksdb [ppc64el] (cosmic-proposed/universe) [5.13.2-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted opencryptoki [source] (bionic-proposed) [3.9.0+dfsg-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted opencryptoki [source] (artful-proposed) [3.7.0+dfsg-4ubuntu1]
-queuebot:#ubuntu-release- New binary: rocksdb [amd64] (cosmic-proposed/universe) [5.13.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rocksdb [i386] (cosmic-proposed/universe) [5.13.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rocksdb [arm64] (cosmic-proposed/universe) [5.13.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: goval-dictionary [amd64] (cosmic-proposed/none) [0.0~git20180502.0.55b7f72-1] (no packageset)
-queuebot:#ubuntu-release- New binary: goval-dictionary [ppc64el] (cosmic-proposed/none) [0.0~git20180502.0.55b7f72-1] (no packageset)
-queuebot:#ubuntu-release- New binary: goval-dictionary [i386] (cosmic-proposed/none) [0.0~git20180502.0.55b7f72-1] (no packageset)
-queuebot:#ubuntu-release- New binary: goval-dictionary [s390x] (cosmic-proposed/none) [0.0~git20180502.0.55b7f72-1] (no packageset)
-queuebot:#ubuntu-release- New binary: goval-dictionary [arm64] (cosmic-proposed/none) [0.0~git20180502.0.55b7f72-1] (no packageset)
-queuebot:#ubuntu-release- New binary: goval-dictionary [armhf] (cosmic-proposed/none) [0.0~git20180502.0.55b7f72-1] (no packageset)
<slangasek> bluesabre: fyi I've added precise to the list of branches imported into the xubuntu seed repo, because according to ubuntu-seeds, precise is still in the list of releases we try to pull updates for, so without it the whole script fails
<slangasek> tsimonq2: ^^ um, ditto lubuntu.  If you insist on the repo not having a complete list of branches, please at least update update-seeds to not reference the branches before you delete them
-queuebot:#ubuntu-release- New: accepted biosyntax [amd64] (cosmic-proposed) [0.1~beta4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted gigalomania [arm64] (cosmic-proposed) [1.0+ds1-1]
-queuebot:#ubuntu-release- New: accepted gigalomania [i386] (cosmic-proposed) [1.0+ds1-1]
-queuebot:#ubuntu-release- New: accepted gigalomania [s390x] (cosmic-proposed) [1.0+ds1-1]
-queuebot:#ubuntu-release- New: accepted gigalomania [amd64] (cosmic-proposed) [1.0+ds1-1]
-queuebot:#ubuntu-release- New: accepted gigalomania [ppc64el] (cosmic-proposed) [1.0+ds1-1]
-queuebot:#ubuntu-release- New: accepted gigalomania [armhf] (cosmic-proposed) [1.0+ds1-1]
-queuebot:#ubuntu-release- New: accepted goval-dictionary [amd64] (cosmic-proposed) [0.0~git20180502.0.55b7f72-1]
-queuebot:#ubuntu-release- New: accepted goval-dictionary [armhf] (cosmic-proposed) [0.0~git20180502.0.55b7f72-1]
-queuebot:#ubuntu-release- New: accepted goval-dictionary [ppc64el] (cosmic-proposed) [0.0~git20180502.0.55b7f72-1]
-queuebot:#ubuntu-release- New: accepted hypopg [amd64] (cosmic-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted hypopg [armhf] (cosmic-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted hypopg [ppc64el] (cosmic-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New binary: libheif [arm64] (cosmic-proposed/universe) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libheif [ppc64el] (cosmic-proposed/universe) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lz4 [amd64] (cosmic-proposed/main) [1.8.2-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: lz4 [armhf] (cosmic-proposed/main) [1.8.2-1ubuntu1] (core)
-queuebot:#ubuntu-release- New: accepted goval-dictionary [arm64] (cosmic-proposed) [0.0~git20180502.0.55b7f72-1]
-queuebot:#ubuntu-release- New: accepted goval-dictionary [s390x] (cosmic-proposed) [0.0~git20180502.0.55b7f72-1]
-queuebot:#ubuntu-release- New: accepted hypopg [i386] (cosmic-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New binary: libheif [armhf] (cosmic-proposed/universe) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lz4 [arm64] (cosmic-proposed/main) [1.8.2-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: lz4 [ppc64el] (cosmic-proposed/main) [1.8.2-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: rustc [arm64] (cosmic-proposed/universe) [1.26.0+dfsg0+llvm-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New: accepted goval-dictionary [i386] (cosmic-proposed) [0.0~git20180502.0.55b7f72-1]
-queuebot:#ubuntu-release- New: accepted hypopg [s390x] (cosmic-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New binary: lz4 [i386] (cosmic-proposed/main) [1.8.2-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: rustc [armhf] (cosmic-proposed/universe) [1.26.0+dfsg0+llvm-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New: accepted hypopg [arm64] (cosmic-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New binary: lz4 [s390x] (cosmic-proposed/main) [1.8.2-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: libheif [s390x] (cosmic-proposed/universe) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted jsonhyperschema-codec [amd64] (cosmic-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted libdsk [arm64] (cosmic-proposed) [1.5.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted libdsk [i386] (cosmic-proposed) [1.5.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted libdsk [s390x] (cosmic-proposed) [1.5.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted libdsk [amd64] (cosmic-proposed) [1.5.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted libdsk [ppc64el] (cosmic-proposed) [1.5.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted libdsk [armhf] (cosmic-proposed) [1.5.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted libheif [amd64] (cosmic-proposed) [1.2.0-1]
-queuebot:#ubuntu-release- New: accepted libheif [armhf] (cosmic-proposed) [1.2.0-1]
-queuebot:#ubuntu-release- New: accepted libheif [ppc64el] (cosmic-proposed) [1.2.0-1]
-queuebot:#ubuntu-release- New: accepted libzypp [amd64] (cosmic-proposed) [17.3.1-1]
-queuebot:#ubuntu-release- New: accepted libzypp [armhf] (cosmic-proposed) [17.3.1-1]
-queuebot:#ubuntu-release- New: accepted libzypp [s390x] (cosmic-proposed) [17.3.1-1]
-queuebot:#ubuntu-release- New: accepted libheif [arm64] (cosmic-proposed) [1.2.0-1]
-queuebot:#ubuntu-release- New: accepted libheif [s390x] (cosmic-proposed) [1.2.0-1]
-queuebot:#ubuntu-release- New: accepted libzypp [i386] (cosmic-proposed) [17.3.1-1]
-queuebot:#ubuntu-release- New: accepted libheif [i386] (cosmic-proposed) [1.2.0-1]
-queuebot:#ubuntu-release- New: accepted libzypp [arm64] (cosmic-proposed) [17.3.1-1]
-queuebot:#ubuntu-release- New: accepted libzypp [ppc64el] (cosmic-proposed) [17.3.1-1]
-queuebot:#ubuntu-release- New: accepted morty [arm64] (cosmic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted morty [i386] (cosmic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted morty [s390x] (cosmic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted opam-file-format [amd64] (cosmic-proposed) [2.0.0~rc2-1]
-queuebot:#ubuntu-release- New: accepted opam-file-format [armhf] (cosmic-proposed) [2.0.0~rc2-1]
-queuebot:#ubuntu-release- New: accepted opam-file-format [ppc64el] (cosmic-proposed) [2.0.0~rc2-1]
-queuebot:#ubuntu-release- New: accepted pgpool2 [amd64] (cosmic-proposed) [3.7.3-1]
-queuebot:#ubuntu-release- New: accepted pgpool2 [armhf] (cosmic-proposed) [3.7.3-1]
-queuebot:#ubuntu-release- New: accepted pgpool2 [ppc64el] (cosmic-proposed) [3.7.3-1]
-queuebot:#ubuntu-release- New: accepted morty [amd64] (cosmic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted morty [ppc64el] (cosmic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted opam-file-format [arm64] (cosmic-proposed) [2.0.0~rc2-1]
-queuebot:#ubuntu-release- New: accepted opam-file-format [s390x] (cosmic-proposed) [2.0.0~rc2-1]
-queuebot:#ubuntu-release- New: accepted pgpool2 [i386] (cosmic-proposed) [3.7.3-1]
-queuebot:#ubuntu-release- New: accepted r-cran-bh [amd64] (cosmic-proposed) [1.66.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-manipulatewidgets [amd64] (cosmic-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted morty [armhf] (cosmic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted opam-file-format [i386] (cosmic-proposed) [2.0.0~rc2-1]
-queuebot:#ubuntu-release- New: accepted pgpool2 [s390x] (cosmic-proposed) [3.7.3-1]
-queuebot:#ubuntu-release- New: accepted r-cran-multcompview [amd64] (cosmic-proposed) [0.1-7-1]
-queuebot:#ubuntu-release- New: accepted nlohmann-json3 [amd64] (cosmic-proposed) [3.1.2-2]
-queuebot:#ubuntu-release- New: accepted r-cran-gmm [amd64] (cosmic-proposed) [1.6-2-1]
-queuebot:#ubuntu-release- New: accepted pgpool2 [arm64] (cosmic-proposed) [3.7.3-1]
-queuebot:#ubuntu-release- New: accepted r-cran-openxlsx [amd64] (cosmic-proposed) [4.0.17-1]
-queuebot:#ubuntu-release- New: accepted r-cran-openxlsx [armhf] (cosmic-proposed) [4.0.17-1]
-queuebot:#ubuntu-release- New: accepted r-cran-openxlsx [ppc64el] (cosmic-proposed) [4.0.17-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ucminf [amd64] (cosmic-proposed) [1.1-4-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ucminf [armhf] (cosmic-proposed) [1.1-4-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ucminf [ppc64el] (cosmic-proposed) [1.1-4-1]
-queuebot:#ubuntu-release- New: accepted sqlalchemy-i18n [amd64] (cosmic-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted r-cran-openxlsx [arm64] (cosmic-proposed) [4.0.17-1]
-queuebot:#ubuntu-release- New: accepted r-cran-openxlsx [s390x] (cosmic-proposed) [4.0.17-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ucminf [i386] (cosmic-proposed) [1.1-4-1]
-queuebot:#ubuntu-release- New: accepted r-cran-openxlsx [i386] (cosmic-proposed) [4.0.17-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ucminf [s390x] (cosmic-proposed) [1.1-4-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ucminf [arm64] (cosmic-proposed) [1.1-4-1]
-queuebot:#ubuntu-release- Unapproved: networkd-dispatcher (bionic-proposed/main) [1.7-0ubuntu3 => 1.7-0ubuntu3.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: kexec-tools (artful-proposed/main) [1:2.0.15-0ubuntu1 => 1:2.0.16-1ubuntu1~17.10.1] (core)
-queuebot:#ubuntu-release- Unapproved: kexec-tools (xenial-proposed/main) [1:2.0.10-1ubuntu2.5 => 1:2.0.16-1ubuntu1~16.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: makedumpfile (artful-proposed/main) [1:1.6.1-2ubuntu0.2 => 1:1.6.3-2~17.10.1] (core)
-queuebot:#ubuntu-release- Unapproved: makedumpfile (xenial-proposed/main) [1:1.5.9-5ubuntu0.7 => 1:1.6.3-2~16.04.1] (core)
-queuebot:#ubuntu-release- New binary: openstack-cluster-installer [amd64] (cosmic-proposed/none) [1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnucobol [amd64] (cosmic-proposed/none) [2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-rwcarlsen-goexif [amd64] (cosmic-proposed/none) [0.0~git20180410.fb35d3c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpam-freerdp2 [ppc64el] (cosmic-proposed/none) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nlopt [s390x] (cosmic-proposed/universe) [2.4.2+dfsg-5] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-dorng [amd64] (cosmic-proposed/none) [1.6.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rappdirs [amd64] (cosmic-proposed/none) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: go-cve-dictionary [ppc64el] (cosmic-proposed/none) [0.1.1+git20180404.0.4ee71e8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lightdm-remote-session-freerdp2 [amd64] (cosmic-proposed/none) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-mda [i386] (cosmic-proposed/none) [0.4-10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpam-freerdp2 [amd64] (cosmic-proposed/none) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rappdirs [i386] (cosmic-proposed/none) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-commonmark [i386] (cosmic-proposed/none) [1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnucobol [ppc64el] (cosmic-proposed/none) [2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: go-cve-dictionary [amd64] (cosmic-proposed/none) [0.1.1+git20180404.0.4ee71e8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnucobol [i386] (cosmic-proposed/none) [2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lightdm-remote-session-freerdp2 [ppc64el] (cosmic-proposed/none) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-magic [amd64] (cosmic-proposed/none) [1.5-8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rappdirs [ppc64el] (cosmic-proposed/none) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lightdm-remote-session-freerdp2 [i386] (cosmic-proposed/none) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-mda [ppc64el] (cosmic-proposed/none) [0.4-10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-commonmark [ppc64el] (cosmic-proposed/none) [1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fasta3 [i386] (cosmic-proposed/none) [36.3.8g-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nagios4 [amd64] (cosmic-proposed/none) [4.3.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-later [ppc64el] (cosmic-proposed/none) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: go-cve-dictionary [i386] (cosmic-proposed/none) [0.1.1+git20180404.0.4ee71e8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-mda [amd64] (cosmic-proposed/none) [0.4-10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nlopt [ppc64el] (cosmic-proposed/universe) [2.4.2+dfsg-5] (no packageset)
-queuebot:#ubuntu-release- New binary: cod-tools [ppc64el] (cosmic-proposed/none) [2.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: geoalchemy2 [amd64] (cosmic-proposed/none) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fasta3 [amd64] (cosmic-proposed/none) [36.3.8g-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-commonmark [amd64] (cosmic-proposed/none) [1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpam-freerdp2 [i386] (cosmic-proposed/none) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-later [amd64] (cosmic-proposed/none) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-later [i386] (cosmic-proposed/none) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnucobol [s390x] (cosmic-proposed/none) [2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpam-freerdp2 [s390x] (cosmic-proposed/none) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: go-cve-dictionary [s390x] (cosmic-proposed/none) [0.1.1+git20180404.0.4ee71e8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnucobol [arm64] (cosmic-proposed/none) [2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: go-cve-dictionary [armhf] (cosmic-proposed/none) [0.1.1+git20180404.0.4ee71e8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-later [s390x] (cosmic-proposed/none) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnucobol [armhf] (cosmic-proposed/none) [2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-mda [s390x] (cosmic-proposed/none) [0.4-10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-commonmark [s390x] (cosmic-proposed/none) [1.5-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted lz4 [amd64] (cosmic-proposed) [1.8.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted lz4 [i386] (cosmic-proposed) [1.8.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted lz4 [s390x] (cosmic-proposed) [1.8.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted lz4 [arm64] (cosmic-proposed) [1.8.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted lz4 [ppc64el] (cosmic-proposed) [1.8.2-1ubuntu1]
-queuebot:#ubuntu-release- New binary: cod-tools [i386] (cosmic-proposed/none) [2.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lightdm-remote-session-freerdp2 [s390x] (cosmic-proposed/none) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rappdirs [s390x] (cosmic-proposed/none) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: go-cve-dictionary [arm64] (cosmic-proposed/none) [0.1.1+git20180404.0.4ee71e8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nlopt [arm64] (cosmic-proposed/universe) [2.4.2+dfsg-5] (no packageset)
<ginggs> Odd_Bloke: thanks for the getfem patch, I was able to fix the FTBFS and upload
-queuebot:#ubuntu-release- New: accepted gnucobol [amd64] (cosmic-proposed) [2.2-1]
-queuebot:#ubuntu-release- New: accepted gnucobol [armhf] (cosmic-proposed) [2.2-1]
-queuebot:#ubuntu-release- New: accepted gnucobol [ppc64el] (cosmic-proposed) [2.2-1]
-queuebot:#ubuntu-release- New binary: libpam-freerdp2 [arm64] (cosmic-proposed/none) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nagios4 [i386] (cosmic-proposed/none) [4.3.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-commonmark [arm64] (cosmic-proposed/none) [1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-mda [arm64] (cosmic-proposed/none) [0.4-10-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gnucobol [arm64] (cosmic-proposed) [2.2-1]
-queuebot:#ubuntu-release- New: accepted gnucobol [s390x] (cosmic-proposed) [2.2-1]
-queuebot:#ubuntu-release- New binary: nlopt [armhf] (cosmic-proposed/universe) [2.4.2+dfsg-5] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-mda [armhf] (cosmic-proposed/none) [0.4-10-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gnucobol [i386] (cosmic-proposed) [2.2-1]
-queuebot:#ubuntu-release- New binary: r-cran-commonmark [armhf] (cosmic-proposed/none) [1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpam-freerdp2 [armhf] (cosmic-proposed/none) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-later [arm64] (cosmic-proposed/none) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rappdirs [arm64] (cosmic-proposed/none) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-later [armhf] (cosmic-proposed/none) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rappdirs [armhf] (cosmic-proposed/none) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cod-tools [s390x] (cosmic-proposed/none) [2.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lightdm-remote-session-freerdp2 [armhf] (cosmic-proposed/none) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nlopt [i386] (cosmic-proposed/universe) [2.4.2+dfsg-5] (no packageset)
-queuebot:#ubuntu-release- New binary: lightdm-remote-session-freerdp2 [arm64] (cosmic-proposed/none) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nlopt [amd64] (cosmic-proposed/universe) [2.4.2+dfsg-5] (no packageset)
-queuebot:#ubuntu-release- New: accepted r-cran-mda [amd64] (cosmic-proposed) [0.4-10-1]
-queuebot:#ubuntu-release- New: accepted r-cran-mda [armhf] (cosmic-proposed) [0.4-10-1]
-queuebot:#ubuntu-release- New: accepted r-cran-mda [ppc64el] (cosmic-proposed) [0.4-10-1]
-queuebot:#ubuntu-release- New binary: rustc [arm64] (cosmic-proposed/universe) [1.26.0+dfsg0+llvm-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [s390x] (cosmic-proposed/universe) [1.26.0+dfsg0+llvm-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [ppc64el] (cosmic-proposed/universe) [1.26.0+dfsg0+llvm-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New: accepted r-cran-mda [arm64] (cosmic-proposed) [0.4-10-1]
-queuebot:#ubuntu-release- New: accepted r-cran-mda [s390x] (cosmic-proposed) [0.4-10-1]
-queuebot:#ubuntu-release- New binary: rustc [i386] (cosmic-proposed/universe) [1.26.0+dfsg0+llvm-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New: accepted r-cran-mda [i386] (cosmic-proposed) [0.4-10-1]
-queuebot:#ubuntu-release- New binary: rustc [s390x] (cosmic-proposed/universe) [1.26.0+dfsg0+llvm-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [ppc64el] (cosmic-proposed/universe) [1.26.0+dfsg0+llvm-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted r-cran-later [amd64] (cosmic-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-later [armhf] (cosmic-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-later [ppc64el] (cosmic-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New source: jboss-annotations-1.2-api (cosmic-proposed/primary) [1.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New source: pmdk (cosmic-proposed/primary) [1.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted r-cran-later [arm64] (cosmic-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-later [s390x] (cosmic-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-later [i386] (cosmic-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New source: ndctl (cosmic-proposed/primary) [60.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted nlopt [amd64] (cosmic-proposed) [2.4.2+dfsg-5]
-queuebot:#ubuntu-release- New: accepted nlopt [armhf] (cosmic-proposed) [2.4.2+dfsg-5]
-queuebot:#ubuntu-release- New: accepted nlopt [ppc64el] (cosmic-proposed) [2.4.2+dfsg-5]
-queuebot:#ubuntu-release- New: accepted nlopt [arm64] (cosmic-proposed) [2.4.2+dfsg-5]
-queuebot:#ubuntu-release- New: accepted nlopt [s390x] (cosmic-proposed) [2.4.2+dfsg-5]
-queuebot:#ubuntu-release- New: accepted nlopt [i386] (cosmic-proposed) [2.4.2+dfsg-5]
-queuebot:#ubuntu-release- New: accepted go-cve-dictionary [amd64] (cosmic-proposed) [0.1.1+git20180404.0.4ee71e8-1]
-queuebot:#ubuntu-release- New: accepted go-cve-dictionary [armhf] (cosmic-proposed) [0.1.1+git20180404.0.4ee71e8-1]
-queuebot:#ubuntu-release- New: accepted go-cve-dictionary [ppc64el] (cosmic-proposed) [0.1.1+git20180404.0.4ee71e8-1]
-queuebot:#ubuntu-release- New: accepted go-cve-dictionary [arm64] (cosmic-proposed) [0.1.1+git20180404.0.4ee71e8-1]
-queuebot:#ubuntu-release- New: accepted go-cve-dictionary [s390x] (cosmic-proposed) [0.1.1+git20180404.0.4ee71e8-1]
-queuebot:#ubuntu-release- New: accepted go-cve-dictionary [i386] (cosmic-proposed) [0.1.1+git20180404.0.4ee71e8-1]
-queuebot:#ubuntu-release- New: accepted simulide [amd64] (cosmic-proposed) [0.1.7+dfsg-1]
-queuebot:#ubuntu-release- New: accepted simulide [armhf] (cosmic-proposed) [0.1.7+dfsg-1]
-queuebot:#ubuntu-release- New: accepted simulide [ppc64el] (cosmic-proposed) [0.1.7+dfsg-1]
-queuebot:#ubuntu-release- New: accepted simulide [arm64] (cosmic-proposed) [0.1.7+dfsg-1]
-queuebot:#ubuntu-release- New: accepted simulide [s390x] (cosmic-proposed) [0.1.7+dfsg-1]
-queuebot:#ubuntu-release- New: accepted simulide [i386] (cosmic-proposed) [0.1.7+dfsg-1]
-queuebot:#ubuntu-release- New binary: cod-tools [amd64] (cosmic-proposed/none) [2.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rocksdb [amd64] (cosmic-proposed) [5.13.2-1]
-queuebot:#ubuntu-release- New: accepted rocksdb [i386] (cosmic-proposed) [5.13.2-1]
-queuebot:#ubuntu-release- New: accepted rocksdb [s390x] (cosmic-proposed) [5.13.2-1]
-queuebot:#ubuntu-release- New: accepted rocksdb [arm64] (cosmic-proposed) [5.13.2-1]
-queuebot:#ubuntu-release- New: accepted rocksdb [ppc64el] (cosmic-proposed) [5.13.2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rappdirs [amd64] (cosmic-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rappdirs [armhf] (cosmic-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rappdirs [ppc64el] (cosmic-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rappdirs [arm64] (cosmic-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rappdirs [s390x] (cosmic-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rappdirs [i386] (cosmic-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-commonmark [amd64] (cosmic-proposed) [1.5-1]
-queuebot:#ubuntu-release- New: accepted r-cran-commonmark [armhf] (cosmic-proposed) [1.5-1]
-queuebot:#ubuntu-release- New: accepted r-cran-commonmark [ppc64el] (cosmic-proposed) [1.5-1]
-queuebot:#ubuntu-release- New: accepted r-cran-commonmark [arm64] (cosmic-proposed) [1.5-1]
-queuebot:#ubuntu-release- New: accepted r-cran-commonmark [s390x] (cosmic-proposed) [1.5-1]
-queuebot:#ubuntu-release- New: accepted r-cran-commonmark [i386] (cosmic-proposed) [1.5-1]
-queuebot:#ubuntu-release- New: accepted lz4 [armhf] (cosmic-proposed) [1.8.2-1ubuntu1]
-queuebot:#ubuntu-release- New binary: cod-tools [armhf] (cosmic-proposed/none) [2.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cod-tools [arm64] (cosmic-proposed/none) [2.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted lightdm-remote-session-freerdp2 [amd64] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted lightdm-remote-session-freerdp2 [i386] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted lightdm-remote-session-freerdp2 [arm64] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted lightdm-remote-session-freerdp2 [ppc64el] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted lightdm-remote-session-freerdp2 [armhf] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted lightdm-remote-session-freerdp2 [s390x] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-dorng [amd64] (cosmic-proposed) [1.6.6-1]
-queuebot:#ubuntu-release- New: accepted r-cran-magic [amd64] (cosmic-proposed) [1.5-8-1]
-queuebot:#ubuntu-release- New: accepted libpam-freerdp2 [amd64] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted libpam-freerdp2 [armhf] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted libpam-freerdp2 [ppc64el] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted libpam-freerdp2 [arm64] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted libpam-freerdp2 [s390x] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted libpam-freerdp2 [i386] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted cod-tools [amd64] (cosmic-proposed) [2.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted cod-tools [armhf] (cosmic-proposed) [2.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted cod-tools [ppc64el] (cosmic-proposed) [2.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted cod-tools [arm64] (cosmic-proposed) [2.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted cod-tools [s390x] (cosmic-proposed) [2.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted cod-tools [i386] (cosmic-proposed) [2.1+dfsg-1]
-queuebot:#ubuntu-release- New: rejected rustc [arm64] (cosmic-proposed) [1.26.0+dfsg0+llvm-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected rustc [s390x] (cosmic-proposed) [1.26.0+dfsg0+llvm-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected rustc [ppc64el] (cosmic-proposed) [1.26.0+dfsg0+llvm-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted openstack-cluster-installer [amd64] (cosmic-proposed) [1]
-queuebot:#ubuntu-release- New: accepted golang-github-rwcarlsen-goexif [amd64] (cosmic-proposed) [0.0~git20180410.fb35d3c-1]
<tsimonq2> slangasek: Fine, thanks.
-queuebot:#ubuntu-release- New: accepted libpsm2 [amd64] (cosmic-proposed) [10.3-37-1]
<cpaelzer> :-/ I have to apologize for a borked upload as I had to build in a cosmic container it is now listed with the changelog as root@c.lxd
<cpaelzer> I have extended my pre-dput checker to unclude that from now on http://paste.ubuntu.com/p/nMnXDzhgjr/ but since LP already has it I can't fix it in archive/history anymore
<cpaelzer> thanks rbasak for making me aware
<apw> cpaelzer, whihc is why you should always spot check the debdiff
<cpaelzer> apw: for my defense, I did check every server- file change to be what I intended, but missed the obvious in the changelog
<cpaelzer> but this one is on me, and apologizing and adding the checks to avoid it happening again is all I can do :-/
<apw> cpaelzer, heh don't beat on yourself too hard ...
-queuebot:#ubuntu-release- New binary: r-cran-tmvtnorm [amd64] (cosmic-proposed/universe) [1.4-10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-tmvtnorm [s390x] (cosmic-proposed/universe) [1.4-10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-tmvtnorm [i386] (cosmic-proposed/universe) [1.4-10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-tmvtnorm [arm64] (cosmic-proposed/universe) [1.4-10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-tmvtnorm [ppc64el] (cosmic-proposed/universe) [1.4-10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-tmvtnorm [armhf] (cosmic-proposed/universe) [1.4-10-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (trusty-proposed/universe) [20180510+dfsg1-0ubuntu3~14.04.1 => 20180510+dfsg1-0ubuntu3~14.04.2] (ubuntu-cloud)
<doko> Laney: the running binutils autopkg test on s390x looks strange
<Laney> maybe you could say how
<Laney> and probably tell juliank since I think he's in or going to be in autopkgtest to look at the cloud-init bustedness
<doko> the build (inside the autopkg test) finishes, and then it hangs
<doko> juliank: ^^^
<juliank> nice
<juliank> doko: it's running at the moment, and seems to make progress configuring stuff, are you talking about an older one that timed out?
<Laney> does seem very much slower than previous runs though
<Laney> note this is running on bos01 which I thought we had disabled
<juliank> Laney: I'm not sure what happened, I saw it reenabled yesterday, so I thought somebody fixed it
<Laney> not me
<juliank> and then I reverted the local autopkgtest-cloud hack for the config hook
<juliank> (which set it to 0 services)
<Laney> probably an accident
<doko> ohh, it's running again ...
 * Laney has killed them
<Laney> well, disabled,
<juliank> Maybe we just have a lot less resources on s390x on bos0Ã
<doko> btw, is there any way to retry all autopkg tests for one package with all-proposed?  every time the openmpi package is uploaded, the tests fail again without it
<juliank> 1
<juliank> and maybe we should try to have 2 workers there or something
<juliank> then try 4
<juliank> and see what's stable
<Laney> it's waiting for SSDs I think
<juliank> Laney: Should we just mv bos01-s390x.rc bos01-s390x.rc.disabled for now as an addtional safety net?
<juliank> Well, I just did
<Laney> if you want
<Laney> any news on the cloud-init front?
<juliank> I actually have not investigated further was investigating upgrade failures so far today
<Laney> ok
<Laney> well the ongoing diaspora-installer look like the same thing
<juliank> some of the lxc failures which fail to fetch gpg keys might be the same issue too
<juliank> some runs work, though
<Laney> seems somewhat racy
<juliank> So there's a race between cloud-init and $something writing /etc/environment?
-queuebot:#ubuntu-release- Unapproved: vte2.91 (bionic-proposed/main) [0.52.1-1ubuntu1 => 0.52.2-1ubuntu1~18.04.1] (ubuntu-desktop)
<apw> juliank, it is so lucky all those files have a lock ... not
<Laney> I think rather the script doesn't get run for some reason
<Laney> when it's broken the mtime is old, from when the image was created
<juliank> ok
-queuebot:#ubuntu-release- Unapproved: gnome-terminal (bionic-proposed/main) [3.28.1-1ubuntu1.1 => 3.28.2-1ubuntu1~18.04.1] (desktop-core)
<ginggs> slangasek: was there a particular terrible autopkgtest timeout with python-numpy you were looking at? the transition to 1.14 did break a few packages in Debian, and some are still not fixed, although numpy has already migrated there
<slangasek> ginggs: Debian still doesn't block testing on autopkgtests, only delays them.  The ones I saw are timing out are astroplan and astropy
<Odd_Bloke> Is there a way of expressing that a test for package X is only bad with dependency Y at version Z?  (In this case, pbgenomicconsensus is blocking nympy, but only because of warnings from one of its dependencies; a newer version of the dependency will probably fix the problem.)
<Odd_Bloke> *numpy
<Odd_Bloke> So I don't want to never run the tests for pbgenomicconsensus, because they may be back to being good once a new version of h5py is uploaded to Debian and sync'd.
<ginggs> Odd_Bloke: adding 'Restrictions: allow-stderr' to debian/tests/control might help you there
<Odd_Bloke> ginggs: In this case, I believe it's upstream tests that are asserting on the output of their command.
<Odd_Bloke> Yeah, make exits non-zero: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/amd64/p/pbgenomicconsensus/20180529_175540_b3da8@/log.gz
<Odd_Bloke> ginggs: FWIW, I believe an upload of h5py 2.8.0 would also address the issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900419
<ubot5> Debian bug 900419 in src:h5py "h5py: Now emitting warnings, breaking pbgenomicconsensus tests" [Normal,Open]
<slangasek> infinity: did you have the action to follow through on mk-sbuild being unhappy about pkg-create-dbgsym disappearing?
-queuebot:#ubuntu-release- Unapproved: rejected gce-compute-image-packages [source] (trusty-proposed) [20180510+dfsg1-0ubuntu3~14.04.2]
<ginggs> slangasek: astroplan timed out on 2018-05-27 05:36:35 UTC with the old numpy http://autopkgtest.ubuntu.com/packages/a/astroplan/cosmic/amd64
<infinity> slangasek: Did I not?
<infinity> slangasek: It certainly should be fixed in bionic and cosmic.  I guess it might want SRUing back for people building bionic/cosmic chroots on trusty/xenial.
<ginggs> infinity: can we get debhelper 11.3 merged please?  it's needed by the new dh-r and there's a big R transition coming
<gpiccoli> Hi sil2100, sorry to bother (if you're away, no hurry..we can talk tmrw)
<infinity> ginggs: Yeah, it's WIP here in front of me.  Just deciding how to re-do the installchangelogs delta in a more maintainable way.
<ginggs> infinity: thanks!
<gpiccoli> I'd like to know if initramfs-tools from trusty-proposed is okay to go to trusty-updates!
<gpiccoli> thanks in advance =)
-queuebot:#ubuntu-release- New binary: r-cran-promises [ppc64el] (cosmic-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-promises [s390x] (cosmic-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1007.10] (kernel)
-queuebot:#ubuntu-release- New binary: r-cran-promises [i386] (cosmic-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-promises [amd64] (cosmic-proposed/universe) [1.0.1-1] (no packageset)
<infinity> gpiccoli: Released.
<gpiccoli> =O wow, that was...quick! heheh
<gpiccoli> thanks a lot infinity!
-queuebot:#ubuntu-release- New binary: r-cran-promises [armhf] (cosmic-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted r-cran-tmvtnorm [amd64] (cosmic-proposed) [1.4-10-1]
-queuebot:#ubuntu-release- New: accepted r-cran-tmvtnorm [armhf] (cosmic-proposed) [1.4-10-1]
-queuebot:#ubuntu-release- New: accepted r-cran-tmvtnorm [ppc64el] (cosmic-proposed) [1.4-10-1]
-queuebot:#ubuntu-release- New: accepted r-cran-tmvtnorm [arm64] (cosmic-proposed) [1.4-10-1]
-queuebot:#ubuntu-release- New: accepted r-cran-tmvtnorm [s390x] (cosmic-proposed) [1.4-10-1]
-queuebot:#ubuntu-release- New: accepted r-cran-tmvtnorm [i386] (cosmic-proposed) [1.4-10-1]
-queuebot:#ubuntu-release- New binary: r-cran-promises [arm64] (cosmic-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted r-cran-promises [amd64] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-promises [armhf] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-promises [ppc64el] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-promises [arm64] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-promises [s390x] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-promises [i386] (cosmic-proposed) [1.0.1-1]
<sil2100> gpiccoli: \o/
<gpiccoli> tnx sil2100 =]
<sil2100> Thank infinity o/
<sil2100> I usually do regular releases on my SRU shifts, that being said pinging on other days is also alright
<gpiccoli> oh okay, thanks for the information
<slangasek> infinity: yeah, diamond is currently on xenial; should I upgrade it?
<infinity> slangasek: WCPGW?
<infinity> slangasek: You could just snag ubuntu-dev-tools from bionic.  It should install on xenial/
<slangasek> infinity: the machine could hang indefinitely due to a bug in the multipath driver?
-queuebot:#ubuntu-release- Unapproved: heat (artful-proposed/main) [1:9.0.4-0ubuntu1 => 1:9.0.4-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: heat (bionic-proposed/main) [1:10.0.1-0ubuntu1 => 1:10.0.1-0ubuntu2] (openstack, ubuntu-server)
<cyphermox> slangasek: or upgrade just multipath-tools + reboot?
<slangasek> cyphermox: more interested in the upgrade generally :)
<Odd_Bloke> https://code.launchpad.net/~daniel-thewatkins/britney/hints-ubuntu/+merge/347146 badtests another couple of the numpy blockers
<teward> infinity: i know this is a followup to a question from a while ago, but which package would I have to grab to 'backport' the fix about mk-sbuild and pkg-create-dbgsym disappearing for cosmic chroots?  I ask because I'm still on Xenial for my sbuild chroots.  and if it's trivial to pull a fixed version I will, otherwise I'll wait to see if it's SRU'd.
<cyphermox> slangasek: well, it would be better, but updating just multipath-tools can be a good test if the paths are failing quickly and often
<infinity> teward: ubuntu-dev-tools from bionic should install cleanly on xenial.
<teward> infinity: ack, let me grab those.
-queuebot:#ubuntu-release- Unapproved: landscape-client (bionic-proposed/main) [18.01-0ubuntu3 => 18.01-0ubuntu3.1] (ubuntu-server)
<teward> infinity: that worked, thanks :)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (trusty-proposed/universe) [20180510+dfsg1-0ubuntu3~14.04.1 => 20180510+dfsg1-0ubuntu3~14.04.2] (ubuntu-cloud)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (artful-proposed/main) [4.13.0-45.50] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: pollinate (artful-proposed/main) [4.27-0ubuntu1 => 4.33-0ubuntu1~17.10.1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: pollinate (trusty-proposed/main) [4.25-0ubuntu1~14.04.1 => 4.33-0ubuntu1~14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pollinate (xenial-proposed/main) [4.25-0ubuntu1~16.04.1 => 4.33-0ubuntu1~16.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: pollinate (bionic-proposed/main) [4.31-0ubuntu1 => 4.33-0ubuntu1~18.04.1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: apport (bionic-proposed/main) [2.20.9-0ubuntu7.1 => 2.20.9-0ubuntu7.2] (core)
-queuebot:#ubuntu-release- New binary: r-cran-ggridges [amd64] (cosmic-proposed/none) [0.5.0-1] (no packageset)
#ubuntu-release 2018-05-31
-queuebot:#ubuntu-release- New binary: spglib [ppc64el] (cosmic-proposed/none) [1.10.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: spglib [s390x] (cosmic-proposed/universe) [1.10.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: spglib [amd64] (cosmic-proposed/universe) [1.10.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: spglib [i386] (cosmic-proposed/universe) [1.10.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: spglib [arm64] (cosmic-proposed/universe) [1.10.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: spglib [armhf] (cosmic-proposed/universe) [1.10.3-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gnome-initial-setup (bionic-proposed/main) [3.28.0-2ubuntu6.1 => 3.28.0-2ubuntu6.16.04.1] (ubuntugnome)
-queuebot:#ubuntu-release- New binary: nut [amd64] (cosmic-proposed/main) [2.7.4-7ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server)
<ginggs> infinity: that R transition has started, debian #896667
<ubot5> Debian bug 896667 in release.debian.org "transition: r-base-3.5" [Normal,Open] http://bugs.debian.org/896667
-queuebot:#ubuntu-release- New: accepted geoalchemy2 [amd64] (cosmic-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-report (bionic-proposed/main) [1.0.11 => 1.1.0] (no packageset)
-queuebot:#ubuntu-release- New: accepted r-cran-ggridges [amd64] (cosmic-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted spglib [amd64] (cosmic-proposed) [1.10.3-1]
-queuebot:#ubuntu-release- New: accepted spglib [armhf] (cosmic-proposed) [1.10.3-1]
-queuebot:#ubuntu-release- New: accepted spglib [ppc64el] (cosmic-proposed) [1.10.3-1]
-queuebot:#ubuntu-release- New: accepted spglib [arm64] (cosmic-proposed) [1.10.3-1]
-queuebot:#ubuntu-release- New: accepted spglib [s390x] (cosmic-proposed) [1.10.3-1]
-queuebot:#ubuntu-release- New: accepted spglib [i386] (cosmic-proposed) [1.10.3-1]
-queuebot:#ubuntu-release- New: accepted nut [amd64] (cosmic-proposed) [2.7.4-7ubuntu1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1007.10]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (artful-proposed) [4.13.0-45.50]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1013.13~16.04.2] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1013.13~16.04.2]
<rbalint> could someone please accept gce-compute-image-packages to trusty? it is tested and is urgent-ish
<apw> rbalint, looking
<rbalint> apw, thanks, sil2100 is looking, too now
<apw> rbalint, then i won't be looking
<bluesabre> slangasek: thanks for taking care of the precise branch :)
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (trusty-proposed) [20180510+dfsg1-0ubuntu3~14.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted llvm-defaults [source] (bionic-proposed) [0.41~exp5~ubuntu1]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-151.201] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-151.201]
-queuebot:#ubuntu-release- New binary: kicad-footprints [amd64] (cosmic-proposed/universe) [5.0.0~rc2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: kicad-templates [amd64] (cosmic-proposed/universe) [5.0.0~rc1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: kicad-symbols [amd64] (cosmic-proposed/universe) [5.0.0~rc2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: kicad-packages3d [amd64] (cosmic-proposed/universe) [5.0.0~rc2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libgit2 [ppc64el] (cosmic-proposed/universe) [0.27.0+dfsg.1-0.4] (kubuntu)
-queuebot:#ubuntu-release- New binary: libgit2 [s390x] (cosmic-proposed/universe) [0.27.0+dfsg.1-0.4] (kubuntu)
-queuebot:#ubuntu-release- New binary: libgit2 [armhf] (cosmic-proposed/universe) [0.27.0+dfsg.1-0.4] (kubuntu)
-queuebot:#ubuntu-release- New binary: libgit2 [arm64] (cosmic-proposed/universe) [0.27.0+dfsg.1-0.4] (kubuntu)
-queuebot:#ubuntu-release- New binary: libgit2 [amd64] (cosmic-proposed/universe) [0.27.0+dfsg.1-0.4] (kubuntu)
-queuebot:#ubuntu-release- New binary: libgit2 [i386] (cosmic-proposed/universe) [0.27.0+dfsg.1-0.4] (kubuntu)
-queuebot:#ubuntu-release- New: accepted fasta3 [amd64] (cosmic-proposed) [36.3.8g-1]
-queuebot:#ubuntu-release- New: accepted kicad-footprints [amd64] (cosmic-proposed) [5.0.0~rc2-2]
-queuebot:#ubuntu-release- New: accepted kicad-symbols [amd64] (cosmic-proposed) [5.0.0~rc2-2]
-queuebot:#ubuntu-release- New: accepted libgit2 [amd64] (cosmic-proposed) [0.27.0+dfsg.1-0.4]
-queuebot:#ubuntu-release- New: accepted libgit2 [armhf] (cosmic-proposed) [0.27.0+dfsg.1-0.4]
-queuebot:#ubuntu-release- New: accepted libgit2 [ppc64el] (cosmic-proposed) [0.27.0+dfsg.1-0.4]
-queuebot:#ubuntu-release- New: accepted nagios4 [amd64] (cosmic-proposed) [4.3.4-2]
-queuebot:#ubuntu-release- New: accepted rustc [arm64] (cosmic-proposed) [1.26.0+dfsg0+llvm-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted rustc [i386] (cosmic-proposed) [1.26.0+dfsg0+llvm-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted rustc [s390x] (cosmic-proposed) [1.26.0+dfsg0+llvm-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted fasta3 [i386] (cosmic-proposed) [36.3.8g-1]
-queuebot:#ubuntu-release- New: accepted kicad-templates [amd64] (cosmic-proposed) [5.0.0~rc1-2]
-queuebot:#ubuntu-release- New: accepted libgit2 [i386] (cosmic-proposed) [0.27.0+dfsg.1-0.4]
-queuebot:#ubuntu-release- New: accepted nagios4 [i386] (cosmic-proposed) [4.3.4-2]
-queuebot:#ubuntu-release- New: accepted rustc [ppc64el] (cosmic-proposed) [1.26.0+dfsg0+llvm-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted kicad-packages3d [amd64] (cosmic-proposed) [5.0.0~rc2-2]
-queuebot:#ubuntu-release- New: accepted libgit2 [s390x] (cosmic-proposed) [0.27.0+dfsg.1-0.4]
-queuebot:#ubuntu-release- New: accepted libgit2 [arm64] (cosmic-proposed) [0.27.0+dfsg.1-0.4]
-queuebot:#ubuntu-release- New: accepted rustc [armhf] (cosmic-proposed) [1.26.0+dfsg0+llvm-0ubuntu2]
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (xenial-proposed/universe) [4.13.0-1030.33] (kernel)
<apw> ^ please could we leave that there, i need it for testing
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (xenial-proposed) [4.13.0-1030.33]
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (bionic-proposed) [2.20.9-0ubuntu7.2]
-queuebot:#ubuntu-release- Unapproved: rejected pollinate [source] (bionic-proposed) [4.33-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: nova-lxd (xenial-proposed/main) [13.3.0-0ubuntu1 => 13.3.0-0ubuntu2] (ubuntu-server)
<ginggs> if you see 'dh: Unknown sequence /usr/share/dh-r/r-cran.mk' in the build log of an R package FTBFS, it means it needs the new dh-r, which in turn needs debhelper 11.3
-queuebot:#ubuntu-release- New binary: reparser [ppc64el] (cosmic-proposed/none) [1.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gloox [s390x] (cosmic-proposed/universe) [1.0.20-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gloox [amd64] (cosmic-proposed/universe) [1.0.20-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gloox [ppc64el] (cosmic-proposed/universe) [1.0.20-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libfabric [amd64] (cosmic-proposed/universe) [1.6.1-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: gloox [i386] (cosmic-proposed/universe) [1.0.20-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-git-lfs-go-netrc [amd64] (cosmic-proposed/universe) [0.0~git20180525.e0e9ca4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-glycerine-go-unsnap-stream [amd64] (cosmic-proposed/universe) [0.0~git20180323.9f0cb55-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-jedisct1-go-dnsstamps [amd64] (cosmic-proposed/universe) [0.0~git20180418.1e49992-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-aplpack [amd64] (cosmic-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-google-uuid [amd64] (cosmic-proposed/universe) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-jsternberg-zap-logfmt [amd64] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gloox [armhf] (cosmic-proposed/universe) [1.0.20-2] (no packageset)
-queuebot:#ubuntu-release- New binary: reparser [i386] (cosmic-proposed/universe) [1.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-xlab-treeprint [amd64] (cosmic-proposed/universe) [0.0~git20180324.505f0ee-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-gomodule-redigo [amd64] (cosmic-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: reparser [s390x] (cosmic-proposed/universe) [1.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: readlike [amd64] (cosmic-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-mssola-user-agent [amd64] (cosmic-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: seqmagick [amd64] (cosmic-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: reparser [amd64] (cosmic-proposed/universe) [1.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: reparser [armhf] (cosmic-proposed/universe) [1.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: reparser [arm64] (cosmic-proposed/universe) [1.4.3-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (bionic-proposed) [1:18.04.11.1]
-queuebot:#ubuntu-release- New binary: gloox [arm64] (cosmic-proposed/universe) [1.0.20-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted gloox [amd64] (cosmic-proposed) [1.0.20-2]
-queuebot:#ubuntu-release- New: accepted gloox [armhf] (cosmic-proposed) [1.0.20-2]
-queuebot:#ubuntu-release- New: accepted gloox [ppc64el] (cosmic-proposed) [1.0.20-2]
-queuebot:#ubuntu-release- New: accepted gloox [arm64] (cosmic-proposed) [1.0.20-2]
-queuebot:#ubuntu-release- New: accepted gloox [s390x] (cosmic-proposed) [1.0.20-2]
-queuebot:#ubuntu-release- New: accepted gloox [i386] (cosmic-proposed) [1.0.20-2]
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (bionic-proposed) [1.0.95ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (artful-proposed) [1.0.91ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (xenial-proposed) [1.0.78+nmu1ubuntu1.6]
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (trusty-proposed) [1.0.59ubuntu0.10]
-queuebot:#ubuntu-release- Unapproved: kdeconnect (bionic-proposed/universe) [1.3.0-0ubuntu1 => 1.3.1-0ubuntu0.1] (kubuntu)
<slangasek> infinity, stgraber: intersection of the TB discussion of discontinued flavors, and the seed migrations to git: edubuntu-meta is still in cosmic but the last update was in bionic and you cut them off from update-seeds in artful.  How do you think this should be handled?  Should the edubuntu-meta package be dropped from cosmic, or is it still being used?
-queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (bionic-proposed) [1:3.28.1-0ubuntu1.18.04.1]
-queuebot:#ubuntu-release- Unapproved: heat (xenial-proposed/main) [1:6.1.2-0ubuntu1 => 1:6.1.2-0ubuntu1.1] (openstack, ubuntu-server)
<stgraber> slangasek: should be dropped
<slangasek> stgraber: ok.  do you want to open a bug against the package for audit purposes, or shall I just drop it?
<stgraber> slangasek: 1774473
<slangasek> stgraber: ta
<juliank> bdmurray: feel free to reject the networkd-dispatcher SRU, it will need changes anyway I think
<juliank> Laney: I think we found the culprit of why environment vars where not updated in cosmic - the fix for 1772137 caused an ordering cycle in systemd, causing cloud-init to not be run
<juliank> so it should go back to normal once -0ubuntu5 goes to release
-queuebot:#ubuntu-release- Unapproved: cups-pk-helper (bionic-proposed/main) [0.2.6-1ubuntu1 => 0.2.6-1ubuntu1.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New sync: linux-signed-azure-edge (xenial-proposed/primary) [4.15.0-1012.12~16.04.2]
-queuebot:#ubuntu-release- Unapproved: rejected networkd-dispatcher [source] (bionic-proposed) [1.7-0ubuntu3.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure-edge [sync] (xenial-proposed) [4.15.0-1012.12~16.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted landscape-client [source] (bionic-proposed) [18.01-0ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-initial-setup [source] (bionic-proposed) [3.28.0-2ubuntu6.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (bionic-proposed) [1:18.04.19]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-split [source] (bionic-proposed) [1.2-2build0.1]
-queuebot:#ubuntu-release- New binary: linux-signed-azure-edge [amd64] (xenial-proposed/universe) [4.15.0-1012.12~16.04.2] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure-edge [amd64] (xenial-proposed) [4.15.0-1012.12~16.04.2]
-queuebot:#ubuntu-release- New binary: deal.ii [s390x] (cosmic-proposed/universe) [9.0.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted nova-lxd [source] (xenial-proposed) [13.3.0-0ubuntu2]
#ubuntu-release 2018-06-01
-queuebot:#ubuntu-release- New binary: otb [s390x] (cosmic-proposed/universe) [6.6.0~rc1+dfsg-1~exp1] (no packageset)
-queuebot:#ubuntu-release- New binary: deal.ii [arm64] (cosmic-proposed/universe) [9.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: otb [ppc64el] (cosmic-proposed/universe) [6.6.0~rc1+dfsg-1~exp1] (no packageset)
-queuebot:#ubuntu-release- New binary: otb [amd64] (cosmic-proposed/universe) [6.6.0~rc1+dfsg-1~exp1] (no packageset)
<slangasek> autopkgtests currently down; rabbitmq is offline
<slangasek> (had died with an OOM)
<slangasek> Laney, juliank: ^^ the juju state looks unpleasant; lots of failed hooks
<slangasek> rabbitmq restarted
-queuebot:#ubuntu-release- New binary: otb [armhf] (cosmic-proposed/universe) [6.6.0~rc1+dfsg-1~exp1] (no packageset)
-queuebot:#ubuntu-release- New binary: otb [arm64] (cosmic-proposed/universe) [6.6.0~rc1+dfsg-1~exp1] (no packageset)
-queuebot:#ubuntu-release- New binary: otb [i386] (cosmic-proposed/universe) [6.6.0~rc1+dfsg-1~exp1] (no packageset)
-queuebot:#ubuntu-release- New: accepted otb [amd64] (cosmic-proposed) [6.6.0~rc1+dfsg-1~exp1]
-queuebot:#ubuntu-release- New: accepted otb [armhf] (cosmic-proposed) [6.6.0~rc1+dfsg-1~exp1]
-queuebot:#ubuntu-release- New: accepted otb [arm64] (cosmic-proposed) [6.6.0~rc1+dfsg-1~exp1]
-queuebot:#ubuntu-release- New: accepted otb [i386] (cosmic-proposed) [6.6.0~rc1+dfsg-1~exp1]
-queuebot:#ubuntu-release- New: accepted deal.ii [arm64] (cosmic-proposed) [9.0.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-git-lfs-go-netrc [amd64] (cosmic-proposed) [0.0~git20180525.e0e9ca4-1]
-queuebot:#ubuntu-release- New: accepted golang-github-gomodule-redigo [amd64] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-jedisct1-go-dnsstamps [amd64] (cosmic-proposed) [0.0~git20180418.1e49992-1]
-queuebot:#ubuntu-release- New: accepted golang-github-mssola-user-agent [amd64] (cosmic-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted libfabric [amd64] (cosmic-proposed) [1.6.1-1]
-queuebot:#ubuntu-release- New: accepted otb [s390x] (cosmic-proposed) [6.6.0~rc1+dfsg-1~exp1]
-queuebot:#ubuntu-release- New: accepted readlike [amd64] (cosmic-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted reparser [arm64] (cosmic-proposed) [1.4.3-1]
-queuebot:#ubuntu-release- New: accepted reparser [i386] (cosmic-proposed) [1.4.3-1]
-queuebot:#ubuntu-release- New: accepted deal.ii [s390x] (cosmic-proposed) [9.0.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-google-uuid [amd64] (cosmic-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted golang-github-xlab-treeprint [amd64] (cosmic-proposed) [0.0~git20180324.505f0ee-1]
-queuebot:#ubuntu-release- New: accepted r-cran-aplpack [amd64] (cosmic-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted reparser [armhf] (cosmic-proposed) [1.4.3-1]
-queuebot:#ubuntu-release- New: accepted reparser [s390x] (cosmic-proposed) [1.4.3-1]
-queuebot:#ubuntu-release- New: accepted golang-github-glycerine-go-unsnap-stream [amd64] (cosmic-proposed) [0.0~git20180323.9f0cb55-1]
-queuebot:#ubuntu-release- New: accepted otb [ppc64el] (cosmic-proposed) [6.6.0~rc1+dfsg-1~exp1]
-queuebot:#ubuntu-release- New: accepted reparser [ppc64el] (cosmic-proposed) [1.4.3-1]
-queuebot:#ubuntu-release- New: accepted golang-github-jsternberg-zap-logfmt [amd64] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted seqmagick [amd64] (cosmic-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted reparser [amd64] (cosmic-proposed) [1.4.3-1]
-queuebot:#ubuntu-release- New binary: libtoxcore [ppc64el] (cosmic-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtoxcore [s390x] (cosmic-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtoxcore [amd64] (cosmic-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtoxcore [i386] (cosmic-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtoxcore [arm64] (cosmic-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtoxcore [armhf] (cosmic-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libtoxcore [amd64] (cosmic-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted libtoxcore [armhf] (cosmic-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted libtoxcore [ppc64el] (cosmic-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted libtoxcore [arm64] (cosmic-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted libtoxcore [s390x] (cosmic-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted libtoxcore [i386] (cosmic-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New binary: golang-github-roaringbitmap-roaring [amd64] (cosmic-proposed/universe) [0.4.7-1] (no packageset)
 * apw pokes queuebot ...
-queuebot:#ubuntu-release- Unapproved: cockpit (bionic-backports/universe) [164-1 => 169-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cockpit (xenial-backports/universe) [164-1~ubuntu16.04.1 => 169-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (bionic-backports) [169-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (xenial-backports) [169-1~ubuntu16.04.1]
<Laney> slangasek: that's the third time this has happened :/
<Laney> juliank: thanks for figuring that out
<Laney> slangasek: juliank: sil2100 (although he's not here): don't suppose any of you want to look into this OOMing problem?
<Laney> I find it a bit disturbing that it didn't happen until relatively recently
<Laney> so maybe something changed that needs fixing, but maybe we also should look into that HA thing that I linked on the bug?
<Laney> and/or get a bigger instance for the rmq server maybe in the interim
<apw> or add some swap to it ?
<Laney> yeah maybe, it doesn't have any
<Laney> is that normal for cloud instances?
<apw> nope not common, but the kernel likes a little swap if it can get it, it lets it avoid ooming
<apw> in a number of cases
<Laney> if it's a leak this might just push the problem down the road a bit
<apw> indeed there is always that risk
-queuebot:#ubuntu-release- Unapproved: accepted cups-pk-helper [source] (bionic-proposed) [0.2.6-1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted kdeconnect [source] (bionic-proposed) [1.3.1-0ubuntu0.1]
<juliank> Laney: I did not figure it out, others noticed cloud-init not running on their systems
<Laney> juliank: oh ok, then lucky you :P
<juliank> yeah lucky me
<rbalint> tjaalton, i just marked LP: #1770650 as verification-done for xenial and artful, could you please release the package even though it is Friday? I'll be available tomorrow if there is any need to address issues
<ubot5> Launchpad bug 1770650 in gce-compute-image-packages (Ubuntu Artful) "Update google compute-image-packages to 20180510" [Undecided,Fix committed] https://launchpad.net/bugs/1770650
<apw> rbalint, did you get that released ?
<rbalint> apw, not yet, and now i only pinged people here :-)
<apw> rbalint, then if you are available to check for issues with these then they could be released i guess
<rbalint> apw, as we discussed privately i'm ready to fix things tomorrow and i'd like to get the package released but i'd need others to accept any of my fixes as SRUs thus let's wait for slangasek a few hours with the xenial release
<apw> rbalint, ack
<tjaalton> rbalint: need my help still?
<rbalint> tjaalton, thanks, no apw helped me out
<tjaalton> okay
-queuebot:#ubuntu-release- New binary: r-cran-samr [arm64] (cosmic-proposed/universe) [2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-samr [armhf] (cosmic-proposed/universe) [2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-samr [amd64] (cosmic-proposed/universe) [2.0-1] (no packageset)
<doko> Laney: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/ppc64el/b/binutils/20180601_113820_3c854@/log.gz
<doko> hmm, that could be uninstallability of the cross compilers
<slangasek> Laney: third time over how long a period?
<Laney> slangasek: A few weeks. Let me see if the first occurence is in dmesg still
<slangasek> rbalint: friday SRU release> well the difficulty is I'm sure /I/ won't be around to help with any reverts; so who will you have from the SRU team to cover?
<Laney> slangasek: [Wed May  9 16:06:23 2018] Out of memory: Kill process 1408 (beam) score 215 or sacrifice child
<Laney> I thought the first time that it was because we'd filled the disk with old kernels, but clearly not; the second time I identified the OOM.
 * slangasek nods
<slangasek> maybe it's worth consulting either server team or IS; they may have experience fighting with rabbit
<Laney> yeah, but I was trying to palm it off to someone else :P
<Laney> we did get this:
<Laney> Start-Date: 2018-02-15  06:05:45
<Laney> Commandline: /usr/bin/unattended-upgrade
<Laney> Upgrade: erlang-public-key:amd64 (1:18.3-dfsg-1ubuntu3, 1:18.3-dfsg-1ubuntu3.1), [a bunch of other erlang stuff]
-queuebot:#ubuntu-release- New binary: r-cran-jsonld [amd64] (cosmic-proposed/universe) [2.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-loo [amd64] (cosmic-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-django-rest-hooks [amd64] (cosmic-proposed/universe) [1.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-django-rest-hooks [amd64] (cosmic-proposed) [1.5.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-loo [amd64] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-jsonld [amd64] (cosmic-proposed) [2.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-samr [amd64] (cosmic-proposed) [2.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-samr [armhf] (cosmic-proposed) [2.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-samr [s390x] (cosmic-proposed) [2.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-samr [arm64] (cosmic-proposed) [2.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-samr [ppc64el] (cosmic-proposed) [2.0-1]
-queuebot:#ubuntu-release- Unapproved: ebtables (artful-proposed/main) [2.0.10.4-3.5ubuntu2.17.10.1 => 2.0.10.4-3.5ubuntu2.17.10.2] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ebtables (bionic-proposed/main) [2.0.10.4-3.5ubuntu2.18.04.1 => 2.0.10.4-3.5ubuntu2.18.04.2] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ebtables (trusty-proposed/main) [2.0.10.4-3ubuntu1.14.04.2 => 2.0.10.4-3ubuntu1.14.04.3] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ebtables (xenial-proposed/main) [2.0.10.4-3.4ubuntu2.16.04.1 => 2.0.10.4-3.4ubuntu2.16.04.2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-pylxd (artful-proposed/main) [2.2.4-0ubuntu1 => 2.2.6-0ubuntu0.17.10.1] (ubuntu-server)
<tsimonq2> 7
<krytarik> :-8
<wxl> ::--9
<tsimonq2> :::---10
-queuebot:#ubuntu-release- New binary: synfig [amd64] (cosmic-proposed/universe) [1.2.1-0.1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: synfig [ppc64el] (cosmic-proposed/universe) [1.2.1-0.1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: synfig [i386] (cosmic-proposed/universe) [1.2.1-0.1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: synfig [arm64] (cosmic-proposed/universe) [1.2.1-0.1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: synfig [armhf] (cosmic-proposed/universe) [1.2.1-0.1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: libgctp [s390x] (cosmic-proposed/universe) [2.0.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libgctp [i386] (cosmic-proposed/universe) [2.0.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libgctp [ppc64el] (cosmic-proposed/universe) [2.0.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libgctp [arm64] (cosmic-proposed/universe) [2.0.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libgctp [amd64] (cosmic-proposed/universe) [2.0.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libgctp [armhf] (cosmic-proposed/universe) [2.0.0-3] (no packageset)
#ubuntu-release 2018-06-02
-queuebot:#ubuntu-release- New: accepted libgctp [amd64] (cosmic-proposed) [2.0.0-3]
-queuebot:#ubuntu-release- New: accepted libgctp [armhf] (cosmic-proposed) [2.0.0-3]
-queuebot:#ubuntu-release- New: accepted libgctp [ppc64el] (cosmic-proposed) [2.0.0-3]
-queuebot:#ubuntu-release- New: accepted synfig [amd64] (cosmic-proposed) [1.2.1-0.1]
-queuebot:#ubuntu-release- New: accepted synfig [armhf] (cosmic-proposed) [1.2.1-0.1]
-queuebot:#ubuntu-release- New: accepted synfig [ppc64el] (cosmic-proposed) [1.2.1-0.1]
-queuebot:#ubuntu-release- New: accepted libgctp [arm64] (cosmic-proposed) [2.0.0-3]
-queuebot:#ubuntu-release- New: accepted libgctp [s390x] (cosmic-proposed) [2.0.0-3]
-queuebot:#ubuntu-release- New: accepted synfig [i386] (cosmic-proposed) [1.2.1-0.1]
-queuebot:#ubuntu-release- New: accepted libgctp [i386] (cosmic-proposed) [2.0.0-3]
-queuebot:#ubuntu-release- New: accepted synfig [arm64] (cosmic-proposed) [1.2.1-0.1]
-queuebot:#ubuntu-release- New binary: gemmlowp [ppc64el] (cosmic-proposed/universe) [0.0~git20180416.38ebac7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gemmlowp [amd64] (cosmic-proposed/universe) [0.0~git20180416.38ebac7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gemmlowp [s390x] (cosmic-proposed/universe) [0.0~git20180416.38ebac7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gemmlowp [arm64] (cosmic-proposed/universe) [0.0~git20180416.38ebac7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cheetah [amd64] (cosmic-proposed/universe) [3.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: powerline [amd64] (cosmic-proposed/universe) [2.6-2] (no packageset)
#ubuntu-release 2018-06-03
-queuebot:#ubuntu-release- New binary: libfm-qt [s390x] (cosmic-proposed/universe) [0.13.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libfm-qt [amd64] (cosmic-proposed/universe) [0.13.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libfm-qt [ppc64el] (cosmic-proposed/universe) [0.13.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libfm-qt [arm64] (cosmic-proposed/universe) [0.13.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libfm-qt [armhf] (cosmic-proposed/universe) [0.13.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libfm-qt [i386] (cosmic-proposed/universe) [0.13.0-2] (no packageset)
<tsimonq2> cyphermox, slangasek: libfm-qt should be in the Lubuntu packageset ^^^ can a packageset update please be done for Cosmic with the current contents of the seed?
-queuebot:#ubuntu-release- New binary: gecode [s390x] (cosmic-proposed/universe) [6.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gecode [ppc64el] (cosmic-proposed/universe) [6.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gecode [i386] (cosmic-proposed/universe) [6.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gecode [amd64] (cosmic-proposed/universe) [6.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gecode [armhf] (cosmic-proposed/universe) [6.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gecode [arm64] (cosmic-proposed/universe) [6.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted cheetah [amd64] (cosmic-proposed) [3.1.0-1]
-queuebot:#ubuntu-release- New: accepted gecode [arm64] (cosmic-proposed) [6.0.1-1]
-queuebot:#ubuntu-release- New: accepted gecode [i386] (cosmic-proposed) [6.0.1-1]
-queuebot:#ubuntu-release- New: accepted gecode [s390x] (cosmic-proposed) [6.0.1-1]
-queuebot:#ubuntu-release- New: accepted libfm-qt [i386] (cosmic-proposed) [0.13.0-2]
-queuebot:#ubuntu-release- New: accepted gecode [amd64] (cosmic-proposed) [6.0.1-1]
-queuebot:#ubuntu-release- New: accepted gecode [ppc64el] (cosmic-proposed) [6.0.1-1]
-queuebot:#ubuntu-release- New: accepted gecode [armhf] (cosmic-proposed) [6.0.1-1]
-queuebot:#ubuntu-release- New: accepted libfm-qt [arm64] (cosmic-proposed) [0.13.0-2]
-queuebot:#ubuntu-release- New: accepted libfm-qt [amd64] (cosmic-proposed) [0.13.0-2]
-queuebot:#ubuntu-release- New: accepted libfm-qt [ppc64el] (cosmic-proposed) [0.13.0-2]
-queuebot:#ubuntu-release- New: accepted powerline [amd64] (cosmic-proposed) [2.6-2]
-queuebot:#ubuntu-release- New: accepted libfm-qt [armhf] (cosmic-proposed) [0.13.0-2]
-queuebot:#ubuntu-release- New: accepted libfm-qt [s390x] (cosmic-proposed) [0.13.0-2]
-queuebot:#ubuntu-release- New binary: r-cran-geometry [ppc64el] (cosmic-proposed/universe) [0.3-6+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-relsurv [ppc64el] (cosmic-proposed/universe) [2.1-2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-pki [ppc64el] (cosmic-proposed/universe) [0.1-5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: baresip [ppc64el] (cosmic-proposed/universe) [0.5.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-roxygen2 [ppc64el] (cosmic-proposed/universe) [6.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: baresip [s390x] (cosmic-proposed/universe) [0.5.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: baresip [amd64] (cosmic-proposed/universe) [0.5.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: baresip [i386] (cosmic-proposed/universe) [0.5.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: baresip [arm64] (cosmic-proposed/universe) [0.5.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-geometry [i386] (cosmic-proposed/universe) [0.3-6+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-relsurv [amd64] (cosmic-proposed/universe) [2.1-2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-brobdingnag [amd64] (cosmic-proposed/universe) [1.2-5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-pki [amd64] (cosmic-proposed/universe) [0.1-5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: baresip [armhf] (cosmic-proposed/universe) [0.5.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-pki [i386] (cosmic-proposed/universe) [0.1-5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: logzero [amd64] (cosmic-proposed/universe) [1.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-roxygen2 [amd64] (cosmic-proposed/universe) [6.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pytest-cython [amd64] (cosmic-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-geometry [s390x] (cosmic-proposed/universe) [0.3-6+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-geometry [amd64] (cosmic-proposed/universe) [0.3-6+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-roxygen2 [i386] (cosmic-proposed/universe) [6.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rstantools [amd64] (cosmic-proposed/universe) [1.5.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-pki [s390x] (cosmic-proposed/universe) [0.1-5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-relsurv [i386] (cosmic-proposed/universe) [2.1-2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-geometry [arm64] (cosmic-proposed/universe) [0.3-6+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-relsurv [s390x] (cosmic-proposed/universe) [2.1-2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-geometry [armhf] (cosmic-proposed/universe) [0.3-6+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-pki [arm64] (cosmic-proposed/universe) [0.1-5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-relsurv [arm64] (cosmic-proposed/universe) [2.1-2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-roxygen2 [s390x] (cosmic-proposed/universe) [6.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-pki [armhf] (cosmic-proposed/universe) [0.1-5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-relsurv [armhf] (cosmic-proposed/universe) [2.1-2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-roxygen2 [arm64] (cosmic-proposed/universe) [6.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-roxygen2 [armhf] (cosmic-proposed/universe) [6.0.1-1] (no packageset)
#ubuntu-release 2019-05-27
<koza> hey, i am debugging a snap build issue on arm64 vs amd64. there is liberror-perl package as a stage-packages dependency that fails to resolve on arm64 but is downloaded on amd64. it is arch all in the archive. could you help me understand what arch all means, i.e. can I safely assume that packages with arch=all will resolve on all supported architectures just fine?
<cjwatson> koza: Architecture: all means that the package is built on a single architecture but is then architecture-independent and published for all architectures.
<cjwatson> So in other words yes.
<koza> allright, so there should be no difference in how that package is handled across different architectures
<juliank> koza: No, there might very well be differences
<juliank> koza: The package is the same, but what it depends on might obviously be not Architecture: all
<juliank> I'm not sure if it's possible for an Architecture: all package that depends on let's say an Architecture: amd64 i386 package to migrate to release pocket
<juliank> But it's certainly possible that an Architecture: all package fails to install on one architecture, but isntalls fine on another.
<juliank> (but yes, usually they should work on all archs)
<koza> got it, thanks. i am running further tests but fyi from report that I have recieved liberror-perl fails as a stage-package on arm64
<juliank> I mean, it probably shouldn't
 * juliank is kind of wondering if we should build a main-extra where we put in linux-image-unsigned and similar build artefacts not meant for users to install
<juliank> ooh, "build-only" might be a good name
<juliank> Laney, sil2100 do we know why unattended-upgrades 0.90 from releasee was triggered by apt and debconf, rather than the upload in security or updates?
<juliank> It picked the correct upload on May 6, but starting with debconf on May 8, it picked release pocket
<juliank> s/know/have an idea/
<juliank> Get:1 http://ftpmaster.internal/ubuntu xenial/main ppc64el unattended-upgrades all 0.90 [31.6 kB]
<juliank> Get:8 http://ftpmaster.internal/ubuntu xenial-updates/main ppc64el libarchive-zip-perl all 1.56-2ubuntu0.1 [84.7 kB]
<juliank> so, um, it's picking up some stuff from updates, just not u-u
<sil2100> hm hmm
<sil2100> THis is indeed very weird
<seb128> sil2100, could you SRU review epiphany-browser/disco? it's just a standard GNOME stable update, should be easy. upstream is unhappy about us being outdated and even blogged about it so I would like to show them some movement from us today :)
<sil2100> seb128: ACK, will do in a minute ;)
<seb128> sil2100, thx!
<Odd_Bloke> sil2100: infinity: Hello SRU vanguards, we've completed validation of the latest cloud-init SRU (in https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1828637) and it's now ready for release; could one of you take a look?  Thanks!
<ubot5> Launchpad bug 1828637 in cloud-init (Ubuntu Disco) "sru cloud-init (18.5-45 to 19.1.1) Xenial, Bionic, Cosmic, Disco" [Undecided,Fix committed]
<LocutusOfBorg> (if anybody cares, I would like to discuss debhelper 12 SRU in #-devel channel)
<sil2100> Odd_Bloke: on it in a moment as well
<Odd_Bloke> sil2100: Thanks!
<juliank> sil2100, infinity: small single word (+automated mirror list update) python-apt SRU regression fix in xenial
<juliank> * in xenial-proposed
<sil2100> juliank: on it in a minute o/
<juliank> thanks si
<juliank> That was supposed to say "thanks sil2100", but he's gonme
#ubuntu-release 2019-05-28
<xnox> tjaalton:  Laney: i have no idea! also weird! and thank you for the reject.
<xnox> will re-upload.
<juliank> Laney, sil2100 Seems we're still hitting the issue where autopkgtest installs unattended-upgrades from release rather than updates.
<juliank> It triggered 0.90 for python-apt/1.1.0~beta1ubuntu0.16.04.5
<juliank> last known good was May 6; python-apt/1.1.0~beta1ubuntu0.16.04.4 triggering 1.1ubuntu1.18.04.7~16.04.2
<juliank> rbalint: ^
<Laney> juliank: sorry, what is the problem in more detail?
<juliank> Laney: unattended-upgrades in xenial is 0.90, xenial-updates has  1.1ubuntu1.18.04.7~16.04.3
<juliank> Laney: All new tests are triggering 0.90
<juliank> That makes no sense, as it does not happen for other stuff
<juliank> AFAICT
<juliank> even security has 0.90ubuntu0.10
<juliank> autopkgtest [17:04:49]: @@@@@@@@@@@@@@@@@@@@ apt-source unattended-upgrades
<juliank> Get:1 http://ftpmaster.internal/ubuntu xenial/main unattended-upgrades 0.90 (dsc) [1,766 B]
<juliank> like, this should already be pulling from -updates
<Laney> yeah OK, and there is other stuff being fetched from -updates in there
<juliank> Hang on a sec
<juliank> cjwatson: xenial-updates is broken
<juliank> cjwatson: Packages that should be in there are not
<juliank> Laney: Do we have -security disabled on autopkgtest?
<juliank> That + broken -updates pocket would explain why it fetches from release
<juliank> cjwatson: So, rmadison unattended-upgrades:  unattended-upgrades | 1.1ubuntu1.18.04.7~16.04.3 | xenial-updates   | source
<juliank> no binary in archive
<juliank> Seems like we probably have more issues with apt-ftparchvie than we realized, and need to regenerate all the dbs
<juliank> as that's across all architectures
<Laney> https://launchpad.net/ubuntu/xenial/amd64/unattended-upgrades/
<juliank> Huh
<juliank> hmm
<Laney> not sure re: security, that's not my intention but it could be
<juliank> rbalint: the unattended-upgrades binary in xenial-updates was removed on may 7th
<juliank> um may 8th
<juliank> Laney: But do we know why it was removed, or who removed it?
<apw> Laney, its not showing removed in the primary publishing list
<juliank> Laney: Log says it superseded itself?
<juliank> This is very odd
<Laney> sorry, I can't decipher all of this stuff
<juliank> apw: only binary was removed, not source
<apw> but only the source is published
<Laney> there is a bug where binaries eat themselves if something is copied twice in the same publisher run, not sure if that manifests itself in the publishing history like this
<juliank> apw: Can you fix that up and like copy back the binary into updates?
<Laney> copy-package --from=ubuntu --from-suite=xenial-updates --to=ubuntu --to-suite=xenial-updates --version=1.1ubuntu1.18.04.7~16.04.3 --include-binaries --force-same-destination unattended-upgrades
<apw> Laney, yeah, that could be, i think a copy over self is worth a try here and let cj-watson et al work out if there are any others
<Laney> probably something like that would recover it
 * apw will give it a go
<juliank> thanks Laney, apw
<juliank> Makes me wonder how we can ensure this does not happen again
<Laney> if it's that LP bug then it's well known
<juliank> or well, a better way to discover it
<apw> normally when these things are suspected log magic is applied
<juliank> I guess I could write a cron job that goes through -updates and looks for missing builds
<juliank> run that once a day and have it send an email
<juliank> s/missing builds/built packages missing/
<apw> juliank, perhaps, or i wonder if teh superceeded by self is an indicator here
<Laney> juliank: as for missing -security, it's probably https://salsa.debian.org/ci-team/autopkgtest/blob/master/setup-commands/setup-testbed#L141
<juliank> ack
<apw> juliank, or actually the 'latest' status being superceeded which seems impossible in and of itself
<juliank> apw: Yeah, that makes sense I guess. I guess with access to the database, it should be easy to write up a report for all binaries whose latest state is superseded
<juliank> but it's probably hilariously slow as I guess there's no index on the status field :)
<apw> i suspect it can be done via the api all be it slowly
<juliank> Well, one query per binary is a ton of queries
<juliank> but I guess it's only problematic on the first run
<juliank> like we can cache status for a random time so we re-check versions we've seen before eventually but not all the time
<apw> juliank, you can get all binaries together for a source, and in the right order that the first should always be published or deleted i believe
<apw> (well or pending, or no records all being good in this context)
<juliank> I wonder if it's faster to just load Sources and Packages files and then look if a given source package has binaries in the Packages file. The only API calls we then need are "which architectures did this build on?"
<juliank> and we can indefinitely cache those API calls
<cjwatson> I'll look after meetings
<cjwatson> no index on the status field> what planet do you think we live on
<apw> the publisher presumably uses that field rather heavily
<juliank> ok
<juliank> hey, I was just guessing, I don't have a launchpad checkout handy
<juliank> Oh, I do have one
<juliank> silly me
<juliank> I should continue my Valid-Until branch
<cjwatson> Looks like phased updates ate it in this case
<apw> juliank, ok the re-copy has published; so the binaries ought to be back
<juliank> $ curl -s http://archive.ubuntu.com/ubuntu/dists/xenial-updates/main/binary-amd64/Packages.xz | xzcat  | grep-dctrl -P unattended-upgrades | wc -l
<juliank> 0
<juliank> unattended-upgrades | 1.1ubuntu1.18.04.7~16.04.3 | xenial-updates   | source
<juliank> rmadison and archive.u.c don't know about it yet
<cjwatson> Packages/Sources queries will be fatally flawed because deliberate removals are sometimes a thing
<apw> cjwatson, removals would express as deleted though right?  and this was expressing as Superceeded
<juliank> cjwatson: Oh right, I was thinking if we remove the SRU, we'd copy back the security one; but I'm not sure we do, and there's not always one available.
<cjwatson> Superseded
<cjwatson> please
<cjwatson> apw: Right, but that distinction does not show up in Packages/Sources files which is what juliank was talking about querying in isolation
<juliank> apw: Yes, but you don't see that in Packages files, which I was considering as a faster alternative to API calls
<apw> juliank, ahh but might it give you a subset to then check via the api
<cjwatson> juliank: I don't know why you would consider this problem for <stable>-updates and nowhere else
<juliank> cjwatson: Oh, I do consider it a problem elsewhere, but that's harder to solve efficiently
<cjwatson> And anyway I'm not talking about removing the entire source, but about removing individual binaries from it, which happens
<juliank> So yeah, I guess we do need to check the launchpad status
<juliank> * publisher status
<apw> cjwatson, in this case the binary itself was showing superseded
<cjwatson> Yes, I know
 * apw shuts up :)
<cjwatson> I'm saying that you can't spot the vanished-binary problem just from published indexes, because individual binaries from a source can be deliberately deleted
<cjwatson> (And it would be incorrect to make the assumption that *all* binaries from a given source vanish when this bug is triggered)
<juliank> So should we wait more or is it safe to conclude that copying it back did not work?
<cjwatson> I'm afraid grepping logs in this case is not going to be useful, because it was a double-override and overrides aren't well-logged
<cjwatson> juliank: copying works
<cjwatson> You can see it in https://launchpad.net/ubuntu/xenial/amd64/unattended-upgrades
<apw> juliank, the launchpad side says it is back
<juliank> I see it there, sure, I'm just waiting for it to be back in rmadison :)
<cjwatson> Publishing is not terribly instant
<cjwatson> It'll get there
 * juliank adds a watch -n60
<juliank> Gotta retry some autopkgtests once it's there :)
<cjwatson> apw: Superseded-by-self is valid because that's how overrides work
<apw> cjwatson, would there then not be a further Pending/Published record after ?
<cjwatson> Sure, but that's harder to check :)
<cjwatson> If we can work out the correct logic then we might just as well fix the actual dominator bug rather than writing complicated workaround monitoring scripts
<juliank> it has arrived :)
<apw> i think i just had unattended-upgrades try and upgrade itself; and it did not go well
 * cjwatson tries to understand the dominator
<cjwatson> It looks correct ...
<cjwatson> I guess I could try setting up a matching situation in the test suite though
<LocutusOfBorg> anybody, please hit gazebo! autopkgtest for gazebo/9.6.0-1build1: amd64: Pass, arm64: Regression â» , armhf: Regression â» , i386: Pass, ppc64el: Regression â» , s390x: Always failed
<LocutusOfBorg> it fails on arm64, armhf, ppc64el because the binary doesn't exist there anymore...
<LocutusOfBorg> (and it won't exist for long time, hopefully never)
<cjwatson> Oh
<cjwatson> Is it that easy
<LocutusOfBorg> isn't it?
<cjwatson> I mean the double-override bug
<apw> cjwatson, oh cornered it by accident ?
<cjwatson> Well not so much by accident, I was aiming at it
<cjwatson> But it actually looks quite easy now that I've narrowed it down
<cjwatson> I'll run some more tests though
 * apw hands cjwatson a snap-trap ...
<cjwatson> We've only ever seen this on arch: all binaries, right?
<cjwatson> Those are all the examples I can find in remotely-recent IRC history, at least
<apw> cjwatson, i don't think i remember in enough detail
<LocutusOfBorg> oh... it wasn't an answer to me lol, I just figured it out
<cjwatson> Yeah, sorry, overlapping conversations
<LocutusOfBorg> its me being sorry, I thought the conversation was over, after some minutes of idling :)
<LocutusOfBorg> force-badtest gazebo/all/arm64 gazebo/all/armhf gazebo/all/ppc64el <-- please because NBS there
<bdmurray> cpaelzer: bug 1819207 is in the Launchpad-Bugs-Fixed for open-vm-tools in the cosmic unapproved queue so that bug will get modified. Is that what you want?
<ubot5> bug 1819207 in ubuntu-drivers-common (Ubuntu Disco) "[FFe] Add Modaliases to open-vm-tools-desktop to allow automatic installation by ubuntu-drivers" [High,Fix released] https://launchpad.net/bugs/1819207
<bdmurray> tsimonq2: Can you add ubuntu package tasks and test cases for bug 1530697, bug 1744861, bug 1789059, bug 1805559
<ubot5> bug 1530697 in Mixxx "qt5: GLSL renderers draw signal at wrong scale and position" [Medium,Fix released] https://launchpad.net/bugs/1530697
<ubot5> bug 1744861 in Mixxx "skin does not scale for high resolution screens with Qt5" [Critical,Fix released] https://launchpad.net/bugs/1744861
<ubot5> bug 1789059 in Mixxx "continual GUI freeze" [Critical,Fix released] https://launchpad.net/bugs/1789059
<ubot5> bug 1805559 in Mixxx "Xlib deadlock in GUI thread" [Critical,Fix released] https://launchpad.net/bugs/1805559
<vorlon> Laney: nothing's been done that would turn off updating of autopkgtest indices for trusty, has it?  I was looking for new test results on http://autopkgtest.ubuntu.com/packages/l/lxc/trusty/ppc64el and http://autopkgtest.ubuntu.com/packages/g/glib-networking/trusty/ppc64el (et al) to see what gnutls26's state actually is
<vorlon> and the test results haven't shown
<Trevinho> hey, bdmurray could you have a look at the mutter/gnome-shell SRU, as it's waiting for some weeks now (as previous package was there before than the re-upload). Thanks :)
<bdmurray> Trevinho: For what release?
<Trevinho> bionic
<bdmurray> I'll have a look
<bdmurray> Trevinho: bug 1827029 is missing mutter tasks
<ubot5> bug 1827029 in gnome-shell (Ubuntu Cosmic) "Extended characters in OSK don't get entered" [Medium,In progress] https://launchpad.net/bugs/1827029
<Trevinho> bdmurray: fixed
<Trevinho> and thanks for looking into this
<bdmurray> Trevinho: was d/p/clutter-Smooth-out-master-clock-to-smooth-visuals.patch superseded by daniel's other changes?
<Trevinho> bdmurray: yes
<Trevinho> bdmurray: here's the rationale https://git.launchpad.net/~3v1n0/ubuntu/+source/mutter/commit/?h=ubuntu/bionic&id=05baba0d0a78775f18d9e16e8f7d074bcbe86cf5
<bdmurray> Trevinho: also the NEWS file lists a fair number of changes were those part of 3.28.3+git20190124?
<Trevinho> bdmurray: yes, basically is almost the same. However since upstream did a new release, we decided to merge with it
<Trevinho> bdmurray: these are the changes from git version to 3.28.4 in mutter https://git.launchpad.net/~3v1n0/ubuntu/+source/mutter/commit/?h=ubuntu/bionic&id=becbb8ffd09d9fd6b1ee38505ad21560c5fdb226 and shell https://git.launchpad.net/~ubuntu-desktop/ubuntu/+source/gnome-shell/commit/?h=ubuntu/bionic&id=c04b315d13b603743f2ae84a009cc900568674ed
<Trevinho> as you can see, a part the autotools stuff there's not much change
#ubuntu-release 2019-05-29
<RAOF> GODDAMNIT EVOLUTION!
<RAOF> "The SRU team meating was 7 hours ago" is *not* a useful notification, damnit!
<Eickmeyer> O_O
<cpaelzer> bdmurray: it is no problem that the open-vm-tools component of the overall 1819207 will get notified
<cpaelzer> I can add tags accordingly if that helps SRU processing
<cpaelzer> bdmurray: done
<Laney> vorlon:
<Laney> ubuntu@juju-prod-ues-proposed-migration-machine-2:~$ echo $(distro-info --supported)
<Laney> xenial bionic cosmic disco eoan
<Laney> ubuntu@juju-prod-ues-proposed-migration-machine-2:~$ distro-info --supported --supported-esm
<Laney> ubuntu-distro-info: You have to select exactly one of --all, --devel, --latest, --lts, --stable, --supported, --supported-esm, --series, --unsupported.
<Laney> this seems like a bit of an annoying interface
<Laney> because --supported-esm contains things that are also in --supported, so we would have to de-duplicate
<Laney> vorlon: would you like to own fixing this? I think building new cloud images also uses distro-info --supported so that would need this treatment too
<Ukikie> Laney: I noticed that and worked around it with something like:
<Ukikie> dists=(precise $(ubuntu-distro-info --codename --supported-esm))
<Ukikie> for dist in $(ubuntu-distro-info --codename --supported);do
<Ukikie>    if [[ ! ${dists[@]} =~ $dist ]];then
<Ukikie>       dists+=($dist)
<Ukikie>    fi
<Ukikie> done
<Ukikie> Properly fixing it does seem like a nice idea. :)
<Laney> also you lose the ordering if you do something like that
<Laney> stgraber: queuebot looks to have gone away
<Laney> jamespage: re the smartmontools backport, we'd need it for disco/cosmic too to maintain an upgrade path
<Laney> you're lucky, I don't normally check the upload queue for backports but I was looking at one for Unit193 ;-)
<stgraber> Will kick queuebot
-queuebot:#ubuntu-release- Unapproved: python-tornado (bionic-proposed/universe) [4.5.3-1 => 4.5.3-1ubuntu0.1] (ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: openssl (disco-proposed/main) [1.1.1b-1ubuntu2 => 1.1.1b-1ubuntu2.1] (core)
<xnox> Laney:  tjaalton: 3rd time lucky openssl for disco ^ looks like it's for the right pocket now.
<Laney> :>
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.38 => 2.39.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (bionic-proposed/main) [2.38+18.04 => 2.39.1+18.04] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (disco-proposed/main) [2.38+19.04 => 2.39.1+19.04] (core)
-queuebot:#ubuntu-release- Unapproved: snapd (cosmic-proposed/main) [2.38+18.10 => 2.39.1+18.10] (desktop-core, ubuntu-server)
<coreycb> rbasak: hello, if you have a chance in your sru rota today we'd like to see if we can get python-glance-store released to cosmic-updates
-queuebot:#ubuntu-release- Unapproved: gnome-control-center (disco-proposed/main) [1:3.32.1-1ubuntu4.1 => 1:3.32.2-0ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- New binary: ceph [arm64] (eoan-proposed/main) [14.2.1-0ubuntu1] (desktop-core, ubuntu-server)
<jamespage> Laney: ack - let me sort that out
<Laney> thankee
-queuebot:#ubuntu-release- Unapproved: smartmontools (cosmic-backports/main) [6.5+svn4324-1 => 7.0-0ubuntu1~ubuntu18.10.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: smartmontools (disco-backports/main) [6.6-1 => 7.0-0ubuntu1~ubuntu19.04.1] (ubuntu-server)
<jamespage> Laney: ^^ - tested via PPA builds here - https://launchpad.net/~james-page/+archive/ubuntu/train/+packages
<Laney> cool, thanks, will look in a bit
-queuebot:#ubuntu-release- Unapproved: libreoffice (disco-proposed/main) [1:6.2.3-0ubuntu0.19.04.1 => 1:6.2.4-0ubuntu0.19.04.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: libreoffice-l10n (disco-proposed/main) [1:6.2.3-0ubuntu0.19.04.1 => 1:6.2.4-0ubuntu0.19.04.1] (ubuntu-desktop)
<rbasak> coreycb: have you done a CI run against python-glance-store as well as having verified the individual fix? I don't see any CI report in the bug.
<coreycb> rbasak: i've not but we generally only run CI for stable point releases. i certainly can though.
-queuebot:#ubuntu-release- Unapproved: accepted smartmontools [source] (bionic-backports) [7.0-0ubuntu1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted smartmontools [source] (cosmic-backports) [7.0-0ubuntu1~ubuntu18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted smartmontools [source] (disco-backports) [7.0-0ubuntu1~ubuntu19.04.1]
<rbasak> coreycb: the bug description  said you'd run it! I don't mind how it's achieved but I'd prefer to have some confidence that the SRU doesn't break existing functionality, and CI seems like a good way to do that.
<rbasak> coreycb: especially if the bug being fixed is particularly targeted and so the test to verify the bug fix itself doesn't exercise much of the package, which I presume here it doesn't?
<coreycb> rbasak: it does appear to say that doesn't it :)
<coreycb> rbasak: we'll run it. sahid, would you mind running CI for python-glance-store that since you put it in the testing section?
<coreycb> rbasak: we are working toward having CI run regularly but not there yet
<rbasak> coreycb: thanks :)
<sahid> rbasak, coreycb: sure will do
<coreycb> sahid: thanks
<coreycb> sahid: thanks
<coreycb> sahid: lol sorry!
<sahid> :)
-queuebot:#ubuntu-release- Unapproved: gnome-control-center (bionic-proposed/main) [1:3.28.2-0ubuntu0.18.04.4 => 1:3.28.2-0ubuntu0.18.04.5] (ubuntu-desktop)
<vorlon> Laney: ack, I'll take a look at that (distro-info), the cpc team already had to deal with this on the cloud image building side
<Laney> vorlon: thanks. an interface in distro-info which lets us get the union of --supported and --supported-esm would seem quite nice to avoid having to perform contortions in multiple places...
<vorlon> bdmurray: ^^ thoughts on this?  I actually assumed distro-info --supported-esm would output those releases that are currently supported and have no separate esm data
<bdmurray> vorlon: Could you clarify what releases you would expect --supported-esm to return right now?
<vorlon> bdmurray: I was thinking trusty xenial bionic cosmic disco eoan; since they are all supported and some of them only if you have ESM.  Does that make sense, and am I contradicting myself vs our past discussion?
<vorlon> for example you currently list both xenial and bionic, which are supported today even if you don't have ESM
<bdmurray> vorlon: Hmm, well I was thinking --supported-esm should only list trusty
<vorlon> so I think it makes sense to also list the non-LTS releases, which don't declare a separate ESM EOL date and are supported
<vorlon> bdmurray: I'm inclined to think the common case, and the one we should therefore have as the interface is the tool, is "give me the list of all releases that are security supported, inclusive of ESM-only ones"
<bdmurray> vorlon: For some reason I'm not able to parse that, so --supported-esm would return what?
<vorlon> bdmurray: trusty xenial bionic cosmic disco eoan -- "I want the list of releases that are supported, inclusive of those you have to get ESM to have support on"
<bdmurray> vorlon: then you still have to diff --supported and --support-esm to get trusty
<vorlon> bdmurray: if what you want is to know what is currently only esm-supported, yes
<bdmurray> vorlon: and I thought that deduplication was Laney's issue
<Laney> No, that's what you'd have to do with the current interfaces
<Laney> To get the result that vorlon is saying that you should get out of the box
<vorlon> right, so cpc currently has to do: supported_suites=($((ubuntu-distro-info --supported-esm; ubuntu-distro-info --supported) | sort -u))
<Laney> yeah
<vorlon> and we would have to do something similar in autopkgtest
<Laney> and then you get the releases in a different order
<apw> why not allow both options to be specified together
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.47 => 2.408.48] (desktop-core)
<Eickmeyer> vorlon: Since you sponsored lsp-plugins, are you good with bringing it in from NEW?
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.48]
-queuebot:#ubuntu-release- Unapproved: accepted xorg-server-hwe-18.04 [source] (bionic-proposed) [2:1.20.4-1ubuntu3~18.04.1]
-queuebot:#ubuntu-release- Unapproved: systemd (disco-proposed/main) [240-6ubuntu5 => 240-6ubuntu5.1] (core)
-queuebot:#ubuntu-release- Unapproved: systemd (xenial-proposed/main) [229-4ubuntu21.21 => 229-4ubuntu21.22] (core)
<mwhudson> vorlon: could you release docker.io/containerd/runc for xenial please
<vorlon> looking
<mwhudson> vorlon: thanks
<vorlon> infinity: trusty-proposed wasn't zeroed out before ESM, and I noticed gnutls26 was blocked from publication only by autopkgtest failures, which I've now confirmed are non-regressions.  thoughts on what we should do with that?
-queuebot:#ubuntu-release- Unapproved: osgearth (trusty-updates/universe) [2.4.0+dfsg-6 => 2.4.0+dfsg-6] (no packageset) (sync)
#ubuntu-release 2019-05-30
-queuebot:#ubuntu-release- Unapproved: exim4 (disco-proposed/main) [4.92-4ubuntu1 => 4.92-4ubuntu1.1] (ubuntu-server)
<infinity> vorlon: Historically, we've never emptied proposed at EOL, we just snapshot it as "this is the way it was".  But ESM does make that a bit goofier, I guess.
<infinity> vorlon: No strong opinion either way.  We could publish it to -updates, we could binary copy it to ESM (and leave it in proposed)...
<infinity> vorlon: I'm even more confused about the seccomp that the security team uploaded (long) after ESMiness.
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-amdgpu-hwe-18.04 (bionic-proposed/main) [18.1.0-1~18.04.1 => 19.0.1-1~18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-nouveau-hwe-18.04 (bionic-proposed/main) [1:1.0.15-3~18.04.1 => 1:1.0.16-1~18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-ati-hwe-18.04 (bionic-proposed/main) [1:18.1.0-1~18.04.1 => 1:19.0.1-0ubuntu1~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-150.176] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-150.176]
<tjaalton> sil2100: is it your sru day? could you review libglvnd for bionic, it's been sitting on the queue for some weeks now
<tjaalton> oh hang on, it's in proposed
<tjaalton> huh, the upload never happened.. shame on me
-queuebot:#ubuntu-release- Unapproved: libglvnd (bionic-proposed/main) [1.0.0-2ubuntu2.2 => 1.0.0-2ubuntu2.3] (core)
<tjaalton> sil2100: nevermind :)
<Laney> :D
-queuebot:#ubuntu-release- Unapproved: cups (bionic-proposed/main) [2.2.7-1ubuntu2.5 => 2.2.7-1ubuntu2.6] (core)
<sil2100> ;)
<sil2100> tjaalton: I can try getting to it today, yes
-queuebot:#ubuntu-release- Unapproved: cups (disco-proposed/main) [2.2.10-4ubuntu1 => 2.2.10-4ubuntu2] (core)
<tjaalton> sil2100: i uploaded it *somewhere* earlier, since it had to be forced now
<tjaalton> sil2100: and thanks, if you do
-queuebot:#ubuntu-release- Unapproved: libpinyin (bionic-proposed/main) [2.1.91-1 => 2.2.2-1ubuntu0.18.04.1] (input-methods, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: ibus-libpinyin (bionic-proposed/main) [1.9.2-2 => 1.11.0-1ubuntu0.18.04.1] (input-methods, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (disco-proposed) [2.578.6]
-queuebot:#ubuntu-release- Unapproved: libpinyin (cosmic-proposed/main) [2.2.0-1 => 2.2.2-1ubuntu0.18.10.1] (input-methods, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: ibus-libpinyin (cosmic-proposed/main) [1.10.0-1 => 1.11.0-1ubuntu0.18.10.1] (input-methods, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted tracker-miners [source] (disco-proposed) [2.1.6-1ubuntu1~19.04]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (disco-proposed) [1:3.32.2-0ubuntu1]
<sil2100> marcustomlinson: hey! Is it intentional that the disco libreoffice SRU has an interim UNRELEASED version in the changelog?
<sil2100> I mean, it's probably not a blocking issue, but the changelog looks messy because of it
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1008.9] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1008.9]
<apw> sil2100, that is a very Debian thing to do, is it a Debian version in there ?
<sil2100> apw: it looks like it yes
-queuebot:#ubuntu-release- Unapproved: systemd (cosmic-proposed/main) [239-7ubuntu10.13 => 239-7ubuntu10.14] (core)
-queuebot:#ubuntu-release- Unapproved: ktouch (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu1.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu10.21 => 237-3ubuntu10.22] (core)
<sil2100> apw: I'll accept it in this case
-queuebot:#ubuntu-release- Unapproved: rejected biosdevname [source] (bionic-proposed) [0.4.1-0ubuntu10.1]
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (disco-proposed) [1:6.2.4-0ubuntu0.19.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice-l10n [source] (disco-proposed) [1:6.2.4-0ubuntu0.19.04.1]
<jdstrand> infinity (cc vorlon): libseccomp should be out of -proposed today. there was some question on snapd and trusty/esm which is why it is there in the first place, but that got answered yesterday
-queuebot:#ubuntu-release- Unapproved: cups (xenial-proposed/main) [2.1.3-4ubuntu0.8 => 2.1.3-4ubuntu0.9] (core)
-queuebot:#ubuntu-release- Unapproved: zfs-linux (bionic-proposed/main) [0.7.5-1ubuntu16.4 => 0.7.5-1ubuntu16.6] (core)
-queuebot:#ubuntu-release- Unapproved: libio-socket-ssl-perl (bionic-proposed/main) [2.056-1 => 2.060-3~ubuntu18.04.1] (core) (sync)
<infinity> jdstrand: But why was it there in the first place, that was the question.
-queuebot:#ubuntu-release- Unapproved: rejected osgearth [sync] (trusty-updates) [2.4.0+dfsg-6]
<sil2100> infinity: I think I heard jdstrand mentioning they put it there for it to get wider testing or something
-queuebot:#ubuntu-release- Unapproved: accepted libglvnd [source] (bionic-proposed) [1.0.0-2ubuntu2.3]
<vorlon> xnox: tweaked the test case for libwww-perl slightly on the openssl.l.l bug, to ensure we actually test the Breaks
<xnox> vorlon:  oooh, ok.
-queuebot:#ubuntu-release- Unapproved: accepted libwww-perl [sync] (bionic-proposed) [6.31-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted libio-socket-ssl-perl [sync] (bionic-proposed) [2.060-3~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted libpinyin [source] (cosmic-proposed) [2.2.2-1ubuntu0.18.10.1]
<vorlon> xnox: the patch against libnet-ssleay-perl patches the documentation to include statements that certain features are not available in this version of net-ssleay
<vorlon> xnox: do we care about the misleading docs? (or is there a fix-up patch I haven't gotten to yet in the review)
<xnox> vorlon:  i think some of those docs are not lies, as the missing bits got implemented in 1.88 only which is in eoan
<xnox> vorlon:  and i did not yet think about backporting that, or not.
<vorlon> xnox: ok
<vorlon> xnox: one of the patches added is to ignore unexpected SIGPIPE being raised during tests; have you considered whether this behavior change will raise unexpected SIGPIPE on real-world use cases and be a regression risk?
<xnox> vorlon:  as far as i recall, no. it was merged as test-suite flakiness rather than TLS1.3
<vorlon> xnox: ok; can you consider now whether there's regression risk there?
<vorlon> and would it be gauche for the perl library itself to ignore SIGPIPE
-queuebot:#ubuntu-release- Unapproved: libpinyin (cosmic-proposed/main) [2.2.0-1 => 2.2.2-1~ubuntu18.10.1] (input-methods, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: libpinyin (bionic-proposed/main) [2.1.91-1 => 2.2.2-1~ubuntu18.04.1] (input-methods, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rejected libpinyin [source] (bionic-proposed) [2.2.2-1ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted libpinyin [source] (cosmic-proposed) [2.2.2-1~ubuntu18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted libpinyin [source] (bionic-proposed) [2.2.2-1~ubuntu18.04.1]
<jdstrand> infinity: I put it there because snapd development encompasses more than just the deb and I a) thought it was going to be supported in sem and b) didn't think that the snapd team would be able to pull in the esm ppa in all the places it would need it (ie, travis, spread tests, what have you)
<vorlon> debian/patches/Move-SSL_ERROR_WANT_READ-SSL_ER
<vorlon> oops
<vorlon> xnox: debian/patches/Move-SSL_ERROR_WANT_READ-SSL_ERROR_WANT_WRITE-retry-.patch also looks like an interesting behavior change to the Net::SSLeay api, read/write change behavior to not retry?
<jdstrand> infinity: so if it was going to be supported I thought for this upload going to trusty-security might make it easier for them to transition to using esm in their project. as it turns out, as of right now, they aren't going to have snapd in esm, so I will push libseccomp to trusty/esm and delete from -proposed
<jdstrand> infinity: and I told them if the decision changes wrt snapd/trusty/esm, to come to us so we can work together on a plan for them building/testing/delivering snapd debs via esm
<jdstrand> infinity: as to why libseccomp is in any of -proposed, yes, sil2100 is right, we wanted wider testing. the non-trusty releases will go to -security
<jdstrand> I'm working to publish the USN for it today
-queuebot:#ubuntu-release- Unapproved: accepted ibus-libpinyin [source] (cosmic-proposed) [1.11.0-1ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted ibus-libpinyin [source] (bionic-proposed) [1.11.0-1ubuntu0.18.04.1]
<xnox> vorlon:  yes, which is now inline with what openssl told everyone to do.... also note that it's unusual to see those errors from openssl pre-tls1.3 as well.
<xnox> vorlon:  i wish i knew how much stuff uses perl for openssl. especially server side, rather than just client.
<xnox> however i hope that people normally have their webserver do tls for them
<vorlon> xnox: then I think this needs to be called out in the bug as regression potential and say that it's a risk of regression whose impact is currently unknown and we're willing to accept that risk
<vorlon> xnox: I'm unsure if the change in SIGPIPE behavior also has the potential to affect non-perl users of lissl
<vorlon> xnox: I've written up the regression potential for libnet-ssleay-perl and reading it does not give me warm fuzzies about accepting this package.  I think the API change to read/write/ssl_read_all/ssl_write_all should be reverted and the tests fixed otherwise
-queuebot:#ubuntu-release- Unapproved: cups (cosmic-proposed/main) [2.2.8-5ubuntu1.3 => 2.2.8-5ubuntu1.4] (core)
<vorlon> ubuntu-mate/daily-live: eoan-desktop-amd64.iso oversized by 61582336 bytes
<vorlon> that's a fair number of bytes
<vorlon> Wimpress: ^^ was that something you're still planning to slim down, or raise the limit on?
<Wimpress> vorlon: I did slim it down, considerably.
<Wimpress> But now I have added the nvidia drivers to the shipl-live seed.
<Wimpress> Which add ~115MB to the image.
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (disco-proposed/main) [2.578.4 => 2.578.5] (desktop-core)
<vorlon> rbasak: why do you say it was wrong to continue overriding the pcs autopkgtests which have always been garbage?
<vorlon> rbasak: (more precisely, they regressed when /etc/init.d/networking stopped being part of the system)
<xnox> vorlon:  shall we do a codesearch of users of read/write?
<vorlon> that wouldn't catch 3rd party software
<vorlon> xnox: wouldn't it be better to revert the api change, and fix whatever the other problem was with the tests?
<xnox> vorlon:  the other problem is that TLSv1.3 started to generate a lot more WANT_READ WANT_WRITE errors, and they were never been properly testing with TLSv1.2 as no renegotiation was done.
<xnox> and for people to install hooks they need access to a non-eating read/write......
<vorlon> xnox: so we can't sanely support TLSv1.3 from perl without changing the API?
<vorlon> OTOH
<vorlon> wouldn't it be better to not support TLS1.3 from perl than to break existing third-party code?
<xnox> vorlon:  i had an upload to cap context at tls1.2 and be done with it
<xnox> vorlon:  but that also means nobody gets tls1.3
<xnox> defeating a bit the point of this sru.....
<xnox> vorlon:  also 3rd party software in perl?!
<vorlon> xnox: I thought the point of sruing the perl bindings is to make sure updating openssl /didn't break the perl bindings/, not to enable TLSv1.3 support in perl
<vorlon> I would be happier with capping perl @ 1.2 than breaking the API
<xnox> vorlon:  https://paste.ubuntu.com/p/D76nnxWNnY/ is the patch i had around for while whilst the hang drama was ongoing
<xnox> it is unexpected behaviour. cause max_proto would be set
<xnox> but that only covers i think the CTX api only
<xnox> not the SSL api
<vorlon> xnox: if you wanted to do the work, I think we could in principle make read/write return short reads only for TLSv1.3; retain the existing behavior for earlier protocol versions; and cap to TLSv1.2 by default requiring someone to opt in from the perl code
<vorlon> but barring that, I would still rather cap to 1.2 now, avoid changing the api, and possibly deal with perl 1.3 support later in a separate SRU
<xnox> ok
<xnox> let me have a cup of tea
-queuebot:#ubuntu-release- Unapproved: libseccomp (disco-security/main) [2.4.1-0ubuntu0.19.04.3 => 2.4.1-0ubuntu0.19.04.3] (core) (sync)
<xnox> vorlon:  wait a minute.
-queuebot:#ubuntu-release- Unapproved: libseccomp (cosmic-security/main) [2.4.1-0ubuntu0.18.10.3 => 2.4.1-0ubuntu0.18.10.3] (core) (sync)
<xnox> vorlon:  "SSL_MODE_AUTO_RETRY has been made the default"
-queuebot:#ubuntu-release- Unapproved: libseccomp (bionic-security/main) [2.4.1-0ubuntu0.18.04.2 => 2.4.1-0ubuntu0.18.04.2] (core) (sync)
<xnox> https://wiki.openssl.org/index.php/TLS1.3#Non-application_data_records
<xnox> so ssl_read()/ssl_write() should be auto-consuming things anyway.......
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.48 => 2.408.49] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: libseccomp (xenial-security/main) [2.4.1-0ubuntu0.16.04.2 => 2.4.1-0ubuntu0.16.04.2] (core) (sync)
<vorlon> xnox: ah
<vorlon> xnox: in that case feel free to edit the regression-potential text back
-queuebot:#ubuntu-release- Unapproved: accepted libseccomp [sync] (disco-security) [2.4.1-0ubuntu0.19.04.3]
<xnox> vorlon:  but that also has the blocking/non-blocking sockets caveats.
-queuebot:#ubuntu-release- Unapproved: accepted libseccomp [sync] (bionic-security) [2.4.1-0ubuntu0.18.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted libseccomp [sync] (cosmic-security) [2.4.1-0ubuntu0.18.10.3]
<xnox> i think i want to double check with upstream on that.
-queuebot:#ubuntu-release- Unapproved: accepted libseccomp [sync] (xenial-security) [2.4.1-0ubuntu0.16.04.2]
<xnox> vorlon:  also upstream does cross-test a wide matrix of openssl releases, perl releases, and the perl library.
<xnox> they test like all the combinations possible back to forever, and multiple openssl versions & implementations
<vorlon> ok
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.49]
<Eickmeyer> Is there an AA that can process lsp-plugins in the NEW queue?
<Eickmeyer> Also, we (the Ubuntu Studio team) now have two packages that need sponsoring.  (bug 1829562 and bug 1831154)
<ubot5> bug 1829562 in Ubuntu Studio "[Needs Packaging] DPF-Plugins for Eoan" [Medium,In progress] https://launchpad.net/bugs/1829562
<ubot5> bug 1831154 in Ubuntu Studio Menu Add "[needs-packaging] ubuntustudio-menu-add" [Medium,In progress] https://launchpad.net/bugs/1831154
<Eickmeyer> Expect more new packages for Ubuntu Studio this cycle. We're WAY behind, and still playing catch-up after the two years of stagnation.
<rbasak> vorlon: the pcs autopkgtest might have been garbage before, and may well still be, but the failures in Disco for 0.10 AIUI was a true positive - it correctly failed due to an installability problem that correctly should have blocked proposed migration before it got any further (to something that may or may not be correct - I haven't looked)
<rbasak> vorlon: the errors changed.
<xnox> but we can't tell the difference between always failed, and always failed but differently now.
<xnox> unless there is uninstallability return codes that are returned back to britney? ie. "can't even install"
<rbasak> xnox: I was under the impression that the whole point of a versioned badtest was that there would be a manual check before bumping the version forward.
<rbasak> I suppose another reason is that if it starts magically working then it won't be ignored forever.
<rbasak> But if all we're doing is bumping it forward blindly if it is still failing, then what's the point of doing it manually like this?
<rbasak> Anyway, I need to go.
<rbasak> I'll check back later.
#ubuntu-release 2019-05-31
<acheronuk> Kubuntu iso build failed with:
<acheronuk> The following packages have unmet dependencies:
<acheronuk>  libio-socket-ssl-perl : Depends: libnet-ssleay-perl (>= 1.84-1ubuntu0.1) but 1.84-1build1 is to be installed
<acheronuk> that is bionic ^^
<acheronuk> xnox: ^
<acheronuk> from the control file: Depends: libnet-ssleay-perl (>= 1.84-1ubuntu0.1),
<acheronuk> sil2100: morning. FYI, xubuntu and kubuntu daily isos for bionic are failing today due to the libio-socket-ssl-perl SRU in bionic proposed having broken deps in its control file
<sil2100> acheronuk: ah, this one, I poked vorlon and xnox about it yesterday already, since it was basically causing FTBFS for another SRU I was driving
<sil2100> I hoped it would have been resolved somehow by today
<acheronuk> ok. as long as is on someone's radar, then good
<sil2100> acheronuk: ok, I actually see an upload that Steve didn't review yesterday, missing piece of the SRU puzzle
<acheronuk> sil2100: makes sense. I looked or something like that. maybe I looked in the wrong queue!
<sil2100> acheronuk: I totally missed it yesterday as well, since the upload was a bit old
<sil2100> So it was hidden in the older entries
-queuebot:#ubuntu-release- Unapproved: accepted libnet-ssleay-perl [source] (bionic-proposed) [1.84-1ubuntu0.1]
<acheronuk> sil2100: yeah, just found this from last night https://irclogs.ubuntu.com/2019/05/30/%23ubuntu-release.html#t14:58
<acheronuk> fort some reason my BNC backlog did not give me that :/
 * acheronuk kicks the KDE bnc
<sil2100> acheronuk: too bad Steve didn't include that analysis in the SRU bug
<sil2100> grrrr
<sil2100> xnox, vorlon: since I accepted the SRU that was in the queue, and seeing that I didn't have all the IRC-chat context, I'm now wondering if that was the right thing to do?
<sil2100> xnox, vorlon: when reviewing the package I just assumed, as per regression potential, that the behavioral change of read()/write() has been decided and accepted, but I see it is not quite
<sil2100> xnox, vorlon: maybe I did accept this package prematurely, but having a partial SRU and bionic-proposed broken was also not great
<sil2100> So it was either this or removing the SRU from the -proposed pocket
<sil2100> Just follow up with another upload to if this needs to be changed
-queuebot:#ubuntu-release- Unapproved: accepted openssl [source] (disco-proposed) [1.1.1b-1ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: xorg-server (bionic-proposed/main) [2:1.19.6-1ubuntu4.2 => 2:1.19.6-1ubuntu4.3] (desktop-core, xorg)
-queuebot:#ubuntu-release- Unapproved: sssd (bionic-proposed/main) [1.16.1-1ubuntu1.2 => 1.16.1-1ubuntu1.3] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: sssd (xenial-proposed/main) [1.13.4-1ubuntu1.14 => 1.13.4-1ubuntu1.15] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (disco-proposed) [240-6ubuntu5.1]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (cosmic-proposed) [239-7ubuntu10.14]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (bionic-proposed) [237-3ubuntu10.22]
-queuebot:#ubuntu-release- Unapproved: qtwebengine-opensource-src (bionic-proposed/universe) [5.9.5+dfsg-0ubuntu2 => 5.9.8+dfsg-0ubuntu1] (kubuntu)
<Eickmeyer> AAs: Ubuntu Studio now has two packages needing review: lsp-plugins, and ubuntustudio-look has a new binary called ubuntustudio-wallpapers-disco that is just moving the disco wallpapers to a new package in prep for new wallpapers on the way.
-queuebot:#ubuntu-release- Unapproved: glusterfs (bionic-proposed/universe) [3.13.2-1build1 => 3.13.2-1ubuntu1] (no packageset)
#ubuntu-release 2019-06-01
-queuebot:#ubuntu-release- Unapproved: libguestfs (disco-proposed/universe) [1:1.40.2-1ubuntu1 => 1:1.40.2-1ubuntu1.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libguestfs (cosmic-proposed/universe) [1:1.38.4-1ubuntu2 => 1:1.38.4-1ubuntu2.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libguestfs (bionic-proposed/universe) [1:1.36.13-1ubuntu3.2 => 1:1.36.13-1ubuntu3.3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: hw-detect (bionic-proposed/main) [1.117ubuntu6 => 1.117ubuntu6.18.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: hw-detect (disco-proposed/main) [1.117ubuntu6 => 1.117ubuntu6.19.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: hw-detect (cosmic-proposed/main) [1.117ubuntu6 => 1.117ubuntu6.18.10.1] (core)
-queuebot:#ubuntu-release- Unapproved: partman-iscsi (bionic-proposed/main) [40ubuntu3 => 40ubuntu3.18.04.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: partman-iscsi (disco-proposed/main) [40ubuntu3 => 40ubuntu3.19.04.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: partman-iscsi (cosmic-proposed/main) [40ubuntu3 => 40ubuntu3.18.10.1] (ubuntu-desktop, ubuntu-server)
#ubuntu-release 2019-06-02
-queuebot:#ubuntu-release- Unapproved: modem-manager-gui (bionic-proposed/universe) [0.0.19.1-1 => 0.0.19.1-1ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: modem-manager-gui (disco-proposed/universe) [0.0.19.1-1build1 => 0.0.19.1-1ubuntu0.19.04.1] (no packageset)
#ubuntu-release 2020-05-25
<vorlon> LocutusOfBorg: I only removed golang-go.net-dev.  golang-golang-x-net-dev binaries still show in the release pocket; and I didn't remove anything from -proposed
<vorlon> LocutusOfBorg: so upon closer look, the version of the golang-golang-x-net-dev binary package in the release pocket is newer than the source package version in -proposed, causing upload failures of the binary build.
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-102.103~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-102.103~16.04.1]
-queuebot:#ubuntu-release- New binary: gnuastro [s390x] (groovy-proposed/universe) [0.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnuastro [amd64] (groovy-proposed/universe) [0.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnuastro [armhf] (groovy-proposed/universe) [0.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnuastro [ppc64el] (groovy-proposed/universe) [0.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnuastro [arm64] (groovy-proposed/universe) [0.12-1] (no packageset)
<LocutusOfBorg> vorlon, yes, because your NBS-cleanup fixed another package, the "correct" one migration
<LocutusOfBorg> x-net-dev should probably die, and the binary is now owned by "golang-golang-x-net"
<LocutusOfBorg> if you want you can also remove the source package! its already gone from debian testing
<LocutusOfBorg> (oh you already did that)
<vorlon> LocutusOfBorg: right, I've removed golang-golang-x-net-dev source now, it was removed from unstable at the end of December but still shows up in the Debian indices because of Built-Using, thereby confusing remove-packages
<LocutusOfBorg> yay thanks
-queuebot:#ubuntu-release- Unapproved: gpsd (focal-proposed/main) [3.20-8ubuntu0.1 => 3.20-8ubuntu0.2] (kubuntu)
-queuebot:#ubuntu-release- New binary: gnuastro [riscv64] (groovy-proposed/universe) [0.12-1] (no packageset)
<xnox> vorlon:  re:policy enforcement, britney does not let things migrate main packages that declare Built-Using on things that are not in main.  So no /new/ things can migrate. I don't think.
-queuebot:#ubuntu-release- New: accepted gnuastro [amd64] (groovy-proposed) [0.12-1]
-queuebot:#ubuntu-release- New: accepted gnuastro [armhf] (groovy-proposed) [0.12-1]
-queuebot:#ubuntu-release- New: accepted gnuastro [riscv64] (groovy-proposed) [0.12-1]
-queuebot:#ubuntu-release- New: accepted gnuastro [arm64] (groovy-proposed) [0.12-1]
-queuebot:#ubuntu-release- New: accepted gnuastro [s390x] (groovy-proposed) [0.12-1]
-queuebot:#ubuntu-release- New: accepted gnuastro [ppc64el] (groovy-proposed) [0.12-1]
-queuebot:#ubuntu-release- New: accepted rust-clipboard [amd64] (groovy-proposed) [0.5.0-2]
-queuebot:#ubuntu-release- New: accepted rust-clipboard [armhf] (groovy-proposed) [0.5.0-2]
-queuebot:#ubuntu-release- New: accepted rust-clipboard [riscv64] (groovy-proposed) [0.5.0-2]
-queuebot:#ubuntu-release- New: accepted rust-fsevent-sys [amd64] (groovy-proposed) [3.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-fsevent-sys [armhf] (groovy-proposed) [3.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-fsevent-sys [riscv64] (groovy-proposed) [3.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-ipnet [amd64] (groovy-proposed) [2.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-ipnet [armhf] (groovy-proposed) [2.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-ipnet [riscv64] (groovy-proposed) [2.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-clipboard [arm64] (groovy-proposed) [0.5.0-2]
-queuebot:#ubuntu-release- New: accepted rust-clipboard [s390x] (groovy-proposed) [0.5.0-2]
-queuebot:#ubuntu-release- New: accepted rust-fsevent-sys [ppc64el] (groovy-proposed) [3.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-ipnet [arm64] (groovy-proposed) [2.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-ipnet [s390x] (groovy-proposed) [2.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-clipboard [ppc64el] (groovy-proposed) [0.5.0-2]
-queuebot:#ubuntu-release- New: accepted rust-fsevent-sys [s390x] (groovy-proposed) [3.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-fsevent-sys [arm64] (groovy-proposed) [3.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-ipnet [ppc64el] (groovy-proposed) [2.2.0-1]
-queuebot:#ubuntu-release- New: accepted jinja-vanish [amd64] (groovy-proposed) [0.2~git20160124.8980cb2-1]
-queuebot:#ubuntu-release- New: accepted knockpy [amd64] (groovy-proposed) [4.1.0-3]
-queuebot:#ubuntu-release- New: accepted mailnag [amd64] (groovy-proposed) [2.0.0-0.2]
-queuebot:#ubuntu-release- New: accepted knockpy [amd64] (groovy-proposed) [4.1.0-2]
-queuebot:#ubuntu-release- New: accepted php-horde-service-urlshortener [amd64] (groovy-proposed) [2.0.3-5]
-queuebot:#ubuntu-release- New: accepted knockpy [amd64] (groovy-proposed) [4.1.0-4]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (focal-proposed) [2.664.2]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (eoan-proposed) [2.620.3]
<mitya57> vorlon: hi, do you think it's fine if we land yet another qtwebengine upload (https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4072/+packages), or it can entangle some unwanted transitions?
<mitya57> It is a fix for built-in PDF viewer.
-queuebot:#ubuntu-release- Unapproved: rejected clamav [source] (bionic-proposed) [0.102.2+dfsg-0ubuntu0.18.04.2]
<mitya57> Also, unrelated question: julia does not exist on ppc64el, how did it happen that its tests were run? http://autopkgtest.ubuntu.com/packages/j/julia/groovy/ppc64el
<mitya57> Should ppc64el be added to https://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/view/head:/ubuntu-release#L365 ?
-queuebot:#ubuntu-release- New binary: caml-crush [amd64] (groovy-proposed/universe) [1.0.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: openscenegraph [amd64] (groovy-proposed/universe) [3.6.5+dfsg1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oem-5.6 [amd64] (focal-proposed/main) [5.6.0-1011.11] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-5.6 [amd64] (focal-proposed) [5.6.0-1011.11]
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1082.92] (kernel)
-queuebot:#ubuntu-release- Unapproved: strongswan (focal-proposed/main) [5.8.2-1ubuntu3 => 5.8.2-1ubuntu3.1] (ubuntu-server)
<doko> Perfect! Once it migrated to the release pocket, Iâll promote it. Do you
<doko> mind pinging me once itâs the case?
<doko> didrocks: ^^^no, it won't migrate until it's promoted
<didrocks> doko: feel free to promote it then, from my POV itâs an ack with the version in -proposed
<doko> yeah, and now I see that julia/ppc64el fails
<doko> rbalint: I see you retried that
<rbalint> doko, yes, at first glance it looked like a temporary issue
<rbalint> doko, mitya57 adding hint                     â16:50:32          doko | rbalint: I see you retried that                                                                                        â halves       ++
<rbalint> doko, mitya57 adding hint https://code.launchpad.net/~rbalint/britney/hints-ubuntu/+merge/384503
<mitya57> rbalint: thanks!
<ginggs> rbalint: tumble.weed put the julia hint back
<rbalint> ginggs, yes, but later also removed it as i see
<juliank> heh 55 packages in focal can't be SRUed, as they have unsatisfiable build-depends
<juliank> well not easily SRUed
<juliank> which ones? https://magenta.jak-linux.org/ubuntu-archive/distcheck/focal/release.txt tells you
<juliank> groovy has 126 such packagesde
<juliank> most of it is build-depends on missing pkg-js-tools:amd64 (>= 0.9.35~)
<juliank> pkg-js-tools in groovy release pocket is 0.9.31
<rbalint> juliank, nice, this report could also be an input for +1 maintenance
<juliank> yes, rbalint
<juliank> Could also generate them for binary depends too
-queuebot:#ubuntu-release- New: accepted caml-crush [amd64] (groovy-proposed) [1.0.9-1]
-queuebot:#ubuntu-release- New: accepted pveclib [ppc64el] (groovy-proposed) [1.0.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted pspp [amd64] (groovy-proposed) [1.2.0-4]
-queuebot:#ubuntu-release- New: accepted pspp [armhf] (groovy-proposed) [1.2.0-4]
-queuebot:#ubuntu-release- New: accepted pspp [arm64] (groovy-proposed) [1.2.0-4]
-queuebot:#ubuntu-release- New: accepted pspp [s390x] (groovy-proposed) [1.2.0-4]
<xnox> ubuntu-archive please add a hint to try boost1.71 & boost-defaults _together_ They are not tried together by current autopkgtest runs, but they should be.
<xnox> also what is missing from ensuring that automatically? Should I have set (>= new-boost1.71) version on all the dependencies?
<xnox> actually scrap that!
<xnox> i have bad dependencies on tools-dev
<vorlon> mitya57: is that qtwebengine-opensource-src build going to be binary copied, or is it going to delay the related transitions by another 24h while it builds?
<vorlon> xnox: right, well, component-mismatches says unicode-data should now be demoted
<vorlon> xnox: so there's still a problem that someone promotes the package to let the migration happen, then the c-m report is wrong, and it gets re-demoted.
<RikMills> vorlon: qtwebengine would be binary copied if my talk in #ubuntu-qt earlier is right
<RikMills> vorlon: we were pretty sure it would be ok, but considering last couple of issues with pushing a new build, thought it best to be good people and ask ;)
<vorlon> RikMills: ack, that's fine then
<xnox> Vo
<xnox> vor
<xnox> vorlon: I see. Horum.
<mwhudson> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt makes even less sense to me than usual
<RikMills> update_output.txt gives me more brain ache than most of the quantum mechanics courses I did at Uni!
<xnox> mwhudson: which particular bit? Shall I do YouTube videos of reading it out loud?
<xnox> (I guess reading between the lines)
<mwhudson> xnox: trying to work out why gsl makes e.g. libgyoto8 uninstallable
<mwhudson> i think i wish update output separated the things the tried packages make _directly_ uninstallable vs transitively
<xnox> Ah that would be nice.
<xnox> I think I should rerun my autotransitioner and it might actually give answers.
<mwhudson> ah i think liblorene needs a rebuild
<mwhudson> ah no it has one
<mwhudson> why is britney not trying to migrate gsl and lorene together?
<mwhudson> at it is
<mwhudson> *ah
<mwhudson> more ah https://people.canonical.com/~ubuntu-archive/transitions/html/html/auto-gsl.html
-queuebot:#ubuntu-release- Packageset: Removed guile-2.0 from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed rdma-core from i386-whitelist in groovy
<mwhudson> they all ftbfs on riscv
<mwhudson> after a day
<mwhudson> are the debian riscv buildds hardware or vms?
<wgrant> A variety, though more hardware over the last few months.
<mwhudson> how the heck did this build succeed? https://launchpad.net/ubuntu/+source/ea-utils/1.1.2+dfsg-5build1/+build/19101627
<mwhudson> node-highlight.js gets installed, which depends on nodejs which doesn't exist on riscv64?
<mwhudson> unless something Provides: nodejs?
<ginggs> mwhudson: i think something briefly provided nodejs, by mistake
<mwhudson> ginggs: oh good
<xnox> mwhudson:  must be via bootstrap archive or some such. also ea-utils directly does not build-depend on nodejs does it?
<mwhudson> xnox: no, it's indirect
<xnox> ack
<ginggs> debian bug #956507 i think
<ubot5> Debian bug 956507 in pegjs "pegjs: stray Provides: nodejs" [Serious,Fixed] http://bugs.debian.org/956507
<xnox> thanks
 * xnox goes to look what pegjs
<xnox> is
<xnox> mwhudson: I guess we want pegjs to migrate!
<mwhudson> i guess the existing ea-utils binary should be removed then
<xnox> And yeah, remote ea-utils
<xnox> And upload SRUs to the same effect?
<mwhudson> ugh
<mwhudson> pegjs probably isn't migrating because it makes a bunch of packages uninstallable on riscv that should never have been installable :(
<xnox> Force migrate pegjs with a force hint
<xnox> Then ask archive admin to unbreak uninstallables from the uninstallables report.
<mwhudson> trying: pegjs
<mwhudson> skipped: pegjs (22, 331, 8)
<mwhudson>     got: 122+0: a-7:a-7:a-8:i-2:p-7:r-83:s-8
<mwhudson>     * riscv64: ea-utils, r-bioc-biovizbase, r-bioc-deseq2, r-cran-haplo.stats, r-cran-hmisc, r-cran-qgraph, r-cran-rgl, r-cran-rms, r-cran-treescape, r-cran-treespace, r-cran-wgcna
<mwhudson> that's not 83 packages
<xnox> Cause pegjs from release is used to build things on riscv64
<xnox> mwhudson: 83 is starting / existing uninstallables, these are the list of new uninstallables
<xnox> There should be uninstallables list somewhere near the update output.
<mwhudson> ah ok
<mwhudson> chdist apt  groovy showsrc ea-utils -> Build-Depends: debhelper (>= 11~), libbam-dev, zlib1g-dev, libgsl-dev, libsparsehash-dev (>= 2.0), r-cran-hmisc
<mwhudson> which of those is bringing node in?
<mwhudson> it's going to be some documentation related thing isn't it
-queuebot:#ubuntu-release- New binary: php-horde-gollem [amd64] (groovy-proposed/none) [3.0.12-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-mapi [amd64] (groovy-proposed/none) [1.0.10-2] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-mongo [amd64] (groovy-proposed/none) [1.1.0-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-webmail [amd64] (groovy-proposed/none) [5.2.22-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-lz4 [amd64] (groovy-proposed/none) [1.0.10-6] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-nag [amd64] (groovy-proposed/none) [4.2.19-3] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-mnemo [amd64] (groovy-proposed/none) [4.2.14-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-content [amd64] (groovy-proposed/none) [2.0.6-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-elasticsearch [amd64] (groovy-proposed/none) [1.0.4-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-form [amd64] (groovy-proposed/none) [2.0.19-2] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-imp [amd64] (groovy-proposed/none) [6.2.24-2] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-javascriptminify-jsmin [amd64] (groovy-proposed/none) [1.0.2-7] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-kolab-server [amd64] (groovy-proposed/none) [2.0.5-7] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-ldap [amd64] (groovy-proposed/none) [2.4.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-oauth [amd64] (groovy-proposed/none) [2.0.4-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-dav [amd64] (groovy-proposed/none) [1.1.4-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-hashtable [amd64] (groovy-proposed/none) [1.2.6-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-kolab-format [amd64] (groovy-proposed/none) [2.0.9-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-memcache [amd64] (groovy-proposed/none) [2.1.1-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-feed [amd64] (groovy-proposed/none) [2.0.4-7] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-kolab-storage [amd64] (groovy-proposed/none) [2.2.3-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-ingo [amd64] (groovy-proposed/none) [3.2.16-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-scribe [amd64] (groovy-proposed/none) [2.0.3-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-groupware [amd64] (groovy-proposed/universe) [5.2.22-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-kolab-session [amd64] (groovy-proposed/universe) [2.0.3-7] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-openxchange [amd64] (groovy-proposed/universe) [1.0.1-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-timeobjects [amd64] (groovy-proposed/universe) [2.1.4-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-imsp [amd64] (groovy-proposed/universe) [2.0.10-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-pdf [amd64] (groovy-proposed/universe) [2.0.7-7] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-kronolith [amd64] (groovy-proposed/universe) [4.2.27-2] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-turba [amd64] (groovy-proposed/universe) [4.2.25-2] (no packageset)
#ubuntu-release 2020-05-26
<mwhudson> https://launchpad.net/ubuntu/+source/pbcopper/1.6.0+dfsg-1 ftbfs on armhf, ppc64el
<mwhudson> that's probably not going to be one problem on those two platforms at a guess
<mwhudson> "Upstream disabled issue tracker on Github and I have no idea how to contact them."
-queuebot:#ubuntu-release- New: accepted php-horde-groupware [amd64] (groovy-proposed) [5.2.22-5]
-queuebot:#ubuntu-release- New: accepted php-horde-timeobjects [amd64] (groovy-proposed) [2.1.4-5]
-queuebot:#ubuntu-release- New: accepted php-horde-pdf [amd64] (groovy-proposed) [2.0.7-7]
-queuebot:#ubuntu-release- New: accepted php-horde-imsp [amd64] (groovy-proposed) [2.0.10-5]
-queuebot:#ubuntu-release- New: accepted php-horde-kronolith [amd64] (groovy-proposed) [4.2.27-2]
-queuebot:#ubuntu-release- New: accepted php-horde-memcache [amd64] (groovy-proposed) [2.1.1-5]
-queuebot:#ubuntu-release- New: accepted php-horde-openxchange [amd64] (groovy-proposed) [1.0.1-5]
-queuebot:#ubuntu-release- New: accepted php-horde-kolab-session [amd64] (groovy-proposed) [2.0.3-7]
-queuebot:#ubuntu-release- New: accepted php-horde-oauth [amd64] (groovy-proposed) [2.0.4-5]
-queuebot:#ubuntu-release- New: accepted php-horde-ldap [amd64] (groovy-proposed) [2.4.1-3]
-queuebot:#ubuntu-release- New: accepted php-horde-turba [amd64] (groovy-proposed) [4.2.25-2]
-queuebot:#ubuntu-release- New: accepted php-horde-content [amd64] (groovy-proposed) [2.0.6-5]
-queuebot:#ubuntu-release- New: accepted php-horde-elasticsearch [amd64] (groovy-proposed) [1.0.4-5]
-queuebot:#ubuntu-release- New: accepted php-horde-hashtable [amd64] (groovy-proposed) [1.2.6-5]
-queuebot:#ubuntu-release- New: accepted php-horde-javascriptminify-jsmin [amd64] (groovy-proposed) [1.0.2-7]
-queuebot:#ubuntu-release- New: accepted php-horde-kolab-server [amd64] (groovy-proposed) [2.0.5-7]
-queuebot:#ubuntu-release- New: accepted php-horde-dav [amd64] (groovy-proposed) [1.1.4-5]
-queuebot:#ubuntu-release- New: accepted php-horde-imp [amd64] (groovy-proposed) [6.2.24-2]
-queuebot:#ubuntu-release- New: accepted php-horde-feed [amd64] (groovy-proposed) [2.0.4-7]
-queuebot:#ubuntu-release- New: accepted php-horde-kolab-format [amd64] (groovy-proposed) [2.0.9-5]
-queuebot:#ubuntu-release- New: accepted php-horde-form [amd64] (groovy-proposed) [2.0.19-2]
-queuebot:#ubuntu-release- New: accepted php-horde-ingo [amd64] (groovy-proposed) [3.2.16-5]
-queuebot:#ubuntu-release- New: accepted php-horde-lz4 [amd64] (groovy-proposed) [1.0.10-6]
-queuebot:#ubuntu-release- New: accepted php-horde-mnemo [amd64] (groovy-proposed) [4.2.14-5]
-queuebot:#ubuntu-release- New: accepted php-horde-scribe [amd64] (groovy-proposed) [2.0.3-5]
-queuebot:#ubuntu-release- New: accepted php-horde-gollem [amd64] (groovy-proposed) [3.0.12-5]
-queuebot:#ubuntu-release- New: accepted php-horde-mapi [amd64] (groovy-proposed) [1.0.10-2]
-queuebot:#ubuntu-release- New: accepted php-horde-kolab-storage [amd64] (groovy-proposed) [2.2.3-5]
-queuebot:#ubuntu-release- New: accepted php-horde-mongo [amd64] (groovy-proposed) [1.1.0-5]
-queuebot:#ubuntu-release- New: accepted openscenegraph [amd64] (groovy-proposed) [3.6.5+dfsg1-3]
-queuebot:#ubuntu-release- New: accepted php-horde-webmail [amd64] (groovy-proposed) [5.2.22-5]
-queuebot:#ubuntu-release- New: accepted php-horde-nag [amd64] (groovy-proposed) [4.2.19-3]
-queuebot:#ubuntu-release- New binary: plume-creator [amd64] (groovy-proposed/universe) [0.66+dfsg1-3.2] (no packageset)
-queuebot:#ubuntu-release- New binary: nuitka [amd64] (groovy-proposed/universe) [0.6.8.3+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: plume-creator [ppc64el] (groovy-proposed/universe) [0.66+dfsg1-3.2] (no packageset)
-queuebot:#ubuntu-release- New: accepted nuitka [amd64] (groovy-proposed) [0.6.8.3+ds-1]
-queuebot:#ubuntu-release- New: accepted plume-creator [amd64] (groovy-proposed) [0.66+dfsg1-3.2]
-queuebot:#ubuntu-release- New: accepted plume-creator [ppc64el] (groovy-proposed) [0.66+dfsg1-3.2]
<Laney> tsimonq2: any chance you're planning to come back to https://code.launchpad.net/~tsimonq2/autopkgtest-cloud/+git/bug-1654761/+merge/363643 ? or should someone else look to take that over?
-queuebot:#ubuntu-release- New source: nvidia-graphics-drivers-440-server (groovy-proposed/primary) [440.64.00-0ubuntu1]
<mitya57> vorlon, RikMills: thanks! New qtwebengine is a valid candidate, so all seems OK :)
-queuebot:#ubuntu-release- Unapproved: mesa (bionic-proposed/main) [20.0.4-2ubuntu1~18.04.1 => 20.0.4-2ubuntu1~18.04.2] (core, xorg)
<tjaalton> sil2100: hey, new mesa upload for bionic to get image builds going again, dropped zink driver which is quite new and not needed on bionic
<tjaalton> it added libvulkan1 dep in libgl1-mesa-dri
<LocutusOfBorg> wgrant, hello, can you please do something related to this? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956507
<ubot5> Debian bug 956507 in pegjs "pegjs: stray Provides: nodejs" [Serious,Fixed]
<LocutusOfBorg> TLDR: pegjs had a "Provide" nodejs" and migrated in focal. Now, lots of node stuff is not migrating because on riscv64 there is no nodejs anymore.
<LocutusOfBorg> for sure we should hint pegjs to migrate, and do something for the archive to forget nodejs in riscv64
<wgrant> LocutusOfBorg: I'll have to leave that for someone else, I'm afraid. But sounds like some binaries just need to be identified and removed.
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1082.92]
<Laney> Going to rebuild the armhf lxd runner machines, several of them appear to be sucking atm
<Laney> After giving the current jobs a little while to finish
<tseliot> sil2100, hey, if you have the time, can you approve nvidia-graphics-drivers-440-server in groovy-proposed (it's in NEW), and move nvidia-graphics-drivers-418-server to restricted, please?
-queuebot:#ubuntu-release- New binary: pbcopper [amd64] (groovy-proposed/universe) [1.6.0+dfsg-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: pbcopper [ppc64el] (groovy-proposed/universe) [1.6.0+dfsg-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: pbcopper [s390x] (groovy-proposed/universe) [1.6.0+dfsg-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: pbcopper [arm64] (groovy-proposed/universe) [1.6.0+dfsg-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: pbcopper [riscv64] (groovy-proposed/universe) [1.6.0+dfsg-1ubuntu2] (no packageset)
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/pegjs/+bug/1880680
<ubot5> Ubuntu bug 1880680 in pegjs (Ubuntu Focal) "Pegjs should not provide nodejs." [High,New]
<LocutusOfBorg> can any archive admin please accept it? vorlon ^^
-queuebot:#ubuntu-release- Unapproved: pegjs (focal-proposed/universe) [0.10.0-1 => 0.10.0-3~ubuntu1.20.04.1] (no packageset)
<LocutusOfBorg> we really need it to go in groovy release and focal...
-queuebot:#ubuntu-release- Unapproved: chrony (focal-proposed/main) [3.5-6ubuntu6 => 3.5-6ubuntu6.1] (core)
<cpaelzer> If an ubuntu-archive member would have time to look at https://bugs.launchpad.net/ubuntu/+source/rdma-core/+bug/1880651 that woudl be great
<ubot5> Ubuntu bug 1880651 in rdma-core (Ubuntu) "[REVMOVE] please remove rdma-core i386 binaries from groovy" [Undecided,Triaged]
<cpaelzer> I'd want to ensure that after removing the (old) binaries proposed migration really unblocks and goes on
<Laney> armhf is back as of 30 minutes ago or so
<Laney> seems to be chugging along nicely now, shiny fresh new VMs
<coreycb> cpaelzer: doko: hi, we have a new version of heat in focal-proposed that is blocked due to python3-ironicclient not being in main. it's py2 counterpart was in main at one point. do you think we could get python3-ironicclient into main for focal and groovy?
<coreycb> bug 1376238
<ubot5> bug 1376238 in python-ironicclient (Ubuntu) "[MIR] python-ironicclient" [High,Fix released] https://launchpad.net/bugs/1376238
<cpaelzer> coreycb: yes if the old one was approved and there is no majore rework that has happened we usually promote it on the terms of the old MIR bug
<cpaelzer> you'll need an archive admin to do, if doko is around he might be able to help
<coreycb> cpaelzer: ack thanks
-queuebot:#ubuntu-release- New binary: libla4j-java [amd64] (groovy-proposed/none) [0.6.0-2] (no packageset)
<tsimonq2> Laney: Oh, that's a good point. I can revisit it.
-queuebot:#ubuntu-release- Unapproved: keystone (eoan-proposed/main) [2:16.0.0-0ubuntu1.1 => 2:16.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted chrony [source] (focal-proposed) [3.5-6ubuntu6.1]
-queuebot:#ubuntu-release- Unapproved: heat (eoan-proposed/main) [1:13.0.0-0ubuntu1 => 1:13.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: inkscape (focal-proposed/universe) [0.92.5-1ubuntu1 => 0.92.5-1ubuntu1.1] (i386-whitelist, ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: nova (eoan-proposed/main) [2:20.1.1-0ubuntu1 => 2:20.2.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted gpsd [source] (focal-proposed) [3.20-8ubuntu0.2]
<RikMills> bdmurray: https://irclogs.ubuntu.com/2020/05/13/%23ubuntu-release.html#t08:19
<RikMills> I'll add that to the bug
<bdmurray> RikMills: Thanks
<vorlon> LocutusOfBorg: pegjs> needs an SRU team member, not an archive admin? generally best to contact the SRU team member on duty per https://wiki.ubuntu.com/StableReleaseUpdates#Publishing but I can take a look now
<vorlon> LocutusOfBorg: and this appears to include packaging changes unrelated to the bug report
-queuebot:#ubuntu-release- Unapproved: rejected pegjs [source] (focal-proposed) [0.10.0-3~ubuntu1.20.04.1]
<vorlon> mwhudson: have you looked at all at the r-cran-lwgeom / r-cran-sf terribleness on s390x?  (blocks proj and gdal and therefore hdf5 etc)
<vorlon> r-cran-lwgeom may be a situation where the version in -proposed has regressed and the version in release needs rebuilt; I'll dig a bit
-queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (eoan-proposed) [14.2.9-0ubuntu0.19.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted keystone [source] (eoan-proposed) [2:16.0.1-0ubuntu1]
<mwhudson> vorlon: no
<mwhudson> vorlon: i can have a look after the school run though
<vorlon> mwhudson: k.  old r-cran-lwgeom needs some source changes to build with proj 7 because integer inequalities are hard apparently, but I'm having a look
-queuebot:#ubuntu-release- Unapproved: accepted heat [source] (eoan-proposed) [1:13.0.1-0ubuntu1]
<vorlon> mwhudson: yeah looks like old r-cran-lwgeom works with a one-liner patch, so I'll downgrade that and make r-cran-lwgeom 0.2-3 SEP
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (eoan-proposed) [2:20.2.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted shotwell [source] (bionic-proposed) [0.28.4-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (bionic-proposed) [3:13.0.2-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (bionic-proposed) [0.96.24.32.13]
-queuebot:#ubuntu-release- Unapproved: openssh (xenial-proposed/main) [1:7.2p2-4ubuntu2.9 => 1:7.2p2-4ubuntu2.10] (core)
<mwhudson> ubuntu-archive: could someone let https://launchpad.net/ubuntu/+source/pbcopper/1.6.0+dfsg-1ubuntu2 out of NEW?
<vorlon> mwhudson: are these binaries that are in Debian and you're just fixing a FTBFS?
<vorlon> mwhudson: ah wrong binary package name for library ok
<bdmurray> vorlon: If an SRU follows on an SRU which has a block-proposed-$release tag should the follow on SRU be built with -v so the block-proposed SRU appears in the changes file?
-queuebot:#ubuntu-release- New: accepted pbcopper [amd64] (groovy-proposed) [1.6.0+dfsg-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted pbcopper [ppc64el] (groovy-proposed) [1.6.0+dfsg-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted pbcopper [s390x] (groovy-proposed) [1.6.0+dfsg-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted pbcopper [arm64] (groovy-proposed) [1.6.0+dfsg-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted pbcopper [riscv64] (groovy-proposed) [1.6.0+dfsg-1ubuntu2]
<vorlon> bdmurray: I suppose that's ideal, but doesn't lp and the sru report take care of rolling things up based on diffing the debian/changelog?
<bdmurray> vorlon: No, they both use the .changes as the answer.
<vorlon> ok then
<mwhudson> vorlon: the binaries are also in debian NEW
<mwhudson> didn't all the php-horde stuff get removed last cycle?
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1084.94~16.04.1] (kernel)
-queuebot:#ubuntu-release- Unapproved: rejected openssh [source] (xenial-proposed) [1:7.2p2-4ubuntu2.10]
-queuebot:#ubuntu-release- Unapproved: accepted openssh [source] (xenial-proposed) [1:7.2p2-4ubuntu2.10]
-queuebot:#ubuntu-release- New binary: php-horde-sesha [amd64] (groovy-proposed/none) [1.0.0~rc3-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-syncml [amd64] (groovy-proposed/none) [2.0.7-6] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-mime [amd64] (groovy-proposed/none) [2.11.0-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-template [amd64] (groovy-proposed/none) [2.0.3-8] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-passwd [amd64] (groovy-proposed/none) [5.0.7-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-service-facebook [amd64] (groovy-proposed/none) [2.0.10-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-service-weather [amd64] (groovy-proposed/none) [2.5.4-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-text-filter-jsmin [amd64] (groovy-proposed/none) [1.0.2-7] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-service-gravatar [amd64] (groovy-proposed/none) [1.0.1-7] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-test [amd64] (groovy-proposed/none) [2.6.3+debian0-5] (no packageset)
-queuebot:#ubuntu-release- New binary: git-remote-hg [amd64] (groovy-proposed/none) [1.0.1~ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-service-twitter [amd64] (groovy-proposed/none) [2.1.6-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-whups [amd64] (groovy-proposed/none) [3.0.12-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-xml-wbxml [amd64] (groovy-proposed/none) [2.0.3-7] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-scheduler [amd64] (groovy-proposed/none) [2.0.3-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-wicked [amd64] (groovy-proposed/none) [2.0.8-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-thrift [amd64] (groovy-proposed/none) [2.0.3-5] (no packageset)
<mwhudson> so what's going on with fenics
 * mwhudson tries the all-proposed hammer
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1084.94~16.04.1]
#ubuntu-release 2020-05-27
<mwhudson> vorlon: gugh https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#r-cran-lwgeom
<mwhudson> vorlon: do you know what mix of packages that needs to be triggered with?
<mwhudson> i thought autopkgtest was supposed to retry with all-proposed by itself if the test deps couldn't be installed, has this regressed?
<vorlon> mwhudson: when I tested it I had -proposed enabled but I didn't fully upgrade the container hmm
<mwhudson> vorlon: i think it just needs proj
<vorlon> mwhudson: php-horde: a bunch of it has been removed from Debian; some of it has been reintroduced
<mwhudson> vorlon: bryce filed a bug to remove it again and blacklist it
<mwhudson> vorlon: https://bugs.launchpad.net/ubuntu/+source/php-horde/+bug/1880776
<ubot5> Ubuntu bug 1880776 in php-horde (Ubuntu) " Please blacklist and remove php-horde and php-horde-* from groovy" [Undecided,New]
<vorlon> so r-cran-sf being the other package in -proposed that is also failing on s390x, yeah probably works if you just test against proj from -proposed
<mwhudson> vorlon: i guess i forget how transitions work https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#pbcopper
<mwhudson> vorlon: are the "old binaries left" a problem? i thought they'd get cleaned up from nbs after the package has migrated
<vorlon> mwhudson: well, most of the php-horde stuff is removed in Debian as well, therefore I had removed the blacklist; for packages that have been reintroduced in Debian (having gone through source NEW), I don't see the point in blacklisting since someone in Debian is actually maintaining them
<vorlon> mwhudson: the old binaries need cleaned up because they're in -proposed
<mwhudson> vorlon: ah
<vorlon> (done)
<mwhudson> vorlon: can you remove those pretty please? and the armhf binaries from release
<mwhudson> (i filed a bug for that, where did it go)
<mwhudson> https://bugs.launchpad.net/ubuntu/+source/pbcopper/+bug/1880674
<ubot5> Ubuntu bug 1880674 in pbcopper (Ubuntu) "please remove armhf binary" [Undecided,New]
<vorlon> mwhudson: no need for bug reports for binary removals, these always follow directly from archive consistency rules rather than being developer decisions
<mwhudson> vorlon: hm even when an architecture becomes unsupported?
<vorlon> mwhudson: as long as it's just us following Debian, yeah
<mwhudson> ok
<mwhudson> well actually we are fractionally ahead of debian here
<mwhudson> unless the ftp-masters have been busy
<vorlon> I will be generally reticent to remove binaries on an arch due to "unsupported" before Debian has at least filed the removal request bug
<mwhudson> anyway i should get on with rebuilding rdeps i guess
<vorlon> mwhudson: and, uh, blasr just ftbfs on amd64 for the pbcopper no-change rebuild, enjoy
<mwhudson> vorlon: hooray
<mwhudson>  libpbcopper-dev : Depends: libpbcopper1.6.0 (= 1.6.0+dfsg-1ubuntu2) but it is not installed
<mwhudson> what did i do wrong
<vorlon> touched a package that uses d-shlibs
<mwhudson> it doesn't though
<mwhudson> which is why the binary package name was wrong
<vorlon> I thought it did previously :)
<vorlon> oh
<mwhudson> i uploaded an attempt at using it but it didn't work
<mwhudson> maybe i should forget about all this until it passes debian NEW
<vorlon> mwhudson: the log shows both libpbcopper1.30 and libpbcopper1.6.0 being pulled in, so perhaps something else that blasr build-depends on needs to build first
<vorlon> yeah libpbbam-dev
<mwhudson> ffs https://launchpad.net/ubuntu/+source/pbbam/1.0.6+dfsg-2build2/+build/19361658
<mwhudson> ../tests/src/test_BamWriter.cpp:40:34: error: call of overloaded âCigarData(const char [1])â is ambiguous
<mwhudson> i would like to register a complaint
<vorlon> I will not buy this tobacconists it is scratched
<mwhudson> "bam" fits the mood though
<vorlon> mwhudson: https://code.launchpad.net/~mwhudson/britney/hints-ubuntu/+merge/384590 is patching the middle of a block marked as "# BEGIN GENERATED BLOCK #', did you regenerate it?
<mwhudson> vorlon: no, is there a script for that or do you just paste it in?
<mwhudson> vorlon:  i don't have access to a machine with /chroots/groovy/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_groovy*Sources
<mwhudson> vorlon: if you can just regenerate it and reject my MP that would be better i guess
<mwhudson> ah fails in debian too https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959643
<ubot5> Debian bug 959643 in src:pbbam "pbbam: FTBFS: ../tests/src/test_BamWriter.cpp:40:34: error: call of overloaded âCigarData(const char [1])â is ambiguous" [Serious,Open]
<mwhudson> well there's a new upstream version, let's see if that helps
-queuebot:#ubuntu-release- Unapproved: rejected rustc [source] (focal-proposed) [1.42.0+dfsg1+llvm-1ubuntu2~20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted strongswan [source] (focal-proposed) [5.8.2-1ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: docker.io (focal-proposed/universe) [19.03.8-0ubuntu1 => 19.03.8-0ubuntu1.20.04] (no packageset)
<LocutusOfBorg> vorlon, I'm asking about groovy TBH
<RikMills> ISO builds look poorly today
<RikMills> lockfile: Sorry, giving up on "/srv/cdimage.ubuntu.com/etc/.lock-archive-sync"
<RikMills> Timed out waiting for archive sync lock!
<sil2100> tjaalton: looking at those today o/
-queuebot:#ubuntu-release- New: accepted git-remote-hg [amd64] (groovy-proposed) [1.0.1~ds-2]
-queuebot:#ubuntu-release- New: accepted php-horde-mime [amd64] (groovy-proposed) [2.11.0-5]
-queuebot:#ubuntu-release- New: accepted php-horde-scheduler [amd64] (groovy-proposed) [2.0.3-5]
-queuebot:#ubuntu-release- New: accepted php-horde-service-gravatar [amd64] (groovy-proposed) [1.0.1-7]
-queuebot:#ubuntu-release- New: accepted php-horde-service-weather [amd64] (groovy-proposed) [2.5.4-5]
-queuebot:#ubuntu-release- New: accepted php-horde-syncml [amd64] (groovy-proposed) [2.0.7-6]
<tjaalton> sil2100: ah, good
-queuebot:#ubuntu-release- New: accepted php-horde-test [amd64] (groovy-proposed) [2.6.3+debian0-5]
-queuebot:#ubuntu-release- New: accepted php-horde-thrift [amd64] (groovy-proposed) [2.0.3-5]
-queuebot:#ubuntu-release- New: accepted php-horde-wicked [amd64] (groovy-proposed) [2.0.8-5]
-queuebot:#ubuntu-release- New: accepted libla4j-java [amd64] (groovy-proposed) [0.6.0-2]
-queuebot:#ubuntu-release- New: accepted php-horde-service-facebook [amd64] (groovy-proposed) [2.0.10-5]
-queuebot:#ubuntu-release- New: accepted php-horde-sesha [amd64] (groovy-proposed) [1.0.0~rc3-5]
-queuebot:#ubuntu-release- New: accepted php-horde-text-filter-jsmin [amd64] (groovy-proposed) [1.0.2-7]
-queuebot:#ubuntu-release- New: accepted php-horde-xml-wbxml [amd64] (groovy-proposed) [2.0.3-7]
-queuebot:#ubuntu-release- New: accepted php-horde-passwd [amd64] (groovy-proposed) [5.0.7-5]
-queuebot:#ubuntu-release- New: accepted php-horde-template [amd64] (groovy-proposed) [2.0.3-8]
-queuebot:#ubuntu-release- New: accepted php-horde-service-twitter [amd64] (groovy-proposed) [2.1.6-5]
-queuebot:#ubuntu-release- New: accepted php-horde-whups [amd64] (groovy-proposed) [3.0.12-5]
<cjwatson> RikMills: I killed one that's been stuck since yesterday afternoon; that should probably help to clear things
<RikMills> cjwatson: aha. makes sense. thanks!
<sil2100> Yeah, the server one for bionic seemed to be hanging for long
<sil2100> cjwatson: thanks!
<Laney> Could someone SRUy look at mesa/bionic in the queue please? It's to fix image buildability due to a component mismatch
<sil2100> Laney: yes, it's on my list for today o/
<sil2100> Got a ping from Timo yesterday
<sil2100> Such an obscure dep-change indeed
<Laney> thanks sil2100!
-queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (bionic-proposed) [20.0.4-2ubuntu1~18.04.2]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-10 [amd64] (bionic-proposed) [1:10.0.0-4ubuntu1~18.04.1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-10 [i386] (bionic-proposed) [1:10.0.0-4ubuntu1~18.04.1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-10 [s390x] (bionic-proposed) [1:10.0.0-4ubuntu1~18.04.1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-10 [armhf] (bionic-proposed) [1:10.0.0-4ubuntu1~18.04.1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-10 [ppc64el] (bionic-proposed) [1:10.0.0-4ubuntu1~18.04.1]
<sil2100> tjaalton: I also accepted all the llvm binaries ^ But sadly arm64 FTBFS
<sil2100> tjaalton: can you take a look and see if a retry would help?
<tjaalton> ah, sure
<tjaalton> hmm no build log
<tjaalton> restart it is then
-queuebot:#ubuntu-release- New binary: drop-seq [amd64] (groovy-proposed/universe) [2.3.0+dfsg-2] (no packageset)
<LocutusOfBorg> missing build on armhf: python3-pybedtools (from 0.8.0-3build1)
<LocutusOfBorg> somebody removed bedtools without cleaning up reverse-dependencies first?
<LocutusOfBorg> ^^ vorlon  please?
-queuebot:#ubuntu-release- New: accepted drop-seq [amd64] (groovy-proposed) [2.3.0+dfsg-2]
<xnox1> LocutusOfBorg:  thanks for fixing up my upload
<LocutusOfBorg> you are welcome :)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (focal-proposed/main) [1.142 => 1.142.1] (core)
<LocutusOfBorg> I did quickly because it breaks people using proposed on their system ;)
-queuebot:#ubuntu-release- Unapproved: accepted chromium-browser [source] (eoan-proposed) [81.0.4044.129-0ubuntu0.19.10.1]
<tseliot> sil2100, hey did you have the chance to have a look at nvidia-graphics-drivers-440-server and nvidia-graphics-drivers-418-server in groovy?
<sil2100> tseliot: hey! Looking now!
<tseliot> thanks
-queuebot:#ubuntu-release- Unapproved: accepted net-snmp [source] (bionic-proposed) [5.7.3+dfsg-1.8ubuntu3.4]
<paride> So in the end what's holding back the mysql-8.0 migration is this bug: https://bugs.launchpad.net/ubuntu/+source/mysql-8.0/+bug/1877504
<ubot5> Ubuntu bug 1877504 in mysql-8.0 (Ubuntu) "new version of libmysqlclient21 8.0.20-0ubuntu0.20.04.1 causes mythtv-set, mythbackend and mythfrontend to segfault on exit." [Undecided,Confirmed]
<paride> which happens when libmysqlclient21 is used to connect to a mariadb server
<paride> and mysql-8.0 triggers a libdbd-mariadb-perl autopkgtest which fails because of it
-queuebot:#ubuntu-release- Unapproved: accepted dahdi-linux [source] (xenial-proposed) [1:2.10.2~dfsg-1ubuntu4]
<coreycb> hello archive admins, please can we get python3-ironicclient promoted to main for focal+? it's py2 counterpart was in main in the past. this will help unblock heat from focal-proposed.
<sil2100> tseliot: ok, I think -440-server is looking okayish, the only nitpicks I would have for a future upload is: bumping copyright, as debian/ is for 2018, and I guess the git branch that debian/control is pointing at is not existing yet
<sil2100> Let me accept it
<sil2100> tseliot: as for -418-server, I didn't promote nvidia packages before, so question: is there an MIR filled in somewhere?
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-440-server [source] (groovy-proposed) [440.64.00-0ubuntu1]
<sil2100> Since we were requested to fill one for a different package that we wanted to promote from multiverse to restricted
<sil2100> But maybe nvidia has some exception?
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-440-server [ppc64el] (groovy-proposed/none) [440.64.00-0ubuntu1] (no packageset)
<tseliot> sil2100, no, there is no MIR, since all the nvidia drivers belong in -restricted
<tseliot> sil2100, I can update the copyright in the next upload
-queuebot:#ubuntu-release- Unapproved: rejected docker.io [source] (focal-proposed) [19.03.8-0ubuntu1.20.04]
-queuebot:#ubuntu-release- Unapproved: docker.io (focal-proposed/universe) [19.03.8-0ubuntu1 => 19.03.8-0ubuntu1.20.04] (no packageset)
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-440-server [amd64] (groovy-proposed/multiverse) [440.64.00-0ubuntu1] (no packageset)
<vorlon> mwhudson: refreshed the list; it doesn't have to be /chroots/groovy, that's just an example path :)
<vorlon> LocutusOfBorg: python3-pybedtools sorted
<LocutusOfBorg> thanks and for pegjs migration please?
<vorlon> LocutusOfBorg: your message was not clear what you needed an archive admin for re: pegjs/groovy
<LocutusOfBorg> pegjs/groovy has "Provides: nodejs" which is OBVIOUSLY WRONG. the new pegjs/groovy-proposed is failing to migrate due to this
<LocutusOfBorg> because it increase the uninstallability count on riscv64 (nodejs is not built there)
<LocutusOfBorg> but we cannot satisfy nodejs installability with pegjs!
<LocutusOfBorg> same for focal of course, I would have SRUed with more changes if possibile, to keep it in sync with groovy (the bugfixes are useful, and not breaking changes, I'll update the SRU report)
-queuebot:#ubuntu-release- Unapproved: accepted plasma-nm [source] (focal-proposed) [4:5.18.4.1-0ubuntu1.1]
<vorlon> LocutusOfBorg: so this is about binary removals on riscv64, ok
<vorlon> LocutusOfBorg: done
<LocutusOfBorg> something around that lines :) thanks!
<LocutusOfBorg> do you think you can accept the same as SRU? assuming I change the bug report?
<vorlon> LocutusOfBorg: we can't remove the binaries from the release pocket as part of an SRU; but under the circumstances we could accept an uninstallability increase on rcisv64
<LocutusOfBorg> sure thanks
-queuebot:#ubuntu-release- Unapproved: pegjs (focal-proposed/universe) [0.10.0-1 => 0.10.0-3~ubuntu1.20.04.1] (no packageset)
<LocutusOfBorg> now the SRU bug is more coherent with the upload
<LocutusOfBorg> also, remmina seems to need a kick to go in release because of riscv64 nox libraries not built there?
<vorlon> LocutusOfBorg: remmina is a candidate despite the unsatisfiable depends
<vorlon> (and is already uninstallable in the release pocket, not a regression)
<LocutusOfBorg> oh ok, wonderful to know!
 * vorlon pokes at r-cran-sf/s390x with more involved triggers
<LocutusOfBorg> I also have a libsdl2 sadness on i386 I couldn't really parse https://autopkgtest.ubuntu.com/packages/libsdl2/groovy/i386
<LocutusOfBorg> probably a force hint is needed?
<vorlon> libsdl2 is in the i386 whitelist; shouldn't be a force hint, at most a badtest, but I'll look at it first
<vorlon> since it seems to be a regression in testability on i386
<vorlon> LocutusOfBorg: it's declaring test deps on the toolchain directly; if this is changed to depend only on build-essential, autopkgtest will fix it up for cross-arch testing
<vorlon> so we should do that instead of regressing test coverage
<LocutusOfBorg> but there is a new test using clang...
<vorlon> ah
<vorlon> yeah that's not fixable via build-essential
<LocutusOfBorg> I mean, the old test is also testing a build with a clang compiler
<LocutusOfBorg> clang ${DEB_HOST_GNU_TYPE:+--target="${DEB_HOST_GNU_TYPE}"} -o use-sdl use-sdl.c -DWRONG_INCLUDE_PATH -lSDL2
<LocutusOfBorg> clang ${DEB_HOST_GNU_TYPE:+--target="${DEB_HOST_GNU_TYPE}"} -o use-ttf use-ttf.c -DWRONG_INCLUDE_PATH -lSDL2 -lSDL2_ttf
<LocutusOfBorg> this ^^
<vorlon> how was clang being installed in the old test?
<LocutusOfBorg> it was not tested at all
<LocutusOfBorg> :)
<vorlon> you said the old test is testing a build with a clang compiler
<LocutusOfBorg> no, the old test is testing "hey, this example file works with gcc"
<LocutusOfBorg> now the very same test with the very same filename is testing both gcc and clang
<LocutusOfBorg> tests are build and deprecated-use
<LocutusOfBorg> https://salsa.debian.org/sdl-team/libsdl2/-/commit/9c79cec729b28f251e1030f419d379482fbbef0b
<vorlon> right, so.  It's possible a dep on clang:native would DTRT
<LocutusOfBorg> https://salsa.debian.org/sdl-team/libsdl2/-/commit/e02927f1176812da75327c5020327b3d9780abd1
<LocutusOfBorg> mmm interesting
-queuebot:#ubuntu-release- New binary: cat-bat [ppc64el] (groovy-proposed/none) [5.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: flash [ppc64el] (groovy-proposed/none) [1.2.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cat-bat [s390x] (groovy-proposed/none) [5.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: flash [s390x] (groovy-proposed/none) [1.2.11-1] (no packageset)
<LocutusOfBorg> I uploaded that
<LocutusOfBorg> lets see how far we go before committing in debian
-queuebot:#ubuntu-release- New binary: cat-bat [amd64] (groovy-proposed/none) [5.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ivar [amd64] (groovy-proposed/none) [1.2.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: flash [amd64] (groovy-proposed/none) [1.2.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cat-bat [riscv64] (groovy-proposed/universe) [5.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: flash [riscv64] (groovy-proposed/universe) [1.2.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cat-bat [arm64] (groovy-proposed/universe) [5.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: flash [armhf] (groovy-proposed/universe) [1.2.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cat-bat [armhf] (groovy-proposed/universe) [5.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: flash [arm64] (groovy-proposed/universe) [1.2.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ivar [arm64] (groovy-proposed/universe) [1.2.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ivar [riscv64] (groovy-proposed/universe) [1.2.2+dfsg-2] (no packageset)
<vorlon> LocutusOfBorg: local test here, changing to clang:native the build test passes (but may be doing amd64 instead?), and the deprecated-use fails
<vorlon> + clang --target=i686-linux-gnu -o use-pkg-config-clang-dynamic use-sdl.c -D_REENTRANT -I/usr/include/SDL2 -lSDL2
<vorlon> well that's a good sign at least
<vorlon> /usr/include/i386-linux-gnu/SDL2/SDL_platform.h:179:10: fatal error: 'begin_code
<vorlon> .h' file not found
<vorlon> LocutusOfBorg: ^^ that's curious, AIUI this should be found at /usr/include/SDL2/begin_code.h so no idea why clang is unhappy
<vorlon> LocutusOfBorg: ah, I was testing wrong, and picking up the binaries from release pocket instead of proposed, oops
<vorlon> LocutusOfBorg: ok when I test against the binaries I'm meant to, seems to work fine by just switching to clang:native, cool
<mwhudson> vorlon: does it make sense to remove the riscv binaries from release for these packages? https://people.canonical.com/~ubuntu-archive/transitions/html/html/auto-gsl.html
<vorlon> mwhudson: do you know why they're failing?
<mwhudson> vorlon: no, the tests are hanging
 * mwhudson checks calendar
<mwhudson> vorlon: maybe the +1 maintenance person could look into it!!!
<vorlon> mwhudson: :P
<vorlon> mwhudson: working on gdal currently which is higher priority :)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (eoan-proposed/main) [5.3.0-56.50] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (eoan-proposed/main) [5.3.0-56.50] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (eoan-proposed/main) [5.3.0-56.50] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (eoan-proposed/main) [5.3.0-56.50] (core, kernel)
-queuebot:#ubuntu-release- New binary: rustc [s390x] (groovy-proposed/universe) [1.43.0+dfsg1+llvm-1~exp1ubuntu1] (i386-whitelist)
<vorlon> N | flash Component: universe Section: science Priority: OPTIONAL
-queuebot:#ubuntu-release- New: accepted ivar [arm64] (groovy-proposed) [1.2.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted ivar [riscv64] (groovy-proposed) [1.2.2+dfsg-2]
<vorlon> who came up with that genius use of the namespace
-queuebot:#ubuntu-release- New: accepted cat-bat [amd64] (groovy-proposed) [5.0.5-1]
-queuebot:#ubuntu-release- New: accepted cat-bat [armhf] (groovy-proposed) [5.0.5-1]
-queuebot:#ubuntu-release- New: accepted flash [amd64] (groovy-proposed) [1.2.11-1]
-queuebot:#ubuntu-release- New: accepted flash [armhf] (groovy-proposed) [1.2.11-1]
-queuebot:#ubuntu-release- New: accepted ivar [amd64] (groovy-proposed) [1.2.2+dfsg-2]
-queuebot:#ubuntu-release- New binary: pbbam [ppc64el] (groovy-proposed/universe) [1.0.7+dfsg-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted cat-bat [arm64] (groovy-proposed) [5.0.5-1]
-queuebot:#ubuntu-release- New: accepted flash [arm64] (groovy-proposed) [1.2.11-1]
-queuebot:#ubuntu-release- New binary: pbbam [amd64] (groovy-proposed/universe) [1.0.7+dfsg-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted cat-bat [riscv64] (groovy-proposed) [5.0.5-1]
-queuebot:#ubuntu-release- New: accepted flash [riscv64] (groovy-proposed) [1.2.11-1]
-queuebot:#ubuntu-release- New: accepted cat-bat [ppc64el] (groovy-proposed) [5.0.5-1]
-queuebot:#ubuntu-release- New: accepted flash [ppc64el] (groovy-proposed) [1.2.11-1]
-queuebot:#ubuntu-release- New: accepted cat-bat [s390x] (groovy-proposed) [5.0.5-1]
-queuebot:#ubuntu-release- New: accepted flash [s390x] (groovy-proposed) [1.2.11-1]
-queuebot:#ubuntu-release- New binary: rustc [ppc64el] (groovy-proposed/universe) [1.43.0+dfsg1+llvm-1~exp1ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: pbbam [arm64] (groovy-proposed/universe) [1.0.7+dfsg-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: pbbam [riscv64] (groovy-proposed/universe) [1.0.7+dfsg-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-azure-4.15 [amd64] (bionic-proposed/main) [4.15.0-1084.94] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (eoan-proposed/main) [5.3.0-1023.24] (core, kernel)
-queuebot:#ubuntu-release- New binary: rustc [i386] (groovy-proposed/universe) [1.43.0+dfsg1+llvm-1~exp1ubuntu1] (i386-whitelist)
#ubuntu-release 2020-05-28
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (eoan-proposed) [5.3.0-1023.24]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (eoan-proposed) [5.3.0-56.50]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (eoan-proposed) [5.3.0-56.50]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (eoan-proposed) [5.3.0-56.50]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (eoan-proposed) [5.3.0-56.50]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure-4.15 [amd64] (bionic-proposed) [4.15.0-1084.94]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (focal-proposed/main) [5.4.0-1012.12] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (focal-proposed/main) [5.4.0-34.38] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (focal-proposed/main) [5.4.0-34.38] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (focal-proposed/main) [5.4.0-34.38] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (focal-proposed/main) [5.4.0-34.38] (core, kernel)
<vorlon> oh good, the upstream r-cran-lwgeom commit that regressed s390x support is 42kloc
<mwhudson> vorlon: yeah i noticed that
<mwhudson> vorlon: it's mostly vendoring a new versino of liblwgeom which is part of postgis, or something?
<vorlon> so it seems
<mwhudson> vorlon: so either (a) the bug is in the non-liblwgeom parts or (b) it's in postgis
<mwhudson> i wonder if the version of postgis we have works on s390x...
 * mwhudson afk
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (focal-proposed) [5.4.0-1012.12]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (focal-proposed) [5.4.0-34.38]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (focal-proposed) [5.4.0-34.38]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (focal-proposed) [5.4.0-34.38]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (focal-proposed) [5.4.0-34.38]
-queuebot:#ubuntu-release- New binary: rustc [amd64] (groovy-proposed/universe) [1.43.0+dfsg1+llvm-1~exp1ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- New source: cd-boot-images (groovy-proposed/primary) [1]
-queuebot:#ubuntu-release- New binary: nomad [amd64] (groovy-proposed/universe) [0.10.5+dfsg1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-optiopay-kafka [amd64] (groovy-proposed/none) [2.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [armhf] (groovy-proposed/universe) [1.43.0+dfsg1+llvm-1~exp1ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: openvswitch (bionic-proposed/main) [2.9.5-0ubuntu0.18.04.1 => 2.9.6-0ubuntu0.18.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected python-botocore [source] (bionic-proposed) [1.15.46+repack-1ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected python-botocore [source] (xenial-proposed) [1.15.46+repack-1ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected python-botocore [source] (eoan-proposed) [1.15.46+repack-1ubuntu0.19.10.1]
-queuebot:#ubuntu-release- Unapproved: libreoffice (focal-proposed/main) [1:6.4.3-0ubuntu0.20.04.1 => 1:6.4.4-0ubuntu0.20.04.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: symfony [amd64] (groovy-proposed/universe) [4.4.8-1] (no packageset)
<LocutusOfBorg> sil2100, can you please have a look at https://bugs.launchpad.net/ubuntu/+source/pegjs/+bug/1880680 ?
<ubot5> Ubuntu bug 1880680 in pegjs (Ubuntu Focal) "[SRU] Pegjs should not provide nodejs." [High,In progress]
<sil2100> LocutusOfBorg: hey! Sure, left a comment if anything o/
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-5.4 [s390x] (bionic-proposed/universe) [5.4.0-31.35~18.04.2] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-5.4 [amd64] (bionic-proposed/universe) [5.4.0-31.35~18.04.2] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-5.4 [ppc64el] (bionic-proposed/universe) [5.4.0-31.35~18.04.2] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-5.4 [arm64] (bionic-proposed/universe) [5.4.0-31.35~18.04.2] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-5.4 [amd64] (bionic-proposed) [5.4.0-31.35~18.04.2]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-5.4 [ppc64el] (bionic-proposed) [5.4.0-31.35~18.04.2]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-5.4 [arm64] (bionic-proposed) [5.4.0-31.35~18.04.2]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-5.4 [s390x] (bionic-proposed) [5.4.0-31.35~18.04.2]
-queuebot:#ubuntu-release- Unapproved: zfs-linux (focal-proposed/main) [0.8.3-1ubuntu12 => 0.8.3-1ubuntu12.1] (core)
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-440-server [amd64] (groovy-proposed) [440.64.00-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-440-server [ppc64el] (groovy-proposed) [440.64.00-0ubuntu1]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp-5.4 [amd64] (bionic-proposed/universe) [5.4.0-1011.11~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [arm64] (bionic-proposed/main) [5.3.0-56.50~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (bionic-proposed/main) [5.3.0-56.50~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure-5.4 [amd64] (bionic-proposed/universe) [5.4.0-1012.12~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (bionic-proposed/main) [5.3.0-56.50~18.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted pbbam [amd64] (groovy-proposed) [1.0.7+dfsg-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted pbbam [ppc64el] (groovy-proposed) [1.0.7+dfsg-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted pbbam [arm64] (groovy-proposed) [1.0.7+dfsg-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted pbbam [riscv64] (groovy-proposed) [1.0.7+dfsg-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: pegjs (focal-proposed/universe) [0.10.0-1 => 0.10.0-3~ubuntu1.20.04.1] (no packageset)
<LocutusOfBorg> sil2100, ^^ thanks :D
-queuebot:#ubuntu-release- Unapproved: debhelper (focal-backports/main) [12.10ubuntu1 => 13ubuntu1] (core, i386-whitelist) (sync)
-queuebot:#ubuntu-release- New binary: php-horde-imap-client [amd64] (groovy-proposed/universe) [2.30.1-1] (no packageset)
<LocutusOfBorg> tsimonq2, ^^ you sure that 13ubuntu1 is a correct version naming for a backport? the same version exists in groovy...
-queuebot:#ubuntu-release- New binary: rustc [arm64] (groovy-proposed/universe) [1.43.0+dfsg1+llvm-1~exp1ubuntu1] (i386-whitelist)
<coreycb> hello, please can an archive admin promote python3-ironicclient to main for focal+? its py2 counterpart was in main in the past. this will help unblock heat from groovy-proposed and focal-proposed.
<vorlon> coreycb: promotion in a stable series takes a bit of work, but I'll poke
<coreycb> vorlon: thanks, if I can help in anyway please let me know
<vorlon> mwhudson: in conclusion, yes, I'm removing those cpl-plugin-*/riscv64 binaries
<vorlon> 461 packages are valid candidates, 407 of them are part of the transition
<vorlon> seems fair
<vorlon> LocutusOfBorg: is there any particular reason you had uploaded no-change rebuilds for only a subset of the tinyxml2 revdeps?
-queuebot:#ubuntu-release- New: accepted linux-signed-azure-5.4 [amd64] (bionic-proposed) [5.4.0-1012.12~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (bionic-proposed) [5.3.0-56.50~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (bionic-proposed) [5.3.0-56.50~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp-5.4 [amd64] (bionic-proposed) [5.4.0-1011.11~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [arm64] (bionic-proposed) [5.3.0-56.50~18.04.1]
<LocutusOfBorg> vorlon, I did search with: reverse-depends -r groovy -b libtinyxml2-dev
<LocutusOfBorg> what did I miss?
<vorlon> LocutusOfBorg: all the ros stuff
<LocutusOfBorg> interesting, I see it in the output
<LocutusOfBorg> can I do it now?
<vorlon> already done
<LocutusOfBorg> nice thanks!
<vorlon> just wanted to understand if there was a reason it wasn't before
<LocutusOfBorg> nah, probably my dpkg-foo failed because of ENODEPS and I didn't parse correctly the output, sorry for that
<LocutusOfBorg> RAOF, are you fixing https://bugs.launchpad.net/ubuntu/+source/yaml-cpp/+bug/1880419 ?
<ubot5> Ubuntu bug 1880419 in yaml-cpp (Ubuntu) "yaml-cpp-config.cmake has incorrect path to yaml-cpp include directory" [Undecided,New]
<LocutusOfBorg> I already have a local patch, could you please help me verifying it works?
<LocutusOfBorg> its building there https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+packages
<mwhudson> vorlon: ack
 * mwhudson glares at http://autopkgtest.ubuntu.com/packages/p/pcs/groovy/arm64
<vorlon> bdmurray: I'm gonna pull the riscv64 binaries on atlas-ecmwf for now
<vorlon> which I believe unblocks the lot
<RAOF> LocutusOfBorg: certainly! I'll check that out this morning
<bdmurray> vorlon: "pull"?
<vorlon> bdmurray: remove-package
<bdmurray> got it
<vorlon> aaaaand something has regressed it
<Eickmeyer> *price-is-right-fail-horn.ogg*
<vorlon> perl is suddenly not a candidate :P
<vorlon> because rspamd newly has tests
<vorlon> so skiptesting that
<mwhudson> vorlon: aargh
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (eoan-proposed/main) [5.3.0-1019.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle-5.4 [amd64] (bionic-proposed/universe) [5.4.0-1011.11~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (focal-proposed/main) [5.4.0-1013.13] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (eoan-proposed/main) [5.3.0-1021.23] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (focal-proposed) [5.4.0-1013.13]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (eoan-proposed) [5.3.0-1021.23]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (eoan-proposed) [5.3.0-1019.21]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle-5.4 [amd64] (bionic-proposed) [5.4.0-1011.11~18.04.1]
-queuebot:#ubuntu-release- Unapproved: curtin (xenial-proposed/main) [19.3-26-g82f23e3d-0ubuntu1~16.04.1 => 20.1-2-g42a9667f-0ubuntu1~16.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: curtin (bionic-proposed/main) [19.3-26-g82f23e3d-0ubuntu1~18.04.1 => 20.1-2-g42a9667f-0ubuntu1~18.04.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (focal-proposed/main) [20.1-10-g71af48df-0ubuntu5 => 20.2-38-g8377897b-0ubuntu1~20.04.1] (core, edubuntu, ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: curtin (focal-proposed/main) [19.3-27-g437caaa9-0ubuntu1 => 20.1-2-g42a9667f-0ubuntu1~20.04.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: octave-mpi [amd64] (groovy-proposed/none) [3.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-mpi [s390x] (groovy-proposed/none) [3.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-mpi [ppc64el] (groovy-proposed/none) [3.1.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cloud-init (eoan-proposed/main) [19.4-33-gbb4131a2-0ubuntu1~19.10.1 => 20.2-38-g8377897b-0ubuntu1~19.10.1] (core, edubuntu, ubuntu-cloud)
-queuebot:#ubuntu-release- New binary: octave-mpi [armhf] (groovy-proposed/none) [3.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-mpi [arm64] (groovy-proposed/none) [3.1.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cloud-init (bionic-proposed/main) [19.4-33-gbb4131a2-0ubuntu1~18.04.1 => 20.2-38-g8377897b-0ubuntu1~18.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- New binary: octave-mpi [riscv64] (groovy-proposed/universe) [3.1.0-1] (no packageset)
<vorlon> now just waiting on ros-ros-comm, whose arm64 autopkgtest finished... so if nothing else has moved, this should go through on the current britney run
-queuebot:#ubuntu-release- New: accepted octave-mpi [arm64] (groovy-proposed) [3.1.0-1]
-queuebot:#ubuntu-release- New: accepted octave-mpi [ppc64el] (groovy-proposed) [3.1.0-1]
-queuebot:#ubuntu-release- New: accepted octave-mpi [armhf] (groovy-proposed) [3.1.0-1]
-queuebot:#ubuntu-release- New: accepted octave-mpi [riscv64] (groovy-proposed) [3.1.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-optiopay-kafka [amd64] (groovy-proposed) [2.1.1-1]
-queuebot:#ubuntu-release- New: accepted octave-mpi [s390x] (groovy-proposed) [3.1.0-1]
-queuebot:#ubuntu-release- New: accepted symfony [amd64] (groovy-proposed) [4.4.8-1]
-queuebot:#ubuntu-release- New: accepted octave-mpi [amd64] (groovy-proposed) [3.1.0-1]
-queuebot:#ubuntu-release- New: accepted php-horde-imap-client [amd64] (groovy-proposed) [2.30.1-1]
#ubuntu-release 2020-05-29
<vorlon> oh hey, I'm getting archive mail.  looks like things moved
<mwhudson> vorlon: party time
-queuebot:#ubuntu-release- New binary: linux-signed-azure-5.3 [amd64] (bionic-proposed/main) [5.3.0-1023.24~18.04.1] (no packageset)
<vorlon> mwhudson, bdmurray: congrats, all unclogged
<mwhudson> i shall celebrate by having lunch
<mwhudson> vorlon: i guess https://wiki.ubuntu.com/PlusOneMaintenanceTeam/Status can be updated?
-queuebot:#ubuntu-release- New binary: python-altair [amd64] (groovy-proposed/universe) [4.0.1-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libvirt (focal-proposed/main) [6.0.0-0ubuntu8 => 6.0.0-0ubuntu8.1] (ubuntu-server, virt)
<vorlon> so atlas-ecmwf build failure seems to be because libclang-common-10-dev on riscv64 doesn't have omp.h
<RAOF> LocutusOfBorg: I'm having trouble finding a test case for that yaml-cpp bug. What does it actually prevent from working?
<RAOF> LocutusOfBorg: I mean, that patch doesn't *break* anything that I tried, but I also can't seem to find anything that the lack of patch breaks.
<RAOF> (It also doesn't need fixing upstream, as upstream has reworked that whole thing after the 0.6.3 release)
<LocutusOfBorg> RAOF, ack, I'll give it a test
<LocutusOfBorg> like "findfoo.cmake" in a cmake list and pkg-config --list to see if the paths are correct
<LocutusOfBorg> that was how I crafted the patch
<LocutusOfBorg> vorlon, r-base just migrated in Debian, maybe its time to remove the block? :)
<RAOF> LocutusOfBorg: To be clear, what I've tried is a `CMakeLists.txt` file with `find_package(yaml-cpp)`, using `${YAML_CPP_INCLUDE_DIRS}` in `target_include_directories()` for a thing, and checking whether it compiles.
<LocutusOfBorg> more or less my check!
<RAOF> I'm perfectly prepared to believe that the paths are wrong, but yaml-cpp is installed the default include paths, so why does it matter that they're wrong?
<LocutusOfBorg> RAOF, I guess nothing, unless somebody is using such paths blindly and subcompiling it as a internal project library not system-wide installed
<LocutusOfBorg> but I agree
<LocutusOfBorg> my thought was about a new cmake more picky
<RAOF> Groovy's CMake doesn't appear to care.
<RAOF> And the next upstream release it'll all be different anyway :)
<LocutusOfBorg> so I'll push probably this patch and live happy
<LocutusOfBorg> but no SRU
<RAOF> I think that's reasonable.
-queuebot:#ubuntu-release- Unapproved: qemu (focal-proposed/main) [1:4.2-3ubuntu6.1 => 1:4.2-3ubuntu6.2] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: qemu (eoan-proposed/main) [1:4.0+dfsg-0ubuntu9.6 => 1:4.0+dfsg-0ubuntu9.7] (ubuntu-server, virt)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure-5.3 [amd64] (bionic-proposed) [5.3.0-1023.24~18.04.1]
-queuebot:#ubuntu-release- Unapproved: qemu (bionic-proposed/main) [1:2.11+dfsg-1ubuntu7.26 => 1:2.11+dfsg-1ubuntu7.27] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: netplan.io (bionic-proposed/main) [0.99-0ubuntu3~18.04.2 => 0.99-0ubuntu3~18.04.3] (core)
-queuebot:#ubuntu-release- Unapproved: netplan.io (focal-proposed/main) [0.99-0ubuntu3~20.04.1 => 0.99-0ubuntu3~20.04.2] (core)
-queuebot:#ubuntu-release- Unapproved: netplan.io (eoan-proposed/main) [0.99-0ubuntu3~19.10.1 => 0.99-0ubuntu3~19.10.2] (core)
<mitya57> vorlon: thanks *a lot* from me too, for making the stuff migrate!
<LocutusOfBorg> vorlon, easy one: missing build on i386: clevis-dracut, clevis-initramfs, clevis-luks (from 12-1ubuntu5)? thanks :D
-queuebot:#ubuntu-release- Unapproved: nfs-utils (focal-proposed/main) [1:1.3.4-2.5ubuntu3 => 1:1.3.4-2.5ubuntu3.1] (core)
-queuebot:#ubuntu-release- Unapproved: nfs-utils (bionic-proposed/main) [1:1.3.4-2.1ubuntu5.2 => 1:1.3.4-2.1ubuntu5.3] (core)
-queuebot:#ubuntu-release- Unapproved: nfs-utils (eoan-proposed/main) [1:1.3.4-2.5ubuntu2 => 1:1.3.4-2.5ubuntu2.1] (core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-keyring (xenial-proposed/main) [2012.05.19 => 2012.05.19.1] (core)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (focal-proposed/main) [5.4.0-1012.12] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-440 (focal-proposed/restricted) [440.82+really.440.64-0ubuntu6 => 440.82.0-0ubuntu0.20.04.1] (i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-440 (bionic-proposed/multiverse) [440.59-0ubuntu0.18.04.1 => 440.82-0ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- New source: nvidia-graphics-drivers-440-server (focal-proposed/primary) [440.64.00-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- New source: nvidia-graphics-drivers-440-server (bionic-proposed/primary) [440.64.00-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New source: nvidia-graphics-drivers-418-server (focal-proposed/primary) [418.126.02-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- New source: nvidia-graphics-drivers-418-server (bionic-proposed/primary) [418.126.02-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: openvpn (bionic-proposed/main) [2.4.4-2ubuntu1.3 => 2.4.4-2ubuntu1.4] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: linux-signed-gke-5.3 [amd64] (bionic-proposed/universe) [5.3.0-1021.23~18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: openvpn (eoan-proposed/main) [2.4.7-1ubuntu2 => 2.4.7-1ubuntu2.19.10.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: openvpn (focal-proposed/main) [2.4.7-1ubuntu2 => 2.4.7-1ubuntu2.20.04.1] (ubuntu-desktop, ubuntu-server)
<vorlon> LocutusOfBorg: sure, can remove the r- block now; there's "only" 1,124 string matches for r-cran on update_excuses...
<vorlon> LocutusOfBorg: clevis i386 removals done
-queuebot:#ubuntu-release- Unapproved: accepted sssd [source] (eoan-proposed) [2.2.0-4ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted sssd [source] (bionic-proposed) [1.16.1-1ubuntu1.6]
-queuebot:#ubuntu-release- Unapproved: mutter (focal-proposed/main) [3.36.2-1ubuntu1~20.04.1 => 3.36.2-1ubuntu1~20.04.2] (desktop-core, desktop-extra)
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.3 [amd64] (bionic-proposed) [5.3.0-1021.23~18.04.1]
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [19.4-33-gbb4131a2-0ubuntu1~16.04.1 => 20.2-38-g8377897b-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<blackboxsw> hello hello sru vanguards: we have a few SRU uploads queued for inclusion if anyone has time  today: curtin X B F https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1881003 and cloud-init X B E F https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1881018
<ubot5> Ubuntu bug 1881003 in curtin (Ubuntu Focal) "sru curtin 2020-05-27 - 20.1-0ubuntu1" [Undecided,New]
<ubot5> Ubuntu bug 1881018 in cloud-init (Ubuntu Focal) "sru cloud-init (19.4.33 to 20.2-30) Xenial, Bionic, Eoan and Focal" [Undecided,New]
<blackboxsw> tjaalton: if around ^
-queuebot:#ubuntu-release- New binary: containerd [amd64] (groovy-proposed/main) [1.3.4-0ubuntu4] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-google-blueprint [ppc64el] (groovy-proposed/universe) [0.0~git20200513.3017498-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-fftw [ppc64el] (groovy-proposed/universe) [1.0-6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-google-protobuf [ppc64el] (groovy-proposed/universe) [1.23.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ldc [amd64] (groovy-proposed/universe) [1:1.21.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fades [amd64] (groovy-proposed/universe) [9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-emersion-go-maildir [amd64] (groovy-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-hashicorp-go-slug [amd64] (groovy-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-la5nta-wl2k-go [amd64] (groovy-proposed/universe) [0.7.0+ds.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-hectane-go-acl [amd64] (groovy-proposed/universe) [0.0~git20190604.da78bae-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-mdlayher-raw [amd64] (groovy-proposed/universe) [0.0~git20191009.50f2db8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-google-blueprint [amd64] (groovy-proposed/universe) [0.0~git20200513.3017498-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-scylladb-termtables [amd64] (groovy-proposed/universe) [0.0~git20191203.c4c0b6d-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-linuxdeepin-go-x11-client [amd64] (groovy-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-k8s-sigs-structured-merge-diff [amd64] (groovy-proposed/universe) [3.0.0+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-fftw [amd64] (groovy-proposed/universe) [1.0-6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-mdlayher-ethernet [amd64] (groovy-proposed/universe) [0.0~git20190606.0394541-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-sourcehut-sircmpwn-getopt [amd64] (groovy-proposed/universe) [0.0~git20191230.23622cc-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-xtaci-tcpraw [amd64] (groovy-proposed/universe) [1.2.25-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-google-protobuf [amd64] (groovy-proposed/universe) [1.23.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-google-blueprint [arm64] (groovy-proposed/universe) [0.0~git20200513.3017498-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-fftw [arm64] (groovy-proposed/universe) [1.0-6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-google-blueprint [armhf] (groovy-proposed/universe) [0.0~git20200513.3017498-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-google-protobuf [arm64] (groovy-proposed/universe) [1.23.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-google-blueprint [s390x] (groovy-proposed/universe) [0.0~git20200513.3017498-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-fftw [s390x] (groovy-proposed/universe) [1.0-6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-google-protobuf [s390x] (groovy-proposed/universe) [1.23.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-google-blueprint [riscv64] (groovy-proposed/universe) [0.0~git20200513.3017498-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ldc [armhf] (groovy-proposed/universe) [1:1.21.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ldc [arm64] (groovy-proposed/universe) [1:1.21.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (focal-proposed/main) [0.136ubuntu6 => 0.136ubuntu6.1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (focal-proposed) [5.4.0-1012.12]
-queuebot:#ubuntu-release- New binary: golang-k8s-sigs-structured-merge-diff [amd64] (groovy-proposed/universe) [3.0.0+ds1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-xtaci-tcpraw [amd64] (groovy-proposed/universe) [1.2.25-2] (no packageset)
#ubuntu-release 2020-05-30
<LocutusOfBorg> hello, I'm merging debhelper, I found something requiring debhelper >= 13.1 such as telegram-purple
-queuebot:#ubuntu-release- New binary: r-cran-fftw [armhf] (groovy-proposed/universe) [1.0-6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-fftw [riscv64] (groovy-proposed/universe) [1.0-6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: r-other-ascat [amd64] (groovy-proposed/universe) [2.5.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: sra-sdk [amd64] (groovy-proposed/universe) [2.10.6+dfsg-5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: lvm2 (focal-proposed/main) [2.03.07-1ubuntu1 => 2.03.07-1ubuntu1.20.04.1] (core, i386-whitelist)
<LocutusOfBorg> vorlon, what is your opinion about pushing libguestsfs and yara to groovy? it will of course increase riscv64 uninstability count because of vim...
<vorlon> LocutusOfBorg: small transition, doesn't seem urgent, and I've been working on the vim build failure
<LocutusOfBorg> ok as you wish, I would like to merge libguestsfs from debian, this is why I asked
<LocutusOfBorg> vorlon, please reject lvm2 from focal-proposed ^^
<LocutusOfBorg> xnox, your intramfs update seems not building
<LocutusOfBorg> its a documentation change needed
<xnox> LocutusOfBorg:  hm
<xnox> something is wrong on my machine
<xnox> cause it's like a second initramfstools upload from me, that builds locally, but fails in groovy
<LocutusOfBorg> xnox, I can tell you why
<LocutusOfBorg> you need at least shellcheck 0.7.1-1
<xnox> hm
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (focal-proposed/main) [0.136ubuntu6 => 0.136ubuntu6.20.04.1] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (focal-proposed/main) [0.136ubuntu6 => 0.136ubuntu6.20.04.3] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: libpod [s390x] (groovy-proposed/universe) [1.6.4+dfsg1-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: mumps [amd64] (groovy-proposed/universe) [5.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libpod [riscv64] (groovy-proposed/universe) [1.6.4+dfsg1-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpod [amd64] (groovy-proposed/universe) [1.6.4+dfsg1-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: mumps [ppc64el] (groovy-proposed/universe) [5.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libpod [ppc64el] (groovy-proposed/universe) [1.6.4+dfsg1-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: mumps [s390x] (groovy-proposed/universe) [5.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libpod [arm64] (groovy-proposed/universe) [1.6.4+dfsg1-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpod [armhf] (groovy-proposed/universe) [1.6.4+dfsg1-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: mumps [arm64] (groovy-proposed/universe) [5.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mumps [armhf] (groovy-proposed/universe) [5.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pagekite [amd64] (groovy-proposed/universe) [1.5.0.191126-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted mumps [amd64] (groovy-proposed) [5.3.1-2]
-queuebot:#ubuntu-release- New: accepted mumps [armhf] (groovy-proposed) [5.3.1-2]
-queuebot:#ubuntu-release- New: accepted mumps [s390x] (groovy-proposed) [5.3.1-2]
-queuebot:#ubuntu-release- New: accepted r-other-ascat [amd64] (groovy-proposed) [2.5.2-2]
-queuebot:#ubuntu-release- New: accepted mumps [arm64] (groovy-proposed) [5.3.1-2]
-queuebot:#ubuntu-release- New: accepted pagekite [amd64] (groovy-proposed) [1.5.0.191126-2]
-queuebot:#ubuntu-release- New: accepted mumps [ppc64el] (groovy-proposed) [5.3.1-2]
-queuebot:#ubuntu-release- New: accepted sra-sdk [amd64] (groovy-proposed) [2.10.6+dfsg-5]
-queuebot:#ubuntu-release- New: accepted golang-github-google-blueprint [arm64] (groovy-proposed) [0.0~git20200513.3017498-1]
-queuebot:#ubuntu-release- New: accepted golang-github-google-blueprint [riscv64] (groovy-proposed) [0.0~git20200513.3017498-1]
-queuebot:#ubuntu-release- New: accepted golang-github-xtaci-tcpraw [amd64] (groovy-proposed) [1.2.25-2]
-queuebot:#ubuntu-release- New: accepted golang-google-protobuf [s390x] (groovy-proposed) [1.23.0-1]
-queuebot:#ubuntu-release- New: accepted ldc [arm64] (groovy-proposed) [1:1.21.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-fftw [arm64] (groovy-proposed) [1.0-6-2]
-queuebot:#ubuntu-release- New: accepted r-cran-fftw [riscv64] (groovy-proposed) [1.0-6-2]
-queuebot:#ubuntu-release- New: accepted golang-github-google-blueprint [armhf] (groovy-proposed) [0.0~git20200513.3017498-1]
-queuebot:#ubuntu-release- New: accepted golang-google-protobuf [arm64] (groovy-proposed) [1.23.0-1]
-queuebot:#ubuntu-release- New: accepted ldc [armhf] (groovy-proposed) [1:1.21.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-fftw [s390x] (groovy-proposed) [1.0-6-2]
-queuebot:#ubuntu-release- New: accepted golang-github-google-blueprint [s390x] (groovy-proposed) [0.0~git20200513.3017498-1]
-queuebot:#ubuntu-release- New: accepted r-cran-fftw [armhf] (groovy-proposed) [1.0-6-2]
-queuebot:#ubuntu-release- New: accepted golang-k8s-sigs-structured-merge-diff [amd64] (groovy-proposed) [3.0.0+ds1-2]
-queuebot:#ubuntu-release- New: accepted golang-github-google-blueprint [amd64] (groovy-proposed) [0.0~git20200513.3017498-1]
-queuebot:#ubuntu-release- New: accepted golang-github-hectane-go-acl [amd64] (groovy-proposed) [0.0~git20190604.da78bae-2]
-queuebot:#ubuntu-release- New: accepted golang-github-linuxdeepin-go-x11-client [amd64] (groovy-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-mdlayher-raw [amd64] (groovy-proposed) [0.0~git20191009.50f2db8-1]
-queuebot:#ubuntu-release- New: accepted golang-github-xtaci-tcpraw [amd64] (groovy-proposed) [1.2.25-1]
-queuebot:#ubuntu-release- New: accepted golang-k8s-sigs-structured-merge-diff [amd64] (groovy-proposed) [3.0.0+ds1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-fftw [amd64] (groovy-proposed) [1.0-6-2]
-queuebot:#ubuntu-release- New: accepted golang-github-hashicorp-go-slug [amd64] (groovy-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-mdlayher-ethernet [amd64] (groovy-proposed) [0.0~git20190606.0394541-1]
-queuebot:#ubuntu-release- New: accepted golang-google-protobuf [amd64] (groovy-proposed) [1.23.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-la5nta-wl2k-go [amd64] (groovy-proposed) [0.7.0+ds.1-1]
-queuebot:#ubuntu-release- New: accepted golang-sourcehut-sircmpwn-getopt [amd64] (groovy-proposed) [0.0~git20191230.23622cc-1]
-queuebot:#ubuntu-release- New: accepted golang-github-scylladb-termtables [amd64] (groovy-proposed) [0.0~git20191203.c4c0b6d-1]
-queuebot:#ubuntu-release- New: accepted fades [amd64] (groovy-proposed) [9.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-google-blueprint [ppc64el] (groovy-proposed) [0.0~git20200513.3017498-1]
-queuebot:#ubuntu-release- New: accepted ldc [amd64] (groovy-proposed) [1:1.21.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-fftw [ppc64el] (groovy-proposed) [1.0-6-2]
-queuebot:#ubuntu-release- New: accepted golang-github-emersion-go-maildir [amd64] (groovy-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted python-altair [amd64] (groovy-proposed) [4.0.1-2]
-queuebot:#ubuntu-release- New: accepted golang-google-protobuf [ppc64el] (groovy-proposed) [1.23.0-1]
-queuebot:#ubuntu-release- New binary: mumps [riscv64] (groovy-proposed/universe) [5.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: petsc [amd64] (groovy-proposed/universe) [3.13.1+dfsg1-2] (no packageset)
#ubuntu-release 2020-05-31
-queuebot:#ubuntu-release- New binary: petsc [ppc64el] (groovy-proposed/universe) [3.13.1+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: petsc [s390x] (groovy-proposed/universe) [3.13.1+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: petsc [arm64] (groovy-proposed/universe) [3.13.1+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: petsc [armhf] (groovy-proposed/universe) [3.13.1+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: guile-ssh [s390x] (groovy-proposed/universe) [0.12.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: guile-ssh [ppc64el] (groovy-proposed/universe) [0.12.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: guile-ssh [amd64] (groovy-proposed/universe) [0.12.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: guile-ssh [arm64] (groovy-proposed/universe) [0.12.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: guile-ssh [armhf] (groovy-proposed/universe) [0.12.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: sphinx-rst-builder [amd64] (groovy-proposed/universe) [0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hopm [amd64] (groovy-proposed/universe) [1.1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hopm [ppc64el] (groovy-proposed/universe) [1.1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: guile-ssh [riscv64] (groovy-proposed/universe) [0.12.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hopm [arm64] (groovy-proposed/universe) [1.1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hopm [armhf] (groovy-proposed/universe) [1.1.6-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted guile-ssh [amd64] (groovy-proposed) [0.12.0-2]
-queuebot:#ubuntu-release- New: accepted guile-ssh [armhf] (groovy-proposed) [0.12.0-2]
-queuebot:#ubuntu-release- New: accepted guile-ssh [riscv64] (groovy-proposed) [0.12.0-2]
-queuebot:#ubuntu-release- New: accepted hopm [arm64] (groovy-proposed) [1.1.6-1]
-queuebot:#ubuntu-release- New: accepted hopm [ppc64el] (groovy-proposed) [1.1.6-1]
-queuebot:#ubuntu-release- New: accepted guile-ssh [arm64] (groovy-proposed) [0.12.0-2]
-queuebot:#ubuntu-release- New: accepted hopm [amd64] (groovy-proposed) [1.1.6-1]
-queuebot:#ubuntu-release- New: accepted sphinx-rst-builder [amd64] (groovy-proposed) [0.0.3-1]
-queuebot:#ubuntu-release- New: accepted guile-ssh [ppc64el] (groovy-proposed) [0.12.0-2]
-queuebot:#ubuntu-release- New: accepted hopm [armhf] (groovy-proposed) [1.1.6-1]
-queuebot:#ubuntu-release- New: accepted guile-ssh [s390x] (groovy-proposed) [0.12.0-2]
-queuebot:#ubuntu-release- New: accepted petsc [amd64] (groovy-proposed) [3.13.1+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted petsc [armhf] (groovy-proposed) [3.13.1+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted petsc [s390x] (groovy-proposed) [3.13.1+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted mumps [riscv64] (groovy-proposed) [5.3.1-2]
-queuebot:#ubuntu-release- New: accepted petsc [ppc64el] (groovy-proposed) [3.13.1+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted petsc [arm64] (groovy-proposed) [3.13.1+dfsg1-2]
<ginggs> vorlon: morning!  are you taking over the r-api-4.0 rebuilds now?
<ginggs> ubuntu-archive: please RM r-cran-roxygen2 binaries on riscv64, it built there by mistake, see debian #960973
<ubot5> Debian bug 960973 in ftp.debian.org "RM: r-cran-roxygen2 [armel] -- RoQA; cannot be built on this architecture" [Normal,Open] http://bugs.debian.org/960973
<xnox> are s390x autopkgtest runners somehow lagging? i thought they are usually done ahead of amd64 or power, but somehow it's now even behind arm
-queuebot:#ubuntu-release- New binary: amule [amd64] (groovy-proposed/universe) [1:2.3.2+git20200530.3a77afb-1] (no packageset)
-queuebot:#ubuntu-release- New binary: amule [ppc64el] (groovy-proposed/universe) [1:2.3.2+git20200530.3a77afb-1] (no packageset)
-queuebot:#ubuntu-release- New binary: amule [s390x] (groovy-proposed/universe) [1:2.3.2+git20200530.3a77afb-1] (no packageset)
-queuebot:#ubuntu-release- New binary: amule [armhf] (groovy-proposed/universe) [1:2.3.2+git20200530.3a77afb-1] (no packageset)
-queuebot:#ubuntu-release- New binary: amule [arm64] (groovy-proposed/universe) [1:2.3.2+git20200530.3a77afb-1] (no packageset)
-queuebot:#ubuntu-release- New binary: amule [riscv64] (groovy-proposed/universe) [1:2.3.2+git20200530.3a77afb-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: telegram-desktop (focal-proposed/universe) [2.0.1+ds-1build1 => 2.1.7+ds-2~ubuntu20.04.1] (no packageset)
<tumbleweed> I'd be interested to know if anyone can reproduce the amd64 test failure on ruby-bio. It looks like a totally bog standard ruby import failing. And I can't reproduce
-queuebot:#ubuntu-release- New binary: golang-github-containers-ocicrypt [amd64] (groovy-proposed/universe) [1.0.2-3] (no packageset)
<vorlon> ginggs: seems, perhaps; I had started batch uploads before seeing that you had done some
-queuebot:#ubuntu-release- New binary: lsp-plugins [amd64] (groovy-proposed/universe) [1.1.22-0ubuntu1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: lsp-plugins [arm64] (groovy-proposed/universe) [1.1.22-0ubuntu1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: lsp-plugins [armhf] (groovy-proposed/universe) [1.1.22-0ubuntu1] (ubuntustudio)
-queuebot:#ubuntu-release- New: accepted amule [amd64] (groovy-proposed) [1:2.3.2+git20200530.3a77afb-1]
-queuebot:#ubuntu-release- New: accepted amule [armhf] (groovy-proposed) [1:2.3.2+git20200530.3a77afb-1]
-queuebot:#ubuntu-release- New: accepted amule [riscv64] (groovy-proposed) [1:2.3.2+git20200530.3a77afb-1]
-queuebot:#ubuntu-release- New: accepted golang-github-containers-ocicrypt [amd64] (groovy-proposed) [1.0.2-3]
-queuebot:#ubuntu-release- New: accepted amule [arm64] (groovy-proposed) [1:2.3.2+git20200530.3a77afb-1]
-queuebot:#ubuntu-release- New: accepted amule [s390x] (groovy-proposed) [1:2.3.2+git20200530.3a77afb-1]
-queuebot:#ubuntu-release- New: accepted amule [ppc64el] (groovy-proposed) [1:2.3.2+git20200530.3a77afb-1]
-queuebot:#ubuntu-release- New binary: paraglob [amd64] (groovy-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: petsc4py [amd64] (groovy-proposed/universe) [3.13.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: paraglob [ppc64el] (groovy-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: paraglob [arm64] (groovy-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: paraglob [armhf] (groovy-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: petsc4py [ppc64el] (groovy-proposed/universe) [3.13.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: slepc [amd64] (groovy-proposed/universe) [3.13.2+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: slepc [ppc64el] (groovy-proposed/universe) [3.13.2+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: paraglob [riscv64] (groovy-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: petsc4py [armhf] (groovy-proposed/universe) [3.13.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: petsc4py [arm64] (groovy-proposed/universe) [3.13.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: petsc4py [s390x] (groovy-proposed/universe) [3.13.0-2] (no packageset)
