#ubuntu-release 2010-04-26
<ScottK> james_w: Thanks for the syncs.
<ScottK> james_w and slangasek: Still a lot of removals need processing.
<james_w> ScottK: np, I'll be around for a few minutes tomorrow morning, so I'll see if I have time to get to them. I'll have time to do it before release, but the sooner the better.
<ScottK> OK.  Great.  Have a good night.
<ScottK> The  libgettext-ruby in queue should fix the current package FTBFS.  It's my upload, so please review and accept.
<ScottK> Ah.  There it is.
<ScottK> kirkland: My condolences on #ubuntu-devel.
<kirkland> ScottK: thanks
<kirkland> ScottK: that was a frustrating conversation
<ScottK> Yeah, it was frustrating even to watch.
<kirkland> ScottK: i'm emailing ubuntu-server@ now, asking if anyone else can reproduce it
<kirkland> ScottK: it's the most basic RAID1 install, and it fails entirely
<ScottK> Fortunately the general advice for LTS - LTS upgrades is to wait for .1, so hopefully that gives us some time for most server upgrades.
<kirkland> ScottK: right
<kirkland> ScottK: thanks for shoulder to lean on; i'm out for the night ;-)
<ScottK> Ooops.  Meant to have that conversation in -server.
 * cjwatson accepts plymouth
<ScottK> cjwatson: Would you please accept libticalcs.  We unscrewed some package naming confusion between Debian and Ubuntu earlier today and got a bit of a library transition to do as a result.  That one needs to go in first.
<cjwatson> done
<Keybuk> cjwatson: if slangasek should look at that lvm upload, be sure someone holds his jaw up - it could injure him if it hits the floor too hard
<Keybuk> it turns out that the reason we've been having lvm issues on boot is ...
<Keybuk> ... because devmapper was *ignoring* devices on boot
<ScottK> cjwatson: Thanks.
<pitti> slangasek, ScottK: so, clamav passes our rather extensive qa-regression-testing check (with a local build), and I couldn't see anything obviously bad, so I had a leap of faith and accepted it last night; just run the tests again on the final lucid .debs, works fine
<pitti> s/just run/I just ran/
<ScottK> pitti: Someone accepted it.  I assume slangasek.
<slangasek> Keybuk: you have failed to adequately account for jet lag and I now have a double dislocation of the mandible without even the pleasure of eating a wicked cheeseburger
<Keybuk> the burger from the Park Plaza room service is pretty passable actually
<ScottK> pitti: Unfortunately, sgran found a problem yesterday, so I have my first SRU (it's not a regression from this last upload, so accepting it was still progress)
<slangasek> Keybuk: however, before accepting, I'm going to look at the package history to see what idiot, as you put it, did think this was a good idea
<Keybuk> slangasek: oh, I know now
<Keybuk> upstream
<Keybuk> akg
<Keybuk> err, agk
<Keybuk> akg make headphones
<Keybuk> nice ones
<pitti> my wife loves her AKG headphones indeed :)
<slangasek> Keybuk: alright - so what gave them the idea?
<Keybuk> so
<Keybuk> the way devmapper works is that you always get an "add /block/dm-0" event first
<Keybuk> that creates the device, and you need the device to load the table into it
<Keybuk> so after loading the table, you then get a "change /block/dm-0" event
<Keybuk> and that's the point at which it might actually have a filesystem
<Keybuk> so it sounds very logical that you'd always ignore the add events
<Keybuk> except "add" events are what "udevadm trigger" (ie. coldplug) generates
<slangasek> right, that explains why we need it, but why did upstream ever think it was ok to ignore these events?
<pitti> Keybuk: so our hotplugging doesn't have STARTUP==1 any more?
<pitti> that's what the comment above seems to suggest
<Keybuk> pitti: it never has
<pitti> perhaps it does have in Debian?
<Keybuk> in fact, it's pretty much nearly impossible to get that into the environment ;)
<Keybuk> no, it doesn't in Debian either
<Keybuk> ENV{} is limited to the environment from the kernel
<Keybuk> by design in udev
<Keybuk> so, err, you'd need the kernel to somehow know you were running udevadm ;)
<Keybuk> from what I can tell
<Keybuk> reading through the history
<Keybuk> they thought udev should add this STARTUP thing
<Keybuk> then they could ignore "add"
<Keybuk> and then they got as far as talking to kay who explained they were wrong
<Keybuk> and then they backed it out again
<Keybuk> (it's not in the current git, which is why I felt safe removing it again)
<pitti> so, I don't see a rule which doesn't look idempotent at first sight
<Keybuk> pitti: I don't understand what you mean
<pitti> Keybuk: like, causing bad effects when you run them twice
<pitti> except for creating the symlinks much earlier
<pitti> but we (hopefully) don't have anything during boot which watches for symlinks to appear; we use the uevents either way
<Keybuk> http://sources.redhat.com/git/gitweb.cgi?p=lvm2.git;a=commitdiff;h=2c0df9552fd46bbf44c10d8fcfba3c4ce1f7d828#patch3
<Keybuk> right, I think agk just thought "we don't need to process add events", and made a release
<Keybuk> and then they learned that they did, and undid it
<Keybuk> and the bad release was the one that we merged
<pitti> mountall looks fine, accepting
<pitti> (yay for being able to cancel fsck again!)
<slangasek> pitti: modulo my comment in the bottom of that bug log :)
<ara> good morning
<ara> happy release week everyone
<Keybuk> slangasek: which bug# is that?
<pitti> bug 562811?
<ubottu> Launchpad bug 562811 in plymouth "[Lucid] fsck cannot be cancelled in Plymouth" [High,Fix released] https://launchpad.net/bugs/562811
<slangasek> which I haven't had a chance to debug yet, I only just found that issue after landing in London and it may have been a bug introduced by one or more of the changes in the latest uploads - though if that's the only bug we have, it's not a regression since cancelling didn't work before either
<slangasek> Keybuk: ^^ that one, yes
<Keybuk> which comment?
<slangasek> oh
<slangasek> not that bug, no
<slangasek> 'sec
<Keybuk> k, I can grep
<slangasek> bug #559761
<ubottu> Launchpad bug 559761 in plymouth "mountall needs to flush plymouth message queue before emitting upstart events" [High,Fix released] https://launchpad.net/bugs/559761
<slangasek> https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/559761/comments/26
<ubottu> Ubuntu bug 559761 in plymouth "mountall needs to flush plymouth message queue before emitting upstart events" [High,Fix released]
<slangasek> (I don't remember seeing the bug prior to making the last change to plymouth)
 * slangasek waves to ara 
<Keybuk> hmm
<slangasek> Keybuk: in more detail: when I hit 'C', the first two fscks appear to already be running, and exit with code 32, which mountall handles gracefully.  The other two fscks, which I never actually see running, exit with code 8 (from memory), which mountall does *not* handle gracefully; then I'm given the error prompt, then I'm given the *second* error prompt, then mountall stops talking to me
<ScottK> Whoever has been accepting my uploads, tiemu ^^^ finishes getting us through the libticables transition we didn't know we were stuck in the middle of until yesterday.
<Keybuk> shouldn't they all end with status == SIGTERM ?
<slangasek> (or to plymouth)
<Keybuk> le sigh
<slangasek> Keybuk: unless you think that particular bug affects more than just the fsck cancelling case, I think the fix should be deferred to SRU
<Keybuk> who will do the SRU?
<slangasek> whoever?
<Keybuk> we're all hard at work on completely different things next cycle ;)
<slangasek> and I don't think that's a counterargument for the need to defer it to post-release; candidate images need to start rolling today
<Keybuk> sure ;)
<Keybuk> rather, is this a bug you think we could live with for the forseeable future?
<slangasek> I could.  I'm not sure if all our users will.
<Keybuk> then we should at least debug it this week
<Keybuk> and queue as a zero-day fix if it's obvious
<slangasek> agreed
<slangasek> sorry, by "SRU" I certainly didn't mean to imply "let's wait 'til next week"
<Keybuk> so, just to confirm
<pitti> (-proposed is open for uploads; there's a bunch of them already)
<slangasek> ok, accepting lvm2; I agree that looks safe, though I'll regression-test today once it's in the archive
<Keybuk> you have three fscks running
<Keybuk> you press C
<slangasek> Keybuk: four
<Keybuk> one of them is cancelled
<slangasek> two
<Keybuk> an error appears for the other
<slangasek> :)
<Keybuk> and pressing I on that doesn't update plymouth with the third?
<slangasek> pressing I *does* update plymouth with the fourth
<Keybuk> oh
<slangasek> pressing I at the prompt for the *fourth* does nothing
<Keybuk> so what's the bug then?
<Keybuk> oh
<Keybuk> I bet I can see it
<Keybuk>                 if ((mnt->error != ERROR_FSCK_FAILED)
<Keybuk>                     && (mnt->error == ERROR_FSCK_FAILED_HARD))
<Keybuk>                         break;
<Keybuk> la la la
<Keybuk> I bet that second one should be != ;-)
<slangasek> two bugs - one clearly a mountall bug, that it thinks there were "serious errors" when there shouldn't have been (log never even shows fsck started for these two fses), and the other I'm not sure whose fault it is, that mountall sends a message to plymouth and doesn't act on the answer
<slangasek> heh, probably? :)
<Keybuk> yeah
<Keybuk> that's why it doesn't act on the answer
<Keybuk> as to "serious errors", that means e2fsck is returning the wrong error code
<Keybuk> e2fsck(8) claims it will return 32 if cancelled, not 8 ;-)
<Keybuk> I wonder whether it's because it's killed when not "in progress"
<Keybuk> maybe we should ignore those
<Keybuk> yeah, confirmed from the e2fsck source
<pitti> ScottK: tiemu> accepted
<ScottK> pitti: Thanks.
<Keybuk> slangasek: SRU candidate just uploaded to my PPA, please test once built ;P
<mantiena> Hi all
<Mirv> for understanding bug priorization, I'd like to know if 8.04 LTS update-manager will start to offer 10.04 LTS upgrades only in 10.04.1 timeframe, or earlier?
<slangasek> Keybuk: you've empirically confirmed that swapping the == for a != fixes the failure to handle 'I'?  if not, I'll want to test that part separately, so that it's not hidden by your fix for the fsck return codes
<Keybuk> slangasek: well, it's clearly wrong
<slangasek> (I'll feel better if there's hard confirmation that this isn't a regression I caused)
<Keybuk> I never put != && == in the same if statement
<Keybuk> either they're both supposed to be == or they're both supposed to be !=
<slangasek> sure... :)
<Keybuk> and I know they're both supposed to be !=
<slangasek> I still want to confirm that fixing this actually fixes the code path where multiple fses have 'serious errors'
<Keybuk> cause I know what that if is guarding against
<Keybuk> oh, sure
<Keybuk> that's why I asked you to test ;P
<slangasek> does your ppa upload not also include the fix for the fsck return codes?
<slangasek> if it does, I'll have to think up another way to cook up a test case
<Keybuk> it does
<slangasek> ok
<Keybuk> you can always just checkout the rev before and build it yourself
<slangasek> I'll probably do a local build first to test the one change , yeah
<mantiena> Maybe someone could tell me when new daily image will be uploaded into cdimage.ubuntu.com ? There are ~150 updated packages since release candidate image (build on April 19), including ubiquity-casper, ubiquity installer, libc and other important packages, it would be nice to have an ability to test these improvements
<slangasek> mantiena: today
<slangasek> (but not for a couple of hours, yet)
<mantiena> slangasek: thanks
<slangasek> mvo: do you know the answer to Mirv's question above?  Has any decision been taken wrt when we'll turn on LTS->LTS upgrades by default?
<mvo> slangasek: last I talked about this with robbiew was that we will turn it on around the .1 time
<Keybuk> slangasek: but the code was wrong
<Keybuk> now the code is right ;)
<Keybuk> I feel the improved harmony in the universe
<Keybuk> it's like a sixth sense
<Keybuk> <g>
<slangasek> Mirv: see mvo's comment above for the answer
<slangasek> Keybuk: heh - hopefully in addition to the code being right, the bugs go away ;)
<Keybuk> the bugs just move
<Keybuk> but they only move when you're not looking at them
<Keybuk> changing the code just takes away their home
<Keybuk> they soon find a new home
<Mirv> slangasek: thanks, then 8.04->10.04 upgrade problem is not that critical at this point yet
<mvo> Mirv: what upgrade problem is that?
<Mirv> mvo: well the openoffice.org-voikko, bug #562948 - dependency cycle
<ubottu> Launchpad bug 562948 in update-manager "Upgrade 8.04 LTS -> 10.04 LTS fails at circular dependency with openoffice.org-voikko" [Undecided,New] https://launchpad.net/bugs/562948
<Mirv> mvo: you might have an idea what should be done, since you fixed the extensions bundled in OOo source package
<mvo> Mirv: let me have a look
<mvo> Mirv: yeah, I wonder if we can use something similar here
<Mirv> nice thing is cleanly failing out and restoring system state
<ogra> pitti, hmm, the util-linux task should have stayed open (or moved to e2fsprogs), the actual bug isnt fixed with the initramfs-tools/flash-kernel workaround, thanks for closing flash-kernel manually though
<ogra> (talking about bug 563618)
<ubottu> Launchpad bug 563618 in initramfs-tools "Ignoring a broken clock results in infinite reboots; not ignoring results in fsck failure; no solution to this problem" [High,Fix released] https://launchpad.net/bugs/563618
<Keybuk> right, should be e2fsprogs
<ogra> Keybuk, !! back in UK ?
<Keybuk> I talked with Ted at LFC and he seemed persuaded that broken_system_clock=true should ignore the timestamps, rather than try and fix them
<Keybuk> ogra: no, in SF still
<Keybuk> (just about to go to bed)
<ogra> ah, i was wondering ybout the time :)
<ogra> *about
<Keybuk> midnight here ;)
 * ogra creates an upstream task for the bug
<stgraber> slangasek: just found an issue with LTSP install on Edubuntu. I have a tentative fix for it and am testing it now. If it works, I'll upload edubuntu-artwork again and then will need a respin of the DVD image.
<pitti> ogra: ah, please reopen then
<stgraber> (yeah, I switched timezone yesterday and am now in Europe until after UDS)
<ogra> pitti, already sorted, i opened a proper upstream task etc
<Jeeves_> Hi all
<Jeeves_> The jigdo images for Lucid on the releases mirrors seem to be broken
<pitti> Jeeves_: I suppose many of the RC debs just disappeared as they were replaced by newer versions of packages
<stgraber> ^ that one fixes an Edubuntu-only issue, not critical but good to have for release (guest accounts for Live-ltsp were using /bin/sh instead of /bin/bash as default shell)
<pitti> cjwatson: I suppose this ubiquity upload really needs to go onto the next images? (slangasek seemed eager to start image building now)
<slangasek> stgraber: why does edubuntu-artwork need another upload for the LTSP issue?
<stgraber> because the edubuntu-dvd specific scripts are in -artwork for now ... (will be split in another package in maverick)
<slangasek> pitti: accepted, yes
<cjwatson> pitti: Steve's on it
<pitti> ah, thanks
<pitti> I guess the two of you are sitting side by side now? :-)
<slangasek> across, yes
 * pitti waves to London
<slangasek> stgraber: so there's a corresponding script change that has to be made, in addition to the ltsp change?  If so, I'd like to see that in parallel for review
<slangasek> (the ltsp change itself seems reasonable, as /bin/sh isn't really a sane login shell)
<stgraber> slangasek: it's not the same issue. The ltsp change is for the live-ltsp shell for generated accounts. The edubuntu-artwork change is for our ltsp install script (launched post-install through a launcher on the desktop) where ssh isn't properly started and so the calls to ssh-keyscan made by ltsp-update-sshkeys fail (making ltsp useless after reboot).
<stgraber> anyway, test install should be done in 30min or so, I'll have the upload done just after that if it worked
<slangasek> stgraber: ah, ok; accepting ltsp now
<Jeeves_> pitti: Maybe, yes.
<Jeeves_> But now the jigdo files are unusable?
<cjwatson> yep
<pitti> Jeeves_: yes, that's an unfortunate consequence
<pitti> Jeeves_: it'll be better on the final version, since those packages don't disappeare
<cjwatson> nothing we can do about this without much tighter integration between cdimage and archive; it's been on the wishlist forever, unlikely to change any time soon
<cjwatson> (I think some ... intellectually challenged triager may have closed the bug, but whatever)
<Jeeves_> ok, so the conclusion is that jigdo is unusable? (Fine by me, but than I can also say that on #ubuntu-mirrors, in case people ask)
<cjwatson> that is an overreaching conclusion
<pitti> Jeeves_: no, jigdo itself is awesome; just the jigdo files for beta/RC are
<cjwatson> the RC jigdo files are unusable at this point
<cjwatson> daily-build jigdo files work fine
<Jeeves_> okidoki.
<Jeeves_> Thanks!
<slangasek> "unusable" - well, I guess you could use them as a basis for rsyncing or zsyncing
<Jeeves_> slangasek: Not if the files it mentions don't exist :)
<slangasek> Jeeves_: it won't be able to fully piece together an image, but it will get much of the way there
<Jeeves_> probably yes.
<Jeeves_> i've never seen the upside of creating your own images :)
<Jeeves_> long live .iso! :)
<stgraber> well, it's useful when you already have a local package mirror and don't want a cdimage mirror as well (though I usually rsync/zsync the .iso instead of playing with jigdo)
<pitti> the best part is that you can scan /var/cache/apt/archives, and other CD images for missing pieces
<slangasek> or, as I said, you can just let it scan what it can, and then use the resulting partial image as a basis for rsync/zsync
<slangasek> which does give improved results when you have a local mirror and a majority of packages are still available
<Jeeves_> I guess I'm just to spoiled with gigabit links and 20mbit dsl :)
<pitti> Jeeves_: yes; jigdo is too much hassle for bandwidth like that :)
<Jeeves_> :)
<stgraber> slangasek: New ETA for the Edubuntu test install, should be tested in a bit more than 30 minutes. That ssh key bug needed two files to be tweaked because for some reason /etc/init.d/ssh stop in the live environment doesn't stop ssh ... only "stop ssh" does.
<cjwatson> yup
<cjwatson> because /etc/init.d/ssh had to be kept around for chroots, and isn't just a link to upstart-job
<Jeeves_> btw, a similar bug is in rsyslogd
<Jeeves_> /etc/default/rsyslogd exists, but isn't used
<cjwatson> that's not a similar bug, it's an entirely different bug
<cjwatson> unless "vaguely related to init" means similar :)
<slangasek> stgraber: ok - I've set the trigger already for the candidate builds, I believe the edubuntu packages will all be published before the edubuntu builds start :)
<Jeeves_> cjwatson: It's similar'ish :)
<Jeeves_> And should be easy to fix
<cjwatson> it's not similarish
<cjwatson> it's also at least in part by design.  upstart jobs are making reduced use of /etc/default/ since they're much easier to edit and maintain directly
<cjwatson> anyway, let's please not have this on #-release
<Jeeves_> cjwatson: I agree. But if you migrate to upstart (which is a good thing), it would be nice if people clean up /etc/default, which is causing confusino
<Jeeves_> I was trying not to :)
<ogra> hmm, was there a mass give-back for universe on the 18th ?
<ogra> looking at the FTBFS logs they all have at least a timestamp from the 18th
<slangasek> stgraber: how's it coming?
<stgraber> slangasek: slowly ... grabbing some lunch now, should have the result by the time I get back. Previous test failed but I don't know if it's my change that didn't work or just because I poked at the environment before the install, so I'm doing one more, then will run the ltsp bit step by step afterwards to make sure everything works as expected. If it's the case, I'll upload, if not, I'll fix and upload :)
<slangasek> stgraber: ok
<ttx> slangasek: got time to review FFe/upstart script on bug 533029 ?
<ubottu> Launchpad bug 533029 in autofs5 "[FFE] autofs5-ldap doesn't work immediately after bootup" [High,Triaged] https://launchpad.net/bugs/533029
<slangasek> lamont: please kill any currently running livefs jobs
<lamont> slangasek: any particular arch?
<cjwatson> all of them, Steve said he forgot to bump CONF.sh in debian-cd
<lamont> right
<lamont> no more livecd rootfs builds going on.  logs may look like someone did a killall apt-get dpkg debootstrap. :-D
<slangasek> lamont: thanks :)
<slangasek> new run started
<stgraber> slangasek: sorry for the delay but it seems like I can't get two installs to do the same thing ... starting yet another one now
<slangasek> stgraber: heh, ok
<mvo> bdmurray: hi, I tried to reproduce #569941, when you are around, could you give me some more infos on it?
<stgraber> slangasek: I've got to run in 10 minutes, I hope I understood what's going wrong so I'll upload a new edubuntu-artwork that should fix the issue and hope that'll do the trick.
<slangasek> stgraber: ok :)
<ScottK> slangasek: I'm travelling to California today and so don't assume I'm avaialble for anything from nowish to ~14 hours from now.
<ScottK> slangasek: I'm still expecting a seamonkey upload.  The diff will be huge, but we need to get to a version that mozilla supports.  There should be a lightning upload too, but I asked to have asac or someone appropriate sign off on that since it will make sunbird go away.
<slangasek> ScottK: ok - have a good trip, then
<ScottK> Thanks.
<slangasek> cjwatson: does bug #569900 look like a dupe of 542210?
<ubottu> Launchpad bug 569900 in mdadm "mount: mounting /dev/md0 on /root/ failed: Invalid argument" [High,New] https://launchpad.net/bugs/569900
<cjwatson> mdadm> my instinct is not
<cjwatson> 542210 triggers when you run any of raid/lvm/crypto configuration in partman after having set up a raid volume (or inherited one from a previous installation)
<cjwatson> if you only do one pass through the raid configuration tool in the partitioner, and you didn't inherit anything from a previous installation, then it isn't 542210
<slangasek> stgraber: I'm pretty concerned about this "umount in lazy mode and force a sync" change
<slangasek> stgraber: can we talk about what problem you were seeing?
<cjwatson> bug 569317
<ubottu> Launchpad bug 569317 in initramfs-tools "compcache/ramzswap support in initrd broken due to typo in /usr/share/initramfs-tools/hooks/compcache:74" [Undecided,Confirmed] https://launchpad.net/bugs/569317
<pitti> argh oversized
<pitti> le sigh, 6 MB growth since RC?
<slangasek> pitti: xfsprogs, jfsutils were missing from RC, which accounts for some; langpacks may account for some more; fix is already in hand, just waiting for some other bits before respinning
<slangasek> cf. bug #569317 in initramfs-tools
<pitti> fix> dropping a langpack, I suppose?
<ubottu> Launchpad bug 569317 in initramfs-tools "compcache/ramzswap support in initrd broken due to typo in /usr/share/initramfs-tools/hooks/compcache:74" [High,Fix committed] https://launchpad.net/bugs/569317
<slangasek> pitti: yep - Hindi, Bengali
<slangasek> (one on each arch)
<micahg> are we too late to sync a change in universe from Debian?
<pitti> micahg: technically not, but practically we'll only accept release critical and safe changes
<pitti> such as a two-line change to fix FTBFS, and the like
<slangasek> micahg: I will assume here you're talking about seamonkey, though
<pitti> the universe cutoff point is tomorrow
<micahg> pitti: k
<micahg> slangasek: no
<slangasek> oh
<slangasek> then, meh
<micahg> phpmyadmin had a feature turned on in Debian that should have been turned on before (logging changes made through the web)
<micahg> slangasek: Seamonkey I think is ready and chrisccoulson is reviewing
<slangasek> alright
 * micahg takes it as a 'no' for phpmyadmin
<slangasek> unless there's a reason to consider this critical... that's a no
<micahg> slangasek: k
<slangasek> lamont: can I get another livefs kill please?
<lamont> sigh
<slangasek> if you'd like to work out what we need to do to our scripts to let Ctrl-C work right... :)
<stgraber> slangasek: turned out that moving to lazy umount didn't solve the issue, so I'm back to trying to have the same issue two times in a row so I can fix it ...
<slangasek> stgraber: right; I'm glad that didn't fix it ;)
<lamont> slangasek: so, um, all zero outstanding killed
<slangasek> lamont: "zero outstanding"?
<lamont> yeah - didn't kill anything
<slangasek> lamont: should have been some DVD builds queued?
<lamont> none running
<slangasek> hmm
<lamont> ah, why so there are
<lamont> moment
<slangasek> ok :)
<bdmurray> mvo: I'm trying it again
<stgraber> slangasek: well, when one install you get a bunch of files and the next you don't, you start to wonder if there's something wrong with that partition you were supposed to umount 10s before ;) but yeah, good that it didn't fix it :)
<slangasek> stgraber: the other thing is, if a lazy mount had any effect at all, it's not guaranteed that the final umount would DTRT either
<slangasek> actually... I don't think it works at all because the kernel gives you a "not mounted" whinge
<lamont> slangasek: shiny.  kick it in the head
<stgraber> slangasek: yeah, I forgot to drop that final umount, it shouldn't have been there.
<slangasek> stgraber: right - and furthermore, anything that *was* holding the mount point open could still be writing...
<slangasek> lamont: thankee :)
<slangasek> stgraber: so - rejected the previous upload from the queue
<stgraber> slangasek: thanks
<cjwatson> jarnos: https://wiki.ubuntu.com/LucidLynx/TechnicalOverview is the central page
<slangasek> jarnos: how are you definining "release notes", then?  there are several possible definitions, I don't know which Xubuntu uses
<jarnos> slangasek: me neither ;) But I think the information on  https://wiki.ubuntu.com/LucidLynx/TechnicalOverview is a good starting point. The challenge is to know which is common with Xubuntu.
<charlie-tca> jarnos: this is a very good starting point - https://wiki.ubuntu.com/Xubuntu/LucidLynx/Beta2
<cjwatson> possible definitions include: a release announcement; a summary of major changes in this release (top of TechnicalOverview); errata (bottom of TechnicalOverview)
<jarnos> charlie-tca: But it is very limited. It does not cover e.g. the "New default open source driver for nVidia hardware" which is available at https://wiki.ubuntu.com/LucidLynx/TechnicalOverview .
<charlie-tca> Did we not link to those notes?
<cjwatson> the Xubuntu notes should really only cover the Xubuntu-specific elements
<charlie-tca> Normally, as a dirivative, we link directly to the Ubuntu release notes and technical overview, so we do not have to repeat them
<jarnos> charlie-tca: we did, but there is the challenge to know what is Ubuntu specific in Ubuntu's release notes.
<cjwatson> "what's new" would be better as a separate entity, since it reduces confusion all round; neither Steve nor I are particularly settled either way on where the errata belong
<charlie-tca> We allow users to read all of it anyway
<charlie-tca> The right place to ask what's new in xubuntu might be #xubuntu-devel, though
<jarnos> I'll have to go now; will be back probably in 2.5 hours or tomorrow.
<jarnos> charlie-tca: Yes we allow users to read all Ubuntu's release notes, but it would be better, if Ubuntu derivatives had Ubuntu specific information separated/removed.
<jarnos> Maybe this kind of separation could be done in Ubuntu release notes. It would be good for official Ubuntu derivatives, like Kubuntu, too.
<jarnos> cjwatson: what do you think about the above?
<lamont> slangasek: dunno if acorn is just really really really busy and ignoring the monitoring, or if you pushed it into a box of scissors.
<lamont> you might want to run whatever livefs build you think you're doing on clementine
<charlie-tca> Ubuntu and Xubuntu upgrade from 8.04, the network manager and volume control applets disappear
<slangasek> lamont: gar, ok; will twiddle the scripts before launching builds, thanks for the heads-up
<stgraber> slangasek: still around ?
<stgraber> seems like I finally have an edubuntu-artwork package that does what it's supposed to :)
<stgraber> it's uploading now, should be in the queue in a few minutes. I'm running a third test-install to make sure it always work but I'm quite confident it should :)
<jarnos> slangasek, cjwatson : now there exist a draft for Xubuntu release notes: https://wiki.ubuntu.com/Xubuntu/LucidLynx/Final/Draft
<stgraber> slangasek: second install confirmed that edubuntu-artwork now works, feel free to respin once it's in the archive (0.1.0-71).
<kirkland> slangasek: around?
#ubuntu-release 2010-04-27
<lamont> slangasek: yeah - almost certainly gone.
<lamont> slangasek: if you knock over clementine, let me know and I'll hijack another buildd to do duty until we get the biobot onsite
<ScottL> how long do we have to complete the latest test cases before release?
 * ScottK looks around.
<ajmitch> hi
<ScottK> Hello.  Made it to the other side of the continent OK.
<ajmitch> oh, you've been travelling?
<ScottK> Yeah, just got to California.
<ScottK> Thus my uncharacteristic quiet online for the last ~12 hours
<ajmitch> Hopefully the queue isn't too unmanageable yet :)
 * ScottK didn't look at the web page yet, but the queuebot doesn't inspire confidence.
 * ajmitch only added a couple of items
<ajmitch> I imagine we'll need to start targetting -proposed for universe tomorrow or the next day?
<ScottK> Yeah, sometime early Wed will be the limit.
<slangasek> stgraber: did you mean for 'kill $!' to be 'kill $ZEN_PID'?
<kirkland> been such a long day
<slangasek> pretty sure it was acpid
<slangasek> since that's what I see in the queue :)
<kirkland> slangasek: ah, probably so
<ScottK> slangasek: Did you just accept the edubuntu-artwork package?
<ScottK> Because I just saved the screenshot of me getting an ack on mod-wsgi and they both showed up building.
<kirkland> slangasek: oh, right; so that fix is by far the least invasive way to solve (the bulk of) the problem for lucid
<kirkland> slangasek: and is pretty clearly a regression
<kirkland> slangasek: i was just checking your pulse on it, in case you wanted it solved differently
<slangasek> kirkland: so, rejecting from the queue, this touches all images and is much too late for us to respin everything for anything short of dataloss or a zero-day security hole; please reupload to lucid-proposed, and please adjust the patch to not silently ignore, e.g., getXconsole not existing
<slangasek> ScottK: yes, accepted it
<kirkland> slangasek: ack
<ScottK> slangasek: OK.  Glad to hear it.  I was a little nervous when I accepted one package and two appeared in the same update.
<slangasek> ScottK: notabug :)
<ScottK> ;-)
<kirkland> slangasek: thanks, EoD, g'night
<slangasek> kirkland: 'night!
<ScottK> slangasek: I'm not sure how relevant to your view of the queue, but I did look through the list of language pack uploads and did not see any non-lang pack stuff mixed in with it.
<slangasek> ScottK: uh - what language pack uploads?
<ScottK> slangasek: for -proposed
<ScottK> ~700 of them
<ScottK> At least in the LP U/I stuff for proposed and release is intermingled.
<slangasek> ah
<slangasek> right, sorry :)
 * slangasek wonders why we have -proposed langpacks so soon
<pitti> slangasek: the last upload apparently was from a previous export accidentally
<pitti> slangasek: so the -proposed ones are the ones which were supposed to be in final
<pitti> but I thought yesterday we agreed to upload them a week after release, to catch some more translations
<pitti> ArneGoetje ^ ? these are more urgent now?
<ara> good morning!
 * slangasek waves
<ArneGoetje> pitti: that's what I discussed with dpm yesterday. Make them available immediately since they were supposed to be on the release ISO anyways. The remaining bugs (incomplete ca@valencia and buggy lithuanian KDE translations) get fixed a bit later, once the issue is fixed in Launchpad code and the translations have been re-uploaded.
<pitti> ArneGoetje: ah, thanks
<stgraber> slangasek: indeed, I meant $ZEN_PID ... though it'll work anyway. Fixing edubuntu-artwork here in case we have to re-upload for whatever reason .
<stgraber> slangasek: got to go for a few hours, I started a rsync of 20100427.1 that just appeared on cdimage, will test it or rsync a newer image when I'm back
<slangasek> stgraber: unfortunately we have to respin everything for a plymouth regression; we're double-stepping to get it in ASAP, but of course this means it'll be at least a few hours before edubuntu final images will be available
<slangasek> lamont: is acorn still awol?
<elmo> slangasek: got rebooted and should be back
 * ogra wonders why that machine is so chaky
<ogra> *shaky
<ogra> clementine didnt have these probs
<ogra> and i dont see anything similar on my bbg3
<elmo> ogra: does your bbg3 board do the same number of livefs builds?
<elmo> if not, it's not a very useful comparison
<ogra> elmo, it doesnt die if i do local livefs builds ... indeed i dont do 10 per day though but i never had a single hang during this cycle
<slangasek> elmo: thanks
<Riddell> ooh, kubuntu builds are go
<slangasek> ttx: eta 30min for ubuntu-server ISOs
<ttx> slangasek: ack
<ogra> slangasek, is omap 20100427 worth testing or do you do another respin ?
<slangasek> ogra: worth testing: yes; another respin: also yes
<ogra> ok :)
 * ogra fires up the install
<slangasek> ETA on the respin is ~4h
<stgraber> slangasek: that's the ETA for omap or is that the ETA for all respin ?
<slangasek> stgraber: all, since the image builds are done after the livefs spins
<slangasek> stgraber: oh, perhaps I should clarify - that's the ETA for all the armel netbook respins, which land at the same time for all subarchs; but other respins for amd64/i386 will continue to arrive in parallel at various points
 * slangasek just realized you were probably asking on account of edubuntu
<slangasek> ttx: ubuntu-server up
<ttx> slangasek: right, but lunch is also up :P
<Riddell> GrueMaster: will you have any spare family members able to test kubuntu netbook on ARM before release?
<GrueMaster> Riddell: Unfortunately, no.  Guess I'll have to do it myself.  :D
<slangasek> lamont: low-priority - why is emacs23 FTBFS on ia64? (no corresponding build log)
<lamont> for the H9, of course.
<lamont> kids->school, breakfast, will look later today
<slangasek> ev: http://iso.qa.ubuntu.com/qatracker/test/4132 - fixed with a shift-reload
<ogra> hrmpf
<ogra> on omap plymouth is really slow ...
<slangasek> plymouth itself?
<ogra> i get a console login prompt before the splash comes up
<ogra> well, there must be some kind of race
<slangasek> eh - so the splash comes up *after* you get a console login prompt?
<ogra> not that i care much with a 600MHz CPU
<ogra> yeah
<slangasek> yuck
<slangasek> yeah, there's a race there
<ogra> i see a login prompt and the cursor blinks about ten times behind the colon before the splash kicks in
<slangasek> I've just never seen it hit before
<ogra> well, extremely slow HW :)
<ogra> even VMs are faster
<slangasek> ogra: current ETA for armel respin is ~1.5h, btw
<ogra> ah, great
<ogra> that leaves me some time to do some testing without panel on the image for asac
<ogra> i assume we dont expect a d-i rebuild anymore ?
<ogra> i.e. i can go on testing netinst too
<slangasek> ogra: and after the splash screen comes up, it still successfully clears itself? or does it get stuck on the screen?
<slangasek> (AFAICS, plymouth-stop.conf should still successfully shut down the splash screen at the end)
<ogra> well, there seems to be a framebuffer issue, it clears itself and eventually i get to X
<ogra> but i can paint with black squares on the screen using my mouse cursor
<slangasek> right - but not a plymouth bug :)
<ogra> i really expect a DSS2 (omap framebuffer driver) issue here though
<ogra> but thats code amit needs to attack post-release anyway and there are no other issues
<ogra> just an uglyness
<Daviey> Hey.. I'm looking for pointers how to proceed with bug #555111.
<ubottu> Launchpad bug 555111 in xmltv "Sync xmltv 0.5.56+cvs20100328-1 (universe) from Debian testing (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/555111
<Daviey> I really don't think it's a good idea to deviate from Debian Testing on this package
<Daviey> The sync closes a nasty bug, which i'm keen to get fixed within 7-14 days of release.
<Daviey> Is it worth raising a FFe at this stage?
<cjwatson> what's the new build-dependency mentioned?
<cjwatson> oh, that's unstable
<cjwatson> this does look as though it requires at least the moral equivalent of a feature freeze exception, although you could convert the existing bug into one rather than bothering to raise a new bug
<Daviey> cjwatson: Okay, i just didn't want to go down the FFe route if there was "no chance".
<Daviey> cjwatson: The build dep adds support for a grabber for a country which didn't exist before.. Other than that, the cvs snapshot is very close to the release.. So it feels like it will be easier to maintain.
<slangasek> Daviey: isn't xmltv on mythbuntu?
<slangasek> would need sign-off from superm1 that it's ok to respin the ISOs
<slangasek> confirmed, it's on mythbuntu as expected
<Daviey> slangasek: yes
<Daviey> slangasek: I think we want a re-spin anyway for the ubiquity UI fixes.
<slangasek> Daviey: that respin is already done
<Daviey> Or has that been done?
<Daviey> ah
<slangasek> and the ISO posted 45 minutes ago
<Daviey> bum
<slangasek> and another respin would delay roughly 2h
<Daviey> i've just ping'd superm1 to see his thoughts
<Daviey> This spin certainly hasn't hit our mirrors yet.
<slangasek> it's there on cdimage.u.c
<Daviey> slangasek: Is there a problem if the shipped ISO is slightly different to the main archive?  (policy, not technically)
<slangasek> Daviey: in general, we guard against it because failing to do so can be a license violation in some cases; that's not an issue here, but it's still not something I want us to be in the habit of
<Daviey> understood
<slangasek> Riddell: will http://kubuntu.org/news/10.04-release be the right url for y'all's announcement?
<slangasek> stgraber: will http://edubuntu.org/news/10.04-release be the right url for edubuntu?
<Riddell> slangasek: http://kubuntu.org/news/10.04-lts-release  let's keep the marketing people happy
<stgraber> slangasek: yep
<slangasek> Riddell: http://www.ubuntu.com/news/ubuntu-10.04-desktop-edition and http://www.ubuntu.com/news/ubuntu-10.04-server-edition say nothing of LTS, but it's your call :)
<slangasek> stgraber: great, thanks
<Riddell> slangasek: tsk.  I'll keep the lts
<slangasek> ScottL: persia has directed me to you for the same question on ubuntustudio - is https://wiki.ubuntu.com/UbuntuStudio/10.04release_notes the plan?
<ScottK> I would appreciate it if some archive admin who has a moment would toss "sync 570497 -S unstable" at mass-sync.
<ScottK> slangasek: I'm not sure if StevenK just ran out of energy, but there is one removal left to deal with in 568778.
<ScottK> If those get done, then I think we're done with ~ubuntu-archive bugs for the cycle.
<cjwatson> ScottK: looking
<cjwatson> (570497)
<ScottK> Thanks.
<cjwatson> done
<ScottK> Great.
<cjwatson> 568778 done too
<slangasek> ah, ta
<slangasek> ogra: omap respin was done on schedule; ISOs posted now to the tracker as well for imx51, dove
<slangasek> GrueMaster, plars: ^^
<GrueMaster> slangasek: On it, thanks.
<plars> slangasek: awesome, thanks
<ScottL> slangasek, i am checking it right now to make sure it's the current one
<slangasek> ScottL: currently, nothing exists at that URL
<ScottL> slangasek, lol, apparently not as it is empty, i'll get it there :)
<slangasek> ok, thanks :)
<ScottK> cjwatson: Thanks again.
<ScottL> slangasek, ubuntu studio release notes are complete
<slangasek> ScottL: thanks!
<ScottL> your welcome :)
<ogra> slangasek, merci
<ScottK> slangasek: I'll be offline for ~9 or 10 hours now.  I'm leaving anjsp in the queue for if you need to stimulate a publisher run.  It fixes the FTBFS, but leaves the package uninstallable, so I'm not worried if it gets in particularly.
<slangasek> ScottK: alrighty, thanks :)
<slangasek> ttx: EC2 posted
<smoser> slangasek, the ec2 build is finished
<slangasek> smoser: yep :)
<slangasek> smoser: just posted to the tracker, a minute before you joined :)
<slangasek> cjwatson: bug #570765
<ubottu> Launchpad bug 570765 in ubiquity "[Lucid] Installer fails to configure grub for dual boot" [Undecided,New] https://launchpad.net/bugs/570765
<stgraber> slangasek: is edubuntu 20100427.2 a final candidate or is another respin already planned for some reason ?
<slangasek> stgraber: final candidate
<stgraber> yeah !
 * stgraber starts rsyncing
<doko> slangasek how are the chances for the final llvm 2.7 upload being accepted?
<doko> slangasek: did the valgrind armel pickup work?
<slangasek> doko: valgrind armel worked, yes
<slangasek> doko: llvm> non-zero chances, it's not on any imagse
<slangasek> images
<doko> slangasek: ok, then I'll prepare clang and llvm-gcc-4.2 as well
<doko> slangasek: I'll try the armel pickup for asis and libgtkada as well
<doko> the llvm fix has the "unfortunate" side effect that it increases the build time on ppc, because the testsuite doesn't crash anymore :-/
<lamont> slangasek: PaS now updates both places at 15 min past the hour, 24 times a day, modulo summertime shifts
<slangasek> lamont: ok, cheers :)
<lamont> and some day, I might get around to finding the wiki page to update
<ogra> slangasek, since we have no iso tracker entry for it ... omap netbook is good to go
<stgraber> slangasek: added 20100427.2 for edubuntu dvd to the tracker so I can enter my results
<slangasek> ogra: ok
<slangasek> stgraber: ok
<stgraber> slangasek: how critical is that grub2 issue reported on iso.qa.ubuntu.com ? Wondering how much effort I should put on the current live images or if I should look at alternate instead.
<ara> Riddell, grub is supposed to add Kubuntu as "Kubuntu" or "Ubuntu" as entry?
<micahg> for any release people, Seamonkey was uploaded earlier and the builders are idle
<charlie-tca> problem with the xubuntu desktop image. 'use the entire disk' partitioning results in all other grub entries not seen except that installation. It doesn't matter how many other installs are present
<charlie-tca> Reinstalling with any other partition method allows you to see the other installations again
<ajmitch> charlie-tca: like bug 570765 ?
<ubottu> Launchpad bug 570765 in ubiquity "[Lucid] no GRUB menu entry for other operating systems" [Undecided,New] https://launchpad.net/bugs/570765
<charlie-tca> Except I don't have windows, and it is hardware
<charlie-tca> That looks like it, though. Thanks
<ajmitch> from the comments it doesn't appear to be specific to having windows
<ajmitch> but at least the bug is known & commented on
<charlie-tca> and apparently won't be fixed. Since it is marked for release notes
 * ajmitch thought the bug for release notes was about the I/O errors being displayed
<charlie-tca> I didn't get any errors.
#ubuntu-release 2010-04-28
<asac> ScottK: hi. i think micah already talked to you that this was coming :) ... seamonkey 2 is in the queue and chrisccoulson confirmd that its working properly etc. so should be fine.
<ScottK> asac: Yes.  We've discussed.  What about lightning?
<micahg> ScottK: chrisccoulson will talk to pitti about it in the morning
<ScottK> OK
<ScottK> By the time I wake up tomorrow it'll likely be later than I'm comfortable accepting it, so don't wait on me.
<micahg> ScottK: we're not uploading for lightning, so either it'll be a binary drop or a source+binary drop
<ScottK> OK, but IIRC the binary removal requires a publisher run which needs an upload to stimulate it, so don't wait too long.
<micahg> ScottK: ok, I'll check with pitti before I go to sleep than and let chrisccoulson make the final decision
<ScottK> They can always sync clamav-data again if they need something to upload.
<micahg> ScottK: I have a universe package that could use a fix :)
<ScottK> Tonight I'm still reviewing/accepting.
<micahg> mediatomb currently has the JS part disabled and someone attached a partial fix
<ScottK> If stuff is uploaded I'll review it, but that sounds to me like a good SRU candidate.
<micahg> ScottK: yeah, I was going to leave it for SRU, but if you need an upload :)
<ScottK> Don't, yet.
<micahg> ScottK: k, I don't have upload rights anyways ;)
<ScottK> I've still got one I'm holding back for slangasek in case of emergency.
<micahg> ScottK: k, sounds good, thanks
<ajmitch> ScottK: I assume most things should be held for SRU now?
<ScottK> ajmitch: I'll still take FTBFS and things that it's important to get in.
<ScottK> But it won't be much longer.
<ajmitch> OK
<micahg> ScottK: a sparc FTBFS on seamonkey isn't a big deal is it? (we'll be updating in about 2 weeks)
<ScottK> micahg: No.  Sparc is pretty broken these days.
<ScottK> Fixing it is preferred, but it would be stunning if there were any sparc seamonkey users.
<micahg> ScottK: it's a just a disable flag to fix, but since it's pretty broke anyways, I figure we can wait till 2.0.5
<ScottK> That's fine.
<micahg> ScottK: how much longer will you be up?
<ScottK> Depends on how my headache does.
<ScottK> An hour or two, probably
<micahg> ScottK: sorry to hear that, I might try for firegpg FTBFS
<slangasek> stgraber: the grub2 issue has been triaged off to release notes, no respins for it - it's straightforward to fix in SRU
<ScottK> slangasek: I'm done reviewing stuff and headed to bed.  I didn't yet call a halt to people uploading Universe FTBFS fixes, so please tell them when it's time to stop.  I still left you anjsp if you need something.
<ScottK> I assume it'll be too late in the morning to for me to accept stuff, so I'll leave it to you to review or not.
<micahg> thanks for firegpg ScottK, I'm trying one more FTBFS
<pitti> Good morning
<slangasek> ScottK: well, the mail sent out at https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-April/000705.html said we would cut off universe packages at April 26, so anything else is going to be only if I'm twiddling my thumbs :)
 * slangasek waves to pitti
<ScottK> micahg: I'm heading to bed, so it'll be up to one of the other release team members to approve if they have time.
<micahg> slangasek: should I not bother with this other FTBFS than?
<ScottK> slangasek: OK.
<micahg> *then
<micahg> ScottK: k, feel better
<slangasek> micahg: you can - I just can't promise that *I* will have time to review and accept it
<micahg> pitti: chrisccoulson will be chatting with you later, but I figured that I'd prime the pump so to speak, WRT lightning-sunbird, we're not sure if we should drop some of the binaries that wouldn't be updated with an SRU or to drop the whole package
<micahg> slangasek: nevermind, the FTBFS is too much for me at this hour
<pitti> micahg: if the current one is unsupportable, then we should perhaps drop the entire package? I remember a discussion about updating it to 2.0?
<micahg> pitti: well, the problem with that one is that upstream is only continuing development of a piece of it
<slangasek> ev, cjwatson: bug #570843 is odd, not sure why this would be turning up so late when we know lucid has already been tested in networked-but-not-really environments before now
<ubottu> Launchpad bug 570843 in ubiquity "[Lucid Lynx RC] Install hangs on a LAN-connected (but no internet) workstation" [Undecided,New] https://launchpad.net/bugs/570843
<pitti> micahg: I'm not a big fan of just removing some binaries of a source; I don't remember a precedent for this, and don't know what could go wrong in soyuz for that
<pitti> micahg: so I'd actually prefer an upload which properly drops those packages, or just remove it completely if it doesn't break (too many) rdepends
<micahg> pitti: k, then we'll probably remove then chrisccoulson can confirm in a few hours
<pitti> thanks
<ara> morning!
<kirkland> slangasek: got your response on https://bugs.edge.launchpad.net/ubuntu/+source/etherboot/+bug/570870 ... what about motu-sru ... still the same?
<ubottu> Ubuntu bug 570870 in etherboot "pxe boot doesn't work with kvm" [Low,In progress]
<kirkland> slangasek: or is that merged with ubuntu-sru too?
<pitti> oh, how was the sparc kde issue sorted out? http://people.canonical.com/~ubuntu-archive/component-mismatches.txt lost all its vpn stuff
<pitti> I approved/promoted the texinfo-doc-nonfree MIR, so that'll be gone soon, too
<pitti> kirkland: it's just ubuntu-sru now
<kirkland> pitti: thanks
<slangasek> pitti: per-arch binary removal :/  the kde failure has mysql-dfsg-5.1 at its root, and doesn't seem tractable - cjwatson gave it a try yesterday
<slangasek> KDE is entirely uninstallable on sparc right now anyway, so I didn't feel bad about doing the binary removal
<pitti> slangasek: ah, ok; I thought as much, thanks for confirming
<pitti> the sparc users will be furious!
<pitti> . o O { both of them! } *cough*
<Jeeves_> :)
<ev> slangasek: fingers crossed that he was using the RC and not a daily
<ev> it sounds like it might be bug 567749, which we fixed post-RC
<ubottu> Launchpad bug 567749 in ubiquity "Broken packages during oem-config" [Undecided,Fix released] https://launchpad.net/bugs/567749
<ev> erm, nevermind.  He wasn't using oem-config.
<ev> trying to reproduce now
<ara> Riddell, around?
<Riddell> ara: hola
<Riddell> ara: grub always says "Ubuntu" to answer your question from yesterday
<ara> Riddell, ok, thanks. Another one :)
<ara> Kubuntu Netbook, when installed in English I get "Konqueror" "KMail" "System Settings" and "Home" in Bookmarks
<ara> but, when installed in Spanish, I only get the first three items
<ara> (not Home)
<Riddell> that'll be a beastie
 * ogra sees the headlines already "No home for that spanish in ubuntu !!!"
<ogra> *the
<ara> hehee
<asac> ScottK: i dont think he has time to do it ... but in case: killing sunbird and just keeping lighting is ok from my pov
<asac> not perfect, but better than killing it completely.
<Riddell> ara: it's patch kubuntu_105_netbook_favourites.diff which adds that, although I think that patch is upstream now.  file a bug on kdebase-workspace anyway
<ara> Riddell, ok, will do, thanks
<slangasek> cjwatson: bug #567592
<ubottu> Launchpad bug 567592 in plymouth "rm: cannot remove `/var/lib/urandom/random-seed': Read-only file system" [Undecided,New] https://launchpad.net/bugs/567592
<smoser> lool, ttx , cjwatson , ttx tells me of mountall issue ?
<cjwatson> lool and I have been trying to run the UEC image under kvm (alone, not via eucalyptus)
<cjwatson> I understand this isn't the usual path, so I don't think there's any cause for panic if your usual tests are passing
<cjwatson> however it did show up an issue or two in plymouth
<ttx> smoser: we were wondering if those could be the source of some of the racy behavior of the images under uec
<smoser> is there backscroll i should read?
<cjwatson> specifically attaching to the session fails if you don't have an initramfs, and if you're then also running the details plugin then plymouth crashes
<ttx> smoser: no, the discussion was live so far :)
<smoser> ok. so you have modified /etc/fstab in the image ?
<smoser> it has hard coded /dev/sda1 as root filesystem
<smoser> never mind that.
<cjwatson> -append "root=/dev/sda"
<cjwatson> didn't touch /etc/fstab
<smoser> yeah, but mountall still gets all upset on /etc/fstab
<smoser> when /dev/sda1 is never going to appear
<smoser> so filesystems event is never going to fire (... i think ... this is memory of a while ago)
<cjwatson> smoser: I understand that the setup I have is going to break for other reasons :)
<cjwatson> so I don't think it's a UEC blocker of any kind
<cjwatson> smoser: but having run into this problem I've been trying to assess what its impact would be outside UEC
<cjwatson> at the moment, I think that the answer is that server boots with no initramfs and without the 'splash' argument are broken
<smoser> broken how ?
<smoser> because instances boot that way both on ec2 and uec
<smoser> oh. if youre running the details plugin. i see. which (i guesss?) is not running in our instances by default.
<smoser> cjwatson, ^^
<cjwatson> details plugin happens if you boot without 'splash'
<cjwatson> my suspicion is that you just don't notice problems because you're running headless :)
<ttx> there are some scary messages appearing on the get-console-output, nevertheless
<cjwatson> certainly to some extent I'm only seeing this because mountall needs to ask questions due to other bugs
<cjwatson> smoser: and FWIW the problem I'm debugging here is the same segfault you reported in https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/567592/comments/3, so I do not believe that you are not seeing it at all :-)
<ubottu> Ubuntu bug 567592 in plymouth "rm: cannot remove `/var/lib/urandom/random-seed': Read-only file system" [Undecided,New]
<smoser> ah. i see.
<smoser> yes, we dont see stuff lke "starting"
<smoser> or "started"
<cjwatson> ah, though to be fair you were triaging hggdh's bug
<smoser> i can point you at ec2 logs if you're interested.
<cjwatson> starting/started are only meaningful terms in conjunction with a job name
<cjwatson> not really, laser-focusing on this bug :-)
<cjwatson> I don't want to get sucked into debugging ec2 in general
<smoser> ok. so yeah, i would say that we're in trouble if plymouth wants to promt the user for information on uec/ec2.
<slangasek> we would be anyway
<slangasek> that's not a bug in plymouth, that's a failure to boot the UEC image correctly
<cjwatson> right, but leaving UEC aside, a server boot without initramfs looks like it'll fail if it needs to prompt
 * slangasek nods
<cjwatson> right now, I'm trying to figure out why it's prompting for /tmp
<slangasek> as far as release noting, this should probably be tacked onto https://wiki.ubuntu.com/LucidLynx/ReleaseNotes#Changes%20in%20boot-time%20output%20on%20Ubuntu%20Server
<smoser> an initramfs-less install outside of ec2/euc instances is not really something that is supported.
<smoser> right? already it means the user is using a custom kernel
<cjwatson> my understanding from Keybuk is that that is false
<cjwatson> it's not a default Ubuntu installation, sure, but it's not an uncommon thing for people to want to do and it's something we want to support
<smoser> which, obviously should be supported, but if they're rolling their own kernel then they can just roll it with an initramfs.
<cjwatson> in the sense of "make not hideously fail", not in the sense of "accept paid support calls"
<ttx> cjwatson: ok
<ttx> so we are in agreement that this precise issue doesn't change anything fro UEC users
<ttx> though supporting no-initramfs + no-splash would be good to have.
<ttx> (for server generally)
<smoser> fwiw, it was a pain to get "no-initramfs" working in ec2/uec.
<smoser> we ran into several bumps in the road causing that feature to wobble back and forth
<cjwatson> I realise that
<cjwatson> the server in general is simpler though
<lool> sorry was in a call
<smoser> i dont necissarily think that the server is a simpler case.  ec2/uec has the "single set of hardware" simple-ness.  ie, console is serial, network driver is X... its all known and explicitly supported.
<ttx> slangasek: should I add bug 557429 to the release notes targets ?
<ubottu> Launchpad bug 557429 in mdadm "array with conflicting changes is assembled with data corruption/silent loss" [High,Triaged] https://launchpad.net/bugs/557429
<cjwatson> smoser: *shrug* by simpler I was referring to the fact that it doesn't tend to have a set of complicated and delicate upstart jobs.  anyway, it's something we should make work, and in most cases it is not that hard.  I don't think it's release-critical or anything.
<cjwatson> that is, simpler in userspace.
<smoser> fwiw, i do hope on maverick, what you were attempting (booting in "stock kvm") will be much better supported and ideally "just work"
<cjwatson> well what I'm trying to do here is to contribute to that, not just complain! :-)
<ogra> slangasek, are all your rebuilds done already ? seems ports -server is still old
<slangasek> ogra: I'll do ports builds shortly
<ogra> thanks
<ogra> i still have a netinst running so no hurry
<slangasek> ttx: 557429> eh? already has a release notes task ):
<ttx> arh
<ttx> slangasek: I missed it. I guess I need another massage
<ttx> sorry for the noise
<smoser> cjwatson, yeah, i didn't think you were just complaining. was just saying, i hope that in maverick this test , your running of the instance would have worked better than it did.  (ie, wouldnh't have failed to get to 'filesystems' event)
<cjwatson> smoser: what specifically is planned for maverick in this regard?
<cjwatson> I'd expect most of the work to be essentially in the foundations arena, and to be bug-fixes
<slangasek> smoser: I see published-ec2-release.txt, which should tell me that you've pre-published these to EC2 for final release, yes?
<smoser> yes.
<slangasek> great, thanks!
<pitti> slangasek: did you accept linux lucid-proposed, or did I screw up with my langpack accept?
<slangasek> pitti: that was me
<pitti> ok, thanks
<slangasek> did it specifically before asking you about langpacks :)
<pitti> ok, langpacks flushed
<pitti> https://edge.launchpad.net/ubuntu/lucid/+queue?queue_state=1 is useful again, yay!
<ScottK> And queuediff too (it was timing out for me)
<doko_> slangasek: llvm, clang and llvm-gcc-4.2 all in the queue. let me know if I have to reupload to -proposed =)
<slangasek> doko_: odds are better if you can get a member of the release team *other* than me to review it...
 * pitti reviews
<doko_> slangasek: ok. thanks pitti
<pitti> doko_: oh, clang looks easy :) 50 line diff
<doko_> pitti: llvm has to go first, clang b-d on it
<pitti> okay
<doko_> pitti: the b-d's are correctly set, so you could accept all at once after review
<pitti> doko_: I'm though with all three; diffs are very small, nice
<doko_> pitti: cool, thanks!
 * pitti reviews the other stragglers while he's at it
<doko_> now a working jit for the powerpc jvm
<pitti> slangasek: ok, I accepted two more universe packages (simple FTBFS); for the remaining ones, xsane is on ubuntustudio and wine1.0 might take too long to build
<pitti> oh, and wine is on u-studio, too
<pitti> oops, that was 1.2
<pitti> the wine1.0 diff looks reasonable
<slangasek> pitti: did you leave the one in there that ScottK was leaving in case we needed to provoke a publisher run?
<pitti> I didn't see that, sorry
<slangasek> no worries, just means we'll do it by hand if necessary :)
<pitti> if we need one, I can find/fix another universe FTBFS
<slangasek> ok
<pitti> sorry if one was deliberately held
<pitti> wine1.0 would actually be suitable; takes 30 mins to build on i386/amd64, no other arches
 * slangasek nods
<ogra> thats a shame !
 * pitti needs to run now, about an hour
 * ogra wants wine on ARM !!!
<slangasek> ogra: talk to me in 4 months
<ogra> slangasek, lol ...
<slangasek> maybe I'll have something for you then
<ogra> slangasek, like the famous wince emu in wine on ARM ? *g*
<slangasek> er, probably not that
<ogra> heh
<ogra> i doubt you can port it to arm
<ogra> but who knows
<slangasek> no, I'm not going to port it to arm
<lamont> ogra: I'd recommend a red wine for ARM.
<ogra> yummy ...
 * ogra has plenty boxes with rioja in the cellar... i should try that
<ogra> rioja with a bagel board :)
<Riddell> slangasek: https://bugs.edge.launchpad.net/ubuntu/+source/akonadi/+bug/564263 should be release noted if you're collecting them
<ubottu> Launchpad bug 564263 in akonadi ""No resource agents found" error when starting for the first time" [Undecided,Confirmed]
<slangasek> Riddell: got it - you can just add an ubuntu-release-notes task to bugs, fwiw
<ogra> wohoo
<ogra> so its possible to do an ubuntu-netbook install with netinst
<ogra> it only takes 6h !
<ogra> (on omap)
<ogra> ok, on to server image testing
<ogra> slangasek, ^^^ omap netinst is good
<slangasek> alrighty
<slangasek> cjwatson: can I get a second opinion on https://bugs.launchpad.net/ubuntu-release-notes/+bug/546245 ?
<ubottu> Launchpad bug 546245 in ubuntu-release-notes "warn about using ubuntu with md raid (unreliable raid config)" [Undecided,New]
<ttx> jjohansen: so should we have a release note about how crappy ext4 can be and suggesting the use of ext3 ?
<cjwatson> there's already a release note task about the dpkg performance problems
<ttx> yes, I'd say that's enough -- but jib and jjohansen were discussing a more generic warning
<jiboumans> it's not just intsallation taking longer
<jiboumans> it's actual service performance after installation
<cjwatson> have we run our server tests with ext3?
<jjohansen> ttx: well yes we could do that
<jiboumans> cjwatson: we know why ext4 is slower than ext3 and there's a benchmark available publicly that shows it
<cjwatson> I'm not sure that answers my question ...
<ttx> jiboumans: I'd argue that you should choose your FS based on your workload, so unless ext3 beats ext4 on most scenarios, it's difficult to write that in release notes
<ttx> cjwatson: the answer is no
<jjohansen> I was talking to psurbi and she hasn't done anything more with it lately.  Its still basically the same cases
<jiboumans> cjwatson: we dont have numbers no
<jjohansen> jiboumans: yes sort of, that isn't a great benchmark
<cjwatson> jiboumans: I wasn't asking for numbers
<cjwatson> jiboumans: I was asking for server validation with ext3, just as we're doing validation with ext4
<cjwatson> anyway, I think "ext4 is slower than ext3" is too simplistic
<cjwatson> we should have a release note, but it needs to be in slightly more depth than that
<jiboumans> cjwatson: agreed
<jiboumans> i'm not attached to any wording, but i want to make it clear you have ext4 by default and what that may mean
<cjwatson> for example I recall the kernel team switching to ext4 in droves at one point upon realising that its unlink was much faster orsome such
<cjwatson> *or some
<ttx> A "pick your FS wisely" section warning on advantages/drawbacks of each ?
<cjwatson> "File system selection" perhaps
<cjwatson> it could note that btrfs won't work yet :-)
<jiboumans> i'm happy with our choice of default, but only if we point out why we picked it
<ttx> Who would know the issue well enough to be able to draft that ?
<jiboumans> i suggest 'data safety'
<cjwatson> that sounds inappropriate?  it's not a safety issue
<jiboumans> cjwatson: sorry, multitasking and not phrasing myself well
<cjwatson> I can draft some of it, as it relates to installation
<cjwatson> I'm not convinced that I can draft the whole thing well
<cjwatson> so perhaps I can tag-team on it with somebody else
<ttx> I wouldn't phrase it "data safety or performance"
<ttx> but rather "performance on workload A vs. perf on workload B"
<ttx> that highlights the best practice of doing that perf test yourself before choosing
<ttx> jjohansen: anyone in kernel that would know this issue particularly well that could help Colin ?
<cjwatson> do we have enough information to write a note like that at this point?
<jiboumans> in short, disk reads/writes seem slower compared to 8.04 and whinging will happen if we dont disclose
<pitti> jiboumans: in dpkg, certainly not in general?
<cjwatson> I think that's too short.  I haven't seen evidence that actual disk read/write throughput is much slower.  Isn't the issue regarding write *barriers*, which is a slightly different matter?
<jiboumans> pitti: in general according to the benchmarks we've seen
<jiboumans> this is what i refer to: http://www.phoronix.com/scan.php?page=article&item=ubuntu_lts_perf&num=2
<cjwatson> (poorly-explained phoronix benchmarks aren't evidence here)
<pitti> subjectively my system feels not slower, rather a bit faster with ext4
<jjohansen> ttx, cjwatson: it was csurbi who looked into it and did some benchmarking
<jiboumans> other than that, anecdotal only
<pitti> especially with things like large rm -r, fsck, and reading of files
<jiboumans> 'we are not using ext4 as it doenst perform as well as X'
<jiboumans> where X isn't necessarily ext3
<cjwatson> I've read the article, I'm not entirely sure I believe it without more of a microbenchmark.  I'm aware of certain things that will be much slower in ext4 and static web pages weren't one of them.  Perhaps something to do with log file writes?
<pitti> please don't generalize from dpkg to overall behaviour?
<cjwatson> if apache is fsyncing its log file, that would explain it
<cjwatson> although it would be a bit odd!
<jjohansen> jiboumans: right, well that doesn't even cover ext3 on the same OS version, a lot more than ext4 has changed
<jiboumans> pitti: i'm not. this is from my friends & network in operations
<cjwatson> release notes really need to be evidence-based and not rumour-based
<jiboumans> cjwatson: it's not a rumour
<jiboumans> 'we did the benchmarks and we picked X instead'
<cjwatson> where's the science in that phoronix article?
<cjwatson> where's the method?
<jjohansen> right, the are cases where it doesn't perform as well, this is known
<jiboumans> i dont have those numbers or specifics. the only thing public i can point at is that article
<jiboumans> jjohansen: this is known to...?
<jiboumans> everyone upgrading from 8.04?
<cjwatson> without method, it's rumour
<jjohansen> jiboumans: the developers
<cjwatson> we know of certain things that aren't rumour
<cjwatson> we should stick to those for the time being
<jjohansen> they have been working on stability and other issues first
<jiboumans> cjwatson: again, not caring about the specifics here. i'm only addressing pitti who said 'only for dpkg, right?'
<jjohansen> they know there are some corner cases
<jiboumans> jjohansen: i care about the people installing it and making sure they're not surprised, or that there's any FUD around our default
<cjwatson> jiboumans: do we care about the specifics for the release note, or not?
<jiboumans> cjwatson: sure
<jiboumans> pick any specifics you want to include
<cjwatson> you're saying "disk reads/writes seem slower", and I'm saying that we should not be specific about the operations that are slower unless we have evidence
<cjwatson> I agree it isn't just dpkg; that's merely the situation where we have most immediate evidence
<jiboumans> cjwatson: i think you're mixing up my conversation with you to point out my concerns with my suggested text for the release notes
<jjohansen> jiboumans: understood
<cjwatson> I hadn't actually seen any suggested text yet :-)
<cjwatson> all I'm saying is that we shouldn't just say "it sucks, use ext3" on the basis of phoronix :-)
<jiboumans> cjwatson: we violently agree
<cjwatson> jiboumans: ok, good :)
<cjwatson> I have a bit of a thing about phoronix I'm afraid - I've seen some pretty disgracefully bad things masquerading as science there (complete unawareness of statistical significance), so I tend to have a negative knee-jerk reaction to them
<jiboumans> cjwatson: appreciated. it's unfortunately the only public thing i can point at =/
<cjwatson> I think it would be interesting to time ext4 with write barriers turned off, and possibly ext3 with write barriers turned on
<cjwatson> the most recent hypothesis is that that's the specific property that changes dpkg's performance characteristics between ext3 and ext4
<cjwatson> it would further be interesting to know what difference that makes to phoronix' benchmarks
<cjwatson> apache2 doesn't appear to be using fsync or fdatasync
<cjwatson> unless it's wrapped up in something outside the apache2 source
<cjwatson> ah, separate library source
<cjwatson> still not seeing any references from C code though
<cjwatson> so I think it would be a good idea to further analyse where the apache slowness is coming from
<cjwatson> is anyone able to take that on?
<cjwatson> I've started a benchmark run in kvm, with the aim of comparing installation time with and without write barriers
<cjwatson> kvm probably isn't a great benchmark for this but it's better than nothing
<jjohansen> cjwatson: I can kick it off on real hardware.  Which installer are you using?
<cjwatson> server
<cjwatson> there's nothing built-in to disable barriers - you'd have to edit /lib/partman/mount.d/70ext3 before starting the partitioner to get it to do that
<cjwatson> actually no, make that /lib/partman/fstab.d/ext3
<cjwatson> and unless you can be bothered to preseed everything, probably best to just compare times of the base-installer and pkgsel segments from syslog
<jjohansen> okay, I'll give it a run
<harmoney> Food time for Londoners.
<lool> Riddell: heya; is LP #564263 still present and worth a release note?  Would you have some sample text?
<ubottu> Launchpad bug 564263 in akonadi ""No resource agents found" error when starting for the first time" [Undecided,Confirmed] https://launchpad.net/bugs/564263
<Riddell> lool: yes we'd like a release note for that
<Riddell> "Akonadi startup is sometimes faulty preventing access to the addressbook and other resources, close and restart Kontact when this happens to work around"
<lool> Riddell: thanks
<cjwatson> FWIW disabling write barriers shows no obvious improvement in kvm (and actually seems to disimprove the pkgsel stage, though it's possible my system was just a bit busier)
<lool> cjwatson: At the ext4 or kvm backend level?
<lool> ScottK: release notes task for LP #290153 seems to have been opened a long time ago, and I understand that the scope of the problem is smaller now, since the systems actually boot albeit slowly; so I'm closing the task, but please reopen if it necessary
<ubottu> Launchpad bug 290153 in linux "Fails to find boot device in Intel D945Gnt" [High,Confirmed] https://launchpad.net/bugs/290153
<slangasek> -
<cjwatson> lool: where I disabled write barriers?  I mounted the ext4 file system with barriers=0
<cjwatson> er barrier=0
<lool> slangasek: LP #470776 still an issue in final?  cjwatson seemed to think it might be fixed now with the latest lucid packages
<ubottu> Launchpad bug 470776 in mountall "retry remote devices when parent is ready after SIGUSR1" [Medium,Fix released] https://launchpad.net/bugs/470776
<lool> slangasek: That is, the part which relates to the mount.nfs errors reaching the console
#ubuntu-release 2010-04-29
<Riddell> slangasek: are we aiming for a midday-ish UK time release?
<bentkus> what the facebook
<bentkus> why the facebook did you kick me?
<nhandler> bentkus: Wrong channel
<bentkus> Yeah
<bentkus> i can see
<bentkus> but i can pay you with beers if you tell me the exact release date
<nhandler> bentkus: Date is April 29th. Now let's move back to -party
<bentkus> -party mode yoohoo
<bentkus> toobad its laread 3 in the night at here
<bentkus> and its my last beer
<bentkus> :(
<ScottK> lool: I saw the bugmail.  I think closing it was the right thing to do (re 290153)
 * lamont sleeps
<lamont> meh.  ECHNA
<slangasek> Riddell: early afternoon
<slangasek> lool: errors on console is not what I was going to release note for 470776
<slangasek> lool: my understanding of the remaining bug is that mountall is unhappy if you list a bind mount in fstab whose source is a symlink
<pitti> Good morning
<wgrant> slangasek: Hi. Are you planning to do the usual #ubuntu-release-party announcement this time, or shall we make other plans?
 * slangasek waves
<slangasek> wgrant: I was planning to do it
<slangasek> I was also planning to do it last time, before someone stole the spotlight from me :)
<wgrant> Yeah.
<wgrant> ubuntu/member/* don't have access this time, so it's less likely.
<wgrant> I don't want that disaster repeated :)
<slangasek> :-)
<ajmitch> talk about spoiling all the fun
<ajmitch> we should thank whoever added the index.html to the .pool dir, that'll save a bit of bandwidth :)
<wgrant> It's been there for a couple of releases now.
<wgrant> Still doesn't stop them much...
<ajmitch> It has? I guess I hadn't noticed
<pitti> slangasek: do you think I can already start accepting some SRUs?
<pitti> slangasek: if you want me, I can set one buildd for each arch to manual, so that we have them on standby in case we need an urgent lucid final build?
<slangasek> pitti: accepting SRUs> yes, that would be good
<pitti> slangasek: yellow is on manual now, but all the i386 buildds time out when I try to switch them
<wgrant> pitti: A timeout timeout, or "Please try again" timeout without an OOPS number?
<pitti> but oh well, most packages there are really small
<pitti> wgrant: trying again for the exact text
<Keybuk> slangasek: I have a last minute urgent mountall upload, is it too late to respin?
<pitti> wgrant: no oops, just a "Sorry, there was a problem connecting to the Launchpad server."
<wgrant> pitti: Aarrrrrgh.
<wgrant> That is impossible.
<wgrant> (it's the only page on which it happens, and it shouldn't be possible)
<pitti> just that it happened four times today, and about a week ago when I desperately tried to reserve an amd64 builder
<slangasek> Keybuk: ...
<Keybuk> it fixes bug #571549
<ubottu> Launchpad bug 571549 in mountall "Steve Langasek is having a good day" [Undecided,Triaged] https://launchpad.net/bugs/571549
 * slangasek snorts
<slangasek> Keybuk: I don't think we need to respin for that, release notes should be fine
<ajmitch> Keybuk: having a nice evil day giving people heart attacks?
<Keybuk> ajmitch: since I can't do it in person ... :-(
<slangasek> lool: oh, it seems 470776 may not be the bug I was thinking of; there was one where someone mentioned problems w/ bind mounts, and this appears not to be it
<ara> morning all!
 * slangasek waves
<ara> hey slangasek
<ara> slangasek, one quick question, are we going to have "home" webpages for every search engine in mozilla?
<slangasek> ara: as far as I know, there's just one home page that points to the default search engine?
<ara> slangasek, If I select a search engine other than Google or Yahoo and close firefox, when I restart firefox I get a 404
<slangasek> oh, is *that* what causes that bug
<slangasek> bug #557640?
<ubottu> Launchpad bug 557640 in ubufox "[Lucid Beta2] nrf-003 testcase failed Default "Welcome to Ubuntu" page doesn't appear without connectivity" [High,Fix released] https://launchpad.net/bugs/557640
<ara> slangasek, yes, it is not a server not found, it is just a plain old 404
<slangasek> ok
<slangasek> I don't know how it's meant to work, but that's probably the bug report to track it on
<ara> slangasek, ok, I'll comment there and will talk to the design guys
<elmo>               
<elmo> wait
 * ara waits
<Jeeves_> morning
<elmo> sorry, that's our bug
<elmo> I'll get it fixed
<elmo> we dropped some rewrites from start.ubuntu.com because we were running into apache mod rewrite bugs (sic) and I didn't realise firefox was sending arbitarty URLs to start.ubuntu.com for different search engines
<ara> elmo, OK, thanks. Glad to hear you're working on it
<ogra> wow, getting up and finding 100 new bugmails in my inbox ... must be release day
<ara> morning ogra, and happy release day :)
<ogra> same to you :)
 * ogra hugs ara 
 * ara hugs ogra back
<pitti> ogra: and it's not just the usual "branch linked" spam? :-)
<ogra> nope :)
 * pitti gets some 50 of those every day
<ogra> i rarely have over 60 when i get up ... and probably another 60 during the day
<pitti> ogra: ah, so it's 40 extra "OMGhowcanyounotfixthisbyrelease" comments :)
<ogra> yeah
<ogra> lovely how much testing we get the last day
<ara> yes, yes
<ogra> we should make secret release schedules and just spread rumours about the actual release date that are 3 weeks ahead
<ara> I *love* that kind of comments
<pitti> ogra: no, before, so that we can actually fix stuff still
<ogra> thats what i meant :)
<ogra> grammar skew :)
<ajmitch> no matter what you do, someone will complain about it
 * pitti suggests redirecting those folks to testing -proposed and giving feedback
 * hyperair got a particularly large amount of spam from the tooltip bug
<Jeeves_> btw: http://lvsd.lucid.bit.nl/stats/
<pitti> yay statistics!
<ogra> slick statistics even
<Jeeves_> :)
<elmo> ara: should be better now, can you confirm?
<pitti> slangasek: FTR, -proposed queue is now processed, except for the four that I uploaded, empathy (had a question on the bug), and poppler (OMGbigdiff, needs more time/discussion to review)
<ev> mvo: just a heads up, we may need you to mkdir ubiquity; touch ubiquity/10.04-update-available on changelogs.ubuntu.com in a bit
<mvo> ev: ok
<mvo> ev: I stand ready
<ev> :) thanks
 * ara checks
<ara> elmo, confirmed
<ara> elmo, thanks
<mvo> ev: is that so that it picks the right release notes text?
<ev> mvo: it's a hint to the installer that a new version is available, so it will show an update button
<mvo> ev: aha, so that the installer can update itself? nice, I noticed that this got landed early this cycle
<ev> mvo: indeed!  sabdfl asked us towards the end of the cycle to only show the option when an internet connection is available and an update is actually available, so we've implemented that.
 * mvo nods
<slangasek> so it seems we're going to do a last-minute respin of Ubuntu desktop CDs only, with a single lucid-updates change, to address the worst of bug #570765 in the limited time available
<ubottu> Launchpad bug 570765 in ubiquity "[Lucid] no GRUB menu entry for other operating systems" [Critical,Confirmed] https://launchpad.net/bugs/570765
<slangasek> pitti: ^^ in particular, this means do NOT promote anything else to -updates :)
<pitti> slangasek: understood; there's just one candidate anyway, but I don't like -updates promotion before release
<slangasek> right
<slangasek> with good reason :-)
<pitti> slangasek: does that require an upload? or just cd image build changes?
<slangasek> pitti: migration-assistant, ubiquity are in progress
<pitti> slangasek: want me to review m-a or are you doing it?
<ev> spot check please - http://paste.ubuntu.com/424497/
<slangasek> pitti: doing
<pitti> yellow is standing by, will bump build score and reenable it on your command
<slangasek> migration-assistant accepted
<pitti> c'mon yellow, grab it
<pitti> fodder for you
<pitti> there
<jarnos> Hello, will https://wiki.ubuntu.com/LucidLynx/ReleaseNotes and http://www.ubuntu.com/getubuntu/releasenotes/1004 have the same notes today?
<pitti> slangasek: hm, I don't think we'll be able to move them to -updates before a publisher run, though
<pitti> i. e. it'll take two publisher runs for them to get into -updates?
<wgrant> You can do it quicker if you get Soyuz approval to run process-accepted manually.
<wgrant> That takes seconds, and will mean you can immediately promote.
<ara> slangasek, we will be respining only CDs or DVDs as well?
<pitti> slangasek: m-a built on i386/amd64
<slangasek> ara: we will be respinning DVDs, but have not yet made a hard decision to take the new ones
<jarnos> Is it deliberate, that they have nothing about nouveu drivers? What is the role of https://wiki.ubuntu.com/LucidLynx/TechnicalOverview ? cjwatson
<cjwatson> wgrant: Soyuz approval?  the Ubuntu archive team does manual stuff like this on production regularly
<cjwatson> but in any case it's easier to just upload directly to -updates
<jarnos> slangasek: ?
<slangasek> pitti: shortcut: ubiquity is going to -updates now, and that's the only one that has to go on the livefs
<cjwatson> jarnos: please raise bug tasks on the ubuntu-release-notes project for anythng you think should be added
<pitti> cjwatson: *nod* but m-a was uploaded to -proposed
<pitti> slangasek: ah, because it includes source, right
<cjwatson> pitti: it doesn't really matter, it's only the source
<wgrant> Oh, OK.
<pitti> I have yellow on standby again, once ubiquity hits
<pitti> ubiquity won't be fast enough to catch the :03 publisher; shall I disable it, or did someone already?
<slangasek> already did
<ev> http://paste.ubuntu.com/424502/
<cjwatson> accepted
<slangasek> amd64: "starting in 1 hour"?
<pitti> build score bumped, yellow back on auto
<stgraber> slangasek: are you going to respin the derivatives as well for that grub issue ?
<pitti> argh
<slangasek> stgraber: please hold, asking this question
<pitti> wgrant: yellow manual/auto worked until five minutes again, and now it's timing out, arrrgh!
<pitti> wgrant: do you have the powers of reenabling it with better tools than the webui?
<wgrant> pitti: You can poke a LOSA to use SQL, but that's about it.
<wgrant> No API yet :(
<pitti> ah, worked now
<wgrant> A LOSA or maybe a lamont. Not sure if he can do it.
<pitti> ubiquity building
<slangasek> stgraber: you have the option
<pitti> dear launchpad, please keep working just a little longer
<lool> it's building now
<lamont> g'morning, btw
<lamont> or morning at least
<stgraber> slangasek: ok, then please respin edubuntu dvd. I have a very decent internet here so I should be able to re-validate both DVDs in ~2 hours after they are on cdimage.
<pitti> good morning lamont, how are you?
<jarnos> cjwatson: ok, but why there are different release notes at wiki and www.ubuntu.com?
<lamont> pitti: the timeout setting manual/auto seems to be related to launchpad being busy holding the door closed on the buildd manager, or at least us
<lamont> pitti: doing well
<slangasek> stgraber: we have a hardlinked copy of the current tree; we'll respin all the affected derivatives regardless, and you'll have the option of taking the current one with the bug or the new one if you're happy doing the extra validation
<stgraber> slangasek: ok
<slangasek> stgraber: if you go with revalidation, I expect we're probably going to have to push the release button for the other flavors before you've completed validation, but we can adjust the announcements accordingly, if that's ok with you
<cjwatson> jarnos: because they're copied over to www.ubuntu.com by our webmaster at release.  Don't worry, they'll be synced
<jarnos> cjwatson: I am wondering, which one is better to be linked in Xubuntu's release notes. Xubuntu's final notes will be at https://wiki.ubuntu.com/Xubuntu/LucidLynx/Final Well, I guess I could choose any.
<stgraber> slangasek: I'm guessing you have to release before and of day London time or is that going to happen even before that ?
<Riddell> GrueMaster: were you able to test the Kubuntu Netbook ARM images?
<cjwatson> jarnos: I think wiki linking to wiki would be fine
<cjwatson> but I don't think it matters too much either way
<stgraber> slangasek: otherwise, yes we can update the announcements to mention that due to that m-a bug we'll be releasing as soon as testing is over
<cjwatson> stgraber: the stuff on releases.ubuntu.com does; things on cdimage.ubuntu.com can delay a little bit if necessary
<Vge> so it will be released some time today? sorry, im little slow
<stgraber> cjwatson: ok
<cjwatson> Vge: that's still the plan
<stgraber> slangasek: any kind of ETA on when we'd get the new images for testing ?
<cjwatson> Vge: but please don't do the "are we there yet" thing in this channel :-)
<stgraber> (as in edubuntu)
<slangasek> stgraber: the Ubuntu release is expected to be before end of day London time, yes.  I don't have an ETA yet on edubuntu, I will see what I can do to expedite
<stgraber> ok, thanks
<pitti> slangasek: I guess it's safe now to reject the wine1.0 upload?
<lamont> slangasek: would a second i386 livefs buildd help, or just unduly complicate things?
<slangasek> lamont: I've asked elmo for a better king, amd64 is our bottleneck
<ev> http://testcases.qa.ubuntu.com/Install/DesktopResize updated
<pitti> slangasek: ubiquity built on i386/amd64; do we need to wait for armel for this run?
 * pitti supposes not
<pitti> armel will still take a while to compute that keyboard map
<slangasek> pitti: no - confirming build status and starting the publisher
<slangasek> confirmed
<slangasek> publisher running
<cjwatson> armel is unaffected because it doesn't have grub
<elmo> 11:32 < elmo> seriously, people
<elmo> 11:32 < elmo> a hardy kernel release TODAY?
<elmo> (since smb claims it wasn't them that moved it from -proposed)
<pitti> hm, I discussed it with smb on Monday, and he said they were good to move
<elmo> pitti: yeah, it's more the timing relative to lucid
<smb> pitti, I thought we discussed on last Friday to be moved this Monday. ;-)
<pitti> smb: right, I forgot; I remembered again when I cleaned up SRUs today
<pitti> oh, you mean mirror bandwidth-wise?
<pitti> argh, sorry about that
<elmo> slangasek: new-king is syncing, FWIW, but I hadn't quite counted on the n million files from chroots
<elmo> slangasek: if at any point you want me to abort, and make king functional again, just let me know
<slangasek> elmo: ok - what's the ETA?
<elmo> slangasek: way too long, i suspect
<elmo> based on a very poor sampling, it looks like at least an hour
<elmo> slangasek: we could of course rebuild the chroots on new-king, but that's the whole 'introducing more variables' thing I was trying to avoid
<ux2> an hour to the release? that's ok for me
<cjwatson> ux2: huh?
<cjwatson> ux2: please don't jump into the middle of conversation here
<ux2> please don't be an asshole, you stupid ubuntuer
<Jeeves_> hmm :)
<slangasek> elmo: I can slot ubuntu-netbook, which is i386-only, at the front; that would buy us some more time to let king finish syncing, and would still be a net win for build time
<cjwatson> I'm tempted to moderate this channel for the duration
<slangasek> elmo: I expect the king.buildd respin to save us at least 3h on the livefs mastering
<elmo> slangasek: ok
<slangasek> (since we're doing opportunistic respins of all affected flavors)
<cjwatson> voiced core-devs, testers, release team folks, etc. - please /msg me if you need to speak and don't have +v
<ogra> i assume armel wont need a rebuild for the grub issue, right ?
<slangasek> it will not
<ogra> ok ... no install stress tests for me then :)
<stgraber> ogra: would have been weird as AFAIK you don't have either grub, m-a or windows on armel ;)
<ogra> yeah
<ogra> just wanted to be sure if ubiquity might need any regression testing or so
<cjwatson> stgraber: fwiw there's nothing windows-specific here
<ara> cjwatson, in a ubuntu-ubuntu installation, what m-a is supposed to migrate apart of firefox bookmarks?
<cjwatson> ev: ^-
<ev> ara: internet explorer bookmarks, "My Documents", music, AOL IM, Yahoo IM,  "My Pictures", the set wallpaper, opera bookmarks, ...
<ara> ev, in ubuntu / ubuntu ones, I was asking
<ev> oh
<ev> pidgin
<ev> sorry about that
<ara> ev, ok, thanks!
<cjwatson> blink, what happened to the moderation here
<lamont> cjwatson: they have voice...
<cjwatson> no they don't
<cjwatson> kraut,Kilos: please leave us to deal with things at the moment rather than asking
<ara> cjwatson, I didn't see anything
<cjwatson> ah!  only moderators see it
<lamont> ah.. I didn't see anything from him
<cjwatson> er, ops
<lamont> heh
<Laney> that's one of the chanmodes
<elmo> FINALLY
<ogra> oh SIGH !!!!
<ogra> http://www.chip.de/news/Ubuntu-10.04-Lucid-Lynx-zum-Download_42676253.html
<ogra> they mirrored yesterdays image, renamed it and offer it as 10.04 already
<ogra> silly world
<slangasek> elmo, lamont: lucid-updates Packages.gz doesn't seem to be making it to syncproxy
<wgrant> Well, historically that has been, well, fine. Hopefully this late respin will cause them to stop that for a release or two :)
<stgraber> ogra: file on their server seems to be RC. clicking on download gets me to ubuntu-10.04-rc-...
<ogra> wgrant, i doubt that, they want the clicks ...
<cjwatson> ogra: can you contact them?
<slangasek> elmo, lamont: the *binaries* have mirrored; the Packages.gz has not
 * ogra tries to find a mailto link or something
<cjwatson> there's a "feedback" link at the bottom
<lamont> slangasek: looking
<slangasek> lamont: thanks
<slangasek> lamont: aha, looks like things are moving now, thanks
<lamont> yeah - was just going to say..  I see 2010-04-29 11:38 for a timestamp
<lamont> echo "$(date -R): Waiting $DELAY seconds before triggering external mirrors."
<lamont> sleep $DELAY
<lamont> and DELAY=600
<lamont> slangasek: and when I first logged in, there was a sleep 600 in the ps output...
<slangasek> hum, ok
<elmo> slangasek: what exactly were you seeing?
<elmo> as in how were you checking syncproxy?
<elmo> AFAIK it doesn't expose http
<slangasek> elmo: cjwatson checked it
<lamont> ok, same questions, cjwatson:
<cjwatson> rsync
<cjwatson> i.e.  RSYNC_PASSWORD=blah rsync -av ouruser@syncproxy
<cjwatson> ::ubuntu/dists/lucid-updates/
<elmo> hmm, that's worrying
<elmo> I saw the same sleep as lamont
<elmo> and at that point dists/ should be synced
<lamont> yeah
<cjwatson> I think I can confirm that this only happens if there's something to migrate on the other OS
<cjwatson> (however, that is still a pretty common case)
<lamont> something to migrate?
<ogra> cjwatson, i sent something to the author and the chief editor
<ogra> i dont expect them to react in time though
<cjwatson> lamont: sorry, I'm talking about bug 570765 not about syncproxy
<ubottu> Launchpad bug 570765 in ubiquity "[Lucid] no GRUB menu entry for other operating systems" [Critical,Confirmed] https://launchpad.net/bugs/570765
<lamont> cjwatson: doh.  sry
<dholbach> I posted a comment in the forum for the chip online article too
<elmo> so
<ogra> cjwatson, wow, that worked well, they replied and ask me for an MD5 for final so they can be sure to offer the right image :)
<elmo> slangasek: new king is consisently hanging when adding modules, and I've no idea why.  at this point I'm going to either have to give up or ask for some help from someone either kernel-y or udev-y
<ogra> cjwatson, and according to dholbach the article is corrected already
<elmo> slangasek: I've done body swaps like this before and it's usually fine except for having to remove /etc/udev/rules.d/70*peristent*net*
<cjwatson> ogra: good
<dholbach> ogra: it's not corrected - it's an older article - I guess that's where the other author got their information (and the links from)
<dholbach> but somebody said he'd pass the information on
<slangasek> elmo: oubiwann sent to get you a kernel person
<cjwatson> ogra: if you didn't already, it might be a good idea to emphasise that they should wait for the official announcement and get the checksums and such from there
<elmo> slangasek: thanks, it was an incredibly hard technical problem and nothing remotely resembling extremely embarassing PEBKAC
<ogra> cjwatson, they said they'll wait for me, i'll just forward them the official announcement then
<slangasek> elmo: can I start flinging stuff at king?
<elmo> slangasek: sorry
<elmo> still working, rebooting now
<slangasek> ok
<elmo> this is a complete clusterf#%Y^
<elmo> ok, booted, 30 more seconds
<elmo> this is unbelivable, so far it looks like it's going to be slower :-///
<elmo> than old king, never mind terranova!
<slangasek> my build time estimates are very much ballpark; none of the livefs build logs have timestamps
<slangasek> and I don't have any in my scrollback
<slangasek> so I can't tell if it's actually slower
<slangasek> would there be any reasons for network contention between the livefs buildds and the archive?
<elmo> slangasek: not enough to be relevant
 * slangasek nods
<elmo> Fetched 515MB in 41s (12.3MB/s)
<elmo> while that's not snappy, I don't think it's in the slow path
<slangasek> stgraber: ETA 1h45 for edubuntu (best guess)
<stgraber> slangasek: ok, thanks
<slangasek> elmo: ok, 33min for a livefs build on king
<slangasek> that's... longer than expected
<slangasek> but < 2x the build time on terranova
<elmo> slangasek: crazy idea, but could it be the completely cold cache?
<slangasek> I have no idea
<lamont> slangasek: and not very much at all pulls bits from ftpmaster
<cjwatson> pitti: is that you looking at NEW?  I was just reviewing adobereader-deu binaries and then they disappeared out of the queue ...
<slangasek> pitti: you reviewed wine1.0 and it's just waiting until the end for accept, right?
<pitti> cjwatson: I NEWed l-b-m, but I left the partner ones alone
<pitti> slangasek: it's fine by itself, but it needs to build (30 mins on i386/amd64) before we lock down lucid
<slangasek> pitti: yep - accepted, I'm afraid we have time
<pitti> cjwatson: and I did that about an hour ago; I'm testing ATM, not queue-juggling
<pitti> cjwatson: something wrong with them?
<pitti> slangasek: heh
<cjwatson> pitti: no, they looked fine
<Riddell> cjwatson: I did that
<pitti> TBH I ignored the partner packages so far, since I never quite managed to read about their process
<Riddell> iamfuzz just asked me to review adobereader-deu
<slangasek> ttx: have you seen the follow-up from Nathan on bug #571057?
<ubottu> Launchpad bug 571057 in ubuntu-release-notes "slapd 2.4.21-0ubuntu5 corrupts olcDatabase={-1}frontend.ldif with duplicate olcAccess lines (again)" [Undecided,Confirmed] https://launchpad.net/bugs/571057
<ttx> slangasek: about the olcAuthzRegexp line ?
<slangasek> ttx: yes
<ttx> slangasek: yes, that's not covered by mathiaz's patch, wanted to ask his opinion about it. Also I'm more and more confused by my tests, each upgrade path ends up with a different conffile
<ttx> duplicated lines
<ttx> so to solve this cleanly we probably need to cover more cases, and do more comprehensive testing of all paths
<slangasek> mmk
<ttx> I'm getting uncomfortable rushing that as a 0-day SRU
 * slangasek nods
<stgraber>  14:48:30 up 3 days,  6:27,  1 user,  load average: 89.62, 72.15, 52.79
<stgraber> can we get someone from IS to look at quandong ?
<cjwatson> elmo: ^- ?
<elmo> well
<elmo> I can bounce apache, but I'm not sure where the actual load is coming from
<elmo> it's not actually all that busy
<elmo> and it's coming down on it's own
<pitti> nice, people are jumping on testing the new ISOs like hungry cats on a mouse
<ogra> did oyu ask them in #u-r-p ?
<elmo> sigh, now it crashed
<pitti> ogra: no, just by the build notification emails, I figure
<pitti> ogra: oh, and I prodded folks in #u-desktop
<ogra> nice
<slangasek> ogra: anyone who asks #u-r-p for ISO testing help may find themselves stabbed at UDS
<ogra> lol
<ara> slangasek, has any other image been posted?
<pitti> ogra: like "test the new images NOW, or I tell Rick how bad you are in the next evaluation" :-P
<ogra> *grin*
<pitti> ogra: you are on #u-r-p? I didn't dare yet
<ogra> sure i am
<cjwatson> twitter is enough for me ...
<cjwatson> (also insane)
<ogra> dont want to miss the entertainment
<slangasek> ara: not yet; the next one up is edubuntu DVD, ETA < 1h but hard to give an exact number
<ara> slangasek, ok, thanks!
<ara> slangasek, what about ubuntu dvds?
<cjwatson> those are next after edubuntu dvd
<pitti> oh, quangdong == iso.qa?
<slangasek> yes
<stgraber> tracker's going to be real slow for a few seconds but should be better after
<slangasek> ah?
<stgraber> seems like Drupal's sessions haven't been cleaned for a while
<slangasek> ah
<stgraber> so it had a table containing 543509 php sessions ...
<slangasek> is that going to log me out of the tracker, *again*?
<stgraber> it shouldn't, I'm only dropping the sessions of anonymous users
<slangasek> ok
<pitti> stgraber: "FATAL: connection limit exceeded for non-superusers" -> that's because of too many sessions?
<stgraber> pitti: yes, seems like each apache process got stuck doing SQL queries
 * ara hugs stgraber
<stgraber> elmo: if you are still around, could you stop apache for a few secs ? should decrease the load and make the cleanup go faster
<pitti> it's not working right now anyway
<slangasek> elmo: ok, newking really is faster - edubuntu i386/amd64 just completed within a minute of each other
<slangasek> oops - within 2 minutes of each other
<elmo> slangasek: thank goodness
<elmo> stgraber: if I can log in, sure
<elmo> stgraber: done
<stgraber> elmo: good, I'll tell you as soon as the cleanup + reindex is done, shouldn't take long
<stgraber> elmo: looks like I need your help there ;)
<stgraber> elmo: http://paste.ubuntu.com/424628/
<stgraber> elmo: can you run these 3 queries as the DB owner ? seems like the "db" user can't do that
<elmo> stgraber: running
<stgraber> after that you can restart apache
<elmo> done
<stgraber> doesn't seem to have improved much :(
<dholbach> slashdot says that "it's out"
<dholbach> a bunch of people luckily told them already that they're wrong
<elmo> sigh
<elmo> what else is on this box
<wgrant> Slashdot consistently announces it hours earlier.
<wgrant> It's incredible.
<ara> Maverick is out. You can download it from here (random link)
<Jeeves_> :)
<Wooster_> Jeeves_: wassup!
<fader_> ara: I always trust thepiratebay.org for downloading OSes
<dholbach> ara: where? where?
<ara> dholbach, :D
<dholbach> which isos were rebuilt? daily-live, dvd, edubuntu?
<dholbach> ubuntu-netbook?
<slangasek> daily-live, netbook, edubuntu so far
<slangasek> edubuntu ISO still finalizing
<cjwatson> ubuntu dvd also planned, plus mythbuntu and xubuntu
<elmo> oh for god's sake quandong
<slangasek> edubuntu ETA: 5min
<lamont> slangasek: just netbook-i386.iso, or also the .img files?
<slangasek> lamont: hmm?
<lamont> slangasek: I think that means 'no, we're not respinning the .img files'
<slangasek> lamont: what .img files?
<slangasek> the armel ones?
<lamont> yeah
<lamont> which != netbook.
<lamont> I'm just going to go pound my head on the wall for a few minutes.
<slangasek> it's netbook, but it's not the netbook we're looking for :)
<lamont> well, to my defense, they do have 'netbook' in the name
<lamont> so I'm gonna use a _soft_ wal
<lamont> l
<Jeeves_> :)
<stgraber> elmo: anything else running on the same xen host as quandong ? (seems like quandong is so slow that my ssh session is completely frozen)
<stgraber> marjo: ^
<stgraber> cjwatson: can you +v marjo ?
<elmo> stgraber: yes, but it's an idle guest
<elmo> stgraber: I'm going to move quandong to  new hardware, we're just bringing it up now
<elmo> or rather the ISO tracker to new HW
<marjo> elmo: thx
<dholbach> slashdot article taken down, probably temporarily
<GrueMaster> Riddell: Sorry for not getting back to you on kde netbook on arm.  I had not had a chance to test them unfortunately.  I noticed that they are not part of the kubuntu testcases on iso.qa.ubuntu.com.
<stgraber> slangasek: what's the version number of the new edubuntu build ? I see 20100429.1 on cdimage
<slangasek> stgraber: that's the one
<stgraber> great, starting to rsync then
<stgraber> highvoltage: ^
<slangasek> stgraber: do you know the status of quandong?
<stgraber> slangasek: nope
<stgraber> slangasek: last thing I know is that elmo was going to move the tracker to another box
 * slangasek nods
<elmo> slangasek: sorry, there isn't  a quicker fix, ng is working on it right now though
<slangasek> elmo: just wanting to confirm that the current page load failure is expected.  Any ETA?
<pitti> so there were two successful tests of auto-resize, and I just finished one myself on i386; both OSes (well, lucids) are in grub
<pitti> it's a bit sad that we don't show grub by default any more for > 1 OS, but I think that's actually deliberate
<cjwatson> ... we should
<cjwatson> it's a bug if we don't, and not one I have reproduced in my testing thus far
<pitti> cjwatson: that didn't fall victim to the design team specs?
 * pitti reboots again, this time without shift
<cjwatson> no, one of the exceptions was in the case of multi-booting
<pitti> ah, ignore me, sorry
<fader_> Same here -- I have definitely seen the grub selector whenever I have done a resize and had multiple installs
<charlie-tca> It showed the menu in my entire disk install by default
<cjwatson> pitti: worked?
<pitti> the other one I was looking at had two kernels
<pitti> cjwatson: yes
<cjwatson> ah
 * pitti gets a little confused with too many installs, sorry
<fader_> I'd like to have the option to hide it even when multiple OSes are installed, actually :)
<pitti> they all worked great, though \o/
<elmo> slangasek: 30m ok?
<slangasek> elmo: it is what it is :)
<elmo> right
<cjwatson> fader_: yeah, bug about that, it was kind of hard to support all the options
<slangasek> ubuntu DVD> 64-bit livefs is built, 32-bit is a-squashin'
<fader_> cjwatson: Ack, I understand the reasons and am just griping :)
<slangasek> Ubuntu DVD ETA: 20min
<highvoltage> stgraber: would that be the one dated today 15:41 (for i386)?
<GrueMaster> Riddell: critical bug on kubuntu-netbook for armel dove.  Bug 571732.  Only on dove (not on imx51, will check omap).
<ubottu> Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/571732)
<cjwatson> that bug's private?
<GrueMaster> it just got filed by apport.  WIll change it.
 * Riddell waits in anticipation
<GrueMaster> Bug 571732.
<ubottu> Launchpad bug 571732 in kdebase-workspace "ksplashx_scale crashed with SIGILL in QImage::transformed()" [Undecided,New] https://launchpad.net/bugs/571732
<GrueMaster> Unfortunately, I think the armel retracer is still wonked.
<Riddell> GrueMaster: does that stop you using the desktop?
<GrueMaster> Riddell: also, it is very slow, possibly due to it not running any optimized video drivers in live (imx51).  Will install and try with closed drivers.
<GrueMaster> Riddell: on dove, yes.  No X.
<GrueMaster> The slowness on imx51 is very aggravating, but the installer is now running.  We'll see how it runs once it is installed.
<GrueMaster> Starting omap.  Not too hopeful due to low memory on system (256M), but we'll see,
<GrueMaster> Riddell: knr boots on omap, goes straight to install.  Good so far.
<slangasek> Ubuntu DVD up - 20100429, not available from the tracker yet
<GrueMaster> slangasek: I am not seeing iso.qa site.  Is it still down?
<slangasek> it is
<GrueMaster> ok
<elmo> tracker should be back up
<slangasek> \o/
<pitti> thanks so much!
<Riddell> GrueMaster: so we should publish omap and imx51 but not dove?
<GrueMaster> Yes, that is my current recommendation.
<GrueMaster> We need to figure out why ksplashx fails.
<Riddell> slangasek: for kubuntu netbook ports please publish omap and imx51 but not dove
<slangasek> ack
<GrueMaster> Riddell: Sorry for not testing it earlier.  I sometimes get overloaded here.
<stgraber> slangasek: edubuntu is now 100% covered
<Riddell> that's fine, it's all best effort stuff nothing we depend on
<stgraber> slangasek: I'm going to do some other test installs but fader_ validated amd64 and I just finished i386
<slangasek> stgraber: excellent :)
<cjwatson> smoser: can you get the EC2 publishing going?
<cjwatson> (pp slangasek)
<ogra> slangasek, oh, i forgot to tell you, i tested omap -server last night, was all fine
<slangasek> ogra: ok
<ogra> (meaning all omap images are good to go)
<Riddell> slangasek: I'm going out for a couple of hours, can you ping ofirk and shtylman if release happens, they'll update the kubuntu.org bits
<Riddell> cjwatson: please +v ofirk and shtylman
<cjwatson> Riddell: done
<slangasek> Riddell: um, it appears that http://www.ubuntu.com/getubuntu/upgrading is not going to include information about upgrades for Kubuntu.  Can you take this into account as necessary on http://kubuntu.org/news/10.04-lts-release
<slangasek> ?
<Riddell> slangasek: I'm not expecting it to cover Kubuntu, we use https://help.ubuntu.com/community/LucidUpgrades/Kubuntu
<Riddell> although a link might be nice
<slangasek> Riddell: ok; it has discussed Kubuntu in the past, and I'm just finding out about this content change now, so just wanted to make sure this isn't going to break your links
<stgraber> elmo: hey, how do I ssh to the ISO tracker now ? (seems like quandong has been abandoned)
<Jeeves_> ipv6 bt tracker is updated
<cjwatson> 17:59 <smoser> cjwatson, slangasek ec2 is essentially released.
<slangasek> james_w: I believe we need the bazaar importer stopped
<cjwatson> 17:59 <smoser> i've updated ami pages and also made images public
<cjwatson> 18:10 <ara> stgraber, I will appreciate if you could share that info with me :-)
<slangasek> smoser: oho - great, thanks
<elmo> stgraber: the new host is temporary, unless it's urgent, do you mind if we wait till we migrate back to quandong?
<ara> elmo, I will need to access tomorrow
<elmo> ara: that's fine
<elmo> ara: new host is limequat
<elmo> ldap accounts are easy
<elmo> I'll make sure yours gets enabled before tomorrow
<ara> elmo, thanks :)
<james_w> slangasek: done, thanks
<slangasek> \o/
<stgraber> elmo: nothing urgent, just nice to have when something comes up or when I want to make a DB dump.
<smoser> http://uec-images.ubuntu.com/releases/10.04/release-20100427.1/ is there, but something went amuck in the web indices
<smoser> i will get that fixed in 30 minutes or so. have to run now.
<slangasek> mvo_: please update changelogs.u.c
<james_w> congratulations slangasek et. al.
<james_w> thanks for all your work
<Jeeves_> Yeah, indeed.
<ogra> yeah, slangasek great job !
 * ara hugs slangasek :)
<stgraber> congrats slangasek & everyone else
<ara> slangasek, :'-)
<kees> woo!
<slangasek> congrats to all!
 * charlie-tca sends congrats and thanks too
 * fader_ cheers.
<shtylman> are we supposed to activate our release pages?
<cjwatson> web updates are in progress
<slangasek> shtylman: yes
<shtylman> kk
<pitti> slangasek: will we still have a release meeting tomorrow?
<pitti> slangasek, cjwatson: oh, and have a nice evening and beer drinking!
<GrueMaster> Is someone updating http://www.ubuntu.com/products/whatisubuntu/arm?  Should be for 10.04 and netbook instead of desktop (as that was the focus since PDX Sprint).
<cjwatson> pitti: release meeting> let's not :-)
<slangasek> pitti: you can!  I'm on vacation tomorrow :)
<doko_> is maverick open?
<GrueMaster> doko_: no rest for the wicked, eh?
<doko_> GrueMaster: it will take some time until we can open the gates for any uploads
<GrueMaster> I was referring to your asking if it was open.
<mdeslaur> Is there no way to see the release notes from www.ubuntu.com somewhere?
<GrueMaster> There is a link to it by following the "Get Ubuntu" link, then selecting "How to Upgrade".
<GrueMaster> Or http://www.ubuntu.com/getubuntu/releasenotes/1004
<GrueMaster> (kind of round about way to get there though).
<mdeslaur> GrueMaster: oh, thanks...it kind of buried
<mdeslaur> s/it/it's/
#ubuntu-release 2010-04-30
<ScottK> Nice job everyone.  Sorry $WORK took me out of the game this week.
<pitti> cjwatson: release meeting> that was meant to be "can I rather go out with my wife this evening", not "oh please let's have one" :-)
<pitti> slangasek: enjoy London!
<ogra> pitti, cjwatson, could one of you publish ports ? we get requests in #ubuntu-arm
<pitti> right, that's on my TODO list
<ogra> good :)
<pitti> I hope I won't screw it up
<ogra> it has to end up on cdimage but dont ask me which folder :P
<pitti> http://cdimage.ubuntu.com/ports/releases/10.04/ I presume
<pitti> I'll compare with http://cdimage.ubuntu.com/ports/releases/9.10/release/
<ogra> might be, but it caould also be http://cdimage.ubuntu.com/$flavour/ports/releases/10.04/
<pitti> sure
<ogra> i think both exist
<pitti> is there any way to know which ones were tested? (like powerpc+ps3)
<ogra> which makes it a bit confusing
<pitti> or are these best-effort?
<ogra> i can only tell that all omap ones were tested and that only imx and omap of kubuntu-netbook should be released (dove is broken)
<ogra> no idea about non ARM
<ogra> (the channel could probably be unmuted again too)
<pitti> ogra: that's just for netbook, or regular ubuntu images for arm as well?
<ogra> we only build ubuntu-netbook, d-i netinstall and ubuntu-server
<ogra> imx51 and dove netbook are in the official release
<ogra> the rest goes to cdimage
<ogra> (arm arches are omap, imx51 and dove)
<ogra> if you find any desktop images for either of these arch you can keep them :) (they shouldnt be built since a while though)
<ogra> i sadly cant reach cdimage to give you any links ... always times out
<pitti> bah, cdimage is totally clogged
<pitti> ogra: ok, so you want those:
<pitti> netbook armel+omap
<pitti> {alternate,desktop,server} armel+{omap,imx51,dove}
<pitti> ?
<ogra> not alternate,desktop
<ogra> only server
<pitti> ah, ok
<ogra> and kubuntu-netbook armel+{omap,imx5}
<pitti> and netbook armel+omap?
<ogra> yes
<pitti> ogra: do you happen to know what CDIMAGE_NO_PURGE=1 is?
<pitti> first time that I see it (on https://wiki.ubuntu.com/ReleaseProcess)
<ogra> nope
<ogra> smells like "do not remove dailies" but i could be wrong
<pitti> but publish-release never has
<ogra> we should probably wait for colin
<ogra> he knows the scripts in and out
<pitti> ARCHES="armel+omap" for-project ubuntu publish-release ubuntu-netbook/ports/daily-live 20100427.1 netbook yes
<pitti> hm, so that did nothing
<ogra>  netbook yes ?
<ogra> shouldnt that be ubuntu-netbook ?
<pitti> yes is the "release" argument
<pitti> ogra: I copied that from https://wiki.ubuntu.com/ReleaseProcess
<pitti> it said
<pitti> Constructing release trees ...
<pitti> Copying netbook-armel+omap image ...
<pitti> Making armel+omap zsync metafile ...
<pitti> Creating torrent for /srv/cdimage.ubuntu.com/www/simple/lucid/ubuntu-10.04-netbook-armel+omap.img ...
<pitti> but there are no new files at all in www, compared to my www.prev backup
<ogra> hmm
<pitti> hm, let's wait for cjwatson, before I screw up stuff
<pitti> CDIMAGE_NO_PURGE=1 didn't make a difference either
<ogra> isnt simple/ what goes to releases.u.c ?
<ogra> iirc it shoudl stay on www/full/
<pitti> ah, right
 * pitti reverts back to previous www dir
<pitti> +./full/releases/lucid/release/ubuntu-10.04-netbook-armel+omap.img
<pitti> ah, how's that
<pitti> +./torrent/releases/lucid/release/netbook/ubuntu-10.04-netbook-armel+omap.img
<pitti> it created those two
<pitti> I don't see an equivalent torrent for karmic, though
<pitti> sorry, I don't feel I can drive that reliably
<ogra> pitti, there was no omap in karmic ... i started implementing it 4 weeks ago :)
<pitti> ogra: right, but there is no /torrent/releases/karmic/release/netbook/ at all
<ogra> ah, k
<ogra> i thought you referred to omap
<ogra> i see /srv/cdimage.ubuntu.com/www/torrent/
<ogra> we probably didnt release the netbook flavour for karmic in ports
<ogra> (armel definately only had desktop back then, not sure about ppc or other ports)
<pitti> ok, I'll play with that a little bit
<pitti> ogra: hm, so my server images look good
<pitti> +./full/ports/releases/lucid/release/ubuntu-10.04-server-armel+omap.img
<ogra> yay
<pitti> and so on
<pitti> but netbook is still wrong
<pitti> +./full/releases/lucid/release/ubuntu-10.04-netbook-armel+omap.img
<ogra> weird
<pitti> it's not on ports
<pitti> ARCHES="armel+omap" for-project ubuntu publish-release ubuntu-netbook/ports/daily-live 20100427.1 netbook named
<ogra> i wonder if there is something missing in publish-release
<pitti> cjwatson: ^ this doesn't seem to move it to ports; am I forgetting a flag here?
<pitti> cjwatson: it does work with server: ARCHES="armel+omap armel+dove armel+imx51 ia64 powerpc powerpc+ps3 sparc" for-project ubuntu publish-release ubuntu-server/ports/daily 20100428 server named
<ogra> pitti, did you try "for-project ubuntu-netbook" for the omap one ?
<ogra> thats usually the project name for the netbook images
<pitti> as I said, I copied that from the release wiki page
<ogra> hmm
<slangasek> pitti, cjwatson, ogra: ok, I'm running through the ports publishing now
<pitti> slangasek: is above the correct command for ubuntu-netbook armel+omap?
<ogra> given the reachability of cdimage it seems there is no hurry anyway :)
<pitti> slangasek: or is it for-project ubuntu-netbook?
 * pitti still puzzled why they don't land on /ports/
<slangasek> pitti: the rune in the wiki was intended for publishing to releases.u.c; I'm not sure why omap is landing where it is
<pitti> slangasek: right, but the for-project argument should be the same for both?
<slangasek> pitti: for publishing to releases.u.c, we explicitly *don't* want armel under a separate ports tree :)
<pitti> I thought it should go to cdimage only?
<slangasek> I believe what we're seeing is that publish-release treats ^ports/ and ^ubuntu-server/ports/ specially
<slangasek> and maps those to ports/releases
<slangasek> but doesn't do this for ubuntu-netbook/
<pitti> full/releases/ is cdimage only
<pitti> ah
<slangasek> yes
<slangasek> yes, omap should go to cdimage only, which is why the rune from the wiki doesn't apply
<pitti> I just updated yes->named, and the version number
<pitti> I'm not sure what CDIMAGE_NO_PURGE=1 does
<slangasek> that's so when you run two separate publishing runs of netbook images to the same directory on releases for different archs, it doesn't nuke your torrents for i386
<pitti> ah, thanks
<slangasek> pitti: ok, have adjusted publish-release locally to let us publish omap under ports/releases/lucid/release; I still have a handful of ports images to publish yet, but have to go catch a plane, so I'll follow up on those later
<slangasek> but omap-netbook is done
 * ogra hugs slangasek 
<lool> cjwatson, slangasek: lucid-netbook-armel+omap.img doesn't seem to be in http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/lucid/
<lool> well it would be under a different name there obviously
<lool> oh was just reported earlier
<slangasek> lool: correct; it's now under cdimage.ubuntu.com/ports/releases/lucid/release/
<slangasek> I could move it if you prefer, then I wouldn't have to worry so much about the mess I'm making of publish-release
<lool> slangasek: I personally would prefer a consistent scheme too; not sure if it's ok to move these around still
<lool> slangasek: Perhaps davidm to decide?
<slangasek> consistent with what, though?
<slangasek> currently it's consistent with what we publish to releases.u.c at release time
<slangasek> and consistent with ubuntu-server publishing
<slangasek> if I change it, it'll be consistent with our daily publishing instead
<lool> $project/$ports/$release/...
<lool> slangasek: I wouldn't mind either way
<lool> Just would like either all in /ports/releases and /releases or all in $project/releases $project/ports/releases
<lool> can we kill the empty full/ubuntu-netbook/ports/releases/10.04 dir?
<lool> slangasek: safe flight BTW
<slangasek> full/ubuntu-netbook/ports/releases/10.04 nuked
<lool> (you can even kill the full/ubuntu-netbook/ports/releases if you like -- but that one isn't confusing :-)
<slangasek> yah, also nuked
<slangasek> ok, need to head toward the plane
<lool> safe flight again
<slangasek> thanks!
<pitti> slangasek: save travels!
<pitti> 'safe'
<lool> can't find the omap server image on cdimage
<lool> ogra: ^ any idea where that one went?
<lool> find full -iname \*server\*omap\* only yields the daily
<lamont> slangasek: any reason not to put oldking back into existance again (cleaner, but tosses yesterday's post-swap activity) - I have a ticket to figure out why newking didn't surprise us with speed, and need to benchmark terranova, and both kings (and reinstall newking cleanly)
<lamont> oh meh. any other RM types have thoughts on that, since the planeward one isn't going to answer.
<lamont> cjwatson: ?
<cjwatson> lamont: no reason, we won't be using it for a few days
<lamont> cjwatson: it'd be more of (1) reversion of what speedup we got, and (2) yesterday's post-swap activity goes *poof* when I reinstall newking cleanly, anyway
<cjwatson> we'll be in no rush for a while
<lamont> right. I, OTOH, get to do a bunch of benchmarking before you do rush me
<lamont> ta
<ogra> lool, isnt published yet ... some ports are some arent
<ogra> lool, slangasek said he would care later (he is traveling atm)
<Mirv> thanks, eventually got also finnish remix released within 20 minutes of release announcement
<lamont> doko: the tarballs you want are there now
#ubuntu-release 2010-05-01
<lool> Who's finishing the publishing for the remaining images?
<kees> $ gpg --verify SHA256SUMS.gpg SHA256SUMS
<kees> gpg: Signature made Thu 29 Apr 2010 11:48:44 PM PDT using DSA key ID FBB75451
<kees> gpg: BAD signature from "Ubuntu CD Image Automatic Signing Key <cdimage@ubuntu.com>"
<kees> ???
<kees> slangasek, cjwatson, elmo: ^^  looks like the *SUMS.gpg files were regenerated a day after the *SUMS files and are wrong now.
<kees> pitti: maybe you have visibility into this too?
<slangasek> lamont: oldking> no objections here
<slangasek> lamont: (sorry, would've answered sooner, but the hotel in Dublin misled me with their claims of wifi into believing I could *use it to do useful things on the Internet*)
<slangasek> kees: which directory is that in?
<slangasek> kees: n/m, found it; fixed
<lamont> slangasek: heh.
#ubuntu-release 2010-05-02
<ogra> slangasek, http://cdimage.ubuntu.com/ports/releases/lucid/release/ still has no server images, are they supposed to show up somewhere else or are they just not done yet ?
<elmo> ogra: umm, server images are on releases.u.c?
<ogra> elmo, armel/ports :)
<ogra> (steve knows i'm talking about ports i suppose :) )
<elmo> ah, yes, for all the armel servers :-P
<ogra> right
<ogra> not really, but for easy development systems without net connection :)
<ogra> you dont really want netbook for those ona  256M beagleboard
<slangasek> mmh, it looks like antimony is out of disk space
<slangasek> elmo, lamont: can you cycle old-images off of antimony?
<slangasek> ogra: ^^ once that's done, I can publish the ports server images
#ubuntu-release 2011-04-25
<cjwatson> I assume somebody is going to do a rebuild pass at some point today?
 * cjwatson eyes up bug 770041
<ubot4> Launchpad bug 770041 in debian-installer (Ubuntu) "natty server installation hang (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/770041
<skaet> cjwatson,  do you know if all the langpacks have landed?   As soon as I know that figured it was worth starting off the rebuilding.
<cjwatson> they have
<cjwatson> -en apparently didn't get uploaded, and micahg was asking about that; but everything else was done over the weekend
<skaet> cjwatson,   can you upload -en?  or do we need to wait for pitti?
<cjwatson> I can't
<cjwatson> let's just skip it?
<cjwatson> it had some effect on Firefox I think but not a showstopper one
<skaet> ok,  if that's the scope, we can cope and post-release update it.
<skaet> any recommended order folks want to see them coming off the builders in?
 * skaet thinking ubuntu desktop, alternate,  ubuntu server (because of last bug mentioned above... checking its still there),  and then...
<skaet> ?
<cjwatson> I was going to see if I could figure out a quick fix for that bug
<skaet> cjwatson,  ok,  will hold off on server until you give me the nod
<cjwatson> it'd affect alternates too
<cjwatson> maybe start with the desktops?
<skaet> didn't realize it would affect the alternates - thanks for pointing out.
<cjwatson> same installer
<skaet> will start the desktops now then,  so they're on the tracker when north america comes online
<skaet> started off ubuntu desktop, kubuntu desktop,  kubuntu-mobile (i386),  mythbuntu desktop
<skaet> cjwatson,  safe to start off all the arm ones?  or is there possible interaction with the bug you're fixing?
<cjwatson> go ahead
<skaet> thanks
<cjwatson> hm, first attempt to reproduce it failed, must not be quite that simple
<cjwatson> skaet: can't reproduce bug 770041, although I do think that if it can be reproduced then it's (a) serious (b) not fixable post-release, and hence worth fixing; I've posted a detailed request for more information
<ubot4> Launchpad bug 770041 in debian-installer (Ubuntu) "natty server installation hang (affects: 1) (heat: 6)" [Undecided,Incomplete] https://launchpad.net/bugs/770041
<skaet> cjwatson,  fair enough.   Just chatted with pgraner, and he'll have some of the QA team see if they can reproduce it when they come online in the US.
<skaet> I'll start off the alternates and DVD's after desktops finish.
<skaet> is there a bug for tracking the fact that -en langpacks didn't get included?
<skaet> cjwatson,  ^
<cjwatson> bug 769759
<ubot4> Launchpad bug 769759 in language-pack-en-base (Ubuntu) "English and a few other Firefox langpacks won't work with 4.0.x (affects: 1) (heat: 10)" [High,Triaged] https://launchpad.net/bugs/769759
<cjwatson> not "didn't get included", by the way - "didn't get updated"
<cjwatson> they're still there, just two weeks old
<skaet> stgraner,  do you want fresh images for edubuntu,  or are you going to go out with the ones from 20110423?
<pgraner> stgraber, ^^^
<skaet> ubuntu desktop just came off the builders and has been posted.  (except for i386 - which is oversized)
<cjwatson> probably a matter of dropping a language pack, waiting for a publisher cycle, and then forcing a non-trivial publisher cycle (e.g. by accepting a universe package)
<skaet> stgraber, if you're around, could you have a look
<skaet> ??
<cjwatson> dunno if stgraber wants to, looks like the next langpack on the block is French ;-)
<skaet> kubuntu desktop (i386, amd64, amd64+mac, powerpc) posted 20110425.
<skaet> hmm,  looks like ubuntu desktop powerpc is oversized as well.  disabling it too.
<cjwatson>  language-pack-kde-sv : Depends: language-pack-sv-base (>= 1:11.04+20110421) but 1:11.04+20110407 is to be installed
<cjwatson> hmm
<cjwatson> http://people.canonical.com/~ubuntu-archive/testing/natty_probs.html agrees
<cjwatson> pitti: ^- this needs your attention, I believe
<ScottK> cjwatson: It looks to me like the lirc upload in queue for -release should be rejected and reuploaded with -proposed as a target.  I'm not up to speed with where we are re respins though, so I wanted to double check that with someone.
<stgraber> skaet: A rebuild of Edubuntu would be great, thanks
<skaet> stgraber,  ok,  will queue it up.
<Riddell> hmm, I'm still getting a btrfs crash when turning to the partitoiner page in ubiquity, but only on a usb install not with a CD
<stgraber> skaet: for bug 737324 it seems pretty unlikely that it'll get solved for Natty as there's no easy way to fix it (moving xfce4-notifyd to recommends in xubuntu-desktop would fix the conflict but might break the desktop). Is it fine moving it to Oneiric ?
<ubot4> Launchpad bug 737324 in xubuntu-meta (Ubuntu Natty) (and 3 other projects) "xubuntu-desktop conflicted with ubuntu-desktop in natty (affects: 2) (dups: 1) (heat: 115)" [Medium,Triaged] https://launchpad.net/bugs/737324
<stgraber> charlie-tca: ^
<charlie-tca> agreed
<skaet> stgraber, agreed.
<ScottK> Is the armel rebuild serving any other purpose at this point than blocking access to buildds?
<stgraber> skaet: ok, nominated for Oneiric then. Can you approve both bug 737324 and bug 759545?
<ubot4> Launchpad bug 737324 in xubuntu-meta (Ubuntu Natty) (and 3 other projects) "xubuntu-desktop conflicted with ubuntu-desktop in natty (affects: 2) (dups: 1) (heat: 107)" [Medium,Triaged] https://launchpad.net/bugs/737324
<ubot4> Launchpad bug 759545 in grub2 (Ubuntu Natty) (and 1 other project) "user prompted to update unmodified grub configuration during Ubuntu server upgrade (affects: 1) (heat: 12)" [Medium,Won't fix] https://launchpad.net/bugs/759545
<ScottK> stgraber: Do you want them approved or declined for natty?
<ScottK> Nevermind
<ScottK> stgraber: Nominations approved.
<stgraber> ScottK: thanks
<ScottK> You couldn't approve that?
<ScottK> I thought if you could upload the package you could approve nominations?
<stgraber> not in Oneiric
<stgraber> I can do it without any issue for Natty or any other supported release
<ScottK> Ah.  I see.  Thanks.
<stgraber> might be interesting having that work for "Future" releases too, would save quite a bit of time to everyone
<stgraber> ScottK: did you approve bug 759545 too ? I still don't see the Oneiric task.
<ubot4> Launchpad bug 759545 in grub2 (Ubuntu Natty) (and 1 other project) "user prompted to update unmodified grub configuration during Ubuntu server upgrade (affects: 1) (heat: 12)" [Medium,Won't fix] https://launchpad.net/bugs/759545
<ScottK> No.  Done now.
<stgraber> thanks
<ScottK> No problem.
<ScottK> iulian: Would you please consider Bug #770183?  I'm inclined to say "Meh, whatever", but I thought a second opinion would be nice.
<ubot4> Launchpad bug 770183 in feel++ (Ubuntu) "FFe: Sync feel++ 0.91.0~svn7013-1 (universe) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New] https://launchpad.net/bugs/770183
<skaet> stgraber, Riddell - would one of you be able to do some language pack pruning on desktop i386,  we have some testing folk eager to chomp at it a bit, and cjwatson's off today.
<stgraber> skaet: is that only desktop i386 and powerpc being affected ?
<skaet> stgraber,  yes that seems to be the case.  amd64 and amd64+mac are fine.
<skaet> just to be clear - ubuntu desktop i386, ubuntu desktop powerpc.
<stgraber> skaet: any langpack in particular you'd like to see gone ? on i386 we have de, en, es, fr, pt, xh, zh-hans
<Riddell> can do, but stgraber seems to have volunteered first :)
<stgraber> on powerpc, we only have -en, so it's a bit harder to cleanup :)
<iulian> ScottK: Looking.
<Riddell> stgraber: drop the last one
<Riddell> zh has their own remix anyway
<Riddell> on powerpc kubuntu doesn't ship language-support- so you could do the same, although it's not ideal
<skaet> stgraber, what Riddell recommends seems reasonable to me as well.
 * skaet wonders if someone has a nice prioritized list that should be consulted about now... :P
<Riddell> the seeds should already be in prioritised order
<Riddell> I don't know how ubuntu prioritises them now, it uesd to be by number of speakers, in kubuntu we do it by popcon count
<stgraber> zh-hans is on both amd64 and i386 (actually it's on != powerpc), should I drop it from all of them ?
<skaet> stgraber,  just drop it from the i386 images.
<stgraber> ok
<skaet> thanks
<iulian> ScottK: I'd say go ahead.  It appears that it's a new package and since it also fixes some bugs, why not.
<ScottK> Thanks.
<stgraber> skaet: for powerpc, should I try removing language-support as Riddell suggested ? That means we won't ship english dictionaries on the CD (myspell-en-au, myspell-en-gb, hunspell-en-us, hunspell-en-ca, wamerican, wbritish, myspell-en-za)
<ScottK> stgraber: If you're working on oversize ....  For powerpc images to be ~usable they need to fit on a CD, so I'd do whatever you need to to make it fit.
<ScottK> Riddell: Actually I recently put language support back for Kubuntu on powerpc as we've got room now.
<stgraber> ScottK: do you happen to know approximately how much space removing language-support saved you ?
<ScottK> stgraber: I don't but if you go look at Kubuntu beta2 powerpc and the current one most of the difference was likely adding that back in.
<stgraber> ScottK: can't find your beta2 powerpc build on cdimage or releases. Anyway, pushed the seeds with language-support removed.
<stgraber> skaet: ^ powerpc and i386 should be fixed with that. i386 was just 1MB oversized, so next build will be fine, powerpc I'm not sure, we'll see ...
<ScottK> iulian: Would you please look at Bug 770298.
<ubot4> Launchpad bug 770298 in python-django-threadedcomments (Ubuntu) "FFe: Sync python-django-threadedcomments 0.5.3-1 (universe) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New] https://launchpad.net/bugs/770298
<iulian> ScottK: Sure.
<iulian> ScottK: We certainly want that in.
<skaet> pushed to the iso tracker the latest set of alternate images.   ubuntu, kubuntu, xubuntu, ubuntu-server and ubuntustudio  have just been posted.
<ScottK> iulian: Thanks.
<iulian> ScottK: Approved and subscribed -archive.
<iulian> No problem.
<skaet> ScottK, Riddell, charlie-tca, ScottL, ^^,  alternates posted.
<charlie-tca> Thanks, skaet
<Riddell> whee
<stgraber> argh, edubuntu failed to build ...
<skaet> stgraber,  edubuntu dvd just failed to build.
 * skaet sees that stgrabers on it....  ;)
<stgraber> some langpack issues ... again
<stgraber> are all the langpacks built and published ?
<stgraber> language-pack-kde-sv : Depends: language-pack-sv-base (>= 1:11.04+20110421) but 1:11.04+20110407 is to be installed
<stgraber> seems to indicate it's not the case
<skaet> hmm, why does edubuntu pick this kde package up as a dependency?   just for my info...
<stgraber> edubuntu ships a lot of kde apps, mostly kdeedu. We also ship all existing translations, so we end up having all of language-pack, language-pack-kde, language-pack-gnome and language-support on our dvd
 * skaet nods - yeah that makes sense,  thanks!
<stgraber> building Edubuntu is probably the best way to make sure all langpacks are properly built :)
 * skaet notes that in future.
<ScottK> I thought we had all of them on the KDE dvd too.
<ScottK> (all the KDE ones)
<stgraber> hmm, seems like language-pack-sv-base wasn't even uploaded. We still have the old version in the archive
<stgraber> ScottK: did you get kubuntu's dvd rebuilt today ? it's quite likely it'll fail too
<ScottK> I didn't.
<ScottK> I've lost track of where we are on rebulds.
<stgraber> ok, the question now is who do we poke to get a langpack fixed ?
<skaet> stgraber, names I've gotten so far are pitti, dpm - neither of which are around right now.  Busy asking to see if I can find some other experts - anyone know any other names.
<skaet> ScottK, stgraber,  was doing edubuntu first.... kubuntu dvd was next up, but seems no point now.
<stgraber> good news is that apparently only -sv is broken (from playing a bit with apt), so as soon as this one is fixed, the image should build fine
<ScottK> skaet: I think that's the full list of experts.
<ScottK> We're going to have an omap4 kernel update in -release?
<ScottK> skaet: Were you expecting this omap4 kernel for -release?  It looks to me like perhaps it was meant for -proposed since it's not a focuse update for critical fixes?
<stgraber> hmm, ubuntu alternate just failed to install for me ...
<skaet> ScottK,  I believe it should be proposed.   just asked around, and there's some CVE updates.
<skaet> (0-day)
<stgraber> segfault when installing python-argparse ... weird
<skaet> stgraber,  hmm... can you see if anyone else on ubuntu-testing is seeing this?
<stgraber> I'm going to retry mine ... the package that's sefaulting as been uploaded 28 weeks ago, so it's not really likely to be the issue ...
<ara> stgraber, I am going to start testing alternate now
<ara> (well, as soon as disk creator finishes)
<stgraber> it looks like a possible kvm issue (memory or similar), retrying now, if I can't reproduce it, then it probably was some memory issue (still weird though, first time I see that this cycle)
<ara> I will try in  a netbook
<ScottK> skaet: Should I reject it then?
<skaet> ScottK,  who uploaded it?   I'd like to double check I'm understanding first,  but I expect that's the right thing.   Please hold off for a minute though until I can check.
<ScottK> Changed-By: Bryan Wu <bryan.wu@canonical.com>
<ScottK> Didn't check the signature to see who actually did the upload.
<skaet> thanks!   will follow up.
<ScottK> skaet: Signed by Tim Gardner <tim.gardner@canonical.com> so he did the actual upload.
<skaet> ScottK,  Pete's followed up with Tim - go ahead and reject.   They'll upload to proposed.
<ScottK> Done.
<ScottK> Someone should follow up on lirc too, but I'm out of time.
<skaet> lirc?
<ScottK> http://launchpadlibrarian.net/70365984/lirc_0.8.7-0ubuntu5_source.changes
<skaet> thanks.
<ScottK> It should almost certainly be rejected and reuploaded for SRU, but I didn't talk to anyone.
<skaet> ScottK,  yeah it should be rejected and reuploaded to SRU at this stage.
<ScottK> skaet: Rejected.  Would you please email the uploader.  I really have to go.
<skaet> ScottK,  will do.  Its superm1
<kenvandine> Recommends should get included on the CD, right?
<skaet> kenvandine,  specific package?
<kenvandine> ubuntuone-client has a recommends for gir1.2-unity-3.0
<kenvandine> but gir1.2-unity-3.0 isn't on the CD
<pgraner> kenvandine, if its not installed what functionality does a user loose?
<kenvandine> the progress bar and urgency hint in the unity launcher
<kenvandine> it still functions
<kenvandine> but i think there are assumptions made that the user will see the urgency hint when needed
<skaet> kenvandine,  if it still functions,  its release notable.
<stgraber> kenvandine: gir1.2-unity-3.0 (>= 3.8.4-0ubuntu3) is the recommends
<stgraber> kenvandine: 3.8.4-0ubuntu1 is what we have in the archive
<skaet> kenvandine,  if its essential,  it should be a requires.
<kenvandine> oh my!
<stgraber> so as the recommends can't be met, gir1.2-unity-3.0 isn't included
<kenvandine> what a crappy goof up that is...
<kenvandine> they must have changed the upstream version without changing the ubuntu version
<skaet> yeah,  that would explain it.
<kenvandine> skaet, i told the U1 folks to prepare an SRU and make sure it gets noted
<skaet> thanks kenvandine :)   is there a bug I should keep on the radar?
<kenvandine> not yet... i can file one
<stgraber> kenvandine: users will have to do a dist-upgrade to get these installed as the change in recommends will bring new packages on the system (not really a problem, will be similar to what kernel updates do)
<kenvandine> i knew it worked in earlier images
<kenvandine> yeah
<skaet> kenvandine, thanks,  let me know the number and I'll add it to the "board".
<kenvandine> man i wish we had caught this earlier...
 * skaet nods
<stgraber> skaet: covering the walls of the conference room with bug numbers ? :)
<SpamapS> Is there a re-spin of any kind happening? I may have found a bug in mdadm/lsb init that causes mdadm to not be started on boot.
<SpamapS> /etc/rc2.d/S25mdadm: 76: LOG_DAEMON_MSG: parameter not set
<skaet> stgraber,  yup,  part of the rundown for the release notes at the end, as things cross through IRC discussions ;)
<stgraber> SpamapS: ouch (/me hopes he didn't introduce this one with the plymouth fix for lsb ...)
<rickspencer3> SpamapS, is there a bug #?
<pgraner> SpamapS, bug?
<skaet> SpamapS, please see if  you can get independent confirmation and a bug number.
<SpamapS> No I just right now found it at this second
<SpamapS> http://testcases.qa.ubuntu.com/Install/ServerRAID1
<stgraber> SpamapS: was it working for beta2 ? my lsb change has been in the archive for a while now
<SpamapS> Found at step 16d
<pgraner> SpamapS, ok, keep me in the loop, either way atm this looks like a release note and SRU fix
<SpamapS> stgraber: I don't know, I didn't do the RAID tests at beta.
<SpamapS> I will file a bug now tho
<stgraber> SpamapS: LOG_DAEMON_MSG is something I introduced in /etc/lsb-base-logging.sh to have better loggin with plymouth
<SpamapS> stgraber: hm..
<stgraber> SpamapS: though reading the code again, I'm not sure how it can be "not set" ...
<SpamapS> stgraber: mdadm is run with 'set -eu'
<SpamapS> stgraber: I believe when using -u, even   [ -z "$LOG_DAEMON_MSG" ] will fail
<stgraber> SpamapS: can you try adding 'LOG_DAEMON_MSG=""' at the beginning of /etc/lsb-base-logging.sh see if that fixes it for you ?
<stgraber> SpamapS: that should workaround the -u
<SpamapS> stgraber: after the bug is reported yes
<stgraber> if that works, I'll prepare a lsb upload
<stgraber> skaet: If that's indeed the issue and my fix works, we'd need respinning of all non-desktop builds to get the fix
<SpamapS> stgraber: yes that fixes it
<pgraner> stgraber, we are trying to hold on the respin, what would the workaround be?
<kenvandine> skaet, bug 770379
<ubot4> Launchpad bug 770379 in ubuntuone-client (Ubuntu Natty) (and 1 other project) "Recommends wrong version of gir1.2-unity-3.0 (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/770379
<stgraber> pgraner: depends how broken RAID is without it ... I'd think it means any 11.04 system with RAID will boot in degraded mode
<robbiew> stgraber: pgraner: given this would primarily affect Server...could we just respon the Server ISOs?
<skaet> thanks kenvandine
<stgraber> pgraner: then whenever the user applies the update + reboot, the system will start syncing the disks again, making the system quite slow for a few hours
<SpamapS> bug 770381
<ubot4> Launchpad bug 770381 in mdadm (Ubuntu) "mdadm does not start automatically at boot due to LOG_DAEMON_MSG being unset (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/770381
<pgraner> robbiew, we could, what I'm trying to assess is: can we workaround and fix in a SRU
<pgraner> robbiew, if we have to respin then we will do it I'm exploring all possibilities atm
<robbiew> pgraner: right
<SpamapS> I can try installing everything from main that uses lsb and seeing which ones use 'set -u'
<stgraber> well, we're basically playing with the user's data there, because if a drive breaks between install and first updates + reboot, the data will be lost
 * pgraner +1 for respin
<SpamapS> some people do depend on mdadm running to notify them of dead raid
<stgraber> SpamapS: yeah and we can get into situations where the RAID array won't re-assemble properly without it ...
<skaet> stgraber, please code up and upload the fix.
<skaet> I'll respin the alternate images not affected by the langpacks tonight (london time),  after you tell me its in the archive.
<skaet> The rest of the images (alternates and dvds that have failed) will get rebuilt when pitti/dpm can get them sorted, and pick it up then.
<skaet> stgraber,  how much time do you estimate it will be before tested and uploaded?
 * skaet is thinking she needs to eat
<stgraber> skaet: 2-3 minutes
<skaet> :)
<stgraber> SpamapS tested my fix and I'm not going to change anything else, I just checked that there's no other variables affected
<stgraber> I just uploaded the new package now, will appear in the queue soonish
<skaet> coolio
<SpamapS> stgraber: awesome, I'll re-do my test with an updated package when it appears
<skaet> ok,  its going to take a bit to build and publish SpamapS .
<stgraber> SpamapS: I can build one for you if you want.
<skaet> stgraber,  can you upload the diff?
<SpamapS> No worries, its such a simple fix, this is more of something to do while I wait for the respin.
<skaet> 		diff from 4.0-0ubuntu10 to 4.0-0ubuntu11 (pending)
<stgraber> skaet: http://paste.ubuntu.com/598809/
<stgraber> skaet: that's: debdiff lsb_4.0-0ubuntu10.dsc ../lsb_4.0-0ubuntu11.dsc | pastebinit
<joshuahoover> skaet: ping
<skaet> stgraber, thanks, looking
<skaet> stgraber,  looks good.   approved.
<skaet> joshuahoover, yup?
<joshuahoover> skaet: u1 has the following bug #770379 that we're fixing now...this was discovered by kenvandine just a bit ago...
<ubot4> Launchpad bug 770379 in ubuntuone-client (Ubuntu Natty) (and 1 other project) "Recommends wrong version of gir1.2-unity-3.0 (affects: 1) (heat: 6)" [High,In progress] https://launchpad.net/bugs/770379
<joshuahoover> skaet: the problem is it leaves unity with no u1 integration and there's a concern that even after the update, most users won't get it because it'll likely require a dist-upgrade
<joshuahoover> skaet: anyway, i'm confirming whether this update will just work for everyone once it's released as an sru or would require dist-upgrade...i'm being told now that it will be a standard update and if that's the case, then i'm less concerned (not happy with it but less concerned)
<skaet> joshuahoover, explain why no u1 integration,   I thought it was just some features not accessible, but it works. (per backsroll discussion)
<skaet> joshuahoover, expectation I had would be sru,  not dist-upgrade.   let me know if that changes.
<kenvandine> a new recommends won't get pulled in on upgrade, on dist-upgrade
<joshuahoover> skaet: ^^
<kenvandine> unless update-manager defaults to dist-upgrade
<kenvandine> but i don't think it does, maybe someone here can confirm that
<SpamapS> hmm.. when doing 0-day SRU's, should a task be opened against Oneiric so that its fixed when dev opens for Oneiric as well?
<pgraner> SpamapS, yes
<skaet> SpamapS, yes
<skaet> lol
 * SpamapS looks for the bug status "Double Confirmed"
<maco> kenvandine:  i think UM will do dist-upgrade when it needs to.  for example, when a new kernel comes out, dist-upgrade is needed to get all its accessory packages
<pgraner> maco, ah yes I think your correct
<maco> hiya pete
 * kenvandine wonders why there is a command line arg for checking for dist-upgrades
<pgraner> maco, hey
<dobey> oh of course. -release.
<pgraner> skaet, we will have a kernel update very shortly after release so we should get it for free then
<skaet> pgraner,  thanks!
<kenvandine> pgraner, ok, so you're saying U1 can just piggy back on your release upgrade?
<kenvandine> :)
<joshuahoover> :)
<pgraner> kenvandine, yep essentially
<kenvandine> joshuahoover, does that make you feel better?
<joshuahoover> kenvandine: yes, thanks :)
<kenvandine> great :)
<dobey> so there's a kernel update too?
<dobey> (sorry, i wasn't in here to see the discussion)
<joshuahoover> dobey: yes, so we should be ok with that happening
<joshuahoover> dobey: so we just do the sru as you originally talked about and i think we're good
<dobey> oh ok. and i was hoping to rush it on the CD :)
<superm1> hey folks, my lirc upload was just rejected an hour ago, i was wondering why
<slangasek> superm1: discussion in scrollback was that it should be diverted to the SRU queue at this point; the lib is seeded everywhere and we're past the deadline for non-critical fixes
<superm1> the delta isn't in the lib though, it's in the package with the init script which is only seeded in mythbuntu?
<slangasek> it doesn't matter, the packages have to be up to date on the images and the images are already being spun
<smoser> skaet, is there a list of bugs that image-spins would be waiting on ? i'm wanting to see if the uec images from today would be considered suitable at the moment.
<superm1> oh, man, that's really unfortunate - this affects the most common remote. i thought mvo had uploaded it and just checked and found he hadn't
<maco> superm1: sru?
<skaet> superm1,  please get into proposed and it will be approved for zero day upload.
<superm1> ok
<slangasek> superm1: sorry to hear that.  maybe for oneiric we should figure out how to avoid liblircclient being included on the CDs?
<slangasek> (is the lib useful without lirc itself, anyway?  if we could get that pulled in opportunistically, maybe that's a better model)
<superm1> that does sound like something that would be a good goal either way, especially with CD's needing to learn how to fit Qt and stuff in
 * slangasek nods
<superm1> it's not useful at all without lirc installed, so indeed
<skaet> smoser,  only bug we're waiting on right now is langpacks.
<smoser> so.. images built ~ 01:00 UTC.
<smoser> anything post that time frame that would require it ?
<skaet> pitti should be coming online soon, and we will be building tonight for the subset that are affected.  No estimate on time at this point,  soonest is the hope.
<skaet> slangasek, stgraber,   pgraner and I are shifting to grab some dinner and set up at the hotel.   Appreciate you keeping an eye open for pitti showing up.
 * skaet --> dinner
<pitti> hello
<stgraber> hi pitti
<pitti> rickspencer3: helo
<stgraber> pitti: we have a small langpack issue for you :)
<stgraber>  language-pack-kde-sv : Depends: language-pack-sv-base (>= 1:11.04+20110421) but 1:11.04+20110407 is to be installed
<pitti> stgraber: yes, that's what I got called for
<pitti> oh, so some packs are missing?
<pitti> I'll check what happened to them
<pitti> they should all have been rebuilt
<stgraber> yeah, seems like language-pack-sv-base never got uploaded
<pitti> grep-dctrl -P language-pack- archive.ubuntu.com_ubuntu_dists_natty_main_binary-amd64_Packages  | grep-dctrl --not -FVersion -sPackage 1:11.04+20110421
<pitti> ugh, 106 packages
<pitti> it seems the build collided with the lucid cronjob, darn
<pitti> I'll get them uploaded
<rickspencer3> hi pitti
<rickspencer3> thanks for coming back
<pitti> rickspencer3: thanks for the call
<GrueMaster> Hmmm.  natty-preinstalled-netbook-armel images don't seem to be playing the ubiquity slideshow anymore.  Not a show stopper as it doesn't affect image first boot, but an odd issue.
<pitti> oh dear
<GrueMaster> I'll file a bug once I am done booting and can see the logs.
<pitti> rickspencer3, stgraber, skaet: all missing packages should be uploaded and building now
<slangasek> pitti: thanks :)
<pitti> https://launchpad.net/builders says ETA 40 minutes to build them all
<pitti> so archive should be good in about 3 hours
<stgraber> yeah! thanks pitti
<cjwatson> Riddell: whoa, re your comment about zh having its own remix
<cjwatson> Riddell: the Chinese remix uses the exact same livefs and package sets as the normal CDs - it just has a different /isolinux/lang
<cjwatson> I'm pretty worried about us having dropped the zh-hans language pack off the i386 CD - that should've been checked with OEM
<cjwatson> rickspencer3: ^- is my instinct correct that the above would be a problem?
<stgraber> I don't think we built anything with that change yet, so we can still remove something else if removing chinese is indeeed an issue (de or fr seem good candidate as they are only seeded for i386 at the moment)
<cjwatson> though it'll take two publisher runs
<cjwatson> but yeah, my instinct is that we should because there are these special arrangements at the moment that necessitate having Chinese support on the desktop CD
<cjwatson> and it's too late to attempt to redo the infrastructure for that
<stgraber> cjwatson: are you doing it or should I ? (I'd revert the seed, drop fr from i386 and re-apply the powerpc change)
<GrueMaster> I've just verified that the ubiquity slideshow not running is armel specific (ran fine in my x86 VM).  Since oem-config still runs through the install fine, I'll file a bug as a low priority.  I don't think it is respin necessary.
<cjwatson> stgraber: I'm not
<stgraber> ok, doing it then
<stgraber> done
<pitti> cjwatson: zh-hans> how so?
<pitti>  * Languages: es xh pt zh-hans
<pitti> these are on all desktop images
<cjwatson> pitti: bzr up
<stgraber> pitti: I reverted to that a few minutes ago
<cjwatson> pitti: oh, yeah, see r1826 and r1828
<pitti> good night everyone
<rickspencer3> cjwatson, yes, that sounds like a problem
<cjwatson> stgraber has initiated the fix
<cjwatson> rickspencer3: (thanks for confirming)
<cjwatson> hm, drat, I should have forced the publisher to run this cycle
<rickspencer3> cjwatson, yes, I saw, thanks
<cjwatson> though no convenient universe packages to accept
<rickspencer3> cjwatson, it's nice to have you back from holiday :)
<cjwatson> well, only for a bit, need to go to sleep soon to get to London tomorrow morning
<pitti> skaet, slangasek: is either of you building CDs? if not, I'd like to smuggle in a tzdata sync, as there's again a high-urgency update
<slangasek> pitti: last I knew, we had final-ish Ubuntu desktop and server CD candidates that we weren't expecting to respin; I guess this is affected by the above discussion about zh langpacks, though?
<stgraber> slangasek: that and mdadm failing on alternate/server builds
<slangasek> ok
<rickspencer3> stgraber, pitti couldn't tzdata and the mdadm fix be picked up in an SRU?
<pitti> slangasek: I'd guess so; they shouldn't be affected by the missing langpacks, though
<pitti> rickspencer3: tzdata yes; I don't know about mdadm
<slangasek> pitti: I'm not building any CDs yet, no; if there's a decision to respin everything, then that's fine
<stgraber> rickspencer3: the mdadm issue was actually a lsb issue. It's already in the archive, just waiting for a respin.
<slangasek> "lsb issue"?
<pitti> slangasek: ok, nevermind then
<stgraber> rickspencer3: the issue with it was that in raid setups mdadm wouldn't even start, so you could end up with broken raid setups post-install.
<stgraber> slangasek: yeah, mdadm is using "set -eu" and the lsb logging script was using [ -z "$SOME_VARIABLE" ] with $SOME_VARIALBE not being defined in some cases
<maxb> SOME_VARIABLE being LOG_DAEMON_MSG ?
<stgraber> slangasek: so the mdadm init script would exit before mdadm would start (possibly affects other init scripts). I uploaded a fix a few hours ago.
<stgraber> maxb: yep
<slangasek> stgraber: oh wtf, please tell me the fix in the upload is to drop the "-u"
<cjwatson> pitti: a tzdata sync would actually be convenient, because it would force the second publisher run to suck in the langpack seed fix
<stgraber> slangasek: nope, I "fixed" lsb by setting the variable. Someone should "fix" mdadm by removing the -u
<slangasek> stgraber: ah, so it's actually lsb that's been uploaded, not mdadm?
<stgraber> right
<cjwatson> (I could do that by hand, but my daughter has just taken over the keyboard of the relevant machine to play cbeebies games)
<slangasek> right, I guess I did see that from queuebot this morning
<cjwatson> and in any case I prefer not doing it by hand if I don't have to
<pitti> cjwatson: so want me to sync?
<slangasek> pitti: I think you should, yes
<cjwatson> yes please
<pitti> Egyptians will be happy :)
<pitti> (one should think that they'd have more important things to do than changing their DST rules right now..)
<slangasek> hah
<pitti> done; really sleep now, see you tomorrow!
<slangasek> 'night, pitti
<stgraber> good night
<ScottK> cjwatson: If you still need publisher runs there's a couple of sync requests in queue.
<cjwatson> didn't think of that, thanks.  should be OK for now, I'll peer at them tomorrow morning at the latest
<skaet> slangasek, cjwatson, stgraber - back from dinner now.   Don't see anything running on antimony now - what's ready from your perspective?
<slangasek> skaet: with tzdata just accepted, I don't think anything's ready at the moment, but once tzdata publishes we should be good to start building everything
<ScottK> That and a second publisher run for the Ubuntu seed changes stgraber did.
<skaet> so, basically queue up the full set of images (cd, alternate, dvds & armel),  or are there some we can live with as is?
 * skaet read through backscroll
<cjwatson> ScottK: tzdata should cover that
<ScottK> OK
<ScottK> tzdata hits them all.  IIRC mdadm does as well.
<cjwatson> of the two publisher runs for a seed change, the first one only needs to involve running germinate, which isn't conditional on the relevant pocket being dirty
<cjwatson> the second one is the one that needs the pocket to be dirty
<cjwatson> mdadm predated the seed change, didn't it?
<cjwatson> oh, sorry, you didn't mean that by "hits them all".
<cjwatson> I think we need to do the lot in any case, yes.
<cjwatson> should be good once this publisher run finishes
<skaet> slangasek , you ok with kicking the full set off?
<slangasek> skaet: I'm not sure I have a handle on what constitutes the "full set" at the moment - everything in cron?
<skaet> slangasek,  cron has more than we're shipping,  so subset.  List can be found on iso tester.  http://iso.qa.ubuntu.com/qatracker/
<slangasek> ok
<skaet> slangasek,  if I assemble the two sets of commands (one for armel, one for rest) would that help?
<skaet> or do you prefer to edit down the cron list?
<cjwatson> publisher's done now
<cjwatson> I'll just check the Task fields
<cjwatson> yep, all fine
<slangasek> skaet: if you have an example of how you usually launch the milestone builds, I can take it from there
<cjwatson> bed - see folks tomorrow
<slangasek> 'night
<skaet> cjwatson,  sleep well - looking forward to seeing you tomorrow.
<skaet> slangasek,  working on it for you.
<skaet> slangasek,  any questions before i turn in,  jetlag/long day is starting to catchup.
<slangasek> none :)
<skaet> thanks slangasek.  please post the images here as the come off (or at least the order to check for them) when picking up the threads in the morning.
<skaet> good night
<slangasek> 'night!
<ScottK> slangasek: FYI, we have a multiverse package sitting in queue if you end up needing to stimulate a publisher run.
<slangasek> ScottK: ack, thanks
<ScottK> I'd left a Universe package there before, but someone had accepted it when cjwatson needed it.
<ScottL> skaet_, downloading and will test tonight
<slangasek> hrm, still not seeing tzdata 2011f-1 in the archive, not sure what's going on
<slangasek> hmm - buggy tools, it's in the Packages.gz.
<slangasek> ok, everything marked for respin on the tracker
<slangasek> alternate CDs up again soon; order is ubuntu kubuntu xubuntu ubuntu-server ubuntustudio
<slangasek> liveCDs to follow, order kubuntu-mobile ubuntu kubuntu xubuntu mythbuntu
<ScottK> No mythbuntu alternates?
<ScottK> ScottL: You'll need to wait for the respin to have something to test.
<slangasek> ScottK: never have been, TTBOMK
<ScottK> OK.  I lose track.
<superm1> never been a need for them that was vocal enough to merit the effort
<ScottK> Nevermind, my mistake.
<superm1> i am a bit curious though, these days what is the use case for having alternates of all these varieties?
<ScottK> I'm wondering the same thing.
<ScottK> I think for Kubuntu we should consider to drop it this next cycle, particularly since our primary ISO tester will be on rotation to Launchpad.
<charlie-tca> Alternates allow options during the installation that the desktop image does not
<charlie-tca> I can name the directories with it, but am forced to use the names in a list with the desktop image
<slangasek> Ubuntu alternate posted
<charlie-tca> guided resize on any hard disk with the alternate image, but not with the desktop image
<superm1> well if these are important options, is maybe a better idea to find a way to get them in the desktop image so that testing efforts don't need to be misdirected though if they're not highly used?
<charlie-tca> They have been removed from the desktop image this cycle
<charlie-tca> I have a music partition on my computer. With the desktop image, I can not use it unless I add it after the installation.
<ScottK> Right, but the same users that generally care about such options can use the server ISO and then add their metapackage of choice after.
<charlie-tca> Sure, if you want to make them do it that way.
<ScottK> It's a question of if it's worth the extra effort involved.
<maco> charlie-tca: the desktop image should still have a manual partitioning option
<charlie-tca> It doesn't
<ScottK> The Kubuntu desktop one does.
<charlie-tca> when you select manual partitioning, you can not enter the partition names
<charlie-tca> bug 769043
<ubot4> Launchpad bug 769043 in ubiquity (Ubuntu Natty) (and 1 other project) "Cannot manually specify a mount point in the manual partitoner (affects: 3) (dups: 1) (heat: 26)" [Medium,Triaged] https://launchpad.net/bugs/769043
<ScottK> Right, you can't do that.
<charlie-tca> Makes the partitions I have used for 5 years unusable now?
<charlie-tca> but, those are just my reasons to keep the alternate install image
<superm1> maybe it's worthwhile to put together a session to discuss all the other reasons people bring to the table for wanting to keep them around in the variants that have both live and alternate currently available at uds then
#ubuntu-release 2011-04-26
<charlie-tca> Or allow each distribution to decide, if possible.
<charlie-tca> If you really can't support both, you should not be placed in a position that says you will.
<slangasek> lamont: acorn is declining to reply to ssh; can you persuade it?
<GrueMaster> So, what's the current reason for the armel image respin?
<slangasek> GrueMaster: there were updates to packages (lsb, tzdata) present on all images
<GrueMaster> grumble.
<GrueMaster> Good thing I keep a list of bugs on my notepad.
<slangasek> kubuntu-mobile (i386) posted; xubuntu alternate posted
<slangasek> (kubuntu alternate as well)
<slangasek> ubuntu desktop posted
<slangasek> kubuntu desktop posted too
<slangasek> ubuntu-server posted
<slangasek> xubuntu desktop posted
<lamont> slangasek: acorn persuasion is done with an honest to goodness human finger applied in the right place
<lamont> sadly, we have no such fingers in that data center at this time.
<lamont> slangasek: so annonaceae is about to become the new acorn
<lamont> though, well, PROCESS.
<lamont> I'll update you has I have word
<slangasek> ok; I'll be afk for the next hour or so
<lamont> OK.  TOTALLY ECHAN and all that.. but HTF do I get compiz to quit deciding that just because I bumped into thte top of the screen that I MUST want it to do fullscreen with the window that I'm MOVING???
<lamont> </rant>
<ScottK> lamont: Come on, you know configuration options are evil and must be avoided.  User choice is more trouble than it's worth.
<lamont> 421 4.4.2 Message submission rate for this client IP add
<lamont> ress has exceeded the configured limit (in reply to MAIL FROM command) <-- now that's just plain rude
<lamont> ScottK: gar
<lamont> what's worse is that after you de-fullscreen it, you get to start over agian
<lamont> someone clueful wanna give me an example package that acorn actually builds?  or shall I just test it with base?
<lamont> s/it/annonaceae/
<highvoltage> all of that is configurable in ccsm
<charlie-tca> slangasek: thanks.
<lamont> sladen: finally actually heading home.  On the bright side, there's a fair chance that once I'm there it'll take less than 5 minutes to have annonaceae live for you
<lamont> slangasek: ^^
<lamont> have I mentioned that 3 characters + tab should be SUFFICIENT?
<slangasek> mythbuntu, edubuntu posted
<slangasek> that leaves arm (waiting for acorn++ to be online); ubuntu, kubuntu dvds
<stgraber> yeah! /me starts downloading
<slangasek> it's so hard to not type 'syncamore'
<slangasek> all the omap4 builds have cleared on sycamore, so I'm starting the first of the omap builds over there to soak up the spare buildd cycles while waiting for onomatopoeia.buildd to come online
<ScottL> are the alternative images rebuilding again?
<slangasek> not "again", the alternate image respin started 4 hours ago and has finished now for all flavors
<slangasek> skaet_, cjwatson: it looks like the livefs builds are done with natty-security enabled, and the alternate builds without (noticed via http://reports.qa.ubuntu.com/reports/ogasawara/weatherreport.html due to krb5) - is this intended/expected?
<slangasek> wow, http://cdimage.ubuntu.com/daily-live/current/ got spiffed up when I wasn't looking
 * lamont returns
<stgraber> hmm, looks like removing language-support didn't help much for the powerpc image
<stgraber> I'm wondering what can be removed to get it under 700MB and still have it working ...
<lamont> slangasek: kick a build on annonaceae.buildd?
<lamont> slangasek: give it a minute more
<slangasek> lamont: say when
<lamont> slangasek: kick it
<slangasek> it seems to like me
<lamont> \o/
<SpamapS> hrm.. iso.qa.ubuntu.com doesn't seem to be working for me
<stgraber> SpamapS: loads fine here
<SpamapS> just spinning for me. :-/
<SpamapS> SYN begat no ACK
<lamont> slangasek: I'd be interested to know how timings compare (in the post-ubuntu-headless cases)
<lamont> slangasek: I'm asserting that the acorn->annonaceae change is permanent, fyi
<lamont> that at least gives us one livecd builder that we can remote powerstab
<ScottK> Because you're evil and like to give people difficult names to type?
<lamont> ScottK: ah, come on, it's not that bad
<lamont> it's not actinidiaceae
<lamont> and 'aceae' falls trippingly off the left hand with practice...
<ScottK> It has more vowels (almost in a row) than it's predecessor has letters.
<lamont> 'c' is not a vowel
<ScottK> Thus the almost.
<cjwatson> lamont: I gave you the exact compizconfig-settings-manager thing for disabling fullscreen-on-drag-to-top the other day
<ScottK> OK, half in a row.
<lamont> custard apple.
<lamont> cjwatson: oh!  so I just fail at reading.  this is cool
<lamont> except for the failing part
<cjwatson> 22:54 <cjwatson> or Grid -> Edges -> Resize Actions -> Top Edge = None
<cjwatson> slangasek: I can't decide which one of those two surprises me
 * ScottK found building with -security suprising, but not necessarily a bad thing.
<lamont> I suspect that -security may be my doing
<cjwatson> it's easy to change for the alternates/server if we want to (debian-cd/CONF.sh SECURITY=)
<lamont> 185      adconra |     echo deb $MIRROR ${STE}-security ${COMP} >> ${ROOT}etc/apt/sources.list
<lamont> 'twasn't me
<lamont> 64  lamont@ | deb ${SECMIRROR} ${STE}-security ${COMP}
<lamont> meh
<lamont> it's only built with -security since januaru 2005 <-- slangasek
<ScottK> Right, the part that's different is -security not being empty at release.
<lamont> or for any .X subsequent release
<lamont> it's a religious thing
<ScottK> cjwatson: I'm off to bed.  There are three syncs waiting for you.  There are also some unprocessed removal bugs.  I also left one package in the queue for if you need to stimulate a publisher run.  I'll reappear in about 6 hours to see if anything else got uploaded before the unseeded final deadline.
<slangasek> lamont: timings look pretty comparable between annonaceae and sycamore - right on the order of 1h
<slangasek> I don't have any relevant successful runs on acorn to compare with
<cjwatson> ScottK: right, thanks
<skaet> hmm... seems there are some builds still failing due to synching locks
<slangasek> transient error, please ignore the mail :)
<skaet> slangasek,  coolio.   what's left?  and how look the images from the last few hours?
<slangasek> left still are arm images, due to a builder problem plus a typo in my last bit of shell scripting; they should start arriving shortly
<cjwatson> unless we want to rebuild alternates/servers with -security on
<cjwatson> but perhaps we should just leave that alone for this cycle
<skaet> cjwatson,  +1 for leave alone at this point unless someone comes up with a VERY good reason.
<cjwatson> nah, I'm easy, let's just leave it then
<skaet> slangasek,  I'm not seeing the DVD's on the iso tracker.  Have they emerged?
<slangasek> skaet: yes, posted < 20min ago - refresh?
<skaet> slangasek, yup,  refresh was needed.
<skaet> thanks
<skaet> cjwatson,  you in london now?
<cjwatson> no, just about to leave Cambridge
<slangasek> and please ignore /those/ mails also
 * slangasek whistles and hits ^C a few more times at random
<cjwatson> I should be there by 9:30 or so assuming there's no particular transport chaos
<cjwatson> packing up now, see you on the other side
<skaet> sounds good,  can you take a quick look at: https://bugs.launchpad.net/wubi/+bug/770256
<ubot4> Launchpad bug 770256 in ubiquity (Ubuntu) (and 2 other projects) "Reboots after Wubi install via ubiquity repeatedly ask to uninstall (affects: 1) (heat: 6)" [Undecided,New]
<skaet> cjwatson,  never mind.   We'll talk about in london.
<slangasek> "assuming these images test out, and the British rail system is reliable, we'll have an on-time release"
<slangasek> ;)
 * skaet shakes head,  and wonders what else murphy has in store :P
<skaet> slangasek,  thanks for pushing those images through for the last few hours.   Appreciate it.
<slangasek> no prob
<skaet> slangasek,  what order are the arm images building in?
<slangasek> skaet: ubuntu-netbook will be done shortly, then kubuntu, ubuntu-headless, kubuntu-mobile
<slangasek> (order scrambled somewhat compared to what was originally queued, due to the builddery)
<skaet> slangasek, cool,  thanks.  let me know when you're calling it a night,  and I'll start monitoring/posting until cjwatson arrives in london.
<slangasek> oh, actually, looks like kubuntu-mobile will be done before ubuntu-headless
<slangasek> and furthermore they should all be done within the hour
<skaet> sweet.  :)
<slangasek> right, there's ubuntu-netbook
<slangasek> kubuntu desktop preinstalled posted
<skaet> GrueMaster, Riddell, ScottK,  ^^
<slangasek> kubuntu-mobile up
<slangasek> ubuntu-headless up, and that's a wrap
<slangasek> skaet: over to you :)
<pitti> Good morning
<pitti> slangasek, cjwatson: for the record, in case you ever need a harmless main package to put a seed change into effect, we could sync tzdata again
<pitti> (we'll prepare an SRU for it)
<skaet> slangasek,  thanks!   sleep well.  :)
<skaet> good morning pitti
 * skaet --> breakfast, then shifting to office.  biab
<smoser> skaet, good morning.
<smoser> any reason that jamespage and i should not start testing today's uec images
<skaet> smoser,  jamespage - no reasons on my horizon,  go at it.
<smoser> skaet, thank you
<smoser> skaet, so you or someone else ther ecan then seed the iso tracker from http://uec-images.ubuntu.com/server/natty/20110426/
<skaet> smoser,  ok,  will do
<jibel> ev, another 'out of memory' crasher, bug 770865
<ubot4> Launchpad bug 770865 in ubiquity (Ubuntu) "ubiquity crashed with IOError in command(): [Errno 32] Broken pipe (affects: 1) (heat: 10)" [High,Triaged] https://launchpad.net/bugs/770865
<jibel> but it crashed at a different place than bug 769359
<ubot4> Launchpad bug 769359 in ubiquity (Ubuntu) "Out of memory error on Kubuntu full disk install (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/769359
<jibel> ev, could it be a problem with swap space being disabled at some point ? I noticed that in both cases "Total swap = 0kB"
<ev> well, the installer will swapoff on any devices you're going to wipe
<ev> jibel: I'm going to have a play around with kvm in a minute
<cjwatson> partman-auto upload on its way to release pocket, acked by skaet and pgraner, reviewed by ev; fixes bug 770041, which is fatal to server installs in certain pre-existing situations and cannot be fixed post-release
<ubot4> Launchpad bug 770041 in partman-auto (Ubuntu Natty) (and 1 other project) "partitioner hangs if libparted sees partitions for which device nodes don't exist (affects: 1) (heat: 8)" [High,In progress] https://launchpad.net/bugs/770041
<ev> new wubi is up, waiting on cmsj to sign before it's ready for the next CD build
<pitti> cjwatson: that affects all images except arm preinstall, I suppose?
<cjwatson> pitti: server and alternate
<pitti> ah
<cjwatson> pitti: theoretically desktop too but I can't ever see anyone attempting a desktop install in the kind of partitioning environment that would trigger it
<cjwatson> at the very least it'll be a few orders of magnitude rarer
<cjwatson> so I'm not inclined to worry about that
<ScottK> cjwatson or pitti: There's three removal bugs still pending for ubuntu-archive.  Can they be dealt with post-release?
<ScottK> post/pre
<ScottK> (early here)
<ScottK> Also there's still one multiverse package in queue I've been holding in case you need a publisher run.  We're 5 minutes from Unseeded freeze, so I do plan to accept it unless I hear otherwise.
<ScottK> skaet: ^^^
<pitti> ScottK: I'll look at the removal bugs
<ScottK> Thanks.
<jibel> pitti, is it intended to have german langpack only on i386 ?
<jibel> I mean on the iso
<pitti> jibel: "intended" is too strong, but we can't fit it on amd64, I guess
<ScottK> I'd say we 'intend' things to fit on one CD.
<ScottK> The rest is just consequences.
<pitti> i386 still has 15 MB free, so we could add French back
<ScottK> ev: My crash happened after swapoff (I did see that in top the time I tried to see if I could catch a memory spike anywhere)
<ScottK> (769359)
<jibel> pitti, ScottK  :-) ok, thanks
<cjwatson> ScottK: yeah, I was about to start looking at the removal bugs, having just done the sync ones
<cjwatson> but if pitti is working on them, that's fine too
<pitti> jibel: chrisccoulson was just pointing out a rather severe bug in language-selector; did you see test results for non-English installations?
<pitti> it still tries to install gnome-user-guide-LANG, but these were removed in a recent gnome-user-docs upload
<jibel> pitti, I'll reproduce. give me 15 minutes
<pitti> jibel: if it just happens in the GUI, it's fine for an SRU, but I'm worried if that breaks actual installations, as it uses a script in language-selector to figure out missing packages
<pitti> chances are that it won't, and that ubiquity will just ignore the missing packages
<chrisccoulson> pitti - bug 771176 (i can't target it though)
<pitti> ScottK: removals done
<ubot4> Launchpad bug 771176 in language-selector (Ubuntu) "langauge-selector non-functional in natty due to missing gnome-user-guide-xx packages (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/771176
<ScottK> Thanks.
<jibel> pitti, it doesn't break installation. I tried French and German this morning
<ScottK> I'm going through the -release bugs now.
<pitti> jibel: *phew*
<pitti> jibel: merci beaucoup for testing
<pitti> chrisccoulson: pushed a fix, uploading to -proposed; thanks!
<chrisccoulson> pitti - cool, thanks for fixing quickly :)
<jibel> pitti, bitte
<cjwatson> pitti: we had to take a language pack out.  how's there suddenly room to put it back in?
<pitti> cjwatson: not sure; but the image is 685 MB, French takes 14.3 MB; so perhaps the rounding is too optimistic and it would overflow
<pitti> I didn't touch the seeds so far; there'd be too little margin for build/compression noise either way
<pitti> lunch, bbl
<ScottK> pitti: Looks like one of the VDR sync's didn't get done: Bug 768200
<ubot4> Launchpad bug 768200 in vdr-plugin-osdteletext (Ubuntu) "Sync vdr-plugin-osdteletext 0.9.0-3 (universe) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,Confirmed] https://launchpad.net/bugs/768200
<pitti> ScottK: oh, doing
<ScottK> Thanks.
<cjwatson> pitti: yeah, I'd prefer to leave it now
<pitti> ScottK: speaking about syncs, WDYT about bug 752396 ?
<ubot4> Launchpad bug 752396 in bzr-fastimport (Ubuntu) "bzr-fastimport is not listed in "bzr plugins" list (affects: 2) (heat: 16)" [Undecided,Confirmed] https://launchpad.net/bugs/752396
 * pitti checks debdiff
<ScottK> pitti: I'd say go for it.
<pitti> (it's not on any image)
<pitti> ok, it fixes just that, plus test suite updates; syncing
<cjwatson> ogra_: so, this bug with double "headless" in image names: it's currently that way for preinstalled-netbook images too.  would you be OK with both of those ending up as ubuntu-11.04-preinstalled-{headless,netbook}-armel+{omap,omap4}.img.gz?
<cjwatson> that seems to me to be the right one of the dup pair to drop
<ogra_> sure
<ogra_> i dont really care which one we drop as long as the duplication is gone :)
<cjwatson> I think if I do that they may also end up in http://cdimage.ubuntu.com/releases/natty/release/ rather than http://cdimage.ubuntu.com/ubuntu-{headless,netbook}/releases/natty/release/
<cjwatson> is that OK too?
<ogra_> definitely better ! :)
<ogra_> we'll need to adjust wiki docs though (/me makes a note)
<ScottK> Release team bug list is now empty.
<jamespage> skaet: hey
<jamespage> skaet: we seem to be missing a few test cases from the ISO tracker for asia-pacific regions - the EBS tests are missing
<jamespage> skaet: can you fix this up for me?
<skaet> jibel,  ^^ can you help jamespage?
<pitti> ScottK: empty bug list> great work!
<ScottK> Thanks.
<jibel> jamespage, ap ebs is there now.
<jibel> 4 were missing
<ogra_> ScottK, btw, i filed a spec request to better document whats needed to enable new unsupported community images, i hope we can work through that together to have a list of things future people need to regard to get community images for new arches
<ScottK> Great.
<jamespage> skaet, jibel: thanks
<ev> jibel: not sure if you saw the note about the impending non-livefs desktop respin for the wubi fix.
<ev> but yeah, we're respinning the cd without a new livefs
<cjwatson> rebuilding server and alternates: echo ubuntu server; for-project ubuntu-server cron.daily; echo ubuntu alternate; for-project ubuntu cron.daily; echo kubuntu alternate; for-project kubuntu cron.daily; echo xubuntu alternate; for-project xubuntu cron.daily; echo ubuntu studio; for-project ubuntustudio cron.daily
<cjwatson> (for partman-auto 93ubuntu16)
<skaet> jibel, pgraner,  ^^
<pgraner> skaet, ack
<pgraner> jibel, rebuilding server and alternates
<jibel> pgraner,  desktop as well (for wubi) ?
<cjwatson> jibel: we don't have a signed image from IS yet
<cjwatson> RT#45487
<jibel> ok
<cjwatson> desktop and I guess DVD ought to go after that
<stgraber> good morning
<pgraner> stgraber, morning
<stgraber> cjwatson: not sure if it's documented anywhere but Edubuntu doesn't ship wubi (we'll probably want to change that for Oneiric though) so we won't need a rebuild for wubi
<jibel> stgraber, in bug 770381 there's a task opened for mdadm, is there something left to do or should I close it ?
<ubot4> Launchpad bug 770381 in mdadm (Ubuntu) (and 1 other project) "mdadm does not start automatically at boot due to LOG_DAEMON_MSG being unset (affects: 2) (dups: 1) (heat: 14)" [Undecided,New] https://launchpad.net/bugs/770381
<stgraber> jibel: hmm, forgot to mark this one invalid. The bug was in lsb, not mdadm (though mdadm's init script could be improved, but that's not really a bug)
<jibel> stgraber, ok thanks
<cjwatson> stgraber: noted, thanks
<cjwatson> IIRC it's just Ubuntu and Kubuntu
<jibel> cjwatson, what's the status of bug 728088, no fix for final ?
<ubot4> Launchpad bug 728088 in debian-installer (Ubuntu Natty) (and 1 other project) "iscsi root with or without auth fails to boot (affects: 2) (heat: 80)" [High,Confirmed] https://launchpad.net/bugs/728088
<cjwatson> jibel: I don't know, I was actually about to ask Daviey about it when he came back into the room
<cjwatson> he had ownership of figuring out a way to reproduce it
<cjwatson> stgraber: hm, in fact it really is "everything but Edubuntu"
<cjwatson> not entirely sure if say kubuntu-mobile really needs it ...
<stgraber> yeah, and Edubuntu missing it isn't intentional. I only looked for it 2 days ago so it was a bit late to get it fixed :)
<cjwatson> stgraber: it was intentional at one point - we have explicit code for it in cdimage
<cjwatson>                 if [ "$PROJECT" != livecd-base ] && [ "$PROJECT" != edubuntu ]; then
<stgraber> could that be some remaining code of the addon cd era ?
<stgraber> hmm, I'd guess not as the addon didn't have a livefs so shouldn't have had wubi for that reason
<stgraber> anyway, it's in our Oneiric todolist to see if wubi works properly with Edubuntu and if so, have it put back on the DVD
<cjwatson> stgraber: I think there was something to use umenu rather than wubi on the add-on CDs, maybe
<Daviey> jibel, So, i tried to reproduce it in virtualbox, and didn't see the issue. :/
<cjwatson> Ubuntu server, Ubuntu alternate, Kubuntu alternate posted
<cjwatson> Xubuntu alternate posted
<jibel> Daviey, sorry, my connection dropped.
<jibel> Daviey, did you talk to patrickdk, the user who reported this issue. He's usually on #ubuntu-testing
<cjwatson> Ubuntu Studio posted
<cjwatson> is anyone going to fix kubuntu-full to be installable?  (http://people.canonical.com/~ubuntu-archive/testing/natty_probs.html)
<ScottK> Let me look into it.
<cjwatson> seems to be a disagreement about the exact set of available language packs
<cjwatson> possibly an SRU at this point, since it would be nice not to have to rebuild desktop livefses?
<ScottK> cjwatson: I think armel probably isn't trivially fixable.  We don't have a dvd for that, so I'm reasonably sure we don't care.
<cjwatson> I was more asking for x86 really
<ScottK> That's about done.
<cjwatson> ok, sru?
<ScottK> Yes.
<ScottK> Uploaded.
 * cjwatson nods, thanks
<cjwatson> we probably ought to rebuild the Kubuntu DVD livefses against that
<cjwatson> (http://cdimage.ubuntu.com/kubuntu/dvd/current/report.html)
<ScottK> You want it to -release then?
<cjwatson> no, I think -proposed would be ine
<cjwatson> *fine
<cjwatson> saves skew between release archive and the desktop images
<cjwatson> since it's a binary of kubuntu-meta
<ev> signed wubi is now in the right place
<ev> cds should be ready to go
<cjwatson> ScottK: is it intentional that kubuntu-mobile includes wubi?
<ScottK> No.
<ScottK> There's no use case where we would possible care.
<ScottK> possible/possibly.
<cjwatson> should I respin and remove it, or just leave it as is?
<ScottK> There's no testing on the current image, so respin without it would be nice, but it's perfectly acceptable to leave it as is.
<ScottK> (I don't know what else you've got on your plate, so low priority)
<cjwatson> I've committed the code change for that, in any event
<cjwatson> so I can do that at the end of the list
<cjwatson> thanks
<cjwatson> charlie-tca: do you want to respin Xubuntu for bug 770256?
<ubot4> Launchpad bug 770256 in ubiquity (Ubuntu) (and 2 other projects) "Reboots after Wubi install via ubiquity repeatedly ask to uninstall (affects: 1) (heat: 6)" [High,Invalid] https://launchpad.net/bugs/770256
<cjwatson> superm1: do you want to respin Mythbuntu for bug 770256?
<ScottK> cjwatson: Updated kubuntu-meta is in queue for -proposed.
 * cjwatson looks
<cjwatson> thanks, accepting
<charlie-tca> How bad is that going to screw up the windows users?
<ogra> hmm, somehow the slideshow vanished from out preinstalled images
<charlie-tca> I think I can release note, thus no respin needed for 770256
<ogra> i would have blamed the latest meta upload, but nothing regarding the slideshow changed in the seeds
<ogra> so i dont get why it wouldnt end up on the images
<superm1> cjwatson, no concerns for mythbuntu respinning for that -
<cjwatson> superm1: so respin or no?
<cjwatson> charlie-tca: FWIW I'll be respinning Ubuntu and Kubuntu, if that influences your decision
<charlie-tca> Okay, go ahead and respin it, I don't have any tests done yet anyway
<cjwatson> righto - thanks
<scott-work> cjwatson: if we end up respinning ubuntustudio-alternative again could you give me a heads up, i have people who are scheduled to test
<cjwatson> (it'll be a livefs-only respin)
<cjwatson> scott-work: the one that was just done is the last I know of
<cjwatson> scott-work: sorry if it interfered, I didn't see many tests already there
<jdstrand> robbiew, Daviey: fyi, bug #771305
<ubot4> Launchpad bug 771305 in samba (Ubuntu) "smbd does not start on first boot with 20110426 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/771305
<jdstrand> s/first boot/reboot/
<superm1> cjwatson, no respin
<cjwatson> superm1: ok, thanks
<robbiew> jdstrand: ack...will look at it...thnx
<jdstrand> robbiew: seems upstarty, fwiw
<robbiew> yeah...that's what I suspect
<jdstrand> robbiew: I saw it yesterday too, I apologize for not filing a bug then (I only made a comment in the test case; thought it was intermittent, but today after several reboots it was not)
<robbiew> no worries...not a HUGE bug and seems like an easy SRU
 * jdstrand nods
<ScottK> Famous last words ...
<robbiew> ScottK: heh...indeed
<Daviey> jdstrand, thanks
<cjwatson> Xubuntu alternate posted (again)
<ogra> cjwatson, we might need a respin for omap3, can we roll that subarch separately (so we dont need to retest omap4)
<cjwatson> ogra: that is possible, yes
<ogra> k, thanks
<cjwatson> damn, need to get round to respinning desktops!
<ogra> still discussing (david just talks to kate)
<cjwatson> (caught up in RL conversations)
<ogra> :)
<cjwatson> echo ubuntu desktop; for-project ubuntu cron.daily-live && build-chinese-edition /srv/cdimage.ubuntu.com/www/full/daily-live/current/natty-desktop-i386.iso; echo kubuntu desktop; for-project kubuntu cron.daily-live; echo xubuntu desktop; for-project xubuntu cron.daily-live
<cjwatson> running
<stgraber> cjwatson: is there a specific package to report bug against for the timezone selection in d-i ?
<cjwatson> stgraber: yes, tzsetup
<stgraber> cjwatson: my IP here got added to maxmind's database just a few months ago and the Canonical geolocation server wasn't updated since then, so it selects "None" as the timezone and doesn't seem to be bothered about it :) (I'd expect d-i to prompt me to choose a valid timezone then)
<cjwatson> yes, that does seem odd
<elmo> wait, wut?  we have a maxmind subscription
<elmo> or is this the non-maxmind DB?
<cjwatson> it's whatever http://geoip.ubuntu.com/lookup does
<stgraber> elmo: geoip.ubuntu.com my IP is 74.114.101.93
<stgraber> elmo: on maxmind's website I correctly get Country, Region, Region Name, City, ... but /lookup returns None for pretty much everything
<dobey> what is the 'deadline' for being able to have 0-day SRU?
<stgraber> elmo: bug 771361 has the output of /lookup from here
<ubot4> Launchpad bug 771361 in tzsetup (Ubuntu) "When IP isn't in maxmind's database, None gets selected as a locale (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/771361
<cjwatson> dobey: release
<dobey> cjwatson: ok, so anything i upload to -proposed today should be able to get in?
<dobey> or tomorrow even i guess
<cjwatson> dobey: in principle yes, though you'll have to let us know
<ev> (fwiw, http://geoip.ubuntu.com/lookup?ip=74.114.101.93 )
<cjwatson> (if you want expedited processing)
<dobey> cjwatson: ok, will do, thanks!
<ogra_> cjwatson, hulp ... i need a hint for a quoting issue ...
<ogra_> i'm currently setting board_opts="mpurate=900" ... that ends up on the kernel cmdline of the image
<cjwatson> ok
<ogra_> the found fix is that we need (literally) mpurate=${mpurate} on the final cmdline
<cjwatson> board_opts='mpurate=${mpurate}'
<ogra_> using board_opts='mpurate=${mpurate}'  in the script will get me that (vs expanding ${mpurate}) right ?
<elmo> oh, right, we can't use the paid one
<elmo> even though we pay for it
<ogra_> cjwatson, ah, snap :)
<elmo> the terms won't let us, since we're essentially exposing their DB to the world
<ogra_> thanks a lot, i was unsure
<stgraber> elmo: and I'm guessing they don't update the free one very often ?
<elmo> stgraber: it's at least 6 months lagged
<ogra_> cjwatson, debian-cd updated, feel free to re-roll omap3 at will
<elmo> stgraber: (I think)
<cjwatson> I have a funny feeling we fixed the None case a while back in ubiquity at least, but I can't find it
<cjwatson> Ubuntu desktop, Kubuntu desktop, Xubuntu desktop posted (Wubi fix)
<cjwatson> echo ubuntu headless; ARCHES=armel+omap for-project ubuntu-headless cron.daily-preinstalled; echo ubuntu netbook; ARCHES=armel+omap for-project ubuntu-netbook cron.daily-preinstalled
<cjwatson> running
<stgraber> cjwatson: yeah, ubiquity doesn't select anything for me, so I just have to click somewhere on the map and it works (it doesn't show None anywhere)
<cjwatson> ubuntu headless omap3 posted
<highvoltage> I think I may have found a bad bug, Edubuntu amd64 suddenly needs a lot more disk space to install (ubiquity says I need 14.1 GB free space and it used to be about half that)
<highvoltage> have anyone noticed something similar in other 64bit isos?
<cjwatson> 19:02 <cjwatson> ubuntu headless omap3 posted
<cjwatson> 19:03 <cjwatson> something odd is wrong with netbook
<cjwatson> 19:03 <cjwatson> http://annonaceae.buildd/~buildd/LiveCD/natty/ubuntu-netbook-omap/ doesn't exist
<cjwatson> 19:04 <cjwatson> I guess that was changed recently
<cjwatson> 19:03 <cjwatson> http://annonaceae.buildd/~buildd/LiveCD/natty/ubuntu-netbook-omap/ doesn't exist
<cjwatson> (er, sorry for dup)
<cjwatson> looks like acorn->annonaceae was a recent change, so doing a full netbook build
<cjwatson> can somebody please post that to the tracker (omap3 only) when it's done?  I'm going out for dinner now and may not be back tonight
<cjwatson> highvoltage: it was deliberately increased recently, though I didn't think it was by that much
<cjwatson> (but, as I said, off out)
<slangasek> yes, ubuntu-netbook's omap livefs build was done on sycamore... I hand-hacked find-livefs-build to get it to pull from the right place at the time
<stgraber> cjwatson: I'll do it
<cjwatson> thanks
<cjwatson> slangasek: ah well, too late, it's rebuilding now
<slangasek> ok
<slangasek> 'sonly an hour to build it, not like the bad-old-days of armel builds
<cjwatson> yeah
<cjwatson> off out now
 * slangasek waves
<highvoltage> cjwatson: thanks for the clarification, I guess we can change the edubuntu minimum specs to have a 20GB hard disk then
<highvoltage> (and have fun!)
<stgraber> marked netbook armel+omap3 for rebuild on the tracker, will monitor cdimage to see when the new one appears
<lamont> cjwatson: acorn->annonaceae was a late-last-night-when-acorn-died change
<GrueMaster> cjwatson: Need to respin kubuntu-preinstalled-desktop & mobile for omap3 as well.
<slangasek> GrueMaster: cjwatson is off and I'm not finding the explanation for the respins in scrollback; can you fill me in?
<ogra_> slangasek, changed kernel cmdline options for omap3
<ogra_> mpurate was set to 900 which means all beagles try to set the CPU to 900MHz
<ogra_> the change sets mpurate=${mpurate} and we can export $mpurate from an u-boot update
<ogra_> (u-boot has a table for that value)
<slangasek> ogra_: so this only requires a respin of the image, not the livefs?
<ogra_> from that table the value is set accoprding to the board u-boot detects, instead of having a hardcoded 900 in there
<ogra_> right, just the image
<ogra_> though i think we have removal code in the build scripts, might be hard to find a filesystem
<ogra_> (since our rootfs is huge before compressing)
<slangasek> respins scheduled
<ogra_> merci
<bdmurray> I just noticed there is a hibernate option when running the Live CD
<stgraber> Ubuntu netbook armel omap3 finished building and is now on the tracker
<ogra_> stgraber, thanks !
<bdmurray> slangasek - I just noticed there is a hibernate option when running the Live CD
<bdmurray> hello?
<pitti> skaet, cjwatson: should we move kubuntu-meta to -updates now, so that we can build the kubuntu DVD with it?
<pitti> sorry, I had a server downtime and lost this evening's scrollback
<bdmurray> pitti: apport seems to be enabled on the live cds afaict
<pitti> bdmurray: right, casper does that
<pitti> so that we can get install failures for ubiquity etc.
<bdmurray> ah, okay that does sound familiar
<bdmurray> I noticed hibernation appears in the live cd power menu too is that deliberate?
<pitti> that sounds like a bug -- the live system doesn't have any swap it could hibernate to
<pitti> unless it uses the ones on the installed system
<pitti> but that would be a bug, too
<bdmurray> the live cd I was using did use my installed system's swap
<bdmurray> er did mount
<pitti> "use" is correct, swap isn't mounted :)
<bdmurray> it looks the gconf key in 32disable_hibernation is wrong
<pitti> but anyway; it's probably debatable that it's doing that
<pitti> bdmurray: hibernation is supposed to be enabled in the installed system
<pitti> there's an example config file how to disable it
<pitti> we had it disabled by default for a while, but there was too much pushback from both users and OEM team
<pitti> this needs some more thought, there's an UDS topic about it
<bdmurray> right I'm saying it showed up when running the Live CD
<pitti> right
<pitti> ah, the casper script is wrong, yes
<bdmurray> looks like it was reported as bug 610351
<ubot4> Launchpad bug 610351 in casper (Ubuntu) "scripts/casper-bottom/32disable_hibernation sets /apps/gnome-power-manager/general/can_hibernate (affects: 1) (heat: 12)" [Undecided,New] https://launchpad.net/bugs/610351
<pitti> too late for natty now, as we can't SRU it, but I'll get it fixed for oneiric
<bdmurray> what would happen if people tried to hibernate? wouldn't data be written to their swap partition?
<pitti> right
<pitti> it probably won't come back, though
<bdmurray> yes but whatever they had on their swap partition (a different hibernation?) would be lost
<pitti> in principle it could work, but I don't think this has ever been tested
<pitti> no, swap partitions with a hibernate image have a different signature and won't be automounted
<jibel> ev, I've just got the 'Out of memory' error, process killed was swapoff, seems rather critical
<pitti> at least that part should work
<bdmurray> okay sounds reasonable
<slangasek> bdmurray: hibernate> hmm.  Does it work?
<slangasek> ah, I gather "no"
<pitti> the hibernation would certainly work; but I'm less sure whether the iniramfs for the live system has teh necessary resuming bits, and whether all the aufs, squashfs etc. stuff would survive that
<bdmurray> well hibernating seems to but resuming is hard
<jibel> ScottK, we are fixing bug 769356, the link for kubuntu release notes is https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview or there's another specific to kubuntu ?
<ubot4> Launchpad bug 769356 in ubiquity (Ubuntu Natty) (and 2 other projects) "Kubuntu installer release notes link points http://www.kubuntu.org/news to (affects: 1) (heat: 8)" [High,Triaged] https://launchpad.net/bugs/769356
<jibel> ev, skaet bug 771517 a consequence of the fix of 770256 ?
<ubot4> Launchpad bug 771517 in wubi "Natty Wubi install via ubiquity fails saying no such file or directory found (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/771517
<skaet> jibel,  did this just showed up with the latest builds from this afternoon or was it around before?  can't tell from the bug.
<jibel> skaet, brand new bug
<skaet> Riddell, ScottL, stgraber, highvoltage, superm1,   can you please review your products on https://wiki.ubuntu.com/NattyNarwhal/ReleaseManifest,  and confirm what is being produced, and where its being broadcast and announced,  matches your expectations.  If so,  please add your signoff to "Sign-off Date" column.
<skaet> jibel,  brand new bug on this afternoon's build?   or brand new bug on earlier image?
<jibel> skaet, with the latest build
<jibel> I'll try to reproduce tomorrow morning.
<skaet> thanks jibel,  we prob need ev to get this sorted if confirmed,   sleep well
<jibel> skaet, thanks, you too, see you tomorrow.
<highvoltage> skaet: done
<skaet> highvoltage, thanks!
#ubuntu-release 2011-04-27
<rickspencer3> skaet, should bug https://bugs.launchpad.net/wubi/+bug/771517 be assigned to ev or so, to ensure it is looked at soon?
<ubot4> Launchpad bug 771517 in wubi "Natty Wubi install via ubiquity fails saying no such file or directory found (affects: 1) (heat: 6)" [Undecided,Confirmed]
<rickspencer3> I have no Windows, so I can't repro it or anything
<skaet> rickspencer3, its note and will get top priority in the morning.   ev's in the release room with us.
<rickspencer3> hi ev!
<rickspencer3> :)
<rickspencer3> thanks skaet
<ScottL> aye skaet will do that now
<skaet> Riddell, ScottL, stgraber, highvoltage, superm1,   can you please review your products on https://wiki.ubuntu.com/NattyNarwhal/ReleaseNotes?
<skaet> thanks ScottL :)
<skaet> ReleaseNotes are still very much work in progress,  and polishing will be going on tomorrow as well,  so feel free to make sure the key points you want to highlight are covered in the Release Notes.
<skaet> If not,  please add them.
 * skaet calling it a night..
<GrueMaster> Night skaet.
<highvoltage> goodnight skaet
<ScottK> jibel_: Did you get the link you needed?
<ScottK> pitti: I'd appreciate it if you would waive the aging period for Bug #771281 as it's a trivial fix, it's already been verified, and since (particularly) it was used to build the final Kubuntu DVD, it'd be nice to get it into -updates for the release.
<ubot4> Launchpad bug 771281 in kubuntu-meta (Ubuntu Natty) (and 1 other project) "kubuntu-full not installable in Natty (affects: 1) (heat: 10)" [Medium,Fix committed] https://launchpad.net/bugs/771281
<superm1> skaet, release notes are good
<stgraber> skaet: I'll update the Edubuntu ReleaseNotes tomorrow morning EDT so in ~10 hours
<micahg> hi, are package removals from unseeded still ok?
<pitti> Good morning
<pitti> ScottK: right, in fact I already proposed that last night, as I assumed we want that in -updates for building the Kubuntu DVD
<pitti> ScottK: (done)
<jibel> pitti, hi a user is reporting problems again with access to /dev/fd0 during installation making the whole process really slow. bug 769704
<ubot4> Launchpad bug 769704 in casper (Ubuntu Oneiric) (and 3 other projects) "Install doesn't proceed because of I/O error for floppy disk drive (affects: 1) (heat: 8)" [Medium,Triaged] https://launchpad.net/bugs/769704
<pitti> ugh, these never die completely
 * pitti looks
<pitti> jibel: hang on, studio? doesn't that use d-i, not the live system?
<pitti> so this isn't a casper bug, something new in d-i does that
<jibel> pitti, oh right, my mistake.
<pitti> I made some additional comments/questions
<jibel> thanks
<cjwatson> pitti: kubuntu-meta> yes, I think so
<cjwatson> ScottK: not sure we've actually redone the Kubuntu DVD yet, mind
<cjwatson> jibel: FWIW "really slow" is not something we will fix at this point - if it works, it'll do
<jibel> cjwatson, a user was reporting something like 40mn to boot. The workaround is easy, so adding it to the release notes is good enough.
<pitti> casper took some 40 minutes to complete
<pitti> and disabling in BIOS works, too
<cjwatson> jibel: this bug is not about boot
<cjwatson> I don't think it's a recent change FWIW
<cjwatson> pitti: watch out for my note on bug 687501, BTW
<ubot4> Launchpad bug 687501 in grub2 (Ubuntu Maverick) (and 3 other projects) "when installer is multipath aware, grub fails to install (affects: 2) (dups: 1) (heat: 38)" [High,Fix committed] https://launchpad.net/bugs/687501
<cjwatson> (comment 25)
<pitti> cjwatson: ah, thanks; do you mind if I mark this as verification-failed in addition, to avoid accidentally copying it?
<cjwatson> pitti: not at all, as long as the reason for it is clear so that we know we can revert it later
<pitti> sure
<ev> right, signed wubi r210 is in the right place, but we're going to check that Windows is happy with the signed binary in a little bit
<jibel> ev, I'm trying to reproduce bug 771517 and bug 770256, what are the conditions to have ubiquity propose 'install ubuntu inside windows'. There are 4 primary partitions, do they all need to be of type ntfs ?
<ubot4> Launchpad bug 771517 in wubi "Natty Wubi install via ubiquity fails saying no such file or directory found (affects: 1) (heat: 6)" [Undecided,Confirmed] https://launchpad.net/bugs/771517
<ubot4> Launchpad bug 770256 in ubiquity (Ubuntu) (and 2 other projects) "Reboots after Wubi install via ubiquity repeatedly ask to uninstall (affects: 1) (heat: 6)" [High,Invalid] https://launchpad.net/bugs/770256
<ev> jibel: only one needs to be ntfs
<cjwatson> and Windows needs to be found by os-prober, and /cdrom/wubi.exe needs to exist
<cjwatson> oh, and we need to be able to find the Windows startup folder
<jibel> my setup is sda1 'dell utility' sda2 to 4 primary ntfs on windows7 /cdrom/wubi.exe exists
<cjwatson> we try 'ProgramData/Microsoft/Windows/Start Menu/Programs/Startup', 'Documents and Settings/All Users/Start Menu/Programs/Startup', 'Winnt/Profiles/All Users/Start Menu/Programs/Startup'
<jibel> how do I verify if windows is found by os-prober ?
<ev> jibel: `sudo os-prober`
<cjwatson> rebuilding desktops for that Wubi fix
<jibel> it returns '/dev/sda2:Windows 7 (loader):Windows:chain' is it ok ?
<ev> yes
<cjwatson> (Ubuntu, Kubuntu, Xubuntu)
<cjwatson> only change will be wubi.exe, you can carry over other previous tests IMO
<cjwatson> jibel: ^- IIRC you can do that with db hackery?
<jibel> cjwatson, yes
<cjwatson> once we've built I can confirm that other things are identical
<jibel> all the directories are there excepted 'Winnt/Profiles/All Users/Start Menu/Programs/Startup', does the windows partition needs to be mounted somewhere ?
<cjwatson> it only needs one of those directories
<cjwatson> it doesn't need to be mounted
<cjwatson> Ubuntu desktop posted - I've confirmed that the only diffs are dists/natty/Release.gpg (just regenerated, Release stayed the same), .disk/info (timestamp), and wubi.exe
<jibel> I definitely don't have this option and the only item in the partitioner are 'replace window7' and 'something else' :/
<cjwatson> Kubuntu desktop posted - likewise confirmed
<cjwatson> are you sure you have four *primary* partitions?
<jibel> that's what diskpart and parted tell me.
<cjwatson> pitti: I've uploaded grub2 Wubi fixes to lucid-proposed and maverick-proposed, if you'd be so good
<pitti> cjwatson: is it urgent as in "now", or is 2 h okay? (having an 1-on-1 now, and then need to run for some errands)
<cjwatson> 2h is fine
<pitti> but I'll try to do it ASAP
<pitti> cjwatson: done
<cjwatson> excellent, thanks
 * pitti -> off for some 1.5 h
<cjwatson> Xubuntu desktop posted (Wubi again)
<skaet> Riddell, ScottK - is rbelem around?   Kubuntu mobile testing sitting as a gap right now.
<Riddell> skaet: he's brazil, he'll wake up shortly
<skaet> Riddell,  thanks.
<Riddell> are new DVDs due today following the new desktop images?
<cjwatson> yes
<cjwatson> I should get round to those shouldn't I
<cjwatson> so, let's see
<cjwatson> Ubuntu DVDs don't need a livefs respin
<cjwatson> but Kubuntu DVDs do, due to the kubuntu-full uninstallability
<cjwatson> correct?
<cjwatson> and Edubuntu can be left alone
<cjwatson> kubuntu-full has already been moved to -updates, so won't require any special CD-build-time work
<skaet> jibel, ^^ most test results should hold.
<cjwatson> (though actually that's only because it's in the livefs, but anyway)
<Riddell> sounds right
<cjwatson> echo ubuntu dvd; for-project ubuntu cron.dvd; echo kubuntu dvd; buildlive kubuntu-dvd dvd && for-project kubuntu cron.dvd
<cjwatson> running
<jibel> cjwatson, ev, I've found the problem with 'wubi option not showing' that's because os-prober returns the wrong partition. Well, not really wrong but not the right one.
<jibel> it returns sda2 which is a recovery partition but the OS is installed on sda3
<jibel> note that it is the default partition scheme from the manufacturer
<cjwatson> there are a few bugs about that, it turns out to be quite hard to distinguish them reliably in all cases
<cjwatson> it works for some people but not others IME
<jibel> if I force the device to be /dev/sda3 in os_prober() then the menu to install Wubi is there and I can proceed with the Wubi setup. I'll file a bug.
<cjwatson> there's already at least one such bug on os-prober
<jibel> ok, I'll search for duplicate first :-)
 * ScottK wonders about is wubi really worth the trouble.
<cjwatson> hm, maybe not
<cjwatson> jibel: sure, go ahead and file a new one
<ev> ScottK: it's an non-destructive option in the face of none when four partitions are present. That strikes me as worth the trouble.
<ScottK> ev: I was thinking more globally.  It seems like every cycle it sucks up a lot of time from critical people.  I don't know how much having the option helps people with transition, so I don't have a strong opinion on it's value relative to it's cost, but the cost is not insignificant.
<ev> I don't have real figures, but I would wager quite a bit.
<ev> At some point I hope we'll do some user testing and I can give you a much better response.
<cjwatson> it's certainly not staffed appropriately
<cjwatson> Ubuntu DVD posted; the changes are partman-auto bug 770041 and the Wubi bugs
<ubot4> Launchpad bug 770041 in partman-auto (Ubuntu Natty) (and 1 other project) "partitioner hangs if libparted sees partitions for which device nodes don't exist (affects: 1) (heat: 8)" [High,Fix released] https://launchpad.net/bugs/770041
<jibel> skaet, I keep all the results from the previous build for {Ku|Xu|U}buntu Desktop excepted Wubi which has changed, that's it ?
<cjwatson> yes, I posted the exact list of changes above
<jibel> thanks, doing the update.
<skaet> jibel,  can you copy the results onto the iso tracker for those past ones?  or do you keep them on the side?
<jibel> skaet, I update the past results with the id of the new build in order to show them on the tracker, excepted wubi, that I'll keep back because it needs to be tested again.
<skaet> jibel,  sounds perfect.  thanks!
<jibel> ev, I think I never see migration-assistant for the same reason than wubi menu not showing in Ubiquity ?
<ev> jibel: they both rely on os-prober, yes
<stgraber> good morning
<jibel> hm, that's a problem then, because I have this issue on 3 different system from different manufacturers.
<jibel> with an untouched factory partitioning scheme.
<cjwatson> it will have to be release-noted - I'm not confident making a quick change for that, not in the slightest
<jibel> skaet, update done.
<skaet> thanks jibel
<jibel> Riddell, any news from Tm_T, there's no results for kubuntu on powerpc
<stgraber> skaet: working on the Edubuntu release notes now
<skaet> stgraber, ok respect the locking,  andy and colin are working on them too right now.
<skaet> thanks.
<Riddell> jibel: he tests in European evenings so he won't have had a chance with today's image yet
<jibel> Riddell, ok.
<cjwatson> oh yeah, I should post the Kubuntu DVD shouldn't I!
<cjwatson> changes are fixed partman-auto, new tzdata, installable kubuntu-full, new Wubi (if that matters)
<cjwatson> err
<cjwatson> damn, kubuntu-full is still uninstallable, I need to respin that with a couple of cdimage changes
<rickspencer3> good morning all
<rickspencer3> pitti, seb128 what's the word on the street?
<rickspencer3> oops, wrong channel!
<skaet> lol
<cjwatson> ok, kubuntu-full properly fixed on Kubuntu DVDs now; posted
<stgraber> skaet, highvoltage: https://wiki.ubuntu.com/NattyNarwhal/ReleaseNote is now up to date for Edubuntu.
<highvoltage> stgraber: looks great
<skaet> highvoltage, stgraber - Thanks!  :)
<highvoltage> only a pleasure!
<hyperair> is there time to upload a small change that adds an Enhances: line to a package in universe?
<cjwatson> hyperair: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2011-April/000844.html - final freeze is past
<cjwatson> so I think not, -> oneiric
<hyperair> alright
<pitti> hyperair: an SRU for this would do fine, as per definition it is only for the case where the package is not yet installed (i. e. you need to download it anyway)
<GrueMaster> skaet: I will test the kubuntu-mobile armel images in a little bit.  Just getting my first cup of coffee now.
<hyperair> alright.
<pitti> hyperair: I updated the bug accordingly
<hyperair> pitti: oh okay, thanks
<hyperair> pitti: do i still need an ubuntu-sru ack, or is your post considered an ack?
<hyperair> oh wait, i forgot, these days we upload directly to -updates and let it wait, right?
<cjwatson> no, -proposed
<cjwatson> but otherwise yes
<pitti> hyperair: right
<hyperair> cjwatson: right, thanks for correcting me before a potential screwup. =p
 * hyperair hasn't done a sru in a while
<skaet> thanks GrueMaster.
<GrueMaster> Why do the mobile armel images keep changing? While I haven't tested since Beta 2, dailies have been complete preinstalled images until 20110425, when they reverted back to rootfs only.
<GrueMaster> See http://paste.ubuntu.com/599850/ to know what I am referring to.
<GrueMaster> The images with the x86 boot sector are ready to run.
<ogra_> GRRR !!!
<patrickmw> cjwatson: Hello.  When a user starts an install and selects Simplified Chinese as their language, will that language pack get fully installed so the user can run Natty with full simplified Chinese support at login?  Or do they still have to install the Simplified Chinese lang pack through Language Support?
<ogra_> who didnt respect the wiki lock when i edited ( i didnt get any warning at all and now there is a mess)
<ogra_> skaet, i added the proper arm sections to the release notes and known issues ... someone edited though while i held the lock, i dont know where the conflicting bits should go now
<pitti> patrickmw: the simplified chinese langpack is on the images, but not the spell checkers, etc.; these will get installed from the network if you are online, or you will get a notification for them post-install if you are offline
<patrickmw> pitti, should that notification be instant, or can it take a while?
 * ogra_ tries to fix, hoping he wont mess up other peoples stuff now
<pitti> patrickmw: some minutes perhaps
<skaet> ogra_,  make your best guess, and I'll do the best to resolve after everyone's out.
<ogra_> skaet, "after everyone is out" ?
<ogra_> who is in ?? :)
<ogra_> i dont get a warning at all, the wiki tells me that others will though
<skaet> ogra, people are adding bugs from each of the teams.   Seems to be changing by the minute.
<skaet> Not sure why not respecting lock.
<ogra_> right, but it seems the locking mechanism doesnt cope
 * skaet nods
<GrueMaster> Wouldn't it be easier for everyone to edit in their own sandbox and feed one person the links to pull in?
<skaet> GrueMaster, that's a good suggestion.   Can you send a note about it to ubuntu-release mail list so we can discuss mechanisms for it at UDS as one of the areas on feedback for improving the release management. ?
<GrueMaster> I'm not on the mailing list.
<ogra_> well, having a working wiki used to work in the past
<skaet> GrueMaster, you can mail to it,  and I'll approve it in,  or subscribe - as you wish.   Its an open list.
<ogra_> without lock it doesnt indeed and getting a 500 error for every edit doesnt help either
<ogra_> so seems i have solved all conflicts now
<ogra_> hmm, we should all just use ubuntu studio !!!
<ogra_> Ubuntu Studio
<ogra_> No issues to report.
<ogra_> :)
<cjwatson> patrickmw: I think it should get fully installed
<patrickmw> cjwatson, ok. thank you
<cjwatson> wiki> it's not that big an issue, worst case we can resolve conflicts later.  I think adding sandboxes that we would have to merge by hand would be a cure worse than the disease.
<cjwatson> patrickmw: modulo pitti's comments, which are correct
<GrueMaster> Then maybe editing the release notes in a gobbie doc or some shared document system.
<cjwatson> the wiki works fine for me, to be perfectly honest
<cjwatson> I really don't care about the odd conflict, as long as they're all resolved for release
<ogra_> well, its extra work vs a working lock system
<ogra_> though i simply count on the fact that we have a working wiki next release :)
<ogra_> it worked in the past too
<cjwatson> anything outside the wiki page is worse than editing in the wiki page, because the wiki page exists from the previous milestone and needs to be evolved
<cjwatson> editing somewhere else guarantees the need to resolve conflicts
<ogra_> indeed
<bdmurray> Is the following link in the technical overview correct? http://www.ubuntu.com/testing/download
<bdmurray> Actually is the https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview the thing to be reviewing?
<charlie-tca> bdmurray: moved to https://wiki.ubuntu.com/NattyNarwhal/ReleaseNotes
<bdmurray> charlie-tca: thanks
<cjwatson> FYI, we're going to try an Ubuntu desktop respin for another attempt at fixing bug 771517, but rather than posting it to the ISO tracker, we'll post it to that bug and see if it actually fixes it.  If not, we'll just stick with the tested images we have
<ubot4> Launchpad bug 771517 in wubi "Natty Wubi install via ubiquity fails saying no such file or directory found (affects: 1) (heat: 8)" [Undecided,Confirmed] https://launchpad.net/bugs/771517
<cjwatson> (and I'm not desperate to ensure that absolutely every single image is up to date with that fix, if we do manage to fix it for real)
<cjwatson> prepublication is done, BTW
<skaet> thanks cjwatson.  :)
<GrueMaster> skaet: On kubuntu-mobile for armel (omap3 & omap4), there is no way to boot them as they sit.  The images are not complete (see my earlier pastebin).  Also, even after grafting them into a working image, they still have a lot of issues keeping them from running properly.
<cjwatson> which earlier pastebin?
<cjwatson> http://paste.ubuntu.com/599850/ ?
<skaet> GrueMaster,  ok,  they won't be going out.
<cjwatson> we haven't had code changes that account for that varying file(1) output
<cjwatson> therefore, I assume that the code must be unreliable in some way
<ogra_> no, they probably failed to build ... but not in a way the builder has catched it
<GrueMaster> cjwatson: I don't know what the problem is either, but the current images are not complete.
<cjwatson> has anyone diffed build logs?
<GrueMaster> And it appears to only happen around release week (same for beta 1 & beta 2).
<cjwatson> -W: Unable to read /srv/cdimage.ubuntu.com/scratch/kubuntu-mobile/daily-preinstalled/apt/natty-armel+omap/apt/preferences.d/ - FileExists (2: No such file or directory)
<cjwatson> +W: Failed to fetch file:/srv/cdimage.ubuntu.com/ftp-universe-ports/dists/natty/main/binary-armel/Packages.bz2  Hash Sum mismatch
<cjwatson> that suggests that a rebuild with a quiescent cdimage build machine should fix it
<cjwatson> there's no reason not to give it a try, at least
<GrueMaster> I can test if they get fixed.
<GrueMaster> But there are other issues once this is resolved that prevent the images from working.
<ogra_> what kind of issues ?
<ogra_> anything that can be worked around without uploads ?
<GrueMaster> Once oem-config finishes, X is supposed to restart, but there is no gui.
<ogra_> hmm, doesnt sound like something to easily work around
<GrueMaster> I'm asking on kubuntu-devel, but I have only been able to get it working by moving plasma-mobile.desktop to /usr/share/autostart.
<ogra_> sounds like kdm
<GrueMaster> kubuntu-mobile uses nodm.
<ogra_> ah
<ogra_> wasnt that a bug before already ?
<GrueMaster> Beta 2.
<GrueMaster> I filed it.
 * ogra_ thought there was a discussion about that issue 
<ogra_> yeah
<GrueMaster> On their wiki (mainly geared for the N900), they have several *tweeks* they recommend before booting.
<GrueMaster> Like reomving all of nepomuk from /usr/share/autostart (it crashes on armel currently).
<ogra_> hrm, why didnt these make it into the image ?
 * GrueMaster only tests what I am given.
<ogra_> indeed, but for such cases we could have added hacks to jasper
<GrueMaster> I'm going to pull the x86 iso and see if it is similar.
<ogra_> (and do it more properly than rm'ing files)
<GrueMaster> The lead for kubuntu-mobile didn't even know about jasper until yesterday.
<ogra_> hrm
<GrueMaster> The two biggest issues I see here are lack of platforms and lack of communication with our team.
<ogra_> yes
 * skaet --> dinner,  back on later
<cjwatson> WTF, why is anonftpsync for universe rewriting every file in the universe pool?
<cjwatson> insane badgers
<cjwatson> oh, not all, just lots.  that doesn't make very much more sense
<cjwatson> all allegedly files that didn't exist
<cjwatson> deeply weird
<cjwatson> oh, it must be files that are symlinks to other components
<cjwatson> i.e. stuff that's been moved around
<cjwatson> so probably sort of required for correctness, but not doing speed any favours though :-/
<cjwatson> and I suspect that being so damn slow means that it spans multiple publisher cycles
<cjwatson> I'll work on reliability of that next cycle, I guess
<cjwatson> (dinner)
<smoser> skaet_, i've added a release note that i would like in the release notes to https://bugs.launchpad.net/ubuntu-release-notes/+bug/768625
<ubot4> Launchpad bug 768625 in sudo (Ubuntu Oneiric) (and 2 other projects) "user prompted for sudo changes on upgrade in ec2/uec image (affects: 1) (heat: 10)" [Medium,Confirmed]
<superm1> pitti, would you mind waiving the 7 day time for the SRU on bug 771560?  It's quite specific to a process that is only used by us, and i've already confirmed it fixed the problem.  had i found it a day earlier i would have had it uploaded for the primary archive
<ubot4> Launchpad bug 771560 in dell-recovery (Ubuntu Natty) (and 1 other project) "GRUB menu pops up needlessly during factory install process (affects: 1) (heat: 10)" [Undecided,Fix committed] https://launchpad.net/bugs/771560
<dobey> hi guys; there's new ubuntuone-storage-protocol and ubuntuone-client in the natty-proposed queue, that we'd like to have as 0day SRUs. can we expedite them please?
<Riddell> SpamapS: bug 770379 says you accepted dobey's ubuntuone-client upload into natty-proposed but it's still in the unaccepted queue
<ubot4> Launchpad bug 770379 in ubuntuone-client (Ubuntu Natty) (and 1 other project) "Recommends wrong version of gir1.2-unity-3.0 (affects: 1) (heat: 10)" [High,Fix committed] https://launchpad.net/bugs/770379
<SpamapS> Riddell: I think it was marked as verification-failed
<SpamapS> Riddell: I seem to recall seb testing the upgrade and noting that the upgrade still does not pull in the recommended gir package.
<SpamapS> Riddell: which means either a) it needs to be added to update-manager's magic, or b) it needs to be a Depends:
<Riddell> ah so this is a second upload to fix that
<Riddell> I'll leave it to you or another SRU member then
<SpamapS> Yeah there's been a lot for the 0-day queue.. I'm working on one that I need to upload at the moment actually. ;)
<cjwatson> GrueMaster: I think the current kubuntu-mobile images should be better - no hash sum mismatch errors in the build logs
<cjwatson> I guess I might as well post that?  the current images have no successful tests registered anyway
<GrueMaster> Did they get rebuilt since yesterday?
<cjwatson> yes
<cjwatson> I did
<cjwatson> and file(1) is now saying "x86 boot sector" rather than "data" for me
<GrueMaster> Ok.  I'll give them a quick spin as soon as I get my desktop working again.
<cjwatson> cdimage@antimony:~/cdimage/www/full/kubuntu-mobile$ zcat daily-preinstalled/20110427/natty-preinstalled-mobile-armel+omap.img.gz | file -
<cjwatson> /dev/stdin: x86 boot sector; partition 1: ID=0xc, active, starthead 1, startsector 63, 144522 sectors; partition 2: ID=0x83, starthead 0, startsector 144585, 4707045 sectors, code offset 0x0
<cjwatson> cdimage@antimony:~/cdimage/www/full/kubuntu-mobile$ zcat daily-preinstalled/20110426.1/natty-preinstalled-mobile-armel+omap.img.gz | file -
<cjwatson> /dev/stdin: Linux rev 1.0 ext3 filesystem data, UUID=cd04ea0a-2c1d-428e-88fd-f01a29ea82fb (large files)
<cjwatson> er, sorry, that's backwards
<GrueMaster> Cool
<cjwatson> cdimage@antimony:~/cdimage/www/full/kubuntu-mobile$ zcat daily-preinstalled/20110426.1/natty-preinstalled-mobile-armel+omap.img.gz | file -
<cjwatson> /dev/stdin: Linux rev 1.0 ext3 filesystem data, UUID=cd04ea0a-2c1d-428e-88fd-f01a29ea82fb (large files)
<cjwatson> cdimage@antimony:~/cdimage/www/full/kubuntu-mobile$ zcat daily-preinstalled/20110427/natty-preinstalled-mobile-armel+omap.img.gz | file -
<cjwatson> /dev/stdin: x86 boot sector; partition 1: ID=0xc, active, starthead 1, startsector 63, 144522 sectors; partition 2: ID=0x83, starthead 0, startsector 144585, 4707045 sectors, code offset 0x0
<cjwatson> and similarly for omap4
<GrueMaster> Did you figureout theproblem?
<cjwatson> I commented on it in scrollback above
<cjwatson> 18:45 <cjwatson> and I suspect that being so damn slow means that it spans multiple publisher cycles
<cjwatson> 18:48 <cjwatson> I'll work on reliability of that next cycle, I guess
<cjwatson> mirroring to antimony spans multiple publisher cycles, thus the archive mirror on cdimage is inconsistent, thus world blows up
<GrueMaster> Ah
<cjwatson> not a new problem, but I didn't realise it was so serious
<cjwatson> posted, anyway
<cjwatson> and posted Ubuntu desktop with updated wubi, as agreed with jibel
<cjwatson> prepublished updated Ubuntu desktop images
<skaet> heya,  anyone know if rbelem is around?
<Riddell> skaet: yes, he's testing now
<yofel> skaet: he's in #kubuntu-devel right now
<skaet> Riddel, yofel - thanks.
#ubuntu-release 2011-04-28
<jibel> cjwatson, I verified successfully the fix for Wubi, and smoke tested desktop images successfully as well. I notified IS, going to bed now.
<GrueMaster> Probably too late, but I have the omap4 image of kubuntu-mobile running now.  Still needs some polish, but the image is now a complete SD image.  After oem-config runs, a system reboot is required for the plasma-mobile environment to start.
<ScottK> GrueMaster: Thanks for testing.  Sounds acceptable to me for a tech preview image.
<GrueMaster> I haven't tested the omap3 image, but it should have the same results.
<GrueMaster> I'm closing up for the day.  Need dinner and my brain is drained from testing & wiki-wacking.
<rbnswartz> if anyone from the release team up? if so could they give me an estimate on release time?
<ckw> rbnswartz, asking is futile
<ckw> They will release it when they release it
<rbnswartz> ckw I can hope can't I? :)
<rbnswartz> I have a free block of bandwidth now and was looking to see how soon release is.
<jbicha> lol
<ckw> I'm also waiting for the torrents *I want to break 1.5 TB upload this year, got to 1.1 last year) and I'm waiting too
<ckw> s/*/(/
<jbicha> I think it will still be a few hours, I don't think UK's even at work yet
<rbnswartz> debian did a twitter feed of all the happenings when they released squeeze. Ubuntu should do the same
<maco> Natty will be released at some point while it is 28 April in at least one timezone on the planet Terra in the system Sol
<rbnswartz> all I want to know is if it will be in the the next couple hours.
<wgrant> Perhaps we need a bot that says "It will be out when it's out." every five seconds.
<rbnswartz> I got up at 2AM hoping that it will be soon. If it won't be within the next couple horse my bandwidth window will close.
<maco> depends when ISO testing & confirmation is finished
<wgrant> Precisely.
 * maco does not have a crystal ball
<wgrant> Precisely.[B
<wgrant> Grar.
 * wgrant kicks screen.
<rbnswartz> wgrant this is random but how do add those comments?
<wgrant> rbnswartz: Which comments?
 * wgrant wonders what you're talking about.
<rbnswartz> that
 * wgrant still isn't sure.
<rbnswartz> the little text notes such as "wgrant still isn't sure"
<nigelb> maco: I'm stealing that statement :)
<maco> nigelb: you dont even get the reference because you dont even watch the show!
<nigelb> maco: BBT?
<maco> no
<nigelb> Dr. Who?
<maco> yes
<nigelb> :)
<nigelb> It has to be one of 'em :)
<wgrant> rbnswartz: You ruin all the fun: "/me still isn't sure."
<maco> nigelb: i need to watch some new shows to trip you up, huh?
<nigelb> we should probably not spam this channel
<nigelb> maco: haha ;)
 * rbnswartz enlightened
 * rbnswartz is enlightened
<pitti> Good morning
<pitti> superm1: I don't mind shortening the maturing period for #771560; just say there that you tested it? (since nobody else really can)
<pitti> superm1: ah, you did
<cjwatson> rbnswartz: it won't quite be in the next couple of hours from when you asked
<rbnswartz> cjwatson thanks.
<ogra_> cjwatson, headless will end up at http://cdimage.ubuntu.com/ubuntu-headless/releases/11.04/ , right (there is no download link in the release notes yet)
<ogra_> ?
<cjwatson> ogra_: lose the "ubuntu-headless" path element
<ogra_> k
<ogra_> same for netbook ?
<cjwatson> yeah - as I indicated the other day
<ogra_> right, just wanted to be sure before i edit :)
<cjwatson> 12:36 <cjwatson> I think if I do that they may also end up in http://cdimage.ubuntu.com/releases/natty/release/ rather than http://cdimage.ubuntu.com/ubuntu-{headless,netbook}/releases/natty/release/
<cjwatson> (though yeah, 11.04 rather than natty in official docs)
<cjwatson> Riddell,ScottK: will anyone be able to sign off on https://wiki.ubuntu.com/NattyNarwhal/ReleaseManifest for kubuntu-mobile?  I gather from scrollback that omap3 is still untested but that omap4 is believed OK with caveats
<ogra_> right, changed (if the wiki ever saves)
<cjwatson> Riddell,ScottK: Kate wants manifest signoff before we publish images
<Riddell> hmm, investigating -mobile
<Riddell> skaet, cjwatson: good to go on kubuntu-mobile
<Riddell> I've signed it off
<skaet> arm as well as i386?
<skaet> Riddell,  thanks for chasing it down.
<Riddell> yes arm too
<cjwatson> ok, thanks
<jibel> Riddell, kubuntu on powerpc is not affected by 756719 ?
<jibel> bug 756719
<ubot4> Launchpad bug 756719 in ubiquity (Ubuntu Natty) (and 3 other projects) "PowerPC Natty Beta LiveCD Hangs Bad Mirror (affects: 2) (dups: 1) (heat: 14)" [Undecided,Invalid] https://launchpad.net/bugs/756719
<Riddell> jibel: hmm, I thought they had been tested but I don't see anything on iso tracker
<cjwatson> that does seem like it should affect both similarly, unless I'm missing something in the ubiquity KDE frontend
<jibel> it affects alternate as well but you can workaround by setting the mirror manually
<cjwatson> indeed
<Riddell> only report I have is..
<Riddell> 20:25 < Tm_T> Riddell: live boots, apps gets launched 20:26 < Tm_T> ...and because of apparently broken hardware (I/O errors from cdrom device) at some point I got plasma-desktop being rather unresponsive
<Riddell> so I guess he didn't get as far as installing it
<cjwatson> I'll withdraw it from the publication I'm doing until we get signoff
<Riddell> yep
<Fight2Win> is it out yet?
<dingan> is it out yet ?
<Riddell> dingan: #ubuntu-release-party
<Riddell> what's the difference between https://wiki.kubuntu.org/NattyNarwhal/TechnicalOverview and https://wiki.kubuntu.org/NattyNarwhal/ReleaseNotes ?
<Riddell> and which should I link to from kubuntu.org for a "here's what's in Ubuntu in general"?
<skaet> Riddell,  ReleaseNotes please
<skaet> its where the public links will go.
<skaet> TechnicalOverview is for pre-release
<skaet> ReleaseNotes is for release
<skaet> ie. TO for natty,   RN for 11.04
<skaet> :)
<mdz> So, welcome :-)
<Riddell> mdz: if you ask "is it out yet?" we'll just send you to #ubuntu-release-party :)
<So> mdz, merci! ; )
<mdz> Riddell, I can just watch over cjwatson's shoulder instead ;-)
<cjwatson> should've done that half an hour ago ;-)
<stgraber> good morning
<mvo> hey stgraber
<paranox> so i heard you guys had a secret milestone build of 11.10
<cjwatson> paranox: we do not
<cjwatson> the oneiric series hasn't been created yet; we'll start bootstrapping it later today
<paranox> this IS #windows8-release, right?
<paranox> "we'll" start bootstrapping it?
<ckw> paranox, See #windows8-release-party
<paranox> does that mean you are somehow associated with canonical?
<ckw> Nope, not at all
<ckw> I'll be good now, please don't kick
<cjwatson> you weren't trolling
<cjwatson> (possibly a ban was a bit excessive)
<Riddell> skaet: will you ping me when release happens?
<mvo> me too please
<ckw> I think it's now. They just muted #ubuntu-release-party
<cjwatson> ckw: don't do the "I think it's now" thing here, please.
<nickmoeck> I think that was to stop the flood of people saying "I"
<cjwatson> this is a business channel.
<ckw> Ah. I misinterpretted the purpose of the mute then. Apologies.
<ckw> I was setup with "the channel will be mutted and people will say "It's released" when it's ready", so I made a logical jump
<stgraber> hey mvo! has been a while ;)
<mvo> stgraber: yeah, easter++
<ogra_> ++ ??
<ogra_> extra eggs ?
<ogra_> :)
<skaet> Riddell will do
<ogra_> take your time, #ubuntu-release-party doesnt even have 500 ppl yet :)
<nigelb> ogra_: heh, yeah, lets wait for 1000 :)
<ogra_> i think we never had 1000 yet
<ogra_> iirc lucid was close though
<nigelb> If @ubuntudev were to tweet "we will release when we have 1000 people in release party, we will replease", we'll get there in 5 secs
<nigelb> Anyway, I should let you folks work :)
<ogra> skaet, TI asked for a minor change in the release notes/announcement
<skaet> ogra,  just made it.
<skaet> to the announce
<skaet> please change the release notes directly
<ogra> will do
<ogra> hmm, the "panda" and "beagle" reference isnt in the release notes wikipage
<ogra> skaet,
<ogra> Developer reference images are provided for select Texas Instruments (TI) ARM
<ogra> platforms, specifically the "PandaBoard" and "BeagleBoard" developer systems.
<ogra> thats what i changed on the release announcement wiki
<ogra> same change done in the ReleaseNotes
<Riddell> skaet: release happened?
<nigelb> Riddell: yes
 * nigelb hugs release team :)
<ckw> The release party is kinda crazy, but I really want to say thank you to you guys for all the work you put in
<skaet> Riddell,  yes
<skaet> just waiting for #IS to let it out...
 * stgraber tries to publish announcement on edubuntu.org but humboldt is way too slow ...
<pitti> darn, I missed the magic moment
<pitti> skaet: congratulations!
<mvo> skaet: yeah, well done!
<pitti> skaet: you missed 11:04 UTC by 32 minutes :)
<ogra> skaet, https://wiki.ubuntu.com/NattyNarwhal/ReleaseNotes still says "draft - work in progress" at the top
<cjwatson> ogra: fixed
<ogra> thx
* skaet changed the topic of #ubuntu-release to: 11.04 is Released! | Oneiric Ocelot Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team with beer  | we accept payment in cash, check or ocelot food | melior malum quod cognoscis
<highvoltage> skaet: congratulations :)
<charlie-tca> Congratulations to everybody. This was pleasant to wake up to!
<skaet> thanks highvoltage ,  congratulations to the entire team !  It wouldn't have happened without everyone's efforts,  development, test, and release!!!
<ogra_> well, we were all led by an awesome release manager :)
<ScottK> doko_: I test built boost1.46 against gcc4.6 in your PPA and it built.  I'd like to get that split and into Main (we'll drop 1.42) with updated boost-defaults before the first autosync.
<ScottK> (please let me know when I can upload it)
<ogra_> cjwatson, seems not all images on http://cdimage.ubuntu.com/releases/11.04/release/ have a manifest file ?
<cjwatson> ogra_: manifest files are only for live-cd-type things
<ogra_> cjwatson, well, preinstalled should have them
<cjwatson> ogra_: dunno, were they in the daily build?
<ogra_> yep
<ogra_> just checked
<ogra_> i dont find them *that* important, but was just pinged about them in -arm
<cjwatson> ogra_: file a bug on ubuntu-cdimage - I'll try to remember to promote them to the release directories before oneiric builds start
<ogra_> will do
<charlie-tca> http://cdimage.ubuntu.com/xubuntu/releases/natty/release/ is missing the Xubuntu Desktop images
<Pici> The release notes on the wiki mention to use the '-d' switch to do-release-upgrade and update-manager in a few places, leftovers from the beta release notes.  I know !itsawiki, but I feel a bit weird modifying it myself.
<cjwatson> charlie-tca: they're there for me
<cjwatson> Pici: feel free to delete -d
<Pici> cjwatson: will do.
<charlie-tca> cjwatson: I only see alternate images there
<charlie-tca> They are at daily-live, but not in release
<doko_> ScottK: you could already upload
<cjwatson> charlie-tca: probably a mirroring issue
<cjwatson> charlie-tca: it's there for me
<stgraber> Pici: I already did it
<Pici> stgraber: Yeah, I saw you had the lock, thanks :)
<davmor2> charlie-tca: why is the xubuntu release page down more importantly ;)
<charlie-tca> Because we did not get the website updated yet
<charlie-tca> http://imagebin.org/150605 is what I get
<charlie-tca> Didn't know we would release as early as this
<charlie-tca> Got to go move a greenhouse this morning, too
<davmor2> charlie-tca: haha
<jdstrand> skaet: congrats :)
<skaet> thanks!
<ScottK> doko_: OK.  Thanks.
<cjwatson> restarted queuebot for oneiric
<ScottK> doko_: Are you going to drop 2.6 from supported python versions?
<doko_> ScottK: no, not before UDS
<ScottK> OK.
<ScottK> doko_: How about dropping python3.1 from python3-defaults now?  We've already done that transition in Debian.
<iulian> skaet: Congrats.  Well done.
<skaet> iulian,  thanks!
<cjwatson> maco: rejected two of your three gally uploads to natty-proposed :)
<cjwatson> they were all identical, I assume due to the LP bug that makes it looks like dput failed
<ScottK> cjwatson: Yes. She's aware of the bug now.  I wonder if that might be worth a mail to u-d-a to make people more generally aware of it?
<cjwatson> I guess
<cjwatson> (though I don't know enough of the details myself)
<superm1> thx pitti
<ScottK> wgrant: ^^^ Could you draft something?
<wgrant> With a bit of luck it will be fixed tomorrow.
<wgrant> But if not, sure.
<maco> cjwatson: yeah clearly i havent done enough uploads post-freeze to learn about that bug :P
<wgrant> maco: It only happens sometimes.
<wgrant> Once a week or so.
<wgrant> Until we fix it again.
<maco> well the answers.lp.net page i saw only referred to it having started recently
<wgrant> Right, about a month ago.
<wgrant> A bit less.
<ScottK> doko: boost1.46 (for Main) and boost-mpi-source1.46 (for Universe) are in New.  Once those are in the archive, boost-defaults can be synced.
<doko> ScottK: the first one already accepted, can't find the latter
<ScottK> doko: I just finished uploading it, so it probably didn't make it to the queue yet.
<ScottK> doko: Should be there now.
<cjwatson> OK, so I think we're just waiting for libffi, and then my understanding is that doko will ask Launchpad admins to open the archive
<cjwatson> I'll check in tomorrow at some point and see if that needs any help, and if it's open, I expect I'll start autosyncs tomorrow
<doko> cjwatson: I'll leave a message here
<cjwatson> OK, thanks
<cjwatson> heading out to the party nowish :)
<doko> hmm, g++-multilib uninstallable ...
<lool> smoser: Hey, I see http://uec-images.ubuntu.com/releases/natty/release/unpacked/ is not as full as the maverick one; is this still underway for natty?
<smoser> lool, what were you wanting , specifically
<lool> I used to mirror stuff like:
<lool> +releases/lucid/release/unpacked/ubuntu-10.04-server-uec-amd64.img.tar.gz
<lool> +releases/lucid/release/unpacked/ubuntu-10.04-server-uec-amd64-vmlinuz-ec2
<lool> And didn't find the natty equivalents
<lool> +releases/maverick/release/unpacked/ubuntu-10.10-server-uec-amd64.img.tar.gz
<lool> etc.
<bjf> pitti, will you be around tomorrow ?
<smoser> lool, those are gone.
<lool> smoser: Okay
<smoser> you'll need to get it from ubuntu-10.04-server-uec-amd64.tar.gz
<smoser> sorry.
<smoser> i added the vmdk
<smoser> and there were no users i knew of the .img.tar.gz
<smoser> and they were only very moderately smaller than .tar.gz
<smoser> note, i did just fix kernels being visable.
<lool> smoser: Do I remember correctly that it contains a fs image and that the tarball of it can't be rsynced properly?
<pitti> bjf: sparsely, because I need to prepare my moving on Saturday, but my IRC proxy is patient :)
<smoser> the .tar.gz file contains image, kernel, ramdisk.. basically image and some other small things.
<smoser> it is definitely built with gzip --rsyncable
<smoser> but note, that those don't really get that good of use out of --rsyncable
<smoser> because the filesystem is fairly random
<lool> smoser: Exactly
<smoser> so rsync doesn't do all that well iirc
<bjf> pitti, will have natty packages to pocket copy, will send email when ready, was just setting expectations :-)
<smoser> lool, did you have a solution to that?
<pitti> bjf: I noticed them on http://people.canonical.com/~ubuntu-archive/pending-sru.html
<pitti> bjf: see my latest reply to the list; you can now also ask SpammapS to copy them
<smoser> or are you saying that the .img.tar.gz was better?
<bjf> pitti, saw that, might be a good test
<pitti> bjf: but only when it's urgent, I didn't walk through the kernel process with him yet
<lool> smoser: Nope; I was mirroring the unpacked output to have more directly usable files, and be as close as possible to something that rsync could base on
<bjf> pitti, not urgent, just will need doing
<lool> smoser: I'm not sure how good the .img.tar.gz was; I don't remember whether it was significantly better
<lool> smoser: But it at least removed one layer of tar + gz
<lool> smoser: Well, I'll mirror the tarball of the bits then, thanks
<smoser> the one inside the archive .tar.gz is still at the front.
<smoser> and always will be
<smoser> it wouldn't surprise me if the first 180M of that .img.tar.gz was identical (or very similar) to .tar.gz
<lool> smoser: Would it make sense to drop the unpacked/ dir entirely for natty though?
<lool> I thought it was broken because it existed but seemed void of its usual contents
<smoser> lool, i dont know.
<smoser> it probably does, but i dont really want to do it post release.
<smoser> as it has been in its current state for beta1+ at least
<lool> Ok
<smoser> but yeah, the only thing there is the kernel now
<lool> smoser: Slightly unrelated question; I booted a maverick released image today to test a -proposed kernel, and used the AMI on http://uec-images.ubuntu.com/releases/maverick/release/ and on boot it had an "old" 2.6.35-24 kernel, but it's neither the maverick release nor the -updates / -security kernel ABI
<lool> smoser: Is it rolled a bit after release and then not updated?
<smoser> lool, http://uec-images.ubuntu.com/releases/maverick/
<smoser> that gives you the date...
<smoser> we are/I am supposed to be doing a better job than we are at updateing images, ideally in line with -updates kernels.
<smoser> so that the latest would alway boot a new kernel.
<lool> smoser: Sorry, I meant to ask what's triggering these updates; is it supposed to be one time a bit after each release, or every month, or every kernel upload etc.
<smoser> https://wiki.ubuntu.com/UEC/Images/RefreshPolicy somewhat covers that.
<lool> ok
<lool> thanks!
<smoser> ideally it should be done on kernel upload...
<smoser> but i dont know that i'd want it to be all the way automated.
<smoser> so far, it has been a manual process to take a daily build, test it, and mark it as "release"
<smoser> but there are dailies, lool, and they're what you probably want.
<lool> For me dailies kind of imply that they saw less testing  :-)
<lool> That's why I usually go to the release image
<lool> but yeah, I could have used the dailies there
<lool> Alright, thanks for all the details
<ScottK> doko: Second try on boost-mpi-source is in queue.
<doko> ScottK: can't find anything
<ScottK> Odd.  I got the waiting for approval mail.
<ScottK> doko: I see it in https://launchpad.net/ubuntu/oneiric/+queue?queue_state=1&queue_text=
<doko> ok, my mistake, wrong queue
<doko> ScottK: failed again
<ScottK> Shoot.
<ScottK> I'll look at it.
<ScottK> It needn't block anything though.
<ScottK> Once boost1.46 is in the archive for armel, you can sync boost-defaults.
<doko> ok
<pitti> cjwatson, slangasek, doko: FYI, I uploaded cdbs (merged with Debian, and cleaned up)
<pitti> good night!
#ubuntu-release 2011-04-29
<wgrant> We're all set up to open oneiric, but the mirrors are overloaded so oneiric isn't there yet.
<charlie-tca> After all the planning, IS upgraded http://xubuntu.org to https://xubuntu.org today
<charlie-tca> and the website is still down
<wgrant> The mirrors are mostly synced now. Any reason not to open?
<wgrant> ScottK: ^^
<ScottK> Dunno.
<ScottK> I'd want doko_ or cjwatson to say.
<wgrant> cjwatson deferred to doko and doko said to open it when the mirrors were done.
<wgrant> So open it we shall.
<ScottK> OK.  Then I better upload the boost-defaults that didn't get synced.
<wgrant> ScottK: You mean the one that was synced a while ago?
<wgrant> https://launchpad.net/ubuntu/oneiric/+source/boost-defaults/1.46.1.1
<wgrant> But depwait everywhere.
<ScottK> Oh.  Cool.
<wgrant> Missing build dependencies: libboost1.46-dev
<wgrant> Does 1.46 need promotion?
<ScottK> yes.
<wgrant> Looks like we'll wait a bit, then!
<ScottK> It should have been accepted into Main.
<wgrant> Even the source is in universe.
<ScottK> The MPI bits are in boost-mpi-source to be in Universe.
<ScottK> Yep.
<ScottK> doko_: boost1.46 landed in Universe.... Needs to be in Main.
<ScottK> pitti should be up soon, maybe he'll fix it.
<ScottK> As long as it's fixed before we autosync, I think that's the important thing.
<wgrant> Yeah.
<wgrant> Gives the mirrors a bit more time to stop crying, too.
<pitti> ScottK: fix the boost component?
<wgrant> pitti: Yes.
<wgrant> It needs to be promoted.
<wgrant> The copied stuff seems to have sensible overrides, which is a pleasant surprise.
 * pitti spells "oneiric" right the third time
<pitti> promoted
<doko> cjwatson, wgrant: my gcc-4.6 update just finished to build on armel, boost-defaults is now accepted, so once these are available in the archive at around 10:40 UTC, we can open/start syncing.  Will prepare the opening email
<wgrant> doko: Great.
<wgrant> doko: The publisher is done.
<wgrant> Who knows when it will make it out to mirorrs.
<ScottK> Is "Invalid Release signature (key id 40976EAF437D05B5)" just the result of a transient state?
<elmo> yes, unfortunately
<wgrant> Argh, sounds like we have a half-synced mirror set..
<wgrant> Yeah.
<elmo> i'm going to head up to the DC in a bit to try and add more capacity
<elmo> but I may have to disable syncing
<wgrant> elmo: It hasn't synced for hours anyway.
<elmo> if we can't get the load under control
<ScottK> Retry worked.
<wgrant> We've had one or two syncs since release.
<elmo> wgrant: no, it hasn't fully synced
<wgrant> Hah.
<wgrant> Lovely.
<elmo> I'm sure it's tried
<wgrant> It's mostly completed one.
<wgrant> doko: So, shall we open it up?
<doko> wgrant: yes, please. I think cjwatson needs to turn on syncing manually
<wgrant> doko: Done.
<wgrant> oneiric PPAs enable.d
<doko> wgrant: is the ftbfs summary from the last test rebuild kept current for oneiric?
<doko> and, is it possible to add the ftbfs bug numbers to the summary pages?
<wgrant> I'll hack oneiric into it, but bug numbers are a bit harder and slower.
<wgrant> doko: It should be checking oneiric now.
<doko> ok, thanks
<ScottK> Did the boost1.46 source get promoted to Main also?  LP seems to think not.
<wgrant> ScottK: Seems to be to me...
<ScottK> https://launchpad.net/ubuntu/+source/boost1.46/1.46.1-4ubuntu1/ says otherwise here.
<wgrant> 2011-04-29 18:04:49 EST Published Oneiric release main libs 1.46.1-4ubuntu1
<wgrant> Ah, that's upload details.
<wgrant> There's meant to be a comment there saying publishing details can differ...
<wgrant> eg. see the similar section on https://launchpad.net/ubuntu/+source/boost1.46
<ScottK> It seems odd to me that that page would, by design, not reflect the current state of the package.
<ScottK> Package information there still says Universe too.
<ScottK> Although it's got Main in the details section.
<wgrant> It shows the state of the source package, which sadly can differ from its publication in particular archives.
<wgrant> It's *meant* to show the .dsc component. But then I guess they realised they needed upload-time overrides, and all that fell apart.
<wgrant> https://launchpad.net/ubuntu/+source/boost1.46/+publishinghistory is about as direct as it gets.
<ScottK> I did manage to set up pbuilder for oneiric, so that's progress.
<wgrant> ScottK: Interesting.
<wgrant> The mirrors must not be that bad after all.
<ScottK> It was pointing at archive.ubuntu.com, so at least that one.
<wgrant> "one"
<wgrant> Its twelve constituent hosts were out of sync earlier.
<mvo> pitti: my update-manager uploads for natty-proposed got rejected, what is the reason? should I combine the two into one or is there a different problem?
<ScottK> Is merges.ubuntu.com pointing at Natty yet?
<ScottK> Natty/Oneiric
<pitti> mvo: Clint reported back in the bugs; yes, two consecutive uploads with the second one not having the first changelog
<mvo> thx
 * mvo prepares a fix
<ScottK> ~all the armel builders are dead?
<ogra_> looks more like a queue prob
<micahg> lamont: ^^
<lamont> yay for network problems. let me go stare at them in a moment
<lamont> it is our friend the broken build
<lamont> micahg: I suspect it should be better now
<micahg> ScottK: ^^
<lamont> though I suspect I should go visit the putatively idle armel builders and smack 'em around a littler
<ScottK> Thanks.
<skaet> All 11.04 milestone bugs that were open have been reviewed and retargetted.
<charlie-tca> finally got xubuntu.org working again. IS picked yesterday to yu
<charlie-tca> upgrade us to ssl
<ScottK> Just blame it on bandwidth overload due to the release.
<charlie-tca> We couldn't even access it to put the download sites up
<ScottK> Wow.  Sounds like really extreme bandwidth saturation.
<ScottK> ;-)
<charlie-tca> heh
<maco> xubuntu must be very popular :P
<charlie-tca> Maybe gaining, at least
#ubuntu-release 2011-04-30
<slangasek> known issue with apt-cache segfaulting on the armel buildds for oneiric? https://launchpadlibrarian.net/70724359/buildlog_ubuntu-oneiric-armel.dpkg_1.16.0~ubuntu8_FAILEDTOBUILD.txt.gz
<ScottK> slangasek: I saw the same with boost-mpi-defaults1.46
<ScottK> .1
<ScottK> https://launchpadlibrarian.net/70720564/buildlog_ubuntu-oneiric-armel.boost-mpi-source1.46_1.46.1-4ubuntu3_FAILEDTOBUILD.txt.gz
<ScottK> defaults/source
<ScottK> Unfortunately mvo seems to have decided he gets a weekend off.
<ScottK> Got this trying to create an oneiric chroot on an armel box:
<ScottK> /usr/lib/pbuilder/pbuilder-createbuildenv: line 88: 16918 Segmentation fault      $CHROOTEXEC /usr/bin/apt-get -q update
<ScottK> Downgrading apt to the natty-release .debs fixes it.
<ScottK> slangasek: I rebuilt Natty's apt in an Oneiric environment and it does not exhibit the segfault, so I think it's an issue in the new version of apt.
<wgrant> ScottK: Is it affecting all builds?
<ScottK> No.
<ScottK> I don't know how many, but at least two.
<ScottK> I can also replicate the problem in an oneirice chroot on my arm box.
<elmo> cjwatson, slangasek, pitti, et al.: cdimage servers are super near flatlining in terms of disk - the disk usage of the archive itself is up to 504Gb, could someone please cleanup unneeded images?
<slangasek> elmo: I've cleaned off some of the old images; not sure exactly how much that buys us, because there's a www.prev hardlink farm at the moment that prevents me from being able to see any impact with df
<slangasek> ScottK: do you have a backtrace for this apt segfault?
<ogra_> slangasek, i dont have time to dpkg -i the world of debugging tools atm, but here is a quick strace if that helps http://paste.ubuntu.com/601208/
<cjwatson> ScottK: yes, I switched merges.u.c to oneiric on Thursday
<cjwatson> slangasek: I've nuked www.prev now
<elmo> slangasek: thanks
<ScottK> slangasek: I filed Bug #774175 to track this.  Maybe mvo reads bugmail on the weekend ....
<ubot4`> Launchpad bug 774175 in apt (Ubuntu) "apt segfaults on armel in oneiric (affects: 1) (heat: 6)" [Critical,Confirmed] https://launchpad.net/bugs/774175
<ScottK> It does look like that apt bug on armel is affecting builds pretty broadly: http://qa.ubuntuwire.org/ftbfs/
#ubuntu-release 2011-05-01
<lamont> ScottK: only things that use apt...
<ScottK> Yep.
<ScottK> 'minor'
<lamont> to like install build-deps or dist-upgrade or anything...
<ScottK> Yep.
<lamont> is there a fix for it yet, or are we still in limbo land?
<ScottK> Still in limbo.
<lamont> I suspect that part of my monday/tuesday will be dealing with bootstrapping the fix
<ScottK> I hope it's not later in the week.
<ScottK> I'm currently building oneiric's apt on natty to see what it does.
<ScottK> apt-get source apt seems like a odd thing to be typing.
<ogra_> the strace i did showed mmap issues, i would put my bet on libc or toolchain
<ScottK> I added a gdb backtrace to the bug.
<doko> ScottK, ogra: did somebody read my last comment?
<ogra_> doko, yes, just now
<ScottK> doko: I'm rebuilding apt with 4.5 on natty right now.
<ogra_> doko, seems ScottK is on it ?
<doko> apparently not rebuilding with 4.5
<ScottK> I am rebuilding with 4.5.
<doko> but on natty, not oneiric
<ogra_> using the natty apt in the chroot ?
<ScottK> doko: If it fails on natty with 4.5 that will pretty conclusively point to apt.
<ScottK> If it doesn't, then I'll try to figure out the easiest way to build apt with 4.5 on oneiric.
 * ogra_ is just compiling an ac100 kernel and all modules, that will take a while, but i can try a rebuild later 
#ubuntu-release 2012-04-23
<skaet> will coordinate with infinity on the subject first thing in the morning then as well.
<cjwatson> stgraber mentioned bug 986806 which might be a regression from the work on encrypted home; will investigate tomorrow
<ubot2> Launchpad bug 986806 in ubiquity "swap not activated after choosing 'use whole disk'" [Undecided,New] https://launchpad.net/bugs/986806
<cjwatson> (probably specific to encrypted home)
 * skaet nods
<cjwatson> also, I now have an LP test that reproduces bug 887185, so I'm working on fixing that
<ubot2> Launchpad bug 887185 in launchpad "ArchivePermission allows duplicated rows" [Critical,Triaged] https://launchpad.net/bugs/887185
<cjwatson> since that ideally ought to be rolled out by the time we initialise Q
<skaet> good luck with figuring out the fix.
<skaet> ok,  no respins for now,  we'll discuss tomorrow morning the timing of the next set of respins
<kees_> g
<hggdh> ugh. kernel oops
<skaet> hggdh,  get the details in a bug immediatley please.   apw should be coming on line soon, and will be here with us in London, to help figure it out.
<cjwatson> Fix for 887185 (well, at least the urgent bits of it) is making its way through EC2 now, so with any luck should be able to get it deployed on Wednesday
<cjwatson> maybe Tuesday with a strong following wind
<hggdh> skaet: bug 987052
<ubot2> Launchpad bug 987052 in linux "WARNING: at /build/buildd/linux-3.2.0/kernel/softirq.c:159 local_bh_enable_ip+0x7a/0xa0()" [Undecided,Confirmed] https://launchpad.net/bugs/987052
<cjwatson> That was worth a late night, since the extra eight hours or so will matter :-)
<hggdh> skaet: end result is system became completely unresponsive
<skaet> Thanks cjwatson.  :)
 * cjwatson spies jetlag
<skaet> hggdh,  not good.
 * skaet notes that cjwatson is right
<skaet> apw, bjf, ogasawara ^ could you please look at this as soon as one of you comes online.
<pitti> Good morning
<pitti> skaet: the rebuilds you pinged about already happened on the weekend AFAICS, right?
<pitti> at least http://reports.qa.ubuntu.com/reports/ogasawara/weatherreport.html says that all packages are current
<pitti> err, images
<ScottK> pitti: AFAIK there's no immediately pending rebuilds, although we do know we'll need to respin everything at some point because Nobody remembered to set OFFICIAL="Release" in debian-cd until now.
<ScottK> cjwatson mentioned it earlier.
<pitti> indeed
<pitti> I wonder if there is anything in precise-proposed which ought to get wrapped into the rebuild then
<pitti> like compiz, dkms, maas-provision
<ScottK> server will need a respin once mass gets accepted regardless (so mass-provision is no rush)
<ScottK> The current maas package in the archives has dependencies that the security team said were no-go for Main.
<ScottK> (mass-provision will go on the server CD and cobbler will go off to Universe)
<skaet> pitti,  lets plan on discussing in the channel in 3 hours (when more folks are on line,  which of the opportunity targets we feel comfortable including in the respin.
 * skaet notes that the weather report, probably needs updating to reflect that Ubuntu Studio transitioned from an Alternate to a DVD this cycle...
<pitti> skaet: agreed
<ogasawara> skaet: have posted a comment to 987052
<skaet> Thanks ogasawara.  :)
<skaet> ogasawara,  who maintains the weather report these days?
<ogasawara> skaet: I do, was just about to look at the ubuntu studio bit
<skaet> ogasawara,  coolio.  Thank you.    Its late though,  that is certainly not urgent.   We can work around.
<ogasawara> skaet: it's a quick fix to point to the new manifest location.
<skaet> ogasawara,  coolio.  what ever
<skaet> is easiest
 * skaet hates keeping reminders if its fastest to just do it rather than write a reminder.   ;)
<skaet> pitti,  if things are calm right now,  could you fit in a pass on https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop?   Want to make sure we've got the right features highlighted for the release, and get started on adding in the key bugs.
<skaet> if you're working on bugs though,   the ReleaseNotes can certainly wait.
<pitti> skaet: oh, can do; I already brushed it up last week, but I'll have another pass
<skaet> great!  thanks pitti.  :)   Its likely to be a WIP until release day... ;)
 * skaet --> gets breakfast,  l8r
<pitti> skaet: I'm fixing a few spelling/grammar/wording issues, and I remove the update-manager -d instructions (as at the time of release the -d won't be necessary any more)
<stgraber> good morning
 * stgraber gets everything setup here for g+, back in a few minutes
<pitti> do we have an official hangout place? I grabbed an USB webcam now (as my laptop is closed under my desk, and the integrated camera won't do much good)
<pitti> but I have some trouble telling g+ about which cam to use
<stgraber> pitti: skaet said we'd, I'm going to create one if I don't have a reference to it in my e-mails
<skaet> pitti, stgraber - go ahead and create a site for now,  we may consolidate later, once we get the hardware set up.    Choose a good name for it ;).
<skaet> I need to figure out with Pete if we should consolidate qa-meeting in with it,  or leave them as separate G+ sessions.
<skaet> Will be heading in to office in 30 minutes or so, and setting up then.
<stgraber> skaet: remember that we have a 10 participants limit in g+ hangouts
<skaet> stgraber,  good point.  ok, separate it is.
 * skaet -->office,  biab
<micahg> could someone do another round of removals from precise stuff that was removed from unstable?  That way I can just file bugs if I see anything left
<cjwatson> Yes, I was about to start that
<micahg> cjwatson: thank you :)
<cjwatson> Oh, a general p-r run you mean
<cjwatson> OK, I guess so, though I'd tend to be pretty conservative
<micahg> cjwatson: is there output of what has Ubuntu diffs and has been removed?
<pitti> hello cjwatson
<micahg> cjwatson: nm, I know the answer to that :)
<cjwatson> micahg: Er, you could run p-r yourself in dry-run mode I guess
<cjwatson> I forget how upset it gets if you don't have ftpmaster shell access
<micahg> I was thinking of ubuntuwire
<cjwatson> Ah
<micahg> after the p-r run, I can go through an see if there's anything that needs an update to remove old stuff
<cjwatson> micahg: In progress now.  A lot of things relate to other package reorganisations that haven't happened yet in Ubuntu, so I'm being pretty cautious.
<micahg> cjwatson: I can appreciate that, thanks, I'm hopefully going to sleep shortly, will try to pick off a few at a time over the course of the day from what's left
<sil2100> Hi!
<sil2100> I have a small request... there is a compiz patch in -proposed that has been pushed in recently
<sil2100> It works, everything is fine - but it's a workaround for a problem we noticed, since we didn't yet have a good fix
<sil2100> But on Friday, we actually found the root cause of the problem and fixed it the right way
<sil2100> So I wanted to know if it would be possible to exchange the workaround for compiz that's already in -proposed for the 'final' fix
<infinity> sil2100: We kinda like things being fixed correctly.
<pitti> sil2100: this -proposed version will not go into the final release anyway
<sil2100> pitti: ah, so it's anyway target for SRU-0?
<sil2100> infinity: this final, non-workaround fix is much better, since it has no performance implications
<sil2100> infinity: since it fixes a typo someone made long long time ago ;)
<pitti> sil2100: so yes, it's perfectly reasonable to replace the upload with a better one
<sil2100> pitti: excellent, I'll ping ogra_ to port the gles patch if possible to the new distro version
<sil2100> pitti: thanks!
<rickspencer3> skaet, I'm looking at the ISO tracker, for the rows that are green, does it mean those ISOs are good to release?
<rickspencer3> for exable Ubuntu amd64 has a green 6/6
<rickspencer3> ?
<stgraber> wow, Ubuntu is installling so much faster now that I closed g+ :)
<stgraber> rickspencer3: they'll all need a rebuild to be tagged as final images
<skaet> rickspencer,  not quite,  it means that all the tests have passed, and we could if there were no other issues known.   Its part of the story, but not all of it.
<rickspencer3> how can I tell which ones are good to go?
<rickspencer3> stgraber, skaet ^ ?
<skaet> rickspencer3, http://pad.ubuntu.com/ubuntu-release
<stgraber> AFAIK none of them have the official tag set, so they all need at least a cd rebuild if not livefs rebuild
<skaet> gives the issues we're monitoring for respin.
<skaet> [18] is the "Release" respin stgraber is referring to.
<Laney> I see two 18s there :P
<rickspencer3> so they all need to be respun and then retested via the ISO tracker?
<skaet> rickspencer3, yes.
<stgraber> skaet: might be worth adding a note in the tracker header again if not disable them all.
<skaet> stgraber,  yes.
<Daviey> pitti: Can maas be accepted please, and maas-provision be pocket copied from -proposed please?
<pitti> Daviey: sure
<Daviey> thanks
<pitti> Daviey: want to do the releasing yourself, for practicing, or not now?
<Daviey> pitti: the hat now?
<Daviey> what*?
<pitti> Daviey: pad updated for maas, re-labeled to "20" (as "18" already existed)
<pitti> Daviey: sru-release -r precise maas-provision
<Daviey> pitti: I'm not in ~ubuntu-archive, frustratingly.
<pitti> Daviey: can run it for you, I just wondered if you wanted to
<pitti> Daviey: ah, ok
<Daviey> I would like to do it myself, yes :).
<Daviey> skaet: didrocks is kindly looking over tge MIR's for horizon.  NOT SPIN RELATED.
 * didrocks emphases in "kindly" :p
<pitti> cjwatson: reviewing gfxboot, this just changes *.po files? I don't see an actual string change in any code there?
<Laney> can we do something with esteid-browser-plugin one way or the other please?
<didrocks> wait for python-coverage, maybe additional changes are needed ^
<didrocks> pitti: surely, there will be needed for another upload, can you reject it for now?
<pitti> didrocks: coverage?
<cjwatson> pitti: there's a *.pot file there too.  The actual string is in debian-cd
<pitti> didrocks: seems Daviey just uploaded it to change the version for the ubuntu delta
<ogra_> pitti, infinity, note that updating the gles patch on top of the compiz change will take another day for linaro and me to update everything again
<didrocks> pitti: yeah, there is no LICENSE/COPYING file
<didrocks> oh sorry
<didrocks> that's fine, BSD-2
<pitti> cjwatson: ah, so it takes the strings from there; thanks
 * didrocks tries to see where it's specified that it's BSD-2 on the package
<skaet> Daviey, didrocks.   Thanks.  (and appreciate the clarification ;) )
<stgraber> skaet, cjwatson: Unable to reproduce bug 986806 here
<ubot2> Launchpad bug 986806 in ubiquity "swap not activated after choosing 'use whole disk'" [High,New] https://launchpad.net/bugs/986806
<skaet> stgraber, ok.   we'll aim to release note.   Its recoverable.   Would you please add a release note project to the bug?
<skaet> (so we don't loose it.)  Important to tell folks how to recover.
<stgraber> skaet: well, I don't know what the problem is post-install so I don't know how to fix it ;)
<skaet> stgraber,  fair enough.  Some of the folks in the room were just discussing it.
<stgraber> skaet: can be any of missing swap in /etc/fstab, non-encrypted swap trying to be mounted as encrypted swap or just non initialized swap partition
<stgraber> skaet: having another look at the log provided by the user to try and see if there's a clue I didn't see initialiy
<stgraber> skaet: oh, I think I found a clue, will do another test install now. Seems to be related to low-memory environment
<stgraber> install was done with < 512MB of ram, which created a zram device that might have caused the encrypted swap script some troubles
<stgraber> cjwatson: sounds possible? ^
<stgraber> cjwatson: relevant part of the log being: http://paste.ubuntu.com/942285/
<cjwatson> stgraber: possible, but I thought I fixed ecryptfs-setup-swap to ignore zram
<cjwatson> right, so that should just have been ignored?
<cjwatson> I did explicitly test that
<stgraber> yeah, I remember seeing that code... test install running here with 480MB to see exactly wha happens
<stgraber> *what
<stgraber> zram seems indeed to be ignored, but then we get that extra log entry:
<stgraber> Apr 22 08:38:12 ubuntu ubiquity: WARNING: Commented out your unencrypted swap from /etc/fstab
<stgraber> that I don't get on a > 512MB install
<cjwatson> Odd, you should, I think
<didrocks> pitti: skaet: python-coverage looks good to me with this upload, acking the MIR. If you accepted it to -proposed an then move it to the release pocket, I'll do the promotion to main
<didrocks> or maybe you want to override directly when copying from proposed to the release pocket?
<cjwatson> That should be commenting out the swap entry on the hard disk, not zram
<pitti> didrocks: accepted to -proposed
<pitti> didrocks: yes, I can do that
<didrocks> pitti: ok, just set the bug report as fix committed, please change the status to released onceâ¦ released ;)
<pitti> didrocks: yep, will do; thanks
<stgraber> skaet: lunch time here, I'll be back for the hangout. I have a test install running for the encrypted swap install so I'll know more at the meeting
<skaet> Thanks stgraber
 * cjwatson slogs through all the removals from the Cambridge Debian BSP in March
 * cjwatson laughs at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662179
<ubot2> Debian bug 662179 in ftp.debian.org "RM: pouetchess -- RoQA; unmaintained, RC buggy" [Normal,Open]
<cjwatson> "5 years after the maintainer promised to fix a chess program
<cjwatson> which ends the game on check, it's time to stop pretending
<cjwatson> that it can be described as a chess program."
<cjwatson> (Why does ubot2 think that bug's open?  Silly thing)
<Laney> ppc build fix
<cjwatson> fine by me
<Laney> cheers
<doko> slangasek, I did check -lucid and -oneiric updates with your upload, and they both do work for me
<cjwatson> So are we good to respin now?
<cjwatson> Oh, maas needs to go to release, copying that now
<stgraber> cjwatson: so I got an Ubuntu install with the same log as the reporter but I still have a working swap. Doing another install on top of that to see if that triggers it then
<cjwatson> ok
<stgraber> (I don't see why it'd but well, that's what the reporter described)
<cjwatson> So IMO it's ETA ~30mins until we can start respins
<cjwatson> OK, I basically can't hear anything at all on G+
<cjwatson> It's very jumpy sound
<cjwatson> I think if we want to have a productive sync with remote participants we'd be better off with IRC
<pitti> IRC ++
<skaet>   cjwatson, stgraber - anything left to wait for from your perspective, or are we good to go?
<skaet> pitti- anything from your radar?
<cjwatson> maas needs to publish to release
 * skaet has gone to IRC
<stgraber> skaet: I just finished another test install for the ecryptfs issue
<pitti> I can't hear a word from the office, and the video is just a slideshow
<stgraber> skaet: I'm looking at the result now
<cjwatson> After that I don't have anything at the moment
<Daviey> It's amazing really.. We can produce an operating system, but a phone call is too much of a challenge :)
<skaet> ok stgraber,  you're my trigger then.  :)
<apw> Daviey, we can produce an operating system, G cannnot produce a phone call
<stgraber> skaet: VM booting now :)
<skaet> utlemming,  you'll need to respin the cloud images to pick up the "Release" setting (it was omitted by accident on last Thursday's interesting)
<ScottK> What are the issue numbers on the pad referring to?
<cjwatson> skaet: um
<skaet> [18]
<skaet> CONF.sh
<cjwatson> skaet: utlemming's cloud image generation code doesn't use debian-cd, so I don't see why that would matter to him
<cjwatson> He may have something independent
 * Daviey checks
<stgraber> skaet, cjwatson: right, can't reproduce the issue even on low memory doing two installs on top of each other
 * Daviey stops checking for the moment.
<cjwatson> OK, let's chalk it up to cosmic rays for now?
<stgraber> skaet, cjwatson: so if that thing is reproducable, it's difficult enough that it likely won't affect a lot of systems and so shouldn't be RC
<skaet> cjwatson,  Daviey thanks!
<skaet> stgraber,  ack.  ok,  will start queueing up the rebuilds.
<stgraber> skaet: commented in the bug asking for everything that'd help to debug this and marked incomplete, so I think we're done with that one for now
<skaet> thanks stgraber,   ok,  going ahead with the desktop rebuilds
<skaet> Daviey,  I'll start the alternates and server as soon as we're sure publishing is clean
<skaet> infinity,  as soon as you've added the timestamps, ping me and we'll start the arm ones off.
<cjwatson> phone> FWIW we found in the foundations installer sprint that mumble was in practice more usable for leaving on all day
<pitti> yeah, video is not all that important here
<stgraber> yeah and doesn't use half of your CPU. Though I think Millbank would still need a decent microphone
 * cjwatson reaches April in this removals sync-up
<cjwatson> keeping up with the Debian FTP team <- hard
<stgraber> cjwatson: can you ensure you don't end up removing qtnx? I know that last time pitti did the removal sync with Debian that dropped it from the archive even though I use it and fix it when it break.
<cjwatson> I don't recall it coming up, but I'm running from the start of the year so if it was removed from Debian before that it won't come up
<Daviey> cjwatson: maas seems published in release pocket now?
 * skaet is marking iso tracker that respins comming...
<cjwatson> Daviey: publisher is still running
<cjwatson> I'm watching the log
<Daviey> ok
<cjwatson> LP tells you it's published at the start of the relevant publisher run
<stgraber> cjwatson: last time it was removed from the ubuntu archive was on the 6th of February, according to the Debian bug, it was removed in Debian on the 17th of December, so should be good then
<cjwatson> stgraber: yep, won't be a problem
<skaet> hmm...   we're double checking WUBI right now...
<cjwatson> maas is done
<Daviey> cjwatson: thanks
<cjwatson> skaet: what about it?
<skaet> cjwatson,  trying to figure out GPL issue resolved with ev
<skaet> seems to be some doubt
<cjwatson> skaet: Steve and I agreed that it should not be a showstopper
<cjwatson> skaet: (a) It's not clear that we've ever got it particularly right for Wubi so it's not really a regression, (b) we can fix it with non-image changes
<ev> we're fine on wubi
<ev> the wubi revision we have signed and in place is the most recent bzr revision
<cjwatson> I raised it here because I only noticed it recently and because it came up in the context of another bug, not because it was a release showstopper
<ev> as colin confirmed, he and steve don't consider the gpl issue a release blocker
<ev> so there's no need to respin wubi images
<skaet> thanks ev, cjwatson. :)
<ev> skaet asked me to write all that here
<skaet> :)  yup
 * skaet trying to get this virtual thing effective,  and make sure room conversations are echo'd here.  ;)
<stgraber> skaet: I moved the Edubuntu page from https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/EdubuntuDesktop to https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/Edubuntu so that the name is similar to that of the other flavours and fixes some broken links in the process
<fabo> heya, can we still have linaro-image-tools package updated in universe?
<stgraber> fabo: yes
<stgraber> fabo: unseeded universe isn't frozen yet though UI and feature freeze apply
<stgraber> fabo: 	
<stgraber> fabo: UnseededUniverseFinalFreeze is tomorrow at 21:00 UTC
<fabo> stgraber: ok, thanks
<skaet> thanks stgraber!   thought I'd caught them all, but it appears not.  :)
<skaet> ^ full rebuild has started,  should be emerging on the iso tracker from now on.
<stgraber> skaet: there also was a broken link to the kernel config /Spec/ instead of /Specs/, spotted by one of the Edubuntu guys, fixed too :)
<skaet> awesome.   Please thank the guy that spotted it from me.  :)
<stgraber> skaet: any reason why Upgrade is disabled? I'm not aware of anything being broken there
<skaet> good point
 * stgraber is always sad to get an e-mail from the auto-upgrader telling him 8 hours of testing couldn't be reported because the builds are disabled ;)
<cjwatson> micahg: OK, first pass at that finally done, so feel free to report anything else that bothers you
<cjwatson> Also, phew, that was a lot of removals
<cjwatson> Not many with FTBFS bugs attached though
<Laney> were you doing removals from unstable or testing?
<Laney> s/doing/tracking/
<skaet> and by accident I ended up including WUBI in the builds - will be reverting back to the already tested one.
<cjwatson> ack, I don't *think* any of the rebuild triggers affect Wubi preinstalled images?
<stgraber> cjwatson: I think dkms does but that's just a dependency fix so we don't NEED it
<cjwatson> <cjwatson@sarantium ~>$ GET http://cdimage.ubuntu.com/wubi/current/i386.manifest | grep dkms
<cjwatson> <cjwatson@sarantium ~>$ GET http://cdimage.ubuntu.com/wubi/current/amd64.manifest | grep dkms
<cjwatson> <cjwatson@sarantium ~>$
<stgraber> oh, ok :)
<stgraber> ah, I guess dkms is usually in /pool so on the desktop media but not on the preinstalled images
<cjwatson> infinity: any word on what to do with gnat-4.6 outdates?
<infinity> cjwatson: doko claimed he'd look at it.
<cjwatson> OK
<infinity> doko: Did you get anywhere with gnat-4.6 (turning off multilib on armel)?
<infinity> cjwatson: We *could* remove all of armel's gnat-4.6 rdeps, but given that we didn't get it ported to armhf in time, that's kinda one of the few potential use-cases for multiarch on armel/armhf. :P
<infinity> Daiey / cjwatson: Erm, was maas-provision meant to be in main?
<cjwatson> I didn't touch that
<infinity> http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html
<ScottK> It was.
<infinity> I assume this invalidates the current server spins being done. :P
<cjwatson> Might want a fix-committed MIR then.
<cjwatson> It would do.
<ScottK> The only question is about the apparmor profile.
<ScottK> That needs fixed first.
<cjwatson> https://bugs.launchpad.net/ubuntu/+source/cobbler/+bug/950193/comments/6
<ubot2> Launchpad bug 950193 in maas-provision "[FFe] [MIR] maas-provision" [High,In progress]
<ScottK> (see the mir bug)
<cjwatson> So that's now critical path.
<cjwatson> forked-daapd FTBFS on armel/armhf because libdispatch misbuilds with a sufficiently new dpkg-dev, and on top of that it fails to build in three different way.
<jdstrand> I am trying to raise Daviey on this issue. I don't know why it was shipped disabled by default. I guess I could've been more clear...
<cjwatson> *ways
<cjwatson> But I think I've got it disentangled now.
<cjwatson> Oh, sorry, two different ways. :-P
<infinity> Daviey: Can you sort out the maas-provision issue with jdstrand ASAP?
<cjwatson> added a note to the pad about this
<cjwatson> speculatively made Ubuntu ARM Server trigger on a fix for this as well as Ubuntu Server; please correct me if I'm wrong
<infinity> cjwatson: Seems right.
<infinity> cjwatson: Did you remove gnat-4.6/armel binaries already?  outdate seems to not list them...
<cjwatson> No
<infinity> Oh, outdate probably doesn't list armel.
<infinity> La la la.
<cjwatson> Try testing-ports/...
<ScottK> All of cobbler can be demoted.
 * infinity nods.
<infinity> I really wish we didn't split main/ports for britney.
<cjwatson> ScottK: I was sort of loosely waiting until maas-provision could be promoted
<ScottK> maas already doesn't depend on cobbler and the only reason maas-provision exists is because cobbler isn't suitable for main.
<ScottK> We've got plenty of time, I guess.
<cjwatson> ew @ libkqueue
<cjwatson> fails to build with a hang in the test suite, only on amd64/i386
<ScottK> Is the stack of mismatches related to horizon meant to impact the server CD?  Does anyone know?
<cjwatson> Oh, and apparently only on buildds, not locally.
<cjwatson> ScottK: No, it's in supported-misc-servers so not on the CD.
<ScottK> OK.
<ScottK> So we don't need to wait for that.
<cjwatson> And libkqueue has the same maintainer as libdispatch.  Bless me, Father, for I have sinned.
<cjwatson> (At least, I assume I must have done.)
<apw> cjwatson, it inevitable, the list of possible sins is so very large
<infinity> Oh, bleh, tulip is GLES + QT issues.
<cjwatson> I might just disable the test suite on sufficiently old kernels.
<infinity> cjwatson: Just build it on one of the new buildds.
<cjwatson> Maybe if I disable it on <<2.6.32, and then we'll find out later if a buildd upgrade to lucid fixes it.
<infinity> cjwatson: They're precise.
<cjwatson> Oho
<cjwatson> OK, I'll try that
<infinity> cjwatson: And that appears to have worked.  \o/
<cjwatson> infinity: I've been gradually removing OODs from GLES/Qt issues (there are still lots).  tulip has an Architecture: all build-dep, but hey, that's uninstallable on armhf anyway.  Shall I just kill it on armel?
<cjwatson> Hooray for brute force and ignorance
<infinity> cjwatson: Yeah, I was going to remove it.
<infinity> cjwatson: Go for it.
<cjwatson> Done
<infinity> (It should have been removed in oneiric, it was out-of-date there too)
<infinity> Oh well.
<cjwatson> Now if anyone understands maven, I could use help with the wagon build failure
<cjwatson> infinity: I've deduced that OOD hasn't been clear since before lucid
<infinity> cjwatson: srsly?
<cjwatson> Since I've been removing binaries that should have been superseded in lucid
<infinity> Ugh.
<cjwatson> I think karmic was the last time
<infinity> Right, this needs to be a more proactive thing, methinks.
<infinity> Would be less effort if we did it more than once every 2 years. :P
<cjwatson> Yes.  One reason I want to kill it dead for precise.
<cjwatson> It should be part of +1 maint.
<infinity> Ooo, axiom's build failure on PPC is special.
<cjwatson> Dear http://people.canonical.com/~ubuntu-archive/testing/precise_outdate.txt, I don't believe you
<infinity> cjwatson: You don't?
<cjwatson> Oh, _all
<cjwatson> Duh
<infinity> cjwatson: Yeah, that's only main. :P
<cjwatson> Sorry, wrong direction in my browser's back/forward queue ...
<infinity> ;)
<smoser> Adri2000, i've updated the README.files.
<infinity> cjwatson: FFe for an axiom sync, the newer version builds everywhere on Debian (well, except mips...)
<infinity> cjwatson: ?
<infinity> cjwatson: No rdeps, except for some science-* metapackages.
<cjwatson> Do you have the upstream changelog handy?
 * infinity looks.
<cjwatson> libdispatch, why do you mock me
<cjwatson> https://launchpadlibrarian.net/102903313/buildlog_ubuntu-precise-armhf.libdispatch_0~svn197-3ubuntu1_FAILEDTOBUILD.txt.gz clang isn't just stuffed on armhf, is it?
<cjwatson> I don't like the look of those BFD assertions
<cjwatson> Also, libdispatch/powerpc builds iff it *isn't* built on sulfur.
<infinity> cjwatson: In theory, clang works on armhf.  I'm not sure how heavily it's been tested...
<cjwatson> (Log's gone, I'm afraid, but it was SIGILLing.)
<infinity> cjwatson: If it's sigilling on sulfur, then it's incorrectly building in altivec.
<infinity> cjwatson: Which would fail on my PPC machines at home too.
<cjwatson> Wouldn't surprise me.  What's the right flag to fix it?
<infinity> cjwatson: (adare/ross are Apple G5s, sulfur is a POWER5)
<cjwatson> -mno-altivec?
<infinity> Could be.
<infinity> Not sure. :/
<cjwatson> There's no mention of altivec in the source.
<cjwatson> I suppose llvm/clang itself could be doing it.
<infinity> Well, altivec being a guess, but I think that's generally where a G5 and POWER5 differ, ISA-wise.
<infinity> But it would also mean those bianries would fail on G4, G3, etc.
<cjwatson> Not really sure I can be bothered to fix it now.  armhf is getting in the way though.
<cjwatson> Pretty sure at least some G4s had altivec.
<infinity> Some did.
<infinity> Differing generatoins, though.
<infinity> Like SSE.
<infinity> Anyhow, nothing in the PPC archive should have altivec.  Maybe an instruction scanner at some point would be nice.
<cjwatson> http://llvm.org/bugs/show_bug.cgi?id=11924
<ubot2> llvm.org bug 11924 in Frontend "clang makefile assumes all powerpc systems have altivec" [Normal,New: ]
<cjwatson> At a guess
<infinity> cjwatson: oo, sounds likely.
<infinity> I'll make a note of that for an SRU.
<cjwatson> So it's clang itself, not libdispatch
<infinity> Check.
<infinity> I'll fix llvm on PPC later.
<infinity> But the armhf thing, hrm.
<infinity> (Well, if we end up needing to upload for armhf, we could do PPC at the same time)
<cjwatson>                   BFD_ASSERT (in_attr[Tag_ABI_HardFP_use].i == 0);
<cjwatson> The assertion is that if Tag_FP_arch is set to 0 then Tag_ABI_HardFP_use must also be set to 0
<infinity> Which means that something here is producing an SF binary.
<cjwatson> This is all in configure tests with fairly basic compiler options.
<cjwatson> configure:2632: clang -g -O2 -Wformat -Wformat-security -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro conftest.c  >&5
<infinity> cjwatson: Right, so either clang is wrong, or something it's linking to is...
<cjwatson> (precise-armhf)cjwatson@scheat:~$ cat t.c
<cjwatson> int main(int argc, char **argv) { return 0; }
<cjwatson> (precise-armhf)cjwatson@scheat:~$ clang t.c -o t
<cjwatson> /usr/bin/ld.bfd.real: BFD (GNU Binutils for Ubuntu) 2.22 assertion fail ../../bfd/elf32-arm.c:11477
<cjwatson> I'm going to vote for clang
<infinity> Poop.
 * infinity has a look.
<cjwatson> Gotta love compiler test cases you can fit into IRC.
 * infinity wonders how/why this worked a few months ago...
<cjwatson> You didn't change the triplet or something did you?
<infinity> No.
<infinity> Just the linker path, which shouldn't relate.
 * cjwatson -> out for a bit
<doko> cjwatson, infinity: will have to wait until tonight. didn't setup dyndns, working from mwhudson's place today with dholbachj
<jdstrand> Daviey: uploaded maas-provision to precise-proposed
<infinity> jdstrand: Is this one good enough to promote?
<cjwatson> infinity: How do I reliably tell whether an object file is SF or HF?
<cjwatson> infinity: 'clang -c t.c -o t.o && clang t.o -o t' produces a working binary, so I'm suspicious.
<infinity> cjwatson: readelf -A | grep Tag_ABI_VFP_args
<infinity> cjwatson: The binary it produces *is* hardfp.
<infinity> cjwatson: The complaint from ld is about something it's linking to... Some static bits, maybe?  I dunno.
<infinity> cjwatson: I was just trying to hunt that down.
<Daviey> infinity: please don't promote it just yet.. would like to test and find reasoning for why the profile was disabled before progressing.
<Daviey> jdstrand: thanks
<infinity> cjwatson: Or maybe Sledge's assertion is just not quite right.
<cjwatson> I'm confused about why compiling and linking separately works, then.
<jdstrand> infinity: it meets the requirements for the MIR, yes. you'll need to talk to Daviey on whether it is suitable as is
<infinity> cjwatson: The assertion should be (essentially) checking exactly the same thing as the above readelf bit.
<infinity> cjwatson: That said, it's possible to produce ELF object with broken/incomplete headers (remember libicu?)
<cjwatson> The link lines look identical.
<infinity> cjwatson: So maybe llvm/clang is doing something sketchy with interim objects.
<cjwatson> Modulo input file name.
<cjwatson> "/usr/bin/ld" -z relro -X --hash-style=gnu --as-needed --build-id --eh-frame-hdr -m armelf_linux_eabi -dynamic-linker /lib/ld-linux-armhf.so.3 -o t /usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../arm-linux-gnueabihf/crt1.o /usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../arm-linux-gnueabihf/crti.o /usr/lib/gcc/arm-linux-gnueabihf/4.6/crtbegin.o -L/usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../arm-linux-gnueabihf ...
<cjwatson> ... -L/lib/arm-linux-gnueabihf -L/usr/lib/arm-linux-gnueabihf -L/usr/lib/gcc/arm-linux-gnueabihf/4.6 -L/usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../arm-linux-gnueabihf -L/usr/lib/gcc/arm-linux-gnueabihf/4.6/../../.. -L/lib/arm-linux-gnueabihf -L/lib -L/usr/lib/arm-linux-gnueabihf -L/usr/lib t.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed ...
<cnd> skaet, infinity: we've had multiple positive test reports of xorg-server in -proposed on the ubuntu-desktop and ubuntu-x mailing lists, and the bug reported has confirmed that the package resolves his issue
<cnd> just fyi in case you want to respin with it
<cjwatson> ... /usr/lib/gcc/arm-linux-gnueabihf/4.6/crtend.o /usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../arm-linux-gnueabihf/crtn.o
<infinity> cjwatson: Oh, wait.  When you do them serially, it doesn't bitch?
<cjwatson> infinity: Correct
<cjwatson> Wait
<cjwatson> Sorry, I must have done something wrong, it does complain now
<gema> skaet: server images created with usb-creator end up in an endless loop and are not properly verified
<gema> skaet: with dd, everything seems to be good
<Daviey> !
<gema> skaet: so the problem is with usb-creator
<skaet> gema,  thanks for finding this.  urk.
<Daviey> gema: This is a recent thing, as the problem WAS the other way around
<cjwatson> Ah, OK, I don't think it's the linker step.  'clang -c t.c -o t.o && clang t.o -o t' asserts; 'gcc -c t.c -o t.o && clang -v t.o -o t' fails.
<cjwatson> ev: ^- could you look into that usb-creator bug?
<gema> Daviey: maybe, this was my first day with server, so I hadn't really been verifying a lot of images on desktop
<Daviey> gema: can you confirm what options you selected in usb-creator?  persistence ?
<ev> gema: what do you mean by an endless loop?
<cjwatson> infinity: In both the above two cases, 'readelf -A t.o | grep Tag_ABI_VFP_args' output is identical.
<gema> ev: if you burn a usb stick with usb-creator, one of the server images either i386 or amd64, and when you start the install you go to "Check disk for defects", you end up in an endless loop
<gema> ev: if you dd the image, on the other hand, it verifies ok
<cjwatson> Endless loop displaying a memory check UI?
<cjwatson> Oh, sorry, defects not memtest
<cjwatson> Never mind me
<gema> ok
<gema> memtest is fine as far as I am concerned
<cjwatson> What's it doing while in the endless loop?
<skaet> thanks for letting us know cnd.    At this point its best to plan on this for a later SRU - too much churn elsewhere.
<cjwatson> I mean, what's on the screen?
<gema> cjwatson: let me pull it again and I will tell you the message
<Daviey> gema: Oh, i suspect you are the first person all cycle to select "Check disk for defects"
<gema> Daviey: I am afraid so, even though it is the first step on every server install xD
<Daviey> gema: s/step/option/
<gema> Daviey: step, as in test case step
<gema> Daviey: all the test cases have that at the beginning
<Daviey> ahh
<hallyn> ev: hey, created a bootable usb yesterday from live desktop precise image, crashed during install.  (It said it would reboot and let me file a bug, but doesn't seem to have saved anything to the usb writeable partition and isn't doing that, i'm afraid)
<gema> cjwatson: it scans the CD ROM and it says [!] Configuring d-i/ No valid Ubuntu CD-ROM, The CD-ROM you have inserted is not a valid Ubuntu CD-ROM. Please change the disk
<gema> cjwatson: and you are stuck there, there is only a "continue" option that doesn't do anything but showing the same dialog again
<ev> hallyn: if there aren't any logs, there's really nothing we can do to fix it
<ev> whatever it was
<hallyn> ev: of course not, just a heads-up
<hallyn> meanwhile, re-trying
<infinity> cjwatson: Eh?  'gcc -c t.c -o t.o && clang -v t.o -o t' doesn't fail here.
<cjwatson> infinity: Sorry, too many negatives.
<cjwatson> infinity: clang -c asserts, gcc -c succeeds.
<infinity> clang -c t.c -o t.o && readelf -A t.o
<cjwatson> So it's the .o clang's producing that's at fault, not its link step.
<infinity> It's either not a hardfp binary, or it's getting broken ELF headers, as I suspected.
<cjwatson> gema: Could you mount the produced USB stick and pastebin 'ls -l' of its top-level directory?
<ev> gema: what does syslinux/syslinux.cfg contain?
<ev> ah, that too
<gema> indeed
<gema> jsut a sec
<cjwatson> That error message indicates that (following symlinks) either (a) .disk is not a directory (b) ubuntu is not a directory (c) md5sum.txt is not a regular file
<infinity> cjwatson: Actually, it is a hardfp binary, according to the headers, but it's also nonsense (and probably a lie)...
<infinity> cjwatson: v4t, thumb-1...
<infinity> If this isn't a lie, it should be. :P
<cjwatson> I note "-triple armv4t-unknown-linux-gnueabihf"
<cjwatson> (in 'clang -v t.c -o t')
<ogra_> awww
<gema> cjwatson, ev: http://paste.ubuntu.com/942601/
<ev> gema: ls -la :)
<cjwatson> Shouldn't need -a
<cjwatson> Oh, we should
 * cjwatson on bad form today
<cjwatson> Anyway, no ubuntu directory or symlink there
<cjwatson> I guess vfat doesn't do symlinks, hmm
<gema> ev: http://paste.ubuntu.com/942603/
<cjwatson> Not sure what to do most correctly.  We could nobble cdrom-checker to check for dists instead of ubuntu.
<ev> that sounds sensible, given that there are other tools out there beyond usb-creator that do equally stupid things in this case
<cjwatson> But we'll have to rebuild d-i for that.
<cjwatson> skaet: ^-
<ev> (unetbootin creates 0 byte files when it encounters a symlink)
<cjwatson> So that'll be netboots, alternates, servers
<infinity> cjwatson: Oh, as to the "upstream changelog" for axiom, it's basically unreadable. :P
<cjwatson> infinity: I guess with no rdeps I basically don't care.  Have your FFe and let's get it build.
<cjwatson> built.
 * infinity grabs cdrom-cheker to review.
<cjwatson> The diff is pretty obvious; I was going to wait for agreement on whether we want that respin.
<cjwatson> It's a fairly contained set of images.
<gema> so, where do you guys want me to put the bug, on usb-creator, on the cdrom-checker?
<infinity> cjwatson: We seemed to have already agreed here.
<cjwatson> cdrom-checker, but I already uploaded a fix without any bug number in the changelog
<skaet> cjwatson,  given its fairly confined, and testing hasn't progressed too far.
<Daviey> cjwatson: i'd really appreciate if d-i went via -proposed if we are doing it.. i think that most people seem to use USB these days makes it a worthwhile fix for release
<cjwatson> So no need for a bug really
<infinity> cjwatson: And accepted, after I looked at wider context. :P
<cjwatson> Daviey: the two halves of that sentence seem contradictory?
<ScottK> Daviey: Did you find an archive admin to binary New the quantum FFe you approved?
<gema> cjwatson: ok, then I won't put a bug there
<ScottK> In the meantime it probably shouldn't be accepted.
<cjwatson> ScottK: o/
<ScottK> OK.  Thanks.
<ScottK> Done then.
<infinity> Daviey: There's no point in doing it in -proposed... We want it in release.
<infinity> Daviey: (d-i, that is)
<slangasek> doko: good-o
<cjwatson> Yeah, d-i doesn't have arch skew problems.
<Daviey> cjwatson: I mean, having an inconsistent d-i really breaks us.. so it would be nice to smooth the road, no?
<cjwatson> Daviey: How so?
<cjwatson> Daviey: I can't think of any problems caused by d-i building at different times on different architectures, in the absence of a kernel ABI bump.
<cjwatson> Which there isn't here.
<infinity> That's pretty much uniquely an issue with ABI bumps, isn't it?
<cjwatson> Yes.
<cjwatson> Daviey,zul: Er.  This quantum upload moves files between packages without Breaks/Replaces.
<cjwatson> Daviey,zul: Please fix.  I won't accept this without that.
<zul> cjwatson: ack
<cjwatson> zul: Also, "debian/quantum-server.quantum-sever.upstart" typo
<cjwatson> This results in your upstart job not being shipped.  Clearly not build-tested.
<cjwatson> zul: I think you only need Breaks: quantum-server (<< 2012.1-0ubuntu3) and Replaces: quantum-server (<< 2012.1-0ubuntu3) in quantum-ryu-agent, not in the other quantum-*-agent, since that's the only file that moves.
<cjwatson> (Is the lack of dependencies on *-agent intentional?  I don't know the packaging structure here.)
<zul> cjwatson: yeah im testing it now
<zul> cjwatson: it is
<cjwatson> OK
<cjwatson> Rejecting the current binaries; I'll be happy to review an update.
<infinity> cjwatson: Oh, derp.  Thise assert is while iterating Tag_FP_arch, which isn't being written by clang/llvm.
 * infinity needs to did into voodoo.
<cjwatson> https://launchpad.net/ubuntu/+source/cdrom-checker/1.21ubuntu2/+build/3426318
<cjwatson> Um, maybe we should get some of these armel builders recovereed?
<cjwatson> -e
<infinity> When was meissa disabled?
<cjwatson> Dunno, but it blew up on the previous cdrom-checker build.
<cjwatson> (I didn't disable it, I just thought about it)
<infinity> I really want these machines running precise.
<cjwatson> Well, something is critical-path, because I don't want to upload d-i with cdrom-checker out of sync
<infinity> It's built now.
<infinity> Sadly, 6 minutes later than you wanted.
<zul> cjwatson: http://paste.ubuntu.com/942687/
<cjwatson> zul: Why the chdir, and the removal of respawn?
<cjwatson> zul: Also, this still doesn't fix the typo in the *file name* of the Upstart job
<cjwatson> The one that means it doesn't get installed at all in your binary packages
<zul> cjwatson: because if quantum-server it just keeps on respawning until someone notices
<cjwatson> zul: The Breaks/Replaces is in the wrong place.  You need it on quantum-plugin-ryu-agent, not quantum-plugin-ryu
<zul> gotcha
<cjwatson> And 'bzr mv debian/quantum-server.quantum-sever.upstart debian/quantum-server.quantum-server.upstart' :-)
<cjwatson> Or even just debian/quantum-server.upstart, probably.
<apw> jbicha, just looking at the 'Ubuntu Desktop Guide' it says 'Welcome to Ubuntu 12.04' without the LTS
<cjwatson> Actually that should have resulted in "/etc/init/quantum-sever.conf", I think, so you may want to test-build to find out why it went missing entirely rather than merely having a typoed name.
<pitti> is someone already reviewing maas-provision, or want me to?
<pitti> Daviey: ^
<zul> cjwatson: works fine if i just rename it debian/quantum-server.upstart
<zul> cjwatson: http://paste.ubuntu.com/942703/
<Daviey> pitti: it's blocked on something, please wait.
<pitti> ack
<jbicha> apw: you could file a bug or submit a merge proposal for that if you like :)
<cjwatson> zul: yep, that looks better now, thanks
<infinity> jbicha: Submit a merge proposal for a 4-character fix? :P
 * cjwatson creates the obvious basic wiki pages for quantal
<jbicha> infinity: you trust my memory?
<cjwatson> and might as well rename the LP series now too
<pitti> cjwatson: can you? or does that require an RT?
<pitti> I just had a look, but don't find a button for it
<jbicha> I'm not sure yet when we're opening the ubuntu-docs branch for the SRU updates, if it's today, it's not hard to remember
<cjwatson> pitti: I should be able to
<cjwatson> Oh, maybe I can only change the displayname.  Let's see
<cjwatson> OK, RT time I guess
<NCommander> morning world
<cjwatson> RTed
<skaet> morning NCommander :)
<skaet> thanks for renaming the series cjwatson.
<jdstrand> Daviey: fyi, bug #987374. I suggest someone fix that before maas-provision is accepted, but please base the work on what is in unapproved now
<ubot2> Launchpad bug 987374 in maas-provision "apparmor denials when using 'maas-import-isos'" [Undecided,New] https://launchpad.net/bugs/987374
<infinity> cjwatson: I can change the series name.
<cjwatson> Huh.  Where?
<cjwatson> You surely don't still have a ducky
<infinity> cjwatson: You could change your RT to be a request for quantal-changes.
<infinity> cjwatson: (I just fixed the name in LP)
<cjwatson> You're in ~launchpad, I guess that might help?
<infinity> Yeah, that's what does it for me.
<apw> jbicha, bug #987385
<ubot2> Launchpad bug 987385 in ubuntu-docs "the Help/Ubuntu Help page lists the release name as 12.04 without the LTS" [Undecided,New] https://launchpad.net/bugs/987385
<ev> cjwatson: do you happen to know why the alternates, specifically the server alternate, has vga=788 set? Do we not want to defer to the kernel on that?
<ev> apw noticed that the Dell system he's testing on really doesn't like that mode
<cjwatson> ev: It's loads faster on most systems
<cjwatson> see the changelog
<ev> ah, okay
<cjwatson> debian-installer (20100211ubuntu11) maverick; urgency=low
<cjwatson>   * vga=788 seems to work now that vesafb and fbcon are built into the
<cjwatson>     kernel, and it's very much faster in kvm, so resync with Debian and use
<cjwatson>     it.
<cjwatson>  -- Colin Watson <cjwatson@ubuntu.com>  Mon, 28 Jun 2010 17:44:51 +0100
<cjwatson> Also, we aren't using full KMS in d-i, IIRC, and so the kernel would ordinarily just give us a really basic text mode
<cjwatson> This is nicer to use
<apw> cjwatson, ok it is occuring on a dell mini 10v, not on my hp mini so i assume it is not everywhere at least
<Daviey> Please can maas-provision be accepted into -proposed only (current target pocket)
<infinity> Done.
<infinity> cjwatson: So, yeah.  Not sure if this is llvm's fault or clang's.  But one or both of them need to be hit with a hammer to map GNUEABIHF to armv7-a, and then to stop assuming that armv7-a means neon. :P
<NCommander> infinity: ew
<cjwatson> infinity: Are you going to keep working on it?
<infinity> cjwatson: Yeah, I can probably just fix it in clang for now, and worry about llvm in a more careful SRU later.
<cjwatson> OK, cool
<infinity> It irks me that all this arch detection stuff seems to happen in two places.
<infinity> If clang is meant to be an llvm frontend, why duplicate it all (and get it differently wrong?)
 * NCommander shivers at menthion of clang
 * skaet sees WUBI update, and goes to revert it manually.
<tumbleweed> ^ anyone feel like uploading the precise-proposed version of that? I can't. bug 987390
<ubot2> Launchpad bug 987390 in distro-info "[SRU] Add Quantal to distro-info-data in oneiric" [Medium,Fix committed] https://launchpad.net/bugs/987390
<slangasek> does kubuntu use network-manager?  I don't see network-manager-kde seeded on the ISOs
<slangasek> I'm actually trying to figure out if the dnsmasq release note is relevant to kubuntu or if it's only relevant to ubuntu desktop
<slangasek> (currently it's being included in the release notes for all the products)
<skaet> slangasek,  we're heading off for dinner here now,  when the maas-provision lands,  can you kick off the respins when [22][23] show up, if I'm not online.
<skaet> ?
 * cjwatson -> evening.  May not be around much tonight; up early tomorrow to head for London.
 * skaet will check in again after food.
<slangasek> skaet: yep, will watch for
<micahg> cjwatson: ~130 removals, nice :)
<jdstrand> ok, I promoted maas-provision
<jdstrand> and demoted cobbler
<pitti> good night!
<Daviey> jdstrand: thanks!
<slangasek> cjwatson: based on feedback from the CD people who rightly point out that using all the sectors for data is a violation of Red Book format, I've lowered our CD size limit back down a smidge, after confirming that none of the precise images currently exceed it
<slangasek> but just in case the images get bigger between now and Thursday, better safe than sorry
<cjwatson> slangasek: OK, thanks
<slangasek> cjwatson: was there going to be a d-i upload for cdrom-checker?
<slangasek> I see cdrom-checker itself updated and in
<cjwatson> Oh, yes, I forgot
<slangasek> ok
<cjwatson> Can't do it right now, either I can do it in an hour or so, else feel free
 * slangasek cancels the alternate CD respins, since we probably want that update in for consistency
<cjwatson> Yes, sorry
<slangasek> just a no-change upload of d-i?
<cjwatson> Yes
<slangasek> ok, will do
<cjwatson> to precise, not -proposed
<slangasek> understood
<ScottK> slangasek: Kubuntu does use NM.  The front end is plasma-widget-networkmanagement.
<slangasek> ok
 * slangasek drops this into the Kubuntu release notes as well then
<slangasek> ScottK: well... except there doesn't seem to be a section for it.  Do you want the dnsmasq release note integrated somewhere on https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/Kubuntu ?
<slangasek> on https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop I stuck it under "Desktop Interface"... I guess I could redo the Common Infrastructure include to allow sticking things under the heading that aren't actually common :P
<ScottK> Just a sec.  Let me get the guy that's doing the release notes.
<slangasek> ok :)
<slangasek> oh grr, the command on the pad backgrounds the job, wth
<ScottK> slangasek: claydoh is doing the Kubuntu release notes.
<ScottK> claydoh: slangasek had a question about where to include the dnsmasq changes that are common to Kubuntu and Ubuntu in the Kubuntu release notes.
<slangasek> claydoh: hey there - I was telling ScottK that I've pulled the release note for dnsmasq out of our "Common Infrastructure" page because it's not common except to desktops, and wondering if you wanted this pulled back into https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/Kubuntu in some fashion
<slangasek> (https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop shows the note in question)
 * ScottK thinks it ought to be in the Kubuntu notes somewhere.
<slangasek> claydoh: I basically agree with ScottK, but don't know where to put it :)
<claydoh> slangasek:  I will look
<slangasek> ok, apparently trying to do a fresh bzr checkout of d-i for this upload was a mistake
<slangasek> I'll just apt-get source and commit after
<slangasek> much after
<claydoh> slangasek: I don't see why it can't be kept where it was
<slangasek> claydoh: because that include file was being pulled into the release notes for all images, including server and core, where it's false
<claydoh> slangasek: oh, ok
<slangasek> self-accepting d-i
<ScottK> python-scipy reject was discussed with the uploader.  It'll come back in a few minutes.
<claydoh> slangasek: I could format Kubuntu's page to reflect the layout for UbuntuDesktop and then place it in a similar area
<slangasek> claydoh: if you wish; my other idea was to munge the way we're doing the include, so that we can shove almost-common stuff in between the header and the include
<ScottK> Common and Desktop Common (matches the seeds)
<ScottK> Should I be concerned about "CD image kubuntu/precise/daily failed to build on 20120423.1"?
<claydoh> slangasek: whichever is better for  you. Desktop Common would seem to be an appropriate place
<slangasek> ScottK: no, that's me properly ^Cing the alternates that I started before noticing d-i needed an update
<ScottK> OK.  Thanks.
<slangasek> ScottK, claydoh: stuck in a 'Desktop Infrastructure' section on the page, is that what you want?  Feel free to edit to taste here
<ScottK> Thanks.
 * ScottK looks at claydoh
<claydoh> ScottK: slangasek I like it
<ScottK> Kubuntu Desktop powerpc test results!  That's a pleasant surprise.
<Riddell> good evening
<gema> there seems to be a problem with the indicator in desktop arm, when there is no wired connection and you are installing and giving it a wireless password, it shows a non-existent wired connection going on and off
<gema> and it takes forever for it to actually show the indicator of wireless connected, even though the network is authenticated
<ogra_> on what platform is that ?
<gema> pandaboard desktop arm
<gema> I am installing without wire
<ogra_> can you file a bug please ...
 * ogra_ hasnt tested wlan for a while, wired works fine usually
<gema> yes, I am waiting for it to finish installing, I have taken pictures and I will attach
<ogra_> thanks
<gema> will give you bug no whenever I have it
<ogra_> please subscribe (not assign) ubuntu-arm to it
<gema> ok
<ogra_> then it will show up on the arm list
<gema> I cannot assign anyway :)
<ogra_> ah, right :)
<gema> it is very annoying, it keeps saying Wired Network disconnected
<gema> ogra_: bug 987511
<ubot2> Launchpad bug 987511 in network-manager "network manager not handling properly wireless only on pandaboard" [Undecided,New] https://launchpad.net/bugs/987511
<gema> I subscribed your team
<jbicha> heh, quantal's not even in the auto-correct dictionaries :( I guess that's a good SRU candidate
<knome> jbicha, "xubuntu" isn't either... oops!!
<ScottK> knome: That's on purpose.
<ScottK> </kidding>
<knome> :P
<knome> anybody familiar with the dictionaries?
<ScottK> Yes.  I make my kids use one every time they ask me how to spell a word.
<knome> ScottK, bad jokes day?
<ScottK> Awwh.  Come one.  Those were great jokes.
<ScottK> The second one is just being ironic since I do that.
<knome> why not come two.
<ScottK> one/on anyway.
<knome> btw, is ScottL a better version of you?
<knome> even lts.
<ScottK> No.  He's always claiming to be at work.
<knome> isn't that a good work?
<ScottK> Whereas I work from home, so I am in fact at work even when I'm at home.
<knome> err, s/work/thing/
<ScottK> No idea.
<knome> same here.
<ScottK> What package ships the "Prepare for shipping ..." bits in oem mode?
<ogra_> ScottK, should all be ubiquity nowadays
<ScottK> ogra_: Thanks.
<ScottK> OK.  With the Kubuntu alternate doing an OEM install doesn't result in oem-config-kde getting installed.  Suggestions on where to look for that problem?
<slangasek> cjwatson: I see various changes to the pipeline command for arm on the pad that I don't understand.  What are these sleep 10's for?
<slangasek> I'm also confused that the entire sequence is now being backgrounded, instead of just the cron.daily part
 * Daviey checks in
 * ScottK tut tuts about asterisk.
<cjwatson> slangasek: It was sleep 1 last I checked, and it was just to make sure that the starting message for each sequence were disjoint.  The entire sequence is now backgrounded because every ARM build type is now being dispatched to its own livefs builder.
<cjwatson> So we don't need to block on one set of livefses before starting on the next.
<slangasek> cjwatson: ah right
<stgraber> ScottK: just saw your message from earlier. Assuming oem-config-kde is on your media, the place to look for it is in ubiquity as that's where the oem udebs come from
<stgraber> ScottK: I fixed an issue there recently with the ubuntu slideshow not being installed. Keep in mind that even though it's the same branch, the desktop and alternate code paths are different, so you'd likely need to update both.
 * stgraber goes to bed now, talk to you all tomorrow
<ScottK> It works fine on the Kubuntu desktop CD and is present on the alternate, just not installed.
<cjwatson> Check the installer syslog for an attempt to install it
<cjwatson> It's meant to work as follows:
<cjwatson>  * oem-config-udeb/frontend is preseeded to "kde" on Kubuntu images (/preseed/kubuntu.seed on the image)
<cjwatson>  * ubiquity/finish-install.d/01oem-config-udeb (/usr/lib/finish-install.d/01oem-config-udeb in the installer environment) fetches that and feeds it to apt-install
<cjwatson> Not meant to be *that* many moving parts here
<ScottK> E: Unable to locate package oem-config-slideshow-ubuntu
<ScottK> It seems to bail at that point.
<cjwatson> Hmm.  Whoops.
<cjwatson> Did you already file a bug for this?  (If not, don't worry, it's just for the bug number.)
<cjwatson> The quick fix is to jam oem-config-slideshow-ubuntu into your seeds and respin.  The slow but correct fix is to change ubiquity to install oem-config-slideshow-ubuntu separately and not worry if it fails.
#ubuntu-release 2012-04-24
<cjwatson> Regression from bug 984736.
<ubot2> Launchpad bug 984736 in ubiquity "oem-config not installed after initial installation in OEM mode" [Undecided,Fix released] https://launchpad.net/bugs/984736
<ScottK> I did.
<ScottK> Let me look for it.
<cjwatson> Well, ish, not entirely sure that description matches that fix
<ScottK> Bug 987050
<ubot2> Launchpad bug 987050 in debian-installer "No "Prepare for shipping ..." option after OEM install from D-I" [Undecided,New] https://launchpad.net/bugs/987050
<ScottK> cjwatson: ^^^ and with that I'm off for a bit to have dinner with the kids.
<cjwatson> ScottK: Would you want a respin for this, if it's done in the seeds for minimal impact?
<ScottK> cjwatson: Yes.
<ScottK> There's minimal testing on the current Kubuntu images.
<cjwatson> You have enough space.
<cjwatson> London's asleep (ironic given I'm on the same timezone).  I'm going to JFDI.
<cjwatson> Running.
<cjwatson> And bed.
<ScottK> cjwatson: Thanks.
<ScottK> Can someone mark the current Kubuntu images obsolete in the tracker?
<slangasek> ScottK: all? desktop? alternate?
<slangasek> (disabling all, can always re-enable some if that's wrong)
<ScottK> slangasek: Whatever cjwatson respun before he went to bed.  I assume it was just the alternates, but I don't know.
 * slangasek looks at the process list and makes an educated guess
<slangasek> mm, I don't see anything respinning
<slangasek> ScottK: ^^ so I don't know where that got stalled, unfortunately
 * lamont finishes testing his postfix change, wonders about how to toss that at -proposed in a proper manner so as not to be larted by slangasek 
<slangasek> lamont: in an SRU-compliant manneR?
<lamont> yeah that's it
<lamont> ScottK had me all prepped, but well.... larting hurts
<slangasek> heh
<lamont> rather, being larted does
<lamont> slangasek: so if I throw it into precise-proposed and there's no paperwork, does it just languish?
<slangasek> it'll almost certainly get wedged at one stage or another
<slangasek> https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
<lamont> ta
<lamont> slangasek: bug 980682, fwiw
<ubot2> Launchpad bug 980682 in postfix "postconf can't open main.cf with the result that /etc/resolvconf/update-libc.d/postfix fails trying to copy /etc/resolv.conf onto itself" [Medium,Fix committed] https://launchpad.net/bugs/980682
<slangasek> score
<lamont> wtf it just shows up now, I do not know.
<lamont> it's been there since 2.1.5
<lamont> and you get turkish debconf translation updates at no additional charge
<slangasek> excÄ±tÄ±ng
<lamont> no.  boring.  it's all very booooooring.
<lamont> nothing to see here, it can move along.
<slangasek> TurkÄ±sh translatÄ±ons are never borÄ±ng
<lamont> rofl
 * slangasek sweeps up the fallen dots
<slangasek> â¦
<lamont> you know those are like nearly-pure sugar, right?
<lamont> ~lamont/+archive/ppa if you are curious at all
<lamont> hrm... no can do step 1 of procedure.
<slangasek> exceptions will be made
<slangasek> also, "fixed in Debian" is an answer ;)
<lamont> yeah.  I need to actually build the binaries for debian so I can upload it
<lamont> Bug description: Dont know what happened, it just crasched
<lamont> now that's specific
<slangasek> that's why we're creating a crash database ;)
<slangasek> since providing good crash data is orthogonal to writing good bug reports
<lamont> too true
<lamont> anyway, it'll be uploaded to debian uh... tomorrow I predict.  and someone will add the SRU stuff to the bug
<lamont> s/someone/someone on the postfix team/
<pitti> Good morning
 * slangasek waves
 * RAOF shores
<cjwatson> ScottK: just alternates.  well, they supposedly posted, but I don't know why queuebot didn't notice ... oh, because it isn't here
<cjwatson> ScottK: so my posting raced with slangasek disabling them
<cjwatson> I've re-enabled Kubuntu/* now
<slangasek> ahh, ok
<slangasek> sorry, would've looked more closely if I'd noticed queuebot wasn't around
<pitti> micahg: there is no open bug for 4digits, and it's a new upstream version etc.; why was this synced?:
<micahg> pitti: looks like all bug fix: http://fourdigits.sourceforge.net/ChangeLog
<pitti> micahg: ah, thanks
<pitti> <fake queuebot> accepted 4digits
 * micahg was going to flag, but missed that queuebot was AWOL
<micahg> pitti: someone in ubuntu-devel was saying how one of the bugs was bad as well
<pitti> back in ~ 2 hours
<micahg> <fake queuebot> Unapproved: spip (2.1.12-1 -> 2.1.13-1, no packageset, unseeded)
 * skaet --> office,  biab
<stgraber> micahg: oops, fixed
<Laney> skaet: morning, all ok?
<Laney> skaet: What time are we having UUFF?
<skaet> good morning Laney :)
<Laney> "1.5 days before release date" - when is that?
<skaet> 1200 UTC is the plan (if I'm remembering correctly..  ;) )
<cjwatson> what are the semantics of UUFF?
<cjwatson> we still have a fair bit ofo outdate to clear
<Laney> pretty much "Universe Done"
<cjwatson> is there a process for exceptions?
<Laney> nope, but maybe we could extend it to EOD
<stgraber> was 12:00 UTC announced somewhere? a quick scan of PreciseReleaseSchedule shows it's today but doesn't say a time, so some will likely assume it's 21:00 UTC like all the other freezes
<Laney> no, but it says "normally" and the page itself talks about 1.5 days before the day of release
<Laney> which is not as clear as it could be but probably does imply 1200UTC
<infinity> cjwatson: http://permalink.gmane.org/gmane.comp.compilers.clang.scm/44047
<skaet> stgraber,  Laney:  http://irclogs.ubuntu.com/2012/04/20/%23ubuntu-meeting.html#t15:01
<Laney> thanks
<pitti> oh, lucid-universe upgrade test failed again
<pitti> https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade-lucid-universe/lastFailedBuild/ARCH=amd64,LTS=lts,PROFILE=universe,label=upgrade-test/artifact/lts-universe-amd64/bootstrap.log
<pitti> jibel: "bind(ipv4,127.0.0.1,5901): Address already in use" -> ah, seems to be a problem with the test env only?
<jibel> pitti, I re-run the job and upgrade is in progress.
<jibel> pitti, but this error shouldn't happen there is a lock that prevent 2 jobs from using the same ports.
<jibel> I'll have a look after the release
<pitti> skaet: http://qa.ubuntuwire.org/ftbfs/
<micahg> can someone look at spip in unapproved?
<micahg> Laney: why would UUFF not be like regular final freeze for seeded an just require a release ACK or 2 to upload *anything*?
<Laney> we decided the semantics differently, and it's unfortunate that we called it "final freeze"
<Laney> I already said that I wanted to revisit it
<cjwatson> skaet,pitti: FWIW I'm less worried about FTBFS in general, and more about cases where there are outdated binaries without source
<cjwatson> we can't fix all the FTBFS
<pitti> right
<cjwatson> and there are some that are actually bogus/not-a-real-problem for one reason or anotheer
<cjwatson> -e
<pitti> I was just saying that probably most of the depwaits are not a concern, if the package never built
<pitti> (on that arch)
<cjwatson> yes, ignore them
<pitti> retried libfixposix on amd64, let's see how far it gets a second time
<micahg> moc looked easy enough to fix, but I don't have time to do it now
<micahg> I'll SRU it if no one beats me to fixing it
<cjwatson> jamespage: do you think you could have a look at the wagon FTBFS?  I'm stumped
<cjwatson> it's something arcane in maven
<cjwatson> https://launchpad.net/~cjwatson/+archive/ppa/+build/3421480 has my latest attempt at extracting debug information
<cjwatson> it builds cleanly in a local sbuild
<pitti> libfixposix built
<pitti> ruby-hdfeos5 running
<pitti> someone kicked wagon already
<cjwatson> I removed openvswitch/powerpc
<stgraber> skaet: http://localized-iso.qa.ubuntu.com/qatracker/milestones/215/builds
<cjwatson> looking at quantum in binary NEW
<pitti> so that leaves sipwitch and slang-slirp as remaining FTBFS on x86
<pitti> for most of the other arches we'll probably resort to binary removal
<cjwatson> sipwitch has no outdates
<pitti> ah, never built
<cjwatson> libdispatch/armhf and forked-daapd/armhf are waiting on infinity figuring out what's wrong with clang
 * micahg is thinking to file a removal request for slang-slirp
<pitti> cjwatson, skaet: want me to run through all the arm*/ppc FTBFS and check which of those have outdates?
<cjwatson> pitti: no need
<cjwatson> I'm already fairly well on top of that, being selective about removal depending on whether they have rdepends
<pitti> ok, thanks
<pitti> so I'll look at why the Chinese images are oversized
<Laney> micahg: oh, hah, that does look easy
<skaet> thanks pitti
<micahg> Laney: debian 623637
<ubot2> Debian bug 623637 in src:slang-slirp "slang-slirp: FTBFS: Test error in examples/vec" [Serious,Open] http://bugs.debian.org/623637
<Laney> moc I meant
<micahg> Laney: ah, yes :)
<Laney> so easy I'm scared of getting it wrong
<doko> infinity, gnat-4.6 uploaded
 * cjwatson removes cuyo/armhf
<pitti> so http://paste.ubuntu.com/943833/ are the five significant packages on the Chinese images
 * cjwatson aborts his moc test build :-)
<Laney> heh
<pitti> we need to chop off a good 8 MB
<Laney> I didn't test it on the affected arches
<pitti> my gut feeling is that we should either drop ttf-wqy-zenhei (as we already ship ttf-wqy-microhei), or ibus-table-wubi (as we already ship sunpinyin)
 * pitti digs into history why wubi was added
<cjwatson> least confusing ibus module name evah
<cjwatson> Laney: haha, makes sense though
<pitti> skaet: I pinged two people about it (see #u-devel), and reduced the options to 3; now we need to know what hurts least
<micahg> can we still do removals after UUFF?
<pitti> micahg: yes, they can happen until the bitter end, i. e. when flipping the status from "frozen" to "current"
<pitti> well, they need a publisher run, of course
 * micahg filed some more removals
<micahg> chrisccoulson: are you going to let esteid-browser-plugin in for precise?
<tumbleweed> pitti, micahg: that does seem to be avoiding the point of the final freeze, but it sounds like that's what we have to do
<cjwatson> surely the point of the final freeze is to allow buildds to settle
<cjwatson> that was the original point, anyway :)
<pitti> cjwatson: ubuntu-defaults-zh-cn has a diff now, can you review?
<cjwatson> fine, thanks
<pitti> thanks
<pitti> I'll respin zh images once that's published
<gema>  
<gema> Close this window.
<cjwatson> Shan't.
<gema> sorry, wrong button of the mouse
<gema> xD
<gema> I was trying to open a link
<pitti> gema: has the HUD become that clever already, to parse human language? :-)
<ogra_> its probably just parsing his thoughts :)
<pitti> ("her")
<ogra_> oops
<gema> pitti: I fell from a hangout... and that was google telling me to close the window x)
<gema> ogra_: how are you girl doing? ;)
<ogra_> hahaha
 * ogra_ should indeed have guessed that gema is a typical female name, sorry :) 
<gema> haha
<gema> no worries
<jamespage> cjwatson: looking at wagon now
<cjwatson> great, thanks
<stgraber> pitti: Chinese images aren't automatically published to localized-iso.qa.ubuntu.com, you should have the required access to post them there manually or if you prefer, just ping me and I'll
<pitti> stgraber: just logged in, I don't seem to be able to disable them, or add new ones
<pitti> stgraber: ooh, I need to explicitly tick the "ubuntu-release" box in the SSO step
<pitti> stgraber: thanks, working now; I marked them for rebuild
<pitti> ubuntu-defaults-zh-cn |        0.7 |       precise | source, all
<pitti> seems I can rebuild them
 * cjwatson removes cernlib/armel and its reverse-deps, geant321, mclibs, and paw
<stgraber> pitti: yeah, SSO currently requires you to manually tick that box for some reason (maybe something I can fix in drupal-launchpad though)
<pitti> meh, http://china-images.ubuntu.com/precise/daily-live/20120424/ is still oversized by a tad
<pitti> i386 is ok now
<pitti> skaet: ^FYI
<ajmitch> Laney: ^^ for your reviewing pleasure
<Riddell> hum oem-config-kde isn't installed after an OEM install from kubuntu alternate CDs, I think that's a new issue
<cjwatson> Riddell: I respun for that last night - are you using the most current version?
<Riddell> yes but let me verify that
<ogra_> Riddell, i think ScottK filed a bug for it yesterday (at least he mentioned it here)
<cjwatson> bug 987050
<ubot2> Launchpad bug 987050 in ubiquity "No "Prepare for shipping ..." option after OEM install from D-I" [Medium,Fix committed] https://launchpad.net/bugs/987050
<cjwatson> otherwise I'd like to see the logs
<Riddell> ce95fd6842fc948244bd4b53327c8027 *precise-alternate-amd64.iso  it's yesterdays image
<Riddell> ok yeah just my brain being broken and getting the image wrong
<cjwatson> phew
<Riddell> I could take it as an insult that my brain being broken is better than the ISOs :)
<stgraber> cjwatson: bug 986806 is starting to look like a boot time race condition more than an installer bug
<ubot2> Launchpad bug 986806 in ubiquity "swap not activated after choosing 'use whole disk'" [High,Incomplete] https://launchpad.net/bugs/986806
<cjwatson> fstab/crypttab sane then?
<stgraber> yeah
<stgraber> and cryptdisk's upstart log shows "... done"
<stgraber> waiting for /var/log/boot.log now to see if maybe we can get a mountall error there
<stgraber> oh, I should also ask him to try to swapon the cryptdisk and see if it works post-boot
<skaet> thanks pitti
<jamespage> cjwatson, ^^ fix to make wagon build offline - testing in PPA
<cjwatson> you're a star
<jamespage> sorry that should have been 'tested' not 'testing' :-)
<jamespage> np
<cjwatson> I would not have got there in months
<cjwatson> accepted
<skaet> Riddell, ScottK,  http://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/Kubuntu - can a first pass of content be added by end of today please?   Also,  I extracted some of the content on upgrading, requirements, etc. from some multiple community pages - it its wrong on this page,  it may need updating elsewhere.
<Riddell> skaet: ack
<skaet> ta
 * cjwatson removes the non-building slang-slirp binaries, since there are no rdepends; source still there
<Laney> ScottK: are you going to accept asterisk?
<Laney> I guess gnome-online-accounts should be rejected now.
<Laney> and a pocket veto seems to have been applied to esteid-browser-plugin
<cjwatson> chrisccoulson seemed to think that should go in
<cjwatson> I wanted somebody who knew about it to take a decision
<cjwatson> seb128: could you look at esteid-browser-plugin in NEW in light of chrisccoulson's comments?
<Laney> asterisk got approved so please accept that
<seb128> cjwatson, that feels like a trap ;-) I will check with him, sort it out yes
<stgraber> skaet: I know you usually like to check, so here's the release announcement URL for Edubuntu 12.04: http://www.edubuntu.org/news/12.04-release
<cjwatson> kompozer may succeed eventually if I stop making stupid mistaes
<cjwatson> Laney: gnome-online-accounts is for -proposed anyway IIRC
<Laney> yes, but if it's SRU then you probably want a proper upload rather than a sync?
<cjwatson> 2^- well that wasn't a bad example of Muphry's Law
<cjwatson> Laney: I'll leave that up to pitti I think
<pitti> Laney: the sync by itself is not a problem, it's just slightly harder to track when the changelog doesn't refer to a bug
<pitti> at this point I think our options of tweaking the zh image size are limited to ubuntu-defaults-zh-cn
<pitti> I'll drop sunpinyin instead and put back zenhei
<Laney> pitti: indeed.
<phillw> hiyas, Im a bit puzzled with bug 837054 and bug 987406  I'd have expected them to affect all flavours?
<ubot2> Launchpad bug 837054 in ubuntu-geonames "Time Zone selection shows about 20 different "New York"s and doesn't autoselect my location" [Medium,Confirmed] https://launchpad.net/bugs/837054
<ubot2> Launchpad bug 987406 in ubiquity "time zone map: graphical mismatch of selected city and highlighted time zone" [Undecided,New] https://launchpad.net/bugs/987406
<stgraber> phillw: the first sounds like a server side bug with the geoname service, the second might be a bug in the custom gtk widget. Either way, neither should be RC so not really a concern at this point.
<phillw> okies, thanks :)
<pitti> cjwatson: new defaults-zh-cn is in the queue, putting back zenhei and removing sunpinyin instead (the other option given by freeflying)
<pitti> cjwatson: I guess the diff will still take a bit, as LP is presumably busy generating the LibO diff
<cjwatson> I can do the diff myself
<pitti> (it's also in ubuntu:ubuntu-defaults-zh-cn)
<cjwatson> accepted
 * pitti reviews the esteid plugin
<pitti> cheers
<ScottK> Laney: Yes.
<Laney> ScottK: Glad we squeezed that in
 * Laney will furnish ajmitch with marmite at UDS
<popey> mmmmm marmite
<phillw> are you allowed marmite in USA, I read that they won't allow the Australian Vegemite in?
<Laney> either you are or I smuggled it in last time ...
<phillw> he he.
<cjwatson> oh DAMN I test-built coq on the wrong arm*
<cjwatson> how frustrating
<ScottK> Laney: Looks like someone else got it already.
<Laney> cool
 * Laney eyes the builds
<ScottK> pitti or some other SRU person: ^^^ postfix upload would be a really good early SRU (assuming we don't respin now).
<lamont> and yeah, should have used an earlier bug number, I expect
<stgraber> Daviey: did you see: http://iso.qa.ubuntu.com/qatracker/milestones/214/builds/15999/testcases/1290/results ?
<pitti> ScottK: will review ASAP
<ScottK> pitti: Thanks.
<Daviey> stgraber: I didn't, thanks!
<stgraber> Daviey: it's linking to a closed bug, so it's probably not that specific bug, but would certainly be interesting to know what went wrong for that tester
<cjwatson> eclipse/armhf built on scheat, so Adam's given it back
<skaet> ScottK,  not spotting postfix on the pad,  could you please add it as opportunity target?
<ScottK> skaet: It's there.
<Daviey> stgraber: tumbleweed yeah that bug is beta 2 :(
<ScottK> skaet: Item 13, second on the opportunity list.
 * skaet *blinks*
<ScottK> Probably got too used to it.  It's been there since Friday since I knew it was coming.
<skaet> yup,  it had NO FIX yet beside it when I saw it, and though you were talking about something different.   Thanks.
<stgraber> Daviey: I'm going to unlink the bug number from this report as it's clearly wrong but it'd be good to have someone test MAAS on i386 ASAP to check that it's not broken for some other reason (as that report would indicate)
<pitti> postfix accepted
<ScottK> pitti: Thanks.
<ScottK> lamont: ^^^
<ScottK> skaet: I passed you note about Kubuntu release notes on to claydoh who (FYI) is doing them for Kubuntu.
<lamont> ScottK: ta
<skaet> Thanks ScottK.   :)
<jdstrand> cjwatson: if you are preparing an upload for that ciphers bug, can you also include http://cvs.openssl.org/chngview?cn=22474? I can send you a debdiff if it would be helpful
<cjwatson> jdstrand: too late
<cjwatson> it's already in the proposed queue
<jdstrand> cjwatson: do you mind if I upload the change on top of yours?
<jdstrand> cjwatson: is yours intended to be fixed before release or in SRU?
<cjwatson> SRU
<cjwatson> and no, I don't mind
<jdstrand> ok, I'll just do that then. thanks
<cjwatson> use -v so that the .changes has all changes since release, please?
<jdstrand> yep
<cjwatson> (I don't think further attempts to change this code for release are wise, given its track record)
<jdstrand> no, me either
<cjwatson> although it's unfortunate that we'll release in this state
 * cjwatson radiates hatred
<jdstrand> yeah, sorry man :(
<cjwatson> meh, not your fault ...
<jdstrand> I just know a bit of what you are going through-- openssl is 'fun' sometimes
<cjwatson> hm, I can't decipher this coq/armhf failure; I'm just going to remove it and its rdeps, so that's libaac-tactics-ocaml, libaac-tactics-ocaml-dev, libssreflect-ocaml, libssreflect-ocaml-dev, why
<cjwatson> kompozer is still test-building, but it's looking good so far, uploading
<infinity> cjwatson: Review, plox: http://paste.ubuntu.com/944079/
<stgraber> skaet: I added two new tags/comments to the UbuntuDesktop release notes so that Edubuntu can include them (as Edubuntu is based on UbuntuDesktop it makes sense to also pull these on top of the CommonInfrastructure ones)
<cjwatson> infinity: aren't there still OEM maverick builds?
<infinity> cjwatson: Oh.  Are there?
<infinity> cjwatson: I can add more cases for older builds, sure.
<cjwatson> I think so.  But otherwise LGTM.
<cjwatson> what's the openssl rejection for?
<cjwatson> micahg: FYI on bug 987615 we don't generally need to blacklist on removal any more anyway
<ubot2> Launchpad bug 987615 in sharand "Please remove sharand source and binaries from precise" [Wishlist,Confirmed] https://launchpad.net/bugs/987615
<ScottK> dkimpy is pure bug fix and the one non-trivial change has test suite coverage (which I ran before uploading)
<ScottK> Since I uploaded it, I'd appreciate a review.
<skaet> stgraber,  thats's fine.    THanks for letting me know so I don't get confused when I go in next.   :)
<ScottK> It's been awhile since I saw lack of implicit IT thumb ..
<phillw> hmm, drat bug 987764
<ubot2> Launchpad bug 987764 in debian-installer "20120423.1 Alternate PowerPC ISO image cannot resize partition" [Undecided,New] https://launchpad.net/bugs/987764
<phillw> that's a new one :(
<cjwatson> that looks like missing ext2.ko again
<cjwatson> CBW
<phillw> poor little .ko :/ Easy fix?
<cjwatson> hm, no, it's in fs-core-modules
<cjwatson> dunno, have asked for partman log so I can see what's going on
<phillw> okies, he's a good tester for ppc.
<cjwatson> (in general: that's bad but release-notable I think)
<stgraber> phillw: if a kernel rebuild fits your definition of easy fix, then yes (assuming it's indeed missing .ko)
<phillw> it is, as the lower spec ppc's we were going to suggest using the alternate image :)
<cjwatson> stgraber: it's not that, sorry for confusion
<cjwatson> well I mean it probably doesn't render the alternate images entirely broken, only resizing, and it's possible it's constrained further beyond that
<pitti> Chinese image rebuild, take II
<pitti> oh, another ssl?
<ScottK> Of course.
<ogra_> this must be the best secured ubuntu release ever :)
<ogra_> so many ssl fixes right before release
<cjwatson> they're (at best) zero-day SRUs
<Riddell> canonical unity-2d guys are wanting a patch to qt in precise-updates, am I ok to start the SRU process?
<Riddell> bug 987855
<ubot2> Launchpad bug 987855 in qt4-x11 "[SRU] Fix problem in Qt dragging when all of the window target has been shaped out for input" [Undecided,New] https://launchpad.net/bugs/987855
<ScottK> Riddell: If you're not, then a lot of people are in trouble.  I think you're just supposed to add it to the pad as an SRU candidate.
<Riddell> groovy
<Riddell> spose that'll give me something to do while I wait for these dvds to download
<pitti> at last, http://china-images.ubuntu.com/precise/daily-live/20120424.1/ is fine now
<pitti> stgraber: ^ would you mind adding that? I still seem to be unable to, I can just re-enable the image but not add a new one (or bump the version)
<pitti> skaet: ^ Chinese image not oversized any more.
<skaet> well done pitti.  :)
<skaet> thank you.  :)
<stgraber> pitti: that's weird... will add now
<stgraber> pitti: done
<pitti> stgraber: thanks
<smoser> is there a list of outstanding issues ?
<smoser> i'm looking for a reason that I should not start testing of the current cloud-images
<superm1> ^ should finally fix ftbfs on arm* (https://buildd.debian.org/status/package.php?p=xbmc&suite=experimental)
<cjwatson> ^- fixes ftbfs on powerpc
<ScottK> It's a good thing we got the third ppc builder.  PPAs have two of three now on non-trivial builds.
 * ScottK is looking after xen-api
 * ogra_ hugs superm1 
<cjwatson> http://www.ubuntu.com/getubuntu/releasenotes?os=$PROJECT&ver=12.04&lang=\${LANG}
<cjwatson> where $PROJECT is ubuntu, kubuntu, etc. depending on image, and \${LANG} is runtime-substituted with a locale code
<cjwatson> sorry for mixed syntaxes there
<cjwatson> this has been in place for at least ten releases so oI trust the web team know their weay around it already
<cjwatson> with extra typing
<superm1> ogra_: :)
<cjwatson> https://wiki.ubuntu.com/Ubiquity/ReleaseNoteshttps://wiki.ubuntu.com/Ubiquity/ReleaseNotes
<Laney> missing context?
<cjwatson> sorry, briefing Kate on how the release notes link from the installer is handled
<Laney> righto
<gema> skaet: what's up with the new server images showing up in the tracker?
<gema> skaet: do we need to worry about them?
<jibel> new server images are not installable
<skaet> Daviey, ^^^
<cjwatson> what's up with them??
<cjwatson> er with one ?
<cjwatson> gema: the reason for the respin was an incorrect CD boot menu entry
<cjwatson> due to a miscommunication between me and Daviey yesterday, I'm afraid
<cjwatson> but they shouldn't have changed anything affecting installability ...
<Daviey> jibel: what are you seing?
<jibel> amd64 failed to install i386 pass. http://paste.ubuntu.com/944248/
<cjwatson> hm, I wonder if that might've been a transient build glitch
 * ScottK suggests waiting on accepting any new uploads until armel and powerpc catch up a bit.
<gema> what would a transient build glitch be?
<cjwatson> explaining would slow me down, let me investigate first :)
<gema> cjwatson: no worries, I will ask again next week :D
<cjwatson> (besides, not sure exactlyl, let me think out loud)
<cjwatson> I often do stream-of-consciousness when investigating this kind of thing, not all of it is going to make perfect sense to anyone!=me
<gema> cjwatson: ack
<cjwatson> nothing obvious to me in the build logs
<cjwatson> hm, libatk1.0-data isn't on the CD, what's the server CD doing trying to install it
<cjwatson> jibel: can I have the entire log please?
<jibel> cjwatson, sure.
<cjwatson> think I'll need to reproduce this locally anyway though
<bdmurray> what needs to happen to get update-manager in -updates in oneiric?  it'll fix bug 873424 and a couple of others
<ubot2> Launchpad bug 873424 in update-manager "ask me later fails" [Medium,Fix committed] https://launchpad.net/bugs/873424
<cjwatson> nothing even depends on subunit in main
<cjwatson> or recommends
<cjwatson> the only recommends on it in the whole archive is samba4-testsuite
<cjwatson> jibel: briefly though, which task(s) did you select?
<jibel> http://people.canonical.com/~j-lallement/precise-server-amd64_lamp_d-i-syslog.log.gz
<jibel> cjwatson, I think it was caused by a network glitch and additional packages used for testing failed to install
<cjwatson> Apr 24 15:16:24 in-target: debconf (developer): starting /usr/bin/debconf-apt-progress --from 800 --to 850 --logstderr -- apt-get -q -y install -- openssh-server python-couchdb subunit python-subunit python-junitxml python-paramiko
<cjwatson> ^- little details it would be nice if you told me in advance
<cjwatson> Apr 24 15:00:00 in-target: Err http://us.archive.ubuntu.com precise Release.gpg
<cjwatson> Apr 24 15:00:00 in-target:   Connection failed
<cjwatson> not an image problem
<stgraber> probably caused by the current archive.u.c slowness
<cjwatson> Apr 24 15:14:24 in-target: W: Failed to fetch http://us.archive.ubuntu.com/ubuntu/dists/precise/Release.gpg  Connection failed
<cjwatson> Apr 24 15:14:24 in-target:
<ev> bug 987402 - *appears* to be a longstanding bug. If you put ubuntu on a usb disk, select the cd boot helper option (copy the ISO to C:\ and write into the NT bootloader, to avoid having to hit F12 on boot) from the windows autorun menu, it will fail.
<ev> This is because it checks to make sure the iso (or in this case the entire external disk) is under a certain size
<cjwatson> Apr 24 15:14:24 in-target: W: Failed to fetch http://us.archive.ubuntu.com/ubuntu/dists/precise-updates/Release.gpg  Connection failed
<ubot2> Launchpad bug 987402 in wubi "Exception: Could not retrieve the required installation files" [Undecided,New] https://launchpad.net/bugs/987402
<cjwatson> Apr 24 15:14:24 in-target:
<cjwatson> Apr 24 15:14:24 in-target: E: Some index files failed to download. They have been ignored, or old ones used instead.
<cjwatson> Apr 24 15:14:24 in-target: W: Failed to fetch http://us.archive.ubuntu.com/ubuntu/dists/precise-backports/Release.gpg  Connection failed
<cjwatson> Apr 24 15:14:24 in-target:
<stgraber> (a few acrhive mirrors are overloaded, either not responding or returning at extremely low speed, around 600B/s here when I last tried)
 * ogra_ heard that in -motu before today
<ogra_> for archive.u.c actually
<stgraber> yeah, it was also mentioned in #canonical-sysadmin and #is
<jibel> re-ran server amd64 and it passed.
<Daviey> jibel: we fixed it!
<cjwatson> :-)
<ogra_> heh
<Daviey> jibel: JUST DON'T RUN IT AGAIN!
<hggdh> LOL
<jibel> Daviey, you should release note it: "Install server but don't run it" ;)
<Daviey> jibel: or make sure you have an adequate network before trying to net install :)
 * cjwatson removes ruby-hdfeos5/i386, since it's due to an old hdf5 and we're hardly going to merge that across several upstream versions before release
<gema> Daviey: maybe the install should fail graceful when the network is not good enough... ehem...
<gema> and say so to the user
<Daviey> gema: it does.. :)
<ev> right, new wubi in place, awaiting a signed binary in #is
<gema> Daviey: then why did jibel thought the install had failed? I regard him as an experience person !
<gema> experienced
<Daviey> gema: It's a preseeded install...
<ev> I've tested that it basically works, but it would be good to get someone with a windows box and USB key to give the boot helper option a go
<Daviey> you won't see the user UI in preseed, right?
<gema> Daviey: no, I thought it was a manual installation!
<gema> Daviey: ack :D
<Daviey> gema: Oh no, trying to get manual installs is like pushing water uphill, no? :)
<ScottK> jibel: Do you know of someone that can do Wubi testing for Kubuntu?  We've got our usual lack of people that run Windows.
<gema> Daviey: it is
<SpamapS> Who maintains this report http://reports.qa.ubuntu.com/reports/ubuntu-server/release-bugs.html ? Its showing bug 928990 which is marked Won't Fix for precise.
<ubot2> Launchpad bug 928990 in cloud-init "fsck / dirty filesystem on instance is death" [High,Triaged] https://launchpad.net/bugs/928990
<Daviey> SpamapS: mostly myself.
<jibel> balloons, ^ can you help finding a tester for Wubi/kubuntu
<balloons> wubi and kubuntu?
<balloons> interesting, and yea
<Laney> kwubuntu
<Daviey> SpamapS: will be gone on next cron.
<balloons> I'll send off some emails now
<balloons> anything in particular we think will be an issue or no?
<ScottK> balloons: Just need the test cases run.
<ScottK> infinity: Is there anything we can do about armel buildd capacity?  I'm now nervous.
<infinity> ScottK: We can wiggle things around a bit.
<infinity> ScottK: And get some reboots and tidies.
<cjwatson> doko,jamespage: do either of you have any idea what's going on with the eclipse/armhf build failure?
<cjwatson> doko,jamespage: it builds on scheat, albeit without parallelisation (I'm trying the latter now)
<ev> signed wubi is in place
<jamespage> cjwatson, looking now
<cnd> I have a freeze exception request for bug 987548
<ubot2> Launchpad bug 987548 in utouch-qml "Fails to build against utouch-geis 2.2.6 and later" [High,Fix released] https://launchpad.net/bugs/987548
<cnd> it's an unseeded package with no reverse dependencies
<cnd> since we're close to the release, I thought I'd ask here to be sure it is seen in time
<tumbleweed> we are past unseeded final freeze... Is it SRUable?
<ScottK> I think it is.
<cnd> yeah, it is
<ScottK> SRU is better.
<cnd> is it possible to SRU a new microrelease upstream?
<cnd> or do I need to make distro patches out of it?
<ScottK> Is that the only change in the microrelease?
<cnd> yeah
<cnd> I see the sru process says it's possible
<ScottK> Should be fine then.
<doko> cjwatson, jamespage: no idea, away now, will be back around midnight
<cnd> I'm just wondering about versioniing
<tumbleweed> cnd: it's more about the complexity of the diff than the version numbers
<cnd> for example, usually SRUs are <release version>.<sru number>
<cnd> I guess it's more of an issue right now since we don't have Q open yet
<ScottK> At this point it'll get copied forward into Q, so just use a regular version number.
<cnd> ok
<slangasek> I thought last cycle we decided we weren't doing any copies forward of SRUs anymore
<slangasek> because we wanted to make sure we had clean builds with the current toolchain
<ScottK> We did?
<ScottK> OK.
<slangasek> pitti probably remembers the details better than I
 * ScottK <-- Not on the SRU team, so don't listen to him.
<cnd> slangasek, wouldn't we still be doing source copies?
<slangasek> cnd: no, doesn't work that way
<cjwatson> you can't have two builds of the same source package published in the same pool
<cjwatson> filename clash
<micahg> slangasek: I thought the decision was once the next release is open, one has to upload there (but it's not open yet)
<micahg> cjwatson: was there a reason you didn't do seamonkey with the rest of the removals I requested?
<cjwatson> micahg: just didn't get to it yet
<micahg> cjwatson: ah, ok, thanks
<pitti> slangasek: AFAIR (and IMHO) we did not want to overly extend the forward copying multiple weeks into the release
<pitti> but I think forward-copying until quantal opens and gets a new toolchain is the right thing
<pitti> ScottK: ^
<slangasek> micahg, pitti: right, ok
<cjwatson> it's not important for them to be in quantal immediately
<cjwatson> squeak-vm LGTM and is required for outdate resolution
<ScottK> If it's not a long build, then let's go for it.
<cjwatson> 7m on amd64
<ScottK> I don't have any insight into how long the private builds will be blocking stuff.
<ScottK> I'd say go for it.  I guess we (meaning someone other than me) can shove hardware at armel if really needed.
<ScottK> I guess now we can see when it lands.
<cjwatson> mm, as infinity says, I think it's mostly a matter of clearing failures
<cjwatson> infinity: were you planning to do that?
<iamfuzz> ScottK, ping?
<ScottK> iamfuzz: pong.
<iamfuzz> ScottK, you're probably going to yell at me... but
 * iamfuzz braces himself
<cjwatson> projectm/armel is a real hassle.  audacious-plugins build-deps on it, and audacious depends on that, and half the A/V world seems to depend on audacious, so removing projectm/armel involves stripping out a huge pile of packages which I'm kind of loath to do
<iamfuzz> ScottK, this final freeze snuck up on me and I need to have a package removed
<ScottK> Removed we can still do.
<iamfuzz> cool
<cjwatson> but it's a GL bug and argh
<ScottK> Please file a removal bug and then ping again.
 * pitti waves good night
<iamfuzz> ScottK, I didn't quite make the deadline for the fixes I needed for gwt
<ScottK> But do it quick.
<iamfuzz> will do
<cjwatson> I wonder if I can strip out some bits
<cjwatson> hmm, audacious-plugins doesn't actually have any runtime dependency on projectm though
<cjwatson> it might be simpler to strip that build-dep - I'll test that
<cjwatson> but audacious-plugins is seeded in ubuntustudio
<cjwatson> conundrum
<iamfuzz> ScottK, https://bugs.launchpad.net/ubuntu/+source/gwt/+bug/987939
<ubot2> Launchpad bug 987939 in gwt "Please remove GWT from Precise" [Undecided,New]
<ScottK> iamfuzz: So it's worse than it was in previous releases?  It's not a new package.
<iamfuzz> ScottK, yes, the JDT changes in Eclipse have broken most of its functionality
<ScottK> OK.
<Daviey> gwt is an awful package in Ubuntu
<iamfuzz> ScottK, We're fixing it, but it's just a bit too late obviously.  Going to try to get it into partner
<Daviey> it's a bastardised version of Ubuntu, with just a subset of it's features.
<iamfuzz> Daviey, yes, yes it is :-)
<iamfuzz> but not for long!
<Daviey> it's a suck it and see if it builds, normally :)
<Daviey> remove 10 lines of code, still fails, remove another 10 etc.
<ScottK> Would a "C" archive admin please look at bug 987939?
<ubot2> Launchpad bug 987939 in gwt "Please remove GWT from Precise" [Undecided,New] https://launchpad.net/bugs/987939
<ScottK> infinity: ^^^ ?
<iamfuzz> Daviey, we dropped some money to have a little company called Credativ to work on it
<cjwatson> looking
<ScottK> Thanks.
<iamfuzz> they've fixed the JDT issues but now some other BS has cropped up
<ScottK> Package is apparently ~totally broken.
<cjwatson> done
<Daviey> (it was only packaged as a subset to support eucalytpus.. if eucalyptus have no need for it, i'm happy to support a dropping of it :)
<iamfuzz> yep, luckily noone but us depends on it at a package level, so Partner it is
<ScottK> iamfuzz: Backports works too.
<iamfuzz> true, but Euca is destined for Partner, so likely the best place for Precise
<ScottK> Ah.  Didn't know that.
<cjwatson> I have an idea for projectm
<cjwatson> audacious-plugins' unsatisfied build-dep only *really* matters because we can't do security updates
<cjwatson> on armel
<cjwatson> so why not remove projectm/armel since it's doomed, but SRU audacious-plugins to drop the build-dep?
<micahg> cjwatson: what do you mean we can't do security updates on armel?
<cjwatson> because projectm/armel is f***ed and unrescueable
<cjwatson> and audacious-plugins build-deps on libprojectm-dev, but only for the sake of building a plugin that it no longer actually includes
<cjwatson> "we can't do security updates on armel" => "if I remove projectm/armel, we won't be able to do updates of audacious-plugins that build on armel"
<micahg> ah, ok, that makes sense
<slangasek> so when did LP change to no longer sending me email about new private bugs that I have access to read through the web UI?
<ScottK> cjwatson: ^^^ audacious-plugins upload is an SRU since it's seeded, right?
<micahg> slangasek: are you subscribed in some way to it?
<ogasawara> as previously discussed, I have our day-0 kernel ready for upload to precise-proposed today.  Just want to get confirmation it's ok to do so at this time.
<slangasek> micahg: I'm subscribed to bugs for plymouth, and I'm not receiving notifications of new private bugs
<slangasek> ogasawara: it's certainly ok to upload; I don't know if it will be accepted immediately, we probably need to check queue lengths before doing so
<ogasawara> slangasek: ack
<ogasawara> just for reference, I've posted a summary of the bugs being resolved in the day-0 upload -> http://pastebin.ubuntu.com/944474/
<fossfreedom> just want to throw out a question - will the upgrade take care of removing xorg.conf and those with manually install nvidia/ati graphics - or should the recommendation be to swap back to opensource drivers before the upgrade?
<utlemming> stgraber: Can I get http://cloud-images.ubuntu.com/precise/20120424/ added to the tracker?
<stgraber> utlemming: yep, doing it now
<utlemming> stgraber: thank you kindly
<stgraber> yay for flood protection :)
<stgraber> utlemming: done
<utlemming> stgraber: perfect
<ev> so I think we may have a problem
<ev> can someone confirm that the "report this problem" checkbox isn't appearing in apport?
<slangasek> oh man
<ev> and that they aren't getting .upload files
<slangasek> it appears for me
<ev> interesting
 * ev digs deeper
<slangasek> but I have apport hard-enabled, does that make the difference here?
<slangasek> I'm also getting .upload
<ev> I think it's my system
<ev> just confirming
<slangasek> fossfreedom: I haven't heard any complaints from users about upgrades breaking of binary drivers are in use; why do you ask?
<highvoltage> stgraber: what's the status on 64bit macs? we added a note in our installer page for 11.10 advising that users should install the 32bit version on macs because of the efi issues
<fossfreedom> ... on askubuntu we are going to pin a release update answer - just want to get this answer correct.  thanks
<stgraber> highvoltage: we keep the note for 12.04, AFAIK we still need +mac builds for EFI and Edubuntu doesn't have one (takes quite a bit of space on cdimage for it and we don't have that many users of it that I know)
<highvoltage> stgraber: ok
<utlemming> stgraber: can we promote the EC2 builds to the Precise Final?
<slangasek> fossfreedom: so the behavior I would expect here is that the binary drivers are upgraded as part of the upgrade and there's no reason to worry about xorg.conf one way or the other
<stgraber> utlemming: are they tested already?
<fossfreedom> thanks - will update the answer accordingly.
<stgraber> utlemming: we move them to Precise Final once fully tested and ready for release
<utlemming> stgraber: yes, there are tested
<utlemming> they were tested this morning, Monday and Friday
 * ScottK votes someone shoot the hadoop-ubuntu/testing hadoop builds on armel in the head.
 * micahg wonders why that's a native PPA
<stgraber> utlemming: ok, moving them then
<ScottK> You mean other than Canonical people abusing resources because it's easy for them to get them?
<ev> slangasek: heh, I had whoopsie disabled.
<ev> false alarm
<slangasek> ;)
<ScottK> cjwatson or slangasek: AIUI the horizon upload in queue for -release is needed to clear up c-m.  Do we need it in -release or can we ignore it and fix things in -proposed/updates?
<highvoltage> stgraber: I added it to known-issues, does it look ok? http://edubuntu.org/news/12.04-release
<stgraber> utlemming, arosales: Please have them signed off on https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest now that they are marked as ready
 * arosales taking a look
<stgraber> highvoltage: not technically a firmware bug, but yeah, that'll do the trick :)
<ScottK> Nice.  Zero builds in progress for the release on armel now because other things are more important.
<arosales> stgraber: Looks like I am missing something. For Ubuntu Cloud images (amd64, i386) we have the Releaes Manifest signed off as of 2012-02-28. Is there another action I need to take?
<slangasek> stgraber: do you have access to kill off these wayward ppa builds ScottK is referencing?
<stgraber> slangasek: I'll have a look
<stgraber> arosales: you need testing sign-off (last column)
<stgraber> arosales: utlemming says they're all tested and good to go, so the manifest should reflect that
<arosales> stgraber: ah ok, I'll update now.
<arosales> stgraber: thanks for the info and ping.
<ScottK> One of them appears to have finished on it's own.
<stgraber> slangasek: no, the only thing I can do is switch them between manual and auto mode at the moment but not kill these builds
<highvoltage> stgraber: "On 64bit Apple systems, the 32bit edition is recommended. The 64bit version won't boot on these systems due to incompatibilities with Apple firmware."
<ScottK> slangasek: Any thoughts on horizon in -release or -updates?
<stgraber> highvoltage: sounds good
<highvoltage> stgraber: is that more accurate? At least we sound slightly less anti-apple like that :)
<slangasek> ScottK: still digging; I think it should really be in -release, but haven't looked if the existing package is suitable for that
<ScottK> OK
<stgraber> highvoltage: yeah, it's more accurate. The reason why amd64 doesn't work on Mac is because of some slight difference in their EFI requiring a different grub/efi install.
<stgraber> highvoltage: it should be possible to produce a media working on both but there wasn't time to do it in precise, hopefully for quantal
<slangasek> pitti: I'm pointing a spotlight on bug #986928; I guess we won't get a fix into release, and it's an upgrade-only issue, but it seems rather crucial to get a fix ASAP
<ubot2> Launchpad bug 986928 in zeitgeist "zeitgeist-daemon crashes with "zeitgeist-daemon.vala:473: Unable to upgrade from schema version 3"" [Critical,Triaged] https://launchpad.net/bugs/986928
<highvoltage> stgraber: ok
<slangasek> ScottK: the horizon in unapproved is needed in order to drop the build-depends on python-cherrypy3; if we don't get this into -release then we at least have to get it into -security, so I'd rather we just get it into release
<slangasek> and it's an arch: all build
<ScottK> The I say let's go for it.
<slangasek> accepted
<slangasek> (also checked that it's not seeded on the server CD)
<ScottK> Barring disaster, I think that's it for precise -release.
<micahg> slangasek: quick question about an SRU I'd like to go to lucid-updates, we ended up modifying the menu entry for Thunderbird from 'Mozilla Thunderbird Mail/News' to just 'Thunderbird Mail', can I go ahead and push this out, or does this need to be reverted (it comes with new translations as well)
<slangasek> micahg: that doesn't sound like an SRU-appropriate change on the face of it; is it related to some bug?
<micahg> slangasek: no, just keeping the various releases in sync for easy maintenance
<slangasek> I would rather see it reverted
<micahg> chrisccoulson: did you discuss the above with anyone already  ^^
<chrisccoulson> well, it's just a translation update really. and compared to the other changes in the update, it's less than a drop i the ocean
<chrisccoulson> perhaps we should revert the hundreds of other string changes ;)
<chrisccoulson> but, seriously, the time to have this conversation was 6 weeks ago
<slangasek> it's a user-visible change that would impact sorting, among other things...
<micahg> chrisccoulson: the only reason why I see this one as different would be it's the menu location, I meant to bring it up last week
<micahg> chrisccoulson: I'd suggest just respinning the 12 update again and I'll just push that out instead of 11 tomorrow (and bite the bullet if I missed something)
<chrisccoulson> seriously? respin to change a single string, and make my life even harder for the next merge?
<micahg> chrisccoulson: not my call, I'm fine with it if the SRU team approves :)
<chrisccoulson> feel free to do that, as long as you do the merges next time :)
<chrisccoulson> it's already bad enough trying to merge in changes that we need because of all the cherry-picking
<chrisccoulson> and across 24 packaging branches
<slangasek> I am unlikely to block the SRU over this; OTOH I'm also unlikely to be the member of the SRU team reviewing it and letting it in
<slangasek> I just think it's unfortunate that an SRU will rearrange users' desktop menus
<micahg> slangasek: it's one of those in -proposed for extended testing in preparation for a security update things
<micahg> so, the other changes (upstream) have an exception to update every 6 weeks
<micahg> or as needed
<slangasek> there's also a good chance that this is not the most confusing change we've ever made in an SRU to one of these packages
<seb128> micahg, how come that string change issue was not raised early than *just* before the time the release should go out?
<seb128> seems like on a 6 weeks period that should have been raised earlier enough to be discussed without rush
<seb128> which is not the case there...
<micahg> seb128: I forgot and was reminded when I did my final acceptance testing, no one complained about it in -proposed
<seb128> :--
<seb128> :-(
<seb128> rather
<seb128> was that an user complain?
<micahg> nope
<micahg> just me noticing
<seb128> ok, so "was reminded" is by yourself ;-)
<micahg> right :)
<seb128> well I've no strong opinion, but if that's an issue it's a shame that it was forgotten and just came back at the time the update is about to go out
<seb128> but it seems like it's not worth delaying the update imho
<micahg> there's enough time to revert if need be, alternatively, I can push out 11 as is and if someone screams respin 12 with the revert
<mdeslaur> seriously, people are going from thunderbird 3 to thunderbird 11, the least of worries is the slight wording change in the desktop file
<mdeslaur> the whole app is changing!
<seb128> mdeslaur, yeah, I agree with that
<ScottK> It looks like Bug #987613  and Bug #987713 are valid removal bugs if there's a "C" archive admin who has  minute?
<ubot2> Launchpad bug 987613 in vloopback "Please remove vloopback source and binaries from oneiric" [Wishlist,Confirmed] https://launchpad.net/bugs/987613
<ubot2> Launchpad bug 987713 in seamonkey "Please remove seamonkey source and binaries from precise" [Wishlist,Confirmed] https://launchpad.net/bugs/987713
<Riddell> stgraber: you tested kubuntu upgrade 3 times?  whatever have we done to deserve that honour?
<Riddell> you must have some automated way of doing that?
<stgraber> Riddell: yeah, these are daily automated upgrade testing
<Riddell> stgraber: how does that setup work?
<stgraber> Riddell: I have a cron running on one of my server that uses the AutoUpgradeTester code from update-manager
<stgraber> Riddell: it's the exact same setup Canonical used to run for all flavours (results used to be on mvo's people.u.c page IIRC)
<stgraber> Riddell: so it essentially runs the equivalent of do-release-upgrade -d in a fresh kvm VM, runs a bunch of test post-upgrade and report failures if it detects a .crash or any other test failure
<Riddell> stgraber: cool
<jdstrand> are there any problems with my pushing a universe package to precise-security now as opposed to thursday?
<jdstrand> I'm assuming not, but thought I would check
<ScottK> ^^^ I emailed the uploader and the author to explain it was too late for -release.
<jdstrand> hrmm, our unembargo tool was not smart and it went to precise-security (our other tools skip the dev release)
<jdstrand> well if openssl098/universe to precise-security is a problem, holler
<slangasek> should be fine
<stgraber> slangasek: leaving now, if you have any other builds that are ready, just pm me the names and version (just to be safe) and I'll move them first thing tomorrow
<cjwatson> ScottK: audacious-plugins is intended for SRU, yes
<cjwatson> ScottK: think I explained it a few lines above that
<balloons> Riddell, ScottK wubi kubuntu testing went well
<balloons> no issues
<skaet> :)  thanks balloons
<balloons> err.. wait.. :-) incoming message ;-)
<balloons> is wubi amd64 only? one person is reporting wubi is always downloading the amd64 image
<cjwatson> currently, wubi just goes off the capabilities of the CPU
<slangasek> there's a single wubi image, and it has to decide somehow which architecture you want
<cjwatson> there's a bug about that
 * slangasek nods
<cjwatson> so on a 64-bit system, it'll always choose amd64, yes
<balloons> ahh, so in order to test the 386 upgrade you HAVE to have 386 only hardware eh
<slangasek> or a 32-bit VM
<cjwatson> well, for upgrade, you could do an install off the wubi that used to be on the CD
<balloons> gotcha.. thanks.. Additionally, 11.10 isn't always installing so cleanly, but we're ignoring that :-)
<cjwatson> the CD was only made non-Wubi-capable in itself in precise
<balloons> yes, I know that.. I believe they are using the old exe's for upgrade testing.. tho some may have used the old cd
<balloons> Riddell, ScottK so I have a couple more testers yet to report, probably will hear back tonight/tomorrow on them
<cjwatson> seriously?  new xbmc *introduced* an outdate?
<cjwatson> hm, this looks like altivec damage to me, I think I'll cheat *cough*
<cjwatson> so I think remaining for outdate_all are pending builds, clang, and eclipse
<ScottK> balloons: OK.  We still need the wubi testing.
<balloons> ScottK, what do you mean?
<balloons> you need more? or ?
<ScottK> balloons: Got two results for amd64 and none for i386.  Need the i386 one tested.
<ScottK> So progress, but yes, more.
<knome> if somebody could do wubi testing for xubuntu too, we'd appreciate it ;)
<balloons> ScottK, right.. but see above.. the i386 is hard to test
<balloons> at least on real hardware
<knome> i don't know when that's been done the last time, seriously
<balloons> it's pretty much impossible tak
<cjwatson> oh, here
 * cjwatson finds a force option
<balloons> if we had an override or something to force i386 it would help alot.. skaet is right we could do vm's, but that's silly
<cjwatson> wubi --32bit
<cjwatson> ./src/wubi/application.py:257:        parser.add_option("--32bit", action="store_true", dest="force_i386", help="Force installation of 32 bit version")
<balloons> cjwatson, rofl ^^
<ScottK> I'd say take the i386 ISO and do whatever the wubi test case says to do.
<cjwatson> go forth and test :-)
<balloons> lol
<balloons> i'll ping back the testers.. probably won't happen till tomorrow at this hour.. but ;-)
<balloons> thanks
<cjwatson> np, should've noticed earlier
<infinity> cjwatson: New review: http://paste.ubuntu.com/944886/
 * cjwatson line-by-lines to make sure
<cjwatson> LGTM
<ScottK> jibel: I see you did a bunch of Ubuntu amd64+mac tests.  Would you be able to run through some of the Kubuntu ones as well.  The tester we had over the weekend seems to have gotten distracted.
#ubuntu-release 2012-04-25
<micahg> ok, a few more removals files
<micahg> *filed
<ScottK> slangasek: Could you take another shot at removals (if you haven't in the last 90 miuntes or so)?
<skaet> ScottK or RIddell - any problem with me removing powerpc from the Kubuntu image set?
<ScottK> skaet: Why?  They are being tested?
 * skaet not seeing evidence of being tested 
<skaet> ScottK,  just trying to clean the tracker up to what we'll actually be trying to ship.
<ScottK> I'm pretty sure we'll ship the powerpc desktop image and we've got a shot at the alternate as the guy doing the testing has promised to do more.
<ScottK> I've also got promises for amd64+mac testing too.
<skaet> https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest
<skaet> does not have it listed as an architecture for this release.
<skaet> re: amd64+mac,  that's fine if its tested.
<ScottK> Which?  powerpc?  that's because we didn't have a tester until this week.
<ScottK> So far the desktop image looks good.
<skaet> Please encourage logging of some of the powerpc results to the iso tracker then asap.   They're sitting at 0, and we're going to need to figure out if viable or not tomorrow.
<ScottK> Not for the desktop image.
<ScottK> http://iso.qa.ubuntu.com/qatracker/milestones/214/builds/15943/testcases
 * skaet sees some now after hitting refresh.
<ogasawara> skaet: just fyi, I'd uploaded the day-0 kernel earlier today.  It's sitting in the queue awaiting approval.  I understand if there's more pressing packages needing approval first, but just wanted you to be aware.
<skaet> ogasawara,  Thanks for letting me know.  :)
<ogasawara> skaet: I also posted a quick summary of the bugs being fixed -> http://pastebin.ubuntu.com/944474/
<skaet> Thanks.  :)
<skaet> Are the release notes for linux portion pretty much done from your perspective?
 * skaet thinks so, but checking
<skaet> ogasawara, ^
<ogasawara> skaet: for the most part yes, but I'll do another pass in the morning to be sure I've not left anything out.  I also updated the known issues section
<skaet> coolio.   That will suit well.
<skaet> (and thank you for the known issues,  spotted them earlier)
<astraljava> What is the policy re: Wubi, when apparently no one in the Xubuntu community has Windows, so we might not get that test case covered.
<pitti> slangasek: #986928> noted, will look into it
<slangasek> pitti: we really ought to have the apt SRU in oneiric-updates before release; we only have 1 of 3 bugs verified so far, but it's the one that has the largest impact on oneiric upgrades AFAICS.  Do you think that's good enough to publish?
<pitti> let me look at the bugs
<slangasek> or should we try to get an autotestupgrade run for all the oneiric->precise upgrades using the -proposed apt?
<pitti> ah, bug 850264
<ubot2> Launchpad bug 850264 in apt "given a foreign architecture of i386 on amd64 machine, and an outdated libc, apt tries to remove libc-bin" [High,Fix committed] https://launchpad.net/bugs/850264
<pitti> I wonder if jibel did a full upgrade test with that version from -proposed
<pitti> if so, I'm happy
<pitti> jibel: ^
<pitti> as the other tests also apply to oneiric->precise dist-upgrades, above test should at least provide regression testing for the other two bugs as well
<skaet> slangasek,  up late...
<skaet> good morning pitti
<slangasek> a bit
<pitti> hey skaet
<skaet> seeing the backscroll on the apt SRU - would be very good if possible.
<micahg> pitti: please copy lightning-extension, enigmail, and thunderbird from natty-proposed to natty-updates only
<pitti> skaet: yes, waiting on jibel to confirm that he used it for a complete dist-upgrade test, and will move then
<skaet> slangasek,  any concerns show up on the radar, beyond the server respin?
<pitti> micahg: ok, so NOT -security? doing
<micahg> pitti: correct
<skaet> pitti,  gotcha.   sounds good.
<slangasek> skaet: nope, all quiet overnight
<pitti> micahg: done
<micahg> pitti: thanks
<pitti> micahg: one of these days you should ask for ~ubuntu-archive permissions :)
<slangasek> ScottK: hmm, what was the issue with removals?
<pitti> not that I mind doing the copying for you, I just don't want to become this a bottleneck
<pitti> "this to become a", argh morning grammar
<skaet> astraljava,  work with balloons to see if there is someone else in the community with windows, who might be willing to give it a try?   The mandatory test cases should be revisited early next cycle, to ensure they still all make sense with the goals of the individual products...
<SpamapS> pitti: one of these days I should get full training on AA status too :)
<skaet> slangasek,  quiet = good right now.  ;)
<skaet> thanks
<pitti> SpamapS: +1
<skaet> SpamapS:  +1 (from me too)
<astraljava> skaet: Alright, will do, thanks!
<jibel> pitti, I did a manual verification because there is no profile that correspond to the test case but I can run the autoupgradetest with the package from oneiric-proposed for regression testing.
<jibel> doing it now.
<pitti> jibel: nice, thanks a lot!
 * skaet --> food then office,  back in a bit.
<Riddell> morning
<pitti> hey Riddell
<Riddell> are we nearly there yet?
<pitti> oh no, you just killed another kitten!
<stgraber> good morning
<pitti> bonjour stgraber
<skaet> Daviey, pitti - did the server images get respun, or that's still pending.   Can't tell from the pad.
<skaet> either of you know?
<skaet> (ie.  are we waiting on an upload from Daviey or has it happened? )
<skaet> :)
<pitti> last respin of server was yesterday around 13:30 UTC
<skaet> pitti,  ok,  looks like we're waiting for an upload from Daviey then,  otherwise and ok from QA that they can test the new version.   Otherwise we'll go with what we have.
<pitti> I believe that's related to the MAAS string change that we discussed on Monday
<pitti> that cjwatson did/was going to do
<skaet> yes,  that's it.  Low risk.
 * pitti checks changelogs
<skaet> pitti, yes we discussed it yesterday,  just not sure whether something had happened overnight,  and sounds like not then.
<pitti> skaet: right, still mining changelogs
<pitti> skaet: https://launchpad.net/ubuntu/+source/gfxboot-theme-ubuntu/0.13.2
<pitti> that was the relevant change I think, updating pad
<skaet> thanks pitti
<pitti> skaet: so I'm fairly sure that's in now
<pitti> on the current server daily
<pitti> Daviey: ^ triple-check?
<pitti> skaet: seems you set the release team sync meetings to "weekly", I guess they only apply for this week?
<skaet> pitti,  yeah,  only this week.
<pitti> skaet: ok; seems I can't edit it to not be repeated, you need to do that apparently
 * skaet doing
<skaet> pitti,  cleaned up.   (hopefully,  let me know if you still see)
<pitti> skaet: looks fine now, thanks!
<skaet> thanks for flagging
<cjwatson> pitti,skaet: the relevant change was actually in debian-cd (gfxboot-theme-ubuntu was the day before), but in any case, it got done and respun
<skaet> cjwatson,  ok,  so moving it off the pad then.
<Daviey> skaet: yes, respin was yesterday..
<Daviey> And it's been validated
<cjwatson> eclipse/armhf failed for me in my latest build attempt on scheat, with no other changes; so I infer that it may be intermittent and I'm going to keep throwing it at the builder
<skaet> Thanks Daviey.  :)
<skaet> cjwatson, ack.
<jibel> skaet, it's confusing to have 2 milestones opened on the tracker. do you plan to merge pre and final ?
<stgraber> I'm doing a few edits of the release notes, let me know if you need me to release the lock
<skaet> jibel,  we're moving them from pre to final as the teams sign off on them for the release.
<skaet> so problem will resolve shortly.  ;)
<skaet> Additional test results can still be added to final, but emphasis should be on the pre ones.
<jibel> skaet, ok, tester can continue submitting results to pre-release then ?
<jibel> *testers even
<stgraber> jibel: images in Precise Pre-release are the priority but once they're moved to Precise Final they can still receive test results
<skaet> :)
<stgraber> skaet: for some reason I skipped that last sentence of yours when reading scrollback ;)
<skaet> :)  no worries.
<stgraber> cjwatson,pitti,skaet: Looking at system requirements, should we say something about low-memory systems installing the 64bit image? basically recommending at least 512MB for 64bit installs
<pitti> stgraber: did anyone actually try that on 512 MB? it might technically work, but certainly not a ver good experience?
<pitti> was that tried without swap?
<skaet> stgraber,  there's a spot in the desktop release notes for system requirements,  that's probably best place to add it
<stgraber> pitti: last I tried, "Install Ubuntu" works on 512MB as long as you have a swap in your partitioning scheme, if you don't, it fails
<pitti> stgraber: the live session uses existing swap partitions?
<stgraber> pitti: the live session doesn't, but ubiquity enables the swap partition as soon as it's created
<pitti> ah, I see
<stgraber> skaet: ok. I'll mention that while the bare minimum for 32bit is 384MB, 64bit should be at least 512MB
<cjwatson> bare minimum, but it does fail in some cases
<cjwatson> (512MB for amd64)
 * skaet nods
<stgraber> skaet: any reason why the lid issue on Unibody Macbook is only listed for UbuntuDesktop? I'd think it'd affect all flavours as it's a kernel/X problem
<Daviey> pitti: Could you promote horizon (bug 914164), not shipped on ISO.. please?
<ubot2> Launchpad bug 914164 in horizon "[MIR] horizon" [High,In progress] https://launchpad.net/bugs/914164
<skaet> stgraber,  just where it got placed likely.   feel free to move it.
<stgraber> skaet: ok
<Daviey> stgraber: I suspect it doesn't impact server flavour strongly.
<stgraber> Daviey: indeed, though we don't have CommonInfrastructureDesktop...
<Daviey> :)..
<Daviey> skaet: Working on server release notes now.
<pitti> Daviey: at it
<Daviey> pitti: thanks
<stgraber> Daviey: and the current list of kernel bugs on CommonInfrastructure already includes some mentions of touchpads, so I guess it won't hurt to have the specifics there too
<skaet> thanks Daviey,  arosales has been adding last night too.   :)
<Daviey> superduper
<pitti> Daviey: done; initially I promoted all binaries, but demoted back the ones not mentinoed on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<pitti> so after next publisher, that shoudl ideally be empty
<Daviey> pitti: openstack-dashboard was promoted?
<pitti> Daviey: no, c-m doesn't ask for it
<pitti> if you want it as well, you need to seed it
<Daviey> curses, i'll fix the seed.
<pitti> Daviey: ah, so perhaps my intial "promote all binaries" was right after all :)
<Daviey> pitti: yeah, it was right :(
<pitti> Daviey: so yes, please fix the seeds, and we'll check the binary c-m after the next publisher
<Daviey> pitti: pushed
<rickspencer3> hey skaet, sorry to sound dense, but I don't think I have the correct link for hte ISO tracker
<cjwatson> http://iso.qa.ubuntu.com/qatracker/milestones/214/builds
<jamespage> cjwatson, I'm not getting anywhere with the eclipse failure on armhf - can't reproduce locally :-(
<stgraber> skaet: http://www.edubuntu.org/news/12.04-release
<cjwatson> jamespage: 09:22 <cjwatson> eclipse/armhf failed for me in my latest build attempt on scheat, with no other changes; so I infer that it may be intermittent and I'm going to keep throwing it at the builder
<cjwatson> jamespage: you can find the hs_err_*.log or whatever it's called in my homedir on scheat
<jamespage> cjwatson, ack - I'll take a look
<skaet> thanks cjwatson.  :)
<skaet> rickspencer3, ok now?
<rickspencer3> skaet, yeah, I got the link, thanks
<ogra_> hmm, i thought the QA team does the oamp4 netinst image tests ... i wonder why there is nothing logged on  the tracker
<ogra_> *omap4
<pitti> skaet, cjwatson: FTR, doing pre-publishing now
<pitti> hm, it's a bit confusing to have two milestones for that
<pitti> seems that publish-image-set.py crashes, looking/fixing
<pitti> skaet, stgraber: I think it would be cleaner to move ubuntu (and server) to "Precise Final" in the tracker now, before pre-publishing; WDYT?
<pitti> I can also fix publish-image-set to publish from "Pre-release", but conceptually that sounds a bit bad
<cjwatson> pre-publishing is kind of not final
<cjwatson> I'd rather pre-publishing went from pre-release
<pitti> ok
<pitti> I'll add "Pre-release" and map that to "final" then
<stgraber> pitti: if we want to pre-publish from pre-release, make sure that you also include what's been moved to final (as these should clearly get pre-published, though IIRC we don't have anything that's on releases.u.c on that page yet)
<pitti> committed, r404 in u-a-t
<pitti> stgraber: yes, I will (there is nothing pre-publish-y on final ATM)
<pitti> we only pre-publish ubuntu desktop/alternate/server now AFAICS (and only i386 amd64)
<Daviey> cjwatson: Are you still handling removals?
<cjwatson> Daviey: can do, point me at a bug?
<cjwatson> I thought server just added stuff ;-)
<pitti> cjwatson, skaet: pre-publishing done and syncing; I run cron.source now, as we are past all freezes for the release pocket; so we'll have the source images readily available tomorrow
<Daviey> cjwatson: not yet raised, didn't seem the point if it wasn't going to happen.. will raise now.
<cjwatson> pitti: cool
<Daviey> cjwatson: LOLOLO
<Daviey> z
<skaet> thanks pitti
<Daviey> cjwatson: bug 988234
<ubot2> Launchpad bug 988234 in openstack-dashboard "Please remove this package from precise, superseeded by horizon" [Undecided,New] https://launchpad.net/bugs/988234
<pitti> Daviey: adjusting horizon overrides again
<Daviey> pitti: thanks
<cjwatson> Daviey: done
<cjwatson> we have no report for obsolete source packages, unfortunately, although they're more or less no-brainers to remove
<cjwatson> we should have, Debian does
<Daviey> cjwatson: i suspect that will be a few crufty things.
<Daviey> Annoyingly, a few bugs got missed because people raised it against the old package source.. which were weren't subscribed to.. not that this problem will go away!
 * cjwatson gives up on the web interface and finds out what the archive bug queue looks like using lp.distributions['ubuntu'].searchTasks(bug_subscriber=lp.people['ubuntu-archive'])
<pitti> https://bugs.launchpad.net/~ubuntu-archive/+assignedbugs seems to work well here, but that's different from "subscribed", of course
<pitti> https://bugs.launchpad.net/~ubuntu-archive/+subscribedbugs?batch=30 WFM
<cjwatson> rather vitally different
<cjwatson> half the time I prefer lp-shell anyway :-)
<pitti> I found that reducing the batch size often helps
<cjwatson> it was faster for a while with the introduction of BugTaskFlat
<cjwatson> but meh
<Daviey> Ooo, not seen BugTaskFlat
<cjwatson> wgrant's reindexing effort
<pitti> Daviey: ah, http://people.canonical.com/~ubuntu-archive/component-mismatches.txt updated again; fixing harder..
<pitti> err, wait, that looks confusing
<pitti> why does it want to demote horizon again?
<pitti> FFS
<pitti> https://launchpad.net/ubuntu/precise/amd64/python-django-openstack/2012.1-0ubuntu5
<pitti> Status:
<pitti>     Superseded
<pitti> Daviey: I'm afraid LP got confused about the promotion/demotion
<pitti> seems this needs a no-change upload
<cjwatson> uh, how did you manage that
<pitti> err, wrong URL, ubuntu5 -> ubuntu6, but same problem
<Daviey> hmm
<pitti> cjwatson: I promoted -S -c main horizon, and then demoted the binaries that we didn't want
<pitti> apparently you need to have a publisher run in between that
<pitti> sorry about that
<pitti> cjwatson: there was some confusion which extra binaries we needed, but the seeds got updated now
<wgrant> You can't revert overrides within a single publisher run. The binaries will disappear, as you've seen here.
<cjwatson> 2012-04-25 09:04:07 DEBUG   horizon/2012.1-0ubuntu6 has been judged as superseded by horizon/2012.1-0ubuntu6
<cjwatson> comedy gold
<Daviey> it does need a no-change upload?
<pitti> ok, doing a no-change upload
<Daviey> pitti: wait
<wgrant> cjwatson: ~ubuntu-archive/+subscribedbugs confuses postgres' planner. ~ubuntu-archive/+bugs is a superset of that, but uses a sufficiently nasty query that the planner is outsmarted, so it should be fast.
<Daviey> pitti: I'd like to sneak in one more change i was going to leave for SRU.
<pitti> Daviey: ok, I'll let you do the upload and will review then
<Daviey> thanks.
<pitti> (and presumably binNEW)
<pitti> Daviey: what's the nature of the change, OOI?
<cjwatson> wgrant: ah, thanks, indeed
<pitti> something 100% super-safe, I hope? :-)
<Daviey> pitti: seems running under wsgi we NEED to use memcache otherwise it randomly looses it's sessions as sessions are not handled across workers.
<wgrant> Bug #180218 is the binary-eater
<ubot2> Launchpad bug 180218 in launchpad "override mismatch race needs to be fixed" [High,Triaged] https://launchpad.net/bugs/180218
<pitti> Daviey: ok, TBH I don't understand a word of that
<pitti> Daviey: doesn't sound like a trivial change, though?
<Daviey> pitti: bug 968850 .. random log outs as the session is lost across wsgi/aapche workers
<ubot2> Launchpad bug 968850 in horizon "intermittent errors and login page" [Undecided,Confirmed] https://launchpad.net/bugs/968850
<cjwatson> pitti: so it would be safer to be in the habit of using  -t -c main horizon  -c main <binaries>  in such cases
<cjwatson> for now
<pitti> cjwatson: right
<Daviey> pitti: it's just a config change.
<cjwatson> I think I'm in that habit so I don't notice this
<pitti> cjwatson: as I said, the set of <binaries> changed in the middle of that :/
 * pitti -> 1-on-1
<cjwatson> ah :-/
<wgrant> cjwatson: https://launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-archive should work most of the time. I intend to look at fixing the bad plans tomorrow.
<wgrant> ubuntu-archive has the fourth largest number of subscriptions, so it makes some bad choices.
<ScottK> slangasek: just that i understood there were some needing doing.
<cjwatson> the extra ones in +bugs on its own shouldn't be a particular problem
<cjwatson> but thanks
<wgrant> For people they're pretty problematic, but for ubuntu-archive it might work, yeah.
<Daviey> pitti: http://pb.daviey.com/qKej/ , currently validating
<ogra_> skaet, so slangasek asked me to update the ubuntu-core part in the release notes ... i dont really know what to write apart from "all general changes for ubuntu also apply to ubuntu-core" ... we didnt touch anything in -core this cycle
<ogra_> would that be enough for you ?
<skaet> ogra_ not quite.... ;)
<ogra_> (and probably a link to the ubuntu core wikipage where we describe what core is indeed)
<skaet> a link to the page, is definitely appropriate
<ogra_> k
<skaet> no significant package changes between the releases?
<ogra_> we simply dont have any precise spcific changes in it (unless infinity did anything i'm not aware of)
<skaet> how should the installation/usage happen/
<ogra_> skaet, nope, its still the same as in oneiric, just updated versions (as everywhere in ubuntu)
<skaet> minimum configuration to use it in.
<skaet> those are the sort of questions.
<skaet> that are in the template
<ogra_> thats all described in the wikipage and didnt change either
<skaet> https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuCore
<ogra_> no
<ogra_> https://wiki.ubuntu.com/Core
<skaet> ok,  if all the info is in the UbuntuCore page,  and no significant changes.
<ogra_> its a kit to produce your own chroot or rootfs, nothing any enduser would use
<skaet> Add 12.04 to the current supported releases
<ogra_> will do
<skaet> and we'll just direct the top level page to it.
<skaet> Are there any specific Ubuntu Core bugs?
<skaet> The only other thing is statinging somewhere the new architectures supported
<skaet> (arm hf,  etc...)
<cjwatson> I can't think of any way a bug could be specific to Ubuntu Core without also being a bug elsewhere.
<ogra_> yeah
 * ogra_ assumes core is supported for 5 years and adds the entry like that
<cjwatson> It must be.  Five-year support applies to packages, not continuing production of images (since we stop that after two years), and all the packages in core are by definition supported for five years already.
<cjwatson> (If they weren't, nothing else could be supported for five years.)
<ogra_> right, thats what i assumed
<pitti> re
<skaet> https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest
<skaet> ^ ogra,  Manifest is where support terms, etc. are kept.
<ogra_> heh, yes, i know :)
<pitti> Daviey: http://pb.daviey.com/qKej/> thanks; I'm afraid I cannot judge about the impact on this, so if you say we need this, then let's get it in; it's not on any of the images anyway, so in theory an SRU should suffice as well
<skaet> all are 5 years, except for the armel port,  which is only 18 months
<pitti> skaet: that's armhf, I take it?
<ogra_> skaet, it says preinstalled in the table
<ogra_> thats wrong, it is just a tarball
 * ogra_ corrects
<infinity> That was probably just a bit of cargo-culting.
<skaet> thanks ogra_
<ogra_> pitti, armhf is 5 years for non-desktop
<pitti> oh, it is? ok
<ogra_> (due to armhf server)
<pitti> but I thought armel was completely unsupported now
<pitti> i. e. similar to powerpc
<ogra_> armel is out, yes
<cjwatson> clang is good.
<cjwatson> Well, except for the ways it fundamentally isn't.
<ogra_> well, out of the canonical supported set ...
<cjwatson> But the patch is fine, and certainly isn't going to make clang/armhf worse since it's totally unusable right now.
<ogra_> still there as community image
<infinity> cjwatson: Heh.
<cjwatson> So accepted in order that we can clear those failures.
<infinity> ogra_: For strategic reasons, armel's getting some limited support.  Feel free to scream "LA LA LA" and ignore the previous sentence.
<doko> cjwatson, seeing that lsb_release still talks about the "development branch" ...
<pitti> that was fixed a few days ago by stgraber
<pitti> https://launchpad.net/ubuntu/+source/base-files/6.5ubuntu6
<pitti> doko: ^
<doko> ahh, ok
<pitti> lsb_release -a LGTM here; do you have the previous version, or did something go wrong here?
<cjwatson> me too
<cjwatson> Daviey: any news on that horizon upload?
<cjwatson> Daviey: if it's going to take a while, we should have a no-change upload to at least get the binaries back
<Daviey> cjwatson: I'm just waiting on one more ack before uploading.
<Daviey> cjwatson: i'll put it in the queue, but hold out for ack please
<cjwatson> ok
<Daviey> wb queuebot
<stgraber> hehe, the auto-respawn seems to work but I'll need to have it do that before it tries to paste something
<stgraber> as the current behaviour means we loose the entry it tried to paste before detecting it's no longer connected
<doko> infinity, does clang generate hard float code by default now?
<cjwatson> doko: that's the idea
<infinity> doko: llvm certainly claims to, if fed the right bits.
<infinity> I won't go beyond "claim" without digging deeper. :P
<doko> infinity, no, I mean clang
<infinity> Well, yes, and I have clang feeding the right bits to llvm.
<infinity> I thought that was implicit. ;)
<doko> because last time I checked it did default to soft float
<cjwatson> That's what infinity's most recent upload fixed.
<doko> ok
<infinity> Well, "fixed".  Brute-forced with various multi-clawed hammers.
<cjwatson> Because otherwise we couldn't build libdispatch.
<infinity> I'll revisit it post-release to generate upstreamable patches.
<Daviey> cjwatson: can that upload be rejected please, uploading a more suitable one.
<cjwatson> Daviey: done
<cjwatson> https://launchpad.net/ubuntu/+source/eclipse/3.7.2-1/+build/3382822 - hooray, it stuck to the wall this time!
<cjwatson> heisenbugs ftl
<jamespage> cjwatson, marvellous!
<cjwatson> I suspect that there's a random set of parallelised ant invocations that all have to get lucky, or something
<cjwatson> but who knows
<doko> hmm, last I looked it was all sequential
<cjwatson> there were parallel bits in one of the ant xml files
<cjwatson> whether they're honoured I have no idea
<cjwatson> (specifically, in the one in the directory that I saw failing)
<Daviey> cjwatson: please accept horizon recent upload, thanks
<jamespage> doko, cjwatson: it looks like something in the native thumb code (just discussing with xranby on #openjdk)
<cjwatson> you found my log?
<jamespage> cjwatson, yep
<cjwatson> Daviey: done
<Daviey> thanks cjwatson
<Daviey> Is anyone else seeing postfix sending mail failures?  seems to be ipv6 related?
<lamont> Daviey: I've seen them when my machine is unfortunate enough to be somewhere that hands it an ipv6 router without bothering to actually be part of the greater ipv6 world
<Daviey> lamont: hmm, actually.. localhost AAAA lookup failure.
<Daviey> http://pb.daviey.com/CqW0/
<lamont> Daviey: does it have an A RR?
<Daviey> lamont: I wrongly blamed postfix, for some reason dig localhost is failing :/.. /etc/hosts seems valid.. :/  Nevermind, sorry for the noise.
<lamont> dig ignores /etc/hosts
<scottl-work> skaet: i have signed off on the release manifest, thank you :)
 * scottl-work is very excited about this release
<skaet> Thanks scottl-work!  :)   us too!
<jo-erlend> are the iso's done? I'm anxious about a fix that's marked as released, but  I don't think it's in the distro yet.
<jo-erlend> bug 899001 to be precise.
<ubot2> Launchpad bug 899001 in sessioninstaller "gst-install wants to install i386-version of codec packages on amd64" [High,Fix committed] https://launchpad.net/bugs/899001
<jo-erlend> committed, even.
<ogra_> well, committed isnt released :)
<jo-erlend> right.
<jo-erlend> is it too late for it to be released in time for the iso's to be completed?
<jo-erlend> that one really, really bothers me.
<stgraber> jo-erlend: yes, it's too late
<jo-erlend> ai...
<astraljava> skaet: All required Studio tests are marked as Passed without bugs. Able to move them into Final now?
<skaet> astraljava,  yup.  we'll work with stgraber to get them moved over, in the next batch.  :)
<jo-erlend> I don't understand how Ubuntu can be released with an open bug that prevents nearly all users from doing something nearly all users will want to do; play media.
<stgraber> astraljava: doing it now. Are upgrades ready too?
<ogra_> jo-erlend, because there is always a .1 release (and SRUs) :)
<astraljava> stgraber: Studio doesn't have an upgrade case. It probably should, but...
<stgraber> astraljava: oh, good point ;)
<astraljava> ;)
<Daviey> mvo: bug 899001: Didn't hit the archive?
<ubot2> Launchpad bug 899001 in sessioninstaller "gst-install wants to install i386-version of codec packages on amd64" [High,Fix committed] https://launchpad.net/bugs/899001
<astraljava> Whee! Thanks stgraber, skaet! :)
<jo-erlend> ogra_, right. In the meantime, journalists are going to write that Ubuntu is promising, but that it still requires some technical knowhow, such as figuring out that you need to "install the restrictions", as someone put it.
<cjwatson> Does this affect only amd64?
<jo-erlend> cjwatson, it does, yes.
<jo-erlend> or I think so.
<Daviey> it seems someone marked it fix committed for the ubuntu task when really it was just fix committed 'upstream'
<popey> cjwatson: i only tested under amd64
<cjwatson> Can we at least please get this uploaded to -proposed immediately?
<cjwatson> We can't do anything until that's done
<mvo> Daviey: uh, let me check that out
<mvo> cjwatson: yeah I have a look now
<apw> i hit the similar issue in testing, filed as bug #987383
<ubot2> Launchpad bug 987383 in sessioninstaller "rhythmbox triggered request for additional codecs which erroneously included multi-arch libraries" [High,Triaged] https://launchpad.net/bugs/987383
<cjwatson> I assume that https://code.launchpad.net/~aptdaemon-developers/sessioninstaller/multiarch/+merge/99693 is the fix
<apw> the issue is work aroundable by only selecting the right architecture codecs only from the popup
<infinity> mvo: The way this was fixed seems suboptimal.
<phillw> hi guys, will the final releases (now arriving for testing) in iso-tracker all have thier zsync options still available? I'm grabbing the lubuntu ones to mirror on a server & will need to zsync when the release is confirmed.
<apw> that is not as clear as one might care for it to be
<cjwatson> infinity: look at the bit starting from "Get the architectures with an installed gstreamer library" - that seems like it'd restrict the architectures shown
<cjwatson> phillw: zsync generation is automatic, so yes
<infinity> cjwatson: Oh, I missed the "it wasn't merged yet".  Bah.
<phillw> thanks cjwatson , for i in ls; zsync .........$i makes more sense than wget :)
<pitti> Daviey: almost there.. http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<cjwatson> So, we could (in principle, if QA is OK with it, if RM is OK with it) respin images for just a single architecture with this change in -updates so that other images aren't out of sync
<mvo> infinity: happy to talk about it in a bit (in a meeting right now) but the problem is that the protocol does not tell us what architecutre the plugin is needed for
<pitti> Daviey: is python-django-openstack supposed to be in main (needs seeding), or should it go to universe?
<infinity> mvo: I misunderstood that the fix wasn't actually in yet. :P
<mvo> oh, ok
<infinity> mvo: So, I take back my suboptimal statement, maybe it's wonderful. ;)
<mvo> haha, ok
<ogra_> infinity, any idea about the omap/omap4 netinst images ? who tests them ?
<infinity> ogra_: apw and I are doing so here.
<infinity> ogra_: Almost done.
 * ogra_ thought QA would ... at least for omap4 
<ogra_> ah, awesome
<Daviey> pitti: yep, pushed
<cjwatson> mvo: So this seems a bit stalled - would it be possible to construct an upload of sessioninstaller to -proposed that just has Sebastian's multiarch branch merged, or do you have concerns that that wouldn't be a sane thing to do?
<apw> ogra_, don't you have omap3/omap4 h/w too ?
<Daviey> skaet: Do you know if "Common Infrastructure" is being worked on?  A few stub entries?
<cjwatson> nobody's done any publish-release work for wubi tarballs, have they, sisgh
<cjwatson> *sigh
<skaet> Daviey,  re: "Common Infrastructure",  slangasek was working on it, but there is still stuff to clean up.
<jo-erlend> I thought that was supposed to be taken out of the CD?
<jo-erlend> or was that just a proposal?
<ogra_> apw, thats why i asked, i would have started a test now
<stgraber> jo-erlend: you can't install Ubuntu using wubi from a CD but wubi itself still works, using a compressed filesystem downloaded from the DC
<jo-erlend> stgraber, I'm not entirely sure what that means.
<stgraber> jo-erlend: go on www.ubuntu.com, download wubi.exe => still works with 12.04
<jo-erlend> aha.
<jo-erlend> stgraber, it still installs to a filesystem image, or does it now just start a normal install?
<stgraber> jo-erlend: it still installs the exact same way it used to, it just doesn't use the install media as its install source but the compressed fs from the DC
<infinity> ogra_: There's no such thing as too many people testing. :P
<infinity> ogra_: But we just got done testing it all here.
<jo-erlend> infinity, that's certainly true. I'm still experiencing lots of weird issues when switching between users.
<ogra_> infinity, well, i have a compiz testbuild pending (as soon as the merge is done) so i would prefer to keep my panda free at least :)
<infinity> ogra_: Fair enough.
<infinity> ogra_: Do you have a decent Beagle?
<ogra_> yes, an XM
<infinity> ogra_: You could do Kubuntu/omap
<infinity> ogra_: Oh, that craps all over the Beagle I have here.
<ogra_> i have to rush out for 1h or so, but will fire off a test on it afterwards
<infinity> ogra_: Pretty please do Kubuntu/omap? ;)
<ogra_> oh, kubuntu ... yeah, can do
<ScottK> Thank you.
<stgraber> Riddell: http://www.stgraber.org/download/releases/ <- I'm mirroring Kubuntu 12.04 there too, it's currently mirroring the daily and merging them the ugly way, so the *SUMS file don't contain the right entries but it'll be fine as soon as I can mirror the real thing
<Riddell> stgraber: oh thanks, but why mirror the daily/ why not just wait for them to be moved to releases/ and mirror that?
<stgraber> Riddell: because I can't be sure cdimage will still have enough bandwidth at that point. It's easier to just mirror a few kBs for the index files/checksums than have to re-download the 20GB of the images
<Riddell> stgraber: ok thanks
<Riddell> I wonder if it would work to set one up on ec2 and charge it to canonical in the normal way
<stgraber> Riddell: my experience with EC2 is that it's way too expensive for anything like that. The box I'm using to mirror these images cost me around $45 a month and has better specs than an extra-large amazon instance and 10TB of bandwidth included
<Riddell> stgraber: yeah but at 12 hours notice it might be the only thing going
<cjwatson> publish-release and publish-image-set.py handle Wubi now
<cjwatson> the filesystem tarballs, that is
<Riddell> probable emergency SRU needed for Kubuntu to get upgrade notification working
<skaet> Riddell,  ack.  Please put details on pad.ubuntu.com/ubuntu-release under SRU
<ScottK> Riddell: I'll update the pad.  You go make the fix.
<Riddell> ScottK: bug 988349
<ubot2> Launchpad bug 988349 in muon "no release upgrade notification" [Undecided,New] https://launchpad.net/bugs/988349
<ScottK> Thanks.
<Riddell> uploaded, needs testing first
<cjwatson> apw: sessioninstaller is ready to test in -proposed
<Riddell> balloons: http://people.canonical.com/~jriddell/tmp/muon/ for testing
<balloons> thx
<Riddell> ping pitti
<pitti> hey Riddell
<Riddell> pitti: can you review bug 988349 and the muon sru in unapproved queue
<ubot2> Launchpad bug 988349 in muon "no release upgrade notification" [Undecided,New] https://launchpad.net/bugs/988349
<Riddell> and let it through
<pitti> Riddell: sure
<pitti> Riddell: hm, nothing in the precise queue?
<Riddell> pitti: oneiric
<pitti> oh, is that for an older release?
<pitti> Riddell: done; is that fixed in precise already?
<Riddell> pitti: yes
<pitti> skaet: time for g+ catchup?
<skaet> pitti,  yes,  slangasek should be around now.
<pitti> skaet: he's in g+ already
 * skaet lost in release notes.  heading in now
<xdatap1> skaet, Hi! We planned a last testing image today for the Italian CD. Is this a good moment or it's planned some uploads in next hours?
<apw> cjwatson, confirming testing the new sessioninstaller package sorted out my codec issues
<cjwatson> pitti: apw's testing of sessioninstaller is apparently good; can we waive the testing period and copy this to -updates so that we can respin amd64 CDs based on that?
<cjwatson> assuming that that's still something skaet thinks is sensible, which I think it'd be good to confirm explicitly
<pitti> cjwatson: sure, waiving the testing period sounds ok to me
<cjwatson> outdate_all is empty!
<cjwatson> both primary and ports
<cjwatson> component-mismatches - what's going on there?
<cjwatson> Daviey: ^-
<pitti> it hasn't been updated in two hours
<Daviey> cjwatson: you tell me... that package is seeded
<Daviey> :/
<cjwatson> the archive might not have been updated
<cjwatson> it only updates when the archive does
<cjwatson> Daviey: huh
<cjwatson> ok, I'll look into that
<Daviey> cjwatson: c-m doesn't seem to reflect the seed.. but i see, it's an archive update issue?
<cjwatson> Daviey: I'm not sure as yet
<cjwatson> it *should* have updated, from the looks of things
<cjwatson> hm, there's a .new that hasn't been moved
<Daviey> cjwatson: Hmm, i updated the seed after horizon was published.. so it could still be related?
<Daviey> has anything touched the release pocket since?
<cjwatson> Daviey: I very much doubt this has anything to do with anything you've done
<Daviey> That'll be a first. :)
<cjwatson> process-component-mismatches-diff is spinning
<sladen> skaet: how does this work; do we create a new page at  https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/DesktopInterface  and include that?
<sladen> skaet: or is there one created, or just edit the master page?
<sladen> skaet: (for populating known issues)
<cjwatson> haha, this is an entertaining bug
<cjwatson> process-component-mismatches-diff spins when component-mismatches goes empty
<cjwatson> fixed, c-m is now empty
<cjwatson> Daviey: ^-
<pitti> \o/
<cjwatson> so we must never have had c-m empty since the diff mailer was introduced :)
<cjwatson> or else we didn't figure out the bug
<Daviey> cjwatson: nice catch!
<Daviey> i've been keeping c-m populated most of the cycle :)
<pitti> jibel: is the upgrade test with oneiric-proposed apt still running, or did it finish?
<skaet> sladen,  Use the master page to contain the content.   We may spin it to a subpage later, if its too much (like with did with Upstart for instance)..
<stgraber> skaet: marking Edubuntu amd64 as disabled on the tracker
<stgraber> cjwatson, infinity: So, as I was telling skaet during our call, respinning Edubuntu amd64 without Edubuntu i386 may be "interesting" as the amd64 build contains an i386 ltsp chroot (as .squashfs), usually built by the matching i386 build. In this case, we can safely use the previous i386 ltsp chroot but I'm not sure if the scripts are clever enough to do that on their own
<stgraber> (that's ltsp/i386.img in the resulting .iso image)
<jibel> pitti, in progress
<skaet> stgraber, so you want both respun?
<cjwatson> one moment
<stgraber> skaet: if it's easy to respin just amd64 containing a new amd64 livefs and the old i386 chroot, I'm fine with that. If it's difficult to do, I don't mind re-testing both.
<cjwatson> I'm pretty sure it'll just work
<cjwatson> it'll either fail to build entirely, or build correctly, and I think the latter
<stgraber> ok, worth the try then :)
<cjwatson> respins running on amd64
<pitti> skaet: need to leave for TKD in 5 mins, is there still anything you need from me?
 * pitti waves good night
<skaet> pitti,  thanks!
<Riddell> I'm out for a couple of hours
<Riddell> then back for a long night of testing and writing
<ScottK> balloons: We're having mixed results on the SRU for Kubuntu upgrade notification.  If you could test that it would be really, really helpful.
<balloons> ScottK, so the best way is to use that pkg and upgrade 11.10?
<ScottK> Yes.
<ScottK> balloons: Take an to date Kubuntu 11.10, install the muon updates from oneiric-proposed, and add 212.13.202.11 changelogs.ubuntu.com to /etc/hosts.  Then logout/in and you should get notified there's a new release.
<balloons> ok -- I'll try that.. someone just finished an upgrade from 11.10 to 12.04 without issue or using the new update, afaik
<ScottK> Thanks.
<ScottK> Updates will work just fine without the new update, people just won't get notified.
<phillw> hi guys, I notice you are doing some respins for amd64 multiarch bug. On Lubuntu, our two 'red' bugs are resolved (old kit, that was dying). We are good to go :)
<slangasek> jibel: do you happen to have an eta for that oneiric-proposed test?  Will we be able to pick the results up from the jenkins overview when it's done?
<cjwatson> phillw: Lubuntu didn't have sessioninstaller, so didn't need to be respun for this
<ScottK> Kubuntu?
<cjwatson> nope
<ScottK> OK.  Thanks.
<cjwatson> I checked with seeded-in-ubuntu
<phillw> cjwatson: okies, it was just to let you know that Lars found that two 'red' bugs were due to failing hardware. He has rescinded both.
<cjwatson> OK
<ScottK> Kubuntu ISO test status: i386 = Done.  amd64 = 1 dvd test left, tester downloading dvd, amd64+mac = tester downloading CDs, powerpc = desktop done and alternate in progress, armhf+omap4 = done, armhf+omap = hoping ogra can still do.
<ScottK> The upgrade issue won't affect precise, just oneiric.
<cjwatson> Bug 987956 is a bit sad-making, though not diagnosed
<ubot2> Launchpad bug 987956 in ubiquity "Installer Deletes Contents from Separate HOME partition without WARNING!" [High,Incomplete] https://launchpad.net/bugs/987956
<ScottK> Ouch.
<balloons>  ScottK, working on the upgrade test now
<ScottK> Excellent.  Thanks.
<ogra_> ScottK, well, i'm at my 5th attempt now
<ScottK> Thanks for working on it.
<ogra_> first failed when i accidentially touched the enter key at user creation
<ogra_> since then i havent seen a successfull boot to ubiquity
<jibel> slangasek, desktop and server passed, universe is in progress and should be done in 2.5 hours
<slangasek> ogra_: hmm?  why is touching the enter key breaking your boot?
<slangasek> jibel: ok, cool.  will that show up on jenkins when done?
<ogra_> slangasek, not my boot, it made kubuntus oem-config crash (i didnt have put in any data in the form field yet)
<jibel> slangasek, yes
<ogra_> not sure why the boot is broken now, might be my microSD card :/
<slangasek> jibel: ok, cool... what would the URL be?
<ogra_> (5 attempts above means that i rewrote the card 5 times from scratch, the last 4 didnt even get to X)
<slangasek> jibel: we really need this SRU in before release, but if we can get it without you having to stick around to babysit test results, so much the better
<slangasek> ogra_: ah, heh
<jibel> https://jenkins.qa.ubuntu.com/view/Precise%20Upgrade%20Testing%20Dashboard/
<jibel> desktop and server test build time is Apr 25, 2012 3:57:18 PM (UTC)
<jibel> these are the run with -proposed
<slangasek> jibel: ok, I'll watch for the results, thanks
<slangasek> pitti: ^^ if the oneiric upgrade tests check out, are you happy for me to self-promote the apt SRU?
 * stgraber downloads
<ogra_> sigh, this one hung hard at plymouth with the "waiting for network configuration" message
<ogra_> it feels like i'm booting some entirely different system ... ubuntu works just fine
<ogra_> (syslog, boot.log and friends are all at zero bytes ... nothing on the serial console either ... :( .... )
<ogasawara> wow, it happens like magic just as I was going to make the request to get the kernels new'd
<infinity> ogasawara: You're welcome.
<ogasawara> infinity: you're the best
<ogra_> you didnt notice the little chip we implanted in your brain and connected to the queuebot ?
<infinity> ogasawara: I sure am.
<ogasawara> hehe
 * infinity mumbles something about pineapples under his breath.
 * ogasawara giggles
 * ogra_ grins
<ogra_> ok, one last attempt
<ogra_> (if only the writing of the microSD wouldnt take 45min here :/ )
<ogra_> GRRRR
 * ScottK did and pinged the uploader ^^^
 * ogra_ sits at a console login prompt *again*
<ogra_> i really really wonder why the first try got me to oem-config at all
<infinity> ScottK: \o/
<ScottK> Three minutes to reject.  Can't complain about lack of responsiveness.
<ogra_> it is as if having kubuntu-desktop installed scatters random bugs into the underlying system or so
<ogra_> and i wish i could even remotely come up with an explanation
<ScottK> We do have a different plymouth theme and the kdm upstart job is different (but not very)
<ScottK> OTOH, it apparently worked on omap4.
 * apw has just tested the current amd64-live image and the codec issue is resolved in this image
<ogra_> the kdm upstart job shouldnt even execute
<ScottK> OK.
<ogra_> since oem-config is there
<ScottK> Right.
<ogra_> (and yes, /var/lib7oem-config-run is there too)
<ogra_> oh
<ogra_> rebooting the board randomly got me back to it !
<ogra_> oh my
 * ogra_ sees the wallpaper 
<ScottK> \o/
 * ogra_ selects "Deutschland Zeit" in the TZ dialog (why doesnt it say "Berlin" ? )
 * cjwatson blames icu
<infinity> Because the former option makes me want to march patriotically, the latter makes me hungry for donuts.
<ogra_> lol
<ogra_> wow, the firefox icon in the slideshow looks really scary
<ogra_> a robot dragon eating the world
<ogra_> (its the first time i touch kubuntu since breezy btw)
 * ogra_ wonders if KDM will ever come up
<ogra_> oh, there we go
 * ogra_ logs in
<highvoltage> the amazing tales of oliver's logins!
<ogra_> haha
<ogra_> well, if it wouldnt be so busy drawing animations it might show me a desktop at some point :)
<ogra_> ah, there we go, i get the "Plasma Desktop Shell - The KDE Crash Handler"
 * ogra_ feels like in an 80s adventure game 
<ogra_> just more bling
<ogra_> oh, geez !
<highvoltage> that's pretty much what every day of my life is like. I spend most of my time walking north, then east, then south, then west though.
<ogra_> just when i wanted to click it mived the window around
<ogra_> *moved
<ogra_> and i have an empty panel at the bottom now
 * ogra_ wonders what to do with this
<ogra_> oh and there is a button at the top right now that offers me to add another panel if i click it
 * ogra_ must admit he is totally lost with that UI
<ogra__> look, i found a way to add a menu !
 * ogra__ now wonders how to judge an image that needed 7 install attempts but in the end succeeded
<ogasawara> infinity: now that the kernel is through, could I get lbm approved in the queue?
<Riddell> skaet: who do we have as an archive admin
<Riddell> and ubuntu-sru
<cjwatson> Here.  What do you need?
<Riddell> cjwatson: bug 988349  is working for me
<ubot2> Launchpad bug 988349 in muon "no release upgrade notification" [Undecided,Fix committed] https://launchpad.net/bugs/988349
<infinity> ogasawara: It's still publishing.
<Riddell> cjwatson: needs checking I've followed procedure right and moved to oneiric-updates
<infinity> ogasawara: I'll accept them when the kernel is happily published. ;)
<Riddell> ogra__: you're a top kubuntu testers now?
<ogra__> Riddell: well, it was kind of painful but it finally succeeded
<infinity> ogasawara: Oh, and it finished while I was waffling. ;)
<ogra__> but i'm still not sure how to mark that adventure on teh iso tracker
<Riddell> ogra__: what did it take to succeed?
<cjwatson> We've already agreed that it's OK to waive the waiting period on this
<ogra__> Riddell: several retries, it failed at very random and unpredictable places
<cjwatson> Looks fine, moving to -updates
<Riddell> ogra__: that doesn't sound like the sort of thing we want to release then
<cjwatson> Riddell: done
<Riddell> cjwatson: great thanks
<cjwatson> the bug tracker should notice shortly
<ogra__> Riddell: well, i only have one (very old) microSD card here, now that the install finished it seems to work, the crashes and hangs were even before any kde stuff could kick in (i had two failures in oem-config and three times it got me to a console login instead of oem-config) ...
<ogra__> Riddell: so i'm not sure if i should blame teh card or not
<Riddell> ogra__: so there is hope but that still doesn't sound like a successful test
<Riddell> ogra__: how do the ubuntu desktop images get tested?
<Riddell> not on the same (very old) microSD card I presume?
<ogra__> Riddell: same way, do an install, use it for a while
<infinity> Riddell: I tested them here.
<ogra__> i didnt do any omap tests here
<ogra__> apart from kubuntu
<infinity> Riddell: I can spin up kubuntu/omap, just didn't do so.
<Riddell> right, thanks for caring about us ogra__ :)
<ogra__> it wont be fun in 256M
<Riddell> infinity: if it's convenient that would be nice but I'm not too fussed about getting it released
<ogra__> Riddell: i think i can blame the card, if infinitymanages to get through oem-confing in teh first attempt i would say we are ok
 * ogra__ shuts down teh board ...
<infinity> If I manage to boot, it'll be a miracle, my Beagle only has 256M of RAM, which is why I asked Oli. :P
 * apw notes it also makes nose excretia look intelligent
<ogra_> infinity, it should manage to run oem-config even in 256M
<ogra_> i doubt it can run the desktop though
<infinity> It ran Ubuntu "alright"... Until Andy decided to test Firefox.
<infinity> Which was a Very Bad Idea.
<apw> i resemble that remark
 * apw notes that although it was usuable, it worked
<infinity> It did, amazingly, cope.  It just coped very, very slowly.
<apw> s/very/omg very/
<cjwatson> You aren't running this in emulation on an AVR breadboard, are you?
<ogra_> haha
<stgraber> ^ please someone reject, dput fail, should have been PPA
<infinity> Gone.
<stgraber> thanks
<gema> skaet: I think we should release not but 979661
<gema> release notE, sorry
<ogra_> Riddell, i marked it as passed but with a comment about how i got there ... the installed system seems to work and all (i did several reboots etc)
<gema> bug
<gema> omg, I cannot type
<infinity> I'm testing it here, but will probably finish in the morning. :P
<skaet> :)  gema,  I'm starting to resemble that as well.
<ogra_> heh
<skaet> bug 979661
<ubot2> Launchpad bug 979661 in update-manager "oneiric to precise: debconf: unable to initialize frontend: Gnome and falls back to Dialog" [High,Confirmed] https://launchpad.net/bugs/979661
<cjwatson> I think that was the one where I was waiting to see if the oneiric apt SRU improved matters
<cjwatson> Has anyone tested that today since apt was moved to oneiric-updates?
<cjwatson> Wait, that *hasn't* been moved to oneiric-updates, argh
<cjwatson> I thought that was a "must do before precise release" thing
<gema> cjwatson: I am doing an upgrade right now
<gema> cjwatson: problem is still there
<cjwatson> yeah, well, we haven't promoted the apt that fixes a load of stuff yet, so ...
<cjwatson> slangasek: ^- weren't you talking to pitti about that earlier today?
<gema> cjwatson: but this time I found the hidden window so I am on the happy road to precise now
<cjwatson> right, I agree that's the workaround, but I was hoping that the apt promotion would render a release note unnecessary
<slangasek> cjwatson: yes, waiting for the oneiric-upgrade-main autotest to complete
<gema> cjwatson, slangasek ack
<cjwatson> Ah - do we have an ETA on that?
<cjwatson> It'd be nice to see whether this means we can forego a confusing and slightly scary release note
<slangasek> jibel gave an eta of now-ish
<slangasek> sorry, make that in-an-hour-ish
<slangasek> cjwatson: desktop and server have already passed muster, perhaps it's better to promote that now and deal afterwards with any unlikely regressions affecting oneiric-upgrade-main?
<cjwatson> judgement call I guess; gema, how long are you around?
<cjwatson> it'd be nice to have time for a manual upgrade test after this, but there'll be a publisher delay of course
<gema> cjwatson: I don't have any other machine on oneiric anymore
<gema> :(
<cjwatson> Oh, is it not reproducible in VMs?
<gema> cjwatson: I will install on one of my test machines
<gema> cjwatson: I don't know
<cjwatson> Right, sorry for the hassle - it'll be a little while before we have something worth retesting, in any event
<gema> but doesn't matter, I will get a netbook on oneiric
<slangasek> and do we think 979661 would be worked around by this SRU?
<gema> and you tell me when to try
<cjwatson> slangasek: I don't know, but it seems not implausible because it's definitely affected by ordering
<slangasek> gema: if you wanted to enable oneiric-proposed, you could test that immediately
<cjwatson> gema: in fact, ... what he said
<slangasek> (that's what's being done in the jenkins tests right now)
<cjwatson> yeah, upgrade apt from oneiric-proposed, then start upgrade
<cjwatson> does update-manager do that automatically from oneiric-updates?
<cjwatson> (IOW, would we need to release note this in any event for people who haven't upgraded apt?)
<gema> I am already half way through the upgrade
<gema> I need to install a test machine with oneiric
<gema> anyway
<cjwatson> we meant on the netbook
<gema> ok, will do that
<cjwatson> But failing that, I can certainly write up a release note
<gema> by the time I have it there you may as well have it further down the pipeline, if not, I will use proposed
<gema> I guess I am going to be around for a while :D
<gema> cjwatson: oneiric iso downloading, will keep you posted in progress
<slangasek> cjwatson: automatically from -updates> I'm afraid I don't know
<cjwatson> Hm, I can't say I'm convinced that it will
<cjwatson> The prerequisites code does things like release-upgrader-apt, but not apt itself (at least it isn't configured to)
 * slangasek nods
<slangasek> so a short release note is probably in order
<gema> cjwatson, slangasek do you guys still want me to test it tonight, then?
<cjwatson> If this apt fixes it, then we can say that fully updating your 11.10 system before the upgrade to 12.04 avoids this bug, which would be a good thing to be able to say
<cjwatson> So I think it is worth it
<cjwatson> But only if you're not already entirely frazzled
<gema> cjwatson: ack, so I will install oneiric
<gema> cjwatson: then point to -proposed my sources, then update
<gema> then upgrade?
<gema> is that what we are aiming to?
<cjwatson> 'sudo apt-get update && sudo apt-get install apt'
<gema> sorry, I am not familiar on how to use proposed
<gema> ok
<cjwatson> there's a wiki page somewhere with stock advice, one moment
<cjwatson> https://wiki.ubuntu.com/Testing/EnableProposed
<gema> so I enable proposed, then I install apt
<gema> ack
<cjwatson> It should be version 0.8.16~exp5ubuntu13.3
<gema> ok
 * Riddell signs off on various kubuntu images
<infinity> kubuntu/omap is going alright, except for the part where I only have 256MB of RAM...
<cjwatson> I think it's beer o'clock
<gema> cjwatson: indeed, I will let you guys know the outcome when I am done
<skaet> slangasek,  we're breaking for a bit,  online later.
<cjwatson> I expect I'll be around by phone-IRC if nothing else
<gema> ack
<gema> cjwatson: although I would prefer you not to touch the repositories after the beers x)
<slangasek> skaet: ok, later
<jibel> slangasek, universe upgraded successfully on both arch
<slangasek> jibel: woot, thanks
<jibel> slangasek, for main jenkins tells me : ETA: N/A :)
<slangasek> oh?
<jibel> and it is still unpacking packages
<slangasek> heh, alright
<slangasek> apt oneiric SRU published
<Riddell> folks we have a second emergency SRU for kubuntu upgrades in oneiric, bug 944876
<ubot2> Launchpad bug 944876 in software-properties "changed mapping of release_upgrades_policy causes software-properties-kde to set the wrong policy" [High,New] https://launchpad.net/bugs/944876
<cjwatson> gema: aw, you're no fun
<Riddell> cjwatson, slangasek: either of you able to take this software-properties SRU of yofel's?
<cjwatson> Only if it's small enough to be reviewed in a phone's web browser
<Riddell> cjwatson: should be actually
<yofel> one line change in 2 places
<slangasek> if not I can look soon-ish
<Riddell> I'm out for half an hour but it's in precise and oneiric-proposed
<slangasek> first though, trying to work out if the amd64 respins are all done
<cjwatson> should be
<slangasek> Ubuntu Desktop amd64+mac seems to have not been updated?
<slangasek> and would also be hit by this
<cjwatson> oh, I meant to do that
<slangasek> cjwatson: should just be a debian-cd run, no livefs, right?
<slangasek> I can do it
<cjwatson> if you could  ARCHES=amd64+mac for-project ubuntu cron.daily-live  that'd be good
<slangasek> done
<slangasek> (well, running)
<cjwatson> s-p diff is pending, maybe somebody at a real computer could look
<Daviey> cjwatson: You aren't on your phone are you?
<cjwatson> ah, both oneiric and precise?
<cjwatson> Daviey: I am, about to put it away and drink beer so put away the nagging stick :0
<cjwatson> :P
<Daviey> heh
<stgraber> cjwatson: I'll take a look at software-properties
<stgraber> (though I guess it should be an SRU team member as it's oneiric-proposed)
<slangasek> yeah
<stgraber> Riddell: what's with preview.diff?
<stgraber> Riddell: looks like you forgot to cleanup before upload :)
<slangasek> stgraber: where are you seeing that? the oneiric version?
<stgraber> slangasek: http://launchpadlibrarian.net/103077132/software-properties_0.81.13.2_0.81.13.4.diff.gz shows me software-properties-0.81.13.4/preview.diff being added to the source
<stgraber> slangasek: yeah, the oneiric one
<slangasek> Riddell, yofel: looks like this was built from branch with 'debuild' instead of with 'bzr bd'; the differences are small enough here that it's ignorable, but please make a note for the future
<slangasek> debuild may not give the right results, particularly for native packages
<slangasek> yofel, Riddell: walk me through this, please.  You're manually shifting the policy index at runtime; that means the value stored on disk is still wrong for some users, and this only fixes the problem if they run software-properties-kde again?
<yofel> yes, I don't know how to fix that in the config file on update
<slangasek> sure
<slangasek> the data is lost, we can't decipher intent
<slangasek> (not reliably)
<slangasek> so this is considered "urgent" so that oneiric users who have managed to set the wrong policy can fix it from the gui in order to upgrade to 12.04?
<yofel> right
 * slangasek nods
<Riddell> hi
<slangasek> precise accepted; sounds like oneiric should be reuploaded though, from stgraber's comments?  (just looking at it now)
<Riddell> I can do trhat
<slangasek> if you use bzr bd, you also don't have to worry about stray temp files getting into the diff :)
<len-dt> Should the qatracker be reset for ISOs that have been respun today? Ubuntustudio's amd64 ISO is still showing test results from yesterday. Web page http://iso.qa.ubuntu.com/qatracker/milestones/216/builds
<slangasek> Riddell: rejected from oneiric-proposed, but the actual change looks fine
<slangasek> so please get me a clean diff and I'll accept
<stgraber> len-dt: testing for the rebuilds needs to happen in http://iso.qa.ubuntu.com/qatracker/milestones/214/builds
<slangasek> len-dt: I've marked the "Precise Final" build as "disabled", thanks
<slangasek> and as stgraber says, the one to test is listed under pre-release
<len-dt> Ok thanks. I post it in our IRC chanel.
<ogasawara> I've uploaded a new lbm-3.2.0-24.8 (-24.7 failed due to buildd kernel version issues which didn't appear when doing local test builds)
<ogasawara> could I get that approved, when someone has a moment
<Riddell> slangasek: uploaded software-properties
<slangasek> Riddell: and accepted, thanks
<slangasek> ogasawara: looking
<slangasek> um
<gema> getting my oneiric ready for upgrade
<stgraber> as the bot is saying, Edubuntu amd64 was tested and I moved it over to Final
<slangasek> was someone else touching software-properties?
<slangasek> there were two in the queue
<slangasek> I tried to reject one, then accept the other
<Riddell> slangasek: I might have rejected the other
<slangasek> now it looks like both were rejected
<slangasek> heh
<Riddell> slangasek: I'll reupload
<slangasek> no
<slangasek> I'll un-reject
<Riddell> ok
<slangasek> done
<slangasek> ogasawara: OOI, why does this only apply to the net modules build?
<slangasek> (accepted)
<ogasawara> slangasek: the cw-3.3 ones were already smart enough to pass in the proper version and not default to the host machine
<slangasek> ok
<slangasek> would it be more future-proof to assume those might also get dumber down the line? :)
<ogasawara> slangasek: indeed :)  I'll add it to my list to review and fix up.
<Daviey> slangasek: fancy allowing horizon into -proposed?  I'd ideally like it in release pocket, or at least updates soon.  It's not shipped on any images.
<slangasek> looking
<Daviey> ta
<highvoltage> 0/win 28
<slangasek> prepublishing the amd64 updates
<slangasek> Daviey: accepted into -proposed; sufficiently trivial that I see no reason not to copy to release when published
<slangasek> s/published/built/
<Daviey> slangasek: thanks
<popey> OUTRAGE!! bug 988543 simply _must_ be fixed before release!
<ubot2> Launchpad bug 988543 in gnome-screenshot "printscreen flashes twice instead of once." [Undecided,Confirmed] https://launchpad.net/bugs/988543
<popey> or something
 * slangasek arranges to fix your outrage before release
 * ScottK hands slangasek a hammer.
<Riddell> who's incharge of the download links?
<slangasek> as in, on www.u.c?
<gema> doing the distro update with apt version 0.8.16~exp5ubuntu13.3
<gema> upgrade, sorry
<slangasek> gema: btw, does your netbook have the same set of packages installed that the machine you saw the bug on did?
<slangasek> because this is a slippery bug
<gema> slangasek: yes, that's why it took me so long
<slangasek> ok, great :)
<gema> slangasek: I hope I haven't missed anything important, because I am feeling sleepy by now
<ogasawara> could I get lbm and linux-meta binNew'd?  After that the day-0 kernel will be ready to be pocket copied
<ScottK> balloons or jibel: Could still use some help on amd64+mac for Kubuntu.
<balloons> ScottK, ack
<gema> slangasek: still asking me to configure libc6
<gema> with the new version
<gema> slangasek: we need to release note
<slangasek> sorry, can you clarify?
<slangasek> "asking you to configure" is by design and not release notable
<gema> yeah, I will take a snapshot
<slangasek> the bug is if it's asking this in the terminal where you can't see it
<gema> slangasek: it is in the Terminal, asking me "Services to restar for GNU libc library upgrade: "
<slangasek> ok
<slangasek> then yeah, that's the bug
<slangasek> sigh
<gema> sorry
<slangasek> not your fault
<slangasek> thanks for re-testing
<gema> no probs
<gema> slangasek: I took a picture with the phone, the machine is frozen and doesn't do screenshots or window resizings
<gema> slangasek: in your inbox
<slangasek> ok
<slangasek> thanks, I think that's enough information for us to generate a release note
<gema> slangasek: ack, I am calling it a day
<gema> see you tomorrow
<slangasek> g'night!
<tumbleweed> ^ that's a non-trivial upstream bump, but seems sane given the circumstances
<slangasek> stgraber: I've added a release note for bug #985065 to https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop, but I couldn't figure out how to make it *work* to change the keymap after choosing "try ubuntu"; you may want to review
<ubot2> Launchpad bug 985065 in xkeyboard-config "Can't use fr/oss keyboard layout by default" [High,Confirmed] https://launchpad.net/bugs/985065
<stgraber> slangasek: testing my workaround again now to make sure it still works
<balloons> my box is SO slow.. still trying to see if I get the upgrade bug
<stgraber> slangasek: oh, well, I didn't remember it being that broken last I tried...
<slangasek> stgraber: basically, I get a keyboard menu with four french keymap choices; moving between any of them still leaves me in qwerty; and the 'add keymap' button in the dialog is grayed out
<slangasek> is that what you see too?
<stgraber> slangasek: so the workaround isn't exactly intuitive. You need to go and re-order the keyboards in the keyboard layout window, that will reset the X property fixing the bug
<slangasek> oh ugh
<slangasek> *reorder* keyboards
<Riddell> skaet: https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/Kubuntu is eyed over by me and ready for proofreadig
<slangasek> stgraber: do you think what I have there currently is better?
<stgraber> slangasek: right, it's grayed out because ubiquity already set 4 layouts (maximum supported by X), you'd need to remove one in order to have access to the "add keymap" button
<skaet> Thanks Riddell
<jibel> slangasek, I think both workarounds are valid. opening keyboard setting and dragging 'France' to the top of the list is an easy workaround once the live session is started
<stgraber> slangasek: yeah, I think it's easier to have them choose the layout in gfxboot than tell them how to get to the keyboard layout and then drag&drop entries to workaround the bug
<jibel> s/France/French
<ScottK> skaet: Kubuntu powerpc also signed off (we've got all the images but amd64+mac done and signed off).
<balloons> ScottK, I'm still working on amd64+mac.. someone should be getting off work and seeing the plea for help :-)
<ScottK> Excellent.
<balloons> my 11.10 upgrade test attempt bombed out though.. my kubuntu 11.10 install froze up trying to grab the proposed packages.. :-(
<balloons> bbl
<ScottK> Is qapt hung?
<ScottK> There's a bug there in qapt 11.10.
<balloons> ohh.. yea
<balloons> and :-)
<ScottK> I had a similar problem today.
<balloons> if I try again, will it work perhaps?
<balloons> i just rebooted the box
<ScottK> I had to kill qapt, then dpkg would run.
<balloons> ok.. I'll do that then
<ScottK> sudo apt-get -f install and see what happens.
<ScottK> It's a real bug, but not directly relevant to upgrading to 12.04.
<stgraber> ScottK: ok, I'm going to move all the Kubuntu builds to the Final milestone except for amd64+mac
<stgraber> ScottK: what's the status on upgrades?
<balloons> right
<ScottK> stgraber: Sounds good.  Thanks.
<Daviey> slangasek: did you copy horizon to release pocket?
<ScottK> stgraber: They are working, but we're having some issues with upgrade notification.
<ScottK> Riddell: Did the second SRU get in?
<Riddell> ScottK: yes, needs testing
<ScottK> stgraber: ^^^ actual upgrades are tested and working.  Need testing on a second SRU for upgrade notification.  That's the status.
<stgraber> ScottK: ok. I'll wait for both of them to be 100% covered on the tracker before moving them
<slangasek> Daviey: not yet - it's built and published everywhere now?
<ScottK> I think that's reasonable.
<Riddell> software-properties-kde in oneiric bug 944876 needs testing
<ubot2> Launchpad bug 944876 in software-properties "changed mapping of release_upgrades_policy causes software-properties-kde to set the wrong policy" [High,Fix committed] https://launchpad.net/bugs/944876
<stgraber> ScottK: amd64 seems to need some results, the only results so far are mine and these are automated headless testing, so having one human at least confirming it looks good from the UI would be good
<ScottK> stgraber: OK.  I'll look for someone to try it.
<Daviey> slangasek: seems to be
<stgraber> ScottL: ping
<Riddell> go kubuntu images!
<stgraber> ScottL: I see your new amd64 image on the tracker has been tested, is it good for release or do you want more testing done first?
<stgraber> jibel: I think I'll finally be ahead of davmor2 on http://iso.qa.ubuntu.com/qatracker/reports/testers/top20 by the time we release! :)
<jibel> stgraber, your bot should be blacklisted ;)
<ScottK> These kind of stats are almost never fair.  I made the top sponsors list almost entirely on the basis of being the uploader for one KDE release.
<ScottK> (it has a lot of packages)
<Daviey> karma for doing an upload which happens to contains translations was always a good one.
<stgraber> jibel: hehe, don't worry you'll still be a long away ahead of me, especially once you get Jenkins to post the automated tests directly to the tracker :)
<ScottK> It got better since you didn't also get drowned in spam.
<ScottK> (for doing an upload with translations)
<stgraber> Daviey: best you can do is use a LP managed project (like LTSP): merge translations in trunk, release, add tarball to LP, merge tarball in UDD branch, tag, push the branch, upload the package
<stgraber> Daviey: that way you get twice the bazaar karma, twice the translation karma and you get the usual soyuz karma :)
<ScottK> BTW, AFAICT, syncs using syncpackage get you no karma.
<stgraber> Daviey: oh and I forgot karma for the bugs you fix in the upstream release and again in Ubuntu with the upload.
<Daviey> while true ; dch -i 'no change test build' ; debuild -S -sa ; dput ppa *.changes ; sleep 1h ; done
<Daviey> seems like reasonable karma-o-matic for soyuz
<Daviey> anyway.. nn o/
<stgraber> Daviey: add a few hundred bugs in that changelog entry and write a 10 lines python script moving them back to New before uploading ;)
<slangasek> stgraber: was the fix for bug #898278 tested to confirm that upgrades are still offered when the version installed *is* older?
<ubot2> Launchpad bug 898278 in ubiquity "Upgrade menu option should not appear for old releases" [High,Fix released] https://launchpad.net/bugs/898278
<slangasek> stgraber: I'm getting "erase" where I'm expecting "upgrade"
<slangasek> and I fear it may be related to misparsing of version strings with LTS in them
<stgraber> slangasek: IIRC I tested it and we have unit test coverage for those bits in ubiquity trunk
<stgraber> slangasek: and I seem to remember testing for point releases and stuff like that, let me have a quick look
<ScottL> stgraber, heh, i didn't know it had been tested yet, i was downloading it now....let me check
<slangasek> stgraber: hmm, ok.  so the case I'm testing is booting an amd64 desktop CD in a machine installed as 11.10 i386
<slangasek> and I'm expecting an upgrade option there
<stgraber> slangasek: hmm, odd, yeah it should definitely show up in that case
<stgraber> >>> re.split(".*([0-9]{2}\.[0-9]{2}).*", "12.04.1 LTS")[1]
<stgraber> '12.04'
<stgraber> slangasek: ^ that's the version parsing code used in ubi-partman
 * stgraber grabs an Ubuntu 11.10 i386 image
<ScottL> stgraber, i'm slightly confused, i have an email for 20120425 build but the qa site shows 20120423 as tested but still building a new image
<stgraber> ScottL: you're looking at Precise Final instead of Precise Pre-release
<stgraber> ScottL: look at: http://iso.qa.ubuntu.com/qatracker/milestones/214/builds for your new amd64 image
 * ScottK sends out his bi-annual "Boost version for $RELEASE" email.
<ScottL> stgraber, i see it now
<stgraber> ScottL: once it's good to go, I'll move it to Precise Final
<ScottL> oh, you are saying that
<ScottL> stgraber, checking with the person who tested it now
<stgraber> slangasek: if you want to have a look while I setup the environment here, it's around line 1780 in /usr/lib/ubiquity/plugins/ubi-partman.py
<ScottL> stgraber, okay, word is that it is good :)  thank you
<stgraber> ScottL: ok, moving it then
<slangasek> stgraber: yes, already looking
<balloons> ScottK, I can't get the do-release-upgrade -d to find the precise release
<ScottK> balloons: Install software-properties-kde from -proposed
<balloons> right -- maybe it didn't stick
<balloons> i have proposed enabled.. and everything is up to date
 * ScottK is on about a 4 second lag right now, so answers come slow.
<balloons> lol -- yep, I confirmed sources.list
<balloons> and updated
<slangasek> ScottK, balloons: the s-p-kde package doesn't autofix on install because it can't tell whether or not you've ever used the GUI
<ScottK> Oh.
<slangasek> it only fixes it if you run the gui again
<ScottK> So run the gui and see what happens.
<ScottK> Thanks.
<ScottK> Lag is only three seconds now.   Much better.
<balloons> ScottK, lol.. os i purged andinstalling it again from command line this time
<balloons> bah it's the same still..
<slangasek> stgraber: the 'reuse' option fails much earlier, ubi-partman.py line 2122
<ScottK> OK.  Gotta go.  BBIAB.
<Riddell> balloons: hi what are you testing?
<stgraber> slangasek: anything weird with your partitioning?
<slangasek> stgraber: no; ordinary vm
<stgraber> slangasek: if it fails there it's most likely a bug somewhere in partman
<stgraber> slangasek: I tried here and I get the Upgrade option
<slangasek> stgraber: with an amd64 CD over an i386 install?
<stgraber> slangasek: I installed Ubuntu 11.10 i386, full disk install in english. Then booted Ubuntu 12.04 amd64 and I see "Install alongside", "Upgrade", "Erase", "Something else"
<stgraber> that's stock 11.10 i386, never booted
 * slangasek nods
<slangasek> stgraber: do you mind testing if the 'upgrade' option works, since you have it there?
<stgraber> sure, running now
<stgraber> it's busy generating .debs now so at least that part seems to work. As I don't have any data or custom package installed on that 11.10 system it's going to be a bit tricky to check it actually did everything right
<slangasek> stgraber: sure; consider it a smoke test for now, hopefully I'll be able to do a fuller test in a little bit :P
<slangasek> blah, yeah, the bug is deep in partman
<stgraber> sorry you have to dig in there ;)
<slangasek> not digging any further
<stgraber> slangasek: install worked
<slangasek> ok
<slangasek> thanks for checking
<stgraber> slangasek: apparently the upgrade at least kept /home as I'm getting the old wallpaper (wallpaper is cached, so I need to switch to another one and back to warty-final to get the new one)
#ubuntu-release 2012-04-26
<astraljava> skaet: I tested Studio image, and it's not even prompting me for the codecs install when attempting to play mp4 video.
 * astraljava just notices that the images have been moved to final again
<Riddell> skaet: if you have any proofreaders at a lose end I have an announcement page (https://www-admin.kubuntu.org/news/12.04-release password restricted)
<bkerensa> skaet: is planned release still for 1200 UTC?
<bkerensa> skaet: Wondering if we have anything left on release notes that needs finishing before tomorrow
<Riddell> skaet: it is and I expect she has gone to sleep
<stgraber> right, I guess it's time for some sleep, talk to you all tomorrow
<jbicha> bkerensa: yes, feel free to improve the release notes
<bkerensa> jbicha: I already added the doc team and one other area
<pitti> Good morning
<pitti> slangasek: apt/oneiric> yes, it should be moved to -updates ASAP, was just waiting on jibel's test result (wasn't finished yet when I had to leave)
<pitti> slangasek: seems you moved it already, thanks
<pitti> slangasek: ah, pre-publishing done, thanks
<skaet> Good morning pitti
<pitti> hey skaet  -- still jetlagged?
<skaet> pitti, afraid so.  :(
<skaet> figure I'll get over it,  just in time to head back home,   lol
<skaet> brerensa,  target time isn't actually 1200 UTC.   Edits and improvements to the release notes are welcome until 0900 UTC.
<metze> hi, when can I expect the final iso images on the ftp server?
<pitti> "today"
<skaet> when the images are available,  it will be announced in #ubuntu-release-party.
<metze> skaet: thanks
<elmo> are we there yet?
<Daviey> elmo: Are you really that keen to update your infrastructure ? :)
<slangasek> he got tired of waiting and switched the servers to Gentoo
<utlemming> skaet: I'm going to bed, but I'll check in at 11:00 UTC ( 05:00 my time ) to be ready for the cloud image release.
 * utlemming goes to bed
<Daviey> utlemming: \o/
<skaet> thanks utlemming
<Kalidarn> hi, what time zone does https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule follow?
<Kalidarn> i had assumed it was UTC
<astraljava> Normally everything's announced in UTC, yes.
<astraljava> As can be witnessed right from the third sentence:"Freezes normally happen around 2100 UTC time of the given date."
<gema> skaet: have we realised that precise leaves the machine unresponsive when there is a lot of io going on?
<gema> even if you are writing to a different HD or external media
<pitti> gema: that bug is ancient indeed
<pitti> Linux really performs poorly when there is high IO
<pitti> mostly due to trashing the cache; /me looks for the bug
<pitti> https://bugzilla.kernel.org/show_bug.cgi?id=12309
<ubot2> bugzilla.kernel.org bug 12309 in Block Layer "Large I/O operations result in poor interactive performance and high iowait times" [High,Reopened]
<pitti> gema: ^  note the 540 comments... :/
<pitti> http://lwn.net/Articles/467328/ too
<gema> pitti: and why is it not fixed?
<gema> I can reproduce it every time
<gema> it even spits out logs in dmesg in Precise
<pitti> yes, me too; every time I rsync a CD image or copy a video to an USB stick or so
<gema> so why haven't we fixed it?
<pitti> but apparently it's ridiculously hard to fix, and there are conflicts of interest between desktop vs. server
<gema> pitti: then why haven't we gone back to a previous kernel for Precise?
<pitti> the HugeTLB problem that the LWN article describes is one side of the story; the other is probably very profane, the rsynced/copied file kills all your existing caches
<pitti> gema: how would that help? that problem has existed for many many years
<gema> pitti: this didn't happen to me in oneiric
<pitti> hm, maybe you see something different than me
<pitti> but rsyncs or copying huge files has caused my computers to grind down to a halt forever
<gema> pitti: http://paste.ubuntu.com/946880/
<gema> this is my dmesg
<gema> from the hang
<pitti> right
<pitti> that just says that the kernel notices the hangs
<gema> which wasn't there in beta2
<gema> which means someone has noticed and activated that
<gema> it wasn't on my machine, but my partner's back then
<pitti> that message isn't new
<gema> ok
<pitti> it behaves differently on different computers
<gema> ok
<gema> is this the same problem you are seeing?
<pitti> ironically, the problem gets worse with faster machines/drives
<gema> I see
<pitti> gema: that dmesg doesn't tell much really, except stating the obvious that your processes are hanging
<gema> I think it is a regression, it didn't happen to me with the oneiric kernel before yesterday
<gema> with the same disks
<pitti> i. e. the faster your shiny new SSD drive can shovel bytes into memory, the faster you get into a situation where caches and mempages are trashed
<gema> *same disks as yesterday*
<pitti> gema: if you can compare the same situation/drive/file/computer with oneiric vs. precise kernel, that certainly would be interesting
<gema> are you suggesting that I go back to oneiric?
<pitti> I did a comparison a while ago, between lucid, oneiric, precise, and they all sucked the same
<gema> that'd certainly fix the issue
<pitti> gema: no, you can install the oneiric kernel on precise and boot into this
<gema> that's a good point
<pitti> i. e switch between oneiric and precise kernels in grub
<gema> will do
<gema> but today I still have work to do on the upgrade bug
<gema> so this will have to wait for 12.04.1
<gema> pitti: if this had been symbian, I'd have stopped the phones from shipping on this problem
<pitti> given that the bug is ~ 5 years old, I'm not very optimistic, but let's see :)
<gema> pitti: this is a regression, please stop patronising me :P
<pitti> there are patches to make this problem better, but they are apparently not approriate for server
<pitti> so maybe we can apply it to -generic and not to the -server flavour
<gema> pitti: I need a kernel person to look at this, i think, I will talk to them today
<pitti> gema: right, looking forward to your comparison
<pitti> as I said, I cannot really help much here, as it has been equally bad in all ubuntu releases on my machines
<pitti> so I hope you find a difference
<pitti> then we'd at least have a handle on that problem and can bisect
<Riddell> morning
<gema> pitti: I will try
<pitti> hey Riddell
<stgraber> good morning
<astraljava> Morning stgraber!
<astraljava> Can you move Xubuntu images to Final? They're all marked as Passed (and most without bugs to boot).
<pitti> hey stgraber
<pitti> stgraber: in the same vein, skaet asked for all images to be moved to Final
 * skaet --> transfering to office,  biab
<sebsebseb> hi
<stgraber> astraljava, pitti: looking
<stgraber> pitti: do you know if she meant all Ubuntu images or really all of them? I'm still seeing some untested images
<pitti> skaet   when stgraber shows up,  if you spot him first,
<pitti>  ask him to move the remainder over to final.
<pitti> stgraber: I think "all", but you can just as well wait until she's back
<stgraber> yeah. I'll move what's fully tested and was signed off for now, will wait for the rest
<stgraber> Daviey, infinity need to sign off on the Netboot images
<astraljava> stgraber: Thankee!
<stgraber> ok, that's all the signed off ones moved
<metze> when will the final images appear on http://cdimage.ubuntu.com ?
<stgraber> waiting for sign off on netboot and for the +mac kubuntu images (didn't seem to get any more testing than they had yesterday)
<stgraber> Riddell: ping
<stgraber> Riddell: are you happy to release the +mac kubuntu images in their current state (one without a test and the other with just 1 out of 4 testcases covered)
<stgraber> ?
<Riddell> stgraber: I'd rather not until tested
<stgraber> Riddell: ok, anyone on it at the moment?
<Riddell> not that I know of alas
<stgraber> jibel: is that something QA can maybe help with? these are the only two untested images left on the tracker
<pitti> given that amd64+mac has the exact same livefs, and the only difference is the boot block, testing that it boots on a Mac should be sufficient IMHO; bonus for one finished test install :)
<jibel> stgraber, syncing images
<stgraber> pitti: thanks!
<infinity> pitti: Have we started any pre-publishing yet?
<stgraber> infinity: are the armel netboot images good to go?
<infinity> stgraber: They are.  Let me go sign thingees.
<stgraber> infinity: thanks, moving them then
<infinity> I'm going to take the liberty of signing off on the armhf netboot stuff for Daviey too.
<stgraber> skaet: so I moved everything that was signed off and tested. We only have netboot that's awaiting signoff (amd64 + i386), some upgrades weren't tested (flavours) and Kubuntu is still waiting for +mac results before considering them good to go
<pitti> thanks stgraber
<infinity> pitti: .pool looks fully populated and pushed, did you do that? ;)
<skaet> Riddell, ScottK,  any updates on Kubuntu +mac
<skaet> ?
<pitti> infinity: yes, me yesterday, slangasek over night after the respin (I double-checked md5sums)
<micahg> is there any chance of respins at this point?  Would I be ok to push out a security update a little later?
<skaet> micahg, hold off please
<infinity> elmo: We seem to be pre-published already as of some time last night, so mirrors should be settling, one would hope.
<micahg> ok, np, can wait
<infinity> micahg: If we respin, it would be because we discover the images actually physically blow up people's computers and kill their pets.
<micahg> infinity: ok, but that's still a maybe, so I'll push out the other releases and precise will go later :)
<jibel> Riddell, ubiquity crashes when I click on 'Create new partition table' in the manual partitioner on kubuntu mac. known issue ?
<Riddell> jibel: nope
<skaet> Riddell,  amd64+mac - signoff ETA?
<skaet> Daviey, aroslaes,  cloude images - signoff ETA?
<skaet> arosales, even.  ^ ?
<knome> skaet, release ETA? :]
<skaet> knome,  #ubuntu-release-party  ;)
<Riddell> skaet: jibel has just said it has a problem so probably none
<jibel> Riddell, and no trace of a crash just "KCrash: Application '' crashing..." in installer/debug
<Riddell> that means it's a pykde issue :(
<jibel> Riddell, can you try on a non-mac image ?
<Riddell> yeah let me do so
<jibel> start ubiquity, select 'something else' in partman and 'Create new partition table'
<pitti> jibel: does that work in ubuntu?
<jibel> pitti, yes
<pitti> I can't quite believe that this affects kubuntu amd64+mac only, and works in kubuntu amd64 and ubuntu amd64+mac
<pitti> unless kubiquity has some KDE specific UI presentation for Mac partitions?
<Riddell> nope
<jibel> I'm finishing the install of desktop and alternate and will try to reproduce afterwards
<Riddell> jibel: in "Prepare partitions" I click on /dev/sda then "New Partitions Table" button, it successfully removes the other partition line items and shows a new "free space" line
<Riddell> hello Millbank
<cjwatson> a KDE-specific bug on Macs isn't totally out of the question, IMO
<jibel> Riddell, 'entire disk' and 'auto-resize' passed
<jibel> Riddell, same bug than ubuntu with the manual partitioner (bug 987418) and the crash
<ubot2> Launchpad bug 987418 in ubiquity "manual partitioner: /dev/sdb (installation media) selected by default as device for boot loader installation" [Medium,New] https://launchpad.net/bugs/987418
<jibel> now trying alternate
<cjwatson> 987418 was one we just didn't have time to fix - it's nasty and unfortunate but I'm pretty sure we released 11.10 with at least some species of this bug (maybe not that specific manifestation)
<stgraber> skaet: do you have Daviey around?
<cjwatson> I've targeted it for quantal, and am going to create some quantal milestones now in order that I can milestone it :-)
<Daviey> stgraber: hey
<stgraber> Daviey: hey there. Are netboot i386 and netboot amd64 good to go? infinity signed off on all the arm ones
<Daviey> stgraber: thye are indeedy
<Daviey> stgraber: i signed them off the other day, no?
<stgraber> Daviey: the testing sign off field was empty when I looked this morning. infinity signed that line off but only for the armhf part
<stgraber> anyway, all good now
<cjwatson> sync-mirrors marked non-executable
<pitti> NB, the hangout says I'm not invited, so I'll watch IRC for now
<ogasawara> I notice the day-0 kernel is still in -proposed, will that get pocket copied soon?
<infinity> pitti: ^
<cdoktor19> hai everyones
<Riddell> "We're sorry, hangout is currently unavailable. Please try again later."  that's an ambigious error message
<pitti> ogasawara: it has one out of 11 bugs verified and is rather intrusive; I think it should get some more testing; few people are running -proposed yet
<pitti> ogasawara: but I haven't been in the loop of previous discussions/testing for this
<pitti> ogasawara: anyway, skaet said to hold off any -updates/-security stuff for now until we release
<ogasawara> pitti: ack.  I would add that I had test confirmation from each before even considering it for the day-0, although I cannot confirm if those testers have followed up and re-tested with -proposed.
<pitti> ogasawara: ah, that's good to know
 * pitti dist-upgrades to -proposed (did it yesterday, but we didn't have the kernel yet)
<gema> cyphermox: ping
<pitti> oh, skaet fell off the planet
<pitti> https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/CommonInfrastructure says "The default run time for Java is OpenJDK... " (literally)
<gema> I hope she's ok
<pitti> can I just edit that?
<pitti> or was that already copied someplace else (web team)?
<Riddell> I have the same question myself for Kubuntu r-n
<pitti> Riddell: presumably these all include /CommonInfrastructure (Ubuntu does, anyway)
<Riddell> the flavour release notes do yes
<gema> pitti: I have summoned skaet
<Riddell> yay!
<jibel> Riddell, kubuntu alternate mac is ok
 * skaet --> had to reboot.  
<Riddell> jibel: oh?  did that change from last time your tried?
<skaet> what's up?
<Riddell> skaet: don't worry I hear ubuntu has an upgrade coming soon, probably it'll fix that reboot issue :)
<ogra_>  /join #ubuntu-release-party
<ogra_> ergh
<pitti> skaet: https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/CommonInfrastructure says "The default run time for Java is OpenJDK... " (literally); can we still edit that?
<pitti> skaet: or was it alraedy copied to the web team?
<pitti> skaet: there is also quite some TODOs in the bugs, shall I take a stab at some verbiage around them?
<jibel> Riddell, it is the first time I try kubuntu alternate on mac
<jibel> Riddell, what did I report previously that I dont remember ?
<pitti> skaet: I also would like to make some grammar/stylistic improvements to https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop, still possible?
<Riddell> jibel: 09:15 < jibel> Riddell, ubiquity crashes when I click on 'Create new partition table'
<ogasawara> skaet, pitti: I would also note that if the day-0 kernel isn't available in -updates upon release, I'll need to edit some of the known kernel issues to mention -proposed instead of -updates.
<Riddell> jibel: isn't that the same thing?
<jibel> Riddell, ubiquity was kubuntu desktop.
<Riddell> oh alternate, gotcha
<jibel> Riddell, alternate was untested, that's what I did
<Riddell> lovely thanks
<skaet> pitti,  it needs to be edited to have an explicit version added.
<skaet> (please fix ;) )
<skaet> pitti,  yes please,  take a stab at the TODOs
<Riddell> jibel: I'll sign off on alternate then but not desktop
<pitti> skaet: right, I'll do that; I was just wondering whether these already got locked down
<pitti> skaet: so, editing
<skaet> thanks pitti.  baton for that page is yours.
<Riddell> skaet: do we have a final URL for the release notes yet or will it just be the same place on the wiki?
<apw> pitti, i am assuming we are going to be promoting the the day0 to -updates ... as soon as we are done with the release ... ?
<skaet> The wiki site will be final.   Other sites will be pointing to that page.
<Daviey> apw: https://bugs.launchpad.net/ubuntu-release-notes
<Daviey> pgraner: ^
<skaet> pitti, when you finish,  please signal,  pgraner, apw, and Daviey are taking a pass and adding ubuntu-release-notes into them.
<Daviey> infinity: bug 770627
<ubot2> Launchpad bug 770627 in libreoffice "LibreOffice - missing packages for ARMEL" [Unknown,Fix released] https://launchpad.net/bugs/770627
<gema> Daviey: the upgrade bug from yesterday night is not there
<pitti> skaet: done with https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop ; now editing CommonInfra
<skaet> thanks pitti
<cjwatson> if kubuntu alternate amd64+mac is good, can somebody move it to final?
<cjwatson> that would help my publishing wowrk
<stgraber> doing so now
<Riddell> thanks stgraber
<cjwatson> ta
<Riddell> stgraber: will you be updating your mirror before the announce?
<stgraber> Riddell: yes
<stgraber> Riddell: the images are already correct on it, I'll sync from cdimage as soon as the final directory structure shows up on it
<Daviey> pitti: do you want to add bug 600178 to known issues for Desktop Release notes known issues?
<ubot2> Launchpad bug 600178 in nvidia-graphics-drivers "Screen tearing when dragging window, in videos and other large screen redraws (on nVidia GPU)" [Undecided,Confirmed] https://launchpad.net/bugs/600178
<Riddell> stgraber: do you know if the se.cdimage.ubuntu.com guy is around to sync on time too?
<stgraber> Riddell: no idea
<pitti> Daviey: not sure how widespread it is, but we might as well
<cjwatson> confirm that it's intentional that kubuntu isn't on releases.ubuntu.com any more?
<cjwatson> the release manifest agrees with the publishing scripts here, but I just wanted to check
<pitti> I was told so for b2
<cjwatson> yes, I see ubuntu-archive-tools er382
<Riddell> cjwatson: I believe it is intentional
<pitti> Daviey: added
<cjwatson> OK, let me add a note on releases.ubuntu.com/kubuntu/ to avoid confusion then
<Riddell> thanks
<Riddell> stgraber: where is your mirror located?
<Daviey> pitti: thanks
<Daviey> jamespage: Does bug 870244 require user action (ie, release note worthy) - or does it DTRT now?
<ubot2> Launchpad bug 870244 in dovecot "mail-stack-delivery package install needs to restart dovecot" [Low,Fix released] https://launchpad.net/bugs/870244
<jamespage> Daviey, Fix Release for precise
<jamespage> so no
<Daviey> jamespage: thanks
<Daviey> pitti: do you want to resolve the release notes bug task? :)
<pitti> Daviey: yes, when I wrote the page
<cjwatson> is the Chinese edition tested?
<stgraber> Riddell: germany
<Riddell> ta
<skaet> gema, ^ has victor done a run with the latest Chinese image?
<Daviey> pitti: Sorry, it didn't look adjusted on the bug task to me.. but super.
<apw> ogra_, do you know if the beagleXM 1GHZ kernel restrcition is still valid in Precise ?
<skaet> gema,  I'm seeing that there has been testing on 20120424.1 images, so we'll be going ahead with them.
<skaet> http://localized-iso.qa.ubuntu.com/qatracker/milestones/215/builds
<ogra_> apw, hmm, ask linaro ?
<ogra_> the HW didnt change though
<pitti> skaet: https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/CommonInfrastructure?action=diff&rev2=50&rev1=49
<pitti> skaet: I'm done with the page for now
<skaet> thanks pitti.  :)
<davmor2> Daviey: did you get my message yesterday about the server docs?
<emdub> just double checking -- it's safe to download the 12.04-server/desktop iso's now correct?  i see them up but they have timestamps from a couple days ago
<pitti> emdub: no, it's not; they are not official until the announcement is sent
<emdub> k
<davmor2> Daviey: infact never mind I tried it it works as expected which threw me :)
<stgraber> Riddell: lunch time here. The mirror is monitoring changes on cdimage and syncing every minute, I see that kubuntu is being published now, so in just a few minutes you should have the mirror ready
<cjwatson> skaet: hmm, I went for Chinese edition amd64 20120425 since that was the sessioninstaller respin, but 20120424.1 is what's on the trackr
<cjwatson> *tracker
<cjwatson> skaet: do I need to roll that back to 20120424.1?
<Riddell> stgraber: enjoy your baguette
<Daviey> davmor2: i did, then you promptly went offline.
<Daviey> apw: Hey, is bug 898127 release notable ?
<ubot2> Launchpad bug 898127 in linux "system hangs and errors at /build/buildd/linux-3.2.0/arch/x86/kernel/apic/ipi.c:113 default_send_IPI_mask_logical+0xdc/0xf0()" [Medium,Incomplete] https://launchpad.net/bugs/898127
<davmor2> Daviey: yeah I tried it within the same folder and the code worked like mv only keeping the original when I tried it against a multibranched directory it worked as expected just me being overly cautious it seems :)
<skaet> stgraber,  could you try to boot 20120425 amd64 Chinese, and see if its basically sane.  I'd prefer to go with that one, rather than rolling back to the one on the tracker.
<skaet> possible?
<Daviey> apw: Do i grok bug 969304, we need a release note entry stating you need a more modern firmware for a particular nic?
<ubot2> Launchpad bug 969304 in linux-firmware "Regression: Missing Firmware Files phanfw.bin and nx3fwct.bin (precise 12.04 beta)" [Undecided,Invalid] https://launchpad.net/bugs/969304
<gema> skaet: victor tested with yesterday images
<gema> skaet: and they were good
<gema> skaet: same bugs as last week, nothing major
<Daviey> apw: bug 979253, has suggested wording
<ubot2> Launchpad bug 979253 in linux "BUG: unable to handle kernel paging request at c00fdd20" [Medium,Triaged] https://launchpad.net/bugs/979253
<skaet> thanks gema
<stgraber> skaet: yep, doing sanity check now
<d0od> You guys are _rockstarz_
<dholbach> hey d0od
<d0od> o/ dholbach
<stgraber> pitti: can you confirm that it's normal for the chinese image to have gfxboot in English by default and same for ubiquity?
<stgraber> (selecting simplified chinese works fine and I then get a fully translated session as the langpack is there)
<pitti> stgraber: hm, no; it's meant to pre-select the language in gfxboot
<pitti> it worked back then when I tested the local builds, but that's some months ago
<stgraber> pitti: hmm, ok... grabbing the i386 one to compare then
<pitti> stgraber: it's supposed to write the language into isolinux/lang on the CD, from where gfxboot is supposed to pick it up
<d0od> I'm not dumb - the release hasn't been announced yet has it? I'm getting a lot of tweets/tips saying it has
<pitti> stgraber: if you have the .iso handy, can you please check it?
<Riddell> d0od: please go to #ubuntu-release-party, we're busy here
<stgraber> pitti: looking
<dholbach> d0od, no, it's not - https://lists.ubuntu.com/archives/ubuntu-announce/2012-April/thread.html should be the safest place to find out if it is :)
<sladen>  /topic No, not released.  Please goto to #ubuntu-release-party | Archive: frozen | http://pad.ubuntu.com/ubuntu-release | Precise Pangolin Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or chocolate | melior malum quod cognoscis
<pitti> d0od: check www.ubuntu.com :)
<stgraber> pitti: nope, isolinux/lang is missing, only lang* there is isolinux/langlist
<pitti> stgraber: erk
 * pitti checks
<stgraber> pitti: same with the previous i386 image, so not a regression in the amd64 respin
<stgraber> I'm kind of surprised the chinese testers didn't see it though :)
<pitti> so, theh ubuntu-defaults-zh-cn .deb has language.txt
<pitti> at least we don't need to upload that one
<stgraber> pitti: iso listing: http://paste.ubuntu.com/947145/
<cjwatson> stgraber: indeed, considering that this was the *only* change in the first iterations of the Chinese edition
<pitti> and ubuntu-defaults-builder still has the handling for copying /usr/share/$PACKAGENAME/language.txt to binary/isolinux/lang
<pitti> I'll start a local build of the zh image, but it'll take a while
 * pitti looks for build logs in the meantime; unfortunately u-d-i is not very verbose there
<stgraber> skaet: so, .iso is broken (as discussed above) but livefs looks good, post-install experience is properly translated, ibus is working (chinese input works fine) and the gstreamer fix works as expected
<stgraber> skaet: so both chinese images will need a respin to include the missing gfxboot file but we can keep the current livefs and just re-test gfxboot
<pitti> [2012-04-25 17:46:41] lb_binary_local-hooks
<pitti> P: Begin executing local hooks...
<pitti> thanks pitti for making that so verbose!
<pitti> at least there's no error message
<stgraber> ;)
<skaet> stgraber,  thanks for figuring that out.   cjwatson ^ lets yank them.
<cjwatson> I'm going to pull those images off china-images.ubuntu.com/releases/precise/
<cjwatson> to avoid confusiong
<cjwatson> -g
<skaet> thanks.
<cjwatson> they're gone
<stgraber> I can re-test both images within ~15 minutes (download + live environment test + install + post-install test), so let me know when you have something to test
<cjwatson> the mechanics of a respin will involve a livecd-rootfs or live-build upload to -proposed and an emergency promotion to -updates, I suppose
<cjwatson> and we'll have to check that the livefs chroots use -updates
<Daviey> utlemming: good morning!
<utlemming> morning Daviey, did you not go to bed, or where you up early?
<Daviey> utlemming: sleep is for the weak..
<Daviey> utlemming: Are you all set?
<utlemming> Daviey: Yes, just awaiting the word.
<highvoltage> good morning everyone!
<Daviey> utlemming: WORD.
<Daviey> utlemming: Cloud images should be published.
 * utlemming starts publishing cloud images
<pitti> cjwatson: oh, you already have a workaround in mind  or see the bug?
<pitti> I don't see it yet
<pitti> local image still building, ETA 20 or 30 mins
<cjwatson> pitti: I don't, but I mean, you're likely going to have to put something in -proposed, right
<cjwatson> It's unlikely to be fixable nusakan-side
<Daviey> utlemming: then go back to bed. :)
<utlemming> Daviey: lol
<stgraber> Riddell: http://www.stgraber.org/download/releases/ is ready
<ogra_> ARGH
 * ogra_ curses
<ogra_> indeed i used the wrong image names when updating all the arm install wikipages
 * ogra_ should have checked nusakan first 
<stgraber> Riddell: "This directory contains only less-used images which are not mirrored widely. For the most frequently downloaded CD images, see releases.ubuntu.com. Please use a mirror if possible." => that's now wrong isn't it?
<cjwatson> where's that?
<stgraber> cjwatson: kubuntu release directory on cdimage
<cjwatson> oh right, one moment
<Riddell> thanks stgraber
<cjwatson> stgraber,Riddell: fixed pending mirroring
<Riddell> thanks cjwatson
<stgraber> Riddell: looks like someone already found the kubuntu images on the mirror, I'm pushing at around 300Mbps at the moment
<apw> doko, are you still editing commoninfrastructure ?
<doko> apw, yes, adding toolchain changes
<apw> doko, ok cool, you might want to preview again as you timed out
<peterm-ubuntu> it's live!
<Riddell> cor
<utlemming> cloud images are published
<Riddell> stgraber: let me know if you get overloaded and I'll remove it from the download page
<pitti> err, WTF
<Riddell> ?
<pitti> stgraber: I'm afraid we'll need to respin the squashfs as well :/
<pitti> cjwatson: ^
<sladen> just zh_cn ?
<pitti> it seems during language cleanup it removes ubuntu-defaults-zh-cn
<cjwatson> haha, score
<pitti> so it's not installed any more in the chroot
<pitti> sladen: yes
<stgraber> pitti: ok
<cjwatson> have you found the bug, or just diagnosing still?
<pitti> I reproduced locally
<pitti> build just finished
<pitti> debugging now
<pitti> presumably a bug in language-selector, but I'll try to find another workaround
<doko> apw: done
<pitti> cjwatson: ok, found the bug
<pitti> language-support-hook uses check-language-support to determine the packages installed for the langauges we want to remove (es and pt here)
<pitti> which includes poppler-data
<pitti> language-support-hook then purges them all, which removes u-d-zh-ch as it depends on poppler-data
<pitti> so, there is an easy, but not fully correct workaround, testing now
<pitti> a complete fix is quite a bit more involved, but we don't need it for the Chinese image yet
* ChanServ changed the topic of #ubuntu-release to: Ubuntu 12.04 (Precise Pangolin) is released! | Precise Pangolin Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or chocolate | melior malum quod cognoscis
<pitti> \o/
<pitti> cjwatson, stgraber: ok, local test build running; shoudl be faster now, as I have all the .debs in the cache
<stgraber> pitti: k
<cjwatson> mvo: have you poked meta-release?
<mvo> cjwatson: no, was waiting for the signal, but I can do it now
<pitti> cjwatson, skaet: when I have a confirmed fix for ubuntu-defaults-image, should I upload to precise-updates to save a publisher cycle, or to -proposed?
<cjwatson> -proposed, please
<pitti> ack
 * pitti files a bug while the test build runs
<cjwatson> -updates will just reject your upload
<cjwatson> (I'm pretty sure)
<cjwatson> Hm, well, I guess it might get held for approval, but let's do it by the book anyway.
<pitti> yes, straight -updates does work, I accidentally accepted a package after oneiric's release
<pitti> but yes, doing -proposed
<cjwatson> ah, ok
<cjwatson> I'm evidently thinking of pre-release
<pitti> I guess we can't upload to precise-release any more
<pitti> so do we need to adjust cdimage etc. to take ubuntu-defaults-builder from -updates?
<cjwatson> It should do that itself
<cjwatson> I think
<pitti> bug 988836 FTR
<ubot2> Launchpad bug 988836 in ubuntu-defaults-builder "Chinese images: Removes ubuntu-defaults-zh-cn" [High,In progress] https://launchpad.net/bugs/988836
<cjwatson> ... apparently not, infinity's gonna look at it
<stgraber> xdatap1: ^ is that bug affecting you?
<xdatap1> stgraber, I don't think so, but let me check
<pitti> xdatap1: check your build log whether it removes ubuntu-defaults-it
<stgraber> xdatap1: basically on the Chinese images this causes any system configuration to be broken and the default language in gfxboot and ubiquity to fallback to English instead of Chinese
<pitti> xdatap1: if your metapackage depends on e. g. poppler-data or another "generic" language support package (that's the only one I can think of), your images won't default to Italian and won't have all the other custom settings
<xdatap1> pitti, stgraber : just checked, we're not affected
<pitti> first attempt for a fix failed, darn
<pitti> so I'm afraid I need to aim for a quick workaround
<xdatap1> pitti, stgraber : we ran into this, let me find the old bug
<highvoltage> Edubuntu 12.04 is released: http://edubuntu.org/news/12.04-release
<xdatap1> pitti, stgraber : Found: https://bugs.launchpad.net/ubuntu-defaults-it/+bug/948264 We tryied to depend on hunspell and it caused the metapackage removal and the problem above. We solved fixing the package
<ubot2> Launchpad bug 948264 in ubuntu-defaults-it "unity launcher customization doesn't works" [Undecided,Fix released]
<pitti> xdatap1: ah, you can dupe that to bug 988836
<pitti> I'm working on a general fix now
<ubot2> Launchpad bug 988836 in ubuntu-defaults-builder "Chinese images: Removes ubuntu-defaults-zh-cn" [High,In progress] https://launchpad.net/bugs/988836
<xdatap1> pitti, it's not an issue for us anymore
<infinity> pitti: FWIW, we've fixed the precise livefs chroots to pull from updates.
<pitti> infinity: thanks
<stgraber> skaet: 12:42 < tumbleweed> loltypo https://www.facebook.com/ubuntulinux/posts/441913515834848
<tumbleweed> stgraber: ah, thanks. Didn't know who to wave that at, but people are poking me about it :)
<stgraber> skaet: URL is wrong, not sure who's in charge of the account but it should be fixed
<stgraber> tumbleweed: at least the comments are wrong in that the domain is canonical owned and was used in the past for the staging www.ubuntu.com site, but it's currently out of date
<tumbleweed> ah, didn't know that
<ogra_> well, it forwards you properly to www.ubuntu.com
<ogra_> (which only shows a drupal error though)
<tumbleweed> doesn't forward me
<ogra_> did it for me
<stgraber> ogra_: that's new then, when I hit www.ubunut.com a few minutes ago I'd get the content of www.ubuntu.com from 10.10 time
<Laney> someone was probably scrambled to fix it :P
<ogra_> hmm, it *did* forward me a moment ago
<ogra_> now it doesnt anymore
<Laney> I would imagine jono or dholbach could look at that
<ogra_> but they both show the same drupal error
<Laney> (the borked update)
<dholbach> Laney, I can't see how I can edit a post
<dholbach> I can delete it though
<dholbach> ubunut.com is offline now
<dholbach> ugh, ubuntu.com too
<ogra_> dholbach, known
<ogra_> (being worked on already)
<skaet> stgraber,  its being handled.   Should be fixed soon.
<stgraber> skaet: thanks
 * pitti runs another zh image test build
<pitti> would anyone have some time to eyeball my currently tested diff?
<pitti> I have tested it in isolation, now testing full image build
<pitti> http://paste.ubuntu.com/947295/ in case anyone has time to review/discuss
<Sjimmie> hi. Here I have the first upgrade bug report. Upgrading fromm ubuntu server 10.04 to 12.04 (LTS -> LTS).
<cjwatson> Please report bugs in Launchpad
<cjwatson> We don't have capacity to take everyone's bug reports on IRC
<Sjimmie> http://pastebin.com/bGecwns5
<Sjimmie> looks quiet enough here :)
<cjwatson> And you'd be better off using do-release-upgrade
<cjwatson> You only just joined
<cjwatson> (Anyway, IRC isn't sanely set up for doing analysis of bugs, even if the channel is quiet.)
<Sjimmie> I did a do-release-upgrade. that crashed. then I did the dist-upgrade -f afterwards, as suggested
<Sjimmie> I know you are right cjwatson but would you have any suggestions anyway to help me along atm :-)
<ogra_> for support try #ubuntu
<cjwatson> No, I'm busy, sorry
<cjwatson> This is *not* a good day for non-release-related questions
<cjwatson> (I mean, not related to my side)
<Sjimmie> no problem and thanks
<cjwatson> pitti: Fun!  Looks OK insofar as I can evaluate it
<pitti> cjwatson: so my approach is to substract all packages which the requested languages need from the "to remove" list
<pitti> I renamed REMOVE_LANGUAGES to "remove", as the other *_LANGUAGES are file names, while REMOVE_LANGUAGES was a value list, that was confusing
<ttx> hmm. Just downloaded ubuntu-12.04-desktop-amd64.iso and got wrong MD5SUM
<ttx> I did it twice to make sure, got:
<ttx> 57876b3740ee89e75c8fefc93a7ceee6  ubuntu-12.04-desktop-amd64.iso
<pitti> ttx: it should be 128f0c16f4734c420b0185a492d92e52
<pitti> I chhecked the pre-published md5sum this morning, that was alright
<ttx> pitti: I tried twice (on release.ubuntu.com) and got 57876b3740ee89e75c8fefc93a7ceee6 twice
<dwatkins> http://releases.ubuntu.com/precise/ ttx?
<pitti> that's the one from cdimage.ubuntu.com/daily-live/20120423/
<ttx> dwatkins: $ wget http://releases.ubuntu.com/precise/ubuntu-12.04-desktop-amd64.iso
<pitti> but we released build 25.1
<ttx> which followed to http://d3qnbzt7ix5jlv.cloudfront.net/ubuntu-12.04-desktop-amd64.iso
<pitti> http://releases.ubuntu.com/precise/MD5SUMS has the right md5sum
<cjwatson> Do people have an opinion on whether quantal should be syncing from testing or unstable?
<cjwatson> Prior practice is unstable for non-LTS, but wgrant asked, so I thought I'd check.
 * ogra_ would vote for unstable
<pitti> I actually think testing was better
<tumbleweed> we're expecting debian to freeze during the cycle
<ttx> pitti: maybe some part of the CDN still have an old image ?
<tumbleweed> but that shouldn't affect the decision much, as unstable doesn't digress far in the early freeze
<pitti> ttx: I checked the image on nusakan, that seems alright
<pitti> 128f0c16f4734c420b0185a492d92e52  simple/releases/precise/ubuntu-12.04-desktop-amd64.iso
<pitti> ttx: we indeed pre-published an older image two days ago
<Laney> I think I probably prefer testing
<pitti> but I would have expected most mirrors to catch up by now
<Laney> Location: http://d3qnbzt7ix5jlv.cloudfront.net/ubuntu-12.04-desktop-amd64.iso [following]
<Laney> 57876b3740ee89e75c8fefc93a7ceee6  ubuntu-12.04-desktop-amd64.iso
<ttx> Laney: same here
<cjwatson> If I use testing, it's hard to change later.  If I use unstable, it's arguably even harder to change later.
<ttx> pitti: could it be that the CloudFront mirror didn't get the memo ? Or failed updating ?
<ttx> kinda bad since it gets most of the releases.ubuntu.com hits
<cjwatson> Uh
<pitti> ttx: I don't know how that's wired, sorry; just weird that it woudl catch the first sync-mirrors, but not the others sent after that
<cjwatson> So cloudfront was I think published directly by hand by elmo rather than synced from releases.ubuntu.com
<cjwatson> I suspect he published the wrong one
<cjwatson> I'm loath to interrupt him since he's in a web panic, but I think I'll have to
<ttx> cjwatson: blame me :)
<pitti> ttx: thanks for catching this!
<ttx> pitti: Good thing I was late in my download, I usually update my ISO before the madness starts
<wgrant> cjwatson/others: Are you still manually running the LP cdimage prober, or has it gotten confused?
<ScottK> Can I still add to the release notes (just got enough info to have a reasonable release note - i.e. here's how you dig your way out of the hole the bug causes)?
<afflux> hi guys. not sure if this is right place, but ubuntu-12.04-alternate-amd64.iso seems to have wrong checksums on http://releases.ubuntu.com/precise/ - the torrent download is correct though.
 * pitti boots kvm -m 1024 -vga std -cdrom binary-hybrid.iso and can't read a thing -- I guess that means it's working :)
<pitti> I also double-checked the list of removed packages, see bug
 * pitti prepares upload
<pitti> afflux: you are, ttx just reported that as well; being worked on
<afflux> ah. seems i joined a few minutes late ;)
<afflux> thanks
<ttx> afflux: good to see other people check md5sums on their downloads :)
<cjwatson> ttx: OK, being worked on
<cjwatson> wgrant: I don't run that, somebody in IS was doing it
<ttx> cjwatson: cheers
<wgrant> cjwatson: Ah, OK.
 * dwatkins greatly appreciates the efforts of the release team and all others working on Ubuntu
<afflux> ttx: well, tbh, I just ran the integrity test and it worked. checked the release type and since it was ok, it's installing on the test box here... ;)
<pitti> ogasawara, skaet: so should we move the kernel to -updates now?
<pitti> and perhaps a few other SRUs which already are verified?
<ogasawara> pitti: +1 from me
<pitti> ogasawara: we are getting in positive test results, and working fine here as well
<ogasawara> pitti: I'd also add QA did an informal test of it yesterday as well and had positive feedback
<pitti> cjwatson: if you want to pre-review before LP diff hits, https://code.launchpad.net/~pitti/ubuntu/quantal/ubuntu-defaults-builder/trunk r142 to 145
<pitti> I'm not quite sure why ubuntu:ubuntu-defaults-builder currently expands to that ~pitti branch, but that's something I don't worry about right now
<pitti> (it'll most probably resolve itself in the next days)
<cjwatson> pitti: accepted, thanks
<cjwatson> I just downloaded the files and diffed
<pitti> cjwatson: I suppose we don't have a foolproof way of actually building a new zh image from -proposed, so want me to move that to -updates as soon as it's published in LP?
<cjwatson> pitti: Yes please
<pitti> ah, ubuntu.getDevelopmentSeries() returns [] ATM; /me adds a fallback to sru-release
<cjwatson> That'll be fixed soon ...
<pitti> quantal is "frozen", I guess it doesn't accept that
<cjwatson> odd
<cjwatson>         return Store.of(self).find(
<cjwatson>             DistroSeries,
<cjwatson>             distribution=self,
<cjwatson>             status=SeriesStatus.DEVELOPMENT)
<cjwatson> huh, ok
<cjwatson> pitti: use .current_series instead
<pitti> ah, that will DTRT? thanks
<pitti> >>> ubuntu.current_series
<pitti> <distro_series at https://api.launchpad.net/1.0/ubuntu/quantal>
<davmor2> skaet: you know the Canonical link in the release email don't seem to connect to anything?
<pitti> cjwatson: thanks, committing
<cjwatson> that's "frozen if there is one, else development if there is one, else current if there is one, else series[0], else None"
<skaet> davmor2: there have been some web problems and its a casualty.  Will be working soon.
<davmor2> skaet: I noticed :) We'll put it down to just pure demand for the iso and carry on as normal :)
<pitti> 0-day SRU release wave comming, brace for impact queuebot
<pitti> "coming", too
<phillw> oooh, here we go again!
<ogra_> sweet !
<Laney> quantal-release eh
<pitti> :)
<tumbleweed> \o/
<cjwatson> Those'll wait a bit :)
<phillw> pitti: just a dumb question, but will these be in the daily build?
<Laney> did we decide on testing or unstable?
<cjwatson> phillw: what daily build
<ogra_> lol
<cjwatson> Laney: I initialised as testing for now and I'll start off syncing from testing, since that's easier to undo latere
<cjwatson> *later
<Laney> fair
<Laney> it is probably somewhat less interesting than usual given the freeze
<pitti> oh, why are the quantal syncs landing in NEW instead of unapproved?
<cjwatson> because it hasn't been initialised yet
<tumbleweed> cjwatson: syncpackage is still going to do unstable by default
<cjwatson> christ knows what you just did to the db
<phillw> cjwatson: I did mention it was a dumb Q :) Just wondered if the cron will still do a daily build with the 0-day SRU's
<pitti> cjwatson: ah, I better keep them in the queue then
<cjwatson> pitti: please DO NOT DO NOT DO NOT accept them
<cjwatson> phillw: no, daily builds are off for the foreseeable
<pitti> ... or I better reject them then, and make a TODO list which pacakges need copying
<cjwatson> pitti: wait
<cjwatson> I'm asking lpops
<phillw> thanks :)
<cjwatson> pitti: Leave them in NEW< it's sfine.
<cjwatson> with typing.
<pitti> cjwatson: too late, I'm afraid, but I have a local list now
<pitti> I'll catch up with them once it's open
<Laney> I thought it was possible to accept from rejected anyway
<pitti> I guess it minimizes the risk of someone accidentally accepting them
<cjwatson> Laney: it is
<cjwatson> pitti: yeah
<Laney> tumbleweed: why doesn't it use the parent series from LP?
<pitti> cjwatson: was the publisher disabled on purpose?
<cjwatson> tumbleweed: I'm OK with that, I think.
<cjwatson> pitti: HELL YES
<pitti> I'm asking because that defaults-builder thing needs publishing
<cjwatson> pitti: Sorry, you'll have to wait now
<pitti> *nod*
<cjwatson> I'm not prepared to run the publisher while a series is initialising
<pitti> oh, that's fine
<cjwatson> tumbleweed: Since syncpackage is a manual operation, there's at least some chance that that's what the developer wanted.
<pitti> I was just wondering if it was a leftover from final release preps
<tumbleweed> Laney: we could probably do that now, yes
<cjwatson> pitti: No, it's an explicit step on NewReleaseCycleProcess.
<Laney> I think it would be better for people to have to explicitly ask to deviate from the default
<Kalidarn> okay that's strange why might i be seeing Requested download is not authorized for use with this tracker.
<Kalidarn> for ubuntu-12.04-dvd-amd64.iso
<tumbleweed> Laney: yeah, that's how we've handled it in the past
<Kalidarn> was that pulled from the tracker?
<cjwatson> Kalidarn: The tracker was having trouble coming into sync earlier.
<cjwatson> It should sort itself out eventually ...
<Kalidarn> the kubuntu dvds worked fine
<Kalidarn> people are thrashing cdiimage :D
<Kalidarn> it's giving me 8-13 KB/s lol
<cjwatson> Yes, that tends to happen on release day.
<Kalidarn> but i guess that's what torrents are for :D
<Kalidarn> which i don't mind using and seeding
<Kalidarn> ubuntu-12.04-dvd-amd64.iso
<Kalidarn> ubuntu-12.04-dvd-amd64.iso
<Kalidarn> apparently 1.66GB according to my torrent client, man that is small
<Kalidarn> i was sure 11.10's dvds were bigger
<ScottK> Kalidarn: This isn't the channel for idle chatter about the release.  See #ubuntu or #ubuntu-release-party (they were - read the release notes).
<Kalidarn> ah true, i only came here to ask about the authorization error.
<arosales> Daviey: thanks for your testing comment for armhf cloud images on the release manifest
<Daviey> arosales: np
<ogra_> cjwatson, i assume you have "adding quantal to debootstrap scripts" somewhere on your TODO ? (wookey just asked me about it )
<cjwatson> ogra_: Yes
 * ogra_ thought so :) 
<cjwatson> in fact I did it locally the other day
<ogra_> these impatient linaroers
<cjwatson> Anyone can look at NewReleaseCycleProcess to see the current TODO
<cjwatson> pitti: Publisher re-enabled.
<tumbleweed> is the parent series mutable after the series has been initialised?
<cjwatson> No.
<cjwatson> But it doesn't matter much since it's just for localpackagediffs and friends, so screw it.
<pitti> cjwatson: thanks; I'm off for some 20 minutes (supermarket), will copy to -updates when I'm back (until you or someone else beats me to it)
<cjwatson> We'll figure something out if it turn out to mattere.
<cjwatson> *matter
<tumbleweed> cjwatson: well, laney was proposing using it for syncpackage, but if it isn't mutable, that doesn't help us
<cjwatson> pitti: The publisher will only barely have started by then.  I'm not really in the mood to run stuff by hand :-)
<cjwatson> tumbleweed: I think it might be better not to for now.
<tumbleweed> yup
<cjwatson> Apparently changing it would involve recomputing all the DistroSeriesDiffs and nothing's set up to do that.
<Laney> that's unfortunate
<gema> we just released and you guys are starting quantal already? O_o... give us some time to recover! :P
<ogra_> no way
<ogra_> we get bored without a dev release
<gema> follow pitti's lead, go to the supermarket !
<pitti> ^ accepting, as discussed
<pitti> will rebuild zh-CN image once that is published
<pitti> ah, unapproved now
<pitti> so that seems to work now
<cjwatson> Yes, please don't accept until we have the initial toolchain sync done though
<pitti> cjwatson: ok, won't do; but at least that flushes my local list of missing 0-day stuff
<pitti> cjwatson: (i. e. stuff copied to precise-updates)
<pitti> none of them will build again, so it's actually quite independent from the toolchain; but it's not urgent at all, so just queueing it up there is fine
<cjwatson> I know, but I would like to not get confused
<bdmurray> it looks to me like the metarelease files didn't get updated on the server
<bdmurray> http://changelogs.ubuntu.com/meta-release-lts
<bdmurray> I'm fixing this now
<bdmurray> hrm
<Laney> I think that's only changed at .1 time
<bdmurray> then people running 10.04 won't see that 12.04 is available is that not right?
<Laney> right, until 12.04.1, as is conventional
<cjwatson> bdmurray: As Laney said, please leave meta-release-lts alone until .1.
<bdmurray> cjwatson: got it
<pitti> argh, apparently defaults-builder missed a publisher run
<pitti> cjwatson: are you still online in 30 mins? if so, woudl you be able to trigger a zh image run?
<pitti> we've got some guests, and I'd like to go AFK for a bit
<cjwatson> pitti: Yes
<cjwatson> pitti: The publisher's been on and off.  This one caught it.
<pitti> thanks
<pitti> so, have a nice evening everyone!
<davmor2> cjwatson: = Welcome to Ubuntu 12.04 'Precise Pangolin' = is the header in the release notes for upgrades should it be =Welcome to Ubuntu 12.04 LTS 'Precise Pangolin'= ?
<slangasek> davmor2: yes
<cjwatson> davmor2: -> mvo
<davmor2> also first line reads The Ubuntu team is proud to announce Ubuntu 12.04 'Precise Pangolin'.
<davmor2> cjwatson: I'll go let him know
<davmor2> cjwatson: meh no mvo it seems :(
<knome> looks like xubuntu doesn't have amd64 torrents. reason?
<knome> 19:24  pleia2: hmm, I guess we have them on our regular download page but not on torrent.ubuntu
<cjwatson> knome: dunno, torrent's been having some trouble but I really don't know what's going on with it
<knome> looks like they are available in cdimage.u.c but not torrents.u.c :/
<cjwatson> Indeed
<cjwatson> Which is due to magellanic having a serious sad
<knome> kick it (him/her?) :P
<cjwatson> Not *sure* that would help
<cjwatson> (it)
<knome> sometimes it helps though.
<knome> at least yourself.
<ogra_> cjwatson, Daviey, skaet, hmm, if LTS to LTS is only offered for .1 https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuServer#From_10.04_to_12.04 should probably state that
<ogra_> people in #ubuntu get clearly confused by the current text and expect upgrades to work right now now
<knome> ogra_, is that supposed to be true for all derivatives/versions?
<ogra_> knome, for LTS to LTS (see discussion above)
<knome> ogra_, a-ha, ok
<cjwatson> knome: Can you try again now?
<cjwatson> I see them on torrent.ubuntu.com:6969.
<knome> torrents.u.c or cdimage.ub.c ?
<knome> -b
<cjwatson> torrent
<knome> i just tried the latter, said can't
<knome> ok, just a sec
<knome> http://torrent.ubuntu.com/xubuntu/releases/precise/release/desktop/
<knome> where's the amd64 one? :/
<cjwatson> huh, wtwf
<cjwatson> that is indeed missing on the master
<cjwatson> ok, I might have been maligning magellanic then
<cjwatson> I bet this is another purging bug
<knome> the torrent *files* are at http://cdimage.ubuntu.com/xubuntu/releases/precise/release/ though
<skaet> ogra_,  the testing prior to release indicated it should be reasonable to do Lucid to Precise.   hmmm....
<cjwatson> so much stuff breaks with publishing different arches out of sync
<cjwatson> skaet: please don't, foundations has been working on the assumption that we'll only enable starting from .1
<ogra_> skaet, well, i thought doing LTS to LTS only at .1 was policy
<ogra_> its just that the text on the server page suggests you should see them right now
<knome> cjwatson, 'Tracker gave an error: "Requested download is not authorized for use with this tracker."'
<skaet> Daviey,  ^  thoughts?
<Daviey> skaet: Colin is looking at it right now with IS
<knome> wait... i'm downloading
<ogra_> Daviey, at the wikipage ??
<Daviey> sorry, confused with the lines
<ogra_> heh
<Daviey> ogra_: can you comment on the exact strings which are confusing?
<ogra_> Daviey, there is no upgrade path from 10.04 to 12.04
<ogra_> Daviey, only from 10.04 to 12.04.1
<Daviey> ogra_: yes there is... we just don't prompt it.
<cjwatson> right (in-person conversation)
<ogra_> we dont enable automatic upgrades for 12.04
<Daviey> ogra_: no, 10.04 to 12.04 upgrade is supported, just not prompted
<cjwatson> if at least *some* people don't upgrade manually, we won't find out about problems in time to fix them for .1
<ogra_> Daviey, then it shold point out that you need to use -d
<cjwatson> but we won't enable it automatically until we've had some manual reporting
<ogra_> do-release-upgrade alone doesnt do it
 * Daviey looks
<slangasek> skaet: bug #988941 looks like one good reason not to recommend 10.04->12.04 upgrades yet...
<ubot2> Launchpad bug 988941 in update-manager "Doing an upgrade from 10.04 to 12.04 (LTS -> LTS) using an ISO" [High,Incomplete] https://launchpad.net/bugs/988941
<knome> cjwatson, don't know if you catched that, but even with the error, i'm able to download and upload with the torrent file
<cjwatson> depends whether other folks are seeding
<cjwatson> I'm pushing out something that should improve matters now
<skaet> slangasek,  hmm... not much data.  yup.  going to be interesting.    Feel free to add the tweaks you want to the release notes to mitigate this.
<slangasek> skaet: bdmurray and I have analyzed it a bit already, I know what's going on there and what we need to fix for .1
<slangasek> still writing it up though
 * ogra_ thinks the -d switch should be added but also a warning 
<ogra_> (for the upgrade docs that is)
<skaet> thanks slangasek.
<Daviey> ogra_: I just reproduced and we do indeed need the -d
<ogra_> right
 * skaet will look into things after dinner.   Been long day and food is overdue. 
<slangasek> ogra_: we've certainly not told people in the past in any prominent documentation to use -d for LTS upgrades before the switch is flipped?
<ogra_> i reproduced it with 4 people in a row in #ubuntu
<ogra_> slangasek, well, people want to upgrade and it doesnt work without -d
<slangasek> yes, and we don't want people to be upgrading yet which is why you need the -d
<slangasek> it's fine to point people at that if they ask
<slangasek> but we don't want to promote it in the docs
<ogra_> but we also want datapoints from people using 12.04
<ogra_> ah, k
<cjwatson> Please don't accept gcc-4.7 yet
<cjwatson> I'll accept base-files and lsb
<cjwatson> Once base-files has built and published, gcc-4.7 can start; not before
<ogra_> Pici, see discussion above :)
<Pici> ogra_: I'll take a look.
<cjwatson> I've uploaded debootstrap to unstable - I'll sync it tomorrow
<cjwatson> (We might be able to copy gcc-4.7 from the PPA instead.)
<knome> cjwatson, looks like the torrents do not throw an error any more. yay!
<knome> cjwatson, and the .torrent files show up in torrent.ubuntu.com, not the .iso files though :)
<knome> ah, the .iso files are now available there too :)
<knome> cjwatson, everything seems to be okay now. thanks!
<bdmurray> it seems that 'update-manager -d' from 10.04 indicates that 12.04 is a beta
<knome> 'beta' as in the 'google mail beta' ?)
<ogra_> ouch
<bdmurray> I think its because of DevelReleaseAnnouncement in update-manager
<bdmurray> slangasek: ^
<slangasek> bdmurray: should be fixable with an update-manager SRU to precise then, right?
<bdmurray> slangasek: yes
<bdmurray> I think there is a u-m in proposed already though
 * slangasek checks
<slangasek> so there is
<slangasek> bdmurray: but it's also a text-only change, so we can clobber that one
<slangasek> bdmurray: can you do the SRU?
<bdmurray> slangasek: in a bit yes
<slangasek> ok
<tgm4883> Is there someone here that can assist with a Ubuntu tracker issue?
<tgm4883> mythbuntu-12.04-desktop-amd64.iso isn't listed on http://torrent.ubuntu.com:6969/
<tgm4883> i386 is
<tgm4883> I have users reporting Failure reason "Requested download is not authorized for use with this tracker."
<bdmurray> slangasek: wehn you said clobber you meant use the same version number?
<slangasek> bdmurray: no, soyuz doesn't allow that - increment the version, but upload w/o putting the first SRU to -updates
<slangasek> bdmurray: so build with a -v option so that the changelog reflects all changes vs. what's currently in precise
<slangasek> tgm4883: is that the same issue knome was inquiring about a little bit ago?
<slangasek> no, knome was asking about xubuntu
<tgm4883> IDK, I wasn't in here. I don't see anything about knome
<tgm4883> there are 4 xubuntu 12.04 torrents it seems
<knome> tgm4883, i got that message too with xubuntu torrents, but was able to download and upload
<tgm4883> that seems to be working
<knome> tgm4883, they work perfectly (with no errors) now though
<tgm4883> knome, all 4 xubuntu ones are listed, I only see 1 of 2 Mythbuntu 12.04 torrents listed
<tgm4883> I'm not in a place I can test though
<knome> hmmh
<knome> tgm4883, did you look from cdimage.ubuntu.com too ?
<tgm4883> knome, yea it's listed on cdimage.ubuntu.com
<slangasek> cjwatson: ^^ mythbuntu is having the same problem that xubuntu was earlier with torrents; I don't know what you did to fix xubuntu
<phillw> cjwatson: is it okay for me to add the links for the torrent links for lubuntu to the secondary server, it currently only has direct downloads available.
<slangasek> tgm4883: fixed the mythbuntu torrents, should propagate out shortly
<tgm4883> slangasek, thanks
<tgm4883> slangasek, if you don't mind me asking, what was the issue?
<slangasek> tgm4883: um... "a script didn't work right"
<tgm4883> heh, nice
<tgm4883> slangasek, thanks again
<slangasek> so I had to manually put the files in the right place for torrent mirroring
<slangasek> phillw: cjwatson'll be afk; I'm not sure I understand the question - are you just asking if you're allowed to link to the torrents?
<phillw> slangasek: yes.
<slangasek> phillw: that's certainly ok - it's nicer on the Internet to use the torrents :)
<slangasek> phillw: you may want to double-check that the torrents all work before linking
<phillw> slangasek: currently the page has the server direct down-loads.. http://thesii.org/iso/
<slangasek> given that xubuntu, mythbuntu both had problems
<slangasek> actually, just checked myself - they're all there
<phillw> it's coping quite well... still on about 1% cpu time and the 100MB/s back-bone seems untroubled by the data flow.
<micahg> umm, shouldn't quantal be derived from unstable or will we continue to sync from testing?
<ogra_> micahg, it wasnt clear and switching from testing to unstable is apparently easier than the other way round
<micahg> makes sense
<micahg> will it be decided at UDS, consensus on ML?
<ogra_> no idea, i thik colin discussed it in person in millbank before deciding to use testing for now
<slangasek> bdmurray: is bug #902603 bug-patternable?  ("Noting disappearance of libtag1c2a" in the upgrade log)
<ubot2> Launchpad bug 902603 in taglib "When installing Multi-Arch: same (meta-)package for two architectures, dpkg considers one arch as completely disappeared" [High,Fix released] https://launchpad.net/bugs/902603
<bdmurray> slangasek: why, yes I just pushed that pattern ;-)
<slangasek> haha
<slangasek> ok
<bdmurray> I'd used it to clean-up a bunch of duplicates too
<slangasek> bdmurray: where are you pointing follow-ups?
<bdmurray> at the bug
<slangasek> ok great
<ScottK> Every post-LTS release we have this "Should be go back to Unstable" conversation like it's a surprise.  We always, in the end, go back to unstable.  Can't we just agree that's what we do and save having to rediscuss it every time.
<slangasek> so fixing the bug description to add the recovery steps is the right answer :)
<bdmurray> Noting disappearance of (libjpeg8|libtag1c2a|odbcinst|libccid)
<ScottK> (every for the two that have come from testing)
<bdmurray> those are the packages I have for the pattern
<jbicha> ScottK: lol
<ScottK> jbicha: My hope is small, but I thought I'd suggest it.
<slangasek> bdmurray: updated the bug description with what I hope is a viable recovery recipe
<slangasek> ScottK: oh, were we discussing it?
<slangasek> I assumed we were going to switch back to unstable
<ScottK> slangasek: By initially setting up for testing, that implies to me the question is open.
<slangasek> heh, ok
 * slangasek sees the scrollback now... ohwell :)
<doko> the gcc-4.7 ppa build for armhf is finishing, so I'll copy the packages from the ppa
<slangasek> doko: I'm confused, cjwatson said earlier that gcc-4.7 needed base-files first before upload, and that was just accepted now?
<slangasek> did you do a separate base-files build in the ppa too?
<doko> yes
<slangasek> ok
<doko> the distro upload is the same as the ppa build, except that the testsuite is disabled in the distro upload, so the ppa upload even is the better one
<gema> I am about to install (dpkg -i *.deb) an oneiric kernel on precise to try something, if I do it that way, can I easily go back to the precise kernel afterwards?
<slangasek> doko: well, I just want to make sure the package being copied is one we know is built knowing that it's for quantal
<doko> slangasek, yes, it is
<slangasek> gema: you probably still *have* the oneiric kernel installed, and can select between them at the grub menu
<slangasek> gema: (holding down shift at boot to get the menu)
<gema> slangasek: will try that first, thanks!
<sebsebseb> hi
<slangasek> gema: we don't remove kernels on upgrade - there's room for improvement in how we handle that, but at least the current behavior ensures you always have a known-good kernel you can boot back to
<gema> slangasek: in this case, that's handy, thanks
<ogra_> lots of room :)
 * knome read "lots of rum"
<knome> makes sense too
<ogra_> yeah :)
<slangasek> bdmurray: does bug #989040 look familiar?  not a freetype bug, but I don't know if this is a common failure
<ubot2> Launchpad bug 989040 in freetype "package libfreetype6 2.4.8-1ubuntu2 failed to install/upgrade: subprocess dpkg-deb --control returned error exit status 2" [Undecided,New] https://launchpad.net/bugs/989040
<pitti> I don't think anyone triggered a new zh_CN CD, doing now
<slangasek> new meaning quantal?
<pitti> no, precise
<slangasek> there were already zh_CN CDs that should have been up-to-date
<pitti> current zh_CN images are broken, bug 988836
<ubot2> Launchpad bug 988836 in ubuntu-defaults-builder "Chinese images: Removes ubuntu-defaults-zh-cn" [High,Fix committed] https://launchpad.net/bugs/988836
<slangasek> ah
<pitti> slangasek: I only see 20120425
<pitti> the fix only got published some 3 hours ago
<pitti> but I had to run out then
<slangasek> yes, that was the date of our last respin of the main CDs, which is what I meant by "up to date" :)
<pitti> slangasek: nobody of the testers seems to have noticed that this CD is anything but Chinese :)
<slangasek> I don't think there are test cases on the iso tracker for zh_CN, are there?
<pitti> I guess not
<sebsebseb> Party Party Party, today for me? Uh no.
<sebsebseb> silly client, wrong channel sorry
<pitti> bed time for me; will examine the zh_CN CD tomorrow morning, unless someone beats me to it
<pitti> main thing to watch out for: it needs to boot a Chinese desktop, not an English one
<doko> rejected 4.7
<bdmurray> slangasek: no the message in 989040 is new to me - the use of zram is interesting though
<slangasek> ouch
<slangasek> memory corruption?
<roadmr> Hello! I installed Ubuntu 12.04 and /etc/defaults/apport has enabled=1, should it?
<slangasek> roadmr: yes; apport remains enabled, but only talks to the crash database by default after release instead of prompting users to submit bugs to launchpad
<ScottK> Ah.  That's it.
<roadmr> slangasek: thanks! that's new and threw me off :)
<gema> slangasek: what is xh_CN?
<gema> zh_CN, rather
<slangasek> gema: the Chinese localized CD
<gema> slangasek: we tested images from Wednesday
<slangasek> ah?
<gema> it is simplified chinese
<gema> and they were fine
<slangasek> were they in English like pitti says? :)
<slangasek> hmm
<gema> slangasek: skaet enabled the tracker for chinese and one member of our team did it
<slangasek> ah, cool
<slangasek> I hadn't seen that
<gema> slangasek: so I guess the last respin broken them?
<slangasek> I don't know... best to ask pitti
<gema> let me see if I can find the results
<gema> slangasek: correction, we tested images from yesterday
<gema> http://localized-iso.qa.ubuntu.com/qatracker/milestones/215/builds
<slangasek> ah, a different tracker URL :)
<gema> yep
<gema> slangasek: I think we should have test cases for languages if they are the same image, rather than different place
<gema> slangasek: because what we've done is confusing
<slangasek> I don't understand you
<slangasek> zh_CN is not the same image
<gema> ah, they are different images
<gema> uhmmm, I thought we installed normal images but in chinese, ok
<gema> my bad
<slangasek> well, maybe that's what was tested and that's why the bug wasn't noticed?
<gema> no, victor downloaded the ones there
<gema> I gave him the link to the localized tracker
<slangasek> ok
<gema> and I am pretty sure he said he tested traditional chinese and simplified
<gema> but I will doublecheck tomorrow
<gema> when was the .1 image created?
<gema> do you know?
<gema> he may have missed the respin
<gema> the last one, I mean
<slangasek> don't know, sorry
<slangasek> well, I can look at timestamps I guess
<gema> yes
<gema> at 14:27 on the 24th
<Riddell> jibel: you didn't mark the amd64+mac desktop images test as failed?  did you just not fill that in?
<slangasek> 2012-04-24 14:28
<gema> and I asked him to test those at 1800 on the 24th
<gema> so I definitely need to follow up with him
<gema> if the images are wrong
<gema> slangasek: thanks
<Riddell> slangasek: got a moment for an opinion?
<slangasek> Riddell: sure
<Riddell> slangasek: amd64+mac kubuntu is missing a test result and jibel said he got a crash on the installer when doing manual partitioning
<Riddell> http://iso.qa.ubuntu.com/qatracker/milestones/214/builds/15941/testcases
<Riddell> slangasek: but ScottK thinks we can release it with loud caveats, what's your opinion
<slangasek> hmm, what is my opinion indeed
<slangasek> I would think it's worth releasing with caveats
<Riddell> is it only listed on the kubuntu.org site in a "not supported in any way images" section
<Riddell> but then I'm never happy releasing things where the main report is a breakage
<Riddell> ScottK: no bug for it presumably?
<slangasek> there are 3 of 4 successes listed though?
<Riddell> yes so it has use cases
<Riddell> one of which is probably ScottK's daughter so that'll be his interest :)
<slangasek> I would certainly think release with caveat is better for users
<Riddell> slangasek: is this the right command?  ARCHES='amd64+mac' for-project kubuntu publish-release daily-live 20120423 desktop named release
<slangasek> Riddell: looks right to me
<cjwatson> pitti: zh_CN> crap, sorry, my bad for not respinning that, too many plates in the air
 * knome notes that cjwatson would be better of buying the plates from IKEA if he tends to break a lot of them
<ScottK> Riddell: Actually that's not my interest (as she's made it clear her isn't going to run Kubuntu).  My interest is providing an image that has a live session so people can try it.
<ScottK> slangasek or cjwatson: Any objection to me uploading boost1.49 and boost-defaults (it'll be a sync) so you can accept them when ready?
<ScottK> I have them ready now and my online availability will be spotty tonight and tomorrow.
<slangasek> ScottK: no objection from me
<ScottK> Thanks.
<ScottK> boost1.49 is a big tarball.  It'll be along in a minute.
<ScottK> boost1.49 and it's packages should go into Main.  It has to be built before the boost-defaults sync will build.
#ubuntu-release 2012-04-27
<pitti> good morning
<pitti> gema, slangasek: no, that bug (Chinese images not being Chinese) is quite some months old already
<slangasek> so I wonder why the testers didn't agree
<pitti> we introduced it in https://launchpad.net/ubuntu/+source/language-selector/0.66
<pitti> cjwatson: no worries; it doesn't matter if we release them a day after, I guess
<pitti> I tested a local build yesterday, downloading http://china-images.ubuntu.com/precise/daily-live/20120426/ now
<pitti> stgraber, cjwatson: http://china-images.ubuntu.com/precise/daily-live/20120426/ is now actually chinese; stgraber, can you please add them to the tracker? I disabled the previous ones, but I still can't add new ones
<skaet> pitti, slangasek, stgraber, cjwatson - http://localized-iso.qa.ubuntu.com/qatracker/milestones/217/builds has been created and chinese images added to it.
<skaet> Since the images were based on a final version of 12.04,  rather than the pre-release ones,  it seemed a new milestone was appropriate.
<skaet> stgraber,  we probably need to figure out some conventions for the transition between pre-release and after the Ubuntu release comes out, and get it documented.
<skaet> I'll set up a blueprint on the subject for later today.
<pitti> skaet: splendid, thanks
<skaet> good morning pitti.
<skaet> :)
<pitti> hey skaet, how do you feel today?
<skaet> pitti,  feeling good.   solid sleep helps wonderfully, as does knowing the release is out the door.  ;)
<pitti> yay, didrocks-isms!
<pitti> da man who never sleeps
<skaet> :)
<skaet> more goodness coming in,  SRU system ramps up for 12.04.  :)
<skaet> re: didrocks,   +1!  :D
<didrocks> \o/
<didrocks> more goodness in the pipe :)
<skaet> :)
<didrocks> does anyone know what shold be the Multi-Arch tag for a -dbg package?
<didrocks> as bamf-dbg is Multi-Arch: same and of course, I'm getting: E: bamf-dbg: arch-dependent-file-not-in-arch-specific-directory usr/lib/debug/usr/lib/bamf/bamfdaemon
<slangasek> it "should" be whatever it is
<slangasek> if the -dbg package ships files in a non-arch-qualified directory, it shouldn't be marked M-A: same
<didrocks> slangasek: ok, as bzr annotate points you as doing this addition I didn't dare removing it without having a confirmation from someone with some clue on this :) thanks!
<slangasek> ;)  I overlooked bamfdaemon when I added it
<didrocks> slangasek: no worry, will use this upload to fix it, thanks for confirming :)
 * skaet --> breakfast then shifting to the office.   biab
 * apw notes that the archive is suitibly slow today
<micahg> isn't it always like that right after release?
<tumbleweed> it is closed, after all
<jibel> Riddell, I reproduced bug 989249, attached the logs and updated the tracker.
<tumbleweed> oh, you mean access
<ubot2> Launchpad bug 989249 in ubiquity "kubuntu amd64+mac crash in manual partitioner" [High,Confirmed] https://launchpad.net/bugs/989249
<Riddell> thanks jibel
<cjwatson> doko_: so can we copy a bunch more stuff from your PPA now?
<doko_> cjwatson, just copied gcc-4.6 and gdc-4.6
<doko_> I'll upload gcj-4.6 and gnat-4.6 directly. did mess up the gcc-defaults in the ppa
<cjwatson> OK
<cjwatson> doko_: oh, I guess you're using copy-package.py, so it didn't show up in the queue?
<doko_> cjwatson, yes, I did. sorry, should I use something else?
<cjwatson> ideally, something that's based on Archive.copyPackage in the API
<cjwatson> I don't think we actually have a proper general tool for it right now; you can either write one :-) or use lp-shell
<pitti> note that copy-proposed-kernel in lp:u-a-t shoudl be fairly close to this
<cjwatson> indeed
<pitti> in fact, it doesn't really hardcode any package name, just the "canonical-kernel-team" PPA name
<cjwatson> it's on the remove-archive-admin-shell-access list to write a general API tool to replace everything we do with copy-package.py
<doko_> ok, noted
<pitti> it'd be fairly simple to rename it to copy-ppa-ubuntu and add some options for PPA name and destination pocket
<cjwatson> so maybe add an option to that script to select the PPA and rename it to copy-from-ppa
<cjwatson> yeah
<pitti> I'd still keep copy-proposed-kernel, but that can then become a tiny shell shim around that
<doko> cjwatson, pitti: would you be ok with demoting gcc-4.5 from the start?
<doko> even if it's still used by u-boot and mysql-5.1?
<cjwatson> why?
<pitti> we still carry mysql 5.1? I thought that was obsoleted by 5.5
<cjwatson> mysql-5.5 actually
<pitti> oh, 5.5
<pitti> so, I'm generally for reducing duplication, just not sure how hard it is to fix u-boot-linaro
<cjwatson> I'd rather those packages were fixed first
<cjwatson> I guess I don't see the rush to demote it
<cjwatson> doko: Any reason I shouldn't accept boost1.49 now?  AFAICS things that use the default compiler should be fine now
<doko> cjwatson, sounds fine
<infinity> doko: I'll push Linaro harder to get u-boot working with 4.6 (or 4.7, ideally), MySQL will take some testing.  We tried to switch it once and its world exploded.  Maybe 4.7 will treat it better, or maybe MySQL needs some love.
 * Laney switches ben to precise
<Laney> er, the other thing
<ogra_> lots of maybes in that sentence
<Laney> we should clean that out too
<micahg> do we still need 4.4 for anything (texlive-bin and libusb++-dev seem to be the only things that require it in main)
<infinity> ogra_: I only count two. :P
<ogra_> enough though :)
<micahg> well, and boost1.46, but that's going away :)
<infinity> micahg: 4.4 demotion seems like a much more solvable issue, though examining WHY things still want it is always a sane first step.
<micahg> after it's demoted I think I'll just kill it (only a handful of universe rdeps)
<micahg> ok, 2 handfuls :)
<infinity> That's, I suspect, the plan.
<doko> infinity, it's mysql 5.1 only, which maybe should be dropped
<infinity> -- precise/main build deps on g++-4.5:
<infinity> mysql-5.5
<infinity> doko: I can't see that that changed in the last day...
<doko> hmm
<micahg> doko: here's what I think you're looking for: https://launchpad.net/ubuntu/+source/mysql-5.5/5.5.20-0ubuntu2
<infinity> SpamapS: Can you waste a bit of time on testing MySQL with g++-4.7 and see if maybe we can finally ditch 4.5 (or even blow some time on finding and fixing the issues?)
<infinity> There.  Go, server team, go.
<doko> cjwatson, infinity, pitti, micahg: I think we are ready for *ish uploads. toolchain is in place, but the -multilib packages are still broken on arm. I don't expect these to be available before tomorrow.
<infinity> What's broken with multilib?
<infinity> (Not that it matters greatly, except for a tiny subset of packages)
<doko> config error, gcc-4.7 didn't build the -multilib packages
<doko> so you'll just see unfulfilled b-d's, and can give back these later
<cjwatson> doko: let's finish boost1.49 and boost-defaults first?
<infinity> Please.
<doko> ?
<cjwatson> per ScottK on -devel
<cjwatson> I wonder if we should merge debhelper
<doko> ohh, I didn't mean to open now, but get uploads for dpkg, apt, etc ready
<cjwatson> Oh, right.  dpkg is Hard this time.
<doko> yes, and debhelper,. cdbs, ...
<doko> should be independent from boost
<cjwatson> I'd be inclined to leave it for a bit rather than rush it.  It'll need care to get multiarch config migration working properly.
<cjwatson> And I don't think it's needed for opening.
<infinity> Config migration should be fairly simple.  "should be". :/
<micahg> Debian has started adding annoying deps on debhelper for various hardening features, so that would probably be good before the autosync
<cjwatson> infinity: Be my guest. :-)
<infinity> cjwatson: I don't mind doing the migration bit, I'm not sure I want to do the merge today.
<cjwatson> I'll go and sort out debhelper now.
<infinity> cjwatson: But I could do both next week.  I agree that we don't need it to open.
<cjwatson> We don't have merge-o-matic yet, unfortunately.
<infinity> MoM and I aren't often on speaking terms anyway.
<cjwatson> Right, I wouldn't recommend it for dpkg in any case.  I meant in general.
<infinity> apt 0.9.2 would be nice, not sure how large the delta there is.
 * infinity has a look.
<doko> infinity, are you tracking the upgrade of the arm buildds?
<doko> when should that happen?
<infinity> doko: Which upgrade?
<doko> to precise
<infinity> doko: To precise, you mean?  We want *all* buildds to do that, not just arm.
<doko> I mean, there are more than 50% offline
<infinity> doko: Timing on that, however, is out of my hands.
<cjwatson> Hum
<doko> is this an webops item?
<infinity> It's an RT ticket, not sure who owns it currently.
<cjwatson> The debhelper merge has a conflict in dh_installinit which is tied in with Steve's efforts to merge proper Upstart handling into Debian
<infinity> But I'll make sure it comes up in calls and we get it done.
<cjwatson> And the new dh_installinit has the effect of installing both Upstart jobs and init scripts, rather than our previous scheme
<cjwatson> slangasek: ^- I'm not confident in my ability to do the debhelper merge accurately; do you think you could deal with it?
<cjwatson> micahg: Build-deps aren't a problem, TBH, as they'll just dep-wait.
<cjwatson> So I think we could open without debhelper, since it isn't trivial.
<cjwatson> Though there are some flag handling features that might not have been build-depped on.
<doko> pitti, cdbs merge?
<infinity> +           // do not show ignoration warnings for directories
 * infinity giggles at "ignoration".
<micahg> automake?
<doko> no new version
<cjwatson> Yeah there is, just not in wheezy
<doko> ahh
<cjwatson> Shall I do that?  I have the last Ubuntu changes.
<doko> sure
<pitti> away -all
<pitti> err
<pitti> doko: can do
<micahg> libreoffice ended up on sulfur, this should be interesting :)
<pitti> why, I thought that one was faster than the older two?
<micahg> yes, and with more cores, it should be interesting to see how fast it tears through it
<cjwatson> ah, good, automake1.11 is a sync
<micahg> is there any point in moving to lsb 4.1 before opening?
<doko> micahg, I don't think so
<cjwatson> Shouldn't be needed pre-opening
<doko> I didn't track clang and fpc
<doko> infinity, can you upload clang defaulting to armv5t on armel?
<pitti> cjwatson, doko: is someone already handling the merging of debhelper?
<doko> <cjwatson> So I think we could open without debhelper, since it isn't trivial.
<doko> pitti, so I assume no
<cjwatson> pitti: 13:13 <cjwatson> The debhelper merge has a conflict in dh_installinit which is tied in with Steve's efforts to merge proper Upstart handling into Debian
<cjwatson> 13:14 <cjwatson> And the new dh_installinit has the effect of installing both Upstart jobs and init scripts, rather than our previous scheme
<cjwatson> 13:14 <cjwatson> slangasek: ^- I'm not confident in my ability to do the debhelper merge accurately; do you think you could deal with it?
<pitti> cjwatson: thanks
<cjwatson> pitti: If you think you can deal with this accurately - that is, if you know authoritatively which way we should be handling init scripts - be my guest, but I don't
<pitti> I have 45 minutes left before I leave for the train station, so I'd rather not attempt that today then
<cjwatson> I'm on the fence about opening without debhelper.  It might be better to wait until we hear from slangasek (who's on holiday) rather than rushing.
<pitti> there are quite a number of changed compiler flag handling, these do look significant
<cjwatson> Yeah
<pitti> my gut feeling is that we probably want to keep our version of dh_installinit instead of Debian's "install both", but I agree, let's wait for Steve for this
<pitti> I don't think we ever want to support sysvinit in Ubuntu again
<cjwatson> Sure; still, the merge wasn't obvious to me anyway
<cjwatson> doko: Do the gcc-4.6 entries on http://people.canonical.com/~ubuntu-archive/nbs.html indicate a problem, or are those waiting for builds to finish?
<doko> cjwatson, problems, working on that
<doko> <doko> cjwatson, infinity, pitti, micahg: I think we are ready for *ish uploads. toolchain is in place, but the -multilib packages are still broken on arm. I don't expect these to be available before tomorrow.
<cjwatson> Oh, that
<cjwatson> NP
<infinity> doko: Sure.  Does llvm need a sane default target too?
<infinity> doko: Actually, we should probably snag llvm-3.1 and clang_3.1 from experimental...
<doko> sure, why not
 * infinity nods.
<infinity> I'll look at merging and/or syncing those, then.
<infinity> After I smoke. ;)
<doko> I'm currently not using llvm for shark/openjdk
<pitti> "The Unapproved queue is empty. "
<pitti> take that, didrocks!
<pitti> *hug*
 * didrocks hugs pitti
<didrocks> pitti: you were fast! ;)
<didrocks> pitti: if only my laptop didn't burn, I would be doing zg now and you would be in a worse shape! :)
<pitti> I've become pretty acquainted with /^--- and skipping over autoconf noise :)
<didrocks> hÃ©hÃ© ;)
<pitti> skaet, cjwatson: FYI, I'll be on holiday on Monday, and there is a national holiday on Tuesday
<infinity> doko: Oh, and I wouldn't worry too much about fpc, I probably need to do an fpc transition first thing next week anyway, so it'll sort itself.
<pitti> so be back on Wed
<cjwatson> Righto
<cjwatson> Have fun :)
<skaet> pitti, cjwatson,   I'll be flying on monday,  then taking a couple of days off.   Will send out email when I know which ones.
<skaet> enjoy your long weekend pitti.
<infinity> doko: Oh, ocaml might need love too...
<pitti> doko: cdbs uploaded
<cjwatson> syncing perl - our only outstanding changes are Conflicts on pre-12.04 versions
<pitti> train time, see you next Wed! You can call my mobile for emergencies
<infinity> doko: Or maybe ocaml will just magically fix itself on rebuild.  Handy.
<ogra_> bah, quantal only just opened and we already have the first 3 ftbfs
<ogra_> (on arm that is)
<infinity> ogra_: ?
<infinity> ogra_: If it's toolchain packages failing due to multilib, ignore it.
<infinity> And indeed, it is.
<ogra_> yeah, i wasnt seriously complianing a day after opening :)
<cjwatson> Is ocaml pre-opening?
<infinity> Yes.
<cjwatson> Bam.
<infinity> cjwatson: I think it's probably safe to assume that anything that looks kinda like a compiler is pre-opening.
<cjwatson> Heh
<cjwatson> Just like to check
<infinity> doko: I assume you've noticed, but your gcc-4.7 in the PPA seems sad.
<ev> https://bugs.launchpad.net/ubuntu/+source/apport/+bug/989779 - skaet
<ubot2> Launchpad bug 989779 in apport ""Problem already known" alert and Launchpad page still open post-release" [Undecided,New]
<skaet> pitti,  can you look into ^
<skaet> ?
<seb128> skaet, he's not online
<ogra_> skaet, he is gone until wed.
<seb128> skaet, and off until wednesday
<skaet> seb128, ogra_ thanks.  didn't realize he'd eod.
<skaet> ev or cjwatson,  can either of you handle?
<cjwatson> I don't know apport or the error tracker design well enough to be comfortable with doing that in a rush
<skaet> cjwatson, ack.    ev just said he'll tackle.   Thanks.
<cjwatson> cool
<infinity> cjwatson: Going to be uploading/syncing some llvm* stuff, not to be accepted until the current publisher run is done.
<cjwatson> OK
<cjwatson> Oh, boost-defaults can go now, can't it
<doko> infinity, yes, known
<cjwatson> infinity: llvm* ready to go now?  The publisher's in cron.germinate, so should be enough for buildds.
<infinity> cjwatson: Yep.
 * cjwatson accepts
 * infinity grabs the one in new.
<cjwatson> Go for it.
<cjwatson> Oh, I think I'll let distro-info-data in too.
<infinity> cjwatson: The kernel sync from -updates would be fine too.
<cjwatson> Good point.
<cjwatson> In fact all the syncs from -updates are fine.
<stgraber> skaet: any objection to marking both pre-release and final milestones as released on the tracker?
<skaet> stgraber,  no objection.   Thanks!  :)
<stgraber> skaet: done. I'll keep all the precise ones as released until we get the first quantal daily. I'll then archive them all
<SpamapS> infinity: I'll definitely give it a shot.
<skaet> stgraber,  sounds good.   Thanks.   I'll add it as a task to the checklist for day+1 tasks.
<ev> fix for bug 989799 uploaded to precise-proposed
<ubot2> Launchpad bug 989799 in nova "create instance min/max count defaulting logic is reversed in EC2 and native OS APIs " [Undecided,New] https://launchpad.net/bugs/989799
<ev> err bug 989779
<ubot2> Launchpad bug 989779 in apport ""Problem already known" alert and Launchpad page still open post-release" [Undecided,New] https://launchpad.net/bugs/989779
<skaet> thanks ev
<skaet> gema, jibel - are either of you online now?    we need to figure out a plan for quickly testing this apport fix.
<ev> please reject
<ev> need to rework that
 * skaet doing
<jibel> skaet, pong
<skaet> hiya jibel
<skaet> when ev gets the apport package uploaded,  would you be able to do some checking that its doing the right thing now, and not causing side effects?
<skaet> (next version ;))
<jibel> skaet, sure. do you have an ETA ? my plan was not to stay late tonight
<skaet> jibel, ev's working on the revised version now.
<skaet> hopefully within the hour,  but if not,  could you hand off to hggdh?
<skaet> we'd like to get this fix out there, ASAP.
<jibel> skaet, ack. within the hour is fine.
<jibel> I'll ask hggdh if it's unverified when I'll leave.
 * hggdh is aware, and waits
 * jibel leaves now then ;)
 * hggdh runs
<skaet> Thanks hggdh, jibel   :)
<ev> ^ skaet please accept that one. The additional changes weren't actually needed in the end, but make the check it's doing more consistent (not assuming certain things are set in /etc/apport/crashdb.conf).
<skaet> ev,  will do,  waiting for the diff.
<infinity> doko: The clang merge might not happen until I get home, it's a bit entertaining.  clang's rdep list is tiny, I'll just rebuild it later when I'm happy with my local builds.  (want to fix some armhf stuff at the same time anyway)
<infinity> cjwatson: ^
<skaet> hggdh,  version you're going to need to wait to be built in -proposed, and test with is apport 2.0.1-0ubuntu7
<hggdh> skaet: ack
<cjwatson> infinity: *nod*
<infinity> cjwatson: And I'll be doing an fpc porting/transition bit earlier next week too so, for me, I'm done with toolchain bits until Monday.
<cjwatson> Anything else you care about pre-opening?
<infinity> cjwatson: When do you plan to mass-sync universe?  I'd like it to happen after I land fpc, so I don't have to transition twice.
<cjwatson> The only thing on my list right now is (?)debhelper.
<cjwatson> infinity: Right after opening.
<seb128> ev, you made apport native in that upload
<infinity> cjwatson: Oh well.  I'll transition fpc twice if I have to, not world-ending. ;)
<seb128> ev, i.e not diff.gz, but a plan tarball
<infinity> cjwatson: Might have to anyway, if the build-deps aren't all sane, since we may end up syncing in a weird order that breaks it all, so meh.  I'll wait for the world to settle and then fix fpc properly.
<cjwatson> infinity: Might take us until early next week before we open anyway
<cjwatson> fpc doesn't have many rdeps, does it?
<infinity> (Ideally, I'd get a new fpc in right now, but that requires a bootstrap...)
<infinity> Actually, wait.  No, I can fudge it.
<infinity> I can sync Debian's fpc now, and then do the armhf bootstrap later.
<seb128> skaet, ev: not sure if apport should be reuploaded with a diff.gz?
<infinity> I'll do that.
<cjwatson> In fact, it seems to be just lazarus?
<infinity> fp-compiler
<infinity> Should be a lot more than lazarus.
<ev> seb128: eep, sorry about that
<cjwatson> Ah, yes
<infinity> Anyhow, synced fpc as a pre-open thing.
<cjwatson> ev: Rejected that one then
<cjwatson> accepted fpc
<infinity> There.  That should be happy for everything but clang, and I'll deal with clang on Monday.
<infinity> Their beautiful misunderstanding of multiarch makes me want to be a bit more careful with it.
<infinity> (testing for /lib/triplet/ as a way to determine the host arch is *brilliant*)
 * cjwatson blinks
<infinity> I shit you not.
<infinity> cjwatson: Also, I don't want to alarm you, but no one's done the inaugural vim merge yet.  Are we slipping in our old age?
<ev> cjwatson: cheers
<infinity> Oh, not even a merge in this case, just a bump to add quantal.
 * infinity does that.
<cjwatson> infinity: heh, go for it ...
<cjwatson> ev: Looks good to me.
<ev> yay
<infinity> And, of course, the no-change rebuild of llvm-2.8 fails.
<infinity> Tempted to just remove it.
 * infinity goes rdep hunting.
<infinity> Hah, and 2.9 also fails, and we use that one.
<infinity> Thanks, gcc-4.7.
<infinity> Might be time to just switch to 3.0 or even 3.1 and drop all the old ones, but I don't have the time tonight to look into that pain.
<infinity> (Have to be out of here in ~30m)
<slangasek> cjwatson: on vacation, but not staying away from the archive ;) I'm happy to do that merge today
<slangasek> cjwatson: btw, do we have dpkg flags behavior restored to match Debian's now?
<infinity> cjwatson: Right.  New plan.  llvm-2.x sucks, I'm going to move llvm-py and llvm-defaults to 3.0 and bounce out 2.x completely.
<infinity> cjwatson: But I have about 15 minutes left to do that, so... That's a "when I get home" thing, to make sure I test it a bit before I do it.
<cjwatson> slangasek: No, I was thinking about that but have been too scared :-)
<infinity> Scared, or scarred?
<cjwatson> Yes.
<infinity> ;)
<cjwatson> That would be an easy change in advance of the merge, I suppose.  Are we sure we'll have enough effort to restore hardening flags everywhere for 12.10?
<slangasek> :)
<infinity> Anyhow, as above, don't worry too much about all things llvm/clang, I'll sort it all when I land.
<cjwatson> Noted
<slangasek> we did say we were going to revert that after 12.04
<cjwatson> We did
<slangasek> how much effort do we expect it to be to restore the flags?
<cjwatson> I can imagine about half an hour per package + whatever it takes to set up something to scan for the problem
<cjwatson> Which I suppose can be a lintian check on lintian.ubuntuwire.org
<slangasek> so we don't really have a package count at this point
<cjwatson> Not AFAIK
<slangasek> ok
<slangasek> well, IIRC from the first time around it was a fairly small percentage of packages
<slangasek> and should be smaller now due to Debian uptake
<cjwatson> In fact, to find out how many we *would* have to change, we'd have to test-rebuild everything and then run hardening-check against them
<cjwatson> Um, isn't it everything that doesn't use dpkg-buildflags?
<slangasek> I thought it was only things that explicitly overrode flags in debian/rules without checking dpkg-buildflags?
<slangasek> maybe that was a subset of the problem
<cjwatson> Those were the ones that broke due to the earlier iteration of our workaround, I think
<ScottK> cjwatson: boost1.49 binaries got accepted into Universe.  They need to be in Main or boost-defaults won't build.
<cjwatson> ScottK: boost1.48 was in universe, though
<ScottK> cjwatson: Yes, but this is replacing 1.46
<cjwatson> Oh, I missed that
<cjwatson> Promoted, thanks - I expect some of the binaries will want to fall back to universe later, but this will do for now
<ScottK> It's a bit of an odd situation where we got 1.48 and an updated defaults via autosync after we decided to stick with 1.46 for oneiric.
<slangasek> cjwatson: hmm, there are some unpleasant trade-offs with this apport change
<ScottK> That should do it.  We'll want to give main users a chance to convert before dropping stuff back.
<slangasek> (skaet just tagged me to follow through on it)
<cjwatson> Oh?  It looked roughly in line with previous code
<slangasek> cjwatson: it may indeed have been... but does this affect bug patterns?
<cjwatson> That I'm not sure
<cjwatson> Has ev already left?  I don't know this code as well as I should.
<slangasek> because we explicitly put in some bug patterns pointing to pages with documentation to help users fix their upgrade issues
<cjwatson> (And I have to finish up soon)
<cjwatson> It's in -proposed, I guess v-failed will do for now if it's breaking stuff ...
<slangasek> in the short term I'm happy to err in the direction of less interaction, but would like to follow through on the bug patterns question
<slangasek> cjwatson, pitti: btw, as far as the debhelper merge is concerned, over the longer term I do want to get us back in sync with debian on dh_installinit so we *would* have the init scripts installed and lying dormant; but a prereq for this would be LSB header fixes so we could use insserv as intended
<slangasek> so that's pretty low priority
 * cjwatson looks for a package he can test against new dpkg
<slangasek> (the only real benefit is further reducing delta with Debian, in terms of both packaging and behavior)
<cjwatson> Or I mean the proposed dpkg change
<cjwatson> I think I need something that (a) doesn't set CFLAGS/LDFLAGS itself and (b) doesn't use dpkg-buildflags
<cjwatson> And (c) doesn't use hardening-includes or similar
<cjwatson> Perhaps man-db 2.5.7-4 is close enough
<cjwatson> Annoyingly, lintian.uw.org isn't running a new enough version of lintian for the hardening checks yet
<cjwatson> Ah, because it isn't released yet
<cjwatson> Oh and (d) actually still builds, bah
<debfx> aren't the hardening flags enabled in gcc anyway?
<jibel> ev, I verified apport 2.0.1-0ubuntu7, it fixes 989779. I also created 2 crashes that don't exist in the crashdb (a syntax error and an import error in update-manager) Is there a way to verify that the reports have been uploaded ?
<skaet> jibel, ev's left the building right now.    slangasek,  thoughts?
<slangasek> sorry, I don't know
<slangasek> debfx: some, not all; I don't remember the precise details of what blew up last time we tried to stop force-setting dpkg-buildflags
<jibel> skaet, I'll update the report with my verification but will set to verified once there is a confirmation that reports are still uploaded.
<gema> skaet: what is this change about?
<gema> why is it going in so late?
<gema> or is this for 12.04.1?
<gema> slangasek: I thought you were off!
<gema> in fact, I thought I was off too :/
<slangasek> jibel: if you have a .upload stamp file in /var/crash, that should be sufficient verification
<slangasek> gema: "off" is a funny concept ;)
<slangasek> it just means I'm not answerable to my manager for anything I do today ;)
<gema> uhmmmm... I am watching you, slangasek  :P
<jibel> slangasek, it's there. verification-done :) thanks
<slangasek> jibel: great, thanks - yeah, that's sufficient because whoopsie does the actual uploading and is an entirely separate package
<slangasek> hggdh: jibel already tested apport, so I've copied it to -updates now
<slangasek> hggdh: so you're off the hook :)
<hggdh> slangasek: roj, thank you
<skaet> thanks slangasek
 * skaet --> out of millbank
<claydoh> torrent for Kubuntu i386 desktop gives an error:
<claydoh> rejected by tracker - Requested download is not authorized for
<claydoh> use with this tracker.
<claydoh> file downloads but doesn't seed
 * ScottK pointed ^^^ since he recalled issues with the Ubuntu torrents yesterday.
<claydoh> where would the best place to report that? All other torrents seem fine
<cjwatson> here - I'll have a look shortly
<claydoh> Ok thanks!
<cjwatson> claydoh: should be fixed soon, sorry about that
<cjwatson> I need to scan for these properly when I'm not supervising kids
<claydoh> cjwatson: thanks!
<ScottK> Would someone please de-New boost-defaults?
<cjwatson> ScottK: done
<cjwatson> three nested screen levels wasn't at all confusing there.  took me two goes to detach the right one afterwards.
<ScottK> Thanks.
<slangasek> ^a aa ^a ^a a
<slangasek> cjwatson: wrt dpkg-buildflags: http://outflux.net/ubuntu/hardening/
<cjwatson> maybe I should learn how to use canonistack so I can do comparison test rebuilds in it
<slangasek> cjwatson: I'm having difficulty actually working out why we needed dpkg-buildflags to do the exports at all in Ubuntu... is there a specific subset of these flags that aren't being set by default in gcc?
<slangasek> I found the rationale for the debhelper compat hack, but not for the dpkg-buildflags part itself
<micahg> slangasek: since the packaging might modify the output?
<slangasek> micahg: I don't follow
<micahg> don't some packages now expect dpkg-buildflags output and then add modifications on top of it?
<slangasek> what if they do?  if those flags are already part of the gcc defaults, how does that hurt anything?
<cjwatson> micahg: I think that's mostly unrelated, although there are perhaps some packages that will misbehave if *FLAGS isn't set in the environment, but I'd expect rather few since Debian doesn't do that
<micahg> or would they get the same modifications if dpkg-buildflags did nothing since they're our default compiler
<slangasek> yeah, that's what I would expect
<cjwatson> How about -Wl,-Bsymbolic-functions?  I don't think the linker sets that by default
<cjwatson> -fstack-protector is default; is --param=ssp-buffer-size=4?
<slangasek> I'm not at all sure
<cjwatson> -D_FORTIFY_SOURCE=2 is default
<slangasek> kees thought only -Werror=format-security was affected
<cjwatson> -Wformat and -Wformat-security are default; -Werror=format-security is not documented as such
<cjwatson> -Wl,-z,relro is not documented as default
<cjwatson> DEB_BUILD_OPTIONS handling would change a bit in the absence of exporting, but that doesn't affect our default builds
<slangasek> where are you finding the documentation of the defaults?
<cjwatson> info gcc-4.6
<cjwatson> and looking in info ld for the -Wl,* ones
<cjwatson>      NOTE: In Ubuntu 8.10 and later versions, for LDFLAGS, the option
<cjwatson>      `-Wl,-z,relro' is used.  To disable, use `-Wl,-z,norelro'.
<cjwatson> aha, that's in gcc-4.6
<cjwatson> still need to figure out how to check for -Wl,-Bsymbolic-functions, though
<ScottK> cjwatson: On a different topic (when you have some spare context) - Since I won't be at UDS, would you be willing to lead a session on changing build priority bases on seeded/packagesets as I proposed on ubuntu-devel a few weeks ago?  I can draft up a spec, but I think someone who'll be at UDS ought to lead the discussion.
<cjwatson> Yes, I guess so; you think it needs a UDS session and not just a bug?
<ScottK> If you think a bug is enough, I'm happy with that.
<ScottK> There's plenty to do at UDS without inventing sessions that aren't needed.
<cjwatson> Let me have a quick hunt for where this is implemented
 * cjwatson doesn't know the buildmaster code that well
<kees> hrm, did I push --param=ssp-buffer-size=4 into Ubuntu's gcc? I thought I did...
<cjwatson> Ah, here we go, lib/lp/soyuz/model/buildpackagejob.py:BuildPackageJob.score()
<cjwatson> That's actually relatively readable
<kees> hrm, looks like I didn't. So --param=ssp-buffer-size=4 is only in dpkg-buildflags
<kees> (as is -Werror=format-security). relro, as you found, has been in Ubuntu gcc for a while.
<kees> https://wiki.ubuntu.com/ToolChain/CompilerFlags <- so I don't think this is lying
<cjwatson> ScottK: Did we think it should be different for different packagesets, or just a bonus for being in a packageset at all?  (The latter is a lot easier since I don't have to figure out where to put the scores.)
<ScottK> I think it's got to be specific packagesets get a bonus.
<cjwatson> Drat.
<ScottK> There are pakcagesets like mono that are completely unrelated to this question.
<cjwatson> In that case it probably needs a session, but only if at least one Launchpad developer who knows anything at all about buildmaster can be there.
<cjwatson> Or soyuz.
<ScottK> That would be wgrant or who?
<cjwatson> Maybe StevenK or bigjools or jtv.
<ScottK> OK.  I'll ask around and see who's going to be there.
 * cjwatson peers at the attendance list.
<ScottK> Oh.  Good point.  Forgot there was one of those.
<slangasek> kees: what does the ssp-buffer-size=4 mean?  That one's always been opaque to me
<slangasek> if some packages start building without it, is that a big deal?
<cjwatson> No sign of any of those people.  Maybe we'd be better off figuring it out on IRC.
<cjwatson> kees: Do you happen to know if there's a way to tell if a given library has been built with -Wl,-Bsymbolic-functions?
<cjwatson> I seem to remember that that was a performance improvement and I'd hate for it to gradually drift away.
<cjwatson> ScottK: It might be as simple as adding a score column to Packageset, defaulting to zero, and adding an API method to set it.
<cjwatson> That wouldn't be desperately hard.
<ScottK> OK.  Maybe wgrant will pop up and some point and we can discuss.  He'll at least have the backscroll.
<cjwatson> Then we could tweak the scores fairly freely and it wouldn't have to be analysed all that carefully in advance.
<Laney> why packagesets and not seeded?
<cjwatson> Launchpad knows about packagesets.  It doesn't know about seeds.
<Laney> but it knows about packages and we know about packages in seeds
<cjwatson> And I really don't want to put weeks or months of effort into the latteer.
<cjwatson> *latter
<cjwatson> It's irrelevant what we know.  It needs to be something in the Launchpad database.
<cjwatson> I think packagesets would be good enough most of the time.  This doesn't need to be perfect (and probably can't be).
<Laney> I am suggesting that the new priority column could be per-package.
<cjwatson> It's not impossible, but I think it'd be overkill.
<ScottK> Would it be simpler to make a need packageset called 'seeded' and bonus that one alone?
<cjwatson> I don't want to hardcode any more Ubuntu-specific naming into Launchpad.
<cjwatson> I'd rather it were entirely agnostic about packageset names.
<cjwatson> (And I don't think it'd be particularly simpler, no)
<cjwatson> I'd also rather change a relatively little-used table like Packageset than a table that gets hit all the time like DistributionSourcePackage ...
<ScottK> OK.
<cjwatson> But maybe wgrant will tell me that's unnecessary paranoia
<ScottK> Is there such a thing as unnecessary paranioa with respect to Soyuz?
<kees> slangasek: when gcc decided whether or not to add the ssp prefix/suffix to a function, it looks for any function with a character array of ssp-buffer-size bytes or more. The default is 8, but there are some things that are still a bit in danger, so gentoo had initially suggested the change, and RH and SuSE followed, and I tended to agree so I added it to Debian with the hopes of getting it into Ubuntu as well.
<kees> slangasek: it's not a big deal to build without it. just marginally less "safe", though those numbers are, I'm sure, just hand-waving.
<kees> cjwatson: -Wl,-Bsymbolic-functions I don't know about, unfortunately. that was all doko :)
<cjwatson> It's impossible to google for since the results are full of build logs :-(
<ScottK> There should be some special character sequence that is in all build logs that you could use to exclude them from results.
<cjwatson> kees: So, I don't know, it's an odd trade-off.  Removing our band-aid would probably encourage us to push dpkg-buildflags patches up to Debian faster, but there's a risk of some regressions in the meantime.
<cjwatson> And, from this discussion, regressions that aren't actually terribly easy to detect.
<cjwatson> We'd lose ssp-buffer-size=4, some format-security errors would stop failing builds, and we might have changes to symbol binding in shared libraries.
<cjwatson> The hardening options in DEB_BUILD_OPTIONS would probably start behaving differently by default, and I'm not sure how much you care.
<cjwatson> And there'd be subtle changes due to *FLAGS being no longer set in the environment by default, which has some non-obvious effects on make's behaviour (although on the whole it would probably result in fewer annoying failures).
<cjwatson> Maybe this is worth it; it doesn't sound immediately perilous.  I'd like to have some notion that we'll be able to scan for the differences, though.
<kees> cjwatson: I don't feel strongly about it. I'd like to move ssp-buffer-size into the gcc patch regardless.
<cjwatson> We can't be failing that many builds due to format-security right now anyway, since there aren't that many failures.
<kees> when I added -Werror=format-security in Debian, I did so under the impression that Ubuntu wasn't force-exporting that into all builds. :P
<cjwatson> Heh, the whole thing is confusing and perhaps reducing confusion is a bigger benefit that anything else.
<kees> so, really, I'd prefer not having that explicit export. but that breaks stuff doko was wanting to have exported.
<cjwatson> And our current dpkg-buildpackage patch is certainly awful.
<cjwatson> Well, only really -Wl,-Bsymbolic-functions, unless there's stuff that needed CFLAGS='-g -O2' in order to behave correctly.
<cjwatson> But FFS it's 2012.
<kees> hah
<kees> my stance on the ubuntu compiler-hardening has always been about making sure even non-package-builds get the options enabled.
<kees> I continue not to be able to make time to get the option upstreamed to gcc as a configure option, though. Zorry (gentoo dev) has been working on it, though.
 * jdstrand would add that this is a differentiating security feature for Ubuntu that we would like to maintain
<jdstrand> hi kees! :)
<cjwatson> jdstrand: The compiler changes or the dpkg-buildpackage export change?
<jdstrand> to be clear, we want our non-package-builds to have the options enabled. where that happens or whether that happens in Debian or Ubuntu doesn't matter to me
<cjwatson> Right, AFAIK nobody is talking about backing out the compiler changes
<jdstrand> cool
<cjwatson> Just trying to evaluate the effect of backing out the awful dpkg-buildpackage change
<kees> hi jdstrand ! :)
<kees> cjwatson: fwiw, from my compiler-hardening perspective, I am in favor of dropping the dpkg-buildpackage change.
<cjwatson> Because it obscures compiler behaviour?
<kees> cjwatson: well, because it creates, for me, unexpected behaviors (packages not expecting -Werror=format-security are getting those options)
<cjwatson> Hm, I thought you were generally in favour of stuff failing rather than building insecurely
<cjwatson> Aha, I just remembered that we don't automatically export -Werror=format-security anyway
<cjwatson> So that's moot
<cjwatson>         # While -Werror=format-security does catch many real bugs, it also
<cjwatson>         # causes many build failures and causes a number of configure tests
<cjwatson>         # to silently fail.  It was not exported to the environment in any
<cjwatson>         # released version of Ubuntu.
<cjwatson>         $build_flags->strip($flag, '-Werror=format-security', undef);
<kees> yeah
<micahg> should we revert that change for quantal?
<cjwatson> micahg: Well, that's what we were discussing for the last hundred lines or so :-)  But not just that bit, the whole export block around it
 * micahg needs to stop trying to help on 4 hours of sleep :)
<kees> cjwatson: correction -> ubuntu _is_ already running with ssp-buffer-size=4. I missed where I'd patched it.
 * ScottK would appreciate it if a "C" archive admin would do the backport in Bug #990140.
<ubot2> Launchpad bug 990140 in precise-backports "Please backport debootstrap 1.0.40 from quantal to precise" [Wishlist,In progress] https://launchpad.net/bugs/990140
<slangasek> kees, cjwatson: right, I think it's better to reduce the confusion... if we're wrong about having the resources to fix things up this cycle, it's not grave
 * kees nods
<ScottK> Ah.  slangasek: Would you please take care of the debootstrap backport? ^^^
<kees> I've just opened 990141 with a patch to document the ssp-buffer-size change, btw (first done in 10.10)
<slangasek> ScottK: looking
<ScottK> Thanks.
<slangasek> ScottK: done
<ScottK> slangasek: Thanks.
<slangasek> hmm, failure trying to submit a merge proposal for quantal: bzr: ERROR: File exists: '/srv/bazaar.launchpad.net/mirrors/00/09/60/5f'
<slangasek> oh, possibly a wrong branch state
<slangasek> yeah
<cjwatson> OK, I'm building everything in main in a canonistack instance with a chroot with the flags export hack deleted from dpkg-buildpackage; may not need to complete that run, but I'll see how it does over the weekend
<cjwatson> least sophisticated buildd ever, it's a for loop around sbuild ;-)
 * slangasek grins
<Daviey> rebuildd, whilst not that cleanly written.. is great for this.. i had it running across 3 different machines before, sharing the same dispatcher.
<Daviey> took some changes to make it work with sbuild.. and a seperate *.py for adding jobs.. but that along with lpapi worked really nicely.
<cjwatson> yeah, I might try something a bit more packaged when I have a bit more time.  mini-buildd looked promising too.
<Daviey> ISTR mini-buildd was single host?  you couldn't dispatch the jobs to multi-hosts?
<cjwatson> It looks smarter than that to me, but I didn't look very hard
<cjwatson> Its package description talks about an autobuilder network
<cjwatson> And judging by its dependencies it already works with sbuild
<Daviey> Ah, groovy.. I must have been thinking of another tool.
<Daviey> cjwatson: The thing i liked about rebuildd was that i could use the sqlalchemy orm to produce reports on pass/fail/dep-wait.. doesn't seem mini-buildd is db backed.
<cjwatson> heh, I'm just doing grep ^Status: ;-)
<cjwatson> (sure, I suspect the second go-around I'll do something more sophisticated)
<Daviey> heh
<wgrant> ScottK, cjwatson: There's going to be a Launchpad dev at UDS, but nobody who knows anything about Soyuz. I'd go with the priority on packageset.
<wgrant> Pretty simple.
<ScottK> wgrant: Is a bug enough for this?
<wgrant> Yes, particularly if cjwatson does the work, otherwise it won't be done for 2 years
<ScottK> Sigh.
<cjwatson> I can do the work, that's fine
<wgrant> It's not a particularly big piece of work
<cjwatson> You reckon my assessment above (add column on packageset, export on webservice, add in .score) is about right?
<cjwatson> Aha, -Wl,-Bsymbolic-functions is detectable in the output of 'objdump -R'
<cjwatson> So I think I'll build main, extract libraries, objdump -R, compare with real archive
<wgrant> cjwatson: Yeah
#ubuntu-release 2012-04-28
<cjwatson> Right, that's well within my capacity then
<cjwatson> ScottK: file bug, assign to me, I'll take it from there
<ScottK> cjwatson: Thanks.  Will do.
<wgrant> Thanks.
<slangasek> bug #989902 is strange; can anyone confirm this is actually an issue on Kubuntu?
<ubot2> Launchpad bug 989902 in ubiquity-slideshow-ubuntu "Kubuntu 12.04 Alternate CD missing file" [Undecided,Invalid] https://launchpad.net/bugs/989902
<ScottK> cjwatson: Bug is Bug #990219, but apparently I can't assign it to you.
<ubot2> Launchpad bug 990219 in launchpad "Reprioritize package build scores based on packageset" [Undecided,New] https://launchpad.net/bugs/990219
<wgrant> ScottK: I've triaged and assigned it
<wgrant> (you can only assign to random people if you're the project's bug supervisor nowadays, because users were being a bit overhelpful)
<ScottK> Thanks wgrant.
#ubuntu-release 2012-04-29
<skaet> edited ~/cdimage/www/full/netboot/precise/index.html to point to precise's community instructions instead of oneiric's.
<skaet> Hasn't picked up yet though, so wondering if there's a step I'm missing
<slangasek> sync-mirror?
<ScottK> skaet: I think Barry's proposed release note in Bug #954595  should be added.
<ubot2> Launchpad bug 954595 in python2.7 "ImportError: cannot import name urandom from os" [Undecided,Invalid] https://launchpad.net/bugs/954595
<skaet> ScottK,  read through it and agree.   Have gone in and added.  When you're adding a release-note project in future, could you be explicit by targetting it to series the release note applies to.   I've done it for this one now already, since I had to go in and update.   If they're release targetted, it becomes easier to find, and update for the release, as well as tracking those that may end up spanning multiple releases.
<skaet> Thanks for flagging it.  :)
<skaet> slangasek,  yup, that sorted it.  :)
<skaet> Thanks!  :)
<slangasek> skaet: ok, good
<slangasek> cjwatson: debhelper merge uploaded
<knome> somebody else who could answer questions about QA tracker/QA iki
<knome> *else than stgraber :D
<slangasek> infinity: hmm, I just hit that libc 'unexpected copy' nonsense on an amd64 sid chroot
<infinity> slangasek: Yeah, I found some older reports of same here and there.  It's not new, but I'm not sure how to reproduce it.
<infinity> slangasek: If your chroot is still in the broken state, could you tar it up for me?
<slangasek> infinity: turns out my sid chroot was broken because I'd previously had a locally-installed multiarch dpkg, then "upgraded" to a new Debian version, and dpkg didn't know where libc6's files were
<slangasek> infinity: once I manually fussed with /var/lib/dpkg/info, the upgrade worked.  It seems unlikely that this is the cause of elmo's powerpc issue
<infinity> slangasek: Hrm.  Well, it's not a fequently-reported thing, so it could be dpkg sadness in other cases too.  I can't readily see how it would work for almost everyone, but not quite.
<infinity> (I suppose one could argue that calling dpkg-query from maintainer scripts is bound to be fragile, and probably not sane in the first place)
<elmo> infinity: I don't understand this - the package contains the directory it's complaining about
<elmo> infinity:  unless I'm just blind/misreading the check
<infinity> elmo: But does dpkg claim that libc6 owns the binary in question?
<elmo> root@royal:/# dpkg -S /usr/lib/powerpc-linux-gnu/
<elmo> libgdbm3, libgmp10, libmpc2, libc6-dev, libgomp1, libpciaccess0, libpcre3, libssl1.0.0, libtinfo5, libc6, fakeroot, libstdc++6, libmpfr4, libglib2.0-0, util-linux, libdb5.1, libdrm-intel1, libdrm-nouveau1a, libdrm-radeon1, libdrm2, libffi6, libelf1, liblzma5, libncurses5, libncursesw5: /usr/lib/powerpc-linux-gnu
<elmo> infinity: ^--
<infinity> Wait, didn't you file a bug about this?  Why can't I find it now?
<infinity> But it should have been /lib/powerpc-linux-gnu/libc6.mumble, surely?
<elmo> infinity: yeah, sorry
<elmo> but
<elmo> infinity: http://paste.ubuntu.com/955807/
<elmo> dpkg -S doesn't claim it, I don't know if that's because the package is in a half-installed state or not
<infinity> It shouldn't be hi, if it never got past the preinst.
<infinity> If it is, then it was previously for some other broken reason...
<elmo> yeah, you're right it's ii
<elmo> oh
<elmo> I see
<elmo> infinity: http://paste.ubuntu.com/955812/
<infinity> *blink*
<infinity> But ou have 2.15 installed?
<elmo> infinity: 2.15 is what I'm *trying* to install
<elmo> and whose preinst is freaking out
<infinity> Oh, err.  From 2.13 to 2.15.  That should work fine.  I'd still like a copy of that filesystem, if it's not way too much hassle.
<elmo> infinity: ok, I'll do it later, I'm too latency-ified right now
<infinity> Fair enough, I'm in a jetlag-induced haze of stupid right now.
<cjwatson> slangasek: isn't this vaguely reminiscent of some of the problems Guillem was alluding to with the in-core dpkg db layout?
<cjwatson> particularly disappearance of info files on upgrade from M-A none to M-A same
<cjwatson> hm, that was M-A none config-files though, which seems a bit unlikely for libc6
<cjwatson> maybe incorrect disappearance?
<slangasek> cjwatson: yes certainly - but it was self-inflicted in this case, by installing an Ubuntu version of dpkg on Debian and then upgrading, which is not supported :)
<slangasek> and by "upgrading" I mean "upgrading to a Debian version that still didn't support multiarch"
<slangasek> so it went: install Ubuntu dpkg, causing the database format to be marked as using the multiarch layout; upgrade to Debian dpkg, which doesn't know about the database format at all; upgrade libc6 with the Debian dpkg, creating /var/lib/dpkg/info/libc6.list and friends; upgrade Debian dpkg to multiarch-aware version, with no database upgrade because the flag was already set; libc6 files missing
<cjwatson> ^- mostly to clear NBS
<tumbleweed> re the hdf5 sync earlier, that's to get the transition rolling with the first autosyncs. It'd be nice if that was published before autosyncs started
<tumbleweed> I assume the archive will be open a day or so before we start autosyncing?
<cjwatson> accepted hdf5
<cjwatson> not sure yet, still waiting for results from my test-build of main with tweaked dpkg
<tumbleweed> thanks, yeah I assumed we were still waiting on that
<cjwatson> it's built 1897 source packages so far
<cjwatson> maybe I should have filtered out kernels, compilers, and language packs; oh well
<tumbleweed> you building everything in main?
<cjwatson> yes
<cjwatson> I ought to figure out some reasonable way to test all components; this was just a quick thing I could throw together in a few minutes at the tail-end of Friday
<cjwatson> filtering down to only things that actually build shared libraries would have been a slightly cleverer start
<tumbleweed> heh
<cjwatson> but that involved more effort than grep-dctrl
<tumbleweed> main is enough to give us an idea of the scale of breakage
<cjwatson> unfortunately I didn't do a test-build with new debhelper + new cdbs, which would probably have helped, but meh
<cjwatson> only one failure in my list so far, which was sbuild pre-emptively abandoning hope of having enough disk to build libreoffice
<cjwatson> so I think that's presumptive evidence that this at least won't cause mass build failures
<tumbleweed> sensible sbuild :)
<tumbleweed> I assume you are also looking for lack of hardening?
<cjwatson> I suppose I should just to check, but I believe we established that all the hardening flags that were dropped are already compiler default
<cjwatson> s
<tumbleweed> oh, I thought there was a gap
<tumbleweed> great
<cjwatson> we thought --param=ssp-buffer-size=4 was missing, but kees later found that that was present after all
<cjwatson> but I can compare hardening-check output easily enough
<cjwatson> of course, if I'm remembering the original purpose of -Bsymbolic-functions correctly, gaps in coverage of relatively little-used libraries won't make a big difference; most of the win was in core desktop stuff that's loaded frequently
<infinity> cjwatson: I'm still hoping to finish off fpc and llvm/clang tonight, though neither is particularly critical to opening the archive.
<infinity> (Just less effort for me if I do get it all sorted beforehand)
<cjwatson> OK
<cjwatson> Rough initial estimate: 733/6032 binary packages show differences in 'objdump -R' output with proposed dpkg change
<cjwatson> I'll see what it looks like in the morning, I guess
<cjwatson> Some of the changes are trivial/irrelevant
<cjwatson> Like extra libc symbols showing up as dynamic relocs for whatever reason I can't be bothered to untangle
<cjwatson> Maybe I should look only for removals
<cjwatson> diffing hardening-check output is puzzling
<cjwatson> some progressions, presumably due to stuff not built for a while being built with newer helpers
<cjwatson> advancecomp shows regressions in stack-protector, fortify, relro despite apparently making use of dpkg-buildflags
<cjwatson> oh, no, most of that is a cdbs bug that left out CPPFLAGS, fixed in quantal; but relro is puzzling since we thought that was the default
<cjwatson> apg regresses relro despite it having been last built long before the dpkg-buildpackage hack
<cjwatson> I wonder if the compiler has dropped relro-by-default or something?
<cjwatson> actually the cdbs bug in question making any difference is a bit odd too, given the purported compiler defaults
<cjwatson> bdfresize regresses fortify too
<cjwatson> last built on amd64 in intrepid
<cjwatson> and no sign of FORTIFY_SOURCE in that log
<kees> cjwatson: _lost_ relro? that is alarming
<kees> cjwatson: and you're building with the ubuntu compiler?
<kees> cjwatson: the only thing that could mess with fortify is lacking -O1 or higher (otherwise it's ignored)
<cjwatson> oh, hah, my check was backwards
<cjwatson> so now I need to wonder what those progressions are instead :(
<cjwatson> acct indeed seems to be lacking -Oanything and so regresses fortify
<cjwatson> ditto amarok
<cjwatson> acct appears to regress -fstack-protector too
<cjwatson> kees: so sorry for false alarm, but still some things to check
<cjwatson> kees: does -fstack-protector also require the optimiser in some cases, by any chance?
<cjwatson> kees: this build is in a precise chroot with the only change being the removal of the env export hack from dpkg-buildpackage
#ubuntu-release 2013-04-22
<jbicha> please reject that u-g-default-settings
<jbicha> I'd like to see the gnome-shell & u-g-default-settings uploads in for raring
<ScottK> Let's hope I rejected the right one.
<stgraber> good morning
<pgraner> morning stgraber
 * infinity is questioning the wisdom of waking up today.
<Laney> doko__: yes indeed (I get mailed about them). I'll upload something in a second.
<cjwatson> I'm going to temporarily remove ubuntuone-couch in order to be able to copy it back (there was an override accident).
<infinity> double-override explodey bug?
<cjwatson> wgrant reckoned "overridden twice the same way"
<wgrant> cjwatson: You shouldn't actually have to remove it
<wgrant> Just copying it over itself should work
<infinity> Yeah, just copying over itself works.
<infinity> Jinx.
<infinity> Either way, it's an irksome bug because no one notices the effects right away.
<cjwatson> wgrant: It didn't earlier, but I only just noticed that that was because I forgot to use -b
<cjwatson> But too late now
<wgrant> Aha
<wgrant> yes, that would do it :)
<infinity> We now have shankbot double-checking my work on kernel SRUs to make sure things don't disappear.
<cjwatson> Looks like it worked
<cjwatson> (That's what I get for trying to do out-of-the-ordinary LP-related jobs at the weekend)
<cjwatson> infinity: My new orphaned-sources script in u-a-t turns out to be good at spotting this
<infinity> cjwatson: \o/
<infinity> removed and blacklisted mozilla-gnome-keyring
<cjwatson> Though it probably doesn't work right on stable releases
<cjwatson> So shankbot's still helpful for SRUs
<wgrant> cjwatson: That won't notice things with arch-dep stuff as well, will it?
<cjwatson> It won't notice if a binary only disappears on a subset of architectures, if that's what you mean
<cjwatson> Or if only a subset of binaries disappear
<infinity> That nyquist/i386 FTBFS is messing with my head.
<stgraber> cjwatson: hey, I just went through the ReleaseProcess wiki page, updating the bits about the ISO tracker. I was also surprised to see no mention of britney/proposed-migration on there. What's the plan? turn off britney before we start rolling final images (so we can decide what goes as SRU and what goes as last minute changes to raring)?
<cjwatson> stgraber: Probably because it's the first release with it and we haven't made up a process yet :)
<infinity> stgraber: Yeah, a global block and unblock things as we want them, methinks.
<infinity> (ie: the same thing Debian does near release)
<cjwatson> Indeed, global block makes more sense than commenting out the cron job
<cjwatson> ("block-all source")
<cjwatson> I'll edit ReleaseProcess now
<stgraber> hmm, yeah, block-all indeed sounds better, that way we don't have to do all the checks ourselves before copying
 * infinity nods.
<cjwatson> It's not really a time-dependent thing though, it's "before publishing anything that's going to be a zero-day SRU"
<infinity> Would be nice if we could extend britney to understand seeds and do something like "block-all seeded-source", but meh.
<cjwatson> I think I'll put it at -3 days (i.e. now) and apply the hint
<cjwatson> Unless anyone objects?
<infinity> cjwatson: Go nuts.
<infinity> We'll definitely have a few things to let through, but I prefer us putting thought into it at this point anyway.
<cjwatson> Yeah
<stgraber> fine with me
 * cjwatson remembers to make a paired change to NewReleaseCycleProcess
<cjwatson> OK, hint applied, let's see if it works
<infinity> Such confidence.
<cjwatson> We'll need to keep an eye on excuses
<infinity> unblocks are just "unblock foo/ver"?
<cjwatson> http://ftp-master.debian.org/testing/hints/README
<cjwatson> But indeed
<infinity> Yeah, I have to google that every time.  We should just have the README in the hints bzr.
<infinity> Assuming britney will ignore it because the user "README" has no perms. :P
<cjwatson> doko__: Should we remove avian/armhf, or do you expect to be able to fix that?
<doko> cjwatson, hmm, can we remove it proposed instead?
<doko> it in ...
<cjwatson> How do you mean?
<cjwatson> There isn't an armhf build of avian in -proposed; that's kind of the problem
<doko> I mean, remove the source in binaries in -proposed
<doko> s/in/and/
<cjwatson> Oh.  Sure, if you want to withdraw the upload from -proposed you can, or if you'd prefer we can just put it on the list of uploads to carry over to s-proposed
<cjwatson> The latter might be cleaner if it's an "I'll fix it up, but not this week" kind of thing
<doko> yep, we can carry it over too
<infinity> Eh.  No point in keeping it in s-proposed if the plan is for doko to upload a newer version at some point.
<infinity> But either way.
<doko> same for handbrake, that was a bad sync :(
<infinity> doko: handbrake will be carried over, it builds fine against libav9, we just haven't migrated yet.
<cjwatson> infinity: Might just make the history clearer
<infinity> cjwatson: Did you have any clever ideas for git-annex's suckage?
<Laney> i am trying to penetrate this makefile
<Laney> to find out where to insert flags
<cjwatson> Yeah, Laney's clearly ahead of me here :)
<cjwatson> Laney: Or you could just build-dep on yesod on powerpc too - doesn't it work there now?
<Laney> yes, but armhf
<infinity> Someone sorting out pytables/ppc wouldn't hurt my feelings either.
<cjwatson> armhf won't work anyway will it?  git-annex uses template haskell
<cjwatson> Unless that's only in stuff that can be avoided ...
<Laney> not sure; the current version at least builds there on debian
<Laney> (in unstable)
<Laney> anyway, I ought to do some normal work, so feel free to take over
<Laney> I was trying to find out how to poke an -f-Webapp in for the non-yesod case in d/rules
<cjwatson> Oh, it got more cabalised?
<Laney> it kind of is, but I cannot tell at this point how much that gets used
<cjwatson> I'm happy (ish) to have a look
<cjwatson> infinity: Don't suppose you left leviathan on?
<infinity> cjwatson: I did.
<cjwatson> Orsome.
<Laney> the new version in Debian is evne more so, so if you get ragey looking at that might be an option
<xnox> infinity: i briefly looked at pytables/ppc but can only look at it against past EOD really as it quite a weird one =)
<cjwatson> Laney: Yeah, I was considering that a while back but it had a load of extra features and stuff
<Laney> la la la
<cjwatson> We probably should have done that weeks ago
<Laney> Well, hopefully we can find out how to do this, or decide that leaving armhf broken is alright
<cjwatson> It doesn't matter for proposed-migration at this point, but I agree it'd be good to fix
<cjwatson> Yeah, I think it's easier than you think.  -f-Webapp isn't the problem
<Laney> oh, good
<stgraber> infinity: hey, I just had a quick look at http://people.canonical.com/~ubuntu-archive/testing-ports/raring_probs.html and noticed it's not empty. For that hv-kvp-daemon-init entry, shouldn't it be safe to just make the package build only on i386 and amd64 (since AFAIK hyperV only supports those anyway)?
<infinity> stgraber: That absolutely should be arch-restricted, yes.
<infinity> stgraber: I'll do that right now.
<doko> cjwatson, cinnamon now built on armhf, but is it blocked now manually?
<infinity> I'll unblock in a sec.
<infinity> We've blocked the world now.
<xnox> stgraber: on the iso tracker, I'm failing to look up when was the last time the 3 MAAS testcases were fully tested on raring.
<xnox> Also do we have anyone confirmed to test MAAS with candidate images? =) jamespage had his turn already with quantal release ;-) so maybe someone else this time around?
<infinity> stgraber: New hv-kvp-daemon-init in the queue in 2 mins.
<stgraber> xnox: I'll get the dates from the DB, one sec
<stgraber> infinity: cool, I'll review once queuebot notices, should be an easy review ;)
<xnox> stgraber: cuase a recent enough test, might be ok for that. Thanks!
<stgraber> (will just need to remember to remove any leftover armhf and powerpc binaries afterwards)
<infinity> stgraber: I'll remove those now, so britney doesn't have a sad.
<infinity> stgraber: Done.
<stgraber> xnox: 2013-02-13 and 2013-02-14 was the last time those were covered, so they definitely need re-testing
<xnox> hm at Alpha2 time. stgraber do you know who did the test? Can we ping the same person? =)
<stgraber>        1289 |   37582 |      1 | 2013-02-14 17:00:37 | hggdh2
<stgraber>        1288 |   37582 |      1 | 2013-02-14 16:13:55 | hggdh2
<stgraber>        1290 |   37582 |      1 | 2013-02-13 21:26:06 | hggdh2
<stgraber> that was a day before he announced he was leaving Canonical, so that'd explain why we didn't get any result after that
<pgraner> stgraber, I'll track someone down to do it
<stgraber> pgraner: thanks
<pgraner> stgraber, no prob
<infinity> stgraber: OMG REVIEW FASTER RELEASE IS SOON EEEE!
<stgraber> infinity: had to wait 5 minutes for LP to give me a two lines diff ;)
<ogra_> there is a release ?
<infinity> ogra_: That's the plan.
<Laney> Oh crap, we aren't rolling?
<xnox> Well, at such a last notice, I guess we'll scrap pressing CDs =)
<cjwatson> stgraber: bug 1170120 :-)
<ubot2> Launchpad bug 1170120 in Launchpad itself "Package diff generation is unnecessarily unresponsive" [Low,In progress] https://launchpad.net/bugs/1170120
<stgraber> cjwatson: yay, thanks for fixing this!
<cjwatson> well, pending review and unlikely to make it now in time to be useful for raring, but yeah
<cjwatson> when I actually looked at it it became clear that the slowness was largely artificial
<cjwatson> pytables> I started looking at that the other day, it's just an endian-related bug I think, just didn't quite finish ...
<cjwatson> ^- that git-annex test-builds fine on armhf and powerpc
<Laney> +-- utf-8 umbrella (utf-8 cloud looks too stormy)
<infinity> cjwatson: Awesomesauce.
 * Laney wonders why that works, since it still seems to use yesod
<cjwatson> It's moved into a bit that's conditional on webapp
<cjwatson> instead of on assistant
<Laney> ah
<Laney> I see, Assistant.hs:140
<doko> dobey, u1db currently ftbfs, see http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20130329-raring.html
<cjwatson> Hm.  I wonder why we don't have a similar non-multiarch tclConfig.sh hack in tcl8.5-dev as in tcl-dev
<cjwatson> Quite tempted to add one
 * Laney gets back to renaming variables in lightdm
<infinity> Grr, missed accepting that by a few seconds. :P
<xnox> cjwatson: good point. =) should be there.
<cjwatson> Doing that now
<doko> cjwatson, are there that many more?
<cjwatson> Well, I found at least one, that's enough for me :-)
<doko> I just fear if we add it, then all of daniel chen's patches maybe get reverted in the s-series ...
<cjwatson> Doesn't seem like a big deal if they do
<xnox> the less the changes to packages, the quicker we can multiarch tktcl in debian the better.....
<xnox> as we do want to drop all patches and just be in sync with debian on most of those packages.
<cjwatson> Yeah, I'd rather increase the chances of actually getting this transition landed in Debian, TBH
<cjwatson> It's not as if it renders it any less M-A: same
<cjwatson> And it'll probably help various third-party builds
<xnox> and keep us more compatible with the rest of distributions out there....
 * xnox doesn't like how interractive parted chokes on uefi-enabled cds dd'ed onto pen-drives.
<ScottK> infinity: We have to britney unblock everything now?  Might be worth a mail to ubuntu-release to let everyone know.
<cjwatson> I'll do it
<ScottK> Thanks.
<infinity> cjwatson: dpkg-architecture is in dpkg-dev, do you want to, I dunno, make tk8.5-dev depend on it?
<cjwatson> infinity: Hmm.  tcl-dev and tk-dev don't
<infinity> cjwatson: Right, that was sort of my point.
<cjwatson> Well, I meant the existing ones in the archive (from tcltk-defaults) as opposed to tcl8.5-dev and tk8.5-dev
<cjwatson> But you may be right ...
<infinity> cjwatson: For package builds, this makes no difference, since dpkg-dev is build-essential, but for random people installing tcl8.5-dev and expecting the config script to work, it won't.
<infinity> cjwatson: Oh, does tcl-dev do the same wrong thing?
<cjwatson> Yeah
<cjwatson> I'll go fix it all
<infinity> Well, fixing that would be nice too.  Thanks. :)
<infinity> (Is there a non-dpkg-arch way to get that string, I wonder?)
<cjwatson> Don't think so
<infinity> Actually, wait, tcl-dev isn't MA:same is it, so there's no reason you can't embed that string at build time instead of doing it at runtime.
<infinity> Which seems more correct, since it should match the package arch, not the default dpkg arch.
<xnox> infinity: it is.
<infinity> Oh, it is.
<infinity> I missed the header in my apt-cache.
<infinity> Drat.
<xnox> infinity: MA & Arch should match between foo-defaults and fooX.Y
<cjwatson> Yeah, hence this hack.
<xnox> otherwise it just doesn't work......
<infinity> That hack will not work if your tcl8.5-dev is not the primary dpkg arch.
<cjwatson> Correct
<infinity> Oh well.
<infinity> Cross that bridge when it annoys us for cross-building, I suppose. :P
<cjwatson> But if you're doing that sort of thing I don't think it's excessive to convert to the right path for finding {tcl,tk}Config.sh
<infinity> Anyhow, if you want to add run-time deps on dpkg-dev, that would be shiny.  If you don't care, I can also pretend not to.
<xnox> I am slightly surprised that dpkg-architecture is in dpkg-dev and not dpkg, since I would have thought something like that would be desirable on e.g. all amd64 installs where we auto-enable multiarch out of the box.
<infinity> xnox: I don't see how the first part of your sentence relates to the second.
<cjwatson> It's irrelevant at run-time
<infinity> dpkg-architecture has pretty much zero runtime utlity (except when people try to do hacks like this)
<cjwatson> Even this isn't really run-time
<infinity> True, it's runtime of a dev package.
<cjwatson> The linker knows about the multiarch path, which is all that's needed
<cjwatson> (And the odd string embedded in binaries and such)
<cjwatson> infinity: All uploaded, should show up shortly
<ogra_> infinity, FYI https://wiki.ubuntu.com/Touch/AndroidAutobuilds
<xnox> infinity: ok. libdpkg-perl is only optional, despite being in many seeds. I somehow thought if dpkg-architecture scripts dependencies are all essential, there is no harm moving dpkg-architecture into dpkg. but turns out there is.
<seb128> if I upload an updated ubuntu-docs package, can it still get in for the release? (we updated the translation template on thursday last week and quite some translation teams worked over the W.E to get the new strings translated)
<cjwatson> I think so
<seb128> great, upload on its way
<seb128> thanks
<doko> cjwatson, using dpkg-architecture, and not b-d on dpkg-dev? I mean, it won't file on the buildds ...
<cjwatson> doko: Read scrollback :-)
<cjwatson> That's fixed in latest uploads
<doko> heh
<cjwatson> And doesn't need a build-dep, only dep
<cjwatson> infinity: When're we stopping image builds?
<cjwatson> ScottK: your unblock syntax is wrong - needs to be "unblock SOURCE-NAME/SOURCE-VERSION" as in my mail
<ScottK> cjwatson: Thanks.  I'll fix.
<ScottK> Fixed.  In my defense, I did that before you sent the mail.
<cjwatson> :)
<cjwatson> Still wrong though
<cjwatson> First / needs to be a space
<ScottK> oh
<ScottK> ok
<ScottK> Maybe that ....
<cjwatson> Yeah, looks better, thanks
<ScottK> Thanks for setting me straight.
<cjwatson> ScottK: oh, except you have the versions the wrong way round
<ScottK> Heh.  Not my morning.
<cjwatson> as in, the imageshack-uploader name with the ddtp-translations version and v.v.
<cjwatson> not meaning to call you out in public or anything, sorry :)
<ScottK> No problem.
<ScottK> Fixed even more.
<Laney> handily you can copy and paste from queue accept, afaics
<cjwatson> ScottK: not pushed though ... maybe a clash with my most recent rev?
<ScottK> Yep
<ScottK> Fixing
<infinity> cjwatson: After that openjdk-7 is done and migrated seems like a decent cutoff to do a respin and uncron.
<ScottK> Figures.  The ONE time I don't pull "since it's just been a minute since my last change."
 * Laney runs
<jbicha> seb128: your ubuntu-docs upload doesn't matter if we don't regenerate the language packs, right?
<seb128> jbicha, not sure, I tested a local build and some page are generated at build time
<seb128> jbicha, but in any case we are ready for the next langpack update
<Daviey> stgraber: I understand you reviewed juju.. and asked for some fixes.  It's in the queue now. Do you want to take that review or not?
<stgraber> Daviey: ah, I didn't notice it getting back in the queue. Yep, I'll take a look
<Daviey> stgraber: thanks!
<stgraber> Daviey: there you go
<Daviey> woot
<Daviey> super stgraber
<dobey> doko: can i get a retry for u1db? i just pulled it from bzr, built a source package, updated pbuilder, and built it in there, with no errors :-/
<Daviey> stgraber: I assume you checked suitable break/replaces ^ ?
<stgraber> Daviey: I think I did last week, anyway, I did a test build + test upgrade here today and it worked, so it should be good
<infinity> cjwatson: nyquist sorted.  Was a particularly icky and silly bug.
<infinity> cjwatson: Any traction on pytables?
<cjwatson> nyquist> good stuff
<cjwatson> pytables> Test-building a really crude fix now
<infinity> \o/
<cjwatson> overlapping strcpy> ah, yeah, that would cause mass confusiong
<cjwatson> -g
<ScottK> Is any of the non-partner stuff in New going to be accepted or should we just reject it all now?
<infinity> cjwatson: Yeah, there was a lot of tag-team WTFery to get down there.
<cjwatson> I was just looking at tegaki-omg-long-package-name
<infinity> ScottK: I just did vala earlier, I might still poke one or two others.
<ScottK> OK
<doko> dobey, given back on amd64. but the last retry was on Sat ...
<cjwatson> dobey: It fails in exactly the same way in a local sbuild instance.  Perhaps try that instead of pbuilder
 * cjwatson does a little dance as we get rid of magellanic (old torrent.u.c)
<infinity> !!
<infinity> Really?
<cjwatson> magellanic is dead, long live caranda
<infinity> Fuck yeah.
<infinity> I assume the new machine is all disky and RAMy and CPUy?
<cjwatson> No idea but I'd have hoped so.  It can't be that much worse than mag
<infinity> magellanic was a 486, I'm sure.
<cjwatson> Well, tegaki-zinnia-traditional-chinese has a giant prebuilt model file in its source which it ships, but it does include a Makefile for rebuilding it from the XML file, and apparently the Debian ftpmasters were happy with tegaki-zinnia-simplified-chinese which is basically the same
<cjwatson> So minded to accept if only because otherwise it's kind of unfairly inconsistent
<utlemming> stgraber: around?
<dobey> cjwatson: but the build depends isn't different for the package, so the same dependencies should be installed in both. why would it fail in sbuild but not pbuilder? that makes absolutely no sense to me.
<infinity> dobey: Which package is this?
<infinity> dobey: I missed the context.
<dobey> infinity: u1db
<dobey> infinity: the tests failed in doko's archive test rebuild
<dobey> but they aren't failing under pbuilder
<dobey> though i do get similar failures running tests for u1db trunk, on my actual raring system. but it's pretty hard to determine what actually broke and caused the failures, since u1db hasn't changed in the archive since decemberâ¦
<doko> dobey, did you check what cjwatson suggested (running in sbuild)?
<infinity> Explodes here too.
<dobey> doko: as soon as i figure out how to do that i guess
<dobey> doko: but that doesn't really help, other than knowing that it does fail in sbuild (but not pbuilder)
<dobey> doesn't tell me why it fails
<infinity> Shouldn't need sbuild.  You can just grab the chroot tarball, unpack it, chroot in, install build-deps and build.
<infinity> If you really can't make it fail in a pbuilder/raring setup, your chroot might be a bit dirty.  You could compare installed packages.
<doko> dobey, failed in the december test rebuild too ... http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20121221-raring.html
<dobey> i wonder what broke it
<cjwatson> dobey: Might be some other minor difference in the environment.  I believe sbuild is a bit stricter about clearing it out.
<cjwatson> dobey: In any case, reproducing it locally will let you investigate directly rather than guessing; it usually becomes clear once you find the cause.
<xnox> to me it looks like a PYTHONHASHSEED issue, worth a try running tests with 1..10 and see if some of them pass while others fail.
<cjwatson> dobey: (sbuild has options for "don't purge the chroot if a build fails", so you can schroot in and try finer-grained things.)
<cjwatson> Plus, sbuild is just plain more relevant than pbuilder ...
<dobey> xnox: right. though hash_randomized is set to 0 in sys.flags hereâ¦
<dobey> cjwatson: sbuild is also just plain more pain that pbuilder (documentation tends to recommend pbuilder, and it's certainly much easeir to set up and get working, especially given that local sbuild and what is on launchpad also differ)
<xnox> looking at the failure somethind does produce the results out of order, might as well test them once sorted.
<doko> yes, hash rand. is turned off by default in 2.7
<xnox> dobey: exacatly how "mk-sbuild raring" is harder than "pbuilder-dist raring create" with "sbuild -d raring foo*.dsc" and "pbuilder-dist raring build foo*.dsc" ??????
<cjwatson> dobey: *shrug* I use sbuild for everything, I'm not failing to eat my own dog food here
<seb128> quick release question
<cjwatson> I don't find it difficult
<dobey> anyway, i'm not trying to argue about sbuild vs. pbuilder or anything. i just want to be able to figure out what is going on here, because the tests work fine in quantal, but not in raring.
<xnox> dobey: the distro-builders use sbuild for a reason ;-)
<seb128> the gtk patch from https://launchpad.net/ubuntu/+source/gtk+3.0/3.6.4-0ubuntu7 (uploaded a week ago) created some scrolling jerkiness for some users, who are suggesting we revert the change for the release
<cjwatson> And while it's true that local sbuild and LP sbuild differ, in practice they differ much less than any sbuild and pbuilder.
<xnox> thus it's good enough arguments as to which one is "better" =))))
<seb128> the issue is not a blocker either way
<dobey> xnox: they also use a different sbuild setup than one can easily create locally
<dobey> xnox: and i don't care which one is "better"
<seb128> would you recommend to rather got for a SRU or upload to raring still?
<cjwatson> Not significantly different in the majority of cases, and if you care about that then why on *earth* are you using pbuilder to try to reproduce sbuild problems?
<cjwatson> At the very least try sbuild before asking other people ...
<cjwatson> Since in this case it didn't differ, and it also doesn't differ in most others
<ScottK> seb128: If you're confident you could SRU it, go ahead and upload and do the SRU template in the bug.  We just won't unblock it and then it'll be available if we decide to push it in.
<seb128> ScottK, ok, thanks
<Daviey> I've only ever seen the chroot difference between LP's and locally created matter once.  And in that instance, i downloaded the LP tarball and based my build on that, to debug
<xnox> dobey: for me it fails utterly different from how it fails in the test rebuild. http://paste.ubuntu.com/5593211/
<xnox> dobey: the test-suite failures in the rebuild, seem like one can address them due str != unicode (note comparison of "string" and u"string") and sorting actual before comparing with reference.
<dobey> xnox: 'foo' == u'foo' in python 2
<dobey> xnox: only if the encoding was actually different would it fail
<xnox> dobey: true, then I don't understand the first failure here https://launchpadlibrarian.net/137872928/buildlog_ubuntu-raring-i386.u1db_0.1.4-0ubuntu2_FAILEDTOBUILD.txt.gz
<xnox> whitespace?! wtf =)
<dobey> no it's not the whitespace. it's that the values are different
<jbicha> is it ok that I marked today's Ubuntu GNOME images as ready for final testing?
<dobey> it's not just an ordering issue (though that is part of it)
<xnox> right, yeah, there is an extra one. missed it.
<xnox> dobey: I have just created a fresh pbuilder-dist raring create, and it fails in it as well, this time with failures as in the rebuild. Maybe your pbuilder chroot got something stray left in it? e.g. dropped essential packages and the like do not get autoremoved... or maybe it's out of date w.r.t. build dependencies.
<xnox> with pbuilder-dist raring build u1*.dsc
<xnox> dobey: so it's not even sbuild vs pbuilder problem.
<dobey> so it's sqlite that broke
<infinity> gtk?  Really?
<ScottK> infinity: I told him to go ahead and upload for SRU and we'd just not unblock.
<infinity> Ahh.
<infinity> Well, we can unblock if there's a respin and we feel the urge.
<infinity> (And we're respinning tonight anyway, so we'll see)
<ScottK> Right.  It'll be there if it seems we want it.
<infinity> ScottK: I need to escape this network for a bit, are you going to review and accept that gtk?
<ScottK> It's unlikely I'll feel like I know enough to decide, but I'll look at it and accept if I'm comfortable.
<infinity> Check.  If no one else gets to it, I will later.
<ScottK> I can ask someone else to review if not.
<seb128> infinity, ScottK: the gtk upload is basically "revert to what we had until one week ago"
<seb128> if you debdiff 0ubuntu6 and 0ubuntu8 you will just get the changelog diff
<seb128> the bug the patch tried to fix was already there in quantal so it's not a new bug or recent regression we tried to address
<ScottK> Thanks seb128
<seb128> ScottK, thanks to you guys for looking at it ;-)
<ScottK> OK.  Done.
<dobey> doko: ok, i've filed bug #1171568 for the regression in sqlite
<ubot2> Launchpad bug 1171568 in sqlite3 (Ubuntu) "libsqlite3-0 3.7.15 breaks u1db tests" [Undecided,New] https://launchpad.net/bugs/1171568
<phillw> is the cron off?
<ScottK> There's a rebuild planned for tonight.  Dunno if it's via cron or not.  (trying to answer what is, I think, your actual question)
<phillw> thanks ScottK, yeah, that was the question, lubuntu still shows 21st :)
<slangasek> cron is off, yes
<slangasek> so rebuilds are manual at this point
<slangasek> I thought they were already run though, maybe I misunderstood?
 * slangasek checks nusakan
<phillw> slangasek: lubuntu shows 21st on my browser. Can someone else check.
<slangasek> correct; the question on my part is whether that's because a build is pending, or because a build failed
<infinity> cron is off, unless stgraber failed at that.  I'll kick off a bunch of rebuilds before bed, unless someone in a more sane timezone wants to do that for me.
<slangasek> infinity: "before bed" - are we currently waiting for some publication before kicking them off?
<ScottK> Since pitti doesn't seem to be around, is there anyone who has a minute to examine a possible fix for a jockey problem before I take a cleaver to it to fix something?
<ScottK> If you can give me half an hour, I think I can have jockey working for wl again.  That may just affect Kubuntu though.
<infinity> slangasek: gtk+3.0
<slangasek> infinity: ok
<infinity> slangasek: The armhf build is just finishing up, and I've unblocked it in britney.
<slangasek> ScottK: where jockey is concerned, by instruments are no less blunt
<slangasek> s/by/my/
<ScottK> OK.
<infinity> slangasek: If you're cool with a respin of The World, I can pretend not to care until the morning.
<slangasek> infinity: I'm not sure what the current recommended method of respinning the world is - pointer?
<infinity> slangasek: Colin and I have just been copying and pasting from crontab.
<slangasek> ok
<infinity> The old "pipeling" no workie since the python rewrite, and neither of us has bothered to do anything cooler just yet.
<slangasek> any ordering constraints?
<infinity> s/pipeling/pipeline/
<infinity> slangasek: Just jamming it all in at once should more or less DTRT with locking.  But if you want to be clever, you can try to keep, say, the ARM and PPC builders full. *shrug*
<infinity> slangasek: I found that, roughly, running two sessions, where you go top down in one, and bottom up in the other, and meet in the middle, seems to keep everything busy.
<slangasek> I could just run everything in the background and trust the locking :)
<slangasek> s/the background/parallel/
<ScottK> Testing my jockey fix now.
<infinity> slangasek: That should generally DTRT.
<ScottK> Meh.  Trickier than I thought.  Getting a bigger hammer.
<ScottK> Did we stop making the Kubuntu powerpc image on purpose?
<ScottK> Someone's actually testing it, so it might be nice to have one less than three weeks old.
<ScottK> (or point me to a failure log please)
<doko> ScottK, infinity: the libfilesystem-ruby source should be removed, the new kid on the block is ruby-filesystem
<phillw> ScottK: you can blame smartboyhw. He told me that your PPC tester had lost his charger for the laptop he had and asked if our lubuntu PPC testers would assist. If it is too late for a re-spin, i will cancel the request.
<ScottK> No, I'm in favor of testing if we can get a current image.
<ScottK> What he said was correct.
<phillw> ScottK: and 'blame' is meant with a smile, he is a dedicated tester team lead and is quite entitled to ask other teams for help, you guys on kubuntu helped lubuntu out a lot in our early days... testers repsond to any SOS
<ScottK> Ah.  OK.
<ScottK> slangasek: Can you tell why Kubuntu PPC is out of date by several weeks?
<phillw> ScottK: ppc installer is a pain, but if you get a respin, we may be able to test it to the level that lubuntu uses for a desktop system.
<ScottK> Yeah
<slangasek> ScottK: looking to see
<ScottK> Thanks.
<phillw> ScottK: Whilst I 'can' edit test suites, I'd ask you to to set it to the same as lubuntu uses. There is more chance of getting a passed by the skin of teeth, with release notes.
<phillw> I'm not kubuntu team :)
<slangasek> ScottK: no obvious cause; etc/default-arches appears to be correct, and there's no indication of a livefs build attempt
<ScottK> slangasek: Someone may have stopped it due to a lack of testers.  Now we've got one.  Would you please give a respin a shot?
<phillw> +1
<slangasek> ScottK: I'm not seeing *where* it's disabled; something is preventing it from being built, I'd like to get to the bottom of that
<ScottK> OK
<ScottK> Thanks
<slangasek> it's not a deliberate change, that would be done in etc/default-arches
<slangasek> so there's a bug somewhere
<ScottK> I think the jockey problem is release notes material unless pitti makes a magical appearance.
<slangasek> ohwait, maybe my local branch is out of date; let's see
<slangasek> mmm still no
<infinity> slangasek: It's disabled in production.  Was done during the last milestone and not reverted.
<slangasek> ah.
 * slangasek reverts
<slangasek> mmm, there's an edubuntu diff as well
<slangasek> ok, firing a kubuntu powerpc build
<infinity> The edubuntu diff should stay.
<phillw> talk about re-spin the world? :)
<ScottK> FSVO world
<slangasek> so as it happens, royal seems to be doing a whole lot of nothing
<slangasek> ah, no, it's really just that slow compared to the others :/
#ubuntu-release 2013-04-23
<TheDrums> stgraber: I'm guessing this isn't the once a year you fixup pastebinit?
 * dtchen is very confused about the rejection of libfilesystem-ruby_0.5-3.1ubuntu1 (e.g., https://launchpadlibrarian.net/138047596/upload_4512415_log.txt)
<infinity> dtchen: It's replaced by ruby-filesystem
<dtchen> infinity: ah, thanks
<darkxst> would it be possible to get my gnome-shell/mutter SRU for Q approved? it has been in the queue for 2 months now!
<plars> infinity: know if anything more is going to be done on the iso size?
<ScottK> Accepted pidgin for (probably) an SRU.  I'm not unblocking, but it'll be there if there's a respin.
<dtchen> ScottK: thanks
<ScottK> dtchen: No problem.  I've got the easy part of the job.
<phillw> sot
<phillw> ScottK: pidging?
<phillw> 8
<phillw> 8pidgin
<phillw> awa,
<phillw> back to hey
<phillw> key board
<phillw> sorry about that, ScottK. (04:13:07) ScottK: Accepted pidgin for (probably) an SRU.  I'm not unblocking, but it'll be there if there's a respin. as the world is being re-spun, will this arrive?
<ScottK> I meant another one.
<ScottK> Those respins are already in progress.
<phillw> crikey!! I hope we do not have a respin the world after this one...
<phillw> thus
<phillw> Thursday is not running away. If you guys want to make a week on Friday.. the testers will no complain. :D
<ScottK> Come one.  We've respun on Thursday before and made it.
<phillw> ScottK: indeed we have, but is that a standard, or an exception. I was still pulling in test reports as versions were being accepted as okay to release... Possible, it is, correct it is not :)
<ScottK> You gotta do what you gotta do.
<ScottK> We aren't going to respin without a good reason.
<ScottK> That's why I said "if".
<ScottK> Don't accept jockey yet.
<cjwatson> phillw: given bug 1080701, at least one further respin-world is likely.
<ubot2> Launchpad bug 1080701 in ubiquity (Ubuntu Raring) "After 'Preparing to install Ubuntu' screen, raring installation hangs" [Critical,Confirmed] https://launchpad.net/bugs/1080701
<ScottK> cjwatson: The jockey upload is respin worthy for Kubuntu (all variants) only.  No rush though since another one is likely coming.
<cjwatson> ack
<ScottK> You might want to unblock pidgin too, not sure.  I'm off to bed.
<ScottK> stgraber: I tried to mark all the Kubuntu images for rebuild and got " An illegal choice has been detected. Please contact the site administrator."  If that button does what it thinks, I should be able to do that, right?
<ScottK> cjwatson: Assuming you can, would you please mark the Kubuntu images for rebuild in the ISO tracker?
 * ScottK goes to bed (really this time).
<cjwatson> ScottK: Done.  No ability to tell/guess why it didn't work for you, though.
<stgraber> good morning
<stgraber> ScottK: hmm, that's very weird. I think slangasek once reported something similar. I'll take a look at the logs see if I can spot something useful in there
<stgraber> TheDrums: nope it's not
<TheDrums> 'Tis a pity, think debian is broken again. :P
<stgraber> TheDrums: well, paste.debian.net seems kinda dead indeed, but that has nothing to do with pastebinit ;)
<TheDrums> Indeed not. :)
<TheDrums> (DDoS provided by pastebinit! ;) )
<smartboyhw> Release Team: When will the upgrade testcases land in http://iso.qa.ubuntu.com/qatracker/milestones/269/builds ?
<smartboyhw> It should be just a matter of copying:)
<stgraber> I'll do that
<smartboyhw> stgraber, thanks \o/
 * smartboyhw hugs stgraber 
<psivaa> cjwatson: xnox: http://pastebin.ubuntu.com/5594979/ is the failure that i was talking about in #u-installer
<gema> psivaa: which line has the problem?
<psivaa> gema: error removing libgksu2-0 is the pop up on the installer
<gema> psivaa: ack
<psivaa> gema: if you look for Removing libgksu2-0 ... in the above paste there after some errors reported
<stgraber> psivaa: do you still have access to that machine?
<psivaa> stgraber: yes, that's in the lab
<stgraber> psivaa: do you have SSH installed on it? (I have a VPN key for the lab)
<gema> stgraber: yes
<stgraber> ok, let me quickly setup my VPN here (reinstalled my laptop on Sunday) and I'll take a look
<psivaa> stgraber: utah-7938-raring-amd64 is the machine in aldebaran
<xnox> psivaa: do you have the rest of the utah logs? how big is the hard-drive?
<stgraber> xnox: looks like a miscompile of some python module to me which then causes all the crashes, should be easy enough to confirm once I've got access to it
<cjwatson> it's a python2.7 failure, encodings.normalize_encoding failing with AttributeError; but the code on disk looks fine; looks like either what stgraber says or data corruption copying the source file to disk
<cjwatson> not an installer bug as such, in any case
<stgraber> ok, so I'm on aldebaran, now to figure out how to connect to that VM :)
<psivaa> sorry had to reboot
<stgraber> psivaa: I'm on aldebaran though that VM (utah-7938-raring-amd64) doesn't answer on port 22, how do I get a shell in there?
<xnox> stgraber: connect to vnc / kvm via virt-manager?
<psivaa> stgraber: virt-manager  -c qemu+ssh://the.machine.ip/system
<psivaa> xnox: the drive is 5G and i'll give you the rest of the logs in a sec
<xnox> psivaa: Somehow I don't think 5GB is big enough anymore, as we peak higher in disk usage and then remove a few things.
<stgraber> /dev/vda1       7.3G  2.7G  4.3G  39% /target
<stgraber> cjwatson: it's not corrupted pyc files for once...
<stgraber> I just wiped them all and still get the stacktrace
<stgraber> oh wow, something went extremely wrong
<cjwatson> have a look at /usr/lib/python2.7/encodings/__init__.py ?
<stgraber> cjwatson: just did, the file sizes match but the content is full of nothing
<stgraber> root@utah-7938-raring-amd64:/# hd /usr/lib/python2.7/encodings/__init__.py
<stgraber> 00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
<stgraber> *
<stgraber> 00001642
<stgraber> root@utah-7938-raring-amd64:/# ls -l /usr/lib/python2.7/encodings/__init__.py
<stgraber> -rw-r--r-- 1 root root 5698 Apr 19 19:20 /usr/lib/python2.7/encodings/__init__.py
<cjwatson> this isn't xfs is it? :-)
<cjwatson> (to be fair I think that problem is a thing of the distant past)
<stgraber> nope, good old ext4 ;)
<cjwatson> default data= ?
<stgraber> /dev/vda1 /target ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
<cjwatson> data=ordered is the default and IIRC the sane one
<stgraber> the __init__.py outside of /target looks good (matches the one on my laptop)
<cjwatson> as long as it's not the crazy data=writeback
<stgraber> and there's no error whatsoever in dmesg
<stgraber> psivaa: was that the first time you had this issue or did you see it in previous tests too?
<cjwatson> and is it reproducible?
<psivaa> this is the first time i'm seeing this issue, and the second run has just finished with http://pastebin.ubuntu.com/5595062/
<cjwatson> so you're getting a succession of different random data corruption ...
<cjwatson> I would be inclined to suspect the host hardware
<pgraner> psivaa, what box is that on?
<stgraber> aldebaran
<psivaa> yes
<psivaa> stgraber: /var/cache/utah/iso is where the is is picked up from
<pgraner> psivaa, thats the box we replaced the raid controller on a few weeks ago
<psivaa> pgraner: no that's alderamin
<stgraber> I'll stop digging into this one and will instead finish setting up my laptop to run VMs here. If it's not an hardware issue with that host, we should see it show up in standard iso testing so the more we do the better.
<psivaa> pgraner: well alderamin was a week ago, not sure about aldebaran
<pgraner> psivaa, prob should check with retoaded he should be online anytime now
<psivaa> pgraner: ack
<pgraner> stgraber, I just ran it in KVM & Virt box and no issues
<stgraber> psivaa: the .iso looks good to me
<stgraber> psivaa: but if the .iso was the problem we'd be seeing squashfs errors in dmesg and the file outside of /target would also be corrupted
<stgraber> psivaa: so it looks like we're getting data corruption on the VM hdd, not from the source media
<psivaa> stgraber: ack, strange timing though
<stgraber> so it could be an hardware issue (though I'm not seeing anything in the host's dmesg) or some weird bug in virtio
<psivaa> stgraber: ack, would me try and install a vm on the host manually help narrow down?
<xnox> stgraber: well, a bug in virtio, disk emulation (sata, ide, virtio), VM write strategy. After all we don't want our kvm/qemu loosing files either.
<stgraber> psivaa: I guess you could boot a VM from the iso, with an HDD attached (virtio disk), then try to copy a bunch of files and see how many end up being corrupted. That'd give us an idea of how common the problem is, though actually debugging it won't be easy at all and the solution may be as simple as rebooting the host...
<psivaa> stgraber: ack
<stgraber> the fact that we got a file of the right size containing only \0 and not some random corruption at the middle of it and didn't get any error from the host or VM kernel would suggest some kind of ext4/virtio interaction (as it's "too clean" for hardware corruption)
<cjwatson> maybe?  not sure I have good intuition about what that might or might not cause
<cjwatson> if the metadata write was committed properly but the data write was just dropped on the floor then you'd see that
<ScottK> TheDrums: The machine that paste.debian.net lives on died.  It'll live again once the hardware is replaced.
<TheDrums> ScottK: Ah, thank you for the info.
<stgraber> cjwatson: hmm, indeed, what's surprising though is that this didn't trigger any kind of error in the VM dmesg. You'd expect ext4 to complain a bit if something like that happened.
<xnox> fsck? =)
<stgraber> xnox: running
<stgraber> xnox: nothing, looks clean (just did a standard fsck.ext4 -f -v)
<cjwatson> retoaded: let me know when you're around - would like to get a patch tested
 * ScottK hopes someone has ping mark for the new name high on their TODO list.
<cjwatson> in progress, so I hear
<cjwatson> I've bumped the size limits for Ubuntu desktop
<cjwatson> (since they were artificial anyway)
<cjwatson> kubuntu/daily-live: raring-desktop-powerpc.iso oversized by 41590784 bytes (1115332608)
<cjwatson> Riddell,ScottK: anything you want to do about that?  bump the limit?
<Riddell> drop it as far as I'm concerned
<cjwatson> the image or the limit?
<cjwatson> ScottK was trying to get testing lined up, I thought
<cjwatson> 23:00 <ScottK> Did we stop making the Kubuntu powerpc image on purpose?
<cjwatson> 23:00 <ScottK> Someone's actually testing it, so it might be nice to have one less than three weeks old.
<cjwatson> 23:00 <ScottK> (or point me to a failure log please)
<Riddell> he does like to keep those old things going :)
<ScottK> Riddell: We actually have a tester, so let's see how it goes.
<Riddell> ok up to you
<ScottK> bump the limit please.
<smartboyhw> Riddell, ScottK and I think I was mentioned yesterday in here about the powerpc image:(
<ScottK> Not much we can do about size.
<cjwatson> OK - uh, let me poke a bit, the size limit isn't arch-specific right now so I'll need to fix that
<infinity> ScottK: There are some things we can do about the size, but it might be a bit too much hassle to try to bring it down right now.
<cjwatson> So what can we strip out of the server-ship seed to make amd64 within size?  We only need ~6MB
<cjwatson> munin maybe?  Would take libdate-manip-perl with it
<pgraner> Daviey, ^^^^ suggestions?
 * jamespage takes a look
<cjwatson> Or python-svn
<cjwatson> quagga?
<cjwatson> if quagga is useful to you then you have a network :)
<cjwatson> ah, as Adam points out it might be network infrastructure, OK
<jamespage> I was thinking quagga as well
<cjwatson> No, Adam's right, you might need it to get your network working, and you might need to preseed it
<jamespage> python-genshi
<jamespage> hmm
<cjwatson> python-genshi is tiny
<cjwatson> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.raring/server-ship
<cjwatson> ^- to help prioritise things
<infinity> Dropping munin seems like an obvious win.  I can't imagine it being the sort of thing you'd ever preseed into an install.
<cjwatson> munin might actually be close to sufficient
<cjwatson> if it's something you can drop
<cjwatson> $ GET http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.raring/server-ship | grep munin | cut -d\| -f5 | numsum
<jamespage> well I'd rather drop backuppc than munin
<cjwatson> 4916980
<cjwatson> $ GET http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.raring/server-ship | grep backuppc | cut -d\| -f5 | numsum
<cjwatson> 718528
<infinity> I was looking at it from a "what might people build into their seeds to preinstall?"... You'd think backuppc might be something you'd install in a base image, but munin not so much?  I dunno.
<infinity> python-svn is likely not widely used, given the fact that you don't actually ship subversion.
<jamespage> nut might be a contender
<cjwatson> python-svn does seem like an obvious win.  It's about 1.5MB
<cjwatson> nut's about 1.7MB
<cjwatson> miscfiles?
<cjwatson> I guess we might want the wordlists
<cjwatson> openssh-blacklist*?
<cjwatson> I dropped those to Suggests in openssh a while back - it's been long enough since that vuln
<infinity> Pretty much nothing pulls in miscfiles, I have a hard time believing people install it intentionally except for Debian oldskoolers who know it exists.
<infinity> It's not the most obviously cool package name.
<jamespage> I'd +1 miscfiles
<jamespage> and siege  as well (but that is tiny)
<cjwatson> python-svn + miscfiles + openssh-blacklist* would be sufficient
<cjwatson> We wouldn't need to strip anything else after that
<stgraber> cjwatson: won't dropping openssh-blacklist in turn drop openssl-blacklist, saving a total of > 15MB? (or am I misreading the germinate output)
<cjwatson> No
<cjwatson> openssl-blacklist is pulled in by openssl-blacklist-extra which is seeded independently
<cjwatson> And I think the tradeoffs for installing openssl-blacklist-extra are different
<stgraber> ah yeah, missed that line
<jamespage> cjwatson, works for me
 * jamespage takes an action to do a full server seed review in the next month or so
<xnox> jamespage: i wonder if libjs-yui3-full could be avoided in mass-region-controller, by either embedding just the bare minimal, or creating a -medium yui package.
<xnox> jamespage: I somehow daubt that every single piece of yui is used.
<jamespage> xnox, please don't make me cry
<xnox> jamespage: well, maybe something for s-series to look into, to bring things back.
<jamespage> xnox, agreed
<cjwatson> I'll start making the seed changes for the above then
<cjwatson> (python-svn + miscfiles + openssh-blacklist*)
<cjwatson> rejecting live-build for a tweak, Adam will reupload
<retoaded> cjwatson, I'm around
<retoaded> pgraner ^^^^
<pgraner> retoaded, thanks, cjwatson will be right with ya
<retoaded> np
<cjwatson> retoaded: great.  I'd like to get http://paste.ubuntu.com/5594654/ tested on a machine that fails bug 1080701
<ubot2> Launchpad bug 1080701 in ubiquity (Ubuntu Raring) "After 'Preparing to install Ubuntu' screen, raring installation hangs" [Critical,Confirmed] https://launchpad.net/bugs/1080701
<cjwatson> retoaded: that patch won't quite apply to the live filesystem because of slightly different path names - can you deal or do you want a version with the paths mangled into shape?
<retoaded> cjwatson, let me peek
<cjwatson> actually why don't I just give you a mangled version anyway
<cjwatson> retoaded: http://paste.ubuntu.com/5595274/
<retoaded> cjwatson, ack
<xnox> stgraber: can you add wubi test-cases back into e.g. raring-daily milestone ? we don't do disk-image installs, but I still want to follow the test-case to do old-style wubi install to verify fixes and store the test results in the iso tracker.
<xnox> stgraber: e.g. product (wubi) same as currently in precise daily.
<tjaalton> hrm, could someone reject my lightdm upload, it's missing depends on the new plymouth version
<retoaded> cjwatson, let me reconnect all drives that were disconnected during testing then I'll give it a go.
<psivaa> cjwatson: xnox: stgraber: the latest preseeded installation has passed on the same host with amd64 image.
<cjwatson> retoaded: thanks
<cjwatson> psivaa: oh good
<infinity> tjaalton: Done.
<tjaalton> infinity: thanks
<infinity> tjaalton: Is this plymouth/lightdm thing meant to be an SRU, or are you angling for a last-minute fix?
<tjaalton> infinity: sru
<infinity> Kay.
<infinity> Then I'll switch hats before I review it.
<tjaalton> it's acked by slangasek already, I've tested it thoroughly here apart from this packaging detail :)
<cjwatson> ScottK: unblocked pidgin
<infinity> tjaalton: Check.
<tjaalton> same should be applied to other *dm's too, but I'll probably leave that up to their maintainers
<cjwatson> that's nasty enough that I'd rather take it, and it has confirmations in the bugs
<xnox> tjaalton: are there packages anywhere? I'd like to test is on my laptop which is affected by it.
<cjwatson> *bug
<tjaalton> xnox: plymouth is on ubuntu-x/x-staging already, I'll push lightdm too
<tjaalton> cjwatson: you mean my bug?
<xnox> tjaalton: please do =)
<cjwatson> tjaalton: no, I mean pidgin
<tjaalton> ah, cool :)
<stgraber> xnox: hmm, ok. I guess it'll confuse some people though as it'll link to non-existing files.
<xnox> stgraber: hmm.. I think pgraner is trying to activate it now. Meh.... i'm tested the upgraded signed wubi.exe as is on the cd and that has disk-image installs disabled....
<stgraber> xnox: done
<pgraner> stgraber, thanks
<stgraber> hmm, what? I added those to daily, not to final...
<pgraner> stgraber, I did the final by accident, I'll remove
<stgraber> ah, ok, it got added back to the manifest, so it then got auto-copied to Raring Final
<pgraner> stgraber, I'll let you fix it
<tjaalton> xnox: ok, uploaded.. should be built soonish
<xnox> tjaalton: thanks.
<stgraber> fixed
<retoaded> cjwatson, with all three drives connected it appears to have resolved the problem. The installer progresses to the point where I am able to select how I want to install (overwrite, alongside, something else) and takes me to the disk layout when I select something else.
<cjwatson> retoaded: ooooooh
<psivaa> cjwatson: will the upcoming respin include server images as well?
<cjwatson> psivaa: yes
<psivaa> cjwatson: ack, thanks
<Laney> can we have them marked on the iso tracker?
<xnox> stgraber: thanks a lot for wubi test cases! we may have found something.
<stgraber> cjwatson, infinity: just a quick update. I'm working with jodh on the two bugs smoser mentioned yesterday.
<cjwatson> new wubi in place which is actually the correct revision and will pop up the right things, thanks xnox
<cjwatson> respinning world for fix for bug 1070801
<ubot2> Launchpad bug 1070801 in OCS Inventory: OCSReports "Can't activate packages with automatic method" [Medium,Confirmed] https://launchpad.net/bugs/1070801
<cjwatson> er, not that
<cjwatson> bug 1080701
<ubot2> Launchpad bug 1080701 in ubiquity (Ubuntu Raring) "After 'Preparing to install Ubuntu' screen, raring installation hangs" [Critical,Fix released] https://launchpad.net/bugs/1080701
<cjwatson> (note part of that's in partman-auto, so applies to alternates/servers too)
<cjwatson> hopefully this is the last ...
<smartboyhw> cjwatson, all images?
<cjwatson> Yeah
<cjwatson> Unless you like partitioner hangs :)
<cjwatson> We only just figured out the fix this morning
<infinity> jbicha: Ouch.
<jbicha> can we get that u-g-default-settings fix in ^ before we respin ubuntu gnome?
<jbicha> oh, too late?
<cjwatson> might be lucky
<infinity> jbicha: We'll respin again if we missed the current one. :P
<cjwatson> the builds are all racing a lock
<infinity> jbicha: So, we'll see. :)
<jbicha> sorry about that, I was out for 30 minutes
<infinity> jbicha: Meh.  It happens.  At least your spins are quick.
<stgraber> sorry for the bad timing but three different people reported a breakage caused by the recent isc-dhcp update in quantal.
<stgraber> it looks like it's caused by some setups requiring access to a RAW socket now (likely as a result of the xen checksum offload patch)
<stgraber> the fix is a one line apparmor change that we already had in raring (which explains why we didn't see the problem there)
<stgraber> I'll upload the fix in a couple of minutes and would appreciate it if we could fast track that SRU as I've got no clue what kind of percentage of users we're talking about but I've got a feeling it's rather high
<slangasek> stgraber: ok, I can push it through when it shows up
<infinity> Nobody accept sphinxtrain until sphinxbase publishes on armhf.
<infinity> And same for pocketsphinx.
<stgraber> slangasek: looks like Launchpad's done diffing isc-dhcp if you want to take a look
<slangasek> stgraber: ok, accepted
<cjwatson> retoaded: sorry, we've had a bit of a build ordering snafu so Ubuntu desktop is delayed, but could you try the Xubuntu desktop images that just came out?  For the purposes of this kind of installer bug it should be the same
<retoaded> cjwatson, sure
<cjwatson> thanks
<slangasek> cjwatson, xnox, stgraber: so there have been a number of reports coming in here at the end about the "remove the media and hit enter" message not showing up in raring.  I'm pretty sure nothing's changed in plymouth; maybe something has changed elsewhere to regress the special-case handling of getting the necessary files all loaded before unmounting? (bug #1171792, bug #1170421)
<ubot2> Launchpad bug 1171792 in plymouth (Ubuntu) "message to remove external drive and press ENTER is hidden" [Medium,New] https://launchpad.net/bugs/1171792
<ubot2> Launchpad bug 1170421 in plymouth (Ubuntu) "Live session shutdown "hangs" (not showing "Please remove media ..." message)" [Undecided,Confirmed] https://launchpad.net/bugs/1170421
<stgraber> slangasek: FWIW I've seen that bug on and off since at least precise, so I doubt it's a new bug, however maybe we did something to make it more likely to happen
<infinity> Depends on how reliably it doesn't work...
<slangasek> hmm; I wasn't aware it was an ongoing problem, I thought it had been fixed in precise-ish with the casper file cache handling
<cjwatson> Yeah, I've been hearing reports of that for a long time; it's true that it's fragile
<retoaded> cjwatson, it might be a little while. my download speeds are horribly slow today.
<cjwatson> retoaded: ok
<cjwatson> let me know at some point so I know when I can hit the pub :)
<cjwatson> slangasek: I wonder if plymouthd is loading something dynamically maybe?
<retoaded> ack
<cjwatson> I dunno, it's incredibly hard to debug
<slangasek> cjwatson: it loads a number of things dynamically, but I thought all the things had previously been dealt with
<cjwatson> Let me see if I can reproduce it in kvm ... although I seem to remember that not being successful in the past
<xnox> same. here. this bug is very often easily reproduced in virtual box. As far as I remember we would drop back to tty1, yet the message is displayed in tty7. Switching to that tty1 should show it.
<stgraber> I've noticed I have better odds of reproducing it when testing Edubuntu and running ltsp-live, but it's still a 1 every 5 times kind of thing, so it makes adding debug everywhere to track it down quite a bit of a pain
<xnox> if we can somehow display the message across all ttys it would help, with like a Wall message.
<cjwatson> It's supposed to be displayed in plymouth, though
<slangasek> yes
<cjwatson> Which is very definitely on one tty :-)
<xnox> true.
<cjwatson> If I can reproduce it then *maybe* I can instrument it somehow - the problem of course is that your filesystem has just gone away
<slangasek> we do have a newer version of plymouth in raring vs. quantal, so it could be a new upstream dependency of some kind, I haven't checked
<slangasek> cjwatson: would it be any use to instrument on a running system to find what files are mmapped?  I guess that doesn't catch files that are opened/read/closed
<cjwatson> I think the problem is that you have to instrument some ill-defined set of processes
<stgraber> cjwatson: yeah, last time I tried debugging that mess I ended up building a custom initrd and booting from that, so I don't need to patch the various files at every single boot
<cjwatson> Maybe systemtap would be of use, if anyone knows it ...
<slangasek> cjwatson: is it that ill-defined?  I thought it's just plymouthd + plymouth (client) + the shutdown script
<cjwatson> What if it ends up waiting for udev or something - but you're probably right
<jbicha> ok, the Ubuntu GNOME images didn't have the updated settings so I clicked the Mark for re-build button on the iso tracker
<cjwatson> Hm, I don't have my plymouth tree here - what communication channel does plymouth -> plymouthd use?
<cjwatson> jbicha: OK, will poke it later
<xnox> cjwatson: just a socket as far as i remember.
<cjwatson> But a socket where?
<slangasek> cjwatson: mm, I thought it was an abstract unix socket
<cjwatson> OK, as long as it's not in a directory whose contents might be swapped out
<stgraber>     for path in $(which halt) $(which reboot) /etc/rc?.d /etc/default $(which stty) /bin/plymouth; do
<cjwatson> Did we start using fontconfig more aggressively?
<stgraber>         cache_path "$path"
<stgraber>     done
<cjwatson> I wonder if it's trying to load a font or some other text rendering thing
<stgraber> cache_path doing a find+cat of everything it finds
<cjwatson> kvm doesn't show plymouth properly at boot
<cjwatson> tail of the output on tty7 is "stty: standard input: unable to perform all requested operations"  "Please remove installation media and close the tray ..."
<cjwatson> But probably an invalid test since it's not actually showing plymouth
<slangasek> cjwatson: confirmed that the socket is abstract
<slangasek> cjwatson: shouldn't be using fontconfig any more aggressively than before
<slangasek> it does use fontconfig though
<stgraber> slangasek: does it preload the fonts or just loads them the first time it needs them?
<slangasek> so maybe that's why it's only been working intermittently?
<slangasek> stgraber: it uses fontconfig
<slangasek> so $indeterminate
<cjwatson> easy for the fonts to be out of cache, perhaps
<slangasek> yeah; I had wondered about that previously, but in the absence of bugs coming my direction I had assumed it was dealt with
<stgraber> so stupid question, but why can't we just show the message before ejecting the media? we're talking < 1s here so it's unlikely to make any visible difference to the user
<stgraber> basically do plymouth message (or echo), then eject, then do the plymouth watch-keystroke (or read)
<cjwatson> I was sort of wondering that.  Perhaps
<slangasek> yeah, I'd had the same thought
<xnox> how does one "eject" usb?
<xnox> as that needs removing as well.....
<xnox> (or you mean that well, it's not visible to the kernel / not-mounted)
<slangasek> xnox: not sure what the question is - one ejects the USB by physically disconnecting the drive
<slangasek> which is what the user should do, to make sure they don't get booted back into the installer
<cjwatson> Are we putting armhf+omap4 on releases.u.c this cycle?
<cjwatson> Adam seems to recall some debate about that
<cjwatson> And IS could do with knowing in order to prepare cloudfront rewrites
<slangasek> so last cycle we had desktop-armhf+omap4 on releases
<slangasek> and this cycle we didn't release it with beta, right?
<xnox> see ya =)
<cjwatson> But apparently that was because of a bug that's been fixed
 * slangasek nods
<slangasek> so this information used to be recorded in the release manifest
<slangasek> I'm not sure the move to iso.qa gives us that anymore
<slangasek> stgraber: ^^ ?
<infinity> slangasek: As a data point, we've also removed the omap4/desktop image from the website's download/arm page (on the staging site).
<slangasek> stgraber: also, *finding* the release manifest in iso.qa is a huge pain :/
<slangasek> infinity: why have we done that?
<infinity> slangasek: I'm not sure there's much point in having it on releases given how close we came to dropping the image entirely.
<slangasek> or rather, who made that decision?
<slangasek> (that's contrary to my last suggestion on the ubuntu-release thread...)
<infinity> slangasek: Came about from a conversation with the web team yesterday, and agreement from me, Pete, Rick... There's a mail thread about this too?  Fun.
<slangasek> yes, there was a mail thread about this, which Amrit (web team) was Cc:ed on
<cjwatson> also do you think we care about pushing dvd/preinstalled to cloudfront?  apparently we did for precise and not for quantal
<slangasek> hmm, which dvd, which preinstalled?
<cjwatson> https://pastebin.canonical.com/89790/
<infinity> Hrm.
<slangasek> we don't have dvd anymore, do we?
<cjwatson> oh yeah
<slangasek> and the only preinstalled we have this cycle is nexus7
<cjwatson> So Ubuntu preinstalled desktop armhf+<whatever>, preinstalled server armhf+<whatever>
<ogra_> what the heck are these ?
 * ogra_ glares at ubuntu-12.04-preinstalled-desktop-armhf+mx5.img.gz
<ogra_> we definitely never had such an image
<cjwatson> <shrug> I don't want to debug precise now, just trying to check :)
<slangasek> ogra_: infinity signed off on it ;) https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest
<infinity> ogra_: Sure we did.
<ogra_> a desktop mx5 ?
<infinity> Yes.
<cjwatson> http://cdimage.ubuntu.com/releases/precise/release/ubuntu-12.04-preinstalled-desktop-armhf+mx5.img.gz
<plars> cjwatson: my understanding was that desktop was no longer going to be released for omap4, we have desktop on nexus7 and netboot/server on omap4 still though
<cjwatson> begs to differ
<plars> pgraner: ^ unless something changed since then?
<cjwatson> plars: yeah, this isn't about "do we release it", it's about whether it's high enough traffic to push to cloudfront
<infinity> plars: No, it's still being released, though perhaps deemphasized.
 * ogra_ wonders who ever tested that
<cjwatson> I'm inclined to say just the things that are on releases.u.c
<infinity> ogra_: Jani did.
<ogra_> oh
<plars> ah, I see
<cjwatson> Which would match quantal
<cjwatson> Just want to make sure I'm telling IS the right things
<slangasek> cjwatson: so I don't see a compelling argument for either of the nexus7 desktop or the omap4 desktop/server being given precedence over the other on releases.u.c; I expect both are going to be lower traffic than e.g. the phablet image
<slangasek> is splitting the desktop image publishing between releases and cdimage problematic?
<cjwatson> ok, so let's just have cloudfront == releases
<cjwatson> slangasek: no
<slangasek> ok
<infinity> slangasek: No, we always did in the past.
<infinity> (And, indeed, powerpc goes to cdimage if it gets tested and released)
<slangasek> infinity: right, was asking on account of the armhf beta2 images that wound up in the pool but not published, wanting to make sure that wasn't a tooling problem
<infinity> Nah, that was just pre-publishing not taking ready states into account (intentionally).
<slangasek> cjwatson: so how would using cloudfront work wrt cdimage anyway?
<cjwatson> same way as it did last two releases :-)
<cjwatson> er, for precise anyway
<cjwatson> rewrites on IS' end
<slangasek> ah
<slangasek> cjwatson: right, so I don't imagine these will see a huge amount of traffic... if we're trying to minimize the load on cdimage, it would probably make more sense to cloudfront some of the flavors rather than these.  So +1 from me for just doing releases.
<stgraber> slangasek: well, the manifest is linked from the frontpage and on the builds page, but yeah, not exactly the most visible link ;) and if you intend to change it, then it's even better hidden.
<stgraber> slangasek: http://iso.qa.ubuntu.com/qatracker/milestones/264/builds is what we had in the beta
<stgraber> so it looks like we tested desktop armhf for the beta but didn't publish because it wasn't bootable
<cjwatson> yeah, from my pov the only once worth this kind of special handling are by definition on releases
<infinity> stgraber: Yeah, that's been fixed since.
<ogra_> right
<dannf> we're seeing a pretty serious kernel bug on calxeda highbank systems, LP: #1171582 - i've tested a workaround in finish-install, patch attached to that bug. is that something that, if approved, could still make the release?
<ubot2> Launchpad bug 1171582 in linux (Ubuntu) "[highbank] hvc0 getty causes random hangs" [High,Incomplete] https://launchpad.net/bugs/1171582
<stgraber> cjwatson, slangasek: want me to upload a casper with the re-ordering we discussed earlier. I don't think it's worth a respin but may be good to include if we have to respin for some other reason
<ogra_> dannf, i saw it mentioned in the kernel team meeting
<cjwatson> *ones
<ogra_> i think ppisati is actively working on it
<cjwatson> stgraber: hmm, we should probably get it into -proposed at least, yeah
<dannf> ogra_: yes, i'm working w/ ppisati - but my understanding is that we can't get a kernel in now
<infinity> Yeah, a new kernel at this point is definitely not going to happen.
<dannf> i tried to find workarounds we could just document, but came up w/ nuthin.. well, nothing that doesn't involve dropping to a shell and typing magic commands
<roaksoax> Hi! I was wondeirng that if I were to upload bug fixes that are not critical for release, would they be held in proposed for 0-day or should I file a proper SRU once raring is released?
<ogra_> dannf, note that this fix  will likely break server installs on omap (which is also in the generic kernel(
<ogra_> not that this is overly important i guess
<cjwatson> version should be 2.42ubuntu1
<retoaded> cjwatson, the xubuntu image appears to work with all disks connected; I can manage partitions during install.
<dannf> ogra_: break?
<dannf> or affect?
<cjwatson> ogra_: um, do omaps have /dev/hvc*?
<infinity> They shouldn't.
 * retoaded will be back in about an hour
<ogra_> dannf, well, if in a serial install no $serial_tty.conf is created i would say break
<cjwatson> ogra_: you've misread
<cjwatson> ogra_: the exit 0 is inserted lower than you think :)
<ogra_> oh, ok
<cjwatson> so with a fixed version number I'm fine with this change
<cjwatson> retoaded: yay yay yay
<infinity> dannf: I'll go ahead and sponsor that for you with a sane version.
<dannf> infinity: ok, thx and to be clear, i've done no testing on omap - i don't have that hardwre
<ogra_> dont worry ... a) i misread  and b) omap is a nice to have only
<ogra_> supported arches surely take precedence if its an on/off decision
<ogra_> (but in case it would have broken it there should have been a note about it somewhere)
<dannf> yeah - i don't see how it could negatively impact omap, but i never really see how i'm about to be wrong :)
<cjwatson> jbicha: ^- 20130423.2 has the new ubuntu-gnome-default-settings
<jbicha> cjwatson: thanks!
<cjwatson> finish-install unblocked too
<infinity> stgraber: ^-- Didn't like your casper upload?
<stgraber> infinity: right. I based that one on what was currently in the archive and not ubuntu:casper where I already had another fix staged.
<stgraber> so I'm now preparing a new one which contains two fixes instead of one (the other fix being detection of swap on virtio, simple one line change I noticed while debugging another issue a while back).
<dobey> hey all, can I get someone to accept rhythmbox-ubuntuone into quantal-proposed and precise-proposed please?
<phillw> can someone please turn back on the kubuntu-ppc iso, it got dropped from 'auto build' but does now have the lubuntu-ppc team agreeable to check it out.
<phillw> ScottK: do you still want kubuntu-ppc tested? Sorry, I should have asked you before I made the request :/
<infinity> phillw: Already done.
<phillw> infinity: thanks, for purely nostalgic reasons, I do care about ppc :)
<infinity> phillw: For bonus points, we also shrunk lubuntu/ppc a fair bit.  It might fit on a CD again.
<phillw> infinity: that would be a nice present to the guys
<infinity> (kubuntu/ppc won't, but none of the kubuntu images fit on CDs)
<phillw> thank you, if the lubuntu ones would, that would be amazing. Julien cannot shrink it more because the 'bug' is the number of kernels.
<infinity> Yeah, I knocked out the e500* kernels from desktop CDs today.
<infinity> Since they're really only wanted on server installs.
<infinity> Compare the size of lubuntu/ppc from 20130423 to 20130423.1, you should be pleasantly surprised.
<phillw> the old desktop / lapbook macs may be on the floor, but they are not dead  yet. If you make the iso CD sized I'll get the guys to have a whip round to buy those who managed it a beer.
<infinity> Hrm.  We might need to do something clever for your alternate CD too.  But at least the desktop one is shrunk.
<phillw> To be honest, my view as release manager is that we get ONE of them released. But, the testers never cease to surprise me. if the ac100 gets the nod, on lubunut we are pretty much good to go. :D
<ogra_> phillw, did the ac100 not get one ? popey did an install today
<ogra_> and afaik it was fine
<vanhoof> cjwatson: infinity: ogra_: dannf: verified bug #1171582
<ubot2> Launchpad bug 1171582 in linux (Ubuntu) "[highbank] hvc0 getty causes random hangs" [High,Incomplete] https://launchpad.net/bugs/1171582
<infinity> vanhoof: Lovely.  We'll keep that open, since it's actually a kernel bug, but good to know the workaround works.
<vanhoof> infinity: ack, just figured was worth a sanity check :)
<vanhoof> infinity: thanks (dannf you too :))
<ogra_> infinity, cjwatson .... so it seems we end up without gksu installed on desktop ... that would need a seed change i guess
<Laney> should it be installed?
<ogra_> gksu deps were removed from the two apps that had it on the desktop and it seems nobody added a seed entry
<dobey> Laney: i'd say no
<ogra_> Laney, well, pkexec doesnt really manage to fulfill the purpose
<dobey> Laney: or at least, i'd defer to security to answer that
<infinity> I assume it's only in the manifest as a ubiquity dependency and thus gets autoremoved at the end of the install?
<ogra_> though people can indeed use sudo
<Laney> right
<ogra_> infinity, xactly
<Laney> I don't know why it's a purpose that needs to be fulfilled by default - if you want it, you can install it?
<ogra_> yeah
<dobey> and that
<ogra_> well, its a convenience for scriping
<ogra_> *scripting
<infinity> But yeah, pretty much any HOWTO that says "run gksu gedit /etc/foo" could s/gksu/sudo/ with the same effect.
<dobey> Laney: it's that people are used to telling people to use it on forums and ask ubuntu and whatnot, to edit files that are owned by root. which is a generally bad thing to be doing anyway, if they don't know what they're doing enough to use sudo/vim instead
<infinity> Honestly, I'd consider it a ubiquity bug that gksu is on the CD at all, rather than a bug that it doesn't stay installed.
<dobey> infinity: that's what i just said in -devel :)
<Laney> dobey: They'll get a nice message telling them to sudo apt-get install gksu
<ogra_> infinity, yeah
<ogra_> the prob is that we have a ton of docs referring to it
<dobey> Laney: yeah. i don't really see any problem with it not being there
<Laney> Why did this just happen: https://launchpad.net/ubuntu/+source/libgcrypt11/1.5.0-3ubuntu2.1/+build/3970473 ?
<dobey> Laney: though if it was up to me, i'd probably just try to get it removed from the archive. :)
<infinity> Laney: Magic.
<Laney> Doesn't look like very good magic
<jbicha> well it would be cool if gedit or nautilus would prompt to elevate privileges when needed
<dobey> jbicha: also that
<infinity> Laney: (I did a mass give-back and forgot to exclude armel... To avoid the pain of buildd exploding due to a lack of a chroot tarball for armel, I replaced it with a kitten jpeg)
 * Laney downloads the chroot
<infinity> I've already removed it.
<Laney> No fun.
<infinity> Oh, but it hasn't been garbage-collected from the librarian yet.
<infinity> http://launchpadlibrarian.net/138118029/chroot-ubuntu-raring-armel.tar.bz2
<Laney> bee-yoo-tea-fuhl
 * Laney just WTFed that tar wouldn't bunzip it for a bit
<infinity> Decompressing kittens is hard.
<Laney> Time + food
<infinity> Ahh, tar -tuna
<slangasek> stgraber: I don't see any manifest link on the front page, fwiw
<stgraber> slangasek: so you see the list of milestones? look in the table header "Milestones for 'Raring' series (product manifest | testsuites)"
<stgraber> product manifest being the magic link you're looking for ;)
<slangasek> stgraber: oh man
<slangasek> stgraber: right, could that link please be made a link color? :)
<stgraber> I'll raise a bug about that for the next time I try to understand Drupal's css ;)
<plars> I suspect http://launchpad.net/bugs/1172002 is going to leave me with no swap after I reboot from this reinstall
<ubot2> Launchpad bug 1172002 in ubiquity (Ubuntu) "Install doesn't mount encrypted swap for reinstall" [Undecided,New]
<dobey> anyone on sru team around?
<dobey> also, does anyone know when the EOL announcement will happen for 10.04 (desktop)/11.10?
<phillw> dobey: the team do keep https://wiki.ubuntu.com/Releases updated but as we are really at the end of a new release, there may be a lag in asnwering personally.
<phillw> *answering*
<skellat> dobey: It appears May 9th was announced for both cases you inquire about.
<stgraber> utlemming: looks like your script doesn't know about Azure yet ;)
<utlemming> stgraber: yeah, it doesn't :) I still have to have get all that plumbed in
<dobey> skellat: ah, where is that? i didn't see it
<dobey> ah, on that wiki page.
<dobey> thanks
<dobey> phillw: ah, i wasn't looking for SRU team to answer the EOL question. i have a couple uploads that have been sat in unapproved for 2 weeks now, and want to get them accepted into proposed so i can move forward with testing and the SRU process :)
<infinity> dobey: I announced those last month: https://lists.ubuntu.com/archives/ubuntu-announce/2013-March/thread.html
<dobey> infinity: ah ok, thanks.
<dobey> infinity: can you do the accepting of rhythmbox-ubuntuone into quantal-proposed and precise-proposed btw?
<infinity> dobey: Ask me again in the morning?  Those diffs are a bit large for me to review before bed.
<dobey> infinity: ok, thanks
<sarnold> Hello all, jdstrand; I have prepared mysql updates for our supported releases. How shall I handle the raring package? The raring version was built for 'raring-security' rather than 'raring', in the security ppa. How shall I proceed?
<jdstrand> sarnold: we could copy to raring-proposed, but its tuesday before release. let's just use a -2 USN after raring is released
<jdstrand> sarnold: you can release all the others using unembargo and sis-changes with the -r option
<sarnold> jdstrand: again with anticipating questions :) hehe
<jdstrand> sarnold: upgrades went smoothe, right? ie, the new upstream release didn't cause any weird upgrade issues did they?
<sarnold> jdstrand: the test failures were consistent from one to the next, and the wordpress test worked well... though I'm just now noticing that I managed to overlook the quantal build in the ppa. :(
<jdstrand> sarnold: I was more talking about if a brand new raring server install had a 0-day conffile change or something weird
<jdstrand> sarnold: I wasn't expecting it, but it might be a factor
<sarnold> jdstrand: hrm, I haven't made a brand-new install of my raring vm in some time, I've just been apt-get dist-upgrading it along the way...
<jdstrand> sarnold: right. part of our testing should be upgrade testing though. Ie, use vm-qrt or the install-packages from the QRT tarball with the current packages. then use uvt repo -e, then do 'apt-get upgrade'
<sarnold> jdstrand: oh, yes, that worked fine. :)
<jdstrand> yeah, then a 0-day security update in raring-security makes sense to me
<gilir> is it possible to respin lubuntu alternate powerpc ? I removed some langpacks to make it cd sized
<slangasek> gilir: sure.  only powerpc needed?
<gilir> slangasek, yes
<slangasek> running
<gilir> thanks :-)
<slangasek> gilir: ^^
<ScottK> phillw: Yes.  Thanks.
<phillw> slangasek: thanks. gilir Is it now CD  sized?
<ScottK> infinity: I don't think there's enough to do about size on kubuntu ppc that it would ever fit on a CD.
<phillw> ScottK: we accept that, it is not an issue.
<gilir> phillw, lubuntu alternate powerpc is now cd sized
<phillw> WOW !! thanks you to all who have done this :)
<Noskcaj> is there a chance bug 1172059 will be fixed in time for release?
<ubot2> Launchpad bug 1172059 in ubiquity (Ubuntu) "kubuntu ubiquity encryption doesn't check password" [Undecided,New] https://launchpad.net/bugs/1172059
<smartboyhw> Noskcaj: We have people fixing, and we have testers:P
<ScottK> smartboyhw: Who's fixing?
<ScottK> Also a Ubiquity upload would affect all the flavors, so it's not just a Kubuntu decision.
<smartboyhw> ScottK: ah damn it is:(
<smartboyhw> s/is/would/
<ScottK> So if a fix becomes available, we'll have to see.
#ubuntu-release 2013-04-24
<phillw> ScottK: kubuntu-ppc is still not on http://iso.qa.ubuntu.com/qatracker/milestones/269/builds is it worth asking our ppc testers to look out for it?
<ScottK> Let me have a look.
<phillw> I'm going to send them one last nagging email :)
<ScottK> phillw: It's there now.
<phillw> okies, I'll amend my email :D
<ScottK> See. There you go.
<phillw> ScottK: are you ubuntu@kitterman.com ?
<ScottK> I am.
<phillw> okies, just so you get a cc
<ScottK> I'm also kitterman@ubuntu.com.  So you can actually do it either way.
<ScottK> ;-)
<phillw> ScottK: you have mail, either way. I'm not too PC with the lubuntu-qa team, we work hard, but chat easy :)
<ScottK> OK.
<ScottK> highvoltage: I'm a bit unsure what to to about calibre - http://launchpadlibrarian.net/138120901/calibre_0.9.18%2Bdfsg-1bzr_source.changes - It's on your image, so I'm relucant to accept, but if it's not in pre-release, we're stuck with the non-free stuff in the archive.
<TheDrums> https://launchpad.net/ubuntu/+source/adobe-flashplugin/  Not in raring?
<micahg> TheDrums: partner uploads happen at the last minute
<sarnold> also this exists https://launchpad.net/ubuntu/+source/flashplugin-nonfree
<TheDrums> micahg: Thank you.
 * micahg wonders if there's a doc reminding people they need to happen
<TheDrums> (There was plenty of packages in the partner repo, wasn't sure if it was removed or had something else done with it.)
<stgraber> good morning
<infinity> phillw: Any issues with me respinning lubuntu alternates for you today?  The current ones contain one stale package.
<stgraber> xnox, cjwatson: do you know if anyone looked at bug 1172002?
<ubot2> Launchpad bug 1172002 in ubiquity (Ubuntu) "Install doesn't mount encrypted swap for reinstall" [Undecided,Confirmed] https://launchpad.net/bugs/1172002
<infinity> phillw: Sine you didn't seem to be awake yet, I just went ahead and respun lubuntu/alternates.  They should spit out soon.
<xnox> stgraber: I commented on it. It is a bit strange. Partman doesn't seem to show any logical partition, which i'd expect to be dm-crypt activated with random password to become swap.
<infinity> phillw: s/Sine/Since/
<stgraber> xnox: right, I saw your discussion with infinity in #ubuntu-installer
<xnox> ack.
<ogra_> stgraber, i have a wishlist request for the iso tracker ... can we please use sane dates ?
<ogra_> like iso ones :)
<ogra_> 04/24/2013 is as wrong as a date can be :P
<knome> is there a wikipage or a blog post that explains the new release model? i'm looking for something that i can link to from the xubuntu release notes, don't really want to use https://wiki.ubuntu.com/ReleaseCadence/RollingRelease
<infinity> knome: There is no new release model.  Does that help?
<knome> well... no.
<knome> is raring supported for 18 months?
<cjwatson> 9 months
<infinity> knome: raring is supported for 9 months.  But the release model hasn't changed, just the support window.
<knome> okay, is there an announcement for that?
<cjwatson> it was in TB minutes I think ...
<stgraber> ogra_: well, Drupal thinks it's in the US and so formats the date that way ;)
<knome> ok, i'll dig up the archives
<cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2013-March/001027.html
<Laney> stgraber did a summary and it got posted on some blog
<infinity> I'll be sure to mention it in the release announcement.
<ogra_> stgraber, tell it that it isnt :)
<cjwatson> But it certainly ought to be written up in some less "for those who care about Ubuntu process minutiae" way
<stgraber> ogra_: oh actually, looks like we can now reconfigure that in the web UI! let me see if I can easily change that without breaking things
<ogra_> :)
<infinity> stgraber: If I accepted callibre and rebuilt edubuntu-dvd, would you or highvoltage have a sad?
<infinity> calibre, even.
<highvoltage> infinity: ah I meant to respond to the calibre issue earlier but had a ton of interruptions (I should spend less time at the office)
<stgraber> infinity: considering I'm half-way through testing, probably :)
<highvoltage> infinity: syncing now and will then test. cdimage is pretty slow though.
<knome> infinity, if you're including it in the general release notes, then i don't need to. ta :)
<stgraber> highvoltage: it's your country that has slow internet, I'm getting my iso images at a nice 8MB/s here ;)
 * cjwatson is getting 38MB/s from cdimage, anything else is your problem :P
 * cjwatson <- slight advantage this week
<infinity> Well, looks who's all smug about his borrowed internet.
<ogra_> cjwatson, using LTE over your mobile ?
<ogra_> :)
<highvoltage> I got 10mbps for everything else yesterday but just around 100-200KB/s for cdimage.
<highvoltage> maybe it was just bad timing or something from my part :)
<cjwatson> I will admit that my mobile internet is in fact faster than my ADSL, but not that ...
<ogra_> heh
<cjwatson> (anyway, my actual point was that cdimage itself seems fine, even if it's only because I'm sort of effectively next to it)
<ogra_> yeah
<highvoltage> I still only get around 200KB/s from it, but my image was last synced yesterday so I guess it won't take long anyway
<infinity> highvoltage / stgraber : Want to join in on the conversation in #-devel?
<stgraber> infinity: yeah, was looking over the diff to actually know what we're talking about ;)
<Laney> We can still sneak unseeded universe fixes in, yes?
<infinity> Laney: Absolutely.
<Laney> Solid.
<stgraber> ok, so I finished pushing my test results for Edubuntu (everything looking good) and marked the images for rebuild so nobody wastes their time on them
<stgraber> I really need to figure out why queuebot does that ^...
<infinity> I assume because it's Swiss.
<highvoltage> stgraber: ack
<knome> fixed the broken link to stÃ©phanes detailed summary at https://wiki.ubuntu.com/TechnicalBoard/TeamReports/13/March
<knome> will https://wiki.ubuntu.com/RaringRingtail/ReleaseNotes be created sometime soon?
<infinity> knome: It will exist later today.
<knome> cheers
<infinity> knome: But if you need to edit or add to it, edit TechnicalOverview please.
<infinity> knome: It'll just be a copy/paste (or even just a rename) of that.
<knome> sure
<knome> i'm just working on the xubuntu release announcement and prefer to have the links ready
<smartboyhw> infinity: Which link.format are we supposed to use for flavour release notes? https://wiki.ubuntu.com/RaringRingtail/ReleaseNotes/<distro> or https://wiki.ubuntu.com/RaringRingtail/<distro> ?
<infinity> smartboyhw: Wherever you want to put them, as long as you link them correctly from the master one, I don't much care, to be honest.
<smartboyhw> infinity: OK then, the Ubuntu Studio one is at https://wiki.ubuntu.com/RaringRingtail/UbuntuStudio
<smartboyhw> I saw the Lubuntu one having /ReleaseNotes after /RaringRingtail and I was afraid I got it wrong:P
<infinity> smartboyhw: Is it linked from TechnicalOverview?
<infinity> smartboyhw: I don't want to do all the wiki gardening required to make sure everyone's stuff is right, so if you link it to the right location, I don't care where that is. :)
<Laney> please review kaya in the queue
<cjwatson> ooh, you fixed it?
<cjwatson> +-import Contol.Exception
<cjwatson> ++import Control.Exception
<cjwatson> stylish
<Laney> erm, wait, that's probably my mistake
<Laney> I made that typo while fixing it
<cjwatson> you appear to have fixed that typo
<Laney> does the diff introduce it and then fix it?
<cjwatson> er, can't see, have accepted :)
 * cjwatson goes and looks again
<Laney> yes
<cjwatson> Yeah, it does
<cjwatson> Oh well
<stgraber> introducing a bug and fixing it in the same diff, yay! :)
<Laney> I was evidently on new-gc-api when I did it
<Laney> ho hum
<cjwatson> Can tidy up for s
<smartboyhw_> Question: Still no codename for S cycle right?
<rustx> hi
<rustx> could i ask you information about the bug fix i would like to provide you on this page ? https://bugs.launchpad.net/ubuntu/+source/facter/+bug/1170325
<ubot2> Launchpad bug 1170325 in facter (Ubuntu) "Facter 1.6.X not considering Qemu/KVM virtual type" [Undecided,New]
<rustx> i m not sure how to propose this fix in the LTS development release
<rustx> can somebody help me to make it clear ?
<ScottK> rustx: We're releasing Ubuntu 13.04 tomorrow, so anything not directly related to that is extremely unlikely to get attention until next week.
<rustx> ScottK: I clearly understand
<rustx> ScottK: that's ok to me, i will fix my productio on my side, and will come back to you next week
<rustx> ScottK: the only thing i am sure with is that puppet devs fixed that bug in later version of facter. I just wanted to be sure that the 120.4 LTS won't be broken, as this is the distro I use on production
<rustx> ScottK: all the best for Ubuntu 13.04 release, big up !
<ScottK> rustx: Sure.  If you can find the exact commit that fixed the bug, then there's a good chance of getting it fixed, but not this week.
<seb128> rustx, ScottK: seems like http://projects.puppetlabs.com/issues/20265 ?
<rustx> yes, this is my issue
<rustx> on puppet side, they told me it was fixed on further facter version (1.7), and asked me to see with Ubuntu teams
<rustx> i wil find the exact commit that fixes this
<seb128> rustx, seems like it's https://github.com/puppetlabs/facter/commit/5c653e98e97ba8e83a46b8e0c1fd72dfe672964b
<seb128> rustx, https://github.com/puppetlabs/facter/commit/4b44b797785ad48d64116e9e13f063dfe89910d2 rather
<rustx> seb128: yes, you got it
<Daviey> Wow, that is remarkably unsafe detection
<rustx> my patch was proposing using a pipe '|' to add KVM Common Processor
<rustx> but it is exactly the same
<rustx> won't break anything, but will fix all VMs running with latest version of qemu-server (with proxmox 2.3)
<seb128> rustx, if you want that SRUed you need to add SRU infos to the bug, especially a testcase to confirm the bug and the fix
<rustx> yes, ok, i will do it
<seb128> thanks
<Daviey> I don't think that fix is enough..
<rustx> this if my first bug fix contribution, so i want to do it well (and not bother you too much)
<seb128> subscribe ubuntu-sponsors to the bug once you are done
<rustx> ok
<seb128> Daviey, I've no clue about the topic, just tried to go back from the launchpad bug infos to the upstream commit...
<rustx> seb128: and you did it really well
<rustx> ty
<seb128> yw
<rustx> Daviey: what is your concern about hat fix which could not be enough ?
<Riddell> update-manager caches the meta-release file (in /var/lib/update-manager/meta-release or $HOME/.cache/update-manager-core/ depending on who runs it) won't that stop notification happening when the new release happens?
<Riddell> I just spent an hour wondering why I wasn't getting notification on my test
<cjwatson> It catches up eventually, and it's good to spread out the load a bit
<Riddell> fair enough I suppose, makes testing a bit more hassle is all
<cjwatson> there's a force option somewhere
<cjwatson> actually, it also uses If-Modified-Since
<Daviey> rustx: I would suggest that, checking if, dmidecode -s system-manufacturer  == Bochs is cleaner
<Daviey> rustx: the cpu field is largely free-form
<rustx> Daviey: yep, but the is_virtual method in facter depends on the output of the /proc/cpuinfo
<rustx> Daviey: i just proposed a patch in accordance with the explanation about this method, on puppet side
<Daviey> rustx: Well, your change makes it no worse than it currently is then :)... but if you really want to be a good citzen, you could speak to upstream about making their detection suck less. :)
<rustx> Daviey: I clearly agree with you, but didn't really want to lead the facter dev. I just saw on my production that all my VMs were considered as 'physical' after qemu-server update, and went to apply a bug fix on my side
<rustx> Daviey: all my monitoring was wrong because of that simple output in /proc/cpuinfo
<rustx> so, I decided to see if i can help on any way :)
<seb128> rustx, was qemu-server a distro upgrade/SRU?
<Daviey> rustx: Yes, sorry - I didn't mean to suggest you shouldn't follow upstreams path
<rustx> seb128: yep. This bug was caused just after qemu-server update
<rustx> i could realize this using proxmoxVE
<rustx> with proxmox 2.2, no trouble, the output is ok
<rustx> with proxmox 2.3, the bug appears, as the output for /proc/cpuinfo changed on the VMs ...
<seb128> rustx, do you know what upgrade exactly?
<rustx> i am updating the SRU, to be sure it's clear to you
<rustx> i will tell you
<seb128> rustx, I don't see any major change in precise
<seb128> thanks
<rustx> in precise, there is no change
<rustx> seb128: but in qemu-server, (debian side), there were some (or on proxmoxVE side)
<rustx> which causes the bug when using facter1.6
<seb128> I see
<rustx> at the end, including facter1.7 in ubuntu 12.04 would fix everything
<seb128> well anyway that upstream patch might not be perfect, as Daviey pointed, but if it fixes real world issues it seems ok for a SRU
<rustx> or, the patch I proposed you should help to fix the facter1.6 version
<Daviey> (This is why I consider it unsafe, as the host/user can put whatever they like) - but this is a good short term fix.
<rustx> i repeat this is my first bug fix : i hope i am not bothering you too much with this
<Daviey> rustx: not at all.. your effort is greatly appreciated :)
<rustx> seb128: http://pastebin.com/DZXmmXCC . This first paste is containing information about my node, with qemu-server not updated (no bug on the VM)
<rustx> seb128: http://pastebin.com/HsHyij3j this second one is containing information on the node that was updated, and that reveals wrong output for /proc/cpuinfo on all the running ubuntu 12.04 Vms ...
<rustx> the only difference is the qemu-server version at the end ..
<Daviey> rustx: Ah, https://github.com/puppetlabs/facter/commit/4b44b797785ad48d64116e9e13f063dfe89910d2#L1R140 <--- does add checking of dmideocode.. seb128 found the right patch for you to pull :)
<rustx> seb128: this is the output of a VM running on the first node (not updated) http://pastebin.com/FuRp7D4M
<rustx> seb128: and this is the output of a VM running on the second node (updated) -> http://pastebin.com/ifhNk77J
<rustx> great then
<rustx> Daviey: you should be a better sysadmin than I am, congrats, and thank you for making me learn good practices
<rustx> i like it
<Daviey> rustx: Thanks for driving this. :) (adding .patch to the url gives you a nice patch you can pull in btw)
<rustx> Daviey: thanks for information
<rustx> i will update my launchpad bug issue, so that it contains all information we discussed here
<rustx> i really want to do it clean :)
<rustx> waouhou, you already updated my launchpad issue ..
<rustx> you're too strong guys !
<stgraber> highvoltage: ^
<highvoltage> stgraber: awesome, thanks
<cjwatson> ScottK: bug 910903 - the source package is still around.  Is it ever likely to be fixed, or should we remove it?
<ubot2> Launchpad bug 908462 in plasma-widget-daisy (Ubuntu Precise) "duplicate for #910903 FTBFS: error: 'TaskManager::TaskPtr' has not been declared " [High,Fix released] https://launchpad.net/bugs/908462
<ScottK> cjwatson: IIRC it's dead upstream so removal is fine.
<cjwatson> Oh, removed from Debian too.  That makes the decision easier.
<rustx> seb128: I've updated the SRU with all informations i could
<cjwatson> ... I was looking at the wrong package.  Never in Debian.
<seb128> rustx, thanks, the testcase should be something others can follow to confirm the issue and verify the fix
<seb128> rustx, like "install kvm; configure it this way; connect to a server running that version; it gives that result"
<cjwatson> ScottK: Hmm.  FWIW plasma-widget-fancytasks has a newer version upstream than was ever in Ubuntu.
<cjwatson> http://kde-look.org/content/show.php/Fancy+Tasks?content=99737
<rustx> ok, i will udpate the test case
<rustx> seb128: perfect, thanks for your explanation
<ScottK> cjwatson: I guess we should look into updating that for "S".
<ScottK> Maybe it's time to tell Mark, "It's slimy slug unless you give us a different name."
<cjwatson> my family suggested Sad Salamander and Steadfast Sloth
<cjwatson> Slippery Snail
<Daviey> Poor Mark has been on the road for a while now, he's not had a chance to consult his oxford dictionary.
<ScottK> Right.  My premise was to suggest something so horrible it would have to be changed.  Of course the recent budget sequester here in the US suggests that can be a risky strategy.
<ogra_> yeah, he's travelling
<cjwatson> ktouchpadenabler source is superseded by kde-workspace, right?
<ScottK> cjwatson: yes.
<cjwatson> ScottK: we have a specific precedent for trolling Mark about release names being risky
<ScottK> Interesting.
<cjwatson> ScottK: we almost ended up with Bendy Badger because of Keybuk trolling him
<cjwatson> (Not that Breezy Badger was much better, but eh)
<ScottK> We've had worse since.  I'm sure it seemed like a troll at the time.
<cjwatson> hah
<ScottK> Salacious Salamander
<Daviey> Sloppy Sloth, is my preference
 * ogra_ is sure mark will again come up with something completely different and unexpected 
<rustx> seb128: test case was updated now
<rustx> i just hope it fits your expectation
<seb128> rustx, that looks great, thanks for the work! please subscribe ubuntu-sponsors to the bug and we are all set ;-)
<doko> huh, avian did just build?
<rustx> seb128: done -> Your subscription request has been received, and will soon be acted upon
<cjwatson> doko: Yeah, apparently magically built when Adam did a mass give-back
<cjwatson> Which was surprising, but I'll take it
<seb128> rustx, excellent
<ScottK> So what's the latest the announcement of the next name has ever come?
<ScottK> It's hard to image it being much later than this.
<dobey> didrocks: ping
<stgraber> ScottK: I think last was the latest we had so far but I don't think it wasn't nearly as late as this one :)
<ScottK> Last time was not nearly as late as this one.
<seb128> ScottK, http://www.markshuttleworth.com/archives/1195 was on oct 17th where release was on the 18th
<rustx> thanks a lot for your time seb128 and Daviey
<ScottK> OK, so it's gone to Wednesday before.
<ScottK> seb128: Thanks.
<seb128> yw ;-)
 * popey still wants SchrÃ¶dinger's Siamese
<smartboyhw> ScottK: I rather think it is Snappy Shuttleworth
<cjwatson> That's down to ten orphaned source packages, which is I think as good as I can get it for raring.
 * Laney wonders how bad ftphs is
<cjwatson> Daviey: bug 1017609 - could somebody on your team answer jbicha's question about python-melangeclient?
<ubot2> Launchpad bug 1017609 in python-melangeclient (Ubuntu) "Please remove melange from ubuntu archive" [Undecided,New] https://launchpad.net/bugs/1017609
<cjwatson> Laney: I don't quite remember, it might be tractable
<Laney> cjwatson: yeah, it is
<Laney> most of the breakage has been down to this one Control.Exception API change ...
 * Laney yah boos at GHC upstream
<cjwatson> src/Network/FTP/Server.hs:169:18: Not in scope: `try'
<cjwatson> src/Network/FTP/Server.hs:217:33: Not in scope: `catch'
<cjwatson> indeed, looks tractable
<cjwatson> You sorting?
<Laney> done
<ScottK> stgraber: Should the "Raring Daily" milestone in the tracker be marked released?  We won't be using that again.
<Laney> just donig the packaging bits and bobs
<xnox> cjwatson: infinity: stgraber: ^
<xnox> ubiquity for kubuntu only.
<xnox> Riddell: ScottK ^
<ScottK> Standing by to retest.
<stgraber> ScottK: nope, not until raring is released as nusakan actually pushes all our builds to the Daily milestone and then those get auto-copied to Raring Final if they're on the manifest
<ScottK> stgraber: OK.  Understood.
<smartboyhw> xnox: Will ubiquity fix respin the entire world
<ScottK> smartboyhw: It will
<ScottK> It should only go in if we're going to do that anyway.
<smartboyhw> Uh oh:P
<xnox> ScottK: smartboyhw: no.
<ScottK> xnox: Yes.
<xnox> ScottK: smartboyhw: the current plan is to put ubiquity into -updates and respin kubuntu against updates only.
<xnox> as ter infinity, cjwatson earlier on.
<ScottK> xnox: Oh.  Missed that.  Thanks.
<highvoltage> stgraber: do we need a link for the website team to fix https://bugs.launchpad.net/ubuntu-website-content/+bug/1065789 ?
<ubot2> Launchpad bug 1065789 in ubuntu-website-content "the release notes link in installer points to www.ubuntu.com" [Undecided,Fix released]
<xnox> highvoltage: that happens with website rollout.
<xnox> highvoltage: the "link" points to the correct redirector with args. By _default_ at pre-release it redirects to default website(s), but once the website is flipped to the "release" edition, the redirects start working correctly.
<xnox> i guess there is no _harm_ in activating redirects early, but the website is frozen already and the next website rollout is the release rollout.
<cjwatson> And *not* unblocking ubiquity, since indeed we'll put it in -updates.
<cjwatson> Relatively tried-and-tested trick by this point :)
<Riddell> ubiquity diff on bug 1172059 looks good
<ubot2> Launchpad bug 1172059 in ubiquity (Ubuntu Raring) "kubuntu ubiquity encryption doesn't check password" [High,In progress] https://launchpad.net/bugs/1172059
<Riddell> can I let it into -proposed or is someone else taking care of that?
<Riddell> oh it's in already
<Riddell> groovy
<highvoltage> xnox: ok
<didrocks> dobey: pong
<dobey> didrocks: hey. i've been pinged about getting bug #1163504 fixed in 13.04, but i don't see anything i can do. can you get the fix into -proposed and see about getting new images spinned with the fix?
<ubot2> Launchpad bug 1163504 in kopete (Ubuntu Raring) "Trademarked assets" [Undecided,New] https://launchpad.net/bugs/1163504
<dobey> didrocks: or a 0-day SRU for worst case?
<cjwatson> uhhh
<cjwatson> it's kinda late dude :(
<dobey> yeah i know that. but tell that to MS legal i guess? :)
<cjwatson> (also shouldn't that kopete task be kdenetwork?)
<cjwatson> well, um, I thought you guys had this handled
<dobey> i knew nothing about it until today
<xnox> dobey: but it's fixed in all found packages but kopete which is not on any of the images.
<dobey> i just had it dumped on me, and saw it's all unity and there's basically nothing here that i have any privileges in ubuntu to upload :)
<xnox> dobey: the next upload can "fix" it, but previous versions of the package will still be in the archive.
<dobey> xnox: it's not fixed in unity-asset-pool
<cjwatson> we know that older versions will still be in the archive
<xnox> dobey: oh....
<dobey> xnox: it's committed in the upstream, but it's still in the ubuntu package
<xnox> dobey: why was is set to committed then (!) i did check all of them.....
<slangasek> ftpshs> fails to puild hrom source?
<cjwatson> unity-asset-pool (from unity-asset-pool) is seeded in:
<cjwatson>   edubuntu: dvd
<cjwatson>   ubuntu-gnome: daily-live
<cjwatson>   ubuntu: daily-live, daily-preinstalled
<cjwatson>   ubuntukylin: daily-live
<cjwatson>   ubuntustudio: dvd
<dobey> xnox: i have no idea. that's why i'm pinging didrocks (and presumably why it somehow managed to get dumped on me this lovely morning)
<cjwatson> and can we get kdenetwork fixed while we're here, please?
<smartboyhw> Why does ubuntustudio contain unity-assets-pool?
<smartboyhw> :O
<cjwatson> no idea
<smartboyhw> ......
<dobey> smartboyhw: or ubuntu-gnome or edubuntu?
<cjwatson> not the time for such questions
<dobey> yeah
<smartboyhw> dobey: Edubuntu does make sense. US doesn't.
<cjwatson> Whatever
<cjwatson> Now is not the time
<dobey> cjwatson: who would be best to fix kdenetwork? ScottK?
<xnox> well kdenetwork i can even upload.
 * xnox looks.
<ScottK> What's the issue?
<dobey> xnox: thanks
<cjwatson> ScottK: Presence of a skype icon which has attack lawyers after it
<cjwatson> bug 1163504
<ScottK> Ah.
<ubot2> Launchpad bug 1163504 in kdenetwork (Ubuntu Raring) "Trademarked assets" [Undecided,New] https://launchpad.net/bugs/1163504
<ScottK> Yeah, should probably fix that.
<Daviey> cjwatson: sure
<cjwatson> kopete isn't on any images
<cjwatson> So we could get away with a day-0 SRU for that
<xnox> dobey: didrocks: why kdenetwork needs fixing? it has code to link/use skype or something for kopete. But it's just kopete which has the icon.
<ScottK> cjwatson: Except then the file is in the release pool for the life of the release.
<ScottK> We plan a Kubuntu respin anyway.
<cjwatson> True.
<didrocks> dobey: xnox: sorry, in another discussion. I'm only looking at unity-asset-pool shortly
<cjwatson> didrocks: This is critical - I hope the other discussion can be suspended for a bit
<dobey> xnox: i don't know. cjwatson asked if it should be kdenetwork instead of kopete. if it's kopete then it's kopete :)
<cjwatson> kopete is from the kdenetwork source package
<dobey> ah ok. xnox ^^
<jokerdino> hey guys, is the archive frozen yet? i would like some advice on how to get a couple of fixes in. separate SRU requests or a new bug-fix only version sync request?
<cjwatson> SRU unless it's critical for images
<jokerdino> (with re: to unity-tweak-tool)
<jokerdino> that was a darn lag. sorry.
<stgraber> unity-tweak-tool isn't seeded, so just upload
<jokerdino> so, i can get a upload later today?
<didrocks> cjwatson: argh, it seems the fix wasn't released :/
<stgraber> cjwatson,infinity: do we have a deadline for unseeded stuff?
<xnox> ScottK: Riddell: so kopete has protocol to connect to skype and the trademarked & copyright assets for everything: logo, status, etc.
<Riddell> nothing in kdenetwork, it's in oxygen-icons
<jokerdino> i think i'll bug you later when i pick the fixes. thanks!
<xnox> ScottK: Riddell: remove all of those icons and see what happens?
<cjwatson> stgraber: probably tomorrow sometime - everything's settled, we shouldn't need to stress about it
<xnox> Riddell: there clerly images in kdenetwork package.
<infinity> stgraber: Tomorrow morningish.
<xnox> Riddell: kdenetwork-4.10.2/kopete/protocols/skype/icons
<infinity> stgraber: If it doesn't build in time and make it, we can just dump it to s-series.
<Riddell> xnox: where? I see only ones in oxygen-icon-theme
<slangasek> jokerdino: this isn't the place to ask for upload sponsorship, if that's what you mean.  Uploads to unseeded packages are still allowed at this point, but not guaranteed to make it into the release - you can still upload but it may wind up having to go through the SRU process
<xnox> Riddell: kdenetwork-4.10.2/kopete/protocols/skype/icons .....
<didrocks> cjwatson: is there a respin needed?
<cjwatson> didrocks: Yes
<stgraber> jokerdino: so based on the above, you should be fine if you upload today
<didrocks> cjwatson: if so, I can fix that quickly
<Riddell> xnox: ooh sneaky
<xnox> Riddell: unless they are not installed...... let me check.
<cjwatson> didrocks: We can't say to the lawyer's "sorry, we can't fix 12.10 images now, but we'll fix it in 13.04" and then not fix it in 13.04
<cjwatson> *lawyers    # argh what's wrong with my typing
<didrocks> cjwatson: let me do a quick upload
<cjwatson> didrocks: Thanks
<cjwatson> Looks like just that one rev since the last autolanding
<didrocks> cjwatson: sorry, I'm not anymore the one looking that stuff getting merged are released, but well :)
<didrocks> cjwatson: yep
<Riddell> xnox: they are indeed
<cjwatson> didrocks: Yep, not looking to allocate blame, but it needs to get fixed
<jokerdino> slangasek, heh no. i wasnt sure about last day procedures with the archive. i was thinking SRU requests go through archive admins. thanks regardless!
<xnox> Riddell: I'm looking at packaging. Does oxygen-icon-theme provide fallbacks? are those trademarked assets as well?
<xnox> Riddell: I'd like to rebuild kdenetwork without skype plugin activated such that we don't ship something that tries to load skype plugin and crashes due to missing icons.
<Riddell> xnox: /usr/share/icons/oxygen/*/actions/im-skype.png and /usr/share/icons/hicolor/*/actions/im-skype.png could well be considered to be the trademark
 * xnox looks at oxygen.
<didrocks> cjwatson: doing a quickly daily, sync in ~20 minutes I guess
<xnox> Riddell: those are shipped from the kopete bin package, by kdenetwork package?!
<pgraner> cjohnston, infinity: just got this report on server cd's https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1107686
<ubot2> Launchpad bug 1107686 in isc-dhcp (Ubuntu) "dhcpd: Open a socket for LPF: Permission denied" [Undecided,Fix released]
<Riddell> xnox: those are from oxygen-icon-theme
<cjohnston> I'm guessing cjwatson ^
<cjwatson> stgraber: ^-
<stgraber> pgraner: how did that get linked to raring server? that bug report is about a regression in a quantal SRU
<stgraber> (which I fixed yesterday and is now in quantal-updates)
<pgraner> stgraber, matsubara pinged me since he is doing the maas testing
<pgraner> stgraber, he says its in raring as well
<dobey> Riddell: /usr/share/kde4/apps/kopete/icons/oxygen/128x128/apps/skype_protocol.png is in kopete - http://packages.ubuntu.com/raring/all/kopete/filelist
<stgraber> pgraner: hmm, ok, that's pretty surprising considering I copied the fix from raring... so must be something else
<Riddell> dobey: yep
<stgraber> pgraner: anyway, is that on some lab machines? (can I see it?)
<pgraner> stgraber, ok I asked him to join here so you can talk to him, and yes it should be on a lab boxen
<matsubara> stgraber, hi there. pgraner told me you have some questions about https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1107686
<ubot2> Launchpad bug 1107686 in isc-dhcp (Ubuntu) "dhcpd: Open a socket for LPF: Permission denied" [Undecided,Fix released]
<stgraber> matsubara: right. That specific bug was a regression in quantal, we've had the fix for that in raring for months, so it's very unlikely you're seeing the same issue.
<stgraber> matsubara: any chance I can have access to your test machine to see exactly what's going on?
<matsubara> stgraber, I see the same error in the log and when I put the workaround suggested in place, the dhcpd server starts normally
<stgraber> matsubara: what workaround?
<matsubara> stgraber, yes, sure. do you have access to the QA VPN?
<cjwatson> Daviey: ah, excellent, you went ahead and removed it, thanks
<stgraber> matsubara: yep, I've got VPN access to the QA lab
<matsubara> network packet packet,\n network packet raw
<matsubara> stgraber, ok. I'll pm you the details
<cjwatson> didrocks: Great, thanks
<Daviey> cjwatson: thanks for noticing it, sad we didn't notice it in quantal
<didrocks> cjwatson: yw, sorry I didn't notice it beforehand :)
<cjwatson> Daviey: Yeah, was trying to make sure the ubuntu-archive request queue was clean for release
<Daviey> perfect, thanks!
<cjwatson> (We now have just three long-term issues that aren't release-specific)
<xnox> Riddell: proposing http://paste.ubuntu.com/5598572/ will test build and test the package in the moment. Looking at the oxygen icons now.
<Riddell> xnox: I'd recommend setting WITH_skype=false too
<xnox> Riddell: for CMake config. Ok. let me try.
<xnox> Riddell: the cdbs combinded dh style packaging is ugly.
<xnox> http://paste.ubuntu.com/5598576/
<Riddell> xnox: looking good
<stgraber> cjwatson, pgraner: turns out the test was on quantal so they hit the SRU regression which I fixed yesterday and landed in -updates this morning. A re-run confirmed that the issue is no longer present.
<cjwatson> Oh good
<pgraner> stgraber, ack great
<pgraner> stgraber, thanks
<Riddell> is it really ok to have the skype icon in the source package?
<cjwatson> Good question
<cjwatson> It might be safer to redo the orig
<cjwatson> At least to remove the icon (I don't think it's necessary to purge all traces of the word "skype", since AFAIK we haven't been asked to)
<xnox> Riddell: i'll repack to remove trademarked assets from kdenetwork and oxygen.
<Riddell> "assets" you sound like a lawyer :)
<bdmurray> what is the release process wiki page?
<Laney> do you need to disable the skype plugin completely?
<cjwatson> AFAIK only the icon needs to go away
<xnox> Riddell: hang out to much with designers. Apperantly "photoshop" produces "assets".
<Laney> that's how I see it too
<cjwatson> if there's a suitable replacement icon then it would be preferable to use that
<xnox> Laney: sure. but i don't want to ship kopete which will try to load skype plugin and fail due to missing icons.
<cjwatson> (we can probably check that if you want)
<cjwatson> bdmurray: https://wiki.ubuntu.com/ReleaseProcess
<Laney> right ...
<xnox> it uses the xdg lookup.... but.
<xnox> Laney: we can always sru kopete with enabled skype plugin and debranded or whatever.
<cjwatson> ubuntukylin-default-settings needs a slideshow fix too (skype icon)
 * cjwatson looks at that
<dobey> xnox: have you verified it will fail without those icons?
<xnox> dobey: no, somebody can do that in the mean time?!
<cjwatson> Kylin doesn't actually *use* those icons, but it ships them
<xnox> Riddell: ^ ?
<dobey> xnox: i doubt it will fail
<dobey> but it would be good if someone could test it real quick
 * xnox doesn't think that offering skype plugin with missing icons is good. One of the "Skype" plugin features is mozilla plugin call to button.
<dobey> hopefully they don't get compiled into the binary so just rm the icons will work to remove them
<xnox> I'd like someone test that as well, if you are going with "remove icons only"
<xnox> dobey: there are alot of compiled moc/ui objects....
<xnox> (not sure if those embdeb icons or not)
<cjwatson> Shouldn't
<xnox> ack.
<dobey> depends on what the rc files do
<dobey> if rc files include reference to the png files, they'll get pulled into the binary as well
<xnox> broken kopete -> breaking firefox sounds like a risky possibility. Hence disable full plugin + maybe sru it back in later after testing and/or replaced artwork.
<Riddell> xnox: how could it break firefox?
<xnox> Riddell: by crashing a page with a phone number that is rendered into a skype callto button.
<xnox> Riddell: kopete builds that as well....
<dobey> i doubt it will crash
<Laney> you could check ...
<Riddell> I've never heard of things crashing ust from missing artwork
<Laney> disabling it seems like a sledgehammer approach
<Riddell> I'll try it out
 * xnox finished the kdenetwork build with skype disabled. testing now.
 * xnox kdenetwork works & kopete works.
<cjwatson> Should we pull in the new casper to -updates for this respin?
<cjwatson> How well is it tested?
<stgraber> cjwatson: the virtio swap bit I've used to debug another issue so I know it works. The shutdown I only did a quick test yesterday in a UEFI VM, doing the same in a BIOS VM now to confirm
<cjwatson> Yeah, I couldn't even get plymouth to show on shutdown in kvm so I'm no help
<stgraber> ah right, just figured out why everything's slow on the machine, I'm building a kernel in the background with -j5, that explains it!
<Riddell> xnox: kopete works ok with skype with no icons
<xnox> Riddell: and firefox as well? callto button?!
<Riddell> xnox: that I've no idea what it is or how it work
<xnox> Riddell: login into skype, enable account in kopete, start firefox, check that mozilla callto plugin is loaded, navigate any pages which have phone numbers
<xnox> and if detected they should turn into call icon with the skype green phone thing, upon clicking which a call should initiate
<xnox> a call in kopete.
<Riddell> xnox: do I need to install this callto plugin?
<xnox> Riddell: it seems to come inside kopete package....
<xnox> doesn't it?
<Riddell> oh nifty
<stgraber> cjwatson: VM with broken text boot/shutdown doesn't look worse with the new casper than it did with the old one. I've got another VM using vmvga which does give me a working plymouth, let's see what that one does.
<xnox> Riddell: hence my concerns.....
<stgraber> cjwatson: I see the message and pressing enter works (kvm with vmvga driver)
<cjwatson> Promising
<stgraber> yeah, I can't confirm whether we fixed the bug or not but at least it doesn't look like it's any worse than it was
<Riddell> xnox: doesn't seem to work with the current kopete package
<Riddell> xnox: I install kopete package, check it's listed in about:plugins  go to http://davidwalsh.name/demo/phone-link-protocol.php to test and link doesn't work "the protocol (tel) isn't associated with any program."
<xnox> Riddell: with and without icons?! =)
<xnox> Riddell: skype should be running....
<xnox> (logged in etc.)
<Laney> since xnox has it working, it sounds like it would be easier for him to check this ...
<jbicha> xnox: what are we going to do for bug 1164592?
<ubot2> Launchpad bug 1164592 in ubiquity (Ubuntu) "Ubiquity freezes in Install Alongside screen" [Medium,Confirmed] https://launchpad.net/bugs/1164592
<Riddell> xnox: yep
<xnox> Laney: what do you mean "working" ?
<Laney> the call thing?
<Laney> at least you're giving instructions like you have it working fo ryou
<xnox> Laney: I know how it's suppose to work, but I haven't used it myself in raring yet. And my machine I'm on at the moment cannot do skype.
<xnox> I have package that is repackaged to remove skype icons, and disable skype plugins and not install them.
<xnox> It works as expected.
<xnox> the final debdiff is: http://paste.ubuntu.com/5598697/
<xnox> I am tempted to upload that.
<xnox> The alternative is to still ship all plugins and just have the icons removed. But that needs another build on my end.
<xnox> Let me dput this version, and I can do another one for icons only and then it's up to release team to decide what to take.
<Riddell> xnox: I'm not fussed but have a slight preference for only removing the icons and not the kopete plugin
 * Laney too
<xnox> ScottK: ^?
<cjwatson> I share that preference
 * ScottK too
<stgraber> yeah, I don't think we want a last minute feature change, dropping/replacing the icons should be enough to fix the bug
<xnox> purging all skype icons? (e.g. even the like skype human contact & status icons)
<Laney> what was asked for?
<Riddell> xnox: they look a lot like straight copies from skype so best to yes
<cjwatson> Apparently the one they really care about is the one that was overriding their icon in their new skype package
<cjwatson> So an actual functional breakage - that was unity-asset-pool
<cjwatson> For the others, we should still be avoiding shipping trademarked things where we don't have permission
<cjwatson> AFAIK it is just the logo
<cjwatson> Or images that incorporate the logo
<xnox> do we know if the trademarked the tripple circle status icon? (which is same outline like the (S) logo)
<xnox> s/the/they/
<xnox> the above kdenetwork is with disabling plugin.
<cjwatson> I do not know and the guidelines do not appear to say
<xnox> cjwatson: ^ reject, I guess for now.
<xnox> well my trademark knoweledge slightly reminds that anything that reasonably can associate / make one believe it's trademark....
<xnox> none the less, I belive those icons are violating copyright and are not suitable for main.
<cjwatson> I would probably err on the side of removing any icons you're unsure about
<Riddell> xnox: kopete mozilla plugin seems broken generally, not much to break more
<cjwatson> rejecting the earlier kdenetwork at least for now
 * cjwatson copies casper to raring-updates
<xnox> Riddell: oxygen-icons shouldn't be an xz, since most of icons are compressed with svgz, thus exploading the archive to be bigger than it should have been.
<xnox> Riddell: for future =)
<cjwatson> OK, so I'm fine with that kdenetwork upload.  Anyone else want to chime in before I accept it?
<Riddell> xnox: I'll pass on your wisdom to upstream but he does work for the same company as you so he might pay more attention to you directly :)
<Riddell> cjwatson: good with me
<Chipaca> xnox: if the plugin needs skype to be installed in order to work, can't it use the real skype icon?
 * Chipaca carries on reading
<xnox> I dunno
<xnox> Chipaca: but good point.
<Riddell> ktp-common-internals also has a skype icon
<cjwatson> It's not clear, but we can always put things back in an SRU if we get clearance
<cjwatson> From what David Pitkin told me, I'm not stressed at this point about grepping the archive for everything
<cjwatson> Since the most pressing concern is how it breaks Skype 4.2
<Laney> LGTM apart from the changelog being wrong
<xnox> Laney: which changelog? mine?
<cjwatson> I don't mind if people want to clean up universe further but it's not immediately critical
<xnox> Laney: yeah.
<cjwatson> xnox: Oh yeah, s/plugin/icons/
<infinity> Riddell: If you want to clean up kt-common-internals, be my guest, kdenetwork will be building for 4h anyway. :/
<cjwatson> changelog ... too late :)
<Laney> unacceptable!
<shibata> Hi release team. I encountered a crash of usb-creator-gtk on 13.04, bug 1068473.
<ubot2> Launchpad bug 1068473 in usb-creator (Ubuntu) "Crash when trying to create USB startup disk." [Undecided,Confirmed] https://launchpad.net/bugs/1068473
<cjwatson> I think our position on usb-creator is mainly "Er, yeah, sorry, it kind of sucks and we haven't had time to sort it out, but for most purposes you can just use dd"
<shibata> cjwatson: I see. Thank you.
<cjwatson> Just waiting for casper to publish to -updates before starting respins
<cjwatson> Anything else, better shout now :-P
<slangasek> can I have libpony on the CD
<infinity> slangasek: No.
<cjwatson> No, because the images don't fit on CDs any more :-)
<infinity> slangasek: Nor can you get a lollipop.
<Laney> what's going to be respinned?
<infinity> gnome, ubuntu, kubuntu, edubuntu...
<cjwatson> weidergespunnen
<cjwatson> er, wieder
<Laney> like a record baby
<stgraber> Laney: edubuntu, ubuntu-gnome, ubuntu, ubuntukylin, ubuntustudio and kubuntu
<cjwatson> Yeah, WHS
<Laney> ah, who cares about that stuff
 * Laney should have checked seeded-in-ubuntu casper
<cjwatson> I dunno why all of those have unity-asset-pool, but they do, and we have to respin either way (either to remove the files or remove the package)
<cjwatson> Laney: I put casper into -updates specifically to avoid everything it touches
<Laney> er, uap
<cjwatson> Yeah
<Laney> I don't see kubuntu there?
<cjwatson> In the case of ubuntu-gnome, it's shotwell -> account-plugin-facebook -> u-a-p
<cjwatson> Kubuntu is there for a different reason
<cjwatson> It wanted a couple of ubiquity changes anyway
<infinity> Laney: kdenetwork for kubuntu (and one or two others)
<Laney> but that's later for kdenetwork, yes?
 * Laney nods
<jbicha> yeah I think we wish we didn't have unity-asset-pool included ;)
<cjwatson> Indeed
<Laney> jbicha: It's an asset to you
<JackYu> cjwatson, when will the new iso of ubuntukylin ready?
<cjwatson> Need to wait for this publisher run to finish (a few more minutes) and then kick everything off; probably a couple of hours
 * skellat is downloading the latest branch of xubuntu-artwork really fast just to do a fast double-check for The Forbidden Trademarked Asset
<cjwatson> Changes are very minor so if you've already done full testing I think a revised smoke test should be fine
<JackYu> cjwatson, ok, so we will test it tomorrow (beijing time:) ).
<cjwatson> What's that in UTC?
<JackYu> +8
<cjwatson> I mean, depending on what you mean by tomorrow that might be after release
<cjwatson> But you're after midnight right now so you mean in about eight hours or so?
<JackYu> oh, yes:)
<cjwatson> OK, that'll be fine, thanks
<Laney> huge oxygen-icons orig is huge
<Riddell> size is everything
<stgraber> should we mark the world as rebuilding on the tracker or do we want to still let people report results on the current ones?
<xnox> Laney: hence my complained. It's an xz tarball of gz compressed icons. Thus it explodes in size for no gain.
<Laney> file a bug :-)
<xnox> Laney: to me that orig src is not actually orig, as icons are "pre-processed".
<xnox> Laney: I will in debian as a serious one.
<xnox> Laney: after may the 7th.
<cjwatson> stgraber: Hmm.  Probably the latter, it'll still be a little while
<Laney> o-i lgtm
<cjwatson> jamespage: your juju-core version number is b i z a r r e
<jamespage> cjwatson, tell me about it
<ScottK> cjwatson: I think it'd be better to just put it in S next week and backport anway.
<infinity> jamespage: We just did.
<infinity> jamespage: Why does the upstream version have a -1 at the end of it?
<cjwatson> ScottK: Yeah, I'm trying to avoid having an opinion on that since I haven't looked :)
<ScottK> (said so in the FFe bug too)
<infinity> Don't technically need an FFe for new unseeded stuff...
<Laney> really?
<Laney> or does F = Final?
<Daviey> infinity: erm, that isn't how it used to be
<ScottK> infinity: New does.
<infinity> It's no more a new feature than any other unseeded things we've synced from Debian in the last week.
<jamespage> it has a -1 because the juju team had to recut the release tarball as it had cruft in it
<infinity> Did those all have bugs?
<infinity> jamespage: That's what dots are for...
<Daviey> The primary reason for an FFe on unseeded stuff was to be a vanguard to Archive Admins.
<ScottK> infinity: Except you need an archive admin to New it and we're all allegedly busy with other stuff now.
<infinity> ScottK: Sure, but added process doesn't help that, we can all just say "no, not enough time".
<ScottK> My usual answer (at least when it's not release week) is to say go ahead if you can find an AA with time.
<Daviey> I don't think it's an unreasonable process TBH.
<infinity> *shrug*
<infinity> I think it's pointless process.
<ScottK> It is a bit different now that we have more AAs and most of the release team are also AA's but meh.
<infinity> FFEs are about reviewing the new features and changes.  "New package" isn't a feature changed in a package, it's just, well, a new package, which we already know how to deal with.
<infinity> And we know how to not deal with it too.
<ScottK> Maybe, but that's not the way we've done it for as long as I can remember.
<infinity> Just seems to be overloading it a bit, and adding process to an already annoying process (new review).
<Daviey> infinity: this one does potentially introduce risk with a non-seeded, but important feature package
<infinity> Daviey: The real risk was in the juju upload we reviewed and accepted earlier.
<ScottK> Daviey: All the more reason to backport it next week.
<infinity> Daviey: (ie: the one that switched it to using alternatives).
<cjwatson> Starting Ubuntu desktop respins
<infinity> There's no "danger" in accepting an alternative implementation.
<infinity> That's like saying every MTA is a "danger" to postfix.
<Daviey> true
<skellat> Alrighty, it looks like xubuntu-artwork is clean of The Forbidden Trademarked Asset
 * ScottK protectively cuddles postfix and summons lamont.
<infinity> But, I'm down with saying it's silly to jam it in late when we'll end up later with people claiming it needs to be heavily SRUed when all the bugs are found.
<infinity> *cough* maas in precise *cough*
<cjwatson> skellat: thanks
<ScottK> infinity: Yep.
<Daviey> To be clear, i couldn't give a hoot if this gets in or not.  I just know that a few people have worked pretty hard to try and get it in.  I don't mind spendig some time trying to help make that happen.
<Daviey> I think they have learned to get it in sooner next cycle.
<infinity> Daviey: Sure, they worked hard, they just worked hard to get it in at the wrong time.
<ScottK> If we don't accept it until next week, it will be in sooner next cycle.
<infinity> Daviey: Such is life sometimes, not everyone makes every milestone.
<infinity> Daviey: Getting it in first thing next week means they have six months to make it not crap. ;)
<Laney> Backports is super easy for new packages too.
<Daviey> infinity: your confidence is high.
<ScottK> I sense consensus emerging on the release team.
<lamont> ScottK: maybe  we should throw postfix at infinity and see if it sticks :D
<lamont> (hi infinity)
<cjwatson> Yeah, no matter how hard you work, landing an entirely new package a day before release is something you should expect to be questioned pretty heavily and possibly denied.
<Daviey> Oh, there has been significant questioning for the last few weeks.
 * ScottK just marked it wontfix based on the discussion here.
<infinity> lamont: I don't want your filthy postfix.
<apw> jamespage, can we assume that the python juju version will never rev into the same version space as the go juju version
 * infinity cuddles exim.
<cjwatson> The questioning I was referring to is the questioning happening now, not anything that happened before upload :-)
<Daviey> ScottK: I disagree that backporting it next week makes any difference.
<Daviey> apw: I checked that.. and it is safe to assume.
<ScottK> Daviey: Sure it does.  If the backport goes badly you can easily update it or even remove it.
<cjwatson> And I'm afraid I agree.  It's too late for a new project.  A backport has more time to deal with stupid build problems and the like.
<infinity> Daviey: It's a huge difference, since the backport can be revved with zero effort.
<ScottK> If it goes into the release pocket, you're stuck with it for the duration.
<Daviey> infinity: 'zero effort' ?
<infinity> Yes.
<cjwatson> In fact, if it goes well in -backports, there's no real reason we couldn't put it in -updates to give it wider visibility.
<infinity> You're familiar with the backports pocket, right?
<Daviey> naturally
<cjwatson> But the first exposure of something like this to the archive shouldn't be in the release pocket a day before release.
<Daviey> But zero effort implies throwing any crap in there.
<infinity> ...
<infinity> You'd rather throw any crap into the release pocket? :)
<lamont> infinity: ....
<Daviey> infinity: No, which is why i declaimed my point with the package being of sound quality :P
<ScottK> Since it's been tested on raring, the additional effort to backport it once it's in "S" is negligible.
<Riddell> today's kubuntu images still have the "this is a pre-release" warning on ubiquity
<xnox> Riddell: you should have used a plus in ktp upload, as in "0.6.1+dfsg1-0ubuntu1" but it's just ok.... passes a point.point.point.point release test.
<cjwatson> Fortunately we have an opportunity to fix that :-)
<cjwatson> What's the exact string so I can grep?
<Riddell> "This is a pre-release of the Kubuntu live CD installer."
<cjwatson> Ah yes
<Riddell> isn't that turned off by something on the CD?
<cjwatson> It's in ubiquity
<cjwatson> Looks like only the KDE frontend is affected
<cjwatson> So I'll upload a fix in a moment
<cjwatson> Is there a bug number/
<cjwatson> ?
<cjwatson> Looks like no
<Riddell> cjwatson: I'll report one
<Riddell> bug 1172059 verified as good
<ubot2> Launchpad bug 1172059 in ubiquity (Ubuntu Raring) "kubuntu ubiquity encryption doesn't check password" [High,In progress] https://launchpad.net/bugs/1172059
<cjwatson> Riddell: don't bother, already building a package
<Riddell> ok
<apw> jamespage, shouldn't this jujud have a manpage ...
 * Riddell uploads muon so raring->s version upgrades will work
<Riddell> cjwatson: ubiquity upload looks good, shall I accept?
<ScottK> Riddell: I already did
<Riddell> lovely
<ScottK> So how come that variable only affects the Qt front end?  How is it done for Ubuntu?
<ScottK> Seems like a deeper disconnect we ought to fix while it's fresh.
<Riddell> it used to be the same thing I'm sure
<cjwatson> The GTK frontend lost the alpha warning in some redesign or other
<ScottK> Riddell: Should we just lose it too then?
<ScottK> One less thing to go wrong.
<Riddell> ScottK: there's a good argument for that yes
<ScottK> So all we need to do is not turn it back on ....
<cjwatson> We can delete that code for S if that's what you'd prefer, sure
<ScottK> May as well.
<cjwatson> I think the need for it is rather less than when it was first introduced anyway
<ScottK> Riddell: What happened to muon?
<balloons> forgive me if this has been asked, i dn't see it in the backscroll. Do we plan on having a "Ubuntu Project Contributors"section in the release notes again?
<balloons> sounds like bkrenesa is going to do this?
<bkerensa> balloons: :)
<pgraner> balloons, yep, I have bkerensa the link so he knows where to put them
<bkerensa> ;)
<Riddell> ScottK: it's compiling away
 * Riddell out for a couple of hours
<jamespage> apw, undoubtedly so
<jamespage> apw, guess I get time to fixup lint now :-)
<cjwatson> I'm preemptively prepublishing the desktop images above so that we can get them onto cloudfront/mirrors/etc.
<cjwatson> dinner
<Daviey> ^ I wanted a bug on the iptables decency introduction
<ScottK> Nothing outside Kubuntu, so I'm unblocking it for release.
<ScottK> Daviey: Is that for release or SRU?
<Daviey> nova and cinder should be release.  maas should be sru
<ScottK> So you're going to respin server?
<Daviey> ScottK: no
<ScottK> Ah, I confused pacackage set with seed there
<dobey> infinity: hey, i got bumrushed to poke at a critical issue with skype icons this morning, and forgot to ping you re: rhythmbox-ubuntuone. can you still look at those SRU uploads today? thanks.
<ScottK> infinity/cjwatson: Any reason not to go ahead and copy ubiquity to updates?
<stgraber> I think they're all out for dinner
<stgraber> but besides that (as being the reason why nobody did it already), I can't see any reason not to copy it
<ScottK> We're still waiting for kdenetwork on armhf anyway.
<ScottK> Let me see how long that's likely to be ...
<ScottK> Ah.  Finished.
<stgraber> I'd just go ahead with copying to updates or pushing straight to the release pocket for the various bits you need (depending on whether you're the only one to ship those or not) and once everything is published let me know and I'll kick a rebuild for you (assuming the others aren't back by then)
<ScottK> We don't want ubiquity in the release pocket because it's there for Kubuntu only.
<ScottK> Just copied to updates.
<stgraber> right, that one goes to updates, the other bits can probably go to release
<ScottK> I suspect that's the first use of the 'sru-release' script for raring.
<ScottK> Yes.
<ScottK> There's already and unblock for kdenetwrok.
<ScottK> Should be good after the next publisher run finishes.
<ScottK> Riddell: Do you know of anything else we're waiting for?
<ScottK> stgraber: I don't know if you fixed something or something magical happened, but I can mark for rebuild now.
<stgraber> ScottK: didn't change anything, so I guess you just didn't hit the same weird bug you hit last time
<xnox> stgraber: ScottK: yeah, they are still out for dinner. I'm heading home now. copy to -updates and respin kubuntu with -updates if all the bits landed seems to me like the only next step.
<xnox> calling it a night =) see you tomorrow.
<Daviey> ScottK: Are you pushing hard against this being NEW reviewed now, overriding my initial assessment - or was your Wont Fix your preference ?
<slangasek> FWIW, I've talked with Daviey about juju-core (both today, and in the lead-up to this FFe); if we think we would just be adding this in via backports+updates later, I don't think there's a strong justification, release-wise, for not letting it into the release pocket today
<ScottK> slangasek: Everyone (except Daviey) that was here earlier on the release team saw it differently.
<Daviey> Proving it's of suitable quality.
<Daviey> providing*
<ScottK> There is zero difference to the user either way.
<slangasek> ScottK: yep, I saw
<Daviey> ScottK: to be fair, infinity seemed quite moderate about it initially
<ScottK> Daviey: True, but after discussion seemed to view it reasonably strongly.
<Daviey> ScottK: if there is zero difference, do you object to it going in now then?
<slangasek> ScottK: the fact that there's zero difference to the user is exactly why I don't see that it's warranted to *not* allow it in the release
<ScottK> slangasek: The complexity of supporting it post release for us is the difference.
<ScottK> See the fun we're having over MaaS in precise now (it was also slammed into the archive on release week).
<ScottK> In a nutshell, I guess the difference is that we don't have to promise zero regressions next week.
<slangasek> is that really because of the late landing in precise, as opposed to being a matter of the code having evolved since then?
<ScottK> It was trouble on contact.
<ScottK> I'm sure it's some of both though.
<Daviey> ScottK: Erm, i disagree with you stating it was introduced in release week
<Daviey> ScottK: https://launchpad.net/ubuntu/+source/maas/0.1~bzr146+dfsg-0ubuntu1
<slangasek> ah, but I would much rather hold the juju team to the "zero regressions" rule
<Daviey> And to be clear, this is on a whole different scale of less complexity
<ScottK> You're correct.
<ScottK> There were however significant changes release week (which must be what I remember) https://launchpad.net/ubuntu/precise/+source/maas/0.1+bzr462+dfsg-0ubuntu1
<stgraber> I really don't see why the JuJu folks want their package in the 13.04 release pocket. If it was my package, I'd actually be very happy to have it just in raring-backports as it'd let me do full version updates post-release without having to go through the SRU process with the exact same installation/discoverability for my users
<ScottK> slangasek: It's still a management burden for the SRU team.
<Daviey> Yes, i remember your commentary.
<Daviey> ScottK: I don't agree it to be any more of a burden than anything else.
<ScottK> MaaS certainly is.
<Daviey> And this is a different topic.
<stgraber> I mean the package will be in the software-center, will be visible in apt, will be mirrored as part of the Ubuntu archive and you get the ability to do major version updates for free if you need to. Why do you want to restrict yourself to the strict SRU policies you'd have to follow if you were to get it in the archive now?
<slangasek> as for juju-core being pushed the week of release... well, the juju team was asking for this a couple of weeks ago, and it didn't go in right away because AIUI Daviey + jamespage were iterating over the packaging and providing feedback; I'm not sure we want a perverse incentive of less diligent review
<Daviey> That bares no resemblance. Different team working on it, different target.
<slangasek> ScottK: from the earlier discussion, I thought it was proposed that the package would be in -backports + -updates?  so AFAICS that would be the same SRU version
<slangasek> er, SRU burden
<ScottK> slangasek: updates maybe someday if things go well.
<slangasek> except that in this case there would be no SRU team overhead for the initial version
<ScottK> I didn't really understand why that would be better either.
<ScottK> The only reason to copy it to updates is if you had something stable and you wanted to offer something newer in backports.
<ScottK> Additionally, I don't think Ubuntu should give this special treatment because it's a Canonical project.  If this were any other upstream, we wouldn't even be discussing it.
<Daviey> ScottK: To be clear, are you keen to actively block this?
<Daviey> ScottK: I don't think that is true.
<ScottK> Yes.  I think it's fundamentally a poor choice.
<slangasek> ScottK: well, I don't see accepting a new package into universe the week of release as special treatment
<slangasek> not qualitatively
<ScottK> The amount of arguing over it certainly is.
<ScottK> If it weren't a Canonical project, the release team would have said no and that would have been it.
<Daviey> ScottK: Well, this would likely be in now.... if you hadn't of decided to re-review my decision
<Daviey> Which TBH, is kinda unheard of anyway
<slangasek> if it weren't a Canonical project, would members of the release team be saying 'no' when other AAs / RT members are saying they're willing to process it?
<ScottK> Of which I was not aware.
<ScottK> If it were an upstream with a history of late delivery of buggy code, absolutely.
<Daviey> This upstream doesn't have that history
<ScottK> It's a matter of opinion.
<slangasek> it's a question of how broad a brush you're using
<Daviey> ScottK: I think that pov requires justification, otherwise it's nothing but rude against the juju team
<ScottK> BTW, I'm not sure how much before my comment yours was (they both say 4 hours ago now), but I hadn't seen it when I wrote my initial objection.  I wasn't intending to re-review what you'd done.
<ScottK> Daviey: I wasn't being that specific.
<Daviey> ScottK: noted, yours was 9 mins after my assessment. Apologies for assuming it was a re-review
<ScottK> If I had seen it and disagreed, I would have directly discussed it with you.  Not sure why didn't see the bug mail come in later.
 * ScottK starts to wonder if we should just do away with feature freeze and let anyone do whatever, whenever?
<Daviey> ScottK: Maybe raise it as a vUDS session?
<ScottK> Ooops.
<ScottK> Forgot the sarcasm tag.
<Laney> Now look what you've done, Kitterman.
<roaksoax> stgraber: so I have one more bug I'd like to get fixed for MAAS as a 0-day sru. Should I upload a new revision of the package that will superseed the one in the still unapproved queue?
<slangasek> ScottK: I don't see the current request being at odds with feature freeze; I thought our policy has always been "new packages that don't touch anything else are fine post-FF if you can find the manpower to review it"
<ScottK> slangasek: Yes, up to a point.
<ScottK> And particularly since this is a re-implementation of an existing package and it's not yet at feature parity, I don't see why it's a big deal to wait a week.
<Daviey> So full feature parity should be achieved this week?
<ScottK> Then if it turns out there are problems, we aren't stuck with some unsupportable mess.
<ScottK> No.
<Daviey> Otherwise, i fail to see how it makes any difference
<ScottK> Why would a user switch to a less mature/less featureful implementation?  Because someday it'll be better?
<ScottK> Other than PR, I don't see any reason to push it in now.
<stgraber> roaksoax: I can reject your previous MAAS upload and you can just upload the same version with the fix
<Daviey> ScottK: Would you be willing to review this next week?
<Daviey> ScottK: This version has assurance of being maintained.
<roaksoax> stgraber: that would work :)
<stgraber> roaksoax: ok, rejected
<ScottK> Daviey: I'll be glad to process the backport request next week.
<Daviey> ScottK: No, i am asking if you can do a NEW review?
<Riddell> evening
<ScottK> Not sure what next week looks like.  Probably.
<roaksoax> stgraber: Thanks, will prepare new package with fix and upload!
<cjwatson> ScottK: Sorry, I beat you to using sru-release, for casper :)
<ScottK> Heh
<ScottK> So where did kdenetwork go?
<cjwatson> I'm afraid I still feel pretty strongly about juju-core.  I actually think that putting it in post-release pockets will make things *better* for the juju team.
<Daviey> cjwatson: how so?
<stgraber> ScottK: so it looks like ubiquity 2.14.8 has now been published in raring-updates. Need anything else?
<Laney> You know we technically have backports open now.
<ScottK> stgraber: kdenetwork.
<ScottK> Laney: Good point.
<cjwatson> Because you won't have the initial "huge pile of stuff via updates, have to get the TB to pass it" thing.
<ScottK> Daviey: How about we put it in backports now?
<cjwatson> Also, I very strongly believe that the "but it's in universe" thing is a case of trying to have your cake and eat it too.
<cjwatson> It's entirely obvious that this is something that Canonical wants to recommend to relevant audiences
<cjwatson> We can't say that on the one hand, and on the other use the excuse of being in universe to be more lenient about it
<Daviey> Oh i agree. I don't subscribe to the idea that universe means 'throw any crap in'
<slangasek> well, from my POV having it in universe is an important benefit for the user because right now users of the package are getting it only from a ppa
<cjwatson> They can get it just as well from -updates a bit later, and with only a slight extra step from -backports nowish (if uploaded there)
<stgraber> ScottK: what version of kdenetwork do you need? The current one is 52min old
<slangasek> ... which means the system provides no guarantees that the maintainers won't introduce regressions
<stgraber> kdenetwork | 4:4.10.2+dfsg-0ubuntu1 | raring/universe | source, all
<ScottK> stgraber: that's the one.
<stgraber> ScottK: ok, so all set then?
<ScottK> I was looking for an ubuntu2.  Forgot about the DFSG.
<ScottK> Yes.
<cjwatson> stgraber: I'm just making sure cdimage can see it
<ScottK> It's been a long day.
<Daviey> Does it need a separate upload to go to backports, before s opens?  Or can i just be included there as part of acceptance ?
<stgraber> cjwatson: ok, feel free to kick the respin if you're already playing on nusakan
<cjwatson> It'd need a separate upload, or separate copy from a PPA or whatever
<cjwatson> slangasek: For my part, I don't see this as the normal case of a new package (I was fine with the libgit2 sync that somebody else accepted) because it's far from without interactions with existing packages; and of course it has the static linking business too which I'm separately unhappy about
<ScottK> Daviey: ^^^^ easiest just to re-upload with raring-backports.
<Daviey> cjwatson: Yes, that frustration has been shared.
<Daviey> jamespage: are you around?
<cjwatson> But not resolved.
<jamespage> Daviey, yes
 * jamespage reads backscroll
<cjwatson> Do we need to respin kubuntu-active as well?
<cjwatson> There's bits of kdenetwork in it, so I guess yes
<cjwatson> Oh, and ubiquity.  So yes.
<stgraber> right and ScottK marked it for respin on the tracker
<Daviey> jamespage: Can you re-upload targeting backports please?
<cjwatson> Respinning.
<cjwatson> So want the "respin everything marked for rebuilding" thing :)
<stgraber> well, I'm going to spend around 15h on various airplanes over the weekend so you may have that next week ;)
<jamespage> Daviey, ack - I'll sort out the ugly version number at the same time.
<stgraber> adding DB fields and testing migration scripts is the kind of thing that long flights are good for
<Daviey> jamespage: thanks
<jamespage> Daviey, ScottK: OK - uploaded to raring-backports
<Daviey> jamespage: thanks.
<Daviey> Hmm, I can't review backports.. can i?
<cjwatson> Technically yes but by policy no (same for me - it's ~ubuntu-backporters)
<cjwatson> But several relevant folks here
<ScottK> Daviey: I've approved the backport, so I think any archive admin can do New.  Please feel free.
<ScottK> I just clearly said it was approved in the bug.
<Daviey> ScottK: I didn't think i was allowed to process backports, even if approved.  Now i do.
<ScottK> IMO, ubuntu-backporters has to approve any backport.
<ScottK> Since this is a new package, there's none of the usual things to worry about that are unique to backports, so there's no reason I can't do the approval and leave the New to another archive admin.
<ScottK> It's a bit of an odd case to have come up.
<roaksoax> stgraber: done! thanks
<balloons> ogra_, have you tried the arm builds for panda or the nexus7?
<xnox> balloons: i can blast through nexus7 tomorrow morning. should be all fine.
<xnox> balloons: and panda as well.
<pgraner> balloons, we don't care about desktop even tho is built, server is the focus on arm
 * cjwatson fixes corner-case checksumming bug in publish-release
<cjwatson> (Confused verify-cloudfront)
<cjwatson> Daviey,jamespage: FWIW, things missed in the NEW review of juju-core: missing ${shlibs:Depends} (yes, it's at least a partially dynamically linked binary); fairly arbitrary Architecture: amd64 i386 that really should be any so that if nothing else we can have visibility of why it fails elsewhere
<Daviey> cjwatson: It was expressly set to amd64 i386
<infinity> Daviey: Yes, it shouldn't be.
<infinity> Daviey: It should be arch:any.
<cjwatson> expressly> that was in fact my complaint
<Daviey> cjwatson: If you are doing a post-review review, why didn't you just volunteer to do it in the first place?
<cjwatson> Er, because I was doing a load of other critical-path things at the time?
<Daviey> And now?
<cjwatson> Now I'm not
<Daviey> Super.
<cjwatson> And I don't see how this is any of your business
<cjwatson> Apparently I should never report problems in packages you care about.  Fine.
<Daviey> Well, you can surely see that it is frustrating to see someone do a review moments after it has just been accepted.
<infinity> You do realise that people can find issues with packages at any point, right?  "It was reviewed" doesn't imply it's perfect.
<cjwatson> I don't really care.  Sorry.
<cjwatson> Since I would far rather be in bed but I need to supervise a load of stuff.
<cjwatson> So, you know, sorry if finding problems has hurt your feeling
<cjwatson> s
<Daviey> No, it has not hurt feelings.  But I appreciate the apologetic sentiment.
<cjwatson> Happy to file bugs if you'd prefer.
 * cjwatson does so
<xnox> cjwatson: time to implement debian ftpmaster style auto-rejects based on lintian tags?! /me recently got auto-rejected in debian =)
<xnox> that should do it.
<Riddell> new Kubuntu builds on their way?
<cjwatson> Yeah
<infinity> Riddell: Yeah, waiting on ARM.
<cjwatson> 22763 pts/9    S+     0:00      \_ ssh -n -o StrictHostKeyChecking=no -o BatchMode=yes buildd@cadejo.buildd /home/buildd/bin/BuildLiveCD -l -A armhf -s omap4 -d raring kubuntu
<cjwatson> At some point ...
 * cjwatson feeds cadejo more hamsters
<cjwatson> It's building the squashfs
<cjwatson> Ah, good, there we go
<balloons> xnox, pgraner ok.. just wanted to see if you noticed some of the bugs creeping in.. the desktop images as usual have some little things
<pgraner> balloons, yep I'll round them up in the am for the release notes
<balloons> pgraner, excellent. Let me know if you need bug numbers :-0
<pgraner> balloons, ha!
<stgraber> apparently my brain really needs sleep now, so I'll disappear for a few hours and be back early tomorrow morning to finish some Edubuntu tests and look at techoverview/release notes. Good night everyone!
<infinity> stgraber: 'Night.
#ubuntu-release 2013-04-25
<plars> so are we still expecting a respin on ubuntu-desktop?
<Riddell> plars: iso tracker says no
<plars> hmm, I got the impression earlier that all desktops were respinning, maybe not?
<Riddell> nope
<ScottK> infinity, slangasek, somebody: When's the cutoff for Universe/unseeded uploads?
<ScottK> "soon" seems good.
<balloons> fyi ubuntu server & maas install failure, https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1172566
<ubot2> Launchpad bug 1172566 in debian-installer (Ubuntu) "MAAS Server install fails when network is disconnected" [Undecided,New]
<plars> Just hit bug #1172572 - seems to be an odd corner case, didn't seem to cause any problem so far, if I go back and forward again it clears up
<ubot2> Launchpad bug 1172572 in ubiquity (Ubuntu) "No option to continue from install type screen" [Undecided,New] https://launchpad.net/bugs/1172572
<plars> balloons: networkless may be a bit of a strange case for maas server :)
<JackYu> morning, everyone:)
<ScottK>  ^^^ is my sync, so someone else please review.
<vibhav> Frozen for release == Final Freeze, right?
<JackYu> vibhav, I think there could be 'Frozen for final release', 'Frozen for Beta release'...
<vibhav> JackYu: Yeah, that could be better, though I prefer the phrase "Final Freeze"
<JackYu> vibhav, I agree.
<jamespage> cjwatson, thanks for those bug reports
<diwic> Hi, I think we need to release note bug 1169984. How do I help out with that?
<ubot2> Launchpad bug 1169984 in linux (Ubuntu Raring) "Either oops or opening device fails with -ENODEV, with HDMI audio" [High,Fix committed] https://launchpad.net/bugs/1169984
<stgraber> good morning
<infinity> ScottK: The cutoff is "really effin' soon" but, honestly, until I mark it stable in LP, there's nothing stopping us from accepting and building stuff, since it's in -proposed anyway, we can toss it out if it doesn't make it.
<infinity> ScottK: (or carry it to S)
<pgraner> Daviey, can you review the bugs on http://iso.qa.ubuntu.com/qatracker/milestones/269/builds/42960/testcases/1461/results  and nominate for release notes etc..
<cjwatson> cdimage mirror syncing disabled
<pgraner> apw, http://iso.qa.ubuntu.com/qatracker/milestones/269/builds/42960/testcases/1461/results
<Laney> can we still unblock stuff?
<cjwatson> Laney: Yeah, for an hour or so
<xnox> Kylin not tested...
<Laney> cjwatson: ok, so autopostgresqlbackup (what a mouthful). don't know about cinder/nova; they aren't on media ...
<cjwatson> infinity was going to look at those two this morning
<Laney> cinder doesn't matter so much
<cjwatson> xnox: They were going to get to it this morning Beijing time ...
<cjwatson> JackYu: Any news on UbuntuKylin image testing?
<pgraner> apw, https://wiki.ubuntu.com/RaringRingtail/TechnicalOverview
<xnox> cjwatson: JackYu: all Kylin got all testing into the iso tracker.
<xnox> now. just mark as ready left I guess.
<cjwatson> Ah, good
<bkerensa> pgraner: more credits should be trickling in... I think we are just waiting on Developers list
<cjwatson> Riddell: Do you have any more details on the Kubuntu ubiquity failure on powerpc?  The original logs in that bug relate to an X bug that should have been fixed
<cjwatson> Sorry, I mean armhf+omap4
<cjwatson> bug 1164239
<ubot2> Launchpad bug 1164239 in ubiquity (Ubuntu) "ubiquity does not start on kubuntu 13.04 arm image" [High,New] https://launchpad.net/bugs/1164239
<highvoltage> stgraber: https://wiki.ubuntu.com/RaringRingtail/TechnicalOverview isn't frozen yet right? (just want to file and add a bug)
<stgraber> highvoltage: AFAIK it's still editable
<cjwatson> No reason it shouldn't be, indeed
<pgraner> bkerensa, ack, just keep updating
<highvoltage> other flavours should probably go ahead and update too, they're sections are a bit bare (perhaps they just have no issues :p)
<pgraner> highvoltage, yes it is
<highvoltage> is ubuntu having monthly releases soon? I see there's ubuntu-13.05, ubuntu-13.06, ubuntu-13.07 on launchpad. or was that just a premature addition based on rolling release / monthly release discussions?
<cjwatson> milestones not releases
<cjwatson> basically for planning
<cjwatson> and no, not premature, it followed all the TB discussions about that
<infinity> Riddell, highvoltage, knome, phillw, zequence: Do you have URLs to separate release announcements that we can link from ours?  (Same URLs as last time, but s/12.10/13.04/?)
<gema> stgraber: we need to remove one test case from the server upgrade list, upgrade (image) which is not valid anymore, this is for i386 and amd64
<gema> stgraber: I am trying to find it on the admin ui, but haven't had luck yet
<highvoltage> infinity: correct
<cjwatson> gema: was never valid in the first place :)
<xnox> pgraner: added release note to the description of bug 1172002
<ubot2> Launchpad bug 1172002 in ubiquity (Ubuntu) "Install doesn't mount encrypted swap for reinstall" [High,Confirmed] https://launchpad.net/bugs/1172002
<stgraber> gema: ok, I'll kill it
<cjwatson> at least not in the form given in that testcase description
<highvoltage> infinity: http://edubuntu.org/news/13.04-release
<stgraber> gema: ah, that'd be because the server upgrades are using the "Desktop upgrade" testsuite ;)
<highvoltage> (not published yet, but that's the URL)
<stgraber> gema: I'll create you a new Server upgrade testsuite
<cjwatson> stgraber: You shouldn't need to
<cjwatson> stgraber: There's no way to upgrade from the server images themselves
<cjwatson> stgraber: I think what happened is that, when the cdromupgrade script went away, somebody thought "oh, image upgrades don't work any more, flail" and replaced with the desktop image upgrade instructions
<cjwatson> stgraber: But that case should just have been removed since squashfs-base broke that use case
<cjwatson> (And it was never a very important use case anyway - networkless server upgrades, really? :-) )
<gema> stgraber: sounds good
<stgraber> gema: done
<Daviey> Please can nova and cinder be ublocked please.  I do not have a hints file.
<infinity> JackYu: Do you have a release announcement, or a web page you want us to reference in our generic release announcement?
<infinity> Daviey: Already done.
<gema> stgraber: that's awesome, you even kept the results, thanks!
<stgraber> cjwatson: right. We no longer have any CD/offline based upgrades for server, but I still needed a "Server upgrade" testsuite to list the online upgrade of server systems (standard do-release-upgrade -d)
<cjwatson> stgraber: There was already a separate test case for that, though
<Daviey> infinity: oh, thanks.
<cjwatson> "Upgrade" vs. "Upgrade (image)"
<cjwatson> And "Upgrade" already had the do-release-upgrade thing
<stgraber> gema: results are tied to the testcase, not the testsuite, so I can indeed change the testsuite completely without loosing results
<gema> stgraber: cool
<cjwatson> Oh, wait - OK, it does say "update-manager -d -c"
<cjwatson> So, yeah, that probably wants to be split
 * ogra_ never got why we have that command distinction
<stgraber> cjwatson: Correct, but the "Upgrade" + "Upgrade (image)" combo was coming from the "Upgrade desktop" testsuite, so I had to create a new "Upgrade server" testsuite for the server products that only contains the "Upgrade" testcase
<cjwatson> Ah, right
<gema> stgraber: and we may add more test cases in the future
<gema> the split makes a lot of sense
<stgraber> right
<stgraber> balloons: can you update http://iso.qa.ubuntu.com/qatracker/testcases/1310/info to also cover server upgrades (it says update-manager currently but should also say apt-get update/apt-get dist-upgrade and do-release-upgrade for servers)?
<stgraber> balloons: if you prefer to create a separate testscase that's fine too but then you'll have to let me know so I can migrate the results before we switch
<phillw> infinity: https://wiki.ubuntu.com/RaringRingtail/ReleaseNotes/Lubuntu
<gema> balloons, stgraber: I think a new test case is in order
<gema> they are different results after all
<infinity> phillw: Announcement, not notes.
<infinity> phillw: ie: last time, you had http://wiki.ubuntu.com/Lubuntu/Announcement/12.10
<infinity> phillw: So, same thing, but 13.04, I'm guessing, since that's already there?
<infinity> JackYu: Does Kylin have a release announcement I can link to?
<phillw> infinity: https://wiki.ubuntu.com/Lubuntu/Announcement/13.04 :)
<JackYu> infinity: Pls see https://wiki.ubuntu.com/UbuntuKylin/1304-ReleaseNotes, we are still preparing.
<knome> infinity, http://xubuntu.org/news/13-04-release for us
<smartboyhw> zequence: Do you have the Studio announcement link for infinity?
<cjwatson> source images might be almost working ...
<cjwatson> going to have to start publishing other images soon but I'll finish this first
<Daviey> infinity: maybe i'm mistaken, but nova and cinder still seem in proposed?
<cjwatson> They're mid-publish, I think
<cjwatson> Yeah, the publisher literally just started writing them into release
<Daviey> ah, ok.
<cjwatson> But I'll keep an eye on it and make sure that finishes
<Daviey> Thanks.
<infinity> JackYu: /win 224
<infinity> Erm.
<infinity> I suck at IRC.
 * cjwatson is slightly spooked by only about 1.5 source CDs coming out - wonder if something's up there
<zequence> infinity: Link to Ubuntu Studio release notes http://ubuntustudio.org/?p=719
<infinity> zequence: s/Notes/Announcement/?
<cjwatson> Sorry, DVDs not CDs
<zequence> infinity: Ah, ok. Let me create a page for it :)
<infinity> zequence: Since your notes seem to be at https://wiki.ubuntu.com/RaringRingtail/UbuntuStudio
<cjwatson> It was about 2.5 for quantal
<infinity> zequence: I'm okay linking to the notes.
<infinity> zequence: Would you prefer I link to your studio.org link above, or straight to the wiki?
<psivaa> stgraber: would you mind having a look at one of the VM's in aldebaran, utah-8063-raring-amd64 please. most of the vms with the latest image get stuck during reboot with ' Casper is resyncing snapshots and caching reboot files' on the console.
<psivaa> i tried with an older image and this issue is not occurring with the old image
<zequence> infinity: This would be better http://ubuntustudio.org/?p=726
<infinity> zequence: I asusme that won't be a 404 soon? :P
<stgraber> psivaa: what happen if you press enter?
<psivaa> stgraber: yes sorry if i press enter that reboots fine
<psivaa> stgraber: for every machine i have to press enter for a reboot
<zequence> infinity: The link is good
<infinity> zequence: Alright.  I assume it's just hidden or something?  I'll take your word for it. :)
<stgraber> psivaa: which is expected no? the fact that the message itself doesn't show up can be explained by some driver weirdness (I need to use the vmvga driver here to get working plymouth)
<stgraber> psivaa: oh crap, I think I see what you mean. If you preseed the reboot flag the machine won't reboot...
<psivaa> stgraber: yes exactly, and it appears only with the new images, because the older ones with the same setup worked
<psivaa> i mean older image
<stgraber> psivaa: yep, I see why, I definitely messed up that part...
<stgraber> cjwatson, infinity: ^
<stgraber> we need: http://paste.ubuntu.com/5600566/
<stgraber> otherwise even if the message isn't shown when $prompt is unset, we're still waiting for the keystroke
<cjwatson> Could you write up a release note?
<stgraber> I need to think of a workaround first, that doesn't involve someone manually pressing enter...
<psivaa> stgraber: i'll report a bug for that then
<psivaa> ?
<stgraber> psivaa: yes, please (against casper)
<cjwatson> Worst case: late_command hack?
<cjwatson> (Or equiv)
<psivaa> stgraber: ack
<stgraber> cjwatson: yeah, I've reading through the init script a few more times and there's no way to easily abuse it. So I'll come up with a sed command to fix it and tell people to run that at some point during the install (like late_command) to fix it
<stgraber> s/reading/read/
<stgraber> cjwatson: I guess we could get that into raring-updates now so that anyone generating images based on Ubuntu gets the fix at least?
<cjwatson> Shame, but at least it's possible
<cjwatson> Yeah
<stgraber> psivaa: ping me when you've got the bug number
<psivaa> stgraber: sure
<stgraber> sed "/eject -p -m/ a\\\n    [ \"\$prompt\" ] || return 0" /etc/init.d/casper
<stgraber> pretty isn't it? :)
<psivaa> stgraber: bug 1172653 is opened for that. and thanks for the debug :)
<ubot2> Launchpad bug 1172653 in casper (Ubuntu) "Preseeded installations do not complete reboot" [Undecided,New] https://launchpad.net/bugs/1172653
<stgraber> psivaa: can you test the workaround on one of your machine?
<stgraber> psivaa: basically run: sed "/eject -p -m/ a\\\n    [ \"\$prompt\" ] || return 0" /etc/init.d/casper
<stgraber> psivaa: as late_command or early_command (doesn't matter when it's run)
<stgraber> that should make the reboot work
<cjwatson> you're missing -i
<psivaa> stgraber: sure
<stgraber> cjwatson: indeed I am, thanks
<stgraber> psivaa: sed -i "/eject -p -m/ a\\\n    [ \"\$prompt\" ] || return 0" /etc/init.d/casper
<psivaa> stgraber: ack
<cjwatson> Would this be easier to read:
<cjwatson> sed -i 's/eject -p -m.*/&; [ "$prompt" ] || return 0/' /etc/init.d/casper
<stgraber> cjwatson: yep, easier to read and less likely to explode in people's shell scripts
<stgraber> it doesn't have give you the exact same file as the one in the casper update (which mine was doing) but we hardly care ;)
<cjwatson> Daviey: nova and cinder are in the release pocket now
<cjwatson> though apparently still in -proposed too which is slightly odd, but I think that'll just take another publisher run
<Laney> publishinghistory for them looks right anyway
<stgraber> casper uploaded, taking care of the release notes now
<cjwatson> How far from ready is Xubuntu?
<cjwatson> Also the rest of Kubuntu
<cjwatson> I'm getting pretty close to the point where I'm going to publish anyway and we release-note the things that haven't been tested; it's easier to withdraw the images later
<cjwatson> (Because otherwise the dailies get garbage-collected)
<knome> cjwatson, ok to release xubuntu
 * cjwatson finally gets source images roughly working
<cjwatson> knome: thanks
<cjwatson> I've marked that on iso.qa
<phillw> cjwatson: ppc-server image is being checked now for 'does it install'. We don't have the required hardware to do the more "esoteric" tests.
<cjwatson> ta
<phillw> cjwatson: the recursive bug is well known & documented, that is just release note worthy.
<knome> that happens to me as well... is there a workaround?
<phillw> knome: the sad saga is listed at http://launchpad.net/bugs/1066435
<ubot2> Launchpad bug 1066435 in linux (Ubuntu) "powerpc: "Fixing recursive fault but reboot is needed!"" [High,Confirmed]
<phillw> it's been around for a while now.
<knome> i don't have a ppc though...
<phillw> knome: then I'm not familiar with your issue, sorry.
<knome> okay :)
<phillw> but, do have a read of the bug and see if it gives you any pointers
<knome> i read a similar one that pointed to https://wiki.ubuntu.com/Audio/UpgradingAlsa/DKMS
<knome> phillw, bug 1169984
<ubot2> Launchpad bug 1169984 in linux (Ubuntu Raring) "Either oops or opening device fails with -ENODEV, with HDMI audio" [High,Fix committed] https://launchpad.net/bugs/1169984
<knome> but i'm not sure if that's my bug either
<knome> i can simply get around it by hard rebooting
<psivaa> stgraber: cjwatson: the reboot worked fine with sed -i 's/eject -p -m.*/&; [ "$prompt" ] || return 0/' /etc/init.d/casper being the late_command
<cjwatson> OK, good
<stgraber> psivaa: cool. I've added that to the release notes.
<psivaa> stgraber: ack
<phillw> infinity: do you have the link to ubuntu release notes to hand?
<infinity> phillw: The final link, or the current location?
<phillw> the final link, just so I can check it ours :)
<infinity> phillw: https://wiki.ubuntu.com/RaringRingtail/TechnicalOverview will be moving to https://wiki.ubuntu.com/RaringRingtail/ReleaseNotes shortly.
<phillw> tx
<Riddell> morning
<MissValeska> Is 13.04 out yet?
<smartboyhw> .....
<stgraber> MissValeska: wrong channel
<smartboyhw> Go to #ubuntu-release-party plz
<MissValeska> Ohh
<MissValeska> Kay
<MissValeska> Thank you ^-^
<cjwatson> Daviey: (a) Sorry I was somewhat on the tetchy side last night (b) Do you know if anyone's available shortly to do cloud image publishing?  I think we forgot to give the Americans advance notice of planned release times ...
<cjwatson> release team: please don't unblock anything else
<Daviey> cjwatson: Yes, I should apologise aswell.  I was unusually sensitive.
<cjwatson> Stress does that :-/
<Daviey> cjwatson: I think i've done it before, but i am worried it has changed since.  I'd rather wait for smoser who should be around shortly-ish
<phillw> I'll be AFK for approx 90 mins
<cjwatson> OK.  cdimage is syncing out now
<cjwatson> We do nominally have instructions on ReleaseProcess but they date from maverick
<cjwatson> And I too generally prefer not to guess ...
<Daviey> Yeah
<Daviey> I'll work with utlemming and smoser to get the instructions refreshed
<cjwatson> Great
<ogra_> Riddell, i cant really belive that bug 1172552 and bug 1164239 are the same bug .... the latter one was an xserver issue that was fixed by mlankhorst right after beta (and the images work fine with unity since then)
<ubot2> Launchpad bug 1164239 in ubiquity (Ubuntu) "duplicate for #1172552 ubiquity does not start on kubuntu 13.04 arm image" [High,New] https://launchpad.net/bugs/1164239
<ubot2> Launchpad bug 1164239 in ubiquity (Ubuntu) "ubiquity does not start on kubuntu 13.04 arm image" [High,New] https://launchpad.net/bugs/1164239
<stgraber> for those not looking at #ubuntu-devel, please do. Looks like we forgot to tell LP that raring is only supported for 9 months (leading to ubuntu-support-status and likely the software-center lying about actually support length)
<Riddell> ogra_: ok maybe they're not then
<ogra_> some logs would eb good :)
<Riddell> ogra_: on the current image I can't even press cntl-alt-F1 to get a terminal (but the mouse moves fine)
<ogra_> *be
<Riddell> so I think I need to work out the serial console thing again which I wasn't in the mood for at 4 in the morning
<ogra_> just add console=ttyO2 to the kernel cmdline in preEnv.txt on the first partition of your install media
<ogra_> hmm
<ogra_> you might also want serialtty=ttyO2
<ogra_> for casper
<zequence> ETA 18:00 UTC?
<smartboyhw> zequence: Who says that?
<zequence> smartboyhw: I'm asking..
<stgraber> zequence: should be much earlier than that. The plan was for 11:00 UTC but there's been a last minute problem that'll delay the release a bit.
<zequence> stgraber: Ok, good to know (I was planning to go out for a while, but will stay until the release is out)
<czajkowski> aloha
<cfhowlett> czajkowski, mohalo
<vibhav> o/
<cjwatson> vibhav: /
<cjwatson> ?
<vibhav> cjwatson: o/ denotes a waving hand
<vibhav> afaik
<smartboyhw> cjwatson you don't do that in meetings?
<cjwatson> Yeah, it usually means you want to ask a question
<Laney> It's common for it to denote raising your hand, i.e. "I have something to ask"
<cjwatson> So I'm asking what your question is
<smartboyhw> lol
<vibhav> nerver knew that
<vibhav> I should probably search for another emoticon
<popey> how about ð©
<smartboyhw> popey: Hmm I can't see it in AndroIR
<popey> Sucks to be you â»
<smartboyhw> *AndroIRC
<vibhav> Can't see this here too
<popey> http://www.fileformat.info/info/unicode/char/1f4a9/index.htm
<smartboyhw> lol popey
<vibhav> heh
<highvoltage> stgraber: do we have an eta on release time? or is it around 18:00 as usual?
<SirDidi> is there a 13.04 release party channel?
<ogra_> yes
<ogra_> #ubuntu-release-party
 * ScottK ponders the size of the required warning label for Kubuntu powerpc.
<ogra_> 6x3
<SirDidi> @ogra_g thx
<cjwatson> UbuntuHashes done
<cjwatson> God help me
<JackYu> :)
<asgeir_> its OUT !!!
<popey> heh
* cjwatson changed the topic of #ubuntu-release to: Ubuntu 13.04 and 12.04.2 released | Archive: frozen | S? S? Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or beer | melior malum quod cognoscis
<smartboyhw> Thank you Ubuntu Release Team <3
<ogra_> thank you smartboyhw ... you did your part too :)
<smartboyhw> ogra_ my part isn't as big as yours:p
<ogra_> big enough :)
<ogra_> cjwatson, so how about we just open 13.10 as "Silent Sabdfl"
<ScottK> infinity and cjwatson: We have a shot at a workaround that may make the Kubuntu armhf image usable, so please keep the image around for a bit in case it turns out we can release it.
<smartboyhw> ogra_ +1:P
 * ogra_ would be curious what a "Silent Sabdfl" logo would look like ... might be intresting what the design team would come up with ...
<belgianguy> hmm, I get a 13.04 upgrade alert
<belgianguy> but it says it's in ALPHA stage ?
<belgianguy> is that normal
<wgrant> cjwatson: ^^ meta-release still references DevelReleaseAnnouncement
<Daviey> The meta files haven't been updated?
<belgianguy> http://i.imgur.com/mmxWcg3.png
<Laney> probably AFKing - can anyone else edit that?
<wgrant> I don't believe so
<wgrant> Will need IS
<ScottK> Oh, never mind, it's already released (Kubuntu armhf)
<Laney> ho hum
<Laney> elmo: ^?
<wgrant> elmo: ^^ if you have a sec
<elmo> hmm?
<wgrant> elmo: meta-release needs an s/DevelRelease/Release/
<wgrant> http://changelogs.ubuntu.com/meta-release
<wgrant> ReleaseNotes: http://archive.ubuntu.com/ubuntu/dists/raring/main/dist-upgrader-all/current/DevelReleaseAnnouncement
<wgrant> ReleaseNotesHtml: http://archive.ubuntu.com/ubuntu/dists/raring/main/dist-upgrader-all/current/DevelReleaseAnnouncement.html
<belgianguy> This is a full screenshot: http://i.imgur.com/xg5GlT3.png
<elmo> where's cjwatson?
 * Daviey does the bzr
<elmo> I gave him edit privs
<elmo> one second
<Laney> AFK?
<elmo> let me see if he's around before I use root
<wgrant> I assume it was he that set it to Supported, but I guess he's gone now
<Daviey> someone want to double check, http://pb.daviey.com/FR5B/ ?
<wgrant> Daviey: Right
<elmo> cjwatson is en route
<Daviey> elmo: As user changelogs bignay:/srv/changelogs.ubuntu.com/www
<Daviey> ah ok
<cjwatson> ScottK: I think I released it anyway
<ScottK> Yes.  It turns out you did.
<cjwatson> Daviey: ta, done
<ScottK> I suspect the low memory thing with the slide show is our culprit on armhf as well and we need to come up with an appropriate workaround.
<Laney> merci
<cjwatson> ScottK: on the basis that it's easier to withdraw later than to try to keep dailies around for an undefined time
<ScottK> OK.
<cjwatson> belgianguy: should be fixed for you now, modulo caching
<ScottK> Makes sense.
<belgianguy> k guys, thanks for the fix ;)
<belgianguy> cjwatson: yup, it's fixed, see you soon!
 * stgraber removed queue admin rights from the release team for raring and added these same rights to ubuntu-sru
<rustx> http://images-mix.netdna-ssl.com/w/300/h/300/q/85/upload/images/extaudio/5591d72c-abd9-454f-a8e8-52ce288d24b2.jpg
<cjwatson> stgraber: thanks - I've been waiting for an official name announcement before starting on NRCP
<rustx> oups .. sorry :-[
<stgraber> cjwatson: yeah, makes sense. It just bothered me when I noticed I could still see those buttons in +queue and figured that was one of those things we can do even without a name for s.
<cjwatson> Yeah
<ScottK> Maybe it's a test to see if we can function without him and the TB should just pick something ...
<slangasek> cjwatson, infinity: congrats
<rickspencer3> slangasek, congrats for what?
<ogra_> rickspencer3, release ?
<slangasek> rickspencer3: for this 13.04 thing that's been announced as out :)
<doko> opening the s-series?
<ogra_> doko, haha
<ogra_> not yet
<rickspencer3> slangasek, weird, how come no one told me about it?
<ogra_> unless you come up with a name and take the blame for it
<ogra_> rickspencer3, infinity sent you a mail, i'm sure
<rickspencer3> oh, right
<smartboyhw_> ogra_ is it that no name = no opening?
<infinity> rickspencer3: Oh, by the way, we released.
<rickspencer3> :)
<rickspencer3> congrats infinity
<ogra_> :)
<ogra_> smartboyhw_, right
<rickspencer3> infinity, I met someone in a dream who asked me if the release was out, and forced me to wake up and check the website at like 5am
<smartboyhw_> :O
<rickspencer3> seriously
<doko> so where's the new name?
<infinity> And in 15 minutes, I'm calling the next one Spanky Spaniel.
<cjwatson> smartboyhw_: the first steps intrinsically involve knowing the name
<ogra_> i guess it would technically work with a dummy ...
<ogra_> but you would have to rename it then
<cjwatson> less trouble to wait, sadly
<ogra_> yeah
<infinity> ogra_: We'd have to change the string in too many places.
<infinity> ogra_: Just not worth it.
<doko> that would be spanky daniel, but it's s not d
 * ogra_ still votes for "Silent Sabdfl"
<cjwatson> doko: Clearly you know something about dholbach that I don't
<ogra_> haha
<infinity> cjwatson: They're from Berlin...
<ogra_> yeah, berlin ...
<doko> cjwatson, yeah, ...
<cjwatson> I think I'm happy for it to stay that way
<doko> also I tend to see dholbach more at conferences than in Berlin lately ...
<rickspencer3> so, I think 13.04 is our best desktop yet
<doko> can we just accept s-series as an alias?
<ogra_> rickspencer3, ++
<cjwatson> doko: Not without some code changes
<rickspencer3> ogra_, what is also cool, is that I have Ubuntu touch running on my tablet :)
<rickspencer3> and I have an IDE with an SDK
<ogra_> :D
<cjwatson> Oh yeah, I should update my N7 while I have bandwidth
<rickspencer3> ogra_, now I just need to make new photobomb for my tablet
<ogra_> and package it
<smartboyhw_> https://plus.google.com/113294244748214217005/posts/59FhBbNNWG3
<smartboyhw_> LOL
<dobey> S-shaped Seahorse
<rickspencer3> hey all
<rickspencer3> I'm sure you are all reading this now?
<rickspencer3> http://www.markshuttleworth.com/archives/1252
<rickspencer3> :)
<dobey> or we should release early on Sept 19, and call it Scurvy Seadog
<smartboyhw_> lol
<smartboyhw_> Saucy Salamender!? Holy christ that's ugly..
<dobey> "Strong indicator of a pristine environment" ?
<dobey> tell that to the salamanders in my yard
<dobey> poor things just don't know they're not supposed to be here :)
<barry> salamander sauce?  almost makes me want to go veg <wink>
<dobey> barry: except for bacon, at least
<Laney> heh
<barry> dobey: yo! no bacon
<dobey> barry: traitor
<rickspencer3> I like it
<rickspencer3> lol
<rickspencer3> it happens to me every time
<rickspencer3> my first reaction to the name is "omg no"
<rickspencer3> then it grows on me
<cjwatson> Stockholm Syndrome
<Laney> I didn't have that this time
<cjwatson> How appropriate :)
<rickspencer3> lol
<Laney> maybe it'll go the other day
<Laney> way
<rickspencer3> there was one name that I refused to use for the whole release though :)
<ScottK> dobey: One of my daughters spent three years being a veg, but bacon got her in the end.
<wgrant> ogra_: If you try to rename a live distroseries on LP I will cry :)
<barry> after we round the z's and head back to a, can we raffle off naming rights?
<kenvandine> ScottK, how can anyone resist bacon!
 * ScottK doesn't know.
<barry> bacon is the candy of meat
<rustx> muslims knows
<kenvandine> indeed
<ogra_> wgrant, ouch, i thought it would be clever
<barry> or maybe the crack of meat anyway :)
<kenvandine> rickspencer3, i so wanted the "rolling rick"
<rickspencer3> my family discovered bacon flavored ranch dressing last week
<kenvandine> yum
<rickspencer3> suddenly, salads are popular with my teenage kids :)
<rickspencer3> kenvandine, so did I!
<rickspencer3> lol
<ScottK> http://www.baconismagic.ca/pre-trip-planning/parts-of-the-pig-that-are-delicious/
<kenvandine> hehe
<dobey> Saucy Sriracha
<rustx> hey guys : https://fbcdn-sphotos-g-a.akamaihd.net/hphotos-ak-prn1/58884_10151539593854190_1629934171_n.jpg
<barry> dobey: now *that* i can support
<rustx> enjoy, bacon time :)
<ScottK> At least saucy is short and easy to type.  That's the most important thing.
<kenvandine> indeed
<rickspencer3> ScottK, right, I will find ways to mispell it, I am sure
<rickspencer3> but Quantaal
<dobey> barry: it's too bad we don't have real UDS any more though. could have made special t-shirts for it :)
<rickspencer3> quetzelator?
<dobey> Quetzelcoatl
<rickspencer3> ScottK, infinity, cjwatson, Riddell, and the rest of the release team ... congrats on a smooth release, btw
<rickspencer3> now that we have the name, I feel like we can finally call it "done" :)
<barry> dobey: rooster sauce
<rustx> i am not part of the team, but Thanks to all of you !!!
 * smartboyhw_ salutes to the whole Ubuntu Release Team
<dobey> barry: but an ubuntu parody :)
<dobey> rickspencer3: especially given that little kerfuffle we had yesterday :)
<barry> dobey: we could put it on youtubuntu
<rickspencer3> dobey, do you want to tell me about it over a proprietary sip client?
<balloons> stgraber, gema et la.. I didn't have time to fix it properly yesterday, but yes someone just added the desktop upgrade tests to server.. Not good.. So yesterday I filed this bug to re-add a "do-release-upgrade" test. It'll get added: https://bugs.launchpad.net/ubuntu-manual-tests/+bug/1172452
<ubot2> Launchpad bug 1172452 in Ubuntu Manual Tests "Testcase Needed: Server Upgrade Test" [Undecided,New]
<dobey> rickspencer3: lol
<stgraber> rickspencer3: ahah, yeah, for the next 10min until someone asks when they can upload to saucy ;)
<smartboyhw_> balloons: Hurray wrong channel posting;P
<ogra_> is it open yet ?
<stgraber> balloons: ok, good. So I gave you a new testsuite for those tests, just let me know when you have the new testcase writen and I'll manually swap the IDs in the DB
<balloons> stgraber, ohh.. excellent, thank you
<smartboyhw_> Just think of it: All the changelogs will be saucy now:o
<dobey> so subliminal
<med_> I guess folks have 6 months to work on their release party recipe of "Saucy Salamander" appetizers.
<kamal> hi Archive Admins -  please let me bring to your attention https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/982889 ...
<kamal> this Critical bug makes Raring yield a black screen on boot instead of the lightdm login for many systems ...
<ubot2> Launchpad bug 982889 in OEM Priority Project precise "X trying to start before plymouth has finished using the drm driver" [High,In progress]
<kamal> fixed packages (lightdm and plymouth) are already available in -proposed ...
<kamal> is there any way they could be pushed into -updates immediately-ish?   its a pretty bad user experience without them.
<infinity> kamal: I'll be looking at that in a sec, yeah.
<kamal> infinity: thanks very much
<slangasek> infinity: would you rather have me look at it?
<cjwatson> saucy-changes exists, for the record
<infinity> slangasek: Go nuts.
<Laney> Are you going to copy juju-core out of backports?
<infinity> slangasek: I already reviewed it once when I accepted it to -proposed, another set of eyes would be good.
<infinity> Laney: No rush to do that.
<Laney> no, just in general.
<infinity> Laney: Oh, or do you mean from backports to saucy-proposed?
<Laney> yes
<Laney> Seeing handbrake ^ reminded me
<infinity> (Which is so backward...)
<infinity> Yeah.
<infinity> I'll do that nowish.
<slangasek> infinity: oh, this is just for -updates promotion?  hmm right... well I can't look at it for a bit anyway, and if it's just the -updates copy not sure it needs more review
<infinity> slangasek: Alright, I'll JFDI.
<kamal> well oiled machine, you guys are!
<plars> The link to bug 1172572 has a typo in the url on the release notes (s/bug/bugs)
<ubot2> Launchpad bug 1172572 in ubiquity (Ubuntu) "No option to continue from install type screen" [Medium,Confirmed] https://launchpad.net/bugs/1172572
<xnox> plars: looking
<infinity> kamal: Released as of the next publisher run.
<kamal> infinity: thanks!
<plars> Ah, I can edit
<plars> odd, it wouldn't give me an edit option at first, but I am logged in
<highvoltage> stgraber: heh, I see someone even submitted a deployment in Afrikaans.
<stgraber> highvoltage: hehe, yeah. We had a few in foreign languages in the last batch I processed
<cjwatson> doko: You can safely upload toolchain stuff now, though hold off a bit before accepting.
<doko> cjwatson, uploaded base-files, did plan to do binary copies of three packages from a ppa. can these be done too at the moment?
<cjwatson> Yes, but again just don't accept until I've checked that the first publisher run is good
<doko> ok
<doko> subscribed to saucy
<doko> -changes
<cjwatson> stgraber: Yeah, for next time, you actually actively mustn't change perms before we've created the new series, because it copies them from the previous one ...
<cjwatson> stgraber: I'll fix things up now
<stgraber> cjwatson: gah, yeah, I should have remembered that the init of a new series copies all the permissions from the previous one (after the whole mess we had to fix because of duplicate package sets entries)
<ScottK> xnox: If you're going to take the plunge on boost, now would be the time to talk to doko about uploading it.
<xnox> ScottK: i think i'm ok to upload it into unapproved right about now.
 * xnox is just resigning changes at the moment.
<slangasek> infinity: btw, just to be sure... the lightdm update got a versioned dep on plymouth, yes?
<cjwatson> It did, proposed-migration noted it
<infinity> slangasek: IIRC.
<SpamapS> Hey shouldn't we change the default for queuediff to raring in ubuntu-archive-tools ?
<rtg> ogasawara, I think we can delete the ubuntu-raring-lbm.git repo, yes ?
<slangasek> infinity: checked and confirmed
<infinity> SpamapS: Patience (but yes).
<rtg> -EWRONGCHAN
<cjwatson> SpamapS: yeah, missed that in my sweep - done
<cjwatson> doko: OK, feel free to start accepting to saucy-proposed
<cjwatson> doko: But security builds means it's a while 'til they'll start
<doko> cjwatson, I know, I prepared at least some of these ;)
<cjwatson> heh, ok
<stgraber> I quickly did the copy of the raring manifest to saucy on the tracker, created the daily milestone, marked all the old milestones released and updated nusakan to point to the new milestone
<stgraber> so whenever we get the first dailies they should auto-publish just fine
<cjwatson> cool
<cjwatson> I think I'll finish up shortly; done most of what I can do today
<cjwatson> have fun :)
<infinity> Beer o'clock.
<infinity> Cheers.
<doko> xnox, copied boost-defaults from the ppa
<stgraber> infinity: have fun!
<xnox> doko: ok.
<xnox> doko: there is also the splitted mpi and boost1.53
<xnox> doko: at http://people.canonical.com/~xnox/repo/
<xnox> doko: can upload in 2 hours or so, but AFK at the moment.
<doko> will be away the evening
<ScottK> doko: I can accept his upload if you're OK with it.  I'll be around for another 4 -5 hours.
<doko> sure
<ScottK> xnox: ^^^ ping me.
<doko> cjwatson, do the archives jobs on p.u.c. run again?
<doko> cjwatson, infinity: once the gcc-defaults build is done, we should be good
<balloons> a little release humor for you all.. I can't be the only one tickled by the fact we'll be supporting 12.10 longer than 13.04 :-)
<xnox> ScottK: and everyone else AA: please wait for gcc-defaults to fully publish before accepting above boosts. I'd rather have them build by gcc4.8. And it's a package split so should be ok.
<ScottK> xnox: OK.  Ping me if you notice it's ready.
<xnox> ScottK: gcc is stuck somewhere mysterious....
<ScottK> Lots of other builds today.
<ScottK> Or more mysterious than that?
<xnox> it's fully build, yet not published anywhere and not in the new/unapproved queues.
<ScottK> It looks to me like the last publisher run didn't go.
<ScottK> I was going to wait ten minutes and then scream if the next one doesn't.
<xnox> meh.
<ScottK> slangasek, cjwatson, infinity, wgrant, whoever: I don't think the publisher is running.  As an example, https://launchpad.net/ubuntu/+source/distro-info-data/0.13ubuntu0.1/+build/4520058 should have been published twice by now.
<ScottK> Yeah, I think it's definitely dead.
<ScottK> xnox: Is there some sekrit Canonical communication method you can use to get someone to fix the publisher?
<slangasek> is it possibly off because of the archive opening for s?
<ScottK> Not intentionally.
<ScottK> cjwatson earlier told doko not to accept stuff until it had run once succesfully and then told him to go ahead.
<ScottK> Also there's tool chain stuff that's trying to get built and out (e.g. gcc-defaults)
<ScottK> slangasek: ^^^
<slangasek> ok, let's see if that's something I can fix
<ScottK> Thanks.
<slangasek> according to the logs, the publisher ran at 19:30 (ish) UTC
<slangasek> and is still running
<slangasek> oh; rather, the instance that started at 16:33 is still running; hmm
<ScottK> First publisher run with a new distro and it takes ~forever?
<ScottK> I don't recall that from before.
<slangasek> well, stracing shows the process doing nothing useful
<slangasek> so I suspect something's gone awry
<slangasek> ah, crashed now with some OOPSes in the logs; maybe I managed to break it by stracing it
<ScottK> Sounds like my work here is done.  Enjoy.
<ScottK> ;-)
<slangasek> I think it may be unwedged now; we'll see soon
<ScottK> Thanks.
<ScottK> slangasek: win
<ScottK> Thanks.
<slangasek> hurrah
 * ogra_ applauds
<ScottK> xnox: ^^^
 * xnox hates the next sentence a lot!
<xnox> slangasek: would you be able to turn britney on from raring to saucy? or is for cjwatson  / infinity to do?
<slangasek> xnox: mmm, I probably can if someone can tell me where it lives
<xnox> slangasek: well the logs of it are exposed on people.canonical.com/~ubuntu-archive and trace from there?! .... so i'd think it's not far away from that place.
<xnox> Laney: can I please have transition tracker? I pushed s/raring/saucy/ but it didn't auto-pull it seems.
<slangasek> xnox: I'm pretty sure it runs on pepo, but it's not in the ~lp_archive user's homedir where IIRC britney used to be
<xnox> ok. wait for colin then.
<slangasek> ah, no, proposed-migration does seem to live on people.c.c after all.. let's see then
<doko> accepted the two boost uploads. -proposed has 4.8 as the default, so everything is fine
<ScottK> doko: publisher was broken earlier, so we were waiting for it.
<doko> ugh
<xnox> ScottK: i think slangasek unbroke it. But we'll see once boost builds =) as we need to "nudge" the archive somehow for a publisher to see what's happening =)
<ScottK> Yes.  He did.
<xnox> ScottK: doko: I see gcc published in proposed correctly.
<ScottK> It would have only be recently though.
<xnox> but britney isn't saucy yet.
<doko> looks like everything I uploaded is published
<slangasek> seems cjwatson committed the change, but it wasn't pushed to people.c.c; still not entirely sure that's the relevant place that it runs from, but have updated the checkout anyway
<infinity> proposed-migration being off isn't a bad thing, per se.
<xnox> fair enough =) it's just it would be helpful with boost transition i'm about to blast once boost1.53 builds and publishes.
<slangasek> well, I'm fairly certain we don't want p-m trying to migrate from raring-proposed to raring, at the least :)
<doko> p-m?
<infinity> slangasek: Hence being off seems like the sane default for now. :P
<infinity> doko: britney.
<infinity> xnox: I don't see how britney would help your boost transition at all, since it all needs to happen in proposed anyway.
<slangasek> infinity: I haven't turned it on or off.  I haven't even found an off switch for it.
<infinity> slangasek: It's de-facto off right now.
<infinity> slangasek: Colin and/or I were going to sort all that in the morning.
<doko> weren't all these -propsed -> -raring messages coming from greenend.co.uk?
<infinity> (Or Colin might do so when he gets in to Cambridge tonight if he can't sleep, but I'm about to pack up and go be somewhere not here)
<xnox> infinity: true.
<slangasek> infinity: what reason is there for me not to do that today, though?
 * xnox will hack up a local transition tracker here to watch things, until laney pulls the new revision into ben on p.c.c
<infinity> slangasek: Nothing compelling, I suppose, but no wildly compelling reason to do so, either, since this is all the usual toolchain staging period and such.
<doko> infinity, I'm done with it
<ScottK> xnox: Since everything except the dev packages is co-installable and there's a lot of boost stuff, I think it's good to let 1.53 go into the release pocket.
<infinity> doko: boost, other bits.  Anyhow, there's no reason we MUST migrate right now, was my point.  Leaving things in proposed for a little while won't kill anyonw.
<ScottK> True.
<ScottK> infinity: If you have a moment, would you please accept my debootstrap SRU for raring.
<xnox> infinity: just will make the first run big =)
<doko> infinity, boost is already there as well, that's just the main/universe split which is running
<xnox> ScottK: !!!!! fixing bugs in raring, before devel series!
 * xnox not like
<ScottK> Devel series isn't open.
<xnox> ScottK: i'm not sure what you are talking about =) i'm uploading packages into it and they are building and publishing (almost) ;-)
<ScottK> You're working on toolchain.
<infinity> debootstrap counts.
<ScottK> I just forward copied it.
<ScottK> Should show up in a moment.
<ScottK> distro-info-data probably does too.
<ScottK> There you go.
<infinity> ScottK: Oh, I bet that sent you an email about can't accept with pending publications in raring.
<infinity> ScottK: Just re-copy after the next publisher run and accept.
<ScottK> We'll find out.
<ScottK> I already found out you can't copy the source before it's built.
<infinity> Given that you can't have the same binary in the archive twice, that would be bad form.
 * infinity packs up and leaves the office.
<ScottK> muon got rejected for the same reason.
<ScottK> Just resync'ed.
<xnox> meh. going to sleep. will be blasting boost tomorrow.
<ScottK> Yeah, binaries have to be published too ...
<ogra_> some of the changes mails look odd
<ScottK> Trying again ...
<ogra_> (plymouth, xdiagnose and lightdm dont list their changelog entries )
<doko> I'm promoting isl and cloog-isl, forgot about these and only did promote mpclib3
<xnox> ogra_: syncs
<doko> MIR was already granted, see #1119818
<xnox> ogra_: carry over from raring-proposed/-updates
 * ScottK has to go.
<ScottK> If by some miracle another debootstrap appears for saucy, please accept it someone.
#ubuntu-release 2013-04-26
<Laney> xnox: the relevant cron entry is disabled "for saucy opening"
<Laney> which also covers some other things, notably britney, so i'm loathe to uncomment it myself
<xnox> Laney: fair enough.
<Laney> soz!
<Laney> how was the release party?
<infinity> Nobody died.
<infinity> I suppose that makes it a success.
 * infinity adds saucy schroots to all his porting boxes.
<Laney> That's what I look for in a party
<Noskcaj> do you know if saucy is meant to appear in testdrive yet?
<infinity> doko: Did you re-override gcj-4.8 after I did? :/
<infinity> Silly double-override bug.
<infinity> wgrant: I'll give you big money and fabulous prizes if you can unwind the double-override bug and make it go away.
<infinity> wgrant: It may be the single most confusing thing Soyuz can do to an archive admin who isn't painfully vigilant.
<xnox> mk-sbuild saucy is failing for me and doesn't install apt. *sigh*
<Laney> debootstrap sad or?
<xnox> well I added the usual symlink....
 * Laney just finished mirroring so is about to try
<xnox> I now copied raring chroot / schroot config and just gonna dist-upgrade it by hand. That seems to work.
<wgrant> infinity: If it was reasonably easy I would have done it 3 years ago :)
<Laney> xnox: "Failure while installing base packages."?
<xnox> wgrant: .... but were you offered fabulous prizes 3 years ago?! =)
<wgrant> A good point!
<infinity> wgrant: What he said!
<xnox> Laney: well i was getting failure in finish.d
<Laney> well, that's after this
<infinity> xnox: I don't see how debootstrap would fail, given that the release pocket is an identical copy of raring.
<wgrant> infinity: In related news, can you promote something from proposed so I can check that the saucy dominator isn't still too much for postgres?
<xnox> wgrant: how about item #1: Blackpool Rock Candy ?!
<infinity> wgrant: Sure, I'll do distro-info-data, that should be vaguely harmless.
<wgrant> infinity: Thanks
<wgrant> I eventually realised that britney must be turned off, so I hadn't actually broken anything.
<wgrant> But I'd like to see saucy-release dominated before I fly away.
<infinity> wgrant: Should hit the next publisher run.
<RAOF> xnox, infinity: Curiously, debootstrap doesn't seem to download apt-get.
<wgrant> infinity: Thanks.
<Laney> debootstrap --variant=buildd is failing for me
<Laney> but the log file it points me to doesn't exist
<Laney> grr
 * infinity tests.
<infinity> Hrm, yes, the lack of apt there is worrisome.
<wgrant> Hm
<wgrant> My mirror isn't that out of date, and it works fine
<infinity> I'll unwind this in a second.
<Laney> http://paste.ubuntu.com/5604007/
<wgrant> Are we missing lots of overrides?
<wgrant> Yeah
<infinity> http://paste.ubuntu.com/5604012/
<infinity> Seems likely, from that output.
<wgrant> No Build-Essential in Packages
<infinity> That could self-solve after this next run.
<infinity> Due to the germinate->apt-ftparchive ordering oddities, and the fact that the release pocket hasn't been regenerated in a while.
<wgrant> Yeah
<wgrant> The last two release publications failed
<wgrant> But germinate's working fine
<wgrant> The one in 15 minutes will hopefully wor
<wgrant> k
<infinity> Fingers crossed.
<infinity> What was breaking it?
<xnox> .... well publishing was stuck last night and there were ooops that vorlon was trying to unwind on #launchpad-ops
<xnox> see scrollback there.
<wgrant> infinity: BPPH is sufficiently large that postgres hadn't yet automatically reanalysed it, so saucy domination queries were taking hours and getting killed
<wgrant> That *should* be fixed now
<infinity> wgrant: Oh, that's vomitously fun.
<wgrant> Yes
<wgrant> So I think saucy may still be running on its initial indices
<wgrant> It's likely that no subsequent release publication succeeded.
<doko> infinity, according to my backlog, nobody did override these before I did: http://paste.ubuntu.com/5604017/
<infinity> doko: I overrode them in the queue, and then you did it again in the same run, which makes Soyuz drop arch:all packages on the floor, cause it's SMART.
<infinity> doko: I thought Colin has mentioned that to you in a query.
<Laney> laney@iota:~$ GET http://archive.ubuntu.com/ubuntu/dists/raring/main/binary-amd64/Packages.bz2 | bzcat | grep-dctrl -FBuild-Essential -c yes
<Laney> 44
<infinity> doko: No big deal, copying over itself (which I just did) should rescue it.
<Laney> laney@iota:~$ GET http://archive.ubuntu.com/ubuntu/dists/saucy/main/binary-amd64/Packages.bz2 | bzcat | grep-dctrl -FBuild-Essential -c yes
<Laney> 0
<wgrant> Yeah
<infinity> Laney: Yeah, see above.  That should self-solve when the release pocket reindexes in this upcoming run.
<wgrant> infinity: You've checked that the override files look sane now, right?
<wgrant> Given you have pepo access
<Laney> Rockin.
<infinity> wgrant: Nah, I'm operating on faith (and multitasking a bit here)
<wgrant> :)
<infinity> wgrant: germinate/apt-ftparchive order is a known misfeature, and a plausible explanation for this.
<infinity> Colin and I were discussing how NMAF and germinate-from-db combined could wipe that one out.
<doko> infinity, but you didn't touch mpclib3, isl, and cloog, correct?
<infinity> doko: I did mpclib3, but it doesn't have arch:all packages, so the double-override didn't break it.
<infinity> doko: I didn't do the others.
<doko> ok
 * infinity retries ecj on powerpc...
<wgrant> infinity: Yeah, but I was hoping to find out ASAP if it wasn't the actual explanation, 'cause I'm well past EOD already.
<wgrant> But we'll see shortly.
<infinity> adconrad@pepo:/srv/launchpad.net/ubuntu-archive/ubuntu-misc$ grep Build-Essential more-extra.override.saucy.main | wc -l
<infinity> 172
<wgrant> That's more plausible.
<infinity> That seems like a number bigger than 0.
<wgrant> Thanks.
 * infinity blinks at ecj's continued failure on the buildds, despite it now working in his chroot.
<infinity> Grr.
<infinity> Oh.
<infinity> Get:9 http://ports.ubuntu.com/ubuntu-ports/ saucy/universe libisl10 powerpc 0.11.1-2 [445 kB]
<infinity> Get:10 http://ports.ubuntu.com/ubuntu-ports/ saucy/universe libcloog-isl4 powerpc 0.18.0-2 [65.3 kB]
<infinity> That seems a bit suspect.
<infinity> doko: Did you just fix the above while we were talking, or can I safely do it now?
<doko> $ ./change-override -c main -s saucy -S isl
<doko> Override component to main
<doko> isl 0.11.1-2 in saucy: universe/libs -> main
<doko> Override [y|N]? y
<doko> 13 publications overridden.
<infinity> doko: That was in the last 30m? :)
<doko> infinity, no, do it now
<wgrant> infinity: Can you kick boost-defaults out of accepted? It's already published, so that dupe is  oopsing
<wgrant> 2013-04-26 10:04:26 DEBUG   Domination for saucy/Release finished
<wgrant> So the publisher should be happy now
<infinity> wgrant: Punted.
<wgrant> Thanks.
<wgrant> Every time I watch the primary archive publisher, I want to finish NMAF...
<infinity> If you're positive you can get a faster/saner implementation, I want to sort out how to make time for you this cycle to get it done.
<wgrant> My attempt in 2009 was dominated by bzip2 compression time...
<infinity> I heard we're going to move all of launchpad to hyperscale ARM servers to encourage better service parallelisation and code profiling habits.
<wgrant> Heh
<infinity> 2013-04-26 10:07:12 DEBUG   Calculating binary filelist.
<wgrant> infinity: So yeah, it's practical, and I might even get bored on the plane.
<infinity> That... Shouldn't take 5 minutes.
<wgrant> We'd need to add extra override support, bu that's basically trivial
<wgrant> infinity: It can if the cache is cold.
<wgrant> It just finished
<wgrant> Well, 40s ago
<infinity> Yeah, I know.  Just as I pasted that.
<infinity> My timing is impeccable.
<wgrant> Most of LP only works if the cache is hot
<wgrant> Because the schema design is not hot.
<infinity> *smirk*
<wgrant> Thankyou 2005.
<infinity> Thank you, "we can always solve it with more RAM" mentality.
<infinity> Turns out that there's a limit to that.
<wgrant> Well
<wgrant> There actually isn't
<wgrant> That'd be the easiest solution to our problems today :)
<infinity> The limit is when you can't get enough RAM to stuff your DB in it. :P
<wgrant> But our DB's still just under 400GB :)
<wgrant> I think
<wgrant> ez
<infinity> *shudders*
<xnox> clearly we need a distributed shared memory scientific riggs to run launchpad.
<wgrant> New Packages files have Build-Essential!
<wgrant> Not quite done yet, though
<infinity> wgrant: Oh, other curiosity, the publisher is still hanging on to custom uploads for armel in saucy. :/
<infinity> adconrad@pepo:~$ ls /srv/launchpad.net/ubuntu-archive/ubuntu/dists/saucy/main/installer-armel/
<infinity> 20101020ubuntu187  current
<infinity> wgrant: No other armel cruft, just custom uploads (so, in effect, just d-i).
<infinity> wgrant: Easy enough to RM at the filesystem level, but I suspect this means it'll come back AGAIN for t-series?
<wgrant> infinity: The latest d-i image is deliberately copied, I'm pretty sure
<wgrant> Except that's not the latest, is it..
<infinity> wgrant: It's the last that was published for armel, but not the "latest", no.
<xnox> .... we don't have armel any more
<wgrant> Oh, armel, right
<infinity> xnox: Yes, we know. :P
<wgrant> Hmm
<wgrant> Difficult
<wgrant> PUs aren't actually bound to the DAS
<wgrant> So we'd have to exclude based on filename
<wgrant> Can you file a bug?
<infinity> I can.
<infinity> But will I?
<wgrant> This code is completely hideous and I tried to veto it, but it didn't work :(
<infinity> You'd think this would have come up in the past for other dropped arches.
<wgrant> It was written since then
<infinity> Unless this code happened after we dropped sparc.
<infinity> Check.
<wgrant> Custom uploads have only been copied since DDs
<wgrant> And sparc/ia64 were dropped in maverick
<wgrant> Can someone reasonably close to a.u.c try to debootstrap now?
<infinity> wgrant: I will.
<infinity> wgrant: Also, https://bugs.launchpad.net/launchpad/+bug/1173128
<ubot2> Launchpad bug 1173128 in Launchpad itself "Custom uploads get carried over to the next series, even for dead architectures" [Undecided,New]
<wgrant> infinity: Done
<infinity> This debootstrap package list looks more plausibly correct.  We'll see if it completes.
<infinity> Should have done it in RAM, I'd be done by now.
<wgrant> Yeah, that's much happier
<wgrant> Works fine
<infinity> \o/
<infinity> Happy EODing.
<infinity> And see you on Sunday...
<Laney> Indeed. Good stuff.
<wgrant> Hopefully there'll be no more breakage...
<infinity> Jesus, dude.  Don't SAY that.
<infinity> You just lit the DC on fire with your mind.
<xnox> infinity: wgrant didn't, but you did =)
<wgrant> LP needs to be threatened every now and then.
<infinity> *FOOMP*
<infinity> Hrm, the sun came back for yet another lovely day in London.
<infinity> I don't know what the locals complain about, it's alwayd gorgeous when I'm here.
<wgrant> I thought London had banned the sun
<wgrant> Yeah, that
<doko> infinity, gcj-4.8-jre-lib is still in universe, promoting it ...
<infinity> doko: Erm...
<wgrant> infinity, doko: With these missing binaries due to double overrides, that should only happen if two people are overriding them the same way at the very same time, or if you override them one way then override them back in the same publishing cycle
<wgrant> Not just if two people override them the same way 5 minutes apart.
<infinity> wgrant: It's hard to track down exactly who did what when something like this happens, mind you.
<infinity> doko: Oh, it went back to universe when I did the copy-over-itself trick.  Lame.  Your override looks like it'll be happy in the next run, at least.
<doko> ok, good to know
<infinity> https://launchpad.net/ubuntu/saucy/powerpc/gcj-4.8-jre-lib <-- Ugly publishing history and a half.
<wgrant> infinity: Not really. You can see if the two overrides happened within a few seconds of each other
<wgrant> infinity: Those two were created 21 seconds apart, which suggests that the exported API method might not actually be checking if the overrides match before changing them
<wgrant> Except that it does.
<xnox> doko: infinity: can you please accept rocs and ogre ? that would be the zero boost transition iteration.
<doko> done
 * infinity fixes partner harder.
<cjwatson> doko: I've re-enabled most of the archive jobs on lillypilly now
<cjwatson> infinity: Any reason I shouldn't re-enable proposed-migration at this point?  I intentionally stopped it during opening by creating ~/proposed-migration/STOP
<cjwatson> (which is why the bzr branches weren't automatically updated when slangasek looked - the cron job updates itself)
<cjwatson> wgrant: infinity's override did take quite a while, I recall
<cjwatson> wgrant: Could easily have been >21 seconds, so possibly there was overlap
 * cjwatson starts proposed-migration.  Let's see what happens
<infinity> cjwatson: I'm all for it, let's see what explodes. :P
<infinity> cjwatson: (And good morning)
<cjwatson> I just wanted to be around for its first run, really
<cjwatson> Morning.  I'll be off again soon :)
<cjwatson> Hmm.  That did nothing
<cjwatson> Oh, blocks
<infinity> Heh, yeah.
<cjwatson> But suspicious excuses
<infinity> Yay, partner got fixed in the last publisher run.
<cjwatson> Ah, I forgot about symlinks
<cjwatson> Let's move that to code so it's less opaque ...
<infinity> cjwatson: That excuses looks like it's still doing raring...
<infinity> Or am I looking at a stale copy?
<cjwatson> It is, hence my "forgot about symlinks" comment
<cjwatson> lrwxrwxrwx 1 ubuntu-archive ubuntu_archive     6 Oct 22  2012 testing -> raring
<infinity> Check.
<cjwatson> lrwxrwxrwx 1 ubuntu-archive ubuntu_archive    15 Oct 22  2012 unstable -> raring-proposed
<cjwatson> So I'll leave the block in place for another run just for safety
<infinity> That's suspicious anyway, I was fairly sure I removed some of those from raring-proposed.
<infinity> Is lillypilly's mirror stale?
<cjwatson> Shouldn't be but I'll look later
<infinity> Well, if the archive reports cron is disabled, it might not be updating.
<cjwatson> I enabled it
<cjwatson> And it looked like it had got that far at least
<infinity> Weird.  That handbrake definitely isn't in raring-proposed, and hasn't been since yesterday.
<cjwatson> infinity: Oh, no, it's just that britney updated its notion of saucy-proposed but then tried to run against raring-proposed.
<infinity> In fact, none of those 4 packages are.
<infinity> Ahhh.
<cjwatson> So it's OK.
<infinity> doko: ecj has an actual FTBFS on powerpc now.
<doko> infinity, yes, looking
<infinity> doko: leviathan has a saucy chroot if you need it.
<cjwatson> OK, excuses look more correct now
<cjwatson> clearing blocks
<cjwatson> final: base-files,boost-mpi-source1.53,boost1.53,casper,debootstrap,gcc-4.7,gcc-4.8,gcc-4.8-arm64-cross,gcc-4.8-armhf-cross,gcc-4.8-powerpc-cross,gcj-4.8,lightdm,mpclib3,plymouth,ubiquity,xdiagnose
<xnox> lgtm =)
<infinity> Indeed, looks vaguely sane.
<cjwatson> And the copies went to the right place (at least base-files did)
<cjwatson> Right, time for me to vanish again :)  SMS me if that caused the publisher to explode or something
<infinity> Assuming doko's happy with his toolchain, we're probably about ready to thaw, then.
<cjwatson> And you can touch ~ubuntu-archive/proposed-migration/STOP if you need to emergency-halt it
<ScottK> infinity: In terms of the success of the release party, depends on who was there if that's a success or not.
<infinity> I'll let the publisher run a few more cycles before I unfreeze.
<infinity> doko: You happy to unfreeze whenever?
<infinity> cjwatson: ^
 * xnox has 74 .changes files ready for next boost iteration once ogre-1.8 is published.
<xnox> infinity: can't wait to unfreeze =)
<doko> infinity, yes, will build ecj with 4.7 for now, don't have the time to investigate today
<cjwatson> Up to you lot, I'm about 17 hours out of date on most of this
<cjwatson> merges.u.c seems to have updated roughly sanely
<infinity> doko: Alright.  We don't need to wait on ecj to unfreeze though, right?
<doko> sure
<infinity> Kay, I'll give the publisher a cycle or two to settle down with proposed-migration, double-check that the world looks sane, and then unfreeze.
<infinity> doko: Do you have your usual "Archive open, here's the toolchain changes" email drafted up?
<doko> infinity, yes, can do this now
<infinity> doko: Delay it an hour or two, I guess.  But yeah, soon.
<doko> but lets wait with this until the packages migrate from -proposed
<infinity> doko: Yeahp, that was the plan.
<wgrant> cjwatson, infinity: Oh, of course, BPPH.changeOverride will only create a new pub if the new overrides don't match... but it doesn't check that the pub it's being called on is actually the latest.
<wgrant> So I suspect that only raced because the method was called on the old pub
<wgrant> It probably wants to scream if it's not the latest.
<infinity> wgrant: It's not like we get to choose which one we call it against...
<wgrant> infinity: Your API script does
<infinity> Oh, is it actually picking (incorrectly) from a list?  I suspect that's fixable.
<wgrant> No
<wgrant> Well, yes, it picks, but it's correct *at the time*
<infinity> Ahh.
<wgrant> But then it probably prompts "I'm going to change *these ones*! Pls confirm"
<wgrant> Then you wait a few seconds
<wgrant> Press y
<wgrant> And then it changes the overrides on them
<wgrant> In the meantime, a new pub has been created
<wgrant> So you're overriding old ones
<infinity> Yay, races.
<ScottK> xnox: Don't forget to update bzr for your rocs upload.
<xnox> ScottK: i haven't. I'm not generating these hundrets of packages from vcs.... especially if they are not lp:ubuntu/pkg
<xnox> might update a couple, but I don't promise to update every single one though.
<ScottK> xnox: VCS headers are in debian/control for a reason.
<ScottK> Even if you don't pick up un-upload changes to go with your upload (which is fine, IMO) you need to update the VCS after.
<xnox> ... including those that point to stale/out-of-date/wrong VCSs?!
<xnox> ScottK: rocs VCS as pointed in debian/control is out of date. I'm not touching it.
<xnox> missing last raring upload.
<xnox> and we will not be able to fix this until we like reject uploads which have not been tagged & match the contents in the $VCS pointed by lp:ubuntu/* or what's in debian/control.....
<infinity> doko: Fun fun on the version fail.  You might need to do an artificial 4.8.0 -> 4.8.0.0 or something to fix that. :/
<ScottK> xnox: Both bzr and raring have 4:4.10.2-0ubuntu1.  I'm not sure what you mean.
<xnox> ScottK: bzr tags -d lp:~kubuntu-packagers/kubuntu-packaging/rocs | grep 4.10.2
<ScottK> xnox: OK.  It's missing the tag, but the VCS data is up to date.
<ScottK> Fixed, BTW.
 * xnox ponders if I can play "to late now, tags were out of date from the archive when a new upload was done" card
<ScottK> xnox: I think you need to look at the last changelog entry, not just tags.
<ScottK> It's easy enough to forget a tag.
<doko> infinity, time to drop spu, and demote newlib
<infinity> doko: I suppose that's one way to fix the broken versions. :P
<doko> infinity, somebody else should be happy too ... (the one wanting to fix newlib during the last two cycles ;-P )
<infinity> Yeah.  newlib sucks.
<infinity> doko: Don't know how Debian PPC people feel about it (or if they care), but we haven't even pretended to support Cell/PS3 in ages.
<doko> and I did annonuce to drop it for jessie already
<infinity> Ahh, good.  Cool.
<infinity> Then yeah, that's an elegant solution to many problems. :)
<doko> people should use the cross-build infrastructure to build it
<plars> hmm, where does do-release-upgrade pull the release notes from that it displays to the user?
<infinity> plars: Is it getting it wrong?
<plars> it looks like on this system I'm upgrading, it still says "alpha" for raring
<xnox> meta file from somewhere....
<plars> infinity: "This is stiall a ALPHA release. Do not install it on production machines."
<infinity> Possibly unrelated, but it looks like the wiki redirect got buggerd. :/
<xnox> plars: which text of three do you see? http://archive.ubuntu.com/ubuntu/dists/raring/main/dist-upgrader-all/current/
<xnox> I'm guessing Devel, that means meta is pointing to the wrong one.
<plars> xnox: devel, yes
<plars> ahh, hang on
<plars> probably because (by habit) I ran with -d
<xnox> hmm... http://changelogs.ubuntu.com/meta-release seems correct
<infinity> Yeah, -d would do silly things.
<plars> so even if it's released, I guess -d tells it to display the devel one
<infinity> At least, until we point meta-release to spanky for devel.
<plars> heh
<xnox> in other news. The release text in those files is wrong as it mentions "supported from 18 months to 5 years"
<xnox> =))))
 * xnox ponders to do a grep for "18" across *.ubuntu.com
<plars> yes
<plars> xnox: that's just in the EOL one though
<xnox> yeah, low priority.
<plars> xnox: you may want to get *slightly* more restrictive with the search than "18" :)
<xnox> plars: true.... About 569,000 results (0.21 seconds)
<infinity> doko: The diff for that spu-dropping gcc-defaults also bumped gccgo to 4.8, was that intentional?
<apw> am i to be supprised that rmadison does not yet show saucy ?
<infinity> Possibly.
<xnox> apw: i'd say impatient.
<apw> xnox, heh, but you are always the optimist :)
<apw> lack of beer i suspect
<xnox> apw: guess what I am on, if I don't drink beer. ;-)
<xnox> apw: to be honest that beer / you are weird joke is getting rather old now and not-funny at all.
 * infinity adds it.
<apw> xnox, soz, i am having an offend everyone day it seems
<xnox> apw: that's ok, no worries.
<infinity> apw: All fixed.
<apw> infinity, taz
<xnox> Laney: infinity: transition tracker seems to be activated & running, but it's still raring and not saucy.
 * infinity wonders where that runs from...
<xnox> infinity: an interesting lucid schroot on people.canonical.com by ubuntu-archive user, or something of some-such.
<Laney> let me look
<infinity> Yeah, I just got there.
<doko> infinity, looks ok to me, I can still use this with go build -compiler gccgo
<Laney> conflicts: Text conflict in ubuntu/download/archive.ben Text conflict in ubuntu/download/archive_ports.ben
<Laney> YOU WHAT
<infinity> I take it Laney's on the case. :P
<Laney> punching it in the guts right now
<infinity> Which is good, cause I've failed to find a config file.
<infinity> Oh.
<infinity> (lucid-transitions)I have no name!@lillypilly:/srv/transitions/transition-tracker$ grep raring go
<infinity> SERIES=raring
<infinity> I suspect that would be it.
<Laney> ya
<infinity> I'll leave it to you.
<Laney> let me see what this conflict is about too
<infinity> I've dealt with enough variations of voodoo today.
 * Laney briefly ponders getting distro-info in lucid
<xnox> Laney: yes, please.
<Laney> xnox: is that better?
<xnox> Laney: yes, thanks a lot.
<xnox> Laney: it's fiddly to setup locally inspection of both release & -proposed pockets.
<rustx> rbasak: hi robby
<rustx> rbasak: i've just  replied to the bug here : https://bugs.launchpad.net/ubuntu/+source/facter/+bug/1170325
<ubot2> Launchpad bug 1170325 in facter (Ubuntu) "Facter 1.6.X not considering Qemu/KVM virtual type" [Undecided,New]
<Laney> sure
<rustx> rbasak: if you need any more information, i remain at your disposal
<doko> infinity, what does the kdepim-dev/boost excuse mean?
<doko> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<doko> xnox, ^^^
<infinity> doko: It means that updating boost-defaults makes kdepim-dev uninstallable.
<doko> but why ...
<doko> dpends only on libboost1.49-dev, libboost-graph1.49-dev
<infinity> Yep.
<infinity> http://paste.ubuntu.com/5604825/
<infinity> kdepim-dev needs transitioning before boost-defaults can migrate.
<xnox> infinity: are you unfreezing saucy, or shall I upload 74 packages and you will accept them?
<doko> xnox, ^^^go on with the tranistion. ogra did migrate
<xnox> and / or doko will accept them?! =)
<doko> or ogre ... what's the difference ;p
<doko> xnox, just upload
<xnox> ack.
<infinity> xnox: I'm unfreezing once gcc-defaults migrates, but it's not hard for us to accept either.
 * xnox ponders if queuebot and launchpad api will get overwhelmed with saucy at :40 ;-)
<ogra_> doko, the difference is the smell of onions !
<xnox> ogra_: and the other one is 3D as well
<ogra_> heh
<infinity> xnox: Are you implying that ogra only exists in two dimensions?
 * ogra_ feels pretty flat at times
<xnox> ... or that ogre actually only ever shows 2D projections
<doko> ogra_, ok, then I'm happy that our room sharing was undone next week ;-P
<ogra_> doko, heh
<bdmurray> ScottK: the description of bug 831768 had some information regarding letting it wait more than 7 days so it could get more testing...
<ubot2> Launchpad bug 831768 in aptitude (Ubuntu Oneiric) "aptitude cannot handle conflicts with multiarch enabled" [High,Confirmed] https://launchpad.net/bugs/831768
<ScottK> bdmurray: Sigh.  I missed that.
<xnox> ScottK: bdmurray and now your conversation will be forever flooded with uploads.
<infinity> xnox: Erm, are most of these no-change rebuilds?
<infinity> xnox: If so, the versions seem a bit suspect.
<xnox> infinity: yes, but all of them actually have binary depends.... Hmm.....
<stgraber> mute queue saucy-proposed
<xnox> infinity: good point, I may have used "-i" instead of rebuild one.
<xnox> stgraber: thanks.
<xnox> infinity: reject all and let me try again?
<infinity> xnox: Dependencies have nothing to do with it.  If they're rebuilds, all these 1.2.3-1 -> 1.2.3-1ubuntu1 versions should be 1.2.3-1build1
<doko> infinity, hmm, wait with accepting ...
 * xnox goes to check my scripts.
<infinity> xnox: Yeah, I'll just reject the whole queue, since it's all you. :P
<infinity> xnox: You want dch -R
<ScottK> Some of them probably have version specific boost depends and won't be a rebuild, but I bet most of them are.
<xnox> ScottK: I also sed through control ;-)
<infinity> Then if you sed through control, those need -i instead of -R.
<xnox> true.
<infinity> But do be careful on that, we don't want to stop syncs from happening for the ones that aren't changed.
<xnox> let me check debdiffs.
<infinity> It's a pain to deal with later.
<xnox> infinity: reject the whole lot, and let me go through these again.
<infinity> Working on it.  Making sure no one uploaded something in the middle of your spw.
<infinity> spew*
<infinity> xnox: Would be nice if the changelogs were clean on "No-change rebuild for XXX transition" or "Mangled debian/control for XXX transition" too.
<xnox> infinity: ack.
<doko> infinity, I'm doing another gcc-4.8 upload
<infinity> doko: One we want to wait on?
<doko> infinity, yes, I think so. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57003
<ubot2> gcc.gnu.org bug 57003 in rtl-optimization "[4.8/4.9 Regression] gcc-4.8.0 breaks -O2 optimization with Wine(64) - links/info/bisect of commits included" [Normal,Resolved: fixed]
<infinity> doko: Ick.  Well, I guess that lets you turn off spu in the process.  And give xnox time to do better changelogs. :P
<doko> spu already done
<infinity> Oh?  I thought you only did it in -defaults, not in GCC itself.
<doko> infinity, can we force demoting gcc-4.4 please?
<infinity> doko: mysql is still building with it.
<infinity> doko: If we can switch that without the testsuite regressing, you win.
<doko> infinity, waiting on getting this resolved didn't help  ...
<doko> or I'm uploading a gcc-4.4 which just builds gcc-4.4-base ...
<infinity> ...
<infinity> Dude, we support mysql-5.5, rather a lot.
<infinity> I'm not sure how breaking it will force anything.
<doko> so apparently it's unsupported. lets talk next week
 * xnox shakes fist at "libboost-dev | libboost1.49-dev"
<infinity> doko: I'm going to give it a test spin with 4.8 here and see how that goes.
<infinity> doko: Maybe the world has improved.
<doko> infinity, you misunderstand.
<doko> this is buggy asm inline code
<infinity> doko: buggy inline ASM that previously worked.
<infinity> doko: Anyhow, maybe upstream did something to it, or gcc now mangles it differently.  I don't think it's been checked since SpamapS last changed the build-dep.
<doko> infinity, in 4.4 ... yes, so what makes you confident that this will get addressed?
<doko> and *nobody* besides debian is using this code
<doko> well, us
<infinity> doko: Nothing makes me confident that it'll get fixed.  I'm just saying that we can't stop supporting it either, so we need to fix it, not break it.
<doko> mariadb ...
<infinity> doko: You're welcome to abuse Daviey. :)
<infinity> doko: mariadb must have the same code... Maybe there's a patch there?
<infinity> (Or it's broken the same way)
<infinity> Project renames don't magically fix bugs.
<SpamapS> my opinion, btw, is to disable the inline ASM
<infinity> SpamapS: There's a way to do that without sadness?  It's been a long time since we talked about this...
<SpamapS> rbasak actually reported it as a bug in Debian, which I ack'd
<infinity> SpamapS: Was it just a question of ending up with slower C routines?
<SpamapS> infinity: there are several ways.
<dobey> infinity: hey! did you get a chance to poke at rhythmbox-ubuntuone SRUs btw?
<SpamapS> infinity: yes, though I believe in newer yassl's, the inline asm has been fixed
<infinity> SpamapS: But, if you have a workaround, please go for it.
<infinity> SpamapS: Or, fix the ASM with a cherrypick? :P
<dobey> infinity: btw are you in UK/EU this week?
<SpamapS> infinity: so one way to handle it is to use newer yassl. Another is to just accept the 10% slow down.
<rtg> infinity, are y'all ready for a 3.9 saucy kernel ?
<doko> rtg, kernel headers would be nice, yes
<SpamapS> infinity: I think the right thing to do is to drop the build-dep, and disable the inline ASM for now. Ihave a TODO to get Debian and Ubuntu mysql in sync once Debian un-freezes.
<rtg> doko, ok, gimme a bit
<infinity> SpamapS: Alright, cool.  If you're going to be fixing this and dropping the dep, that's good enough for me (and doko).
<doko> SpamapS, \o/
<infinity> SpamapS: As long as it happens SoonTM.
<infinity> SpamapS: (Like, weeks soon, not days soon, I don't think anyone's panicking to drop gcc-4.4 TODAY, just to make sure it's gone this cycle)
<SpamapS> infinity: right, lets target a1?
<doko> infinity, rtg: and I'd like to demote 4.7 as well. not now, but after the next glibc and linux upstream versions are in the archive
<infinity> doko: Should be doable.  I'll do some eglibc PPA tests against 4.8
<infinity> SpamapS: Meh, just target "really soon".  Ubuntu doesn't do alphas, but you can target month-1, if you like to have a TODO list.
<infinity> SpamapS: I'm sure doko will bug you again if you forget about it. ;)
<SpamapS> infinity: ok, a1 was really "target a time where somebody in charge of release management will bug me if I forget"
<infinity> SpamapS: Heh.  doko will bug me, and I'll bug you.  It'll be great.
<doko> indirect spanking
<infinity> SpamapS: (or, you could upload the quick "disable asm" hack to Ubuntu now, and then fix it less crappily in Debian and sync/merge at your leisure)
<SpamapS> infinity: indeed I think thats probably the way to go.
<infinity> doko, slangasek, cjwatson: Let's avoid touching component-mismatches while toolchain/boost transitions shake out a bit.
<xnox> infinity: in the mean time, where shall I upload boost transition? just keep in on my machine or upload into ppa and then do a source copy?
<xnox> once gcc4.8 builds & publishes.
<doko> sure, looks fine
<doko> xnox, upload them now. they can wait in the queue
<infinity> Except people might accept them.  Are we concerned about that gcc bug being a problem?
 * xnox ponders to artificially tweak .dsc to depend on the pending gcc-4.8, to just let the packages into dep-wait state on gcc-4.8 ;-)
<doko> well, misoptimized memcpy ... otoh it didn't show up in gcc itself
<doko> xnox, yes, that's what I'm actually doing in such cases ...
<infinity> xnox: Not an awful idea, actually.  And simple enough.
<infinity> gcc-4.8 >= 4.8.0-4ubuntu2
 * xnox goes to add it to my scripts ;-)
<xnox> cause i want these built, while I sleep / on the plane.
<rtg> infinity, linux_3.9.0-0.1 is in the pipe. Shall I wait on linux-meta until after we're sure headers and everything are good ?
<infinity> rtg: Meh, just throw it all at the archive, we'll avoid accepting it for a little while anyway.
<rtg> ack
<SpamapS> $ bzr branch ubuntu:mysql-5.5
<SpamapS> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/+branch/ubuntu/mysql-5.5/"
<SpamapS> huh?
<doko> rtg, heh, you only see something with the headers once you start building with it ...
<xnox> SpamapS: we did distro-branch but didn't import saucy yet. Use bzr branch lp:ubuntu/raring/mysql-5.5 for now.
 * xnox goes to check if it's safe to start package importer.
<SpamapS> xnox: *ah* ok that makes sense
<apw> rtg, did you prep linux-signed for saucy as well ?
<stgraber> win 77
<stgraber> gah
<rtg> apw, all 3 packages are uploaded
<apw> rtg, great thanks
<rtg> let the carnage begin....
<rbasak> SpamapS, doko, infinity: note that we *assume* that the C code is slower. I haven't seen any evidence that the assembly actually speeds things up when pitted against a more recent gcc.
<SpamapS> rbasak: I tested it
<rbasak> So I think it makes complete sense to drop the assembly and use the C until/unless upstream fix it.
<SpamapS> rbasak: it was slower.
<rbasak> Ah, OK. Fair enough.
<SpamapS> rbasak: by about 10%
<Daviey> SpamapS: how did you benchmark ?
<SpamapS> as I said, I believe they have fixed it in newer yassl
<SpamapS> Daviey: 10000 MySQL connections
<rbasak> SpamapS: I wonder if updating the entire extra/yassl directory to the latest upstream yassl breaks anything?
<SpamapS> I can dig out the results.. its been a while now
<SpamapS> rbasak: it does not break anything, I have tested that
<rbasak> SpamapS: could that be a cost of connection setup, then, rather than normal use? Who actually uses 10000 MySQL connections in the real world?
<SpamapS> the yassl guys are actually really awesome and care a lot about API stability and high performance / low cost
<SpamapS> rbasak: *everyone*
<Daviey> rbasak: So many crappy php applications have poor connection reuse
<rbasak> Oh, OK then.
<SpamapS> And specifically, 10000 iterations of connect, do a big giant select, disconnect.
<SpamapS> I tested w/o SSL as well for a control
 * SpamapS is so bad about keeping these things around :-P
<SpamapS> anyway, we're talking about a tiny subset.. i386 mysql servers.
<SpamapS> that need SSL..
<rbasak> So I guess the question is whether Debian or Ubuntu are willing to carry that patch? I think we want to shrink Ubuntu's MySQL delta if we can rather than grow it, given MySQL's closed development and the existence of MariaDB and Percona etc. I'd rather that we spent the time on them if we're going to introduce deltas.
<doko> rbasak, that's not the only thing to consider. we'll drop gcc-4.4 in ubuntu with this patch. this is more than enough
<Daviey> My care for 386 is small. :)
<rbasak> Daviey: yeah but Debian's is bigger, and I don't want Ubuntu to maintain a delta. I'm concerned that it'll get neglected.
<vibhav> When, during the UDS, is the toolchain for the next release discussed? (Assuming such a discussion takes place)
<doko> vibhav, there's a blueprint
<infinity> rbasak: This wasn't about deltas, SpamapS is going to fix it in Debian.
<infinity> vibhav: It's usually more "decided" than "discussed", though we sometimes debate a bit about deadlines for getting things in.
<vibhav> doko: Could you link me to the blueprint?
<vibhav> ah
<vibhav> Yes, the toolchain is rather decided
<vibhav> I presume we would be using gcc 4.8.0 for this cycle, wont we?
<infinity> Yes.  Already in the archive.
<vibhav> \o/
<vibhav> thanks infinity
<doko> Daviey, did I miss your blueprint to drop i386?
<Daviey> doko: no
<xnox> doko: Ubuntu Server for quantal and up only released i386 install media.
<xnox> s/i386/amd64/
<xnox> Daviey: how much do you care about x32 ?
<SpamapS> rbasak: I think we'll just live with a bad i386 ssl in MySQL.
<Daviey> xnox: Right, but the archive is still reasonable
<SpamapS> and by bad I mean 10% slower.. not exactly the end of the world. :-P
<Daviey> xnox: My interest in 32 bit is pretty small. But i'm not pushing for it to be discontinued
<rbasak> SpamapS: OK, thanks. At least until upstream fix it :)
<infinity> SpamapS: Surely, a full upstream pull of yassl is overkill, there must be one upstream commit or something that fixes the bug.
<SpamapS> rbasak: don't hold your breath, its been open for 18 months now.
<rbasak> infinity: I couldn't find an available upstream VCS when I looked.
<SpamapS> infinity: the only reason we have to do that is the ridiculous embedding. Part of my grand plan is to have yassl be its own library.
<SpamapS> infinity: gearmand is about to start linking to yassl, so Debian will have two consumers.
<infinity> Ahh, ick.  Yeah, linking that dynamically will lead to less sad security teams.
<SpamapS> Right.
<SpamapS> and we'll get to use the latest yassl, because they're a good library, and don't break backward compatibility.
<Daviey> asm makes me cry.  It's impossible to do a reasonable audit without wanting to kll yourself
<ScottK> BTW, there are plenty of desktop users of mysql, so it's not just a server thing.
<ScottK> (SSL may be though)
<infinity> Daviey: That's how I feel about python. :P
<Daviey> infinity: pah! :)
<ScottK> infinity: Be nice.  You'll make barry cry.
<antarus> infinity: bleh
<Daviey> infinity: You are confident you could audit malicious asm shellcode embedded in something?
<xnox> infinity: are you about for a second review of the batch with corrected version numbers, changelog, and mangled .dsc with gcc-4.8 build-dep ? not two linux packages are in the queue. Turns out none of the packages need s/1.49/1.53/ mangling as all of them use defaults-dev (sometimes defaults-dev | 1.49-dev)
<infinity> Daviey: Depends on the machine, not all asm is created equal.
<Daviey> infinity: true
<xnox> s/not/no/
<antarus> Daviey: I don't think his point was that asm was *good*
<infinity> xnox: Sure, I'll have a glance when I get back to the hotel.  Don't feel like being in the office all night again.
<xnox> infinity: ack. will upload in a sec.
<antarus> dynamic languages like python let you do colossally stupid things
<antarus> like the C preprocessor ;p
<rbasak> All Turing compelte languages let you do colossally stupid things :)
<xnox> rbasak: any language let you do colossally stupid things =)
 * rbasak invents a language with only one command that takes no parameters: "exit"
<xnox> vowpal-wabbit.updated.changes -> inappropriate changesfile name, OMG!
<dobey> everything that gets accepted to raring-proposed will end up in saucy right now?
<xnox> dobey: NO!
<xnox> dobey: anything accepted to raring-proposed will end up in raring-proposed => heading for SRU.
<xnox> dobey: saucy already has different compiler and boost1.53 api. and kernel.
<xnox> dobey: one should do an upload to saucy _first_ and then to raring-proposed.
<dobey> xnox: right, but at least in the past there has been a period of time when updates to the just-released ubuntu will get copied into the new development version as well
<xnox> dobey: all 0day sru's and raring-proposed carry over, has already been carried over.
<xnox> that was done yesterday.
<dobey> i'd rather not have to create separate uploads for this :-/
<dobey> but i don't know if the fix is totally correct yet or not, and Laney has presumably already left
<dobey> hopefully not missing his flight if he's going to the sprint
<xnox> AAs: please reject clamav, cups, casper, maas from raring-proposed unapproved queue. All of them trying to upload a higher than saucy version number into raring without using SRU version number.
<xnox> (SRU team?!)
<xnox> glib-networking already has matching upload in saucy and correct SRU version in raring-proposed unapproved queue.
<xnox> dobey: upload to saucy with normal version number. Bugs should be fixed in saucy first!
 * xnox or laney or anyone else can do sru version upload for you later.
<xnox> or it will simply wait.
<dobey> xnox: well it's a bug that doesn't really affect saucy, as it only happens on upgrade from quantal -> raring
<xnox> dobey: bug # ?
<ScottK> I self rejected clamav.  I meant that for saucy.
<dobey> xnox: bug #1173249
<ubot2> Launchpad bug 1173249 in software-center (Ubuntu Raring) "update-software-center AttributeError during upgrade from 12.10 to 13.04" [Critical,Triaged] https://launchpad.net/bugs/1173249
<dobey> i guess i should mark it invalid for saucy though
<xnox> dobey: i think it still should be in saucy, as at one point we were considering quantal -> lts upgrades. Also wouldn't it affect precise -> next-LTS upgrades?
<xnox> dobey: and regradless it's friday, so there is no difference in uploading today vs on monday.
<dobey> well, it doesn't change the fact that in the past, i have uploaded packages to release-proposed to do updates, and was able to just have them copied over to development series, within the first few weeks after a release. i don't recall any new policy to disallow that being declared (but if there was, please refersh my memory with a URL) :)
<stgraber> xnox: are you done flooding the saucy?
<stgraber> unmute queue saucy-proposed
<ScottK> xnox: I fixed clamav.
<xnox> stgraber: yes.
<xnox> ScottK: thanks.
<ScottK> That was just my fingers typing raring while my brain was saying saucy.
<xnox> stgraber: want to redirect casper upload to saucy?
<stgraber> xnox: didn't I copy it already?
<stgraber> ah no, looks like I only copied the one from -updates not the one that was in -proposed
<xnox> stgraber: nope, there is 1.332 in raring-proposed unapproved. which is higher than salamaner
<xnox> salamander.
<stgraber> xnox: right. I'll wait for that one to be at least approved in raring-proposed then will do a binary copy to saucy
<xnox> stgraber: but it's not using sru style version number. But I guess you can blag it that it actually is ;-)
<ScottK> xnox: It's usual for us to forward copy stuff until the archive is open for uploads.
<ScottK> xnox: There's no requirement for a particular style of version numbers for SRU.
<xnox> ScottK: which is bad encouragement.
<stgraber> xnox: well, to be fair at the time I uploaded it, it wasn't clear whether it'd be an SRU or not ;)
<xnox> stgraber: sure.
<ScottK> I think it's better to announce a change in the way we do things rather than just rejecting stuff.
<stgraber> ScottK: btw, if you've got a sec, it'd be great if you could let casper into raring-proposed. I'd like that one fixed ASAP so that anyone building a derivated distro picks it up and avoids the bug.
<xnox> ScottK: if not gcc bug, we would be open now. And I don't want what happened in raring where 2 months later (which is ~6 weeks after archive open) on my raring system I saw uploads in quantal-proposed & quantal-updates >> than raring
<ScottK> stgraber: Sure.
<ScottK> infinity: I think xnox is volunteering to join the SRU team.
<stgraber> xnox: don't worry, I've got a script for that and I monitor + copy-package when I spot one
<stgraber> though I usually only care once the package hits -updates
<xnox> ScottK: I volunteer to be AA and only remove packages =)
<ScottK> No, that's StevenK's job.
<ScottK> stgraber: Need a test case.  You can add that while it's building.
<stgraber> ScottK: ah yeah, true, didn't do the SRU paperwork back then :) will do in a sec
<ScottK> Thanks
<ScottK> xnox: I'll forward copy that one after it's built/published.
<xnox> I'd even would like to get security team to do saucy first and/or together with -security if the version numbers still match.
<stgraber> ScottK: there you go
<ScottK> Thanks.
<ScottK> xnox: They usually do.
<infinity> xnox: You might want to avoid making policy that other people enforce. :)
<infinity> xnox: It's pretty routine for 0-day SRUs to get copied over, rather than force two identical uploads.
<infinity> xnox: Now, this doesn't go on forever, but you were demanding we reject things that were uploaded before raring released.  Trust me, if I had planned on doing so, I would have done so then.
<xnox> infinity: sure. but it's day 1 now =) the stuff that is in unapproved queue already is fair game and the rest of packages there have SRU template complete.
<infinity> (We also have scripts to check if release-1-updates is >> release)
<xnox> infinity: dobey wanted to upload something today as if it was 0-day SRU (which may still be possible, if in fact we do not need that patch in saucy but it feels like if it's needed for quantal -> raring upgrade we do want it in saucy)
<infinity> xnox: If he uploads it to raring, we want it in saucy too, yes.  And we'll copy it.
<stgraber> I don't see what annoying people who worked hard during release week preparing SRUs gets us. The backlog of pre-release SRU uploads should just get processed as usual and then be copied to saucy once built, which AFAICT has been done by the SRU team (or me with the mass copy I did yesterday)
<infinity> xnox: In short, please don't flip out about nothing, this is business as usual.
<infinity> stgraber: Indeed, I did some yesterday too.
<xnox> hmm...... it's just in raring cycle release-1-updates was << release, but that patch was not actually part of release. ( one person did -1-updates while the other did release) and it took a few months to get noticed.
<xnox> that was with lvm2 package.
<stgraber> oh and I really need to poke cjwatson and infinity during the sprint about that whole becoming an AA and SRU team member thing
<infinity> xnox: That's unfortunate, but not solved by this.
<xnox> not sure how that slipped all the fancy reports you say exist and you are teaching me about.
<infinity> xnox: Reports don't look at the contents of packages.
<xnox> i think a third party noticed and opened the task against $release and that's how eventually we noticed this.
<infinity> xnox: Anyhow.  I'm not here to argue.  Just calm down.
<slangasek> infinity: so do you want me to prepare separate uploads for this hdparm SRU I was about to do? :)
<infinity> xnox: Yes, SRU patches can get lost in release+1 when someone does a merge or something and skips that revision.  That's not new.
<xnox> infinity: also very true =)
<xnox> anywho I have now boost1.53 build failures to attend to and/or pack =)
<infinity> slangasek: Couldn't care less, tbh.
<slangasek> xnox: I wouldn't really advise packing the boost1.53 build failures; they could push your luggage over the weight limit
<infinity> (Yes, we should move to the "fix it in both releases independently" thing soon, both to get new toolchain good/badness, and to make sure we're not stomping all over ourselves with merges, but in the first few days after release when all is calm, I really don't much care, and I'm all for a bit of slack)
<infinity> I'd rather be having a beer than uploading everything twice today. :P
<xnox> i guess something lightweight like opening a saucy task should be enough on those to "copy over once build OR notice that it got stomped over and do a separate upload"
<xnox> =))))
 * xnox forgets about sloppy SRUs , boost1.53 FTBFS, packing and goes to drink tea!
<infinity> Shouldn't need a saucy task, the generic task won't be closed by an SRU (assuming there is a generic task).
<phillw> infinity: just as total "by the way", is there any planned date for the first makes of the likes of lubuntu to arrive on the daily images?
<ScottK> "next week"
<infinity> phillw: We'll turn dailies on again over the weekend or early next week.
<infinity> phillw: No schedule day for flipping the switch, but "soon".
<infinity> phillw: Right now, they're be nearly identical to raring anyway, so not much excitement there. :P
<infinity> s/they're/they'd/
<phillw> ScottK: infinity thanks :) You know how keen our l-QA testers are :D
<dobey> can someone sponsor the debdiff on bug #1173249 into raring-proposed please? since i don't have upload privs to pygobject
<ubot2> Launchpad bug 1173249 in software-center (Ubuntu Raring) "update-software-center AttributeError during upgrade from 12.10 to 13.04" [Critical,Triaged] https://launchpad.net/bugs/1173249
<ScottK> dobey: I'd try -devel.  There's nothing release specific about a sponsoring request and there are more people there.
<dobey> i guess it's just not a great time for requesting such a thing, regardless of where the request is made.
<ScottK> No
 * cjwatson uploads ghc - might as well get that in place along with the rest of the toolchain
<Laney> seriously?
<cjwatson> why not?
<cjwatson> (you have 80MB worth of upload time to persuade me to C-c :-) )
<Laney> http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/release-7-6-3.html doesn't change very much
<Laney> There will probably be a more featureful upstream release that will be more worth the effort
<cjwatson> I guess ...
<antarus> cjwatson: you can move to austin, TX, they are getting google fiber ;p
<cjwatson> Wish we had binNMUs, then it wouldn't be so annoying
<Laney> well, this transition should be entirely no-change
<cjwatson> antarus: I will live in the US some time after hell freezes over
<cjwatson> Laney: OK, ctrl-c'ed
<Laney> merci
<dobey> cjwatson: given the rate of ice cap melting, we're not too far from that ;)
<Laney> yeah, we can help it along with ghc transitions too :P
<Laney> ref. https://buildd.debian.org/~nomeata/graphs.cgi
<dobey> heh
<dobey> Laney: i don't have upload privs to pygobject btw. attached a debdiff to the bug, if you have a minute to upload it :)
<Laney> dobey: I'm a beer or two down - feels like a dubious proposition to me
<Laney> tomorrow on my travels though, no probs
<dobey> heh
<ScottK> antarus: Kansas City has Google Fiber.  It gets pretty cold in the winter there.   Maybe he'd go for that.
<cjwatson> It's not the *temperature* I object to :)
<ogra_> the fiber ?
<ogra_> you're such a copper guy
<dobey> i definitely like my fiber
<dobey> even if it's not gigabit yet
 * ScottK <--- too (FIOS, not Google, but it'll do)
<slangasek> Riddell, ScottK: hey, so there are an awful lot of kubuntu-specific plymouth bugs coming in for raring; I don't know of any reason there would be kubuntu-specific plymouth problems though, and I can't reproduce them either in a VM or on real hardware by installing the kubuntu theme on an existing Ubuntu system.  Is there someone who could take a look at these and figure out what's going on?
<ScottK> apachelogger would be the appropriate victim.
<slangasek> ok
<slangasek> apachelogger: ping, re: plymouth+kubuntu
<ScottK> he's not online though.
<ScottK> There are some issues that only happen on fresh install, not upgrades, so it wouldn't surprise me if a system that already had Ubuntu on it would be different.
#ubuntu-release 2013-04-27
<slangasek> ScottK: ah - for some reason, Kubuntu 13.04 installs with 'splash' not set on the kernel commandline :/
<slangasek> ScottK: neither 'splash' nor 'quiet'
<ScottK> slangasek: I assume that's bad.
<slangasek> well, it's rather difficult to correct now that the release is out
<slangasek> and it was reported in ISO testing... but the bug got filed against plymouth and I only had a chance to look at it now :/
<ScottK> We can add it to the release notes.
 * slangasek nods
<slangasek> strangely, this is only one of three kubuntu-specific plymouth bugs that came in, all of them different
<slangasek> (bug #1171099)
<ubot2> Launchpad bug 1171099 in ubiquity (Ubuntu) "kubuntu - plymouth not shown" [High,Confirmed] https://launchpad.net/bugs/1171099
<ScottK> Could you add some suitable text to the bug and give me a ping so I can make sure things are all updated?
<slangasek> on the way out to dinner now; I can try to add something later
<ScottK> Thanks.
<SpamapS> \
<cjwatson> infinity: What's blocking opening at this point?
<cjwatson> I saw mention of a GCC bug in scrollback, though I couldn't find details; but there's been a gcc-4.8 upload since then
<ScottK> I think that was it.
<ScottK> Might be nice to sort component mismatches a bit first.
<cjwatson> Mm.  Some of that is probably backed up on the boost transition finishing migrating.  But I think I'll let people with a firmer grasp of the saucy toolchain changes sort it out ...
 * ScottK looks again
<cjwatson> Is somebody sorting out kdepim, which is blocking boost-defaults?
<ScottK> No.  To sort kdepim you end up having to sort all the KDE packages that use boost together.
<ScottK> It's on xnox's list, so I'm leaving it to him.
<ScottK> BTW, the boost-mpi-foo demotions are definitely correct.
<ScottK> They should never have been in Main.
<ScottK> He's got the whole thing scripted, so I don't want to step into the middle of it.
<ScottK> I can fix up the obvious boost ones.
<ScottK> The boost override changes I know are correct, are done.
<ScottK> I wouldn't mess with the rest of the 1.53 demotions until the transition is done.
<ScottK> As long as the first autosync doesn't happen before the next publisher run is finished, I think we're good.
<cjwatson> OK.  I'm not going to do it now anyway since I'm about to be travelling
<cjwatson> Happy to sort it out tomorrow once I'm in .ca.us if everything else is done by then, or else there's an obvious crontab line that anyone with access to ubuntu-archive@lillypilly can uncomment
<cjwatson> (env setup + auto-sync --batch)
<infinity> cjwatson: GCC is what we were waiting on, yes.  I'll open it this morning when doko send his "We're open for devel, here's how the new toolchain sucks and/or is awesome" mail.
<infinity> s/send/send/
<infinity> s/send/sends/
<infinity> Typing hard.  Need breakfast.
<stgraber> oh wow, the Swiss lounge in Zurich upgraded their Internet! last time I barely had 5Mbps, this time I'm getting a nice symmetric 75Mbps, now to find some unreasonably large package to upload ;)
<stgraber> infinity, cjwatson: Now that we have the name of the release I think the topic deserves some updating ;) (can't do it, apparently I don't have the required ACL for this channel)
<iulian> Why don't we just -t it?
<stgraber> that works too
* infinity changed the topic of #ubuntu-release to: Ubuntu 13.04 and 12.04.2 released | Archive: frozen | Saucy Salamander Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or beer | melior malum quod cognoscis
 * infinity looks suspiciously at his d-i build failures.
<Noskcaj> does anyone know why there are no testcases for saucy on the iso tracker? sorry to ask on two channels but i'm not sure which it should go on
<infinity> Oh, I forgot to set the default suite.  Oops.
<slangasek> ScottK: release notes suggestion added to bug #1171099.
<ubot2> Launchpad bug 1171099 in ubiquity (Ubuntu) "kubuntu - plymouth not shown" [High,Confirmed] https://launchpad.net/bugs/1171099
#ubuntu-release 2013-04-28
<ScottK> slangasek: Thanks.
<JoseeAntonioR> hey guys, I'd like to know, is Adam the release manager now? just so I can cite it that way on the UWN
<slangasek> JoseeAntonioR: there is no release manager; Adam is a member of the release team
<JoseeAntonioR> slangasek: great, thanks!
 * vibhav patiently waits for the archive to open
* infinity changed the topic of #ubuntu-release to: Ubuntu 13.04 and 12.04.2 released | Archive: open | Saucy Salamander Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or beer | melior malum quod cognoscis
<smartboyhw> \o/ Thanks infinity:)
<vibhav> Archive open \o/
 * cjwatson enables the auto-sync cron job
<ScottK> So it seems there's a bit of a ping pong possible on c-m.  I get the impression it's looking in -proposed and noticing something can be demoted without making sure it can be demoted in -release too.
<ScottK> So you demote stuff and then it wants to be promoted right away because of stuff in -release.
<cjwatson> c-m doesn't look in -proposed at all in its default configuration.
<cjwatson> Though http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt exists.
<cjwatson> BTW, I've removed the alpha warning code from ubiquity as we discussed pre-release.
<ScottK> OK.  Then I don't know why boost1.49 keeps showing up as downgradeable and then after moving to universe it immediately wants back in main.
<ScottK> Thanks
<cjwatson> I'll have a look at debugging that when I'm a bit less jetlagged, I guess ...
<ScottK> Great.
<cjwatson> Maybe breakfast and heroic amounts of coffee will help.
 * ScottK has to remember "heroic amounts of coffee".
<ScottK> I've read about studies that purport to show you burn more calories when exhausted, so breakfast is probably good.
<ScottK> stgraber: ^^^ the opendkim version comparison is wrong there.  It's looking at backports for the "from" version number and it shouldn't.
<ScottK> debfx: ^^^ you're official.
<debfx> thanks ScottK :)
<ScottK> debfx: Thanks for volunteering to help.
<ScottK> Also thanks for cjwatson's queue management changes in LP that allow you to get +queue access just for backports.
<cjwatson> yw :)
<cjwatson> you may or may not wish to use the 'queue' tool in lp:ubuntu-archive-tools instead
<cjwatson> (or as well)
<ScottK> debfx: ^^^
 * micahg should probably try that at least once
<debfx> now we only need to convince infinity to fix that backports can't build-depend on backports bug
<ScottK> debfx: I'm not sure it's still actually a problem.
<debfx> oh, it isn't?
<ScottK> https://launchpad.net/ubuntu/+source/opendmarc/1.1.3-1~ubuntu12.04.1
<ScottK> Although that one may have worked only because opendkim-tools doesn't exist in the release pocket
<micahg> ScottK: right, you can build-depend on something newer in backport
<micahg> *backports
<ScottK> Then what doesn't work?
<micahg> sorry, can't
<micahg> *can't build-depend
<ScottK> opendmarc does build-dep on opendkim-tools which is only in precise-backports.
<debfx> I'll retry the package that led me to file that bug
<micahg> something newer
<ScottK> OK, so it's an exists in insufficient version problem?
<micahg> the issue is pinning, backports is pinned and the LP sbuild doesn't do version checking
<ScottK> OK, so my case doesn't answer the question.
<debfx> yes, still doesn't work
<ScottK> OK.
 * cjwatson waits for auto-sync to finish ...
<cjwatson> Up to libpano13 ... come on, bored now
<ScottK> cjwatson: I just got an accepter mail for authres migration to the release pocket.  It was auto synched so I found that surprising. Is that expected?
<ScottK> r/d
<stgraber> ScottK: yeah, it's a known problem of queuebot but I've never taken the time to add the necessary logic to deal with backports
<stgraber> currently it's just looking for the highest version in the archive. Which tends to be correct unless that source is in -backports and the source that was uploaded isn't
<cjwatson> ScottK: Not sure
<cjwatson> ScottK: I doubt auto-syncing is specifically relevant
#ubuntu-release 2014-04-21
<bluesabre> Greetings release team, we have a bug fix SRU here: https://bugs.launchpad.net/ubuntu/+source/parole/+bug/1309951
<ubot2> Launchpad bug 1309951 in parole (Ubuntu) "Parole reports "Gstreamer backend error, could not initialise supporting library" because "gstreamer1.0-pulseaudio" is missing." [Undecided,Confirmed]
<bluesabre> Would it be possible get a review of this.  It's a simple, low-risk fix, with the inclusion of a new Recommends on the parole package.
<bluesabre> Please let me know if there are any questions.
<infinity> bluesabre: Get someone to upload it, much easier to review in the queue.
<infinity> bluesabre: (but looks fine to me)
<bdmurray> Could somebody have a look at this ubuntu-archive-tools mp? https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/email-quote-version/+merge/216490
<bdmurray> infinity: could we get some of the old trusty milestones deactivated?
<infinity> bdmurray: Yup.
<infinity> I can't help thinking that milestones with dates should auto-deactivate...
<infinity> bdmurray: That look better?
<bdmurray> yes, thanks!
<infinity> Except for the seriously bizarre ordering in the combo box...
<infinity> 5, 1, 2, updates, 3, 4?  Wow.
<utlemming> infinity: when is the EOL notification for 12.10 going out?
<Aki-Thinkpad> utlemming, 12.10 isnt supported anymore?
<utlemming> Aki-Thinkpad: run "ubuntu-distro-info --supported", it has an EOL of "April 2014" on the release wiki
<Aki-Thinkpad> akiva@Akiva-ThinkPad:~$ ubuntu-distro-info --release --supported
<Aki-Thinkpad> 10.04 LTS
<Aki-Thinkpad> 12.04 LTS
<Aki-Thinkpad> 13.10
<Aki-Thinkpad> 14.04 LTS
<utlemming> Aki-Thinkpad: that is part of why I was asking about the EOL notification
<Aki-Thinkpad> !12.10
<ubot2> 12.10 (Quantal Quetzal) was the 17th release of Ubuntu. Download at http://releases.ubuntu.com/12.10/ - Release Notes: http://www.ubuntu.com/getubuntu/releasenotes/1210
<Aki-Thinkpad> utlemming, mmmm is it the server version?
<utlemming> Aki-Thinkpad: well, it wasn't an LTS and was the last 18month supported stable release. So server or not, it doesn't matter.
<Aki-Thinkpad> I didnt realize that there was ever an 18month release cycle...
<Aki-Thinkpad> maybe I have a bad memory
<Aki-Thinkpad> I always thought it was 9, and then 6
<utlemming> Aki-Thinkpad: development cycle is 6 months, but the supported life was 18 months. Starting with 13.04 it became 9 months except for LTS releases, which is 3 or 5 years, depending on the variant
<Aki-Thinkpad> utlemming, yah my memory must be failing me. I think you are right
<Aki-Thinkpad> 6 months would not make sense...
<infinity> utlemming: There should be an announcement, yes.  It's all been a bit messy because of the switch in support lengths, and what that means for users, etc.  I'll gather up everything we discussed and decided on and put out the EOL warnings soon.
<utlemming> infinity: great, thanks :) I just need that to inform the cloudy people. However, according to the distro-info-data, it EOL'd on the 18th.
<infinity> utlemming: Yeah, distro-info-data was set at 12.10 release, it's certainly not kept up with discussions since then.
<infinity> (I wouldn't take d-i-d as anything but an approximation of truth, ever)
#ubuntu-release 2014-04-22
<bdmurray> if somebody could review ubuntu-release-upgrader in saucy-proposed that would be great
<RAOF> bdmurray: Sure.
<bluesabre> welcome Logan_ :)
<bdmurray> RAOF: thanks
<med_> gaughen, are cloud-images painfully slow to load for everyone tonight?
<med_> kirkland, ^
<ScottK> Who knows phased updates well enough to know how it deals with a large set of packages released together?
<infinity> ScottK: That's going to be mostly up to the package manager, but if they're all interdependent, the answer is probably "not very well".
<infinity> ScottK: Since you might get half of them randomly wanting to upgrade, and half of them not, and then python-apt (or whatever backend your upgrader uses) will tell you where to go and how to get there, and you get no upgrades at all until they all phase in.
<infinity> ScottK: Or, that's pretty much how I assume it would work out.
<infinity> bdmurray: ^
<infinity> Oh, though, it might be more clever than that, come to think of it.
<infinity> Since apt (and python-apt) don't actually give a crap about phase, it's only the high-level manager that uses it to "show" the upgrades to you.
<infinity> So, if you show half of them, then do dependency resolution, you'd get the other half...
<infinity> So, maybe you'd just get everything phasing much more quickly than expected, rather than the inverse...
<infinity> Definitely worth some closer investigation.
<xnox> ScottK: the more packages depend on each other, the slower the phasing needs to be, since a phasing match on any higher level packages pulls in libcore, et.al. And i believe update-notifier / update-manager is the only one that looks at phasing.
<xnox> apt-get dist-upgrade will just pull in everything.
<xnox> ScottK: but bdmurray is the one you should probably talk to.
 * ScottK is imagining the KDE point releases being unpleasant.
<infinity> ScottK: It might be that the point release would be a special case where you'd just want to override the phasing to 100% for all of it, so it doesn't come in weird pieces.
<infinity> Maybe.
<ScottK> Since it's just bugfix stuff, it's mostly not driven by dependency and if you phase in a set of say 70 packages in over a few days, I think it'll be never ending updates for the lucky ones that draw the early update.
<ScottK> Yeah.
<infinity> Probably worth adding a --no-phase switch to sru-release.
<infinity> Or --initial-phase, so it's more generically useful.
<infinity> Just --phase, I guess.  We don't like typing.
<ScottK> It doesn't affect Kubuntu now since muon-updater doesn't know about phasing, but I don't think that's the only place it's relevant.
<infinity> So --phase=100 would just not set it at all (which is the same thing), no phase would default to 10, and you could alternately twiddle different initial options.
<infinity> The other obvious interdependent mess is the kernel, but since I've never had a complaint, I assume xnox's analysis (and my second scenario) are correct.
<infinity> So, once linux-meta phases in, you just get the whole mess at once.
<infinity> And the phasing of the other packages would be meaningless.
<ScottK> what about openstack point releases?
<infinity> I really hope they version their depends correctly when they need to.
<infinity> But they tend to do piecemeal updates of the components, not one massive dump.
<ScottK> OK.
<infinity> So, I'd assume deps are correct when they have to be, and otherwise things are backward compat.
<xnox> ScottK: server has no support for installing phased updates, so also not quite so relevant.
<infinity> Well, yes, that too.
<ScottK> xnox: I meant installing it, not installing using it.
<infinity> ScottK: Can't be too many people who run openstack on an Ubuntu desktop with update-manager.
<infinity> (But yeah, it should probably be okay anyway)
<ScottK> Does server still just use apt?
<xnox> yes.
<infinity> apt or unattended-upgrades, but nothing particularly more fancy.
<ScottK> OK.
<ScottK> My recent server install was on Hardy.
<infinity> I suppose someone could try to jam phasing knowledge into landscape or some other mass admin thing, but I would pretty much consider it harmful at that point.
<infinity> Or, at least, very confusing.
<ScottK> Yeah.  I'm not proposing it.
<ScottK> Just think it's worth considering that anything server/cloud 'ish won't do phase updates either.
 * infinity scratches his head over one of his machines not running ntpdate on boot...
<infinity> Oh, *sigh*.
<infinity> It's outsmarting itself.
<infinity> Internal bridge comes up, ntpdate runs, lockfiles, external if comes up via DHCP, ntpdate exits on the lockfile.
<infinity> Derp.
<xnox> !isitout
<ubot2> Yes, it's out! Download at http://www.ubuntu.com/download | Release announcement at https://lists.ubuntu.com/archives/ubuntu-announce/2014-April/000182.html
 * xnox ponders if we need a new command for "is next release named yet"
<arrith> yes
<ScottK> Not on IRC please.
<saiarcot895> Hi all. Can someone nominate for #1308794 for Trusty? I have a fix ready for SRU.
<NoNameYet_xnox> bug #1308794
<ubot2> Launchpad bug 1308794 in checkstyle (Ubuntu) "Checkstyle unusable on Trusty" [Undecided,In progress] https://launchpad.net/bugs/1308794
<saiarcot895> Thank you, NoNameYet_xnox
<bdmurray> Could I get a speedy release of the SRU for bug 1310851?
<ubot2> Launchpad bug 1310851 in ubuntu-release-upgrader (Ubuntu Saucy) "Failed to fetch window does not appear" [High,Fix committed] https://launchpad.net/bugs/1310851
<infinity> bdmurray: Yeah, that looks reasonable.
<infinity> bdmurray: Done.
<bdmurray> infinity: thanks
<bdmurray> infinity: when will Quantal be going EoL? I'm going on vacation later this week and was thinking about stopping the acceptance of crash reports for errors tomorrow.
<infinity> bdmurray: I need to send out a warning announce, discussing with the security team has me sending out the warn nowish, and EOL would be in ~4w, then.
<infinity> bdmurray: Though, given that we never switched the default upgrade path from 13.10 to 14.04, the arguments we originally had for the slight extention are gone.
<bdmurray> infinity: ah, so not in april then
<infinity> But no one told me that in enough time to warn for an earlier EOL. :P
<ScottK> infinity: So what's the 12.10 upgrade path?
<infinity> ScottK: 12.10->13.10->14.04
<infinity> So, 12.10 needs to EOL before 13.10, but needed to EOL after 14.04 release.  Basically, anytime in the next month is fine for that.
<ScottK> OK.
#ubuntu-release 2014-04-23
<stokachu> cjwatson: hey when you get a chance would you mind looking over bug 1311274
<ubot2> Launchpad bug 1311274 in Ubuntu Untitled "Include sosreport into ubuntu-seeds/cloud-image" [Medium,Confirmed] https://launchpad.net/bugs/1311274
<bregma> hey guise I have a bunch of Unity and Compiz bugfixes for 14.04, some of which will obviously require an SRU, but do I require going through the SRU process for every single bug fix or can some fixes be uploaded without?
<seb128> bregma, having different bugs/testcases help to build confidence in the update, but I think not having a bug reference for every change is fine, as long as you have one that covers those changes to make sure to regression test the update
<seb128> I'm not in the SRU team though
<seb128> so to be confirmed by others
<bregma> seb128, we've got bug references for every bug, I just want clarification if we need to SRU every bug
<seb128> but we often have "upstream bugsfix updates" as SRUs with a bug describing the update and what to test/check for
<seb128> if you list them in the changelog they should be SRU compliant yet
<seb128> yes
<bregma> mostly because it's going to quickly become unscalable
<seb128> otherwise it's going to create issues with the process
<seb128> why not?
<seb128> if those are identified issue with fixes it shouldn't be that difficult to have a testcase for each
<seb128> if you don't want to do that just don't list them in the changelog
<sil2100> Hello SRU team! There are 3 packages in the UNAPPROVED queue that we think are ready from the SRU-point of view - it's ubuntu-push, webbrowser-app, unity-webapps-googleplus
<sil2100> All those packages have SRU-ready bugs
<infinity> bregma: If you're asking if you need an upload per bug, absolutely not.
<infinity> bregma: One upload with all the bugs fixed, and proper references for each is what we expect to see.
<bdmurray> infinity: could you release app-install-data-ubuntu early to fix bug 1161283?
<ubot2> Launchpad bug 1161283 in app-install-data-ubuntu (Ubuntu) "Problems reported with .desktop files for sonic-visualiser" [Medium,Fix committed] https://launchpad.net/bugs/1161283
<infinity> bdmurray: Yeah, can do in a sec.
<infinity> bdmurray: Can you find someone to do verification on bug #1308354?  It didn't get all properly linked to things, cause mvo messed up the changelog...
<ubot2> Launchpad bug 1308354 in software-center (Ubuntu Trusty) "Password revealed when pasted with Ctrl-V" [High,In progress] https://launchpad.net/bugs/1308354
<infinity> (You'd think whoever accepted that upload would have noticed)
<bdmurray> hrm
<bdmurray> infinity: okay, I've verified that fix if you want to release it early so we don't forget which bug it fixes.
<infinity> bdmurray: Ta.
* infinity changed the topic of #ubuntu-release to: Released: Trusty Final | Archive: Limbo | Utopic Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis
<ogra_> is the archive open yet
<ogra_> ?
<infinity> ogra_: You're joking, I hope.
 * ogra_ taps foot
<ogra_> :)
<stgraber> yay, I can finally start doing Ubuntu stuff (was pretty much doing upstream work only till now). I'll setup the tracker and system-image after lunch then.
<davmor2> hey guys when will Quantal be retired?
<davmor2> also for that matter saucy
<sergiusens> davmor2: https://wiki.ubuntu.com/Releases
<infinity> davmor2: I'll send out warning announcements later tonight.  The wiki is probably wrong, FWIW.
<sergiusens> infinity: so not this month?
<davmor2> sergiusens: yes I was more after date then month ;)
<infinity> sergiusens: Next month.  Got extended a bit to stagger upgrades and not have people panicking due to the weird support cycle changes in the last few releases.  Then it'll be business as usual going forward.
<sergiusens> great
<davmor2> infinity: thanks dude
<Logan_> infinity: I've got someone in #ubuntu who is not getting any new releases with a do-release-upgrade - Prompt=normal, and lsb_release -a spits out 13.10 - what gives?
<infinity> Logan_: Not sure, ask bdmurray.
<Logan_> bdmurray: ^
<bdmurray> Logan_: have them run DEBUG_UPDATE_MANAGER=1 /usr/bin/do-release-upgrade'
<bdmurray> well without the '
<bdmurray> It might be bug 1310891
<ubot2> Launchpad bug 1310891 in ubuntu-release-upgrader (Ubuntu Trusty) "cached meta-release file should not be saved if it is html" [High,Triaged] https://launchpad.net/bugs/1310891
<Logan_> bdmurray: <Sinistrad> Logan_: http://paste.ubuntu.com/7316720/
<Logan_> (at the bottom)
<Logan_> looks exactly like that bug, eh?
<bdmurray> no it doesn't say "reading file" does it?
<Logan_> no, no it doesn't
<Logan_> bdmurray: if you want to debug with him directly, he's Sinistrad in #ubuntu :P
<Logan_> or I can have him come in here
<bdmurray> that's okay how about #ubuntu-bugs
<bdmurray> or have him check the contents of the files that are read in the bug report I mentioned
<cjwatson> ^- lack of bug number, I've talked to the lander
<infinity> cjwatson: Sure.
<cjwatson> disabling publisher
<cjwatson> utopic -> FROZEN
<infinity> cjwatson: I'll toss up milestones.
<cjwatson> ta
<cjwatson> branching seeds
<cjwatson> infinity: I think you can safely +initseries if you want
<cjwatson> (don't remember whether ~launchpad can do that)
<infinity> cjwatson: I can do it.  Did you want to poke WeBops to pre-emptively disable the possibly-offensive lock contender first?
<cjwatson> so glad I wrote branch-seeds, avoids having to pay attention
<cjwatson> infinity: nah, let's see if it works by itself
<cjwatson> (it might do, I think some jobs have moved around a bit)
<infinity> cjwatson: Does "auto-select" for arch indep work, or should I be paranoid and click i386?
<cjwatson> infinity: What's the exact text?
<infinity> Architecture independent builder:
<infinity>     Auto select
<infinity>     amd64
<infinity>     arm64
<infinity>     armhf
<infinity>     i386
<infinity>     powerpc
<infinity>     ppc64el
<cjwatson> Pretty sure I just left it at the defaults last time, but double-checking
<infinity> I'm assuming the default should work, I've just never played with this form before. :)
<cjwatson> Yeah, pretty certain auto select is fine
<cjwatson> Not that being explicit hurts
<infinity> Button pressed.
<cjwatson> Seeds branched
<infinity> Back to milestones...
<cjwatson> 2014-04-23 19:15:21 INFO    Running <InitializeDistroSeriesJob for distribution: ubuntu, distroseries: utopic, parent[overlay?/pockets/components]: jessie[False/Release/], architectures: (u'amd64', u'arm64', u'armhf', u'i386', u'powerpc', u'ppc64el'), archindep_arch
<cjwatson> So no lock problem
<infinity> Hah.  LP is timing out creating milestones.  La la la.
<cjwatson> Still need to do germinate output, but all the seeds exist on the mirror now which is good enough for the publisher
<infinity> Wait, that's not a timeout, that's something more insidious.
<infinity> I'm getting the "Please try again" error page.
<cjwatson> Do you have an oops?
<infinity> No, see above.
<infinity> OOPSless, it's the page you get during maint.
<cjwatson> Oh.  Looks normal here, I can manual/auto a builder just fine ...
<cjwatson> Maybe you can't create milestones during IDS?
<infinity> Maybe.
 * infinity shrugs and moves down the list to see what can happen in parallel.
<infinity> I can do the bootstrap archive twiddling.
<cjwatson> You could probably do the edit-acl too
<cjwatson> 12 and 13
<cjwatson> NoNameYet_xnox: Your nick is wrong now. :-)  Do you know how to branch-distro?  Not quite time yet but will be shortly
<infinity> I did those post-release.
<infinity> Well, I did 12 post-release.  13 might need doing (but it implies it should maybe be automatic)
<cjwatson> Oh, yeah, IDS might do it
<cjwatson> In fact it might grant ubuntu-sru access too since we did 12 early ...
<cjwatson> So you'll want to check that
<cjwatson> IWBNI IDS gave any intermediate feedback whatsoever.  *nervous*
<cjwatson> I'm sure it was more like 7min last time
<cjwatson> Ah, there
<cjwatson> 2014-04-23 19:28:44 INFO    Ran 1 InitializeDistroSeriesJob jobs.
<cjwatson> 13mins
<cjwatson> re-enabled publisher, will run in ~4mins
<infinity> Ahh, milestone creation works now.
<cjwatson> (Also, I can't add, publisher will be at :33)
<infinity> cjwatson: Yeah, drat, it copied the perms from trusty.  of course.
 * infinity will edit.
<cjwatson> publisher taking ages to say anything for some reason; I guess it lacks logging in this situation
<cjwatson> Ah, there
<cjwatson> 2014-04-23 19:37:08 INFO    Creating archive indexes for utopic, utopic-backports, utopic-security, utopic-updates, utopic-proposed.
<infinity> Alright, queue rights look sane, bootstrap archive fixed up.
<infinity> cjwatson: Should be good to go to toss in chroots now?
<cjwatson> Yup
<infinity> Ahh, yes, should be.
<infinity> Throwing in trusty chroots for now, will fix (and reenable bootstrap bits) later.
<cjwatson> I've taught archive-reports etc. about utopic; it may be temporarily confused but whatever
<infinity> I'll do a partner copy in a sec.
<cjwatson> infinity: I think I have to go now, but the delicate bit is done.  I suggest compare-archives after this publisher run + archive-reports and then the second publisher should fix everything up properly
<infinity> cjwatson: *nods*
<cjwatson> So yay
<cjwatson> If you want to continue wittering here then I can pick up later
<stgraber> qatracker is ready for utopic (copied manifest over from trusty, setup testsuites and daily milestone)
 * stgraber goes to create a few system-image channels now
<cjwatson> BTW proposed-migration is stopped by way of ~ubuntu-archive/proposed-migration/STOP
<cjwatson> So if you get to the point where you want it to run again and you're sure it has been adequately educated, rm that
<infinity> cjwatson: Check.
<cjwatson> Actually I can minimally educate it now
<cjwatson> I wonder if autopkgtest will work with utopic
<cjwatson> ah there's an entry for that
<cjwatson> jibel: could you please set up autopkgtest for utopic?
<cjwatson> proposed-migration configured for utopic (but still stopped)
<cjwatson> gone
<infinity> cjwatson: Ta.
<infinity> I think I've angered LP with my chroot uploads.
 * infinity taps his foot.
<cjwatson> infinity: (oh look, still slightly around) compare-archives looks fine
<cjwatson> so we're up to and including 10, except for 8
<cjwatson> assuming you got milestones done
<infinity> Milestones done.
<infinity> Partner should be okay once it publishes my copy.  I'll wait another cycle.
<infinity> 12 and 13 are done.
<infinity> 14 and 15 are done.
<cjwatson> 18 (merge-o-matic) done
<infinity> cjwatson: Can we turn on p-m without adt working, or will it explode?
<cjwatson> ... I forget
<cjwatson> you could disable it by temporarily emptying ADT_SERIES
<cjwatson> or just let it explode and force things as needed
<cjwatson> it shouldn't explode in a way that permanently blocks p-m or anything
<infinity> Well, depends on the definition of "explode". :)
<infinity> If it just fails all the tests, that's "fine" for now.
<cjwatson> Yeah, I think that's the worst case
<infinity> So, 8 and 17...
<infinity> And 16.
<cjwatson> No rush on 17, I'll do that later / tomorrow
<cjwatson> 8 can either wait until xnox is around or you can see if a webop knows how
<cjwatson> 13?
<infinity> I did 13.
<infinity> So, we can defer 8, 16, and 17, and I think we're up to toolchain bits.
<infinity> (Once the publisher runs again)
<cjwatson> should be safe to jam in whatever toolchain bits we have now, yeah
<infinity> doko: That's your cue for binutils/gcc, if you're still around.
<infinity> I'll let my base-files in to build once this publisher settles.
<cjwatson> IDS has over-copied a spare grub-efi-amd64 for some reason but I'll look into that tomorrow, ignore for now if you happen to be fine-tooth-combing compare-archives
<infinity> I'm taking your word on compare-archives, I don't think it needs two of us.
<infinity> skype just published to partner, will check that archive once the mirror pushes.
<cjwatson> second publisher is mostly done; you should be all good there now
<cjwatson> all it really lacks at this point is Contents, which I expect will be filled in tonight
<infinity> Yeah, should be good to let base-files build and see if it implodes.
<cjwatson> yup
<cjwatson> really gone
<doko> infinity, cjwatson: thatÃs for tomorrow morning
<infinity> doko: Do either of your uploads need to be pre-open, or do you just want them pre-debian-import?
<infinity> (ie: is there much of an argument to wait on them?)
<doko> infinity, the binutils upload should be pre-open, I don't care about the other ones (besides the ruby default, but ScottK did volunteer for this)
<infinity> doko: Kay.  The binutils you already had prepped, right?  Want me to just grab it from chinstrap, twiddle the changelog target and upload for you?
<infinity> base-files builds looked sane.
<doko> sure
<doko> I thought you didn't want to rush things?
<infinity> distro-info-data looks sane too, if someone wants to SRU that.
 * stgraber does the usual extras.ubuntu.com trick to generate the needed indices
<infinity> bdmurray: Feel like snagging my distro-info-data delta from utopic and SRUing it back to current releases?
<infinity> bdmurray: I'll review, and we can push an instant release if it all looks sane.
<infinity> bdmurray: (Or vice versa, I can do the SRUs and you can review)
<infinity> partner looks published correctly.
<bdmurray> I'll do the SRU if you could review my P and S fixes for bug 1311396
<ubot2> Launchpad bug 1311396 in ubuntu-release-upgrader (Ubuntu Saucy) "broken croatian translation results in traceback in new release notification" [High,In progress] https://launchpad.net/bugs/1311396
<infinity> bdmurray: Looking.
<infinity> bdmurray: Is that what was being reported on IRC a little while back, or something else?
<infinity> Oh, must be something else, based on the timestamp.
<bdmurray> infinity: yeah, something else fun
<infinity> bdmurray: Japanese isn't broken in S?
<infinity> bdmurray: And none of these are broken in Q?  (I haven't EOLed Q just yet, but feel free to not care)
<bdmurray> infinity: no, japanese is fine in saucy
<infinity> bdmurray: Kay, cool.
<infinity> bdmurray: Accepted both, assuming that would be your answer.
<bdmurray> mvo and I talked about modifying pre-build.sh to check for this
<infinity> bdmurray: Hard failing the actual build on msgfmt errors wouldn't hurt either.
<infinity> bdmurray: I'm not a huge fan of too much logic living in weird pre-build scripts outside debian/rules.  It's good to get the import right, but it's also good to make sure the build itself is sane.
<infinity> bdmurray: (And if the build fails, you won't upload, cause you always testbuild, right?)
<bdmurray> infinity: right unless it is distro-info-data
<infinity> bdmurray: Need a d-i-d for precise too, methinks.
<bdmurray> its coming
<infinity> Oh, c'mon LP, how is there not a debdiff for the saucy one yet?
<Logan_> infinity: can we have Utopic derive from Sid instead of Jessie?
<infinity> Logan_: I assme you mean where debian autosyncs will come from, that's sid.
<Logan_> no: https://launchpad.net/ubuntu/utopic
<Logan_> > Derived from Jessie
<infinity> Logan_: Right, that's not particularly meaningful.
<Logan_> well, the package diffs are helpful (although there's also MDT for that)
<Logan_> and it compares against Jessie instead of Sid
<infinity> Oh, you're the one person who uses that page? :)
<Logan_> thank you for making me feel special! :)
<Logan_> I was always a unique one
<infinity> Logan_: So, this is pretty much how we always set this up.
<Logan_> there's always room for change!
<infinity> Also not sure if that can be changed post-init. :P
<Logan_> gah, should've asked before
<infinity> Logan_: I believe if you ask LP people, they consider that feature pretty much broken by design anyway.  I wouldn't worry too much about it.
<Logan_> alrighty
<infinity> (base)adconrad@cthulhu:~$ sru-review -s saucy distro-info-data
<infinity> ERROR: queue does not have a debdiff
<infinity> bdmurray: ^-- What crack is sru-review smoking?
<bdmurray> infinity: works for me
<infinity> ...
<infinity> Bad cache, I guess.
 * infinity wipes out his lplib cache.
<infinity> Which is, apparently, enormous.
<infinity> bdmurray: Thanks for those.
<infinity> ScottK: Did you still want to do some ruby mangling pre-open?
<tumbleweed> finally, a name. thanks infinity
<cjwatson> infinity: How goes?
<infinity> cjwatson: Taking a break on 19 for doko (maybe) and ScottK (he had some ruby stuff he wanted to do for opening)
<infinity> cjwatson: Though, I suppose we can call those things "pre-autosync" rather than "pre-thaw" and no one will care much.
<infinity> cjwatson: Going to skip down to livefs chroots shortly, just a bit distracted at the moment.
<xnox> cjwatson: i have no rights to do branch-distro someone more powerful needs to do that.
<xnox> cjwatson: i'll check udd to be up-to-date, unless it has been done already
<cjwatson> OK
<wgrant> xnox: branch-distro is in progress
<wgrant> It will take $longtime
<wgrant> UDD must not be restarted until it is complete
<cjwatson> infinity: OK, well, if you're ready to start auto-sync and I'm not around, just drop --dry-run from that crontab entry on snakefruit
<cjwatson> But we should make sure that p-m is working first
<cjwatson> infinity: Shall I try turning on p-m?
<infinity> cjwatson: Can't hurt.
<infinity> (famous last words)
<infinity> cjwatson: If it seems to be working correctly, I'll do the carefully selective mass copy/delete from t-p to u-p.
<cjwatson> Running
<infinity> Oh, actually, I won't do the copy/delete until adt is back up.
<cjwatson> Grr, needs fixing mk2.  Let me just get my daughter a drink then I'll try again
<infinity> Just in case something in there would actually migrate without tests.
<infinity> Though I think it was all missing binaries.
<infinity> I think.
<xnox> Logan_: it's best to derive from jessie imho, since otherwise everything is always derived from sid.... and the diffs will just keep on pointlessly growing post-ubuntu-release.
<xnox> wgrant: i've stopped UDD a while back (wednesday release week).... so much for wishful release name thinking.
 * xnox looks what else i can do.
<cjwatson> Right, had to copy the Dates file over, let's try that again
<infinity> Oh, whee, I have 13 minutes to get to my dinner appt with my brother.  I'll be back in a couple of hours, though.  The rest of the checklist just seems like crossed Ts and dotted Is, except for the cdimage stuff, which I can do later tonight.
<cjwatson> Setting up chdists
 * infinity runs out.
<ScottK> cjwatson: We need to sync in ruby2.1 and make it default (per doko).  I can do it if you're ready for it.
<cjwatson> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html looks plausible; I might drop the block shortly
<cjwatson> ScottK: Please do
<cjwatson> Well, unless it wants to go after binutils
<ScottK> OK.  Never done Ruby before, so let's give this a shot ...
<cjwatson> I guess there isn't really a problem with this going before binutils; should only need to have that before the general bulk
<bdmurray> Should step 12 (ubuntu-sru queue admin access) from NewReleaseCycleProcess move to the ReleaseProcess page?
<ScottK> cjwatson: Any objection to me waving ruby2.1  through New?
<cjwatson> bdmurray: It's better where it is, because ideally (i.e. without this stupid name delay) it comes after initialising the new series, so that it doesn't get copied over
<cjwatson> ScottK: None except that I just did
<ScottK> OK.
<ScottK> Thanks.
<ScottK> OK, so while that builds, I'll go learn how to make it default.
<bdmurray> cjwatson: okay, fyi I think infinity did that step last Friday
<cjwatson> bdmurray: Yeah, we dealt with the fallout today
<cjwatson> When things aren't pathological the process as written is better :-)
<bdmurray> cjwatson: got it
<Logan_> xnox: fair enough
<ScottK> xnox: Did you figure out what boost version we want?
<xnox> ScottK: i've mailed debian maintainer, we want to go for .55 but i haven't done a test rebuild in either ubuntu nor debian.
<xnox> ScottK: i could upload the switch to e.g. experimental and sync. But i'd also need to do the .55 package split.
<ScottK> cjwatson: doko specifically said he wanted ruby2.1 as default, but Debian is still on 2.0.  It's easy enough on the packaging side for me to set it as 2.1, but I'd like someone else to agree with it who's here right now.
<xnox> infinity: ideally i'd love to get the boost 1.55 as default pre-debian-import.....
<xnox> ScottK: looking at changes between 2.0 and 2.1 it's fairly minimalistic. If there is fallout / incompatibilities i'm happy to work on fixing them.
<cjwatson> I don't think I have an opinion on ruby
<xnox> ScottK: my ruby  is rusty, but i don't see anything scary at all.
<cjwatson> The main problem historically has just been somebody actually caring for it properly in Ubuntu; if xnox is happy to step up to that ...
<ScottK> Yep.  I'll upload it once ruby2.1 is built.
<xnox> here be unicorns! =)
<slangasek> mmm, tasty unicorns
<xnox> slangasek: i think we should start adding easter-eggs e.g. to pop-up mascot PNG if one does something, cause unicorn will be an awesome mascot =)
<slangasek> we should just bundle http://games.adultswim.com/robot-unicorn-attack-twitchy-online-game.html
<xnox> slangasek: I heartbleed ^_^
<ScottK> Needed for ruby2.1 ^^^
<ScottK> Thanks.
<xnox> ScottK: yeah, got agreement from Steve to do 1.55 by default in experimental and also sync into ubuntu
<ScottK> OK.
<ScottK> It would be nice to get that done before the first autosync.
<cjwatson> Urgh, no syncpackage.
<cjwatson> -proposed.
<kirkland> can someone approve byobu 5.77-0ubuntu1.1 into trusty-proposed?
<kirkland> I have motivated testers ready and waiting...
#ubuntu-release 2014-04-24
<RAOF> kirkland: looks sensible to me. Enjoy your testing.
<kirkland> RAOF: cheers, thanks
<ScottK> Fun.  So ruby2.1 downloads config.guess and config.sub from the network.
<jose> infinity: ping, have a minute?
<xnox> ScottK: haha =) good that ubuntu builders don't have network, unlike debian. Sounds like an RC bug to me.
<jose> or xnox
<xnox> jose: hey! what's up?
<jose> xnox: hey, someone cancelled his OpenWeek slot tomorrow at 17 UTC and I was wondering if you would like to do a session about the Ubuntu Release Team
<jose> it's basically what you do on the team and how can people contribute
<jose> all for an hour
<xnox> jose: haha =) well i'm not actually in fact on the release team.
<jose> oh, I thought you were
<xnox> jose: and unfortunately i have an ~ 1.5h meeting at 17 UTC.
<jose> uh, good luck with that one
<jose> well, if anyone else from the release team was reading and wants to do it I'll be happy to set it up (as long as someone else doesn't snag the slot before!)
<xnox> jose: here are the members https://launchpad.net/~ubuntu-release/+members
 * jose pings 100 people
<jose> thanks for the link :)
 * ScottK will be in the middle of a 9 hour meeting.
<xnox> jose: it's only 10 =) well 7-8 if you discard the not so active people.
 * jose strikes ScottK from the list :(
<xnox> ScottK: =))))) 9 hour meetings -> sounds utopic
 * jose puts an ice cream cone on his head
<ScottK> xnox: Even better I'm the presenter for about 4 hours of it.  They'd notice if I was missing.
<xnox> ScottK: one would think that....
<xnox> ScottK: one of my mates in university had a slide 30/38 that said "WAKE UP B#$@#" and nothing else, he had it up for good 20 seconds and only a couple of people smirked/giggled and everyone just stared akwardly, not realising what the giggles are for.
<ScottK> Fun.
<ScottK> I once had a slide that had a nice summary box at the bottom that said (in Latin) "everything sounds better in Latin".  The presentation was very close to being given before anyone asked what it meant.
<ScottK> xnox: It gets worse.  The configure check it has to see if config.sub/guess have already been downloaded looks in the wrong place.
<ScottK> And now I have to update distro-info-data before I can upload...
<xnox> ScottK: i think that's updated already
<ScottK> In trusty?
<ScottK> It is in Utopic
<xnox> ScottK: in trusty-proposed
<ScottK> Faster to edit /usr/share/distro-info/ubuntu.csv than to enable proposed.
<xnox> true =)
<xnox> infinity: cjwatson: the three boost packages are in the unapproved queue. Would be handy to build them & promote binaries from the "main-only" boost1.55 as per: $ rmadison -S boost1.54 -s trusty  | grep -v universe
<xnox> i'll do transition tracker for it tomorrow.
<infinity> ScottK: distro-info-data is updated in all releases now.
<ScottK> infinity: Thanks.
<infinity> xnox: Does boost-mpi need to build-dep on boost*?
<infinity> xnox: The shlibdeps seem to be unhappy.
<ScottK> infinity: once the 2.1 binaries are published, I'll upload defaults.
<infinity> ScottK: Looks like they're all going to succeed, so go ahead and upload.
<infinity> ScottK: And pick a version that will let us sync with Debian later when they switch.
<infinity> 1:2.1.0.0~ubuntu1 maybe
<ScottK> Oddly, I have 2.1.0.0~ubuntu1
<ScottK> (with the epoch)
<infinity> Heh.
<ScottK> Uploaded.
<infinity> Man, this is the worst part of a new release.  It takes forever for firefox to learn that "qu" means utopic/+queue instead of trusty/+queue
<ScottK> I just leave the tab open.
<RAOF> Man, we need better tooling for reviewing SRUs-that-are-syncs-from-PPAs.
<infinity> RAOF: Yeahp.  Or we need to give wgrant enough breathing room to fix the queue so syncs aren't opaque blobs of awful.
<ScottK> I keep thinking ectopic instead of utopic.
<infinity> (It's in progress, just slow going)
<infinity> ScottK: Rick made that same joke.
<infinity> "utopic pregnancy".
<wgrant> No breathing for me for a while...
<infinity> wgrant: Please keep breathing.
<infinity> wgrant: But, seriously, I know you're being pulled in 17 directions.  If there's any way we can push the queue stuff forward by leveraging any of your minions, or hiring infinite monkeys, it's a massive pain point for AAs.
<wgrant> A few months ago it was second on my list of big features. Now I can't even count :/
<infinity> wgrant: So, it's third, and you need more fingers? :P
<infinity> ScottK: Looks like that needs more changes than just rules/postinst
<ScottK> I don't think so, but I'll look again.
<infinity> ScottK: debian/control points everything at ruby2.0
<infinity> ScottK: The only one that's (accidentally) correct is ruby-all-dev, since it depends on both.
<ScottK> Good point.  Please reject.
<infinity> ScottK: Lots of (currently v2.0) in there too.
<ScottK> Yeah.  Fixing that too
<infinity> ScottK: (Also, you can probably drop the versioned deps while you're switching)
<ScottK> Already did
<infinity> Well, not the ones for ruby-all-dev, but the others.
<infinity> Right, I'll stop being annoying. :)
<ScottK> I should probably also add 1.9 into supported.
<ScottK> For now.
<infinity> Should you?
<infinity> I imagine the intent is to drop it.
<infinity> We already defaulted to 2.0 for trusty, 1.9 should die.
<infinity> Oh, no we didn't.
 * infinity scratches his head.
<infinity> 1.9.1 was default in trusty.  Curious.
<infinity> We had two in main.  Bleh.
<ScottK> Yep.
<infinity> Oh, but Debian's dropping it from trusted.
<infinity> I'd just follow their lead there.
<ScottK> So I figure at least for a transitional period it ought to be supported.
<infinity> s/trusted/supported/
<ScottK> Yeah, but they've had 2.0 as default for awhile already.
<infinity> Well, I assume that triggers which extensions get built.
<infinity> So we'd just have to transition again after dropping it out to remove them all.
<infinity> Maybe as well drop it now.
<ScottK> Normally for python we add the new one, rebuild shit, drop the old one, and build again.
<infinity> Can transition twice if you'd prefer.
<ScottK> I guess since we're changing the default, it doesn't matter much.
<infinity> Boosts the upload stats. :P
<infinity> But I imagine dropping it will work fine.
<ScottK> Nah.  I'd rather do it once and blame you if there's trouble.
<infinity> Works for me.
<infinity> I'll pass the blame to doko.
<ScottK> OK.  Let's try this ....
 * infinity teaches rmadison about utopic
<infinity> ScottK: You missed some descriptions.  Do you care?
<ScottK> I don't.
<infinity> Heh.
<ScottK> I'll fix it if you'd prefer.
<infinity> Nope, don't care.
<infinity> It'll sort itself out if/when Debian moves anyway.
<ScottK> doko_: default ruby = ruby2.1 is done.
<infinity> cjwatson: Alright, I put wgrant on 8 and 16.  pitti's handling the ones with his name on them (35, 36, 44, 45)
<infinity> cjwatson: I did livefs chroots for arm64 and ppc64el, and filed a ticket for the other 4.
<infinity> cjwatson: I think we're still stuck on 19 until doko wakes up and gives his blessing.
<infinity> cjwatson: And I didn't get to mangling debian-cd/cdimage, I've had an eventful evening away from work tonight.  Maybe if I fail to sleep, I can tackle more things.
<seb128> RAOF, hey
<seb128> RAOF, thanks for looking at that ido bug
<seb128> RAOF, I just commented on it, let me know if what I wrote makes sense to you
<RAOF> seb128: It does; I expect to approve ido at some point next week. Unless someone else gets to it first.
<seb128> RAOF, ok, thanks
<seb128> RAOF, you could maybe review nautilus in the SRU queue? ;-)
<seb128> would be nice to get that one rolling because we are likely to get other segfault fix rounds following
<ogra_> our first upload into utopic was a poporietary package ??
<ogra_> oh my
<ogra_> :)
<xnox> infinity: yeah it does, i busted it. let me fix it up.
 * xnox should automate build-depends mangaling as well, too error-prone
<xnox> I get 404 on http://archive.ubuntu.com/ubuntu/dists/utopic/Contents-i386.gz but i guess that might still be normal?
<xnox>  / expected
<mlankhorst> probably not there yet :P
<cjwatson> xnox: It generated last night but apparently isn't actually there.  I wonder if there's a race with the publisher
<cjwatson> (e.g. if sometimes it generates but drops the result into the wrong tree so that it then gets discarded)
<cjwatson> doko_: Are you planning to upload your toolchain bits?
<cjwatson> At least binutils
<ogra_> cjwatson, when do you plan to do the first image testbuilds ? this week already ?
 * ogra_ needs to update some tools
<cjwatson> ogra_: I'd like to get there before EOW, but can't say for sure yet
<ogra_> ok
<ogra_> just want to be prepared :)
<cjwatson> doko_: ... uploading binutils for you now with mangled series
<cjwatson> infinity: Should we drop block-all source around now?  Anything in -proposed should be OK if it's a valid candidate, I'd have thought
<cjwatson> infinity: Also, reminder to do the big copy from trusty-proposed
<mvo> could someone reject the recent ubuntu-release-upgrader upload to trusty-proposed please? I think I will include another fix there
<seb128> mvo, done
<mvo> thanks seb128
<seb128> yw!
<ogra_> stgraber, hmm, you didnt move the devel/devel-proposed alias to utopic yet
<cjwatson> Riddell: trusty-proposed will be copied in bulk to utopic-proposed fairly soon, fyi
<Riddell> cjwatson: oh ok I didn't realise that
<stgraber> ogra_: considering there are no images in those channels, I thought it'd be best to wait until we have something in them and confirmed it works before changing the alises
<stgraber> *aliases
<ogra_> stgraber, ok, just wanted to know if it was intentional
<ogra_> (makes sense to wait ... its is just that my tools are not multi-release aware, i have to point them somewhere, but can do that manually for the fist image)
<stgraber> ogra_: so I think we should wait to have a good build in utopic-proposed, have this promoted to utopic and then flip the aliases
<ogra_> yep
<cjwatson> NewReleaseCycleProcess step 17 done, I think
<Laney> I'll do ben shortly
<xnox> cjwatson: please unblock binutils, boost-mpi-source1.55, boost1.55. All built and look happy.
<cjwatson> xnox: I was hoping to get autopkgtest results for binutils
<cjwatson> (that aren't lies)
<xnox> cjwatson: the qualifier makes the difference =)
<cjwatson> there are some results on the private jenkins: lintian is still running, and binutils passed on amd64 but hit a testbed error on i386
<infinity> cjwatson: Yeah, block-all source is likely not needed anymore.
<infinity> cjwatson: Especially now that autopkgtests are back and happy, so we don't have to pick and choose carefully.
<infinity> cjwatson: Oh, unless those results are, as you said, lies. :P
<infinity> doko_:
<infinity> dpkg-source: info: upstream files that have been modified:
<infinity>  binutils-2.24.51.20140417/ld/emulparams/aarch64linux.sh.rej
<infinity> doko_: Is that a sign of a broken patch, or just that you had cruft in your package when you built it?
<doko_> infinity, cruft
<infinity> doko_: Kay.
<infinity> cjwatson: britney reporting a pass on binutils despite the apparent i386 failure is disconcerting.  Or is that passed on the private instance?
<cjwatson> infinity: yeah, not sure what's up there, pitti was working on it
<infinity> doko_: Can you double-check testsuite results for binutils on all arches and sign off on it?
<doko_> infinity, meh, lp doesn't reply
<doko> infinity, no regressions
<infinity> doko: Excellent, thanks.
<cjwatson> infinity: cdimage/debian-cd updated for utopic
<jdstrand> hrm, I did 3 pocket copies from trusty-security to utopic-proposed (rsync, mysql-5.5 and python-django) a while ago, but now thinking that may have been a mistake
<cjwatson> I think that's fine
<cjwatson> assuming you copied with binaries
<jdstrand> I did
<jdstrand> ah, I see them in unapproved
<jdstrand> https://launchpad.net/ubuntu/utopic/+queue?queue_state=1&queue_text=
<jdstrand> ok, sorry I jumped the gun there
<cjwatson> no it's fine
<infinity> xnox: So, are you still happy with the boost-defaults in the queue?  Nothing needed fixing there to match your new boost uploads?
<xnox> infinity: it should be all good.
<infinity> xnox: Accepting, then.
<xnox> thanks!
 * mdeslaur pokes infinity for EoL announcement
<infinity> mdeslaur: Yes dear.
 * mdeslaur gives cookie to infinity
<Laney> EU legislation requires your explicit confirmation to the acceptance of any cookies
 * Laney confiscates it
<Laney> om nom nom
<mdeslaur> lol
<infinity> Laney: Neither of us are in the EU, you just violated Canadian sovereignty.
<ogra_> bah MiM attacks on IRC !
<infinity> Laney: The moose of punishment is on its way.
<Laney> That'll go well with my cookie, thanks
<infinity> Laney: I suspect you've ever met an angry moose...
<Laney> I've never knowingly met any moose :(
<Laney> WCPGW
<infinity> Laney: Well, as you know, Canadians are kind and welcoming people.  We achieve this by chanelling all our rage and anger in two directions: the moose population, and hockey.  The Moose of Punishment plays hockey.  Enjoy.
<infinity> (PS: Now I want a cookie)
 * whiskers75 gives infinity a cookie
<ogra_> a moose shaped one ?
<whiskers75> A chocolate chip one.
<infinity> ogra_: Hockey-puck-shaped seems like it would be easier to achieve.
<ogra_> heh
<cjwatson> moose of punishment> now I'm reminded of the two toy seals Daniel Silverstone had at one point
<cjwatson> Club the Seal, and the Seal of Approval
<infinity> Kinnison is a strange fellow.
 * whiskers75 meows at infinity
 * Laney plays some moose polo
<xnox> Why is makedev in trusty ubuntu-minimal?
<ogra_> xnox, legacy of dmraid or something like that ?
<infinity> xnox: Why wouldn't it be?
<infinity> xnox: It's been prio:required pretty much forever.
<slangasek> infinity: because makedev is obsoleted in favor of udev in Debian
<infinity> slangasek: Well, your package depends on it. ;)
<infinity> slangasek: (mountall)
<slangasek> yes, that's why upstart must die, long live systemd
<slangasek> <cough>
<infinity> Poor upstart.
<slangasek> I think that dep dates back to Scott, it's been a minor annoyance that I have yet to take care of
<doko> hrm, sagari already used
<infinity> Anyhow, it'll be gone by the next LTS, I suppose, so I'm not sure it's worth caring deeply about removing makedev from required right now.
<infinity> doko: Doing a GCC upload?  We can kill it and aim it at sagari when this kernel's done.
<doko> sure, waiting for it now
 * infinity puts "powerpc VM buildds" on his TODO for the next week or two, too.
<infinity> I wonder if I have the time to make that happen before autosync.
<infinity> I guess I'll look at that after I find some breakfast and wake up.
<infinity> I need to re-do all the ppc64el VMs with trusty final too, since they're all pre-ABI-bump still, and the upgrade path there is bordering on nonexistent.
<saiarcot895> Are all the build machines on Lucid or Precise?
<infinity> saiarcot895: PPAs are hardy (don't ask), ia64 and sparc are lucid, i386, amd64, armhf, and powerpc are precise, and ppc64el and arm64 are trusty.  Was that a confusing enough answer?
<saiarcot895> infinity: Yes. :) What's with the disparity?
<saiarcot895> the time they were created, maybe?
<infinity> saiarcot895: The PPA thing is, like I said, a don't ask.  The ppc64el and arm64 ones are obvious, they didn't exist in precise.
<infinity> saiarcot895: And ia64 and sparc were dropped after lucid, hence they're not getting upgraded, and will disappear when lucid EOLs.
 * infinity goes to find breakfast.
<doko> infinity, I killed ross while cancelling the GCC build
<infinity> doko: Did you cancel too early? :/
<doko> maybe. shouldn't I?
<infinity> doko: There's a bug where you can't cancel until it's actually into dpkg-buildpackage.
<infinity> It gets a bit confused.
<doko> ok, trying to avoid that in the future
<xnox> infinity: does "eglibc still looks in /dev/shm" instead of "/run/shm" ?
<infinity> xnox: That question didn't seem like a complete sentence...
<xnox> infinity: does eglibc now default to using "/run/shm" (for whatever it may use that for) instead of "/dev/shm"? As per commented in the mounted-dev.conf upstart job that sets up /dev/shm to be symlink to /run/shm.
<xnox> infinity: or do we want /dev/shm compat symlink still...
<infinity> xnox: /dev/shm should probably never go away, IMO.
<infinity> xnox: Why are you trying to kill it? :P
<xnox> infinity: ok.
<xnox> infinity: makesense in linux style "don't break user interfaces"
<infinity> xnox: A decade of docs told people to use that path, even if I change glibc in Debian/Ubuntu, there's countless other bits of software I won't get to, not to mention 3rd party stuff I can't control.
<infinity> (The irony here that is moved from /var/run/shm to /dev/shm 12 years ago, and now people have decided to move it back to /run isn't lost on me)
<infinity> s/that is/that it/
<xnox> Haha =)
<xnox> that is funny =)
<infinity> xnox: Well, it makes sense, historically.
<xnox> do we require devtmpfs?
<xnox> ( i thought we did, by virtue of udev requirement)
<infinity> The right place for state files was /var/run, but /var wasn't guaranteed to be on /, so we started dumping early-need stuff in /dev to compensate, and then /run happened to fix the problem.
<infinity> Anyhow, not everyone is on the /run bandwagon, and I see no value in dropping the symlink pretty much ever.
<xnox> yeah, yeah, agreed with you, will keep that bit.
<xnox> i'll test openvz and lxc container and probably drop MAKEDEV usage from that job, and thus from mountall dependencies.
<xnox> (well make a merge proposal to drop that)
<infinity> xnox: Fair enough.  Seems like a waste of time to care, since mountall itself will be gone by the next LTS, but whatever. :P
<infinity> GAH.
<infinity> cjwatson: germinate is exploding in the publisher.
<infinity> wgrant: ^-- You were sad that everything went smoothly?
<slangasek> rc/l[
<knome> hey, would anybody here know if https://launchpad.net/xubuntu-desktop/ carries any technical merit, or would it be okay to just remove that project?
<stgraber> no obvious reason to keep it around if you're not using it to host code or blueprints
<stgraber> Edubuntu has a similiar /edubuntu but we use it for some branches
<knome> ok, good
<knome> i'll get that removed :)
<cjwatson> infinity: Hm, yes, reproduces with just "germinate -s ubuntu.utopic -d utopic --no-rdepends"
<cjwatson> So hopefully that's debuggable tomorrow
<infinity> cjwatson: Kay.  It's halting archive-reports, due to the way we check if the archive has changed, but I suspect there's no other serious fallout.
<infinity> doko: gcc-4.9/amd64 unsatisfiable Depends: libgcc-4.9-dev (>= 1:4.9.0-1ubuntu2)
<cjwatson> Alarmingly, it's not actually clear that it's infinite recursion
<infinity> doko: Looks like the real package doesn't have an epoch.
<infinity> cjwatson: Oh, it might just be very, very deep recursion?
<cjwatson> Just crudely tracing in pdb, it seems to be walking through a legitimately deep dep tree
<infinity> Well, autopkgtest still seems remarkably buggered, so I'm in no rush to let open the world.
<infinity> Though we could probably thaw the queue and just keep britney in block-all for now.
<cjwatson> # TODO: would be much more elegant to reduce our recursion depth!
<cjwatson> sys.setrecursionlimit(2000)
<infinity> Hah.
<cjwatson> cranking to 3000 makes it go away, LA LA LA
<infinity> Make it 9000?  We have a lot more CPU and RAM than we had when that was written.
<infinity> And then get someone to do a production cowboy...
<cjwatson> I don't want to overdo it, 3000 should be fine
<infinity> Heh.
<infinity> Are we using the packaged germinate in production?
<cjwatson> Yeah but a backport
<infinity> If so, turning around an SRU with that 1-char fix in a few hours wouldn't hurt my feelings.
<infinity> Oh.
<cjwatson> Oh hey, it's just 2.8
<infinity> Yeah, I don't see a backport there.
<infinity> Unless it's not using the package.
<cjwatson> It should be
<cjwatson> Could you file a bug for me?
<infinity> Yup.
<infinity> cjwatson: https://bugs.launchpad.net/ubuntu/+source/germinate/+bug/1312478
<ubot2> Launchpad bug 1312478 in germinate (Ubuntu Trusty) "germinate's recursion limit is too low for utopic" [Undecided,New]
<infinity> cjwatson: targetted for trusty and precise SRUs.  I doubt anyone cares about non-LTS germinate sadness.
<cjwatson> yeah
<infinity> cjwatson: I wonder if we were literally just bumping up against the limit in trusty and something tipped us over, or if this is a sign of something going more deeply wrong.
<cjwatson> I didn't trace the whole stack, but it didn't look horrible
<cjwatson> And it finishes very quickly after I bump the limit
<infinity> Might be worth throwing a counter in and seeing if ubuntu.trusty gets us in the 1900s or something.  Cause if we've gone from, say, 800 to 2500, that would perhaps point to, if not a germinate bug, us creating a Very Hard to Sort dependency tree.  Which could also anger apt's resolver.
<cjwatson> mm, not tonight though
 * infinity nods.
<infinity> cjwatson: In lieu of trying to SRU in a hurry tonight, I might just get a GSA to cowboy your s/2000/3000/ fix in production, under the assumption that the SRU will just overwrite that in a few days.
<cjwatson> Yeah that should be fine
<cjwatson> But I'll do the SRUs shortly
<cjwatson> Though I'd like to go to bed; indeed if I can do the SRUs tomorrow morning that'd be better
<cjwatson> http://bazaar.launchpad.net/~cjwatson/germinate/trunk/revision/552
<infinity> Ta.
#ubuntu-release 2014-04-25
<infinity> cjwatson: Alright, cowboy looks good.  And, FWIW, if the SRU is the identical 1-char change we just cowboyed, I'm happy with "it works in production" as a valid SRU validation. :P
 * cjwatson nods
<doko> infinity, known. waiting for the testresults, and then a re-upload
<infinity> doko: Ta.
<wgrant> infinity, cjwatson: ... sob
<infinity> wgrant: Fixed now, you missed the excitement. ;)
<wgrant> infinity: I sobbed at the recursion limit.
<infinity> wgrant: Ahh.  Yeah, that does seem a bit special.
<sil2100> Hello SRU team! We have some packages in the UNAPPROVED queue that are SRU-ready - I'm talking here about compiz, unity and qtorganizer5-eds at least
<sil2100> Would it be possible for someone to take a look at those in some free cycle?
<sil2100> Thank you!
<cjwatson> wgrant: Yeah, it's unfortunately fundamentally highly recursive as written, rather hard to disentangle
<cjwatson> I think it would be possible to trim about a quarter of the stack depth without too much invasiveness (there are a couple of tail calls that could be pulled out manually), but anything more would be a deep rewrite
<cjwatson> apt probably doesn't have anything like the same problem - it marks everything it's asked for and then repeatedly sweeps over the package cache looking for uninstallables and ways to resolve them, AIUI
<cjwatson> germinate is quite a lot more naÃ¯ve
<cjwatson> stgraber: I think queuebot is asleep
<doko> ScottK, are you planning to merge ruby-defaults too?
<stgraber> cjwatson: restarted. I guess it didn't like yesterday's DoS
<Laney> Please reject that
<Laney> Not that
<cjwatson> Laney: done
<Laney> Cheers
<bregma> hey folks, I have unity and compiz pending in the UNAPPROVED queue with some important SRU bug fixes for 14.04 that need to be unleashed into the wild, if someone would please take a look I would value your alacrity
<ScottK> doko: again?  I already did once to make 2.1 the default.
<xnox> ScottK: "<doko> ahh, ruby-defaults is in place" in #-devel after that message.
<ScottK> xnox: Thanks.
<seb128> is there any chance somebody could do some trusty SRUs review?
<seb128> infinity, bdmurray, arges, slangasek, stgraber: ^
<seb128> sorry for pinging, but some of those fix annoying LTS issues, would be nice to keep rolling even if it's slowly :-)
<arges> seb128: sure I can take a look, any specifically?
<seb128> arges, nautilus would be nice, it should be easy and we have other SRUs likely coming next week, so having the first one out of the way when that happens could be good
<seb128> arges, otherwise no, there is just a stack of items, seeing some landing, I don't want to hijack the queue or anything, just go in order
<seb128> arges, though compiz/unity might be nice as well
<seb128> since that's an important piece of our desktop and some annoying issues are resolved in the update
<seb128> thanks ;-)
<arges> seb128: for nautilus shouldn't the version be 1:3.10.1-0ubuntu8.1 instead of ubuntu9?
<seb128> arges, no
<seb128> we just need something > trusty and < u (if u exists)
<seb128> well, really > trusty, != u-versions
<arges> so if we approve trusty then that version will be > u
<Laney> it'll be copied to u
<arges> seb128: Laney: so shouldn't this fix go into Utopic first? (Although I assume you'll sync soon with a later release)
<xnox> arges: typically we mass copy everything from t-proposed -> u, once u opens. but u is not open yet.
<seb128> arges, well, usually early in the cycle we SRU and pocket copy to the SRU to the new serie
<seb128> -to
<arges> xnox: seb128 OK. I'll make a note of this
<xnox> arges: that would be the case "utopic first" if and when utopic would open, it's still is frozen.
<seb128> xnox, well, even when new series are open we usually have been fine by doing SRU -> pocket copies to new serie in the first weeks after release
<Laney> At some point they usually say "stop doing that now"
<seb128> right
<Laney> But it's my understanding there's usually a little overlap at least
<doko> cjwatson, infinity: did we ask to create u chroots on the developer boxes?
<cjwatson> I didn't
<infinity> doko: Not yet, no.
<hggdh> is 12.10 EOL-ed already?
<xnox> hggdh: no EOL announce email, and https://launchpad.net/ubuntu/quantal says status:supported (for EOL is status:obsolete) => no it has not been EOL-ed yet.
<ogra_> wasnt it extended by 3 weeks or so ?
<ogra_> or 4
 * cjwatson removes the freeze block
<xnox> ogra_: well, i see no email from infinity which would say that.
<xnox> hggdh: there is no notice yet, once the notice will be out it will say when 12.10 will go EOL.
<ogra_> xnox, hmm, i thought there was one when the new schdule was announced
<hggdh> I thought it was originally announced for April 18th, this is why I am asking
<ogra_> (the switch to 9 months(
<xnox> hggdh: well that slipped. Cause there was no EOL email on ~18th of March.
<hggdh> xnox: so... are we going to EOL it now?
<xnox> hggdh: and 18th of april is probably just an arbitrary extrapolation from https://wiki.ubuntu.com/QuantalQuetzal/ReleaseSchedule
<Laney> arges: got 2 seconds to look at deboostrap/trusty too?
<infinity> hggdh: I'll send the warn email out today, it won't EOL for a few weeks, though I anticipate that all we'll support is critical CVEs for that extended time.
<hggdh> infinity: perfect, thank you
<arges> Laney: i'll take a look soon. bit busy  atm
<Laney> ok
<cjwatson> xnox: boost-defaults appears to be stuck on kdepim-dev?
<cjwatson> (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt)
<arges> Laney: ok debootstrap is good to go
<Laney> thanks!
<xnox> cjwatson: sounds about right, kdepim-dev always declares unsatisfyable dependends unless everything up to it has transitioned...
<xnox> cjwatson: do you want this fixed pre-dropping freeze?
<cjwatson> Not vital, I think
<infinity> Oh look, my vim migrated.  Time to upgrade to utopic.
<Laney> seriously, vim's my main motivator for an early upgrade
<xnox> infinity: Laney: phf emacs-goodies-el migrated a day ago =)
<infinity> Someone unblocked it just for you? :P
<cjwatson> I unblocked it since easy
<cjwatson> I think that was around the same time I accepted vim
<xnox> " i don't use it, might as well unblock" :-) ?! =))))
<cjwatson> Yeah, who cares if emacs breaks
<infinity> Indeed.
<Laney> rms
<cjwatson> It'll slow down its ascent to malevolent godhood
<Laney> He probably doesn't care if it breaks *in Ubuntu*, though.
<xnox> one day i might switch.... everytime i pick it up, i get distracted and run away from it.
<infinity> Laney: I think rms prefers to pretend we don't exist.
<Laney> Sounds like a winner to me
<doko> pitti, jibel: please repeat the binutils autopkg test. seems to be an internal issue
<doko> cjwatson, infinity: can you do something about the binutils autopkg test restart? ^^^
<jibel> doko, its is running
<jibel> started 35min ago
<doko> jibel, where can I see this?
<jibel> doko, only on the internal instance http://d-jenkins.ubuntu-ci:8080/job/utopic-adt-binutils/
<jibel> results are synced to the public jenkins when the job is done
<infinity> jibel: Do we ever plan to fix that situation and make things more transparent?
<jibel> infinity, yes we want to get rid of jenkins
<infinity> jibel: *cheer*
<infinity> jibel: Debian's CI UI is definitely easier to navigate.  Not sure if there's any inspiration to be found there.
<infinity> (And their logs border on readable...)
<jibel> infinity, there is some work with Antonio on debci
<xnox> binutils/i386 pass
<xnox> binutils/amd64 running
 * infinity lunching.
<jibel> binutils/amd64 pass
<xnox> lintian ~25m ETA
 * xnox off to buy chromecast
<highvoltage> xnox: nice, does it run ubuntu yet?
<infinity> So, not to crush anyone's spirits, but I'm not thawing utopic until binutils is fixed.  Hopefully, we'll get there soon.
<ScottK> Any spirit crushing is just a bonus then?
<infinity> Heh.
<ScottK> There's mail in the moderation queue for u-d-a if there's an admin around.
 * infinity looks.
<ScottK> Thanks.
<ScottK> Blame is officially passed.
<xnox> infinity: what's wrong with binutils?
<xnox> infinity: it passed autopakage test.
<ScottK> xnox: Look on #u-devel about two hours ago.
<xnox> ScottK: thanks.
<xnox> ScottK: and *sigh*
#ubuntu-release 2014-04-27
<xnox> bedtools adt run is odd -> requested to test src+binary version 2.19.1-1, jenkins executes source 2.17.0-1 which doesn't have adt tests.
<xnox> similar issue with epsilon.
<xnox> ipset
<xnox> haha retry does not help, it retries old version again none-the-less...
<darkxst> should daily iso'
<darkxst> s be spinning again now?
<darkxst> i.e. for Ubuntu GNOME
<darkxst> cjwatson, infinity, stgraber ^
<infinity> darkxst: Not yet.
<cjwatson> darkxst: No, we'll probably try turning them on tomorrow (assuming the livefs chroot creation ticket got resolved; haven't checked)
<darkxst> cjwatson, ok
<cjwatson> wgrant: Could you switch http://qa.ubuntuwire.com/ftbfs/ over to utopic when you get a chance?
<infinity> cjwatson: It's not resolved yet, AFAIK.
<infinity> cjwatson: Also, if you're around, do you happen to know a workaround for britney losing its mind over massive recursive sets?
<infinity> AIEEE: counter overflow: 7309 involved packages.
<infinity> AIEEE triggered by: libav
<infinity> That sort of thing.
<cjwatson> I don't
<cjwatson> You could block stuff until it's all ready per a transition tracker ...
<cjwatson> Then at least probably only the last run will take forever
<infinity> Oh, kay, so this doesn't end up being a failure to process things, it's just telling me it hates me?
<infinity> Blocking the three problematic packages for now would be simple.
<infinity> gst-plugins-bad1.0, libav, rtmpdump
<infinity> Let's try that for now and revisit in the $later.
<cjwatson> Yeah, I don't understand it properly but I think the effect is that it gives up on some paths and then spends $forever backtracking
<cjwatson> But it doesn't actually cause a failure directly
<infinity> I expect xnox will yell at me later about blocking one of his transitions, but we'll sort that out in a bit.
<cjwatson> However it does tend to cause p-m runs to take hours, so it's best avoided
<xnox> infinity: cjwatson: do block libav, and portions of ghc.
<xnox> they can be easily worked of a tracker.
<cjwatson> ghc doesn't usually cause counter overflows?
<xnox> i think it's something else though, libraw or some such?
<wgrant> cjwatson: Oh yeah, I should do that.
<xnox> infinity: do it as a bug, that way anybody can cancel it once ready.
<infinity> xnox: It's the three I mentioned.
<cjwatson> xnox: I'll babysit ghc as usual, I imagine; it shouldn't need blocking
<xnox> infinity: yeah, block, there are logs to see past runs anyway to figure out what needs doing.
<infinity> cjwatson: Any cleanup need doing if one kills britney mid-run?
<infinity> Cause I'm sick of waiting on this one to finish. :P
<cjwatson> infinity: Shouldn't be
<infinity> Oh, it might be near done anyway.
<infinity> They've been ~4h each since this started, and this is 2.5 in...
<infinity> Err, 3.5
<infinity> Meh.
<infinity> Screw it.  Killing.
<infinity> Oh, there were a few other triggers too.  Bother.
<cjwatson> They might be enough smaller than libav not to matter as much
<infinity> AIEEE: counter overflow: 3217 involved packages.
<infinity> AIEEE triggered by: openjpeg
<infinity> Still seemed pretty big. :P
<infinity> I've just blocked every trigger for now to see if that happies things up, then we can peel back the damage.
#ubuntu-release 2015-04-20
<rbasak> I'd like to upload a fix for the apport hook in mysql-5.6. Currently it doesn't get installed at all.
<rbasak> I think no images have been rolled yet so this should be OK?
<pitti> rbasak: yes, and we're still working on some installer fixes anyway
<rbasak> OK thanks!
<rbasak> Just testing my fix now. Should be done in an hour or two (it takes a while to build!)
<pitti> rbasak: oh, you could just copy the fixed hook into your test env?
<rbasak> pitti: I could, and that works. But that doesn't check if I screwed something up in packaging. Which I did in my first attempt :)
<jibel> infinity, bug 1446231
<ubot93> bug 1446231 in console-setup (Ubuntu Vivid) "debconf prompt during upgrade from Utopic to Vivid desktop" [High,New] https://launchpad.net/bugs/1446231
<diwic> Hi, I'm wondering if a bug is critical enough to upload a fix right now or if I should wait for the SRU period. It's bug 1445358
<ubot93> bug 1445358 in pulseaudio (Ubuntu) "Pulseaudio fails to run when system's language is in certain non-English locales" [High,In progress] https://launchpad.net/bugs/1445358
<infinity> diwic: Is it pulseaudio that's broken, or the langpacks?
<infinity> pitti: ^
<diwic> infinity, pulseaudio
<infinity> diwic: Either way, I think it's worth fixing.
<diwic> infinity, ok, I'll prepare an upload then
<infinity> diwic: The way I'm reading the bug, it sounded like the langpacks were broken, since they say recompiling the .mo from the PA source and slapping it in place works.
<infinity> diwic: But I'm happy if you tell me otherwise.
<diwic> infinity, I think that might be if somebody localised things on an Ubuntu level instead of upstream level
<diwic> infinity, somebody localised "yes" in a function where it should not have been localised and so pulseaudio is confused when it tries to parse e g "ja" instead of "yes"
<infinity> diwic: Sure, but I think PA is stripped, so if you fix the package, we still need to fix the langpacks.  Which we can probably manage, but we'll see.
<infinity> diwic: Anyhow, fix the package, and we'll sort out the next steps.
<diwic> infinity, but if I change the package not to localise the "yes" will it require fixing the langpacks too? Will there not just be an unused translation of "yes" in them?
<infinity> diwic: Oh, that might indeed work.
<infinity> diwic: Let's see the diff, and w'ell figure it out from there.
<diwic> ok
<flexiondotorg> infinity, Is this bug still on the cards? https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1434579
<ubot93> Launchpad bug 1434579 in virtualbox (Ubuntu) "Unable to install VirtualBox Guest Service in 15.04" [High,Confirmed]
<infinity> flexiondotorg: Yeah, I'm going to try to squeeze it in.
<flexiondotorg> infinity, Excellent.
<flexiondotorg> infinity, Are you aware of this? - https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1445622
<ubot93> Launchpad bug 1445622 in gvfs (Ubuntu) "Trash directory unable to be found" [High,Confirmed]
<infinity> flexiondotorg: I'm aware of it.  Unless someone proposes a decent fix, I don't consider it RC.  Not being able to use the trash in the live environment isn't, IMO, a bug, and the error message is just cosmetically icky.
<infinity> flexiondotorg: The MATE behaviour of telling you the trash doesn't work and offering a permanent deletion is fine, some of the other flavours are a bit more ugly, but it's not world-ending.
<flexiondotorg> infinity, Oops. I pasted the wrong link.
<flexiondotorg> infinity, I agree that one is not RC.
<flexiondotorg> infinity, This one however? - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1359689
<ubot93> Launchpad bug 1359689 in linux (Ubuntu Vivid) "cryptsetup password prompt not shown" [Critical,Triaged]
<infinity> flexiondotorg: That's more bad, but also not a regression from utopic, as far as I can tell form the bug log.
<infinity> flexiondotorg: So, I'd love to see it fixed, but I'm not going to lose sleep over it either.
<infinity> flexiondotorg: It also seems to be more than one bug mixed together in the comments, given that some say 3.19 fixes it, and some don't.
<wxl> infinity: would you be so kind as to accept lxsession 0.5.2-0ubuntu2 so that lxde doesn't have all sorts of annoying permission issues? https://bugs.launchpad.net/ubuntu/+source/lxsession/+bug/1424362/comments/53
<ubot93> Launchpad bug 1424362 in lxsession (Ubuntu Vivid) "permissions issues in LXDE as of Vivid Lubuntu Final Beta" [High,Fix released]
<infinity> wxl: It's been in the release pocket for 4 hours already.  So, sure.
<infinity> wxl: https://launchpad.net/ubuntu/+source/lxsession/0.5.2-0ubuntu2
<wxl> oh derp i'm behind. thanks infinity :)
<wxl> now to schedule a rebuildâ¦
<flexiondotorg> infinity, https://bugs.launchpad.net/ubuntu-mate/+bug/1443525 - Reproduced on Ubuntu in the live session and installed system using current 15.04 daily.
<ubot93> Launchpad bug 1443525 in ubuntu-mate "liblibsmb segfaults browsing Windows Shares with Caja or Nautilus" [Undecided,New]
<infinity> flexiondotorg: Doesn't look RC to me either, but reassigning to samba at least.
<wxl> thx pitti!
<pitti> wxl: what?
<wxl> pitti: https://www.google.com/url?q=https%3A%2F%2Fbugs.launchpad.net%2Fbugs%2F1445587&sa=D&sntz=1&usg=AFQjCNFhcT2lTz3eYJZQ04bdLjn392t2ug
<wxl> argh stupid google urls
<wxl> bug 1445587
<ubot93> bug 1445587 in ubiquity (Ubuntu Vivid) "Installer hangs after clicking "Restart Now"" [High,Fix committed] https://launchpad.net/bugs/1445587
<pitti> wxl: oh, you're welcome :) that took all day :(
<wxl> yikes bummer
<pitti> wxl: I went off the completely wrong path initially
<wxl> pitti: happens sometimes
<wxl> balloons: that bug 1445587 will probably require a rebuild/addendum to your call for testing âº
<ubot93> bug 1445587 in ubiquity (Ubuntu Vivid) "Installer hangs after clicking "Restart Now"" [High,Fix committed] https://launchpad.net/bugs/1445587
<balloons> wxl, I tried to wait until today to re-send the announce to get past some of these initial bugs :-)
<balloons> there will always be something eh?
<wxl> indeed, indeed
<balloons> better to get more folks attacking things early
<wxl> i already got through our second rebuild XD
<wxl> pitti: i'm not sure if you';re the right guy for this but i see the new ubiquity is in the proposed pocket. will that eventually get moved to release, so i can schedule a rebuild?
<micahg> infinity: will there be a round of ubuntu-archive removal bugs processed before release?  it seems there are quite a few out there
<ianorlin> pitti: I still have the enter not getting it to restart after the install problem on my laptop
<wgrant> ianorlin: With which image?
<ianorlin> 4f6a788d674eef64a81ca0bf03b97ef0  vivid-desktop-amd64.iso
<ianorlin> for 420.1 which just got respun with the fix
<wxl> wgrant: yeah pitti's 2.21.23 is in the manifest
<wxl> so it SHOULD work
<wxl> balloons: are you going to rebuild for reboot now fix? it seems based on some limited testing it's not working for us
<balloons> wxl, infinity owns the controls for this release
<balloons> wxl, that said I don't see why not, but it'll likely get bundled
<wxl> balloons: it seems that no image has the update in it. it would have to be at least version 20150420. i think we're the only ones. if you have anyone to verify that might save others the trouble of rebuilding.
#ubuntu-release 2015-04-21
<tjaalton> RAOF: doing sru's today? could you ack libdrm & xtrans backports to trusty?
<RAOF> tjaalton: Tomorrow is my SRU day, but sure.
<tjaalton> ah
<tjaalton> ok
<tjaalton> thx
<tjaalton> the wiki is out of date then :)
<RAOF> No, I'm on Tuesday in US time :)
<RAOF> tjaalton: Heh. libdrm-tegra0 needs a description fix. I'm pretty sure it's not the accessor to exynos-specific DRM services :P
<RAOF> Also, are we absolutely sure that no-one uses the drmAllocCpy symbol that's been dropped?
<tjaalton> bah, maarten added tegra
<tjaalton> I think the symbol was made non-public
<RAOF> That's no different from being dropped :P
<tjaalton> right.. but
<tjaalton> I'll dig up the log
<tjaalton> RAOF: http://sprunge.us/KQUH
<RAOF> Yeah, so that technically breaks ABI.
<RAOF> And when I say âtechnicallyâ, what I mean is âthat absolutely breaks ABIâ.
<RAOF> But it's unlikely that anyone's using that symbol...
<tjaalton> noone complained so far
<RAOF> Right.
<RAOF> Of course, that commit *also* hasn't been in an LTS release :)
<tjaalton> yep, new in 2.4.60
<RAOF> tjaalton: Hm, how about I reject that, you fix the tegra description and un-staticise that symbol, and then I'll accept?
<tjaalton> o
<tjaalton> k
<tjaalton> fixing vivid too then?
<RAOF> The description, sure.
<RAOF> I don't expect that symbol to be used anywhere outside of libdrm, but would feel *really* stupid if I ACKd the SRU and it broke something.
<RAOF> Cost-benefit is a bit different for vivid :)
<tjaalton> right
<tjaalton> hm, screw vivid, it'll get fixed once carrizo support is added
<tjaalton> RAOF: uploaded
<RAOF> (You probably mean *fix* a typo in your changelog âº)
<tjaalton> oh I forgot the fix part
<tjaalton> reject and I'll try again!
<tjaalton> uploaded the new
<tjaalton> rejected the faulty one myself
<RAOF> Oh, ta.
<tjaalton> thanks!
<tjaalton> it'll end up in NEW, so the drama continues ;)
<RAOF> :)
<RAOF> That's nice and quick!
<tjaalton> yeah
<tjaalton> hmm does that hold amd64 back though? that's all I care for testing
<RAOF> I think you should have all the !armhf stuff in trusty-proposed.
<tjaalton> right, that's greta
<tjaalton> -at
<elfy> pitti: I saw the fix release against the remove media bug - did a rebuild for me, on vbox it just fails to start live session
<elfy> same in kvm
<infinity> micahg: Yeah, there will be more AA stuff.
<infinity> wxl: There will be rebuilds this morning for people who didn't rebuild their own.
<pitti> Good morning
<pitti> elfy: downloading xubuntu daily now and having a look
<pitti> elfy: ah, I see it; that's plumbed together differently on xubuntu, so I didn't see that on ubuntu
<flexiondotorg> pitti, How is Xubuntu different? I have new Ubuntu MATE image building and I am wondering if I'll run into the same issue?
<pitti> it's not different in the end, I just didn't test the code path that elfy meant
<pitti> selecting live or install on gfxboot both works, but not selecting "try live session" in ubiquity-dm
<flexiondotorg> pitti, Understood.
<flexiondotorg> pitti, What change caused the regression?
<pitti> in http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/revision/6294
<pitti> looking for the "Try live" button now, we need to start the real DM there too
<flexiondotorg> pitti, Thanks.
<flexiondotorg> pitti, Might this also interfere with oem-config once the system has been prepared?
<pitti> flexiondotorg: no, oem-setup has its own .service
<pitti> (and .upstart)
<flexiondotorg> pitti, Ah. Of course.
<darkxst> pitti, yes very much you need to launch the real dm at that point!
<wgrant> infinity: https://launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-archive
<wgrant> https://launchpad.net/ubuntu/vivid/+bugs?field.subscriber=ubuntu-archive is also relevant, but empty.
<darkxst> otherwise every flavour will be broken
<pitti> elfy, darkxst, flexiondotorg, infinity: fixed ubiquity uploaded (with the revert), sorry for messing that up
<darkxst> pitti, I assume, all that worked under ubuntu, display-manager.service is lightdm specific?
<pitti> darkxst: no, it most likely has the same problem
<pitti> display-manager.service applies to all DMs
<darkxst> pitti, that is what I figured, but though you might have tested things before uploading
<pitti> darkxst: I tested selecting live and install from gfxboot
<pitti> but gfxboot doesn't have an option for the maybe-ubiquity mode, so I missed that, sorry
<pitti> now I know about "maybe-ubiquity" :)
<darkxst> pitti, np, i'm more curious about actually fixing the race, but alas no time this week
<pitti> darkxst: which race now?
<pitti> we fixed the shutdown race and the one with oem-config yesterday
<darkxst> probably that, though this was related
<tjaalton> infinity: libdrm and xtrans are now in trusty-proposed, llvm-toolchain-3.6 just got uploaded
<tjaalton> infinity: upgrade and downgrade works, though downgrade needs 'apt install xserver-xorg libegl1-mesa-drivers xserver-xorg-video-all xserver-xorg-input-all' to pull everything
<tjaalton> so once llvm is acked and past NEW, I could start pushing stuff to proposed
<tjaalton> actually could start from the server
<tjaalton> apt-get remove .*lts-vivid works for downgrade
<bregma> hey folks, how do I get may latest Unity package (fix for #1446256) properly ACKed and moved from -proposed to -release so it gets on the image?
<flexiondotorg> infinity, Are all the desktop flavours going to get a rebuild?
<sil2100> popey: btw. was there a final decision on whether we should re-publish today scope in the store?
<popey> sil2100: not my decision. I asked you! :)
<sil2100> Just wanted to know if you got an override from victor or someone else ;)
<infinity> flexiondotorg: They all got a rebuild this morning, but there will be more rebuilds, yes.
<infinity> flexiondotorg: That shouldn't stop people from testing anyway.
<flexiondotorg> infinity, Am doing :)
<flexiondotorg> infinity, Just checking if the "final" rebuild was down to me.
<infinity> flexiondotorg: No, I'm keeping track.
<flexiondotorg> infinity, Thanks.
<flexiondotorg> infinity, I have a patch that fixes this - https://bugs.launchpad.net/ubuntu-mate/+bug/1445198
<ubot93> Launchpad bug 1445198 in ubuntu-mate "Failed script for encrypt home after installation" [Medium,Confirmed]
<flexiondotorg> infinity, I've discussed it with the Debian maintainers and we have decided I should deviate the Ubuntu mate-terminal package.
<flexiondotorg> infinity, What version should I give the new mate-terminal package for Ubuntu?
<infinity> flexiondotorg: Wait, that's a bug in the terminal?
<infinity> flexiondotorg: Anyhow, a new version would be 1.8.1+dfsg1-4ubuntu1
<flexiondotorg> infinity, Yes. mate-terminal.wrapper doesn't support double quoted strings.
<infinity> flexiondotorg: Which is what you get by default running "dch -i" on an Ubuntu system.
<flexiondotorg> infinity, If I prepare a debdiff would you accept it?
<infinity> flexiondotorg: I'll review it.  I won't promise I'll accept it unless it's correct. ;)
<flexiondotorg> infinity, Sounds fair :)
 * ogra_ tickles the publisher with a feather ... run publisher, run ... 
<flexiondotorg> infinity, Could you review this please? https://bugs.launchpad.net/ubuntu-mate/+bug/1445198/comments/7
<ubot93> Launchpad bug 1445198 in ubuntu-mate "Failed script for encrypt home after installation" [Medium,Confirmed]
<flexiondotorg> I'd like to file a sync request for mate-tweak from Debian unstable. It fixes a bug and adds translations. The package has not previously been synced from Debian so that changelog and history are different from the Ubuntu package.
<flexiondotorg> Is there anything special I need to do.
<infinity> flexiondotorg: I can sync it, lemme just look at a debdiff first.
<jdstrand> fyi, I'm deleting apparmor-easyprof-ubuntu-snappy from the archive since we now use ubuntu-core-security instead
<flexiondotorg> infinity, Shall I raise a request sync?
<infinity> flexiondotorg: I already synced it.
<flexiondotorg> infinity, Brilliant. You star!
<infinity> jdstrand: Does it have any rdeps?
<flexiondotorg> infinity, And thanks :)
<infinity> adconrad@nosferatu:~$ reverse-depends src:apparmor-easyprof-ubuntu-snappy
<infinity> Reverse-Depends
<infinity> ===============
<infinity> * ubuntu-snappy                 (for apparmor-easyprof-ubuntu-snappy)
<infinity> jdstrand: ^
<infinity> jdstrand: I feel like maybe that should be fixed before you delete things. :P
<jdstrand> that seems not correct
<jdstrand> it isn't on the image and http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.vivid/rdepends/ALL/apparmor-easyprof-ubuntu-snappy shows nothing and it fell out of main today
<cjwatson> reverse-depends has a bit of lag.
<cjwatson> That's why checkrdepends still exists on ubuntu-archive@snakefruit, although in general it's less convenient because it requires a local dists mirror.
<cjwatson> Still, I think that is in fact still current.
<cjwatson> germinate rdepends only shows anything if it goes via something that's seeded, and snappy isn't in the ubuntu.vivid seeds.
<infinity> jdstrand: It fell out of main because ubuntu-snappy isn't in main.
<cjwatson> Hm, actually, ubuntu-snappy is in system-image ...
<infinity> flexiondotorg: That mate-terminal change is rather substantial.  Not that I thikn switching from python to perl isn't a wonderful thing, but I suspect you could have fixed your bug in a few lines instead of a new scripts.
<cjwatson> Is there a Provides maybe?
<jdstrand> I should mention that ubuntu-core-security-apparmor uses a Provides: apparmor-easyprof-ubuntu-snappy
<infinity> jdstrand: Ahh.  You should have mentioned that, yes. :)
<cjwatson> Yeah, so that'll satisfy germinate and apt, but shouldn't the dependency be updated anyway?
<jdstrand> it should
<jdstrand> I'll adjust that too
<cjwatson> Also surely should be Conflicts/Replaces/Provides rather than Breaks/Replaces/Provides.
<infinity> jdstrand: Also, that shouldn't be Provides/Breaks/Replaces, it should be Provides/Conflicts/Replaces.
<jdstrand> cjwatson: it actually doesn't Conflicts
<infinity> jdstrand: C/R is what triggers package managers to swap packages.
<infinity> jdstrand: It doesn't matter if it actually has file overlaps, if the goal is to have them not installed together (which is what I assume from your breaks).
<cjwatson> Right, Conflicts/Replaces is a special thing that has distinct semantics.
<cjwatson> See policy 7.6.2.
<infinity> cjwatson: Did you look that up, or have you quoted it enough to have it burned in?
<cjwatson> I looked it up. :-)
<flexiondotorg> infinity, That mate-terminal.wrapper patch has been submitted upstream. Where I am an upstream developer.
<flexiondotorg> infinity, We try to align with GNOME where possible these days.
<infinity> flexiondotorg: I guess diffing with gnome-terminal.wrapper might make it more reviewable.
<flexiondotorg> infinity, It is a 4 char diff if you do that :)
<infinity> flexiondotorg: Right, lemme grab the diff, apply it, look at it locally, and upload for you if it looks sane.
<flexiondotorg> infinity, Many thanks. I have build the revised package in a PPA and tested it works.
<infinity> flexiondotorg: Which version of gnome-terminal did you copy that from?  It's very whitespace-different from the one on my system.
<infinity> flexiondotorg: But a diff with -b (ignore whitespace) shows that it's the same, yes.
<flexiondotorg> infinity, I cleaned up the whitespace because it is wrong in gnome-terminal.wrapper.
<infinity> flexiondotorg: "wrong"? :P
<infinity> flexiondotorg: if you're forking someone else's tool, it generally pays to keep it close to identical, so it's easier to cherry-pick in the future.
<jdstrand> fyi, ubuntu-snappy trunk already removed reference to apparmor-easyprof-ubuntu-snappy, so the next upload will resolve that side
<infinity> flexiondotorg: I mean, it's your call, it's your code, but I'd highly recommend not gratitously differing from gnome-terminal just to make it prettier.  *shrug*
<flexiondotorg> infinity, Just chatted with the other MATE devs. We are happy with the cleaned up whitespace in my patch.
<infinity> flexiondotorg: Mmkay.
<infinity> flexiondotorg: http://launchpadlibrarian.net/203927315/mate-terminal_1.8.1%2Bdfsg1-4_1.8.1%2Bdfsg1-4ubuntu1.diff.gz <-- That's what I uploaded.  Look fine?
<infinity> flexiondotorg: I fixed one of your other patches too, which was missing a trailing line, and ran update-maintainer.
<flexiondotorg> infinity, Just looking now...
<flexiondotorg> infinity, Look good. Thank you.
<jderose> infinity: FYI, oem-config isn't getting installed in oem-mode with 20150421.1
<jderose> infinity: if i recall, you said this happens when your local repo is out of sync when build the ISO?
<flexiondotorg> jderose, What is your oem-config issue exactly?
<flexiondotorg> jderose, I ask because I've had issue with for weeks, but as of earlier today (Ubuntu MATE rebuild) it is working, for me at least.
<flexiondotorg> jderose, And the OEM has also confirmed it working on their range of hardware.
<jderose> flexiondotorg: ubiquity-frontend-gtk, oem-config-gtk aren't installed after you do an oem-mode install... so you have to manually install them afterwards
<flexiondotorg> jderose, What flavour?
<jderose> ubuntu desktop
<flexiondotorg> jderose, I'll test that here now
<jderose> wasn't an issue with 20150421, but is with 20150421.1
<flexiondotorg> jderose, Sounds worrying.
<jderose> it frequently happens in daily ISO during the dev cycle, i think it's something infinity can easily fix :)
<infinity> jderose: Yeah, it's version skew, I'll make sure that's fixed before tonight's respin.
<jderose> infinity: cool, thanks!
<elfy> infinity: any reason for me not to rebuild xubuntu?
<infinity> elfy: I'll be rebuilding the world very soon, don't do it.
<elfy> ok - just concerned about time is all - I'd like to see a booting one for me before 2200 - when I will promptly crash till tomorrow :)
<Odd_Bloke> infinity: What's the rebuild for; will it affect cloud images?
<infinity> Odd_Bloke: Depends on when you last built your cloud images.
<Odd_Bloke> infinity: Since midnight UTC?
<infinity> Odd_Bloke: You're missing the latest libaudit update, so yes.
<Odd_Bloke> *sobs gently in to his beer*
<infinity> Odd_Bloke: Welcome to release week?
<Odd_Bloke> Why do you think I bought the beer? :p
<infinity> Odd_Bloke: If Friday's images were perfect, we'd not block off a week to do this. :P
<flexiondotorg> infinity, I appreciate you have a lot going on right now but is the virtualbox-guest-x11 drivers issue still ear marked for getting fixed? https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1434579
<ubot93> Launchpad bug 1434579 in virtualbox (Ubuntu) "Unable to install VirtualBox Guest Service in 15.04" [High,Confirmed]
<infinity> flexiondotorg: Yes.
<infinity> flexiondotorg: Just crazy busy.
<flexiondotorg> infinity, I can't imagine. But thank for getting back to me :)
<wxl> infinity: should i rebuild again for any reason?
<Ukikie> He's going to rebuild world soon.
<jibel> wxl, there is one more ubiquity fix coming
<wxl> jibel: great, thanks for the heads up. i assume we'll get a global rebuild?
<jibel> wxl, yes
<wxl> jibel: is this expected to complete today?
<jibel> wxl, yes, likely today
<wxl> k thanks jibel !
<Laney> glib2.0 fixes that trash bug in the installer (probably)
<Laney> up to you if you want to get that in for the respin or not
<Laney> s/installer/live environment/
<infinity> Laney: I'm reviewing it.
<jderose> infinity: when are you planning on spinning the next ubuntu desktop daily iso?
<robru> infinity: can you approve ubuntu-ui-toolkit? pitti wanted it but couldn't wait for the silo to publish
<slangasek> robru: what does "couldn't wait for the silo to publish" mean?  It looks like this is a copy from the silo
<robru> slangasek: it means that pitti wanted this but needed to EOD. so he's not here to advocate for it, I'm requesting it on his behalf.
<slangasek> ok
<infinity> robru: Can do.
<robru> infinity: thanks!
<cyphermox> release team: I'd have two fixes which may be nice to land before release, one for console-setup ^
<cyphermox> and the other for partman-multipath.
<slangasek> infinity: ^^ console-setup is your debconf prompt on upgrade bug; the multipath one is an issue with multipathd offhandedly corrupting your disks
<slangasek> I think technically both could go to 0-day SRU as neither impacts the installer per se
<cyphermox> true
<slangasek> cyphermox, infinity: oh, I just noticed the multipath change is a partman workaround, not a fix for multipath-tools itself... that of course needs to go into the installer proper...
<slangasek> partman-multipath isn't in the initramfs itself, but I'm not sure if d-i will pull components from -updates in all circumstances
<slangasek> it looks like it "only" requires a respin of ubuntu-server and lubuntu
#ubuntu-release 2015-04-22
<jderose> is it expected that when doing a vivid encrypted home folder install (ecryptfs), grub should prompt you for a passphrase at boot?
<jderose> is this a regression, or have things just changed in terms of how the encrypted swap partition gets unlocked?
<cyphermox> jderose: no, I don't think you should get prompted on boot for anything when it's for an encrypted home folder.
<cyphermox> especially since that would break having multiple users with encrypted home folders, unless they shared a password for swap :P
<jderose> cyphermox: gotcha, thanks... looking into it now. this was from a System76 "golden imaged" installed under qemu in oem-mode... so seeing if it's an issue on normal installs
<cyphermox> I may be wrong though -- if it's not working you might want to make sure your image is up to date I guess?
<jderose> also noticed there were a number of packages marked as auto-removable after this too, so that might be related
<jderose> cyphermox: i could see entering the passphrase (potentially) making sense when resuming from suspend, but you're right that it really doesn't make sense when cold-booting a potentially multi-user system
<cyphermox> even if you resume, you have no guarantee the same user is trying to resume, again on a multi-user system
<jderose> yeah, true
<cyphermox> not that I expect multi-user to be such a common use case, but still :)
<jderose> hmm, didn't happen on a normal user install. might be related to my work-around for oem-config-gtk and friends not being installed after doing an oem-mode install
<jderose> seems like when i `sudo apt-get install ubiquity-frontend-gtk oem-config-gtk` to work around them being missing after doing an oem install from the latest daily iso, i might need to use --no-install-recommends... without it, some suspect looking packages are being drug in
<tyhicks> jderose: hey - just passing through but, no, there's nothing in Ubuntu proper that would cause you to be prompted at boot for an ecryptfs encrypted home directory
<jderose> yup, --no-install-recommends seems to solve it. likely there is an underlying bug here, but probably something that will (for most users, even oem install) resolve itself after the next iso build
<jderose> tyhicks: gotcha, thanks!
 * jderose now tries a normal user bare-metal install...
<jderose> normal user install seems fine... no passphrase prompt from grub, no autoremove-able packages after the install completes
<tyhicks> good to hear
 * tyhicks steps away
<flexiondotorg> Is world currently being rebuilt?
<elfy> doesn't appear to be so
<elfy> we did a rebuild a few ago it seems
<elfy> still got issues - though hardware does boot and shutdown properly
<flexiondotorg> flexiondotorg, OK, I'm going to kick a rebuild of Ubuntu MATE then.
<elfy> vbox fails miserably
<flexiondotorg> elfy, What issues are most pressing for you?
<elfy> kvm works as you boot the try from the first menu and not the fancy dialogue
<flexiondotorg> elfy, I'm aware of VBox falling in a heap on restart. I did some testing to pitti regarding that.
<flexiondotorg> elfy, That issue about trying a live session from the Ubiquity DM is still there?
<flexiondotorg> That is why I was going to rebuild, I thought that was fixed.
<elfy> kvm 32 bit works from the fancy dialogue, 64 bit in kvm from there fails to start desktop
<flexiondotorg> elfy, OK. Thanks.
<elfy> I'm not sure if the various fixes infinity was waiting for actually landed or not
 * flexiondotorg is conflicted. Not sure if a rebuild is wise.
<elfy> well - it might be useful if you want to see if you get different fail points I suppose
<flexiondotorg> elfy, Just got to that place with my thinking.
 * flexiondotorg is rebuilding.
<flexiondotorg> elfy, The powerpc testers has found bugs with partitioning in Ubiquity. Can you do some partitioning tests on x86 to see if this is a general issue?
<elfy> not now - my little window of checking stuff before work is almost closed - sorry
<flexiondotorg> elfy, OK. I'll try and do it later too :)
<elfy> flexiondotorg: actually - any sort of partitioning in live or a particular sort?
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1446792
<ubot93> Launchpad bug 1446792 in ubiquity (Ubuntu) "ubiquity installer crashes during partition" [Undecided,New]
<elfy> flexiondotorg: looks ok - it's installing after resizing and creating new partition now
<elfy> well I guess pitti et all will carry on trying to fix this all
<pitti> I pretty much gave up on vbox
<elfy> mmm
<pitti> if you shut down X, the X driver leaves teh graphics cards in a broken state
<elfy> well I get fails in kvm too
<pitti> I only see these vertical stripes garbage, and that's it
<elfy> oh I don't get that - just some text sitting there :)
<pitti> that doesn't look like something we can fix today (and not me personally, I have no clue about X drivers)
<pitti> elfy: even with latest casper?
<elfy> I am at least positive about hardware - that works :)
<pitti> yep, we are testing real hardware and qemu here with every change
<elfy> pitti: no idea what casper it is - was expecting a global rebuild overnight - didn't appear to be one, we did a xubuntu one seemingly
<infinity> elfy: Yeah, global rebuild didn't happen because things ended up trapped in -proposed, and I'm waiting on a last PAM fix.
<elfy> pitti: well running xubuntu in kvm I get various results
<elfy> infinity: ack
<infinity> pitti: Any ideas about the ubuntu-system-settings-online-accounts autopkgtest failure?
<pitti> infinity: not yet; I started a local run, I'll look at it first thing after breakfast
<pitti> infinity: it seems odd that it started failing on /sbin/initctl yesterday; perhaps a fallback path when the primary code path stopped working
<elfy> well - real life calls me off to work now - I'll catch up on the fun later
<flexiondotorg> pitti, I know you've decide to give fixing VirtualBox restarts a pass for 15.04. But what component is the bug actually in? Ubiquity, Casper, etc?
<flexiondotorg> pitti, I've had a bugs raised against Ubuntu MATE and I want to file it correctly.
<pitti> flexiondotorg: not sure, virtualbox-guest-x11 perhaps? but I figure we don't have that installed by default, I figure it falls back to some generic -vesa driver or whatever
<flexiondotorg> pitti, virtualbox-gues-x11 is not installed by default but the dkms moule is part of the kernel package now.
<flexiondotorg> pitti, This is the squashfs error I am refering too.
<pitti> flexiondotorg: for that I'd start with casper for now (we don't know the real reason yet, but it's a good place to start)
<flexiondotorg> pitti, Thanks.
<Odd_Bloke> I see that the new pam has hit vivid-proposed; when will it migrate?
<Odd_Bloke> infinity: ^ ?
<infinity> Odd_Bloke: Ideally soon.
<rbasak> Looks like the openssh dep8 test failed due to an unrelated timeout.
<rbasak> Ah, and already rerun and passed this time. Thanks.
<rbasak> Odd_Bloke: FYI, pam is in the release pocket now.
<Odd_Bloke> rbasak: Great, thanks!
<Odd_Bloke> Now we play the waiting (for mirrors) game.
<rbasak> Your image builds depend on mirrors?
<Odd_Bloke> We build the base image on the buildds, but then the rest happens on jerff which will hit the mirrors.
<rbasak> Oh. Waiting for mirrors for images to mirror, rather than for the new pam to mirror. I understand now.
<infinity> Rebuilding the world now.  Hopefully these are final.
<elfy> infinity: I popped in from work at just exactly the right time to see what was happening it seems :)
<infinity> LocutusOfBorg1: ^-- This is the vbox upload that you should be able to merge entirely into Debian.
<Riddell> what's new in these images?
<infinity> Riddell: Depends on when your last one was.  Diffing your manifests would help.
<infinity> Riddell: At the very least, there's a PAM fix, but might also be ubiquity and other bits.
 * Riddell plays the pam pam tune on spotify
<flexiondotorg> infinity, Does the new virtualbox package fix this? -> https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/1434579
<ubot93> Launchpad bug 1434579 in virtualbox (Ubuntu) "Unable to install VirtualBox Guest Service in 15.04" [High,Confirmed]
<infinity> flexiondotorg: Yes.
<flexiondotorg> Excellent. Will test.
<infinity> flexiondotorg: There will still be one "useless" item listed, but it will now let you install the x11 driver, which makes it all work.
<flexiondotorg> infinity, Great. Many thanks.
<LocutusOfBorg1> infinity, <3
<infinity> LocutusOfBorg1: If you pull that into sid, we'll just sync it back to w-series and kill the ubuntu fork.
<infinity> LocutusOfBorg1: Should be Debian-friendly, I didn't do anything that would break non-Ubuntu.
<LocutusOfBorg1> you removed .gitattributes... weir
<LocutusOfBorg1> d
<LocutusOfBorg1> should I really drop it?
<LocutusOfBorg1> -changelog merge=dpkg-mergechangelogs
<infinity> LocutusOfBorg1: Oh, that's because I build with "dpkg-buildpackage -i -I", which excludes VCS files.
<LocutusOfBorg1> ack
<LocutusOfBorg1> http://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/commit/?id=87db86590cc380594238c9b6746fb0bc278ec244
<LocutusOfBorg1> I gave you credits, I hope it is all ok
<infinity> LocutusOfBorg1: Looks good, though you didn't need to apply the gitattributes removal.  Not that it matters to keep it either, I imagine.
<LocutusOfBorg1> http://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/commit/?id=28524c4dabd28a27c947eb0bde322272b4729462
<LocutusOfBorg1> Already rebased and pushed :)
<LocutusOfBorg1> I noticed it while posting here
 * LocutusOfBorg1 wonders if somebody will make him stop using push -f
<infinity> LocutusOfBorg1: Shiny.
<LocutusOfBorg1> infinity, do you plan to do the same for debian?
<infinity> LocutusOfBorg1: Which?  Include the drivers in the kernel?  Probably not.  But my changes are harmless in that case.
<infinity> LocutusOfBorg1: The package layout is designed to prefer kernel-provided drivers if they're installed, and dkms if not, so it'll all Just Work.
<LocutusOfBorg1> yep I know, but having the module provided by the kernel for debian too will avoid many bug reports about problems in building
<LocutusOfBorg1> when different kernels are used
<infinity> LocutusOfBorg1: Yeah, would be a conversation to have with the Debian kernel team, but I think they prefer to stick closer to vanilla upstream.
<LocutusOfBorg1> so next question, what about asking vbox people to upstream their module?
<wxl> backlog suggests there's vm probs again?
<flexiondotorg> infinity, Do you anticipate that the rebuilds that ran earlier are the last spins before final?
<infinity> flexiondotorg: That's the hope.
<jderose> when using an encrypted home directory, is anyone getting prompted by a grub- esque dialog to unlock the cryptoswap prior to lightdm coming up?
<flexiondotorg> infinity, Great. Looking good for Ubuntu MATE so far :)
<flexiondotorg> jderose, I haven't got to the test case yet.
<flexiondotorg> jderose, Will feedback to you when I do.
<jderose> flexiondotorg: cool, thanks. it might be related to doing an oem insall, still trying to narrow it down.
<flexiondotorg> jderose, So oem install with encrpyted home is the test case?
<jderose> not using encrypted home directory during oem-mode install itself, but i'm setting it up during the frist-user-run-config
<flexiondotorg> jderose, Understood.
<Odd_Bloke> Is that unapproved isc-dhcp anything to worry about?
<infinity> Odd_Bloke: It'll be an SRU.
<rbasak>    * debian/patches/dhcp-getifaddrs.patch: use getifaddrs
<rbasak>      for getting nic addresses rather than /proc/net (LP: #1446767)
<ubot93> Launchpad bug 1446767 in isc-dhcp (Ubuntu W-series) "dhclient can fail if other nics are renamed" [High,Confirmed] https://launchpad.net/bugs/1446767
<rbasak> Odd_Bloke: https://launchpad.net/ubuntu/vivid/+queue?queue_state=1 to see unapproved stuff if you don't know about that already.
<Odd_Bloke> rbasak: Aha, thanks!
<Odd_Bloke> infinity: \o/
<flexiondotorg> jderose, I've tested on i386 and amd64. I can't reproduce.
<jderose> flexiondotorg: i haven't been able to reproduce it doing a normal, manual install, so i think it's related to my image mastering tools
<flexiondotorg> jderose, What flavour BTW?
<jderose> flexiondotorg: ubuntu desktop
<flexiondotorg> jderose, OK.
<jderose> flexiondotorg: you're testing mate, correct?
<flexiondotorg> jderose, I am. But I just did some testing with stock Ubunut. Will try your test case on stock Ubuntu now.
<jderose> so far i've only been able to reproduce imaging from our imaging server. there are a number of things i do slightly differently than ubiquity, so it might be one of those differences. like we do gpt partitioning even when the drive is < 2TB
<flexiondotorg> jderose, imaging server?
<jderose> yeah, the imaging system that System76 uses. which i also wrote... so probably my goof :P
<flexiondotorg> jderose, Ah, so you work for System76?
<jderose> yup :)
<flexiondotorg> jderose, Nice :)
<flexiondotorg> jderose, Testsed stock Ubuntu. oem install, first boot encrypted home. All good.
<jderose> flexiondotorg: yeah, i had the same results.
<wxl> pitti: is there still another ubiquity fix coming? folks still complaining about bug 1445587
<ubot93> bug 1445587 in ubiquity (Ubuntu Vivid) "Installer hangs after clicking "Restart Now"" [High,Fix released] https://launchpad.net/bugs/1445587
<jderose> ah ha, seems like it's related to gpt partitioning. the only thing i changed was to make the imager use mbr partitioning, an now there are no problems
<jderose> pitti: are you aware of any issues with systemd + encrypted home directory + gpt partitioning? i see a message in syslog from systemd about the cryptoswap failing because of dependencies
<elfy> wxl: and are you completely sure they have latest image, there are still issues with vbox afaik also
<wxl> elfy: well they say 20150422.1, soâ¦ but yeah, it is vbox
<elfy> right - from what I've read in logs etc - vbox issue is an issue and will be tomorrow too
<elfy> but I'm just me obviously
<pitti> wxl: not right now; on hardware and qemu it seems working fairly well now
<wxl> pitti: elfy: well, the guy did reference vbox, so
<elfy> pitti: hardware works for me on both arch's, qemu seems ok, vb hard reboot still
<infinity> wxl: Yeah, it's still broken in virtualbox, and we're not going to be fixing that for release.
<teward> infinity: is a fix scheduled at some point?
<wxl> infinity: i'll request a new bug be filed
<wxl> teward: did you test recently with vmware? it would be nice to know if it's an issue
<infinity> teward: That would imply we know why vbox is sad.
<teward> wxl: not recently, i need an image, hence my asking in -quality if there's been a 'final image' available for download
<teward> (my prior VM exploded itself)
<wxl> teward: well we've had about a billion rebuilds, so based on history we may never have a final :) just go grab it!
<teward> heh
<pitti> jderose: not aware of that, no
<teward> wxl: which image, beta 2?
<teward> or current daily
<wxl> teward: vivid final. dailies are building currently.
<pitti> jderose: hang on -- that's ecryptfs, right?
<wxl> teward: and desktop! not alternate. i've got another issue with it i'm trying to track down at this time.
<jderose> pitti: i'm still digging into this, but as far as i can tell, it only happens when using gpt partitioning... with mbr partitioning, it works fine
<pitti> jderose: might that still be bug 953875?
<ubot93> bug 953875 in ubiquity (Ubuntu Vivid) "Encrypted swap no longer mounted at bootup" [High,Fix released] https://launchpad.net/bugs/953875
<pitti> jderose: ok, something else then
<infinity> wxl: Nothing is building currently...
<wxl> infinity: well, that's what i meant.
<pitti> jderose: I have a hunch what's wrong -- maybe the gpt generator saw the underlying incomplete swap partition and tried to activate it
<teward> wxl: i'd need a link then for the final image, i don't have a link and i don't see one in standard locations.
<pitti> jderose: but journalctl appreciated
<wxl> teward: zsync i'm assuming?
<infinity> teward: Which flavour?
<teward> wxl: yes.
<teward> infinity: Lubuntu
<teward> although I need a zsync for Ubuntu Server as well
<wxl> teward: amd64?
<infinity> http://cdimage.ubuntu.com/lubuntu/daily-live/20150422/
<teward> infinity: thanks
<infinity> http://cdimage.ubuntu.com/ubuntu-server/daily/20150422/
<infinity> ie: where you'd expect.
<wxl> yeah what he said
<wxl> until we schedule another rebuild
<wxl> :)(
<teward> infinity: i didn't see the date folder when i went through
<teward> i blame browser cache
<jderose> pitti: i looked at /etc/fstab, /etc/crypttab, and they seem correct. happen to have instructions somewhere on how best to get you what you need with journalctl?
<pitti> jderose: do you actually have the intended cryptswap1 partition?
<jderose> yup
<pitti> jderose: just its output up to the point when it hangs would be useful
<pitti> jderose: ok, so the original bug got fixed I guess
<infinity> wxl: I have no intention of rebuilding anything, but if you need to break just lubuntu, that's your call.
<jderose> as far as i can tell, yes, but i don't know all the details of that bug
<wxl> infinity: i was kidding, dear :)
<infinity> wxl: We're at the point where any bugs found should just be SRUs and mentioned in release notes if they're annoying enough.
<teward> wxl: as soon as zsync pulls the image down i'll let you know and then go beat it with a stick :)
<jderose> pitti: oh, also, in case you didn't read back... this issue is that with gpt partitioning i get prompted by a grub-esque/debconf-esque dialog to enter my passphrase to unlock the cryptoswap, prior to lightdm coming up
<pitti> jderose: hm, that seems unusual; would you mind filing a bug with the defails how you installed, the logs, etc?
<jderose> so cryptoswap is working correctly, minus the unlock prompt that (afaik) should never be there
<pitti> need to disappear soon today, I'm afraid
<pitti> jderose: yeah, I suppose that
<jderose> yup, will do that shortly
<pitti> 's a /dev/urandom device
<pitti> ergo no password
<pitti> jderose: please attach fstab, crypttab, and output of sudo blkid
<jderose> k, will do after i isolate the steps to reproduce it a bit better
<teward> wxl: do you have the bug for the virtualbox issue you now want me to test on a VMware environment?  In addition to the shutdown/restart of live bug that was just pinged to me in -quality
<teward> (I already have the shutdown/restart bug on screen)
<wxl> teward: that's the one actually
<teward> heh
<teward> wxl: specificity is golden, by the way :p
<teward> i'll check this as soon as zsync is done
 * wxl moves over to -quality
<jamespage> why is oslo.db seeded in desktop and kubuntu?
 * jamespage scratches his head
<jamespage> well it needs fixing
<infinity> jamespage: It's not on images.
<jamespage> infinity, good-oh
<infinity> jamespage: Just in supported, I assume due to build-deps or something.
<jamespage> righty
<slangasek> infinity: is it safe for me to do a sync-mirrors right now? (snappy pre-publications)
<slangasek> infinity, cjwatson: does regeneration of Task fields still require a non-null publication in the release pocket?
<cjwatson> slangasek: yes, though it can be something trivial like a section override
<cjwatson> slangasek: I did some work recently which would make that easier to fix, but not complete yet
<Riddell> meh my kubuntu.org announce leaked onto the rss feed again, sorry :(
<slangasek> cjwatson: well I happen to have a package that I needed to let out of the unapproved queue, so this will do the trick
<slangasek> should autopkgtest be unblocked for release?
<slangasek> I guess it's a safe bet that libreoffice shouldn't ;P
<jderose> pitti: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1447282
<ubot93> Launchpad bug 1447282 in systemd (Ubuntu) "Prompted for cryptoswap passphrase when using GPT partitioning + encrypted home directory (ecrptfs)" [Undecided,New]
<jderose> fyi, booting with init=/sbin/upstart seems to reliably work-around the problem
<kenvandine> please reject ubuntu-system-settings, that should have gone to the overlay ppa
<cyphermox> kenvandine: too late for that I think
<Ukikie> dput without dest?
<cyphermox> well, it's in proposed anyway
<kenvandine> right
<kenvandine> Ukikie, no, silo wasn't configured for the overlay ppa
<cjwatson> it can be removed from -proposed
 * kenvandine is glad we have proposed :)
<cjwatson> can even be copied into the overlay ppa if you want
<cjwatson> (and if robru is happy with me doing that)
<kenvandine> cjwatson, i can fix it myself :)
<kenvandine> thx though
<robru> cjwatson: kenvandine oh just copying it to the overlay is the easiest thing...
<cjwatson> well, doing it via citrain entails rebuild+reupload
<cjwatson> copying way more efficient
<kenvandine> ok, please copy it :)
<robru> cjwatson: no need to rebuild, but it is a hassle to change the silo destination and republish
<cjwatson> ah right
<cjwatson> anyway, I'll copy+delete
<robru> cjwatson: yeah if you can copy it that's easiest, thanks a bunch!
<kenvandine> cjwatson, thanks!
<kenvandine> robru, i'll be sure to check that column from now on :)
<robru> kenvandine: thanks
<kenvandine> i'll go ahead an run the merge job
<cjwatson> copied and deleted
<kenvandine> thanks!
<slangasek> robru: so how did ubuntu-system-settings end up in vivid-proposed instead of the overlay ppa?  Are there silos still missing a reconfigure?
<slangasek> cjwatson: does deleting ubuntu-system-settings from vivid-proposed prevent us from re-copying it to w-proposed from the overlay ppa when w opens?  (Since we're meant to sync the lot from the overlay into w)
<robru> slangasek: because Ken assigned, built, and published the silo himself and he didn't configure for the overlay ppa.
<slangasek> robru: oh.  which makes me realize, we haven't really talked through dual publications for stable-phone-overlay/vivid + w... we probably need to revisit that again
<cjwatson> slangasek: no
<cjwatson> slangasek: it's just like resurrecting a deletion using a copy-with-binaries, which we know we can do
<slangasek> robru: ok.  can we make the overlay ppa the default target, please?  At least so long as vivid is the default release
<slangasek> cjwatson: ok
<robru> slangasek: right, so we still have that dual publishing code, it's a little bit-rotty but it shouldn't be hard to resurrect
<slangasek> robru: I seem to recall that last time we were dual publishing, we still had some inconsistencies in how we were versioning packages etc
<slangasek> sorry, when I say "dual publishing" I don't mean just the publishing of one silo to two targets, but the general question of making sure the changes land in both places
<robru> slangasek: i don't think so? I remember working on the version-mangling code... It injected "~utopic" at the time so the version numbers matched but utopic was always lower
<slangasek> robru: anyway, it occurs to me that even if we don't want it today, after tomorrow we /do/ want all uploads to the overlay ppa to also land in w-proposed
<slangasek> at least initially
<robru> slangasek: the problem is the spreadsheet. I'm not sure i can make cells default to non-blank, and even if i can, it wouldn't distinguish between vivid or others.
<robru> Eg rtm would also default to overlay, which would explode
<slangasek> robru: we could change the meaning of an empty cell, and require an explicit 'ubuntu' target to override?
<robru> slangasek: more spreadsheet code? :-/
<slangasek> robru: hmm is that where the code for this lives?  well
<slangasek> robru: let's not worry about it just yet then, maybe kenvandine was a one-off ;)
<robru> slangasek: well, Jenkins defines "empty dest PPA" to mean Ubuntu archive...
<slangasek> robru: right, so you could change the definition on the jenkins side instead of on the spreadsheet?
<robru> slangasek: just would get ugly quick to change it, corner cases etc.
<robru> slangasek: Hmmmmmmm i suppose.
<robru> slangasek: i don't think it's necessary, rsalveti already knows, so do mirv and sil and i... Now ken knows, not many other people assign silos
<robru> slangasek: is it OK to wait and see if it happens again?
<slangasek> robru: sure
<robru> slangasek: great, thanks. I can focus on spreadsheet replacement ;-)
<slangasek> infinity: ill-timed ping
<slangasek> infinity: ubuntu-core needs an upload of livecd-rootfs to fix a hook that's forcibly removing python from the images.  The only change is to an ubuntu-core-specific hook.  Can I squeeze this into the archive under the wire, or should I upload it only to the ubuntu-core image ppa?
<slangasek> infinity: ^^ fyi, self-accepting into -proposed but not unblocking; I'll leave that to your judgement
#ubuntu-release 2015-04-23
<zul> can someone unbock nova-compute-lxd please it fixes container networking with 0.7?
<Fr3llD> no release party here?
<wxl> Fr3llD: #ubuntu+1 and it's not ready yet :)
<Fr3llD> so.. i ddg a bit but i can't find any release _time_
<wxl> Fr3llD: yeah, it's more that it happens when it happens
<Fr3llD> im a newbie ubuntu, but im quite a fan in just a few months..
<wxl> yay! time to become a contributor :)
<Fr3llD> it not related to a time zone or something?
<wxl> kind of but no
<wxl> we have a reolving membership of release team members around the world
<wxl> so the release date can change somewhat
<Fr3llD> im about to make my first contribution on github.. till now i just contributed in buying t-shirts.. ;-)
<infinity> slangasek: livecd-rootfs isn't on images, so as long as you're 200% positive your changes don't affect other people, it's safe to let it in.
<wxl> heheheh
<wxl> i didn't mean monetary contributions but helping!
<infinity> slangasek: And, indeed, looks entirely safe, letting it in.
<Fr3llD> @wxl, i know.. but im not a programmer or coder, just a user and thats hard after 20 years of M$
<wxl> Fr3llD: perfect opportunity to help other newbies, write documentation, or just demonstrate ubutnu to the rest of the world
<wxl> Fr3llD: there's also things like reporting and confirming bugs
<wxl> Fr3llD: there's a way for EVERYONE to contribute
<wxl> Fr3llD: needless to say i see the uk contingent is active here, so we will see release today! :)
<Fr3llD> u r right, but i found out that there is a great communiity  that already did a lot, all  the help i needed was easy to find on askubuntu!
<wxl> Fr3llD: yep and it was there because people contributed. there's always more to do!
<Fr3llD> im going to.. i was about to make my first bugreport on github, so thats my first start.. but i want to make a good effort to report a bug properly and give some troubleshoot hints with it.
<wxl> Fr3llD: feel free to ping me if you need help on it. i can help you tie that assumedly upstream bug report to a downstream report on ubuntu. sounds like you might make a good bug triager :)
<wxl> on that note i'm going to go to sleep!
<Fr3llD> whats a bug triager?
<Fr3llD> nevermind, goto sleep!
<wxl> Fr3llD: here's your homework https://wiki.ubuntu.com/Bugs/Triage
 * wxl disappears
<jamespage> infinity, I've verified that zul's nova-compute-lxd upload for bug 1447128 resolved the networking issue described - please could it be accepted?
<ubot93> bug 1447128 in nova-compute-lxd (Ubuntu) "lxd instances not correctly networked with neutron" [Undecided,New] https://launchpad.net/bugs/1447128
<infinity> jamespage: Yup.
<Riddell> are we nearly there yet?
<infinity> Riddell: Things are looking good.  Need to do publishing and release notes dances and the like, but things look on track.
<Fr3llD> nice
<Fr3llD> this is really kewl btw, im new to ubuntu but its really kewl to see this up close.. *ill be quiet now*
<flexiondotorg> infinity, Do you have a rough ETA for release?
<infinity> flexiondotorg: Aiming for mid-afternoon London time, ish.
<flexiondotorg> infinity, Great!
<Riddell> just in time for a cup of tea
<Odd_Bloke> infinity: Cloud images are ready to go.
<infinity> Odd_Bloke: Ta.
<maclin> infinity: hi, the ubuntu kylin is still on the state: re-building, there must be some problem, could you help to confrim that ?
<infinity> maclin: It's built.
<infinity> maclin: It took a while longer than normal, for some odd reason.
<flexiondotorg> infinity, How you holding up? :)
<ogra_> are we there yet ?
<ogra_> :P
<maclin> infinity: yep, we are syncing the image now, thanks a lot :)
<Fr3llD> nice! release party? ;-)
<ogra_> Fr3llD, yeah, in #ubuntu-release-party :)
<Riddell> ... silence...
<Odd_Bloke> ... a clock ticks sonorously in the background ...
<mdeslaur> infinity: can I publish stuff to vivid-security now, or do I need to wait some more?
<infinity> mdeslaur: You can.
<mdeslaur> infinity: cool, thanks
<infinity> Riddell: Couple of small speed bumps, working it all out now.
<infinity> (And anyone else complaining about ticking clocks)
<utlemming> infinity: ready for Cloud Images to go public?
<slangasek> infinity: hi - what are "1.0 bits" you refer to in mail?
<slangasek> is that ubuntu-core-launcher?
<slangasek> it certainly seems we do want that
<infinity> slangasek: ubuntu-core-launcher and ubuntu-snappy
<infinity> utlemming: It's not world-ending if you push yours before I push here, I'm still sorting out the last snappy bits.
<slangasek> ok
<slangasek> infinity: so I'm withdrawing the previously-generated images, we'll have new ones soon
<infinity> slangasek: Also, I gave you the wrong filenames for your images.  Derp.  Subarches should be arch+subarch, not arch-subarch.  I published to the + location and symlinked so the links in the docs still work.
<slangasek> yeah, noticed that
<infinity> slangasek: Oh look, more stuff in the queue.  Do you need those too? :/
<slangasek> infinity: not that I've been told
<Odd_Bloke> infinity: We're pulling the cloud triggers now.
<infinity> slangasek: Can you sort that out and let me know ASAP?  We can squeeze them in before the archive closes if they're absolutely needed, but time's basically run out.
<slangasek> infinity: working on it
<slangasek> infinity: ubuntu-core-config should go in
<slangasek> infinity: and ubuntu-core-launcher also
<infinity> slangasek: core-launcher was in ages ago.
<slangasek> infinity: sorry, I meant ubuntu-snappy
<infinity> slangasek: What was in the queue was ubuntu-core-config (accepted now), and ubuntu-snappy.
<infinity> slangasek: Okay, both accepted.  Will babysit them through.
<infinity> slangasek: And I plan to close the archive after this unless someone screams Very Loudly.
<slangasek> infinity: ok, sounds good from my side
<Odd_Bloke> infinity: Is 2016-01-30 the correct EOL date for vivid?
<infinity> Odd_Bloke: I haven't set one, but distro-info-data claims 2016-01-23, which is exactly 9mo.
<infinity> Odd_Bloke: And "exactly 9mo" is the right thing to advertise, since if we can always extend, but we won't make it shorter.
<slangasek> infinity: and at the end, the decision is that the prebuilt images we'll ship for the stable channel are the ones I already gave you from last night, with everything else picked up via the channel update
<slangasek> infinity: so snappy shouldn't be a blocker for image publication now
<infinity> slangasek: \o/
<infinity> slangasek: Well, now that I've accepted and unblocked this stuff, I'll let it all migrate before I close the archive, but I can send out the ISO announcement nowish.
<infinity> slangasek: If you want to replace those images with ones built from the final state of the release pocket, do let me know later.  We can do that.
 * slangasek nods
<ogra_> infinity, hey, where is the announce in #ubuntu-release-party !
<bdmurray> infinity: shall I make the meta-release changes?
* infinity changed the topic of #ubuntu-release to: Released: Trusty 14.04.2, Vivid 15.04 | Archive: Go For Beer | Vivid Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis
<U1510nameseeker> Congratulations! What's the name for Ubuntu WW?
<infinity> U1510nameseeker: A mystery.
<ogra_> we'Re waiting for it too :)
<U1510nameseeker> Oh?
<U1510nameseeker> How is it decided? How will we find out?
<ogra_> would be funny to call it warty warthog :)
<infinity> ogra_: Wartier.
<U1510nameseeker> Why would that be funny?
<ogra_> finishing a loop
<ogra_> haha, yeah
<ogra_> U1510nameseeker, mark decides the names and he will blog once he made that decision ... watch planet.ubuntu.com, it will show up there
<U1510nameseeker> So does this mean all development is frozen because it's impossible to push any new things because the name is unknown?
<U1510nameseeker> Mark?
<ogra_> shuttleworth
<U1510nameseeker> Who's that?
<ogra_> try google :)
<U1510nameseeker> I can't, I'm in Google right now
<elfy> infinity cyphermox - thanks for your help during this cycle
<U1510nameseeker> A search will disconnect me
<cyphermox> elfy: no worries. I didn't do that much :)
<elfy> well - saying - ooh nasty, I'll look - meant a lot to me :D
<cjwatson> U1510nameseeker: development's hardly frozen, lots happens in branches anyway until it's ready to land, and in practice people usually take a bit of a break after release
<cjwatson> U1510nameseeker: it's not ideal to be stuck without a name, but it's not a disaster as long as it doesn't go on too long
<U1510nameseeker> What would happen if this mark guy got hit by a bus now?
<davmor2> infinity: should there be an update on ubuntu.com ?  currently it still seems to say download 14.10
<ogra_> we might all be jobless then ...
<cjwatson> U1510nameseeker: then we'd come up with a different procedure; I'm reasonably sure that (a) there are contingency plans in place (b) the release name is just about the least of the concerns
<U1510nameseeker> Ah, he does more than name versions?
<cjwatson> U1510nameseeker: Mark is Canonical's founder
<sil2100> infinity: hey! could you drop unity8 from the unaproved queue?
<sil2100> Oh, thanks :)
<cjwatson> that's why he gets to name stuff
<sil2100> Actually someone just did
<infinity> sil2100: pitti did, after I told him to.
<infinity> Best.  Minion.  Ever.
<smb> Banana?
<pitti> sil2100: yes, that looked like a misfire to me
<ogra_> for size ?
<pitti> sil2100: I supposed it sohuld have gotten to the overlay PPA?
<sil2100> pitti: yeah, sometimes it's easy to miss out on that especially when there are spreadsheet issues ;)
<pitti> sil2100: no worries :)
<sil2100> pitti: sorry for that one!
<cyphermox> smb: Banana!
<ogra_> for size ?
<davmor2> pitti: don't stand for infinity calling you a minion, you need to sit for that kinda insult
<pitti> davmor2: what? I've been his minion all week :)
<flexiondotorg> infinity, cyphermox - Thanks for your help :)
<davmor2> pitti: and for how much of that time have you been sitting?
<cjwatson> davmor2: speak for yourself, I *like* being a minion
<davmor2> cjwatson: minion is easier than leader :D  Less meeting too :)
<tjaalton> infinity: so should we poke lts-vivid backports next week?
<Riddell> http://changelogs.ubuntu.com/meta-release hasn't updated yet?
<infinity> tjaalton: We should, yes.
<infinity> Riddell: Indeed it hasn't.
<infinity> bdmurray: Can you twiddle meta-release for me?
<bdmurray> infinity: yep
<tjaalton> infinity: ok, i've pushed xtrans, libdrm (new on armhf), llvm-toolchain-3.6 (new) and xserver (new) already, though xserver won't build before mesa is uploaded and built..
<tjaalton> upgrade/downgrade on the staging ppa works
<slangasek> infinity: congrats :)
<bdmurray> infinity: done
<infinity> bdmurray: Ta.
<cjwatson> have we flipped the ddebs switch yet
<cjwatson> ?
<infinity> cjwatson: Nein.
<cjwatson> slackers
<cjwatson> thought you said the plan was five minutes after release :)
<ogra_> bdmurray, flavours too ? someone in #u-r-p complains mate isnt updating yet
<bdmurray> ogra_: its the same meta-release file and I literally just did it
<ogra_> ah, k
<cjwatson> ogra_: probably caches
<ogra_> yeah
<bdmurray> .cache/update-manager-core/meta-release
<infinity> cjwatson: "Five minutes after release" is a bit of a flexible time...
<Odd_Bloke> He didn't mean five of your Earth minutes.
<cjwatson> oh, silly me
<cjwatson> Proportionally-scaled Venusian minutes give you until about 11:34 UTC tomorrow.
<apw>  i don't want to know what a venusion FTE costs per year
<cjwatson> Depends whether the contract drafter was foresighted enough to specify it in terms of years rather than days
<cjwatson> (The Venusian day is slightly longer than the Venusian year)
<pitti> beer time!
<cjwatson> And it rotates backwards.  Weird planet
<doko> please could somebody accept the final gccgo-5 5.1.0 release as long as buildds are idle?
#ubuntu-release 2015-04-24
<xnox> doko_: are we open yet? where should new boost go?
<ogra_> xnox, did you hear a name yet ?
<xnox> infinity: or are we in nonameyet territory?
<xnox> ogra_: nope. le sigh.
<xnox> ok i'm not volunteering without a name ;-)
<xnox> cjwatson: ^
<infinity> We're nameless.
<ogra_> we should just call it ThatWThing
<xnox> just call it warty warthog
<xnox> part II
<xnox> LP
<xnox> EP
<ogra_> warty warthog redux :)
<Ukikie> Wistful Woodpecker.
<Ukikie> Done. ;P
<tjaalton> could someone ack my x-x-v-intel upload to utopic and lts-utopic backport to trusty?
<tjaalton> review first of course :)
<infinity> tjaalton: I could just reject it, if that helps.
<tjaalton> infinity: mmm.. not really, unless there's something wrong of course :)
<infinity> tjaalton: Accepted, but then noticed afterward that your chagelog bug ref is wrong, so the bugs won't autoclose.  Please be sure to track them by hand.
<cjwatson> infinity: So shall we do ddebs while we're waiting?
<wgrant> I have a list of PPAs that should also have it enabled.
<wgrant> Was going to do it last night, but beer.
<cjwatson> Beer is important.
<wgrant> We're also about to obsolete q/r/s.
<wgrant> And clean up dists.
<tjaalton> infinity: oh bah, LP: missing
<infinity> tjaalton: Yeah.  I'm not quite awake this morning, or I would have rejected for that.  But not world-ending, just make sure it's all sorted manually.
<tjaalton> sure will
<tjaalton> thanks
<wgrant> cjwatson: Can you think of any reason not to go ahead with killing quantal, raring and saucy from ftpmaster? saucy was finally killed from archive yesterday.
<cjwatson> wgrant: None that I know of.  JFDI
<jamespage> infinity, hey - the MIR for conntrack completed on the morning of release:
<jamespage> https://bugs.launchpad.net/ubuntu/+source/conntrack/+bug/1381450
<ubot93> Launchpad bug 1381450 in libnetfilter-queue (Ubuntu) "[MIR] conntrack, libnetfilter-queue, libnetfilter-cttimeout, libnetfilter-cthelper" [Medium,Fix committed]
<jamespage> am I going to get myself intro trouble if I add that dependency to the neutron stable updates well be doing next week?
<infinity> jamespage: Ugh.  Would have been nice if someone had pointed that out.
<infinity> jamespage: But we can "fix" it by copying it to -updates and changing the component there.
<jamespage> infinity, I only noticed after the general whirlwind yesterday
<jamespage> I knew the security team where trying to squeeze in the review, but failed to note that it had completed..
<wgrant> Enabled ddebs on both primary archives and the silos.
<wgrant> Silos have publication enabled too, primary archives not.
<cjwatson> \o/
<cjwatson> Anyone have an excuse to accept anything in -proposed?
<cjwatson> wgrant: Would it be worthwhile on partner too?
<wgrant> cjwatson: Possibly.
<wgrant> infinity: https://pastebin.canonical.com/130301/ is the list of archives that have binaries in the primary archive
<cjwatson> distribution.name :)
<wgrant> Indeed, I'm living in the past.
<deej> infinity and/or any other release managers, it looks like the metadata for vivid/Contents-amd64.gz is wrong in the Release file and it's making our AWS mirrors freak out
<deej> And I imagine other things as well
<deej> How can we get that fixed?
<xnox> infinity: cjwatson: wgrant: ^^^^ from deej
<deej> wgrant is on his way apparently
<apw> lots of looking is going on ...
<wgrant> Yeah, Adam and I are investigating.
<wgrant> deej: Does Contents look OK now?
<deej> Let me check
<deej> wgrant: It'll take me a minute to double check the md5, but sizes match
<wgrant> deej: Yeah, looks good on pepo now, but will be interesting to see if anything else is borked.
<deej> wgrant: Looks good to me
<wgrant> https://bugs.launchpad.net/launchpad/+bug/1448270 was the bug
<ubot93> Launchpad bug 1448270 in Launchpad itself "updateContentsFiles doesn't check for suite immutability" [Critical,Triaged]
<wgrant> Great, thanks for pointing it out, fixing, and confirming :)
<deej> No problem at all
<deej> I'm glad you guys were around to fix it :)
<wgrant> We were very nearly not!
<ScottK> Nothing like planning on ~everyone traveling the day after release.
<ScottK> What could go wrong.
#ubuntu-release 2015-04-25
<ScottK> wgrant, cjwatson, somebody: Rejected: clamav 0.98.6+dfsg-1ubuntu3 in vivid (Cannot copy DDEBs to a primary archive) - that makes releasing an SRU kind of tough
<ScottK> Oh, I think I get it.
<ScottK> It's still copying to the release pocket, not -updates
<ScottK> Well no, same error using copy-package to updates.
<ScottK> Sigh.
<cjwatson> 19:33 <wgrant> We can fix the clamav situation by either a) reuploading it, b) fixing pkg-create-dbgsym before SRU verification completes, c) removing the primary archive ddebs check since it's obsolete now that publish_debug_symbols is a disableable thing.
<cjwatson> (I'm sure wgrant won't mind me leaking that)
<cjwatson> Basically we turned on new-style ddebs and then had to revert because that broke gcc; unfortunately clamav was a temporary casualty of this.  If you can wait until Monday-ish then I believe William was intending to do c) then.  Otherwise do a).
<ScottK> cjwatson: We're getting a fairly high rate of bug reports over this.  I guess I'll go a.
<ScottK> Thanks.
<cjwatson> ScottK: Thanks.  Sorry for the inconvenience.
<cjwatson> Too much to hope that it would all go smoothly after all the planning ...
<ScottK> Well the other frustrating part is we knew about this bug but thought almost no one would hit is, so didn't push uploading a fix.
<ScottK> Clearly that analysis was in error.
<ScottK> OK.  Released again.  Let's see how that goes.
<ScottK> Seems like that worked.
<ScottK> Thanks cjwatson and wgrant.
<wgrant> ScottK: Sorry, meant to copy what Colin quoted here but got distracted by another crisis. I'll indeed be implementing c) on Monday, but clamav was the only package hit.
<ScottK> wgrant: At least we got it sorted.  Thanks.
<wxl> hey we going to turn dailies back on?
<infinity> wxl: Doesn't make much sense to do so until w-series is open.
<Logan> and/or named
<wxl> infinity: oh. that makes sense then :)
<Ukikie> Also, the name issue.
#ubuntu-release 2016-04-25
<infinity> cjwatson: Kay, wasn't sure if this race was known.  Do we ever do a DB sweep to detect such things and fix them?  Seems a bit broken if we have double-accepted binaries and (obviously) only one can be the one on disk.
<pitti> infinity: yes, I noticed; on my todo list; for some reason there were tons of timeouts on the autopkgtest.u.c. host when reading swift, maybe some effect of the post-release networking flood
<LocutusOfBorg> doko, ^^^ please, fixing the build issue (I uploaded 0.4-1.3 in debian too, will be autosyncd)
<xnox> doko, i think we should remove osmium (deprecated) in favor of libosmium (the new one)
<xnox> we are still frozen?! =(
<LocutusOfBorg> yes, until tonight or tomorrow I guess
<apw> i believe we are waiting for soem -fpic issue to be resolved
<apw> though i would defer to doko for details
<cjwatson> doko: ghc/{amd64,ppc64el} seems to be building more happily now.  Procedure was simple once I thought of it: copy your yakkety source to xenial in a PPA configured to build for amd64 and ppc64el, then use the result to supply build-deps for the yakkety build.
<cjwatson> doko: I guess you're fixing https://launchpad.net/ubuntu/+source/gcc-5/5.3.1-15ubuntu6 ?
<doko> ahh, forgot to upload
<xnox> doko, infinity, apw : ^ icu transition bug-fix
<xnox> the russian transliteration rules changed from fancy quotes to regularish quotes
<doko> xnox, ahh, but please file a bug report, this is ci-train stuff (or ping sil2100)
<xnox> doko, dee development stopped long time ago.
<xnox> it's a unity7 thing only.
<doko> ahh
<xnox> doko, ^ this fixes compile error of the test-suite. There is still operator< test suite failure when comparing shared pointers to node objects.
<xnox> i'm not sure how that at all works in c++, or why it is failing. Somehow I suspect operator< shouldn't be declared inline in the templates.... but i really don't know the C++ standards/specs to understand where the bug is.
<xnox> doko, haha, i bet pointers are compared wrong way around on big-endian.
<xnox> or rather they are compared wrong way on little-endian platforms
<xnox> osmium built on powerpc and nowhere else.
<xnox> Mirv, in yakkety qtbase-opensource-src fails to rebuild with new libpng due to test-suite errors e.g. https://launchpadlibrarian.net/256001809/buildlog_ubuntu-yakkety-amd64.qtbase-opensource-src_5.5.1+dfsg-16ubuntu8_BUILDING.txt.gz
<xnox> do you know if there are any patches in qt to support new libpng?
<doko> xnox, cjwatson: how did you bootstrap ocaml for pie? https://launchpad.net/ubuntu/+source/ocaml/4.02.3-6ubuntu1  seems to be ok on ppc64el, but fails on amd64
<xnox> maybe there is extra code on amd64 that is not available / not compiled on other arches?
<cjwatson> I have no idea
<xnox> ok osmium is baffling me with success on powerpc & armhf, but not other platforms.
<xnox> https://launchpad.net/ubuntu/+source/osmium/0.0~20160124-b30afd3-1ubuntu1
<cjwatson> Maybe it only matters on arches where ocaml has a native compiler
<cjwatson> (utter guesswork)
<cjwatson> I'm not sure I totally believe that looking at the source.  Compare build logs I guess
<cjwatson> s390x seems to be able to link objinfo_helper happily.  Is -Wl,-Bstatic -lbfd -Wl,-Bdynamic portable with PIE?
<cjwatson> Or, put differently, is it possible for libbfd.a to contain PIC code on amd64?
<cjwatson> Might be enough to just disable PIE for objinfo_helper, if not
<doko> xnox, I demoted osmium to proposed, so not a blocker anymore
<xnox> tah
<xnox> doko, so qt left and 4 haskell things?
<doko> the 3 haskell things are wip, and I think I fixed the ocaml thing
<xnox> doko, and then we open?
<xnox> doko, or do we open, whenever infinity wants to?
<doko> xnox, well, I'd like to have working toolchains again ... so ocaml, ghc, hopefully the icu transition in time.
<doko> xnox, sbeattie isn't here, so maybe scan his pie archive for stuff which needs a rebuild
<doko> xnox, or do a qt upload with the tests disabled ...
<xnox> doko, we could build qt against old libpng.
<xnox> it looks like it is libpng induced failures, which are real, not imaginary.
<doko> xnox, sure, that would help with icu
<doko> xnox, can you do that?
<xnox> let me fiddle with that.
<doko> xnox, hmm, we would need to promote libpng12 again if you build qt with it
<wxl> so we have images but no testcases?
<infinity> doko: It's never been demoted.
<doko> ohh, not yet ...
<infinity> Not while the transition is still ongoing, no.
<doko> heh, haskell-text-icu accepted for release with icu 57 still in proposed
<infinity> Yay, static linking. :/
<doko> xnox, hmm, that png12 road is cursed ... can't install the other b-d's anymore
<knome> wxl, lubuntu should be set now
<wxl> knome: thank you :)
<knome> np
<bdmurray> infinity: What is happening with that dpkg SRU?
<infinity> bdmurray: I'm doing it through the secutity PPA.
<infinity> bdmurray: In a few minutes.
<bdmurray> infinity: So I could upload a new ubuntu-release-upgrader shortly which depends on it?
<infinity> bdmurray: Yeah.  We'll need to verify the SRU, despite the fix being "obvious", but that shouldn't be too hard to expedite.
<bdmurray> infinity: what bug is this?
<infinity> https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1574285
<ubot5> Ubuntu bug 1574285 in libreoffice (Ubuntu Yakkety) "dpkg-maintscript-helper: prepare_dir_to_symlink can never succeed" [High,Confirmed]
<infinity> http://anonscm.debian.org/cgit/dpkg/dpkg.git/diff/?id=ca5c108
<LocutusOfBorg> doko, I uploaded a "fixed" crossguid, I don't know why debian has a symbol for ppc64el that disappeared on Ubuntu, I did a "arch=!ppc64el" it should work, and unblock kodi
<LocutusOfBorg> also flashplugin-nonfree is fixed, but you already know that :)
<doko> LocutusOfBorg, -O3 on ppc64el
<LocutusOfBorg> so, what is the best fix? change the optimization level or ignore that symbol?
<doko> ignore or mark it as optional. c++ symbols files suck in any case ...
<infinity> LocutusOfBorg: The better fix for flashplugin is to not list libpng at all, it's not a direct dep.  (if it was a direct dep, your fix would be broken).
<infinity> LocutusOfBorg: The dep list should be reconciled with the output from 'readelf -a /usr/lib/flashplugin-installer/libflashplayer.so | grep NEEDED'
<LocutusOfBorg> indeed, I didn't download the package :(
<doko> hmm, did somebody already remove libgccjit-5-dbg, libgcj-doc from proposed?
<doko> ahh, crap. remove-package always wants a -b for binary packages, which is inconsistent with other commands
<LocutusOfBorg> infinity, do you want me to upload flashplugin without libpng runtime dependency?
<LocutusOfBorg> well, uploaded
<LocutusOfBorg> Rejected:
<LocutusOfBorg> polybori 0.8.3-5.1 in stretch (same version already has published binaries in the destination archive)
<LocutusOfBorg> wgrant, ^^^
<LocutusOfBorg> I can't sync it
<LocutusOfBorg> uploading now a 0.8.3-5.1build1
<cjwatson> LocutusOfBorg: err stop
<LocutusOfBorg> ETOOLATE :(
 * cjwatson manages to reject it in time
<cjwatson> let me see what actually happened
<infinity> I delete 5.1 from xenial-proposed
<LocutusOfBorg> the source seems there https://launchpad.net/ubuntu/+source/polybori/0.8.3-5.1/+build/9540992
<LocutusOfBorg> not sure what happened, I leave the checks to you
<LocutusOfBorg> thanks
<cjwatson> LocutusOfBorg: look at https://launchpad.net/ubuntu/+source/polybori/+publishinghistory
<cjwatson> LocutusOfBorg: I can copy it back in from there, but is there any reason to believe that the FTBFS on armhf has been fixed?
<infinity> Well, it would need a -5.1build1 regardless.
<infinity> If the intent is to transition.
<infinity> The one in xenial was pre-transition.
<LocutusOfBorg> yep, the rationale is: we removed armhf in debian
<LocutusOfBorg> so, please let me transition it :)
<LocutusOfBorg> would be nice to copy it back then, at least to fix the libpng stuff
<infinity> bdmurray: ^-- There's your dpkg SRU.
 * LocutusOfBorg will fix the FTBFS probably in the next few days
<doko> crap, hhvm still ftbfs https://launchpadlibrarian.net/256053682/buildlog_ubuntu-yakkety-amd64.hhvm_3.12.1+dfsg-1ubuntu1_BUILDING.txt.gz
<cjwatson> all right; I just wanted to make sure that it was actually investigated rather than doing a knee-jerk upload as a workaround.
<doko> LocutusOfBorg, mia and lightspark ftbfs
<doko> LocutusOfBorg, polybori ftbfs
<doko> slangasek, infinity, pitti, xnox, sbeattie: about archive opening ... ghc is fixed, I'm not sure about ocaml on amd64. I still would like to see icu migrate before we open the archive. from my point of view ocaml is a blocker, icu is a point of discussion.
<doko> I'll be afk tomorow for most of the day, so I can't help with issues
<infinity> doko: Finishing the icu transition so it doesn't get tied up with autosync transitions might be nice.  What's the ocaml/amd64 issue?
 * infinity spots the ocaml rdep build failures.
<doko> infinity, look at the hhvm fbfs. now demoted to proposed
<infinity> doko: Right, and ocamlimages, mldonkey...
<doko> ocaml itself builds again, but maybe this addition of -fPIC was not good enough
<infinity> + ocamlfind ocamlopt -package lablgtk2,graphics,unix -w A-4-9-40-42-44-45-37-41-48 -I . -I ../../src -linkall -o monochrome.opt ../../src/camlimages_core.cmxa ../../src/camlimages_all_formats.cmxa monochrome.cmx -linkpkg
<infinity> /usr/bin/ld: /usr/lib/ocaml/libasmrun.a(startup.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
<infinity> Looks like it's not creating PICish objects?
<doko> yeah, might be this flag missing from some ocaml infrastructure
<infinity> I'm going to grab lunch and then I'll download ocaml and see if I can make sense of the C parts while ignoring the ocaml parts. ;)
<infinity> It could also be that this change has cascaded into needing a full ocaml transition.
<xnox> infinity, i currently believe qtbase-opensource-src test-suite failures are due to switch to libpng16-dev, tried rebuilding with libpng12-dev to get the icu abi bump, without libpng abi bump -> no dice
<xnox> libpng12-dev is not installable in yakkety.
<xnox> and i don't want to rebuild in xenial with wrong toolchain =/
<doko> xnox, scratch this. I uploaded the package ignoring the test results
<doko> you can't build using png12 anymore
<infinity> Ignoring the testsuite doesn't seem like the right answer.
<doko> agreed, it's a temporary work-around which needs fixing for the release
<bdmurray> infinity/slangasek: I'm planning on making this change to the release upgrader http://pastebin.ubuntu.com/16056888/. Seem reasonable?
<infinity> bdmurray: Assuming that actually does what it seems to be saying it should do.
<slangasek> bdmurray: what's the context for this change?  This means that an SRU will need to be installed on either trusty or wily before upgrading, is that correct?
<bdmurray> slangasek: Yeah, to make sure bug 1560797 is fixed.
<ubot5> bug 1560797 in apt (Ubuntu Wily) "apt does not configure Pre-Depends: before depending package" [High,Fix released] https://launchpad.net/bugs/1560797
<slangasek> fun
<bdmurray> that and bug 1574285 for trusty
<ubot5> bug 1574285 in libreoffice (Ubuntu Yakkety) "dpkg-maintscript-helper: prepare_dir_to_symlink can never succeed" [High,Confirmed] https://launchpad.net/bugs/1574285
<slangasek> bdmurray: then it seems ok to me
<infinity> So, we need to test and expedite that dpkg SRU, but I can figure out a small testcase tonight and push it out.
<infinity> (Honestly, the fix is obviously correct regardless, but...)
<bdmurray> I'll work on getting this uploaded, if the dpkg change is slow it'll just stop upgrades from T to X for a bit.
<infinity> bdmurray: I don't intend for it to be slow.
<bdmurray> I guess I assumed tonight was hours away for you like it is for me.
<infinity> Well, I said "tonight" because I have plans between 4:30 and 6:30, so "right now" is less realistic.
<infinity> But it'll still be soon enough.
<bdmurray> Should I make a separate bug for this or just refer to the existing two?
<infinity> bdmurray: Don't care, as long as you test to make sure it DTRT.
<bdmurray> infinity: I view the right thing as not upgrading w/o those packages.
<infinity> bdmurray: Does that setting also force an upgrade (or at least ask nicely), or does it stop hard?
<infinity> bdmurray: We have a small issue that that apt isn't in trusty-security (and shouldn't be copied there because it wasn't built against only security, like my dpkg just was)
<bdmurray> infinity: it stops hard just complaining about an unmet dependency
<infinity> bdmurray: So, we might need a no-change apt SRU via security (or to examine the deps and make sure it's clean to copy) to resolve that.
<infinity> bdmurray: I'll delve deeper into this when I return from my early evening shenanigans.
<infinity> bdmurray: But go ahead and upload.  We'll sort out how to make sure everything's good before we release.
<LocutusOfBorg> doko, polybori seems an issue boost related
<LocutusOfBorg> xnox, ^^
<LocutusOfBorg> mia boost related
<LocutusOfBorg> lightspark needs llvm 3.6
<xnox> most "boost related" bugs are actually just bad c++ =)
<LocutusOfBorg> xnox, unfortunately I have not a strong boost knowledge (unless you provide me some "upgrade from 1.58 manual")
<LocutusOfBorg> I would prefer to spend my time in libpng related failures
<LocutusOfBorg> and then look at what broke elsewhere
<xnox> LocutusOfBorg, looks like a case of a missing ';' =)
<xnox> the compiler is now more strict.
<LocutusOfBorg> you all say qtbase-opensource-src doesn't pass the testsuite with new libpng
<LocutusOfBorg> https://buildd.debian.org/status/package.php?p=qtbase-opensource-src&suite=unstable
<LocutusOfBorg> why debian is green then?
<LocutusOfBorg> xnox, I will look at them as soon as I finish the current stuff :)
<tyhicks> infinity: can you reject the grub2 and grub2-signed uploads? we just noticed that grub2 FTBFS on ppc64el
<LocutusOfBorg> thanks for now
<tyhicks> sbeattie is looking into the reason for the FTBFS and then we'll test again and do another upload
<infinity> tyhicks: You have a log?
<tyhicks> infinity: https://launchpadlibrarian.net/256038626/buildlog_ubuntu-yakkety-ppc64el.grub2_2.02~beta2-36ubuntu4_BUILDING.txt.gz
 * LocutusOfBorg sleeps
<infinity> tyhicks: Not your fault, doko broke the compiler.
<infinity> tyhicks: Will upload a fix.
<tyhicks> heh
<tyhicks> sbeattie: ^
<infinity> tyhicks: https://launchpad.net/ubuntu/+source/gcc-5/5.3.1-16ubuntu2
<infinity> tyhicks: If you still have that source in the PPA you copied from, you can retry the build once that compiler's published.
<sbeattie> infinity: oh, phew. I was worried it was pie related.
<infinity> tyhicks: (If you don't, you can revive it with copy-package --force-same-destination --from=ppa:foo/bar --to=ppa:foo/bar --from-suite=yakkety --to-suite=yakkety -e $version grub2)
<infinity> Err, add a -b
<tyhicks> infinity: thanks!
 * infinity runs out.
<sbeattie> infinity: we still have it, but thanks.
#ubuntu-release 2016-04-26
<infinity> doko: hhvm now fails with http://paste.ubuntu.com/16058278/ which doesn't immediately seem pic/pie related...
 * infinity tests something.
<infinity> tyhicks: https://launchpad.net/ubuntu/+source/grub2/2.02~beta2-36ubuntu4 <-- All looks good now.
<infinity> tyhicks: I'll accept -signed from the rejected queue when all my UEFI bits are in.
<infinity> sbeattie: ^
<sbeattie> infinity: thanks!
<infinity> sbeattie: ^
<sbeattie> thanks! /me does a happy dance
<infinity> bdmurray: Ah-ha.  Took me a while to reproduce that dpkg bug.  It only hits when /bin/sh is bash (which is probably why we don't have a bazillion duplicates)
<infinity> bdmurray: Verified now with my testcase that the proposed dpkg fixes it.
<infinity> bdmurray: Fasstracked that dpkg update through, based on manual testing and autpkgtests looking clean.  You're clear for the ubuntu-release-upgrader update whenever.
<slangasek> infinity: uhm? how did we get *any* reports of a bug that requires /bin/sh to be bash, and why would we consider that an SRUable bug instead of user error?
<cpaelzer> I just realized that we are in SRU mode for xenial seeing the DPDK upload in unapproved and quickly added a proper SRU template for the bugs 1546565 , bug 1570466 and bug 1570195
<ubot5> bug 1546565 in openvswitch-dpdk (Ubuntu) "Ownership/Permissions of vhost_user sockets for openvswitch-dpdk make them unusable by libvirt/qemu/kvm" [High,Triaged] https://launchpad.net/bugs/1546565
<ubot5> bug 1570466 in dpdk (Ubuntu) "Adding/removing ports leaks memory in dpdk" [High,Triaged] https://launchpad.net/bugs/1570466
<ubot5> bug 1570195 in linux (Ubuntu) "Net tools cause kernel soft lockup after DPDK touched VirtIO-pci devices" [Medium,Confirmed] https://launchpad.net/bugs/1570195
<cpaelzer> sorry, next time the SRU template should be there before the upload
 * cpaelzer is changing xenial upload mode to SRU ...
<cking> hi there, thermald 1.4.3-5~14.04.3 is in trusty -proposed, but it contains a bug, can that be rejected for me?
<smb> cking, I think what I meant was let  	1.4.3-5~14.04.4 in unapproved get rejected
<cking> ah, please ignore my initial comment folks :-/
<smb> Which is mostly because you said you did not include all the changes between 14.04.2 and 14.04.4 in the changelog of .4
<cking> smb, ack
<smb> apw, are you already with enough powers to reject cking 's older thermald  	1.4.3-5~14.04.4 from Trusty's unapproved queue?
<apw> cking, you presumably do want this double thermald rejected ?
<smb> apw, the 21 hours ago one
<cking> the first one to be removed, leave the latest
<cking> tbanks apw
<Odd_Bloke> Could someone migrate gce-utils 1.3.3-0ubuntu4 from yakkety partner-proposed to partner, please?
<Odd_Bloke> Also, if a member of the SRU team could review the cloud-init waiting in https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text= it would be much appreciated. :)
<pitti> doko: icu and rdepends are currently landing \o/
<xnox> pitti, yeah, thanks
<doko> ahh, I got emails ...
<pitti> ah, yakkety got unfrozen? I just synced apt and that went straight through
<pitti> hmm, https://launchpad.net/ubuntu/yakkety still says "frozen"
<Laney> guess somebody is speed reviewing the queue...
<apw> not me
<pitti> there's tons of other and much less harmful stuff in there
<pitti> (not that apt is known-broken, but I would have expected it to go in when we open)
<mwhudson> someone is definitely reviewing things in the queue
<mwhudson> i wonder who it is :-)
<pitti> I did the xenial SRUs earlier on, but not yakkety
<xnox> pitti, it would be nice for gcc-5 to migrate to yakkety to, such that people get the right compiler in release pocket, with pie enabled.
<xnox> *too,
<pitti> xnox: ok; linux will most probably fail anyway due to the timeout, and binutils/i386 passed against the previous ubuntu1
<pitti> xnox: so if it's urgent, I can hint it in
<doko> libpng demoted \o/
<xnox> pitti, not urgent, as i guess infinity will be the one to open and say "we have pie, have fun"
<ogra_> infinity, hmm, did you not release ubuntu-core tarballs for xenial ?
<apw> that was rather instant approval too
<doko> pitti, xnox: yes, gcc-5/gcc-6 would be good to have ...
<pitti> doko: gcc-5 hinted; is there any urgency wrt. fast-tracking -6?
<doko> hmm, no
<apw> pitti, what does the separation of ADT testing into by package and by package version mean
<doko> xnox: looking at boost-defaults failing autopkg tests ... are these all real?
<pitti> apw: britney now suppresses the package version for excuse lines which all just have "in progress", as it's not easy to predict which version it is going to be (and it was often wrong, which is why I did that)
<pitti> apw: in most cases that "unifies" lines properly, but this doesn't seem to work sometimes so that you get two lines
<pitti> just a cosmetical issue
<apw> pitti, so they are "currently undecided versions" that seems sensible enough
<doko> xnox, ugh, this looks like a boost issue ... https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/ppc64el/c/compute/20160423_162855@/log.gz
<ogra_> infinity, ignore that, found them
<xnox> doko, horum weird yes.
<LocutusOfBorg> [13:10:30] <LocutusOfBorg> hi, please accept crossguid, wrt libpng transition
<LocutusOfBorg> [13:10:35] <LocutusOfBorg> (unblocking kodi)
<LocutusOfBorg> thanks!
<xnox> thanks to willy glibc security upload, we will have autopkgtest for yakkety in approximately never =)
<Odd_Bloke> arges: o/  Do you have a couple of minutes to review https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text= and accept it?
<arges> Odd_Bloke: cloud-init i see. ok
<Odd_Bloke> arges: This is a backport of stuff that's already been SRU'd to wily/trusty; and smoser reviewed it before sponsoring the upload.
<arges> Odd_Bloke: ok done
<Odd_Bloke> arges: Thanks!
<xnox> doko, after https://launchpad.net/ubuntu/+source/qt4-x11/4:4.8.7+dfsg-5ubuntu4 builds qt4 moc things that fail with BOOST_JOIN errors should be better.
<marcoceppi> congrats all on a great release! I have some questions about getting a micro release of a tool into universe. charm 2.1.1 is in xenial and I'd like to submit 2.1.2 - is the first step to upload to yakkety then request an SRU?
<slangasek> marcoceppi: does the project have a microrelease policy that fits with https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases ?  Are you going to be doing enough of these, and is the delta large enough, to make it less time-consuming for you to go through the MRE process instead of doing discrete SRU bugs for each of the changes included upstream?
<slangasek> marcoceppi: we would certainly want it in yakkety before SRU to xenial, but in terms of first steps, I think the above is probably more relevant :)
<slangasek> doko: libpng seems to have been pre-demoted, is that you?  any particular reason for a pre-demotion?
<doko> slangasek, yeah, I see cairo is unhappy
<slangasek> it's unhappy, so you demoted?
<doko> re-promoted
<slangasek> or you mean you demoted thinking everything was done and see cairo is still unhappy
<slangasek> ok
<doko> pitti, please override the cairo/libreoffice/s390x autopkg test. then cairo can migrate
<slangasek> pitti's not the only one who can override that, you know ;)  but in this case it may not be worth it, the test should be done momentarily
<infinity> slangasek: /bin/sh -> bash is only a "dpkg-reconfigure dash" away.  If you want to call that user error, we'd need to cripple that a bit, I think, or warn against it, or whatever.
<infinity> slangasek: I've always considered it entirely valid for /bin/sh to be bash or dash.
<infinity> slangasek: Either way, the dpkg bug was still a bug. :P
<slangasek> infinity: I consider reconfiguring your system to use bash as /bin/sh to be foot-shooting and we should not support it.
<infinity> slangasek: Oh, I'm also not sure if we ever forcefully switched people?
<infinity> slangasek: Like, if you've upgraded since hoary...
<ogra_> i think update-manager had code ...
<ogra_> but that was plenty of releases ago
<infinity> Either way, bad shell is bad shell.  I'm more confused by dash's behaviour there, to be honest.
<doko> infinity, from my point of view we can open the archive
<infinity> doko: \o/.
<infinity> doko: Did you want to do the honors on the email?
<doko> yep, already prepared
<infinity> Check.
* infinity changed the topic of #ubuntu-release to: Released: Trusty 14.04.4, Xenial 16.04 | Archive: open | Xenial Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis
<infinity> doko: Mail away.
<cjwatson> Shall I enable auto-sync?
<doko> please do
<infinity> cjwatson: I'm going to create-missing-builds first.
<infinity> cjwatson: Then I was going to turn on autosync.
<infinity> After that churn's done retrying.
<cjwatson> OK, leaving it off for now then.
<cjwatson> Not that I think the order matters much; it can just all be slung into the pot.
<infinity> It sort of matters from an upload order perspective.  If any of the autosyncs rely on any of these broken builds and they magically now succeed.
<infinity> But yeah, the odds are low. :P
<infinity> Anyhow, running now.
<teward> infinity: hate to throw more onto your plate - nginx 1.10.0 is now out, evidenced by my yakkety upload for it, can we SRU that version string change for Xenial?  (https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1575212) ^
<ubot5> Ubuntu bug 1575212 in nginx (Ubuntu Xenial) "[Xenial] [SRU] Update nginx to 1.10.0" [Wishlist,In progress]
<infinity> teward: Diff looks clean, absolutely let's SRU that.
<doko> what's the plan with the ci-train any yakkety?
<teward> infinity: wonderful!  it's sitting in unapproved queue right now for xenial-proposed :)
<infinity> robru: ^-- ci-train, is it yakketyful?
<apw> infinity, wow that wasn't missing <sarcasm> tags, it really is empty
<infinity> apw: Every once in a while, things go right. :)
<infinity> And the 1.9.x -> 1.10 gamble appears to have paid off for nginx.
<apw> teward, the changelog says there is a refreshed patch in there, but no delta for it
<infinity> apw: I see it.
<infinity> apw: Perhaps you're slightly blind?
<teward> apw: http://launchpadlibrarian.net/256470908/nginx_1.9.15-0ubuntu1_1.10.0-0ubuntu0.16.04.1.diff.gz
<slangasek> infinity, doko: robru is out right now.  there is a question of how it will be yakketified, I was just talking to sil2100 about that
<teward> apw: find "debian/patches"
<teward> apw: or, second-to-last change set in that patch
<apw> <- emulating a bag of rocks ...
<apw> thanks
<slangasek> because we're now in a transitional period between vivid and xenial for the phone images, in addition to needing to land to devel
<cjwatson> whee, all the builds
<teward> infinity: indeed, the 1.9.x -> 1.10 gamble did pay off.  In this case, nothing to add between 1.9.15 and 1.10.0, i think that's why 1.10.0 was pushed a week?
<infinity> slangasek: So, triple landings until we can kill vivid? :P
<teward> infinity: glad to see it's there though :)
<slangasek> infinity: I've insinuated that triple landings might be a horrible idea.  But we'll see what the phone team decides to do
<slangasek> (my recommendation is dual landings for xenial+yakkety and force all projects to create a vivid branch)
<infinity> slangasek: That might put pressure on to make the move to xenial faster, which I wouldn't be against.
<infinity> slangasek: Perhaps intentionally making vivid landings a bit harder is the way to get movement.
<bdmurray> infinity: I've verified that the ubuntu-release-upgrader in xenial-proposed won't allow upgrades with the old versions of apt or dpkg.  I think slangasek wants to verify bug 1572416 too though.
<ubot5> bug 1572416 in ubuntu-release-upgrader (Ubuntu Xenial) "do-release-upgrade crashes in Greek locale" [High,In progress] https://launchpad.net/bugs/1572416
<infinity> Why is it always greek?
<seb128> slangasek, infinity, it's just means triple landing, just done with extra steps and more vcs
<seb128> also they are wanting to move
<infinity> Oh, cause it's an Alkis bug.
<seb128> just didn't solve the gcc ABI break and how to deal with the store
<seb128> well that + getting the image back in shape
<seb128> but that is easy enough in principle
<seb128> just work
<slangasek> infinity: IMHO the best argument for splitting instead of doing triple landings is to make xenial landings /easier/, instead of requiring them to all maintain compatibility on the vivid branch
<infinity> slangasek: Yes, also a fair argument.
<slangasek> pitti: this channel also exists and gets used for sru discussions ;)
<pitti> slangasek: *shrug* too many channels :)
<slangasek> yeah, but infinity and bdmurray just discussed u-r-u above :)
<bdmurray> slangasek: should we wait to test your fix? pitti thinks we should release it asap
<pitti> well, I wasn't saying "right now", I just wanted to know the procedure
<pitti> ISTR that in the past there was some extra magic for the u-r-u tarballs
<pitti> but shortening the 7 day period seems adequate
<bdmurray> The meta-release file may need to be modified to point at -updates.
<bdmurray> pitti: so that could be the extra magic
<mapreri> can i point an archive admin on the rm @ lp #1575255 ?  that thing is blocking libreoffice-dictionaries migration.
<ubot5> Launchpad bug 1575255 in hunspell-sv (Ubuntu) "RM: hunspell-sv -- obsolate; replaced by hunspell-sv from libreoffice-dictionaries" [Undecided,New] https://launchpad.net/bugs/1575255
<marcoceppi> slangasek: I don't have an autopackage, but it follows everything else. We're just having to constantly chase juju, and I expect we'll have 3-5 micro releases to push into a release every 6 months - maybe an MRE is the way to go
<xnox> doko, [2] is left as an exercise for the reader? =)
<slangasek> marcoceppi: ok, sounds reasonable.  We're going to want some documentation/discussion of /how/ this package meets those MRE requirements; can you post to ubuntu-release@ about it?
<jcastro> marcoceppi: I am gathering those requirements now
<jcastro> slangasek: we should have something to post to the list by eod
<slangasek> cool
<teward> infinity: to get the SRU moved, do we just have to get the nginx upload out of the unapproved queue for Xenial, to make it land?
<infinity> teward: You have to exercise patience.
<teward> infinity: ack
<infinity> teward: But yes, I'll get it into -proposed.  Then you need to do some testing to say "yup, still not broken".  Then we can promote it.
<teward> infinity: my apologies, i've got one of those 'limited patience' mindsets today :/
<teward> infinity: ack
<infinity> teward: And if there are autopkgtests that trigger, we'll look at those too.
<teward> how fortunate i have multiple Xenial VPSes now to test with :p
<teward> ack
<infinity> teward: Given the exactly zero code changes, there's no specific things we need to test, except to test that it, indeed, still functions and passes whatever tests we already have.
<teward> yup
<infinity> teward: Well, I guess there's one code change.  You could test the version banner is correct. :P
<infinity> teward: But if it's not, I'd be VERY surprised and confused. :)
<teward> heheh, indeed.
<teward> definitely, I'd be equally confused
<mapreri> infinity: do you have some seconds to process an RM?
<robru> infinity: slangasek oh i can yakify it in just a minute
<infinity> mapreri: Maybe?
<mapreri> infinity: that would be â¥! #1575255
<robru> slangasek: what's the plan? dual silos should become yakkity+vivid?
<infinity> mapreri: It's still seeded all over, will need to fix that first.  But I can sort that in a bit, since I have all the seeds here.
<mapreri> ah, right, forgot to run seeded-in-ubuntu ...
<slangasek> robru: no, not exactly.  You'll need to find out from sil2100 what the final decision has been
<infinity> cyphermox: Why the whacky versioning on those klibc uploads?
<mapreri> infinity: thanks for that!  (as fixing the seed for me would mean pinging people anyway) :)
<cyphermox> infinity: is it that wacky?
<infinity> cyphermox: Yeah.  Should be 2.0.4-8ubuntu1.1, 2.0.3-0ubuntu1.1, 2.0.3-0ubuntu1.0.1
<infinity> cyphermox: Normally, anyway.
<cyphermox> bah
<cyphermox> reject them and I can reupload
<infinity> cyphermox: -NubuntuN.$release tends to imply identical code backporty things.
<mapreri> infinity: umh, `seeded-in-ubuntu myspell-sv-se` and `seeded-in-ubuntu hunspell-sv-se` return nothing here, though.
<infinity> (Not that we have hard rules about this)
<infinity> mapreri: seeded-in-ubuntu takes source arguments, not binary.
<mapreri> meh.
<cyphermox> infinity: it's the exact same patch/diff on different releases, which do have the same original code
<infinity> mapreri: Or, I can bypass the tool with:
<infinity> (base)adconrad@nosferatu:~/backup/adconrad/backup/adconrad/build/seeds$ rgrep myspell-sv-se | grep yakkety
<infinity> ubuntu-gnome.yakkety/supported: * myspell-sv-se
<infinity> ubuntukylin.yakkety/supported: * myspell-sv-se
<infinity> ubuntu.yakkety/supported: * myspell-sv-se
<infinity> edubuntu.yakkety/dvd-langsupport: * myspell-sv-se
<mapreri> `seeded-in-ubuntu hunspell-sv` returns only ubuntu, ubuntu-gnome, ubuntukylin, no edubuntu.
<infinity> cyphermox: I mean we tend to use that versioning when the upstream version is the same on all releases (firefox and tzdata come to mind).
<mapreri> so fun.
<infinity> mapreri: edubuntu is half dead/dying, the tool might be smarter than my seed checkout in that regard. :)
<mapreri> :>
<cyphermox> infinity: the upstream version on trusty and wily is the same
<cyphermox> (well, so is the revision too)
<infinity> cyphermox: Yeah, I know.  Meh.  I'm not super picky either way.  The security team would do that the way I said above, but they're also not the only source for version standardisation, as we have no real standard. :)
<cyphermox> I may be again working with older doc, but I'm more or less following https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
<cyphermox> right
<cyphermox> I don't care either way, I used this because it's a mental shortcut when I was preparing backports just before.
<infinity> They don't even follow their own rules all the time. :)
<cyphermox> hehe
<infinity> (See recent glibc in proposed)
<cyphermox> like I said, maybe that's old outdated doc
<cyphermox> I had some trouble finding it again :)
<infinity> cyphermox: I just wasted 5m bikeshedding something that doesn't matter, so I'm done.  We can take what you uploaded if you like it well enough.
<cyphermox> ok
<cyphermox> I'll prepare my next NM SRU as 1.2.0-0ubuntu1.16.04.0.1.just.to.mess.with.infinity.1
<infinity> cyphermox: That would get rejected. :P
<cyphermox> d'oh
<sbeattie> Oh man, did I forget the git hash, the current discordian date, and my astrological sign in the *glibc upload versions?
<infinity> sbeattie: Hah.  No, you used -NubuntuN.1 and -NubuntuN.0.1 versioning where the doc claims you should use .15.04 and .15.10 when versions are the same.
<infinity> sbeattie: But I think that part of the doc is wrong and you were right. :P
<slangasek> 0e725a8-prickle-prickle
<infinity> https://en.wikipedia.org/wiki/Discordian_calendar#Implementations
<infinity> Man, I never even noticed ddate was gone.
<infinity> I guess I don't use it enough.
<wxl> ddate is gone? :(
<infinity> Well, it's in a new source now.
<infinity> It was dropped from util-linux.
<wxl> that's terrible
<sbeattie> well, somebody (not naming names) had already done a round vivid/wily glibc updates, so I was just following suit, trying to stick to the existing pattern.
 * wxl exercises the turkey curse on the maintainers
<sbeattie> oh man, ddate out of util-linux? I guess it *has* been a while since I took the bit out of my mytt config to automatically add a ddate header.
<sbeattie> s/mytt/mutt/
<infinity> sbeattie: Never fear, "apt-get install ddate" returns sanity.
<infinity> Now to put that in the minimal seed.
<mapreri> "apt-get is dead.  long life apt."
<infinity> I still type "dpkg-buildpackage -i -I -rfakeroot -uc -us -S" when I could probably just type "debuild -S", I don't think I'll ever switch from apt-get to apt.
<wxl> too bad there's not a ddate implementation to cron. then there REALLY could have been some controversy
<mapreri> o.O
<mapreri> i don't even know off-hands what -i and -I do...
<infinity> Set up default ignore patterns.
<infinity> See -i and -I docs in dpkg-source(1)
<mapreri> ya know, that's why i have a ~/.devscripts setting them for me (and i use debuild) :P
<infinity> I think the -i and -I ignore patterns might now be default without specifying.  I know -rfakeroot has been the default for years (maybe a decade or so now)...
<infinity> But retraining fingers is hard.
<slangasek> infinity: what, dropped from util-linux and nobody made util-linux Pre-Depends: ddate for upgrades?!
<infinity> slangasek: ikr?
 * infinity thinks it might be Burger Time (the event, not the underrated video game), then finally time for autosync to return.
<cyphermox> xnox: don't you still need to kill gpg-agent every time you remove and reconnect your yubikey?
<xnox> cyphermox, no
<xnox> cyphermox, but e.g. $ stop gpg-agent; start gpg-agent
<xnox> can help if and when scdc daemon throws up on itself, afer e.g. suspend and resume
<cyphermox> well, pcscd is masked here because it's always in the way
<cyphermox> whenever it is running it tends to take over the card because it can also do straight smartcard
<Logan> doko: do you think the increase in outstanding merges at the end of the Xenial development cycle (compared to previous ones) might be due to the death of UDD?
<infinity> Logan: I'd say it's a combination of people not running "grep-merges" and people not wanting to make drastic changes in an LTS.
<infinity> Logan: I don't see how UDD really factors in, given that it made most simple merges harder, not easier, IMO.
<Logan> I had issues using grab-merge because it doesn't automatically unapply quilt patches
<Logan> and it also didn't give me an easy way to merge from experimental instead of unstable
<Logan> in any case, dgit integration can't come soon enough ;)
<infinity> Initial autosync in progress now.
<Logan> \o/
<cyphermox> slangasek: ^ efivar for mokutil, along with mokutils where appropriate...
<doko> xnox, I wasn't given a link, and then I forgot :-/
<doko> infinity, autosyncs not yet running?
<infinity> doko: It's in progress.
<infinity> doko: Hence the NEW trickling in.
<doko> ahh
<doko> just 500?
<infinity> doko: 2824, but LP can't batch that many at once, so it's going in chunks.
<xnox> doko, lemonade =) let the librarian breath =) no need to be all jay-z about it.
<xnox> *breathe
 * doko fethes a beer
<doko> fetches even
<xnox> there will be a forever of autopkgtests too...
<infinity> Indeed.
<infinity> I believe the last time I sent the archive opening email, I recommended that people chillax for a few days while autosync ate all the infra. :P
<infinity> Om nom nom.
<xnox> Laney, http://people.canonical.com/~ubuntu-archive/transitions/html/boost1.60.html looks odd. why boost-defaults is red on s390x?
<doko> xnox, why do you care? it migrated
<xnox> doko, i suspect stale meta-data -> stale table results to see what else needs doing.
<mapreri> infinity: have you got any chance at fixing up the seeds and remove hunspell-sv?  :)
<infinity> mapreri: I'll get to it.
<infinity> mapreri: I don't imagine it'll harm anyone to be there a few more hours. :P
<mapreri> i'd say not, no :)
<mapreri> also because the lo-dicts migration is blocked also on ubuntu-keyboard, which is stuck in proposed waiting for the autopkgtests queue to get over with it...
<mapreri> opening the archive and turning on the auto-syncs has the effect of stalling autopkgtests, apparently :)
<bdmurray> infinity: Bug 1572416 was verified so I think we are good to release ubuntu-release-upgrader
<ubot5> bug 1572416 in ubuntu-release-upgrader (Ubuntu Xenial) "do-release-upgrade crashes in Greek locale" [High,In progress] https://launchpad.net/bugs/1572416
<infinity> bdmurray: Mmkay.
<infinity> bdmurray: The autopkgtests fail.
<infinity> Which, apparently, they've been doing for a while, and no one cared.  Whee.
<bdmurray> infinity: that isn't a new failure
<infinity> bdmurray: Yeah, so I see.
<infinity> Perhaps related to this?
<infinity> (nosetests3:8783): Gtk-WARNING **: Locale not supported by C library.
<infinity> 	Using the fallback 'C' locale.
<infinity> ie: are you trying to use a UTF-8 locale without building it?
 * infinity looks.
<infinity> bdmurray: Just going to test this locally quickly, then release it.
<bdmurray> infinity: okay, I'll update the meta-release file after that
<infinity> bdmurray: Still mulling over if we should copy the apt from updates to security as well.
<infinity> bdmurray: Otherwise, people trying to do-release-upgrade from security-only systems will just not be able to.
<bdmurray> infinity: that'd be ironic when the release become EoL
<infinity> bdmurray: Lemme do a quick scan of apt binaries to see if they'll need a rebuild in the security PPA or if they can be cleanly copied.
<infinity> mdeslaur: I scanned all the apt/trusty-updates binary deps, and they're all satisfiable in trusty-security.  Mind if I copy it over, same rationale as dpkg (want to fix upgrade bugs for people running security-only)?
<infinity> Dyslexic spam misread of the day:
<infinity> 18197 N + Apr 26 Natural Life    (0.8K) Scientists Discover Cure to Candida
<infinity> I read that as "Canadia".
<teward> infinity: heh
<bdmurray> infinity: what about wily's apt?
<infinity> bdmurray: Oh, should be the same story, but I should also scan it.  Thanks.
 * infinity gets downloady.
<infinity> wily's is also safe to copy.
<infinity> sbeattie, tyhicks, care to have an opinion, since mdeslaur seems to be selfishly away from his computer after hours?
<infinity> bdmurray: FWIW, "LANG=C.UTF-8 xvfb-run nosetests3" fixes that one test failure.
<infinity> bdmurray: But I agree, not a regression from the previous version, so we can just fix that in bzr and catch it next time.
<bdmurray> infinity: hmm, thanks
<infinity> bdmurray: I can't quite sort out what is trying to set an invalid locale, or where, but overriding it appears to work.
<infinity> bdmurray: Though, if that's required to pass the tests, one might also argue it's required to be set early and always in the upgrader itself.
<infinity> bdmurray: And, thus, not set to pass the tests.
<sbeattie> infinity: I think that's okay, we don't want security-only upgrades to fail.
<infinity> sbeattie: Ta.  Just wanted a +1 before I mess with your pocket.
<infinity> Messing away now.
<infinity> sbeattie: I'm still not convinced that there's anyone who actually runs security-only, but...
<sbeattie> I've .... yet to meet that unicorn, either.
<infinity> sbeattie: If I were to go back in time and do it all over, I'm not sure I'd give people the option.
<teward> infinity: thanks for pushing that SRU up - testing completed.  :)
<infinity> sbeattie: The original intent was to mirror how Debian does it, but Debian doesn't do the rebase-security-on-SRUs thing until after point releases, so we differ regardless.
<teward> infinity: I run security-only, by only doing security updates on my servers in production through Landscape management
<teward> (just sayin')
<infinity> teward: Huh.  So, you're the one.
<teward> infinity: i know several production systems at another workplace running security-only
<teward> and seven clients with the same setup
<infinity> teward: I have unattended-upgrades configured to only *automatically* pull security updates, but I do a manual pass for SRUs (reviewing via apt-listchanges) from time to time too.
<teward> infinity: yeah i do that as well
<teward> infinity: but that's once every quarter
<teward> until then, everything's security-only, and Landscape-managed
<infinity> sbeattie: Well, looks like we found him.
<teward> :P
<teward> but again, Landscape managed, once a quarter everything's snapshotted, and then "UPdate All The Things" gets clicked ;)
<infinity> bdmurray: Yeah, the more I think about it, the more I think it's probably an u-r-u bug, not a test bug.
<infinity> bdmurray: If it needs a UTF-8 locale to function sanely and we're not always setting it (though, I see we make an attempt to sometimes set it?), derp.
<infinity> bdmurray: Unless the tests, being all unit-testy, just aren't invoking things in the same was as the actual applications do, and at runtime, it's *always* C.UTF-8, then it's a testsuite bug.
<infinity> bdmurray: But worth a ponder.
<infinity> s/same was/same way/
<bdmurray> infinity: got it, thanks. You'll release u-r-u?
<infinity> bdmurray: Check your mail.
<infinity> bdmurray: All the right apts and dpkgs should be in place too.
<infinity> bdmurray: Well, when the publisher catches up to my abuse.
<infinity> bdmurray: You might want to grab dinner or a drink or go salsa dancing before updating meta-release.
<infinity> bdmurray: The publisher is churning on a LOT of stuff from the autosync.
<infinity> The downside of more and faster buildds is that we can dump half a distro on disk in a half hour period, apparently. :P
<infinity> slangasek: Were you going to do any simple runtime tests to your command-not-found update before releasing it?
<infinity> (ie: install it, type some not found commands, check output, make sure it doesn't vomit on its own DB, release)
<slangasek> infinity: well I /wasn't/ going to, but I can take a hint
<cjwatson> infinity: I can disable three-quarters of them if stuff is building too fast for you.
<infinity> cjwatson: I can too. :P
<cjwatson> infinity: Or, you know, on ppc64el we can just wait an hour and they'll disable themselves. :P
<infinity> cjwatson: Hah.
<infinity> cjwatson: I love that right when we're going to kill it and move it to scalingstack, the P7 powerpc builders have become rock solid.  It's like they can sense impending doom.
<infinity> cjwatson: Modulo upgrade reboots, I haven't had a single one have a problem on lts-x (which is comforting).
<cjwatson> infinity: For values of "right when" that include deploying a new scalingstack region, but yes.
<infinity> cjwatson: Oh, the ppc64el thing seems to have already happened.
<cjwatson> infinity: Yeah, two compute nodes appear to be sad.  See #is.
<infinity> cjwatson: Is that sea of "cleaning" just two nodes?
<cjwatson> infinity: You have to factor in ppc64el scalingstack's background unreliability as well.
<infinity> cjwatson: Oh well, I look forward to powerpc's 9 POWER7 builders beating it.
<infinity> Proving that 9 healthy middle-aged men can beat up 30 crippled 20-year-olds.  Or something.
#ubuntu-release 2016-04-27
<cjwatson> infinity: I think actually three busted nodes.  The thing with Cleaning is that if a lot of instance resets are sitting there for minutes failing to boot, then they can starve the instance reset workers of resources.
 * infinity nods.
<infinity> cjwatson: Has anyone managed to come up with a reproducer that we can throw at IBM and say "fix, pls"?
<cjwatson> Not to my knowledge.
<infinity> cjwatson: Like some sort of "run qemu in a loop really fast and watch the world burn" thing?
<teward> infinity: are autopkgtests taking eons or is it just me?
<cjwatson> I believe William tried that kind of thing and failed to come up with a reproducer.
<infinity> teward: Everything is taking eons, welcome to autosync.
<cjwatson> teward: Look at the queue lengths on http://autopkgtest.ubuntu.com/running.shtml
<teward> heheh
<infinity> teward: You'd be better off ignoring reports and migrations and such for a couple of days, it's lower stress that way.
<teward> cjwatson: eww
<cjwatson> Don't expect stuff that lands on the end of it to come out very soon
<teward> infinity: ack, thanks for accepting the SRU (with the pending yakkety-proposed -> yakkety migration being stuck)
<infinity> teward: yakkety'll get there eventually.  Just stop babysitting and find something more fun to do. :)
<cjwatson> I would be astonished if migrations weren't mostly stuck right now. :-)
<teward> infinity: was actually just checking is all, though what the running page shows and proposed migration excuses show don't match :p
 * teward was just curious
<teward> I was more concerned about that SRU than I was yakkety, 'cause Yakkety will land eventually :p
<infinity> teward: excuses shows the state as of the last time it was generated.  Which was a while ago.
<infinity> (Because everything is slow right now, blah blah)
<teward> heheh
<teward> indeed
<cjwatson> [6~[6~$ curl -s http://people.canonical.com/~ubuntu-archive/auto-sync/2016-04-26/20:00:02.log | grep Updated: | tr -s ' ' | cut -d' ' -f2
<cjwatson> 2824
<cjwatson> $ curl -s http://people.canonical.com/~ubuntu-archive/auto-sync/2016-04-26/20:00:02.log | grep Updated: | tr -s ' ' | cut -d' ' -f2
<cjwatson> 2824
<cjwatson> Sigh, sorry for the dup
<Laney> xnox: I should say it's because there are NBS packages in yakkety which are bad, for example libboost-context-dev.
<mapreri> infinity: ! thank you â¥
<xnox> Laney, found it
<xnox> doko, pitti - please cleanup NBS of boost-defaults on s390x, as in please remove
<xnox> libboost-coroutine-dev 1.58.0.1ubuntu1 s390x
<xnox> libboost-context-dev 1.58.0.1ubuntu1 s390x
<pitti> xnox: hm, that's not on http://people.canonical.com/~ubuntu-archive/nbs.html ?
<xnox> pitti, it's NBS on some arches only. It is built practically everywhere, apart from a few niche arches.
<xnox> pitti, e.g. it is valid on all other arches....
<pitti> well yes, but the nbs report is supposed to have that
<xnox> pitti, there is libboost-doc 1.58.0.1ubuntu1 yakkety all too
<xnox> from rmadison
<pitti> xnox: removed
<xnox> doko, pitti, infinity - could you please promote libboost-random1.60.0 and libboost-regex1.60.0 to main?
<xnox> otherwise ceph will not migrate...
<xnox> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ceph
<pitti> ah yes, it's on http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt
<doko> publisher runs are slooowwww
<pitti> err, wait -- libboost-random1.60.0 does not exist at all in rmadison
<pitti> sorry, looked in xenial
<xnox> >_<
 * xnox was like surely the world would be on fire
<pitti> yeah, publishers, testing, everything will be a tarpit for the next days
<pitti> rmadison is also dog slow, FWIW
<pitti> xnox: so why is change-override yelling at me
<pitti> $ change-override -s xenial-proposed -c main libboost-random1.60.0 libboost-regex1.60.0 libdatrie1-udeb libthai-data-udeb libthai0-udeb
<xnox> pitti, s/xenial/yakkety/ ?
<pitti> don't say anything
<pitti> xnox: same error, though
<pitti> lputils.PackageMissing: Could not find binaries for 'libboost-random1.60.0/None' in yakkety-proposed
<pitti> ah, that's already in yakkety
<pitti> this is utterly confusing
<pitti> promoting some binaries in -proposed, some in -release, and hoping that LP/britney will DTRT on landing -proposed packages
<doko> outdated reports?
<pitti> xnox: ok, promoted the lot in y-release; I hope that shines through to yakkety-proposed, let me know if it still doesn't work in an hour or so
<xnox> doko, not really. thanks to my patches to britney components missmatches must be satisfied before things migrate.
<xnox> thus e.g. one has to promote things in -release, for packages to migrate from -proposed to -release if they pull new things into main.
<xnox> pitti, ok, thanks.
<mdeslaur> infinity: did anyone answer you yesterday? it's scrolled out of my scrollback buffer, what was it for, apt?
<mdeslaur> infinity: oh, looks like you did it, never mind
<Odd_Bloke> If someone could migrate gce-utils from (partner) xenial-proposed to xenial, it would be much appreciated. :)
<xnox> Err:11 http://ddebs.ubuntu.com yakkety-updates Release
<xnox>   404  Not Found
<xnox> pitti, ^ is that normal? =)
<pitti> xnox: I'm getting similar errors from the ddeb-retriever builders since yakkety's creation; I haven't investigated that yet
<pitti> i. e. ddeb-retriever cannot find yakkety-updates indexes on the archive (which I don't understand, they are there)
<xnox> ack.
<xnox> pitti, ceph looks good now, it now progressed to scheduling autopkgtests....
<pitti> xnox: so, on my list, but not top prio
<xnox> 600 more armhf builds to go, 2k autopkgtests and can start investigating fall out =)
<pitti> 600? that was quick
<pitti> xnox: ah, it's more like 1900 :)
<xnox> 600 builds to go on https://launchpad.net/builders =) 2k autopkgtests pending ;-)
<pitti> oh right, sorry
<pitti> xnox: yeah, isn't opening week fun :)
<pitti> xnox: we had > 5000 tests per arch this morning, I already short-circuited most of the perl ones
<xnox> cheat
<pitti> well, it wasn't a new upstream release or so, just a debian rev with three relatively small chagnes; so running only some tests was good enough
<pitti> otherwise doko would haunt me for not landing anything at all any more :)
<Odd_Bloke> Should amd64/i386 be absent from http://cdimage.ubuntu.com/releases/16.04/release/ ?
<xnox> yes
<xnox> Odd_Bloke, amd64/i386 is on releases.ubuntu.com
<Odd_Bloke> xnox: Of course, how silly of me. ;)
<xnox> Odd_Bloke, think [archive|ports].ubuntu.com
<Odd_Bloke> xnox: Ack, that's helpful, thanks.
<cjwatson> pitti: it occurred to me that the ddeb-retriever errors are maybe it complaining about its own archive, not archive.u.c?
<cjwatson> pitti: since it is indeed true that /srv/ddebs.ubuntu.com/www/dists/yakkety-updates/ doesn't exist
<xnox> cjwatson, pitti - my compaint is about ddebs.ubuntu.com missing yakkety-updates initialisation.
<xnox> also xenial-security is missing
<pitti> xnox: yes, understood
<xnox> huh, -security is missing on all after trusty
<pitti> xnox: -security isn't a thing on ddebs
<xnox> ok
<pitti> we always immediately copy -security to -updates
<pitti> for better mirror load
<xnox> then just yakkety-updates was not (yet) created on ddebs.
<pitti> infinity, slangasek: can you please have a look at my last comment in bug 1547466 ? i. e. do you agree that we should just SRU grep 2.25 wholesale or should I continue monkey-patching this?
<ubot5> bug 1547466 in grep (Ubuntu Xenial) "grep switches into binary mode while processing a text file" [Undecided,In progress] https://launchpad.net/bugs/1547466
<stokachu> is getting a MRE for my packages the way to go in order to have newer features (in addition to bug fixes) approved for xenial? packages im referring to are in universe (conjure-up, bigdata, openstack)
<infinity> pitti: I'm inclined to agree with the "just update to 2.25" position.
<slangasek> stokachu: an MRE is specifically intended for upstreams that do bugfix-only releases.  We do make other exceptions for featureful upstream releases but they are more exceptional
<slangasek> pitti: given that we seem to have landed on a lemon of a release with grep 2.24 I'm ok with 2.25 in principle, but how do you propose to regression-test this?
<stokachu> slangasek: ok, specifically in conjure-up, openstack case is there something I need to file with the TB to get an exception for new features?
<stokachu> they are listed as part of juju's exception process so i wasn't sure if i needed to do anything else
<slangasek> stokachu: "listed as part of juju's exception process"?
<slangasek> stokachu: the TB has ruled that the SRU team has the authority to make their own decisions about these exceptions without them going to the TB.  However, there is no structure in place within the SRU team to review these.  So I do think the TB is still the best place for now to get these things done
<stokachu> slangasek: sorry looks like it was just an SRU that included enhancementshttps://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1573176
<ubot5> Ubuntu bug 1573176 in juju-core (Ubuntu) "[SRU] Juju 2.0 for Xenial" [Undecided,Fix released]
<pitti> slangasek: grep has tests itself and for these changes, but of course that doesn't tell us if anyone was relying on the grep 2.2[34] binary behaviour under C by now; although that's rather adademic IMHO
<pitti> slangasek: beyond that, I don't have a good idea myself how to define regression tests for that other than the obvious test for fixing that bug (i. e. whether it causes new FTBFS)
<pitti> it could just equally be that the regression in .24 (grep -Pz) breaks stuff
<pitti> so in summary having the fixes seems better to me than keeping the current broken behaviour
<pitti> but yeah, difficult :(
<slangasek> pitti: I don't consider an upstream testsuite sufficient regression testing for such a core tool.  Maybe an archive rebuild, yes
<pitti> wrt. regression testing backporting that (huge) fix vs. taking the full release doesn't make much difference either
<slangasek> and a longer aging?
<pitti> i. e. maybe we should step back and rather ask us "do we want to fix this bug at all"
<slangasek> I think we do
<slangasek> it's a huge and problematic interface change
<pitti> I think we should, but saying "no" would be policy compliant too)
<slangasek> and if we had C.UTF-8 as default everywhere already then we could ignore it
<slangasek> but as it stands this has a big negative impact on the LTS
<pitti> yeah, folks upgrading from trusty who then find their usages of grep broken won't be amused
<pitti> so back then when we fixed all the ftbfs fallout that actually sounded like a deliberate (although painful) behaviour change, so I'm glad that it wasn't after all
<pitti> slangasek: an archive rebuild sounds good (maybe on amd64 only), but we build under C.UTF-8 now
<slangasek> it is a misfeature that users' locale is not UTF-8 by default.  infinity had aspirations to fix this for 16.04 but it didn't make the cut
<pitti> if we could do a test rebuild under C, that might help
<pitti> how do you mean? user's locale for a normal install always ought to be a real UTF-8 one, not C (nor C.UTF-8)
<slangasek> pitti: reverting the locale isn't relevant for regression testing, which is what we'd want the archive rebuild for
<slangasek> pitti: "for a normal install" - only for a desktop install
<slangasek> if you do a C locale install, e.g. on a server image where you select no locale at all, you get ASCII where you should get UTF-8
<pitti> for server and cloud too
<pitti> ah, does server allow you to choose C? (it's been a while since I did a d-i server install, but I don't remember that)
<pitti> sorry, time for basketball, will be back in a few hours
<slangasek> not only that, but there are environments (chroots, etc) where by default you're never selecting a locale, period
<pitti> wgrant, doko: how difficult would it be to do an archive rebuild (one arch only) against xenial plus grep from xenial-proposed?
<pitti> yes, sure
<slangasek> (and schroot's handling of LANG has been making me mad for some time, besides)
<pitti> I'm not saying it doesn't happen, I just disagree that it can be considered "our normal default"
<pitti> in the end stuff needs to work in both
<slangasek> When you don't configure a locale, the default is C.ASCII.  That we have installers which guide you to choose a locale doesn't change this
<cjwatson> pitti: copy it to a PPA and then it's easy
<pitti> slangasek: right (not sure what we're actually debating now)
<pitti> cjwatson: ah, that's even easier
<slangasek> pitti: the meaning of the word "default" ;)
<slangasek> pitti: enjoy basketball :)
<pitti> ah :)
<cjwatson> pitti: though I'd like to wait until the current librarian expiry situation is sorted out a bit better, if that's possible
<pitti> cjwatson: oh, absolultely
<slangasek> but in fact, maybe this highlights misunderstanding between infinity and myself about how this should be fixed... he may be assuming that it's a sufficient fix to set C.UTF-8 in all environments by default, and I may have just argued that this is not sufficient
<pitti> ok, will copy to a PPA when I'm back
<infinity> slangasek: If you're arguing for redefining the libc C/POSIX as C.UTF-8, that could be rather surprising to people who actually expect it to be ASCII.
<infinity> slangasek: I think the best we can do is attempt to make all system/user login environments default to C.UTF-8 (when not otherwise specified) and call it good enough.
<slangasek> infinity: I'm arguing that when no locale env vars are set, C.UTF-8 should be used instead of C
<infinity> slangasek: But POSIX says otherwise.
<infinity> slangasek: If you mean that when nothing is specified, a login session should SET C.UTF-8 (ie: mangle pam_env to do this), I could get behind that.
<infinity> slangasek: But when you explicitly unset it all after that, it should come out POSIX.
<slangasek> pfft
<xnox> slangasek, given that C.UTF-8 is a superset of POSIX....
<xnox> infinity, that is ^
<infinity> xnox: Yes and no.
<slangasek> infinity: can you point me to the bit of POSIX that specifies this?
<slangasek> I'd like to spend the next half hour of my life rules-lawyering you
<xnox> =)
<infinity> xnox: C.UTF-8 contains the same characters at the beginning of the codeset as C, yes, but UTF-8 still isn't ASCII, and pretending it is is surprising if you expected ASCII.
<cjwatson> POSIX actually contradicts infinity, although I think I still agree with infinity that keeping it ASCII is a safer choice
<cjwatson> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.html#tag_07_02
<cjwatson> "This default locale can be the POSIX locale or any other implementation-defined locale"
<mdeslaur> heh, was about to paste that :)
 * mdeslaur loves butting into other people's arguments
<infinity> "For C-language programs, the POSIX locale shall be the default locale when the setlocale() function is not called."
<infinity> cjwatson: It seems to contradict itself. ;)
<cjwatson> Ooh, now that's subtly different
<infinity> Or, we're arguing what "default" means again.
<cjwatson> setlocale() not called != setlocale() called but no locale env vars present
<cjwatson> I would certainly argue that it is less confusing for those two situations to result in the same thing
<infinity> Indeed.
<slangasek> I would argue that if you're calling setlocale(), you're i18nized and expecting to deal with non-asciiness at some level, and if you're not calling setlocale() you're not, so a difference in behavior there is actually o
<slangasek> k
<infinity> slangasek: I agree that it's "ok", but it's still confusing from a user perspective.
<slangasek> especially when the only difference we're actually talking about is whether or not to choke on utf-8
<infinity> Anyhow, we could indeed change the setlocale() with empty vars behaviour.  I've never been super comfy about doing that because C.UTF-8 isn't actually a builtin (ie: it requires an external locale def), but we try really hard to make sure it's always on disk and built.
<slangasek> infinity: supposing we don't change the default locale under setlocale().  can you tell me how to make the behavior of my schroot not suck?  Because pam_env on the host already sets my desired locale for the host, which is not C.UTF-8; that is /not/ the correct locale for use inside the chroots, where I should not have to install langpacks or have matching locales configuration; and I believe
<slangasek> schroot currently deals with this by unhelpfully nuking any locale env vars.
<infinity> slangasek: schroot invokes pam, it could be pam_enving as well.
<infinity> slangasek: But you bring up a valid point for bare chroot(1) perhaps.
<infinity> (Though, it's never bugged me that those are POSIX)
<slangasek> infinity: it invokes pam on the host. pam_env already sets *the correct locale for the host*.
<infinity> Oh, I was just grepping code.  It doesn't call into pam in the chroot?  Check.
<infinity> I guess that would be a nonsensical thing to do if you're not "logging in" to the chroot.
<infinity> slangasek: Anyhow, for individual tools like schroot, the answer could as easily be "set LANG=C.UTF-8".
<slangasek> yeah; if it did call pam in the chroot, I would expect that to be busted in various other ways
<infinity> slangasek: But the larger question is if we should have to, and I get that.
 * slangasek nods
<infinity> slangasek: Though, arguably, schroot should be doing something clever to read /etc/environment and /etc/default/locale (ie: emulating pam_env, if it can't call it).   It's meant to be a much smarter tool than dumb ol' chroot(1).
<infinity> slangasek: So the real question is if the behaviour of chroot(1) is correct, and I'm sort of on the fence there.
<slangasek> infinity: if I have to configure /etc/environment and /etc/default/locale inside each schroot chroot to get sane behavior, that is also full of fail
<slangasek> schroot setting LANG=C.UTF-8 by default is saner, but still has the problem that we have to individually touch each tool whose behavior we want to make sane
<infinity> slangasek: Why?  I treat my schroots as individual "systems", not unlike a container or a VM.  Those are configured via /etc/default/locale
<infinity> chroot(1), on the other hand, just gets spillover from your environment and no guarantee of cleanliness, which is entirely correct, if gross.
<slangasek> infinity: the whole point is that this should *not* be "configuration". This should be "don't be stupid by default".
<apw> isn't that down to making the chroots sane when we deliver them
<xnox> slangasek, i thought glibc doesn't default to C.UTF-8 because it was not compiled-in locale into libc.so|a binary itself, unlike posix. the point of posix/c locale was that it doesn't need any external files. has that been fixed now, and c.utf-8 is compiled into libc.a ?
<infinity> slangasek: Okay, sure.  schroot should set C.UTF-8 if there's no existing config, but I'd argue it should also be honoring /etc/* in case we have an /etc/default/locale that says otherwise.
<infinity> xnox: c.utf-8 is still external.
<infinity> xnox: Even in our talks about integrating it upstream, no one's yet gone down the scary road of trying to make it a built-in.
<xnox> right, then it can't be universally default.
<xnox> infinity, i tried and failed when working on clearlinux
<infinity> We do always ship it pre-compiled with libc.so, so for the dynamic case, it's basically as good as builtin (though, we'd need to make sure to pull it into the initrd, etc).
<infinity> But for static, it's a bit more of a crapshoot.
<infinity> Especially with craptastic Built-Using tracking, which we need to fix.
<infinity> Since the compiled version on disk may not match what the setlocale() you compiled into your binary expects.
<infinity> Well, also means the concept of a portable 100% static binary dies.
<infinity> But hey, libnss broke that more than a decade ago.
<infinity> Ideally, I'd like to figure out how to make the upstream build system let you pick a --setlocale-default and build that locale into libc.{so,a} at build time.
<infinity> That would make this less scary.
<infinity> That would also let embedded vendors build, say, a C+ru_RU system without the overhead of external locales.
<infinity> Which would be neat.
<doko> pitti, pretty easy. is this urgent? I'm planning to do one with an updated gcc too, but not yet
<pitti> doko: not "this week" urgent for sure, the buildds are aching enough as they are
<pitti> doko: perhaps next week or so, when the dust settles
<pitti> for now, just discussing options how we could verify the new grep
<pitti> slangasek: if doko wants to do a test rebuild with gcc-6+the new grep, would you consider this a close enough approximation? doing two rebuilds at the same time seems a bit wasteful
<pitti> (grep 2.25 is in yakkety already)
<pitti> â© âª 5.500 tests on the wall, 5.500 tests -- break one cloud, upload one perl, 8.800 tests on the wall â« â¬
<slangasek> pitti: yes, that's fine by me
<slangasek> tests> heh
<slangasek> queue under 2k!  fancy
<pitti> slangasek: btw, there are 8 extra armhf workers on scalingstack now
<slangasek> pitti: excellent :)
<pitti> slangasek: of course I get a watchdog email every 15 minutes or at least 2 hours which hard-reboots them, so I'm not entirely sure how much load they actually take off
<pitti> as each hang causes the client side to hang for a fair while too (until commands time out)
<pitti> but I think the net result between taking off load and introducing hangs is still positive, armhf was a lot furhter behind yesterday (relative to x86)
<pitti> slangasek: can you exercise your magic management powahs to make cking available to me for half a day or so on our sprint? :-)
<pitti> he's a miracle on figuring out such stuff, and I don't have a clue how to debug this any further :(
<pitti> speaking of breaking clouds -- wgrant, cjwatson: https://launchpad.net/builders â quo vadis, lcy01 buildds?
<pitti> FWIW, on my side I keep running into "ERROR" states recently again, but it's by and large running
<slangasek> pitti: cking isn't mine to give you, put something on the sprint agenda and ask ogasawara ? :)
<cking> i am sure that is doable
<pitti> ah, there's not a list, but a timetable; I'll pick some random time and let ogasawara move it around or slap my fingers then :)
<pitti> cking: that'd be great, thanks
<pitti> ah no, there's a link to "kernel agenda", found it
<pitti> r/o
<slangasek> infinity: apparently we've had cloop as a "supported" "desktop" package in main since 2008 to support mounting livecds.  But I'm pretty sure that's not compatible with any format we're currently using. ;)  Should we drop that from the seed?
<infinity> slangasek: Oh, it was manually seeded?  Oops.  Should have dropped out when we dropped the dep from livecd-rootfs.
<infinity> slangasek: Kill mit fire.
<slangasek> infinity: gekillt und gepusht
#ubuntu-release 2016-04-28
<slangasek> infinity: should casper and livecd-rootfs be using xz-utils instead of lzma?
<infinity> slangasek: And dell-recovery probably, yeah.
<doko> pitti, unable to give back autopkg tests, timing out
<pitti> doko: yes, autopkgtests.u.c. seems to be down, looking
<pitti> i. e. just the debci frontend, the machinery works
<pitti> doko: as soon as the queue settles, I'm going to mass-retry all the failures, though
<pitti> oh, OOM killer
<Odd_Bloke> Why is Vivid still listed as Supported (https://launchpad.net/ubuntu/vivid/)?  (Snappy?)
<apw> Odd_Bloke, yes, that is snappy related, not sure if that status can change or not and keep that side working
<xnox> Odd_Bloke, and because Ubuntu Touch is on vivid too
<xnox> Odd_Bloke, note how vivid is not gone from the mirrors.
<Laney> vivid was a vintage release
<Laney> top quality packages
<Laney> good sun that year
<xnox> Odd_Bloke, use distro-info / distro-info-data, don't trust launchpad. it's supported to keep PPAs working for phone landings.
<xnox> Laney, approved by all hipsters in Hoxton
<pitti> I'm sure to the kernel team it feels more like venomous viper by now ;)
<apw> pitti, :)
 * ogra_ thought lag moved to linaro ... 
<ogra_> (oh, wait, he colletc cobras, not vipers)
<ogra_> *collects
<flexiondotorg> Laney or infinity Now I have PPU for some Ubuntu MATE packages, what does the SRU process look like?
<flexiondotorg> Do I file an SRU and get a release team ack and then upload? Or can upload directly?
<pitti> flexiondotorg: file an SRU bug and upload
<flexiondotorg> pitti, So file SRU and then upload without ack?
<pitti> flexiondotorg: yes, it'll be held in the unapproved queue anyway, where the sru team will review it
<flexiondotorg> pitti, Thanks.
<flexiondotorg> infinity, I tried upload ubuntu-mate-welcome to xenial for an SRU and I was rejected.
<rbasak> flexiondotorg: when I first got upload rights, I discovered that packagesets are per-release. Which I agree is a pain :-/
<rbasak> Unless there's some reason not to, it would make sense to add you to those packages for Xenial as well, since that's what we agreed. I don't know how though.
 * rbasak should probably learn that.
<flexiondotorg> rbasak, I was informed during the DMB meeting that the PPU would be applied to Xenial and Yakkety.
<flexiondotorg> SO I can maintain Xenial.
<rbasak> flexiondotorg: agreed, that's what I mean.
<infinity> flexiondotorg: My bad, I haven't set up the packageset yet.  I'll get to that right after my morning meeting.
<infinity> flexiondotorg: I'll ping you when it's done so you can try again.
<bzoltan_> infinity: would you pleas re-trigget the autopkg test for this https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-047/excuses.html
<flexiondotorg> infinity, Cheers.
<infinity> pitti: Remind me of the syntax for nudging the non-archive autopkgtests? ^^
<pitti> infinity: retry-autopkgtest-regressions --ci-train landing-047 -s vivid
<pitti> infinity: that'll generate the commands to stdout
<infinity> pitti: Shiny.
<infinity> bzoltan_: Done.
<bzoltan_> infinity:  thank you
<slangasek> grah.  what is pulling ocl-icd into main?  seeded-in-ubuntu claims it's 'supported' and grep of the seeds disagrees
<slangasek> oh. not in main, but in restricted, right
<infinity> nvidia-opencl-icd-304 might belong in multiverse.
<infinity> Oh, but nvidia-XXX recommends nvidia-opencl-icd-XXX
<infinity> So that would need fixing if we wanted to demote.
<ginggs> infinity, slangasek: we need the icd from nvidia, but the icd loader from ocl-icd
<slangasek> infinity: I don't have a specific reason to demote, I was just being confused when analyzing unowned packages in "main" because restricted != main
<infinity> ginggs: No one's questioning the package selection, just the supported status. :)
<slangasek> though I see it's pulling more dependencies now
<infinity> slangasek: Ahh, fair enough.
<slangasek> (c-m, this morning)
<infinity> slangasek: c-m could try to be a bit more clear about the non-free components, I suspect.
<slangasek> infinity: and my local why-in-main script could be smarter ;)
<infinity> (As could other tools)
<slangasek> 'reverse-depends -c main src:ocl-icd' <nothing> Whhhhyyyyyyy
<ginggs> infinity: sure, i just know that the naming of these packages is terrible and I've worked with them a bit, so i might be able to clarify what goes with what
<infinity> slangasek: Maybe we should simplify your script by proposing a GR to drop non-free.
<slangasek> infinity: I am submitting an amendment to this GR to replace the word "non-free" with "acid"
<infinity> Duuuuuuuuuude.
<infinity> flexiondotorg: Try that SRU upload again.
<infinity> flexiondotorg: http://paste.ubuntu.com/16102589/ <-- Double-check that for me?  If it looks sane, I'll copy it forward to yakkety.
<infinity> flexiondotorg: Looks like it matches your list, I just re-checked myself.  So, copying.
<infinity> flexiondotorg: And done.
<bzoltan_> folks, I got a little problem :) Vivid is removed from the http://cdimage.ubuntu.com/ubuntu-core/releases/
<bzoltan_> but I still need a core image of Vivid
<nacc> bzoltan_: why? vivid is EOL?
<bzoltan_> nacc: I know, but the Ubuntu Phone is still based on Vivid
<bzoltan_> nacc: and I need to create an SDK image for it, what is based on a core image
<bzoltan_> is this any good? http://cdimage.ubuntu.com/ubuntu-core/vivid/daily-preinstalled/current/vivid-preinstalled-core-amd64.tar.gz
<infinity> bzoltan_: Lemme slap vivid core on old-releases, that should sort you out.
<nacc> bzoltan_: or maybe it's at: http://cdimage.ubuntu.com/ubuntu-touch/vivid/daily-preinstalled/ ?
<bzoltan_> infinity: that would be great
<nacc> (-touch rather -core)
<bzoltan_> nacc:  good hint, I will try the touch too
<infinity> bzoltan_: If you use the ubuntu-core tarball, the touch images won't be much use.
<bzoltan_> infinity: I used to use the core image to patch it with all the SDK API and toolchain pckages.
<infinity> bzoltan_: Yeah, sec.  Resurrecting.
<infinity> http://old-releases.ubuntu.com/releases/vivid/
<infinity> bzoltan_: ^
<bzoltan_> infinity:  thank you!
 * infinity notes upon seeing them in the same directory for the first time that his core naming is inconsistent with other products... Oops.
<bzoltan_> infinity:  sorry to bug you with my problems today :) You might now apt better then me... How is it possible that a package fails to install due to a  strange dependency problem, but the dependency can indeed be installed ->http://pastebin.ubuntu.com/16118469/
<bzoltan_> That happens when a developer tries to bootstrap a click chroot for the phone
<bzoltan_> cjwatson: you might have some idea ^
<nacc> bzoltan_: maybe try `apt-get install ubuntu-sdk-libs:armhf ubuntu-html5-container:armhf` as it might be further down the chain
<nacc> that is the conflict is if it installed the latter, the former becomes uninstallable or something
<nacc> bzoltan_: as you haven't yet installed the original package in that pastebin :)
<infinity> bzoltan_: Indeed, as nacc suggests, try installing both together.
<bzoltan_> infinity: nacc: no problem when I install both
<nacc> bzoltan_: ok, it's hard to say what apt thought, can you get back to the original state (with the second package not installed)? and see if apt will let you specify both? not sure why it's happening otherwise
<lamont> infinity: since you are my favoritest one.... can you help me understand how xenial has not come to live in http://changelogs.ubuntu.com/meta-release-lts
<nacc> lamont: i assume it won't until 16.04.1
<nacc> so as to avoid suggesting LTS -> LTS upgrades before then?
<lamont> oh, right.
<lamont> now all is clear... I'll just go crawl back into my corner and pretend I didn't forget that feature of LTS
<lamont> and it's so sad that dapper never got a .1 :D
<nacc> heh
<ogra_> it had a .6 !
<ogra_> (well, .06 technically)
<pitti> see, not bigger than .1 :)
#ubuntu-release 2016-04-29
<infinity> lamont: dapper had a .1 and a .2!
<infinity> http://old-releases.ubuntu.com/releases/dapper/
<bzoltan_> nacc: apt let me install both together as it installs the ubuntu-html5-container:armhf alone too... only thing it bails out on is to handle the dependency when i installubuntu-sdk-libs:armhf
<lamont> infinity: I was looking at meta-release-lts
<infinity> lamont: Yeah, it's full of lies because it post-dates dapper.
<lamont> heh
<flexiondotorg> infinity, Thanks. Looks like it works :-) ^^^
<ogra_> chpasswd: (user ubuntu) pam_chauthtok() failed, error:
<ogra_> Authentication token manipulation error
<ogra_> chpasswd: (line 1, user ubuntu) password not changed
<ogra_> E: config/hooks/01-setup_user.chroot failed (exit non-zero). You should check for errors.
<ogra_> infinity, did anything change in the xenial archive tonight that isnt on xenial-changes ? i could build xenial images 14h ago ... now it fails in chpassword without any changes in that area
<ogra_> (for snappy that is)
<ogra_> the only thing i see changed in the archive is lamont's bind9 upload ... but it is beyond me how that could make chpasswd fail
<lamont> ogra_: hostname resolution is littered everywhere.  having said that, the change in bind9 was restoring some code in the SHUTDOWN path for bind9 so that it quit throwing an assertion
<lamont> so yeah, confusing
<lamont> there's also a goodly number of different packages seeing this:
<lamont> Processing triggers for mime-support (3.59ubuntu1) ...
<lamont> dpkg: error processing package language-selector-common (--configure):
<ogra_> hmm, does chpasswd use the hostname in any way ?
<lamont> package language-selector-common is already installed and configured
<lamont> ogra_: nfc
<ogra_> i wouldnt expect it to
<lamont> right.  sudo? not surprisingly, does.
<ogra_> no sudo in image builds :)
 * lamont needs to step away
<ogra_> cjwatson, did anything with the LP buildds change tonight ? (i cant build xenial images anymore ... over night with no changes in the area THAT MAKE IT FAIL)
<ogra_> EEK
<ogra_> silly caps
<cyphermox> don't know who did that, but thanks ^
<cyphermox> seb128:  (that was about NM) ^
<Laney> cyphermox: did you upload that ubiquity change yet?
<seb128> cyphermox, happyaron is working on those, I'm doing the sponsoring ;-)
<cyphermox> Laney: no, it's not uploaded, but I will soon
<Laney> rockin'
<cyphermox> it's not like it will make a difference for now.
<cyphermox> oh, otoh people could update ubiquity on the live cd... :/
<Laney> people would be able to use dailies
<Laney> not sure those exist yet though
<cyphermox> yeah
<cyphermox> well for yakkety I'm doing d-i merges now
<cyphermox> console-setup right now, and most of them will need a ubiquity update anyway
<Laney> xenial dailies I mean
<Laney> but y too
<cyphermox> I will upload it now
<Laney> what a beauty you are
<cyphermox> why thank you mon petit pois
<infinity> ogra_: No idea what's up with your image building woes.
<ogra_> infinity, yeah, i'm pretty lost ... there was a minor change in live-build/auto/config (to install u-boot-tools on all arches) ... that built last night just fine ... since this morning all builds fail ... in deparation i already tried a rolled back bind9 in the PPA and now i'm trying a build with all PPA packages removed ...
<ogra_> all show the same chpasswd error
<ogra_> pretty much out of the blue
 * infinity cocks his head sideways at this log.
<infinity> + sed -i /^ubuntu/d /etc/passwd
<infinity> + sed -i /^ubuntu/d /etc/shadow
<infinity> ogra_: If you're deleting the user, how do you expect chpasswd to work?
<ogra_> it is added to the nss-extrausers files ... note that no char in this code has changed in over a year
<ogra_> and the same hook is used on the phone images
<infinity> Ahh, kay.
<ogra_> http://paste.ubuntu.com/16127540/
<infinity> I see no immediate reason why your world would have exploded.
<ogra_> thats the only change in livecd-rootfs
<ogra_> infinity, me neither, thats what bothers me so much ... :)
<ogra_> how can chpasswd break without any changes ...
<infinity> ogra_: You want *all* arches to have u-boot-tools?  Really?
<ogra_> yes
<infinity> ogra_: How or why is it being used on x86 or ppc?
<ogra_> intel edison seemingly uses uboot
<infinity> Fair enough.
<infinity> And, indeed, embedded ppc machines often do too.
<ogra_> in any case there is no reason why that change should break chpasswd all of a sudden
<infinity> Still, I'd expect kernel snaps to come pre-tooled.
<infinity> No, that change should be harmless indeed.
<ogra_> not for the roolback bits
<ogra_> we need to modify some bootloader vars from userspace if boot fails
<cyphermox> infinity: could you obliterate this console-setup? ^ it should have been for yakkety
<infinity> cyphermox: Sure.
<cyphermox> ta
<ogra_> on uboot we use fw_setenv ... on grub grub-editenv for that
<ogra_> the change just seeds fw_setenv
<ogra_> hmm, how long does it take tile a package deletion in a PPA goes active .... seems i'm still getting the PPA livecd-rootfs
<ogra_> (trying to roll back the PPA completely, just to make sure its not anything in there)
<infinity> I see no livecd-rootfs in the PPA Packages file (which I just downloaded)
<infinity> But man, there's a lot of other crap in here.
<infinity> Like gccgo and systemd.
<ogra_> all outdated
<ogra_> ubuntu-core-config, ubuntu-snappy, squashfs-tools and initramfs-tools-ubuntu-core are the only relveant ones
<ogra_> and the only one with recent changes is initramfs-tools-ubuntu-core
<ogra_> everything else has been there yestzerday too
<ogra_> ok, if livecd-rootfs is finally gone let me trigger another build ...
<ogra_> Preparing to unpack .../livecd-rootfs_2.408_amd64.deb ...
<ogra_> Unpacking livecd-rootfs (2.408) ...
<ogra_> ah, finally
<ogra_> it is really annoying that packages you delete are immediately gone from the LP UI ... cheating me into thinking i can build :P
<ogra_> infinity, still failing
<ogra_> infinity, did anything else in the archve change beyond bind9 ?
<infinity> Kay, not surprising, since I couldn't see how your PPA would be breaking it.
<infinity> But I also can't see how updates would be.
<ogra_> right, just wanted to makes sure we can exclude that
<infinity> ogra_: xenial-changes looks accurate to me.
<ogra_> k
<ogra_> well, *something* changed that breaks it
<ogra_> build root behavior changes ? setup changes ?
<infinity> Oh, bah.  Your rebuilds knocked the successful builds off the page.
<infinity> Do you have a successful log?
<ogra_> yes :(
<ogra_> not handy, no
<ogra_> take a yakkety one
 * infinity goes digging in cdimage logs.
<ogra_> (yakkety builds still fine btw, i tested that)
<infinity> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image/+build/59382
<infinity> That's the last success, I'm guessing.
<ogra_> yeah, last night
<ogra_> http://paste.ubuntu.com/16127953/ is the code in question
<nacc> bzoltan_: very strange! I'm not sure why that would be
<infinity> @@ -1039,7 +1039,7 @@
<infinity>    libgnutls-openssl27 libgnutls30 libklibc liblockfile-bin liblockfile1
<infinity>    libnewt0.52 libnl-3-200 libnl-genl-3-200 libp11-kit0 libpng12-0 libslang2
<infinity>    libssl1.0.0 libtasn1-6 linux-base lockfile-progs logrotate net-tools
<infinity> -  netcat-openbsd sudo ubuntu-core-config ucf udev vim-common vim-tiny whiptail
<infinity> +  netcat-openbsd sudo ucf udev vim-common vim-tiny whiptail
<infinity>  Suggested packages:
<infinity> ogra_: So, that's the only meaningful diff I see in the logs.  ubuntu-core-config isn't being installed anymore.
<ogra_> uuuh
<ogra_> why would that be
<infinity> (Well, and livecd-rootfs versions, but we've established that's probably not an issue)
<bzoltan_> nacc:  my best guess is that there was  some black magic casted on that package... anyhow, my workaround is to explicitly install that dependency with the meta package what should pull it. Ugly hack, but does the job.
<nacc> bzoltan_: ok -- if i find time, i will try and reproduce it
<infinity> ogra_: Because initramfs-tools-ubuntu-core also isn't being installed anymore, and that's what pulled it in.
<ogra_> infinity, heh ... task header missing in ubuntu-core-config in the PPA i guess
<ogra_> same for the initramfs packages
<infinity> ogra_: Ahh, is this the first time those have been in the PPA?
<ogra_> but that still doesnt explain why chpasswd would fail ... i dont think we touch anything in that area from either of these packages
<ogra_> infinity, no, but core has no meta ... we only have tasks
<ogra_> if they go to the PPA and you dont hack the task into the control file they are completely ignored ... funnily it is recognized that the archive version is outdated though ... so we end up with no package installed
<infinity> ogra_: Well, those are the only two package differences I see in the log, other than your livecd-rootfs.
<ogra_> but still ... that shouldnt influence chpasswd
<ogra_> argh
<cjwatson> ogra_: No builder changes.
<ogra_> it should !
<infinity> Well, and the bind9 libs, but given the bind9 fix was in the daemon, seems unlikely it would have miscompiled the libs on all arches. :P
 * ogra_ finds a pam config file in ubuntu-core-config
<infinity> Ah-ha.
<ogra_> oh my
<infinity> ogra_: Okay, mystery solved.  You're welcome.
<infinity> ogra_: Also, diffing logs is super handy when trying to answer questions like this.  For future reference.
<ogra_> ok, fixing the task header harder
<ogra_> infinity, thanks so much ... i'll try to remember next time
<doko> infinity, trying to install libcgal-qt5-dev on rugby/yakkety-armhf, ... the package is not seen there in version
<doko> $ apt-cache showsrc libcgal-qt5-dev | grep ^Version
<doko> Version: 4.8-3
<doko> $ apt-cache show libcgal-qt5-dev | grep ^Version
<doko> Version: 4.7-4
<doko> in the release pocket ...
<infinity> doko: ftpmaster agrees.  Curious.
 * infinity copies cgal over itself.
<infinity> Erm, wait.
<infinity> No.
<infinity> https://launchpad.net/ubuntu/+source/cgal/4.8-3/+build/9639663
<infinity> doko: It's gone NBS on armhf (along with a couple of other binaries)
<doko> ohh
<infinity> That feels like a mistake.
<infinity> +cgal (4.8-2) unstable; urgency=medium
<infinity> +
<infinity> +  * Fix FTBFS on armel and armhf caused by missing OpenGL ES support in CGAL
<infinity> +    (and libQGLViewer). Stop building libcgal-qt5-11 and libcgal-qt5-dev on
<infinity> +    armel and armhf.
<LocutusOfBorg> yes, nto a mistake
<infinity> +
<LocutusOfBorg> just removed
<infinity> + -- Joachim Reichel <reichel@debian.org>  Fri, 22 Apr 2016 16:54:32 +0200
<infinity> libcgal-qt5-dev has reverse build-depends.  So, that needs cleaning up.
<doko> ok, removing prepair and pprepair binaries
<doko> ovito and openscad too
<infinity> NBS binaries removed.
<LocutusOfBorg> whoever did setup the json-c tracker
<LocutusOfBorg> it isn't working
<LocutusOfBorg> https://release.debian.org/transitions/html/auto-json-c.html
<LocutusOfBorg> can you please copy ben from here?
<LocutusOfBorg> not sure what is wrong, maybe you need also the -dev packages?
<infinity> I'll fix it up.
<infinity> LocutusOfBorg: Done.
<infinity> Err, or I clashed with someone else.
<infinity> Now done. :P
<LocutusOfBorg> yes, doko fixed it
 * LocutusOfBorg wrote that on devel
<jgrimm> infinity, https://launchpad.net/ubuntu/vivid   still in "Supported" status.. should be marked "Obsolete" as EOL'd?
<infinity> jgrimm: There are unfortunate reasons why we can't close it just yet.
<infinity> jgrimm: So, yes it should be Obsolete, but LP can't say that.
<jgrimm> infinity, heh. no worries,minor thing just wanted to mention in case not realized
<infinity> jgrimm: Well aware. :)
<jgrimm> :)
<alex-abreu> balloons, ping
<balloons> alex-abreu, pong
<alex-abreu> balloons, wondering if you have the powers to re trigger a britney run ...
<balloons> alex-abreu, no magic powers there I'm afraid
<alex-abreu> balloons, ah ... is there someone that does ? :)
<balloons> a hard proposition at this hour on a Friday :-)
<alex-abreu> balloons, indeed
<balloons> off the top, I can't think of anyone still around
<alex-abreu> balloons, are you acquainted w/ britney's error messages?
<balloons> alex-abreu, I would say in general no
<alex-abreu> balloons, ok thank you :)
<slangasek> alex-abreu: what are you trying to retrigger?
<alex-abreu> slangasek, this ci request that apparently generated false positives' results for britney ... (i am not sure about it though but i cannot make sense ofthe error messages), https://requests.ci-train.ubuntu.com/#/ticket/1056
<slangasek> alex-abreu: what do you see that's a false positive? What I see is britney saying that you're making packages uninstallable
<slangasek> alex-abreu: you have a package webapps-demo-click that depends on a package named qtdeclarative5-hud1.0, which only exists in trusty
<alex-abreu> slangasek, that's why i am saying that I am sure about what the diagnostic, ... could you point me to the failure since I dont see where it is
<slangasek> webapps-demo-click/amd64 unsatisfiable Depends: webapps-demo
<alex-abreu> slangasek, ah ...
<slangasek> webapps-demo-click/amd64 unsatisfiable Depends: qtdeclarative5-hud1.0
<slangasek> Not considered
<alex-abreu> slangasek, mmmh thank you ...
<pitti> PSA: I have to rebuild http://autopkgtest.ubuntu.com
<pitti> (this only affects the web presentation, not the test machinery and britney)
#ubuntu-release 2016-04-30
<tsimonq2> infinity: in lintian, are yakkety packages supposed to throw a bad-distribution-in-changes-file?
<infinity> tsimonq2: Nah, needs an update.
<infinity> tsimonq2: It's fixed in 2.5.44 in yakkety-proposed
<tsimonq2> infinity: alright, thank you :)
<infinity> .. which is FTBFS due to the PIE changes.  Whee.
<Ukikie> No pie for you.
<flocculant> or cake
<tsimonq2> infinity: do you like pie? *ahem* ;)
#ubuntu-release 2016-05-01
<darkxst> I notice some packages syncing that require gtk+ 3.20 (which is not going to ready soon) can these be blocked somehow?
<darkxst> infinity, ^
<infinity> darkxst: Erm, not easily.
<infinity> darkxst: Why is ours going to take significantly longer than Debian's?  The Mir patch can't be that bad to forward-port.
<infinity> Debian's had 3.20 in experimental since March, you'd think we would have been paying attention...
<darkxst> infinity, its the CSS Nodes changes, so Unity themes will need a lot of work
<Ukikie> Themes and even some applications.
<darkxst> larsu typically did the themes work, but he has left -desktop team
<infinity> darkxst: What's synced that's breaking?
<infinity> Things like gspell seem harmless, since it didn't exist before.
<darkxst> nothing breaking, will just be stuck in proposed
<infinity> Sure, that's not the end of the world unless it ends up blocking people working on something specific.
<infinity> And if it does, we can work around it.
<infinity> But we should try to migrate ASAP anyway, especially if the new GTK changes lots of things, so we get testing.
<infinity> cjwatson: Dang, wish I'd paid closer attention to uninst on release day.  That node-bones uninst on two arches turns out to be a long string of node packages that are all broken and need removing/demoting (doing now in yakkety).
<darkxst> infinity, ok, so just deal with the packages individually if we need to upload bugfixes?
<infinity> darkxst: Pretty much.  I can't block "everything with N versioned build-dep" and blacklisting all gtk packages is also silly, so...
<infinity> darkxst: If we really need to fix something in an older version, we can remove the newer one, pop the older one in proposed, wait for it to migrate, and reinstate the new one.
<infinity> darkxst: But I really do hope we just move to the new gtk instead.
<darkxst> infinity, ok, thought there might be a way to do that, but thats fine
<darkxst> I can't see it coming "soon"...
<darkxst> gtk+ that is
<infinity> I'll see if I can put some pressure on Will to make it a priority. :P
<darkxst> Will is trying to find someone to work on the theme
<infinity> Ahh, joy.
<infinity> Well, who needs themes anyway?  I remember when GTK applications were grey and square.
<darkxst> there is no one left on the desktop team, that really is familiar with themes
<darkxst> right, lets just go back to the 90's everything was so simple then :)
<infinity> No one in the community he could throw some money at either?
<darkxst> I suggested one person to him
<tsimonq2> infinity: got thrown a W: lxqt-metapackage source: newer-standards-version 3.9.8 (current is 3.9.7)
<tsimonq2> infinity: https://www.debian.org/doc/debian-policy/upgrading-checklist.html shows 3.9.8 as current
<tsimonq2> infinity: what's up with that?
<infinity> tsimonq2: The lintian changelog can probably answer your question without you asking me.
<infinity> tsimonq2: http://metadata.ftp-master.debian.org/changelogs/main/l/lintian/unstable_changelog
<tsimonq2> infinity: I see, but it needs to be synced to Yakkety, seems to be a recent upload so I'll be patient, just thought I'd ask :)
<infinity> tsimonq2: It's in -proposed.
<infinity> tsimonq2: Things are a bit backed up now with the autopkgtest queue, that's all.
<tsimonq2> infinity: which is why I kinda guessed it's too recent yet
<tsimonq2> infinity: I see :)
<tsimonq2> infinity: sorry for my impatience :P
<cjwatson> infinity: node-bones> ah, ok.  thanks for chasing that.
<infinity> cjwatson: I've been bored, I knocked out a few.
<infinity> Should probably sleep.
<infinity> cjwatson: I'm tempted to blacklist 32-bit-only software on the basis that who effin' cares.
<infinity> cjwatson: That would take out a chunk of the amd64 list.
<LocutusOfBorg> good morning, lets try again: I want libpng removed from ubuntu, but you already know that, remaining issues are: faumachine broken in debian too, can't fix, k3d is a boost issue I couldn't understand, openmsx a boost/gcc issue, scantailor is now fixed, virtualbox has some fPIE issues I can't know how to fix, warzone2100 is broken in Debian too, xcftools has some utf8 issues I'm pinging the upstream developer to look at them
<LocutusOfBorg> what are the next steps?
<LocutusOfBorg> BTW for xcftools I guess some export UTF8 on test/dotest are already enough, but I can't test because I have no s390x machine
<ginggs> LocutusOfBorg: openmsx uploaded, there was a fix on github that wasn't there yesterday
<LocutusOfBorg> oh gosh, I looked at openmsx two days ago, and I also tried to build the latest git snaphost :)
<flocculant> darkxst: given that Ali has blogged testing for you on yakkety - I've added yakkety to the tracker for you - you had nothing to test
<flocculant> sgclark: not sure who else is kubuntuish tbh - but you've no builds on the isotracker either
<lordievader> flocculant: Yofel is Kubuntu ;)
<flocculant> lordievader: thanks - yofel ^^
<flocculant> :)
<darkxst> flocculant, ok, thanks.
<sgclark> flocculant: hi, I am a newb, what do you mean by builds on isotracker, Am I suppose to do something? Not sure I would have perms. yofel has been away.
<infinity> flocculant: What do you mean kubuntu has no builds on the tracker?  They've been there since day 1.
<infinity> flocculant: If you mean no testcases, yeah, that seems a bit borked.
<infinity> .. for everyone.
<infinity> Who deleted all the testcases? :P
<infinity> stgraber: ^
<infinity> stgraber: Do they not carry over between series' or did someone oops?
<flocculant> infinity: that I guess
<flocculant> anyway I did for some flavours - deffo borked for ubuntu
<flocculant> tbh  - it always took a poke to get them on the tracker - never automatic
<infinity> Irksome.
<sgclark> sorry to be a pain, is this something I am suppose to be doing? ( still learning here )
<flocculant> sgclark: on the isotracker - flavours have test instances for their iso
<flocculant> sgclark: you 'kubuntu' have none currently :)
<sgclark> gosh we sure don't
<sgclark> but I am clueless on how to remedy that
<flocculant> infinity: well perhaps this is one of those 'if flavours' things - no different than the milestone issue
<flocculant> sgclark: I haz help for you :)
<sgclark> flocculant: yay ty
<infinity> flocculant: IMO, it should be fixed at the source, creating a new series should copy the old one en toto.  But since we can't hop in a time machine and do that, thanks for helping people out.
 * flocculant does wish there was some manual for it though ;)
 * sgclark wants a time machine
<flocculant> infinity: the score is - 'help people' 1 - be stupid 0
<flocculant> sgclark: anyway - I assume you are in the kubuntu 'release team' ?
<flocculant> assuming so - /query flocculant and we'll sort it out for you :)
<sgclark> flocculant: I am suppose to be assistant to yofel. But yofel has been very busy
<flocculant> ack - such is life :)
<sgclark> yep
<flocculant> infinity: there are so many ubuntu ones - I've not even thought about those ...
<sgclark> so I am just trying to learn as I go and be helpful while I have a smidge of time
<infinity> flocculant: Meh, Ubuntu's not your problem.  I'll get it sorted if you don't.  But thanks for helping fellow flavours.
<flocculant> yup - /query me and I'll point you in the right direction :)
<infinity> flocculant: And not sure if sgclark has the right tracker perms.
<flocculant> infinity: always happy to point out there are no directions once I've helped :D
<sgclark> I probably don't
<flocculant> infinity: sgclark just has to be in kubuntu release team afaik
<sgclark> perms has been one of my biggest blockers
<flocculant> if not I can do
<sgclark> I am not official release no
<flocculant> ...
<flocculant> okey doke
 * flocculant puts kettle on
<sgclark> sorry to dissapoint lol
<flocculant> infinity: I'll make yak kubuntu = xenial kubuntu then
<infinity> flocculant: WFM.
<infinity> I'm not actually sure which LP team maps to "kubuntu release" in the tracker.
<infinity> And I can't see the guts to find out.
<infinity> So, meh.
<flocculant> infinity: well https://launchpad.net/~xubuntu-release works for us/me and the perms work
<flocculant> also I'm in ubuntu-qa-website-devel personally so can fix stuff for flavours
<infinity> flocculant: Yeah, but there is no ~kubuntu-release. ;)
<sgclark> well our reelease team for years was just Jonathan.
<sgclark> that is no more
<infinity> Only stgraber and a few others can see what the tracker actually means by "kubuntu release", it's a black box to me.
<infinity> *shrug*
<sgclark> so yofel and I stepped up, but we both still need to get ubuntu-core motu etc
<sgclark> time being issue of course
<sgclark> anyway the whole experience has been an eye opener!
<flocculant> infinity: ok - have perms - will sort them out :)
<infinity> sgclark: core-dev and motu aren't really necessary for flavour people, so long as you have packeset rights to most/all of what you need.
<sgclark> hmm I have had to have everything sponsered it seems
<flocculant> infinity: afaik - I could add kubuntu peeps
<flocculant> but
<infinity> sgclark: But the loss of Riddell and ScottK as "general experienced and privileged Ubuntu people" (release team, SRU, archive admin, etc) is something I need to backfill for.  Not kubuntu's responsibility, though, just sucks.
<sgclark> yes it does
<sgclark> I am trying to become one of those. but I have still much to learn
<flocculant> *this* is just about 'no docs' though
<sgclark> I had no idea.
<sgclark> someday I will get there, they have many years experience above me lol
<infinity> flocculant: Yeah, the tracker is pretty much just documented in stgraber's head, and the random experience of people banging their own heads on it.
<flocculant> infinity: I have that headache ...
<flocculant> stgraber: ok - I have added your 32/64 bit builds copied from xenial - anymore - get people in to your release team and I'll talk to you and explain what you need to do at some point :)
<infinity> s/stgraber/sgclark/ :P
<flocculant> infinity: I *think* that Nick waited for me to whine then had a script :)
<flocculant> oh yea ... sgclark :)
<infinity> flocculant: Yeah, pretty sure when I whine to stgraber about things like this, he just mangles the SQL DB on the backend.
<flocculant> infinity: it seemed it was always me that did the whine :p
<flocculant> anyway - sending a mail to list(s)
<sgclark> ok "get people in youor release team" can you expand on that? me and yofel are release team, him being of higher power.
<infinity> I'll be seeing stgraber later tonight, I'll be sure to annoy him.
<flocculant> infinity: not touched 'upgrade'
<infinity> sgclark: Don't worry about what that means until we know what your "release team" is.
<sgclark> and thank yoou for your help, truly
<sgclark> ok
<infinity> sgclark: As in, the tracker thinks you have one, but I don't know what it is. :P
<sgclark> got it
<flocculant> sgclark: I will elaborarate
<infinity> flocculant: See above.
<sgclark> I will carry on learning and doing as I can
<sgclark> thanks for all the help, I do appreciate it
<stgraber> infinity: tracker permissions is a bit weird because Drupal. Basically you have roles, like "kubuntu release" which are assigned to products. Those "roles" are applied automatically through OpenID, you can get the mapping list from the Launchpad openid plugin configuration page (that would be role to LP team mapping)
<infinity> stgraber: Yeah, that last bit sounds like a thing I can't see. :)
<infinity> stgraber: Hence why I don't know what maps to "kubuntu release".
<flocculant> stgraber: you fiddling? can't get to admin pages ...
<stgraber> flocculant: nope
<flocculant> or is just a normal 'buntu thing :(
<stgraber> infinity: yeah, IIRC only folks in ~ubuntu-qa-website-devel have full admin access. I'm happy to add you to it if that's useful.
<flocculant> magic as soon as I moan ...
<flocculant> stgraber: I think it would be useful :D
<stgraber> flocculant: well, he may not want to have such access so he can instead keep having me do the changes :)
<knome> flocculant, i'm on the admin team too fwiw...
<infinity> stgraber: Yeah, I have zero urge to be special, I'd rather whine about buggy manual procedure until you make it not manual. :P
<infinity> stgraber: (ie: new series not having testcases, derp)
<stgraber> infinity: I thought we made it so testcases can be changed not to be tied to a series, only using the per-series bit for old LTS releases
<stgraber> anyway, boarding now, see you in a bit
<infinity> stgraber: I get there late (like, midnightish), but see you soon.
<flocculant> knome: ack that
<flocculant> stgraber: yea - but don't I don't know who in -release has those perms so ...
<flocculant> I know you do :)
<flocculant> I do as well - not something I would hand out like sweets for sure
<flocculant> but as far as I know - as long as foo is in their release team they can add products
<flocculant> sent mail to -release/qa re that
<flocculant> I can and did - deal with my stuff and some flavours - some others - Lubuntu/Kylin added their own it seems
<flocculant> bit *shrug* - really only care about Xubuntu - but seemed churlish to not mention it :D
<flocculant> infinity: I have mail in mod queue re tracker on -release if you could do something with that :)
<flocculant> oh meh - same on -quality
<flocculant> mailman loves images :p
<knome> flocculant, actually i handled lubuntu :P
<flocculant> jibel: could you approve the -quality modded message from me please :p
<flocculant> or hggdh if you are first ;)
<flocculant> knome: cheers :)
<flocculant> sgclark: so basically - kubuntu release team needs to be on LP - then you'll get access to the right things on the tracker(s)
<infinity> flocculant: I'm sure there's a mapping there, we'll figure out what it is.
<flocculant> infinity: :D
<flocculant> infinity: I just know I have 2, 1 from xubuntu release - which allows me to do whatever with the xubuntu bit, 2 - ubuntu-qa-website-devel which allows me to do stuff for anyone - hence dealing with gnome and kubuntu
<hggdh> flocculant: approved
<flocculant> knome has the same -website approval
 * infinity puts on pants and goes to catch some airplanes.
<flocculant> good call there infinity ...
<flocculant> or arrest
<flocculant> :p
<flocculant> hggdh: thanks :)
<hggdh> yw
<flocculant> stgraber: while I know this sounds a bit like 'well jfdi then' there's nothing that I know of written down about this - especially from a flavour pov
 * flocculant did mention it a few times to balloons :D
<flocculant> infinity: help ... I want to change the time that xubuntu images build - and I'm pretty sure that I need to do the mp in ubuntu-cdimage/etc/crontab
<flocculant> I've just seen so many different branches of it - I am completely confused where to pull and push from :(
 * flocculant does a sad 
<cjwatson> flocculant: lp:ubuntu-cdimage is the master branch
<flocculant> cjwatson: thanks :)
<flocculant> cjwatson: sorry here - so I rarely venture into Lp to push things - how do I push to there lp:~flocculant/ubuntu-cdimage/somename ?
<cjwatson> flocculant: https://help.launchpad.net/Code/UploadingABranch
<cjwatson> or you can just tell me what change you want, but you may want the practice
<cjwatson> (UploadingABranch> then https://help.launchpad.net/Code/Review)
<flocculant> cjwatson: well I manage ok with the manual test branch - not come across one that doesn't say bzr push foo - but basically I (xubuntu) are looking to get our builds building earlier
<cjwatson> "not come across one that doesn't say bzr push foo" - sorry I have no idea what you mean
<flocculant> looked at all the times in /etc/crontab there - hoping for 1am for the daily
<flocculant> cjwatson: like bzr push lp:~flocculant/ubuntu-manual-tests/ubuntu-manual-tests
<cjwatson> flocculant: the Launchpad page for a branch only shows that if you can push to the branch
<flocculant> aak okey doke
<cjwatson> https://git.launchpad.net/launchpad/tree/lib/lp/code/templates/branch-management.pt for gory details
<flocculant> cjwatson: happy to look  - but in the meantime would there be a reason for the xubuntu build to not be moved?
<cjwatson> no particular reason I know of
<flocculant> we're trying to sort out some way to let our testers know our build is at least working - manual testing is our best current option
<flocculant> cjwatson: ok thanks for your help - I'll get the mp there as soon as I can and then wait on you all :)
<flocculant> cjwatson: wasn't expecting you to be up tbh - getting on in the UK :)
<cjwatson> I put it at about that time in 2006 when Xubuntu was created, probably arbitrarily
<cjwatson> I'm going to bed soon enough
<flocculant> cjwatson: yup - pretty much the same - south coast UK
<flocculant> thanks for the help :)
<flocculant> for better or worst ... https://code.launchpad.net/~flocculant/ubuntu-cdimage/x-build-time/+merge/293489
#ubuntu-release 2017-04-24
<slangasek> infinity: ah, is that why c-m screamed at me? :)
<krytarik> infinity: Hi. Could you please accompany  http://bazaar.launchpad.net/~ubuntustudio-dev/ubuntu-seeds/ubuntustudio.artful/revision/1508  by adding the "ship-live" seed to Studio here similar to the Edubuntu one?: http://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/view/head:/lib/cdimage/germinate.py#L371  Thanks!
<estan> i know it's a desktop package, so probably takes some extra checking, but qtbase-opensource-src 5.5.1+dfsg-16ubuntu7.4 has been in the upload queue for almost a month now, does it usually take this long for someone to have a look at it?
<estan> (it fixes this bug i reported: https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1598173 )
<ubot5> Ubuntu bug 1598173 in qtbase-opensource-src (Ubuntu Xenial) "Please consider SRU of "xcb: Compress mouse motion and touch update events"" [Undecided,New]
<estan> (note that there's already a 5.5.1+dfsg-16ubuntu7.3 upload there as well, but 5.5.1+dfsg-16ubuntu7.4 includes both those fixes, see dmitri's comment on the bug)
<apw> estan, in large part it is because it is a sync and syncs are a pig to review
-queuebot:#ubuntu-release- Unapproved: rejected qtbase-opensource-src [sync] (xenial-proposed) [5.5.1+dfsg-16ubuntu7.3]
-queuebot:#ubuntu-release- Unapproved: qtbase-opensource-src (xenial-proposed/main) [5.5.1+dfsg-16ubuntu7.2 => 5.5.1+dfsg-16ubuntu7.4] (kubuntu, qt5, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rejected qtbase-opensource-src [sync] (xenial-proposed) [5.5.1+dfsg-16ubuntu7.4]
-queuebot:#ubuntu-release- Unapproved: accepted qtbase-opensource-src [source] (xenial-proposed) [5.5.1+dfsg-16ubuntu7.4]
<estan> apw: aha, i see. thanks a lot for taking care of it!
<LocutusOfBorg> hello, any AA around for a question=
<flocculant> that's going to be fun for 6 months ... any AA around to talk about AA :p
<LocutusOfBorg> I restricted the architectures where llvm 3.7 is built (because just needed for ghc on arm*, so not really needed to build on other architectures)
<LocutusOfBorg> unfortunately I'm not sure I gave the commands correctly, it seems "decruftable" but I need double checking before asking or filing a removal bug
<infinity> Looks removable to me.
<LocutusOfBorg> thanks!
<infinity> LocutusOfBorg: And removed.
<LocutusOfBorg> my biggest concern was on the -all packages, because debian has them built, while ubuntu has not
<LocutusOfBorg> oh... thanks <3 I was filing a bug lol :)
<LocutusOfBorg> now, I have to understand why llvm 4.0 is not migrating
<LocutusOfBorg> and fix a build failure on 3.8 :)
<infinity> * amd64: libllvm-ocaml-dev
<LocutusOfBorg> yep I saw that
<LocutusOfBorg> but I have to rmadison a little bit
<LocutusOfBorg> indeed
<LocutusOfBorg> so the decruft happening in Debian has to happen here too, let me see
<infinity> LocutusOfBorg: Looks like llvm-4.0 stopped producing libllvm-4.0-ocaml-dev
<LocutusOfBorg> libllvm-4.0-ocaml-dev it probably needs to be removed too?
<LocutusOfBorg> exactly
<infinity> LocutusOfBorg: Which libllvm-ocaml-dev depends on.
<infinity> LocutusOfBorg: Nothing about things needing to be removed.
<infinity> LocutusOfBorg: But rather llvm-defaults needing fixing.
<LocutusOfBorg> interesting, I got the same conclusion, but meh, not sure why this is happening :)
<LocutusOfBorg> let me double check
<infinity> LocutusOfBorg: Not sure why it's happening?  libllvm-ocaml-dev depends on libllvm-4.0-ocaml-dev, and llvm-toolchain-4.0 doesn't produce libllvm-4.0-ocaml-dev anymore, thus libllvm-ocaml-dev is broken. :P
<LocutusOfBorg> the question is "why is not happening in Debian" :)
<infinity> LocutusOfBorg: Either llvm-toolchain-4.0 needs to start producing that binary again, or llvm-defaults need to stop producing the unversioned one.
<LocutusOfBorg> https://packages.debian.org/unstable/libllvm-ocaml-dev
<infinity> LocutusOfBorg: It's not happening in Debian because their llvm-defaults isn't 4.0?
<LocutusOfBorg> 3.8 satisfies it
<infinity> ...
<infinity> Our llvm-defaults points to 4.0.
<LocutusOfBorg> indeed, on that page there was a "not alpha, hurd-*" I missed the "not"
<infinity> Debian's does not.
<LocutusOfBorg> yep, but I didn't parse correctly that page lol
<LocutusOfBorg> ENOCOFFEE
<LocutusOfBorg> thanks!
<infinity> LocutusOfBorg: As for the 3.8/arm64 thing, I have a hunch that related to a gcc regression.  At least, it's moderately suspicious that the current gcc's testsuite has a ton of timeouts in asan tests, and llvm-3.8 also times out in sanitizer tests.
<infinity> Oh, but that built before gcc-6 did.
<infinity> So, weird coincidence, but perhaps unrelated.
<infinity> Or the same patches landed in both toolchains. :P
<LocutusOfBorg> well, it fails on Debian experimental but not Debian unstable
<LocutusOfBorg> so, somewhere we picked up that stuff from experimental I wild guess
<infinity> That's not really how I read the Debian build history.
<infinity> I read it as "this timeout is just borderline, and sometimes it succeeds, and sometimes it doesn't".
<infinity> It's just sbuild killing it for N minutes without stdout, afterall, it's not the package itself throwing a failure.
<LocutusOfBorg> well, it failed 3/4 experimental builds, and 0/2 unstable builds
<LocutusOfBorg> (there are three kinds of lies, lies, damn lies, and statistics)
<infinity> Right, 3/4.  Not 4/4.  Hence your assertion that "experimental breaks it" is clearly false.
<infinity> And 2/2 is hardly a large enough sample size to assert that "unstable fixes" it.
<infinity> So I suspect it's just right on the edge of the timeout window.  Sometimes a few minutes over, sometimes a few minutes under.
<LocutusOfBorg> yep, I fully agree, I was just trying to see if something in the toolchain was different
<LocutusOfBorg> and 3/4, VS 0/2 at least is worth a look :)
<LocutusOfBorg> anyway, lets see if now it builds
-queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (zesty-proposed) [2.2.9-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (xenial-proposed) [2.2.9-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (yakkety-proposed) [2.2.9-0ubuntu1~16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (trusty-proposed) [2.2.9-0ubuntu1~14.04.1]
-queuebot:#ubuntu-release- New sync: vine (artful-proposed/primary) [1.1.3+dfsg-2]
-queuebot:#ubuntu-release- New binary: healpix-cxx [s390x] (artful-proposed/universe) [3.30.0-6ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: healpix-cxx [amd64] (artful-proposed/universe) [3.30.0-6ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: case [amd64] (artful-proposed/universe) [1.5.3+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: healpix-cxx [ppc64el] (artful-proposed/universe) [3.30.0-6ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: healpix-cxx [i386] (artful-proposed/universe) [3.30.0-6ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: healpix-cxx [arm64] (artful-proposed/universe) [3.30.0-6ubuntu1] (no packageset)
<xnox> Laney, infinity - have archive reports been adjusted for artful? because i get emails from pitti, that are not visible in http://people.canonical.com/~ubuntu-archive/component-mismatches.txt unless something has moved as well now.
<Laney> They should have been
<xnox> Laney, ok, in that case i'm emiling ubuntu-release with a question =)
<Laney> Someone demoted the unity8 stuff?
<Laney> Is that what you're asking about?
-queuebot:#ubuntu-release- New binary: healpix-cxx [armhf] (artful-proposed/universe) [3.30.0-6ubuntu1] (no packageset)
<xnox> Laney, yes | no | maybe. https://launchpad.net/ubuntu/+source/ubuntu-meta/1.380
<Laney> I saw that
<xnox> then there was pitti's email stating that everything is a mess now
<Laney> I don't see that one
<xnox> then i couldn't find the mess
<Laney> It looks like someone put it all in universe
<xnox> ah, let's check publishing record.
<Laney> https://launchpad.net/ubuntu/+source/unity8/+publishinghistory
<xnox> but that was bileto landing
<xnox> has bileto gone crazy?!
<Laney> what was?
<xnox> unity8 publishing
<Laney> I don't see what that has to do with it
<xnox> it does have AA rights, .... or do we not get a publishing entry when things move between components?
<Laney> There is an entry there
<jamespage> just checking that the archive is open for artful uploads before I bombard it with half a hundred uploads?
<LocutusOfBorg> jamespage, open :)
<jamespage> \o/
<xnox> jamespage, enjoy!
<Laney> jamespage: you can see the status on https://launchpad.net/ubuntu/artful BTW
<Laney> It'll say "Frozen" or something if it's frozen
<jamespage> Laney: yeah - just making sure
<Laney> but Active Development -> go wild
<jamespage> Laney: it does say something like pre-release freeze until its open (looked last week)
<Laney> yep
<jamespage> I love the fact that I can wildcard with dput :-)
 * jamespage launches a salvo of uploads
<jamespage> if there is an AA around - most of that's going to depwait until the new sync of vine from Debian gets acked - pretty please :-)
<apw> xnox, i think infinity had "sorted" component missmatches to 0 and is intending to keep it so
<xnox> right. now i'm thinking the emails i got was because there was delay between branch updates; and my meta upload. such that once meta cleared things were fine. but someone still demoted things.
<Laney> I would assume that someone used the output of component-mismatches to know what to demote
<apw> i am sure that is true
<apw> but presumably if meta now needed things they would be in there as new component-missmatches with MIRs already acked
<apw> c-m-proposed looks believeably and non-empty
<LocutusOfBorg> infinity, do you think I have to reupload llvm-3.7 without the examples package? I still see some sadness there, even after your hammer
-queuebot:#ubuntu-release- Unapproved: linux-firmware (zesty-proposed/main) [1.164 => 1.164.1] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: rejected linux-firmware [source] (zesty-proposed) [1.164.1]
-queuebot:#ubuntu-release- Unapproved: ceph (xenial-proposed/main) [10.2.6-0ubuntu0.16.04.1 => 10.2.7-0ubuntu0.16.04.1] (kubuntu, ubuntu-desktop, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: ceph (zesty-proposed/main) [10.2.6-0ubuntu1 => 10.2.7-0ubuntu0.17.04.1] (kubuntu, ubuntu-desktop, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: ceph (yakkety-proposed/main) [10.2.6-0ubuntu0.16.10.1 => 10.2.7-0ubuntu0.16.10.1] (kubuntu, ubuntu-desktop, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mtx [source] (yakkety-proposed) [1.3.12-9ubuntu0.16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted mtx [source] (xenial-proposed) [1.3.12-9ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: linux-firmware (zesty-proposed/main) [1.164 => 1.164.1] (core, kernel)
<xnox> hehe autopkgtests will take forever to run
<xnox> apw, could you please demote these to universe? http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<LocutusOfBorg> remove upstart instead of demote? :)
<xnox> LocutusOfBorg, not ready to be removed, demotion is a good start.
<xnox> because then we know it's dropping out of tasks.
<xnox> and if any remain.
<LocutusOfBorg> it was an half joke btw :)
<LocutusOfBorg> unity demoted it is also nice
<LocutusOfBorg> The requested URL /~ubuntu-archive/proposed-migration was not found on this server.
<LocutusOfBorg> is it just me or...
<mapreri> not just you
<mapreri> some minutes ago it was giving 403 errors, so I guess sysadm are doing something
 * LocutusOfBorg fights daily against proxies and bad connections
<mapreri> ... and you work on an IT company!
<LocutusOfBorg> this is why I have to fight against it folks blocking everything
<LocutusOfBorg> security for some customers means block even irc/ssh/git protocols
<acheronUK> aha. at least it's not just me
<LocutusOfBorg> I have to fetch git repos over https and proxy
<Laney> it would be quite something if a 404 error were just experienced by one person :)
<LocutusOfBorg> and canonical in the last months is disabling https fetch for git repos
<LocutusOfBorg> Laney, when your proxy changes what you see... this happens
-queuebot:#ubuntu-release- Unapproved: sssd (xenial-proposed/main) [1.13.4-1ubuntu1.4 => 1.13.4-1ubuntu1.5] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: sssd (yakkety-proposed/main) [1.13.4-3ubuntu0.3 => 1.13.4-3ubuntu0.4] (kubuntu, ubuntu-desktop, ubuntu-server)
<LocutusOfBorg> not probably at this level, but before downloading it downloads the file for you, and redirect you to a download link if the antivirus is happy
<Laney> Anyway
<Laney> I believe the machine is down atm due to being upgraded to xenial
<LocutusOfBorg> nice :)
<sergiusens> ah, that might explain my 503s
<LocutusOfBorg> was it on trusty?
<Laney> dapper
-queuebot:#ubuntu-release- Unapproved: rejected vlc [source] (yakkety-proposed) [2.2.4-4ubuntu0.16.10.2]
<Laney> (that was a joke)
<Laney> (a hilarious one)
<LocutusOfBorg> I got it :)
<Laney> (please laugh)
<LocutusOfBorg> seriously, it was on breezy I gues
<LocutusOfBorg> *guess
 * acheronUK wondered at the symbolism of people.ubuntu.com vanishing
<LocutusOfBorg> we had dapper machines on buildd for quite some time IIRC, so it might even not be a joke :)
<acheronUK> *canonical
<cjwatson> disabling https fetch for git repos> what do you mean?  https fetch from git.launchpad.net works fine ...
<LocutusOfBorg> ehm, some repositories I don't remember where
<LocutusOfBorg> not git.l.net
<LocutusOfBorg> will try to remember
<cjwatson> I think it's more likely that something would be broken that that Canonical would be intentionally disabling it, though perhaps there's some weirdness I'm unaware of
<LocutusOfBorg> ok, so I will maybe write here in case I find that link
<xnox> LocutusOfBorg, bzr http, git https
<mapreri> that reminds me that ubuntu-it still has his machine on precise... we should probably complete the preparations for the upgrade...
<xnox> mapreri, it can wait, another 4 days
<LocutusOfBorg> plenty of time!!!
<mapreri> ahem :|
<mapreri> if only software would port itself over new libs :(
<jamespage> please could an AA accept the sync I did of vine into artful earlier today - that will unblock a number of dep-waits I have in the openstack dependencies for pike-1
-queuebot:#ubuntu-release- New binary: libepoxy [ppc64el] (artful-proposed/main) [1.3.1-2ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- New binary: libepoxy [amd64] (artful-proposed/main) [1.3.1-2ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- New binary: libepoxy [s390x] (artful-proposed/main) [1.3.1-2ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- New binary: libepoxy [i386] (artful-proposed/main) [1.3.1-2ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- New binary: libepoxy [armhf] (artful-proposed/main) [1.3.1-2ubuntu1] (desktop-core)
<zx2c4> infinity: what's the next step with https://bugs.launchpad.net/ubuntu/+source/wireguard/+bug/1685522 ?
<ubot5> Ubuntu bug 1685522 in wireguard (Ubuntu) "out of date snapshot" [Undecided,Confirmed]
-queuebot:#ubuntu-release- New binary: libepoxy [arm64] (artful-proposed/main) [1.3.1-2ubuntu1] (desktop-core)
<jbicha> zx2c4: according to https://wiki.ubuntu.com/SponsorshipProcess you should subscribe ~ubuntu-sponsors to the bug
<zx2c4> jbicha: thanks just did that
<zx2c4> jbicha: so now what?
<zx2c4> somebody just needs to "sponsor" me?
<zx2c4> seems like most folks are too busy
<LocutusOfBorg> let me see
<zx2c4> LocutusOfBorg: thanks!
<zx2c4> LocutusOfBorg: infinity, cjwatson, and i discussed this strategy of using an empty package pretty extensively last night in this channel
<LocutusOfBorg> README.Debian file was nice too
<zx2c4> LocutusOfBorg: you want me to add a README.Debian file to it?
-queuebot:#ubuntu-release- Unapproved: wireguard (zesty-proposed/universe) [0.0.20170214-1 => 0.0.20170214-1ubuntu0.17.04] (no packageset)
<LocutusOfBorg> zx2c4, ^^ I had to tweak it a little bit
<zx2c4> LocutusOfBorg: im writing a README.debian and then im going to reupload to the bug, doe sthat sound good?
<LocutusOfBorg> nah
<LocutusOfBorg> it is fine
<zx2c4> oh, cool, okay
<zx2c4> so when this says "Unapproved: wireguard ..." what does that mean?
<zx2c4> (where can i see your tweaks?)
<LocutusOfBorg> https://launchpad.net/ubuntu/zesty/+queue?queue_state=1&queue_text=
<LocutusOfBorg> http://launchpadlibrarian.net/316831052/wireguard_0.0.20170214-1_0.0.20170214-1ubuntu0.17.04.diff.gz
<LocutusOfBorg> here, just look at my debdiff and compare it to your
<LocutusOfBorg> (hint: I removed the .pc directory, changed back to quilt)
<zx2c4> LocutusOfBorg: you added back in all those random other files?
<zx2c4> i guess thats fine
<zx2c4> interesting in any case
<zx2c4> debian/ubuntu processes remain mysterious to me
<LocutusOfBorg> zx2c4, you changed from quilt to native, so it means the orig tarball is not preserved
<LocutusOfBorg> so, patches are not unapplied and a lot of other stuff
<zx2c4> i didnt realize we wanted to keep the original tarball?
<LocutusOfBorg> and that .pc was a result for that
<LocutusOfBorg> yes zx2c4
<zx2c4> ahh
<LocutusOfBorg> why not?
<LocutusOfBorg> security, avoid new tarballs just for fun
<LocutusOfBorg> native package is not easy to follow, upstream one is
<zx2c4> because it's code that should _not_ persist
<zx2c4> but in anycaes, its not a big deal
<zx2c4> im just happy that this is in the queue
<LocutusOfBorg> we are talking about the upstream package, not the debian changes that prevents it from working
<LocutusOfBorg> that version needs to be complete and coherent with what upstream released on that snapshot
<zx2c4> even the upstream package. its not a package. or a release. its just some random code dump from one particular day. which is why it shouldnt have been in ubuntu
<zx2c4> okay i understand
<zx2c4> so what happens next with this queue?
<LocutusOfBorg> and your debian/* foo should explain/change that, with patches approach
<zx2c4> somebody else presses the "approve" button, and then we're all set?
<LocutusOfBorg> zx2c4, now, somebody on release team should approve yes
<zx2c4> oh cool, so that's where infinity comes in
<LocutusOfBorg> somebody will add verification-needed and you will test/change back to verification-done, explaining the testing you did
<LocutusOfBorg> https://wiki.ubuntu.com/StableReleaseUpdates
<zx2c4> cool okay
<zx2c4> and all that explanation will happen on the original bug report?
<LocutusOfBorg> I hope so :)
<xnox> Laney, britney runs off snakefruit right? thus i should not expect anything to migrate, until snakefruit is back up?
<xnox> and infinity / slangasek fix it up?
<cjwatson> xnox: correct
<apw> correct
<xnox> tah
-queuebot:#ubuntu-release- New binary: systemd [s390x] (artful-proposed/main) [233-5ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: systemd [ppc64el] (artful-proposed/main) [233-5ubuntu1] (core)
-queuebot:#ubuntu-release- New: accepted systemd [s390x] (artful-proposed) [233-5ubuntu1]
-queuebot:#ubuntu-release- New binary: systemd [i386] (artful-proposed/main) [233-5ubuntu1] (core)
<santa_> dear release wizards,
<santa_> I have a question regarding SRU's to zesty
<nacc> santa_: what is the question?
<santa_> we are considering in kubuntu an SRU for plasma (we have 5.9.4 in zesty and we would like to provide 5.9.5 via an SRU)
<santa_> we maintainain in kubuntu ~300 packages, so we have some automation tools
<santa_> the easier thing for us would be preparing a _complete_ plasma update
<santa_> that means we might have some packages providing a 0-diff update
<santa_> would be allowed to do that?
<infinity> krytarik: You completely broke the ubuntustudio seeds.
<xnox> santa_, as long as it will be tolerable to reject all the 0-diff updates?! e.g. things do not depend on the updated version numbers.
<xnox> i think SRU team may be ok with rejecting a bunch of things.
<infinity> xnox: You might want to not speak for the SRU team. ;)
 * xnox is not ~ubuntu-sru team member
<santa_> xnox: we can make it tolerable, yes
<infinity> santa_: I have no issues with it conceptually.  It certainly has precedent.
<santa_> we just need to not bump the buld depends, that's easy to do, we just disable that in the tooling and that's it
<infinity> santa_: The bigger issue is findind someone with the time to process it all, since that used to be ScottK.
<santa_> plasma are 42 source packages in case you are wondering
<apw> how many of these packages would ... 42 ok
<infinity> 42 is a much less scary number than 300.
<infinity> santa_: So, yeah.  From our POV, even the 0-change uploads are not a huge burden on *us*.  But you need to think hard about yourself as well, as you do need to verify all those binary builds.
<infinity> santa_: Cause part of the SRU process is not trusting something is okay just because it rebuilt with "no changes".  It needs to be installed, run, tested.
<infinity> santa_: So, for the 0-change ones, it's probably in your best interest to skip them.
<infinity> (For me, I don't much care, it's easy to review sometihng without a change :P)
<santa_> infinity: yeah, I get what you mean. a 0-diff is after all a rebuild, so that 'invalidates' somehow the testing we do. I guess we could improve a bit the tooling and the workflow to deal with these kind of things
<infinity> santa_: But if you're willing to verify them all and you want the versions to be pretty and match, I'm not going to tell you not to do it.
<santa_> regarding the status of artful. I guess we are free to upload now? we already have several things to update
<nacc> santa_: archive is open
<santa_> plasma 5.9.5 in the first place
<santa_> frameworks
<santa_> and we also have the kdepim which we couldn't include in zesty, that needs several NEW reviews
<santa_> regarding the kdepim this is what we had in zesty: http://gpul.grupos.udc.es/ka-iron-hand_reports/applications_archive/16.12.3_zesty_proposed_migration.pdf
<santa_> the kdepim is the bunch of the top, those in dark red are already in the archive, those in grey are not
<santa_> so what do you suggest us to do? upload those who are not in the archive first, and then the rest, or just upload them all? we could do any of both with our automation tooling
<mapreri> oh, people.c.c is back.
<mapreri> was britney also stopped, by any chance?
<bdmurray> infinity: Is the Artful release schedule good?
<apw> mapreri, yes same machine
<infinity> bdmurray: I like it well enough.
<infinity> mapreri: people was never gone, but people/~ubuntu-archive is actually a proxy through to another machine (the one that runs britney)
<mapreri> ic
<bdmurray> infinity: Okay, I was thinking about doing the meta-release file
<infinity> bdmurray: Might want to upload u-r-u to artful before you do.
<bdmurray> infinity: well, alright
<krytarik> infinity: Hurr durr, I was hoping I wouldn't have to duplicate the general 'live' seed file to 'dvd-live' - will do so then.. :/
<infinity> krytarik: Well, I'm not entirely sure what your intent is here.
<infinity> krytarik: There's nothing wrong with having a dvd-live, but you deleted it.
<infinity> krytarik: Deleting it and still having it listed in STRUCTURE makes germinate very unhappy.
<infinity> krytarik: Your STRUCTURE references a lot of seeds that don't exist. :P
<slangasek> xnox: upstart, cgmanager demoted
<infinity> krytarik: live-common and ship-live also aren't a thing in your seeds.
<krytarik> infinity: Trust me! :P
<infinity> krytarik: No? :)
<infinity> krytarik: Oh, scratch the live-common bit, that's in platform, so everyone shares it.
<infinity> krytarik: So, that's correct.  But deleting dvd-live was less correct. :P
<krytarik> Yes, I see that now. :P
<infinity> krytarik: And the bug you were trying to fix, I think, was the lack of ship-live.
<infinity> If you even need one.
<krytarik> Well, that plus referencing a 'dvd' seed that doesn't exist.
<infinity> krytarik: Anyhow, I think reverting that entire last commit and then deleting "live" (moving anything from there that you need into dvd-live), and then sorting out a ship-live seed to fix your other bug would get the job(s) done.
<infinity> Although... You don't have a LIVE_TASK in livecd-rootfs.  How does ANY of this work for you?
<infinity> bdmurray: Wow, phased-updater takes an amazingly long time to run.
<infinity> bdmurray: Are you doing something very slow there like iterating through all SRUs via LP?
<krytarik> infinity: Oh meh, I just see Edubuntu, which I've been following for this, has 'include ubuntu.*' rather than just 'platform.*' as we do, so that's why they get away with not having a 'ship-live' seed themselves.  So I guess I'll either copy the Ubuntu or the Xubuntu one, which our seed is otherwise based on.  Also, I was thinking earlier regarding the 'dvd-live' seed, could I just have it ...
<krytarik> ... an empty file except the header, and otherwise pull in 'live' as it does now?
<infinity> krytarik: An empty file pulling in live would work fine, but we really don't need both "ubuntustudio-live" *and* "ubuntustudio-dvd-live" tasks in the archive.
<infinity> krytarik: Just settling on dvd-live and making it behave like edubuntu makes more sense to me.
<infinity> krytarik: The only reason to have a split would be if you were producing both size/type images, which you're not.
<infinity> I'll note that edubuntu has that same bug. :P
<infinity> Not that it's producing images anymore at all.
<krytarik> And yes, adding a LIVE_TASK for it would be nice then indeed, I see. :P
<infinity> I'm not actually sure where dvd-live comes into play for edubuntu, now that I look...
<infinity> krytarik: Anyhow, unwinding all of that and sorting out what you actually need/want to do could be some back and forth.
<infinity> krytarik: Could you please just revert your last commit (or I will), so it stops breaking infrastructure? :P
<krytarik> infinity: Sure, asap.  Would you be fine with an --overwrite there? :P
<infinity> No.
<infinity> That'll break anyone who updates with a pull.
<infinity> Which icludes the aforementioned infrastructure.
<infinity> Never ever go back in time in a shared repository unless you control all the checkouts.
<krytarik> Alright, if there are copies of it someplace indeed..  And well, it should be easy enough to fix properly now that I know more about it.
-queuebot:#ubuntu-release- Unapproved: distro-info-data (precise-proposed/main) [0.8ubuntu0.11 => 0.8ubuntu0.12] (ubuntu-server)
<cjwatson> Copying Edubuntu is probably a bad idea.
<cjwatson> It was complicated and weird to set up that way.
<cjwatson> There was some special reason for it that I now forget.
<krytarik> infinity: Look good to you?: http://paste.openstack.org/show/MpSB7IDbQ03QyYeOgvPD/
-queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (precise-proposed) [0.8ubuntu0.12]
<infinity> krytarik: I dunno.  The surefire way to not mess up a revert is to do a revert. :P
<infinity> krytarik: ie: bzr revert -r1507
<krytarik> Well, I don't want to go back to where it doesn't have any 'pool/'.. :P
<infinity> krytarik: Fair enough, though the actual bug that was meant to be fixed by giving you a pool won't be fixed.
<infinity> In that you don't ship grub-efi-whatever anywhere.
<krytarik> Pretty sure it will..?
<infinity> krytarik: How?  Your seeds don't reference grub-efi-amd64-signed anywhere.
<krytarik> Err, look again at the paste?
<infinity> krytarik: Oh, in the uncommitted revision, sure.
<infinity> krytarik: I was looking at the current and saying that reverting from current to current-1 wouldn't regress anything.
<infinity> krytarik: Yes, there's a fair chance that paste will fix things.
<krytarik> infinity: Done.
<bdmurray> slangasek: https://code.launchpad.net/~brian-murray/apport/lp-retracer-config-artful/+merge/323074
<slangasek> bdmurray: is this on the release-opening checklist, or if not could you add it?
<slangasek> (merged)
<bdmurray> slangasek: it is just slightly wrong
<slangasek> bdmurray: and I've dropped powerpc for 17.*
<bdmurray> slangasek: noted
-queuebot:#ubuntu-release- Unapproved: accepted network-manager [source] (yakkety-proposed) [1.2.6-0ubuntu1.1]
<krytarik> infinity: Oh no, now it's moaning at a missing 'dvd' seed file still - not sure what should be in there though..
<infinity> krytarik: The edubuntu dvd file looks useful, minute the ltsp bit.
<infinity> krytarik: (ie: all the langpacks)
<infinity> krytarik: The edubuntu dvd-langsupport also looks handy.
<infinity> I mean, if you care about translations.
<krytarik> I think the image is bloated enough already as it is.. :P
<infinity> krytarik: An empty (well, comment-only) dvd file might do the trick too.  Along with the cdimage change you proposed.
<krytarik> Yeah, just thought the same.
<krytarik> infinity: ..I'm stuck at the comment part now. :P
<infinity> "This seed exists only to gather together all the other dvd seeds."
<infinity> See platform/support-common for prior art. :P
<krytarik> Yes! \o/
<infinity> krytarik: Bonus points for comitting and pushing the fix?
<krytarik> Sure, am on it.
<krytarik> infinity: Done.
<rcj> slangasek: can we bump distro-info-data out of precise-proposed?
<slangasek> rcj: do you mean release it or supersede it?
<rcj> slangasek: release it, sorry for being imprecise
<rcj> That's being super aggressive on the timing but it's blocking image builds and the nature of the change is low-risk.
<slangasek> rcj: at the moment I'm wondering why it's not showing up on http://people.canonical.com/~ubuntu-archive/pending-sru.html; <-- infinity, snakefruit fallout?
<rcj> possibly, last update ~90m ago?
<rcj> Also hasn't automatically approved the nominated track in bug #1685055
<ubot5> bug 1685055 in distro-info-data (Ubuntu Precise) "Update to add Artful" [Undecided,Fix committed] https://launchpad.net/bugs/1685055
<slangasek> rcj: it ignores the nomination and creates the bug task outright, so the nomination is still there
<rcj> oh, there is a precise series entry.  It's just also showing my nomination message.
<slangasek> rcj: released
<rcj> slangasek: Thank you
<slangasek> infinity: so what is taking update-germinate so long?
<infinity> slangasek: I suspect it might always take this long, I just normally never have something I want to do. :P
<infinity> slangasek: But I have a manual archive-reports running too now, since halting the world on update-germinate was apparently not a solid plan.
<slangasek> infinity: really? why shouldn't this be a no-op for stable releases?
<slangasek> infinity: you do? does that mean you killed mine, or did it die on its own?
<infinity> You had one running?
<slangasek> infinity: from a minute after I asked you about update-germinate ;)
<infinity> slangasek: Mine's been running longer.  So, the more interesting question is if you killed mine, or if yours is spinning on a lock, or if you didn't notice it exited. :P
<infinity> slangasek: Oh, or mine exited already.
<slangasek> infinity: ps really thinks mine was the only one running when I checked :)
<infinity> Possibly due to the chdist bug I fixed.
<slangasek> but mine exited non-zero
<infinity> slangasek: Yours is running currently?
<slangasek> no
<slangasek> wait
<slangasek> yes
<infinity> 30020 pts/5    S      0:00 /bin/sh /home/ubuntu-archive/bin/archive-reports
<infinity> 30022 pts/5    S      0:00  \_ /bin/sh /home/ubuntu-archive/bin/run-proposed-migration
<infinity> pts/5 is you, so...
<infinity> UNIX is hard.
<slangasek> but it detached from the tty...
<slangasek> wat
<infinity> The background_and_wait stuff probably behaves weirdly with a controlling terminal.
<slangasek> and $HOME/.archive-reports.lock is absent
<infinity> Oh, yay, not whining about SSL certs anymore.
-queuebot:#ubuntu-release- New: accepted systemd [i386] (artful-proposed) [233-5ubuntu1]
-queuebot:#ubuntu-release- New: accepted systemd [ppc64el] (artful-proposed) [233-5ubuntu1]
<infinity> slangasek: So, have you found anything broken yet?  I've only had to fix chdist so far, it seems.
<infinity> Hrm, archive-reports is clearly exiting early, cause no component-mismatches.
<slangasek> infinity: haven't pinpointed the breakage, but yeah, pending-sru is not updated either
<infinity> Right, time to -x it.
<infinity> And see where it bombs.
<infinity> Ideally only one of us. :P
<slangasek> infinity: go ahead :)
<infinity> Watch it succeed this time, since I think I fixed chdist after you started your last run.
<infinity> Anyhow, running with much spew.
<infinity> slangasek: We have component-mismatches this go around. \o/
<infinity> slangasek: Note that pending_sru doesn't come from archive-reports, it's out of band (and not running because I disabled the whole crontab)
<infinity> But it did have one successful run since reboot, I think.
<slangasek> ok
<infinity> slangasek: Oh.  When you ran archive-reports, did you run it straight, or with the PYTHONPATH bits from crontab?
<infinity> (I ran mine straight and it succeeded)
 * infinity is running every other bit of contrab by hand to see how they fare.
<infinity> contrab!
-queuebot:#ubuntu-release- Unapproved: gnome-calendar (zesty-proposed/main) [3.24.0-0ubuntu1 => 3.24.1-0ubuntu0.1] (desktop-extra, ubuntu-desktop)
<slangasek> infinity: ah I had grabbed PATH but missed PYTHONPATH
<infinity> slangasek: Okay, so we both ran it without the altered PYTHONPATH.  Curious.
<infinity> (I suspect that's obsoleted by xenial having new enough whatever)
<slangasek> infinity: there's not much /in/ pythonpath; it's probably lazr that's been updated
<infinity> And germinate from git, which we want to keep doing, IIRC.
<slangasek> yeah
<infinity> As Colin's given up on SRUing it.
<slangasek> lazr in xenial is now newer than the one we have in ~/python
<slangasek> six should probably go
<slangasek> the other bits probably still belong
<slangasek> six is 1.8.0 (~/python) vs. 1.10.0 (xenial)
<infinity> Kay, go ahead and whack that, IMO.
<infinity> archive-reports clearly ran fine without the downgrade.
<slangasek> removed the links; keeping the trees until we're sure everything that uses PYTHONPATH is happy
<infinity> Almost through crontab.
<infinity> Won't restore it until after one more reboot to make systemd stop whining.
<infinity> krytarik: I fixed your fix, FWIW.  germinate doesn't hate your seed anymore.
<infinity> krytarik: (No guarantees it'll do the things you want it to do, but at least it's not exploding)
<infinity> slangasek: And have a fresh pending_sru.
<slangasek> tada
<infinity> Two of stgraber's reports running, and if those complete, I'm calling snakefruit done, ish.
<infinity> Which turned out to be a lot less painful than I'd thought.
<infinity> Oh, hrm.  No.  old britney (used for /testing/ and /testing-ports/) might be broken.  But I can sort that out without holding up everything else.
<infinity> slangasek: Ahh, slight stay of execution on some bits that cheat and schroot into the trusty-transitions chroot.  Likely because precise was too old. :P
<infinity> slangasek: So, we'll probably want to upgrade that schroot $later, do some testing, and then decide if we even need it anymore.
<infinity> Well, upgrade, or create a parallel one to test in.
<krytarik> infinity: Given there was a seemingly successful run of Germinate before that addition, it wasn't entirely necessary though, right?
<infinity> krytarik: It was necessary.  I hacked it in production to test before committing. :P
<krytarik> Ah. :P
<cjwatson> slangasek: update-germinate routinely takes forever because it's emitting the full rdepends tree.
<slangasek> cjwatson: and it's intentional that this isn't short-circuited for e.g. trusty?
<cjwatson> slangasek: it certainly was intentional at one point, because I wanted to keep seeing updates
<slangasek> ok
<cjwatson> (I think it looks at -updates; haven't checked recently)
<cjwatson> feel free to override this if you don't think it's useful enough to merit it of ocurse
<cjwatson> *course
<infinity> Yeah, the taking forever thing isn't really an issue when it's not blocking me rebooting. ;)
<cjwatson> if so you should just do it by removing things from the update-germinate script
<infinity> It could also be mitigated by parallelizing it, but I think running single-threaded is better to keep it out of the way.
<infinity> I just whacked a bunch of vivid for flavours that clearly won't care (ie: almost everyone), which will help some.  And precise will go away in 4 days.
<cjwatson> It could also be mitigated by doing some of what I did to speed things up in Launchpad.
<cjwatson> Or rather on the publisher machine.
<cjwatson> We can't share the processing that depends on the seed data, but we can share the processing that depends on the input Packages files.
<cjwatson> See lp:ubuntu-archive-publishing lib/scripts/generate_extra_overrides.py
<infinity> cjwatson: Yeah, but wasn't the major win there parallelisation?
<infinity> Which I think we don't want on snakefruit, as we'll get massive spikes instead of the smooth munching of one core.
<cjwatson> That helped, but sharing the output of duplicated processing steps helped too.
<infinity> Ahh.
<infinity> So we could maybe reuse that bit.
<cjwatson> Emitting rdepends is still going to be terrible though, and that's one of the most useful bits of that output.
<cjwatson> I think the correct fix there is to output a DB of some kind and have a little webapp to render bits of it as needed.
<cjwatson> Rather than the gigantic tree of a zillion little files.
<infinity> On the other hand, the nice lasy at A&W thought I looked grumpy and gave me a root beer lollipop.
<infinity> Which, it turns out, is awesome.
<infinity> s/lasy/lady/
<cjwatson> Score one for looking grumpy.
<cjwatson> Oh.  I thought that was a Canadian spelling of lassie.
<infinity> I knew it would pay off eventually.
<infinity> Just didn't think I'd wait 39 years.
<infinity> I don't really want to know what science goes into making a hard candy taste like a carbonated beverage, do I?
#ubuntu-release 2017-04-25
-queuebot:#ubuntu-release- New: accepted libva-utils [sync] (artful-proposed) [1.8.1+ds1-1]
-queuebot:#ubuntu-release- New: accepted vine [sync] (artful-proposed) [1.1.3+dfsg-2]
-queuebot:#ubuntu-release- New binary: libva-utils [ppc64el] (artful-proposed/universe) [1.8.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libva-utils [amd64] (artful-proposed/universe) [1.8.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libva-utils [i386] (artful-proposed/universe) [1.8.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libva-utils [armhf] (artful-proposed/universe) [1.8.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libva-utils [s390x] (artful-proposed/universe) [1.8.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libva-utils [arm64] (artful-proposed/universe) [1.8.1+ds1-1] (no packageset)
<bdmurray> cyphermox: I verified bug 1676547. Do you think another verification is needed? e.g. the ignored devices you mention
<ubot5> bug 1676547 in network-manager (Ubuntu) "No network connectivity after upgrade from 16.04 to 16.10" [Critical,In progress] https://launchpad.net/bugs/1676547
<zx2c4> okay im super dumb
<zx2c4> LocutusOfBorg sponsored https://bugs.launchpad.net/ubuntu/+source/wireguard/+bug/1685522 and now it's in https://launchpad.net/ubuntu/zesty/+queue?queue_state=1&queue_text=wireguard . I read https://wiki.ubuntu.com/StableReleaseUpdates a few times and there are things about bug templates and adding bug tags, but does that even apply in this case or make any
<zx2c4> sense? i cant figure it out
<ubot5> Ubuntu bug 1685522 in wireguard (Debian) "out of date snapshot" [Unknown,Confirmed]
<zx2c4> this process must be really intuitive for you guys but it's quite overwhelming for me
<apw> zx2c4, you had a fix for wireguard and LoB sponsored it for you right ?  into zesty-proposed ?  it is waiting for SRU team approval
<zx2c4> apw: its an "empty package" update
<apw> zx2c4, i think i saw you saying that you had discussed this with someone, perhaps s-langasek, and was going to ask you to make sure that information is in the SRU bug, but there does not appear to be one
<zx2c4> apw: i just added a section?
<zx2c4> https://bugs.launchpad.net/ubuntu/+source/wireguard/+bug/1685522/comments/5
<ubot5> Ubuntu bug 1685522 in wireguard (Debian) "out of date snapshot" [Unknown,Confirmed]
<zx2c4> apw: is that correct?
<apw> zx2c4, bah, there is an SRU bug, but it is not mentioned in the upload
<zx2c4> apw: oh,erm, well what now
<zx2c4> apw: i seriously have no idea how to grok this
<zx2c4> tons of different websites and trackers and processes and tools
<zx2c4> im totally lost
<apw> zx2c4, when LoB did the sponsorship he should have noticed that the SRU Bug was not in the changelog
<zx2c4> oh
<zx2c4> changelog
<zx2c4> gotcha
<zx2c4> he made a few changes to the package
<zx2c4> but i guess he didnt notice
<zx2c4> so now what
<zx2c4> it's in bureaucracy purgatory?
<apw> (yes the process must seem archane to the uninitiated)
<apw> heh, we are in that
<zx2c4> holy moses
<zx2c4> cant you just press the button and make it all just go through smoothly
<zx2c4> or, uh, is there a real human who we could just speak to instead of going through all these hoops?
<zx2c4> seems like that would save hours of time
<apw> heh, well i am a real human, at least last time i checked
<zx2c4> oh, cool, and you're part of the team and stuff who can do things?
<zx2c4> sorry - i thought you were just a kind soul helping me navigate the waters, but otherwise just another user like me
<apw> yep, i am able to review that upload, and indeed was
<zx2c4> nice!
<zx2c4> my original .tar.gz source package was much more minial than the LoB one -- he added back the original source and quilt stuff that was supposed to be removed, for some reaosn, even though he kept my blank makefile and whatnot
<zx2c4> i assume this is more convention/process stuff
<apw> zx2c4, that keeps the visual delta for review to a minimum i guess
<zx2c4> oh, thats silly
<zx2c4> but okay
<zx2c4> makes the package look super sloppy IMHO
<zx2c4> doesnt really matter now i guess
<zx2c4> so what is happening right now in terms of kicking this along?
<apw> indeed, i assume because he wanted to keep the orig
<zx2c4> keeping the orig makes _no_ sense at all
<zx2c4> ohwell
<apw> on that you'd want to argue with LoB
<zx2c4> apw: yea as i said it doesnt really matter any more
<zx2c4> i just want to keep this thing moving along the pipeline
<zx2c4> and now its evidently stopped
<zx2c4> but you're doing something to move it forward since you're on the sru team?
<apw> zx2c4, i am
<zx2c4> yay!
<zx2c4> thanks a bunch
-queuebot:#ubuntu-release- Unapproved: wireguard (zesty-proposed/universe) [0.0.20170214-1 => 0.0.20170214-1ubuntu0.17.04] (no packageset)
<zx2c4> woah whats that mean
<zx2c4> wait now there are two in there
<apw> zx2c4, yep, don't sweat it
<apw> zx2c4, that is me just adding the bug number to the changelog
<zx2c4> nice added the LP #
<zx2c4> excellent
-queuebot:#ubuntu-release- Unapproved: rejected wireguard [source] (zesty-proposed) [0.0.20170214-1ubuntu0.17.04]
<zx2c4> cool so thats the old one going away
<apw> yep
-queuebot:#ubuntu-release- Unapproved: accepted wireguard [source] (zesty-proposed) [0.0.20170214-1ubuntu0.17.04]
<zx2c4> accepted!
<zx2c4> now it's in done!
<apw> zx2c4, yep, looks tollerable and i assume that whats there is some kind of mess which will kill kittens from the bug description, so it has to be better than that
<apw> zx2c4, it'll build and publish into zesty-proposed now, and can be double checked that it works for the purpose (people can upgrade to it and get fixed) etc
<apw> zx2c4, and then it'll get released once that is done to -updates
<zx2c4> what what kittens what better than that error:didnotparse
<zx2c4> okay cool
<zx2c4> so do i need to run a zesty machine and explicitly pull the package from zesty-proposed to try it and report back on the bug or something?
<apw> from teh bug i assume the version in -release is toxic
<apw> zx2c4, the bug will request someone tests it yes, if you can do that then that is helpful indeed
<zx2c4> apw: oh, no, the issue is just that wireguard is experimental software and the contract that's made with distros is that it's fine to package if and only if each snapshot is updated and doesn't go stale. so the idea here would be to always track debian sid, which is maintained by dkg who is active with the project
<zx2c4> so i very much would have preferred the ubuntu package to track debian sid
<zx2c4> but evidently that's not how it works or something? so infinity just said to remove the package all together
<zx2c4> that seemed a bit harsh and bad to me, but i'd rather have that then have an unacceptably outdated package in there
<zx2c4> and now seeing the huge amount of paperwork involved to just make a simple version bump, it's making more sense to me that it might not just be "trivial" to track debian sid
<apw> people would normally use a PPA for that kind of thing, for a development snapshot you want to update without having to jump thorough process hoops
<zx2c4> yea
<zx2c4> so that was the plan in the first place. it never was supposed to migrate out of sid anyway. so this whole business is just rectifying that error.
<apw> ahh did it leak in debian as well ?
<zx2c4> apw: no, dkg did the right hting and set it up not to do so
<zx2c4> apw: oh, no
<zx2c4> this package is wrong
<zx2c4> i just checked the build
<zx2c4> it's still instlaling files
<zx2c4> because of LoB's changes!
<zx2c4> im going to add a launchpad # to the changelog of the original minimal one
<apw> zx2c4, there are nolonger any binaries in there, but yes, there looks to be an example in there, sigh
<zx2c4> not good
<zx2c4> im uploading a new tar.gz to the bug report
<apw> zx2c4, you will need to increment the version of course
<zx2c4> oh, ugh
<zx2c4> really
<zx2c4> ?
<zx2c4> the other one is stuck in there?
<zx2c4> okay ill submit two
<zx2c4> this is nuts!
<apw> does debian let you have two packages with the same version number and different contents ...
<zx2c4> do i have to append the changelog, or can i just change the existing entry
<apw> i'd just add a .1 on the end of teh 0.17.04 bit myself
<zx2c4> apw: okay
<zx2c4> so
<zx2c4> 0.17.04.1
<zx2c4> thats fine
<zx2c4> do i need to add an entry to the top of the changelog, or can i simply modify the existing descriptive changelog entry?
<apw> its pretty normal to have an incremental upload # in there
<zx2c4> okay
<apw> if we are killing the previous one without releasing i don't care if there is a new section or not
<zx2c4> okay great
<apw> zx2c4, you can delete the attachments if they are wrong
<zx2c4> apw: https://bugs.launchpad.net/ubuntu/+source/wireguard/+bug/1685522/+attachment/4867673/+files/wireguard_0.0.20170214-1ubuntu0.17.04.1.tar.gz
<ubot5> Ubuntu bug 1685522 in wireguard (Ubuntu) "out of date snapshot" [Undecided,Confirmed]
<zx2c4> done.
<zx2c4> apw: the .deb that those generate are perfect
<zx2c4> so now we do the queue again?
-queuebot:#ubuntu-release- Unapproved: wireguard (zesty-proposed/universe) [0.0.20170214-1ubuntu0.17.04 => 0.0.20170214-1ubuntu0.17.04.1] (no packageset)
<zx2c4> nice!
<zx2c4> its happening
-queuebot:#ubuntu-release- Unapproved: accepted wireguard [source] (zesty-proposed) [0.0.20170214-1ubuntu0.17.04.1]
<zx2c4> thanks apw
<zx2c4> i really appreciate it
<zx2c4> apw: so im supposed to wait for SRU to change the tag to -->verification-done, right? testers arent supposed to do it themselves?
<apw> zx2c4, no you can test it and do that
<zx2c4> oh, cool, okay
<zx2c4> the -dkms package is changing from _amd64 -> _all
<zx2c4> presumably that is okay though
<zx2c4> rather, the -tools package is doing so
<zx2c4> this is intended, since there's no platform specific code in the new package
<apw> zx2c4, it will either work in testing or not, that is the key test
<zx2c4> haha indeed
<zx2c4> i manually dpkg -i'd the .deb but
<zx2c4> i want to wait for it to sync to the index
<zx2c4> so i can see precisely what hpapens with `apt install`
<zx2c4> (i dont want to accidently accept this and then have to go through the whole process again)
<apw> takes about 40m
<zx2c4> cronjob i guess?
<zx2c4> okay, so it's 7:30am in the morning here. i stayed up all night trying to figure out ubuntu build system (and failed, but then you saved me)
<zx2c4> going to get some rest and then check&adjusttag first thing when i wake up
<apw> its not much better here
<zx2c4> :-D
<zx2c4> Well thank you so so so much for your help
<zx2c4> Very much appreciated
<apw> np
<Laney> 25/04 05:14:05 <apw>
<Laney> !!!!
<apw> Laney: happens ... ugg
<acheronUK> insomnia strikes?
<acheronUK> I know that feeling
 * Laney pats apw 
<apw> acheronUK, something like that
-queuebot:#ubuntu-release- Unapproved: ding-libs (xenial-proposed/main) [0.5.0-1 => 0.5.0-1ubuntu0.16.04.1] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected linux-firmware [source] (zesty-proposed) [1.164.1]
-queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (yakkety-proposed) [1.28~16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (xenial-proposed) [1.28~16.04.1]
<apw> slangasek, ^ you did that backport as far as xenial did you intend to go further ?
-queuebot:#ubuntu-release- Unapproved: accepted caja [source] (zesty-proposed) [1.18.1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (zesty-proposed) [1.164.1]
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (zesty-proposed/main) [0.93.1ubuntu2 => 0.93.1ubuntu2.1] (desktop-core, ubuntu-server)
<sergiusens> can I get snapcraft into -updates please? On pending SRU there's an ubuntu-image failure on i386 which I cannot relate to a snapcraft problem
<sergiusens> apw: maybe you don't mind taking a look? ^
 * apw looks
<apw> sergiusens, ok all released ... remember artful is now open and to throw that in as well next time round
<sergiusens> apw: thanks, and yeah, I was going to do it for this one to (push it to a) but it was still frozen at the time
<apw> sergiusens, not a complaint, just a reminder
<sergiusens> that said, can't wait for Y to EOL :-)
<sergiusens> thanks again!
<ginggs> would someone please 'force-badtest python-asdf/all/s390x' - looking at old test logs, it seems the tests have always failed on s390x, but only recently did the exit status starting getting returned
<apw> it is very unsatisfactory that we have only /all/ for that, as it may start not being broken sometime
<apw> Laney, ^ is there any way we can apply different fire to make that into always-failed ?
<Laney> no
<Laney> that would probably be a nice feature
<Laney> but it's not there
<Laney> we've talked about that before
<apw> Laney, should we have some markup to say "remove this on this date" so we at least re-check every month/cycle/millenia
<Laney> why is that python-asdf log a 404?
<apw> Laney, oh has someone applied actual fire to the results perhaps ?
<apw> Laney, http://autopkgtest.ubuntu.com/packages/p/python-asdf/artful/s390x
<apw> as we only seem to have literally one result now, sadly a good one
<Laney> what's that about
<apw> oh and that one result the log is also gone
<ginggs> old results here http://autopkgtest.ubuntu.com/packages/python-asdf/zesty/s390x
<apw> Laney, oh it seems to systemic, i cannot hit any of the others either
<ginggs> the first result for the new series always seems to 404
<ginggs> happened with zesty too
<xnox> apw, looking at zesty the logs are there and failed.
<xnox> apw, i think artful logs links are broken, as they are copy of previous release or some such, no? or was everything retriggered?
<Laney> I think it's copying the status from the previous release
<Laney> that makes sense
<ginggs> e.g. try hitting the log at the bottom of the zesty page, dated 2016-10-05 06:42:50 UTC
<apw> oh and looking in teh wrong swift bucket for the result
<xnox> apw, it seems to me that -2 is broken, as the only passes are with -1
<xnox> and -2 was supposed to fix CI tests
<xnox> hm
<xnox> http://launchpadlibrarian.net/302710801/python-asdf_1.2.1-1_1.2.1-2.diff.gz
<rbasak> bdmurray: opinion on releasing bug 1611816 to xenial-updates? It's not verified on Yakkety, and it seems unlikely that anyone will. So that would create a feature regression on Xenial->Yakkety upgrade ("any such feature must then also be added to any newer supported Ubuntu release")
<ubot5> bug 1611816 in cifs-utils (Ubuntu Yakkety) "pam_cifscreds.so not supplied in package" [Medium,Fix committed] https://launchpad.net/bugs/1611816
<rbasak> So should I hold releasing pending verification of Yakkety as well?
<xnox> ginggs, why do you want force badtest? or why do you want -2 python-asdf?
<ginggs> compare a -1 and a -2 log on s390x, they both have the same FAILURES
<xnox> true
<xnox> ginggs, but asdf is asserting things on as binary checksums and i clearly see bigendian fails.
<Laney> looks like we managed to miss a bug before, and now we know about it
<xnox> Laney, apw - i really wish we did not have :all packages auto published into all arches, idealy i'd make python-asdf:all to not be published into s390x, as clearly it is broken on that arch.
<xnox> indeed, needs a bug report. I will follow up.
<ginggs> xnox, yeah i'm not saying its not broken on big endian, i'm saying it's always been broken - so not a regression
<Laney> Might as well get it out of proposed by fixing the bug rather than ignoring the test
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (yakkety-proposed/main) [0.92ubuntu1.3 => 0.92ubuntu1.4] (desktop-core, ubuntu-server)
<xnox> https://bugs.launchpad.net/ubuntu/+source/python-asdf/+bug/1686079
<ubot5> Ubuntu bug 1686079 in python-asdf (Ubuntu) "python-asdf is broken on big endian architectures" [High,Confirmed]
<xnox> opened upstream bug report too on github
<xnox> https://github.com/spacetelescope/asdf/issues/235
<ginggs> xnox: thanks
<Laney> <3
<zx2c4> apw: verification done state! horrah https://bugs.launchpad.net/ubuntu/+source/wireguard/+bug/1685522 -- everything worked perfectly
<ubot5> Ubuntu bug 1685522 in wireguard (Ubuntu) "out of date snapshot" [Undecided,Confirmed]
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (xenial-proposed/main) [0.90ubuntu0.4 => 0.90ubuntu0.5] (desktop-core, ubuntu-server)
<ahasenack> rbasak: I can try verifying that on yakkety
<ahasenack> https://launchpad.net/bugs/1611816 I mean
<ubot5> Ubuntu bug 1611816 in cifs-utils (Ubuntu Yakkety) "pam_cifscreds.so not supplied in package" [Medium,Fix committed]
<rbasak> ahasenack: thanks!
<rbasak> RAOF: I thought it was Wednesday for some reason. I've been releasing SRUs from the proposed report.
<apw> rbasak, the sru table doesn't seem to have people assigned anymore
 * sil2100 needs to finally assign himself to a day
<zx2c4> apw: so is the next step pushing the button to move from -proposed to main?
<zx2c4> or is that another team typically?
<rbasak> apw: https://wiki.ubuntu.com/StableReleaseUpdates#Publishing ?
<sil2100> I added myself on Monday, since I assume Adam might be too occupied for SRU publishing usually
 * apw boggles at what he was reading
<apw> zx2c4, that will happen as a matter of course if you have verified it
<zx2c4> i changed the tag to verified-done
<zx2c4> hopefully thats correct
<apw> oh it was archive admin days
<mitya57> It should be âverification-doneâ, not âverified-doneâ.
-queuebot:#ubuntu-release- Unapproved: rejected iproute2 [source] (yakkety-proposed) [4.3.0-1ubuntu3.16.10.1]
-queuebot:#ubuntu-release- Unapproved: sbuild (yakkety-proposed/universe) [0.71.0-2ubuntu1 => 0.71.0-2ubuntu1.1] (no packageset)
<rbasak> Archive admins have days? :)
<ogra_> periodical :)
<apw> yeah it should be archive admin nights really
<bdmurray> rbasak: that type of bug seems trivial enough to verify on yakkety that I, as an SRU team member, might just do it
<rbasak> bdmurray: fair enough, but what about the general case?
<xnox> slangasek, both sbuild and autopkgtest "regressions" are either test failures themself; or interaction failure of autopkgtest with autopkgtest...
<xnox> Laney, is on the case to fix autopkgtest/xenial test failure.
<xnox> i have uploaded sbuild/yakkety fix into unapproved queue.
<xnox> still need to figure out how to backport the test fixes to sbuild/xenial, given older sbuild there.
<bdmurray> rbasak: I'd think about how long the interim release, Y in this case, is supported.
<bdmurray> rbasak: People aren't likely to upgrade from X to Y at this point in time, take bug 1676547 for example. ;-)
<ubot5> bug 1676547 in network-manager (Ubuntu) "No network connectivity after upgrade from 16.04 to 16.10" [Critical,In progress] https://launchpad.net/bugs/1676547
<bdmurray> cyphermox: speaking of is there some more testing that should be done to cover "if devices that should be explicitly ignored by" NM?
<cyphermox> no, it's pretty much just the upgrade test
<bdmurray> okay I wasn't sure if an upgrade with a special configuration should be tested
<cyphermox> the intent is to not break people's systems on upgrade, if they then want to start using netplan, it will still require manual intervention
<cyphermox> well, you could enable netplan and then upgrade.
-queuebot:#ubuntu-release- Unapproved: accepted sssd [source] (yakkety-proposed) [1.13.4-3ubuntu0.4]
<cyphermox> let me add that to the testcase, and then I'll spin up a VM to do that test
<bdmurray> cyphermox: sounds good, thanks!
-queuebot:#ubuntu-release- Unapproved: accepted sssd [source] (xenial-proposed) [1.13.4-1ubuntu1.5]
<jbicha> bdmurray: if someone wants to upgrade to Z, they have to go through Y, right?
<bdmurray> jbicha: not if Y is EoL
<jbicha> so in a few months, you can upgrade directly from X to Z?
-queuebot:#ubuntu-release- Unapproved: autopkgtest (xenial-proposed/main) [4.3~ubuntu16.04.1 => 3.20.4ubuntu1] (core)
<bdmurray> jbicha: Yes
-queuebot:#ubuntu-release- Unapproved: sbuild (xenial-proposed/universe) [0.67.0-2ubuntu7 => 0.67.0-2ubuntu7.1] (no packageset)
<Laney> What's the haps on autosync?
-queuebot:#ubuntu-release- Unapproved: sosreport (trusty-proposed/main) [3.2-2~ubuntu14.04.1 => 3.4-1~ubuntu14.04.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: sosreport (yakkety-proposed/main) [3.3-1 => 3.4-1~ubuntu16.10.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: sosreport (xenial-proposed/main) [3.2+git276-g7da50d6-3ubuntu1 => 3.4-1~ubuntu16.04.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: sosreport (zesty-proposed/main) [3.3+git50-g3c0349b-2 => 3.4-1~ubuntu17.04.1] (ubuntu-desktop, ubuntu-server)
<infinity> Laney: I'll be turning it on soon.  Was just giving people a chance to do some manual merges and mini-transitions if they felt the urge.
<Laney> I feel the urge for some hot de-tangling action
<infinity> Oh baby.
<Laney> Stupid freeze probably limits the fun though
<infinity> Which freeze?
<davmor2> all of them
<infinity> Oh, the Debian freezew.
<infinity> s/w//
<slangasek> apw: backport> that's in reference to shim-signed?  I hadn't yet because IIRC there's still another shim-signed in process for trusty and it's not critical right now
<apw> slangasek, ahh yes shim-signed indeed ... thanks
-queuebot:#ubuntu-release- Unapproved: binutils (trusty-proposed/main) [2.24-5ubuntu14.1 => 2.24-5ubuntu14.2] (core)
<slangasek> infinity: why is gcc spitting noise about ignoring /usr/share/dpkg/ in the colord testsuite in artful? http://autopkgtest.ubuntu.com/packages/c/colord/artful/armhf
<slangasek> that's /usr/share/dpkg/pie-compile.specs, /usr/share/dpkg/pie-link.specs
<slangasek> I thought it was resolved that dpkg would not be trying to mangle specs anymore
<infinity> slangasek: That's not entirely how that bug played out, no.
 * tsimonq2 high-fives Laney - merge fun! :D
<infinity> slangasek: In the end, with PIE being enabled on all Debian arches, I think we need to revert that gcc patch.
<slangasek> infinity: can you elaborate?  I thought doko's position was very clear, that dpkg should not be overriding specs.  And in those build logs I see gcc being passed a -spec option courtesy of dpkg-buildflags
<infinity> slangasek: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848129 is a "fun" read.
<ubot5> Debian bug 848129 in dpkg-dev "pie-link specs should not be passed when pie is not enabled" [Important,Fixed]
<infinity> slangasek: So, basically, the (broken, IMO) gcc patch will trip for arches where PIE isn't the default and hardening=+pie (or +all) is passed.  I could switch that to -fPIE -pie instead, but that will, as guillem points out, cause other build regressions.  This all got papered over in Debian because there are no official Debian arches that aren't PIE-by-default anymore, and the patch doesn't filter the spec file for pie *disabling*, just the ...
<infinity> ... inverse.
<infinity> slangasek: I guess when I asked doko if he was okay with the current state of dpkg, I had wrongly assumed he'd backed out this patch, since the two are clearly not compatible. :/
<slangasek> ok
<slangasek> infinity: trying to understand exactly what was changed here, it seems that pie was moved out of Dpkg/Vendor/Default.pm and into Dpkg/Vendor/Debian.pm; but doesn't that just mean that Ubuntu inherits from there?
-queuebot:#ubuntu-release- Unapproved: rejected binutils [source] (trusty-proposed) [2.24-5ubuntu14.2]
<slangasek> so for places where Ubuntu and Debian have different PIE behavior, dpkg is still wrong AIUI
<infinity> slangasek: Nah, cause I also changed the whitelist.
<slangasek> ah
<slangasek> ok
<infinity> slangasek: (Yes, the whitelist should be a vendor var, but it's not, so oh well)
<slangasek> infinity: then I think I will ignore this until doko is back
<infinity> I'm tempted to pull out the gcc patch and suffer his wrath on return.
<infinity> Because as it stands, hardening=+pie will not work on 3/6 of our arches.
<infinity> Which is not ideal as I'm about to turn on autosyncs.
<slangasek> ah is that the impact - yeah, that seems worth backing out the patch then
<slangasek> infinity: you'll flag it to him as well?
<infinity> I'll let him know.  And put on a helmet.
<slangasek> ok
<infinity> The other option, as I said, is to make +pie use -fPIE -pie flags instead of specs.
<infinity> Which is more error-prone, but also less controversial in the short term.
<infinity> Likely to blow up a bunch of library builds, though.
<infinity> So, perhaps less than ideal. :P
<bdmurray> cyphermox: with regards to bug 1676547 - will people with only -security enabled upgrading from 16.04 be affected?
<ubot5> bug 1676547 in network-manager (Ubuntu) "No network connectivity after upgrade from 16.04 to 16.10" [Critical,In progress] https://launchpad.net/bugs/1676547
<slangasek> xnox: so the sbuild sru is a wholesale backport of the autopkgtest?
<xnox> slangasek, yeap; as is in yakkety; with a further tweak in xenial.
<xnox> slangasek, there are about 5-6 upstream commits; cherry-picking individual fixes, exposes other bugs, that were fixed up later. Thus imho updating to latest version of the test is the best course of action.
<xnox> the actual amount of testing of /sbuild/ is the same.
<xnox> e.g. both before and after, it is verified that it can create $devel and build procenv in it.
 * slangasek nods
-queuebot:#ubuntu-release- Unapproved: accepted sbuild [source] (yakkety-proposed) [0.71.0-2ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted sbuild [source] (xenial-proposed) [0.67.0-2ubuntu7.1]
<cyphermox> bdmurray: no, they wouldn't be affected.
<slangasek> xnox: and autopkgtest^2 failure is due to wrong assumptions about /proc/cpuinfo?
<xnox> he?
<slangasek> xnox: autopkgtest/armhf autopkgtest failed for apt
<slangasek> and it's looking for cpu_model and can't find it
<slangasek> just confirming if that matches your understanding of the root cause
<slangasek> the xenial one is different
<xnox> well xenial has that too on armhf only
<xnox> FAILED (failures=2, skipped=141)
<xnox> maybe Laney and I should have looked at armhf and cherrypick a fix for that too.
<xnox> there is no cpu_model on arm64
<xnox> i got disconnected, what was the last message that got through?
<xnox> well, i guess arm64 is not armv7l =)
<xnox> https://anonscm.debian.org/git/autopkgtest/autopkgtest.git/commit/?id=1f619a921083f4f9992adeb007257db50b6530a2
<xnox> https://anonscm.debian.org/git/autopkgtest/autopkgtest.git/commit/?id=37030cd0ee15151307dfe4b8416bf3dff9525c6b
<xnox> arm64 should fake armhf harder =)
<infinity> xnox: kernel personalities have never altered cpuinfo, that way lies madness.
<infinity> (people relying on cpuinfo to be anything other than casually informative are usually wrong)
<xnox> infinity, cool, can i haz real armhf in scalingstack? =) kthxbye
 * xnox EOD
<slangasek> xnox: no
<slangasek> HTH HAND
<xnox> i had to google both HTH and HAND
<nacc> heh
<xnox> infinity, lxc does fake things in /proc e.g. it fakes uptime.
<slangasek> infinity: if you are doing the gcc patch revert, can you let me know once that's published so I can retry colord autopkgtests?
<infinity> xnox: s/lxc/namespaces/ yeah.  But namespaces and personalities don't relate at all.
<infinity> slangasek: I'll get on that in a sec.
<slangasek> infinity: no hurry, just asking for the signal to be raised :)
<bdmurray> infinity: speaking of cpuinfo does what we are collecting in zesty look good?
<bdmurray> an example - https://launchpadlibrarian.net/316253544/ProcCpuinfoMinimal.txt
<infinity> bdmurray: Have any from ~x86 systems?
<infinity> bdmurray: But that LGTM for x86.
<infinity> bdmurray: Oh, except...
<infinity> bdmurray: Didn't one iteration of this take the *last* cpu instead of the *first*, so we'd pick up on the fact that there were more than one?
<infinity> Oh, that celeron might only have one.
<infinity> May have been a bad example. :)
<bdmurray> infinity: I think the first CPU is 0.
<infinity> bdmurray: Oh, it is indeed.  So that Celeron, being a Celeron, is just dinky and has two cores.
<infinity> bdmurray: So, yes, that collected info is a +1 from me for x86.
<bdmurray> infinity: Okay, I'll look for non-x86 then think about SRU'ing apport.
<infinity> bdmurray: But x86 doesn't have the CPU\n\nExtra_info bit that some !x86 arches do, so that Extra_info is the bit I'd also like to make sure we're collecting.
<bdmurray> infinity: bug 1680507 seems fine too
<ubot5> bug 1680507 in linux (Ubuntu Zesty) "breakpoint test from ubuntu_kernel_selftest failed to build on aarch64 " [Medium,Confirmed] https://launchpad.net/bugs/1680507
<infinity> bdmurray: arm64 is the same layout as x86. ;)
<nacc> ppc64el has the weird stuff at the end, iirc
<nacc> about the fw level and stuff
<infinity> bdmurray: Any hope for ppc... What he said.
<infinity> sparc does too, but we don't support sparc. :P
<infinity> So does armv7.
<infinity> And s390x is just entirely bizarre.
<bdmurray> Now I'm sorry I asked.
<nacc> heh
<nacc> and they are all different
<infinity> s390x cpuinfo is beyond different.
<infinity> We need a time machine to actually define a format for that.
<nacc> :)
<cjwatson> We might want to look at switching cdimage to python3 soon now that nusakan's on xenial.
<cjwatson> The code's been tested with both for ages.
<cjwatson> I just didn't want to deal with 3.2 in production ...
<infinity> slangasek: Oh, this might not be super contentious.  doko disabled the patch on Debian, just forgot (I presume) to do so on Ubuntu.
<bdmurray> slangasek: looking at http://cdimage.ubuntu.com/lubuntu/releases/16.10/release/ some of the wording between 64 bit / 32 bit could use an update too
<slangasek> bdmurray: the current wording is generated from scripts in lp:ubuntu-cdimage; if the existing language is wrong we should fix that there
<slangasek> infinity: ah ok
<bdmurray> slangasek: ack it seems to direct people to the 32 bit image e.g. "if you need support for 32-bit code" and "For almost all PCs".
<infinity> bdmurray: We could just update i386 to say "don't use this; if you use this, you're bad and should feel bad"
<bdmurray> infinity: "and upgrading in the future will be terrible"
<ginggs> I know many people who are caught out by the 64-bit description mentioning AMD, and the 32-bit description mentioning Intel/AMD
<infinity> bdmurray: (I don't think the "if you need full support for 32-bit" part is out of line, but the bits about which ports run on which machines could use an update)
<infinity> A bit of wikipedia research to figure out when all Intel machine supported long mode and then updating amd64 to say "for all modern PCs manufactured after 2007" or whatever might be better.
<infinity> s,PCs,Intel/AMD PCs,'
<infinity> Since the term "PC" is stupidly overloaded and meaningless.
-queuebot:#ubuntu-release- Unapproved: apt (xenial-proposed/main) [1.2.20 => 1.2.21] (core)
-queuebot:#ubuntu-release- Unapproved: apt (yakkety-proposed/main) [1.3.5 => 1.3.6] (core)
-queuebot:#ubuntu-release- Unapproved: apt (zesty-proposed/main) [1.4 => 1.4.1~17.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: binutils (trusty-proposed/main) [2.24-5ubuntu14.1 => 2.24-5ubuntu14.2] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted binutils [sync] (trusty-proposed) [2.24-5ubuntu14.2]
<mwhudson> can someone (infinity, slangasek?) review golang-defaults on https://launchpad.net/ubuntu/artful/+queue?queue_state=0&queue_text= please
<robert_ancell> jbicha, hey, was just about to restart into GNOME so wasn't on IRC
<robert_ancell> argh, wrong channel
-queuebot:#ubuntu-release- New: accepted golang-defaults [amd64] (artful-proposed) [2:1.8~1ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-defaults [armhf] (artful-proposed) [2:1.8~1ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-defaults [ppc64el] (artful-proposed) [2:1.8~1ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-defaults [arm64] (artful-proposed) [2:1.8~1ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-defaults [s390x] (artful-proposed) [2:1.8~1ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-defaults [i386] (artful-proposed) [2:1.8~1ubuntu1]
-queuebot:#ubuntu-release- New: accepted libva-utils [arm64] (artful-proposed) [1.8.1+ds1-1]
-queuebot:#ubuntu-release- New: accepted libva-utils [s390x] (artful-proposed) [1.8.1+ds1-1]
-queuebot:#ubuntu-release- New: accepted libva-utils [armhf] (artful-proposed) [1.8.1+ds1-1]
-queuebot:#ubuntu-release- New: accepted case [amd64] (artful-proposed) [1.5.3+dfsg-1]
-queuebot:#ubuntu-release- New: accepted libva-utils [i386] (artful-proposed) [1.8.1+ds1-1]
-queuebot:#ubuntu-release- New: accepted libva-utils [amd64] (artful-proposed) [1.8.1+ds1-1]
-queuebot:#ubuntu-release- New: accepted libva-utils [ppc64el] (artful-proposed) [1.8.1+ds1-1]
-queuebot:#ubuntu-release- New: accepted caja-extensions [i386] (artful-proposed) [1.18.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted caja-extensions [ppc64el] (artful-proposed) [1.18.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted caja-extensions [amd64] (artful-proposed) [1.18.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted caja-extensions [armhf] (artful-proposed) [1.18.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted caja-extensions [arm64] (artful-proposed) [1.18.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted caja-extensions [s390x] (artful-proposed) [1.18.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: golang-github-gosexy-gettext (zesty-proposed/main) [0~git20130221-0ubuntu12 => 0~git20130221-0ubuntu13] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: golang-gopkg-flosch-pongo2.v3 (zesty-proposed/main) [3.0+git20141028.0.5e81b81-0ubuntu7 => 3.0+git20141028.0.5e81b81-0ubuntu8] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: golang-context (zesty-proposed/main) [1.1-1ubuntu8 => 1.1-1ubuntu9] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: golang-gopkg-lxc-go-lxc.v2 (zesty-proposed/main) [0.0~git20161126.1.82a07a6-0ubuntu3 => 0.0~git20161126.1.82a07a6-0ubuntu4] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: golang-goprotobuf (zesty-proposed/main) [0.0~git20161116.0.224aaba-3ubuntu1 => 0.0~git20161116.0.224aaba-3ubuntu2] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: golang-github-mattn-go-colorable (zesty-proposed/main) [0.0.6-1ubuntu5 => 0.0.6-1ubuntu6] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: golang-gocapability-dev (zesty-proposed/main) [0.0~git20150716.0.2c00dae-1ubuntu7 => 0.0~git20150716.0.2c00dae-1ubuntu8] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: golang-petname (zesty-proposed/main) [2.6-0ubuntu1 => 2.6-0ubuntu2] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: golang-yaml.v2 (zesty-proposed/main) [0.0+git20170125.0.4c78c97-0ubuntu1 => 0.0+git20170125.0.4c78c97-0ubuntu2] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: golang-github-olekukonko-tablewriter (zesty-proposed/main) [0.0~git20151029.0.a5eefc2-1ubuntu6 => 0.0~git20151029.0.a5eefc2-1ubuntu7] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: golang-github-pborman-uuid (zesty-proposed/main) [0.0+git20150824.0.cccd189-1ubuntu7 => 0.0+git20150824.0.cccd189-1ubuntu8] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: golang-x-text (zesty-proposed/main) [0.0~git20161013.0.c745997-2ubuntu1 => 0.0~git20161013.0.c745997-2ubuntu2] (kubuntu, ubuntu-desktop, ubuntu-server)
<slangasek> tsimonq2: are you sure that the rationale given for the healpix-cxx name revert is correct?  It doesn't seem to match the upstream (Debian) rationale, which rather says "ehhh we already were building with g++6 so there's no compatibility issue"
#ubuntu-release 2017-04-26
-queuebot:#ubuntu-release- New binary: vine [amd64] (artful-proposed/universe) [1.1.3+dfsg-2] (no packageset)
<tsimonq2> slangasek: For what it's worth, I hate to put blame on anyone, but look at the bug report associated with my upload.
<tsimonq2> slangasek: I originally just wanted to keep the delta as-is and just merge from Debian, but what mapreri said seemed to make sense.
<tsimonq2> slangasek: Also, as a question for you, what is the difference between healpix-cxx and freehdl irt this?
<tsimonq2> slangasek: Because I'm not seeing a difference myself (but I could be wrong).
<tsimonq2> slangasek: (and I used freehdl as a model for my follow-up fix, as I noted in the bug report)
<tsimonq2> slangasek: Also, I could be wrong, but I have to do what I did because it was *already* renamed...
<tsimonq2> slangasek: fwiw here's a bug report bug 1685546
<ubot5> bug 1685546 in healpix-cxx (Ubuntu) "Merge 3.30.0-6 from Debian Sid" [Wishlist,Fix committed] https://launchpad.net/bugs/1685546
<tsimonq2> slangasek: So to answer your question, yes, I'm pretty sure. Please, if I'm mistaken, prove me wrong. :)
<mwhudson> oh haha all those golang uploads were meant to be for artful :(
<jbicha> mwhudson: did you do "dch -r"?
<mwhudson> i did not
<mwhudson> i also need to find the hammer to get dch to stop complaining about a distribution name it doesn't know about
<mwhudson> oh "yes |" works
<Ukikie> mwhudson: Don't have the latest distro-info-data..?
<nacc> mwhudson: --force-distribution
<tsimonq2> Oh, and Lintian.
<tsimonq2> I hate how Lintian keeps yelling at me... :P
<slangasek> tsimonq2: right; so the argument in Debian AIUI is "we don't need a transition because it was never in a stable release", not "we don't need a transition because the ABI didn't change"
<tsimonq2> !info healpix-cxx xenial
<ubot5> Package healpix-cxx does not exist in xenial
<tsimonq2> OH
<tsimonq2> Hmmm
<tsimonq2> Wait nevermind.
<tsimonq2> !info libhealpix-cxx0v5 xenial
<ubot5> libhealpix-cxx0v5 (source: healpix-cxx): representation of spherical data - C++ shared library. In component universe, is optional. Version 3.11.2-7.1ubuntu1 (xenial), package size 289 kB, installed size 958 kB
<tsimonq2> slangasek: But it's in an LTS release, I thought that meant we have to keep our delta until Artful+1?
<slangasek> tsimonq2: whereas in Ubuntu, libhealpix-cxx0 *was* in a stable release (vivid); so if there is an ABI change when rebuilding with g++6 vs. 5, that is relevant to us but not to Debian
<tsimonq2> slangasek: Sure.
<slangasek> g++5 vs. g++4.9 actually
<tsimonq2> slangasek: So what's the problem?
<slangasek> tsimonq2: the Provides: is possibly the problem
<slangasek> tsimonq2: sorry, I should have led with that - have you checked that the ABI of libhealpix-cxx0 in vivid matches the ABI of libhealpix-cxx0v5 in xenial+?
<tsimonq2> slangasek: I have not personally verified that, no.
<tsimonq2> slangasek: But we have carried the delta through 17.04.
<tsimonq2> slangasek: So I guess I'm failing to understand what the problem is.
<slangasek> tsimonq2: your merge has *changed* the package layout; you are declaring a Provides that wasn't there before; I am asking for proof that it is correct
<slangasek> you can only say Provides: if the ABIs are functionally identical
<slangasek> oops, hang on
<slangasek> ok, the Provides is certainly correct ;)
<slangasek> because the ABI of the new libhealpix-cxx0 is necessarily the same as the ABI of the previous libhealpix-cxx0v5
<slangasek> but it's not necessarily the same as the ABI of the previous libhealpix-cxx0
<tsimonq2> slangasek: So then tell me, what says that it's correct?
<tsimonq2> slangasek> you can only say Provides: if the ABIs are functionally identical - ah ok, didn't read this, nvm
<slangasek> but the previous libhealpix-cxx0 is before the last LTS
<tsimonq2> Yes, it is.
<slangasek> so by that measure, I'll add it to the bucket of "we're not sure this was actually correct but we'll follow Debian on it and blame them if it breaks".
<slangasek> and accept it from new
<slangasek> tsimonq2: thanks for listening to me babble ;)
<tsimonq2> slangasek: No, thanks for listening to ME babble. ;)
<tsimonq2> slangasek: And thanks for the review. :)\
-queuebot:#ubuntu-release- New: accepted healpix-cxx [amd64] (artful-proposed) [3.30.0-6ubuntu1]
-queuebot:#ubuntu-release- New: accepted healpix-cxx [armhf] (artful-proposed) [3.30.0-6ubuntu1]
-queuebot:#ubuntu-release- New: accepted healpix-cxx [ppc64el] (artful-proposed) [3.30.0-6ubuntu1]
-queuebot:#ubuntu-release- New: accepted healpix-cxx [arm64] (artful-proposed) [3.30.0-6ubuntu1]
-queuebot:#ubuntu-release- New: accepted healpix-cxx [s390x] (artful-proposed) [3.30.0-6ubuntu1]
-queuebot:#ubuntu-release- New: accepted healpix-cxx [i386] (artful-proposed) [3.30.0-6ubuntu1]
<tsimonq2> \o/
-queuebot:#ubuntu-release- New: accepted libepoxy [amd64] (artful-proposed) [1.3.1-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted libepoxy [armhf] (artful-proposed) [1.3.1-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted libepoxy [ppc64el] (artful-proposed) [1.3.1-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted libepoxy [arm64] (artful-proposed) [1.3.1-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted libepoxy [s390x] (artful-proposed) [1.3.1-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted libepoxy [i386] (artful-proposed) [1.3.1-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted vine [amd64] (artful-proposed) [1.1.3+dfsg-2]
<mwhudson> slangasek: can you mainify https://launchpad.net/ubuntu/+source/golang-1.8 ?
<mwhudson> ah i guess it's getting a bit late there
<slangasek> mwhudson: done anyway :)
-queuebot:#ubuntu-release- Unapproved: software-properties (yakkety-proposed/main) [0.96.24.7.1 => 0.96.24.7.2] (desktop-core, ubuntu-server) (sync)
<kees> zesty is missing from the top page of wiki.ubuntu.com and I can't log in to the wiki for some reason :(
<apw> kees, hmmm
<kees> ah, it was just really really slow.
<kees> fixed now
<apw> kees, wiki and really slow are synonymous for sure
<kees> hehe
<mwhudson> slangasek: thanks
<Laney> xnox: yeh feel free to test/upload
<Laney> I only looked at that one you were complaining about
<LocutusOfBorg> anybody can understand with me why llvm-toolchain-3.7 is not migrating? AA powers might be needed :)
<apw> llvm-3.7-examples/amd64 unsatisfiable Depends: llvm-3.7-dev (>= 1:3.7.1-5)
<LocutusOfBorg> yes, and I asked ( infinity did IIRC) to remove binaries on amd64
<apw>  llvm-3.7-dev      | 1:3.7.1-5        | artful-proposed/universe | arm64, armhf
<apw> so examples is uninstallable because it depends on it
<LocutusOfBorg> yes, I/we intentionally are building it only for arm*
<LocutusOfBorg> so, arch:all can't exist because somewhere they are not installable? seems strange
-queuebot:#ubuntu-release- Unapproved: qemu (xenial-proposed/main) [1:2.5+dfsg-5ubuntu10.11 => 1:2.5+dfsg-5ubuntu10.13] (ubuntu-server, virt) (sync)
 * apw thinks about that
<LocutusOfBorg> an arch:all can't depend on an arch:any package, otherwise it becomes uninstallable where such "any" is not built
<apw> that seems to be a true statement
<LocutusOfBorg> but examples depends on development packages
<LocutusOfBorg> there is no need to have examples on amd64 because the library is not available
<LocutusOfBorg> but meh, they are arch:all, so built for everybody
<apw> we might have to arch limit that example dep
<cpaelzer> ah while I see you here LocutusOfBorg, yes I think the merge on me is fine, I saw on mom that you added me as comment
<cpaelzer> LocutusOfBorg: we will roadmapify all our merges soon if you need any sort of further confirmation
<LocutusOfBorg> cpaelzer, I don't know how to add people on MoM, but thanks, even if I don't remember the package (strongswan?)
<cpaelzer> LocutusOfBorg: yes the swan
<LocutusOfBorg> thanks!, I hate doing no-change rebuilds and being accounted on MoM
<LocutusOfBorg> apw, seems that Debian force-hinted it to let it migrate
<LocutusOfBorg> since we disabled llvm-3.7 on archs because we *don't* want people using it anymore
<LocutusOfBorg> it seems something useful
<mapreri> all depends on britney's conf, mind yo
<mapreri> you*
<mapreri> https://anonscm.debian.org/git/mirror/britney2.git/tree/britney.conf#n36
<mapreri> # if you're not in this list, arch: all packages are allowed to break on you
<mapreri> NOBREAKALL_ARCHES = i386 amd64
<mapreri> might be different on ubuntu
<LocutusOfBorg> apw, force-hint pretty please?
<xnox> Laney, tah
<infinity> LocutusOfBorg: No.
<infinity> LocutusOfBorg: arch-restrict llvm-3.7-examples or, here's a novel thought, stop producing the package entirely, since you "don't want people using that version".
<LocutusOfBorg> infinity, https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+sourcepub/7737290/+listing-archive-extra I'm already testing the first
<apw> LocutusOfBorg, force-hint> that doesn't seem like the right approach ...
<LocutusOfBorg> it did seem the right approach for Debian Release
<LocutusOfBorg> anyhow, will probably ask to move to a recommends or similar
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-340 [source] (xenial-proposed) [340.102-0ubuntu0.16.04.2]
<LocutusOfBorg> infinity, "missing build on amd64: clang-3.7-doc, liblldb-3.7, liblldb-3.7-dbg, liblldb-3.7-dev, lldb-3.7, lldb-3.7-dev, llvm-3.7-examples (from 1:3.7.1-3ubuntu4) "
<LocutusOfBorg> now with that removal we should be good, right?
<LocutusOfBorg> just for next time, where did mark blog the artful codename? :)
<ogra_> i think he didnt this time
<LocutusOfBorg> so... who choose it?
<apw> mark
<ogra_> i didnt say he didnt chose it :)
<LocutusOfBorg> interesting :)
<ogra_> he just didnt blog about it it seems
<LocutusOfBorg> I used to go on that website to understand when the archive was opening
<LocutusOfBorg> I missed two days of work :)
<ogra_> not trusting infinity's mails ?
<LocutusOfBorg> I'm subscribed to ubuntu-devel and ubuntu-devel-discuss, where did that mail go?
<ogra_> ubuntu-release
<LocutusOfBorg> ough
<ogra_> iirc
<ogra_> ah, no ... ubuntu-devel-announce actually
<LocutusOfBorg> thanks, will check my subscription then
<LocutusOfBorg> BTW I plan to pass the llvm-3.8 arm64 test hang to doko when he is back from VAC :/ I don't really have clues, but seems somewhat a gcc timeout
-queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (xenial-proposed) [3.4-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (trusty-proposed) [3.4-1~ubuntu14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (yakkety-proposed) [3.4-1~ubuntu16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (zesty-proposed) [3.4-1~ubuntu17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (xenial-proposed) [1.2.21]
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (yakkety-proposed) [1.3.6]
-queuebot:#ubuntu-release- Unapproved: rejected iproute2 [source] (xenial-proposed) [4.3.0-1ubuntu3.16.04.1]
<dax> howdy! what's the difference between "current" and "pending" on http://cdimage.ubuntu.com/daily-live/ in general? I assume pending becomes current after $something, just not sure what that is.
<slangasek> dax: after automated smoketests pass, if any exist
<dax> thanks :)
<slangasek> mwhudson: I promoted golang-1.8 but it wants demoting; golang-defaults hasn't migrated?
<slangasek> mwhudson: because golang-defaults wants gccgo-go to be promoted, this harkens back to the conversation with infinity
<slangasek> mwhudson: n/m, gccgo-go itself is a binary that should be demoted; fixing now
<slangasek> why is the gcc-6 build horrible on arm64 :P
<LocutusOfBorg> slangasek, wrt LP: #1667834
<ubot5> Launchpad bug 1667834 in php7.1 (Ubuntu) "[FFe] Please remove php7.1 from zesty" [Undecided,Triaged] https://launchpad.net/bugs/1667834
<LocutusOfBorg> can I remove the block?
<slangasek> LocutusOfBorg: it's not my block, it's the server team's; nacc ^^ ?
<LocutusOfBorg> I mean, now it won't land on zesty anymore :p
<LocutusOfBorg> maybe lets land it on artful
<LocutusOfBorg> also 7.0 needs some mergecare :)
<LocutusOfBorg> "One of my tasks in 17.10 will be to migrate php7.1 into main and drop php7.0."
<LocutusOfBorg> I guess this means "remove after zesty"
<nacc> LocutusOfBorg: yes i own php, i'll handle it
<slangasek> LocutusOfBorg: yes, my setting the block was mechanics, it's the server team to consult about whether it's time to remove it now
<nacc> LocutusOfBorg: is there a reason you need to remove it?
<nacc> own for the server team, that is
<LocutusOfBorg> since the bug was "don't land for zesty", and now zesty is closed, I thought about setting it as "fix released", something everybody would/might do while randomly looking at bugs
<LocutusOfBorg> maybe you can retitle it, so people won't remove it by mistake :)
<nacc> presuming that doesn't change the tag's effect, i don't care
<nacc> slangasek: ?
<nacc> ah based upon slangasek's comment in the bug, it needs to stay open
<slangasek> nacc: keeping it open because you don't want it to migrate yet?
<nacc> slangasek: yeah
<slangasek> ok
<nacc> slangasek: i'm going to merge php7.0 now (in process) so i can sru it back logically, then i'll work on the migration
<slangasek> fwiw getting that done would let us clean up http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed, I would not mind seeing that happen :)
<nacc> i synced up with ondrej on it last week so we are in line with debian on timelines for 17.10 and 18.04
<nacc> slangasek: ack
<LocutusOfBorg> thanks you both for caring
<LocutusOfBorg> slangasek, on that page there is listed a package I maintain ndg-httpsclient
<LocutusOfBorg> should I do something?
<nacc> LocutusOfBorg: i updated the bug and assigned to myself for now
<LocutusOfBorg> yep, I saw
<slangasek> LocutusOfBorg: movements to universe don't require any action from developers; it's currently on http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed but not on http://people.canonical.com/~ubuntu-archive/component-mismatches because packages in artful-proposed no longer need it in main but packages in artful still do. Once those packages migrate (I don't remember what it
<slangasek> was, maybe it was conntrack?), it'll drop out
<LocutusOfBorg> thanks
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/python-urllib3/1.19.1-1
<LocutusOfBorg> this is the reason I wild guess
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-77.98] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-77.98]
<slangasek> ah, lubuntu-next image build failures, artful must be fully open
<slangasek> anyone planning to make a non-failing lubuntu-next image build? :)
<bdmurray> slangasek: Could you have look at bug 1680090? I'd like to release it and just want a rubber stamp that comment #9 isn't worth removing v-done.
<ubot5> bug 1680090 in apt-xapian-index (Ubuntu Zesty) "python3-xapian not installed when apt-xapian-index upgraded" [High,In progress] https://launchpad.net/bugs/1680090
<bdmurray> s/rubber stamp/second set of eyes to say/
<slangasek> bdmurray: agreed
<slangasek> bdmurray: dino99 is low signal-to-noise, he does craaaaazy things with his systems
<bdmurray> slangasek: yes, I know that name
<slashd> For SRU, I had a talk with apw and rbasak about this bug a couples weeks ago LP: #1674399, could you please look at this bug and based on the Descriptions and comment #6 if this looks eligible for SRU in Stable release ? (note that this is a HW enablement, not a bug, this is why I'm requesting you to have a look at it) thanks in advance
<ubot5> Launchpad bug 1674399 in openssl (Ubuntu Artful) "OpenSSL CPU detection for AMD Ryzen CPUs" [Medium,In progress] https://launchpad.net/bugs/1674399
<infinity> slashd: I disagree with your reasoning for not fixing both 64 and 32.
<infinity> slashd: Lots of people run 64/32 multiarch and would benefit from fixing both.
<slashd> infinity, I'm fine with fixing 32bit, I proposed that approach cause apw wanted to self-contained the fix as much as possible
<infinity> That doesn't really contain it much. ;)
<slashd> infinity, so what if I do the same proposition but including 32-bit in stable release, would that work for you ?
<infinity> slashd: The claim that Ryzen is "64-bit only" is also a bit poorly worded.  What you mean to say is "there are no 32-only variants".
<infinity> slashd: I think that would work for me, but what I really want to see is the diff.
<slashd> infinity, debdiff or the upstream patch ? I have both
<infinity> slashd: diff, so I can judge the impact from a code review, and then test plan (as you've mostly laid out, but modified to include both arches).
<rbasak> I had a brief look. Looks like a fairly straightforward rearrangement, but it needs reviewing carefully as it's in assembly.
<infinity> slashd: debdiff.  Am I missing where that's attached?
<rbasak> "Do it carefully" is my only comment really.
<slashd> infinity, I have it ready, but not attached yet. I'll attach to the bug now if you want
<rbasak> Also, for regression potential, are there any CPUs out there that will false positive?
<infinity> slashd: Conceptually, I have no issues with the plan (other than the "please do 32-bit too" comment).
<slashd> infinity, sure, I'm actually glad you are keen to see the 32-bit portion included
<rbasak> And I wonder if we need to test a wide variety of CPUs out there, and if so how that might be achieved.
<slashd> I have a debdiff with both arches ready for artful if you want to have a look
<infinity> rbasak: x86 vendors coordinate to not overlap on flags, if someone managed to break just this one, they'll have a very bad time in general.
<infinity> (I mean, sure, it's a possibility, but it hasn't happened in decades)
<rbasak> OTOH, if someone who knows tells us it's probably OK, that's fine too. infinity counts as such a person :-)
<slashd> infinity, rbasak, attaching the debdiff now
<infinity> rbasak: Kernels, C libraries, video drivers, crypto accelerators, etc, etc, on multiple OSes all rely on those flags not being broken.  I can be fairly confident from my history in that space that a newish flag (as this is) will not throw a false positive.
<rbasak> infinity: I thought your previous statement was fine, but thanks :)
<slashd> infinity, rbasak --> https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1674399/+attachment/4868343/+files/artful_openssl_lp1674399.debdiff
<ubot5> Ubuntu bug 1674399 in openssl (Ubuntu Artful) "OpenSSL CPU detection for AMD Ryzen CPUs" [Medium,In progress]
<infinity> rbasak: The only place where this messes up is when a flag is present, but broken which, ironically, only Intel ever seems to manage.  Then we need to mask out the broken CPUs.  But I know not of any such errata for sha acceleration.
<rbasak> Well, that's what I meant by a false positive.
<slashd> rbasak, for the testing I proposed something in comment #6
<slashd> let me know what you think
<rbasak> "Claims support but it doesn't" is the only definition of that, surely?
<infinity> On, x86 ASM, how I don't love reading you.
<infinity> rbasak: Oh, well, I read it as "the flag is on, but for unrelated reasons", which doesn't happen in practice.
<rbasak> I'll look at it another time thanks, as I'm EOD. Feel free to review and accept without me.
<infinity> rbasak: "Flag is on, but the CPU is crap" can happen, but it's rare and, as I said, historically only Intel manages to do this more than once a decade, and they already had this flag on pre-patch. ;)
<rbasak> already had this flag on> good point.
<slashd> rbasak, infinity, take your time to review all this, please keep me posted if possible by commenting the LP bug, and I stay at your disposal if you have any question I can answer.
<slashd> infinity, rbasak, tks for jumping on this
<infinity> slashd: Like I said, I'm conceptually fine with it (and, indeed, quite excited about the massive speed boost).  I think maybe the other thing I'd like to see is some attempt at coverage across a bunch of weirdo cores.  Whatever we can get our hands on.  If upstream has such testing, I'd accept that in lieu.
<slashd> infinity, ack
<infinity> A few generations of Intel cores pre/post-feature shoudn't be hard to dig up, ditto for AMD, but finding some odd non-Intel/AMD stuff to just double-check would be nice.
<infinity> (But I'm also not super concerned about the idea that someone's flipped that bit by accident)
<slashd> infinity, ack I'll do my best to test on various CPU that I can get access and try to contact openssl upstream to look at their upstream testing results
<slashd> infinity, so my question is, can we go ahead with the upload and do the testing during the -proposed phase ? or you want me to test all this prior the upload ?
<rbasak> IMHO, that's what -proposed is for, so doing it in the -proposed phase would be fine. But I'm interested to see what infinity says.
<rbasak> Though, I would want the plan to be in the bug description before accepting into proposed, because that can help prevent an accidental release if a verification-done gets marked without it done.
<slashd> rbasak, my proposal is documented in the LP bug, and will update it again with what has been discuss here, once infinity confirm about the testing as of if it needs to be done prior -proposed or not. And then of course again once in -proposed
<infinity> slashd: Upload away, IMO.
<infinity> slashd: We have enough users who recklessly run proposed that we'll get some test coverage there too. :P
<slashd> infinity, I'll then start the upload for Artful, note that starting next week I'll be gone for 2 weeks for sprints, and won't be able to do much testing, so do you think it's preferable we only start the SRU when I get back or we upload this week and worst case it will languish in -proposed for ~2weeks which will allow ppls to test with no stress (if any volunteer)
<Ukikie> I usually run with proposed, but with http://paste.openstack.org/show/608137
<slashd> mdeslaur, is your offer to upload my openssl debdiff on devlopment release (Artful) still valid ? I'll upload the debdiffs in Stable release myself ^^^^ look infinity comment
<infinity> slashd: I think letting it fester in proposed for two weeks to see if we get random negative feedback is entirely fine.  Obviously, I'll delete/revert it if it breaks anything, but I don't need you around for that.
<infinity> slashd: 2 weeks of random user installations plus you executing a more precision test plan should give us solid confidence.
<slashd> infinity, ack then mdeslaur will upload in Artful as I don't have righ in dev release, and I'll take care of the other uploads myself.
<slashd> infinity, tks again
<stgraber> going to mark juju-core as badtest FYI
<stgraber> + echo SKIP: Juju won't bootstrap unknown without published agent
<stgraber> so that's the usual juju issue of not knowing what the new release is
<stgraber> (trying to get LXD to migrate)
<infinity> stgraber: Can you maybe poke the juju folks with a sharp stick and get them to fix it too? :P
-queuebot:#ubuntu-release- Unapproved: gnome-software (zesty-proposed/main) [3.22.7-0ubuntu3 => 3.22.7-0ubuntu3.17.04.1] (ubuntu-desktop)
<stgraber> infinity: I'll be with them next week, will nag them then
-queuebot:#ubuntu-release- Unapproved: rejected apt [source] (zesty-proposed) [1.4.1~17.04.1]
<mdeslaur> slashd: sure, just let me know when it's ready and I'll do it
#ubuntu-release 2017-04-27
-queuebot:#ubuntu-release- Unapproved: php7.0 (xenial-proposed/main) [7.0.15-0ubuntu0.16.04.4 => 7.0.18-0ubuntu0.16.04.1] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New sync: php7.1 (artful-proposed/primary) [7.1.4-2]
-queuebot:#ubuntu-release- Unapproved: php7.0 (yakkety-proposed/main) [7.0.15-0ubuntu0.16.10.4 => 7.0.18-0ubuntu0.16.10.1] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: php7.0 (zesty-proposed/main) [7.0.15-1ubuntu4 => 7.0.18-0ubuntu0.17.04.1] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: gnome-software (yakkety-proposed/main) [3.20.1+git20170208.0.a34b091-0ubuntu1 => 3.20.1+git20170427.0.3d09239-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-software (xenial-proposed/main) [3.20.1+git20170208.0.a34b091-0ubuntu1~xenial1 => 3.20.1+git20170427.0.3d09239-0ubuntu1~xenial1] (ubuntu-desktop)
<tsimonq2> Archive admins: please override the test regression in ostree, looks fine to me and builds fine locally (in sbuild *and* autopkgtest).
<slangasek> tsimonq2: we need autopkgtests to pass on the infrastructure, not just by hand; I will not as a rule hint in autopkgtest regressions.  However in this case there is already a hint for the previous version that just needs updated, so done - but I see 'error: Server returned status 503: Service Unavailable' in the logs, is this test trying to access a service that's blocked by the firewall?
<slangasek> tsimonq2: and actually when I say 'done' I mean infinity did it
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.8.0-51.54~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (yakkety-proposed/main) [4.8.0-51.54] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.8.0-51.54~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (yakkety-proposed) [4.8.0-51.54]
<LocutusOfBorg> hello, question about magnum testsuite
<LocutusOfBorg> it is failing on s390x because probably ran in a container? doing systemctl is-active of a service inside a container is impossible
<LocutusOfBorg> what do you propose? disabling testsuite? ignoring it on s390x?
<LocutusOfBorg> this is blocking a lot of stuff
<LocutusOfBorg> (or do we have real s390x machines?)
<ginggs> LocutusOfBorg: armhf tests also run in containers
<ginggs> and the magnum tests on s390x did pass with python-oslo.i18n/3.15.0-0ubuntu1, so maybe that should be added to triggers
<LocutusOfBorg> I did all-proposed=1
<LocutusOfBorg> lets try again
<ginggs> http://autopkgtest.ubuntu.com/packages/m/magnum/artful/s390x someone tried with a bunch of triggers on 2017-04-26 08:40:37 UTC, but not python-oslo.i18n
<LocutusOfBorg> I did it
 * LocutusOfBorg probably
<LocutusOfBorg> infinity, ndg-httpsclient please demote :)
<LocutusOfBorg> (I did make urllib3 migrate a few minutes ago)
<LocutusOfBorg> so, now nothing is keeping it in main anymore
<apw> LocutusOfBorg, those will sow up in reports and get done as we go
<LocutusOfBorg> http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed
<LocutusOfBorg> you mean there? :)
<apw> no that one tells you what will happen when the packages migrate, it is not showing on the primary one yet
<LocutusOfBorg> how do I check if the package "can be demoted"?
<LocutusOfBorg> ./demote-to-proposed -n ndg-httpsclient -m "foo"
<LocutusOfBorg> lets see
<LocutusOfBorg> oh noes :( wrong tool
<cjwatson> there's no relevant dry-run for moving to universe other than component-mismatches
<LocutusOfBorg> ack thanks
<LocutusOfBorg> well, if you want,the package now should be movable to universe
<LocutusOfBorg> doko, hi, still on VAC? I suppose you are the one who knows when pie will be enabled by default :) (wrt steghide and similar failures)
<xnox> LocutusOfBorg, systemctl is-active should totally work inside containers. armhf and s390x run in two different type of containers, one is lxc the other is lxd. both are similar but lxd is slightly more strict with permissions and apparmor protection.
<LocutusOfBorg> interesting
<LocutusOfBorg> but why clicking retry a few times works?
<LocutusOfBorg> totally not reproducible
<xnox> because tests are flaky =)
<Laney> I bet it is
<Laney> People mash retry over and over again instead of looking at the failures
<Laney> Therefore the tests don't get more reliable
<LocutusOfBorg> Laney, this is completely true, but I have zero clues in debugging it further
<LocutusOfBorg> (this is why I asked here)
<LocutusOfBorg> I don't want flaky tests being around
<Laney> It also doesn't scale to make the release team responsible for fixing bugs just because they happen to show up in an autopkgtest result :/
<LocutusOfBorg> giving me help doesn't mean you have to fix it :)
<LocutusOfBorg> I don't have access to the hardware, and I don't know deeply how containers are working
<Laney> ok, well all I would know how to do is run the thing on lxc on my desktop
<Laney> sudo autopkgtest-build-lxc ubuntu artful; autopkgtest --shell-fail --apt-upgrade magnum -- lxc --sudo artful
<Laney> then hope it fails in the same way and attack it from there
 * LocutusOfBorg upgrades his autopkgtest tool
<LocutusOfBorg> but... how do I pass "s390x" arcitecture?
<LocutusOfBorg> oh I see
<Laney> nah just run it on your host arch
<LocutusOfBorg> but on results I don't see issues on arches not s390x
<LocutusOfBorg> you mean some generic lxc issue
<LocutusOfBorg> <VirtSubproc>: failure: ['sudo', 'lxc-ls'] failed (exit status 1, stderr 'sudo: lxc-ls: command not found\n')
<LocutusOfBorg> autopkgtest [12:25:44]: ERROR: testbed failure: cannot send to testbed: ['BrokenPipeError: [Errno 32] Broken pipe\n']
<LocutusOfBorg> it should have a strong lxc1 dependency
<xnox> no, it should not.
<xnox> because autopkgtest ships runners for all sorts of technologies, and one needs just any of them, not all. plus not all are available everywhere.
<LocutusOfBorg> recommends instead of suggests?
<Laney> don't think so
<Laney> but if the message isn't nice enough then you could file a bug at debian
<LocutusOfBorg> nah, not needed of course
<LocutusOfBorg> Error: container artful is not defined
<LocutusOfBorg> uff
<LocutusOfBorg> any idea? http://paste.ubuntu.com/24466017/
<Laney> the output you have there indicates that the container is called autopkgtest-artful
<LocutusOfBorg> thanks!
<Laney> and it just totally reproduced for me :)
<LocutusOfBorg> I got trapped by the .new, I thought the /dev/lxc" error was the culprit
<tjaalton> would it be possible to get debhelper 10 in xenial proper? packages are migrating to it and backporting hwe stack is getting more tedious
<LocutusOfBorg> Laney, Apr 27 10:40:35 autopkgtest-lxc-bfgnic magnum-conductor[31826]: /usr/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py:200: FutureWarning: The access_policy argument is changing its default value to <class
<LocutusOfBorg> Apr 27 10:40:35 autopkgtest-lxc-bfgnic magnum-conductor[31826]:   access_policy)
<LocutusOfBorg> is this related?
<Laney> I don't know
<Laney> you tell me :P
<LocutusOfBorg> restarting it works, so probably it is a race condition somewhere, starting it too fast
<LocutusOfBorg> it gets restarted many times too quickly, and goes into an error state
<jbicha> tjaalton: +1 from me
<jbicha> could someone look into why the default Ubuntu flavor does not have artful daily iso's published?
<jbicha> I thought this means that the iso build was successful today and yesterday: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/artful/ubuntu
<jbicha> oh I see it's in pending now at least http://cdimage.ubuntu.com/daily-live/
<Laney> Right, the platform-qa-jenkins jobs need to be updated.
<jbicha> thanks
<Laney> xnox: You want to fix that? ^-
 * Laney isn't in the right team
<xnox> Laney, i believe this was proposed to be fixed.... by someone else already. I saw the merge proposal.
<xnox> https://code.launchpad.net/~powersj/qa-jenkins-jobs/enable-artful-iso-testing/+merge/323252
<Laney> nice
<slashd> morning mdeslaur, is your offer to sponsor my openssl debdiff for openssl on development release (artful) still valid ?
<Laney> xnox: so fix means approve
<mdeslaur> slashd: yes, where is it?
<Laney> or merge or something
<slashd> mdeslaur, https://launchpadlibrarian.net/317175176/artful_openssl_lp1674399.debdiff
<xnox> Laney, i need olli ries to add me to the team or something.
<Laney> you are in the team
<xnox> canonical-platform-qa? no i am not.
<Laney> https://launchpad.net/~canonical-platform-qa-jenkins/+members#active
<Laney> that one
<xnox> ah -jenkins
<xnox> ok i shall merge it.
<xnox> and i think jenkins polls to self-update the jobs
<Laney> this https://code.launchpad.net/~canonical-platform-qa/qa-jenkins-jobs/snap-channel-support/+merge/320420 got some CI stuff run on it
<xnox> hm.
<xnox> Laney, i'm not sure if that still works. infinity did somebody tell you something about ci bot accounts that you semi-rejected, but I probably want to own? or e.g. foundations to own?
<xnox> was it platform-qa-bot?
<mdeslaur> slashd: ack, building now and will upload in a few miuntes
<slashd> mdeslaur, merci beaucoup, much appreciated
<Laney> xnox: do you know why it would have stopped working?
<xnox> -ENOCLUE
<Laney> ah well
<Laney> LocutusOfBorg: what happens if you install python-osprofiler inside the container where it's failing?
<LocutusOfBorg> how can I Laney ? do I need to install it before the autopkgtest is executed?
<Laney> LocutusOfBorg: erm... you get a shell when it fails, right?
<LocutusOfBorg> yes
<LocutusOfBorg> I do
<Laney> so, apt :P
<LocutusOfBorg> I did install it already
<LocutusOfBorg> but I don't know what to do next
<Laney> run the test again
<Laney> debian/tests/the-test-name
<Laney> (in general there's a chance it requires some of the AUTOPKGTEST_* variables set, but I checked and in this case it doesn't)
<LocutusOfBorg> ok but the test fails obviously
<LocutusOfBorg> the problem is: systemd tries to start it many times, and makes them "failed" units
<Laney> not obvious to me
<LocutusOfBorg> I thought I wrote this above
<Laney> it fails because of that missing dependency
<LocutusOfBorg> [12:48:13] <LocutusOfBorg> Laney, Apr 27 10:40:35 autopkgtest-lxc-bfgnic magnum-conductor[31826]: /usr/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py:200: FutureWarning: The access_policy argument is changing its default value to <class
<LocutusOfBorg> you mean this one?
<Laney> make it stop trying to respawn it
<Laney> so you stop getting smacked by the timer
<Laney> (or pass --setup-commands 'apt -y install python-osprofiler' and re-run the whole autopkgtest)
<LocutusOfBorg> e.g. I ran systemctl restart magnum-conductor and magnum-api, and the test is succeeding
<LocutusOfBorg> the problem is just some race condition during startup, probably a sleep 5 at the begin of the init script would "fix" this issue (wrong fix, of course, but to make clear what I'm saying)
<xnox> LocutusOfBorg, Laney - there were ordering bugs in many openstack packages, which failed when installing out of order, and the postinst doesn't wait for services to start.
<Laney> I'm telling you what the fix is
<xnox> they start, then fail, then restart, then succeed a lot, resulting in race which is not apperant to the naked eye, as the status command shortly after already says everything is running just fine.
<LocutusOfBorg> with python-osprofiler it works, interesting
<LocutusOfBorg> soooo how to fix properly?
<xnox> some of the similar bugs were fixed properly in the binary package depends and postinst; some with basically doing loop wait in dep8 =/
<Laney> Add that dependency
<Laney> It's not what xnox is saying
<xnox> ok
<Laney> Reproduce the bug and look in /var/log/magnum/...
<LocutusOfBorg> xnox, there is already the loop wait, for 5 seconds, but a failed unit isn't restarted automatically
<Laney> it's like "omg I don't know about osprofile things"
<LocutusOfBorg> "Depends: python-magnum, magnum-common, magnum-api, magnum-conductor, python-osprofile"
<Laney> There might be a separate issue with the failure handling in the systemd unit, but that's not what is causing the startup to fail here
<LocutusOfBorg> this works then
<Laney> probably wants to be in the real depends of the package
<Laney> then you can give autopkgtest the .dsc file instead of the package name and it'll build it and run the tests :-)
<LocutusOfBorg> oh indeed nice
<LocutusOfBorg> not sure if I have to add to python-magnum magnum-common or the two magnum-api/magnum-conductor
<LocutusOfBorg> probably the common is the best place
<LocutusOfBorg> the python binding has no init script
<Laney> where's the code that loads the config?
<Laney> probably python-magnum
<Laney> sil2100: the bot API key works
<Laney> winning
<sil2100> Laney: \o/ excellent!
<LocutusOfBorg> Laney, debian/magnum-common.postinst.in and debian/magnum-common.config.in seems to be the two parsing the config, not sure if it is the same as what you are referring to
<Laney> LocutusOfBorg: nah, code within the application itself - common has a dependency to python-magnum anyway
<Laney> e.g. "magnum/cmd/api.py:    profiler.setup('magnum-api', CONF.host)"
<xnox> did anything change in the cdimage layout and/or the download tool in question is just broken since 8th of april? ERROR:root:Failed to fetch URL 'http://cdimage.ubuntu.com/trusty/daily-live/pending/SHA256SUMS': HTTP Error 404: Not Found . Aborting!
<Laney> Presumably they stopped being built because there's no more point releases coming and someone cleaned up the old dailies?
<xnox> yeah, but they are still here http://cdimage.ubuntu.com/releases/trusty/release/ it looks to me like something is failing in jenkins / proxy etc. and that it fallsback to some bad urls as well.
<xnox> well artful download passed so we are good.
<xnox> static validation has failed though
<xnox> UTAHISOException: Cannot list ./wubi.exe in /data/iso/ubuntu/artful-desktop-amd64.iso: Command '['bsdtar', '-t', '-v', '-f', '/data/iso/ubuntu/artful-desktop-amd64.iso', './wubi.exe']' returned non-zero exit status 1
<xnox> hm, but i thought we stopped shipping wubi....
<xnox> or maybe it needs a new symlink on people.
 * xnox smells alphabetic ordering
<LocutusOfBorg> thanks Laney , uploaded!
<LocutusOfBorg> damn I forgot to give you credits :/
<LocutusOfBorg> sorry
<apw> weall know Laney rocks
<Laney> LocutusOfBorg: np, don't forget to push to git
<ginggs> Laney: \m/
<Laney> \m/ >_< \m/
<LocutusOfBorg> thanks done
<xnox> Laney, this is to fix static validation job, which blocks smoketest jobs https://code.launchpad.net/~xnox/utah/skip-wubi-more/+merge/323328
<Laney> trusty's the only wubi thing left?
<xnox> i think so.
<xnox> out of the ones that we test in the jenkins.
<Laney> looks like you need these people https://launchpad.net/~canonical-ci-engineering/+members#active
<xnox> fginther, ^ please review utah fix
<xnox> not sure if platform jenkins auto picks up things from lp:utah
<LocutusOfBorg> Laney, can I expect the same fix to apply to openstack-trove and murano?
<Laney> LocutusOfBorg: don't know
<LocutusOfBorg> lets see the publisher, testsuite rerun and then I'll try to see
<LocutusOfBorg> thanks for the help, now I have some more tools to debug
<Laney> Run the test, check what systemd says when the job fails to start
<Laney> run things by hand, see what they print, check log output, etc
<LocutusOfBorg> btw with mapreri we were talking about some improvements, e.g. when somebody clicks "retry" to a test, the status on excuses isn't set back to "running"
<LocutusOfBorg> so people click lots of times
<LocutusOfBorg> same test run should be not allowed, so clicking twice a link should result in only one test run
<LocutusOfBorg> the autopkg page e.g. http://autopkgtest.ubuntu.com/packages/g/gnocchi/artful/s390x should have probably some "all-proposed" column
<LocutusOfBorg> and a line saying "something is already running there, right now, waiting for result"
<mapreri> *blink*
<LocutusOfBorg> this would save some time to builders, due to useless retries
<mapreri> I know updating excuses is not easily feasible, so I was more thinking about having autopkgtest.u.c/packages/... pages having a note whether packages are being tested or in the queue.
<Laney> The queue isn't inspectable as it stands
<LocutusOfBorg> sad!
<Laney> Well
<Laney> /running/ could be split out into a script that makes some json or so
<Laney> and then /running/ and /packages/ and /request.cgi could all look at that
<apw> Laney, i thought running is actually static json is it not ?
<apw> i am sure i inspect that, it is however delayed and periodic
<Laney> apw: the logtail bit, but not the queue bit
<apw> Laney, isn't that in the json as well ... hrm
 * apw suggests ignoring apw as he is likely less well informed than Laney
<Laney> apw: see webcontrol/request.cgi running()
 * Laney wants a release/tools sprint to have some clear time to work on all this stuff
<infinity> Laney: I need to plan that.
<Laney> infinity: That'd be peachy
<Elleo> .49
<Elleo> oops
<cjwatson> subscribe
<Laney> Almost half way there
<cjwatson> living on a prayer
<slangasek> did someone change the c-m report emails? I'm now getting email notifications about demotions, which I know I wasn't before
<slangasek> (so is that someone changing the code, or is it snakefruit fallout?)
<bdmurray> tjaalton: For which release did you verify bug 1676845?
<ubot5> bug 1676845 in vlc (Ubuntu Yakkety) "libgles1-mesa is being removed, don't depend on it" [Undecided,New] https://launchpad.net/bugs/1676845
<infinity> slangasek: I didn't change it.  I also have a hard time seeing how it would be fallout from the upgrade, though.
<xnox> slangasek, i believe this has always been the case.....
<infinity> slangasek: I confess that I don't read the mail often enough to know for sure if this is "usual".
<xnox> slangasek, it would be nice to change FROM: address such that i don't get sad, each time i get notification of email with pitti's face
<infinity> slangasek: But I *think* it used to tell me about demotions (though, annoyingly, it claims it's a promotion, because derpy code)
<infinity> in 20
<tjaalton> bdmurray: xenial
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [0.7.9-90-g61eb03fe-0ubuntu1~16.04.1 => 0.7.9-113-g513e99e0-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (yakkety-proposed/main) [0.7.9-90-g61eb03fe-0ubuntu1~16.10.1 => 0.7.9-113-g513e99e0-0ubuntu1~16.10.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<max100> anyone know why rednotebook is no longer in the official repo?
<max100> for zesty to be more specific
<dax> max100: it is.
<dax> oh, no it's not
<dax> sorry, packages.ubuntu.com tricked me
<dax> "Depends on obsolete python-webkit; removed from Debian testing (Debian bug #749259); LP: #1677048"
<ubot5> Debian bug 749259 in rednotebook "rednotebook: depends on python-webkit which is deprecated" [Serious,Open] http://bugs.debian.org/749259
<ubot5> Launchpad bug 1677048 in pywebkitgtk (Debian) "Please remove pywebkitgtk from Ubuntu" [Unknown,New] https://launchpad.net/bugs/1677048
-queuebot:#ubuntu-release- New: accepted php7.1 [sync] (artful-proposed) [7.1.4-2]
<slangasek> bdmurray: I would appreciate queue review of software-properties/yakkety-proposed; and apologies for the synciness, had to be binary copied from security-proposed ppa
-queuebot:#ubuntu-release- Unapproved: pcs (xenial-proposed/universe) [0.9.149-1ubuntu1 => 0.9.149-1ubuntu1.1] (no packageset)
<bdmurray> silly silly syncs
-queuebot:#ubuntu-release- New sync: freebayes (artful-proposed/primary) [1.0.2-1]
<bdmurray> slangasek: I don't see that package in the security PPA anymore. https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa
<slangasek> bdmurray: yes, tyhicks said he removed it from there
<slangasek> hmm
<slangasek> does that break things when it's deleted from source ppa before released from unapproved?
<slangasek> this is ringing a bell :P
<slangasek> well, in this case it's still retrievable from the queue so maybe we're ok
<bdmurray> slangasek: where would I get the package to review the diff if its not in the PPA?
<infinity> bdmurray: https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages?field.name_filter=software-properties&field.status_filter=&field.series_filter=
<infinity> bdmurray: It's still not garbage-collected.
<infinity> bdmurray: Which means queue can find it, and the copy will succeed.  But for a limited time. :P
<bdmurray> slangasek: looks fine to me although a test case is missing
<slangasek> lol checking
<bdmurray> Should I try accepting it via sru-review?
<slangasek> bdmurray: should work as long as you --no-diff
-queuebot:#ubuntu-release- Unapproved: accepted software-properties [sync] (yakkety-proposed) [0.96.24.7.2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (zesty-proposed) [3.22.7-0ubuntu3.17.04.1]
<slangasek> bdmurray: test case added if you want to give that eyeballs
<bdmurray> slangasek: sure, why did it go through the security ppa? because it'll end up in -security?
<slangasek> bdmurray: yes - since per our discussion I understand unattended-upgrades only pulls new packages in from -security, not from -updates
<slangasek> (new dependencies)
<infinity> Err, no.
<bdmurray> only pulls in new dependencies (from anywhere) when the update comes from -security
<slangasek> infinity: unattended-upgrades, not update-manager
<infinity> By default, unattended-upgrades only upgrades from security.
<infinity> New deps, however, can happen in any pocket you've configured it to look at.
<infinity> Which is, by default, release and security, but if you ask it to update updates, that'll work fine too.
<infinity> slangasek: Yes, I can read. :)
<infinity> See Unattended-Upgrade::Allowed-Origins
<infinity> The bug that was fixed there was that we used to not allow the release pocket, so new deps added would not work unless they were also in the allowed pocket.
<slangasek> ah
<infinity> Now, we default to allowing release and security.  But if you've configured unattended-updates to do updates, it'll obviously do that too.
<bdmurray> bug 1624641 is the change I'm thinking of
<ubot5> bug 1624641 in unattended-upgrades (Ubuntu Yakkety) "security updates with a new dependency don't get installed" [High,Fix released] https://launchpad.net/bugs/1624641
<infinity> bdmurray: Yeahp, that's the one I'm describing above.
<slangasek> infinity: so, if this is not actually a security update, there should be no need to put it into security pocket to get the behavior we want
<infinity> slangasek: Right.
<slangasek> we can just put it in -updates, and people will get it when they apply updates, whether that's unattended-upgrades or update-manager or feta
<slangasek> "Hello Vague"
<infinity> slangasek: Unless you believe it's something users of the security pocket should just want, regardless, which can be argued for functional updates sometimes, when they have a positive impact on future security updates.
<infinity> But if you feel that, I'll let you talk it out with the security czars. :)
<slangasek> infinity: ok.  so when all is said and done, doing this in the security ppa was pointless but not harmful; and we can publish it to -updates only (along with binary copies of the perl deps which need promoting to main)
<slangasek> I don't see a reason this needs to be pushed out to security, no
 * infinity nods.
 * slangasek puts a pin in his brain to remember this for next time
<slangasek> https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1672424/comments/21 ftw
<ubot5> Ubuntu bug 1672424 in gnome-software (Ubuntu Zesty) "Cannot install Debian files outside of the repositories" [Critical,Fix committed]
<bdmurray> Okay, I'm on the same page too now.
<bdmurray> slangasek / infinity: however the fix for bug 1681231 we want to go into -security because people upgrading may not -updates enabled correct?
<ubot5> bug 1681231 in cracklib2 (Ubuntu Zesty) "package cracklib-runtime 2.9.2-3 failed to install/upgrade: dependency problems - leaving triggers unprocessed" [High,Triaged] https://launchpad.net/bugs/1681231
-queuebot:#ubuntu-release- Unapproved: cloud-init (zesty-proposed/main) [0.7.9-90-g61eb03fe-0ubuntu1 => 0.7.9-113-g513e99e0-0ubuntu1~17.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<infinity> bdmurray: Possibly, yes.
<infinity> bdmurray: And following up from the above, https://launchpad.net/ubuntu/+source/unattended-upgrades/0.90ubuntu0.1 should have gone to security too, since its intent was to fix security updates. :P
<infinity> (I mean, it fixed both security and updates, but security was the trigger for the bug)
<bdmurray> infinity: oh that's great. is that u-u issue fixable now?
<infinity> The part where people seemed to stop caring after the update hit -updates is another indication that there are probably very few users who actually run security-only.
<infinity> bdmurray: u-u has no compiled binaries, and no versioned deps, so it might be worth a quick chat with security about if they just want the current SRUs copied wholesale to the security pocket.  It should be safe to do so.
<infinity> bdmurray: Or, more conservatively, we could copy the ones that just added the release pocket bit, which would be very safe.
<infinity> mdeslaur: Come have an opinion.
<mdeslaur> yeah, we could copy it over
<mdeslaur> yakkety's 0.92ubuntu1.1 too
<infinity> mdeslaur: I proposed https://launchpad.net/ubuntu/+source/unattended-upgrades/0.92ubuntu1.1 for yakkety and https://launchpad.net/ubuntu/+source/unattended-upgrades/0.90ubuntu0.1 for xenial as minimal impact.  There are later SRUs, but they aren't about this thing.
<infinity> mdeslaur: If that's cool with you, I'll do the copies right now.
<mdeslaur> infinity: sure, if there are no binaries, etc...you can just copy it over
<mdeslaur> infinity: yep, cool
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (yakkety-security/main) [0.92ubuntu1.3 => 0.92ubuntu1.1] (desktop-core, ubuntu-server) (sync)
<infinity> 0.92ubuntu1.3 => 0.92ubuntu1.1 ... Really?
<infinity> Well job, queuebot.
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (xenial-security/main) [0.90ubuntu0.4 => 0.90ubuntu0.1] (desktop-core, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [sync] (xenial-security) [0.90ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [sync] (yakkety-security) [0.92ubuntu1.1]
<infinity> mdeslaur, bdmurray: ^--- Both done.
<mdeslaur> thanks
<infinity> mdeslaur: Though, again, as I said, the fact that no one complains when we miss things like this really makes me wonder if "security-only" users are a myth.
<infinity> I think if I had a time machine, I'd just scrap the concept and have one post-release updates pocket.
<infinity> Especially given that we also decided somewhere along the way to pull SRUs into security over time.
<slangasek> infinity: your queuebot has been replaced by Q*bert, HTH
<bdmurray> infinity: ack, thanks
<slangasek> right, now I've got a fancy test case but no yakkety install to run it on.  What's the fastest way nowadays to go from zero to installed yakkety desktop in a VM?
<infinity> slangasek: Download an ISO?
<slangasek> tedious
<infinity> slangasek: Assuming you want a real desktop, not just a chroot to piss around in.
<slangasek> I have to install it!
<mdeslaur> infinity: it would be nice to kill it....we've gotten perhaps 2 or 3 bugs about something not working for -security only users in the past
<nacc> heh, i've often resorted to iso and virt-manager. Then make a copy of the image
<mdeslaur> infinity: maybe we can discuss killing it before the next lts
<slangasek> infinity: needs to be a desktop, I need to run Software & Updates
<slangasek> oh technically I don't need to install, do I, I could just do this from the livecd
<slangasek> infinity: you're a genius, thanks
<infinity> slangasek: Yeah, then "dd if=/dev/zero of=disk.img bs=10M count=2000 conv=sparse && kvm -m 2G -hda disk.img -cdrom yakkety-desktop.iso" and wait around a bit? :P
<infinity> slangasek: Oh, or from the livecd, if it's testable in the live env.
<infinity> mdeslaur: It'd be an interesting discussion to have, but it might just be one of those things we're stuck with at this point.
<infinity> mdeslaur: Also, the (now default) "only install security updates automatically, but let me install other updates manually" thing is divided across pockets, since that's easy, it would require a rethink if we killed the security pocket.  Like somehow tagging packages with security fixes in Packages or some out-of-band source that apt and friends consume.
<infinity> mdeslaur: Which is actually sort of a cool concept, but work.  And we all love work.
<mdeslaur> hrm, and some of those may require other packages that weren't tagges as security
<mdeslaur> yeah, ok, it's a bit more complicated than I thoght
<mdeslaur> wow, I can't type today
<infinity> Well, that's not really a problem.  If you tell apt to install foo and bar because they're security updates, it'll happily pull baz as an extra dep even if it's not.
<infinity> But yeah.  It's not trivial to remove the security pocket and still have a concept of "this upload contains a security fix" in a way that automated tools can consume.
<mdeslaur> you're assuming that all the required dependencies actually got bumped manually or automatically
<infinity> The most naive implementation would be a "Security-Updates: CVE-1234 LP1234 BTS1234" header, and if it exists, we act on it.
<mdeslaur> no?
<infinity> mdeslaur: Hrm?  I don't follow.
<mdeslaur> if the nss security update was built with a newer nspr from -updates, but nobody added a explicit version bump, or the symbols file didn't change...
<infinity> mdeslaur: If you apt-get update and there are 34 updates, but 5 have a Security-Update header, apt-security (or whatever) marks those 5 for install, and then attempts an install, which will automatically resolve if two more packages are also needed, despite not having the header.
<mdeslaur> then installing the nss security update wouldn't automatically pull in the newer nspr
<infinity> mdeslaur: Then that's a bug.  Period.
<mdeslaur> yeah, but it happens _all the time_
<infinity> mdeslaur: That same bug could exist in any SRU, and shouldn't.
<infinity> Also, if there's a symbols file, there shouldn't be a bug.
<infinity> But I'll assume you meant that there wasn't one.
<infinity> Or, I guess, that it has the wrong versions, because someone's using dpkg-gensymbols in slacker mode.
<infinity> Now *that's* something I'd like to stamp out.
<mdeslaur> happens all the time, ie: debian bug 820565
<ubot5> Debian bug 820565 in src:nspr "nspr: bump minimum PR_*printf version in .symbols to 4.10.9" [Wishlist,Fixed] http://bugs.debian.org/820565
<infinity> How is that wishlist?
<infinity> mdeslaur: But yes, point made.  It's an issue.  I don't really see it as an issue that affects security any more than other SRUs except that we'd be trying to cherry-pick security updaes, which might magnify it.
<infinity> mdeslaur: Anyhow, all totally a hypothetical, since I think if we float "hey, let's kill the security pocket and redesign this mess", all of us who aren't super keen on doing a ton of work for a potentially minimal gain will opt for beer instead.
<mdeslaur> right, automatically installing security update would probably trigger it a lot more...for SRUs, people are probably just installing all updates, so it doesn't happen frequently
<mdeslaur> oh, beer *drool*
<infinity> See?
<mdeslaur> what were we talking about? oh right, beer.
 * sbeattie works on an emrgency beer update
 * apw wonders why he is being highlighted repeatedly, oh beer
<infinity> Hah.
<mdeslaur> :)
<sbeattie> apw: such a better choice then me being highlighted for security...
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (trusty-proposed/universe) [20160930-0ubuntu3~14.04.2 => 20160930-0ubuntu6~14.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: grub2 (artful-proposed/main) [2.02~beta3-4ubuntu3 => 2.02~beta3-4ubuntu3] (core)
<bdmurray> slangasek: line 8 of the test case in bug 1679784 talks about using update-manager but that'd install all of -proposed. I usually just recommend using apt and installing the specific packages.
<ubot5> bug 1679784 in software-properties (Ubuntu Xenial) "Changing from Xorg video driver to NVIDIA driver using Software & Updates does not display debconf prompt" [Critical,Confirmed] https://launchpad.net/bugs/1679784
<slangasek> bdmurray: yes, I'm asking for update-manager specifically because I want to confirm correctness of behavior w/ u-m
<bdmurray> slangasek: okay. could you replace yakkety with zesty in sru-review?
<slangasek> bdmurray: done
<bdmurray> caribou: Do you have an upstream PR for the fix for bug 1654600?
<ubot5> bug 1654600 in unattended-upgrades (Ubuntu Zesty) "unattended-upgrade-shutdown hangs when /var is a separate filesystem" [High,In progress] https://launchpad.net/bugs/1654600
<slangasek> bdmurray: fwiw I'm self-verifying this one in a VM, so if u-m + -proposed does eat the VM afterwards I don't care ;)
<bdmurray> slangasek: I just like to pretend that people other than us developers do verifications.
<nacc> dream a little dream, bdmurray
<Bashing-om> Me as a lowly user, just break things :)
<tsimonq2> slangasek: Ack, thanks.
<bdmurray> nacc: lol
-queuebot:#ubuntu-release- Unapproved: grub2 (artful-proposed/main) [2.02~beta3-4ubuntu3 => 2.02~beta3-4ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (zesty-proposed) [0.93.1ubuntu2.1]
<jbicha> bdmurray: I replied on LP: #1685803
<ubot5> Launchpad bug 1685803 in gnome-calendar (Ubuntu Zesty) "Update gnome-calendar to 3.24.1" [High,In progress] https://launchpad.net/bugs/1685803
<bdmurray> jbicha: okay, in a meeting
<cyphermox> could someone please review my grub2 upload in the artful queue?
<slangasek> bdmurray: I notice binutils seems to not be making it to yakkety-updates, presumably because of the failing linux autopkgtests; but the linux autopkgtests are flaky.  Would you mind looking at whether that's releasable?
<bdmurray> slangasek: systemd too then?
<bdmurray> it also is blocked by linux autopkgtests
-queuebot:#ubuntu-release- Unapproved: accepted gnome-calendar [source] (zesty-proposed) [3.24.1-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: rejected golang-context [source] (zesty-proposed) [1.1-1ubuntu9]
-queuebot:#ubuntu-release- Unapproved: rejected golang-github-mattn-go-colorable [source] (zesty-proposed) [0.0.6-1ubuntu6]
-queuebot:#ubuntu-release- Unapproved: rejected golang-github-pborman-uuid [source] (zesty-proposed) [0.0+git20150824.0.cccd189-1ubuntu8]
-queuebot:#ubuntu-release- Unapproved: rejected golang-gopkg-flosch-pongo2.v3 [source] (zesty-proposed) [3.0+git20141028.0.5e81b81-0ubuntu8]
-queuebot:#ubuntu-release- Unapproved: rejected golang-goprotobuf [source] (zesty-proposed) [0.0~git20161116.0.224aaba-3ubuntu2]
-queuebot:#ubuntu-release- Unapproved: rejected golang-x-text [source] (zesty-proposed) [0.0~git20161013.0.c745997-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: rejected golang-github-gosexy-gettext [source] (zesty-proposed) [0~git20130221-0ubuntu13]
-queuebot:#ubuntu-release- Unapproved: rejected golang-gocapability-dev [source] (zesty-proposed) [0.0~git20150716.0.2c00dae-1ubuntu8]
-queuebot:#ubuntu-release- Unapproved: rejected golang-petname [source] (zesty-proposed) [2.6-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: rejected golang-github-olekukonko-tablewriter [source] (zesty-proposed) [0.0~git20151029.0.a5eefc2-1ubuntu7]
-queuebot:#ubuntu-release- Unapproved: rejected golang-yaml.v2 [source] (zesty-proposed) [0.0+git20170125.0.4c78c97-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: rejected golang-gopkg-lxc-go-lxc.v2 [source] (zesty-proposed) [0.0~git20161126.1.82a07a6-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (yakkety-proposed) [0.92ubuntu1.4]
<slangasek> bdmurray: likely :)
<slangasek> bdmurray: thanks
<bdmurray> slangasek: I'm confused about "3. Install binutils and gcc-5 from -proposed." in bug 1623418 as the gcc-5 tasks are New
<ubot5`> bug 1623418 in gcc-5 (Ubuntu Xenial) "gcc-as-needed.diff patch broke mpx support in GCC" [Medium,New] https://launchpad.net/bugs/1623418
<slangasek> bdmurray: ah.  I don't have more details; perhaps the v-done tag should be removed?
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (xenial-proposed) [0.90ubuntu0.5]
<slangasek> bdmurray: fwiw I've confirmed that the packages /show up/ correctly in update-manager, though the actual install on top of 16.10 ISO wants to pull down 461.3MB... so I think I'll verify that I don't get any errors calculating the upgrade, then abort and install by hand
<slangasek> oops, I did get an error, 'not enough free space' on the livecd
<slangasek> bdmurray: do you think the above is close enough, or should I go through the trouble of installing off of the CD?
<bdmurray> slangasek: that's the software-properties bug?
<slangasek> yes
<bdmurray> I've a VM that I could do that with that won't run out of space.
<slangasek> ok, up to you
<slangasek> I also just realized I could unselect packages in u-m :P
<bdmurray> That would be better
<slangasek> ok, rebooting and trying that
<bdmurray> I think there's even a select all and select none
<bdmurray> slangasek: Oh hey, how does bug 1389582 fit into this?
<ubot5`> bug 1389582 in software-center (Ubuntu) "software-center misses a dependency on libgtk2-perl" [High,Triaged] https://launchpad.net/bugs/1389582
<slangasek> uh... probably fits in somewhere :P
<slangasek> bdmurray: this is proving more difficult than expected; the VM is refusing to boot back to ubiquity >_<
<slangasek> bdmurray, infinity: lib{gtk,cairo,glib,pango}-perl copied to {trusty,xenial,yakkety}-updates and promoted to main, though
<slangasek> ah, there's a splash screen
<slangasek> bdmurray: v-done \o/
<slangasek> suppose I should prep the SRU for trusty+xenial also
<bdmurray> keep the momentum!
-queuebot:#ubuntu-release- Unapproved: software-properties (xenial-proposed/main) [0.96.20.6 => 0.96.20.7] (desktop-core, ubuntu-server)
 * nacc uploads php-defaults to switch default php to 7.1
<nacc> slangasek: i also uploaded some changes to remove explicit dependencies on src:php7.0 binaries rather than the ones from php-defaults
 * slangasek nods
<nacc> fixing two b-d on php7.0 and then i think we'll be able to demote and remove src:php7.0
<nacc> i synced with ondrej on this too, so we're not diverging from debian in any signficant way
-queuebot:#ubuntu-release- Unapproved: software-properties (trusty-proposed/main) [0.92.37.7 => 0.92.37.8] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted php7.0 [source] (zesty-proposed) [7.0.18-0ubuntu0.17.04.1]
<slangasek> cyphermox: reviewing grub2 in unapproved mostly for the uefi-signed aspect rather than the code aspect, but just checking on the way through, is the Signed-off-by in debian/patches/grub-install-extra-removable.patch still accurate?
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (artful-proposed) [2.02~beta3-4ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (artful-proposed) [2.02~beta3-4ubuntu3]
<slangasek> smoser: did you happen to prepare software-properties 0.96.20.6 using usd?  The autopkgtest failures appear to be a real regression, due to the disappearance of the empty directory tests/aptroot/etc/apt/apt.conf.d/ from the source package
<slangasek> which seems like a pretty gittish thing to happen
<slangasek> nacc, rbasak: ^^
<nacc> slangasek: hrm, i'll wait to see how smoser prepared the upload
<rbasak> I agree it does sound like git.
<rbasak> If it does turn out to be this, I wonder what we should do about it.
-queuebot:#ubuntu-release- Unapproved: rejected software-properties [source] (xenial-proposed) [0.96.20.7]
<slangasek> I don't recall if there's a way to force inclusion of empty dirs in git
<nacc> slangasek: so i just did a `pull-lp-source software-properties` which grabbed 0.96.24.13 and that directory doesn't seem to exist?
<slangasek> nacc: well, but it does exist in the xenial-updates version of the package
<slangasek> which is the one that had passing autopkgtests
<nacc> ah
<nacc> sorry, i missed that context
-queuebot:#ubuntu-release- Unapproved: software-properties (xenial-proposed/main) [0.96.20.6 => 0.96.20.7] (desktop-core, ubuntu-server)
#ubuntu-release 2017-04-28
<slangasek> bdmurray: the above means that AFAICS software-properties currently in xenial-proposed has a legit autopkgtest regression, which *should* be fixed in my new upload of software-properties 0.96.20.7 just now.  I would suggest either accepting 0.96.20.7 over 0.96.20.6 and shepherding it through without requiring reverification of the other SRU bugs, or else releasing 0.96.20.6 with a known
<slangasek> autopkgtest regression with the expectation that this is fixed in 0.96.20.7.  what do you think?
<bdmurray> To avoid confusion with releasing 0.96.20.7 I'd say accept 0.96.20.6 into -updates now.
<solarce> is there an ETA for when precise will show up old-releases and stop showing up on archive?
<nacc> slangasek: ack, i can confirm the importer for lpusip/import/0.96.20.5 does not show any tests/aptroot/etc/apt/apt.conf.d but `pull-lp-source` of the same does
<nacc> slangasek: will debug first thing tmrw
<rbasak> nacc: not much to debug I think. git doesn't track empty directories. There's no representation for that.
<rbasak> We definitely need a bug on it.
<rbasak> https://git.wiki.kernel.org/index.php/GitFaq#Can_I_add_empty_directories.3F
<rbasak> And figure out how we can manage this.
<rbasak> Perhaps we need to add that support to git. Their FAQ suggests it's doable (just difficult).
<nacc> ah i see, you add a .gitignore in the empty dir to make it not empty
<bdmurray> you add a .gitignore so its not ignored?
<nacc> bdmurray: yeah, it basically makes it non-empty any longer
<nacc> bdmurray: it's a bit of a kludge
<bdmurray> yes
<nacc> rbasak: you're right, and we don't want to contentfully hcange the srcpkg; but wouldn'thave dpkg-buildpackage have complined about the deletion?
<nacc> it might have been just a warning, but wouldn't it have said something?
<solarce> .gitkeep is also common http://www.ryanwright.me/cookbook/git/gitkeep
<nacc> solarce: ah interesting, thanks!
<rbasak> software-properties is a native package
<nacc> rbasak: oh right
<solarce> nacc: np!
<rbasak> But the same bug could occur in debian/ in a non-native package. Or in a non-native < 3.0 package.
<nacc> rbasak: yep
<nacc> rbasak: should we have the importer at least fail for now on packages containing empty directories?
<nacc> rbasak: rather than falsely successfully import them
<rbasak> Agreed
<rbasak> If the problem is the index, we may be able to work around in the importer by manually constructing the tree object
<rbasak> Oh, but usually that goes through the index. Hmm. In any case, that might still break user tooling when working with the repository.
<nacc> rbasak: would `find . -type d -empty` as we import be sufficient?
<rbasak> I think so, yes.
<nacc> rbasak: ok, i'll play with it tmrw
<nacc> slangasek: thanks for finding the bug! :)
<nacc> rbasak: probably something like: http://paste.ubuntu.com/24469989/
<slangasek> nacc: cool, thank you!
<slangasek> bdmurray: ok, sru-releasing 0.96.20.6 now if you haven't already
<nacc> rbasak: yeah with that, the import spits out an error immediately (with --no-fetch)
<nacc> i wonder what dgit does with that srcpkg
<cyphermox> slangasek: he did the most part of the original code, I just shuffled things around a bit (and did send him a copy for review, but I got no response yet)
<slangasek> solarce: precise is not being removed from archive, since Canonical is continuing to provide (paid) security support for it: https://insights.ubuntu.com/2017/03/14/introducing-ubuntu-12-04-esm-extended-security-maintenance/
<slangasek> cyphermox: ok, so currently not actually signed-off-by :)
<solarce> slangasek: oh nice, we (Travis CI) assumed the "usual" move to old-releases, that means less work for us, thanks!
<cyphermox> not totally
<nacc> slangasek: yeah, i think it's a bug in dgit too :)
<nacc> so we're not worse, at least!
<rbasak> nacc: yeah that's fine for now.
<rbasak> Meanwhile, I've been testing.
<tsimonq2> slangasek: My understanding was that it would just continue to be updated in a private repository, but it would continue to exist just as any other EOL release does/
<tsimonq2> ?
<rbasak> git _can_ represent an empty directory internally.
<rbasak> If I construct the tree object manually.
<rbasak> However, the index cannot represent it, and thus it doesn't get checked out as empty, nor does git status see anything about it, nor does stuff like "git reset --hard" see it.
<slangasek> solarce: it will /also/ be available from old-releases fairly soon
<slangasek> so you'll have a nice long transition window
<nacc> rbasak: i see
<rbasak> So we could fix the importer and call it a "client problem" bug for now. Then at least the imported trees will be correct, awaiting a future client-side tooling fix.
<slangasek> tsimonq2: updates in a private repository; existing packages kept on archive.u.c (at least for right now) so that no rejiggering of other sources.list entries required
<rbasak> And then we could move the warning client side for now.
<solarce> slangasek: stellar, thank you for the updates
<rbasak> "usd clone" could look for these, create the empty directories and leave .gitignore files inside them for example.
<solarce> and all the hard work, we definitely benefit from it <3
<rbasak> And "usd build" could reconstruct it.
<nacc> rbasak: right, i see that
<rbasak> (in case git has lost them)
<slangasek> solarce: sure thing.  sorry, someone (maybe you?) pinged me directly on irc a couple of weeks ago but was gone before I came online in the morning
<rbasak> Oh.
<rbasak> But when a new tree is constructed from the index (ie. when you commit), that new tree object will have lost the empty directory again.
<solarce> slangasek: that was Carmen from my team, no worries, timezones and being busy is the usual
<rbasak> So this really is quite broken at the client side end and I don't see an easy workaround that allows a developer to use git and not lose the empties.
<nacc> rbasak: yeah, it feels like a bit of a mess
<nacc> rbasak: ian might have some ideas
<nacc> i'll file a bug against dgit to let him know tmrw
<rbasak> Good idea, thanks.
<solarce> slangasek: we're putting our precise stuff into maintenance mode and getting full steam ahead on finishing trusty and hopefully xenial by the end of the year
<solarce> anywho, thanks again, headed out for now
<slangasek> I like component-mismatches reports much better now that I've trimmed down duplicate data points in the svg and it no longer takes 100MB to render them
<slangasek> juju-mongodb3.2, another good example of where using p-m for SRUs would help... ignored because FTBFS but the FTBFS aren't regressions
<tsimonq2> slangasek: ack
<infinity> nacc: Can you subscribe ~ubuntu-server to php7.1 bugs as was the case for php7.0?
<slangasek> infinity, nacc: oops, let me do that, since I did the maining
<infinity> slangasek: If you can?
<slangasek> (done)
<slangasek> infinity: you don't know about bdmurray's LP backdoor?
<infinity> slangasek: Apparently not.
<slangasek> turns out the api doesn't block you from subscribing teams you're not part of to package bugmail ;)
<infinity> Fun.
<infinity> The UI requires you to be an admin.  I didn't realise that constraint was UI level. :P
<infinity> (I'm a member... The longest member on the team, in fact)
<slangasek> :-)
-queuebot:#ubuntu-release- Unapproved: openssl (yakkety-proposed/main) [1.0.2g-1ubuntu9.1 => 1.0.2g-1ubuntu9.2] (core)
-queuebot:#ubuntu-release- Unapproved: openssl (zesty-proposed/main) [1.0.2g-1ubuntu11 => 1.0.2g-1ubuntu11.1] (core)
-queuebot:#ubuntu-release- Unapproved: openssl (xenial-proposed/main) [1.0.2g-1ubuntu4.6 => 1.0.2g-1ubuntu4.7] (core)
-queuebot:#ubuntu-release- New binary: gzip [amd64] (artful-proposed/main) [1.6-5ubuntu1] (core)
-queuebot:#ubuntu-release- New: accepted freebayes [sync] (artful-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted gzip [amd64] (artful-proposed) [1.6-5ubuntu1]
<slangasek> nacc: looks like the usual sorts of autopkgtest failures to unwind for php-defaults
-queuebot:#ubuntu-release- New binary: freebayes [amd64] (artful-proposed/none) [1.0.2-1] (no packageset)
<caribou> bdmurray: yes, I sent a slightly adapted debdiff to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809669
<ubot5`> Debian bug 809669 in unattended-upgrades "unattended-upgrades: files got created under /var/ mountpoint" [Critical,Open]
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.24.1 => 2.25] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (zesty-proposed/main) [2.24.1+17.04 => 2.25+17.04] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.24.1+16.10 => 2.25+16.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.24.1~14.04 => 2.25~14.04] (no packageset)
 * apw reviews ^
<Laney> anyone waiting for anything pre-autosync?
 * Laney stares at cron
 * rbasak believes cron is probably waiting for _something_ :-P
<apw> it is waiting till you look away, so it can run whatever you are waiting for
<Laney> it's waiting for someone to remove --dry-run :P
<infinity> Laney: I'm going to remove it after I wake up and refresh the chroots.
<smoser> slangasek, i possibly did. but not sure. https://code.launchpad.net/~smoser/software-properties/trunk.lp1532855/+merge/318132
<smoser> where is the error you were pointing at (/me realizes both slangasek and nacc are west coast)
<rbasak> o/
<rbasak> smoser: it was in your upload to Ubuntu rather than in upstream. Did you use the git importer stuff to prepare that?
<rbasak> In any case I'm pretty certain it's a bug in our git stuff.
<rbasak> git cannot represent empty directories. So the importer will have dropped it, not you.
<rbasak> s/cannot represent/cannot manage/
<smoser> its more than likely.
<smoser> in that i use usd anywhere i can, and i suspect i had nacc import that so i could use it :)
<smoser> what was the regression though ? is there a bug for that ?
<smoser> and is there a bug against usd-importer ?
<rbasak> The regression was that it broke a dep8 test. I believe slangasek fixed it up already with a fixed upload/accept.
<rbasak> nacc was going to file a bug against usd-importer, but I don't see one yet.
<rbasak> He said he'd do it today.
<rbasak> In the short term we'll just have the importer break if it sees an empty directory. So at least we won't be importing bad data.
<rbasak> Medium term we can have the importer import the right thing, since internally git can represent an empty directory. The problem is at the porcelain/index level only. So then the importer would continue, but client-side devs would still drop it without realising.
<rbasak> Then we'd have to have "usd clone" detect and warn or break if it spots any empty directories.
<rbasak> Long term I think the only sensible way to fix this is to fix git. It does sound like upstream will accept the fix; it just needs the work done.
<smoser> i dont see the upload though for software properties
<rbasak> https://launchpad.net/ubuntu/+source/software-properties/0.96.20.6
<rbasak> IIRC, .5 was the broken upload, which slangasek replaced with .6.
<smoser> "uploaded by Scott Moser" ?
<rbasak> Though .6 is supposedly signed by you? That's odd.
<rbasak> Oh.
<rbasak> .6 is the broken one.
<rbasak> 0.96.20.7 is in unapproved.
<rbasak> <bdmurray> To avoid confusion with releasing 0.96.20.7 I'd say accept 0.96.20.6 into -updates now.
<rbasak> bdmurray, slangasek: so are we reviewing/accepting 0.96.20.7 without an SRU bug?
<rbasak> (I mean that's fine, if that's the plan, just checking if it is)
<Odd_Bloke> tjaalton: slangasek: You're the two people on the SRU rota for today, would you be able to take a look at gce-compute-image-packages in the trusty queue?
<Odd_Bloke> (Thanks in advance!)
<tjaalton> Odd_Bloke: the debdiff doesn't look complete?
<tjaalton> or, were some of the changes already in 0ubuntu3~14.04.2?
<bdmurray> caribou: Okay, I looked in github for it.
<tjaalton> looks like it
<caribou> bdmurray: ah, sorry I thought you meant debian
<tjaalton> Odd_Bloke: there's no SRU bug in the changelog entry
<caribou> bdmurray: I'll prepare a PR for it next week
<bdmurray> rbasak: 0.96.20.7 dos have an SRU bug.
<bdmurray> rbasak: http://launchpadlibrarian.net/317339072/software-properties_0.96.20.6_0.96.20.7.diff.gz
<rbasak> Oh, OK. And we're restoring the directory in it as well?
<rbasak> IMHO, that should be changelog noted, but never mind.
<Odd_Bloke> tjaalton: My assumption was that a bug's presence in the new entries would be sufficient; does it also need to be in the backport-specific stanza?  (https://bugs.launchpad.net/ubuntu/+source/gce-compute-image-packages/+bug/1664949 is in the backported changelog entries.)
<ubot5`> Ubuntu bug 1664949 in gce-compute-image-packages (Ubuntu Trusty) "Daemons do not log output to serial console" [Undecided,In progress]
<Odd_Bloke> I guess my assumption is very opaque to the user.
<Odd_Bloke> tjaalton: Could you reject it and I'll re-upload?
<tjaalton> Odd_Bloke: yep
<tjaalton> at least the tools complain about this
<rbasak> Odd_Bloke: note that the rich history adoption by the importer currently races the SRU queue. Quite suboptimal right now, sorry :-/
<tjaalton> so I think it wouldn't add the template entry to the bug
<rbasak> Odd_Bloke: the importer will look for an upload tag in its repository at import time, which will be shortly after queue accept time. But currently there's no way for uploaders to push there directly :-/
<rbasak> nacc or I have to manually do it.
<rbasak> If the upload tag arrives late, then IIRC it'll currently be ignored. In the future we want it to be noted (with git-notes) but it won't be accepted into the DAG.
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (trusty-proposed/universe) [20160930-0ubuntu3~14.04.2 => 20160930-0ubuntu6~14.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: rejected gce-compute-image-packages [source] (trusty-proposed) [20160930-0ubuntu6~14.04.0]
<tjaalton> Odd_Bloke: I need to run out now :/
<Odd_Bloke> tjaalton: No worries; just pushed up the fixed package.
<Odd_Bloke> Get to it when you can.
<slangasek> how often is MoM supposed to refresh?
 * apw is seeing build failures caused by dpkg-genbuildinfo trying to read _all packages on not amd64
<cjwatson> slangasek: half-hourly or so, but it was crashing on something, I've been trying to hit it over the head today
<slangasek> cjwatson: ok, cheers
<cjwatson> it has some hateful failure modes
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (zesty-proposed) [2.25+17.04]
<slangasek> alas, poor yorick, your autopkgtests fail
<slangasek> so... runs under xvfb-run, sometimes creates X windows, sometimes fails. ok then
<Laney> worked pretty well in zesty
<jdstrand> infinity: hey, does dput need updates for .buildinfo? I see .buildinfo is in my source.changes file, but I tried an upload to artful (from zesty host) and got:
<jdstrand> GPG verification of /srv/launchpad.net/ubuntu-queue/incoming/upload-ftp-20170427-181152-004277/ubuntu/apparmor_2.11.0-2ubuntu5_source.buildinfo failed: Verification failed 3 times: ["(7, 58, u'No data')", "(7, 58, u'No data')", "(7, 58, u'No data')"]
<slangasek> I wouldn't expect a .buildinfo file in a source upload
<slangasek> maybe that's a broken dpkg/
<mapreri> dpkg-buildpackage always produces .buildinfo, by design.  also in source builds.
<jdstrand> slangasek: so source.changes shouldn't have .buildinfo in it?
<slangasek> jdstrand: well, see what mapreri says
<mapreri> another question is how you got one from a zesty host?
<slangasek> I don't understand that as a 'design'
<jdstrand> mapreri: I built in an artful schroot. upload from a zesty host
<mdeslaur> jdstrand: you need to install devtools from artful to get .buildinfo signing
<jdstrand> ah
<mapreri> the idea is that you produce always a .buildinfo, and then do a source-only build including a .buildinfo produced by a binary build.  but why in a source-only build with a source-only .changes a buildinfo can be useful, it escapes me too.
<mdeslaur> err, not devtools
<mapreri> devscripts*
<mapreri> i.e. debsign, if you are using that to sign.
<mdeslaur> yeah, devscripts
<mdeslaur> sorry, brainfrat
<mdeslaur> brainfart
<mapreri> but so launchpad forces .buildinfo to be signed correctly?
<mapreri> (dak doesn'tâ¦)
<cjwatson> it does at the moment yet
<cjwatson> *yes
<mapreri> well, keep it that way :)
<cjwatson> from the discussion yesterday I thought that we should probably SRU the devscripts changes to sign buildinfo if present
<mapreri> possibly
<mapreri> it would make senes
<mapreri> also dscverify
<rbasak> It alarms me a little to hear that by default a source only upload will also leak details of my local environment. That isn't something I'd expect.
<mapreri> what are you thinking about?
<mapreri> installed packages and their versions?
<rbasak> dpkg-buildpackage -S, followed by dput?
<rbasak> installed packages and their versions> right.
<mapreri> well, you should be building also the sources in a clean environment, imho, not just the binariesâ¦
<rbasak> Also from an engineering perspective, I'd expect that uploading the same source tree should result in the same upload and behaviour in Launchpad (or dak I guess) regardless of my environment.
<rbasak> mapreri: why? I use git to make sure my source tree is clean.
<mapreri> I found git trees containing files that should not be uploaded, correctly cleaned by `debian/rules build`.
<rbasak> "Buliding" the sources shouldn't be a thing.
<mapreri> err
<mapreri> `debian/rules clean`
<jdstrand> mdeslaur: that seemed to work. thanks! :)
<jdstrand> infinity: nm
<rbasak> "debian/rules clean" is superseded by "git clean" IMHO
<rbasak> I know it isn't by policy.
<rbasak> But "debian/rules clean" may be buggy on a per-package basis.
<rbasak> "git clean" should always work.
<rbasak> (unless the package is buggy, in which case at least "git clean" is and will remain consistent)
<mapreri> then it's a reason to fix it, not ignoring it and just use git :)
<rbasak> Sure I'll fix it if I know about it.
<rbasak> But only because policy says that "debian/rules clean" must exist. I'd advocate dropping it. Tooling/client issue.
<mapreri> cjwatson: btw, debsign underwent quite a lot of changes to support buildinfo, see one of the commits: https://anonscm.debian.org/git/collab-maint/devscripts.git/commit/?id=0b4258b893617d69d0a840da4bf2341299d5afb4
<mapreri> (and there are several followup fixups)
<cjwatson> yeah, I know it went wrong a couple of time
<cjwatson> s
<cjwatson> I'm not sure what the motivation for buildinfo in source-only uploads was; it feels like there probably was one and that it would be useful for somebody to dig it up
<cjwatson> to understand how useful requiring a signature on it is
<nacc> slangasek: ack, on my todo today to clean up
<cjwatson> though speaking of buildinfo I guess I should tackle slangasek's https://bugs.launchpad.net/launchpad/+bug/1686242
<ubot5`> Ubuntu bug 1686242 in Launchpad itself ".changes files reference .buildinfo files that aren't exposed" [Undecided,New]
<mapreri> debian #846164 is the relevant bug.
<ubot5`> Debian bug 846164 in dpkg-dev "dpkg-dev: Have dpkg-genchanges support a source+buildinfo-only upload after a binary build" [Wishlist,Fixed] http://bugs.debian.org/846164
<mapreri> but indeed I can't see any reason to generate a .buildinfo out of a source-only build without any binary artifact generated.
<cjwatson> so that sort of implies that the point of source+buildinfo is that it's describing the binaries you built but didn't upload ...
<mapreri> exactly
<mapreri> the whole goal is that "i build this and I claim those are the hashes.  you now try to build it again yourself, and accept it only if you get the same hashes"
<rbasak> That use case certainly does make sense and seems entirely reasonable.
<mapreri> that's the final dream, anyway.  We are still quite far from that goal.
<rbalint> mapreri: dpkg-buildpackage can fail if build-dependencies in clean target change
<rbalint> mapreri: dpkg-buildpackage -S
<mapreri> rbalint: -eparse
<rbalint> mapreri: dpkg-buildpackage -S can fail if build-dependencies used in d/rules clean target change
<mapreri> rbalint: what do you mean here by "change"?
<rbalint> mapreri: broke :-)
<mapreri> that the clean target modifies the Build-Dependencies list?
<mapreri> or what
<rbalint> mapreri: not the list of build dependencies, but the dependencies themselves
<cjwatson> rbasak: FWIW I've been known to use debian/rules clean to generate bits of the source package; if you must generate debian/control, it's just about the only correct way to do it.  I don't think that part is superseded.
<rbalint> mapreri: like there is an incompatible change in dh-r
<mapreri> rbalint: like a running dpkg process doing stuff at the same time you are running a source build, and happening to be messing with the packages involved?
<cjwatson> rbasak: (not saying that's normally a good idea, but certainly in the past I've felt that it was the least bad answer to the problem at hand)
<mapreri> cjwatson: in those cases I generate that stuff once, and keep it around, and only call the relevant method in d/rules clean only to be sure nothing has changed.
<rbasak> Understood, thanks. The annoying thing about not using -nc is that then you technically need build dependencies installed :-/
<rbasak> Though in that case, perhaps "usd build-source" must necessarily use a chroot? nacc ^
<mapreri> rbasak: I just run -S -d, and install the things only needed for clean, which are usually very few.
<rbasak> mapreri: sure, but I think tooling for general use needs to dtrt even for the edge cases.
<rbasak> So what should our git-based workflow recommend/do by default?
<rbasak> I was hoping to avoid making new contributors set up a chroot.
<rbasak> (by using PPAs for test builds, etc)
<cjwatson> If you can guarantee that the source tree has never been built, then I think -nc is safe
<apw> it now is only safe if you haven't also changed the version number
<cjwatson> why?
<mapreri> rbasak: are you sure you can do anything relevant without having a local chroot for test builds? :|
<apw> (ie don't build -S -nc both sides of it)
<apw> because the new buildinfo leave mess in the tree in debian/files
<rbasak> mapreri: yes, by having Launchpad build it for me.
<cjwatson> ah sure but that's just a bug
<cjwatson> You could pass -nc if the build-dependencies *aren't* satisfied, on the grounds that the user can't then have built it (well, they could have built it in a chroot with the tree bind-mounted, I guess)
<rbasak> I'm trying to make it as easy for drive-by contributors as possible.
<mapreri> rbasak: possibly I'm too grumpy and old-style for that idea :)
<cjwatson> I kind of feel a bit grumpy about encouraging people to regard Launchpad as a test-build service
<cjwatson> Sometimes it's appropriate and sometimes it's abused; it still needs to be easy for people to do test builds locally rather than using a shared and therefore limited resource
<rbasak> One alternative might be to get local building with lxd working better.
<rbasak> My main gripe with sbuild is that it's a massive pain for a new contributor to set up.
<cjwatson> An sbuild lxd session mode would be lovely
<cjwatson> It already has multiple session modes (albeit that one of them is very weird), so it shouldn't be too hard
<mapreri> isn't lxd too painful to set up for drive-by contributions?
<rbasak> "I'm after a one command "here, take this git commit (or even work tree) and give me debs)" with no setup
<rbasak> lxd is trivial to set up, no?
<mapreri> i find pbuilder way way easier to set up
<rbasak> It pretty much Just Works.
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (precise-proposed/main) [1.267.1 => 1.267.2] (core)
<mapreri> then, I'm biased as i'm its maintainer :P
<cjwatson> ("chroot mode" is the jargon I'm looking for in sbuild)
<cjwatson> I'd much rather people be directed towards something that is as close as possible to the software stack used in LP
<cjwatson> lxd is generally pretty easy to set up since it has default image-based workflows
<rbasak> So sbuild has an adt chroot mode now. And adt has a lxd backend. I haven't tried this trickery though.
-queuebot:#ubuntu-release- New source: ubuntu-advantage-script (precise-proposed/primary) [1]
<xnox> slangasek, ^^^^^^
<xnox> both ubuntu-meta and ubuntu-advantage-script are in.
<rbasak> Yeah and lxd also has automatic and sensible by default image management, so we don't have to teach new contributors on keeping chroots up to date, etc.
<slangasek> xnox: as I said, I don't like -script as a package name; even if there happens to only be one script, -script is bad for a name
<xnox> slangasek, i am happy to adjust and fix things; as long as there is authoritative request for a name. I am just a minion, and other minions also did not feel what the right name should be. Hence minions uploaded status quo =)
<dpb1> slangasek: ubuntu-advantage-scripts ?
<dpb1> is that better?
<xnox> slangasek, i object to -scripts because there is only one script so far; if one doesn't count motd snippet =)
<cjwatson> My rule of thumb is to try to explain what it does rather than what it is
<xnox> cjwatson, yeah, but i was not sure if ubuntu-esm would be good enough name or not.
<cjwatson> Just as I don't put language-specific file extensions in program names on the PATH, because nobody cares what language it's in when they're just trying to run it; similarly, nobody cares that it's a script, they care that it enables ESM (or whatever)
<xnox> slangasek, ubuntu-advantage-esm ?
<nacc> rbasak: could be, yes -- it should be on our roadmap i guess
<rbasak> ubuntu-esm-tools? ubuntu-advantage-tools?
<rbasak> ubuntu-advantage would be fine too, as a package that provides ubuntu-advantage -specific functionality, IMHO.
<xnox> rbasak, it's only one script so far that only can enable/disable esm; and should be in add-apt-repository imho, but that's too high level.
<rbasak> "You have ubuntu-advantage installed" makes sense.
<nacc> smoser: rbasak: LP: #1687057
<ubot5`> Launchpad bug 1687057 in usd-importer "git cannot represent empty directories by default" [Undecided,New] https://launchpad.net/bugs/1687057
<nacc> rbasak: since you have a handle on a 'fix', can you assign to yourself?
<rbasak> ack
<slangasek> rbasak: except for the part where UA is also the name of a product and one has this package installed without necessarily being subscribed to the product
<xnox> rbasak, but ubuntu-advantage imho is landscapish functionality to install.
<rbasak> nacc: "could be, yes" - in response to what please?
<rbasak> slangasek, xnox: fair, so ubuntu-esm-tools then?
<dpb1> xnox: well, it's like naming a list variable.  even with one item, plural is better
<slangasek> xnox: 'ubuntu-advantage' was the guidance from dpb1. I think either 'ubuntu-advantage-tools' or 'ubuntu-advantage-scripts' here.
<slangasek> I don't care between them
 * xnox is going away to have starbucks
<dpb1> +1 to either
 * xnox wants a definitive name
<dpb1> tools or scripts
<slangasek> xnox: ubuntu-advantage-tools
<slangasek> done
<rbasak> One day you'll be shipping a go binary instead of a script.
<xnox> preferably elected using a condorcet voting method.
<nacc> rbasak: sorry, in response to modifyin build-source to use lxd or chroot or something else
<rbasak> nacc: OK, thanks. I'll file a bug against usd build-source then.
<xnox> slangasek, ok. i will reupload things as tools.
<nacc> rbasak: thanks
-queuebot:#ubuntu-release- New: rejected ubuntu-advantage-script [source] (precise-proposed) [1]
<rbasak> nacc: bug 1687059
<ubot5`> bug 1687059 in usd-importer ""usd build-source" does not run debian/clean" [High,New] https://launchpad.net/bugs/1687059
<nacc> rbasak: ack, so i think that's what --clean=dpkg-source (dgit's default) is meant to reflect
 * nacc is just reading the manpage a bit more
<nacc> rbasak: i think something like: sbuild -s --no-clean-source --chroot-mode=adt --adt-virt-server=lxd --chroot ubuntu:zesty for a zesty build will work
<nacc> the --no-clean-source seems to be required or it tries to clean the source in the host which will fail without the deps
<rbasak> Nice.
<rbasak> That'll build binaries though right?
<cjwatson> won't that also do a bunch of adtish things?
<rbasak> I do see --no-arch-any and --no-arch-all, which together with --source might work.
<rbasak> cjwatson: how so? I'm not sure I follow. It's just the adt backend we're invoking, right?
<cjwatson> I haven't looked - is it invoking something other than adt-run?
<rbasak> I believe so, yes.
<nacc> cjwatson: testing still so not sure :)
<cjwatson> I guess that's weird but workable then
<nacc> well that failed http://paste.ubuntu.com/24473829/
 * cjwatson would prefer sbuild --chroot-mode=lxd and have it have a reasonable default base image name ...
<rbasak> cjwatson: I would too. But that's not written :)
<nacc> oh i think i see what i did wrong
<nacc> rbasak: this will ... be tricky for the snap though
<nacc> nope, that wasn't it (i thought maybe because i hadn't done an explicit autopkgtest-build-lxd it was failing
<nacc> i will note that technically sbuild doesn't mention lxd only lxc
<rbasak> nacc: snap> yeah :-/
<rbasak> Yeah sbuild doesn't currently directly support lxd at all.
<nacc> well it appears to invoke it (or something) if you tell it to use lxd :) -- but then it errors out because i think it assumes it's able to write somewhere that doesn't exist?
-queuebot:#ubuntu-release- New source: ubuntu-advantage-tools (precise-proposed/primary) [1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (precise-proposed/main) [1.267.1 => 1.267.2] (core)
<nacc> slangasek: looking at src:php-defaults in a-p, i think i'm getting confused, the autopkgtests are running with --apt-pocket=proposed=src:php-defaults, which should only depend on php7.1 versions. reverse-depends shows that src:php7.0 only has rdeps from php-defaults (which get replaced in a-p). So i'm not sure how php7.0* are getting pulled in
<nacc> slangasek: that seems to be the source of the failure(s), though, php7.0-cli but php7.1-xml installed
<slangasek> bdmurray: follow-up comment on https://code.launchpad.net/~vorlon/update-manager/ubuntu-support-optimize/+merge/323363 , further input requested
<slangasek> nacc: looking
<nacc> slangasek: thanks
<slangasek> nacc: manually installing test deps of php-codecoverage as 'sudo apt install php-codecoverage php-xdebug phpunit php7.1-cli php7.0-cli-' shows that php-xdebug needs a rebuild
<nacc> oh! it depends on that symbolic phpapi
<nacc> slangasek: thanks!
<slangasek> nacc: maybe other revdeps, you'd want to look
<nacc> slangasek: great, grep-dctrl-packages found a few more
<nacc> slangasek: thanks again for the pointer
<slangasek> bdmurray: yeah I think fwiw pep8 wants imports sorted alphabetically, but as we're not enforcing that on the project overall I wasn't fussed :)
<xnox> slangasek, new stuff is in the queue.
<Odd_Bloke> I'm guessing tjaalton isn't going to get to it today, so slangasek do you have a minute to accept the gce-compute-image-packages waiting in the trusty queue?
<slangasek> Odd_Bloke: done
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (trusty-proposed) [20160930-0ubuntu6~14.04.0]
<Odd_Bloke> slangasek: Thanks!
<fossfreedom> quick question all - ubuntu budgie dailies appear to being built with the zesty seeds. When do the dailies switch to the artful seeds?
<jbicha> fossfreedom: why do you think it is using the zesty seed?
<fossfreedom> I removed tracker, gnome photos and added gthumb to our artful seeds a couple of days ago.  today's build still has gnome photos, tracker and doesnt have gthumb
<jbicha> fossfreedom: you need to update ubuntu-budgie-desktop
<fossfreedom> ah - wilco roger
<jbicha> gnome-documents also has a hard depends on tracker
<fossfreedom> yep - that has gone as well
<slangasek> bdmurray: https://code.launchpad.net/~vorlon/update-manager/ubuntu-support-optimize/+merge/323363 - pushed, ready for re-review
<bdmurray> fossfreedom: It'd actually be roger wilco but wikipedia says that's redundant. https://en.wikipedia.org/wiki/Voice_procedure#Words_in_voice_procedure
<fossfreedom> lol
<bdmurray> slangasek: no change to the changelog version?
<slangasek> bdmurray: oops, fixing
<slangasek> bdmurray: fixed
<slangasek> bdmurray: except lp was slower than my typing; /now/ fixed
<bdmurray> slangasek: also all the other prints are "print(" <- no space
<slangasek> wah
<slangasek> bdmurray: should I also localize it? :)
<slangasek> I can't see where the pot update happens
<slangasek> heh; open-iscsi autopkgtest takes 18m to succeed, 11h 18m to fail
<nacc> slangasek: hrm, i tried to rebuild src:libguestfs (php7.1 transition) and i get: /bin/sh: 1: /usr/sbin/dpkg-divert: not found. It's in dpkg, though, afaict, and that seems installed in the build. I tried building the current artful version in artful and it also fails. I'm testing locally if the ubuntu4 version succeeds in zesty.
<nacc> slangasek: stacks of timeouts, i guess?
<slangasek> nacc: in zesty, /usr/sbin/dpkg-divert is a symlink to /usr/bin/dpkg-divert.  Possibly a dropped compat symlink. Why is it calling it with a full path?
<slangasek> nacc: yeah, probably. would be nice if it would fail sooner
<nacc> slangasek: not sure :) and i'm not sure what is calling it yet
<nacc> slangasek: yeah, those tests are ... not great on some lvel
<slangasek> nacc: does the dpkg-divert call happen in build or during build-dep install?
<infinity>     - Remove update-alternatives, dpkg-divert and dpkg-statoverride
<infinity>       compatibility symlinks, again.
<infinity> dpkg (1.18.11) unstable; urgency=medium
<nacc> slangasek: looks to be during the build itself
<nacc> from somethig called supermin?
<slangasek> 'tool for building supermin appliances'
<slangasek> which I guess are like supermax appliances but with fewer guards
<nacc> slangasek: might get fixed witha  merge
<nacc> i'll check
<infinity> nacc: Probably, given that supermin and libguestfs have both built on Debian long after that dpkg change.
<nacc> infinity: yeah
<infinity> Though I see no mention of it in either changelog.
<infinity> Oh, found it.
<nacc> 5.1.17-2 ?
<infinity> supermin (5.1.17-2) unstable; urgency=medium
<infinity>   * Add patch so that we do not look for dpkg* in the wrong places
<nacc> yeah
<infinity> Yeah.
<nacc> ok, i'll merge that
<slangasek> nacc: actually I just finished a merge here that I can upload if you like
<nacc> slangasek: oh that'd be great
<nacc> slangasek: fwiw, i think we just have a pile of rebuilds that i just have to do in the right order  for php7.1. I've got the full list now (about 45 packages) and am working through it now
 * slangasek nods
<infinity> I feel like I see some variation of this quote far too often:
<infinity> "On amd64 and x86 architecture it works only by sheer luck."
<nacc> heh
-queuebot:#ubuntu-release- New source: ubuntu-advantage-tools (precise-proposed/primary) [1]
 * infinity glances up.
<infinity> slangasek: ^-- Did people decide against the base-files thing after all, or is that something else?
<slangasek> infinity: yeah, non-base-files
<slangasek> infinity: I think xnox won an argument I didn't care about ;)
<infinity> And is someone going to make this get pulled in on upgrade, or will the instructions be "apt-get install ubuntu-thingee && do-enable-thing"?
<infinity> (I'm totally fine with the latter)
<slangasek> infinity: ubuntu-minimal incoming
<infinity> Oh. :P
<infinity> It's entirely possible to remove minimal from a server by "accident", and I've done it repeatedly.
<slangasek> well, adding it as a new package in the transitive essential set would be a bit much
<infinity> I tihnk the last time I removed minimal, it was because of ureadahead messing with me.
<xnox> infinity, people who remove less don't need a shell script to enable esm repository =)
-queuebot:#ubuntu-release- New: rejected ubuntu-advantage-tools [source] (precise-proposed) [1]
<xnox> and can download https://esm.ubuntu.com/key.asc using your basic token.
-queuebot:#ubuntu-release- New: accepted ubuntu-advantage-tools [source] (precise-proposed) [1]
<infinity> slangasek: Did no one also argue that a tool with a generic name like "ubuntu-advantage" (a product name that refers to a lot more than ESM) might be the wrong name for the binary? :P
<xnox> we have
<infinity> xnox: Yeah, I'm not particularly fussed if people need to install it manually.
<infinity> xnox: The argument for the binary name being wrong fell on deaf ears, I guess?
<infinity> (ubuntu-esm(1) would have made more sense)
<xnox> slangasek, infinity - now shall we refresh the data for the command-not-found to include ubuntu-advantage?
<slangasek> xnox: pass
<infinity> xnox: Ick, no.
 * xnox was kidding
-queuebot:#ubuntu-release- New binary: ubuntu-advantage-tools [i386] (precise-proposed/none) [1] (no packageset)
<infinity> Though, it's trivial to add a single binary to c-n-f-data without rescanning the archive.
<slangasek> infinity: in theory the command may be extended later with other subcommands
<infinity> slangasek: Yeah, I figured that was the counter argument.
<infinity> slangasek: But a package called "foo-tools" implies multiple tools, so u-a-esm would be a good start. :P
 * infinity shrugs.
<infinity> Also, a manpage that says "this must be run as root" in Section 1 is a bit lolz.
<infinity> Ditto for it installing to /usr/bin instead of /usr/sbin
<infinity> But I see you'd accepted anyway. :P
<slangasek> infinity: go ahead and argue for keeping the release open longer in order to fix these issues? :)
<slangasek> it does have subcommands that work as non-root
<infinity> "I'm EOLing today" isn't really the best argument for giving people a free pass on NEW review.
<xnox> infinity, /usr/bin because usr-merge
<infinity> xnox: Eh?
<infinity> xnox: usr-merge isn't bin-sbin merge.
<xnox> infinity, we are working with people who use github web-ui to edit and commit source code
<xnox> infinity, oh, on my books it is =)
-queuebot:#ubuntu-release- New: accepted ubuntu-advantage-tools [i386] (precise-proposed) [1]
<xnox> so choice of /usr/bin was deliberate.
<xnox> by me
<infinity> slangasek: But fair on the "some bits work as non-root".
<slangasek> infinity: it's not a free pass, I'm reviewing it to my usual standards
<infinity> Well, one bit.
<xnox> infinity, the plural instead of singular was debated too. '-script' was weird, and '-tool' is weird too, 'ubuntu-advantage' as package name is weird, as it is paid subscription, rather than something one simply installs.
<slangasek> yes, I didn't want a package name that needs a migration when they add the second tool
<xnox> infinity, i hate that things are in sbin that have informational parts that work as non-root.
<infinity> xnox: Yeah, I like the future-proofiness of "u-a-tools" for the package name.  Just seems silly to not keep said future-proofiness by having the binary clearly purpose-named.
<slangasek> and Ubuntu puts /usr/sbin on the non-root path so the distinction is mostly historic in either direction
<xnox> infinity, to be fair it has *2* scripts, with 4 functions.
<xnox> enable / disable esm
<infinity> Right, bin versus sbin, I'm over.  It does a thing as non-root.
<xnox> you are safe / you need ESM motd generation
<slangasek> so there's another package in NEW for precise-proposed. anyone want nvidia-prime? :P
<infinity> No.  Reject it.
<slangasek> 151 weeks old, how many years is that
<infinity> If no one bugged us about needing it in 151 weeks, I suspect they don't need it on EOL day. ;)
<infinity> Just shy of 3 years.
-queuebot:#ubuntu-release- New: rejected nvidia-prime [source] (precise-proposed) [0.5~hybrid0.0.4]
<nacc> slangasek: were you mentioning open-iscsi re: src:debconf?
<slangasek> nacc: yeah
<nacc> slangasek: it does seem like a real failure (the iscsi root disk logged in and then tried to start a second session)
<nacc> slangasek: but i can't imagine that's debconf's fault :)
<slangasek> how rude
<xnox> slangasek, was the uploader fired before able to nag about that?
<nacc> slangasek: http://autopkgtest.ubuntu.com/packages/open-iscsi/artful/amd64 sort of implies it's still a bad test :)
<slangasek> nacc: yes, flaky at least
<slangasek> it's been running again for 44m, so...
<nacc> slangasek: yeah
<xnox> slangasek, so what about meta accept? =)
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-meta [source] (precise-proposed) [1.267.2]
<slangasek> xnox: why does xserver-xorg-lts-trusty get added where it wasn't before?
<xnox> slangasek, i ran update, and that's what is missing.
<xnox> ... maybe i should not run update.
<slangasek> xnox: right; I'm concerned whether it's actually correct and very wary of making that change right before we close the archive
<xnox> slangasek, shall i back that out?
<slangasek> xnox: maybe we can get infinity to clarify the expected behavior, they were his commits
<infinity> I think what was expected was that meta wouldn't get updated.
<slangasek> well geez
<xnox> i am dputing a meta without -trusty
<infinity> Yeah, well-thought-out, I know.
<xnox> because i want to go afk and drink teah
<slangasek> xnox: thanks
<slangasek> infinity: next you're going to tell me we shouldn't assume the Date in the Releases file will never change
<slangasek> xnox: thanks
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (precise-proposed/main) [1.267.1 => 1.267.2] (core)
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-meta [source] (precise-proposed) [1.267.2]
<infinity> I could back out those commits so ./update works as expected, but easy enough to just do it by hand this one time.
<slangasek> yes
<infinity> trusty will have similar issues.  I'm trying to remember the hysterical raisin for this.  Might have had to do with trying to make point release ISO builds behave sensibly.
<infinity> Though, by xenial, I think I gave up the practice and did it gooder.
<slangasek> hmmmm
<infinity> Well, more differenter.
<slangasek> cyphermox: so the 24-week-old secureboot stack in the precise unapproved queue, that's the old and busted one
<slangasek> I guess we're not getting a new hot one
<slangasek> so we should jettison it
<infinity> It's EOL day, the queues should just be mass rejected.
-queuebot:#ubuntu-release- New sync: kreport (artful-proposed/primary) [3.0.0-2]
<infinity> (except for this ubuntu-advantage thing)
<cyphermox> slangasek: correct.
<slangasek> and the cgroup-lite currently in -proposed?
-queuebot:#ubuntu-release- Unapproved: rejected grub2-signed [source] (precise-proposed) [1.9~ubuntu12.04.11]
-queuebot:#ubuntu-release- Unapproved: rejected shim-signed [source] (precise-proposed) [1.19~12.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected grub2 [source] (precise-proposed) [1.99-21ubuntu3.21]
-queuebot:#ubuntu-release- New sync: kproperty (artful-proposed/primary) [3.0.0-2]
<slangasek> and the two packages in NEW for partner
-queuebot:#ubuntu-release- Unapproved: rejected shim [sync] (precise-proposed) [0.9+1474479173.6c180c6-0ubuntu1]
<infinity> slangasek: Historically, I leave the unverified junk in proposed alone.  It can be archived for posterity as-is.
<slangasek> infinity: and you wouldn't suggest that we, say, get it verified now and promote it and possibly introduce a regression
<infinity> slangasek: Yeah, let's not do that.
<slangasek> just checkin'
<infinity> I mean, I love breaking everyone the day we close the archive and make it impossible to unbreak them, but I'm less in love with being chased by townsfolk with pitchforks.
<infinity> I have sensitive skin.  Pointy things hurt.
<slangasek> infinity: you're looking at it all wrong, think of your commission on the new ESM signups
<xnox> lol
<infinity> slangasek: The S in ESM stands for Security, not Stupidity.  Not sure we're signing up to fix the latter.
<slangasek> huh I thought it was Spaghetti
<infinity> And there's nothing more secure than a system that won't boot.
<dpb1> yummmmm, extended spaghetti
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (precise-proposed) [1.267.2]
<cyphermox> infinity: we rely on that amount of security-through-unbootability
-queuebot:#ubuntu-release- New: rejected navicli [source] (precise-proposed) [7.33.2.0.51-0ubuntu0.12.04.1]
-queuebot:#ubuntu-release- New: rejected vchs-cloudimage [source] (precise-proposed) [0.1.1ubuntu1~12.04.0]
-queuebot:#ubuntu-release- Unapproved: gnome-documents (zesty-proposed/universe) [3.24.0-0ubuntu1 => 3.24.0-0ubuntu1.1] (desktop-extra, ubuntugnome)
<slangasek> hahaha dput refusing to let me upload to an unsupported release
-queuebot:#ubuntu-release- Unapproved: update-manager (precise-proposed/main) [1:0.156.14.21 => 1:0.156.14.22] (core)
<jbicha> please reject gnome-documents/zesty, I might as well update it to 3.24.1 instead
<slangasek> infinity: ^^ update-manager for your consideration; text of new message identical to that shown in motd
<slangasek> jbicha: done
-queuebot:#ubuntu-release- Unapproved: rejected gnome-documents [source] (zesty-proposed) [3.24.0-0ubuntu1.1]
<infinity> slangasek: Tested?
<slangasek> infinity: y
<infinity> slangasek: In 7 locales?
<slangasek> 7?
<infinity> slangasek: With one hand tied behind your back?
<slangasek> my precise chroot has no extra locales, but I could set that up and test (but no translations included I was just being anal in marking it translatable)
<slangasek> I did have to fix a unicode bug when copying from update-motd because smartquote
<infinity> slangasek: Yeah, I guess that was my way of saying "why bother marking it translatable", but if it works, it works, and my carefactor for how is low.
<infinity> slangasek: So, accepting that as the quick hack it is.  To not conflate bugs, we should probably just clsoe the one this references with this upload.
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (precise-proposed) [1:0.156.14.22]
 * slangasek nods
<infinity> slangasek: But if this is The Right Thing going forward, I suspect you want something maintainable, that inserts version numbers into the strings, and actually divines support status based on something other than when you uploaded the patch. ;)
<slangasek> yep
<slangasek> http://paste.ubuntu.com/24475235/
<slangasek> there, two locales tested ;)
<Ukikie> I'm presuming PPA builds will fail for precise now?
<infinity> Ukikie: They will when I mark precise OBSOLETE.  I might not do that today, but I will Soon(tm).
<infinity> We might want to revisit that with an LP twiddle to make ESM releases "sort of obsolete", so PPAs can still target them.  I dunno.
<Ukikie> OK, wondered due to the extended part.  Thanks.
<infinity> That is, indeed, the one open question that is why I won't be closing the archive today.  Needs a discussion.  And possibly code, depending on the outcome of said discussion.
<cjwatson> Yeah maybe we should verify that ESM can actually be enabled by users of it before closing
<cjwatson> (assuming you haven't yet?)
<infinity> cjwatson: I won't be closing it until next week.
<infinity> cjwatson: But hi!
<infinity> cjwatson: Do you have any feelings about if people should or shouldn't be allowed to build PPAs for precise, given that it'll be in a "sort of supported" state?
<infinity> cjwatson: (If so, I imagine we need a new OBSOLETE-ESM status that would do all the same things as obsolete, but allow PPAs to build against it without the "build for obsolete series" flag set)
<infinity> wgrant: ^-- Or you can have opinions when you wake up.
<wgrant> I've been at the airport for two hours...
<wgrant> infinity: I think we should leave PPAs buildable, though problems arise if they need packages from the private ESM archive...
<infinity> wgrant: If PPA users are depending on the ESM archive, I think they get to keep both pieces.
<wgrant> Quite.
<infinity> wgrant: But "leaving them buildable" implies either not closing the archive, or some twiddling to make closing and PPA-buildability not mutually exclusive.
<wgrant> infinity: And the value of closing the archive is?
<wgrant> Beisdes cosmetics, which we've already violated for vivid forever...
<infinity> wgrant: Tells people to GTFO when they attempt to upload to it.  I guess that's about it.
<wgrant> It's a little unfortunate, but doesn't seem functionally problematic AFAICT
<infinity> wgrant: Cosmetically, I actually prefer is precise stays listed, as people might use https://launchpad.net/ubuntu/+source/<package> to look up what's published in their still-sort-of-supported release.
<infinity> I just don't like that it's listed as "SUPPORTED", nor that it allows uploads.
<infinity> wgrant: But those issues are hardly urgent either, so we can just keep it open.
<infinity> And maybe decide later if there's some better way to represent the true state.
<wgrant> That would be my recommendation.
#ubuntu-release 2017-04-29
<slangasek> cyphermox, jdstrand: https://wiki.ubuntu.com/UbuntuMainInclusionRequirements references secunia, but this db has a EULA that prohibits use except by students, private persons, and hobbyist researchers.  Should that ref be removed?
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (yakkety-proposed) [2.25+16.10]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.25]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.25~14.04]
<LocutusOfBorg> hello archive admins, do you think we can remove location-service? I want to ask removal of boost-1.61 and this is the last blocker. ginggs suggests  that such ubuntu phone stuff should be removed now :)
<LocutusOfBorg> I can also push the fix FWIW, not sure why lp: #1640320 is still open
<ubot5`> Launchpad bug 1640320 in location-service (Ubuntu) "FTBFS in zesty" [High,Confirmed] https://launchpad.net/bugs/1640320
<LocutusOfBorg> xnox, ^^ :=
<cjwatson> infinity: Yeah, I went to bed just after saying that, but what you and William arrived at seems reasonable enough.
<LocutusOfBorg> how do we use the new ben binary I just uploaded in artful for the transition tracker? (see #debian-release for a rationale of my need)
-queuebot:#ubuntu-release- Unapproved: file-roller (zesty-proposed/main) [3.22.3-1ubuntu1 => 3.24.1-0ubuntu1] (ubuntu-desktop)
<jbicha> please reject file-roller/zesty, that was for artful
-queuebot:#ubuntu-release- Unapproved: rejected file-roller [source] (zesty-proposed) [3.24.1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: kdoctools [ppc64el] (artful-proposed/universe) [5.33.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kdoctools [amd64] (artful-proposed/universe) [5.33.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kdoctools [i386] (artful-proposed/universe) [5.33.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kdoctools [arm64] (artful-proposed/universe) [5.33.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kdoctools [s390x] (artful-proposed/universe) [5.33.0-0ubuntu1] (kubuntu)
 * cjwatson gives MoM a modern version of patch pending a full upgrade to xenial; much better
-queuebot:#ubuntu-release- New binary: kdoctools [armhf] (artful-proposed/universe) [5.33.0-0ubuntu1] (kubuntu)
<infinity> cjwatson: Now if someone would fix the bug where it appends newlines to changelogs...
<acheronuk> if someone has time to approve the new binaries in kdoctools, that would be great.
<acheronuk> keeping half our frameworks stcak in depwait at the moment: http://gpul.grupos.udc.es/ka-iron-hand_reports/frameworks_archive/5.33_artful_proposed_migration.pdf
<acheronuk> *stack
-queuebot:#ubuntu-release- New binary: llvm-toolchain-4.0 [amd64] (artful-proposed/main) [1:4.0-5] (core)
-queuebot:#ubuntu-release- New: accepted kdoctools [amd64] (artful-proposed) [5.33.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kdoctools [armhf] (artful-proposed) [5.33.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kdoctools [ppc64el] (artful-proposed) [5.33.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kdoctools [arm64] (artful-proposed) [5.33.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kdoctools [s390x] (artful-proposed) [5.33.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kdoctools [i386] (artful-proposed) [5.33.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-4.0 [amd64] (artful-proposed) [1:4.0-5]
-queuebot:#ubuntu-release- New: accepted freebayes [amd64] (artful-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted kproperty [sync] (artful-proposed) [3.0.0-2]
-queuebot:#ubuntu-release- New: accepted kreport [sync] (artful-proposed) [3.0.0-2]
-queuebot:#ubuntu-release- New binary: kproperty [ppc64el] (artful-proposed/universe) [3.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: kproperty [s390x] (artful-proposed/universe) [3.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: kproperty [amd64] (artful-proposed/universe) [3.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: kproperty [i386] (artful-proposed/universe) [3.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: kproperty [arm64] (artful-proposed/universe) [3.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: kproperty [armhf] (artful-proposed/universe) [3.0.0-2] (no packageset)
<acheronuk> TY, whoever that ^^^ was :)
<infinity> acheronuk: NP.
-queuebot:#ubuntu-release- New binary: llvm-defaults [amd64] (artful-proposed/universe) [0.36ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-defaults [i386] (artful-proposed/universe) [0.36ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-defaults [arm64] (artful-proposed/universe) [0.36ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-defaults [armhf] (artful-proposed/universe) [0.36ubuntu3] (no packageset)
<LocutusOfBorg> lets add again ocaml :)
<infinity> LocutusOfBorg: You added it on 4 arches, but libllvm-4.0-ocaml-dev only exists on two.
<infinity> Oh, the other two might still be building.
-queuebot:#ubuntu-release- New: accepted llvm-defaults [amd64] (artful-proposed) [0.36ubuntu3]
-queuebot:#ubuntu-release- New: accepted llvm-defaults [armhf] (artful-proposed) [0.36ubuntu3]
-queuebot:#ubuntu-release- New: accepted llvm-defaults [arm64] (artful-proposed) [0.36ubuntu3]
-queuebot:#ubuntu-release- New: accepted llvm-defaults [i386] (artful-proposed) [0.36ubuntu3]
<cjwatson> infinity: feel free to work that one out; I think I got lost in Scott code when I tried
-queuebot:#ubuntu-release- New: accepted kproperty [amd64] (artful-proposed) [3.0.0-2]
-queuebot:#ubuntu-release- New: accepted kproperty [armhf] (artful-proposed) [3.0.0-2]
-queuebot:#ubuntu-release- New: accepted kproperty [ppc64el] (artful-proposed) [3.0.0-2]
-queuebot:#ubuntu-release- New: accepted kproperty [arm64] (artful-proposed) [3.0.0-2]
-queuebot:#ubuntu-release- New: accepted kproperty [s390x] (artful-proposed) [3.0.0-2]
-queuebot:#ubuntu-release- New: accepted kproperty [i386] (artful-proposed) [3.0.0-2]
<infinity> Cannot copy 1150 packages at once; bisecting ...
<infinity> Cannot copy 575 packages at once; bisecting ...
<infinity> Go, auto-sync, go.
-queuebot:#ubuntu-release- New binary: iptraf-ng [amd64] (artful-proposed/main) [1:1.1.4-6] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: six [amd64] (artful-proposed/main) [1.10.0-4] (core)
#ubuntu-release 2017-04-30
-queuebot:#ubuntu-release- New binary: node-tunein [amd64] (artful-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gfal2 [s390x] (artful-proposed/universe) [2.13.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: debian-reference [amd64] (artful-proposed/universe) [2.67] (no packageset)
-queuebot:#ubuntu-release- New binary: hfst-ospell [s390x] (artful-proposed/universe) [0.4.3~r338-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gfal2 [ppc64el] (artful-proposed/universe) [2.13.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ffc [amd64] (artful-proposed/universe) [2016.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hfst-ospell [ppc64el] (artful-proposed/universe) [0.4.3~r338-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gammaray [ppc64el] (artful-proposed/universe) [2.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gfal2 [amd64] (artful-proposed/universe) [2.13.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: gfal2 [i386] (artful-proposed/universe) [2.13.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: hfst-ospell [i386] (artful-proposed/universe) [0.4.3~r338-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hfst-ospell [amd64] (artful-proposed/universe) [0.4.3~r338-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-goleveldb [amd64] (artful-proposed/universe) [0.0~git20170302.0.3c5717c-4] (no packageset)
-queuebot:#ubuntu-release- New binary: gammaray [i386] (artful-proposed/universe) [2.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gammaray [amd64] (artful-proposed/universe) [2.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ompl [ppc64el] (artful-proposed/universe) [1.2.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ompl [s390x] (artful-proposed/universe) [1.2.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ompl [i386] (artful-proposed/universe) [1.2.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ompl [amd64] (artful-proposed/universe) [1.2.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gfal2 [arm64] (artful-proposed/universe) [2.13.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: python-gmpy [amd64] (artful-proposed/universe) [1.17-3] (no packageset)
-queuebot:#ubuntu-release- New binary: python-gmpy2 [amd64] (artful-proposed/universe) [2.0.8-2] (no packageset)
-queuebot:#ubuntu-release- New binary: wolfssl [s390x] (artful-proposed/universe) [3.10.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bfs [s390x] (artful-proposed/universe) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pygame [i386] (artful-proposed/universe) [1.9.3+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bgw-replstatus [s390x] (artful-proposed/universe) [1.0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: bitlbee-facebook [s390x] (artful-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pygame [amd64] (artful-proposed/universe) [1.9.3+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bio-tradis [s390x] (artful-proposed/universe) [1.3.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gfal2 [armhf] (artful-proposed/universe) [2.13.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: bfs [ppc64el] (artful-proposed/universe) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bio-tradis [ppc64el] (artful-proposed/universe) [1.3.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: butteraugli [ppc64el] (artful-proposed/universe) [0~20170116-1] (no packageset)
-queuebot:#ubuntu-release- New binary: catimg [ppc64el] (artful-proposed/universe) [2.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: certspotter [s390x] (artful-proposed/universe) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: docopt.cpp [s390x] (artful-proposed/universe) [0.6.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: fzy [s390x] (artful-proposed/universe) [0.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bgw-replstatus [ppc64el] (artful-proposed/universe) [1.0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: butteraugli [s390x] (artful-proposed/universe) [0~20170116-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepnano [s390x] (artful-proposed/universe) [0.0+20160706-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wolfssl [ppc64el] (artful-proposed/universe) [3.10.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bitlbee-facebook [ppc64el] (artful-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fontmanager.app [s390x] (artful-proposed/universe) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: catimg [s390x] (artful-proposed/universe) [2.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: canu [s390x] (artful-proposed/universe) [1.3+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: canu [ppc64el] (artful-proposed/universe) [1.3+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cubicsdr [s390x] (artful-proposed/universe) [0.2.0+git20170310+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: docopt.cpp [ppc64el] (artful-proposed/universe) [0.6.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: fzy [ppc64el] (artful-proposed/universe) [0.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbloom [s390x] (artful-proposed/universe) [1.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: certspotter [ppc64el] (artful-proposed/universe) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fontmanager.app [ppc64el] (artful-proposed/universe) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libnexstar [s390x] (artful-proposed/universe) [0.15-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepnano [ppc64el] (artful-proposed/universe) [0.0+20160706-1] (no packageset)
-queuebot:#ubuntu-release- New binary: guetzli [s390x] (artful-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: belenios [s390x] (artful-proposed/universe) [1.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: guetzli [ppc64el] (artful-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cubicsdr [ppc64el] (artful-proposed/universe) [0.2.0+git20170310+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: heaptrack [ppc64el] (artful-proposed/universe) [1.0.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: kreport [s390x] (artful-proposed/universe) [3.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libnexstar [ppc64el] (artful-proposed/universe) [0.15-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-sparsersb [s390x] (artful-proposed/universe) [1.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php-ds [s390x] (artful-proposed/universe) [1.1.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kreport [ppc64el] (artful-proposed/universe) [3.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mptp [s390x] (artful-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbloom [ppc64el] (artful-proposed/universe) [1.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pgaudit [s390x] (artful-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: janus [ppc64el] (artful-proposed/universe) [0.2.2+dfsg-4] (no packageset)
-queuebot:#ubuntu-release- New binary: mptp [ppc64el] (artful-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pupnp-1.8 [s390x] (artful-proposed/universe) [1:1.8.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: mlv [s390x] (artful-proposed/universe) [3.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mrboom [s390x] (artful-proposed/universe) [3.1.127-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mlv [ppc64el] (artful-proposed/universe) [3.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-sparsersb [ppc64el] (artful-proposed/universe) [1.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php-ds [ppc64el] (artful-proposed/universe) [1.1.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pupnp-1.8 [ppc64el] (artful-proposed/universe) [1:1.8.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: python-biotools [s390x] (artful-proposed/universe) [1.2.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qtdeclarative-render2d-opensource-src [s390x] (artful-proposed/universe) [5.7.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-google-protobuf [s390x] (artful-proposed/universe) [3.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sassphp [s390x] (artful-proposed/universe) [0.5.10-2] (no packageset)
-queuebot:#ubuntu-release- New binary: stressant [s390x] (artful-proposed/universe) [0.4.0] (no packageset)
-queuebot:#ubuntu-release- New binary: vis [s390x] (artful-proposed/universe) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mrboom [ppc64el] (artful-proposed/universe) [3.1.127-1] (no packageset)
-queuebot:#ubuntu-release- New binary: protracker [ppc64el] (artful-proposed/universe) [2.3d.r10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qtdeclarative-render2d-opensource-src [ppc64el] (artful-proposed/universe) [5.7.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: runcircos-gui [s390x] (artful-proposed/universe) [0.0+20160403-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tnetstring3 [s390x] (artful-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pgaudit [ppc64el] (artful-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-snowballc [s390x] (artful-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-biotools [ppc64el] (artful-proposed/universe) [1.2.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sniproxy [s390x] (artful-proposed/universe) [0.5.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: orthanc-wsi [ppc64el] (artful-proposed/universe) [0.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-snowballc [ppc64el] (artful-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-google-protobuf [ppc64el] (artful-proposed/universe) [3.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sassphp [ppc64el] (artful-proposed/universe) [0.5.10-2] (no packageset)
-queuebot:#ubuntu-release- New binary: orthanc-wsi [s390x] (artful-proposed/universe) [0.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: runcircos-gui [ppc64el] (artful-proposed/universe) [0.0+20160403-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-v8 [ppc64el] (artful-proposed/universe) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tnseq-transit [s390x] (artful-proposed/universe) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hfst-ospell [arm64] (artful-proposed/universe) [0.4.3~r338-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sniproxy [ppc64el] (artful-proposed/universe) [0.5.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: tnetstring3 [ppc64el] (artful-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: protracker [s390x] (artful-proposed/universe) [2.3d.r10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: stressant [ppc64el] (artful-proposed/universe) [0.4.0] (no packageset)
-queuebot:#ubuntu-release- New binary: hfst-ospell [armhf] (artful-proposed/universe) [0.4.3~r338-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vis [ppc64el] (artful-proposed/universe) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: seafile-client [s390x] (artful-proposed/universe) [6.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tnseq-transit [ppc64el] (artful-proposed/universe) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libhtml-gumbo-perl [s390x] (artful-proposed/universe) [0.17-1] (no packageset)
-queuebot:#ubuntu-release- New binary: uvloop [s390x] (artful-proposed/universe) [0.8.0+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: seafile-client [ppc64el] (artful-proposed/universe) [6.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ciftilib [s390x] (artful-proposed/universe) [1.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: 4pane [s390x] (artful-proposed/universe) [4.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pgsql-ogr-fdw [s390x] (artful-proposed/universe) [1.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: trnascan-se [s390x] (artful-proposed/multiverse) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gst-omx [s390x] (artful-proposed/universe) [1.10.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php-cassandra [s390x] (artful-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ciftilib [ppc64el] (artful-proposed/universe) [1.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: uvloop [ppc64el] (artful-proposed/universe) [0.8.0+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-line-profiler [s390x] (artful-proposed/universe) [2.0+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: 4pane [ppc64el] (artful-proposed/universe) [4.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libhtml-gumbo-perl [ppc64el] (artful-proposed/universe) [0.17-1] (no packageset)
-queuebot:#ubuntu-release- New binary: indexed-gzip [s390x] (artful-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gst-omx [ppc64el] (artful-proposed/universe) [1.10.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php-cassandra [ppc64el] (artful-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pgsql-ogr-fdw [ppc64el] (artful-proposed/universe) [1.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-line-profiler [ppc64el] (artful-proposed/universe) [2.0+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: trnascan-se [ppc64el] (artful-proposed/multiverse) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gammaray [armhf] (artful-proposed/universe) [2.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: indexed-gzip [ppc64el] (artful-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: belenios [ppc64el] (artful-proposed/universe) [1.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wolfssl [amd64] (artful-proposed/universe) [3.10.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: wolfssl [i386] (artful-proposed/universe) [3.10.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: aiohttp-cors [amd64] (artful-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bfs [amd64] (artful-proposed/universe) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bio-tradis [amd64] (artful-proposed/universe) [1.3.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bfs [i386] (artful-proposed/universe) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: android-sdk-helper [amd64] (artful-proposed/universe) [0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: bgw-replstatus [i386] (artful-proposed/universe) [1.0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: bitlbee-facebook [amd64] (artful-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: braillegraph [amd64] (artful-proposed/universe) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: butteraugli [amd64] (artful-proposed/universe) [0~20170116-1] (no packageset)
-queuebot:#ubuntu-release- New binary: catimg [amd64] (artful-proposed/universe) [2.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: certspotter [amd64] (artful-proposed/universe) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dired-quick-sort [amd64] (artful-proposed/universe) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bgw-replstatus [amd64] (artful-proposed/universe) [1.0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: bitlbee-facebook [i386] (artful-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: butteraugli [i386] (artful-proposed/universe) [0~20170116-1] (no packageset)
-queuebot:#ubuntu-release- New binary: certspotter [i386] (artful-proposed/universe) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bio-tradis [i386] (artful-proposed/universe) [1.3.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: catimg [i386] (artful-proposed/universe) [2.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: btrfs-heatmap [amd64] (artful-proposed/universe) [6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: canu [amd64] (artful-proposed/universe) [1.3+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepnano [amd64] (artful-proposed/universe) [0.0+20160706-1] (no packageset)
-queuebot:#ubuntu-release- New binary: docopt.cpp [amd64] (artful-proposed/universe) [0.6.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: el-x [amd64] (artful-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: emacs-git-modes [amd64] (artful-proposed/universe) [1.2.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: examl [i386] (artful-proposed/universe) [3.0.18-2] (no packageset)
-queuebot:#ubuntu-release- New binary: fenrir [amd64] (artful-proposed/universe) [1.05-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fonts-blankenburg [amd64] (artful-proposed/universe) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fonts-smc-dyuthi [amd64] (artful-proposed/universe) [2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: canu [i386] (artful-proposed/universe) [1.3+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: docopt.cpp [i386] (artful-proposed/universe) [0.6.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: examl [amd64] (artful-proposed/universe) [3.0.18-2] (no packageset)
-queuebot:#ubuntu-release- New binary: fonts-bebas-neue [amd64] (artful-proposed/universe) [3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fzy [amd64] (artful-proposed/universe) [0.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepnano [i386] (artful-proposed/universe) [0.0+20160706-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fasd [amd64] (artful-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: elisp-bug-hunter [amd64] (artful-proposed/universe) [1.3.1+repack-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fonts-monlam [amd64] (artful-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cubicsdr [amd64] (artful-proposed/universe) [0.2.0+git20170310+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: fontmanager.app [i386] (artful-proposed/universe) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fonts-smc-meera [amd64] (artful-proposed/universe) [7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fonts-smc-raghumalayalamsans [amd64] (artful-proposed/universe) [2.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fzy [i386] (artful-proposed/universe) [0.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fontmanager.app [amd64] (artful-proposed/universe) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fonts-smc-rachana [amd64] (artful-proposed/universe) [7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fonts-smc-anjalioldlipi [amd64] (artful-proposed/universe) [7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fonts-smc-suruma [amd64] (artful-proposed/universe) [3.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gitsome [amd64] (artful-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-blevesearch-go-porterstemmer [amd64] (artful-proposed/universe) [1.0.1+git20141230.9.23a2c8e-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-bluebreezecf-opentsdb-goclient [amd64] (artful-proposed/universe) [0.0~git20160515.0.539764b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-bsphere-le-go [amd64] (artful-proposed/universe) [0.0~git20170215.0.7a984a8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-cupcake-rdb [amd64] (artful-proposed/universe) [0.0~git20161107.0.43ba341-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-code.gitea-sdk [amd64] (artful-proposed/universe) [0.0~git20170322.0.1bec42c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-bsm-redeo [amd64] (artful-proposed/universe) [0.0~git20160817.0.1ce09fc-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-blevesearch-segment [amd64] (artful-proposed/universe) [0.0~git20160915.0.762005e-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-couchbase-ghistogram [amd64] (artful-proposed/universe) [0.0.0+git20170308.21.d910dd0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cubicsdr [i386] (artful-proposed/universe) [0.2.0+git20170310+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-edsrzf-mmap-go [amd64] (artful-proposed/universe) [0.0~git20160512.0.935e0e8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-facebookgo-clock [amd64] (artful-proposed/universe) [0.0~git20150410.0.600d898-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-facebookgo-stack [amd64] (artful-proposed/universe) [0.0~git20160209.0.7517733-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-denisenkom-go-mssqldb [amd64] (artful-proposed/universe) [0.0~git20170117.0.9e40d9d-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-facebookgo-freeport [amd64] (artful-proposed/universe) [0.0~git20150612.0.d4adf43-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-exponent-io-jsonpath [amd64] (artful-proposed/universe) [0.0~git20151013.0.d6023ce-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-facebookgo-subset [amd64] (artful-proposed/universe) [0.0~git20150612.0.8dac2c3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gammaray [arm64] (artful-proposed/universe) [2.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-go-macaron-csrf [amd64] (artful-proposed/universe) [0.0~git20170207.0.428b7c6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-go-openapi-analysis [amd64] (artful-proposed/universe) [0.0~git20160815.0.b44dc87-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-go-xorm-builder [amd64] (artful-proposed/universe) [0.0~git20170224.0.c6e604e-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-gorilla-securecookie [amd64] (artful-proposed/universe) [1.1+git20170224.6.e59506c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-jaytaylor-html2text [amd64] (artful-proposed/universe) [0.0~git20170217.0.24f9b0f-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-go-macaron-bindata [amd64] (artful-proposed/universe) [0.0~git20161222.0.85786f5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-go-openapi-errors [amd64] (artful-proposed/universe) [0.0~git20160704.0.d24ebc2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-issue9-assert [amd64] (artful-proposed/universe) [0.0~git20161202.0.598d99b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-go-macaron-toolbox [amd64] (artful-proposed/universe) [0.0~git20170220.0.6766b8f-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-gogits-chardet [amd64] (artful-proposed/universe) [0.0~git20150115.0.2404f77+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-gorilla-pat [amd64] (artful-proposed/universe) [0.0~git20160413.0.cf955c3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-joho-godotenv [amd64] (artful-proposed/universe) [1.1+git20170328.12.325433c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-juju-errors [amd64] (artful-proposed/universe) [0.0~git20160809.0.6f54ff6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-leemcloughlin-gofarmhash [amd64] (artful-proposed/universe) [0.0~git20160919.0.0a055c5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-lunny-log [amd64] (artful-proposed/universe) [0.0~git20160921.0.7887c61-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-hillu-go-yara [amd64] (artful-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-kisielk-gotool [amd64] (artful-proposed/universe) [0.0~git20161130.0.0de1eaf-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-jroimartin-gocui [amd64] (artful-proposed/universe) [0.3.0+git20170212.45.ed41d1b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-lpabon-godbc [amd64] (artful-proposed/universe) [1.0+git20140613.1.9577782-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-kubernetes-gengo [amd64] (artful-proposed/universe) [0.0~git20161024.0.6a1c24d-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-mcuadros-go-version [amd64] (artful-proposed/universe) [0.0~git20161105.0.257f7b9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-msteinert-pam [amd64] (artful-proposed/universe) [0.0~git20151204.0.02ccfbf-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-neelance-astrewrite [amd64] (artful-proposed/universe) [0.0~git20160511.0.9934826-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-neowaylabs-wabbit [amd64] (artful-proposed/universe) [0.0~git20170406.0.cfb5237-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-makenowjust-heredoc [amd64] (artful-proposed/universe) [0.0~git20140704.0.1d91351-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-nbutton23-zxcvbn-go [amd64] (artful-proposed/universe) [0.0~git20160627.0.a22cb81-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-ngaut-log [amd64] (artful-proposed/universe) [0.0~git20170217.0.1c9fb4d-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-mrjones-oauth [amd64] (artful-proposed/universe) [0.0~git20170225.0.3f67d9c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-neelance-sourcemap [amd64] (artful-proposed/universe) [0.0~git20151028.0.8c68805-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-ngaut-deadline [amd64] (artful-proposed/universe) [0.0~git20170224.0.71c16b1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-petar-gollrb [amd64] (artful-proposed/universe) [0.0~git20130427.0.53be0d3+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-pkg-xattr [amd64] (artful-proposed/universe) [0.2.0+git20170313.4.2c7218a-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-quobyte-api [amd64] (artful-proposed/universe) [0.0~git20160913.0.bf713b5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-rjeczalik-notify [amd64] (artful-proposed/universe) [0.0~git20170301.0.41a8645-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-siddontang-go-snappy [amd64] (artful-proposed/universe) [0.0~git20140704.0.d8f7bb8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-steveyen-gtreap [amd64] (artful-proposed/universe) [0.0~git20150807.0.0abe01e-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-ngaut-sync2 [amd64] (artful-proposed/universe) [0.0~git20141008.0.7a24ed7-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-pquerna-otp [amd64] (artful-proposed/universe) [0.0~git20170223.0.9e19353-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-sergi-go-diff [amd64] (artful-proposed/universe) [0.0~git20170118.0.24e2351-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-twinj-uuid [amd64] (artful-proposed/universe) [0.10.0+git20160909.96.7bbe408-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-pingcap-check [amd64] (artful-proposed/universe) [0.0~git20161122.0.9b26663-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-siddontang-go [amd64] (artful-proposed/universe) [0.0~git20161005.0.1e9ce2a-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-renstrom-dedent [amd64] (artful-proposed/universe) [1.0.0+git20150819.3.020d11c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-unknwon-cae [amd64] (artful-proposed/universe) [0.0~git20160715.0.c6aac99-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-unknwon-paginater [amd64] (artful-proposed/universe) [0.0~git20170205.0.7650849-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-willf-bitset [amd64] (artful-proposed/universe) [1.0.0+git20161202.88.5c3c0fc-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-yohcop-openid-go [amd64] (artful-proposed/universe) [0.0~git20170224.0.fa274ac-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gopkg-alexcesaro-quotedprintable.v3 [amd64] (artful-proposed/universe) [0.0~git20150716.0.2caba25-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-unknwon-i18n [amd64] (artful-proposed/universe) [0.0~git20170218.0.8372b90-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-xanzy-go-cloudstack [amd64] (artful-proposed/universe) [2.1.1+git20160728.1.1e2cbf6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gopkg-jarcoal-httpmock.v1 [amd64] (artful-proposed/universe) [0.0~git20170321.0.abbf154-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-vmware-photon-controller-go-sdk [amd64] (artful-proposed/universe) [0.0~PROMOTED-339-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-golang-x-sync [amd64] (artful-proposed/universe) [0.0~git20170317.0.5a06fca-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-syndtr-goleveldb [amd64] (artful-proposed/universe) [0.0~git20170302.0.3c5717c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gopkg-gomail.v2 [amd64] (artful-proposed/universe) [2.0.0+git20160411.23.81ebce5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-honnef-go-augeas [amd64] (artful-proposed/universe) [0.0~git20161110.0.ca62e35-1] (no packageset)
-queuebot:#ubuntu-release- New binary: guetzli [amd64] (artful-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: javafxsvg [amd64] (artful-proposed/universe) [1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kreport [i386] (artful-proposed/universe) [3.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ldcofonts [amd64] (artful-proposed/universe) [1.0.0.part3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gopkg-editorconfig-editorconfig-core-go.v1 [amd64] (artful-proposed/universe) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-strk.kbt-projects-go-libravatar [amd64] (artful-proposed/universe) [0.0~git20161111.0.d628b68-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kreport [amd64] (artful-proposed/universe) [3.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gopkg-olivere-elastic.v3 [amd64] (artful-proposed/universe) [3.0.41-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kytos-utils [amd64] (artful-proposed/universe) [2017.1b1.post1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: guetzli [i386] (artful-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: heaptrack [amd64] (artful-proposed/universe) [1.0.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: hikaricp [amd64] (artful-proposed/universe) [2.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: janus [i386] (artful-proposed/universe) [0.2.2+dfsg-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libbloom [i386] (artful-proposed/universe) [1.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libnexstar [amd64] (artful-proposed/universe) [0.15-1] (no packageset)
-queuebot:#ubuntu-release- New binary: librandom123 [amd64] (artful-proposed/universe) [1.09+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libundead [amd64] (artful-proposed/universe) [1.0.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: minetest-mod-craftguide [amd64] (artful-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: minetest-mod-unifieddyes [amd64] (artful-proposed/universe) [0.4.15-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mptp [amd64] (artful-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: heaptrack [i386] (artful-proposed/universe) [1.0.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libbloom [amd64] (artful-proposed/universe) [1.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libnexstar [i386] (artful-proposed/universe) [0.15-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libundead [i386] (artful-proposed/universe) [1.0.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mocker-el [amd64] (artful-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: janus [amd64] (artful-proposed/universe) [0.2.2+dfsg-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libsmali-1-java [amd64] (artful-proposed/universe) [1.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mptp [i386] (artful-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libclasslojure-clojure [amd64] (artful-proposed/universe) [0.7.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: minetest-mod-homedecor [amd64] (artful-proposed/universe) [0.4.15-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lockdown [amd64] (artful-proposed/universe) [0.2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-bn.js [amd64] (artful-proposed/universe) [4.11.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-combine-source-map [amd64] (artful-proposed/universe) [0.8.0+ds-4] (no packageset)
-queuebot:#ubuntu-release- New binary: node-tweetnacl [amd64] (artful-proposed/universe) [0.14.5+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-sparsersb [i386] (artful-proposed/universe) [1.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pftools [amd64] (artful-proposed/universe) [3+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mlv [amd64] (artful-proposed/universe) [3.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-hoek [amd64] (artful-proposed/universe) [4.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: opensvc [amd64] (artful-proposed/universe) [1.8~20170412-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-brorand [amd64] (artful-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pgaudit [amd64] (artful-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nose-el [amd64] (artful-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lgooddatepicker [amd64] (artful-proposed/universe) [8.3.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mrboom [amd64] (artful-proposed/universe) [3.1.127-1] (no packageset)
-queuebot:#ubuntu-release- New binary: paleomix [amd64] (artful-proposed/universe) [1.2.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php-ds [amd64] (artful-proposed/universe) [1.1.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: protracker [amd64] (artful-proposed/universe) [2.3d.r10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pupnp-1.8 [amd64] (artful-proposed/universe) [1:1.8.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: pyicloud [amd64] (artful-proposed/universe) [0.9.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pytest-mpl [amd64] (artful-proposed/universe) [0.7-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-biotools [i386] (artful-proposed/universe) [1.2.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-dbfread [amd64] (artful-proposed/universe) [2.0.7-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mlv [i386] (artful-proposed/universe) [3.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pgaudit [i386] (artful-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: protracker [i386] (artful-proposed/universe) [2.3d.r10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pypng [amd64] (artful-proposed/universe) [0.0.18+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-btrfs [amd64] (artful-proposed/universe) [6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-engineio [amd64] (artful-proposed/universe) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-kanboard [amd64] (artful-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-sparsersb [amd64] (artful-proposed/universe) [1.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pupnp-1.8 [i386] (artful-proposed/universe) [1:1.8.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: python-dnslib [amd64] (artful-proposed/universe) [0.9.7+hg20170303-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pyqrcode [amd64] (artful-proposed/universe) [1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php-ds [i386] (artful-proposed/universe) [1.1.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-holidays [amd64] (artful-proposed/universe) [0.8.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-biotools [amd64] (artful-proposed/universe) [1.2.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mrboom [i386] (artful-proposed/universe) [3.1.127-1] (no packageset)
-queuebot:#ubuntu-release- New binary: orthanc-wsi [i386] (artful-proposed/universe) [0.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pgpy [amd64] (artful-proposed/universe) [0.4.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: qcumber [amd64] (artful-proposed/universe) [1.0.14+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-calibrate [amd64] (artful-proposed/universe) [1.7.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-miniui [amd64] (artful-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-snowballc [amd64] (artful-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-v8 [amd64] (artful-proposed/universe) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-ddplugin [amd64] (artful-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-google-protobuf [i386] (artful-proposed/universe) [3.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: orthanc-wsi [amd64] (artful-proposed/universe) [0.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-xopen [amd64] (artful-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-crul [amd64] (artful-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-snowballc [i386] (artful-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-doorkeeper-openid-connect [amd64] (artful-proposed/universe) [1.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-maven-libs [amd64] (artful-proposed/universe) [3.3.9+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-gbulb [amd64] (artful-proposed/universe) [0.5.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-pwt9 [amd64] (artful-proposed/universe) [9.0-0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-jar-dependencies [amd64] (artful-proposed/universe) [0.3.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qtdeclarative-render2d-opensource-src [amd64] (artful-proposed/universe) [5.7.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-v8 [i386] (artful-proposed/universe) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qtdeclarative-render2d-opensource-src [i386] (artful-proposed/universe) [5.7.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rubocop [amd64] (artful-proposed/universe) [0.48.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-rails-assets-underscore [amd64] (artful-proposed/universe) [1.8.3+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: runcircos-gui [i386] (artful-proposed/universe) [0.0+20160403-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sassphp [i386] (artful-proposed/universe) [0.5.10-2] (no packageset)
-queuebot:#ubuntu-release- New binary: sniproxy [amd64] (artful-proposed/universe) [0.5.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: stressant [amd64] (artful-proposed/universe) [0.4.0] (no packageset)
-queuebot:#ubuntu-release- New binary: tdiary-style-gfm [amd64] (artful-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tigris [amd64] (artful-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tnetstring3 [i386] (artful-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-survey [amd64] (artful-proposed/universe) [3.31-5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: runcircos-gui [amd64] (artful-proposed/universe) [0.0+20160403-1] (no packageset)
-queuebot:#ubuntu-release- New binary: seqsero [amd64] (artful-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: stressant [i386] (artful-proposed/universe) [0.4.0] (no packageset)
-queuebot:#ubuntu-release- New binary: tnetstring3 [amd64] (artful-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tools-trace-clojure [amd64] (artful-proposed/universe) [0.7.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-google-protobuf [amd64] (artful-proposed/universe) [3.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sniproxy [i386] (artful-proposed/universe) [0.5.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: tools-nrepl-clojure [amd64] (artful-proposed/universe) [0.2.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sassphp [amd64] (artful-proposed/universe) [0.5.10-2] (no packageset)
-queuebot:#ubuntu-release- New binary: vim-ledger [amd64] (artful-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tdiary-style-rd [amd64] (artful-proposed/universe) [0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tilix [amd64] (artful-proposed/universe) [1.5.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tnseq-transit [amd64] (artful-proposed/universe) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tools-reader-clojure [amd64] (artful-proposed/universe) [1.0.0~beta2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: unsafe-fences [amd64] (artful-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vis [i386] (artful-proposed/universe) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tilix [i386] (artful-proposed/universe) [1.5.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: typesafe-config [amd64] (artful-proposed/universe) [1.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: tnseq-transit [i386] (artful-proposed/universe) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vis [amd64] (artful-proposed/universe) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: seafile-client [amd64] (artful-proposed/universe) [6.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: uvloop [amd64] (artful-proposed/universe) [0.8.0+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xtensor [amd64] (artful-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: seafile-client [i386] (artful-proposed/universe) [6.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vibe.d [i386] (artful-proposed/universe) [0.7.30-1] (no packageset)
-queuebot:#ubuntu-release- New binary: uvloop [i386] (artful-proposed/universe) [0.8.0+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: adql [amd64] (artful-proposed/universe) [1.3-4] (no packageset)
-queuebot:#ubuntu-release- New binary: ciftilib [amd64] (artful-proposed/universe) [1.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: django-dirtyfields [amd64] (artful-proposed/universe) [1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: eag-healpix [amd64] (artful-proposed/universe) [2017.02.26-2] (no packageset)
-queuebot:#ubuntu-release- New binary: fonts-smc-chilanka [amd64] (artful-proposed/universe) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fonts-smc-keraleeyam [amd64] (artful-proposed/universe) [2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fonts-smc-uroob [amd64] (artful-proposed/universe) [2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-keysign [amd64] (artful-proposed/universe) [0.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-jinzhu-inflection [amd64] (artful-proposed/universe) [0.0~git20151009.0.3272df6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vibe.d [amd64] (artful-proposed/universe) [0.7.30-1] (no packageset)
-queuebot:#ubuntu-release- New binary: astrodendro [amd64] (artful-proposed/universe) [0.2.0+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: drf-extensions [amd64] (artful-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fonts-smc-karumbi [amd64] (artful-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gajim-antispam [amd64] (artful-proposed/universe) [0.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: scap-security-guide [amd64] (artful-proposed/universe) [0.1.31-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ciftilib [i386] (artful-proposed/universe) [1.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fonts-smc-manjari [amd64] (artful-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fonts-naver-d2coding [amd64] (artful-proposed/universe) [1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-buger-jsonparser [amd64] (artful-proposed/universe) [0.0~git20170215.0.6bd1670-1] (no packageset)
-queuebot:#ubuntu-release- New binary: 4pane [amd64] (artful-proposed/universe) [4.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: apertium-spa-cat [amd64] (artful-proposed/universe) [2.0.0~r77288-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gst-omx [i386] (artful-proposed/universe) [1.10.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcatmandu-store-elasticsearch-perl [amd64] (artful-proposed/universe) [0.0507-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libhtml-gumbo-perl [i386] (artful-proposed/universe) [0.17-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmarc-spec-perl [amd64] (artful-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libnet-prometheus-perl [amd64] (artful-proposed/universe) [0.05-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpod-weaver-section-generatesection-perl [amd64] (artful-proposed/universe) [1.06-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-argv [amd64] (artful-proposed/universe) [0.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-binary-extensions [amd64] (artful-proposed/universe) [1.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: 4pane [i386] (artful-proposed/universe) [4.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jel [amd64] (artful-proposed/universe) [2.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libhttp-server-simple-cgi-prefork-perl [amd64] (artful-proposed/universe) [6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpandoc-wrapper-perl [amd64] (artful-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-assert-plus [amd64] (artful-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gst-omx [amd64] (artful-proposed/universe) [1.10.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmojo-jwt-perl [amd64] (artful-proposed/universe) [0.05-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libhtml-gumbo-perl [amd64] (artful-proposed/universe) [0.17-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-anymatch [amd64] (artful-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-boom [amd64] (artful-proposed/universe) [4.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-constants-browserify [amd64] (artful-proposed/universe) [1.0.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-hash-test-vectors [amd64] (artful-proposed/universe) [1.3.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-https-browserify [amd64] (artful-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-json-loader [amd64] (artful-proposed/universe) [0.5.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-loader-runner [amd64] (artful-proposed/universe) [2.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-object-key [amd64] (artful-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-prr [amd64] (artful-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-quote-stream [amd64] (artful-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-tapable [amd64] (artful-proposed/universe) [0.2.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-browser-resolve [amd64] (artful-proposed/universe) [1.11.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-hash.js [amd64] (artful-proposed/universe) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-json-schema [amd64] (artful-proposed/universe) [0.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-p-limit [amd64] (artful-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-sntp [amd64] (artful-proposed/universe) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-url [amd64] (artful-proposed/universe) [0.11.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: open-infrastructure-locales-c.utf-8 [amd64] (artful-proposed/universe) [20170410-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-des.js [amd64] (artful-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-minimalistic-crypto-utils [amd64] (artful-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-tough-cookie [amd64] (artful-proposed/universe) [2.3.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: open-infrastructure-storage-tools [amd64] (artful-proposed/universe) [20170410-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-jsbn [amd64] (artful-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-urlgrey [amd64] (artful-proposed/universe) [0.4.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-querystring [amd64] (artful-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: indexed-gzip [amd64] (artful-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pgsql-ogr-fdw [i386] (artful-proposed/universe) [1.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: php-cassandra [i386] (artful-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-bip32utils [amd64] (artful-proposed/universe) [0.0~git20170118.dd9c541-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-django-otp [amd64] (artful-proposed/universe) [0.3.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-jsonpointer [amd64] (artful-proposed/universe) [1.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-line-profiler [amd64] (artful-proposed/universe) [2.0+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pweave [amd64] (artful-proposed/universe) [0.25-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-rpaths [amd64] (artful-proposed/universe) [0.13-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sortedcollections [amd64] (artful-proposed/universe) [0.5.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pgsql-ogr-fdw [amd64] (artful-proposed/universe) [1.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pytds [amd64] (artful-proposed/universe) [1.8.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-django-push-notifications [amd64] (artful-proposed/universe) [1.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-line-profiler [i386] (artful-proposed/universe) [2.0+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-xapian-haystack [amd64] (artful-proposed/universe) [2.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: php-cassandra [amd64] (artful-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-leather [amd64] (artful-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-django-extra-views [amd64] (artful-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pydap [amd64] (artful-proposed/universe) [3.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: muttdown [amd64] (artful-proposed/multiverse) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: skyview [amd64] (artful-proposed/universe) [3.2.3+repack-1] (no packageset)
-queuebot:#ubuntu-release- New binary: spyder-unittest [amd64] (artful-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: starjava-registry [amd64] (artful-proposed/universe) [1.2+2016.05.03-1] (no packageset)
-queuebot:#ubuntu-release- New binary: systray-mdstat [amd64] (artful-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: trnascan-se [i386] (artful-proposed/multiverse) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: zabbix-cli [amd64] (artful-proposed/universe) [1.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: repetier-host [amd64] (artful-proposed/universe) [0.85+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: starjava-pal [amd64] (artful-proposed/universe) [1.0.1+2016.08.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: trnascan-se [amd64] (artful-proposed/multiverse) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: spyder-memory-profiler [amd64] (artful-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tt-rss-notifier-chrome [amd64] (artful-proposed/universe) [0.5.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: starjava-util [amd64] (artful-proposed/universe) [1.0+2017.03.17-1] (no packageset)
-queuebot:#ubuntu-release- New binary: grr-client-templates [amd64] (artful-proposed/multiverse) [3.1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: open-ath9k-htc-firmware [amd64] (artful-proposed/universe) [1.4.0-81-gf206e56+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-ltfatpy [amd64] (artful-proposed/universe) [1.0.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ompl [armhf] (artful-proposed/universe) [1.2.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New sync: grr (artful-proposed/primary) [3.1.0.2+dfsg-2]
-queuebot:#ubuntu-release- New sync: litmus (artful-proposed/primary) [0.13-1]
-queuebot:#ubuntu-release- New binary: ompl [arm64] (artful-proposed/universe) [1.2.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pygame [armhf] (artful-proposed/universe) [1.9.3+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: belenios [amd64] (artful-proposed/universe) [1.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New sync: svgwrite (artful-proposed/primary) [1.1.8-2]
-queuebot:#ubuntu-release- New binary: belenios [i386] (artful-proposed/universe) [1.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rematch [amd64] (artful-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-viridislite [amd64] (artful-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wolfssl [arm64] (artful-proposed/universe) [3.10.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: wolfssl [armhf] (artful-proposed/universe) [3.10.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bfs [arm64] (artful-proposed/universe) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bgw-replstatus [arm64] (artful-proposed/universe) [1.0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: bio-tradis [arm64] (artful-proposed/universe) [1.3.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bfs [armhf] (artful-proposed/universe) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bgw-replstatus [armhf] (artful-proposed/universe) [1.0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: bio-tradis [armhf] (artful-proposed/universe) [1.3.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bitlbee-facebook [armhf] (artful-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: butteraugli [armhf] (artful-proposed/universe) [0~20170116-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bitlbee-facebook [arm64] (artful-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: butteraugli [arm64] (artful-proposed/universe) [0~20170116-1] (no packageset)
-queuebot:#ubuntu-release- New binary: catimg [arm64] (artful-proposed/universe) [2.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: certspotter [arm64] (artful-proposed/universe) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: catimg [armhf] (artful-proposed/universe) [2.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: certspotter [armhf] (artful-proposed/universe) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: canu [arm64] (artful-proposed/universe) [1.3+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepnano [arm64] (artful-proposed/universe) [0.0+20160706-1] (no packageset)
-queuebot:#ubuntu-release- New binary: docopt.cpp [arm64] (artful-proposed/universe) [0.6.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: fontmanager.app [arm64] (artful-proposed/universe) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: canu [armhf] (artful-proposed/universe) [1.3+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: docopt.cpp [armhf] (artful-proposed/universe) [0.6.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: deepnano [armhf] (artful-proposed/universe) [0.0+20160706-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fzy [arm64] (artful-proposed/universe) [0.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cubicsdr [arm64] (artful-proposed/universe) [0.2.0+git20170310+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: fzy [armhf] (artful-proposed/universe) [0.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fontmanager.app [armhf] (artful-proposed/universe) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: guetzli [arm64] (artful-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: guetzli [armhf] (artful-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: heaptrack [armhf] (artful-proposed/universe) [1.0.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: kreport [arm64] (artful-proposed/universe) [3.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbloom [arm64] (artful-proposed/universe) [1.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libnexstar [arm64] (artful-proposed/universe) [0.15-1] (no packageset)
-queuebot:#ubuntu-release- New binary: janus [arm64] (artful-proposed/universe) [0.2.2+dfsg-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libbloom [armhf] (artful-proposed/universe) [1.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: kreport [armhf] (artful-proposed/universe) [3.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: cubicsdr [armhf] (artful-proposed/universe) [0.2.0+git20170310+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libnexstar [armhf] (artful-proposed/universe) [0.15-1] (no packageset)
-queuebot:#ubuntu-release- New binary: janus [armhf] (artful-proposed/universe) [0.2.2+dfsg-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libundead [armhf] (artful-proposed/universe) [1.0.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: heaptrack [arm64] (artful-proposed/universe) [1.0.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: mlv [armhf] (artful-proposed/universe) [3.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mptp [armhf] (artful-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pgaudit [arm64] (artful-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mlv [arm64] (artful-proposed/universe) [3.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mrboom [arm64] (artful-proposed/universe) [3.1.127-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mptp [arm64] (artful-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pgaudit [armhf] (artful-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mrboom [armhf] (artful-proposed/universe) [3.1.127-1] (no packageset)
-queuebot:#ubuntu-release- New binary: protracker [armhf] (artful-proposed/universe) [2.3d.r10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pupnp-1.8 [armhf] (artful-proposed/universe) [1:1.8.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: python-biotools [armhf] (artful-proposed/universe) [1.2.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: protracker [arm64] (artful-proposed/universe) [2.3d.r10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-biotools [arm64] (artful-proposed/universe) [1.2.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pupnp-1.8 [arm64] (artful-proposed/universe) [1:1.8.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: orthanc-wsi [arm64] (artful-proposed/universe) [0.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php-ds [arm64] (artful-proposed/universe) [1.1.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qtdeclarative-render2d-opensource-src [arm64] (artful-proposed/universe) [5.7.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-google-protobuf [arm64] (artful-proposed/universe) [3.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: orthanc-wsi [armhf] (artful-proposed/universe) [0.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qtdeclarative-render2d-opensource-src [armhf] (artful-proposed/universe) [5.7.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php-ds [armhf] (artful-proposed/universe) [1.1.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sassphp [arm64] (artful-proposed/universe) [0.5.10-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-google-protobuf [armhf] (artful-proposed/universe) [3.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: runcircos-gui [armhf] (artful-proposed/universe) [0.0+20160403-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sniproxy [arm64] (artful-proposed/universe) [0.5.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: stressant [arm64] (artful-proposed/universe) [0.4.0] (no packageset)
-queuebot:#ubuntu-release- New binary: tnetstring3 [arm64] (artful-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: runcircos-gui [arm64] (artful-proposed/universe) [0.0+20160403-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sniproxy [armhf] (artful-proposed/universe) [0.5.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: sassphp [armhf] (artful-proposed/universe) [0.5.10-2] (no packageset)
-queuebot:#ubuntu-release- New binary: stressant [armhf] (artful-proposed/universe) [0.4.0] (no packageset)
-queuebot:#ubuntu-release- New binary: tilix [armhf] (artful-proposed/universe) [1.5.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tnseq-transit [arm64] (artful-proposed/universe) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vis [arm64] (artful-proposed/universe) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tnetstring3 [armhf] (artful-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vis [armhf] (artful-proposed/universe) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tnseq-transit [armhf] (artful-proposed/universe) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: seafile-client [armhf] (artful-proposed/universe) [6.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: seafile-client [arm64] (artful-proposed/universe) [6.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vibe.d [armhf] (artful-proposed/universe) [0.7.30-1] (no packageset)
-queuebot:#ubuntu-release- New binary: uvloop [arm64] (artful-proposed/universe) [0.8.0+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: uvloop [armhf] (artful-proposed/universe) [0.8.0+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ciftilib [armhf] (artful-proposed/universe) [1.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ciftilib [arm64] (artful-proposed/universe) [1.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: 4pane [arm64] (artful-proposed/universe) [4.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: flask-ldapconn [amd64] (artful-proposed/none) [0.6.13-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-delegates [amd64] (artful-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: 4pane [armhf] (artful-proposed/universe) [4.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gst-omx [arm64] (artful-proposed/universe) [1.10.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libhtml-gumbo-perl [arm64] (artful-proposed/universe) [0.17-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libhtml-gumbo-perl [armhf] (artful-proposed/universe) [0.17-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gst-omx [armhf] (artful-proposed/universe) [1.10.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pgsql-ogr-fdw [armhf] (artful-proposed/universe) [1.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: php-cassandra [armhf] (artful-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-line-profiler [armhf] (artful-proposed/universe) [2.0+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pgsql-ogr-fdw [arm64] (artful-proposed/universe) [1.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-line-profiler [arm64] (artful-proposed/universe) [2.0+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php-cassandra [arm64] (artful-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted debian-reference [amd64] (artful-proposed) [2.67]
-queuebot:#ubuntu-release- New: accepted gammaray [amd64] (artful-proposed) [2.7.0-1]
-queuebot:#ubuntu-release- New: accepted gammaray [ppc64el] (artful-proposed) [2.7.0-1]
-queuebot:#ubuntu-release- New: accepted gfal2 [i386] (artful-proposed) [2.13.3-3]
-queuebot:#ubuntu-release- New: accepted gfal2 [s390x] (artful-proposed) [2.13.3-3]
-queuebot:#ubuntu-release- New: accepted hfst-ospell [amd64] (artful-proposed) [0.4.3~r338-1]
-queuebot:#ubuntu-release- New: accepted hfst-ospell [ppc64el] (artful-proposed) [0.4.3~r338-1]
-queuebot:#ubuntu-release- New: accepted iptraf-ng [amd64] (artful-proposed) [1:1.1.4-6]
-queuebot:#ubuntu-release- New: accepted six [amd64] (artful-proposed) [1.10.0-4]
-queuebot:#ubuntu-release- New binary: trnascan-se [armhf] (artful-proposed/multiverse) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ffc [amd64] (artful-proposed) [2016.2.0-2]
-queuebot:#ubuntu-release- New: accepted gfal2 [amd64] (artful-proposed) [2.13.3-3]
-queuebot:#ubuntu-release- New: accepted golang-goleveldb [amd64] (artful-proposed) [0.0~git20170302.0.3c5717c-4]
-queuebot:#ubuntu-release- New: accepted hfst-ospell [s390x] (artful-proposed) [0.4.3~r338-1]
-queuebot:#ubuntu-release- New binary: trnascan-se [arm64] (artful-proposed/multiverse) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gammaray [i386] (artful-proposed) [2.7.0-1]
-queuebot:#ubuntu-release- New: accepted hfst-ospell [i386] (artful-proposed) [0.4.3~r338-1]
-queuebot:#ubuntu-release- New: accepted gfal2 [ppc64el] (artful-proposed) [2.13.3-3]
-queuebot:#ubuntu-release- New: accepted node-tunein [amd64] (artful-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted 4pane [arm64] (artful-proposed) [4.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ciftilib [arm64] (artful-proposed) [1.5.1-1]
-queuebot:#ubuntu-release- New: accepted flask-ldapconn [amd64] (artful-proposed) [0.6.13-1]
-queuebot:#ubuntu-release- New: accepted gst-omx [armhf] (artful-proposed) [1.10.4-1]
-queuebot:#ubuntu-release- New: accepted libhtml-gumbo-perl [arm64] (artful-proposed) [0.17-1]
-queuebot:#ubuntu-release- New: accepted mlv [arm64] (artful-proposed) [3.1.0-1]
-queuebot:#ubuntu-release- New: accepted mrboom [arm64] (artful-proposed) [3.1.127-1]
-queuebot:#ubuntu-release- New: accepted node-delegates [amd64] (artful-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted open-infrastructure-storage-tools [amd64] (artful-proposed) [20170410-1]
-queuebot:#ubuntu-release- New: accepted orthanc-wsi [armhf] (artful-proposed) [0.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted 4pane [armhf] (artful-proposed) [4.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted gst-omx [arm64] (artful-proposed) [1.10.4-1]
-queuebot:#ubuntu-release- New: accepted libhtml-gumbo-perl [armhf] (artful-proposed) [0.17-1]
-queuebot:#ubuntu-release- New: accepted mrboom [armhf] (artful-proposed) [3.1.127-1]
-queuebot:#ubuntu-release- New: accepted orthanc-wsi [arm64] (artful-proposed) [0.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted pgaudit [armhf] (artful-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted pgsql-ogr-fdw [arm64] (artful-proposed) [1.0.2-2]
-queuebot:#ubuntu-release- New: accepted pgsql-ogr-fdw [i386] (artful-proposed) [1.0.2-2]
-queuebot:#ubuntu-release- New: accepted php-cassandra [arm64] (artful-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted php-cassandra [i386] (artful-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted ciftilib [armhf] (artful-proposed) [1.5.1-1]
-queuebot:#ubuntu-release- New: accepted mlv [armhf] (artful-proposed) [3.1.0-1]
-queuebot:#ubuntu-release- New: accepted pgaudit [arm64] (artful-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted pgsql-ogr-fdw [armhf] (artful-proposed) [1.0.2-2]
-queuebot:#ubuntu-release- New: accepted php-cassandra [armhf] (artful-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted php-ds [armhf] (artful-proposed) [1.1.8-1]
-queuebot:#ubuntu-release- New: accepted protracker [armhf] (artful-proposed) [2.3d.r10-1]
-queuebot:#ubuntu-release- New: accepted pupnp-1.8 [armhf] (artful-proposed) [1:1.8.0-3]
-queuebot:#ubuntu-release- New: accepted python-biotools [arm64] (artful-proposed) [1.2.12-1]
-queuebot:#ubuntu-release- New: accepted python-bip32utils [amd64] (artful-proposed) [0.0~git20170118.dd9c541-1]
-queuebot:#ubuntu-release- New: accepted indexed-gzip [amd64] (artful-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted pgsql-ogr-fdw [amd64] (artful-proposed) [1.0.2-2]
-queuebot:#ubuntu-release- New: accepted php-ds [arm64] (artful-proposed) [1.1.8-1]
-queuebot:#ubuntu-release- New: accepted pupnp-1.8 [arm64] (artful-proposed) [1:1.8.0-3]
-queuebot:#ubuntu-release- New: accepted python-biotools [armhf] (artful-proposed) [1.2.12-1]
-queuebot:#ubuntu-release- New: accepted python-django-push-notifications [amd64] (artful-proposed) [1.4.1-1]
-queuebot:#ubuntu-release- New: accepted python-leather [amd64] (artful-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted python-line-profiler [arm64] (artful-proposed) [2.0+ds1-1]
-queuebot:#ubuntu-release- New: accepted python-pweave [amd64] (artful-proposed) [0.25-1]
-queuebot:#ubuntu-release- New: accepted qtdeclarative-render2d-opensource-src [armhf] (artful-proposed) [5.7.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted open-infrastructure-locales-c.utf-8 [amd64] (artful-proposed) [20170410-1]
-queuebot:#ubuntu-release- New: accepted protracker [arm64] (artful-proposed) [2.3d.r10-1]
-queuebot:#ubuntu-release- New: accepted python-django-otp [amd64] (artful-proposed) [0.3.11-1]
-queuebot:#ubuntu-release- New: accepted python-line-profiler [amd64] (artful-proposed) [2.0+ds1-1]
-queuebot:#ubuntu-release- New: accepted qtdeclarative-render2d-opensource-src [arm64] (artful-proposed) [5.7.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ruby-google-protobuf [armhf] (artful-proposed) [3.2.0-1]
-queuebot:#ubuntu-release- New: accepted runcircos-gui [armhf] (artful-proposed) [0.0+20160403-1]
-queuebot:#ubuntu-release- New: accepted sassphp [armhf] (artful-proposed) [0.5.10-2]
-queuebot:#ubuntu-release- New: accepted seafile-client [armhf] (artful-proposed) [6.0.4-1]
-queuebot:#ubuntu-release- New: accepted sniproxy [armhf] (artful-proposed) [0.5.0-2]
-queuebot:#ubuntu-release- New: accepted php-cassandra [amd64] (artful-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted python-jsonpointer [amd64] (artful-proposed) [1.10-1]
-queuebot:#ubuntu-release- New: accepted ruby-google-protobuf [arm64] (artful-proposed) [3.2.0-1]
-queuebot:#ubuntu-release- New: accepted sassphp [arm64] (artful-proposed) [0.5.10-2]
-queuebot:#ubuntu-release- New: accepted sniproxy [arm64] (artful-proposed) [0.5.0-2]
-queuebot:#ubuntu-release- New: accepted stressant [armhf] (artful-proposed) [0.4.0]
-queuebot:#ubuntu-release- New: accepted tnetstring3 [arm64] (artful-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted tnseq-transit [arm64] (artful-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted trnascan-se [arm64] (artful-proposed) [1.3.1-1]
-queuebot:#ubuntu-release- New: accepted uvloop [arm64] (artful-proposed) [0.8.0+ds1-1]
-queuebot:#ubuntu-release- New: accepted pytds [amd64] (artful-proposed) [1.8.2-1]
-queuebot:#ubuntu-release- New: accepted runcircos-gui [arm64] (artful-proposed) [0.0+20160403-1]
-queuebot:#ubuntu-release- New: accepted stressant [arm64] (artful-proposed) [0.4.0]
-queuebot:#ubuntu-release- New binary: butteraugli [s390x] (artful-proposed/universe) [0~20170116-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gfal2 [arm64] (artful-proposed/universe) [2.13.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-blevesearch-segment [amd64] (artful-proposed/universe) [0.0~git20160915.0.762005e-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-bsm-redeo [amd64] (artful-proposed/universe) [0.0~git20160817.0.1ce09fc-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-couchbase-ghistogram [amd64] (artful-proposed/universe) [0.0.0+git20170308.21.d910dd0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-denisenkom-go-mssqldb [amd64] (artful-proposed/universe) [0.0~git20170117.0.9e40d9d-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted seafile-client [arm64] (artful-proposed) [6.0.4-1]
-queuebot:#ubuntu-release- New: accepted vis [arm64] (artful-proposed) [0.3-1]
-queuebot:#ubuntu-release- New binary: gammaray [arm64] (artful-proposed/universe) [2.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-bluebreezecf-opentsdb-goclient [amd64] (artful-proposed/universe) [0.0~git20160515.0.539764b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-cupcake-rdb [amd64] (artful-proposed/universe) [0.0~git20161107.0.43ba341-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-exponent-io-jsonpath [amd64] (artful-proposed/universe) [0.0~git20151013.0.d6023ce-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-facebookgo-freeport [amd64] (artful-proposed/universe) [0.0~git20150612.0.d4adf43-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-facebookgo-subset [amd64] (artful-proposed/universe) [0.0~git20150612.0.8dac2c3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-go-macaron-csrf [amd64] (artful-proposed/universe) [0.0~git20170207.0.428b7c6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-go-openapi-analysis [amd64] (artful-proposed/universe) [0.0~git20160815.0.b44dc87-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted tnseq-transit [armhf] (artful-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New binary: gfal2 [armhf] (artful-proposed/universe) [2.13.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-edsrzf-mmap-go [amd64] (artful-proposed/universe) [0.0~git20160512.0.935e0e8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-facebookgo-stack [amd64] (artful-proposed/universe) [0.0~git20160209.0.7517733-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-go-macaron-toolbox [amd64] (artful-proposed/universe) [0.0~git20170220.0.6766b8f-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-go-xorm-builder [amd64] (artful-proposed/universe) [0.0~git20170224.0.c6e604e-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-gorilla-pat [amd64] (artful-proposed/universe) [0.0~git20160413.0.cf955c3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-issue9-assert [amd64] (artful-proposed/universe) [0.0~git20161202.0.598d99b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-joho-godotenv [amd64] (artful-proposed/universe) [1.1+git20170328.12.325433c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-juju-errors [amd64] (artful-proposed/universe) [0.0~git20160809.0.6f54ff6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bio-tradis [s390x] (artful-proposed/universe) [1.3.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-facebookgo-clock [amd64] (artful-proposed/universe) [0.0~git20150410.0.600d898-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-go-openapi-errors [amd64] (artful-proposed/universe) [0.0~git20160704.0.d24ebc2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-gorilla-securecookie [amd64] (artful-proposed/universe) [1.1+git20170224.6.e59506c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-jroimartin-gocui [amd64] (artful-proposed/universe) [0.3.0+git20170212.45.ed41d1b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ompl [i386] (artful-proposed/universe) [1.2.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pygame [i386] (artful-proposed/universe) [1.9.3+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-gmpy [amd64] (artful-proposed/universe) [1.17-3] (no packageset)
-queuebot:#ubuntu-release- New binary: wolfssl [s390x] (artful-proposed/universe) [3.10.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-bsphere-le-go [amd64] (artful-proposed/universe) [0.0~git20170215.0.7a984a8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-gogits-chardet [amd64] (artful-proposed/universe) [0.0~git20150115.0.2404f77+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ompl [amd64] (artful-proposed/universe) [1.2.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-gmpy2 [amd64] (artful-proposed/universe) [2.0.8-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-go-macaron-bindata [amd64] (artful-proposed/universe) [0.0~git20161222.0.85786f5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pygame [amd64] (artful-proposed/universe) [1.9.3+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-jaytaylor-html2text [amd64] (artful-proposed/universe) [0.0~git20170217.0.24f9b0f-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wolfssl [ppc64el] (artful-proposed/universe) [3.10.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted 4pane [amd64] (artful-proposed) [4.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted adql [amd64] (artful-proposed) [1.3-4]
-queuebot:#ubuntu-release- New: accepted astrodendro [amd64] (artful-proposed) [0.2.0+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted belenios [i386] (artful-proposed) [1.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted bfs [armhf] (artful-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted bgw-replstatus [armhf] (artful-proposed) [1.0.1]
-queuebot:#ubuntu-release- New: accepted bio-tradis [armhf] (artful-proposed) [1.3.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted bitlbee-facebook [armhf] (artful-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted butteraugli [armhf] (artful-proposed) [0~20170116-1]
-queuebot:#ubuntu-release- New: accepted canu [armhf] (artful-proposed) [1.3+dfsg-1]
-queuebot:#ubuntu-release- New: accepted 4pane [i386] (artful-proposed) [4.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted belenios [amd64] (artful-proposed) [1.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted bgw-replstatus [arm64] (artful-proposed) [1.0.1]
-queuebot:#ubuntu-release- New: accepted bitlbee-facebook [arm64] (artful-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted canu [arm64] (artful-proposed) [1.3+dfsg-1]
-queuebot:#ubuntu-release- New: accepted catimg [armhf] (artful-proposed) [2.2.1-1]
-queuebot:#ubuntu-release- New: accepted certspotter [armhf] (artful-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted ciftilib [i386] (artful-proposed) [1.5.1-1]
-queuebot:#ubuntu-release- New: accepted cubicsdr [armhf] (artful-proposed) [0.2.0+git20170310+dfsg-2]
-queuebot:#ubuntu-release- New: accepted deepnano [armhf] (artful-proposed) [0.0+20160706-1]
-queuebot:#ubuntu-release- New: accepted apertium-spa-cat [amd64] (artful-proposed) [2.0.0~r77288-1]
-queuebot:#ubuntu-release- New: accepted bio-tradis [arm64] (artful-proposed) [1.3.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted catimg [arm64] (artful-proposed) [2.2.1-1]
-queuebot:#ubuntu-release- New: accepted ciftilib [amd64] (artful-proposed) [1.5.1-1]
-queuebot:#ubuntu-release- New: accepted deepnano [arm64] (artful-proposed) [0.0+20160706-1]
-queuebot:#ubuntu-release- New: accepted docopt.cpp [arm64] (artful-proposed) [0.6.2-2]
-queuebot:#ubuntu-release- New: accepted drf-extensions [amd64] (artful-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted fontmanager.app [arm64] (artful-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted fonts-naver-d2coding [amd64] (artful-proposed) [1.2-1]
-queuebot:#ubuntu-release- New: accepted fonts-smc-karumbi [amd64] (artful-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted bfs [arm64] (artful-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted certspotter [arm64] (artful-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted django-dirtyfields [amd64] (artful-proposed) [1.2.1-1]
-queuebot:#ubuntu-release- New: accepted eag-healpix [amd64] (artful-proposed) [2017.02.26-2]
-queuebot:#ubuntu-release- New: accepted fonts-smc-chilanka [amd64] (artful-proposed) [1.2.0-1]
-queuebot:#ubuntu-release- New: accepted fonts-smc-manjari [amd64] (artful-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted fzy [arm64] (artful-proposed) [0.9-1]
-queuebot:#ubuntu-release- New: accepted gajim-antispam [amd64] (artful-proposed) [0.4.3-1]
-queuebot:#ubuntu-release- New: accepted golang-github-buger-jsonparser [amd64] (artful-proposed) [0.0~git20170215.0.6bd1670-1]
-queuebot:#ubuntu-release- New: accepted grr-client-templates [amd64] (artful-proposed) [3.1.0.2-1]
-queuebot:#ubuntu-release- New: accepted butteraugli [arm64] (artful-proposed) [0~20170116-1]
-queuebot:#ubuntu-release- New: accepted docopt.cpp [armhf] (artful-proposed) [0.6.2-2]
-queuebot:#ubuntu-release- New: accepted fonts-smc-keraleeyam [amd64] (artful-proposed) [2.0-1]
-queuebot:#ubuntu-release- New: accepted fzy [armhf] (artful-proposed) [0.9-1]
-queuebot:#ubuntu-release- New: accepted golang-github-jinzhu-inflection [amd64] (artful-proposed) [0.0~git20151009.0.3272df6-1]
-queuebot:#ubuntu-release- New: accepted gst-omx [amd64] (artful-proposed) [1.10.4-1]
-queuebot:#ubuntu-release- New: accepted guetzli [arm64] (artful-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted heaptrack [arm64] (artful-proposed) [1.0.0-4]
-queuebot:#ubuntu-release- New: accepted janus [arm64] (artful-proposed) [0.2.2+dfsg-4]
-queuebot:#ubuntu-release- New: accepted jel [amd64] (artful-proposed) [2.1.1-1]
-queuebot:#ubuntu-release- New: accepted cubicsdr [arm64] (artful-proposed) [0.2.0+git20170310+dfsg-2]
-queuebot:#ubuntu-release- New: accepted fonts-smc-uroob [amd64] (artful-proposed) [2.0-1]
-queuebot:#ubuntu-release- New: accepted grr [sync] (artful-proposed) [3.1.0.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted guetzli [armhf] (artful-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted janus [armhf] (artful-proposed) [0.2.2+dfsg-4]
-queuebot:#ubuntu-release- New: accepted kreport [armhf] (artful-proposed) [3.0.0-2]
-queuebot:#ubuntu-release- New: accepted libbloom [armhf] (artful-proposed) [1.4-2]
-queuebot:#ubuntu-release- New: accepted libhtml-gumbo-perl [amd64] (artful-proposed) [0.17-1]
-queuebot:#ubuntu-release- New: accepted libhttp-server-simple-cgi-prefork-perl [amd64] (artful-proposed) [6-1]
-queuebot:#ubuntu-release- New: accepted libmojo-jwt-perl [amd64] (artful-proposed) [0.05-1]
-queuebot:#ubuntu-release- New: accepted fontmanager.app [armhf] (artful-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted libnet-prometheus-perl [amd64] (artful-proposed) [0.05-1]
-queuebot:#ubuntu-release- New: accepted libpod-weaver-section-generatesection-perl [amd64] (artful-proposed) [1.06-1]
-queuebot:#ubuntu-release- New: accepted mptp [armhf] (artful-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted node-argv [amd64] (artful-proposed) [0.0.2-1]
-queuebot:#ubuntu-release- New: accepted node-binary-extensions [amd64] (artful-proposed) [1.8.0-1]
-queuebot:#ubuntu-release- New: accepted node-browser-resolve [amd64] (artful-proposed) [1.11.2-1]
-queuebot:#ubuntu-release- New: accepted node-des.js [amd64] (artful-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted node-hash.js [amd64] (artful-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted heaptrack [armhf] (artful-proposed) [1.0.0-4]
-queuebot:#ubuntu-release- New: accepted libnexstar [armhf] (artful-proposed) [0.15-1]
-queuebot:#ubuntu-release- New: accepted node-anymatch [amd64] (artful-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted node-boom [amd64] (artful-proposed) [4.3.1-1]
-queuebot:#ubuntu-release- New: accepted node-hash-test-vectors [amd64] (artful-proposed) [1.3.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ompl [arm64] (artful-proposed) [1.2.1+ds1-1]
-queuebot:#ubuntu-release- New: accepted open-ath9k-htc-firmware [amd64] (artful-proposed) [1.4.0-81-gf206e56+dfsg-1]
-queuebot:#ubuntu-release- New: accepted python-django-extra-views [amd64] (artful-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted python-ltfatpy [amd64] (artful-proposed) [1.0.8-1]
-queuebot:#ubuntu-release- New: accepted python-rpaths [amd64] (artful-proposed) [0.13-1]
-queuebot:#ubuntu-release- New: accepted libhtml-gumbo-perl [i386] (artful-proposed) [0.17-1]
-queuebot:#ubuntu-release- New: accepted node-assert-plus [amd64] (artful-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted node-https-browserify [amd64] (artful-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted pygame [armhf] (artful-proposed) [1.9.3+dfsg-2]
-queuebot:#ubuntu-release- New: accepted python-pydap [amd64] (artful-proposed) [3.2.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rematch [amd64] (artful-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted repetier-host [amd64] (artful-proposed) [0.85+dfsg-2]
-queuebot:#ubuntu-release- New: accepted skyview [amd64] (artful-proposed) [3.2.3+repack-1]
-queuebot:#ubuntu-release- New: accepted spyder-memory-profiler [amd64] (artful-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted starjava-pal [amd64] (artful-proposed) [1.0.1+2016.08.11-1]
-queuebot:#ubuntu-release- New: accepted litmus [sync] (artful-proposed) [0.13-1]
-queuebot:#ubuntu-release- New: accepted ompl [armhf] (artful-proposed) [1.2.1+ds1-1]
-queuebot:#ubuntu-release- New: accepted python-xapian-haystack [amd64] (artful-proposed) [2.1.0-2]
-queuebot:#ubuntu-release- New: accepted scap-security-guide [amd64] (artful-proposed) [0.1.31-3]
-queuebot:#ubuntu-release- New: accepted spyder-unittest [amd64] (artful-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted starjava-util [amd64] (artful-proposed) [1.0+2017.03.17-1]
-queuebot:#ubuntu-release- New: accepted systray-mdstat [amd64] (artful-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted trnascan-se [i386] (artful-proposed) [1.3.1-1]
-queuebot:#ubuntu-release- New: accepted vibe.d [amd64] (artful-proposed) [0.7.30-1]
-queuebot:#ubuntu-release- New: accepted wolfssl [armhf] (artful-proposed) [3.10.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted node-constants-browserify [amd64] (artful-proposed) [1.0.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-viridislite [amd64] (artful-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted starjava-registry [amd64] (artful-proposed) [1.2+2016.05.03-1]
-queuebot:#ubuntu-release- New: accepted trnascan-se [amd64] (artful-proposed) [1.3.1-1]
-queuebot:#ubuntu-release- New: accepted wolfssl [arm64] (artful-proposed) [3.10.2+dfsg-2]
-queuebot:#ubuntu-release- New binary: golang-github-syndtr-goleveldb [amd64] (artful-proposed/universe) [0.0~git20170302.0.3c5717c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-vmware-photon-controller-go-sdk [amd64] (artful-proposed/universe) [0.0~PROMOTED-339-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-xanzy-go-cloudstack [amd64] (artful-proposed/universe) [2.1.1+git20160728.1.1e2cbf6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-golang-x-sync [amd64] (artful-proposed/universe) [0.0~git20170317.0.5a06fca-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gopkg-editorconfig-editorconfig-core-go.v1 [amd64] (artful-proposed/universe) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-line-profiler [i386] (artful-proposed) [2.0+ds1-1]
-queuebot:#ubuntu-release- New: accepted svgwrite [sync] (artful-proposed) [1.1.8-2]
-queuebot:#ubuntu-release- New: accepted zabbix-cli [amd64] (artful-proposed) [1.6.1-1]
-queuebot:#ubuntu-release- New binary: golang-github-willf-bitset [amd64] (artful-proposed/universe) [1.0.0+git20161202.88.5c3c0fc-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gopkg-alexcesaro-quotedprintable.v3 [amd64] (artful-proposed/universe) [0.0~git20150716.0.2caba25-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gopkg-jarcoal-httpmock.v1 [amd64] (artful-proposed/universe) [0.0~git20170321.0.abbf154-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-honnef-go-augeas [amd64] (artful-proposed/universe) [0.0~git20161110.0.ca62e35-1] (no packageset)
-queuebot:#ubuntu-release- New source: gtk+4.0 (artful-proposed/primary) [3.90.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: guetzli [i386] (artful-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hikaricp [amd64] (artful-proposed/universe) [2.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted sortedcollections [amd64] (artful-proposed) [0.5.3-1]
-queuebot:#ubuntu-release- New binary: javafxsvg [amd64] (artful-proposed/universe) [1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ldcofonts [amd64] (artful-proposed/universe) [1.0.0.part3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libnexstar [amd64] (artful-proposed/universe) [0.15-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libundead [i386] (artful-proposed/universe) [1.0.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: litmus [s390x] (artful-proposed/none) [0.13-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ompl [s390x] (artful-proposed/universe) [1.2.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-yohcop-openid-go [amd64] (artful-proposed/universe) [0.0~git20170224.0.fa274ac-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kreport [i386] (artful-proposed/universe) [3.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: librandom123 [amd64] (artful-proposed/universe) [1.09+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ompl [ppc64el] (artful-proposed/universe) [1.2.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: guetzli [amd64] (artful-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: litmus [ppc64el] (artful-proposed/none) [0.13-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbloom [i386] (artful-proposed/universe) [1.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: svgwrite [amd64] (artful-proposed/none) [1.1.8-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted heaptrack [amd64] (artful-proposed) [1.0.0-4]
-queuebot:#ubuntu-release- New: accepted hikaricp [amd64] (artful-proposed) [2.6.0-1]
-queuebot:#ubuntu-release- New: accepted janus [i386] (artful-proposed) [0.2.2+dfsg-4]
-queuebot:#ubuntu-release- New: accepted libclasslojure-clojure [amd64] (artful-proposed) [0.7.1-2]
-queuebot:#ubuntu-release- New: accepted libundead [amd64] (artful-proposed) [1.0.6-2]
-queuebot:#ubuntu-release- New: accepted litmus [ppc64el] (artful-proposed) [0.13-1]
-queuebot:#ubuntu-release- New: accepted lockdown [amd64] (artful-proposed) [0.2]
-queuebot:#ubuntu-release- New: accepted minetest-mod-homedecor [amd64] (artful-proposed) [0.4.15-1]
-queuebot:#ubuntu-release- New: accepted mlv [amd64] (artful-proposed) [3.1.0-1]
-queuebot:#ubuntu-release- New: accepted mocker-el [amd64] (artful-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted heaptrack [i386] (artful-proposed) [1.0.0-4]
-queuebot:#ubuntu-release- New: accepted lgooddatepicker [amd64] (artful-proposed) [8.3.0+ds-1]
-queuebot:#ubuntu-release- New: accepted libundead [i386] (artful-proposed) [1.0.6-2]
-queuebot:#ubuntu-release- New: accepted minetest-mod-craftguide [amd64] (artful-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted mlv [i386] (artful-proposed) [3.1.0-1]
-queuebot:#ubuntu-release- New: accepted mptp [i386] (artful-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted mrboom [i386] (artful-proposed) [3.1.127-1]
-queuebot:#ubuntu-release- New: accepted node-brorand [amd64] (artful-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted node-hoek [amd64] (artful-proposed) [4.1.0-2]
-queuebot:#ubuntu-release- New: accepted nose-el [amd64] (artful-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted janus [amd64] (artful-proposed) [0.2.2+dfsg-4]
-queuebot:#ubuntu-release- New: accepted litmus [s390x] (artful-proposed) [0.13-1]
-queuebot:#ubuntu-release- New: accepted mptp [amd64] (artful-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted node-bn.js [amd64] (artful-proposed) [4.11.6-2]
-queuebot:#ubuntu-release- New: accepted node-tweetnacl [amd64] (artful-proposed) [0.14.5+dfsg-2]
-queuebot:#ubuntu-release- New: accepted octave-sparsersb [i386] (artful-proposed) [1.0.5-1]
-queuebot:#ubuntu-release- New: accepted orthanc-wsi [amd64] (artful-proposed) [0.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted paleomix [amd64] (artful-proposed) [1.2.7-1]
-queuebot:#ubuntu-release- New: accepted pgaudit [amd64] (artful-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted php-ds [amd64] (artful-proposed) [1.1.8-1]
-queuebot:#ubuntu-release- New: accepted libsmali-1-java [amd64] (artful-proposed) [1.4.2-1]
-queuebot:#ubuntu-release- New: accepted mrboom [amd64] (artful-proposed) [3.1.127-1]
-queuebot:#ubuntu-release- New: accepted octave-sparsersb [amd64] (artful-proposed) [1.0.5-1]
-queuebot:#ubuntu-release- New: accepted orthanc-wsi [i386] (artful-proposed) [0.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted pgaudit [i386] (artful-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted protracker [amd64] (artful-proposed) [2.3d.r10-1]
-queuebot:#ubuntu-release- New: accepted pupnp-1.8 [amd64] (artful-proposed) [1:1.8.0-3]
-queuebot:#ubuntu-release- New: accepted pyicloud [amd64] (artful-proposed) [0.9.1-2]
-queuebot:#ubuntu-release- New: accepted pytest-mpl [amd64] (artful-proposed) [0.7-2]
-queuebot:#ubuntu-release- New: accepted python-biotools [i386] (artful-proposed) [1.2.12-1]
-queuebot:#ubuntu-release- New: accepted minetest-mod-unifieddyes [amd64] (artful-proposed) [0.4.15-1]
-queuebot:#ubuntu-release- New: accepted opensvc [amd64] (artful-proposed) [1.8~20170412-1]
-queuebot:#ubuntu-release- New: accepted php-ds [i386] (artful-proposed) [1.1.8-1]
-queuebot:#ubuntu-release- New: accepted pupnp-1.8 [i386] (artful-proposed) [1:1.8.0-3]
-queuebot:#ubuntu-release- New: accepted python-biotools [amd64] (artful-proposed) [1.2.12-1]
-queuebot:#ubuntu-release- New: accepted python-dbfread [amd64] (artful-proposed) [2.0.7-2]
-queuebot:#ubuntu-release- New: accepted python-engineio [amd64] (artful-proposed) [1.3.1-1]
-queuebot:#ubuntu-release- New: accepted python-holidays [amd64] (artful-proposed) [0.8.1-1]
-queuebot:#ubuntu-release- New: accepted python-pgpy [amd64] (artful-proposed) [0.4.1-2]
-queuebot:#ubuntu-release- New: accepted python-xopen [amd64] (artful-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted node-combine-source-map [amd64] (artful-proposed) [0.8.0+ds-4]
-queuebot:#ubuntu-release- New: accepted protracker [i386] (artful-proposed) [2.3d.r10-1]
-queuebot:#ubuntu-release- New: accepted python-btrfs [amd64] (artful-proposed) [6-2]
-queuebot:#ubuntu-release- New: accepted python-gbulb [amd64] (artful-proposed) [0.5.3-2]
-queuebot:#ubuntu-release- New: accepted python-pyqrcode [amd64] (artful-proposed) [1.2.1-1]
-queuebot:#ubuntu-release- New: accepted qtdeclarative-render2d-opensource-src [amd64] (artful-proposed) [5.7.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-calibrate [amd64] (artful-proposed) [1.7.2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-miniui [amd64] (artful-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-snowballc [amd64] (artful-proposed) [0.5.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-survey [amd64] (artful-proposed) [3.31-5-1]
-queuebot:#ubuntu-release- New: accepted pftools [amd64] (artful-proposed) [3+dfsg-2]
-queuebot:#ubuntu-release- New: accepted python-dnslib [amd64] (artful-proposed) [0.9.7+hg20170303-1]
-queuebot:#ubuntu-release- New: accepted qcumber [amd64] (artful-proposed) [1.0.14+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-crul [amd64] (artful-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-snowballc [i386] (artful-proposed) [0.5.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-v8 [i386] (artful-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted ruby-ddplugin [amd64] (artful-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted ruby-google-protobuf [amd64] (artful-proposed) [3.2.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-jar-dependencies [amd64] (artful-proposed) [0.3.10-1]
-queuebot:#ubuntu-release- New: accepted ruby-rails-assets-underscore [amd64] (artful-proposed) [1.8.3+dfsg-1]
-queuebot:#ubuntu-release- New: accepted rubocop [amd64] (artful-proposed) [0.48.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted runcircos-gui [amd64] (artful-proposed) [0.0+20160403-1]
-queuebot:#ubuntu-release- New: accepted seafile-client [amd64] (artful-proposed) [6.0.4-1]
-queuebot:#ubuntu-release- New: accepted sniproxy [i386] (artful-proposed) [0.5.0-2]
-queuebot:#ubuntu-release- New: accepted svgwrite [amd64] (artful-proposed) [1.1.8-2]
-queuebot:#ubuntu-release- New: accepted tdiary-style-rd [amd64] (artful-proposed) [0.0.3-1]
-queuebot:#ubuntu-release- New: accepted tilix [amd64] (artful-proposed) [1.5.4-1]
-queuebot:#ubuntu-release- New: accepted tnetstring3 [amd64] (artful-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted tnseq-transit [amd64] (artful-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-pwt9 [amd64] (artful-proposed) [9.0-0-1]
-queuebot:#ubuntu-release- New: accepted sassphp [amd64] (artful-proposed) [0.5.10-2]
-queuebot:#ubuntu-release- New: accepted stressant [i386] (artful-proposed) [0.4.0]
-queuebot:#ubuntu-release- New: accepted tigris [amd64] (artful-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted tnetstring3 [i386] (artful-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted tools-nrepl-clojure [amd64] (artful-proposed) [0.2.12-1]
-queuebot:#ubuntu-release- New: accepted tools-trace-clojure [amd64] (artful-proposed) [0.7.9-1]
-queuebot:#ubuntu-release- New: accepted unsafe-fences [amd64] (artful-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted uvloop [i386] (artful-proposed) [0.8.0+ds1-1]
-queuebot:#ubuntu-release- New: accepted vim-ledger [amd64] (artful-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-google-protobuf [i386] (artful-proposed) [3.2.0-1]
-queuebot:#ubuntu-release- New: accepted tdiary-style-gfm [amd64] (artful-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted tnseq-transit [i386] (artful-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted typesafe-config [amd64] (artful-proposed) [1.3.1-2]
-queuebot:#ubuntu-release- New: accepted vibe.d [i386] (artful-proposed) [0.7.30-1]
-queuebot:#ubuntu-release- New: accepted vis [i386] (artful-proposed) [0.3-1]
-queuebot:#ubuntu-release- New binary: bfs [ppc64el] (artful-proposed/universe) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bgw-replstatus [s390x] (artful-proposed/universe) [1.0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: bio-tradis [s390x] (artful-proposed/universe) [1.3.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bitlbee-facebook [s390x] (artful-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted seqsero [amd64] (artful-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted tools-reader-clojure [amd64] (artful-proposed) [1.0.0~beta2-1]
-queuebot:#ubuntu-release- New: accepted vis [amd64] (artful-proposed) [0.3-1]
-queuebot:#ubuntu-release- New binary: bgw-replstatus [ppc64el] (artful-proposed/universe) [1.0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: bitlbee-facebook [ppc64el] (artful-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: butteraugli [s390x] (artful-proposed/universe) [0~20170116-1] (no packageset)
-queuebot:#ubuntu-release- New binary: canu [s390x] (artful-proposed/universe) [1.3+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: catimg [s390x] (artful-proposed/universe) [2.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: certspotter [s390x] (artful-proposed/universe) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepnano [ppc64el] (artful-proposed/universe) [0.0+20160706-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted tilix [i386] (artful-proposed) [1.5.4-1]
-queuebot:#ubuntu-release- New: accepted xtensor [amd64] (artful-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New binary: butteraugli [ppc64el] (artful-proposed/universe) [0~20170116-1] (no packageset)
-queuebot:#ubuntu-release- New binary: catimg [ppc64el] (artful-proposed/universe) [2.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cubicsdr [s390x] (artful-proposed/universe) [0.2.0+git20170310+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: docopt.cpp [ppc64el] (artful-proposed/universe) [0.6.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: fontmanager.app [ppc64el] (artful-proposed/universe) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fzy [ppc64el] (artful-proposed/universe) [0.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gfal2 [armhf] (artful-proposed/universe) [2.13.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-gorilla-pat [amd64] (artful-proposed/universe) [0.0~git20160413.0.cf955c3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted uvloop [amd64] (artful-proposed) [0.8.0+ds1-1]
-queuebot:#ubuntu-release- New binary: canu [ppc64el] (artful-proposed/universe) [1.3+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepnano [s390x] (artful-proposed/universe) [0.0+20160706-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fontmanager.app [s390x] (artful-proposed/universe) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-gogits-chardet [amd64] (artful-proposed/universe) [0.0~git20150115.0.2404f77+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-issue9-assert [amd64] (artful-proposed/universe) [0.0~git20161202.0.598d99b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-joho-godotenv [amd64] (artful-proposed/universe) [1.1+git20170328.12.325433c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-juju-errors [amd64] (artful-proposed/universe) [0.0~git20160809.0.6f54ff6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-kubernetes-gengo [amd64] (artful-proposed/universe) [0.0~git20161024.0.6a1c24d-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-lpabon-godbc [amd64] (artful-proposed/universe) [1.0+git20140613.1.9577782-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-jaytaylor-html2text [amd64] (artful-proposed/universe) [0.0~git20170217.0.24f9b0f-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-lunny-log [amd64] (artful-proposed/universe) [0.0~git20160921.0.7887c61-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-msteinert-pam [amd64] (artful-proposed/universe) [0.0~git20151204.0.02ccfbf-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-neowaylabs-wabbit [amd64] (artful-proposed/universe) [0.0~git20170406.0.cfb5237-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-ngaut-sync2 [amd64] (artful-proposed/universe) [0.0~git20141008.0.7a24ed7-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-pingcap-check [amd64] (artful-proposed/universe) [0.0~git20161122.0.9b26663-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-pquerna-otp [amd64] (artful-proposed/universe) [0.0~git20170223.0.9e19353-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-renstrom-dedent [amd64] (artful-proposed/universe) [1.0.0+git20150819.3.020d11c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: guetzli [s390x] (artful-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fzy [s390x] (artful-proposed/universe) [0.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-mcuadros-go-version [amd64] (artful-proposed/universe) [0.0~git20161105.0.257f7b9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-ngaut-log [amd64] (artful-proposed/universe) [0.0~git20170217.0.1c9fb4d-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-pkg-xattr [amd64] (artful-proposed/universe) [0.2.0+git20170313.4.2c7218a-1] (no packageset)
-queuebot:#ubuntu-release- New binary: grr [arm64] (artful-proposed/none) [3.1.0.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: wolfssl [ppc64el] (artful-proposed/universe) [3.10.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted canu [i386] (artful-proposed) [1.3+dfsg-1]
-queuebot:#ubuntu-release- New: accepted cubicsdr [amd64] (artful-proposed) [0.2.0+git20170310+dfsg-2]
-queuebot:#ubuntu-release- New: accepted deepnano [amd64] (artful-proposed) [0.0+20160706-1]
-queuebot:#ubuntu-release- New: accepted dired-quick-sort [amd64] (artful-proposed) [0.1-1]
-queuebot:#ubuntu-release- New binary: golang-github-kisielk-gotool [amd64] (artful-proposed/universe) [0.0~git20161130.0.0de1eaf-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-petar-gollrb [amd64] (artful-proposed/universe) [0.0~git20130427.0.53be0d3+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbloom [s390x] (artful-proposed/universe) [1.4-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted certspotter [amd64] (artful-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted deepnano [i386] (artful-proposed) [0.0+20160706-1]
-queuebot:#ubuntu-release- New: accepted docopt.cpp [i386] (artful-proposed) [0.6.2-2]
-queuebot:#ubuntu-release- New: accepted elisp-bug-hunter [amd64] (artful-proposed) [1.3.1+repack-1]
-queuebot:#ubuntu-release- New: accepted examl [amd64] (artful-proposed) [3.0.18-2]
-queuebot:#ubuntu-release- New: accepted fasd [amd64] (artful-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted fontmanager.app [amd64] (artful-proposed) [0.1-1]
-queuebot:#ubuntu-release- New binary: golang-github-neelance-astrewrite [amd64] (artful-proposed/universe) [0.0~git20160511.0.9934826-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted canu [amd64] (artful-proposed) [1.3+dfsg-1]
-queuebot:#ubuntu-release- New: accepted docopt.cpp [amd64] (artful-proposed) [0.6.2-2]
-queuebot:#ubuntu-release- New: accepted emacs-git-modes [amd64] (artful-proposed) [1.2.4-1]
-queuebot:#ubuntu-release- New: accepted fenrir [amd64] (artful-proposed) [1.05-1]
-queuebot:#ubuntu-release- New: accepted fonts-bebas-neue [amd64] (artful-proposed) [3.0-1]
-queuebot:#ubuntu-release- New: accepted fonts-monlam [amd64] (artful-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted fonts-smc-dyuthi [amd64] (artful-proposed) [2.0-1]
-queuebot:#ubuntu-release- New: accepted fonts-smc-rachana [amd64] (artful-proposed) [7.0-1]
-queuebot:#ubuntu-release- New: accepted fonts-smc-suruma [amd64] (artful-proposed) [3.2.1-1]
-queuebot:#ubuntu-release- New binary: golang-github-quobyte-api [amd64] (artful-proposed/universe) [0.0~git20160913.0.bf713b5-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted el-x [amd64] (artful-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted fontmanager.app [i386] (artful-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted fonts-smc-anjalioldlipi [amd64] (artful-proposed) [7.0-1]
-queuebot:#ubuntu-release- New: accepted fonts-smc-raghumalayalamsans [amd64] (artful-proposed) [2.1.1-1]
-queuebot:#ubuntu-release- New: accepted fzy [i386] (artful-proposed) [0.9-1]
-queuebot:#ubuntu-release- New: accepted gitsome [amd64] (artful-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-blevesearch-go-porterstemmer [amd64] (artful-proposed) [1.0.1+git20141230.9.23a2c8e-2]
-queuebot:#ubuntu-release- New: accepted golang-github-bluebreezecf-opentsdb-goclient [amd64] (artful-proposed) [0.0~git20160515.0.539764b-1]
-queuebot:#ubuntu-release- New: accepted golang-github-bsphere-le-go [amd64] (artful-proposed) [0.0~git20170215.0.7a984a8-1]
-queuebot:#ubuntu-release- New: accepted cubicsdr [i386] (artful-proposed) [0.2.0+git20170310+dfsg-2]
-queuebot:#ubuntu-release- New: accepted fonts-blankenburg [amd64] (artful-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted fzy [amd64] (artful-proposed) [0.9-1]
-queuebot:#ubuntu-release- New: accepted golang-code.gitea-sdk [amd64] (artful-proposed) [0.0~git20170322.0.1bec42c-1]
-queuebot:#ubuntu-release- New: accepted golang-github-bsm-redeo [amd64] (artful-proposed) [0.0~git20160817.0.1ce09fc-1]
-queuebot:#ubuntu-release- New: accepted golang-github-cupcake-rdb [amd64] (artful-proposed) [0.0~git20161107.0.43ba341-2]
-queuebot:#ubuntu-release- New: accepted golang-github-edsrzf-mmap-go [amd64] (artful-proposed) [0.0~git20160512.0.935e0e8-1]
-queuebot:#ubuntu-release- New: accepted golang-github-facebookgo-clock [amd64] (artful-proposed) [0.0~git20150410.0.600d898-1]
-queuebot:#ubuntu-release- New: accepted golang-github-facebookgo-stack [amd64] (artful-proposed) [0.0~git20160209.0.7517733-2]
-queuebot:#ubuntu-release- New: accepted golang-github-go-macaron-bindata [amd64] (artful-proposed) [0.0~git20161222.0.85786f5-1]
-queuebot:#ubuntu-release- New: accepted golang-github-denisenkom-go-mssqldb [amd64] (artful-proposed) [0.0~git20170117.0.9e40d9d-2]
-queuebot:#ubuntu-release- New: accepted golang-github-go-macaron-csrf [amd64] (artful-proposed) [0.0~git20170207.0.428b7c6-1]
-queuebot:#ubuntu-release- New: accepted golang-github-go-xorm-builder [amd64] (artful-proposed) [0.0~git20170224.0.c6e604e-1]
-queuebot:#ubuntu-release- New: accepted golang-github-hillu-go-yara [amd64] (artful-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted golang-github-joho-godotenv [amd64] (artful-proposed) [1.1+git20170328.12.325433c-1]
-queuebot:#ubuntu-release- New: accepted golang-github-juju-errors [amd64] (artful-proposed) [0.0~git20160809.0.6f54ff6-2]
-queuebot:#ubuntu-release- New: accepted golang-github-kubernetes-gengo [amd64] (artful-proposed) [0.0~git20161024.0.6a1c24d-1]
-queuebot:#ubuntu-release- New: accepted golang-github-lpabon-godbc [amd64] (artful-proposed) [1.0+git20140613.1.9577782-1]
-queuebot:#ubuntu-release- New: accepted golang-github-makenowjust-heredoc [amd64] (artful-proposed) [0.0~git20140704.0.1d91351-1]
-queuebot:#ubuntu-release- New: accepted golang-github-blevesearch-segment [amd64] (artful-proposed) [0.0~git20160915.0.762005e-2]
-queuebot:#ubuntu-release- New: accepted golang-github-go-openapi-analysis [amd64] (artful-proposed) [0.0~git20160815.0.b44dc87-1]
-queuebot:#ubuntu-release- New: accepted golang-github-jaytaylor-html2text [amd64] (artful-proposed) [0.0~git20170217.0.24f9b0f-1]
-queuebot:#ubuntu-release- New: accepted golang-github-kisielk-gotool [amd64] (artful-proposed) [0.0~git20161130.0.0de1eaf-1]
-queuebot:#ubuntu-release- New: accepted golang-github-lunny-log [amd64] (artful-proposed) [0.0~git20160921.0.7887c61-2]
-queuebot:#ubuntu-release- New: accepted golang-github-mrjones-oauth [amd64] (artful-proposed) [0.0~git20170225.0.3f67d9c-1]
-queuebot:#ubuntu-release- New: accepted golang-github-nbutton23-zxcvbn-go [amd64] (artful-proposed) [0.0~git20160627.0.a22cb81-1]
-queuebot:#ubuntu-release- New: accepted golang-github-neelance-sourcemap [amd64] (artful-proposed) [0.0~git20151028.0.8c68805-1]
-queuebot:#ubuntu-release- New: accepted golang-github-ngaut-deadline [amd64] (artful-proposed) [0.0~git20170224.0.71c16b1-3]
-queuebot:#ubuntu-release- New: accepted golang-github-ngaut-sync2 [amd64] (artful-proposed) [0.0~git20141008.0.7a24ed7-2]
-queuebot:#ubuntu-release- New: accepted golang-github-facebookgo-freeport [amd64] (artful-proposed) [0.0~git20150612.0.d4adf43-1]
-queuebot:#ubuntu-release- New: accepted golang-github-jroimartin-gocui [amd64] (artful-proposed) [0.3.0+git20170212.45.ed41d1b-1]
-queuebot:#ubuntu-release- New: accepted golang-github-mcuadros-go-version [amd64] (artful-proposed) [0.0~git20161105.0.257f7b9-1]
-queuebot:#ubuntu-release- New: accepted golang-github-neelance-astrewrite [amd64] (artful-proposed) [0.0~git20160511.0.9934826-1]
-queuebot:#ubuntu-release- New: accepted golang-github-ngaut-log [amd64] (artful-proposed) [0.0~git20170217.0.1c9fb4d-1]
-queuebot:#ubuntu-release- New: accepted golang-github-pingcap-check [amd64] (artful-proposed) [0.0~git20161122.0.9b26663-1]
-queuebot:#ubuntu-release- New: accepted golang-github-pquerna-otp [amd64] (artful-proposed) [0.0~git20170223.0.9e19353-1]
-queuebot:#ubuntu-release- New: accepted golang-github-renstrom-dedent [amd64] (artful-proposed) [1.0.0+git20150819.3.020d11c-1]
-queuebot:#ubuntu-release- New: accepted golang-github-sergi-go-diff [amd64] (artful-proposed) [0.0~git20170118.0.24e2351-2]
-queuebot:#ubuntu-release- New: accepted golang-github-siddontang-go [amd64] (artful-proposed) [0.0~git20161005.0.1e9ce2a-1]
-queuebot:#ubuntu-release- New: accepted golang-github-gorilla-pat [amd64] (artful-proposed) [0.0~git20160413.0.cf955c3-1]
-queuebot:#ubuntu-release- New: accepted golang-github-msteinert-pam [amd64] (artful-proposed) [0.0~git20151204.0.02ccfbf-1]
-queuebot:#ubuntu-release- New: accepted golang-github-petar-gollrb [amd64] (artful-proposed) [0.0~git20130427.0.53be0d3+dfsg-1]
-queuebot:#ubuntu-release- New: accepted golang-github-quobyte-api [amd64] (artful-proposed) [0.0~git20160913.0.bf713b5-1]
-queuebot:#ubuntu-release- New: accepted golang-github-siddontang-go-snappy [amd64] (artful-proposed) [0.0~git20140704.0.d8f7bb8-1]
-queuebot:#ubuntu-release- New: accepted golang-github-syndtr-goleveldb [amd64] (artful-proposed) [0.0~git20170302.0.3c5717c-1]
-queuebot:#ubuntu-release- New: accepted golang-github-unknwon-cae [amd64] (artful-proposed) [0.0~git20160715.0.c6aac99-1]
-queuebot:#ubuntu-release- New: accepted golang-github-unknwon-paginater [amd64] (artful-proposed) [0.0~git20170205.0.7650849-2]
-queuebot:#ubuntu-release- New: accepted golang-github-willf-bitset [amd64] (artful-proposed) [1.0.0+git20161202.88.5c3c0fc-1]
-queuebot:#ubuntu-release- New: accepted golang-github-yohcop-openid-go [amd64] (artful-proposed) [0.0~git20170224.0.fa274ac-1]
-queuebot:#ubuntu-release- New: accepted golang-github-leemcloughlin-gofarmhash [amd64] (artful-proposed) [0.0~git20160919.0.0a055c5-1]
-queuebot:#ubuntu-release- New: accepted golang-github-pkg-xattr [amd64] (artful-proposed) [0.2.0+git20170313.4.2c7218a-1]
-queuebot:#ubuntu-release- New: accepted golang-github-steveyen-gtreap [amd64] (artful-proposed) [0.0~git20150807.0.0abe01e-1]
-queuebot:#ubuntu-release- New: accepted golang-github-unknwon-i18n [amd64] (artful-proposed) [0.0~git20170218.0.8372b90-2]
-queuebot:#ubuntu-release- New: accepted golang-github-xanzy-go-cloudstack [amd64] (artful-proposed) [2.1.1+git20160728.1.1e2cbf6-1]
-queuebot:#ubuntu-release- New: accepted golang-gopkg-alexcesaro-quotedprintable.v3 [amd64] (artful-proposed) [0.0~git20150716.0.2caba25-1]
-queuebot:#ubuntu-release- New: accepted golang-gopkg-gomail.v2 [amd64] (artful-proposed) [2.0.0+git20160411.23.81ebce5-1]
-queuebot:#ubuntu-release- New: accepted golang-gopkg-olivere-elastic.v3 [amd64] (artful-proposed) [3.0.41-1]
-queuebot:#ubuntu-release- New: accepted golang-strk.kbt-projects-go-libravatar [amd64] (artful-proposed) [0.0~git20161111.0.d628b68-1]
-queuebot:#ubuntu-release- New: accepted guetzli [amd64] (artful-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-neowaylabs-wabbit [amd64] (artful-proposed) [0.0~git20170406.0.cfb5237-1]
-queuebot:#ubuntu-release- New: accepted golang-github-twinj-uuid [amd64] (artful-proposed) [0.10.0+git20160909.96.7bbe408-1]
-queuebot:#ubuntu-release- New: accepted golang-golang-x-sync [amd64] (artful-proposed) [0.0~git20170317.0.5a06fca-1]
-queuebot:#ubuntu-release- New: accepted golang-gopkg-jarcoal-httpmock.v1 [amd64] (artful-proposed) [0.0~git20170321.0.abbf154-1]
-queuebot:#ubuntu-release- New: accepted grr [arm64] (artful-proposed) [3.1.0.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted javafxsvg [amd64] (artful-proposed) [1.2.1-1]
-queuebot:#ubuntu-release- New: accepted kreport [i386] (artful-proposed) [3.0.0-2]
-queuebot:#ubuntu-release- New: accepted ldcofonts [amd64] (artful-proposed) [1.0.0.part3-1]
-queuebot:#ubuntu-release- New: accepted libbloom [i386] (artful-proposed) [1.4-2]
-queuebot:#ubuntu-release- New: accepted libnexstar [i386] (artful-proposed) [0.15-1]
-queuebot:#ubuntu-release- New: accepted kreport [amd64] (artful-proposed) [3.0.0-2]
-queuebot:#ubuntu-release- New: accepted librandom123 [amd64] (artful-proposed) [1.09+dfsg-1]
-queuebot:#ubuntu-release- New binary: gst-omx [s390x] (artful-proposed/universe) [1.10.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: orthanc-wsi [ppc64el] (artful-proposed/universe) [0.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php-cassandra [s390x] (artful-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-line-profiler [s390x] (artful-proposed/universe) [2.0+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-v8 [ppc64el] (artful-proposed/universe) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: runcircos-gui [ppc64el] (artful-proposed/universe) [0.0+20160403-1] (no packageset)
-queuebot:#ubuntu-release- New binary: seafile-client [ppc64el] (artful-proposed/universe) [6.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-honnef-go-augeas [amd64] (artful-proposed) [0.0~git20161110.0.ca62e35-1]
-queuebot:#ubuntu-release- New binary: ciftilib [ppc64el] (artful-proposed/universe) [1.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pgsql-ogr-fdw [s390x] (artful-proposed/universe) [1.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-snowballc [ppc64el] (artful-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sassphp [ppc64el] (artful-proposed/universe) [0.5.10-2] (no packageset)
-queuebot:#ubuntu-release- New binary: sniproxy [ppc64el] (artful-proposed/universe) [0.5.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: tnetstring3 [ppc64el] (artful-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tnseq-transit [s390x] (artful-proposed/universe) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: uvloop [ppc64el] (artful-proposed/universe) [0.8.0+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vis [ppc64el] (artful-proposed/universe) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libbloom [amd64] (artful-proposed) [1.4-2]
-queuebot:#ubuntu-release- New binary: protracker [s390x] (artful-proposed/universe) [2.3d.r10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: seafile-client [s390x] (artful-proposed/universe) [6.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tnseq-transit [ppc64el] (artful-proposed/universe) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: uvloop [s390x] (artful-proposed/universe) [0.8.0+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted 4pane [ppc64el] (artful-proposed) [4.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted aiohttp-cors [amd64] (artful-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted belenios [ppc64el] (artful-proposed) [1.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted bfs [i386] (artful-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted bgw-replstatus [i386] (artful-proposed) [1.0.1]
-queuebot:#ubuntu-release- New binary: hfst-ospell [armhf] (artful-proposed/universe) [0.4.3~r338-1] (no packageset)
-queuebot:#ubuntu-release- New binary: stressant [ppc64el] (artful-proposed/universe) [0.4.0] (no packageset)
-queuebot:#ubuntu-release- New binary: vis [s390x] (artful-proposed/universe) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted android-sdk-helper [amd64] (artful-proposed) [0.1]
-queuebot:#ubuntu-release- New: accepted bgw-replstatus [amd64] (artful-proposed) [1.0.1]
-queuebot:#ubuntu-release- New: accepted bio-tradis [i386] (artful-proposed) [1.3.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted bitlbee-facebook [i386] (artful-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted btrfs-heatmap [amd64] (artful-proposed) [6-1]
-queuebot:#ubuntu-release- New: accepted butteraugli [i386] (artful-proposed) [0~20170116-1]
-queuebot:#ubuntu-release- New: accepted catimg [i386] (artful-proposed) [2.2.1-1]
-queuebot:#ubuntu-release- New binary: ruby-google-protobuf [ppc64el] (artful-proposed/universe) [3.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted 4pane [s390x] (artful-proposed) [4.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted bio-tradis [amd64] (artful-proposed) [1.3.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted braillegraph [amd64] (artful-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted catimg [amd64] (artful-proposed) [2.2.1-1]
-queuebot:#ubuntu-release- New: accepted ciftilib [ppc64el] (artful-proposed) [1.5.1-1]
-queuebot:#ubuntu-release- New: accepted gammaray [armhf] (artful-proposed) [2.7.0-1]
-queuebot:#ubuntu-release- New: accepted gst-omx [s390x] (artful-proposed) [1.10.4-1]
-queuebot:#ubuntu-release- New: accepted hfst-ospell [arm64] (artful-proposed) [0.4.3~r338-1]
-queuebot:#ubuntu-release- New: accepted indexed-gzip [ppc64el] (artful-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New binary: trnascan-se [s390x] (artful-proposed/multiverse) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted bitlbee-facebook [amd64] (artful-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted certspotter [i386] (artful-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted gst-omx [ppc64el] (artful-proposed) [1.10.4-1]
-queuebot:#ubuntu-release- New: accepted hfst-ospell [armhf] (artful-proposed) [0.4.3~r338-1]
-queuebot:#ubuntu-release- New: accepted janus [ppc64el] (artful-proposed) [0.2.2+dfsg-4]
-queuebot:#ubuntu-release- New: accepted libbloom [ppc64el] (artful-proposed) [1.4-2]
-queuebot:#ubuntu-release- New: accepted libhtml-gumbo-perl [s390x] (artful-proposed) [0.17-1]
-queuebot:#ubuntu-release- New: accepted mlv [ppc64el] (artful-proposed) [3.1.0-1]
-queuebot:#ubuntu-release- New: accepted mptp [ppc64el] (artful-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted bfs [amd64] (artful-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted ciftilib [s390x] (artful-proposed) [1.5.1-1]
-queuebot:#ubuntu-release- New: accepted indexed-gzip [s390x] (artful-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted libhtml-gumbo-perl [ppc64el] (artful-proposed) [0.17-1]
-queuebot:#ubuntu-release- New: accepted mlv [s390x] (artful-proposed) [3.1.0-1]
-queuebot:#ubuntu-release- New: accepted mrboom [s390x] (artful-proposed) [3.1.127-1]
-queuebot:#ubuntu-release- New: accepted octave-sparsersb [s390x] (artful-proposed) [1.0.5-1]
-queuebot:#ubuntu-release- New: accepted orthanc-wsi [s390x] (artful-proposed) [0.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted pgaudit [s390x] (artful-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted pgsql-ogr-fdw [s390x] (artful-proposed) [1.0.2-2]
-queuebot:#ubuntu-release- New: accepted octave-sparsersb [ppc64el] (artful-proposed) [1.0.5-1]
-queuebot:#ubuntu-release- New: accepted php-cassandra [ppc64el] (artful-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted protracker [ppc64el] (artful-proposed) [2.3d.r10-1]
-queuebot:#ubuntu-release- New: accepted python-biotools [ppc64el] (artful-proposed) [1.2.12-1]
-queuebot:#ubuntu-release- New: accepted python-line-profiler [s390x] (artful-proposed) [2.0+ds1-1]
-queuebot:#ubuntu-release- New: accepted qtdeclarative-render2d-opensource-src [s390x] (artful-proposed) [5.7.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-snowballc [s390x] (artful-proposed) [0.5.1-1]
-queuebot:#ubuntu-release- New: accepted ruby-google-protobuf [ppc64el] (artful-proposed) [3.2.0-1]
-queuebot:#ubuntu-release- New: accepted runcircos-gui [ppc64el] (artful-proposed) [0.0+20160403-1]
-queuebot:#ubuntu-release- New: accepted libnexstar [ppc64el] (artful-proposed) [0.15-1]
-queuebot:#ubuntu-release- New: accepted php-ds [ppc64el] (artful-proposed) [1.1.8-1]
-queuebot:#ubuntu-release- New: accepted python-line-profiler [ppc64el] (artful-proposed) [2.0+ds1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-snowballc [ppc64el] (artful-proposed) [0.5.1-1]
-queuebot:#ubuntu-release- New: accepted ruby-google-protobuf [s390x] (artful-proposed) [3.2.0-1]
-queuebot:#ubuntu-release- New: accepted sassphp [ppc64el] (artful-proposed) [0.5.10-2]
-queuebot:#ubuntu-release- New: accepted seafile-client [ppc64el] (artful-proposed) [6.0.4-1]
-queuebot:#ubuntu-release- New: accepted sniproxy [ppc64el] (artful-proposed) [0.5.0-2]
-queuebot:#ubuntu-release- New: accepted stressant [ppc64el] (artful-proposed) [0.4.0]
-queuebot:#ubuntu-release- New: accepted tnetstring3 [ppc64el] (artful-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted pgaudit [ppc64el] (artful-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted qtdeclarative-render2d-opensource-src [ppc64el] (artful-proposed) [5.7.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted runcircos-gui [s390x] (artful-proposed) [0.0+20160403-1]
-queuebot:#ubuntu-release- New: accepted seafile-client [s390x] (artful-proposed) [6.0.4-1]
-queuebot:#ubuntu-release- New: accepted stressant [s390x] (artful-proposed) [0.4.0]
-queuebot:#ubuntu-release- New: accepted tnseq-transit [ppc64el] (artful-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted trnascan-se [ppc64el] (artful-proposed) [1.3.1-1]
-queuebot:#ubuntu-release- New: accepted uvloop [ppc64el] (artful-proposed) [0.8.0+ds1-1]
-queuebot:#ubuntu-release- New: accepted vis [ppc64el] (artful-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted wolfssl [amd64] (artful-proposed) [3.10.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted pupnp-1.8 [ppc64el] (artful-proposed) [1:1.8.0-3]
-queuebot:#ubuntu-release- New: accepted sassphp [s390x] (artful-proposed) [0.5.10-2]
-queuebot:#ubuntu-release- New: accepted tnetstring3 [s390x] (artful-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted trnascan-se [s390x] (artful-proposed) [1.3.1-1]
-queuebot:#ubuntu-release- New: accepted vis [s390x] (artful-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted belenios [s390x] (artful-proposed) [1.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted bgw-replstatus [ppc64el] (artful-proposed) [1.0.1]
-queuebot:#ubuntu-release- New: accepted bitlbee-facebook [ppc64el] (artful-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted butteraugli [s390x] (artful-proposed) [0~20170116-1]
-queuebot:#ubuntu-release- New: accepted canu [s390x] (artful-proposed) [1.3+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-v8 [ppc64el] (artful-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted tnseq-transit [s390x] (artful-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted wolfssl [i386] (artful-proposed) [3.10.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted bio-tradis [ppc64el] (artful-proposed) [1.3.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted canu [ppc64el] (artful-proposed) [1.3+dfsg-1]
-queuebot:#ubuntu-release- New: accepted catimg [s390x] (artful-proposed) [2.2.1-1]
-queuebot:#ubuntu-release- New: accepted certspotter [s390x] (artful-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted cubicsdr [s390x] (artful-proposed) [0.2.0+git20170310+dfsg-2]
-queuebot:#ubuntu-release- New: accepted deepnano [s390x] (artful-proposed) [0.0+20160706-1]
-queuebot:#ubuntu-release- New: accepted docopt.cpp [s390x] (artful-proposed) [0.6.2-2]
-queuebot:#ubuntu-release- New: accepted sniproxy [s390x] (artful-proposed) [0.5.0-2]
-queuebot:#ubuntu-release- New: accepted bfs [ppc64el] (artful-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted catimg [ppc64el] (artful-proposed) [2.2.1-1]
-queuebot:#ubuntu-release- New: accepted cubicsdr [ppc64el] (artful-proposed) [0.2.0+git20170310+dfsg-2]
-queuebot:#ubuntu-release- New: accepted docopt.cpp [ppc64el] (artful-proposed) [0.6.2-2]
-queuebot:#ubuntu-release- New: accepted fontmanager.app [s390x] (artful-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted fzy [s390x] (artful-proposed) [0.9-1]
-queuebot:#ubuntu-release- New: accepted guetzli [s390x] (artful-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted libbloom [s390x] (artful-proposed) [1.4-2]
-queuebot:#ubuntu-release- New: accepted mptp [s390x] (artful-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted fzy [ppc64el] (artful-proposed) [0.9-1]
-queuebot:#ubuntu-release- New: accepted wolfssl [ppc64el] (artful-proposed) [3.10.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted bitlbee-facebook [s390x] (artful-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted ompl [i386] (artful-proposed) [1.2.1+ds1-1]
-queuebot:#ubuntu-release- New: accepted pygame [amd64] (artful-proposed) [1.9.3+dfsg-2]
-queuebot:#ubuntu-release- New: accepted python-gmpy2 [amd64] (artful-proposed) [2.0.8-2]
-queuebot:#ubuntu-release- New: accepted wolfssl [s390x] (artful-proposed) [3.10.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted deepnano [ppc64el] (artful-proposed) [0.0+20160706-1]
-queuebot:#ubuntu-release- New: accepted bgw-replstatus [s390x] (artful-proposed) [1.0.1]
-queuebot:#ubuntu-release- New: accepted ompl [s390x] (artful-proposed) [1.2.1+ds1-1]
-queuebot:#ubuntu-release- New: accepted python-gmpy [amd64] (artful-proposed) [1.17-3]
-queuebot:#ubuntu-release- New: accepted kreport [s390x] (artful-proposed) [3.0.0-2]
-queuebot:#ubuntu-release- New: accepted pygame [i386] (artful-proposed) [1.9.3+dfsg-2]
-queuebot:#ubuntu-release- New: accepted gfal2 [armhf] (artful-proposed) [2.13.3-3]
-queuebot:#ubuntu-release- New binary: mariadb-10.1 [amd64] (artful-proposed/universe) [10.1.22-4] (no packageset)
-queuebot:#ubuntu-release- New binary: wuzz [ppc64el] (artful-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-couchbase-moss [amd64] (artful-proposed/universe) [0.0~git20170330.0.d2258a2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-go-openapi-loads [amd64] (artful-proposed/universe) [0.0~git20160704.0.18441df-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-issue9-identicon [amd64] (artful-proposed/universe) [0.0~git20160320.0.d36b545-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-siddontang-rdb [amd64] (artful-proposed/universe) [0.0~git20150307.0.fc89ed2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wuzz [armhf] (artful-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-facebookgo-ensure [amd64] (artful-proposed/universe) [0.0~git20160127.0.b4ab57d-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-lunny-nodb [amd64] (artful-proposed/universe) [0.0~git20160621.0.fc1ef06-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-gorilla-sessions [amd64] (artful-proposed/universe) [1.1+git20170307.5.ba78acc-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gopkg-pg.v5 [amd64] (artful-proposed/universe) [5.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-alicebob-miniredis [amd64] (artful-proposed/universe) [0.0~git20170325.0.bfdf65a-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-ngaut-pools [amd64] (artful-proposed/universe) [0.0~git20141008.0.6352e00-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gopkg-testfixtures.v2 [amd64] (artful-proposed/universe) [2.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyvenv-el [amd64] (artful-proposed/universe) [1.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wuzz [amd64] (artful-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wuzz [s390x] (artful-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-go-openapi-strfmt [amd64] (artful-proposed/universe) [0.0~git20160812.0.d65c7fd-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-hmac-drbg [amd64] (artful-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wuzz [i386] (artful-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-seiflotfy-cuckoofilter [amd64] (artful-proposed/universe) [0.0~git20160609.0.d048387-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-cellranger [amd64] (artful-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-code.gitea-git [amd64] (artful-proposed/universe) [0.0~git20170321.0.5b41327-1] (no packageset)
-queuebot:#ubuntu-release- New binary: starjava-connect [amd64] (artful-proposed/universe) [0.1+2016.05.03-1] (no packageset)
-queuebot:#ubuntu-release- New binary: starjava-array [amd64] (artful-proposed/universe) [0.2+2016.05.03-1] (no packageset)
-queuebot:#ubuntu-release- New binary: spyder-line-profiler [amd64] (artful-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wuzz [arm64] (artful-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: starjava-task [amd64] (artful-proposed/universe) [0.2+2016.05.03-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-code.gitea-git [amd64] (artful-proposed) [0.0~git20170321.0.5b41327-1]
-queuebot:#ubuntu-release- New: accepted golang-github-couchbase-moss [amd64] (artful-proposed) [0.0~git20170330.0.d2258a2-1]
-queuebot:#ubuntu-release- New: accepted golang-github-go-openapi-loads [amd64] (artful-proposed) [0.0~git20160704.0.18441df-1]
-queuebot:#ubuntu-release- New: accepted golang-github-gorilla-sessions [amd64] (artful-proposed) [1.1+git20170307.5.ba78acc-1]
-queuebot:#ubuntu-release- New: accepted golang-github-lunny-nodb [amd64] (artful-proposed) [0.0~git20160621.0.fc1ef06-1]
-queuebot:#ubuntu-release- New: accepted golang-github-seiflotfy-cuckoofilter [amd64] (artful-proposed) [0.0~git20160609.0.d048387-1]
-queuebot:#ubuntu-release- New: accepted golang-gopkg-pg.v5 [amd64] (artful-proposed) [5.3.3-1]
-queuebot:#ubuntu-release- New: accepted mariadb-10.1 [amd64] (artful-proposed) [10.1.22-4]
-queuebot:#ubuntu-release- New: accepted pyvenv-el [amd64] (artful-proposed) [1.10-1]
-queuebot:#ubuntu-release- New: accepted spyder-line-profiler [amd64] (artful-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-alicebob-miniredis [amd64] (artful-proposed) [0.0~git20170325.0.bfdf65a-1]
-queuebot:#ubuntu-release- New: accepted golang-github-go-openapi-strfmt [amd64] (artful-proposed) [0.0~git20160812.0.d65c7fd-1]
-queuebot:#ubuntu-release- New: accepted golang-github-ngaut-pools [amd64] (artful-proposed) [0.0~git20141008.0.6352e00-1]
-queuebot:#ubuntu-release- New: accepted golang-gopkg-testfixtures.v2 [amd64] (artful-proposed) [2.2.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-cellranger [amd64] (artful-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted starjava-connect [amd64] (artful-proposed) [0.1+2016.05.03-1]
-queuebot:#ubuntu-release- New: accepted wuzz [amd64] (artful-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted wuzz [armhf] (artful-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted wuzz [ppc64el] (artful-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-facebookgo-ensure [amd64] (artful-proposed) [0.0~git20160127.0.b4ab57d-1]
-queuebot:#ubuntu-release- New: accepted golang-github-siddontang-rdb [amd64] (artful-proposed) [0.0~git20150307.0.fc89ed2-1]
-queuebot:#ubuntu-release- New: accepted starjava-array [amd64] (artful-proposed) [0.2+2016.05.03-1]
-queuebot:#ubuntu-release- New: accepted wuzz [arm64] (artful-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted wuzz [s390x] (artful-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-issue9-identicon [amd64] (artful-proposed) [0.0~git20160320.0.d36b545-1]
-queuebot:#ubuntu-release- New: accepted starjava-task [amd64] (artful-proposed) [0.2+2016.05.03-1]
-queuebot:#ubuntu-release- New: accepted node-hmac-drbg [amd64] (artful-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted wuzz [i386] (artful-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New binary: grpc [s390x] (artful-proposed/universe) [1.2.5-1+nmu1] (no packageset)
-queuebot:#ubuntu-release- New binary: grpc [amd64] (artful-proposed/universe) [1.2.5-1+nmu1] (no packageset)
-queuebot:#ubuntu-release- New binary: grpc [ppc64el] (artful-proposed/universe) [1.2.5-1+nmu1] (no packageset)
-queuebot:#ubuntu-release- New binary: grpc [i386] (artful-proposed/universe) [1.2.5-1+nmu1] (no packageset)
-queuebot:#ubuntu-release- New binary: grpc [arm64] (artful-proposed/universe) [1.2.5-1+nmu1] (no packageset)
-queuebot:#ubuntu-release- New binary: grpc [armhf] (artful-proposed/universe) [1.2.5-1+nmu1] (no packageset)
-queuebot:#ubuntu-release- New binary: flask-socketio [amd64] (artful-proposed/universe) [2.8.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-facebookgo-stats [amd64] (artful-proposed/universe) [0.0~git20151006.0.1b76add-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-blevesearch-bleve [amd64] (artful-proposed/universe) [0.5.0+git20170324.202.4702785f-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-go-openapi-validate [amd64] (artful-proposed/universe) [0.0~git20160704.0.deaf2c9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-asn1.js [amd64] (artful-proposed/universe) [4.9.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-miller-rabin [amd64] (artful-proposed/universe) [4.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-lexrankr [ppc64el] (artful-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-worrms [amd64] (artful-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-go-openapi-runtime [amd64] (artful-proposed/universe) [0.0~git20160704.0.11e322e-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-errno [amd64] (artful-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-natserv [amd64] (artful-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kanboard-cli [amd64] (artful-proposed/universe) [0.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-lexrankr [amd64] (artful-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-siddontang-goredis [amd64] (artful-proposed/universe) [0.0~git20150324.0.760763f-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-lexrankr [i386] (artful-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wala [amd64] (artful-proposed/universe) [1.3.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbiod [amd64] (artful-proposed/universe) [0.1.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-lexrankr [s390x] (artful-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-markbates-goth [amd64] (artful-proposed/universe) [1.38.0+git20170301.0.488a04a-1] (no packageset)
-queuebot:#ubuntu-release- New binary: starjava-table [amd64] (artful-proposed/universe) [3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-shinyjs [amd64] (artful-proposed/universe) [0.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xtensor-python [amd64] (artful-proposed/universe) [0.10.0-1] (no packageset)
<LocutusOfBorg> slow and busy publisher :)
-queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (xenial-proposed/multiverse) [5.0.36-0ubuntu1.16.04.2 => 5.0.40-0ubuntu1.16.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted flask-socketio [amd64] (artful-proposed) [2.8.6-1]
-queuebot:#ubuntu-release- New: accepted golang-github-facebookgo-stats [amd64] (artful-proposed) [0.0~git20151006.0.1b76add-1]
-queuebot:#ubuntu-release- New: accepted golang-github-go-openapi-validate [amd64] (artful-proposed) [0.0~git20160704.0.deaf2c9-1]
-queuebot:#ubuntu-release- New: accepted golang-github-siddontang-goredis [amd64] (artful-proposed) [0.0~git20150324.0.760763f-1]
-queuebot:#ubuntu-release- New: accepted golang-github-blevesearch-bleve [amd64] (artful-proposed) [0.5.0+git20170324.202.4702785f-1]
-queuebot:#ubuntu-release- New: accepted golang-github-markbates-goth [amd64] (artful-proposed) [1.38.0+git20170301.0.488a04a-1]
-queuebot:#ubuntu-release- New: accepted golang-github-go-openapi-runtime [amd64] (artful-proposed) [0.0~git20160704.0.11e322e-1]
-queuebot:#ubuntu-release- New: accepted grpc [amd64] (artful-proposed) [1.2.5-1+nmu1]
-queuebot:#ubuntu-release- New: accepted grpc [armhf] (artful-proposed) [1.2.5-1+nmu1]
-queuebot:#ubuntu-release- New: accepted grpc [ppc64el] (artful-proposed) [1.2.5-1+nmu1]
-queuebot:#ubuntu-release- New: accepted kanboard-cli [amd64] (artful-proposed) [0.0.2-1]
-queuebot:#ubuntu-release- New: accepted node-asn1.js [amd64] (artful-proposed) [4.9.1-1]
-queuebot:#ubuntu-release- New: accepted node-miller-rabin [amd64] (artful-proposed) [4.0.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-lexrankr [i386] (artful-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-lexrankr [s390x] (artful-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-shinyjs [amd64] (artful-proposed) [0.9-1]
-queuebot:#ubuntu-release- New: accepted starjava-table [amd64] (artful-proposed) [3.2-1]
-queuebot:#ubuntu-release- New: accepted grpc [arm64] (artful-proposed) [1.2.5-1+nmu1]
-queuebot:#ubuntu-release- New: accepted grpc [s390x] (artful-proposed) [1.2.5-1+nmu1]
-queuebot:#ubuntu-release- New: accepted node-errno [amd64] (artful-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-lexrankr [ppc64el] (artful-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-worrms [amd64] (artful-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted xtensor-python [amd64] (artful-proposed) [0.10.0-1]
-queuebot:#ubuntu-release- New: accepted grpc [i386] (artful-proposed) [1.2.5-1+nmu1]
-queuebot:#ubuntu-release- New: accepted r-cran-lexrankr [amd64] (artful-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted wala [amd64] (artful-proposed) [1.3.9-1]
-queuebot:#ubuntu-release- New: accepted libbiod [amd64] (artful-proposed) [0.1.0-3]
-queuebot:#ubuntu-release- New: accepted r-cran-natserv [amd64] (artful-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New binary: golang-github-siddontang-ledisdb [amd64] (artful-proposed/universe) [0.5+git20170318.76.5929802-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-facebookgo-httpdown [amd64] (artful-proposed/universe) [0.0~git20160323.0.a3b1354-1] (no packageset)
-queuebot:#ubuntu-release- New binary: starjava-fits [amd64] (artful-proposed/universe) [0.1+2017.03.29-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libscout [amd64] (artful-proposed/universe) [0.0~git20161124~dcd2a9e-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-falafel [amd64] (artful-proposed/universe) [2.1.0-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox (xenial-proposed/multiverse) [5.0.36-dfsg-0ubuntu1.16.04.2 => 5.0.40-dfsg-0ubuntu1.16.04.1] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: virtualbox-guest-additions-iso (xenial-proposed/multiverse) [5.0.36-0ubuntu1.16.04.2 => 5.0.40-0ubuntu1.16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: biosquid [i386] (artful-proposed/universe) [1.9g+cvs20050121-9] (no packageset)
-queuebot:#ubuntu-release- New binary: biosquid [s390x] (artful-proposed/universe) [1.9g+cvs20050121-9] (no packageset)
-queuebot:#ubuntu-release- New binary: biosquid [amd64] (artful-proposed/universe) [1.9g+cvs20050121-9] (no packageset)
-queuebot:#ubuntu-release- New binary: biosquid [ppc64el] (artful-proposed/universe) [1.9g+cvs20050121-9] (no packageset)
-queuebot:#ubuntu-release- New binary: biosquid [arm64] (artful-proposed/universe) [1.9g+cvs20050121-9] (no packageset)
-queuebot:#ubuntu-release- New binary: biosquid [armhf] (artful-proposed/universe) [1.9g+cvs20050121-9] (no packageset)
-queuebot:#ubuntu-release- New binary: nfs-ganesha [amd64] (artful-proposed/universe) [2.4.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nfs-ganesha [ppc64el] (artful-proposed/universe) [2.4.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nfs-ganesha [s390x] (artful-proposed/universe) [2.4.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nfs-ganesha [i386] (artful-proposed/universe) [2.4.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nfs-ganesha [arm64] (artful-proposed/universe) [2.4.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nfs-ganesha [armhf] (artful-proposed/universe) [2.4.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tuned [amd64] (artful-proposed/universe) [2.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kup-backup [amd64] (artful-proposed/universe) [0.6.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kup-backup [ppc64el] (artful-proposed/universe) [0.6.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kup-backup [i386] (artful-proposed/universe) [0.6.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kup-backup [s390x] (artful-proposed/universe) [0.6.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kup-backup [arm64] (artful-proposed/universe) [0.6.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kup-backup [armhf] (artful-proposed/universe) [0.6.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted kup-backup [amd64] (artful-proposed) [0.6.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted kup-backup [armhf] (artful-proposed) [0.6.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted kup-backup [ppc64el] (artful-proposed) [0.6.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted nfs-ganesha [arm64] (artful-proposed) [2.4.5-1]
-queuebot:#ubuntu-release- New: accepted nfs-ganesha [i386] (artful-proposed) [2.4.5-1]
-queuebot:#ubuntu-release- New: accepted kup-backup [arm64] (artful-proposed) [0.6.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted kup-backup [s390x] (artful-proposed) [0.6.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted tuned [amd64] (artful-proposed) [2.8.0-1]
-queuebot:#ubuntu-release- New: accepted kup-backup [i386] (artful-proposed) [0.6.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted nfs-ganesha [armhf] (artful-proposed) [2.4.5-1]
-queuebot:#ubuntu-release- New: accepted biosquid [amd64] (artful-proposed) [1.9g+cvs20050121-9]
-queuebot:#ubuntu-release- New: accepted biosquid [armhf] (artful-proposed) [1.9g+cvs20050121-9]
-queuebot:#ubuntu-release- New: accepted biosquid [ppc64el] (artful-proposed) [1.9g+cvs20050121-9]
-queuebot:#ubuntu-release- New: accepted golang-github-facebookgo-httpdown [amd64] (artful-proposed) [0.0~git20160323.0.a3b1354-1]
-queuebot:#ubuntu-release- New: accepted libscout [amd64] (artful-proposed) [0.0~git20161124~dcd2a9e-1]
-queuebot:#ubuntu-release- New: accepted nfs-ganesha [ppc64el] (artful-proposed) [2.4.5-1]
-queuebot:#ubuntu-release- New: accepted starjava-fits [amd64] (artful-proposed) [0.1+2017.03.29-1]
-queuebot:#ubuntu-release- New: accepted biosquid [arm64] (artful-proposed) [1.9g+cvs20050121-9]
-queuebot:#ubuntu-release- New: accepted biosquid [s390x] (artful-proposed) [1.9g+cvs20050121-9]
-queuebot:#ubuntu-release- New: accepted nfs-ganesha [amd64] (artful-proposed) [2.4.5-1]
-queuebot:#ubuntu-release- New: accepted biosquid [i386] (artful-proposed) [1.9g+cvs20050121-9]
-queuebot:#ubuntu-release- New: accepted nfs-ganesha [s390x] (artful-proposed) [2.4.5-1]
-queuebot:#ubuntu-release- New: accepted golang-github-siddontang-ledisdb [amd64] (artful-proposed) [0.5+git20170318.76.5929802-1]
-queuebot:#ubuntu-release- New: accepted node-falafel [amd64] (artful-proposed) [2.1.0-2build1]
-queuebot:#ubuntu-release- New binary: hmmer2 [ppc64el] (artful-proposed/universe) [2.3.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hmmer2 [s390x] (artful-proposed/universe) [2.3.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hmmer2 [amd64] (artful-proposed/universe) [2.3.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hmmer2 [armhf] (artful-proposed/universe) [2.3.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hmmer2 [arm64] (artful-proposed/universe) [2.3.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-tape [amd64] (artful-proposed/universe) [4.6.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: starjava-votable [amd64] (artful-proposed/universe) [2.0+2016.12.22-1] (no packageset)
<mapreri> hey, waldi is complaining that he is receiving emails from the auto-sync about src:archvsync being rejected (in debian it is a by-hand package).
<mapreri> please put it in the sync blacklist or something.
<mapreri> infinity, cjwatson â
<mapreri> well, of course it's not the archvsync, but launchpad, which fails to accept it after being built, sorry https://launchpad.net/ubuntu/+source/archvsync/20170204/+build/12500345
-queuebot:#ubuntu-release- New sync: tslib (artful-proposed/primary) [1.9-1]
<infinity> mapreri: I would suggest that instead of blacklisting it, we might want to carry an Ubuntu delta that drops the by-hand bit.  Seems the actual Debian package bit might still be useful for people who want to run a Debian FTP mirror on Ubuntu
<infinity> mapreri: I might just do that right now.
<mapreri> I wonder if there is actually anything in that .deb
<mapreri> 	28.0 kB
<infinity> There is.
<infinity> It's a shell script.  Not gonna be large.
<infinity> Well, a few shell scripts now.
<mapreri> even documentation, apparently!
<mapreri> infinity: alright, thank you!
<infinity> mapreri: And done.
-queuebot:#ubuntu-release- New binary: archvsync [amd64] (artful-proposed/universe) [20170204ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted archvsync [amd64] (artful-proposed) [20170204ubuntu1]
-queuebot:#ubuntu-release- New: accepted hmmer2 [amd64] (artful-proposed) [2.3.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted hmmer2 [armhf] (artful-proposed) [2.3.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted hmmer2 [s390x] (artful-proposed) [2.3.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted starjava-votable [amd64] (artful-proposed) [2.0+2016.12.22-1]
-queuebot:#ubuntu-release- New: accepted hmmer2 [arm64] (artful-proposed) [2.3.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted node-tape [amd64] (artful-proposed) [4.6.3-1]
-queuebot:#ubuntu-release- New: accepted hmmer2 [ppc64el] (artful-proposed) [2.3.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted tslib [sync] (artful-proposed) [1.9-1]
-queuebot:#ubuntu-release- New binary: tslib [amd64] (artful-proposed/none) [1.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tslib [s390x] (artful-proposed/none) [1.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tslib [ppc64el] (artful-proposed/none) [1.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tslib [armhf] (artful-proposed/none) [1.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tslib [i386] (artful-proposed/none) [1.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tslib [arm64] (artful-proposed/none) [1.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-buffer-xor [amd64] (artful-proposed/universe) [2.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-cipher-base [amd64] (artful-proposed/universe) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpsortb [amd64] (artful-proposed/universe) [1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpsortb [s390x] (artful-proposed/universe) [1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-cached-path-relative [amd64] (artful-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-date-now [amd64] (artful-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-ieee754 [amd64] (artful-proposed/universe) [1.1.8-3] (no packageset)
-queuebot:#ubuntu-release- New binary: node-sha.js [amd64] (artful-proposed/universe) [2.4.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: starjava-vo [amd64] (artful-proposed/universe) [0.2+2017.01.13-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpsortb [ppc64el] (artful-proposed/universe) [1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-console-browserify [amd64] (artful-proposed/universe) [1.1.0+20161220gitf0a8898487-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-retape [amd64] (artful-proposed/universe) [0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-base64-js [amd64] (artful-proposed/universe) [1.2.0+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: node-static-eval [amd64] (artful-proposed/universe) [1.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-hash-base [amd64] (artful-proposed/universe) [3.0.3+20161104git280d4a0c567-1] (no packageset)
#ubuntu-release 2018-04-23
-queuebot:#ubuntu-release- Unapproved: rjava (bionic-proposed/universe) [0.9-9-1ubuntu1 => 0.9-9-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted rjava [source] (bionic-proposed) [0.9-9-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: osgi-foundation-ee (bionic-proposed/universe) [4.2.0-3 => 4.2.0-4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted osgi-foundation-ee [source] (bionic-proposed) [4.2.0-4]
<slangasek> infinity, cyphermox: no fresh bug reports against shim-signed for 24h; that's promising.  I think we should push shim-signed 1.34.4.
<slangasek> tsimonq2: hum, I don't love this collection of functions in the ubiquity code printing debugging errors about ecryptfs being deprecated, rather than the code being removed; but I see you're following suit with what was done to the GTK code
<tsimonq2> slangasek: Yep.
<wxl> sounds like slangasek has himself a bug report to file XD
<slangasek> a complaint about the style of a project that I'm not a committer on is not really a bug report
<tsimonq2> Â¯\_(ã)_/Â¯
<wxl> that codebase is pretty much crazymaking as far as i'm concerned
-queuebot:#ubuntu-release- Unapproved: ubiquity (bionic-proposed/main) [18.04.9 => 18.04.10] (core)
-queuebot:#ubuntu-release- Unapproved: accepted linux-raspi2 [sync] (bionic-proposed) [4.15.0-1009.10]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-19.20]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-19.20]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-raspi2 [sync] (bionic-proposed) [4.15.0.1009.7]
-queuebot:#ubuntu-release- Unapproved: accepted linux-gcp [sync] (bionic-proposed) [4.15.0-1005.5]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-gcp [sync] (bionic-proposed) [4.15.0.1005.7]
-queuebot:#ubuntu-release- Unapproved: fpc (bionic-proposed/universe) [3.0.4+dfsg-16 => 3.0.4+dfsg-18] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: autopkgtest (bionic-proposed/main) [5.3ubuntu1 => 5.3.1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted fpc [sync] (bionic-proposed) [3.0.4+dfsg-18]
-queuebot:#ubuntu-release- Unapproved: autodep8 (bionic-proposed/main) [0.11.1 => 0.12] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: pandas (bionic-proposed/universe) [0.22.0-3 => 0.22.0-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted linux-azure [sync] (bionic-proposed) [4.15.0-1008.8]
-queuebot:#ubuntu-release- Unapproved: deal.ii (bionic-proposed/universe) [8.5.1-1ubuntu1 => 8.5.1-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted linux-azure [sync] (bionic-proposed) [4.15.0-1008.8]
-queuebot:#ubuntu-release- Unapproved: accepted linux-azure [sync] (bionic-proposed) [4.15.0-1008.8]
-queuebot:#ubuntu-release- Unapproved: accepted linux-azure [sync] (bionic-proposed) [4.15.0-1008.8]
-queuebot:#ubuntu-release- Unapproved: accepted linux-azure [sync] (bionic-proposed) [4.15.0-1008.8]
-queuebot:#ubuntu-release- Unapproved: accepted linux-azure [sync] (bionic-proposed) [4.15.0-1008.8]
-queuebot:#ubuntu-release- Unapproved: accepted linux-azure [sync] (bionic-proposed) [4.15.0-1008.8]
-queuebot:#ubuntu-release- Unapproved: accepted linux-azure [sync] (bionic-proposed) [4.15.0-1008.8]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-azure [sync] (bionic-proposed) [4.15.0.1008.8]
-queuebot:#ubuntu-release- Unapproved: accepted linux-azure [sync] (bionic-proposed) [4.15.0-1008.8]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-azure [sync] (bionic-proposed) [4.15.0.1008.8]
-queuebot:#ubuntu-release- Unapproved: accepted pandas [sync] (bionic-proposed) [0.22.0-4]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed-azure [sync] (bionic-proposed) [4.15.0-1008.8]
-queuebot:#ubuntu-release- Unapproved: accepted linux-aws [sync] (bionic-proposed) [4.15.0-1006.6]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-aws [sync] (bionic-proposed) [4.15.0.1006.6]
-queuebot:#ubuntu-release- Unapproved: accepted linux-kvm [sync] (bionic-proposed) [4.15.0-1007.7]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-kvm [sync] (bionic-proposed) [4.15.0.1007.7]
-queuebot:#ubuntu-release- Unapproved: jmol (bionic-proposed/universe) [14.6.4+2016.11.05+dfsg1-3 => 14.6.4+2016.11.05+dfsg1-3.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted jmol [sync] (bionic-proposed) [14.6.4+2016.11.05+dfsg1-3.1]
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-390 [source] (bionic-proposed) [390.48-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: mpdecimal (bionic-proposed/main) [2.4.2-1 => 2.4.2-1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted mpdecimal [source] (bionic-proposed) [2.4.2-1ubuntu1]
<acheronuk> nvidia-prime in the queue? adds back the 'prime-switch' script, but with it not installed? '+#prime-switch /sbin'
<acheronuk> I wonder if that is intended?
-queuebot:#ubuntu-release- Unapproved: creduce (bionic-proposed/universe) [2.8.0~20180315-1 => 2.8.0~20180422-1] (no packageset) (sync)
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-390 [amd64] (bionic-proposed/restricted) [390.48-0ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-390 [i386] (bionic-proposed/restricted) [390.48-0ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted creduce [sync] (bionic-proposed) [2.8.0~20180422-1]
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-390 [armhf] (bionic-proposed/restricted) [390.48-0ubuntu3] (ubuntu-desktop)
<acheronuk> our sddm has a pacth to use prime-switch: https://git.launchpad.net/~kubuntu-packagers/kubuntu-packaging/+git/sddm/tree/debian/patches/06_nvidia_prime_setup.diff?h=kubuntu_bionic_archive
<ginggs> acheronuk: try asking tseliot in #-devel
<acheronuk> ginggs: he's not in there, or I would have
<ginggs> acheronuk: ya, just saw that, sorry.  he's normally around there
<slangasek> infinity: LP: #1761630 is awaiting an ack/nack of the late landing of the new upstream rsyslog
<ubot5`> Launchpad bug 1761630 in rsyslog (Ubuntu Bionic) "journald takes over /dev/log in bionic, impacts usability of syslog querying" [Critical,Fix committed] https://launchpad.net/bugs/1761630
<acheronuk> ginggs: thanks. hopefully he'll turn up in a bit
<ginggs> acheronuk: I pinged tseliot by email
<acheronuk> thank you
<infinity> slangasek: I'm okay with it if the people doing it are 99% sure it's going to be an improvement over the current state.
<infinity> xnox: ^
<infinity> xnox: Also, are you coming in today, or remote?
 * infinity bets his question will be answered in person in ~25m.
-queuebot:#ubuntu-release- Unapproved: rejected ubiquity [source] (bionic-proposed) [18.04.10]
<acheronuk> ^^^ may I ask why that was rejected?
<tseliot> acheronuk: hi, the prime-switch tool won't do much, since a reboot is required now. I  left the file there just in case things change in the future.
<acheronuk> tseliot: ok. that is fair enough. sddm only executes it if it there anyway.
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-390 [amd64] (bionic-proposed) [390.48-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-390 [i386] (bionic-proposed) [390.48-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-390 [armhf] (bionic-proposed) [390.48-0ubuntu3]
<acheronuk> or how it seems anyway. I must admit I have not looked at prime interaction much
<apw> acheronuk, because it had a load of junk in it by the looks of the diff
<acheronuk> apw: I should be more direct with questions. i.e. was it any of the KDE front end change?
<acheronuk> thanks
-queuebot:#ubuntu-release- Unapproved: accepted autodep8 [sync] (bionic-proposed) [0.12]
-queuebot:#ubuntu-release- Unapproved: accepted lensfun [sync] (bionic-proposed) [0.3.2-4]
-queuebot:#ubuntu-release- Unapproved: accepted autopkgtest [sync] (bionic-proposed) [5.3.1]
<apw> acheronuk, not sure i can tell if there were any kde frontend changes in there
<acheronuk> apw: yeah. just looked at the diff, and the KDE change is at the end. no surprise if you don't get to that
-queuebot:#ubuntu-release- New: accepted candid [source] (bionic-proposed) [1.0.0~alpha+201804191824-24b36a9-0ubuntu1]
<cjwatson> apw: It had a translation update from me, which is most of it
<cjwatson> Oh, but then indeed some other junk
<apw> cjwatson, and a large chunk of an apt-cache, which i assume is why it got rejected :)
<cjwatson> Somebody didn't clean
<cjwatson> Lemme do that merge as requested by Steve in the MP and I'll reupload
-queuebot:#ubuntu-release- New binary: candid [amd64] (bionic-proposed/none) [1.0.0~alpha+201804191824-24b36a9-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: candid [ppc64el] (bionic-proposed/none) [1.0.0~alpha+201804191824-24b36a9-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: candid [i386] (bionic-proposed/none) [1.0.0~alpha+201804191824-24b36a9-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: candid [s390x] (bionic-proposed/none) [1.0.0~alpha+201804191824-24b36a9-0ubuntu1] (no packageset)
<infinity> cjwatson: I was already on the ubiquity thing.
<infinity> cjwatson: But I guess I can compare mine to yours. :P
<cjwatson> infinity: Oh, go for it then
<cjwatson> infinity: Shall I finish the merge though?
<infinity> cjwatson: If you want to commit the merge, go for it.
<infinity> cjwatson: Then I'll compare to the upload I "fixed" here for Steve.
<infinity> (WHich has a proper clean, a non-bodged update to localechooser...)
-queuebot:#ubuntu-release- New binary: candid [arm64] (bionic-proposed/none) [1.0.0~alpha+201804191824-24b36a9-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: candid [armhf] (bionic-proposed/none) [1.0.0~alpha+201804191824-24b36a9-0ubuntu1] (no packageset)
<cjwatson> infinity: merged - I left the changelog as UNRELEASED, feel free to sync that up
<infinity> cjwatson: Yup.
-queuebot:#ubuntu-release- Unapproved: libxshmfence (bionic-proposed/main) [1.2-1 => 1.3-1] (core) (sync)
<jibel> infinity, I've another fix coming for ubiquity
<jibel> for bug 1765651
<ubot5`> bug 1765651 in ubiquity (Ubuntu Bionic) "Do not run gnome-initial-setup during OEM preparation stage" [High,Triaged] https://launchpad.net/bugs/1765651
<infinity> jibel: Oh, fun.  Then I won't finalize and upload this just yet.
<jibel> and then another one for bug 1741690 once we understand what's wrong and how to fix it
<ubot5`> bug 1741690 in ubiquity (Ubuntu Bionic) "You can't enable the Orca screen reader until after you click "Try Ubuntu" on Ubuntu bionic" [Critical,In progress] https://launchpad.net/bugs/1741690
-queuebot:#ubuntu-release- New: accepted candid [amd64] (bionic-proposed) [1.0.0~alpha+201804191824-24b36a9-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted candid [armhf] (bionic-proposed) [1.0.0~alpha+201804191824-24b36a9-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted candid [ppc64el] (bionic-proposed) [1.0.0~alpha+201804191824-24b36a9-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted candid [arm64] (bionic-proposed) [1.0.0~alpha+201804191824-24b36a9-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted candid [s390x] (bionic-proposed) [1.0.0~alpha+201804191824-24b36a9-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted candid [i386] (bionic-proposed) [1.0.0~alpha+201804191824-24b36a9-0ubuntu1]
<infinity> jibel: Doesn't entirely sound like anyone has a fix for the first one either?
<jibel> infinity, I'm testing a fix for the first one
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [4.15.0-1008.8] (kernel)
<infinity> jibel: Mmkay.
<tseliot> apw: hey, can you approve nvidia-prime too, please?
-queuebot:#ubuntu-release- Unapproved: jedit (bionic-proposed/universe) [5.4.0+dfsg-3 => 5.5.0+dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [4.15.0-1008.8]
-queuebot:#ubuntu-release- Unapproved: accepted jedit [sync] (bionic-proposed) [5.5.0+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: javassist (bionic-proposed/universe) [1:3.21.0-1 => 1:3.21.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted javassist [sync] (bionic-proposed) [1:3.21.0-2]
-queuebot:#ubuntu-release- Unapproved: usbguard (bionic-proposed/universe) [0.7.0+ds1-2build1 => 0.7.2+ds-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted usbguard [sync] (bionic-proposed) [0.7.2+ds-1]
<sil2100> cpaelzer: hey! You removed the tomcat task from tasksel some month ago, but on the ISO tracker there's still a server test case for the tomcat server installation
<jibel> infinity, https://code.launchpad.net/~jibel/ubiquity/lp1765651_OEM_touch_gnome-initial-setup_flag/+merge/343793 ready for review
-queuebot:#ubuntu-release- Unapproved: mate-panel (bionic-proposed/universe) [1.20.1-0ubuntu1 => 1.20.1-2ubuntu1] (ubuntu-mate)
<sil2100> cpaelzer: I guess the test-case is no longer valid as tomcat8 is not seeded and in universe, right? Should we remove the test-case?
-queuebot:#ubuntu-release- Unapproved: speech-dispatcher (bionic-proposed/main) [0.8.8-1 => 0.8.8-1ubuntu1] (kubuntu, ubuntu-desktop)
<infinity> jibel: Is that tested?
-queuebot:#ubuntu-release- Unapproved: libabw (bionic-proposed/main) [0.1.1-4ubuntu1 => 0.1.2-1ubuntu1] (kubuntu, ubuntu-desktop)
<acheronuk> tseliot: I'm hoping the nvidia-prime in the queue might help fix LP #1762885 but I can't test :/
<ubot5`> Launchpad bug 1762885 in sddm (Ubuntu) "SDDM starts to black screen on hybrid laptops withe modern NVidia cards" [Undecided,New] https://launchpad.net/bugs/1762885
-queuebot:#ubuntu-release- Unapproved: rejected base-files [source] (bionic-proposed) [10.1ubuntu2]
<apw> ^ so we don't accept it prematurely ...
<doko> apw: hmm, what would be the right time?
<apw> doko, normally just before we start making the finals, just what we always do
<apw> we'll just accept it from rejected when we are ready
<apw> this is release week, we do wierd things, its normal
<xnox> ð
 * apw boggles, there is a rainbow _character_ now ?
<xnox> apw, install "gnome-characters" deb app; then enable it as a search provider
<xnox> and then in gnome-search after pressing super you can type to search these emoji
<apw> i can just cut-n-paste it now you typed one ... i think i am more supprised my irc client is utf-8 clean enough to display it
<xnox> really useful
<xnox> if you enable it as a search provider
<apw> there had better be a right hand side :)
<cpaelzer> sil2100: sorry for the delay, was in a call
<cpaelzer> reading backlog
<cpaelzer> sil2100: yes I think just nobody thought on the test when doing the modifications
<sil2100> cpaelzer: ok, should I remove the testcase then?
<xnox> ð©
-queuebot:#ubuntu-release- Unapproved: google-perftools (bionic-proposed/main) [2.5-2.2ubuntu1 => 2.5-2.2ubuntu2] (ubuntu-server)
<cpaelzer> sil2100: IMHO yes, I just now go to the tracker and want to take a look before saying yes
<cpaelzer> sil2100: ok yeah it is just the install with this task test - yes this should be removed
<cpaelzer> and it is on 4/5 architectures (all but arm)
<cpaelzer> how is this edited actually?
<xnox> ð
<cpaelzer> xnox: are these unicode experiments?
<xnox> yes
<xnox> i think gnome-characters should be installed by default
<doko> slangasek, infinity: please have a look at the libdbi-drivers ftbfs, fails with your freetds update
<xnox> infinity, https://github.com/CanonicalLtd/subiquity/pull/319
<ubot5-ng> CanonicalLtd bug (Pull request) 319 in subiquity "Offline MAAS installer" (comments: 1) [Open]
<tseliot> acheronuk: that looks like a duplicate of LP: #1764005, which affects lightdm. I assume they are the same, since they rely on the same scripts
<ubot5`> Launchpad bug 1764005 in nvidia-prime (Ubuntu) "Black-screen on boot with nvidia 390 for Budgie, MATE, Xubuntu, Kubuntu" [High,In progress] https://launchpad.net/bugs/1764005
-queuebot:#ubuntu-release- Unapproved: qemu (xenial-proposed/main) [1:2.5+dfsg-5ubuntu10.25 => 1:2.5+dfsg-5ubuntu10.26] (ubuntu-server, virt)
<acheronuk> tseliot: seemed likely to me, which is why I was hoping that prime upload would fix
<sil2100> cpaelzer: ok, disabled the test-case, thanks for confirming
<jibel> infinity, yes tested in OEM and non OEM installations
<infinity> jibel: Excellent.
-queuebot:#ubuntu-release- Unapproved: candid (bionic-proposed/none) [none => 1.0.0~alpha+201804191824-24b36a9-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-tx-tftp (bionic-proposed/main) [0.1~bzr47-0ubuntu1 => 0.1~bzr47-0ubuntu2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ubiquity (bionic-proposed/main) [18.04.9 => 18.04.10] (core)
<cjwatson> infinity: reminder that you were going to update bionic chroots
<infinity> cjwatson: Reminder noted.
-queuebot:#ubuntu-release- Unapproved: accepted candid [source] (bionic-proposed) [1.0.0~alpha+201804191824-24b36a9-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (artful-proposed) [2:11.0.3-0ubuntu2]
<jibel> could someone have a look at bug 1765724 ?
<ubot5`> bug 1765724 in cryptsetup (Ubuntu) "Xenial -> Bionic - System fails to boot after upgrade - <email address hidden> fails to start" [Critical,New] https://launchpad.net/bugs/1765724
<xnox> jibel, so i have been working on that.
<xnox> jibel, and failed to reproduce it.
<xnox> jibel, i've used 16.04.4 install media and did two installs and upgrades. The first one i did was "full disk encrypt + upgrade" => result was fully non-degraded system.
<xnox> jibel, then i re-read the bug ;-)
<xnox> jibel, and did the "/home encyprted + upgrade" again, i had fully booted system.
<jibel> xnox, I tried again last friday. Let me try again
<jibel> I tried and reproduced it.
<xnox> jibel, so, how to reproduce this?
<doko> openjdk-9 removed
<tsimonq2> (ecryptfs is no longer installed by default so encrypted /home doesn't work.)
<jibel> xnox, 16.04.4 + encrypted home + update then upgrade. The upgraded system hangs on boot when it tries to activate the crypted swap
<jibel> tsimonq2, it shouldn't affect upgrades
<infinity> jibel: Did the upgrade remove it?
<tsimonq2> Exactly my thought.
<xnox> jibel, e.g. did you do just encrypt home? lvm + encrypt home? full disk encrypt + encrypt home? was it a clean target disk install? or was there something on the disk?
<jibel> infinity, no
<jibel> xnox, yes just encrypted home
<jibel> no lvm at all
<jibel> and a clean disk
<jibel> xnox, I'm redoing the full test
<xnox> thanks.
<xnox> jibel, and i wonder if it matters which xenial iso used.... are you using 16.04.0 iso per chance? i used 16.04.4..... i wonder if we "fixed" things since .0
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (bionic-proposed) [18.04.10]
<xnox> bah
<xnox> i can't read =) you did say 16.04.4
<jibel> xnox, there is this warning during the upgrade
<jibel> Installing new version of config file /etc/init.d/cryptdisks-early ...
<jibel> WARNING: you need to set all of cipher, hash and size for the plain dm-crypt mapping cryptswap1 in /etc/crypttab.
<cjwatson> infinity: hmm, new chroots not super-happy with life
<cjwatson> ah, may be a buildd-manager/keyserver problem
<cjwatson> infinity: (disregard, not your problem)
<xnox> jibel, ok. does it boot?
<xnox> i also wonder if it is racy or not....
<xnox> Cause it failed with dependency....
-queuebot:#ubuntu-release- New source: cider (bionic-proposed/primary) [0.16.0+dfsg-2build1]
-queuebot:#ubuntu-release- New: accepted cider [source] (bionic-proposed) [0.16.0+dfsg-2build1]
<jibel> xnox, the same machine that was hanging repeatedly on Friday boots now
-queuebot:#ubuntu-release- New binary: cider [amd64] (bionic-proposed/none) [0.16.0+dfsg-2build1] (no packageset)
-queuebot:#ubuntu-release- New: accepted cider [amd64] (bionic-proposed) [0.16.0+dfsg-2build1]
<xnox> jibel, it might be racy, and was loosing race, if e.g. hypervisor was "slower" on friday =/
<xnox> jibel, i do hope that the orderings for these things are reliable / stable enough.
<coreycb> xnox: is it ok if i add openstack release notes to https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes?
-queuebot:#ubuntu-release- Unapproved: modemmanager (bionic-proposed/main) [1.6.8-2 => 1.6.8-2ubuntu1] (kubuntu, ubuntu-desktop)
<xnox> coreycb, yes
<coreycb> xnox: ok thanks
<rbalint> xnox: systemd is blocked from migration by a single autopkgtest which passed with systemd/237-3ubuntu9 but which includes the boot of a kvm instance
<rbalint> infinity: ^ could it let to migrate?
<xnox> rbalint, thanks, but it is known that open-iscsi tests are racy on boot.
<xnox> rbalint, we are aware of it, and are working on migrating it.... here in person at bluefin.
<rbalint> xnox: cool, thanks
<ahasenack> xnox: is that the one with the 10s timeout change/fix?
<xnox> ahasenack, yes.... there is also a silo for testing that change alone
<xnox> ahasenack, have you tried it?
<ahasenack> no, I haven't, but looking forward to it
<ahasenack> can I just get the deb from lp? I can try it on a laptop which takes 10s longer to boot because of that
<xnox> ahasenack, see the silo linked from the bug report
<xnox> ahasenack, or install from proposed
-queuebot:#ubuntu-release- Unapproved: rejected zfs-linux [source] (artful-proposed) [0.6.5.11-1ubuntu3.4]
-queuebot:#ubuntu-release- Unapproved: libdbi-drivers (bionic-proposed/main) [0.9.0-5ubuntu1 => 0.9.0-5ubuntu2] (core)
<LocutusOfBorg> slangasek, https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1766215
<ubot5`> Ubuntu bug 1766215 in virtualbox (Ubuntu) "package virtualbox-dkms 5.2.10-dfsg-2 failed to install/upgrade: installed virtualbox-dkms package post-installation script subprocess returned error exit status 1" [Undecided,New]
<LocutusOfBorg> was this what you were referring to when said "no new reports wrt shim?"
<LocutusOfBorg>  At main.c:281:
<LocutusOfBorg> - SSL error:02001002:system library:fopen:No such file or directory: ../crypto/bio/bss_file.c:74
<LocutusOfBorg> - SSL error:2006D080:BIO routines:BIO_new_file:no such file: ../crypto/bio/bss_file.c:81
<LocutusOfBorg> kmodsign: /var/lib/dkms/virtualbox/5.2.10/4.15.0-15-generic/x86_64/module/virtualbox.ko: No such file or directory
<LocutusOfBorg> seems something broke dkms badly
<jibel> xnox, I reproduced the problem. the VM fails to boot after an upgrade from xenial
<xnox> jibel, can I have a tar ball of /var/log from said machine?
<xnox> jibel, that would have the installs logs, and the boot journal.
<jibel> xnox, sure
-queuebot:#ubuntu-release- Unapproved: activemq-activeio (bionic-proposed/universe) [3.1.4-2 => 3.1.4-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted activemq-activeio [sync] (bionic-proposed) [3.1.4-3]
-queuebot:#ubuntu-release- Unapproved: statcvs (bionic-proposed/universe) [1:0.7.0.dfsg-6 => 1:0.7.0.dfsg-7] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted statcvs [sync] (bionic-proposed) [1:0.7.0.dfsg-7]
<jibel> xnox, https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1765724/+attachment/5125848/+files/var_log.tgz
<ubot5`> Ubuntu bug 1765724 in cryptsetup (Ubuntu) "Xenial -> Bionic - System fails to boot after upgrade - <email address hidden> fails to start" [Critical,New]
<jibel> xnox, failed boot is -1, last boot is to recovery with swap disabled
-queuebot:#ubuntu-release- Unapproved: twisted (bionic-proposed/main) [17.9.0-1 => 17.9.0-2] (kubuntu, ubuntu-desktop, ubuntu-server) (sync)
<xnox> jibel, could you boot; enable swap; run $ systemctl daemon-reload; and give a tar ball of /run and /etc ?
<xnox> jibel, cause it's erroring out on dependency ordering... awaiting for drive.... As if the drive changes uuid?
<xnox> jibel, it would be alos nice to get the output of $ sudo blkid ?
<jibel> xnox, by enable swap you mean just removing the comment in fstab or starting it?
<xnox> jibel, just remove the comment.
-queuebot:#ubuntu-release- Unapproved: accepted libdbi-drivers [source] (bionic-proposed) [0.9.0-5ubuntu2]
<xnox> jibel, daemon-reload should rerun systemd generators, which create these units in /run
<jibel> okay
<xnox> jibel, which fail to start in the right order for you.
-queuebot:#ubuntu-release- Unapproved: rejected simplestreams [source] (artful-proposed) [0.1.0~bzr450-0ubuntu1.1]
<jibel> xnox, attached to the bug report
<xnox> doko, why did you force sync rails -1, on top of 0ubuntu4? and dropping the ubuntu changes? and not asking the TIL to look at it?
<xnox> jibel, cool, checking.
-queuebot:#ubuntu-release- Unapproved: debian-installer (bionic-proposed/main) [20101020ubuntu538 => 20101020ubuntu539] (core)
<xnox> jibel, yeah, the race looks legit.
<tjaalton> doko: bah, tomcat update broke dogtag, again..
-queuebot:#ubuntu-release- Unapproved: rejected debian-installer [source] (bionic-proposed) [20101020ubuntu539]
<xnox> jibel, it's a race. it may require fixes in systemd unit generator; if i have a proposed solution, i may ask you to add a snippet in /etc to see if that reliably fixes the boot for you and makes it race-free.
-queuebot:#ubuntu-release- Unapproved: libqmi (bionic-proposed/main) [1.18.0-3 => 1.18.0-3ubuntu1] (kubuntu, ubuntu-desktop)
<xnox> jibel, and with an extra snippet, you'd then need to reboot enough to confirm. E.g. if you think that it happens every 3 boot; to like reboot 20 times, to hopefully for systems to always come up fine.
<xnox> jibel, i also think we should not make it required.... and instead opportunistically bring it up. and e.g. boot degraded if it is not there.
-queuebot:#ubuntu-release- Unapproved: accepted makedumpfile [source] (artful-proposed) [1:1.6.1-2ubuntu0.2]
<tjaalton> doko: seems to be due to tomcat built with newer jdk now
<jibel> xnox, okay, let me know when you have something
<xnox> jibel, so, i think this is not a regression per-se, because if we would have kept the encrypt-/home with ecryptfs, things would be racy today too.
<xnox> jibel, so newly installed systems are not affected, thus this is not a blocker for release, despite nice to have for the release.
<xnox> jibel, it can be SRU thing to fix.
<jibel> xnox, an SRU sounds fine.
<jbicha> xnox: gnome-characters is installed by default but as a snap so the GNOME Shell search provider doesn't work yet https://forum.snapcraft.io/t/gnome-shell-search-providers/4322
<jbicha> also: https://gitlab.gnome.org/GNOME/gnome-characters/issues/11
<ubot5-ng> GNOME bug 11 in gnome-characters "Search provider should be enabled by default" (comments: 2) [Bugzilla, Opened]
<ubot5`> Error: Gnome bug 11 could not be found
-queuebot:#ubuntu-release- Unapproved: accepted makedumpfile [source] (xenial-proposed) [1:1.5.9-5ubuntu0.7]
-queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (bionic-proposed/multiverse) [5.2.10-dfsg-2ubuntu18.04.1 => 5.2.10-dfsg-3ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-hwe [source] (bionic-proposed) [5.2.10-dfsg-3ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted kexec-tools [source] (xenial-proposed) [1:2.0.10-1ubuntu2.5]
-queuebot:#ubuntu-release- Unapproved: debian-installer (bionic-proposed/main) [20101020ubuntu538 => 20101020ubuntu539] (core)
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (bionic-proposed) [20101020ubuntu539]
-queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (bionic-proposed/multiverse) [5.2.10-dfsg-2ubuntu18.04.1 => 5.2.10-dfsg-4ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-hwe [source] (bionic-proposed) [5.2.10-dfsg-4ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-panel [source] (bionic-proposed) [1.20.1-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected libqmi [source] (bionic-proposed) [1.18.0-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted simplestreams [source] (xenial-proposed) [0.1.0~bzr426-0ubuntu1.3]
-queuebot:#ubuntu-release- Unapproved: accepted libabw [source] (bionic-proposed) [0.1.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted speech-dispatcher [source] (bionic-proposed) [0.8.8-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: librtcom-telepathy-glib (bionic-proposed/universe) [0.1.38~git.1.e4dae27b-0ubuntu3 => 0.1.38~git.1.e4dae27b-0ubuntu4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted librtcom-telepathy-glib [source] (bionic-proposed) [0.1.38~git.1.e4dae27b-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: rejected google-perftools [source] (bionic-proposed) [2.5-2.2ubuntu2]
<doko> why are the ftbfs fixes rejected?
<doko> no reject messages yet
<doko> tjaalton: yes, it's openjdk-10 now, and it will be 11 in November
-queuebot:#ubuntu-release- Unapproved: rejected python-tx-tftp [source] (bionic-proposed) [0.1~bzr47-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: mate-notification-daemon (bionic-proposed/universe) [1.20.0-0ubuntu1 => 1.20.0-2] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libxshmfence [sync] (bionic-proposed) [1.3-1]
-queuebot:#ubuntu-release- Unapproved: accepted twisted [sync] (bionic-proposed) [17.9.0-2]
<infinity> doko: Read your email?
<doko> infinity: read above message?
<doko> no reject message yet
<infinity> doko: The rejects are pretty fire and forget for me.  But one of them was missing the patch you referenced in patches/series, and the other one wasn't cleaned before the source package was built.
-queuebot:#ubuntu-release- Unapproved: accepted mate-notification-daemon [sync] (bionic-proposed) [1.20.0-2]
-queuebot:#ubuntu-release- Unapproved: google-perftools (bionic-proposed/main) [2.5-2.2ubuntu1 => 2.5-2.2ubuntu2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: mate-common (bionic-proposed/universe) [1.20.0-0ubuntu1 => 1.20.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: wine-development (bionic-proposed/universe) [3.5-1 => 3.6-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted wine-development [sync] (bionic-proposed) [3.6-1]
-queuebot:#ubuntu-release- Unapproved: mate-user-guide (bionic-proposed/universe) [1.20.0-0ubuntu1 => 1.20.0-1] (ubuntu-mate, ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: ros-metapackages (bionic-proposed/universe) [1.9 => 1.10] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ros-metapackages [sync] (bionic-proposed) [1.10]
-queuebot:#ubuntu-release- Unapproved: ros-geometry2 (bionic-proposed/universe) [0.5.16-3 => 0.5.16-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ros-geometry2 [sync] (bionic-proposed) [0.5.16-4]
-queuebot:#ubuntu-release- Unapproved: openvpn-systemd-resolved (bionic-proposed/universe) [1.2.6-1 => 1.2.7-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted openvpn-systemd-resolved [sync] (bionic-proposed) [1.2.7-1]
-queuebot:#ubuntu-release- Unapproved: libmateweather (bionic-proposed/universe) [1.20.0-0ubuntu1 => 1.20.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: python-easydev (bionic-proposed/universe) [0.9.35+dfsg-1 => 0.9.35+dfsg-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-easydev [sync] (bionic-proposed) [0.9.35+dfsg-2]
-queuebot:#ubuntu-release- Unapproved: rejected modemmanager [source] (bionic-proposed) [1.6.8-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-tx-tftp (bionic-proposed/main) [0.1~bzr47-0ubuntu1 => 0.1~bzr47-0ubuntu2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.29]
-queuebot:#ubuntu-release- Unapproved: accepted python-tx-tftp [source] (bionic-proposed) [0.1~bzr47-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted google-perftools [source] (bionic-proposed) [2.5-2.2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted libmateweather [sync] (bionic-proposed) [1.20.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-user-guide [sync] (bionic-proposed) [1.20.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-common [sync] (bionic-proposed) [1.20.0-1]
-queuebot:#ubuntu-release- Unapproved: mate-icon-theme (bionic-proposed/universe) [1.20.0-0ubuntu1 => 1.20.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: marco (bionic-proposed/universe) [1.20.1-0ubuntu1 => 1.20.1-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-session-manager (bionic-proposed/universe) [1.20.0-0ubuntu1 => 1.20.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-control-center (bionic-proposed/universe) [1.20.2-0ubuntu1 => 1.20.2-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-screensaver (bionic-proposed/universe) [1.20.0-0ubuntu1 => 1.20.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted marco [sync] (bionic-proposed) [1.20.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-icon-theme [sync] (bionic-proposed) [1.20.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-session-manager [sync] (bionic-proposed) [1.20.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-control-center [sync] (bionic-proposed) [1.20.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-screensaver [sync] (bionic-proposed) [1.20.0-1]
-queuebot:#ubuntu-release- Unapproved: mate-media (bionic-proposed/universe) [1.20.0-0ubuntu1 => 1.20.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-system-monitor (bionic-proposed/universe) [1.20.0-0ubuntu1 => 1.20.0-1] (ubuntu-mate, ubuntukylin) (sync)
<slangasek> cjwatson, infinity: didn't clean> oops
-queuebot:#ubuntu-release- Unapproved: caja-extensions (bionic-proposed/universe) [1.20.0-0ubuntu1 => 1.20.0-1] (ubuntu-mate) (sync)
<slangasek> infinity: d-i not uploaded yet for 4.15.0-19.20 ? should I?
<infinity> slangasek: Look harder?
<infinity> slangasek: Except it's FTBFS on ppc64el.  Grr.
 * infinity looks.
-queuebot:#ubuntu-release- Unapproved: engrampa (bionic-proposed/universe) [1.20.0-0ubuntu1 => 1.20.0-1] (ubuntu-mate, ubuntukylin, xubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: eom (bionic-proposed/universe) [1.20.0-0ubuntu1 => 1.20.0-1] (ubuntu-mate, ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: rejected zfs-linux [source] (xenial-proposed) [0.6.5.6-0ubuntu21]
<slangasek> LocutusOfBorg: LP: #1766215> ah. thanks, I missed that the dkms maintscript code didn't get fixed for this.
<ubot5`> Launchpad bug 1766215 in virtualbox (Ubuntu) "package virtualbox-dkms 5.2.10-dfsg-2 failed to install/upgrade: installed virtualbox-dkms package post-installation script subprocess returned error exit status 1" [Critical,Confirmed] https://launchpad.net/bugs/1766215
-queuebot:#ubuntu-release- Unapproved: mate-applets (bionic-proposed/universe) [1.20.1-2ubuntu1 => 1.20.1-3] (ubuntu-mate) (sync)
<slangasek> infinity: ah, I was looking at rmadison, ok
-queuebot:#ubuntu-release- Unapproved: mate-calc (bionic-proposed/universe) [1.20.1-0ubuntu1 => 1.20.1-1] (ubuntu-mate, ubuntukylin, xubuntu) (sync)
<slangasek> infinity: (which is an hour out of date, phooey)
<slangasek> infinity: anyway, now urgently fixing dkms :/
<LocutusOfBorg> thanks slangasek! sorry if I didn't tell you earlier, I was really AFK
<LocutusOfBorg> I hope you can fix this :)
<doko> crap, google-perftools still ftbfs on ppc64el
-queuebot:#ubuntu-release- Unapproved: mate-indicator-applet (bionic-proposed/universe) [1.20.0-0ubuntu1 => 1.20.0-1] (ubuntu-mate) (sync)
<infinity> checking how to access the program counter from a struct ucontext... configure: WARNING: Could not find the PC.  Will not try to compile libprofiler...
<infinity> doko: ^-- Due to that, it looks like.
-queuebot:#ubuntu-release- Unapproved: mate-netbook (bionic-proposed/universe) [1.20.0-0ubuntu1 => 1.20.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-sensors-applet (bionic-proposed/universe) [1.20.1-0ubuntu1 => 1.20.1-3] (ubuntu-mate) (sync)
<slangasek> LocutusOfBorg: that bug report was filed 4h ago; did you have reports sooner than that?  Sorry, I failed to look at the dkms-providing packages for bug reports before committing
-queuebot:#ubuntu-release- Unapproved: mate-user-share (bionic-proposed/universe) [1.20.0-0ubuntu1 => 1.20.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: dkms (bionic-proposed/main) [2.3-3ubuntu7 => 2.3-3ubuntu8] (kubuntu, ubuntu-desktop)
<slangasek> infinity: ^^ dkms in the queue, please review.  should look familiar from shim-signed, except I'm intentionally not guarding for the "zero .kos" case because this is code inside dkms itself and that would be a different sort of bug
-queuebot:#ubuntu-release- Unapproved: python-caja (bionic-proposed/universe) [1.20.0-0ubuntu1 => 1.20.0-1] (ubuntu-mate) (sync)
<sil2100> New language packs being uploaded, will mass-approve once the upload stage is done
<infinity> slangasek: So, I'm not sure if we actually ship anything that would have such an issue, but would it not be potentially valid for a DKMS module to build a complex set of modules in subdirs?
<infinity> slangasek: ie: would find maybe be more appropriate than the glob?
-queuebot:#ubuntu-release- Unapproved: netplan.io (bionic-proposed/main) [0.35 => 0.36] (core)
<slangasek> sil2100: why another language pack run?  didn't we just have one at the end of last week?
<slangasek> infinity: you and your thorough reviews.  I think you're correct; otoh the code in shim is also currently broken in the same way in that case.  Do you want to accept this to unbreak the current failing-to-install maintainer scripts, and then I'll look at cleaning up both?
<sil2100> slangasek: the language-packs we generated (and exported) last week didn't have gnome-initial-setup translated for most languages due to it landing lateish, there was a translation-rush during the weekend to get that fixed
<slangasek> ah
-queuebot:#ubuntu-release- Unapproved: libmatemixer (bionic-proposed/universe) [1.20.0-0ubuntu1 => 1.20.0-1] (ubuntu-mate, ubuntukylin) (sync)
<slangasek> icky, but ok
<sil2100> slangasek: since it's one of the first things a user sees we found it important to respin ;/
<slangasek> sil2100: technically since it doesn't happen until after reboot, if they use the default of downloading updates during install, it would still be translated if we pushed these langpacks to -updates, AIUI
<slangasek> sil2100: (i.e. I think the langpacks shouldn't be allowed to delay the spinning of RCs, if everything else is ready to go before that... which it may not be)
<infinity> slangasek: Yeah.  I'm also less sure than you based on limited context that the empty test isn't useful here (and it certainly wouldn't be harmful), so I'd be okay with the code mirroring shim exactly.
-queuebot:#ubuntu-release- Unapproved: mate-polkit (bionic-proposed/universe) [1.20.0-0ubuntu1 => 1.20.0-1] (ubuntu-mate, ubuntukylin) (sync)
<infinity> slangasek: I specifically told sil2100 that the langpacks can not (and will not) be a blocker, but if he can get them in before the other things I'm blocking on, that's fine.
<slangasek> infinity: ok then we're on the same page, good-o
<infinity> slangasek: He misspoke with "important to respin". :P
<doko> infinity: the debian version builds without any patches ... https://launchpad.net/~doko/+archive/ubuntu/toolchain/+sourcepub/9007034/+listing-archive-extra
<slangasek> infinity: I'm arguing that the empty test isn't useful because in shim we're doing "look for all installed kernels; run 'dkms uninstall' for a kernel the dkms module may never have built for; try to sign the modules; run 'dkms install'" but in dkms we're doing "build the modules for this exact kernel version, then sign them"
<infinity> doko: Well, that's a much newer version.
<slangasek> infinity: so if the dkms build doesn't spit out any modules that we're able to find and sign, I'd rather see those failures
<infinity> slangasek: Fair, and I would expect it to fail earlier for other reasons, but if the code flow does get that far, I'd find it bombinb in the signing part to be weird and confusing, so the empty test is correct even if it's a no-op. :P
 * infinity waves his hand hand-wavingly.
<sil2100> slangasek: yeah, as per what infinity said, it wasn't a blocker per-se, it was just something we wanted to get in for the nearest re-spin if possible
<slangasek> infinity: well, think of it as a poor-man's assert in shell, if that helps?  I'm saying that I believe it's correct that it should never fail and therefore if it does I need to know about it in order to debug my assumptions
<infinity> slangasek: Don't feel strongly either way, I just consider "poor shell globbing instead of exiting for sane reasons earlier" to be about as readable "no, really, python tracebacks are totally better than error handling".
<infinity> s/readable/readable as/
<infinity> slangasek: Your assumption is probably correct.  But as this is new code, if your assumption turns out to be incorrect, you've introduced a bug.  If your assumption is correct, the test is a no-op.
<slangasek> infinity: if my assumption turns out to be incorrect it's still less buggy than the version currently in bionic
<slangasek> fails on a strict subset of machines
<slangasek> and I'll need to know it's buggy in order to prioritize getting it fixed before GA
<infinity> slangasek: Oh, yes, I'm not arguing at all about the validity of this upload compared to the previous. :)
<slangasek> ok
<slangasek> so if you want to accept this, I think the next upload will do the 'find' thing
<infinity> slangasek: Just about the eventual "final form", since we were discussing changing it a bit more anyway.
-queuebot:#ubuntu-release- Unapproved: accepted dkms [source] (bionic-proposed) [2.3-3ubuntu8]
<slangasek> infinity: ta
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Bionic Final] has been updated (20101020ubuntu539)
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Bionic Final] has been updated (20101020ubuntu539)
-queuebot:#ubuntu-release- Builds: Netboot armhf [Bionic Final] has been updated (20101020ubuntu539)
-queuebot:#ubuntu-release- Builds: Netboot i386 [Bionic Final] has been updated (20101020ubuntu539)
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Bionic Final] has been updated (20101020ubuntu539)
-queuebot:#ubuntu-release- Builds: Netboot s390x [Bionic Final] has been updated (20101020ubuntu539)
<cyphermox> sil2100: netplan is in unapproved.
<sil2100> cyphermox: looking!
-queuebot:#ubuntu-release- Unapproved: libmatemixer (bionic-proposed/universe) [1.20.0-0ubuntu1 => 1.20.0-1] (ubuntu-mate, ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: eom (bionic-proposed/universe) [1.20.0-0ubuntu1 => 1.20.0-1] (ubuntu-mate, ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-calc (bionic-proposed/universe) [1.20.1-0ubuntu1 => 1.20.1-1] (ubuntu-mate, ubuntukylin, xubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-applets (bionic-proposed/universe) [1.20.1-2ubuntu1 => 1.20.1-3] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted netplan.io [source] (bionic-proposed) [0.36]
<sil2100> All langpacks approved
-queuebot:#ubuntu-release- Unapproved: mate-themes (bionic-proposed/universe) [3.22.16-2ubuntu1 => 3.22.16-4ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (artful-proposed) [0.6.5.11-1ubuntu3.4]
-queuebot:#ubuntu-release- Unapproved: skiboot (bionic-proposed/main) [5.10~rc4-1 => 5.10~rc4-1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (xenial-proposed) [0.6.5.6-0ubuntu21]
-queuebot:#ubuntu-release- Unapproved: pyqt5 (bionic-proposed/universe) [5.10.1+dfsg-1ubuntu1 => 5.10.1+dfsg-1ubuntu2] (kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: latte-dock (bionic-proposed/universe) [0.7.4-0ubuntu1 => 0.7.4-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: cpprest (bionic-proposed/universe) [2.10.2-5 => 2.10.2-6] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: nlohmann-json (bionic-proposed/universe) [2.1.1-1 => 2.1.1-1.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted cpprest [sync] (bionic-proposed) [2.10.2-6]
-queuebot:#ubuntu-release- Unapproved: accepted nlohmann-json [sync] (bionic-proposed) [2.1.1-1.1]
-queuebot:#ubuntu-release- Unapproved: accepted skiboot [source] (bionic-proposed) [5.10~rc4-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: debian-installer (bionic-proposed/main) [20101020ubuntu539 => 20101020ubuntu540] (core)
<infinity> apw: ^--- This should work.
-queuebot:#ubuntu-release- Unapproved: accepted caja-extensions [sync] (bionic-proposed) [1.20.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted eom [sync] (bionic-proposed) [1.20.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-applets [sync] (bionic-proposed) [1.20.1-3]
-queuebot:#ubuntu-release- Unapproved: accepted mate-indicator-applet [sync] (bionic-proposed) [1.20.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-netbook [sync] (bionic-proposed) [1.20.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-sensors-applet [sync] (bionic-proposed) [1.20.1-3]
-queuebot:#ubuntu-release- Unapproved: accepted mate-user-share [sync] (bionic-proposed) [1.20.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted engrampa [sync] (bionic-proposed) [1.20.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-calc [sync] (bionic-proposed) [1.20.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-polkit [sync] (bionic-proposed) [1.20.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted python-caja [sync] (bionic-proposed) [1.20.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted libmatemixer [sync] (bionic-proposed) [1.20.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-system-monitor [sync] (bionic-proposed) [1.20.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-media [sync] (bionic-proposed) [1.20.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted pyqt5 [sync] (bionic-proposed) [5.10.1+dfsg-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (bionic-proposed) [20101020ubuntu540]
-queuebot:#ubuntu-release- Unapproved: accepted mate-themes [source] (bionic-proposed) [3.22.16-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted latte-dock [source] (bionic-proposed) [0.7.4-0ubuntu2]
-queuebot:#ubuntu-release- New binary: eom [s390x] (bionic-proposed/universe) [1.20.0-1] (ubuntu-mate, ubuntukylin)
-queuebot:#ubuntu-release- New binary: eom [amd64] (bionic-proposed/universe) [1.20.0-1] (ubuntu-mate, ubuntukylin)
-queuebot:#ubuntu-release- New binary: eom [ppc64el] (bionic-proposed/universe) [1.20.0-1] (ubuntu-mate, ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-prime [source] (bionic-proposed) [0.8.8]
-queuebot:#ubuntu-release- New binary: eom [arm64] (bionic-proposed/universe) [1.20.0-1] (ubuntu-mate, ubuntukylin)
-queuebot:#ubuntu-release- New binary: eom [i386] (bionic-proposed/universe) [1.20.0-1] (ubuntu-mate, ubuntukylin)
<slangasek> infinity: what's your evening schedule looking like?  anything that you need me to cover / keep eyes on while you're e.g. grabbing a bite?
-queuebot:#ubuntu-release- New binary: eom [armhf] (bionic-proposed/universe) [1.20.0-1] (ubuntu-mate, ubuntukylin)
<infinity> slangasek: I think the current plan is to let the world settle and kick off a fresh set of images before bed (in 4 or 5 hours or so).
-queuebot:#ubuntu-release- New: accepted eom [amd64] (bionic-proposed) [1.20.0-1]
-queuebot:#ubuntu-release- New: accepted eom [armhf] (bionic-proposed) [1.20.0-1]
-queuebot:#ubuntu-release- New: accepted eom [ppc64el] (bionic-proposed) [1.20.0-1]
-queuebot:#ubuntu-release- New: accepted eom [arm64] (bionic-proposed) [1.20.0-1]
-queuebot:#ubuntu-release- New: accepted eom [s390x] (bionic-proposed) [1.20.0-1]
-queuebot:#ubuntu-release- New: accepted eom [i386] (bionic-proposed) [1.20.0-1]
<infinity> apw: ^-- Assuming you are happy with your kernel and let it migrate.
<slangasek> infinity: ok.  do you have a list of must-have packages that I should help shepherd?
<infinity> slangasek: Anything seeded and less than 2 days old (which for most flavours is just kernel/d-i/dkms, I believe, and for mate and kylin is a bunch of stuff that got minor syncs this afternoon.
<infinity> )
<slangasek> that's less a list than it is an algorithm
<slangasek> ok, I'll work through update_excuses
<slangasek> sforshee, apw: I see linux-meta-raspi2 reporting a bunch of arm64 'in progress' tests which I expect won't work.  Are you effectively able to ignore these missing test results on your side?  and would raspi2 be ready to promote already?
<infinity> slangasek: Also did an update run of metas for all flavours, kylin and studio were the only two with pending changes, so lobbing those at the queue.
<infinity> slangasek: And yeah, raspi2 on arm64 tests very unhelpfully install the kernel, reboot, fail to boot (because lol booting raspi2 kernel on kvm), and then go AWOL.
-queuebot:#ubuntu-release- Unapproved: ubuntukylin-meta (bionic-proposed/universe) [0.29 => 0.30] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: ubuntustudio-meta (bionic-proposed/universe) [0.177 => 0.178] (ubuntustudio)
<sforshee> slangasek: I don't know of anything we can do to ignore those on our end, I think apw was looking into it at some point
<slangasek> infinity: yeah, I already badtested linux-raspi2/arm64 itself for this, it's just a question of whether the kernel team is going to appropriately override this
<slangasek> sforshee: to ignore them on your end, 1) manually parse the report with your eyeballs, 2) confirm there are no other blockers aside from these abberant arm64 results, 3) close the blocking bug ;)
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Bionic Final] has been updated (20101020ubuntu540)
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Bionic Final] has been updated (20101020ubuntu540)
-queuebot:#ubuntu-release- Builds: Netboot armhf [Bionic Final] has been updated (20101020ubuntu540)
-queuebot:#ubuntu-release- Builds: Netboot i386 [Bionic Final] has been updated (20101020ubuntu540)
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Bionic Final] has been updated (20101020ubuntu540)
-queuebot:#ubuntu-release- Builds: Netboot s390x [Bionic Final] has been updated (20101020ubuntu540)
<sforshee> slangasek: that works for the tracking bug, britney still seems to want tests to have actually run though
<sforshee> that's the part that we don't seem to have a way to bypass
-queuebot:#ubuntu-release- Unapproved: extundelete (bionic-proposed/universe) [0.2.4-1build1 => 0.2.4-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted extundelete [source] (bionic-proposed) [0.2.4-1ubuntu1]
<sforshee> slangasek: we don't normally promote derivatives before the master kernel do we?
<mparillo> On a Kubuntu Mailing List, I saw a call for testing volunteers for other flavors. This weekend, I could have sworn there were test cases for Lubuntu Next, but I do not see them now. I assume I did something wrong this weekend?
<infinity> mparillo: lubuntu-next ISOs are not being released, they only exist for testing purposes before the switch.
<infinity> (much like kubuntu-active and kubuntu-plasma in the past)
-queuebot:#ubuntu-release- Unapproved: caja (bionic-proposed/universe) [1.20.2-1ubuntu1 => 1.20.2-3ubuntu1] (ubuntu-mate, ubuntukylin, xubuntu)
<mparillo> Thank you. So I must have gone to the Daily this weekend where I saw the Lubuntu Next instead of the Final where I do not..
<slangasek> sforshee: I don't have an opinion on kernel team internal policy wrt ordering of promotions; as far as I'm concerned they don't need to wait for the master to be released first.  As for britney wanting the tests to be run, that's something I can override on our side
-queuebot:#ubuntu-release- Unapproved: ext3grep (bionic-proposed/universe) [0.10.2-3 => 0.10.2-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ext3grep [source] (bionic-proposed) [0.10.2-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ext4magic (bionic-proposed/universe) [0.3.2-7 => 0.3.2-7ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ext4magic [source] (bionic-proposed) [0.3.2-7ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntukylin-meta [source] (bionic-proposed) [0.30]
 * tsimonq2 confirms infinity's statement that Lubuntu Next will not have a release.
<infinity> slangasek: Internal policy is for everything to follow master, just for sanity's sake, since we rely on master testing to expose a bunch of potential problems where flavour testing lacks coverage.
<infinity> slangasek: On the other hand, the only kernel I care about today is master anyway.
<infinity> Well, and I guess raspi2, since it's also baked into an image.
-queuebot:#ubuntu-release- Unapproved: transgui (bionic-proposed/universe) [5.0.1-5ubuntu1 => 5.0.1-5.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted transgui [sync] (bionic-proposed) [5.0.1-5.1]
<infinity> sforshee: Can you speak for master and the rightness or wrongness of removing the proposed block, or are you deferring that to Andy?
<sforshee> infinity: adt on master looks good, sru testing is in progress but I can peek at the results so far
-queuebot:#ubuntu-release- Unapproved: accepted ubuntustudio-meta [source] (bionic-proposed) [0.178]
-queuebot:#ubuntu-release- Unapproved: accepted caja [source] (bionic-proposed) [1.20.2-3ubuntu1]
<tsimonq2> infinity, slangasek: Not urgent, but can I please get eyes on bug 1757658?
<ubot5`> bug 1757658 in holdingnuts (Ubuntu) "Please port your package away from Qt 4" [Medium,Confirmed] https://launchpad.net/bugs/1757658
<tsimonq2> Needs a source package removal of an unseeded Qt 4 package that is dead upstream.
<tsimonq2> Also hasn't seen a Debian upload since oldoldstable, and it's in sync with Debian.
<slangasek> tsimonq2: is this the last one required in order to remove qt4 from bionic?
<tsimonq2> slangasek: Nope.
<tsimonq2> We're a bit far from that goal.
<tsimonq2> 18.10 or 19.04 is more likely.
<slangasek> tsimonq2: then unless you have a complete list of packages that you think it's reasonable for us to remove in order to get qt4 out of bionic, I don't think it's worth rm'ing packages that are not RC buggy in Debian
<slangasek> (currently, Debian bug #874917 is filed as wishlist)
<ubot5`> Debian bug 874917 in src:holdingnuts "[holdingnuts] Future Qt4 removal from Buster" [Wishlist,Open] http://bugs.debian.org/874917
<slangasek> tsimonq2: unless there is more broken in holdingnuts than "using an old toolkit"
<tsimonq2> OK.
 * acheronuk thinks worth keeping just for the name....
<tsimonq2> hehe
<tsimonq2> slangasek: At the beginning of next cycle though, while we're on the subject, I plan on working with acheronuk to drastically reduce the Qt 4 packages in the archive.
<tsimonq2> Taking out KDE 4 is a big part of that.
<tsimonq2> I really don't want to have to support those for the LTS but it's too late now.
-queuebot:#ubuntu-release- Unapproved: shim-signed (bionic-proposed/main) [1.34.4 => 1.34.5] (core)
<sforshee> infinity: so for the tests look okay, but still a lot of tests outstanding. I don't have any ppc results yet.
-queuebot:#ubuntu-release- Unapproved: felix-latin (bionic-proposed/universe) [2.0-8build1 => 2.0-10] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted felix-latin [sync] (bionic-proposed) [2.0-10]
-queuebot:#ubuntu-release- Unapproved: rkward (bionic-proposed/universe) [0.6.5-1 => 0.7.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted rkward [sync] (bionic-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- Unapproved: dkms (bionic-proposed/main) [2.3-3ubuntu8 => 2.3-3ubuntu9] (kubuntu, ubuntu-desktop)
<fossfreedom> huh? I spy a "DD-Series" for PPA's to copy to
<tsimonq2> Like CC-Series, you can't actually build packages for it yet.
<tsimonq2> But, you can target bugs at it.
<fossfreedom> 19.04 seems so far away ...
<tsimonq2> Not really. ;)
<fossfreedom> :)
<slangasek> tsimonq2: one would think you're not under any obligation to support them in the LTS if they're not seeded
<slangasek> sforshee: no ppc results> is everything working there as expected?  do I need to go chasing hardware on your behalf?
<tsimonq2> slangasek: I /guess/...
<sforshee> slangasek: maas iw having trouble talking to the bmc, not sure we have anyone around to troubleshoot that
<sforshee> slangasek: so if there's some hardware to use then I could run the tests manually
<Wimpress> slangasek: You said a kernel was expected. I see it is in proposed. When it lands will also the iso get respun?
<slangasek> Wimpress: yes.  that's the trigger for all of the respins that infinity mentioned in his "test now" email
<slangasek> sforshee: is this on entei or on some other machine?
-queuebot:#ubuntu-release- Unapproved: mutter (bionic-proposed/main) [3.28.1-1 => 3.28.1-1ubuntu1] (desktop-extra, ubuntu-desktop)
<slangasek> mutter grumble
<slangasek> sforshee: not sure we have anyone around> we absolutely need to get this unblocked ASAP
-queuebot:#ubuntu-release- Unapproved: gnome-shell (bionic-proposed/main) [3.28.1-0ubuntu1 => 3.28.1-0ubuntu2] (desktop-extra, mozilla, ubuntu-desktop)
<jbicha> not sure there's a big difference between mutter and grumble ;)
<jbicha> infinity: could you have cc-series derive from Buster (maybe even Sid)? The "derived from" section at https://launchpad.net/ubuntu/bionic wasn't very useful
-queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (bionic-proposed) [1.34.5]
-queuebot:#ubuntu-release- Unapproved: deepin-icon-theme (bionic-proposed/universe) [15.12.56-1 => 15.12.56-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted deepin-icon-theme [sync] (bionic-proposed) [15.12.56-3]
-queuebot:#ubuntu-release- Unapproved: scala (bionic-proposed/universe) [2.11.12-1 => 2.11.12-2] (no packageset) (sync)
<rbalint> Laney: re: modemmanager and libqmi why -Wno-error or cast is better than setting proper glib api? new upstream is waiting in unstable anyway for next sync
-queuebot:#ubuntu-release- Unapproved: accepted scala [sync] (bionic-proposed) [2.11.12-2]
-queuebot:#ubuntu-release- Unapproved: php-sabredav (bionic-proposed/universe) [1.8.12-3ubuntu2 => 1.8.12-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted php-sabredav [sync] (bionic-proposed) [1.8.12-5]
<rbalint> Laney: both -Wno-error and casting can hide problems later while it is true that modemmanager and libqmi don't work with newer API
-queuebot:#ubuntu-release- Unapproved: flightgear (bionic-proposed/universe) [1:2017.3.1+dfsg-4 => 1:2018.1.1+dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-meta (bionic-proposed/universe) [1.223 => 1.224] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: accepted flightgear [sync] (bionic-proposed) [1:2018.1.1+dfsg-1]
<sforshee> slangasek: bjf got the machine back, it's going to take a bit if we want to run all the testing though
<sforshee> so what's your timeline?
-queuebot:#ubuntu-release- Unapproved: dkms (bionic-proposed/main) [2.3-3ubuntu8 => 2.3-3ubuntu9] (kubuntu, ubuntu-desktop)
<slangasek> sforshee: I want a thoroughly tested golden kernel, ready to release, asap; and I want you to tell me when that will be :-)
<slangasek> sforshee: I don't want to take any shortcuts on the testing but I want to know if we're going to miss infinity's window for this being done tonight
<slangasek> sforshee: (he said "4 or 5 hours" 2 hours ago, so if the tests will take longer than 3h then I need to know that in order to coordinate a handoff from infinity)
<sforshee> slangasek: it will be more than 3 hours
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-settings (bionic-proposed/universe) [18.04.16 => 18.04.17] (ubuntu-mate)
<slangasek> sforshee: ok. how many more?
<slangasek> infinity: ^^ you don't get ppc64el-tested kernels promoted to bionic within your "4-5 hours" window.  Do you want to tag me in to do the respins once this has all landed?  Do you want to give me the command list you want me to run?
<slangasek> infinity: alternatively, should we opportunistically promote this kernel as soon as we have initial smoketest results on ppc64el?
<sforshee> slangasek: I honestly don't know, we don't usually watch them that closely. Let me see if I can get a rough estimate from previous runs.
<slangasek> sforshee: ta
<Laney> rbalint: Casting is not a problem.
<Laney> Building in the distro with Werror is quite often a problem
<Laney> (not here)
-queuebot:#ubuntu-release- Unapproved: dkms (bionic-proposed/main) [2.3-3ubuntu8 => 2.3-3ubuntu9] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rejected dkms [source] (bionic-proposed) [2.3-3ubuntu9]
-queuebot:#ubuntu-release- Unapproved: rejected dkms [source] (bionic-proposed) [2.3-3ubuntu9]
<rbalint> Laney: is setting proper API version limits a problem?
<rbalint> Laney: because this is less intrusive and cheaper than starting fixing casts
<sforshee> slangasek: my best guess is about 5-6 hours, that's a really rough estimate though
<slangasek> sforshee: ok thanks
-queuebot:#ubuntu-release- Unapproved: accepted dkms [source] (bionic-proposed) [2.3-3ubuntu9]
-queuebot:#ubuntu-release- Unapproved: netplan.io (bionic-proposed/main) [0.36 => 0.36.1] (core)
-queuebot:#ubuntu-release- Unapproved: ikarus (bionic-proposed/universe) [0.0.3+bzr.2010.01.26-4build1 => 0.0.3+bzr.2010.01.26-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ikarus [source] (bionic-proposed) [0.0.3+bzr.2010.01.26-4ubuntu1]
<sil2100> infinity: reviewing the fixed netboot.io from the queue
<sil2100> s/netboot.io/netplan.io
-queuebot:#ubuntu-release- Unapproved: accepted netplan.io [source] (bionic-proposed) [0.36.1]
-queuebot:#ubuntu-release- Unapproved: command-not-found (bionic-proposed/main) [18.04.3 => 18.04.4] (core)
-queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (bionic-proposed/multiverse) [5.2.10-dfsg-4ubuntu18.04.1 => 5.2.10-dfsg-5ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-hwe [source] (bionic-proposed) [5.2.10-dfsg-5ubuntu18.04.1]
<sil2100> infinity, apw: are we still waiting for the kernels to migrate? Since I see d-i is blocked on that
<slangasek> sil2100: we are
<slangasek> sil2100: according to sforshee we have several hours before the ppc64el tests complete.  We could potentially release the packages into the release opportunistically
<slangasek> sil2100: knowing that if the ppc64el kernel fails its tests, we will need another iteration
 * sil2100 sneaks in the c-n-f before Adam can kill him for it
<slangasek> jbicha: php-sabredav, regressed autopkgtests
<slangasek> I swear proposed-migration is running more slowly because we're watching it
<slangasek> either that or ftp-master is very sad
-queuebot:#ubuntu-release- Unapproved: accepted command-not-found [source] (bionic-proposed) [18.04.4]
<sforshee> slangasek: based on the progress so far I'm fearing they'll take longer than I guessed
<slangasek> sforshee: have the tests gotten far enough along before failing that you would consider this a good smoketest for ppc64el?  what do you think about us promoting the kernels now in order to unblock image builds, and dealing with any ppc64el failures after the tests finish?
<sforshee> slangasek: the qa regression tests ran without errors so I'd say that's pretty good
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-meta [source] (bionic-proposed) [1.224]
<sil2100> hm
<slangasek> sforshee: do you want to start clearing blocking bugs on your side, then?  with the understanding that it's still a high priority to get a green test for ppc64el for release and we might still respin the world if we have to bump the kernel
<sil2100> If the kernel teams feel it's safe to lift the block tags from the kernels, I'm fine with that (especially that we're blocked on this)
<jbicha> slangasek: yes I am reopening the Debian bug for php-sabredav
-queuebot:#ubuntu-release- Unapproved: gcc-h8300-hms (bionic-proposed/universe) [1:3.4.6+dfsg2-4ubuntu2 => 1:3.4.6+dfsg2-4ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-h8300-hms [source] (bionic-proposed) [1:3.4.6+dfsg2-4ubuntu3]
<sforshee> slangasek: are you ok with us not having adt results for systemd against this kernel?
<sforshee> I just started them, not sure how long they usually take
<slangasek> sforshee: I do see systemd results at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#linux-meta; what's missing?
<sforshee> slangasek: they just showed up as miss in the adt matrix, typically that would mean a new systemd promoted and we don't have results against that version
<slangasek> oh
<slangasek> sforshee: I don't think the changes between systemd 237-3ubuntu8 and 237-3ubuntu10 are interesting wrt kernel promotion
<sforshee> ok
<slangasek> one networkd change; one udev-udeb change; one journald change
<sil2100> Ok, seeing that this will still take a while, I think I'll go to sleep now
<sil2100> I saw the s390x netplan.io tests failing again with the new version, but this seemed a bit more racy - I re-ran it just in case
<slangasek> sil2100: netplan.io/s390x is listed always-failed
<slangasek> anyway, g'night!
<sil2100> Ah, crap, right! I was just opening all the tests for netplan that run
<slangasek> hmph, we didn't drop the transitional nplan package from the minimal seed
<slangasek> (and I don't plan to now)
<sil2100> Oh well, not perfect I guess but I don't see a big issue leaving it as is
<sil2100> But I might not understand all the consequences of course
<slangasek> sil2100: just cruft left behind forever on systems ;)
<sil2100> ;)
<sil2100> Ok, netplan.io amd64 failed, that one should be passing
<sforshee> slangasek: ok I removed the blocking tags from the bugs
<slangasek> sil2100: yes; I've already retried it; was discussing on internal chan w/ cyphermox about the apparent raciness of ipv6 after systemd-networkd changes
<sil2100> The test-suite seems to be flaky so I guess this might just need a re-run
<sil2100> slangasek: thanks!
<cyphermox> one of these two tests should definitely not have failed, the other is expected fallout from networkd changes
<sforshee> slangasek: we're only worried about master and raspi2 right now? Or do I also need to check testing on the others?
<cyphermox> I'm not sure they will be racy; might be permanent fail until I fix it
<sil2100> Ok, I see things are in capable hands as always, good night!
<cyphermox> slangasek: ah, I didn't notice it passed once
<slangasek> sforshee: master and raspi2 are the priority for spinning images.  I am interested in having them all in today if possible, it's not as urgent but we do need to get on with the cloud image builds as well
<sforshee> I'll see where they are at
<cyphermox> slangasek: now I go fix shim-signed one more time; shim-signed MOK migration take UINT_MAX
<slangasek> cyphermox: what else needs fixing there? nothing else was on my radar
<cyphermox> bumping version in migration?
<slangasek> cyphermox: oh yes
<slangasek> cyphermox: thanks ;-)
<cyphermox> np. I do need to have a quick check though; hoping extra appended signatures wouldn't break things
<slangasek> badtesting netplan.io/0.36.1 since we understand the cause of these regressions and need that in asap
<slangasek> which I think means there's nothing else we're waiting for except the next p-m + publisher run
<Wimpress> slangasek: Please can you accept ubuntu-mate-settings 18.04.17
<sforshee> slangasek: we still don't have a lot of results for the azure and kvm kernels, aws is looking fine though
<slangasek> Wimpress: looking
<slangasek> sforshee: what other results are you lacking on azure? http://people.canonical.com/~kernel/status/adt-matrix/bionic-linux-meta-azure.html looks complete to me
<sforshee> slangasek: our sru testing
<slangasek> sforshee: and that shows up somewhere other than the matrix?
<sforshee> slangasek: yep
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-settings [source] (bionic-proposed) [18.04.17]
<cyphermox> sforshee: once I'm done with this I'm happy to help testing azure/kvm kernels if you tell me what the testing entails
<slangasek> I expect it's all automated and we just need to wait :)
<slangasek> sforshee, cyphermox: anyway, if testing is still in progress on those, I don't need to rush it
<Wimpress> slangasek: Thanks.
<sforshee> slangasek: http://kernel.ubuntu.com/sru/dashboards/web/kernel-stable-board.html has links
<sforshee> and yes it's automated
<cyphermox> ack
<cyphermox> shim-signed incoming.\
-queuebot:#ubuntu-release- Unapproved: shim-signed (bionic-proposed/main) [1.34.5 => 1.34.6] (core)
-queuebot:#ubuntu-release- Unapproved: shim-signed (bionic-proposed/main) [1.34.5 => 1.34.6] (core)
<cyphermox> err?
-queuebot:#ubuntu-release- Unapproved: shim-signed (bionic-proposed/main) [1.34.5 => 1.34.6] (core)
#ubuntu-release 2018-04-24
<slangasek> sforshee: yes it has links, to internal IPs I don't have access to. ohwell :)
<slangasek> Trevinho, jbicha: hi, I haven't seen any commentary on whether and why the mutter + gnome-shell uploads are critical for release; if you're expecting this to land in the GA image please fill us in on the details
<slangasek> Trevinho, jbicha: as we are otherwise just about to start rolling candidate images, and need to know whether to hold off ubuntu + budgie until these are in
<slangasek> sforshee: linux tests appear to have passed on ppc64el http://autopkgtest.ubuntu.com/packages/l/linux/bionic/ppc64el
-queuebot:#ubuntu-release- Unapproved: mutter (bionic-proposed/main) [3.28.1-1 => 3.28.1-2] (desktop-extra, ubuntu-desktop) (sync)
<jbicha> slangasek: seb128 at least wanted the gnome-shell policykit fix in for release. maybe mutter wouldn't hurt too?
-queuebot:#ubuntu-release- Unapproved: mutter (bionic-proposed/main) [3.28.1-1 => 3.28.1-2] (desktop-extra, ubuntu-desktop) (sync)
<jbicha> here's a mutter sync if you prefer. It's practically the same as the ubuntu1 upload
-queuebot:#ubuntu-release- Unapproved: mutter (bionic-proposed/main) [3.28.1-1 => 3.28.1-2] (desktop-extra, ubuntu-desktop) (sync)
 * jbicha stares at queuebot
-queuebot:#ubuntu-release- Unapproved: mutter (bionic-proposed/main) [3.28.1-1 => 3.28.1-2] (desktop-extra, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: mutter (bionic-proposed/main) [3.28.1-1 => 3.28.1-2] (desktop-extra, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: mutter (bionic-proposed/main) [3.28.1-1 => 3.28.1-2] (desktop-extra, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: mutter (bionic-proposed/main) [3.28.1-1 => 3.28.1-2] (desktop-extra, ubuntu-desktop) (sync)
<jbicha> queuebot: stop muttering!
<slangasek> jbicha: I have no reason to prefer a sync; I prefer that someone tell me it's worth delaying the start of candidate image spins by 2+h
-queuebot:#ubuntu-release- Unapproved: mutter (bionic-proposed/main) [3.28.1-1 => 3.28.1-2] (desktop-extra, ubuntu-desktop) (sync)
<slangasek> jbicha: I mean, I prefer someone tell me /whether/ it's worth delaying; obviously all things being equal I prefer that to not be the answer ;)
-queuebot:#ubuntu-release- Unapproved: mutter (bionic-proposed/main) [3.28.1-1 => 3.28.1-2] (desktop-extra, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: mutter (bionic-proposed/main) [3.28.1-1 => 3.28.1-2] (desktop-extra, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: mutter (bionic-proposed/main) [3.28.1-1 => 3.28.1-2] (desktop-extra, ubuntu-desktop) (sync)
<jbicha> there apparently is no one around for Desktop now but me
-queuebot:#ubuntu-release- Unapproved: mutter (bionic-proposed/main) [3.28.1-1 => 3.28.1-2] (desktop-extra, ubuntu-desktop) (sync)
<jbicha> my understanding is that Seb did really want that gnome-shell fix in but understands if it ends up being a 0-day SRU instead
-queuebot:#ubuntu-release- Unapproved: mutter (bionic-proposed/main) [3.28.1-1 => 3.28.1-2] (desktop-extra, ubuntu-desktop) (sync)
<jbicha> unfortunately, I guess there's a decent chance we'll end up respinning again :(
-queuebot:#ubuntu-release- Unapproved: mutter (bionic-proposed/main) [3.28.1-1 => 3.28.1-2] (desktop-extra, ubuntu-desktop) (sync)
<jbicha> it doesn't feel like that particular bug is technically release criticalâ¦ so maybe there's no need to wait on spinning up candidates
-queuebot:#ubuntu-release- Unapproved: mutter (bionic-proposed/main) [3.28.1-1 => 3.28.1-2] (desktop-extra, ubuntu-desktop) (sync)
<slangasek> jbicha: ok
<jbicha> on the other hand, it looks like queuebot really wants you to accept mutter or something
-queuebot:#ubuntu-release- Unapproved: mutter (bionic-proposed/main) [3.28.1-1 => 3.28.1-2] (desktop-extra, ubuntu-desktop) (sync)
 * slangasek goes with "or something"
-queuebot:#ubuntu-release- Unapproved: mutter (bionic-proposed/main) [3.28.1-1 => 3.28.1-2] (desktop-extra, ubuntu-desktop) (sync)
<jbicha> lol
<Trevinho> slangasek: mutter one would be nicer to have, as otherwise we're getting lots of errors and whoopsie dialogs for the wrong reason, but in theory we could even wait for .1. For shell surely we can wait if it makes things problematic
<Trevinho> I had these prepared before the FF, but they were not sposorized, so we ended up pushing them later
<sforshee> slangasek: systemd tests are failing with all the amd64 kernels ...
<slangasek> Trevinho: taking any new packages is problematic in the sense that it pushes back the timeline for spinning candidate images.  "whoopsie dialogs" on the live image sound like a bad thing, to be sure
<Trevinho> well, not that they show all the time
<Trevinho> but they might show on Xwayland issues pointing out that the problem is in mutter instead (which is not true)
<slangasek> sforshee: that's not a bug in the kernel but in the tests.  The fact that linux-image now comes from linux-signed source instead of linux source confuses the way we're running the tests and will need fixed
<sforshee> slangasek: that's good to hear
<slangasek> sforshee: I can try to run some tests that include linux-signed if that would give you greater confidence
-queuebot:#ubuntu-release- Unapproved: dehydrated (bionic-proposed/universe) [0.6.1-1 => 0.6.1-2] (no packageset) (sync)
<slangasek> Trevinho: ok. for the moment I'm focused on getting us to where we can start spinning images and if you or seb128 decide this is critical to fix in the GA image we can revisit
<sforshee> slangasek: I was already coming to the conclusion that it wasn't a kernel issue anyway, so it's fine
<Trevinho> slangasek: for sure not critical, and if it makes more problems than improvements, just don't mind about that.... we'll SRU it
<slangasek> sforshee: I did go ahead and kick off fresh tests, might as well make use of that idle cloud
<sforshee> ack
<infinity> slangasek: Looking at excuses, it looks like mate-settings and shim-signed are the only things currently migrating?
<infinity> slangasek: (or migrated)
<infinity> slangasek: There are definitely some more ubiquity fixes we want to land tomorrow, but I think we want a full respin tonight to see if people can test the new kernel and discover bits that have gone goofy with the package reorg.
<infinity> slangasek: So, from the nusakan CLI, run the full ubuntu-server pipeline from crontab, and then on iso.qa, request rebuilds for all desktop ISOs.  Don't bother with base.
<infinity> slangasek: (once that shim-signed is definitely published)
<slangasek> infinity: they are in the process of migrating yes
<slangasek> infinity: and I've twiddled OFFICIAL in CONF.sh
<infinity> slangasek: If we can get solid kernel testing over the next 12+ hours, then we can tidy up any remaining bugs (or hope for none), finalize base-files and OFFICIAL, and spin final tomorrow night.
<infinity> slangasek: Or twiddle OFFICIAL now. :P
<slangasek> is base-files not yet finalized? it's no longer in the queue, which I though it was previously
<slangasek> hmm
<infinity> slangasek: It was rejected to avoid premature acceptance.  Didn't actually review it to make sure it was sane.
<slangasek> I assumed it being gone meant it was already in
<slangasek> so, I guess anything I spin now will clearly also not be final
<slangasek> want me to review that now?
<infinity> slangasek: Nah, like I said, I'm pretty positive we'll have more fixes tomorrow.
<slangasek> ok
<infinity> slangasek: I just want a respin tonight because this kernel shuffle can't possibly have no side-effects (though, I'm prepared to be pleasantly surprised)
<slangasek> well, in that respect maybe it's useful for me to respin ubuntu-server now without waiting for shim-signed, to verify whether building a d-i-based image succeeds
<infinity> slangasek: d-i is the only one that I'm pretty sure won't be harmed.
<infinity> slangasek: Since the CD bits come from the d-i build (which I made sure is fine), and the kernel is installed by installing packages.
<slangasek> ah :)
<slangasek> "sophos running at time of implementation, blocking the update" wtf? https://bugs.launchpad.net/ubuntu/+source/shim-signed/+bug/1766385
<ubot5`> Ubuntu bug 1766385 in shim-signed (Ubuntu) "package shim-signed 1.34.5+13-0ubuntu2 failed to install/upgrade: installed shim-signed package post-installation script subprocess returned error exit status 1" [Undecided,New]
-queuebot:#ubuntu-release- Unapproved: xfpanel-switch (bionic-proposed/universe) [1.0.7-0ubuntu1 => 1.0.7-0ubuntu2] (ubuntustudio, xubuntu)
<infinity> slangasek: A quick look at debian-cd implies that live-based images should probably end up with a bootable kernel.  A quick scrub of ubiquity looks like it'll DTRT.  The code is now entirely logically wrong WRT it thinking there's no "signed kernel", but the result will be correct, I think.
<infinity> slangasek: Anyhow, better to test than to read code and assume I parse python the same was as the interpreter.
<slangasek> k
<infinity> s/was/way/
<infinity> slangasek: We'll also have the bug all over that we install the linux-signed transitional meta when we don't need to.  I think I'll defer that bug for 18.04.1, unless all the fixes jump out as obvious in the first couple of hours in the office tomorrow.
<slangasek> infinity: I would suggest deferring it entirely to 18.10, it's just an extra dummy package
<infinity> slangasek: Or that.  Not super picky about the cruft indeed.
 * infinity is going to try to get a nap in before morning in the arctic circle slaps him in the face.
<infinity> Sunrise before 6am is barbaric.
<bluesabre> That sounds unpleasant.
-queuebot:#ubuntu-release- Unapproved: dgit (bionic-proposed/universe) [4.3 => 4.4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted dgit [sync] (bionic-proposed) [4.4]
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Bionic Final] has been updated (20180424)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Bionic Final] has been updated (20180424)
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Bionic Final] has been updated (20180424)
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Bionic Final] has been updated (20180424)
<slangasek> button pushing
-queuebot:#ubuntu-release- Unapproved: hugo (bionic-proposed/universe) [0.39-1 => 0.40-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted hugo [sync] (bionic-proposed) [0.40-1]
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Bionic Final] has been updated (20180424)
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Bionic Final] has been updated (20180424)
-queuebot:#ubuntu-release- Unapproved: nvptx-tools (bionic-proposed/universe) [0.20171010-1 => 0.20180301-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted nvptx-tools [sync] (bionic-proposed) [0.20180301-1]
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Bionic Final] has been updated (20180424.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Bionic Final] has been updated (20180424.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Bionic Final] has been updated (20180424.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Bionic Final] has been updated (20180424.1)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Bionic Final] has been updated (20180424)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Bionic Final] has been updated (20180424)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Bionic Final] has been updated (20180424)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Bionic Final] has been updated (20180424)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Bionic Final] has been updated (20180424)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Bionic Final] has been updated (20180424)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Bionic Final] has been updated (20180424)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Bionic Final] has been updated (20180424)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Bionic Final] has been updated (20180424)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Bionic Final] has been updated (20180424)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Bionic Final] has been updated (20180424)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Bionic Final] has been updated (20180424)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Bionic Final] has been updated (20180424)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Bionic Final] has been updated (20180424)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Bionic Final] has been updated (20180424)
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Bionic Final] has been updated (20180424)
<powersj> slangasek: were the server live images going to be rebuilt as well?
<slangasek> powersj: yes, there's one building now (delayed due to terminal copy-paste being terrible for me for some reason I haven't debugged), and there'll be another after mwhudson's updated subiquity snap lands (plus a yet-to-be-uploaded shim-signed)
<mwhudson> the snap is in stable now btw
<mwhudson> but it missed the current build
<powersj> slangasek: safe to test the ubiquity isos though right?
<powersj> and thanks
<slangasek> powersj: they need testing but they're also not final
<slangasek> they're just the ones that have the major kernel+bootloader changes (finally) landed
<slangasek> mwhudson: what revision?
<mwhudson> slangasek: 346 on amd64
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Bionic Final] has been updated (20180424)
<ogasawara> slangasek: I've been notified of bug 1766391.  I will ask apw to address it first thing his morning which is about 3-4hrs from now.
<ubot5`> bug 1766391 in shim-signed (Ubuntu Bionic) "package shim-signed (not installed) failed to install/upgrade: installed shim-signed package post-installation script subprocess returned error exit status 5" [Critical,Triaged] https://launchpad.net/bugs/1766391
<slangasek> ogasawara: ok. I'm not sure what to do with it in the meantime then, since this leaves all users who are upgrading to the kernel in the release pocket broken wrt dkms modules
<slangasek> ogasawara: I can leave it as-is, or I can revert the kernel in the release pocket to -15
<slangasek> granted, it's going to be a lot more than 4h either way before we have a fixed -20 kernel, so that's probably something to figure out
<ogasawara> slangasek: I'm ok if you want to revert it to avoid more carnage because as you say, it's going to be a few hours to get another upload in over the top
<ogasawara> sforshee: ^^
<sforshee> fine with me to revert it
<slangasek> sforshee, ogasawara: on balance, I think we should leave it in; anyone doing a new install is going to have to manually deal with the dkms problem, but those are only test images so that's ok; and anyone who is upgrading only needs to reboot to the old kernel to get back to their working modules, then wait for the fixed kernel to land
<slangasek> it's a one-liner fix to the kernel packaging, so I'll try to have something waiting for apw in the morning
<slangasek> (unless sforshee wants to land it before then)
<sforshee> slangasek: I'm on it, will spin the master and raspi2 kernels at least tonight
<slangasek> sforshee: oh excellent
<slangasek> sforshee: thanks
<sforshee> slangasek: I'll just upload this direct to -proposed, will let you know once I've done that
<slangasek> sforshee: ta
-queuebot:#ubuntu-release- Unapproved: libabigail (bionic-proposed/universe) [1.1-1 => 1.2-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted libabigail [source] (bionic-proposed) [1.2-1]
-queuebot:#ubuntu-release- Unapproved: shim-signed (bionic-proposed/main) [1.34.6 => 1.34.7] (core)
-queuebot:#ubuntu-release- Unapproved: rejected shim-signed [source] (bionic-proposed) [1.34.7]
-queuebot:#ubuntu-release- Unapproved: shim-signed (bionic-proposed/main) [1.34.6 => 1.34.7] (core)
<slangasek> infinity, apw, cyphermox: self-accepting shim-signed 1.34.7 after copious testing of the various possible dkms states; more eyeballs welcome when they're available but critical upgrade bug etc
-queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (bionic-proposed) [1.34.7]
-queuebot:#ubuntu-release- Unapproved: linux-meta (bionic-proposed/main) [4.15.0.19.20 => 4.15.0.20.21] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: linux-signed (bionic-proposed/main) [4.15.0-19.20 => 4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: linux (bionic-proposed/main) [4.15.0-19.20 => 4.15.0-20.21] (core, kernel)
<slangasek> tseliot: I think nvidia-headless-390 nvidia-headless-no-dkms-390 want seeding somewhere to keep them in restricted instead of multiverse
<slangasek> sforshee: thanks for the uploads.  I need to run out to the store, I'll review as soon as I'm back
-queuebot:#ubuntu-release- Unapproved: gcc-6 (bionic-proposed/universe) [6.4.0-16ubuntu1 => 6.4.0-17ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-6 [source] (bionic-proposed) [6.4.0-17ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gcc-6-cross-ports (bionic-proposed/universe) [28ubuntu2 => 28ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gcc-6-cross (bionic-proposed/universe) [30ubuntu2 => 30ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-6-cross-ports [source] (bionic-proposed) [28ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-6-cross [source] (bionic-proposed) [30ubuntu3]
-queuebot:#ubuntu-release- Unapproved: linux-meta-raspi2 (bionic-proposed/universe) [4.15.0.1009.7 => 4.15.0.1010.8] (kernel)
-queuebot:#ubuntu-release- Unapproved: linux-raspi2 (bionic-proposed/universe) [4.15.0-1009.10 => 4.15.0-1010.11] (kernel)
-queuebot:#ubuntu-release- Unapproved: virtualbox (bionic-proposed/multiverse) [5.2.10-dfsg-2 => 5.2.10-dfsg-5] (ubuntu-cloud) (sync)
-queuebot:#ubuntu-release- Unapproved: virtualbox (bionic-proposed/multiverse) [5.2.10-dfsg-2 => 5.2.10-dfsg-5] (ubuntu-cloud) (sync)
<sforshee> slangasek: raspi2 uploaded, going to bed now
<ogasawara> slangasek: calling it a night here as well.  call me if there's more fires.  I've sent email to the team to start respinning the bionic derivative kernels once the EU crew comes online shortly.
-queuebot:#ubuntu-release- Unapproved: handbrake (bionic-proposed/universe) [1.0.7+ds1-2build3 => 1.1.0+ds1-1] (no packageset) (sync)
<slangasek> sforshee, ogasawara: thanks, good night
-queuebot:#ubuntu-release- Unapproved: accepted handbrake [sync] (bionic-proposed) [1.1.0+ds1-1]
-queuebot:#ubuntu-release- Unapproved: accepted linux [source] (bionic-proposed) [4.15.0-20.21]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta [source] (bionic-proposed) [4.15.0.20.21]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed [source] (bionic-proposed) [4.15.0-20.21]
<cpaelzer> hi release Team, one question for a CVE in DPDK
<cpaelzer> I "could" just run syncpackage -r bionic-proposed -d unstable -v -V 17.11.2-1 dpdk to get the fixes we need for the CVE
<cpaelzer> but we are so close to the release that I wonder if we need to do otherwise
<cpaelzer> I can hand over to the security Team to push to -security right after release maybe?
<cpaelzer> or would we still be willing and able to do the sync now, let it build and migrate
<cpaelzer> guidance is welcome, let me know which path I should start with (sync now or pass to security Team)
-queuebot:#ubuntu-release- Unapproved: accepted linux-raspi2 [source] (bionic-proposed) [4.15.0-1010.11]
<slangasek> cpaelzer: dpdk is in main but not seeded on any images; we could take it today, but it would need to be a targeted fix in order to be accepted, which I don't know if the sync is
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-raspi2 [source] (bionic-proposed) [4.15.0.1010.8]
<cpaelzer> slangasek: it is a special early stable release for the cve
<slangasek> infinity, apw: linux 4.15.0-20.21 has the critical fixes for dkms breakage; I suppose that's eta 4h for the linux package to be built, then various delays for getting linux-signed and d-i built and everything migrated
<cpaelzer> it has two minor fixes that were queued before
<cpaelzer> and otherwise just the CVE
<cpaelzer> see https://dpdk.org/doc/guides-17.11/rel_notes/release_17_11.html section "2.8.2. 17.11.2"
<slangasek> infinity, apw: with that, I'm signing off for the night; enjoy the respinning
<cpaelzer> slangasek: also we have a SRU exception for such minor releases (even if it would not be just a CVE fix)
<slangasek> cpaelzer: if it's anything that looks non-trivial upon code inspection by a release team member, it'll likely get kicked back; you can always upload it and try, though
<slangasek> cpaelzer: final freeze is more strict than the SRU process because there's a fixed deadline for reverts
<cpaelzer> I haven't started with the MRE paperwork yet as this is so time critical and limited to the CVE fixes - so I wanted to ask before wasting time
<cpaelzer> slangasek: well then it certainly looks WAY++ more complex than usual
<cpaelzer> slangasek: so lets do it as post release security update right away
<cpaelzer> slangasek: thanks for guidance, that was just what I needed
-queuebot:#ubuntu-release- New binary: linux [s390x] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: ukui-menu (bionic-proposed/universe) [1.1.2-0ubuntu1 => 1.1.3-0ubuntu1] (ubuntukylin)
<acheronuk> tseliot: new did nvidia-prime fixed sddm issues as well. thanks
 * acheronuk downloads new isos
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Bionic Final] has been updated (20180424.1)
<tseliot> acheronuk: great, thanks for letting me know
<acheronuk> tseliot: I see this in ubuntu-drivers-common, but yet no microcode on isos with the kernels. https://launchpad.net/ubuntu/+source/ubuntu-drivers-common/1:0.5
<acheronuk> duh. I mean. https://launchpad.net/ubuntu/+source/ubuntu-drivers-common/1:0.4.23.3
<valorie> could connect to the crazy bug I kept running into with oem installs: LP: #1766056
<ubot5`> Launchpad bug 1766056 in ubiquity (Ubuntu) "in Kubuntu Bionic oem install, after installer finishes, it won't shut down to allow reboot" [Undecided,Confirmed] https://launchpad.net/bugs/1766056
<acheronuk> apw: so that changes says driver manager detection for microcode with be dropped as kernel meta will depend on microcode, but the 2nd part of that has not been done yet?
<seb128> slangasek, could you consider the gnome-shell update for release?
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
<acheronuk> *will be dropped
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
<acheronuk> so we are doing bionic finals without LP: #1738259 being fixed for bionic?
<ubot5`> Launchpad bug 1738259 in linux-meta (Ubuntu Bionic) "need to ensure microcode updates are available to all bare-metal installs of Ubuntu" [Critical,Triaged] https://launchpad.net/bugs/1738259
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [source] (bionic-proposed) [3.28.1-0ubuntu2]
<slangasek> acheronuk: microcode> correct. most recent version still showed regressions; it's currently targeted at the first SRU cycle after bionic releases
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux [s390x] (bionic-proposed) [4.15.0-20.21]
<Wimpress> slangasek: WIll the images respin for this new kernel?
<slangasek> Wimpress: yes
<Wimpress> Thanks.
<slangasek> (they were going to be respun anyway, according to infinity)
<Wimpress> OK, good to know.
<Wimpress> The MATE QA team are going to start testing the new images now.
<acheronuk> slangasek: ok then. was very doubtful it could be an omission in error, but I had to query. thanks
<seb128> slangasek, hey, saw my gnome-shell ping? :)
<slangasek> seb128: yah, have accepted it. I was going to look at mutter as well, which I suppose you might also like?
<seb128> ah, I didn't notice the accepted, thanks!
<seb128> that would be nice
-queuebot:#ubuntu-release- Unapproved: accepted mutter [source] (bionic-proposed) [3.28.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted xfpanel-switch [source] (bionic-proposed) [1.0.7-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ukui-menu [source] (bionic-proposed) [1.1.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox [sync] (bionic-proposed) [5.2.10-dfsg-5]
<slangasek> oh, somebody else is awake and reviewing
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox [sync] (bionic-proposed) [5.2.10-dfsg-5]
<slangasek> (rather quick reviews, apparently! :)
<infinity> slangasek: I tend to review in batches, then accept.
<slangasek> infinity: fair :)
<infinity> Also, d'oh on the 1-char bug in headers.postinst.in :(
<infinity> And pretty obvious why we both missed it in review too, since that directory totally *should* be called headers_postinst, not header_postinst.
<LocutusOfBorg> can anybody please do a quick removal? LP: #1765392
<ubot5`> Launchpad bug 1765392 in hedgewars (Ubuntu) "please remove hedgewars on ppc64el" [Undecided,New] https://launchpad.net/bugs/1765392
<LocutusOfBorg> I'll probably drop ppc64el from supported archs
<infinity> "Unfortunately this already happened with arm64"... where it's currently built?
<LocutusOfBorg> it is in Ubuntu, but not in Debian
<LocutusOfBorg> the fact is that converting pascal to c, and then building with clang (because gcc lacks of some features), is PITA and unsupported upstream
<LocutusOfBorg> https://buildd.debian.org/status/logs.php?pkg=hedgewars&arch=arm64
<LocutusOfBorg> you can see how arm64 sucks :)
<infinity> If it's unsupported upstream, why are you doing it that way?
<LocutusOfBorg> oh hold on, now arm64 has fpc bootstrapped
<LocutusOfBorg> so the problem is "fixed" and will be fixed once ppc64el is bootstrapped too
<LocutusOfBorg> I just tried to provide it (upstream gave the possibility to use this experimental pas2c binding), while waiting for the new fpc, ppc64el ready
-queuebot:#ubuntu-release- Unapproved: linux-gcp (bionic-proposed/main) [4.15.0-1005.5 => 4.15.0-1006.6] (kernel)
-queuebot:#ubuntu-release- Unapproved: linux-meta-gcp (bionic-proposed/main) [4.15.0.1005.7 => 4.15.0.1006.8] (kernel)
<LocutusOfBorg> but in the meanwhile fpc got some new ports, and upstream will probably drop it
<infinity> LocutusOfBorg: so, if you weren't building it this weird way, it would build on ppc64el?
<LocutusOfBorg> too much effort, because pascal is not case sensitive, so the conversion fails badly a lot of times, requiring lots of patches just because of case-sensitiveness and other stuff
<infinity> That doesn't seem like a reason for removal. :P
<LocutusOfBorg> infinity, there is no fpc on ppc64el
<LocutusOfBorg> so, I can't :/
<LocutusOfBorg> pas2c is the workaround for this
<infinity> Ahh.  So, instead of goofy workarounds, just use fpc, and I'll remove that binary, yes.
<infinity> But do the former first.
<infinity> I'm not removing some heisenbinary that might magically build again later.
<LocutusOfBorg> ack
<LocutusOfBorg> it will become building magically once fpc is ported, and will build in "the right way" (tm)
<slangasek> infinity: should we just drop pkg-create-dbgsym from the archive? ftbfs and debhelper conflicts/replaces it
<LocutusOfBorg> wasn't pkg-create-foo droppable only after 18.04?
<slangasek> why?  it's for all intents and purposes uninstallable in any build environment
<LocutusOfBorg> I remember requesting the same some months ago on this channel, sorry my memory fails now
<LocutusOfBorg> (I trusted the answer and went to another topic)
<infinity> slangasek: We should drop it, but someone should also fix mk-sbuild to make its installation  non-fatal.  I'll do that when I pop into the office.
<infinity> slangasek: I think that's the only thing that I can think of that will break a little.
<slangasek> infinity: ok, I'll give you a bug as a reminder
<LocutusOfBorg> infinity, I uploaded the fix
-queuebot:#ubuntu-release- Unapproved: appmenu-gtk-module (bionic-proposed/universe) [0.6.94-0ubuntu1 => 0.6.94-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: hedgewars (bionic-proposed/universe) [0.9.24.1-dfsg-1 => 0.9.24.1-dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted hedgewars [source] (bionic-proposed) [0.9.24.1-dfsg-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: vala-panel-appmenu (bionic-proposed/universe) [0.6.94+repack1-0ubuntu1 => 0.6.94+repack1-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-tweak (bionic-proposed/universe) [18.04.16-0ubuntu1 => 18.04.16-1] (ubuntu-mate) (sync)
<slangasek> infinity: LP: #1766513
<ubot5`> Launchpad bug 1766513 in ubuntu-dev-tools (Ubuntu) "RM: pkg-create-dbgsym: obsolete, debhelper conflicts" [High,Triaged] https://launchpad.net/bugs/1766513
-queuebot:#ubuntu-release- New binary: linux-raspi2 [arm64] (bionic-proposed/universe) [4.15.0-1010.11] (kernel)
-queuebot:#ubuntu-release- Unapproved: mate-window-applets (bionic-proposed/universe) [1.5.1-1 => 1.5.1-2] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-dock-applet (bionic-proposed/universe) [0.85-0ubuntu1 => 0.85-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- New binary: linux-raspi2 [armhf] (bionic-proposed/universe) [4.15.0-1010.11] (kernel)
-queuebot:#ubuntu-release- Unapproved: mate-optimus (bionic-proposed/universe) [18.04.0-0ubuntu1 => 18.04.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: handbrake (bionic-proposed/universe) [1.1.0+ds1-1 => 1.1.0+ds1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted handbrake [source] (bionic-proposed) [1.1.0+ds1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted linux-gcp [source] (bionic-proposed) [4.15.0-1006.6]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-gcp [source] (bionic-proposed) [4.15.0.1006.8]
<doko> update_excuses/update_output isn't updated
<sil2100> britney is still running from what I see in the logs
<sil2100> But should slowly finish
<slangasek> there was a 3h gap.  perhaps there's a bug in britney that causes it not to run if there are no archive updates?
<apw> slangasek, iirc it runs if the archive changes or there is 'Test in progress' in there
<slangasek> right; so the fact that it had published shim-signed+libabigail and the release pocket updated was not a reason for p-m to run again
<slangasek> actually it looks like the archive wasn't updating
<slangasek> shim-signed only published 23m ago
-queuebot:#ubuntu-release- Unapproved: linux-kvm (bionic-proposed/main) [4.15.0-1007.7 => 4.15.0-1008.8] (kernel)
-queuebot:#ubuntu-release- Unapproved: linux-meta-kvm (bionic-proposed/main) [4.15.0.1007.7 => 4.15.0.1008.8] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-raspi2 [arm64] (bionic-proposed) [4.15.0-1010.11]
-queuebot:#ubuntu-release- New: accepted linux-raspi2 [armhf] (bionic-proposed) [4.15.0-1010.11]
<LocutusOfBorg> infinity, do you like hedgewars now?
<infinity> LocutusOfBorg: It's the best thing ever.
<LocutusOfBorg> please give the game a shot :)
<LocutusOfBorg> but not too much, I don't want to be blamed if bionic gets delayed because of people playing too much :)
<sil2100> I'd play it if it was beaverwars
<sil2100> With a bionic addon
<LocutusOfBorg> I should probably ask ubuntu developers to give me their faces, and create an hedgewars ubuntu team with us as "hogs" :)
<ginggs> can src:libthrust be removed? LP: #1766109
<ubot5`> Launchpad bug 1766109 in libthrust (Ubuntu) "Please remove src:libthrust from bionic" [Undecided,New] https://launchpad.net/bugs/1766109
-queuebot:#ubuntu-release- Unapproved: libvirt (bionic-proposed/main) [4.0.0-1ubuntu7 => 4.0.0-1ubuntu8] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: accepted linux-kvm [source] (bionic-proposed) [4.15.0-1008.8]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-kvm [source] (bionic-proposed) [4.15.0.1008.8]
<sil2100> hm, I don't see proposed-migration running again, although I'd expect it to tick because of -kvm accepted
<apw> doesn't it have to publish first?
<apw> those are 'pending' still not published
<sil2100> Yeah, I guess you're right
-queuebot:#ubuntu-release- Unapproved: linux-oem (bionic-proposed/universe) [4.15.0-1002.3 => 4.15.0-1004.5] (kernel)
<tjaalton> apw: ^
<tjaalton> or sil2100
<sil2100> Oh noes, another one
<tjaalton> :P
<sil2100> No -meta?
<tjaalton> soon
<tjaalton> hmm, reject meta :)
<sil2100> apw: I'll take that so you can work on some more good stuff
 * sil2100 doesn't see any -meta in the queue
-queuebot:#ubuntu-release- Unapproved: linux-meta-oem (bionic-proposed/universe) [4.15.0.1002.3 => 4.15.0.1004.2] (kernel)
<tjaalton> I've now uploaded two, drop the older one
<tjaalton> hmm signed will take some time.. and I need to lunch first
<sil2100> Wow, this is actually quite a diff
<tjaalton> which one?
-queuebot:#ubuntu-release- Unapproved: mate-desktop-environment (bionic-proposed/universe) [1.20.0+3ubuntu2 => 1.20.0+4] (ubuntu-mate) (sync)
<sil2100> Just talking to myself about the -oem itself, lots of versions pulled in
<tjaalton> yes, rebase included changes after -17
<cjwatson> slangasek: 3h gap was the daily apt-ftparchive clean precessing its way around the way
<cjwatson> *around the day
-queuebot:#ubuntu-release- New binary: linux-kvm [amd64] (bionic-proposed/main) [4.15.0-1008.8] (kernel)
<sil2100> tjaalton: hm, no -v needed for -oem? Since I see the last version in bionic was 1002.3
<sil2100> tjaalton: and the new linux-oem is 1003.4 and 1004.5, while the .changes file only includes changes from 1004.5
-queuebot:#ubuntu-release- New binary: linux-gcp [amd64] (bionic-proposed/main) [4.15.0-1006.6] (kernel)
<tjaalton> sil2100: maybe, i can add that
<tjaalton> oh
<tjaalton> ah, right
<sil2100> tjaalton: btw. I also see only one -meta in the queue ;p Is that the 'correct' meta package?
<tjaalton> reject both, i'll check again after lunch
<sil2100> tjaalton: ok, thanks o/
-queuebot:#ubuntu-release- Unapproved: rejected linux-meta-oem [source] (bionic-proposed) [4.15.0.1004.2]
-queuebot:#ubuntu-release- Unapproved: rejected linux-oem [source] (bionic-proposed) [4.15.0-1004.5]
-queuebot:#ubuntu-release- Unapproved: linux-aws (bionic-proposed/main) [4.15.0-1006.6 => 4.15.0-1007.7] (kernel, ubuntu-budgie)
-queuebot:#ubuntu-release- Unapproved: linux-meta-aws (bionic-proposed/main) [4.15.0.1006.6 => 4.15.0.1007.7] (kernel, ubuntu-budgie)
<sil2100> Reviewing linux-aws ^
<apw> sil2100, those are in the ubuntu-budgie set ?
<sil2100> hm, interesting, I didn't expect that - wonder how it's in daily-live
<tjaalton> sil2100: actually, since linux-oem hasn't made it to bionic release yet, I'll just add the whole changes since the first release
<sil2100> tjaalton: it didn'
<sil2100> eh, premature enter
<sil2100> tjaalton: it didn't get to release? I see 4.15.0-1002.3 linux-oem in the release pocket
<sil2100> Or am I missing coffee again
<tjaalton> oh
<tjaalton> I thought it was still in proposed
<tjaalton> ah, released yesterday
-queuebot:#ubuntu-release- Unapproved: linux-oem (bionic-proposed/universe) [4.15.0-1002.3 => 4.15.0-1004.5] (kernel)
<sil2100> apw: ok, I'm digging but I fail to see how linux-tools-aws is pulled in, but there's quite some germinate logs to browse - that being said, since we'll be re-spinning anyway and the changes should not affect linux-tools-aws, should be all good
<sil2100> apw: anyway, it looks good to me so I'll accept it if you have nothing against it
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: accepted linux-aws [source] (bionic-proposed) [4.15.0-1007.7]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-aws [source] (bionic-proposed) [4.15.0.1007.7]
<doko> LocutusOfBorg: hedgewars ftbfs on arm64 and ppc64el
<rbalint> Laney: how about i reupload the modemmanager and libqmi packages with the current fix or the desktop team fixes it in the way they please before the release because they currently ftbfs?
<LocutusOfBorg> doko, remove ppc64el binaries should have been done by infinity some hours ago?
<LocutusOfBorg> arm64 is building correctly
<LocutusOfBorg> (update excuses/publisher slowliness)
<LocutusOfBorg> please just kick ppc64el out as I did in debian
<LocutusOfBorg> and please kick source casablanca out too, now it is named cpprest
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/casablanca/+bug/1765630 and  https://launchpad.net/bugs/1765392
<ubot5`> Ubuntu bug 1765630 in casablanca (Ubuntu) "remove casablanca from bionic." [Undecided,New]
<ubot5`> Ubuntu bug 1765392 in hedgewars (Ubuntu) "please remove hedgewars on ppc64el" [Undecided,New]
<cpaelzer> otherwise not worth to mention until reporter clarified, but since it is release weel - has anybody seen things like bug 1765844 ?
<ubot5`> bug 1765844 in openssh (Ubuntu) "openssh private key exposed due to change in permissions" [Undecided,Incomplete] https://launchpad.net/bugs/1765844
<Laney> rbalint: Feel free to leave them if you don't want to turn off -Werror for some reason.
-queuebot:#ubuntu-release- Unapproved: libqmi (bionic-proposed/main) [1.18.0-3 => 1.18.0-3ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-meta (bionic-proposed/universe) [1.224 => 1.225] (ubuntu-mate)
<sil2100> tjaalton: ok, re-checking -oem - remember about the -meta and -signed packages
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-meta [source] (bionic-proposed) [1.225]
-queuebot:#ubuntu-release- Unapproved: linux-meta-oem (bionic-proposed/universe) [4.15.0.1002.3 => 4.15.0.1004.2] (kernel)
<tjaalton> sil2100: yep, meta uploaded, signed needs some work still
-queuebot:#ubuntu-release- Unapproved: ubuntu-dev-tools (bionic-proposed/universe) [0.162 => 0.163] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-dev-tools [source] (bionic-proposed) [0.163]
-queuebot:#ubuntu-release- Unapproved: linux-azure (bionic-proposed/main) [4.15.0-1008.8 => 4.15.0-1009.9] (kernel)
-queuebot:#ubuntu-release- Unapproved: linux-signed-azure (bionic-proposed/main) [4.15.0-1008.8 => 4.15.0-1009.9] (kernel)
-queuebot:#ubuntu-release- Unapproved: linux-meta-azure (bionic-proposed/main) [4.15.0.1008.8 => 4.15.0.1009.9] (kernel)
<sil2100> tjaalton: I'm a noob, but just curious - what's with that =SIGN-ME-TXT= thingies in the control stub?
-queuebot:#ubuntu-release- Unapproved: ubuntu-dev-tools (bionic-proposed/universe) [0.162 => 0.164] (no packageset)
<sil2100> Anyway, let me get back to this after lunch, but it mostly looks fine
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-dev-tools [source] (bionic-proposed) [0.164]
<sil2100> I'll take care of azure as well
<tjaalton> sil2100: copied from debian.master, ask apw :)
<cascardo> sil2100: they come from the master kernel, they are replaced by the rules with either unsigned or signed (or there's no signed anymore)
<apw> sil2100, right that is either the words "signed" or "unsigned" as we only have a linux-image-unsigned on platforms that sign
<cascardo> should be on debian/scripts/control-create
-queuebot:#ubuntu-release- Unapproved: modemmanager (bionic-proposed/main) [1.6.8-2 => 1.6.8-2ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: linux-signed-oem (bionic-proposed/universe) [4.15.0-1002.3 => 4.15.0-1004.5] (kernel)
<sil2100> Funky!
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (bionic-proposed) [4.0.0-1ubuntu8]
-queuebot:#ubuntu-release- Unapproved: accepted appmenu-gtk-module [sync] (bionic-proposed) [0.6.94-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-dock-applet [sync] (bionic-proposed) [0.85-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-tweak [sync] (bionic-proposed) [18.04.16-1]
-queuebot:#ubuntu-release- Unapproved: accepted vala-panel-appmenu [sync] (bionic-proposed) [0.6.94+repack1-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-desktop-environment [sync] (bionic-proposed) [1.20.0+4]
-queuebot:#ubuntu-release- Unapproved: accepted mate-window-applets [sync] (bionic-proposed) [1.5.1-2]
-queuebot:#ubuntu-release- Unapproved: accepted mate-optimus [sync] (bionic-proposed) [18.04.0-1]
<rbalint> Laney: by leave them you mean leave them setting the api levels or leave them ftbfs?
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-oem [source] (bionic-proposed) [4.15.0.1004.2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-oem [source] (bionic-proposed) [4.15.0-1004.5]
-queuebot:#ubuntu-release- Unapproved: zlib (trusty-proposed/main) [1:1.2.8.dfsg-1ubuntu1 => 1:1.2.8.dfsg-1ubuntu1.1] (core)
<doko> Laney: the arm64 autopkg testers don't seem to be happy
-queuebot:#ubuntu-release- Unapproved: libqmi (bionic-proposed/main) [1.18.0-3 => 1.18.0-3ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: modemmanager (bionic-proposed/main) [1.6.8-2 => 1.6.8-2ubuntu1] (kubuntu, ubuntu-desktop)
<Laney> doko: can you please be a bit more verbose?
<rbalint> Laney: in case meant leave it ftbfs then please reject my uploads
<Laney> rbalint: I meant 'leave it alone'
<Laney> but I just fixed it differently. :-)
<Laney> thanks for bringing it to our awareness
<doko> Laney: all tests fail, running against an unknown version
-queuebot:#ubuntu-release- Unapproved: rejected libqmi [source] (bionic-proposed) [1.18.0-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected modemmanager [source] (bionic-proposed) [1.6.8-2ubuntu1]
<Laney> thanks
<Laney> doko: Adam's going to look :D
-queuebot:#ubuntu-release- Unapproved: accepted libqmi [source] (bionic-proposed) [1.18.0-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted modemmanager [source] (bionic-proposed) [1.6.8-2ubuntu1]
-queuebot:#ubuntu-release- New binary: linux [armhf] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
<LocutusOfBorg> http://autopkgtest.ubuntu.com/packages/b/budgie-desktop/bionic/arm64
<LocutusOfBorg> arm64 sadness?
<infinity> LocutusOfBorg: Yes.
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
<apw> ^^ ?
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
<LocutusOfBorg> infinity, I did remove the binary for hedgewars in proposed, but something is preventing it from migration (should it still get kicked from release too?)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
<acheronuk> o_O
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: samba (bionic-proposed/main) [2:4.7.6+dfsg~ubuntu-0ubuntu1 => 2:4.7.6+dfsg~ubuntu-0ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: samba (bionic-proposed/main) [2:4.7.6+dfsg~ubuntu-0ubuntu1 => 2:4.7.6+dfsg~ubuntu-0ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: samba (bionic-proposed/main) [2:4.7.6+dfsg~ubuntu-0ubuntu1 => 2:4.7.6+dfsg~ubuntu-0ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: samba (bionic-proposed/main) [2:4.7.6+dfsg~ubuntu-0ubuntu1 => 2:4.7.6+dfsg~ubuntu-0ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: samba (bionic-proposed/main) [2:4.7.6+dfsg~ubuntu-0ubuntu1 => 2:4.7.6+dfsg~ubuntu-0ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: samba (bionic-proposed/main) [2:4.7.6+dfsg~ubuntu-0ubuntu1 => 2:4.7.6+dfsg~ubuntu-0ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: samba (bionic-proposed/main) [2:4.7.6+dfsg~ubuntu-0ubuntu1 => 2:4.7.6+dfsg~ubuntu-0ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: samba (bionic-proposed/main) [2:4.7.6+dfsg~ubuntu-0ubuntu1 => 2:4.7.6+dfsg~ubuntu-0ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: samba (bionic-proposed/main) [2:4.7.6+dfsg~ubuntu-0ubuntu1 => 2:4.7.6+dfsg~ubuntu-0ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: samba (bionic-proposed/main) [2:4.7.6+dfsg~ubuntu-0ubuntu1 => 2:4.7.6+dfsg~ubuntu-0ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: samba (bionic-proposed/main) [2:4.7.6+dfsg~ubuntu-0ubuntu1 => 2:4.7.6+dfsg~ubuntu-0ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: samba (bionic-proposed/main) [2:4.7.6+dfsg~ubuntu-0ubuntu1 => 2:4.7.6+dfsg~ubuntu-0ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: samba (bionic-proposed/main) [2:4.7.6+dfsg~ubuntu-0ubuntu1 => 2:4.7.6+dfsg~ubuntu-0ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: samba (bionic-proposed/main) [2:4.7.6+dfsg~ubuntu-0ubuntu1 => 2:4.7.6+dfsg~ubuntu-0ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: samba (bionic-proposed/main) [2:4.7.6+dfsg~ubuntu-0ubuntu1 => 2:4.7.6+dfsg~ubuntu-0ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: samba (bionic-proposed/main) [2:4.7.6+dfsg~ubuntu-0ubuntu1 => 2:4.7.6+dfsg~ubuntu-0ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: samba (bionic-proposed/main) [2:4.7.6+dfsg~ubuntu-0ubuntu1 => 2:4.7.6+dfsg~ubuntu-0ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: samba (bionic-proposed/main) [2:4.7.6+dfsg~ubuntu-0ubuntu1 => 2:4.7.6+dfsg~ubuntu-0ubuntu2] (core)
<doko> infinity, slangasek, Laney: ^^^
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: samba (bionic-proposed/main) [2:4.7.6+dfsg~ubuntu-0ubuntu1 => 2:4.7.6+dfsg~ubuntu-0ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: samba (bionic-proposed/main) [2:4.7.6+dfsg~ubuntu-0ubuntu1 => 2:4.7.6+dfsg~ubuntu-0ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: samba (bionic-proposed/main) [2:4.7.6+dfsg~ubuntu-0ubuntu1 => 2:4.7.6+dfsg~ubuntu-0ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: samba (bionic-proposed/main) [2:4.7.6+dfsg~ubuntu-0ubuntu1 => 2:4.7.6+dfsg~ubuntu-0ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: samba (bionic-proposed/main) [2:4.7.6+dfsg~ubuntu-0ubuntu1 => 2:4.7.6+dfsg~ubuntu-0ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: samba (bionic-proposed/main) [2:4.7.6+dfsg~ubuntu-0ubuntu1 => 2:4.7.6+dfsg~ubuntu-0ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-aws [amd64] (bionic-proposed/main) [4.15.0-1007.7] (kernel, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-aws [amd64] (bionic-proposed/main) [4.15.0-1007.7] (kernel, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-aws [amd64] (bionic-proposed/main) [4.15.0-1007.7] (kernel, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-aws [amd64] (bionic-proposed/main) [4.15.0-1007.7] (kernel, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-aws [amd64] (bionic-proposed/main) [4.15.0-1007.7] (kernel, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-aws [amd64] (bionic-proposed/main) [4.15.0-1007.7] (kernel, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-aws [amd64] (bionic-proposed/main) [4.15.0-1007.7] (kernel, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-aws [amd64] (bionic-proposed/main) [4.15.0-1007.7] (kernel, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-aws [amd64] (bionic-proposed/main) [4.15.0-1007.7] (kernel, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-aws [amd64] (bionic-proposed/main) [4.15.0-1007.7] (kernel, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-aws [amd64] (bionic-proposed/main) [4.15.0-1007.7] (kernel, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-aws [amd64] (bionic-proposed/main) [4.15.0-1007.7] (kernel, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-aws [amd64] (bionic-proposed/main) [4.15.0-1007.7] (kernel, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-aws [amd64] (bionic-proposed/main) [4.15.0-1007.7] (kernel, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-aws [amd64] (bionic-proposed/main) [4.15.0-1007.7] (kernel, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-aws [amd64] (bionic-proposed/main) [4.15.0-1007.7] (kernel, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-aws [amd64] (bionic-proposed/main) [4.15.0-1007.7] (kernel, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-aws [amd64] (bionic-proposed/main) [4.15.0-1007.7] (kernel, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-aws [amd64] (bionic-proposed/main) [4.15.0-1007.7] (kernel, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-aws [amd64] (bionic-proposed/main) [4.15.0-1007.7] (kernel, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-aws [amd64] (bionic-proposed/main) [4.15.0-1007.7] (kernel, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-aws [amd64] (bionic-proposed/main) [4.15.0-1007.7] (kernel, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-aws [amd64] (bionic-proposed/main) [4.15.0-1007.7] (kernel, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-aws [amd64] (bionic-proposed/main) [4.15.0-1007.7] (kernel, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-aws [amd64] (bionic-proposed/main) [4.15.0-1007.7] (kernel, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-aws [amd64] (bionic-proposed/main) [4.15.0-1007.7] (kernel, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-aws [amd64] (bionic-proposed/main) [4.15.0-1007.7] (kernel, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-aws [amd64] (bionic-proposed/main) [4.15.0-1007.7] (kernel, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-aws [amd64] (bionic-proposed/main) [4.15.0-1007.7] (kernel, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
<infinity> stgraber: Hey, where does queuebot live and how do we shoot it?
-queuebot:#ubuntu-release- New binary: linux-aws [amd64] (bionic-proposed/main) [4.15.0-1007.7] (kernel, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-aws [amd64] (bionic-proposed/main) [4.15.0-1007.7] (kernel, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
<Kamilion> <queuebot> I'm at soup!
-queuebot:#ubuntu-release- New binary: linux-aws [amd64] (bionic-proposed/main) [4.15.0-1007.7] (kernel, ubuntu-budgie)
<acheronuk> lol
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-20.21] (core, kernel)
 * sil2100 gets back to reviewing the kernels
<cjwatson> ... that didn't work
<cjwatson> stgraber: ^- please get it to rejoin once it's happier with life
<LocutusOfBorg> cjwatson, maybe this is a network issue, but since the quiet I didn't see any queuebot message
<cjwatson> I saw three
<acheronuk> I saw none
 * cjwatson shrugs
<LocutusOfBorg> https://paste.ubuntu.com/p/4ypzzrFwvS/
<cjwatson> don't care
<LocutusOfBorg> me neither
<cjwatson> kicking means rejoining is self-service once stgraber fixes it, so arguably better anyway
<acheronuk> don't disagree with that!
<LocutusOfBorg> yep this is true, thanks for stopping it!
<Kamilion> Well, since we've got a lull then, I guess I'll take a moment to say thank you to everyone.
<bdmurray> sil2100: Could we release update-notifier in artful early?
<sil2100> bdmurray: ah, it's the update notification check not working? It would make sense to get that released before bionic
<bdmurray> sil2100: yeah, that'd be good
<bdmurray> otherwise the people will come with pitchforks
<sil2100> bdmurray: you think it was around for enough or should we wait for tomorrow still? I can't remember how big the change was
<sil2100> But I think I remember it was basically re-adding removed code, right?
<bdmurray> sil2100: yes, it just adds code that was removed some time ago. We could wait for another day, I don't mind either way.
<seb128> can gnome-shell be made to migrate despite the arm64 tests being in a weird state?
<seb128> seems like more an infra issue than a g-s one
<stgraber> lets see if it's happier. it didn't like something it got from Launchpad apparently
<sil2100> bdmurray: I'd give it this one more day just to be sure and publish it tomorrow in the morning, still leaving some time in case things explode
<bdmurray> sil2100: okey dokey
-queuebot:#ubuntu-release- Unapproved: flash-kernel (bionic-proposed/main) [3.90ubuntu1 => 3.90ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: rsyslog (bionic-proposed/main) [8.32.0-1ubuntu3 => 8.32.0-1ubuntu4] (core)
-queuebot:#ubuntu-release- Unapproved: accepted flash-kernel [source] (bionic-proposed) [3.90ubuntu2]
<cjwatson> stgraber: thanks
<cjwatson> seb128: infinity's working on that arm64 failure
<seb128> cjwatson, thx
-queuebot:#ubuntu-release- Unapproved: accepted samba [source] (bionic-proposed) [2:4.7.6+dfsg~ubuntu-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: linux-meta (bionic-proposed/main) [4.15.0.20.21 => 4.15.0.20.22] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-artwork (bionic-proposed/universe) [18.04.10 => 18.04.11] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta [source] (bionic-proposed) [4.15.0.20.22]
-queuebot:#ubuntu-release- Unapproved: ubiquity (bionic-proposed/main) [18.04.10 => 18.04.11] (core)
-queuebot:#ubuntu-release- Unapproved: mate-desktop (bionic-proposed/universe) [1.20.1-1ubuntu2 => 1.20.1-2ubuntu1] (ubuntu-mate, ubuntukylin, xubuntu)
-queuebot:#ubuntu-release- Unapproved: rsyslog (bionic-proposed/main) [8.32.0-1ubuntu3 => 8.32.0-1ubuntu4] (core)
<xnox> jdstrand, this ^ rsyslog has your and mine fix in it.
-queuebot:#ubuntu-release- Unapproved: mate-settings-daemon (bionic-proposed/universe) [1.20.1-2ubuntu1 => 1.20.1-3] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: ubiquity (bionic-proposed/main) [18.04.10 => 18.04.11] (core)
-queuebot:#ubuntu-release- Unapproved: rejected ubiquity [source] (bionic-proposed) [18.04.11]
-queuebot:#ubuntu-release- Unapproved: dcontainers (bionic-proposed/universe) [0.8.0~alpha.5-2 => 0.8.0~alpha.6-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted dcontainers [sync] (bionic-proposed) [0.8.0~alpha.6-1]
-queuebot:#ubuntu-release- Unapproved: rejected rsyslog [source] (bionic-proposed) [8.32.0-1ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted mate-settings-daemon [sync] (bionic-proposed) [1.20.1-3]
-queuebot:#ubuntu-release- Unapproved: accepted rsyslog [source] (bionic-proposed) [8.32.0-1ubuntu4]
-queuebot:#ubuntu-release- Unapproved: linux-meta (bionic-release/main) [4.15.0.20.22 => 4.15.0.19.21] (core, kernel) (sync)
<jdstrand> xnox: ack, thanks for incorporating my changes into your upload
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta [sync] (bionic-release) [4.15.0.19.21]
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (bionic-proposed) [18.04.11]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-artwork [source] (bionic-proposed) [18.04.11]
-queuebot:#ubuntu-release- Unapproved: accepted mate-desktop [source] (bionic-proposed) [1.20.1-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: juju-core (xenial-proposed/main) [2.3.2-0ubuntu0.16.04.1 => 2.3.7-0ubuntu0.16.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: linux-azure [amd64] (bionic-proposed/main) [4.15.0-1009.9] (kernel)
-queuebot:#ubuntu-release- New binary: linux-azure [amd64] (bionic-proposed/main) [4.15.0-1009.9] (kernel)
-queuebot:#ubuntu-release- New binary: linux-azure [amd64] (bionic-proposed/main) [4.15.0-1009.9] (kernel)
-queuebot:#ubuntu-release- Unapproved: base-files (bionic-proposed/main) [10.1ubuntu1 => 10.1ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: linux-azure [amd64] (bionic-proposed/main) [4.15.0-1009.9] (kernel)
-queuebot:#ubuntu-release- New binary: linux-azure [amd64] (bionic-proposed/main) [4.15.0-1009.9] (kernel)
-queuebot:#ubuntu-release- New binary: linux-azure [amd64] (bionic-proposed/main) [4.15.0-1009.9] (kernel)
-queuebot:#ubuntu-release- New binary: linux-azure [amd64] (bionic-proposed/main) [4.15.0-1009.9] (kernel)
-queuebot:#ubuntu-release- New binary: linux-azure [amd64] (bionic-proposed/main) [4.15.0-1009.9] (kernel)
-queuebot:#ubuntu-release- New binary: linux-azure [amd64] (bionic-proposed/main) [4.15.0-1009.9] (kernel)
-queuebot:#ubuntu-release- New binary: linux-azure [amd64] (bionic-proposed/main) [4.15.0-1009.9] (kernel)
-queuebot:#ubuntu-release- New binary: linux-azure [amd64] (bionic-proposed/main) [4.15.0-1009.9] (kernel)
<nacc> stgraber: cjwatson: --^ did it happen again?
-queuebot:#ubuntu-release- New binary: linux-azure [amd64] (bionic-proposed/main) [4.15.0-1009.9] (kernel)
-queuebot:#ubuntu-release- New binary: linux-azure [amd64] (bionic-proposed/main) [4.15.0-1009.9] (kernel)
<nacc> thanks
<cjwatson> stgraber: over to you
<sil2100> stgraber: I can just accept those NEW binaries to make it stop, but maybe you want those in for debugging?
<sil2100> stgraber: or can I just proceed and accept?
<stgraber> crap
<stgraber> wth is going on
<stgraber> No such source package: 'linux-azure_4.15.0-1009.9_amd64.tar.gz'.
<stgraber> that seems reasonable, why does it try that as a source package name
<LocutusOfBorg> please let cmake in from unapproved queue, fixing ceph rebuilds
<LocutusOfBorg> tdaitx, ^^
<stgraber> ah, the "signing" type is the problem, queuebot doesn't know about that yet, it only knows about "uefi"
<cyphermox> hah
<stgraber> cjwatson: is that new? (arch=signing)
<stgraber> anyway, it should now to treat that as if arch=uefi now
<infinity> tjaalton: Is there a reason linux-oem needs to produce udebs?
<cjwatson> stgraber: Not super-new - about two years ago
<cjwatson> stgraber: But maybe things have been using the uefi alias
<cyphermox> uefi yep
<cjwatson> And yeah, treating it like uefi is correct
<cyphermox> maybe signing was used now for the kernel changes to always get the signed copies installed
-queuebot:#ubuntu-release- New: accepted linux-azure [amd64] (bionic-proposed) [4.15.0-1009.9]
-queuebot:#ubuntu-release- New: accepted linux-oem [amd64] (bionic-proposed) [4.15.0-1004.5]
<xnox> slangasek, willcooke - i believe ifupdown should not be in Ubuntu Desktop; and neither should be pppoeconf pulled in; given that NetworkManager can do ppp configs, and ppp is installed.
<slangasek> cyphermox: it was moved to signing as part of turning up support for ppc64el signed kernels
<cyphermox> slangasek: ah
<cyphermox> slangasek: fyi, shim-signed in queue.
<slangasek> cyphermox: ack
 * cyphermox cries
-queuebot:#ubuntu-release- Unapproved: accepted cmake [source] (bionic-proposed) [3.10.2-1ubuntu2]
<slangasek> xnox: too late for us to be cleaning things out of seeds for 18.04
-queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (bionic-proposed) [1.34.8]
<xnox> slangasek, it's on the live system, enables networkigng wait-online, which is wrong....
<willcooke> xnox, NM does ppp vpns, but pppoeconf is used for more than just VPNs.  But not sure it should be installed by default any more, it feels a bit anachronistic. ifupdown, I can't think of anything that needs it, probably a hangover.  Can we drop it next cycle and see, or do you want it gone now?
<slangasek> xnox: more than the live system, I see it's part of the ubuntu-desktop seed
<willcooke> oh, yeah, what slangasek said
<slangasek> willcooke: pppoeconf depends on ifupdown and pulls it in, xnox is suggesting that causes issues for the live image
-queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (bionic-proposed) [10.1ubuntu2]
<slangasek> the basic principle is that you should have everything you need to get online and get further software... pppoeconf is still needed for some cases of "get online" and I don't think we have time to move it into a "present but not installed by default" configuration that won't be terrible
<willcooke> right, yeah, I've first hand experience of needing pppoeconf this week
-queuebot:#ubuntu-release- Unapproved: linux-firmware (artful-proposed/main) [1.169.3 => 1.169.4] (core, kernel)
<slangasek> xnox: is there something else we should be giving ifupdown so that it's not interfering with wait-online?
<xnox> slangasek, we could add a generator, which would check/parse e-n-i and not enable networking.service wanted-by network-online.target.....
<slangasek> xnox: where the parsing should be as simple as grep -rqE '^[[:space:]]*(auto|allow-hotplug)\b' /etc/network/interfaces /etc/network/interfaces.d ?
<slangasek> or possibly only the 'auto'
<mdeslaur> is it too late to get a packagekit security fix in?
<infinity> mdeslaur: No, but almost.
<mdeslaur> infinity: thanks, I'll upload in a minute
<cyphermox> slangasek: willcooke: pppoeconf is used to make the weird DSL-based + VPN setups for some Russian ISP
<cyphermox> most PPPoE actually already works with NM
<willcooke> cyphermox, and VDSL in the UK
<infinity> willcooke: Russia, UK, same same.
<infinity> willcooke: You both hate Europe.
<willcooke> XD
<cyphermox> heh
<cyphermox> slangasek: infinity: incoming livecd-rootfs for some cloud images failing to build
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.524 => 2.525] (desktop-core)
<slangasek> cyphermox: I'm not happy with shim-signed 1.34.8 (which I did not review; someone had accepted it before you even commented about it being in the queue).  We are only supposed to have been triggered if there is a dkms module requiring the key to be added in mok.  Ignoring all errors from --enroll-key means silently ignoring failures to prompt the user for passwords
<slangasek> cyphermox: did you add this as a workaround to recover users that had already gotten wedged because of a failing trigger?
<cyphermox> slangasek: it's for https://launchpadlibrarian.net/367147329/DpkgTerminalLog.txt
<cyphermox> argh
<cyphermox> bug 1766627
<ubot5`> bug 1766627 in shim-signed (Ubuntu) "package shim-signed 1.34.7+13-0ubuntu2 failed to install/upgrade: installed shim-signed package post-installation script subprocess returned error exit status 1" [Undecided,Fix released] https://launchpad.net/bugs/1766627
<xnox> infinity, cyphermox - most fibre-to-home connections.
<slangasek> I know that's the linked bug; I want to understand why ignoring all errors is the right size hammer for something that looks to me should have been fixed on the triggering side
<xnox> but we want it via NM, not via ifupdown. Ubuntu desktop user unlikely to manage ifupdwon ppp by themselves.
<cyphermox> slangasek: seriously, way too many conflicting requirements. I did think of checking if a .key file existed, and did ||: instead, I didn't think of the failure to prompt
<cyphermox> the only thing that /should/ be triggering is dkms, but if you didn't update dkms, and update shim-signed, then you'd potentially run into this issue
<slangasek> cyphermox: do you know why shim-signed was triggered at all in that bug report? dpkg logs show none of the usual suspects (dkms|nvidia|bcmwl|virtualbox)
<slangasek> it was a dist-upgrade, so there was no previous bionic version of dkms present that could have triggered it
<cyphermox> slangasek: there is nothing except dkms that should trigger, and all the calls in shim-signed are SHIM_NOTRIGGER=y
<slangasek> indeed
<slangasek> so I don't think we've understood this bug report
-queuebot:#ubuntu-release- Unapproved: packagekit (bionic-proposed/main) [1.1.9-1ubuntu1 => 1.1.9-1ubuntu2] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.525]
-queuebot:#ubuntu-release- Unapproved: accepted packagekit [source] (bionic-proposed) [1.1.9-1ubuntu2]
<xnox> willcooke, when you say it hang on shutdown..... did you press enter?
<xnox> bah
<xnox> wrong channel
<slangasek> cyphermox: grub-efi-amd64 is triggering shim-signed.
<cyphermox> oh, so it is
<cyphermox> this needs to go
<slangasek> cyphermox: do you remember why this is there?  added Oct 2016, "to make sure users can disable shim validation if necessary"
<slangasek> are we sure it needs to go? and is that the right path for us to fix this properly for release?  a grub rebuild is not as quick to turn around
<cyphermox> IIRC to make sure on upgrade validation was disabled if there were dkms modules installed already
<slangasek> ok, so this is now redundant with the code in shim-signed and dkms?
<cyphermox> slangasek: my immediate fix is to revert that change I did
<slangasek> grub takes time to build and be published.
<slangasek> 2h minimum if we go this route
<cyphermox> yeah, I know
<cyphermox> I'm saying *not grub*
<tjaalton> infinity: I'm not sure, are those used only on server images?
<slangasek> cyphermox: ok, I really don't understand what you're saying.  "revert that change" - which change?
<cyphermox> shim-signed
<cyphermox> which should appear incessantly
<slangasek> reverting that change will reintroduce the bug
<infinity> tjaalton: d-i images, to be exact.  But yes, that's server and netboot.  *I* build neither of those with your kernel.  I have no idea what you do with it.
<slangasek> which is caused by grub triggering when it shouldn't
<cyphermox> slangasek: just look at the shim-signed in queue :)
-queuebot:#ubuntu-release- Unapproved: shim-signed (bionic-proposed/main) [1.34.7 => 1.34.9] (core)
<slangasek> cyphermox: ok - not a revert but an amendment.  Check.
<tjaalton> infinity: there's talk of using bionic oem on a vendor server image..
<cyphermox> sorry, it was after to upload than to amend the communication.
<infinity> tjaalton: Gross.
<cyphermox> *faster
<slangasek> :)
<infinity> tjaalton: Is there talk of us actually supporting it, then?  Should it be in main?
<cyphermox> now I really want shim and all things secureboot to die
<tjaalton> infinity: is it in main in xenial?
<cyphermox> slangasek: to say as someone else said earlier, can we remove dkms completely?
-queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (bionic-proposed) [1.34.9]
<infinity> tjaalton: It's in universe in all releases.
<slangasek> cyphermox: should 1766637 and 1766338 be duped to 1766627, which is the bug you referenced in your changelog?
<cyphermox> possibly, last I checked ..27 was the newest.
<tjaalton> infinity: AIUI it's going to be supported for 5y in bionic
<infinity> tjaalton: By whom?  Is there a formal commitment for this?  A contingency plan if we give up early (ie: make the oem meta point back to generic)?
<tjaalton> that would be one option, or point to the next lts backport
<cyphermox> slangasek: bug mangling done.
<slangasek> cyphermox: thanks
<infinity> tjaalton: Right, whatever oem is based on at the time, I guess.
<slangasek> infinity: are you in the loop on xnox's proposal to make changes to the ubuntu-desktop seed today?
<infinity> tjaalton: If there's a formal commitment to maintain it and move to a kernel team kernel as soon as you decide to stop maintaining it, I'm happy to promote it.
<infinity> slangasek: If by "in the loop", you mean "in agreement", I am not.
<slangasek> infinity: is that why he's assigning the bug to me instead of to you?
<infinity> slangasek: It may well be that he's trying to pull a fast one.
<infinity> xnox: Are you trying to pull a fast one?
<tjaalton> infinity: right, so keep it in universe for now. I think some details are still undecided
<xnox> infinity, slangasek - i believe it is wrong to ship unused ifupdown by default; and it is lack of seeds review prior to the release that led to this situation. It is wrong to install ifupdown by default on all desktops, when it is not to be used.
<xnox> infinity, slangasek - not pulling a fast one, asking for architect review & product owner, prior to uploading things for release team review.
<slangasek> xnox: my point is, don't route around infinity who is the primary gatekeeper of changes at this point in the release cycle
<infinity> tjaalton: "For now"... I mean, release is in under two days, and I'd like the release pocket to represent our intent here.  It doesn't have to, but it would be nice.
<slangasek> xnox: do I agree ifupdown should be dropped: ideally yes
<slangasek> xnox: do I think we can drop it without impacting some users' ability to run Ubuntu: no
<xnox> slangasek, on new installs of bionic?!
<xnox> slangasek, it's not like it's removed from the archive.
<xnox> _desktop_
<tjaalton> infinity: well I don't know, I'm asking others what to do with it
<slangasek> xnox: how do they get it if they're not online because they don't have pppoeconf?
<slangasek> infinity: how's the arm64 un-breaking going?  quick glance tells me that we might have something unhappy with the new kernel packaging vs flash-kernel?
<slangasek> xnox: are you telling me "no one needs pppoeconf anymore", or are you telling me "we don't care about this use case"?
<slangasek> xnox: yes, it sucks to have this in 18.04 GA.  But GA-1.5days is not the time to be making these changes and I think we just have to eat it.
<infinity> slangasek: Should be unstuck.
<slangasek> infinity: ok.  so I should mash test retry buttons, or you already have?
<infinity> slangasek: Still considering a better fix to flash-kernel, but the current adt backlog is resolving.
<infinity> slangasek: Already mashed.
<slangasek> ok
<slangasek> infinity: any reason not to force-skiptest them all, regardless?
<xnox> willcooke, i believe asserting that one needs pppoeconf to get to the internet (meaning the ISP pppoe stuff, not VPN stuff) is configurable via NM.
<slangasek> are we still waiting for other things that will arrive later?
<xnox> willcooke, it is also true if you use ppoeconf, it doesn't mean that you for that to use ifupdown.
<xnox> willcooke, and certainly neither should be enabled & pre-installed in the livefs
<xnox> willcooke, it should be shipped in the pool/ then
<slangasek> xnox: do we ship other things in pool/ besides things that are auto-installed by ubiquity based on hardware detection?
<slangasek> xnox: current desktop pool contents for reference: https://paste.ubuntu.com/p/XCcg9RkRNJ/
<slangasek> xnox, infinity, willcooke: I am convinced it would be consistent with our other usage of the ship-live seed to move pppoeconf to ship-live (the on-ISO package pool) and drop it from ubuntu-desktop.  Whether this is an ok time to make that change, I defer to infinity
<infinity> slangasek: We also have no idea if that will fix the bug being investigated.
<slangasek> infinity: I don't know details on what's being investigated, xnox was thin on details there.  I think it's right on its face that we didn't want ifupdown in the default desktop for 18.04
-queuebot:#ubuntu-release- Unapproved: hedgewars (bionic-proposed/universe) [0.9.24.1-dfsg-1ubuntu1 => 0.9.24.1-dfsg-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: xchat (bionic-proposed/universe) [2.8.8-14 => 2.8.8-15] (no packageset) (sync)
<infinity> slangasek: Sure, I don't disagree with that, except for timing and testing.
-queuebot:#ubuntu-release- Unapproved: accepted hedgewars [sync] (bionic-proposed) [0.9.24.1-dfsg-2]
-queuebot:#ubuntu-release- Unapproved: accepted xchat [sync] (bionic-proposed) [2.8.8-15]
<slangasek> infinity: ok.  that's exactly why I'm deferring to you on it.  it has my +1
<slangasek> infinity: how was the arm64 retry mashing done?  Most of the blocking arm64 autopkgtests do not have new results, nor do they have currently-running tests
<infinity> slangasek: You're just in the window where finished things don't have results yet, I think.
<slangasek> infinity: it's looking like a longer window than is proper
-queuebot:#ubuntu-release- Unapproved: meld (bionic-proposed/universe) [3.18.0-4 => 3.18.0-6] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted meld [sync] (bionic-proposed) [3.18.0-6]
<infinity> slangasek: I've gotten some back.
<slangasek> infinity: e.g. you said "already mashed" 16 minutes ago, some of these tests should take between 6 and 14 minutes (http://autopkgtest.ubuntu.com/packages/c/cockpit/bionic/arm64), so they're at least 2 minutes delinquent.  which ones have you gotten back?
<slangasek> I'm clicking through and just seeing bunches of red
<infinity> slangasek: https://autopkgtest.ubuntu.com/packages/update-notifier/bionic/arm64 for instance.
<infinity> I admit I didn't keep all the windows open.
<Laney> Not sure they were all retried
<Laney> There's no trace of cockpit in the logs since the earlier failure
<slangasek> yeah that's what I'm getting at
<slangasek> :)
<slangasek> so I'll mash some other buttons
<slangasek> done
<slangasek> infinity: anything blocking us at this point which isn't accepted into -proposed?  looks like it'll be another late-in-the-day respin the world?
<infinity> slangasek: I don't think we're waiting on anything, except maybe me fixing flash-kernel a tiny bit harder, but that will migrate instantly if I do.
<infinity> Plus, it's only on one image.
<infinity> Also about ready for a block-all source once the current batch is through.
 * slangasek nods
<LocutusOfBorg> lol infinity so I was already the person who subscribed archive team to remove pkg-create-dbgsym package? I might have been pissed off that day because of some failures due to it being installed on some old systems :)
<LocutusOfBorg> thanks!
<infinity> apw: Can you make a determination on the kernel in proposed and clear the block-proposed tag if you're happy with them (and tell me why not if you're not).  I'm going to grab some food while I wait for the world to do things.
<infinity> sforshee: ^
-queuebot:#ubuntu-release- Unapproved: debian-installer (bionic-proposed/main) [20101020ubuntu540 => 20101020ubuntu541] (core)
-queuebot:#ubuntu-release- Unapproved: accepted juju-core [source] (xenial-proposed) [2.3.7-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [4.15.0-1009.9] (kernel)
<acheronuk> infinity slangasek: I think lubuntu would quite like a lxpanel fix to evict deepin-terminal from any spun image? LP: #1766478
<ubot5`> Launchpad bug 1766478 in lxpanel (Ubuntu) "Deepin terminal is installed in base install unintentionally" [Undecided,Triaged] https://launchpad.net/bugs/1766478
<acheronuk> but tsimonq2 is just about to roll wheels on his driving test!
<slangasek> acheronuk: so are there no other uploaders for this who can take care of it?
<cyphermox> acheronuk: want to make the change I can sponsor?
<tsimonq2> slangasek: (wxl doesn't have upload access, gilir is nowhere to be found, I'm about to go AFK for Important Things, acheronuk doesn't have PPU; yes)
<slangasek> I could upload the fix now fwiw - unless someone's specifically fishing for sponsorship
<cyphermox> I'm not convinced just lxpanel is going to be enough
<cyphermox> germinate seems to say it's apport-gtk who wants deepin-term
<sforshee> infinity: I blew away the blockers for everything but azure, whose signed package is still in the new queue
<sforshee> infinity: also highlight cascardo for bionic stuff, I'm going to be afk for a while here pretty soon
<cascardo> hi there
-queuebot:#ubuntu-release- Unapproved: lxpanel (bionic-proposed/universe) [0.9.3-1ubuntu2 => 0.9.3-1ubuntu3] (lubuntu)
<slangasek> cyphermox: germinate> pointer?
<slangasek> cyphermox: lxpanel should be fixed anyway, but we might also have to juggle seeds
<cyphermox> http://people.canonical.com/~ubuntu-archive/germinate-output/lubuntu.bionic/all
<cyphermox> slangasek: looking harder, maybe lxpanel would be sufficient
<cyphermox> (since this shows up in all, and so far I don't find anywhere else)
<cyphermox> nah, lxterminal is explicitly in core-gtk
-queuebot:#ubuntu-release- Unapproved: accepted lxpanel [source] (bionic-proposed) [0.9.3-1ubuntu3]
<slangasek> cyphermox: deepin-terminal in http://people.canonical.com/~ubuntu-archive/germinate-output/lubuntu.bionic/core
<slangasek> and blames apport-gtk
<cyphermox> yeah, I was just typing that
<cyphermox> also, lubuntu is no-follow-recommends, and lxpanel only recommends x-terminal-emulator
<slangasek> k
<acheronuk> lubuntu said to me they now follow recommends. but I don't know what they changed
<acheronuk> [17:51] <wxl> acheronuk: yes that's the bug. @tsimonq2 that looks like a consequence of allowing recommends :/
<tsimonq2> waaat
<tsimonq2> No we don't.
<cyphermox> the seed git disagrees, if I'm looking at the right place
<tsimonq2> ^
<tsimonq2> (You most likely are.)
<acheronuk> ok. just repeating what was said in lubuntu-devel
<cyphermox> slangasek: apport-gtk should recommends rather than depends on x-terminal-emulator?
<acheronuk> as said, 'I know nothing'
<slangasek> cyphermox: solved differently.  lubuntu.bionic/core updated to explicitly seed lxterminal instead of relying on traversal of lubuntu-core dependencies, since lubuntu-core Depends: apport-gtk, [...] lxterminal and the depth-first dependency resolution traverses the first before it sees the second
<slangasek> although it's possible that won't work
<cyphermox> ack
<cyphermox> slangasek: I was thinking this was more a matter of sorting than traversal order, this makes sense
<slangasek> anyway, going to check now what an update gives me
<slangasek> cyphermox: unfortunately the sorting of dependencies is somewhat enforced nowadays by dpkg-dev
<slangasek> I could create another metapackage, aaaaaaa-no-not-that-one
<slangasek> -lubuntu
<cyphermox> bah
<cyphermox> arguably apport-gtk doesn't need a hard depends on x-terminal-emulator; it only tries to run a terminal if apport-retrace is already installed, and checks if some term exists first
<slangasek> yes; however, fixing this by demoting it to recommends is a short-term fix anyway because lubuntu is meant to follow-recommends eventually
<slangasek> so if we can fix it properly, and without having to send apport through the publisher cycle, I would prefer that
<slangasek> lubuntu-meta (0.95) UNRELEASED; urgency=medium
<slangasek>   * Refreshed dependencies
<slangasek>   * Added lxterminal to core
<slangasek> that looks promising
<cyphermox> wee
<slangasek> @@ -8,6 +8,7 @@
<slangasek>  lxpanel
<slangasek>  lxsession
<slangasek>  lxterminal
<slangasek> +lxterminal
<ubot5-ng> slangasek: Error: "@" is not a valid command.
<slangasek>  openbox
<slangasek>  pcmanfm
<slangasek>  plymouth-theme-lubuntu-logo
<slangasek> that looks less promising
<lyn||orian> adding lxterminal in twice?
<ginggs> tdaitx: LocutusOfBorg asked me to ping you re: LP: #1766649
<ubot5`> Launchpad bug 1766649 in cmake (Ubuntu) "cmake: upstream patch should use 10 instead of 1.10 for java version comparison" [High,In progress] https://launchpad.net/bugs/1766649
<slangasek> ginggs: the fix for which is theoretically currently in -proposed?
<slangasek> ah, I see he's just updated the bug
<sil2100> hm, the kernel still in -proposed I see
<slangasek> "not working properly" means what?
<ginggs> slangasek: I've asked, will relay if I get an answer
<slangasek> cyphermox, acheronuk: lubuntu is clearly getting deepin-terminal because it's alphabetically the first solution for x-terminal-emulator, and apport-gtk is alphabetically the first dependency of lubuntu-core.  It's hard to fix either of these things.  Strangely, ubuntu-desktop gets its preferred terminal as a side effect of xinit Recommends: gnome-terminal | xterm | x-session-manager |
<slangasek> x-window-manager | x-terminal-emulator
<ginggs> slangasek: I still would like to get ocrmypdf in, but don't know what to do - I can't even stop building the s390x binaries, as ocrmypdf is arch:all. According to the Debian maintainer, "Tesseract 4 is known to not work on big endian" debian #849094  So could I make tesseract build on little-endian only, would that help?
<ubot5`> Debian bug 849094 in liblept5 "liblept5: Broken on s390x (+ other big endian archs)" [Normal,Open] http://bugs.debian.org/849094
<slangasek> ginggs: there were previous autopkgtests that passed on s390x.  What were these tests?  Is ocrmypdf so completely broken that being able to gate on the results of those previous tests is useless?
<cyphermox> slangasek: "yay"
<cyphermox> slangasek: so, ok to upload apport-gtk that reduces the Depends to a Recommends?
<slangasek> cyphermox: the solution that will fail again as soon as lubuntu starts to follow recommends?
<slangasek> cyphermox: go for it. autopkgtests only take 7 minutes to run, apport takes 6 minutes to build
<cyphermox> slangasek: lubuntu will only start to follow recommends after 18.04.
<slangasek> yes
<slangasek> but maybe apport should actually Suggests: x-terminal-emulator instead of recommending
<cyphermox> fair
<jbicha> yeah, germinate terminals are a pain https://launchpad.net/ubuntu/+source/xinit/+changelog
<cyphermox> jbicha: not quite the same problem :)
<jbicha> getting xterm out of main took a long time
-queuebot:#ubuntu-release- Unapproved: apport (bionic-proposed/main) [2.20.9-0ubuntu6 => 2.20.9-0ubuntu7] (core)
<slangasek> ginggs: so, is it an option to XFAIL those tests that we know won't pass on s390x, instead of badtesting on s390x and completely bypassing CI for it?
<slangasek> ginggs: if you tell me it's not an option, then a badtest is the sensible fallback
<ginggs> slangasek: i can try XFAILing those tests
<slangasek> cyphermox: we could've also created a dummy package a-terminal-emulator depending on lxterminal ;-)
<ginggs> slangasek: iirc, there was a badtest for it in the past, but then it started working for a while
<slangasek> sil2100: do you know why debian-installer is in the queue?  (vs accepted)
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (bionic-proposed) [2.20.9-0ubuntu7]
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (bionic-proposed) [20101020ubuntu541]
<flocculant> slangasek: shall I expect another respin when I wake up in 8 or so hours?
<slangasek> flocculant: yes
<ginggs> slangasek: re: cmake, LocutusOfBorg thinks ceph in his ppa is still failing, but he will check when he gets home
<flocculant> slangasek: thanks
 * sil2100 looks
<sil2100> slangasek: you accepted it?
<tdaitx> ginggs: LocutusOfBorg: reported the bug upstream and updated ours with the link, I am rebuilding ceph in my own ppa as well, but it takes a couple hours to finish
<tdaitx> if you happen to have the buildlog failure, please add that to the bug so I can take a look
<slangasek> sil2100: I did; I didn't see anything blocking, and am keen to get everything built
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [4.15.0-1009.9]
<sil2100> slangasek: yeah, I guess it's basically needed for linux to migrate
<sil2100> slangasek: at least so it seems from update output from first glance, since right now it's making debian-installer-udebs uninstallable
<slangasek> sil2100: correct.  and the uploader knows that d-i needs to migrate at the same time as linux, so I was asking if you knew anything I missed
<sil2100> No, sadly I had no context of that, I just recently got back from dinner ;)
<slangasek> perhaps he assumed there would be prompt review without him having to say anything
<infinity> slangasek: He might have planned to self-accept and then got distracted by a bratwurst.
<slangasek> infinity: reasonable
<infinity> slangasek: Going to kick back and relax for a couple of hours and then check on the state of the churn and block-all/respin before bed.
<slangasek> (both the self-accept, and the bratwurst)
<slangasek> tdaitx, ginggs: LocutusOfBorg's ppa is not configured to build against -proposed; those build failures are inconclusive
-queuebot:#ubuntu-release- Unapproved: activemq (bionic-proposed/universe) [5.15.3-1 => 5.15.3-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted activemq [sync] (bionic-proposed) [5.15.3-2]
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Bionic Final] has been updated (20101020ubuntu541)
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Bionic Final] has been updated (20101020ubuntu541)
-queuebot:#ubuntu-release- Builds: Netboot armhf [Bionic Final] has been updated (20101020ubuntu541)
-queuebot:#ubuntu-release- Builds: Netboot i386 [Bionic Final] has been updated (20101020ubuntu541)
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Bionic Final] has been updated (20101020ubuntu541)
-queuebot:#ubuntu-release- Builds: Netboot s390x [Bionic Final] has been updated (20101020ubuntu541)
<LocutusOfBorg> slangasek, actually ppc64el should have picked it up
<LocutusOfBorg> tdaitx, https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/14793210
<slangasek> LocutusOfBorg: ah; so you tested with a local cmake in your own ppa?  Is your cmake source identical to what was uploaded to the archive?
<LocutusOfBorg> yes slangasek I did that
<slangasek> k
<LocutusOfBorg> buuuuut javah is not found becauseeeee openjdk is not providing it? lol
<slangasek> correct that openjdk is not providing it
<slangasek> I'm told it's now called javac -h
<tsimonq2> Can anyone repro bug 1766049? I'm getting failed testcases because of it.
<ubot5`> bug 1766049 in Ubuntu Manual Tests "Restart is not working at the end of bionic final installation" [Undecided,New] https://launchpad.net/bugs/1766049
<LocutusOfBorg> so there was no need to upload this cmake version probably
<LocutusOfBorg> I mean, we need the cmake in proposed, but we need also sourceful upload of ceph, dropping javah
<LocutusOfBorg> seems legit now :)
<LocutusOfBorg> please can we keep it in proposed until I sort it out?
<slangasek> why?
<LocutusOfBorg> because I see the run against cmake in release finding java correctly https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/14793207
<slangasek> LocutusOfBorg: so if you're saying it's a no-op, so be it.  That's not a reason to keep it hanging around in -proposed anyway
<LocutusOfBorg> I don't know if this is a no-op or not... better wait for tdaitx
<LocutusOfBorg> I might be more confident with a revert of the upload, and then an eventual SRU later
<slangasek> linux migrating
<LocutusOfBorg> the cmake fix seems sane anyway
-queuebot:#ubuntu-release- Unapproved: ocrmypdf (bionic-proposed/universe) [6.1.2-1 => 6.1.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ocrmypdf [source] (bionic-proposed) [6.1.2-1ubuntu1]
<slangasek> cyphermox: lol the linux-signed packaging split regresses the apport testsuite on amd64.  badtesting
<cascardo> lol
<cyphermox> slangasek: this is hilarious
<slangasek> LP: #1766740
<ubot5`> Launchpad bug 1766740 in apport (Ubuntu) "apport autopkgtest regression due to kernel packaging changes" [Undecided,New] https://launchpad.net/bugs/1766740
<slangasek> tsimonq2, infinity: where do we sit wrt Supported: metadata for Lubuntu-Next?
<tsimonq2> slangasek: I'm uncertain on it, but I can get back to you as soon as I can.
<slangasek> tsimonq2: ok.  hard deadline of early Thursday for that
<tsimonq2> slangasek: ack
-queuebot:#ubuntu-release- Unapproved: ddccontrol (bionic-proposed/universe) [0.4.3-1ubuntu1 => 0.4.3-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ddccontrol [sync] (bionic-proposed) [0.4.3-2]
-queuebot:#ubuntu-release- Unapproved: python-pefile (bionic-proposed/universe) [2017.11.5-1 => 2017.11.5-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-pefile [sync] (bionic-proposed) [2017.11.5-2]
-queuebot:#ubuntu-release- Unapproved: fonts-noto-color-emoji (bionic-proposed/main) [0~20180102-1 => 0~20180424-0ubuntu1] (ubuntu-desktop)
<infinity> tjaalton: linux-signed-oem has a built-dep that can never be satisfied.
<jbicha> ^ the emoji font is just an SRU candidate
#ubuntu-release 2018-04-25
<infinity> britney block in place, waiting for some reports to go empty so I'm sure that my view of the archive is stable.
 * slangasek nods
<Odd_Bloke> I trust that by 20.04, emoji font uploads will be considered release blockers.
<tsimonq2> But why? :P
<tsimonq2> I think lolcat should be a release blocker, but it doesn't seem to be, despite all my efforts. ;)
-queuebot:#ubuntu-release- Unapproved: gr-fosphor (bionic-proposed/universe) [3.7.0.2.7b6b996-2 => 3.7.0.2.7b6b996-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gr-fosphor [sync] (bionic-proposed) [3.7.0.2.7b6b996-3]
<infinity> World respinning, off to bed.
<Ukikie> I thought you'd just go ahead with an Ubuntu version of 'lolcat'
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Bionic Final] has been updated (20180425)
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Bionic Final] has been updated (20180425)
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Bionic Final] has been updated (20180425)
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Bionic Final] has been updated (20180425)
<tsimonq2> Ukikie: I was told "no deltas allowed" :P
<Ukikie> I have skittles-barf you can use instead, tsimonq2.
<Ukikie> Aha, I see.
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Bionic Final] has been updated (20180425)
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Bionic Final] has been updated (20180425)
<tsimonq2> Ukikie: Hah.
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Bionic Final] has been updated (20180425)
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Bionic Final] has been updated (20180425)
<Ukikie> tsimonq2: http://paste.openstack.org/show/1nJeawNVJYw1TlG8R9PR  cat foo | skittles-barf
<tsimonq2> 08:57:02 PM < Odd_Bloke> I trust that by 20.04, emoji font uploads will be considered release blockers.
<tsimonq2> 08:58:02 PM < tsimonq2> But why? :P
<tsimonq2> grrrrrrrrr
 * tsimonq2 highlighted text then middle clicked
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Bionic Final] has been updated (20180425)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Bionic Final] has been updated (20180425)
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Bionic Final] has been updated (20180425)
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Bionic Final] has been updated (20180425)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Bionic Final] has been updated (20180425)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Bionic Final] has been updated (20180425)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Bionic Final] has been updated (20180425)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Bionic Final] has been updated (20180425)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Bionic Final] has been updated (20180425)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Bionic Final] has been updated (20180425)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Bionic Final] has been updated (20180425)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Bionic Final] has been updated (20180425)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Bionic Final] has been updated (20180425)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Bionic Final] has been updated (20180425)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Bionic Final] has been updated (20180425)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Bionic Final] has been updated (20180425)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Bionic Final] has been updated (20180425)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Bionic Final] has been updated (20180425)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Bionic Final] has been updated (20180425)
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Bionic Final] has been updated (20180425)
<tjaalton> infinity: which one?
<tdaitx> LocutusOfBorg: slangasek: I patched ceph to replace that javah call with an additional flag to javac, it has worked locally in an existing chroot from a failed chroot, so I uploaded to a ppa to check if the fix works on a clean environment
<tdaitx> * from a failed build
<slangasek> tdaitx: ok.  let me know when you have something for uploading
<doko> please unblock gcc-6, the gcc-6-cross and gcc-6-cross-ports packages are already in the release pocket
<slangasek> doko: you going to fix that rails sync?
<slangasek> doko: unblocking
<doko> slangasek: I didn't look after infinity's upload
<slangasek> doko: well, it's still broken
<doko> sure, I can have a look
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Bionic Final] has been updated (20180425)
<tjaalton> infinity: ah, linux-libc-dev
<tjaalton> infinity: not sure how to fix that, apw?
<slangasek> tjaalton: you'll need to change the packaging to build-depend on something actually built from linux-oem's source package.  b-d on linux-libc-dev is convenient to use for this for linux-signed, doesn't work for -oem.  what does linux-signed-azure do?
<slangasek> I see e.g. linux-headers-4.15.0-1008-azure
<slangasek> so I guess there's probably some toggle in the generic kernel packaging to support this
<tjaalton> okay, I'll have a look
-queuebot:#ubuntu-release- Unapproved: libplist (bionic-proposed/main) [2.0.0-2 => 2.0.0-2ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rejected libplist [source] (bionic-proposed) [2.0.0-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libplist (bionic-proposed/main) [2.0.0-2 => 2.0.0-2ubuntu1] (kubuntu, ubuntu-desktop)
<slangasek> libplist, a FTBFS to make you hate compilers.  and cpus.  and numbers.
<slangasek> doko: did you have any further thoughts around google-perftools, since your upload seems not to have fixed the ppc64el ftbfs?
<doko> everybody implements this himself instead of using intrinsics ... https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html
<doko> slangasek: no, didn't look yet. it's the configury now failing. it's fixed in unstable, tested in ppa:doko/toolchain. but would need a proper merge, or cherry pick
<slangasek> doko: yes, I ignored the intrinsics because I'm byteswapping an unaligned buffer, so it wasn't obvious to me that memcpy() + __builtin_bswap64() is better than a manual byteswap.  is it?
<doko> I haven't checked ...
<tjaalton> slangasek: I'll port 21456eb0acdcf from -signed-azure..
<tjaalton> to support using the headers pkg
<tjaalton> uh
<tjaalton>  linux-headers-4.15.0-1004-oem (>= 4.15.0-1004.6),
<tjaalton> that's not going to work either
-queuebot:#ubuntu-release- Unapproved: pyxdg (bionic-proposed/main) [0.25-4 => 0.25-4ubuntu1] (core)
<doko> wondering if we should ignore the autopkg test failure for python-redis on i386
<slangasek> doko: vs removing all redis things on i386?
<slangasek> tjaalton: does it work if you use 4.15.0-1004.5+signed1 as your changelog version number instead?
<doko> slangasek: sure, would be an option as well
<doko> but doesn't help with newly synced packages
<doko> filing a Debian issue
<tjaalton> slangasek: oh, yes. I thought that version was bogus :P
<tjaalton> which the script created
<slangasek> :)
-queuebot:#ubuntu-release- Unapproved: linux-signed-oem (bionic-proposed/universe) [4.15.0-1004.5 => 4.15.0-1004.5+signed1] (kernel)
<tjaalton> doko: btw, I fixed tomcat8 to work with jre8.. https://pastebin.com/EnVh7K8v
<doko> libphonenumber built when given back
<slangasek> doko: tdb also
<doko> yeah, can't give all the packages back on armhf and arm64, because the test rebuilds are not yet finished there
<doko> and random nightly/daily builds are considered to be more important
<slangasek> sure.  I tried to reproduce the tdb failure on the porterbox and couldn't
<doko> there's something wrong if you only have 2-5 test rebuilds running at at time
<slangasek> hmm, so there's a patch in BTS for the first db5.3 failure, but then it also complains about java version numbers
<doko> tjaalton: is this an upstream fix? btw, should tomcat8.0 be removed?
<tjaalton> doko: no, I made that. yes tomcat8.0 can be removed, there's a bug open and u-a subscribed
<doko> looking
<tjaalton> had a chat with coty sutherland, I'll ask if this is upstreamable
<tjaalton> or at least part of it
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed-oem [source] (bionic-proposed) [4.15.0-1004.5+signed1]
<doko> tjaalton: resteasy still b-d on it
<tjaalton> bug 1717998
<ubot5`> bug 1717998 in tomcat8.0 (Ubuntu) "Please remove tomcat8.0 before 18.04 releases" [High,Triaged] https://launchpad.net/bugs/1717998
<tjaalton> oh
<tjaalton> resteasy3.0?
<doko> yes, opened a task for that one as well
<doko> no rdeps
<tjaalton> well, that's another one to sort.. there aren't other consumers in the distro for resteasy other than dogtag
<tjaalton> but it can't work with 3.1
<doko> oops, removed too early
<doko> but dogtag doesn't depend on it
<tjaalton> tomcat8.0?
<tjaalton> I think the build-dep can be fixed back to tomcat8
<doko> for resteasy?
<tjaalton> thing is either src:resteasy would need to be reverted to 3.0.19 or resteasy3.0 left in the archive
<tjaalton> there's a bug about that too
<tjaalton> which I can't find
<tjaalton> bug 1682149
<ubot5`> bug 1682149 in dogtag-pki (Ubuntu) "dogtag-pki stops working with resteasy newer than 3.0.19-2" [Undecided,Confirmed] https://launchpad.net/bugs/1682149
<doko> resteasy ftbfs
<tjaalton> with tomcat8
<tjaalton> ?
<tjaalton> linux-signed-oem failed too
<tjaalton> Downloading http://ftpmaster.internal/ubuntu/dists/bionic-proposed/universe/signed/linux-oem-amd64/4.15.0-1004.5/SHA256SUMS ... not found
<slangasek> tjaalton: because it's in main. tralala
<tjaalton> ahaha
<doko> tjaalton: so reasteasy3.0 succeeds to build. so we can live with the resteasy removal
-queuebot:#ubuntu-release- Unapproved: db5.3 (bionic-proposed/main) [5.3.28-13.1 => 5.3.28-13.1ubuntu1] (core)
<tjaalton> doko: you mean tomcat8.0 removal?
<slangasek> tjaalton: probably because it was initially accepted into main and then demoted?  I can hack around this by temporarily promoting linux-headers-4.15.0-1004-oem to main, let you build, and then we can re-demote it if that's where it's supposed to be.  As for fixing the location of the signed files on disk, that may simply involve pepo surgery, but I'll leave that for someone else to figure out
<slangasek> during UK daytime
<slangasek> tjaalton: anyway, linux-headers-4.15.0-1004-oem overridden to main, watch for that to take effect then retry the build
<tjaalton> slangasek: yeah we discussed this with infinity briefly, perhaps main is the right target since it's going to be supported until either -generic or -hwe takes over
<doko> tjaalton: yes
<LocutusOfBorg> slangasek, I got the cmake issue
<LocutusOfBorg> the cmake part is correct, javah is ignored now, so wrt cmake the archive is correct
<LocutusOfBorg> the problem is: ceph still uses manually Java_JAVAH_EXECUTABLE, so this needs to change on ceph side
<LocutusOfBorg> I changed it to "Java_JAVAC_EXECUTABLE -h"  but I presume your "-h" was just to make it show the help :p
<LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/14794722
<LocutusOfBorg> if this one is good, I'll upload mostly as-is
 * LocutusOfBorg afk for some time today
<jibel> Laney, seb128 hi, I get bug 1766811 with latest ubuntu desktop image
<ubot5`> bug 1766811 in ubiquity (Ubuntu Bionic) "ubiquity crashed with dbus.exceptions.DBusException in call_blocking(): org.freedesktop.DBus.Error.UnknownMethod: No such interface '(null)' on object at path /org/gnome/SessionManager" [Critical,New] https://launchpad.net/bugs/1766811
<tjaalton> doko: huh, I could've sworn src:resteasy was at version 3.1..
<seb128> jibel, when did that start? with the ubiquity update?
<jibel> seb128, today with latest build
<seb128> jibel, but you didn't have the issue yesterday when you tried .11 locally built?
<jibel> seb128, I couldn't test that because there was another crash that we reverted just before this point
<seb128> jibel, is the issue in the live session or in ubiquity-dm?
<jibel> seb128, live session, I'm testing the ubiquity-only mode now
<seb128> k, that makes sense, that codepath is not supposed to be used in -dm
<seb128> jibel, do you know what other packages changed between the isos?
<seb128> I don't see anything that could create that pb in the ubiquity diff, but maybe it's just some side effect we didn't think of
<jibel> seb128, http://paste.ubuntu.com/p/FYx3J7NGsZ/
<seb128> thx
<jibel> gnome-shell
<seb128> it's puzzling
<seb128> the code does
<seb128>         if gnome_session:
<seb128>             manager = session.get_object('org.gnome.SessionManager',
<seb128>                                          '/org/gnome/SessionManager')
<seb128>             manager.RequestReboot()
<seb128> so it's using dbus to talk directly to gnome-session
<seb128> which gives
<seb128> No such interface '(null)' on object at path /org/gnome/SessionManager
<jibel> seb128, it only happens from the live session
<seb128> k, makes sense
<seb128> there is no gnome-session in ubiquity-dm
<seb128> so it doesn't try to do that call there
<seb128> I'm syncing the pending iso
-queuebot:#ubuntu-release- Unapproved: google-perftools (bionic-proposed/main) [2.5-2.2ubuntu2 => 2.5-2.2ubuntu3] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: libvirt (artful-proposed/main) [3.6.0-1ubuntu6.5 => 3.6.0-1ubuntu6.6] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: libvirt (xenial-proposed/main) [1.3.1-1ubuntu10.21 => 1.3.1-1ubuntu10.22] (ubuntu-server, virt)
<cjwatson> slangasek: For better or worse, LP currently hardcodes main for the signing custom upload there, so we shouldn't do ftpmaster surgery to move the files around.
-queuebot:#ubuntu-release- Unapproved: ubiquity (bionic-proposed/main) [18.04.11 => 18.04.12] (core)
<acheronuk> respins for that ubiquity ^^^?
<fossfreedom_> really? that's taking "last minute" to the extreme!
<sil2100> Yeah
<sil2100> It's a bit of a serious thing
<acheronuk> fossfreedom_: if it causes restart to fail at the end of installation, then users may assume that installation failed, or do some unsafe method of restart
<acheronuk> + it look bad
<fossfreedom_> hmm ... then sounds like nobody is sleeping tonight to complete the retesting
<Mirv> mostly it just looks bad
<acheronuk> yeah
<Mirv> I'm getting a weak signal that some 16.04 LTS users (one source, claiming plural) would be getting offer to 18.04 LTS upgrade without -d switch or anything, but so far unable to get any direct source (and unable to reproduce). just mentioning if the noise would happen to become louder.
<Mirv> probably just people really messing with -d
<Mirv> it's also impossible to get the message really through that supported upgrading starts around 18.04.1
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (bionic-proposed) [18.04.12]
-queuebot:#ubuntu-release- Unapproved: accepted fonts-noto-color-emoji [source] (bionic-proposed) [0~20180424-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted db5.3 [source] (bionic-proposed) [5.3.28-13.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libplist [source] (bionic-proposed) [2.0.0-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted google-perftools [source] (bionic-proposed) [2.5-2.2ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted pyxdg [source] (bionic-proposed) [0.25-4ubuntu1]
<cjwatson> fossfreedom_: Feel free to find a release when we didn't respin day before release :)
-queuebot:#ubuntu-release- Unapproved: flash-kernel (bionic-proposed/main) [3.90ubuntu2 => 3.90ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: accepted flash-kernel [source] (bionic-proposed) [3.90ubuntu3]
-queuebot:#ubuntu-release- Unapproved: caja (bionic-proposed/universe) [1.20.2-3ubuntu1 => 1.20.2-4ubuntu1] (ubuntu-mate, ubuntukylin, xubuntu)
-queuebot:#ubuntu-release- Unapproved: marco (bionic-proposed/universe) [1.20.1-1 => 1.20.1-2ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: mate-control-center (bionic-proposed/universe) [1.20.2-1 => 1.20.2-2ubuntu1] (ubuntu-mate)
<doko> why do I still see the old ghc 8.0.2-10 package in bionic?
<doko> the source package
<Laney> laney@nightingale> GET http://archive.ubuntu.com/ubuntu/dists/bionic/universe/source/Sources.xz | xzcat | grep-dctrl -S -sPackage,Version -X ghc                                                                                  ~
<Laney> Package: ghc
<Laney> Version: 8.0.2-11
<Laney> no
<doko> apt-cache showsrc shows it
<doko> and:
<doko> $ reverse-depends -b src:llvm-toolchain-3.7
<doko> Reverse-Build-Depends
<doko> =====================
<doko> * ghc                           (for llvm-3.7)
<infinity> doko: reverse-depends is a 3rd party service that's often out of date.
<apw> $ apt-cache showsrc ghc | grep ^Version:
<apw> Version: 8.0.2-11
<apw> not here
<doko> apw: that would prove the existance ...
<infinity> ... of?
 * apw sees -11
<doko> was this in -proposed at some time?
<cjwatson> you sure you don't have artful in sources.list or something?
<doko> hmm, so here we go with llvm-3.7 :-/
<infinity> doko: ... what?
<cjwatson> -11 build-deps on llvm-3.7 too (on arm*)
<doko> we have to keep it
<infinity> doko: -11 indeed build-depends on llvm-3.7.  Not sure why you thought that meant -10 was still around.
<cjwatson> right, so unstable's version b-ds on -3.9, but no time for a Haskell transition now :)
-queuebot:#ubuntu-release- Unapproved: pluma (bionic-proposed/universe) [1.20.1-2ubuntu1 => 1.20.1-3ubuntu1] (ubuntu-mate, ubuntukylin)
<doko> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896864 can we bad-test python-redis for the release?
<ubot5`> Debian bug 896864 in src:python-redis "python-redis autopkg test failures on i386" [Important,Open]
<xnox> apw, infinity - the most relevant bit got copied into the bug description
<xnox> https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1766727
<ubot5`> Ubuntu bug 1766727 in linux (Ubuntu) "initramfs-tools exception during pm.DoInstall with do-release-upgrade from 16.04 to 18.04 " [Undecided,Confirmed]
<xnox> upgrade.log if you want to read it non-wrapped, skip to the end of said file
-queuebot:#ubuntu-release- Unapproved: gcc-snapshot (bionic-proposed/universe) [1:20180322-1ubuntu1 => 1:20180425-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-snapshot [source] (bionic-proposed) [1:20180425-1ubuntu1]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-146.195] (core, kernel)
<xnox> infinity, fyi https://bugs.launchpad.net/ubuntu/+source/netcfg/+bug/1757078
<ubot5`> Ubuntu bug 1757078 in netcfg (Ubuntu) "DNS setting is not reflected in netplan yaml file when domain name isempty string" [Critical,Confirmed]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-146.195]
<xnox> apw, infinity https://paste.ubuntu.com/p/tHqNpPQDhb/
-queuebot:#ubuntu-release- Unapproved: accepted mate-control-center [source] (bionic-proposed) [1.20.2-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted marco [source] (bionic-proposed) [1.20.1-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted pluma [source] (bionic-proposed) [1.20.1-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted caja [source] (bionic-proposed) [1.20.2-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: netcfg (bionic-proposed/main) [1.142ubuntu6 => 1.142ubuntu7] (core)
-queuebot:#ubuntu-release- Unapproved: accepted netcfg [source] (bionic-proposed) [1.142ubuntu7]
-queuebot:#ubuntu-release- Unapproved: pypeg2 (bionic-proposed/universe) [2.15.2-1 => 2.15.2-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pypeg2 [sync] (bionic-proposed) [2.15.2-2]
-queuebot:#ubuntu-release- Unapproved: installation-guide (bionic-proposed/main) [20160121ubuntu3 => 20160121ubuntu4] (core)
-queuebot:#ubuntu-release- Unapproved: adonthell (bionic-proposed/universe) [0.3.6-1build1 => 0.3.7-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted adonthell [sync] (bionic-proposed) [0.3.7-1]
<coreycb> hi release team, bug 1750121 for neutron-dynamic-routing basically causes BGP to become unusable after reboot. very minimal patch and very minimal reverse dependencies involved. can i upload to bionic?
<ubot5`> bug 1750121 in neutron-dynamic-routing (Ubuntu Bionic) "Dynamic routing: adding speaker to agent fails" [High,Triaged] https://launchpad.net/bugs/1750121
-queuebot:#ubuntu-release- Unapproved: eom (bionic-proposed/universe) [1.20.0-1 => 1.20.0-2ubuntu1] (ubuntu-mate, ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: mate-panel (bionic-proposed/universe) [1.20.1-2ubuntu1 => 1.20.1-3ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: accepted installation-guide [source] (bionic-proposed) [20160121ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted eom [source] (bionic-proposed) [1.20.0-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-panel [source] (bionic-proposed) [1.20.1-3ubuntu1]
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1004.5+signed1] (kernel)
<doko> slangasek: c-icap/1:0.4.4-1 autopkg test on amd64 now fails the same way as on s390x (Ignored failure)
<doko> tjaalton, slangasek: linux-signed-oem given back and successfully built
<tjaalton> cool
-queuebot:#ubuntu-release- Unapproved: linux-base (xenial-proposed/main) [4.0ubuntu1 => 4.5ubuntu1~16.04.1] (core)
<jibel> when do you plan to respin an image?
<coreycb> infinity: mind if i upload neutron-dynamic-routing to bionic? re: msg above
<infinity> jibel: Very soon.  Working on one more bug.
<jibel> okay, I'll take a break and come back later in the evening then
<slangasek> cjwatson: no surgery- ack
<slangasek> cjwatson: so the kernel should also not look in universe
<cjwatson> Agreed
<slangasek> infinity, sil2100, apw: do you know who accepted libplist, db5.3, pyxdg?  These are all targeted for SRU but the bugs don't seem to be marked as SRUs
<apw> slangasek, i do not
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1004.5+signed1]
<sil2100> Not me
<slangasek> apw: fyi https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1766916
<ubot5`> Ubuntu bug 1766916 in linux (Ubuntu) "secureboot signing code looks for signed artifacts by component, should always be in main" [Undecided,New]
<apw> slangasek, aware of that, which kernel was exhibiting it?  linux-oem ?
<slangasek> apw: it was, yes
<apw> slangasek, so that one is resolved by its promotion
<slangasek> apw: yes
-queuebot:#ubuntu-release- Unapproved: s390-tools (bionic-proposed/main) [2.3.0-0ubuntu2 => 2.3.0-0ubuntu3] (core)
 * sil2100 should have checked that before approving
-queuebot:#ubuntu-release- Unapproved: s390-tools (bionic-proposed/main) [2.3.0-0ubuntu2 => 2.3.0-0ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: rejected s390-tools [source] (bionic-proposed) [2.3.0-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted s390-tools [source] (bionic-proposed) [2.3.0-0ubuntu3]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [amd64] (xenial-proposed/main) [4.15.0-20.21~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [ppc64el] (xenial-proposed/main) [4.15.0-20.21~16.04.1] (kernel)
-queuebot:#ubuntu-release- Unapproved: linux-base (xenial-proposed/main) [4.0ubuntu1 => 4.5ubuntu1~16.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: linux-base (xenial-proposed/main) [4.0ubuntu1 => 4.5ubuntu1~16.04.1] (core)
<tsimonq2> infinity: Are we calling this next respin a *final* final?
<infinity> tsimonq2: Friggin' better be.
-queuebot:#ubuntu-release- Unapproved: rejected linux-base [source] (xenial-proposed) [4.5ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected linux-base [source] (xenial-proposed) [4.5ubuntu1~16.04.1]
<tsimonq2> infinity: I'm confirming that someone isn't crying wolf here, but there's a super slim chance Kubuntu might need something snuck in. If not in the final, as a 0 day SRU.
 * tsimonq2 isn't particularly pleased about it..
<slangasek> tsimonq2: if 0 day SRU is even an option for whatever it is, then that's your only option
<tsimonq2> slangasek: Alright.
<slangasek> tsimonq2: anything that doesn't scream "this needs to be in the ISO" doesn't need to be in the ISO
 * tsimonq2 continues trying to confirm the severity of the problem.
<tsimonq2> slangasek: You're probably right, but I need to cover my bases here.
<slangasek> tjaalton: linux-oem has all the bits in the archive now and it appears tests are running
<cyphermox> could installation-guide please be unblocked? AFAICT it's in main but only seeded in supported-installer-common, it does not land on any CD
<slangasek> cyphermox: looking
<slangasek> unblocked
<cyphermox> ta
-queuebot:#ubuntu-release- Unapproved: accepted linux-base [source] (xenial-proposed) [4.5ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: linux-meta (bionic-proposed/main) [4.15.0.20.22 => 4.15.0.20.23] (core, kernel)
<tjaalton> slangasek: yeah, I'll pay attention to those
<tjaalton> should actually show more green this time
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta [source] (bionic-proposed) [4.15.0.20.23]
<tsimonq2> slangasek: You are right. src:powerdevil will get an upload to Bionic tonight that I'd argue needs to be a 0 day SRU.
<tsimonq2> I don't have access to my machine with my GPG privkey atm, so unless acheronuk snipes it, we're talking 8ish PM Central.
-queuebot:#ubuntu-release- Unapproved: debian-installer (bionic-proposed/main) [20101020ubuntu541 => 20101020ubuntu542] (core)
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (bionic-proposed) [20101020ubuntu542]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [amd64] (xenial-proposed) [4.15.0-20.21~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [ppc64el] (xenial-proposed) [4.15.0-20.21~16.04.1]
<slangasek> infinity, sil2100, apw, Laney: anyone reviewing unseeded things in -proposed?  Should I be looking at this?
<infinity> slangasek: The bot's still doing unseeded.
<slangasek> infinity: they're not being unblocked into the release pocket
<slangasek> you froze the whole archive, I believe?
<infinity> slangasek: Oh, *in* proposed.  I was doing a mass unblock of stuff from the last 24h, but if you wanted to fish through old things to see if something magically fixed itself, go nuts.
-queuebot:#ubuntu-release- Unapproved: linux-meta-raspi2 (bionic-proposed/universe) [4.15.0.1010.8 => 4.15.0.1010.9] (kernel)
<slangasek> infinity: "were doing" - so you already have this in progress?  since I'm seeing stuff that's blocked and not seeded e.g. adonthell
<infinity> slangasek: Yeah, I'm on it.
<slangasek> infinity: ok.  yeah I wasn't going to fish the old stuff
<slangasek> infinity, Wimpress: and what's the deal with the various mate packages?  I don't see any discussion here about them, they're clearly not on track to be SRUs, and they're not unblocked so they're not looking good for inclusion in an imminent respin
<infinity> slangasek: They're being unblocked.
<slangasek> ok
<slangasek> infinity: eom mate-panel caja marco mate-control-center pluma?  is that a complete list for mate?
-queuebot:#ubuntu-release- Unapproved: build-essential (bionic-proposed/main) [12.4ubuntu1 => 12.5ubuntu1] (core)
<Wimpress> infinity Thanks
<Wimpress> Travelling right now, so appreciate you unblocking the MATE packages
-queuebot:#ubuntu-release- Unapproved: a7xpg (bionic-proposed/universe) [0.11.dfsg1-9.1 => 0.11.dfsg1-10] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ii-esu (bionic-proposed/universe) [1.0a.dfsg1-7build1 => 1.0a.dfsg1-8] (no packageset)
-queuebot:#ubuntu-release- Unapproved: parsec47 (bionic-proposed/universe) [0.2.dfsg1-8 => 0.2.dfsg1-9] (no packageset)
-queuebot:#ubuntu-release- Unapproved: tatan (bionic-proposed/universe) [1.0.dfsg1-7 => 1.0.dfsg1-8] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gunroar (bionic-proposed/universe) [0.15.dfsg1-8build1 => 0.15.dfsg1-9] (no packageset)
-queuebot:#ubuntu-release- Unapproved: projectl (bionic-proposed/universe) [1.001.dfsg1-8build1 => 1.001.dfsg1-9] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mu-cade (bionic-proposed/universe) [0.11.dfsg1-11 => 0.11.dfsg1-12] (no packageset)
-queuebot:#ubuntu-release- Unapproved: titanion (bionic-proposed/universe) [0.3.dfsg1-6build1 => 0.3.dfsg1-7] (no packageset)
<Wimpress> slangasek That list looks correct
<slangasek> doko: build-essential is seeded in the images.  What is this?
<doko> really?
<doko> mehh
-queuebot:#ubuntu-release- Unapproved: accepted a7xpg [source] (bionic-proposed) [0.11.dfsg1-10]
-queuebot:#ubuntu-release- Unapproved: accepted ii-esu [source] (bionic-proposed) [1.0a.dfsg1-8]
-queuebot:#ubuntu-release- Unapproved: accepted parsec47 [source] (bionic-proposed) [0.2.dfsg1-9]
-queuebot:#ubuntu-release- Unapproved: accepted tatan [source] (bionic-proposed) [1.0.dfsg1-8]
-queuebot:#ubuntu-release- Unapproved: accepted gunroar [source] (bionic-proposed) [0.15.dfsg1-9]
-queuebot:#ubuntu-release- Unapproved: accepted projectl [source] (bionic-proposed) [1.001.dfsg1-9]
-queuebot:#ubuntu-release- Unapproved: accepted mu-cade [source] (bionic-proposed) [0.11.dfsg1-12]
-queuebot:#ubuntu-release- Unapproved: accepted titanion [source] (bionic-proposed) [0.3.dfsg1-7]
<doko> I'll do that as a SRU then
<slangasek> why does it need SRUed?
-queuebot:#ubuntu-release- Unapproved: rejected build-essential [source] (bionic-proposed) [12.5ubuntu1]
<doko> missed to build the cross packages for amd64 and i386
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Bionic Final] has been updated (20101020ubuntu542)
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Bionic Final] has been updated (20101020ubuntu542)
-queuebot:#ubuntu-release- Builds: Netboot armhf [Bionic Final] has been updated (20101020ubuntu542)
-queuebot:#ubuntu-release- Builds: Netboot i386 [Bionic Final] has been updated (20101020ubuntu542)
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Bionic Final] has been updated (20101020ubuntu542)
-queuebot:#ubuntu-release- Builds: Netboot s390x [Bionic Final] has been updated (20101020ubuntu542)
-queuebot:#ubuntu-release- Unapproved: linux-meta-raspi2 (bionic-proposed/universe) [4.15.0.1010.8 => 4.15.0.1010.9] (kernel)
-queuebot:#ubuntu-release- Unapproved: rejected linux-meta-raspi2 [source] (bionic-proposed) [4.15.0.1010.9]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-raspi2 [source] (bionic-proposed) [4.15.0.1010.9]
<foka> Hi jbicha and all: Thank you for (automatically?) syncing hugo 0.40-1, though it actually introduced a bug that was fixed in the 0.40.1 release today.  I have just uploaded hugo_0.40.1-1 to Debian, though it will be some hours yet before it got processed by dinstall and got picked up by Launchpad.
<foka> But yes, if hugo 0.40.1-1 arrives before Bionic's release, it would be nice to get it in.  (Hugo's main author got bitten by the "shortcode vs .Content corner cases" bug himself.)  See https://gohugo.io/news/0.40.1-relnotes/
<foka> Thanks again!
<slangasek> infinity: do I understand correctly based on the recent accepts that you're respinning everything?  for those following along, what triggered this?
<infinity> slangasek: We have one last ubiquity fix we're mulling over.  If we decide to land that, I think I'll accept doko's build-essential from rejected and let it pass too.
<infinity> slangasek: Respinning the world is triggered by previous ubiquity anyway.  But testing one final reboot fix.
<bdmurray> slangasek, infinity: I'll be uploading a fix for bug 1764848 shortly.
<ubot5`> bug 1764848 in openssl (Ubuntu Bionic) "Upgrade to ca-certificates to 20180409 causes ca-certificates.crt to be removed if duplicate certs found" [High,In progress] https://launchpad.net/bugs/1764848
<cyphermox> infinity: last ubiquity fix being EFI?
<tjaalton> doko: how about building tomcat with jdk8 for now and fixing the issues with jre8 in sru? This patch is getting bigger and I'd like to send it upstream first
<infinity> cyphermox: Expand on that statement?
<cyphermox> infinity: what is the last ubiquity fix you're mulling over?
-queuebot:#ubuntu-release- Unapproved: lxd (xenial-backports/main) [2.21-0ubuntu3~16.04.1 => 2.21-0ubuntu3~16.04.2] (edubuntu, ubuntu-server)
<infinity> cyphermox: Papering over the longstanding Plymouth reboot issue.
<cyphermox> ok
<infinity> cyphermox: But what did you mean?
<cyphermox> I mean fixing crash at the end of install when you don't have an EFI system partition
<infinity> cyphermox: I'm not familiar with that one.
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (xenial-backports) [2.21-0ubuntu3~16.04.2]
<cyphermox> infinity: anybody working on the plymouth one right now?
<cjwatson> cyphermox: xnox is, if he stops talking about it at some point
<infinity> cyphermox: Yes.
<cyphermox> ok
<bdmurray> lol
<infinity> cyphermox: Your bug.  Does it have a bug?  Does it have a fix?
<cyphermox> filing the bug, fix for now may be to revert a change in partman-efi we did a few weeks ago
<cyphermox> OTOH it won't so much "fix" things as give users an apportunity to go back to partitioning and add what's missing
-queuebot:#ubuntu-release- Unapproved: openssl (bionic-proposed/main) [1.1.0g-2ubuntu3 => 1.1.0g-2ubuntu4] (core)
<infinity> cyphermox: Allowing them to fix things seems better than crashing.  What was the actual intent?  To yell at them?
<infinity> cyphermox: Anyhow, proposed fix ASAP, please.
<cyphermox> the original issue was the message is confusing for everyone, so it was dropped, but it's meant to catch EFI installs being attempted where there is no ESP created
<infinity> cyphermox: So, why did this cause things to crash?
-queuebot:#ubuntu-release- New: accepted golang-1.10-race-detector-runtime [amd64] (artful-backports) [0.0+svn285455-0ubuntu1~17.10.1]
-queuebot:#ubuntu-release- Unapproved: lxd (artful-backports/main) [2.21-0ubuntu3~17.10.1 => 2.21-0ubuntu3~17.10.2] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: casper (bionic-proposed/main) [1.393 => 1.394] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted golang-1.10-race-detector-runtime [amd64] (xenial-backports) [0.0+svn285455-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New: accepted golang-1.9-race-detector-runtime [amd64] (xenial-backports) [0.0+svn285455-0ubuntu1~16.04.1]
<slangasek> cyphermox: nack on reverting partman-efi.
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (artful-backports) [2.21-0ubuntu3~17.10.2]
<slangasek> infinity: ^^
<slangasek> this needs to be fixed properly by enforcing ESP before we proceed with the install
<slangasek> *not* by restoring that terrible dialog
<infinity> Right, that sounds like a code change too large to review and land confidently.
<slangasek> and that we were discussing it today doesn to make it critical for GA
<infinity> Can we just avoid the installer crashing?
<slangasek> no
<slangasek> it crashes in grub-installer
<infinity> Excellent.
<slangasek> "crashes"
<infinity> Well job.
<Laney> ð§
<slangasek> infinity: this is a longstanding existing bug that has resulted in multiple bug reports on shim-signed over multiple cycles.  It's not 18.04.0 critical.
<infinity> slangasek: Check.
<infinity> Then this last trivial fix is the end of (seeded) bionic
<sforshee> slangasek: linux-azure is no longer blocked by our bug
<doko> tjaalton: do we need that for the release, or could that be done in a SRU?
-queuebot:#ubuntu-release- Unapproved: accepted casper [source] (bionic-proposed) [1.394]
-queuebot:#ubuntu-release- New binary: build-essential [amd64] (bionic-proposed/main) [12.5ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted openssl [source] (bionic-proposed) [1.1.0g-2ubuntu4]
-queuebot:#ubuntu-release- New: accepted build-essential [amd64] (bionic-proposed) [12.5ubuntu1]
<slangasek> infinity: are you planning to skip tests for linux-meta so it doesn't take all day?
<infinity> slangasek: Yes.
<Laney> https://salsa.debian.org/debian/ca-certificates/commit/1bc87e0b41a04551a93d4e784e158b044c18792a
<slangasek> infinity: ack
<infinity> bdmurray: Actually, after a talk with Laney, we're going to revert https://salsa.debian.org/debian/ca-certificates/commit/1bc87e0b41a04551a93d4e784e158b044c18792a instead.
<slangasek> infinity: when the dust settles I'd like to understand why that s390-tools upload was needed
<bdmurray> infinity: openssl upstream is making the same change pretty much
<bdmurray> additionally the debian-devel thread leads me to believe other packages might have switched to openssl rehash https://lists.debian.org/debian-devel/2018/04/msg00058.html
<infinity> bdmurray: According to..?
<bdmurray> https://github.com/openssl/openssl/issues/6083
<ubot5-ng`> openssl bug 6083 in openssl "return codes for duplicate certificates differs between c_rehash and openssl rehash" (comments: 0) [Open]
<ubot5`> bug 6083 in Mozilla Firefox "Double-clicking Firefox shortcut in Quick launch gives profile selection" [Undecided,Invalid] https://launchpad.net/bugs/6083
<infinity> bdmurray: Hah, approved 12m ago.  Nice.
<infinity> bdmurray: Alright, pretend this conversation didn't happen. :)
<tjaalton> doko: it's better to have something not breaking in the release, breaks upgrades too
<slangasek> but upgrade issues can always be solved as 0-day SRU, and these packages are not on any images, correct?
<slangasek> infinity: does the fact that the automated tests for the subiquity server image are broken and failing to promote impact the ability to publish for release?
<slangasek> (doesn't stop us from testing and reporting results on iso.qa, just means it won't be 'current')
<infinity> slangasek: Not as long as someone registers some manual tests.
<tjaalton> slangasek: correct, not in any image
<tjaalton> and in universe
<infinity> slangasek: The current links mean exactly diddly to the publishing process.
<slangasek> infinity: ok. andreas is working on fixing the test (it needs to know location of vmlinuz on disk in order to do a non-booting check of sb signatures), but needs someone to be able to land the utah change
<tjaalton> 0-day sru to build against jdk8 would work for me
-queuebot:#ubuntu-release- Unapproved: node-vue-resource (bionic-proposed/universe) [1.3.4-1ubuntu1 => 1.3.4+dfsg-1] (no packageset) (sync)
<slangasek> jibel: ^^ ah, looks like you have utah access, could you look at https://code.launchpad.net/~ahasenack/utah/live-server-kernel-path-1766947/+merge/344342 ?
<infinity> Not in images and in universe is certainly doable right now, too.
-queuebot:#ubuntu-release- Unapproved: accepted node-vue-resource [sync] (bionic-proposed) [1.3.4+dfsg-1]
<slangasek> jibel: the fact that this change will be incorrect for releases < bionic is ignorable since server-live is not in xenial and we won't respin for artful
-queuebot:#ubuntu-release- New binary: node-vue-resource [amd64] (bionic-proposed/universe) [1.3.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted node-vue-resource [amd64] (bionic-proposed) [1.3.4+dfsg-1]
<doko> rbalint: \o/ all the D games back in
-queuebot:#ubuntu-release- Unapproved: modglue (bionic-proposed/universe) [1.19-0ubuntu4 => 1.19-0ubuntu5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted modglue [source] (bionic-proposed) [1.19-0ubuntu5]
-queuebot:#ubuntu-release- Unapproved: gnome-gmail (bionic-proposed/universe) [2.5.4-2 => 2.5.4-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-gmail [sync] (bionic-proposed) [2.5.4-3]
<flocculant> infinity - what we actually respinning for?
<ahasenack> slangasek: plars gave a review. Your comment above about releases < bionic addresses his comment, correct?
<infinity> flocculant: ubiquity, and misc.
<slangasek> ahasenack: yes. commented on MP.
<flocculant> infinity: okey doke - thanks :)
<ahasenack> slangasek: plars thanks! ok, who can merge? plars?
<plars> ahasenack: ah, didn't see the conversation here. Even if it was, I'd rather go back and do a quick cleanup later than block things over something like that, but not even an issue it seems. I already gave my +1
<slangasek> plars: could you land it?  since we cannot
<rbalint> doko: i was wondering how much time should i spend testing them before upload :-)
<plars> ahasenack: I top approved it, not sure if they have an autolander for this, do you know? if not I can just merge by hand
<ahasenack> let me look at some old ones
<ahasenack> I don't see a bot
<ahasenack> bzr log also only shows actual people committing and merging
<plars> ahasenack: pushed
<tsimonq2> infinity: I changed the release notes, but if you plan on doing flavor announcement paragraphs in your announcement, Lubuntu's will be at https://lubuntu.me/bionic-released/
-queuebot:#ubuntu-release- Unapproved: jargoninformatique (bionic-proposed/universe) [1.3.6-0ubuntu6 => 1.3.6-0ubuntu7] (no packageset)
<ahasenack> plars: plars thanks
<infinity> tsimonq2: I do not.
<ahasenack> plars: now I need a build in this ppa I guess: https://launchpad.net/~canonical-platform-qa-jenkins/+archive/ubuntu/canonical-platform-qa-jenkins-prod
<infinity> tsimonq2: It'll look like the xenial release announce: https://lists.ubuntu.com/archives/ubuntu-announce/2016-April/000207.html
<ahasenack> https://launchpad.net/~canonical-platform-qa-jenkins/+archive/ubuntu/canonical-platform-qa-jenkins-staging has it too
<ahasenack> checking recipes
<tsimonq2> infinity: OK. Just thought I'd explicitly mention it, just in case.
-queuebot:#ubuntu-release- Unapproved: accepted jargoninformatique [source] (bionic-proposed) [1.3.6-0ubuntu7]
<ahasenack> https://code.launchpad.net/~canonical-platform-qa-jenkins/+recipe/utah-staging and https://code.launchpad.net/~canonical-platform-qa-jenkins/+recipe/utah-production
<ahasenack> plars: do you have perms to kick either recipe?  ^
<plars> ahasenack: looks like I do. Do you have a preference? which one are you set up to use right now?
<ahasenack> jenkins uses the prod one
<ahasenack> plars: we can of course try staging first
<ahasenack> just checking the current ver, if it's what we had in trunk before
<ahasenack> yeah, ppa has r1123, our merge became r1124
<plars> ahasenack: for a change like that, it doesn't seem bad to go straight to production if that helps you
<ahasenack> it does
<ahasenack> also, staging only builds for xenial for some reason, I wonder if it's even used
<plars> they are both built daily anyway
<plars> I've triggered them both
<ahasenack> plars: after this I'll need a manual jenkins run of the failed job :) https://platform-qa-jenkins.ubuntu.com/view/server/job/ubuntu-bionic-live-server-amd64-iso-static-validation/79/
<ahasenack> after the builds finish, of course
<ahasenack> plars: thx
<ahasenack> indeed, they are daily. We are just anticipating things
<plars> ahasenack: sure, np
<plars> ahasenack: as luck would have it, I even have access to that jenkins
<ahasenack> haha :)
<ahasenack> I logged in, and I can just see
<plars> ahasenack: it built, but that job doesn't seem to update utah... looking around to see if they have something for that already, but do you know per chance?
<ahasenack> plars: the ppas are not done yet
<ahasenack> https://launchpad.net/~canonical-platform-qa-jenkins/+archive/ubuntu/canonical-platform-qa-jenkins-prod/+packages
<ahasenack> plars: the job adds that ppa
<ahasenack> now it's done
<ahasenack> let me check in my container
 * ahasenack apt updates
<ahasenack> yeah, new version visible, at least in bionic. I don't know what release is in that jenkins node
<ahasenack> but all are built
<ahasenack> plars: can you see the actual script that jenkins is running? There is no add-apt-repository or apt-update call?
<plars> ahasenack: I found info for venonat, updating it now
<ahasenack> are you having to login to do it?
<ahasenack> or using jenkins' script execution perhaps?
<plars> ahasenack: we could probably do it through jenkins too, but shortest path
<ahasenack> sure
<plars> and this way I could easily see which ppa it was using too (prod)
<ahasenack> nice
<ahasenack> matches the code I was looking at, good to know
<plars> ahasenack: well it seemed to fail for a different reason now at least?
<ahasenack> checking
<ahasenack> hm, it's looking for that file in another test
<ahasenack> ./utah/isotest/data/file_list_subiquity:casper/vmlinuz.efi
<ahasenack> :/
<plars> yeah
<ahasenack> just a sec
<ahasenack> should have grepped before
<ahasenack> plars: https://code.launchpad.net/~ahasenack/utah/one-more-vmlinuz-rename-1766947/+merge/344346
<slangasek> infinity: is there a draft up for the 18.04 release announcement, so that the product teams can have input on wording?
<infinity> slangasek: Nope, feel free to do that based on a copy/waste of 16.04, if you like and aim me at it.
<slangasek> infinity: https://wiki.ubuntu.com/BionicBeaver/ReleaseAnnouncement
<slangasek> infinity: I didn't see any follow-up on list of UbuntuKylin's statement of 5y LTS?
<infinity> slangasek: Ahh, balls.  I forgot to do that.  They're still 3y in the Packages file and that's, IMO, correct, but I suppose we should have a formal debate with them about it before we close the archive. :/
<slangasek> k
<slangasek> tsimonq2: speaking of which, clock's ticking on lubuntu-next supported fields
<tsimonq2> slangasek: Indeed.
<Kamilion> oh, is that going to be released, or should I grab one of the dailys to continue playing with it?
-queuebot:#ubuntu-release- Unapproved: debian-installer (bionic-proposed/main) [20101020ubuntu542 => 20101020ubuntu543] (core)
<slangasek> Kamilion: it is not going to be released. but currently the archive says the packages are LTS-supported, which is false.
<Kamilion> SYN/ACK.
<rbasak> bdmurray: sil2100: missed my SRU day today. I can do tomorrow instead though, assuming you'll be busy with the release anyway?
<slangasek> infinity: why the d-i respin for openssl vs. putting that in as 0-day SRU?
<infinity> slangasek: To make d-i not be built against things that no longer exist in the archive.
<slangasek> I mean, apparently openssl has already landed, but
<slangasek> AIUI openssl is only an upgrade issue.
<plars> ahasenack: success!
<ahasenack> hoorray
<ahasenack> #82
<plars> ahasenack: I am way late for an appointment, but I'll be back asap. let me know if you need anything else
<ahasenack> now the others are running
<slangasek> infinity: so it's more a question of how we arrived here, and when we're going to be done so that images are actually spinning
<ahasenack> plars: thanks a lot
<plars> happy to help
<sil2100> rbasak: sure, no problem
<slangasek> infinity, sil2100: are we waiting for anything beyond linux-meta 4.15.0.20.23 to be mirrored before respinning non-di images?
<infinity> slangasek: Yes.
<ahasenack> slangasek: great, server-daily iso promoted: http://cdimage.ubuntu.com/daily-live/current/bionic-desktop-amd64.iso
<ahasenack> 25/apr/2018
<slangasek> infinity: yes we are waiting for something beyond?
<apw> we are waiting on the openssl update
<infinity> And casper.
<slangasek> k
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (bionic-proposed) [20101020ubuntu543]
<slangasek> ah, I see
<slangasek> doko: crossbuild-essential-amd64/amd64 unsatisfiable Depends: gcc-x86
<slangasek> infinity: openssl is going to have a long test cycle.  Should we really wait for openssl+debian-installer, or should we divert those to -updates now and draw the line behind casper?
-queuebot:#ubuntu-release- Unapproved: build-essential (bionic-proposed/main) [12.5ubuntu1 => 12.5ubuntu2] (core)
<doko> slangasek: yes, fixed. ^^^
<slangasek> doko: k, reviewing
<doko> and NEW packages demoted to universe
<doko> however I'm not sure how that correct dependency gcc-x86-64-linux-gnu could be fulfilled on amd64. there is no such package on amd64
<doko> maybe the packages have to become arch dependent
<slangasek> doko: accepted, but this is also now late vs. casper which will be ready to go next publisher cycle and I don't think we should hold up the image spins for this
-queuebot:#ubuntu-release- Unapproved: accepted build-essential [source] (bionic-proposed) [12.5ubuntu2]
<slangasek> infinity: ^^
<doko> agreed
-queuebot:#ubuntu-release- Builds: Netboot i386 [Bionic Final] has been updated (20101020ubuntu543)
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Bionic Final] has been updated (20101020ubuntu543)
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Bionic Final] has been updated (20101020ubuntu543)
-queuebot:#ubuntu-release- Builds: Netboot armhf [Bionic Final] has been updated (20101020ubuntu543)
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Bionic Final] has been updated (20101020ubuntu543)
-queuebot:#ubuntu-release- Builds: Netboot s390x [Bionic Final] has been updated (20101020ubuntu543)
<infinity> slangasek: Not waiting on build-essential, openssl I'm going to skiptest after some light spot-checking of early results.  The 1-line change doesn't scare me from the POV of needing full regression coverage.
<slangasek> infinity: ok. I just dropped your d-i hint because I was about to say that d-i and openssl should be either or both and I was prepared to force-copy 20101020ubuntu542 into release pocket instead
<slangasek> infinity: I do think that openssl should've been shunted to SRU but if you have this in hand and it's all unblocking together shortly, so be it
<slangasek> doko: so since build-essential looks late, it's going to need a reupload so that it's a viable SRU anyway
<slangasek> tdaitx: I haven't seen anything further from you wrt ceph, is there a package to be sponsored?  It should be an SRU now rather than in release, since libcephfs2 is on images
<slangasek> nbs/c-m cleared again
<infinity> priority-mismatches cleared.
<tdaitx> slangasek: there is, I have a fix that worked locally, it's building in a ppa (should be done already has I not uploaded the wrong version earlier)
-queuebot:#ubuntu-release- Unapproved: systemtap (bionic-proposed/universe) [3.1-3 => 3.1-3ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted systemtap [source] (bionic-proposed) [3.1-3ubuntu0.1]
<tyhicks> ^ I uploaded that to bionic-proposed with the intent that it lands in bionic-updates
<tyhicks> systemtap in bionic-release is useless right now but I think my upload is fine to process as an SRU
<mwhudson> tyhicks: are you implying systemtab is ever not useless? :)
<infinity> tyhicks: Being unseeded, it can go in before release, if you give it some light testing and let me know if it should be unblocked (once it's built, blah blah)
<tyhicks> mwhudson: I've found it to be useful a handful of times (but it has been a while...) :)
<tyhicks> infinity: ack, will do
<slangasek> tdaitx: do you want to give me a link to the ppa so I can pick it up for you?  is it sponsorship- and sru-ready? (bug filed, linked in changelog)
<tdaitx> slangasek: it's not sru-ready, I will get the request filled after the team metting
<tdaitx> and then post the debdiff with the right link
<slangasek> ok
-queuebot:#ubuntu-release- Unapproved: debian-games (bionic-proposed/universe) [2.2ubuntu1 => 2.2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted debian-games [source] (bionic-proposed) [2.2ubuntu2]
<tyhicks> infinity: systemtap from bionic-proposed is working as intended: https://bugs.launchpad.net/ubuntu/+source/systemtap/+bug/1766754/comments/5
<ubot5`> Ubuntu bug 1766754 in systemtap (Ubuntu) "Linux kernel > 4.14 requires systemtap 3.2" [High,In progress]
<tyhicks> thanks in advance if you have a chance to route it to -release
<slangasek> tyhicks, infinity: unblocking systemtap (unseeded)
<tyhicks> thanks
<sil2100> I'll be unblocking debian-games once it's done as well, if no one minds (will help me in some removals)
<slangasek> infinity, sil2100: it appears everything's through for spinning of non-di images
<Wimpress> slangasek I've just landed in Spain to discover there's an issue with the Ubuntu MATE images.
<slangasek> Wimpress: verbose++?
<Wimpress> Sorry, in a taxi.
<Wimpress> The images are at, or extremely close, to capacity.
<Wimpress> Consequently the settings daemon is crashing due to not being able to write to disk in the live session.
<Wimpress> slangasek would it be possible to make the Ubuntu MATE images allow for more than 2GB please?
<infinity> Wimpress: Those two statements can't possibly relate.
<Wimpress> And respin them
<infinity> Wimpress: ISOs are read-only, the size of the image has nothing to do with writing during the live session.
<slangasek> what infinity says
<infinity> slangasek: Should be good to go for me to trigger all flavours, not just non-di ones, but I figured I could afford to wait another 15m for a clean britney run to verify that state.
<infinity> Actually, I guess d-i is literally the only thing in britney, so rmadison will resolve that one.
<slangasek> yeah, I hadn't seen it on rmadison yet
<infinity> And rmadison loves me.
<infinity> So, beginning the thing.
<acheronuk> I know no-one can say for sure, but I guess we are looking at releasing quite late tomorrow is spins are ok? I only ask due to a query from the guy doing our release video who is on US time.
<sil2100> \o/
<acheronuk> if the answer is *** knows, so be it
<slangasek> acheronuk: it's dependent on how quickly the get tested and marked good by the flavor teams
<slangasek> s/the/they/
<infinity> acheronuk: My plan is still for between 1200 and 1400 London time, assuming test results trickle in in time.  Which they should, if people in the right time zones can get a few shots in.
<acheronuk> infinity: ok. thanks. Kubuntu can factor that in to how we do our announcement then. video might not be ready in time
<infinity> World repsin in progress.
<acheronuk> :)
<acheronuk> fingers crossed!
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Bionic Final] has been updated (20180425.1)
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Bionic Final] has been updated (20180425.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Bionic Final] has been updated (20180425.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Bionic Final] has been updated (20180425.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Bionic Final] has been updated (20180425.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Bionic Final] has been updated (20180425.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Bionic Final] has been updated (20180425.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Bionic Final] has been updated (20180425.1)
<slangasek> tjaalton: linux-oem is still blocked by your blocker bug
<slangasek> tsimonq2: I think I see the bug wrt the support status.  cooking up a fix
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Bionic Final] has been updated (20180425.1)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Bionic Final] has been updated (20180425.1)
<slangasek> tsimonq2: I might be fixing this via your seed inheritance fwiw
<slangasek> ah nope can't do that, 'all' is pseudo
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Bionic Final] has been updated (20180425.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Bionic Final] has been updated (20180425.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Bionic Final] has been updated (20180425.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Bionic Final] has been updated (20180425.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Bionic Final] has been updated (20180425.1)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Bionic Final] has been updated (20180425.1)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Bionic Final] has been updated (20180425.1)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Bionic Final] has been updated (20180425.1)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Bionic Final] has been updated (20180425.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Bionic Final] has been updated (20180425.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Bionic Final] has been updated (20180425.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Bionic Final] has been updated (20180425.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Bionic Final] has been updated (20180425.1)
<slangasek> sforshee: perhaps you're the better person to ping about the status of linux-oem.  should it be unblocked?
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Bionic Final] has been updated (20180425.1)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Bionic Final] has been updated (20180425.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Bionic Final] has been updated (20180425.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Bionic Final] has been updated (20180425.1)
<slangasek> doko: :P crossbuild-essential-amd64/amd64 unsatisfiable Depends: gcc-x86-64-linux-gnu (>= 7.3)
 * sil2100 picks up studio testing
<sil2100> Inbetween my removal-spree
<sil2100> Ok, hotel wifi is super slow
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Bionic Final] has been updated (20180425.1)
-queuebot:#ubuntu-release- Unapproved: hugo (bionic-proposed/universe) [0.40-1 => 0.40.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: rejected hugo [sync] (bionic-proposed) [0.40.1-1]
-queuebot:#ubuntu-release- Unapproved: xdg-desktop-portal-gtk (bionic-proposed/universe) [0.10-1 => 0.11-1] (ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: xdg-desktop-portal (bionic-proposed/universe) [0.10-4 => 0.11-1] (ubuntugnome) (sync)
#ubuntu-release 2018-04-26
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Bionic Final] has been updated (20180425.1)
<tsimonq2> slangasek: Knock yourself out.
<tsimonq2> And did you spot the bug or not? ;)
<sil2100> What bug?
<slangasek> tsimonq2: I mean, I've spotted the bug but I don't have a good fix for it.  The issue is that SUPPORTED_SEEDS = ["all"] which encompasses everything and trumps the NON_LTS_SEEDS
<slangasek> tsimonq2: I think I might try reordering the list and special-casing 'all'
<tsimonq2> slangasek: Thanks.
<tsimonq2> (just got home and I'm packing for my flight tomorrow)
<slangasek> tsimonq2: https://code.launchpad.net/~vorlon/ubuntu-archive-publishing/lubuntu-next-support-fixup/+merge/344358 untested
<sil2100> mwhudson: hey! Can you help with testing the bionic subiquity images?
<mwhudson> sil2100: sure, although in some sense i'm a very bad person to test them
<mwhudson> sil2100: http://iso.qa.ubuntu.com/qatracker/milestones/389/builds/171072/testcases ?
<mwhudson> uh http://iso.qa.ubuntu.com/qatracker/milestones/389/builds/171072/downloads has the wrong link
<sil2100> Oh
<sil2100> Let me try fixing that
<mwhudson> bionic-live-amd64.iso.zsync
<mwhudson> s/live/live-server/ i think
 * sil2100 fixes that
<slangasek> infinity: https://code.launchpad.net/~vorlon/ubuntu-archive-publishing/lubuntu-next-support-fixup/+merge/344358 is an untested stab at the lubuntu support metadata.  I don't see a trivial way to test this
<sil2100> mwhudson: should be fixed
<mwhudson> sil2100: looks better thanks
<sil2100> Ok, I go take a few hours or sleep, but I'll start off earlier to help out with testing
<sil2100> o/
<mwhudson> oh phew the installed system boot was just a bit slow for some reason in this test
<bashfulrobot> Tick tick tick. (Exciting)
<sforshee> slangasek: no it's tjaalton you want for linux-oem
-queuebot:#ubuntu-release- Unapproved: java-atk-wrapper (bionic-proposed/main) [0.33.3-20 => 0.33.3-20ubuntu0.1] (core)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Bionic Final] has been updated (20180426)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Bionic Final] has been updated (20180426)
<jbicha> ^ um, the iso cronjob isn't still on, is it?
<jbicha> slangasek: ping ^ since you might still be around
<slangasek> it was turned off well before; just checked and it's off. someone must have manually requested that rebuild
<slangasek> despite it being a no-op
<slangasek> handsome_feng: ^^ was that you?
<jbicha> yeah, I diffed the manifest's and they were the same
<slangasek> were there test results already reported from the previous build?  I can axe it from the iso tracker
<handsome_feng> slangasek: You mean rebuild the iso?
<slangasek> handsome_feng: yes
<handsome_feng> slangasek: It's zhangchao in our team, we found some thing wrong in the iso, so we rebuild it
<jbicha> handsome_feng: could you be more specific about what you think was wrong?
<slangasek> handsome_feng: ok but you rebuilt it against an archive that has not changed
<jbicha> sorry to change the topic but I'm going to bedâ¦
<handsome_feng> We found that there are some permissions related errors in the x86_64 live system, we thought it maybe someting wrong when build the iso
<slangasek> handsome_feng: what permissions where?  let us help you debug this, please
<jbicha> handsome_feng: I think there are some concerns about Ubuntu Kylin's request to offer 5 years of support for this LTS so please discuss that here too
<jbicha> good night all
<handsome_feng> jbicha: good night
<handsome_feng> slangasek: https://paste.ubuntu.com/p/x9cwtjBGGh/
<slangasek> handsome_feng: when these dconf errors happen, can you please show the uid of the at-spi-bus-launcher process (e.g.: 'ps awxu | grep 3948') and the permissions on /run/user/999/ and /run/user/999/dconf (if it exists)?
<doko> crossbuild-essential-amd64/amd64 unsatisfiable Depends: gcc-x86-64-linux-gnu (>= 7.3)
<slangasek> handsome_feng: also: what is the effect of these permission failures?
<doko> is this only checked on amd64? I mean, this was true before for arm64 and ppc64el on these archs as well
<slangasek> doko: that package only exists on !amd64
<slangasek> so do you intend for the amd64 package to pull in a foreign-arch foo-to-x86 compiler?
<handsome_feng> slangasek: the effect is that the peony, ukui-panel, ukui-menu launch failed
<slangasek> doko: or, it's an arch: all package; do you intend this only to be installed on !amd64?
<doko> no. but as I said, that was already the case with crossbuild-essential-arm64/arm64
<doko> yes, the latter
<slangasek> doko: right - so it's possible the dependencies of arch: all packages are only enforced on amd64 (this is somewhat configurable in britney, I don't remember if that's the current value).  We can consider overriding this
<slangasek> handsome_feng: when did this last work?
<doko> ahh, ok. so maybe no need to make it Arch:any
<handsome_feng> slangasek: the daily 0421
<handsome_feng> we tested it in daily 0421. And it's ok.
<handsome_feng> slangasek: https://paste.ubuntu.com/p/3JNzF5m4V8/
<handsome_feng> slangasek: and this error only happend in x86_64, the i386 works fine in live system.
<slangasek> handsome_feng: ok.  can you also test the 20180425 image to see if it happens there?  that will help us better bisect the delta between the images
<slangasek> 109 packages changed between 20180421 and 20180426 so that will take some time to dig through
<slangasek> handsome_feng: ok, so something has pre-created the /sur/user/999/dconf/user file as root.  not good..
<handsome_feng> slangasek: OK, we will test it ASAP, but it will take some time to download the iso
<slangasek> handsome_feng: yes, understood.  I will keep digging into the changesets in the meantime.  Also, the squashfs from the 20180424 build is still available from launchpad; if 20180425 is broken we should try to download that and manually add it to an ISO for testing
<slangasek> handsome_feng: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/bionic/ubuntukylin/+build/130378
<handsome_feng> slangasek: Thanks
<tjaalton> slangasek: dunno what's the criteria to unblock (never done that before) but the tests that had been run looked green so it's unblocked now
<slangasek> tjaalton: ok, and un-frozen as well now
<tjaalton> great
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Bionic Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Bionic Final] has been marked as ready
<handsome_feng> slangasek: 20180425 has the same problem
<slangasek> ok, at least that tells us which side the problem is on
<slangasek> handsome_feng: how do I reproduce this locally?  with the 'try' or 'install' option?
<handsome_feng> slangasek: with try
<handsome_feng> This only occurs in live system, if we install the system directly, all goes fine.
<slangasek> handsome_feng: ok.  I went to 'try' with 20180426 and I didn't see the problem in /run/user/999/dconf
<slangasek> this is with 20180426 amd64
<handsome_feng> slangasek: OK , we will try that now
<doko> please accept gcc-snapshot
<slangasek> doko: I might leave it there for a little bit if that's ok, so I have something to trigger archive regeneration for the lubuntu cleanup I'm working on
<doko> ok
<handsome_feng> slangasek: we test the 20180426, and it also has the same problem..
<slangasek> handsome_feng: ok.  I am also testing 20180425.1 now to see if I can reproduce the problem here
<slangasek> infinity1, tsimonq2: alright, I've wrapped my head around this code now and have good output now - 62 packages having their support term lowered.  Pushing.
<slangasek> handsome_feng: I cannot reproduce the problem on 20180425.1.  Can you give me any more guidance on steps to reproduce this?
<tsimonq2> slangasek: ack, thabks.
<tsimonq2> *thanks
<sil2100> handsome_feng: did you fill in a bug for it already?
<slangasek> sil2100: good morning
<handsome_feng> slangasek: We've burn the 20180426 iso again. The bug disappears.
<slangasek> hmm
<slangasek> handsome_feng: do you think the previous burn didn't get done correctly?  or do you think that we have a race condition in the boot?
<handsome_feng> Maybe the previous burn was wrong. We will test 20180425.1 again to confirm the problem.
<slangasek> handsome_feng: I would suggest also trying 20180426 several times to be sure the problem is really gone
<handsome_feng> slangasek: OK, We will do it
<sil2100> slangasek: morning o/
<sil2100> phew
<sil2100> slangasek: any blockers reported in the meantime?
<handsome_feng> sil2100:Good morning! and we didn't fill a bug for it, we just found this problem when we test the iso this morning
<slangasek> sil2100: none that I know of
-queuebot:#ubuntu-release- Unapproved: python-pip (bionic-proposed/universe) [9.0.1-2 => 9.0.1-2.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-pip [source] (bionic-proposed) [9.0.1-2.1]
<sil2100> infinity1: ubuntu-studio looks ok for both amd64 and i386
-queuebot:#ubuntu-release- Unapproved: yapf (bionic-proposed/universe) [0.20.1-1 => 0.20.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted yapf [source] (bionic-proposed) [0.20.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: pywinrm (bionic-proposed/universe) [0.0.3-1 => 0.3.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pywinrm [source] (bionic-proposed) [0.3.0-1ubuntu1]
<sil2100> mwhudson: I'll give subiquity a quick spin as well, so that you don't have to feel that your bias affected the test results ;)
<sil2100> slangasek: do you know if it's still ok to process package removals?
<slangasek> sil2100: sure
<slangasek> sil2100: I mean, if you remove the package and somebody disagrees, there will be sadness because there's no time for it to be readded
-queuebot:#ubuntu-release- Unapproved: pyroma (bionic-proposed/universe) [2.0.2-1 => 2.0.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pyroma [source] (bionic-proposed) [2.0.2-1ubuntu1]
-queuebot:#ubuntu-release- New sync: python-requests-ntlm (bionic-proposed/primary) [1.1.0-1]
<sil2100> xnox: the fallback casper message on exit is nice, but I must say I find it sometimes confusing
<sil2100> xnox: maybe 'confusing' being the wrong term, but since I see it everytime before plymouth kicks in, it's confusing as at one time the user is told to just reboot and then suddenly "nope, just press enter to do that"
-queuebot:#ubuntu-release- Unapproved: woo (bionic-proposed/universe) [1.0+dfsg1-2 => 1.0+dfsg1-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted woo [source] (bionic-proposed) [1.0+dfsg1-2ubuntu1]
<Mirv> it seems no-one updated slideshow translations, can someone find out what needs to be fixed/documented where for the process? https://code.launchpad.net/~ubiquity-slideshow/ubiquity-slideshow-ubuntu/html
<Mirv> I've tested Finnish and French, the second (snap) and last slides are untranslated due to string changes during the cycle
<Mirv> (the middle string on the last slide is translated though)
-queuebot:#ubuntu-release- New: accepted python-requests-ntlm [sync] (bionic-proposed) [1.1.0-1]
<Mirv> it's documented here https://wiki.ubuntu.com/NonLanguagePackTranslationDeadline but maybe some process document needs to be updated as well
-queuebot:#ubuntu-release- Unapproved: capstone (bionic-proposed/universe) [3.0.4-3 => 3.0.4-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted capstone [sync] (bionic-proposed) [3.0.4-5]
<fossfreedom> anybody got quick access to an ISO to boot? - clicking quit from ubiquity doesnt launch into the live session - appears to hang (standard bios boot)
-queuebot:#ubuntu-release- New binary: python-ntlm-auth [amd64] (bionic-proposed/none) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-ntlm-auth [amd64] (bionic-proposed) [1.1.0-1]
<Mirv> filed bug #1767048
<ubot5`> bug 1767048 in ubiquity-slideshow-ubuntu (Ubuntu) "Slideshow translations were not updated for 18.04 LTS" [Undecided,New] https://launchpad.net/bugs/1767048
<acheronuk> fossfreedom: xubuntu? or all?
<jibel> fossfreedom, where do you press "quit" and which flavour?
<Mirv> fossfreedom: correct, clicking Quit from the keyboard selection menu does not seem to do anything
<Mirv> (Ubuntu main flavor for me)
<Mirv> it just hangs and becomes unresponsive
<sil2100> Mirv: hm, so we had an upload of the slideshow before release, but it didn't seem to include new translations
<sil2100> I guess that's what hid the issue
<Mirv> sil2100: right, it may have confused someone following the process that "oh, that was uploaded"
<sil2100> That might have been my responsibility, ouch
<fossfreedom> acheronuk, I'm on Ubuntu Budgie - thanks for the confirmation Mirv
<Mirv> sil2100: well it's not the first time, and can be fixed for .1, but it's good to get the process bullet proof for updating the nonlangpack translations for release
<acheronuk> I dunno if KDE front end even has that option there. certainly never noticed
<sil2100> Ok, switching to the office for a short while
<sil2100> brb
<doko> are python3-networkx or python-networkx on any image?
<fossfreedom> Thoughts on this - three times this morning I've tried to boot into a live session on UB and I'm getting this https://imgur.com/a/NwCJRt6
<jibel> that's the same error handsome_feng mentioned earlier
 * fossfreedom scrolling back
-queuebot:#ubuntu-release- Unapproved: python-networkx (bionic-proposed/main) [1.11-1ubuntu1 => 1.11-1ubuntu2] (ubuntu-server)
<jibel> fossfreedom, https://paste.ubuntu.com/p/x9cwtjBGGh/
<fossfreedom> yep -same issue
<jibel> Laney, ^^ any thoughts? same error on 2 different flavours
<jibel> fossfreedom, which build of which flavour ?
<fossfreedom> 64bit Ubuntu Budgie
<doko> Laney: s390x autopkg testers unhappy (unknown versions everywhere)
<jibel> fossfreedom, what is the build number?
<jibel> 201804??
<sil2100> jibel, fossfreedom: which bug is this about?
<jibel> sil2100, "unable to create file '/run/user/999/dconf/user': Permission denied.  dconf will not work properly" when at-spi-dbus-bus is activated
<jibel> I don't think any bug has been filed
<jibel> I didn't see any in the backscroll
<doko> is it already possible to upload to -proposed?
<infinity1> Was it ever not?
<doko> can't remember
<sil2100> jibel: what are the steps to reproduce that?
<sil2100> I guess I'm missing some backscroll
<apw> doko, we always upload to -proposed all cycle, via the redirect for 'bionic' to -proposed
<doko> apw: well, my question is, if I already can queue up -proposed uploads
<apw> doko, as long as things are prepped as SRUs i believe they are fine to upload
<apw> doko, though i would not think we want anything major in there in case we have to rebuild anything
<doko> ok
<apw> infinity, ^ that make sense ?
<jibel> sil2100, I don't know. I didn't reproduce it myself but 2 testers on 2 different flavours reported it?.
<jibel> -?
<jibel> fossfreedom, can you report a bug please and attach the journal?
<jibel> also describe the steps to reproduce  the problem if you can do it reliably
<acheronuk> if this the no free space thing again, or something else?
<handsome_feng> slangasek: I found this problem also occurs in Ubuntu, see https://paste.ubuntu.com/p/sZykyz5BVg/
<jibel> handsome_feng, how do you reproduce it?
<jibel> can you reproduce it in a VM or only hardware?
<handsome_feng> jibel: Just burner the iso and then go into live system
<handsome_feng> jibel: I found that is only occurred in Dell computer.
<handsome_feng> And in the vm, all works fine
<jibel> yeah but fossfreedom did it in vbox apparently
<sil2100> hmmmmm
<handsome_feng> jibel: emmm, It's wired..
<jibel> handsome_feng, can you report a bug in LP please?
<jibel> it'll be easier to track the status than on IRC
<handsome_feng> jibel, OK, I will do it now
<jibel> thanks
<acheronuk> In latest ubuntu iso in virtualbox, I click 'try' and punts me to gdm login screen instead of straight into live session? is the intended?
<jibel> no it means that the shell failed to start
<jibel> you'll find more info in the journal
<handsome_feng> jibel: LP: #1767067
<ubot5`> Launchpad bug 1767067 in Ubuntu "[Live]Wrong Permission in live mode." [Undecided,New] https://launchpad.net/bugs/1767067
<acheronuk> and if I click live session user, the 1st time seems to crash and push me back to gdm. 2nd try logs me in to live user
<handsome_feng> And feel free to edit it
<acheronuk> jibel: https://i.imgur.com/Hx7YJGI.png
<jibel> acheronuk, yeah same bug than handsome_feng
<fossfreedom_> sil2100: sorry - dropped out of IRC - on mobile at the moment - this bug is about trying to launch into a live session.  When I tried earlier it was failing 50% of the time.  Basically left at the login screen.  Cannot launch into the session
<fossfreedom_> It is intermittent. sometimes the live session launches - sometimes it doesn't.  Nothing obvious as to why
<jibel> okay, I reproduced it
<fossfreedom_> Never seen this before until last nights respin
<willcooke> I saw it during the day yesterday
<willcooke> (but thought it was just me)
<jibel> handsome_feng, when did you first see this problem? with which build?
<jibel> willcooke, did you ever see it before?
<willcooke> jibel, Not sure if we're talking about the same thing.  I saw the live image booting to a login screen instead of a logged in session during the day yesterday, and I /think/ Tuesday evening
<handsome_feng> jibel: We test 20180421, and it works fine
<seb128> handsome_feng, did you get any imagine in between those days? like on monday 23 or 24?
<jibel> willcooke, that would be the symptom but without the log it cannot be confirmed.
 * willcooke checks his trash
<handsome_feng> seb128: no...I just got the 20180425
<handsome_feng> I found if I manually select "try but not install" , all goes fine!
<seb128> handsome_feng, jibel, in what mode is the issue happening exactly?
<sil2100> jibel: were you able to reproduce it finally? Is this random?
<handsome_feng> live mode
<seb128> handsome_feng, but you just said that if you select "try" it goes fine?
<handsome_feng> I can reproduce, If  I manually select "try but not install" , all goes fine, and if I wait until the windows shows, the problem occurs
<seb128> isn't try = live session?
<jibel> seb128, just boot, then in ubiquity-dm select 'try ubuntu'
<seb128> jibel, it happens only through that codepath? picking the live session from syslinux works?
<jibel> seb128, yes
<seb128> jibel, what flavor(s) are we talking about?
<jibel> seb128, ubuntu, budgie and kylin
<seb128> oh, ubuntu as well?
<jibel> yes
<handsome_feng> wait until the windows show and then chose try
<seb128> *fun*
<seb128> jibel, do you know on what iso it started?
<seb128> we had ubuntu isos in between monday and today
<jibel> no, I've 24 here, I'll try it
<seb128> thx
<seb128> that sucks, looks like a release blocker issue?
<LocutusOfBorg> question: can I sru virtualbox or sync it? I guess the former, right?
<acheronuk> FFS I just tried again to video capture what it does, and it didn't happen
<seb128> Laney, are you guys in London poking at it?
<jibel> seb128, and you see the bug only on BIOS machine because on UEFI you don't start ubiqutiy-dm
<handsome_feng> 1. when start, hit the arrow keys, choose "try Ubuntu but not install" -> works fine.   2. Wait until the windows show and then choose the "try ubuntu" -> failed.
<sil2100> jibel, handsome_feng: I was testing kylin i386 on my VM and it worked correctly
<sil2100> jibel, handsome_feng: just now re-tested with clicking 'try ubuntu' and everything works
<handsome_feng> sil2100: Yeah, I also test it in vm, and works fine
<jibel> I have the bug in a VM and fossfreedom too
<acheronuk> urgh. randomly hard to reproduce! fun
<seb128> jibel, I'm testing
<sil2100> jibel: are you able to reproduce it on a VM? Or you're on the real hardware?
<jibel> sounds racy
<jibel> sil2100, yes in qemu
<jibel> other in vbox
<sil2100> Or maybe it's because I'm testing the i386 image
<jibel> the platform is unrelated
<jibel> the flavour too
<seb128> I just tried on an amd64 iso, didn't get the issue
<sil2100> I wonder when this started
<seb128> if I had to guess I would say this week when we started fixing ubiquity use of gsettings, that uncovered issue with code that never worked properly
<Laney> seb128: a bit, but please do too
<seb128> Laney, do you have any clue so far? I didn't manage to reproduce yet :/
<Laney> no didn't make it happen
<seb128> I guess something in ubiquity-dm triggers a gsettings write with the worng user/env
<seb128> but I've not idea what
-queuebot:#ubuntu-release- Unapproved: python-redis (bionic-proposed/main) [2.10.6-2 => 2.10.6-2ubuntu1] (ubuntu-server)
<willcooke> Just to update the channel.... I consider this a release blocker.  Release team in London are trying to reproduce it right now
<willcooke> I've let JamieBennett know that this is a problem
<seb128> willcooke, thx for the update, difficult to follow for those who are not in London
<willcooke> I'll relay messages
<seb128> thx
 * didrocks doesn't succeed in reproducing :/
<didrocks> and looking at the code, I don't see anymore obvious guilty path
 * seb128 neither
<jibel> seb128, no failure with 24 and 50% of the boot are failing with 25.1
<didrocks> yeah, that was the day we fixed the a11yâ¦ correct?
<seb128> jibel, can you boot to -maybe, go to a tty and look at the permission of the /run ... file which is listed in the error?
<jibel> willcooke, to reproduce just boot 25.1 in qemu and select "try ubuntu", retry until it fails
<seb128> didrocks, that's the day we fixed the session reboot
<seb128> jibel, are we talking about the "login fails, you get gdm" or about the dconf errors?
<jibel> willcooke, I kept a VM running with the problem if they need more data in london
<willcooke> just reconfigured my test laptop in to legacy mode, L_aney is writing a USB stick
<willcooke> #livetweet
<jibel> willcooke, you can relay the message ;)
<didrocks> seb128: hum, are you sure? we fixed the a11y issue on the 24, so 25.1 contains the a11y fix, not the one from 24
<willcooke> jibel, shall we get you on a HO?
<seb128> willcooke, great that you are here, at least we have some update of what is going on in London
<seb128> otherwise it feels like complet disconnect
<doko> infinity, Laney: are you aware of https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/s390x/b/backblaze-b2/20180426_070912_e76c3@/log.gz ?
<JamieBennett> willcooke: a HO seems sensible
<jibel> sure, give me a minute
<seb128> which is a bit sad
<Laney> doko: yes
<Laney> seb128: :/
<Laney> we're trying to reproduce it
<Laney> but please try as well
<seb128> Laney, sorry, feels like we have pretty much being blocked or informed with hours delays of anything happening since tuesday, it's a bit the suck :/
<seb128> yeah, i'm trying
<seb128> but I'm a bit confused now
<Laney> what delays?
<doko> Laney: looks like a quoting error?
<Laney> doko: no, the apt update failed
<seb128> are we investigating the dconf permission errors?
<doko> ahh
<Laney> yes
<seb128> or the "get login screen"
<Laney> what has the release sprint delayed in that though?
<seb128> Laney, if you guys were not at the same place there would be IRC discussions about the issues being considered/worked on and others would be in the loop of what's going on/what are the issues/what is the status
<Laney> this is a bug that was raised on IRC?
<seb128> yes
<seb128> 1h30 ago
<Laney> that's the first we knew
<jibel> seb128, I think the "get loing screen" is the same problem
<seb128> anyway that's not an important discussion to have now
<seb128> jibel, I don't understand, does it happen in live or not?
<jibel> seb128, yes in a live session
<jibel> 4213 [  306.097343] ubuntu gnome-session-binary[4872]: dconf-CRITICAL: unable to create file '/run/user/999/dconf/user': Permission denied.  dconf will not work properly.
<seb128> jibel, do you have the buggy session atm?
<jibel> seb128, you boot to a live session, and get a login screen
<jibel> tes
<jibel> yes
<seb128> do you need to go through ubiquity-maybe?
<seb128> or does it happen also in direct live from syslinux?
<willcooke> HO: https://hangouts.google.com/hangouts/_/canonical.com/will?authuser=0
<jibel> seb128, yes, I didn't reproduce it when booting straight to the live sesion from syslinux
<seb128> k, good
<seb128> jibel, can you "ps axu | grep dconf" on the buggy system?
<willcooke> jibel, link ^
<willcooke> for HO
<willcooke> cc seb128, didrocks
<jibel> yup 1s, the sound indicator disappeared
<didrocks> joining once my other vm trial booted
<didrocks> (don't want to artifically slowing it down and see what happens)
<LocutusOfBorg> distro_info.DistroDataOutdated: Distribution data outdated. Please check for an update for distro-info-data. See /usr/share/doc/distro-info-data/README.Debian for details.
<LocutusOfBorg> sigh
<LocutusOfBorg> backprotpackage broken
<seb128> willcooke, same as didrocks, my laptop is already struggling with vms boots etc atm, might join in a bit
<philroche> Canonical CPC team checking in. I am CPC vanguard so if you know of any packages server/cloud related that will possibly cause a respin please ping. We're currently getting dailies uploaded to public clouds but will hold off on promotion until we get the OK from you guys.
<seb128> jibel, did you see my question about the ps?
 * didrocks does another testboot closing thunderbird this timeâ¦
<seb128> I'm not getting the issue in virtualbox
<didrocks> I'm using kvm/qemu through gnome-boxes
<didrocks> as it's clearly a race depending on who writes first, hard to reproduce :/
<jibel> Laney, https://bugs.launchpad.net/ubuntukylin/+bug/1767067
<ubot5`> Ubuntu bug 1767067 in ubiquity (Ubuntu) "Booting to live session fails with: at-spi-bus-launcher: unable to create file '/run/user/999/dconf/user': Permission denied." [Critical,New]
<seb128> sounds like we lost jibel, probably under pings from r-t and others
<seb128> willcooke, jibel, I can't reproduce and can't help if IRC get ignored so I'm stepping out of that for a bit and going to look at launchpad recent reports & co, let me know if I can help/if someone wants to look at what I asked a bit earlier
<Laney> :/
<Laney> we're just trying hard to debug it, it's not a deliberate ignoring of you
<seb128> I was trying to help
<jibel> seb128, sorry, I missed your messsage
<willcooke> seb128, join the HO
<seb128> Laney, it's fine, it's just that it seems impossible from people not with you to get enough interaction bandwith to be useful, which is fair enough
<jibel> seb128, gdm       5318  0.0  0.2 280736  5736 tty1     Sl   08:37   0:00 /usr/lib/ibus/ibus-dconf
<jibel> ubuntu    5685  0.0  0.0  21536  1068 tty3     S+   09:45   0:00 grep --color=auto dconf
<ubot5`> Ubuntu bug 5685 in searchandrescue (Ubuntu) "searchandrescue: merge new debian version" [Medium,Fix released] https://launchpad.net/bugs/5685
<seb128> willcooke, I can't, my machine is already swapping from the vm and GNOME session eating 1.5G ram
<seb128> jibel, you don't have dconf-service process(es)?
<seb128> weird :/
<jibel> no
<didrocks> same here, it's either vm or HO :/
<JamieBennett> seb128: how about joining the HO via phone?
<willcooke> update for IRC:  xnox thinks he can see the race
<seb128> JamieBennett, I guess I can try, I just don't have my canonical account on my phone
<seb128> willcooke, ah, nice
<willcooke> atspi starting before dconf
<willcooke> and sometimes it doesnt
<didrocks> which basically matches the first report on atspi
<didrocks> I guess needing its env vars to see what's up
<seb128> who is owner the dconf/user file?
<seb128> it doesn't make sense to me
<seb128> at-spi-bus-laun[4081]: unable to create file '/run/user/999/dconf/user': Permission denied. dconf will not work properly.
<seb128> suggests that's it's not at-spi starting before dconf
<jibel> seb128, it doesn't exist
<willcooke> we think it;s that the file doesn't exist, rather than perms
<seb128> while permission denied then?
<didrocks> we had the same issue in ubiquity
<seb128> no
<didrocks> it was printing "Permission denied"
<seb128> ubiquity had the file owned by root
<didrocks> remember the second one
<seb128> because a dconf-server was spawned by root
<jibel> and 999 is owned by ubutnu
<didrocks> the one while you left for lunch :)
<didrocks> yeah, that was the first issue
<didrocks> the second was missing XDG_RUNTIME_DIR
<seb128> with XDG env was uncorrect
<seb128> right, be the result was a file root owned there
<didrocks> which was printing '/run/user/999/dconf/user': Permission denied
<didrocks> there was no file
<willcooke> HO closed for now
<willcooke> xnox has a plan
<seb128> good
<didrocks> just in case the issue is the same the second fix we got the other day: check XDG_RUNTIME_DIR in that process and if setting it works
<didrocks> ftr
<willcooke> xnox, ^
<seb128> would be useful to have the env of at-spi if the process doesn't exit due to the error
<seb128> but it's weird, the a11y stack has its own bus iirc, it's not using the standard session one
-queuebot:#ubuntu-release- Unapproved: val-and-rick (bionic-proposed/universe) [0.1a.dfsg1-5build1 => 0.1a.dfsg1-6~build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted val-and-rick [source] (bionic-proposed) [0.1a.dfsg1-6~build1]
<Laney> I made it happen
<Laney> this is weird
<didrocks> anything interesting in env/file permission/confirming file doesn't exist?
<Laney> https://paste.ubuntu.com/p/VYh4qqJFpf/ that's the install debug log
<Laney> first bad line is (ubiquity:1430): IBUS-WARNING **: 09:47:25.837: The owner of /home/ubuntu/.config/ibus/bus is not root!
<cjwatson> I was suggesting here trying to get an strace -f of both ubiquity-dm and the running dbus-daemon (the latter by pid)
<cjwatson> and then assuming you hit the bug, search down for that directory name and then work backwards
<cjwatson> big hammer but it might be quickest, assuming it doesn't perturb the bug out of existence
<seb128> Laney, did you find a way to trigger it or just go it after n tries?
-queuebot:#ubuntu-release- New binary: python-requests-ntlm [amd64] (bionic-proposed/universe) [1.1.0-1] (no packageset)
<infinity> seb128: The latter.
<seb128> k :/
<enyc> "intermittent race-condition heisenbug" =)
<seb128> bug #1767048 :/ (not rc but annoying if that's the case)
<ubot5`> bug 1767048 in ubiquity-slideshow-ubuntu (Ubuntu) "Slideshow translations were not updated for 18.04 LTS" [Undecided,New] https://launchpad.net/bugs/1767048
-queuebot:#ubuntu-release- New: accepted python-requests-ntlm [amd64] (bionic-proposed) [1.1.0-1]
<infinity> seb128: Yeah, if we find ourselves having to delay, that's a valid candidate.
<jibel> seb128, are this strings in a langpack or with the package? when I look earlier today, the untranslated string in French is translated in LP since 2016
<cjwatson> in the package
<cjwatson> that's true of the installer in general - it can't rely on langpacks
<Mirv> jibel: part of the nonlangpack translations: https://wiki.ubuntu.com/NonLanguagePackTranslationDeadline
<jibel> right, that's what I supposed but everything is translated in French.
<Mirv> I think the template in LP is correct, but the translations just weren't exported and included in an upload
<cjwatson> last translation update in the package seems to have been 2017-10-17
<willcooke> seb128, jibel - everyone here as now reproduced the issue.  Adding more cpus to a VM seems to "help".  Trying to figure out what's going on now in parallel
<Mirv> jibel: the link changed a bit: https://bazaar.launchpad.net/~ubiquity-slideshow/ubiquity-slideshow-ubuntu/html/revision/810#slideshows/ubuntu/slides/gethelp.html
<Mirv> so that's why the two strings on the last page got affected
<cjwatson> I'll see if I can get a translation update going
<willcooke> seb128, jibel - "help" = help reproduce
<Laney> we found another gsettings call too https://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/bin/ubiquity-dm#L526
<Laney> without all the sudo shizzle
-queuebot:#ubuntu-release- Unapproved: python-josepy (bionic-proposed/universe) [1.0.1-1 => 1.1.0-1] (no packageset) (sync)
<seb128> cjwatson, thx
-queuebot:#ubuntu-release- Unapproved: accepted python-josepy [sync] (bionic-proposed) [1.1.0-1]
<seb128> willcooke, k, let me try that
<seb128> Laney, ah, that sounds boggus
<Wimpress> willcooke Laney jibel Ubuntu MATE are experiencing the dconf issues.
<Wimpress> It seems 100% reproducible in the 25.1 i386 image for Ubuntu MATE if that helps.
<Wimpress> I got word of this last night while travelling to UbuCon
<Wimpress> Sat in the hotel now, happy to assist.
<willcooke> Wimpress, if you have old images, could you see if you can work out when it broke?
<Wimpress> Was also broken in 25
<jibel> I couldn't reproduce with 24
<willcooke> does that tie in with the permissons fixes
<willcooke> it must do
<Wimpress> The oldest image I have is 24. So going to test it.
<seb128> willcooke, thanks for the cpu hint, I got the pb on first try after changing vbox ncpu from 1 to 2
<seb128> while I didn't get it on like 15 tries before
<willcooke> thanks apw :)
<seb128> on that session I've a dconf/user though
<seb128> but it's root:root owned
<willcooke> seb128, did you go direct in to the live session?
<seb128> no
<seb128> ubiquity-maybe (the screen with the Ui and the 2 choices)
<seb128> and clicked on "try"
<Laney> that's weird, we don't see those files
<seb128> let me retry a new boot
<Laney> because there's no user session and the xdg runtime user gets deleted
<Laney> so you can't see the root:root state, not here
<seb128> the user session is in "closing" state for me (c1)
<seb128> still active due to ibus which didn't exit
<seb128> ibus-daemon and ibus-dconf
-queuebot:#ubuntu-release- Unapproved: accepted cloud-utils [source] (xenial-proposed) [0.27-0ubuntu25.1]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-utils [source] (artful-proposed) [0.30-0ubuntu2.1]
<Laney> interesting
-queuebot:#ubuntu-release- Unapproved: python-pyvmomi (xenial-proposed/main) [5.5.0-2014.1.1-3 => 6.5.0.2017.5-0ubuntu1~16.04.1] (ubuntu-server)
<Wimpress> Laney seb128 Ubuntu MATE doesn't use ibus.
<seb128> I don't think ibus is the issue
<seb128> Laney, I think fixing those gsettings calls in -dm done without the wrapper is worth trying
<seb128> Laney, I killed ibus, session closed, dconf dir had been wipped out
<seb128> but the file was there and root owned in my case
<seb128> didrocks, ^
<didrocks> yeah, I think the gsettings call fix worth a shot (ensuring it has correct DBUS address and XDG_RUNTIME_DIR)
<Laney> trying to see where the bad permissions actually come in
-queuebot:#ubuntu-release- Unapproved: ubiquity-slideshow-ubuntu (bionic-proposed/main) [137 => 138] (kubuntu, ubuntu-desktop)
<Mirv> thanks cjwatson
<cjwatson> seb128,didrocks,Laney: I think that would be https://paste.ubuntu.com/p/RSqyqmz6s2/
<cjwatson> naive untested conversion
<cjwatson> (the logfile stuff is probably unnecessary, but is just in case)
<cjwatson> can somebody try editing that in place?
 * didrocks still can't reproduce itâ¦ a quick diff look sounds good to try out with the wrapper we fixed
 * cjwatson is too rusty on all this and also doesn't have a reproducer case to hand
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (xenial-proposed) [1:2.5+dfsg-5ubuntu10.26]
<silWeb> cjwatson: reviewing the slideshow upload o/
<cjwatson> thanks
<cjwatson> I mean it's 123000 lines of unreviewable diff, but go nuts
<Mirv> fwiw I checked all the fi.po in the diff and it seemed to do what it's supposed, for all flavors
<silWeb> Reviewing as much as possible, sanity checking
<silWeb> But looks like the translations aren't bogus
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity-slideshow-ubuntu [source] (bionic-proposed) [138]
<cjwatson> Laney can still reproduce #1767067 with my patch
<seb128> :(
<cjwatson> we're hitting it with more debugging
<cjwatson> https://people.canonical.com/~cjwatson/tmp/ubiquity-gsettings.patch is the current thing in progress
<seb128> cjwatson, thanks for the status updates on IRC!
<xnox> Laney, infinity, cjwatson - "fix" the permissions, before quiting (meaning inside on_click handler of Try Ubuntu button) http://paste.ubuntu.com/p/gz6ddmPSF4/
<xnox> trying this now
<seb128> xnox, cjwatson, Laney, I guess you already saw that, but booting to ubiquity-maybe, going to a tty I've dconf/user root owned
<seb128> so it's clearly from ubiquity-dm and not during the session start later
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (xenial-proposed) [1.3.1-1ubuntu10.22]
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (artful-proposed) [3.6.0-1ubuntu6.6]
<Laney> yeah
<willcooke> seb128, hard deadline for a decision abot a release today is 4pm UK time.  Current options are, AIUI, revert the a11y fixes and respin -or- release as is -or- fix the bug
<willcooke> seb128, could you look at how we could save some time if we do revert so that we've got a headstart if that is the final decision?
<willcooke> like maybe make a start on reverting?
<willcooke> JamieBennett, fyi ^
<seb128> willcooke, are we confident a revert would fix it?
<silWeb> Did we bisect it to started after this weeks a11y fixes?
<silWeb> jibel: you tried earlier images, right?
<jibel> silWeb, I tried 24
<willcooke> yeah jibel tried earlier images, and Wimpress did too
<jibel> i'm trying a revert of a a11y patch
<seb128> willcooke, on what image did it start?
<seb128> did it start with ubiquity .11 or .12?
<willcooke> 25 I think
<seb128> or .10?
<silWeb> On the 24th the a11y fixes landed
<seb128> which one
<seb128> we had several iterations
<silWeb> The keypress one, and it was in the 25 image
<silWeb> https://launchpad.net/ubuntu/+source/ubiquity/18.04.11
<silWeb> jibel: so you could reproduce with 24 as well or not?
-queuebot:#ubuntu-release- Unapproved: virtualbox (bionic-proposed/multiverse) [5.2.10-dfsg-5 => 5.2.10-dfsg-5ubuntu1] (ubuntu-cloud)
<LocutusOfBorg> can we have virtualbox processed please???^^^ I can sync from Debian, but I think this is too late, so I would like to do an sru
<LocutusOfBorg> (in case, accept when convenient
<silWeb> LocutusOfBorg: I'll look at it once the fires are extinguished
<jibel> silWeb, I didn't reproduce with 24
<acheronuk> the bug just changed to "Fix Released"?
-queuebot:#ubuntu-release- Unapproved: nvidia-cuda-toolkit (bionic-proposed/multiverse) [9.1.85-3 => 9.1.85-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (bionic-proposed/multiverse) [5.2.10-dfsg-5ubuntu18.04.1 => 5.2.10-dfsg-5ubuntu18.04.2] (no packageset)
<cjwatson> seb128: my analysis of the debug output so far is that dconf/user is being created as root by ubiquity rather than by ubiquity-dm
<cjwatson> at least in the cases we've looked at
<seb128> cjwatson, is "maybe-ubiquity" using ubiquity or -dm?
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-cuda-toolkit [source] (bionic-proposed) [9.1.85-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-hwe [source] (bionic-proposed) [5.2.10-dfsg-5ubuntu18.04.2]
<cjwatson> acheronuk: that's interfering users for you
<seb128> sorry I'm not that familiar with how ubiquity works
<seb128> I though the standalone mode was -dm
<seb128> and ubiquity the UI used in the live session
<cjwatson> maybe-ubiquity goes through ubiquity-dm
<cjwatson> which starts ubiquity as a subprocess within X etc.
<seb128> I see
<seb128> well at least by the time the 2 choices screen is displayed I've a dconf/user root owned
<cjwatson> xnox: I mean ... I guess.  perhaps.  pretty awful though
<seb128> I did a gsettings wrapper that logs uid/$@/env and call the real binnary
<seb128> the /usr/bin/gsettings command is never called as root
<seb128> but I guess that was not a likely case, anyway that seems ruled out
<Wimpress> There is a useful bug in Ubuntu MATE that might be interesting to you
<cjwatson> it was definitely possible though I'd mostly ruled it out here, but thanks for the confirmation
<Wimpress> crtl + alt + t works in Ubiquity
<seb128> is that still true?
<seb128> sounds like one of the possible side effect of the gsettings misuse we fixed recently
<seb128> in any case switch to a tty works now in ubiquity so it's easy to get a debug command line
<Wimpress> Not on HPI ;-)
<Wimpress> And the ctrl + alt +t thing has been around for a good while.
-queuebot:#ubuntu-release- Unapproved: ruby-delayed-job-active-record (bionic-proposed/universe) [4.1.2-1 => 4.1.2-2] (no packageset)
<ahasenack> LocutusOfBorg: I got that "distribution data outdated" error too in a script a jenkins job is using: /usr/bin/download-latest-test-iso. Do you know where that script comes from by any chance? https://pastebin.ubuntu.com/p/wZgVs2n7ym/
<cjwatson> distro-info
-queuebot:#ubuntu-release- Unapproved: accepted ruby-delayed-job-active-record [source] (bionic-proposed) [4.1.2-2]
<cjwatson> happens on release day every six months
<LocutusOfBorg> ahasenack, sudo vi /usr/share/distro-info/ubuntu.csv
<LocutusOfBorg> set the bionic date to tomorrow
<LocutusOfBorg> 18.04 LTS,Bionic Beaver,bionic,2017-10-19,2018-04-27,2023-04-26
<ahasenack> I don't have shell access on that box
<LocutusOfBorg> and postpone the issue for 24h :)
<seb128> Wimpress, well, we fixed that gsettings bug this week, could have made that hack stop working
<LocutusOfBorg> so, ask to SRU the fix, you need to add a new entry with CC and some tentative schedule I would guess
<ahasenack> this is the ci job that gates the live-server iso image from pending to current
<ahasenack> need to find someone who can hack it
<ahasenack> josh is on pto
<cjwatson> ahasenack: please could you debug this elsewhere?
<cjwatson> we have enough fires here
<rbalint> Laney: can we expect bionc/s390x autopkgtest runners to be fixed before the release or hints may be the way to go?
<jibel> ahasenack, i'll have a look
<Laney> rbalint: IS is looking
<rbalint> Laney: thanks!
<cjwatson> seb128: I'm wondering if Gio.Settings.new in gtk_ui might create the dconf/user file with the privileges of the current process
<cjwatson> or something in those bindings
<cjwatson> it looks to me as though dconf-service creates that even if reading
<jibel> I reverted this http://paste.ubuntu.com/p/p7xdxWqwNN/ (r6627) and cannot reproduce the bug
<seb128> cjwatson, the way gsettings work dconf is only used for writes and dconf-service shouldn't start on reads
<seb128> or until you issue a write
<cjwatson> what else would be creating dconf/user though?
<seb128> nothing that I know of
<seb128> I would expect that some root code is issue a dbus call that tells dconf to write something
<cjwatson> I think we should go ahead with this revert now (reversioned to 18.04.13 rather than 18.04.12ubuntu1, but otherwise jibel's patch LGTM)
<cjwatson> does anyone object?  we should definitely continue to try to find the root cause but we're pretty nearly out of time
<jibel> could someone else test the revert?
<cjwatson> I think apw is doing so
<apw> sil2100, ^ apw@brain:~/vms$
<apw> sil2100, ^ are you doing that ?
<seb128> cjwatson, if we think it's fine to release without screen reading in the installer that makes sense
<cjwatson> I mean it's not *fine* but it may be least-bad
<cjwatson> and fix properly for .1
<sil2100> I'm testing it
<Mirv> if there's the respin, will you unblock http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubiquity-slideshow-ubuntu before that?
<infinity> Mirv: Yes.
<Mirv> ok
<jbicha> jibel: the screen reader was broken for 17.10 too, right?
<cjwatson> xnox has an alternative hack that chowns dconf/user to 999:999 in the try_ubuntu entry point
<cjwatson> I think personally I'm more comfortable with the revert - fewer unknowns
<cjwatson> but that's just me
<cyphermox> jibel: looking at the code, wouldn't it have made the screen reader only work in the only-ubiquity session?
<cyphermox> oh, duh
<acheronuk> a revert will re-break ubiquity reboot for flavours?
<jibel> cyphermox, yes, but without it there is not way for someone blind to boot to the live session or install the distro
<cjwatson> only a revert of the screen reader stuff
<cjwatson> I don't think the reboot fix needs to be involved
<cyphermox> jibel: yeah, I clued in... also in a normal session you can start it yourself..
<seb128> cjwatson, I tried to do the Gio.Settings.new/connect/etc from a root python interpreter, that doesn't lead to a dconf/user file created
<cjwatson> maybe it depends on the signal being received?
<seb128> well I went to another tty and did a write on the key
<jibel> cyphermox, right but if your blind you cannot go to the live session
<seb128> but maybe I tested something not right
<jibel> you are*
<seb128> the callback didn't seem to get called
<cjwatson> it's clear that reverting a screen reader fix would be bad for blind people, and I don't *like* that
<cyphermox> jibel: maybe-ubiquity gives you the option. that's what you'd get normally if you just wait at the bootspash in legacy mode
<cyphermox> if you're booting UEFI you'd fall right in the live session if I'm not mistaken
<jibel> cyphermox, how do you know which button to click and that you're on the right button if you do not *see* it
<cjwatson> xnox's alternative hack wouldn't have that downside; I'm less comfortable with that I think basically because I feel that there are too many paths to check
<xnox> willcooke, cjwatson, Laney, infinity, jibel, apw - here is my bodge/hack, possibly will not be taken, but this appears to fix it for me
<xnox> https://code.launchpad.net/~xnox/ubiquity/fixup-owner-dconf/+merge/344474
<xnox> if interested
<cyphermox> jibel: people know to hit left or right and then enter.
<cyphermox> (or at least, some do)
<jibel> how? just turn off your screen and try
<cjwatson> jibel: I understand that you're arguing really hard that reverting a screen reader fix is bad.  What's your positive alternative suggestion?
<jibel> https://code.launchpad.net/~jibel/ubiquity/lp1767067_revert_r6627_a11y if we go the revert way
<cjwatson> jibel: Do you prefer xnox's patch?
<cjwatson> xnox: needs to be chown uid:uid rather than just uid I think
<cjwatson> mode 600. I *guess*.
<seb128> cjwatson, xnox, I would just rm the file
<jibel> cjwatson, I don't have an alternative, I was replying to "in a normal session you can start it yourself" which is not true for disabled users
<seb128> that file is not useful, it's just the way dconf has to tell client code to reload the db after it changes
<seb128> dconf-service is going to rewrite the file if it's not there
<cjwatson> reasonable point
<xnox> seb128, true, if dconf is restarted and if that file is not locked / not in use....
<xnox> seb128, let me try
<cjwatson> I mean after try-ubuntu it surely ought not to be :)
<xnox> sil2100,  https://code.launchpad.net/~xnox/ubiquity/fixup-owner-dconf/+merge/344474
<cyphermox> xnox: ubi-language seems late to be doing this?
<cjwatson> it's the try-ubuntu entry point
<cjwatson> so it's effectively where we're about to exit ubiquity
<cyphermox> heh
<cjwatson> xnox: also, needs a great big comment explaining WTF is going on
<cjwatson> and to be moved above the "Spinning cursor" comment
<cjwatson> a hack like this with zero inline commentary isn't acceptable
<sil2100> I'm prepping an iso with xnox
<sil2100> 's branch as well
<didrocks> yeah, removing the file sounds the best path to me for now
<xnox> seb128, cjwatson - removing file, works good. Pushing branch.
<seb128> :)
<didrocks> phew :)
<sil2100> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1767067
<ubot5`> Ubuntu bug 1767067 in ubiquity (Ubuntu Bionic) "Booting to live session fails with: at-spi-bus-launcher: unable to create file '/run/user/999/dconf/user': Permission denied." [Critical,Confirmed]
<willcooke> update: new patch being pushed now, then an image, then we need to test
<didrocks> great!
<seb128> good
<Wimpress> willcooke: Is one sample test image being created?
<Wimpress> If so, I've found somewhere with WiFi. Can download and test.
<xnox> apw, https://code.launchpad.net/~xnox/ubiquity/fixup-owner-with-remove/+merge/344477
<xnox> here
<xnox> here
<seb128> cjwatson, looking at the timestamp of the dconf/user root owned and the journal log with millisec precision the file is modified really close from the Gio.Settings.new use and I can't find anything else in the patch/code that could explain the problem so you might be right
-queuebot:#ubuntu-release- Unapproved: ubiquity (bionic-proposed/main) [18.04.12 => 18.04.13] (core)
<Laney> seb128: think I know the real fix, can we talk about it?
<seb128> oh, waouh
<seb128> sure!
<Laney> ok
<Laney> so the code ended up in run() instead of __init__() which is where I was putting it
<Laney> problem is that run() runs as root and __init__ as the user
<Laney> so the dconf call is happening as the root user
<cjwatson> (this seems promising and I'm happy with it replacing the 18.04.13 above)
<Laney> what I don't understand is why it was a race
<Laney> presumably the callback racing with a regain_privileges() elsewhere or something
<seb128> ah
<seb128> that's a bit weird
<seb128> I also don't understand what "dconf call" is happening
<Laney> whatever Gio.Settings.new is doing
<Laney> or the read maybe
<seb128> but it shouldn't do one
<seb128> and dconf shouldn't start until there is a writte
<seb128> that's one of the things desrt was always pointing, on a normal session login dconf shouldn't be activated
<seb128> the reads go through direct mmaping of the db
<seb128> well, if moving to __ini__ fixes the issue that great and I think it's a better way out
<seb128> but I still don't fuilly understand it either
<seb128> neither why it's a race nor why there is a write at all
<cjwatson> I'm thinking maybe it socket-activates something as root that then later creates dconf/user due to a gsettings set?
<seb128> could be I guess
<seb128> Laney, you/anyone is trying to move the Gio blob to __init__ now?
<Laney> yes
<seb128> great
<Laney> I'll do a merge proposal in a second
<seb128> thx, let me know and I give it a try as well
<ginggs> can nvidia-cuda-toolkit be unblocked please?
-queuebot:#ubuntu-release- Unapproved: synapse (bionic-proposed/universe) [0.2.99.3-1 => 0.2.99.4-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted synapse [sync] (bionic-proposed) [0.2.99.4-1]
-queuebot:#ubuntu-release- Unapproved: sugar-read-activity (bionic-proposed/universe) [119-1 => 120-1] (sugar) (sync)
-queuebot:#ubuntu-release- Unapproved: sugar-browse-activity (bionic-proposed/universe) [201.3-1 => 202-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted sugar-browse-activity [sync] (bionic-proposed) [202-1]
-queuebot:#ubuntu-release- Unapproved: sugar (bionic-proposed/universe) [0.112-2 => 0.112-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted sugar [sync] (bionic-proposed) [0.112-4]
<Laney> xnox: apw cjwatson seb128 https://code.launchpad.net/~laney/ubiquity/lp1767067/+merge/344482
<seb128> Laney, thx, testing that
<Laney> accidentally pushed it to trunk again ://///
<cjwatson> have retroreviewed
-queuebot:#ubuntu-release- Unapproved: rejected ubiquity [source] (bionic-proposed) [18.04.13]
-queuebot:#ubuntu-release- Unapproved: ubiquity (bionic-proposed/main) [18.04.12 => 18.04.14] (core)
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (bionic-proposed) [18.04.14]
<Laney> http://people.canonical.com/~laney/ubiquity-gsettings.patch
<Laney> that's the same thing as a .patch
<Laney> You can apply it in break=bottom or whatever
<Laney> that ubiquity is going to be unblocked and then we'll respin
-queuebot:#ubuntu-release- Unapproved: accepted sugar-read-activity [sync] (bionic-proposed) [120-1]
<doko> any update on the s390x autopkg runners?
<xnox> doko, no, and not work on in this channel.
<xnox> (as in it is tracked / debugged on internal channel)
<doko> xnox: must be so internal that I cannot follow it :-/
<doko> are desktop images the only images for the respin?
<infinity> doko: No.
<jbicha> infinity: I tried pinging handsome_feng twice about the 5 year support for Kylin issue but I didn't really get a reaction
<handsome_feng> jbicha, infinity:Hi, I'm here
<jbicha> handsome_feng: I'm not a member of the Tech Board or Release Team
<jbicha> but I think there are concerns about whether Kylin can support its packages for 5 years now that it is no longer based on the main Ubuntu flavor supported by Canonical
<jbicha> and Ubuntu MATE is only offering 3 years of support
 * acheronuk assumed that 5 years was a typo?
-queuebot:#ubuntu-release- Unapproved: freeipa (bionic-proposed/universe) [4.7.0~pre1+git20180411-2ubuntu1 => 4.7.0~pre1+git20180411-2ubuntu2] (no packageset)
<doko> infinity: please could you considering to ignore the i386 autopkg test failure for python-redis and accept that one? please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896864 for the background. we could accept the upload in unapproved too instead
<ubot5`> Debian bug 896864 in src:python-redis "python-redis autopkg test failures on i386" [Important,Fixed]
<jbicha> handsome_feng: is 3 years support ok for Kylin?
-queuebot:#ubuntu-release- Unapproved: accepted freeipa [source] (bionic-proposed) [4.7.0~pre1+git20180411-2ubuntu2]
<handsome_feng> jbicha: I'm ping my leader, so please wait a moment. :)
-queuebot:#ubuntu-release- Unapproved: dogtag-pki (bionic-proposed/universe) [10.6.0-1ubuntu1 => 10.6.0-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted dogtag-pki [source] (bionic-proposed) [10.6.0-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted java-atk-wrapper [source] (bionic-proposed) [0.33.3-20ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted python-redis [source] (bionic-proposed) [2.10.6-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted xdg-desktop-portal [sync] (bionic-proposed) [0.11-1]
-queuebot:#ubuntu-release- Unapproved: accepted python-networkx [source] (bionic-proposed) [1.11-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: bind-dyndb-ldap (bionic-proposed/universe) [11.1-3 => 11.1-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted xdg-desktop-portal-gtk [sync] (bionic-proposed) [0.11-1]
-queuebot:#ubuntu-release- Unapproved: accepted bind-dyndb-ldap [source] (bionic-proposed) [11.1-3ubuntu1]
<Guest85065> !isitout
<ubot5`> Not yet!
<doko> ok, uploading tdaitx's fix for ceph as well
-queuebot:#ubuntu-release- Unapproved: ceph (bionic-proposed/main) [12.2.4-0ubuntu1 => 12.2.4-0ubuntu2] (desktop-core, ubuntu-server)
<Wimpress> jbicha: Give Kylin is base on MATE and Ubuntu MATE is 3 years I don't see how Kylin can offer 5.
<Wimpress> handsome_feng: See above ^
<seb128> cjwatson, Laney, willcooke, I tested a few reboot with what is currently in lp:ubiquity (patching the code in rescue.target) and I didn't hit the error, looks good so far to me
<didrocks> I couldn't reproduce the issue, but I didn't get any regression with the same inline patching method
<seb128> thx didrocks
<Laney> thx
<Laney> we tried lots of times here too
<handsome_feng> Wimpress, jbicha, infinity: After dissussing with the other members of ubuntu kylin, we agree with the desision that offering 3 years support for kylin
<doko> infinity: please review the ceph upload
<handsome_feng> Wimpress: Thanks! :)
<jbicha> handsome_feng: could you reply to your reply on the ubuntu-release mailing list then? thank you
<handsome_feng> jbicha: Fine, I will do it now
<jbicha> slangasek: sorry about the lateness but would you approve of me uploading gnucash 3.0 with the build tests ignored? LP: #1758740
<ubot5`> Launchpad bug 1758740 in gnucash (Ubuntu) "FFe: Sync gnucash 1:3.0-1 (universe) from Debian experimental (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/1758740
<slangasek> jbicha: you want to sync a package with a failing test whose impact you don't know, in order to be able to remove webkitgtk?
<slangasek> jbicha: reverse-depends also suggests this is not the only remaining blocker for webkitgtk
<rbasak> Could I have an ack from a release team member on https://code.launchpad.net/~racb/ubuntu-seeds/demote-nagios3/+merge/344490 please?
<rbasak> In particular are there any implications that I'm missing?
<jbicha> slangasek: yes. ð Those other rdepends are kinda unimportant
<slangasek> rbasak: no impact on metapackages/images; ok to make that change if you're sure
<rbasak> slangasek: thanks. Also is it syntactically OK to drop the Monitoring section in the seed file?
<slangasek> rbasak: sure, those are just human-readable labels
<rbasak> Yeah that's what I thought. Thanks. I'll push.
<abdelraouf> hello guys, when'll 18.04 LTS be available for download
<dpb1> it will be announced when it's ready
<doko> rbasak: remove from artful?
<abdelraouf> there is too much work left ?
<rbasak> doko: not remove, just demote.
<rbasak> I've pushed the branch.
<doko> rbasak: really from artful?
<rbasak> I guess someone will need to move it after that takes effect?
<tjaalton> doko: so I have the patch for tomcat jre8 support ready and test suite passes, so either push that or revert to build with jdk8. opinions? I'll send the patch upstream soon
<rbasak> doko: no, bionic
<doko> ahh, ok
<doko> tjaalton: I would prefer the former
<tjaalton> doko: ok, I'll upload that
-queuebot:#ubuntu-release- Unapproved: tomcat8 (bionic-proposed/universe) [8.5.30-1ubuntu1 => 8.5.30-1ubuntu2] (kubuntu)
<jbicha> slangasek: oh never mind. Eclipse depends indirectly on webkitgtk and I never got around to seeing how badly Eclipse would break if that dep were removed
<slangasek> jbicha: ok.  in any case, I'm not ok with this as a last-minute untested change
<infinity> jbicha: Thanks for clearing that up for us (re: kylin support length)
<infinity> doko: Too late for ceph, it's on some images.  It'll need to be an SRU.
<doko> ok
<jbicha> infinity: np. I thought it was strange when Kylin proposed 5 years this time but it wasn't my job so I didn't say anythingâ¦
<seb128> cjwatson, Laney, didrocks, k, I confirmed with http://people.canonical.com/~seb128/startorca.py started with sudo -E -H that it leads to a root owned dconf/user
<JHOSMAN> How long is it until the ISO's release of 18.04?
<rbasak> infinity: so to be clear I'm expecting a component mismatch to appear somewhere. So you're aware.
<cjwatson> JHOSMAN: we won't be giving expected times here; please don't ask
<didrocks> seb128: thx for testing, so reading a key lead to thisâ¦ weird :/
<slangasek> rbasak, infinity: I'm going ahead with the nagios demotions now
<dpb1> JHOSMAN: sign up here, and you wont have to poll https://lists.ubuntu.com/mailman/listinfo/ubuntu-announce
<JHOSMAN> thanks dpb1
<rbasak> Thanks
<doko> infinity, slangasek: please unblock ruby-delayed-job as well
<infinity> doko: Refresh the page?
<infinity> doko: Oh, NVM, I had the longer named one.
<doko> infinity, slangasek: slangasek mentioned a possibility to ignore the "crossbuild-essential-amd64/amd64 unsatisfiable Depends: gcc-x86-64-linux-gnu" for build-essential. is this possible?
<flocculant> infinity: hi - just got in from work - are we respinning?
<infinity> doko: Not for release, build-essential is on media, and we're respinning in a matter of minutes.
<Wimpress> flocculant: Yes.
<flocculant> Wimpress: okey doke - thanks
<Mirv> duty calls, but thank you everyone in advance for your hard work
<teward> is everything still on track for release today?
<slangasek> xnox, Laney: should ntp block the network-online target?  Should the autopkgtest runner setup scripts key on time-sync.target?
<slangasek> teward: we're having to respin desktop images at the very last minute, but still on target for some value of "today"
<teward> slangasek: cool.  I'm more concerned about the Server images here, but I thought I'd ask.  :)
<slangasek> those images have no known blockers; but the release happens across all flavors at once
<teward> indeed.  glad to know it's "in the works" either way :)
<xnox> slangasek, time-sync.target only starts ntp daemon; but does not block until ntp sync is finished. we do start and reach time-sync.target; there is a new wait-time-sync.target with a wait-time-sync binary that blocks sysinit.target until NTP is *synced*
<xnox> but that's only in v238 which we do not have yet.
<slangasek> k
<slangasek> so "yes in principle but doesn't help us today"
<xnox> that
<slangasek> anyway, I bumped the RT
<xnox> thanks
<xnox> slangasek, "local" time on machines appear to be in EDT timezone, and wrong time.
<LocutusOfBorg> accepting vbox will make me so happy :)
-queuebot:#ubuntu-release- Unapproved: virtualbox (bionic-proposed/multiverse) [5.2.10-dfsg-5 => 5.2.10-dfsg-6] (ubuntu-cloud) (sync)
<LocutusOfBorg> also people upgrading and finding their saved snapshots working and not completely broken
<slangasek> xnox: and did this just recently change on the machines, or did something change in the apt/archive behavior?
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox [source] (bionic-proposed) [5.2.10-dfsg-5ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox [sync] (bionic-proposed) [5.2.10-dfsg-6]
<dpb1> slangasek: https://bugs.launchpad.net/subiquity/+bug/1766980 - comments 11 and particularly 12
<ubot5`> Ubuntu bug 1766980 in subiquity "Failed to import ssh key" [High,Triaged]
<doko> tjaalton: I assume tomcat8 will need a SRU. is in the kubuntu seed
<xnox> slangasek, it has finally drifted far enough for apt to stop considering them as good enough drift
<xnox> slangasek, apt was updated a while back; but this issue is reproducible on xenial guests too.
<xnox> slangasek, so i'm suspecting HMC->lpar->nova->qemu side of things, rather than guest.
<xnox> guest should be made more resilient against buggy hosts, and block on ntp sync. but both things should be fixed.
<dpb1> ahasenack: at least we should add a release note for the ssh-import-id problem.  I think until we have a definitive error condition more than that, it's not worth escalating.
<ahasenack> ok
<dpb1> ahasenack: I suspect it doesn't happen on vms due to races, and wasn't caught there?
<ahasenack> dpb1: oh, we were talking about two things then
<ahasenack> a) this ssh key one for subiquity
<ahasenack> b) the desktop bug people here have been rallying about
<dpb1> ahasenack: no, I'm just talking subiquity
<slangasek> xnox: indeed
<slangasek> dpb1: thanks, reading
<doko> slangasek: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt is this already addressed?
<slangasek> doko: yes, *twice*, I went to process it and found somebody else had already demoted them despite me commenting here
<doko> I didn't
<infinity> I did it ages ago.
<infinity> slangasek: Oh, erk.  Did you do those demotions again after I did?
<slangasek> infinity: possibly, considering I replied here 2 minutes after rbasak's comment saying I would take care of it
<infinity> slangasek: I was probably already alt-tabbed and doing it.
<infinity> slangasek: I'll copy them all back in after I've started image builds to undo double-override bain damage.
<infinity> s/bain/brain/
<slangasek> ok
-queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (bionic-proposed/multiverse) [5.2.10-dfsg-5ubuntu18.04.2 => 5.2.10-dfsg-6ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-hwe [source] (bionic-proposed) [5.2.10-dfsg-6ubuntu18.04.1]
<tjaalton> doko: hah, ok
<stgraber> hmm, we're getting reports that dist-upgrading a clean Ubuntu 16.04 server to 18.04 leads to apparmor being removed, will try to reproduce now
<stgraber> second such report in two days (heard of it because LXD isn't very happy when the apparmor tools are missing and apparmor isn't disabled by the user)
<infinity> stgraber: That's a neat trick.
<infinity> stgraber: Although, to be fair, almost nothing depends on it.
<infinity> stgraber: And without using do-release-upgrade, I don't see why we'd expect ubuntu-standard to always stick aorund.
<stgraber> sorry, wasn't clear, that was with do-release-upgrade
<infinity> Oh, that's more sketchy.
<stgraber> which is why I'm looking into it at all :)
<stgraber> deploying clean 16.04 server on MAAS, will try to do-release-upgrade that and see if I still have apparmor, if not, that may be a bit of a problem
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Bionic Final] has been updated (20180426)
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Bionic Final] has been updated (20180426)
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Bionic Final] has been updated (20180426)
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Bionic Final] has been updated (20180426)
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Bionic Final] has been updated (20180426)
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Bionic Final] has been updated (20180426)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Bionic Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Bionic Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Bionic Final] has been updated (20180425.1)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Bionic Final] has been updated (20180425.1)
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Bionic Final] has been updated (20180426)
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Bionic Final] has been updated (20180426)
<dpb1> oooh
<krosonp> wow it's really fun to watch this :)
<acheronuk> Kubuntu marked ready in error. whoops :P
 * acheronuk watches the world re-spin
<acheronuk> so what QA do we do on these respins? sanity check on ubiquity and slideshows?
<infinity> acheronuk: boot-install-reboot smoketest, make sure the slideshow kinda slideshows, and for gtkish flavours, check screen reader works.
<acheronuk> right thanks
<slangasek> infinity: is that only subiquity that's being rebuilt?  (looking at email about failed rebuild)  what's the trigger for that?
<infinity> slangasek: oem-config is on literally every image.
<infinity> How it failed, I don't know.
<slangasek> infinity: squint
<popey> stgraber: fwiw I just upgraded a clean 16.04.4 to 18.04 and apparmor is still there
<dpb1> pshew
<popey> stgraber: i have seen oddities (not this specifically) where people install from an older point release.
<stgraber> popey: yeah, same with clean 16.04 server here, trying with one using the version of LXD our bug reporter used
<popey> kk
<stgraber> popey: so far, apt doesn't show me any weird removal so I expect that to work too
<stgraber> which is good, that means we won't find ourselves with a good chunk of our server users running without apparmor
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Bionic Final] has been updated (20180426)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Bionic Final] has been updated (20180426)
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Bionic Final] has been updated (20180426)
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Bionic Final] has been updated (20180426)
<willcooke> dpb1, ^
<ahasenack> does this mean the pending/ subdirectory contains these now?
<infinity> ahasenack: http://cdimage.ubuntu.com/ubuntu-server/daily/20180426/
<ahasenack> the timestamp there is odd, it's from yesterday still, albeit close to midnight
<dpb1> ah
<ahasenack> mh, daily, that's not subiquity, is it?
<dpb1> daily-live is
<stgraber> popey: yeah, install with LXD 2.21 works fine too, apparmor is still there
<popey> odd, does something conflict with apparmor maybe?
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Bionic Final] has been updated (20180426)
<ogra_> yeah, perhaps something they installed on 16.04
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Bionic Final] has been updated (20180426)
<stgraber> possibly, apparmor is a recommends of ubuntu-standard, so I can see how it may be removed to satisfy the upgrade, but I'd need to know more about what that user might have done differently first...
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Bionic Final] has been updated (20180426)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Bionic Final] has been updated (20180426)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Bionic Final] has been updated (20180426)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Bionic Final] has been updated (20180426)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Bionic Final] has been updated (20180426)
<willcooke> pizza has arrived
<popey> \o/
<bdmurray> wait where?
<apw> in my hand ?
<xnox> bdmurray, it is good
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Bionic Final] has been updated (20180426.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Bionic Final] has been updated (20180426.1)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Bionic Final] has been updated (20180426)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Bionic Final] has been updated (20180426)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Bionic Final] has been updated (20180426)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Bionic Final] has been updated (20180426)
<valorie> there we are
<willcooke> \m/
<Laney> SHIP. IT.
<krosonp> !press the button!
<ubot5`> krosonp: I am only a bot, please don't think I'm intelligent :)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Bionic Final] has been updated (20180426)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Bionic Final] has been updated (20180426)
<valorie> zsyncing....
<doko> mehh, woo build on arm64 restarted?
<slangasek> "woo build"?
<Laney> https://launchpad.net/ubuntu/+source/woo/1.0+dfsg1-2ubuntu1/+build/14797731 ?
<popey> BIOS boot 20180426 ubuntu image, chose f4 screen reader, try ubuntu. I get no voices.  Audio works - I get drums on launching ubiquity
<popey> Is there some additional key-combo to make it speak to me?
<jdstrand> stgraber, infinity: fyi, I've tested this myself and can't reproduce. note that apparmor did introduce a Breaks: media-hub, mediascanner2.0, messaging-app, webbrowser-app
<jdstrand> none of that would be on server though
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Bionic Final] has been updated (20180426)
 * flocculant waits for popey's answer
 * sil2100 tests studio
<willcooke> popey, alt + super + s
<popey> ok, that poked it
<willcooke> phew
<flocculant> willcooke: which does nothing on xubuntu
<flocculant> not sure we've ever tested it
<Laney> that specific code path
<Laney> is for gnome
<Laney> not sure what xfce uses, maybe something different
<flocculant> Laney: oh right - I just read the testcase - will have to investigate that at some point and deal with the testcase
<ogra_> jdstrand, heh, you have high confidence in server users :)
<ogra_> .oO( oh. that media-hub thing could be helpful for my streaming server )
<popey> hm, can't get my thinkpad to boot this usb in uefi mode. black screen. maybe pilot error.
<willcooke> Use cases all passed on what was the crashy hardware here
<popey> i keep getting grub
<willcooke> with the options of try install etc?
<popey> ya
<willcooke> thats normal.  It should boot to live from there if you leave it, or select try
<popey> We don't show the super menu thing in uefi mode?
<willcooke> no because UEFI
<jibel> translations of the slideshow are correct in French.
<popey> ok, screen reader works here in both uefi and bios mode
<Laney> fantastique!
<jdstrand> stgraber, infinity: fyi, I tried a server install with media-hub installed (one of the Breaks from apparmor): apt-get upgrade has apparmor correctly held, apt-get dist-upgrade has it upgrade with media-hub removal, do-release-upgrade -d has it upgrade with media-hub removal
<jdstrand> I think we need to put this in the 'needs info' column
<stgraber> jdstrand: yeah, definitely. If we get more such reports we'll try to track down what they have in common
<flocculant> Wimpress: running 64bit install for you screen reader working
<popey> https://usercontent.irccloud-cdn.com/file/sorZj2gJ/IMG_20180426_202857.jpg
<popey> That's annoying.
<jibel> popey, do you have an existing operating system on this machine?
<popey> yes
<popey> windows 10 on another ssd
<sil2100> popey: ok, that's ugh, a known bug sadly
<jibel> popey, likely bug 1766945
<ubot5`> bug 1766945 in ubiquity (Ubuntu) "(EFI on top of legacy install) choosing "replace" or "resize" options in partitioning may lead to an install failure" [Undecided,New] https://launchpad.net/bugs/1766945
<sil2100> Partially caused by my removal of the partman-efi force_uefi warning
<sil2100> Since that's this case I didn't taste
<sil2100> s/taste/test
<popey> ok
<abdelraouf> popey: can you disable UEFI support
<abdelraouf> from bios?
<popey> i jhave already tested with uefi off
<popey> now I'm testing with it on, but can't.
<popey> but we know that's a known bug now. thanks seb128 jibel
<jibel> I did a bunch of smoke tests with 26: dm -> live session -> install, dm -> install, syslinux -> live -> install, syslinux -> install. Tried with and without orca and also a series of dm -> live boots. nothing to report, ubuntu desktop looks fine.
<Laney> â¥
<willcooke> thanks jibel
<willcooke> jibel, could you comment on the bug to that effect?
<jibel> yes
<Laney> ð
<popey> testing MATE i386 and amd64
<flocculant> Wimpress: did 64 bit screen reader for you
<flocculant> wxl tsimonq2 - doing 64 bit lubuntu
<popey> flocculant: yes, amd64 mate screen reader worked here
<flocculant> popey: and here
<willcooke> thanks ahasenack
<flocculant> no idea how to screen reader in lubuntu - just testing it installs
<popey> flocculant: does it not trigger from the menu at boot?
<flocculant> seemingly not
<flocculant> did the F5 choose screen reader - like I did for us (xubuntu)
<flocculant> same result - silence
<sil2100> Studio looks good (on a kvm)
<popey> flocculant: which iso did you grab?
<flocculant> wxl tsimonq2 - lubuntu slideshow, browse the web slide - might be useful to update that pic from 16.10 ;)
<popey> i only see alternate isos
<flocculant> http://iso.qa.ubuntu.com/qatracker/milestones/389/builds/171117/testcases
<flocculant> definitely on the tracker
<popey> ah got it
<popey> daily-live - duh
<flocculant> oh really? I see it on Bionic Final page here
<popey> ok, mate i386 and amd64 are good here.
 * flocculant is doing things he can zsync quickly
<sil2100> Trying budgie now
<jibel> budgie and kylin, anyone ?
<sil2100> i386
<flocculant> sil2100: I'm on the way to having budgie 64bit
<jibel> k, syncing kylin
<ahasenack> I don't know how to test the screen reader, I have never used it before
<flocculant> at 835.2 kBps :|
<ahasenack> in legacy boot, I see "f5", used that, selected screen reader, and then hit "try ubuntu" in the menu
<ahasenack> but nothing is different
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Bionic Final] has been updated (20180426)
<valorie> ooooo, it rebooted ok!
<valorie> \o/
<popey> jibel: need me to do one?
<acheronuk> valorie: oem?
<sil2100> flocculant: excellent! I'm testing i386 in the meantime, thanks!
<sparkiegeek> ahasenack: if you hit Alt + Super + S it enables the screen reader
<jibel> popey, kylin i386would be nice
<flocculant> sil2100: no problem
<popey> jibel: on it
<jibel> downloading is slow
<valorie> oem now
<flocculant> jibel: indeed it is - got worse here in the last 30 minutes
<valorie> I missed the grub bit so went ahead and did two others
<popey> yeah, getting 1-2MB/s now
<flocculant> yea - jumped - at 93% for budgie 64 bit
<Wimpress> UbuCon ninjas are on it like a bonnet
<ahasenack> sparkiegeek: indeed it does, thanks
-queuebot:#ubuntu-release- Unapproved: mozjs24 (xenial-proposed/universe) [24.2.0-3ubuntu2 => 24.2.0-3ubuntu2.1] (ubuntugnome)
<flocculant> budgie screen reader works
<JamieBennett> Anyone tested in VMWare?
<popey> Not what you asked, but I test in VirtualBox
<flocculant> though I've turned it off - screen reader and Ozric Tentacles is a bad combo
<flocculant> and I'm doing these in kvm
<jibel> JamieBennett, I did
<jibel> in vmplayer
<JamieBennett> VMWare Fusion 8.x -> "Try Ubuntu" -> Screen Reader on -> black screen for 5 mins
<jibel> JamieBennett, how much memory did you allocate to your vm ?
<JamieBennett> (testing on Mac)
<JamieBennett> 1GB
<jibel> JamieBennett, be a bit more generous
<popey> Hah. is it 2012?
<jibel> JamieBennett, 1.5 is the minimum
<JamieBennett> Sorry, 1GB RAM
<Wimpress> You'd get away with 1GB with Ubuntu MATE ;-)
<Kamilion> i can't even get most of the flavors to boot with 1GB of ram
<JamieBennett> 20GB disk
<flocculant> lol
<Kamilion> i have to crank up to 2048MB in vmware for every new VM I create, hehe
 * JamieBennett tries again
<flocculant> Kamilion: I wondered sometime ago why xubuntu iso was like treacle - I had been testing something, and it was set at 768Mb
<flocculant> it 'worked'
 * popey gets out his Thinkpad 380XD with 32MB RAM for ISO testing..
 * flocculant doesn't work for Canonical :p
<Kamilion> I said most of the flavors
<Kamilion> xubuntu and lubuntu are the ones that generally work for 1GB or less
<Kamilion> ubuntu-studio has always been annoying in it's thirst for RAM form e :D
<ogra_> popey, ubuntu-core FTW !
<flocculant> sil2100: budgie 64bit done
<JamieBennett> jibel: problem is that VMWare defaults to 1GB
<ogra_> ah, damn, we dont have isos
<popey> ogra_: yeah, was about to mention, lack of installer...
<JamieBennett> ogra_: we have UC16 images
<popey> No. "dd" is not an installer.
<ogra_> yeah, ... that will come :)
<jibel> JamieBennett, so do virt-manager
<sil2100> i386 almost done
<ogra_> popey, as a frontend to dd ;)
<JamieBennett> ogra_: etcher.io is just a frontend to dd but it does look pretty
<jdstrand> stgraber, infinity: for completeness on a 16.04 desktop install with media-hub, mediascanner2.0, webbrowser-app and messaging-app (ie, all the new Breaks in bionic), apt-get upgrade correctly holds apparmor, apt-get dist-upgrade upgrades apparmor and removes those packages, and update-manager -d upgrades apparmor and removes those packages
 * popey guess which of the various chinese glyphs in the installer enable screen reader
<ogra_> JamieBennett, yeah, we can have the same for code one day :)
<jdstrand> stgraber, infinity: again, needs info. doesn't seem to be related to the added breaks, whatever it is
<flocculant> anything else need doing?
<ogra_> jdstrand, stgraber, perhaps some broken PPA package the user added ?
<flocculant> other than Chinese ...
<sil2100> i386 is good
<sil2100> fossfreedom: thanks for testing as well!
<jdstrand> ogra_: yeah, that is what I was thinking
<popey> Uh, screen reader didnt start on kylin i386
<popey> dunno how to poke it.
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Bionic Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Bionic Final] has been marked as ready
<tsimonq2> I'm about to leave for Milwaukee then will be on a plane to Seattle. Once Lubuntu is ready, don't wait on me to mark things as ready please.
<flocculant> tsimonq2: looks like you've got tests on all types 32/64/alternate/desktop
<JamieBennett> jibel: OK, 2GB did it, no blank screen now
<stgraber> jdstrand, ogra_: current suspicion is that the "clean" install from that user came from hetzner.de and that they messed something up... they had apparmor installed for sure but maybe hetzner didn't have ubuntu-standard on there for some reason.
<stgraber> the next LXD SRU will add a recommends on apparmor, that may help with such weird systems
<jdstrand> stgraber: nice
<ogra_> given how important apparmor got now it should probably be moved up a little from recommends
<JamieBennett> Anyone got the installer showcase to disappear during install in a live session
<popey> which iso you using JamieBennett ?
<JamieBennett> plain Ubuntu 18.04 as linked above
<JamieBennett> ah
 * sil2100 is testing kylin amd64 now
<JamieBennett> "System program problem detected"
<popey> "Insufficient RAM" :)
<jibel> JamieBennett, bug 1751252
<ubot5`> bug 1751252 in ubiquity (Ubuntu Bionic) "ubiquity crashed with signal 5 in _XEventsQueued()" [High,Triaged] https://launchpad.net/bugs/1751252
<JamieBennett> waiting for the report to be generated
<jibel> compare the stack traces once it's retraced
<JamieBennett> jibel: looks like that one, yes
<JamieBennett> jibel: old bug?
<jibel> not old, it started in bionic
<jibel> willcooke, ^^ something to investigate
<JamieBennett> jibel: old as in weeks not today
<jibel> JamieBennett, yes, early 2018
<JamieBennett> it looks like it hung trying to report the bug :(
<JamieBennett> or it is very ssssslllllllllllooooooooooooooooooowwwwwwwwww
<Kamilion> Does *ANYONE* test if TORAM=Yes works, or is that considered to be 'if it works it works, if it breaks, you get to keep both pieces' ?
<Kamilion> I'm not saying it's broken, I'm just querying if I'm the only one who actually uses/tests with it
<jibel> ubuntukylin amd64 is ok. First slide of the slideshow is not fully translated though
<JamieBennett> jibel: probably completely unrelated but did you turn screen reader off half way through install in your testing?
<jibel> JamieBennett, I didn't
<JamieBennett> jibel: OK
<popey> jibel: how did you trigger screen reader in kylin?
 * JamieBennett tries that again
<JamieBennett> alt, super, s?
<popey> didnt work on the i386 image
<jibel> popey, I didn't try the screen reader, they use their own and don't know how to activate it. But they hit the bug without it
<popey> oh ok
<Wimpress> Has anyone tried an OEM install?
<willcooke> Wimpress, I have on ubuntu desktop
<willcooke> doing free software now
<jibel> Wimpress, i did
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Bionic Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Bionic Final] has been marked as ready
<sil2100> Testing subiqity now
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Bionic Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Bionic Final] has been marked as ready
<sil2100> jibel: you testing kylin i386 now?
<sil2100> Since I saw you also did kylin
<jibel> sil2100, I did 64bit
<popey> i did kylin i386
<sil2100> popey: <3
<sil2100> jibel: <3
<willcooke> jibel, do you have a vm you can test "reuse home" on?
<jibel> willcooke, yes
<jibel> just did
<willcooke> <3
<flocculant> I assume I can go rest a bit now then :p
<cjwatson> doko: woo was an accidental manual cancellation (the canceller mistakenly thought it had hung)
<willcooke> jibel, looks like we can mark ubuntu desktop ready
<willcooke> Laney, you want the honour? ^
<jibel> Done
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Bionic Final] has been marked as ready
<jibel> \o/
<Laney> â
<popey> I also tested the oem install, worked fine.
<sil2100> fossfreedom: is budgie ready?
<sil2100> fossfreedom: can you trigger it on the isotracker?
<fossfreedom> will do - one last test 64bit, partitioning, no network - just a few minutes sil2100
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Bionic Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Bionic Final] has been marked as ready
<sil2100> fossfreedom: thanks!
<willcooke> valorie, you need any help with kubuntu 386?
<valorie> oh it would be great if someone did one
<willcooke> testers.... away
 * willcooke downloads
 * valorie is a little shaken up and need to catch my breath for a sec
<popey> any others need doing?
<acheronuk> I'm doing Kubuntu i386 oem, but can only do a VM test with that
<popey> acheronuk: what do you need me to do?
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Bionic Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Bionic Final] has been marked as ready
<willcooke> looks like kylin need some i386 tests doing too
<acheronuk> popey: probably nothing, unless you feel like doing a belt and braces re-test of i386 oem on real hardware. thanks :)
<jibel> willcooke, popey did it
<sil2100> Subiquity looks good
<sil2100> mwilson-e: ^
<popey> willcooke: TRUE
<popey> acheronuk:
<sil2100> mwilson-e: (nvm)
<jibel> popey, can you update the tracker?
<sil2100> mwilson-e: pinged wrong person! Sorry!
<sil2100> mwhudson: ^
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Bionic Final] has been updated (20180426)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Bionic Final] has been updated (20180426)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Bionic Final] has been updated (20180426)
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Bionic Final] has been updated (20180426)
<sil2100> mwhudson: will you mind if we mark subiquity as ready?
<popey> jibel: done
<jibel> thx
<mwhudson> sil2100: ask slangasek!
<sil2100> !
<sil2100> slangasek: can we mark subiquity as good? I tested amd64 on bios and uefi on kvm (so, well, limited testing)
<sil2100> But seeing the delta for these images, I'd think that's enough
<flocculant> doing a quick manual test for lubuntu
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Bionic Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Bionic Final] has been marked as ready
<mwhudson> sil2100: the point being there might be a new subiquity image coming
<sil2100> mwhudson: wha?
<sil2100> mwhudson: why? Is  there something we do not know and should?
<sil2100> mwhudson: is there a regression in the newly respun image?
<mwhudson> sil2100: https://bugs.launchpad.net/subiquity/+bug/1766980
<ubot5`> Ubuntu bug 1766980 in subiquity "Failed to import ssh key" [High,Triaged]
<mwhudson> sil2100: at least subiquity is a snap...
<sil2100> Isn't it a bit too late for a subiquity image by now? We're already late with everything
<sil2100> We didn't know about this one before it seems
<slangasek> sil2100, mwhudson: ! don't ask me either, ask the server team! :)
<sil2100> Was it linked in the isotracker?
<mwhudson> sil2100: it was but i think it's priority was misdiagnosed at the time
<mwhudson> slangasek: heh
 * slangasek tags in dpb1 
<infinity> mwhudson: Ugh.
<sil2100> eh
<sil2100> mwhudson: ok, since subiquity is a snap I guess we could live through that, but it would have to land ASAP
<sil2100> Like, 2 hours ago at best
<slangasek> infinity, sil2100, mwhudson: it's release-noted and we're not holding you up for it
<dpb1> slangasek: +1, post-release is fine
<mwhudson> oh
<dpb1> slangasek: we have updated the release-notes page already
 * mwhudson dials down the panic slightly
<sil2100> phew, thank you
<marathone> !isitout
<ubot5`> Not yet!
<slangasek> mwhudson: apologies; I thought it was important to work through characterizing the bug and come up with a plan for fixing but I didn't ever think it was realistic to have it fixed in GA and should have said
<mwhudson> slangasek: that'll learn me for being too optimistic
<flocculant> sil2100: you want to know release note place for xubuntu - it's different from beta one now we're releasing -  https://xubuntu.org/news/xubuntu-18-04-release/
<flocculant> infinity: or you ^^
<infinity> flocculant: The main release notes should link to it.
<flocculant> infinity: aah yes - it does
<flocculant> been talking to tsimonq2 - he's ok for it to be marked ready, so I did for him
<sil2100> \o/
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Bionic Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Bionic Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Bionic Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Bionic Final] has been marked as ready
<flocculant> well thanks eveyone for the fun ride this week - but I'm off up the wooden hill
<sil2100> mwhudson, slangasek: soo, with all that, should we mark subiquity as ready?
<slangasek> sil2100: you're still talking to !server team ;)
<flocculant> I've marked mine too obviously
<slangasek> sil2100: dpb1 is the authority on this
<sil2100> bluesabre: ping!
<sil2100> dpb1: ^ ;)
<flocculant> sil2100: what do you need bluesabre for?
 * dpb1 reads
<flocculant> sil2100: if it's anything Xubuntuish - I've done what needs doing afaik
 * flocculant hangs about a bit longer
<sil2100> Ah, it's marked, sorry
<sil2100> bluesabre: unping
<flocculant> :)
<flocculant> sil2100: you know I'm in the Xubuntu release team?
<flocculant> if you didn't you do now lol
<rpcruz> !isitout
<ubot5`> Not yet!
<Kamilion> i ran into that ssh key bug myself, failed to import my keys from launchpad/kamilion and github/kamilion.
<dpb1> slangasek: the jenkins jobs are all green
<slangasek> dpb1: so you're happy to release the amd64 subiquity image?
<slangasek> dpb1: the alternate server images have some un-finished tests also; should we be blocking on these?
<sil2100> ErichEickmeyer: ping! Are you around by any chance?
<valorie> Kubuntu is https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes/Kubuntu
<popey> acheronuk: confirmed oem install of 386 kubuntu worked fine :)
<sil2100> ErichEickmeyer: we did some sanity-testing of studio bionic on both arches, do you think we can proceed with marking those as ready?
<acheronuk> popey: fantastic. thanks
<flocculant> sil2100: ovenwerks (studio guy) was trying to raise erich at 21:53 - no reply in their dev channel yet
<sil2100> flocculant: thanks for the info
<flocculant> np
<flocculant> from that channel I would suspect they'd be happy to mark it *shrug*
 * flocculant really goes now - thanks to you all - happy release :)
 * Kamilion starts grabbing .torrent files to seed
<sil2100> dpb1: we good to mark subiquity as ready?
<dpb1> sil2100: we are good on subiquity
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Bionic Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Bionic Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Bionic Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Bionic Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Bionic Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Bionic Final] has been marked as ready
<Skotsj> Woo
<sil2100> dpb1: <3
<valorie> release team: <3
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Bionic Final] has been marked as ready
<krosonp> thank you guys for the hard work!
<willcooke> any kylin devs online in this channel/
<slangasek> xnox: are you available to talk s390x?
<willcooke> ?
<xnox> slangasek, yes.
<xnox> slangasek, online installs are all good.
<sil2100> acheronuk: are you around by any chance?
<slangasek> xnox: none of the tests are marked off on the iso tracker
<xnox> slangasek, and the offline one should be working fine, but i appear to be failing to point it to the offline export of the .iso to complete offline install
<xnox> (it is failing to find the kernel.... but it looks like i'm exporting the iso badly)
<acheronuk> sil2100: yep
<xnox> slangasek, i cannot mark things "ready"
<slangasek> xnox: and what are the tests you actually run, since I expect the default ones for ubuntu server don't map correctly to the s390x install paths?
<slangasek> xnox: but you can report test results and there are none reported against this image
<jibel> willcooke, it's a bit early for kylin
<sil2100> acheronuk: ah, actually, I found what I needed, nvm! Sorry to bother
<willcooke> jibel, yeah figures.  I think we can mark them ready.
<slangasek> dpb1: ^^ seems we don't yet have a confirmed good run of the s390x iso
<willcooke> jibel, sil2100 - doing one more 64bit test on Kylin
<jibel> willcooke, they didn't report any critical bug apparently but it's hard to tell everything they reported is untriaged
<dpb1> slangasek: then if we can't release the others, we need to wait for that testing.
<jibel> willcooke, I'd rather wait until they wake up.
<willcooke> jibel, we're testing and are going to call it good I think
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Bionic Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Netboot i386 [Bionic Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Netboot s390x [Bionic Final] has been marked as ready
<willcooke> loving that animated shutdownb scren
<jibel> willcooke, for example bug 1766499
<ubot5`> bug 1766499 in Ubuntu Kylin "Unable to find http://archive.ubuntukylin.com:10006/ubuntukylin bionic Release" [Undecided,New] https://launchpad.net/bugs/1766499
<sil2100> Marking studio, looks sane enough to me (and no contact with the release manager)
<sil2100> ErichEickmeyer: ^ hope you don't mind
<jibel> willcooke, they say it is not fixed and the bug suggests they cant update the system
<willcooke> jibel, that won't be affected by anything that has changed today
<slangasek> xnox: is the "failing to point to iso export" a hard failure?
<SlidingHorn> sil2100: last I saw someone report in -devel, it was working
<jibel> willcooke, which does not mean the image is good
<SlidingHorn> I'm not authorized to give a green light though
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Bionic Final] has been marked as ready
<sil2100> SlidingHorn: I guess it's enough for us (being this late)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Bionic Final] has been marked as ready
<willcooke> jibel, not iso testing though
<JamieBennett> willcooke: are you happy to release?
<willcooke> JamieBennett, yeah, Ubuntu Desktop is marked ready
 * mwhudson gets on a bus for a bit
<willcooke> JamieBennett, I think 5 more mins are everything will be marked ready
<JamieBennett> OK, we can fix any issues afterwards in .1 or even before, lets give the world Ubuntu 18.04
<jibel> willcooke, I just verified and the kylin apt source on the iso is wrong. Not sure they'll want to release with this kind of issue.
<Laney> They fix it by fixing their archive
 * JamieBennett nods
<xnox> slangasek, so, cause the time was wrong, and d-i seems to not have did ntp sync.... but with the right clock offline install works too, so s390x server is awesome.
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Bionic Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Bionic Final] has been marked as ready
<slangasek> xnox: thanks. you'll post this result to the iso tracker?
<xnox> slangasek, yes, offline test case pass.
<dpb1> OK
<dpb1> slangasek: we are a go on all required server testing
<willcooke> \m/
<slangasek> dpb1: marked ready for release
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Bionic Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Bionic Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Bionic Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Bionic Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Bionic Final] has been marked as ready
 * JamieBennett has a sigh of relief
<JamieBennett> Super proud of everyone involved, well done!
<Odd_Bloke> slangasek: infinity: Are we good to start pushing out cloud images?
<infinity> Odd_Bloke: Official release will be right around midnight London time, but if you need some lead time pushing, push away.
<willcooke> popey, Wimpress - thanks for your testing skillz
<popey> no problemo
<Odd_Bloke> infinity: Ack.
<Wimpress> Something something Cuba Libre
<Wimpress> #isitoutyet
<ogra_> ot yet!
<ogra_> +N
<ogra_> (bah)
<LocutusOfBorg> infinity, please unblock virtualbox and virtualbox-hwe whenever possible?
<infinity> LocutusOfBorg: Done.
<sil2100> Wimpress: you'll be updating https://ubuntu-mate.org/download/ to include bionic soonish, right?
<popey> it is updated
<popey> i clicked 64-bit and got a page offering bionic
<ogra_> http://i.imgur.com/YsbKHg1.gifv
<popey> free wifi in a car park of a pub apparently
<sil2100> wow, magic indeed
 * sil2100 probably had some old cache
<willcooke> thanks everyone
<davidcalle> Bravo
<sil2100> \o/
* sil2100 changed the topic of #ubuntu-release to: Released: Xenial 16.04.4, Artful 17.10, Bionic 18.04 | Archive: final freeze | Bionic Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melius malum quod cognoscis
<freehUgsz> CONGRATS
<popey> woot
<pietroalbini> \o/
<kyrofa> Congratulations everyone, thanks for all the hard work
* infinity changed the topic of #ubuntu-release to: Released: Xenial 16.04.4, Bionic 18.04 | Archive: final freeze | Bionic Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melius malum quod cognoscis
<valorie> yay!!!!!!!!!!!!!!!
<valorie> thank you to all of you super people who make this happen
<sparkiegeek> \o/
<Laney> ð
-queuebot:#ubuntu-release- Builds: 35 entries have been added, updated or disabled
<teward> yay for release!  thank you everyone for your efforts :D
<dpb1> nice work guys
<dpb1> <clapping emoji>
<dpb1> ð ð ð
<dpb1> there we go
<willcooke> ð
<willcooke> bah
<willcooke> you beat me
<dpb1> willcooke: I had emoj installed (snap) !
<knome> oh gosh emoji, i must part ;)
<willcooke> harsh
<mwhudson> haha
<Laney> ð
<dpb1> an actual emoji-ragequit.  i love it.
<sarnold> ~fifteen years ago I helped organize IRC "conferences" on a predominately spanish-speaking educational irc network ..
<sarnold> after every presentation there were *hundreds* of lines of
<sarnold> plas plas plas plas plas plas plas plas plas plas
<sarnold> in glorious colours
<sarnold> a few emojies feels a bit restrained :D
<popey> ð 
<Laney> congratulations to all the ubuntu developers on a great 18.04 LTS!!!!!!!
<sil2100> WOW
<Laney> ð 
<sil2100> infinity doesn't appreciate cute...
<sil2100> Ok, I think I go EOD to bed
<sil2100> o/
<sarnold> Laney: *thats* the stuff!
<willcooke> g'night all
<DalekSec> Laney: Haha!  Nice job.
<Laney> :D
<Laney> sarnold: That's a script I never get to use
<Laney> like the kenny one
<Laney> mfmppfppfmpmpppmffmfmmfpfmp!
<sarnold> lol
<tsimonq2> hahahaha
<valorie> are you in the airport, tsimonq2?
<tsimonq2> Boarding.
<tsimonq2> I barely made it!
<acheronuk> thank you everyone. :)
<tsimonq2> Ditto.
<tsimonq2> Nice job y'all.
<tsimonq2> ðððððððððð
<tsimonq2> Now we wait for the Calculating Camel to be announced... ð
<valorie> carrot
<valorie> gonna be carrot, I just know
<valorie> although Chthonic Cthulhu is the best I've heard so far
<infinity> valorie: I read that as Catholic Cthulhu, which would also be alright.
<valorie> lol
<valorie> + + +
 * infinity closes bionic in Launchpad.
<teward> to be honest, y'all just made me laugh with your last few messages, and I thank you for that since today's been a chaotic day that hasn't had me smile or laugh.  :)
<slangasek> teward: then I'm sure you must be looking forward to Chaotic Chinchilla
<teward> heh
<acheronuk> usually the meta on changelogs.ubuntu.com gets updated after half a day or so? was wondering when, given the lateness now?
#ubuntu-release 2018-04-27
<infinity> acheronuk: We'll give it a day or three to see if any critical upgrade bugs trickle in that we should be SRUing for before opening the flood gates.
<acheronuk> fair enough. seems sensible
<teward> infinity: et. al. who do we stab for an incorrect link on the ubuntu.com alternate downloads page?
<teward> s/stab/poke/
<slangasek> teward: which page?
<sarnold> https://www.ubuntu.com/download/alternative-downloads
<slangasek> and which link?
<sarnold> Ubuntu 18.04 Server (64-bit)   http://releases.ubuntu.com/18.04/ubuntu-18.04-server-amd64.iso.torrent
<teward> slangasek: https://www.ubuntu.com/download/alternative-downloads - ubuntu server 18.04
<teward> link should be http://releases.ubuntu.com/bionic/ubuntu-18.04-live-server-amd64.iso.torrent
<teward> it's missing -live- in there
<slangasek> k
<teward> at least, for the torrents one that sarnold poked at :P
<slangasek> not sure I can find anybody on the web team to fix it at this point; let me check with IS
<teward> slangasek: thanks.
<teward> slangasek: it's a known issue that `do-release-upgrade` alone doesn't find the 18.04 release, right?  Or is this a slow-to-update thing somewhere?
<teward> (that is, d-r-u without the `-d` arg/flag)
<sarnold> I believe that's the meta on changelogs.ubuntu.com mentioned fifteen minutes ago
<teward> ah I guess I missed that message.
<teward> my fault for having to juggle multiple windows at once :p
<ErichEickmeyer> !tell
<ErichEickmeyer> Derp, wrong channel.
<ErichEickmeyer> Dunno what happened to sil2100, but wanted to say thanks for marking it as ready. Looks good to me.
<sarnold> bed :)
<ErichEickmeyer> I'll get the release notes ready. I'm at my day job right now (and for abot the next 4 hours), so I'll get a release announcement going as soon as I can. Only thing is we need to update the release notes on the Wiki for Studio (I do not currently have access to that).
<ErichEickmeyer> sarnold: Ah.
<ErichEickmeyer> Thanks.
<Ukikie> teward: LTS users get offered at the first point release, IIRC.
<teward> that's what I thought, but wanted a confirm :p
<slangasek> teward, sarnold: fixed
<teward> slangasek: thanks.
-queuebot:#ubuntu-release- Unapproved: cloud-init (bionic-proposed/main) [18.2-14-g6d48d265-0ubuntu1 => 18.2-27-g6ef92c98-0ubuntu1] (edubuntu, ubuntu-cloud, ubuntu-server)
<Odd_Bloke> https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1767224 <-- I think this is on the wrong project, but sounds familiar
<ubot5> Launchpad bug 1767224 in grub-installer (Ubuntu) "Installer crashed on install during the grub install process" [Undecided,New]
<flocculant> xubuntu doesn't appear to have a release, or I've gone blind http://cdimages.ubuntu.com/xubuntu/releases/18.04/release/
<SlidingHorn> flocculant: it's showing up for me
<flocculant> mmm
<SlidingHorn> cdimage instead of images
<flocculant> mmm
<flocculant> well no-one else from xubuntu has said anything - so it must work somewhere
<SlidingHorn> using the singular subdomain doesn't work for you either?
<flocculant> nope
<flocculant> anyway - ignoring that - too early
<SlidingHorn>  Well I assure you it shows here! xD
<Bashing-om> flocculant: Looks good here also " xubuntu-18.04-desktop-amd64.iso2018-04-26 18:401.3G" .
<flocculant> well it doesn't show up in a vm browser
<slangasek> there are multiple frontends to cdimage.u.c and it looks like one of them must have run out of disk.  checking to see if I can fix this quickly
<flocculant> slangasek: thanks
<slangasek> ... or, multiple frontends may have run out of space.
<slangasek> I'm not immediately seeing anything in the mirror set that shouldn't be there
<flocculant> I'd assume it was local firefox until it was empty on vm too
<ErichEickmeyer> Noticing the same problem for Ubuntu Studio, btw.
<ErichEickmeyer> flocculant: Thanks for all your help, btw! :)
<slangasek> ubuntustudio is mirrored now
<ErichEickmeyer> Ah, thank you slangasek!
<slangasek> xubuntu also now mirrored
<flocculant> slangasek: thanks :)
<flocculant> ErichEickmeyer: welcome :)
<flocculant> slangasek: didn't help people telling me they could see it lol
<flocculant> anyway - back to getting ready for work
<flocculant> thanks again
<slangasek> flocculant: there's a new frontend with plenty of space, and the other two in the rotation are right at capacity for what we're throwing at them :/
<flocculant> price of popularity?
<slangasek> in this case, definitely the price of longevity
<flocculant> :)
<flocculant> anyway - thanks for looking and fixing that - have a good rest of day
<doko> is the archive already frozen? if not, woo is now built everywhere
<Ukikie> Bionic was released, mate.
-queuebot:#ubuntu-release- Unapproved: linux-meta-oem (xenial-proposed/universe) [4.13.0.1024.28 => 4.13.0.1025.30] (kernel)
-queuebot:#ubuntu-release- Unapproved: rejected linux-meta-oem [source] (xenial-proposed) [4.13.0.1025.30]
<acheronuk> morning. are we now on the normal 1 week testing for bug fixing SRUs?
<sil2100> acheronuk: yeah
<acheronuk> fair enough. thanks
<infinity> acheronuk: Yes and no.  If it's a bug that affects upgrades, *and* is trivially visually reviewable, *and* is trivially verifiable as correct, then we can fasttrack things.  Keeping upgrades broken for a week just to satisfy the rules is daft.
<sil2100> I guess that's true indeed
<infinity> sil2100: Heading into the office in a couple of minutes if anyone's there.  So, y'know, hide all the crude drawings of ritual infinity sacrifice and such.
<sil2100> infinity: no such drawings here! (/me quickly throws out some papers from the desk)
<sil2100> Besides, we only do naughty drawings here
<Mirv> good shiny morning/afternoon to everyone
<mdeslaur> congrats release team! :)
-queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.41 => 2.42] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapcraft (artful-proposed/universe) [2.41+17.10 => 2.42+17.10] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapcraft (bionic-proposed/universe) [2.41+18.04.2 => 2.42+18.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (xenial-proposed) [2.42]
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (artful-proposed) [2.42+17.10]
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (bionic-proposed) [2.42+18.04]
<marathone> !isitout
<ubot5> Yes, it's out! Party in #ubuntu-release-party :)
<marathone> !Congratulations
* Laney changed the topic of #ubuntu-release to: Released: Xenial 16.04.4, Bionic 18.04 | Archive: closed | Bionic Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melius malum quod cognoscis
<guardian> thanks for the hard work
<guardian> I've been using 18.04 for a month and it's really great
<smoser> can someone NACK my cloud-init upload in the SRU queue for bionic?  We want to fix the changelog a bit.
<apw> smoser, looking
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (bionic-proposed) [18.2-27-g6ef92c98-0ubuntu1]
<apw> smoser, ^
<smoser> gracias. /me thinks apw might enjoy NACKing smoser's uploads.
<apw> smoser, it would be inappropriate to confirm or deny such a claim :)
<j1mc> hello ubuntu-release folks, i was directed here to note a release-related issue, even though it is post-release. the release notes point to a now-dead link for the beta-2 server installer . . .
<j1mc> from the notes: `Server installer
<j1mc> The next generation Subiquity server installer, brings the comfortable live session and speedy install of Ubuntu Desktop to server users at last.
<j1mc> N.B., If you require LVM, RAID, multipath, vlans, bonds, or the ability to re-using existing partitions, you will want to continue to use the alternate installer which can be downloaded from http://cdimage.ubuntu.com/releases/18.04/beta-2/`
<j1mc> if i should file a bug for this, which project should i file the bug under?
<rbasak> dpb1: ^
<dpb1> rbasak: can you edit that page still?
<rbasak> Yes the page remains editable.
<rbasak> Just need the replacement URL.
<dpb1> rbasak: http://cdimage.ubuntu.com/ubuntu/releases/18.04/release/
<rbasak> Ah of course.
<rbasak> Sorry I assumed it was going to be a deeper link.
<rbasak> I'll fix it.
<dpb1> well, it wasn't clear to me either
<dpb1> not sure what is up with the extra release
<dpb1> anyway
<dpb1> thanks rbasak
<j1mc> it appears as though the beta-2 image would need to be re-posted
<rbasak> Done
<rbasak> j1mc: I've updated the URL to the release URL. Why would we need to re-post the beta-2 image?
<rbasak> It can just point to the release image, right?
<j1mc> apologies . . . i'm not sure why you'd need the beta 2 image. from the original release notes, it sounded like the prior version of the installer was only available in the beta-2 image.
<rbasak> Sorry for the confusion. The alternate installer is part of the release.
<j1mc> if the non-subiquity / prior-version installer is available in the final 18.04 image, then people should be okay.
<j1mc> ah, ok. that makes sense. thanks!
<dpb1> "traditional server installer", we are still working on that name
<dpb1> :)
<dpb1> I see it referred to about 3 different ways in the release notes.  ah well
<j1mc> good name choice.  thanks again for your help.  : )
-queuebot:#ubuntu-release- Unapproved: cloud-init (bionic-proposed/main) [18.2-14-g6d48d265-0ubuntu1 => 18.2-27-g6ef92c98-0ubuntu1~18.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (artful-proposed/main) [4.13.0-40.45] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.13.0-40.45~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-123.147~14.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-123.147] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (xenial-proposed/universe) [4.13.0-1025.28] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (artful-proposed) [4.13.0-40.45]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (xenial-proposed) [4.13.0-1025.28]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.13.0-40.45~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-123.147]
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-123.147~14.04.1]
-queuebot:#ubuntu-release- Unapproved: dell-recovery (bionic-proposed/universe) [1.58 => 1.59] (no packageset)
<youtah> Congrats and a huge thank you to everyone that worked on this! (goes back over to the party channel)
<bdmurray> cjwatson: Are you about? I could use some help with Bionic SRU permissions.
<cjwatson> bdmurray: for about 5min.  what's up?
<bdmurray> cjwatson: I got a 404 trying to let a package into bionic-proposed.
<bdmurray> cjwatson: I don't see a step regarding fixing permissions for ubuntu-sru in the release checklist but thought you might remember / be able to do it.
<cjwatson> bdmurray: It's in NewReleaseCycleProcess, step 13.  I think it requires ~techboard - I can't do it.
<bdmurray> cjwatson: Ah, thanks for the information
<bdmurray> cjwatson: An archive admin could accept the SRU though right?
<cjwatson> Should be able to, yeah
<cjwatson> Unless I'm misremembering, which is very possible at five to eight on a Friday :)
<cjwatson> Must run though
<gaughen> stgraber, I see that you're listed as archive admin, would you help us out with a bionic sru? ^^
<bdmurray> smoser: Or rather Grant ubuntu-sru queue admin access to bionic?
<bdmurray> stgraber: https://wiki.ubuntu.com/NewReleaseCycleProcess step 13
<bdmurray> smoser: my bad sorry ;-)
<stgraber> bdmurray: done
<bdmurray> stgraber: thanks!
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (bionic-proposed) [18.2-27-g6ef92c98-0ubuntu1~18.04.1]
<gaughen> thanks stgraber!
<marathone> !?
#ubuntu-release 2018-04-28
-queuebot:#ubuntu-release- Unapproved: snapcraft (bionic-proposed/universe) [2.42+18.04 => 2.42+18.04.1] (no packageset)
<sergiusens> slangasek if you happen to be around, mind accepting that snapcraft 2.42 I just dput into bionic? I don't know what diffences we may have but this was green for what we pushed into bionic as 2.42+18.04 as seen by https://github.com/snapcore/snapcraft/pull/2107 and this fix is now also green as seen on https://github.com/snapcore/snapcraft/pull/2110
<ubot5-ng`> snapcore bug (Pull request) 2107 in snapcraft "Release changelog for 2.42" (comments: 0) [Closed]
<ubot5-ng`> snapcore bug (Pull request) 2110 in snapcraft "tests: conditionally add python3-distutils" (comments: 0) [Open]
<LocutusOfBorg> can we still sync a bugfix from Debian?
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/virtualbox-ext-pack/+bug/1767402
<ubot5> Launchpad bug 1767402 in virtualbox-ext-pack (Ubuntu) "hash mismatch or wrong accept-license key trying to install virtualbox-ext-pack 5.2.10" [Critical,Confirmed]
<LocutusOfBorg> this is what I'm talking about
<LocutusOfBorg> just an hash changed upstream, so the downloader fails to verify it
<LocutusOfBorg> one-line fix
<ginggs> LocutusOfBorg: I think sync it, and then release team can decide whether to unblock
<LocutusOfBorg> thanks I don't want to SRU when I have 3 bugs already on both debian and Ubuntu
<LocutusOfBorg> (with different versioning=
<ginggs> you can always upload a SRU ubuntu0.18.04.1 version if it is rejected
<LocutusOfBorg> sure, but I prefer to avoid it :)
<ginggs> of course
<pietroalbini> while debugging why users weren't able to download ubuntu server from the italian loco website (ubuntu-it.org), I discovered the iso archive directory structure changed between artful and bionic
<pietroalbini> what's the difference between cdimages.u.c/.../ubuntu-18.04-server-amd64.iso and releases.u.c/.../ubuntu-18.04-live-server-amd64.iso?
<pietroalbini> (a revert to the old structure would be awesome, but I understand why you don't want to do it now ;) )
<krytarik> See the server release notes on alternate vs live images.
<pietroalbini> oh, ok, thanks
-queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (bionic-proposed/multiverse) [5.2.10-3 => 5.2.10-4] (no packageset) (sync)
<LocutusOfBorg> please accept the ext-pack <3
#ubuntu-release 2018-04-29
-queuebot:#ubuntu-release- Unapproved: ubuntu-gnome-default-settings (bionic-proposed/universe) [17.10.4 => 18.04.0] (ubuntugnome)
<LocutusOfBorg> xnox, seems somebody wants to override your upload? http://launchpadlibrarian.net/367824976/ubuntu-gnome-default-settings_17.10.4_18.04.0.diff.gz
<LocutusOfBorg> darkxst, ^^ can you please double check?
<darkxst> LocutusOfBorg, oh I didnt see xnox's upload, it wasnt in the bzr branch!
<darkxst> If some cancels the upload I will rebase with both changes
<darkxst> and upload again
<jbicha> I think xnox doesn't like to use bzr branchesâ¦
<LocutusOfBorg> you  can reupload without need of reject
<LocutusOfBorg> release team will keep the newest version (usually)
<LocutusOfBorg> who likes bzr branches?
<jbicha> it's polite to use the Vcs or at least notify the Vcs owner when you do an upload and don't want to use the Vcs
-queuebot:#ubuntu-release- Unapproved: ubuntu-gnome-default-settings (bionic-proposed/universe) [17.10.4 => 18.04.0] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-gnome-default-settings [source] (bionic-proposed) [18.04.0]
#ubuntu-release 2019-04-22
-queuebot:#ubuntu-release- New binary: r-cran-psychometric [ppc64el] (eoan-proposed/universe) [2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-psychometric [s390x] (eoan-proposed/universe) [2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-facebookgo-inject [amd64] (eoan-proposed/universe) [0.0~git20180706.f23751c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-irkernel [amd64] (eoan-proposed/universe) [0.8.15-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-gliderlabs-ssh [amd64] (eoan-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-jesseduffield-gocui [amd64] (eoan-proposed/universe) [0.3.0+git20190409.1b91467-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-psychometric [i386] (eoan-proposed/universe) [2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-icrowley-fake [amd64] (eoan-proposed/universe) [0.0~git20180203.4178557-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-psychometric [armhf] (eoan-proposed/universe) [2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-forecast [amd64] (eoan-proposed/universe) [8.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-forecast [i386] (eoan-proposed/universe) [8.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-psychometric [amd64] (eoan-proposed/universe) [2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-psychometric [arm64] (eoan-proposed/universe) [2.2-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: insighttoolkit4 (eoan-proposed/universe) [4.12.2-dfsg1-4ubuntu6 => 4.12.2-dfsg1-4ubuntu7] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-github-facebookgo-inject [amd64] (eoan-proposed) [0.0~git20180706.f23751c-1]
-queuebot:#ubuntu-release- New: accepted golang-github-icrowley-fake [amd64] (eoan-proposed) [0.0~git20180203.4178557-1]
-queuebot:#ubuntu-release- New: accepted r-cran-forecast [amd64] (eoan-proposed) [8.5-1]
-queuebot:#ubuntu-release- New: accepted r-cran-irkernel [amd64] (eoan-proposed) [0.8.15-1]
-queuebot:#ubuntu-release- New: accepted r-cran-psychometric [arm64] (eoan-proposed) [2.2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-psychometric [i386] (eoan-proposed) [2.2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-psychometric [s390x] (eoan-proposed) [2.2-1]
-queuebot:#ubuntu-release- New: accepted golang-github-gliderlabs-ssh [amd64] (eoan-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted r-cran-forecast [i386] (eoan-proposed) [8.5-1]
-queuebot:#ubuntu-release- New: accepted r-cran-psychometric [armhf] (eoan-proposed) [2.2-1]
-queuebot:#ubuntu-release- New: accepted golang-github-jesseduffield-gocui [amd64] (eoan-proposed) [0.3.0+git20190409.1b91467-1]
-queuebot:#ubuntu-release- New: accepted r-cran-psychometric [ppc64el] (eoan-proposed) [2.2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-psychometric [amd64] (eoan-proposed) [2.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted landscape-client [source] (eoan-proposed) [18.01-0ubuntu8]
-queuebot:#ubuntu-release- Unapproved: fakechroot (eoan-proposed/universe) [2.19-3ubuntu2 => 2.19-3.2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted fakechroot [sync] (eoan-proposed) [2.19-3.2]
-queuebot:#ubuntu-release- Unapproved: accepted lighttpd [source] (eoan-proposed) [1.4.53-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted calamares-settings-ubuntu [source] (eoan-proposed) [1:19.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted gringo [sync] (eoan-proposed) [5.3.0-10]
-queuebot:#ubuntu-release- Unapproved: accepted kylin-nm [source] (eoan-proposed) [1.0.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-8 [source] (eoan-proposed) [1:8-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted php-zeta-unit-test [sync] (eoan-proposed) [1.1.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted rails [sync] (eoan-proposed) [2:5.2.2.1+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: accepted dde-qt-dbus-factory [source] (eoan-proposed) [1.1.0-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-7 [source] (eoan-proposed) [1:7.0.1-8ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mozc [source] (eoan-proposed) [2.23.2815.102+dfsg-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted symfony [sync] (eoan-proposed) [3.4.22+dfsg-2]
-queuebot:#ubuntu-release- Unapproved: accepted insighttoolkit4 [source] (eoan-proposed) [4.12.2-dfsg1-4ubuntu7]
-queuebot:#ubuntu-release- Unapproved: accepted ppp [source] (eoan-proposed) [2.4.7-2+4.1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted lubuntu-meta [source] (eoan-proposed) [19.10.1]
* infinity changed the topic of #ubuntu-release to: Released: Bionic 18.04.2, Disco 19.04 | Archive: Open | Eoan Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melius malum quod cognoscis
<infinity> vorlon: Did you re-enable daily builds on nusakan?
<infinity> vorlon: If it was you, you didn't create an Eoan Daily milestone on the tracker first (done now).
<infinity> I mean, if it was someone else, same complaint. :P
<infinity> vorlon: Anyhow, checklist-wise, we're done up to and including #40 (though I suspect some of 36 might still need doing for some flavours?).
<infinity> vorlon: No idea if you're working tomorrow, but I'm not.  I will be around to look in on things to check for major fires, though.
<infinity> doko: Did you want the honors of sending the usual "Hey guys, upload all the things now" email?  Archive is open, and first auto-sync run is completed (and even half migrated), so any time is fine.
<acheronuk> oh, we are are off. :)
-queuebot:#ubuntu-release- Unapproved: distro-info-data (trusty-security/main) [0.18ubuntu0.12 => 0.18ubuntu0.12] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: distro-info-data (bionic-security/main) [0.37ubuntu0.4 => 0.37ubuntu0.4] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: distro-info-data (xenial-security/main) [0.28ubuntu0.11 => 0.28ubuntu0.11] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: distro-info-data (cosmic-security/main) [0.38ubuntu0.3 => 0.38ubuntu0.3] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [sync] (trusty-security) [0.18ubuntu0.12]
-queuebot:#ubuntu-release- Unapproved: distro-info-data (disco-security/main) [0.39ubuntu2 => 0.39ubuntu2] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [sync] (xenial-security) [0.28ubuntu0.11]
-queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [sync] (bionic-security) [0.37ubuntu0.4]
-queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [sync] (disco-security) [0.39ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [sync] (cosmic-security) [0.38ubuntu0.3]
<acheronuk> I assume is someone adding eaon to the templates in python-apt in the next few days?
<infinity> juliank generally gets to that fairly quickly.
<infinity> Also, it's eoan.
<acheronuk> right.
<infinity> We had to have it in big letters on a whiteboard in the office when we were doing the opening so we wouldn't get it wrong. :P
<acheronuk> Yeah, I can get that. My fingers do not want to get it right!
<juliank> acheronuk: infinity will do that very soon
<infinity> juliank: I will?
<infinity> Or s/: infinity/, infinity:/ ? :)
<juliank> I will
<juliank> Seems something got messed up while typing
<juliank> acheronuk, infinity: Fixed in https://launchpad.net/ubuntu/+source/python-apt/1.9.0~alpha0~ubuntu1 - but we really should work on moving this to distro-info-data this cycle
<juliank> odd version numbers, again, but they'll make sense eventually
<acheronuk> juliank: thannks :)
<ddstreet> infinity as you're the sru vanguard today (assuming sil2100 is out for the holiday), can you find time to approve the b/c openldap upload plz?  the (same) openldap upload to cosmic was already accepted and is almost at 7 days in -proposed now
<infinity> ddstreet: I'm out for the day too.  I might look at queues at some point, but I wouldn't count on it.
<ddstreet> ah ok...thnx...
<infinity> Also, 'b/c'?
<infinity> Did you just mean b?
<ddstreet> infinity sorry, b/x
<ddstreet> just used to typing b/c so often
-queuebot:#ubuntu-release- Unapproved: accepted openldap [source] (bionic-proposed) [2.4.45+dfsg-1ubuntu1.2]
<infinity> ddstreet: Has someone tested and confirmed that this will behave exactly the same on xenial as it does on bionic/cosmic?
<infinity> I guess I don't see why it wouldn't (beyond systemd being two years older), so I'll accept it and you can decide when verifying if it works. :P
 * infinity goes back to not being here.
-queuebot:#ubuntu-release- Unapproved: accepted openldap [source] (xenial-proposed) [2.4.42+dfsg-2ubuntu3.5]
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (trusty-proposed/universe) [20190124+dfsg1-0ubuntu1~14.04.0 => 20190315-0ubuntu1~14.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (bionic-proposed/universe) [20190124+dfsg1-0ubuntu1~18.04.0 => 20190315-0ubuntu1~18.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (disco-proposed/main) [20190124+dfsg1-0ubuntu1 => 20190315-0ubuntu1~19.04.0] (core, ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (cosmic-proposed/main) [20190124+dfsg1-0ubuntu1~18.10.0 => 20190315-0ubuntu1~18.10.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (xenial-proposed/universe) [20190124+dfsg1-0ubuntu1~16.04.0 => 20190315-0ubuntu1~16.04.0] (ubuntu-cloud)
<vorlon> infinity: it was me; you said image builds were ready to go after I did the db@limequat thing, so I did that - only now finding in the checklist where it lists that there are other things to do first
<vorlon> rcj: are you taking care of stable/ubuntu-19.04 for cloud snaps?
<vorlon> rcj: er, ubuntu-19.10
<vorlon> stgraber: is stable/ubuntu-19.10 channel ready to go for lxd?
<stgraber> Yes
<stgraber> Created it a week ago
<rcj> I think EANIMAL is defined in /usr/include/asm-generic/errno.h ;)
<vorlon> stgraber: excellent
<rcj> vorlon: good reminder, we will
<infinity> vorlon: Yeah, I forgot that the db@limequat thing doesn't create the daily milestone until I looked and there wasn't one yet. :P
<LocutusOfBorg> hello, can we please kick this package out from eoan? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911832
<ubot5`> Debian bug 911832 in src:php-symfony-polyfill "php-symfony-polyfill: ftbfs since php 7.3 is the default" [Serious,Open]
<infinity> LocutusOfBorg: Gone.
<teward> is Eoan open for uploading things now?  Got an NGINX package update to push in at some point this week :P
<ahasenack> hm, #topic seems to say it's open
<vorlon> launchpad.net/ubuntu/eoan also says that
<teward> ah, good.  i'll be pushing that update then soon (tm)
<tsimonq2> Er, reject the newlib upload coming into Bionic.
<tsimonq2> I pulled the wrong source.
<tsimonq2> Sorry.
-queuebot:#ubuntu-release- Unapproved: newlib (bionic-proposed/universe) [2.4.0.20160527-3 => 3.1.0.20181231-1build1] (no packageset)
<tsimonq2> To clarify, 2.4.0.20160527-3build1 is the intended upload, please reject 3.1.0.20181231-1build1.
-queuebot:#ubuntu-release- Unapproved: newlib (bionic-proposed/universe) [2.4.0.20160527-3 => 2.4.0.20160527-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mozc (xenial-proposed/main) [2.17.2116.102+gitfd0f5b34+dfsg-1ubuntu1.1 => 2.17.2116.102+gitfd0f5b34+dfsg-1ubuntu1.2] (input-methods, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rejected newlib [source] (bionic-proposed) [3.1.0.20181231-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted newlib [source] (bionic-proposed) [2.4.0.20160527-3build1]
<LocutusOfBorg> thanks infinity
-queuebot:#ubuntu-release- Unapproved: gnupg2 (cosmic-proposed/main) [2.2.8-3ubuntu1.1 => 2.2.8-3ubuntu1.2] (core)
-queuebot:#ubuntu-release- Unapproved: gnupg2 (bionic-proposed/main) [2.2.4-1ubuntu1.2 => 2.2.4-1ubuntu1.3] (core)
-queuebot:#ubuntu-release- Unapproved: gnupg2 (xenial-proposed/main) [2.1.11-6ubuntu2.1 => 2.1.11-6ubuntu2.2] (core)
-queuebot:#ubuntu-release- Unapproved: gnupg (xenial-proposed/main) [1.4.20-1ubuntu3.3 => 1.4.20-1ubuntu3.4] (core)
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (cosmic-proposed/main) [0.131ubuntu15.1 => 0.131ubuntu15.2] (core)
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (bionic-proposed/main) [0.130ubuntu3.7 => 0.130ubuntu3.8] (core)
<vorlon> tsimonq2: do you want to steal TIL back from me on lxpanel?
<vorlon> coreycb: python-formencode still on your radar for merging?
<tsimonq2> vorlon: I don't particularly care.
<tsimonq2> (lxpanel)
#ubuntu-release 2019-04-23
-queuebot:#ubuntu-release- New binary: nginx [amd64] (eoan-proposed/main) [1.15.12-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: nginx [s390x] (eoan-proposed/main) [1.15.12-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: nginx [i386] (eoan-proposed/main) [1.15.12-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: nginx [ppc64el] (eoan-proposed/main) [1.15.12-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: nginx [arm64] (eoan-proposed/main) [1.15.12-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: nginx [armhf] (eoan-proposed/main) [1.15.12-0ubuntu1] (ubuntu-server)
<vorlon> tsimonq2: are you sure you don't care? :)  maybe lxpanel should be a sync again now that it's no longer seeded anywhere, hmm
-queuebot:#ubuntu-release- Unapproved: mdadm (bionic-proposed/main) [4.1~rc1-3~ubuntu18.04.1 => 4.1~rc1-3~ubuntu18.04.2] (core)
-queuebot:#ubuntu-release- Unapproved: mdadm (cosmic-proposed/main) [4.1~rc1-4ubuntu1 => 4.1~rc1-4ubuntu1.1] (core)
<ddstreet> oSoMoN network-manager has been in bionic-proposed for 122 days...can you find time to verify and get it pushed to -updates please?
<oSoMoN> ddstreet, that's on tkamppeter's plate now, and he marked the SRU bug (bug #1809132) verified a month ago
<ubot5`> bug 1809132 in network-manager (Ubuntu Bionic) "Updated bionic to the current 1.10 stable version" [Low,Fix committed] https://launchpad.net/bugs/1809132
<ddstreet> oSoMoN i think it's held up by lp #1754671
<ubot5`> Launchpad bug 1754671 in network-manager (Ubuntu Bionic) "Full-tunnel VPN DNS leakage regression" [High,Fix committed] https://launchpad.net/bugs/1754671
<oSoMoN> indeed
<oSoMoN> tkamppeter, can you handle that one? ^
<ddstreet> is someone else verifying that?
<ddstreet> thnx!
<seb128> ddstreet, oSoMoN, we started an email discussion about that some days ago in desktop, the issue is that our team lacks knowledge around those topics so we would need help testing that side of the changes/verifying they are correct
<seb128> vorlon seemed to have doubts about it
<seb128> we probably need foundations or someone who understands that topic enough to help
<oSoMoN> ha, I haven't gone through all my e-mail backlog yet
<tkamppeter> oSoMoN, according to comment #24 there seems to be an upstream fix which is too complex for an SRU.
<tkamppeter> Who at Foundation one should contact for such a thing.
<juliank> hmm, so we diverged from Debian in renaming libsrecord0 to libsrecord0v5
<juliank> Debian had binNMUs
<juliank> so gotta figure out if the binNMU happened before or after the g++ abi transition
<rbalint> RAOF, bdmurray could you please accept lxd to cosmic-proposed? do-release-upgrade is broken on wsl until the package update is out
-queuebot:#ubuntu-release- Unapproved: qemu (xenial-proposed/main) [1:2.5+dfsg-5ubuntu10.36 => 1:2.5+dfsg-5ubuntu10.37] (ubuntu-server, virt)
<ddstreet> sil2100 if you have time for this qemu, it's a small workaround fix needed only for xenial, that does have moderate urgency for a customer; cpaelzer is ok with the workaround based on previous discussion with him (tho he can correct me if needed :)
<cpaelzer> ddstreet: acked the MP with some comments
<cpaelzer> I see the fight between deadlines to fix it and my preference to have some more time&tests on it in -proposed
<cpaelzer> but getting it there certainly seems to be the right next step to me
<ddstreet> thnx!  and once it's in -proposed, we should be able to provide a hotfix to reduce the urgency
<juliank> So, um, Debian did not follow the srecord gcc ABI rename, and stayed with libsrecord0 instead of libsrecord0v5. It's the only change we have, so um, I
<juliank> feel like maybe we should just revert it now
<juliank> There are no rdeps outside its source package, it's in universe, and it seems pointless work
<Laney> do it
<Laney> we basically mass scripted those changes, so ended up with a few that Debian didn't do
<juliank> ack
<juliank> synced
-queuebot:#ubuntu-release- New binary: srecord [s390x] (eoan-proposed/universe) [1.64-1] (no packageset)
-queuebot:#ubuntu-release- New binary: srecord [i386] (eoan-proposed/universe) [1.64-1] (no packageset)
-queuebot:#ubuntu-release- New binary: srecord [ppc64el] (eoan-proposed/universe) [1.64-1] (no packageset)
-queuebot:#ubuntu-release- New binary: srecord [amd64] (eoan-proposed/universe) [1.64-1] (no packageset)
-queuebot:#ubuntu-release- New binary: srecord [armhf] (eoan-proposed/universe) [1.64-1] (no packageset)
<juliank> I was looking at getting libgnome-keyring removed, seems rdeps are libgnomeui (and its rdep is linsmith)
<juliank> they are not in Debian testing, so prime candidate for removal
-queuebot:#ubuntu-release- New binary: srecord [arm64] (eoan-proposed/universe) [1.64-1] (no packageset)
<infinity> juliank: Wait, but you can't just sync that...
<juliank> infinity: No?
<infinity> juliank: Cause it needs all the control magic to takeover for the 0v5 one.
<juliank> hmm
<infinity> Basically, the exact inverse of what 0v5 does.
<infinity> Or, just merge instead of syncing and keep the delta fiveever.
<juliank> So, it is safe to sync, as libsrecord0v5 Conflicts with libsrecord0
<juliank> it might trick apt into the wrong decision
<juliank> but we might get away with it even if it's wrong
<infinity> update-manager won't upgrade that.  It'll poop and go partial.
<infinity> Since the Conflicts/Replaces is in the other direction.
<juliank> nice
<infinity> The path of least resistance would have been to just beg Debian to do the (pointless?) ABI change. :P
<infinity> Of course, someone should have done that 4 years ago.
<infinity> Oh!
<infinity> It's orphaned and QA maintained!
<infinity> juliank: You can just upload our delta to Debian and be done with it. :P
<infinity> Also, it's been uploaded once in the last 5 years, people clearly care deeply about it.
<juliank> I mostly care about fixing the last few libgcrypt11-dev build-depends to say libgcrypt20-dev, and hence stumpled upon this
 * infinity nods.
<infinity> I'd definitely just go for pushing our delta to Debian and double-uploading that to Ubuntu so you don't have to wait on NEW, but that's me.
<juliank> I asked Debian RT, and they mentioned debian bug 791295 - it was a conscious decision not to do the rename
<ubot5`> Debian bug 791295 in src:srecord "srecord: library transition may be needed when GCC 5 is the default" [Important,Open] http://bugs.debian.org/791295
<juliank> Although, the Depends never happened
<juliank> or well Breaks: srecord (<< version that expects pre-gcc5 things)
<infinity> Yeah, also, the "screw third-party software" stance feels wrong to me.
<infinity> No one said the ABI break wasn't real, just that they didn't care because no archive rdeps.
<infinity> But also, it's been orphaned since then, and I figure QA can do whatever they please in the interest of easing cross-distro compat.
<infinity> My two cents.
<juliank> In any case, it's final buster freeze
<infinity> Other option is a QA upload that just adds a Breaks/Conflicts against the 0v5 lib.
<infinity> So, no NEW processing, but we can sync that and it would Just Work.
<infinity> Sure, it might not migrate before release, not really an issue.
<infinity> Since it's not broken in Debian.
<infinity> And, like I said, one upload in 5 years doesn't point to a rapidly-changing history that you'd be blocking an RC upload. :P
<juliank> can do that later, but I don't want to block uploads to buster via unstable
<infinity> Or slap it at experimental, but then you'd have to remember later, which sucks.
<juliank> not sure how far we'll need that, I guess we still need it in 20.04?
<infinity> Anyhow, I don't think we should let this version in eoan-proposed.  COncur?
<infinity> Yeah, we could just have a local delta to forcefully swap back and drop it post-20.04
<infinity> Bi-directional replaces is all manner of sketchy in dpkg, unfortunately, but the odds of interrupted upgrades and rollbacks are slim enough that meh.
<infinity> Oh, but it's C/R, not R, so it's not actually doing overwrites.
<juliank> infinity: The Replaces are not a problem I think, as they're used with Conflicts and not Breaks, so we do not use them in the "replaces files" since
<infinity> Just hinting.
<juliank> yes
<infinity> I really wish someone had decided that a richer syntax was smarter than magic pair/triplet hints.
<juliank> I filed bug 1825972 for the libgnome-keyring, libgnomeui, linsmith removal
<ubot5`> bug 1825972 in linsmith (Ubuntu) "Remove libgnome-keyring, libgnomeui, linsmith from eoan" [Undecided,New] https://launchpad.net/bugs/1825972
<juliank> not sure if there's anything else to do - the packages are still in unstable after all, so would they sync again?
<infinity> Not at the same versions.
<infinity> But new ones would.
<juliank> that should be fine I guess
-queuebot:#ubuntu-release- New binary: srecord [amd64] (eoan-proposed/universe) [1.64-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: srecord [ppc64el] (eoan-proposed/universe) [1.64-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: srecord [i386] (eoan-proposed/universe) [1.64-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: srecord [s390x] (eoan-proposed/universe) [1.64-1ubuntu1] (no packageset)
<juliank> I feel like the rest of the week I'Ã¶Ã¶ mainly be hitting autopkgtest retry buttons
<infinity> Yeah, I did that a LOT over the weekend.
<infinity> I'm technically not here, but I decided to do a favour for Brian with precise-esm distro-into stuff.
<juliank> Also, I guess I'll be upgrading to eoan later today
<Laney> any particular problem?
<infinity> Laney: With autopkgtest?
<Laney> ye
<infinity> Laney: The biggest problem I had was the usual armhf-no-networky issue.
<juliank> More like I have a few tests failing with missing eoan in python-apt distro data
<juliank> and gotta retry those
<Laney> ahhh
-queuebot:#ubuntu-release- New binary: srecord [arm64] (eoan-proposed/universe) [1.64-1ubuntu1] (no packageset)
<Laney> what the F is that problem about
<juliank> but also, quite a few in progress
<Laney> last I heard Steve was looking into it I think, but the ball is probably on the floor
<infinity> Laney: I genuinely don't know.  I want to say it *seems* to be related to load, but that could just be confirmation bias because more tests == more failures.
<infinity> I'm about 100% sure it'd go away if we put the effort into making armhf a first-class citizen with kvm instead of lxd, but that's also a huge draw on already limited compute resources (plus man hours we don't really have)
-queuebot:#ubuntu-release- New binary: srecord [armhf] (eoan-proposed/universe) [1.64-1ubuntu1] (no packageset)
<Laney> right, I've never seen this particular problem on VMs
<infinity> But "blame lxd" also isn't a useful diagnosis.
<Laney> we did reconfigure armhf with StÃ©phane's recommended settings
<Laney> but that didn't completely fix the problem
<infinity> If the plan of record is to ship armhf with 20.04, *and* we get new arm64 kit to let scalingstack breathe, I think I'd like to give a stab at making armhf kvmish.
<infinity> But until A is decided, it's a waste of our time, and until B is sorted, it's a waste of compute we don't have.
-queuebot:#ubuntu-release- Unapproved: ubuntu-fan (xenial-proposed/main) [0.12.8~16.04.2 => 0.12.8~16.04.3] (no packageset)
 * juliank is always like "did I break software-properties?" when reading excuses, but then remembers it only failed because it needs new python-apt
-queuebot:#ubuntu-release- New: rejected srecord [amd64] (eoan-proposed) [1.64-1]
-queuebot:#ubuntu-release- New: rejected srecord [armhf] (eoan-proposed) [1.64-1]
-queuebot:#ubuntu-release- New: rejected srecord [ppc64el] (eoan-proposed) [1.64-1]
<infinity> Yeah, the first week while everything that knows about new names is migrating is "fun".
-queuebot:#ubuntu-release- New: rejected srecord [arm64] (eoan-proposed) [1.64-1]
-queuebot:#ubuntu-release- New: rejected srecord [s390x] (eoan-proposed) [1.64-1]
-queuebot:#ubuntu-release- New: rejected srecord [i386] (eoan-proposed) [1.64-1]
<infinity> All the things that fail because lxd/docker images don't exist yet is also irritating.
-queuebot:#ubuntu-release- New: accepted srecord [amd64] (eoan-proposed) [1.64-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted srecord [armhf] (eoan-proposed) [1.64-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted srecord [ppc64el] (eoan-proposed) [1.64-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted srecord [arm64] (eoan-proposed) [1.64-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted srecord [s390x] (eoan-proposed) [1.64-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted srecord [i386] (eoan-proposed) [1.64-1ubuntu1]
 * juliank is always like "did I break software-properties after all?" when reading excuses, but then remembers it only failed because it needs new python-apt
<infinity> Uh oh, I think juliank is stuck in a loop.
<infinity> Can we reboot him?
 * juliank is always like "did I break software-properties after all?" when reading excuses, but then remembers it only failed because it needs new python-apt
<juliank> goto out;
<juliank> should build a "could not find a distribution template for Ubuntu/" auto-retry
<juliank> I did retry crash and software-properties now, in case anyone is wondering
<infinity> I'm staying away from that stack, it's all yours.
<ddstreet> juliank btw i have a day or two this week that i'll update s-p to handle private ppas, but as part of that i'm adding python3-launchpadlib as a dep; i assume there is no issue with that?
<ddstreet> i assume s-p doesn't currently use s-p because it predates that lib...
<ddstreet> er, doesn't currently use launchpadlib, i mean
<infinity> s-p?
<ddstreet> software-properties
<infinity> Oh, sof.. RIght.
<infinity> It predates lplib by a couple of years.
<ddstreet> yep
<juliank> so, it will pull it into a couple more tasks live server and cloud images
<infinity> OTOH, depending on your goals, sometimes just smacking the API via direct HTTP is less error prone than pulling in lplib for the fully integrated API experience.
<infinity> I mean, if you're in a position to know the URL you want.
<ddstreet> well private ppas require authentication with lp
<infinity> Oh, private.  Right.  Fair enough.
<ddstreet> it's really waaaaaaaay easier using lplib
 * infinity nods.
<juliank> so this might blow up minimal images a bit I guess?
<ddstreet> once i have something to look at, i'll open a MP for your review
<juliank> but I don't really see any big issues
 * apw waits for his cve git repo to update
<infinity> Minimal images shouldn't have software-properties.
<apw> (and apprently for his irc client to switch buffers successfully, sigh)
<infinity> It's in desktop/server/cloud, nothing lower.
<juliank> ok, well, that makes sense
<infinity> And lplib is already in most of the desktops, so this would just add it to a couple more and server, which seems fine.
<juliank> ack
<infinity> Speaking of that stack, sort of, it's a real shame we never managed to maintain update-manager in Debian in a reasonable fashion.
<infinity> Honestly, when I first installed Ubuntu a few minutes after getting the job, update-manager immediately impressed me as a "oh, this is actually a Linux I could install on my mom's computer".
<infinity> It's the little things.
<juliank> Debian's stuck with PackageKit offline upgrades
<infinity> I mean, I don't mind that solution (for my parents) either.  While I've never seen it, I assume it plays similarly to the "must reboot to update" Windows Updates?
<infinity> Blank screen, progress bar, angry message about not cutting power?
<juliank> infinity: Well, it installs _after_ reboot
<infinity> But in 2004/2005, update-manager was so much more slick than any other option.
<infinity> juliank: WIndows Updates "can't update locked files" updates happen post-reboot too.
<juliank> that's the key difference to Windows which installs before reboot and keeps you waiting, which is nice if you are low on power
<infinity> Usually, you'll see it split in 3.  Stuff it can do online, stuff it can do on shutdown, stuff it does after reboot, and I'm not really sure where the lines are drawn.
<juliank> I dropped update-manager in Debian to get rid of aptdaemon, as that ended up unmaintained, and packagekit became usable
<infinity> I'm glad we're not that messy. :P
<juliank> A lot of things would be a lot easier if we did offline upgrades, at least for release upgrades
<infinity> Certainly less error prone in some cases, I don't disagree.
<infinity> And I think for dist-upgrades, it's worth examining.
<infinity> I mean, not the apt dist-upgrade case, but the "friendly" case.
<juliank> ack
<infinity> I'm also wondering if we shouldn't paper over trigger loops with a log parses that just retries --configure and continues the upgrade.
<infinity> Retry limit of 3 or something, but once would usually do it.
<infinity> s/parses/parser/
<infinity> A loop break at the dpkg level with a --force option we enable only for release upgrades could also work.
<infinity> Like Debian used to --force-overwrite back in the bad old days.
-queuebot:#ubuntu-release- Unapproved: console-setup (bionic-proposed/main) [1.178ubuntu2.8 => 1.178ubuntu2.9] (core)
-queuebot:#ubuntu-release- Unapproved: console-setup (cosmic-proposed/main) [1.178ubuntu9.1 => 1.178ubuntu9.2] (core)
-queuebot:#ubuntu-release- Unapproved: console-setup (disco-proposed/main) [1.178ubuntu12 => 1.178ubuntu12.1] (core)
<jdstrand> hey, when does the dev release typically show up in https://cloud-images.ubuntu.com/<name> and also for wherever lxc fetches stuff (lxc launch ubuntu-daily:<name>/<arch>)? I ask cause the libseccomp upload is failing autopkgtests in part because of the latter (and I'm trying to test locally for the former and noticed autopkgtest-buildvm-ubuntu-cloud fails (I'm going to create disco and upgrade,
<jdstrand> so no biggie))
<jdstrand> stgraber: hey, you may know the 2nd part of that ^
<xnox> jdstrand, so, we need updated distro-info-data and then cpc to kick those build off.
<stgraber> ubuntu-daily is cloud-images so once a cloud image gets published you should be good
<xnox> jdstrand, but we can't have distro-info-data until EANIMAL is revealed.
<xnox> jdstrand, so ping mark
<jdstrand> heh
<jdstrand> stgraber: thanks
<xnox> jdstrand, for ADT testing we "fake" devel images, by manually copying disco -> eoan, and sed sources.list, apt update, and hope for the best ;-)
<jdstrand> xnox: so we typically just wait until that happens before a thing that needs them migrates?
<xnox> jdstrand, imho, if $ ubuntu-distro-info --devel gives errors, one should fallback and use --stable
<xnox> jdstrand, something like that, yes.
<jdstrand> ok, thanks
<xnox> jdstrand, or ask release team / sru team to override, skiptest, mark bad test, etc.
<stgraber> images:ubuntu/eoan should work though as those are generated by the LXD team and they're showing up as green on our side
<jdstrand> stgraber: + lxc launch ubuntu-daily:eoan/amd64 docker -c security.nesting=true
<jdstrand> Error: Failed container creation: The requested image couldn't be found
<jdstrand> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/d/docker.io/20190423_082805_6dc5d@/log.gz
<jdstrand> stgraber: maybe it was just a timing thing?
<xnox> jdstrand, images: != ubuntu-daily
<xnox> jdstrand, images: != ubuntu-daily:
<stgraber> jdstrand: lxc launch images:ubuntu/eoan/amd64
<jdstrand> that's fair. note I was pretty clear that I didn't know what was being used ;)
<xnox> =)))))
<jdstrand> stgraber: ok, sure. I wasn't really planning on touching docker.io but I can. are you saying this is a more robust invocation in general?
<jdstrand> stgraber: actually, while I have you. did mdeslaur talk to you about libseccomp 2.4.1? also, do you use golang-seccomp?
<stgraber> jdstrand: I wouldn't say more robust as the CPC generated images (ubuntu: and ubuntu-daily:) do tend to be more tested. But "images:" is generated by a much simpler build process (same as we use for all other LXD distro images) and so we tend to have the images for the new development release the day the name is announced whereas the CPC images can take over a week because of various dependencies
<stgraber> jdstrand: we don't, no. LXD itself generates a liblxc plaintext policy whihc is then converted by liblxc (C library) using libseccomp
<jdstrand> stgraber: cool. cause it had a bug in it you'd like want if you used it.
<jdstrand> stgraber: as for 2.4.1, not sure if you saw, but db was reworked by upstream and as part of that they fixed a CVE wrt arg filtering. we are looking to upgrade to 2.4.1 in all releases
<stgraber> jdstrand: ah, interesting. I don't believe we actively use arg filtering anywhere now so unlikely to be a big deal for us, but the snap will pick it up once 16.04 has it.
<jdstrand> stgraber: iirc, you have a significant number of tests and it would be great if you could rung the libseccomp 2.4.1 packages through them
<jdstrand> run*
<stgraber> jdstrand: we intend to start shipping our own copy of libseccomp in the snap very soon too as we'll need support for userspace mediation once we get those landed upstream
<jdstrand> stgraber: we're hoping for testing prior to pushing to the archive
<jdstrand> stgraber: I highly suggest looking at 2.4.1
<stgraber> jdstrand: yep, do you have those in -proposed? I can manually update our test runners for it (bionic)
<jdstrand> stgraber: they aren't in proposed. let me ask mdeslaur what he thinks about pocket copying them
<jdstrand> mdeslaur: stgraber is willing to testing lxd against our libseccomp updates. what do you think about them going to -proposed?
<jdstrand> s/testing/test/
<mdeslaur> jdstrand: I'm still unsure of the approach, so I'd rather we test lxd before sending them to -proposed
<mdeslaur> but if snap and lxd work, 2.4.1 in proposed sounds good
<mdeslaur> jdstrand: ^
<jdstrand> I'll be testing snapd today (so far it has been great)
<jdstrand> stgraber: would our public security-proposed ppa work for you? something else? ^
<stgraber> jdstrand: that's fine, I can just manually wget + dpkg install them
<jdstrand> stgraber: ok. I'll copy them over. gimme a sec
<jdstrand> mdeslaur: jeez we have access to a lot of ppas
<mdeslaur> jdstrand: wait a sec
<mdeslaur> jdstrand: I didn't put them there so people don't install them
<mdeslaur> jdstrand: give stgraber access to our private ppa instead
<jdstrand> I'll just scp them to people
<infinity> xnox: Err, wat?
<xnox> infinity, which bit? =)
<infinity> 06:39 < xnox> jdstrand, but we can't have distro-info-data until EANIMAL is revealed.
<jdstrand> mdeslaur: we have people that regularly run our security proposed ppa?
<infinity> xnox: distro-info-data is updated in every release going back to precise.
<xnox> infinity, i might be wrong, but we normally update distro-info-data with both adjective & animal. Or are you planning to update it with adjective alone; and then later sru the animal name?
<infinity> xnox: If anything's blocking cloud builds, it's not us.
<mdeslaur> jdstrand: yeah, we do...which is why I try to upload stuff there...but if we don't go forward with 2.4.1, they will get stuck
<infinity> xnox: No "planning" at all, it's done.  Days ago.
<jdstrand> stgraber: I'm stepping into a meeting in 2 minutes. I'll ping you. thanks again
<xnox> infinity, ok.
<jdstrand> mdeslaur: I see. I'm pretty sure we are going to go forward. 2.3 is rather terrible wrt arg filtering I discovered
<xnox> debootstrap is done too. Let me see where the eoan images are then
<jdstrand> mdeslaur: but yes, must test :)
<infinity> xnox: To be fair, jerff was waiting on a new-new distro-info for other reasons (ESM madness), but I got that all fixed up, so they can upgrade that machine.
<xnox> true
<xnox> but i don't even see cpc-jenkins jobs to attempt building 19.10 which is way pre jerff bits.
<xnox> jdstrand, infinity - pinged cpc team about it.
<jdstrand> thanks
<jdstrand> stgraber: fyi, http://people.canonical.com/~jamie/libseccomp/
-queuebot:#ubuntu-release- Unapproved: debootstrap (disco-proposed/main) [1.0.112ubuntu1 => 1.0.112ubuntu1.1] (core)
-queuebot:#ubuntu-release- Unapproved: debootstrap (cosmic-proposed/main) [1.0.108ubuntu1.1 => 1.0.108ubuntu1.2] (core)
-queuebot:#ubuntu-release- Unapproved: debootstrap (bionic-proposed/main) [1.0.95ubuntu0.3 => 1.0.95ubuntu0.4] (core)
-queuebot:#ubuntu-release- Unapproved: debootstrap (xenial-proposed/main) [1.0.78+nmu1ubuntu1.8 => 1.0.78+nmu1ubuntu1.9] (core)
<teward> um, is there any issue with the publishers to Proposed?
<teward> nginx has been stuck for 12 hours without being 'uploaded' - just stuck at 'pending publication' to proposed
<apw> teward, it is in binary New
<teward> ah
<teward> missed that xD
<teward> apw: i'm guessing because there's a new .deb included in it.
<apw> tkamppeter, geoip2
<teward> which I had a discussion with sarnold about several times during last cycle :P
<teward> hep.
<teward> yep*
<teward> apw: guess i haven't had enough coffee to wake up today :)
 * teward goes and finds more
<teward> tkamppeter: apw: for the record, geoip2 module was added to the NGINX packages as a third party plugin because the in-built GeoIP module only works with MaxMind legacy which is no longer available for 'free' - this is ultimately done in order to provide an alternative for those who want to use GeoIP with the MM GeoIP2 DBs.
<apw> teward, and i read the associated bug as saying that it should end up in universe ...
<teward> correct, that is a Universe-targeted binary
<teward> it's not included in -core (that needs a MIR)
<teward> so that binary can be dropped to Universe.  I'm working on prepping the MIR to Main that one (it's currently only dep'd by nginx-extras and nginx-full both binary debs in Universe)
<teward> but i'm also 'dragging my feet' as it's early in the cycle, not to mention I just got dropped on me at work creating a REST API for a huge project
<teward> so that's taking some attention :p
<teward> wow i'm an idiot the big red "NEW" is right there in front of me, I should've noticed that.  *smacks face against keyboard*
<stgraber> jdstrand: all our x86 CI nodes are now on the updated libseccomp, I'll let you know if we see anything bad happen
<jdstrand> stgraber: great, thanks! (cc mdeslaur)
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (disco-proposed) [1.0.112ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (cosmic-proposed) [1.0.108ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: resolvconf (xenial-proposed/main) [1.78ubuntu6 => 1.78ubuntu7] (core)
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (bionic-proposed) [1.0.95ubuntu0.4]
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (xenial-proposed) [1.0.78+nmu1ubuntu1.9]
<bdmurray> infinity: Were you going to verify tzdata?
-queuebot:#ubuntu-release- Unapproved: accepted libmbim [source] (bionic-proposed) [1.18.0-1~ubuntu18.04.1]
<sil2100> kenvandine, tkamppeter: hmm, the libqmi upload seems to have a bad version number
<kenvandine> ugh
<sil2100> kenvandine, tkamppeter: 1.22.0-1.3~ubuntu18.04.1, while I don't see 1.22.0-1.3 anywhere
<sil2100> kenvandine, tkamppeter: so currently it would be higher than what's in disco/eoan
<sil2100> Disco/eoan have 1.22.0-1.2
<kenvandine> i can reupload that in a couple minutes
<sil2100> Thanks! :)
<sil2100> I suspect 1.22.0-1.3 was supposed to be pushed to disco before release or something
<sil2100> (synced)
<kenvandine> i'll upload it as 1.22.0-1.2~ubuntu18.04.1
<kenvandine> sil2100: the problem there is it's older than the previous changelog entry
<kenvandine> sil2100: i guess that's actually fine
<sil2100> kenvandine: yeah, that's not a problem per-se, doesn't look perfect but yeah
<sil2100> Many of our backport-SRUs have such situation
<kenvandine> sil2100: ok, uploaded
<sil2100> Thanks!
-queuebot:#ubuntu-release- Unapproved: rejected libqmi [source] (bionic-proposed) [1.22.0-1.3~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: libqmi (bionic-proposed/main) [1.18.0-3ubuntu1 => 1.22.0-1.2~ubuntu18.04.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted libqmi [source] (bionic-proposed) [1.22.0-1.2~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted modemmanager [source] (bionic-proposed) [1.10.0-1~ubuntu18.04.1]
<tkamppeter> sil2100, I got a lot of messages about libmbim, is it correctly uploaded now? What was wrong with it?
-queuebot:#ubuntu-release- Unapproved: accepted ureadahead [source] (xenial-proposed) [0.100.0-19.1]
<sil2100> tkamppeter: it's all fine now, the problem was that the upload was 1.22.0-1.3~ubuntu18.04.1 while 1.22.0-1.3 never got synced into disco
<sil2100> tkamppeter: so if we'd accept it, the package in bionic would have a higher version number than in disco/eoan
<sil2100> tkamppeter: but Ken tweaked it
<vorlon> infinity, cyphermox, Laney: not sure who's in the best position to look into this, but ubiquity autopkgtests have suddenly regressed as soon as the release name changed http://autopkgtest.ubuntu.com/packages/u/ubiquity/eoan/arm64
<tkamppeter> I see now that my original debdiff attached to the bug report also had the correct version 1.22.0-1.2~ubuntu18.04.1 and not ...-1.3~... really strange.
<tkamppeter> sil2100, kenvandine ^^
<kenvandine> that is really strange!
<kenvandine> i wonder if i screwed that up :)
<tkamppeter> sil2100, I was asking about libmbim, because I got a lot of error mails, but according to the bug rpoert it seems to have ended up all OK.
<kenvandine> it's been so long, i don't recall
<cyphermox> vorlon: ok
<sil2100> tkamppeter: ouch, yeah, looks like those failed due to some LP issues, let me look
<Laney> vorlon: cyphermox: Looks like the dpkg-trigger triggered one did pass on eoan, but it broke between then and 2019-04-23, or do I miss something?
<tkamppeter> sil2100, kenvandine, now seems that Yuan-Chen Cheng from OEM nees to verify the fix, as he should be the one with these new modem models.
<kenvandine> tkamppeter: yes
<kenvandine> tkamppeter: please email him about that
<tkamppeter> kenvandine, done.
<kenvandine> tkamppeter: thanks
<tkamppeter> sil2100, thank you very much for having modemmanager passed into -proposed.
<vorlon> Laney: oh the 21st was after the release date as well, ok.  So yeah, it regressed shortly after archive opening :)
<sil2100> tkamppeter: your welcome! libmbim is now built correctly, so now modemmanager should be able to build soon as well
<cyphermox> Laney: you're not missing anything, this isn't a regression, it's a test that is not flexible enough
<Laney> nod
-queuebot:#ubuntu-release- New binary: clamav [s390x] (eoan-proposed/main) [0.101.2+dfsg-1ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: clamav [ppc64el] (eoan-proposed/main) [0.101.2+dfsg-1ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: clamav [i386] (eoan-proposed/main) [0.101.2+dfsg-1ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: clamav [amd64] (eoan-proposed/main) [0.101.2+dfsg-1ubuntu1] (ubuntu-server)
<acheronuk> who needs to tell 'reverse-depends' about eoan? I can't recall who
<vorlon> tumbleweed: ^^
-queuebot:#ubuntu-release- New binary: clamav [arm64] (eoan-proposed/main) [0.101.2+dfsg-1ubuntu1] (ubuntu-server)
<acheronuk> thanks
-queuebot:#ubuntu-release- New binary: clamav [armhf] (eoan-proposed/main) [0.101.2+dfsg-1ubuntu1] (ubuntu-server)
<tumbleweed> vorlon: does eoan have a name yet?
<tumbleweed> that's blocking it
<xnox> tumbleweed, eoan is the adjective to use; there is no animal yet, but it shouldn't matter, right?
<xnox> tumbleweed, note how all of distro-info-data updated already, and debootstrap, etc.
<tumbleweed> no, it's not (in Debian)
<tumbleweed> I'm not going to get it updated in Debian, if we're getting a name, tomorrow
<xnox> tumbleweed, ransom holder!
<xnox> tumbleweed, i wish we knew if and when we get the eanimal
<tumbleweed> I was giving it a few days to see if a name would appear
<vorlon> tumbleweed: why is the Ubuntu reverse-depends service blocked on a Debian upload of distro-info-data?
<teward> tkamppeter: got a few minutes to look at nginx in the NEW queue?
<teward> if you're not busy.
<tumbleweed> vorlon: it's actually blocked on a git checkout of distro-info-data
<tumbleweed> so I can just commit EANIMAL to that
<vorlon> ah
<tumbleweed> but I was assuming we'd get an animal within a day or two
<tumbleweed> is that unlikely?
<vorlon> tumbleweed: why wouldn't you just use the Ubuntu distro package anyway, given that distro-info-data is always srued?
<vorlon> tumbleweed: I have no control over the timeline, and reverse-depends not working is a nuisance now
<vorlon> not enough for me to have complained directly, but I'm +1ing acheronuk ;)
<tumbleweed> because I didn't have root on ubuntuwire at the time
<vorlon> ah ;)
 * tumbleweed can probably unwind all of that
<tumbleweed> I would like an animal, of course
<tumbleweed> and I'm slightly worried that without the pressure of opening the release, it will take months now
<cjwatson> If we used the null animal (i.e. literally just called it Eoan, not Eoan EANIMAL or whatever) and it were to happen that we didn't get an animal by release time, what would go wrong?
<vorlon> Eoanimal
<teward> multiversal panic perhaps? :P
<tumbleweed> terrible wallpaper image?
<vorlon> Eoan Eoanimal, pronounced "an animal"
<tumbleweed> no t-shirt :P
<cjwatson> I mean that's the designers' problem and they can apply whatever pressure they can if they need to :)
<cjwatson> But the null animal seems like a better default than errno jokes that probably wouldn't be very good to actually release with
<cjwatson> And a more generalisable precedent if we had to
 * tumbleweed pulls out all of those local checkouts on my ubuntuwire cronjobs
<teward> anyone able to take a look at nginx / libnginx-mod-geoip2 in the NEW queue?  The 'new' binaries created need demoted to Universe, ultimately, though this is being added to the packaging because of the GeoIP support for MaxMind Legacy no longer being usable due to MaxMind dropping the Legacy DBs for non-paying customers, and there not being any in-built GeoIP2 module within the code base yet for the GeoIP2 databases.
<tkamppeter> teward, nginx in the new queue? What is that?
<teward> tkamppeter: apw pinged you maybe the wrong one to ping
<teward> *yawns* I have an NGINX upload (web server software) that includes a new plugin .deb for GeoIP2 support and it's in NEW because it's new to the package
<teward> though those binaries for libnginx-mod-http-geoip2 are new they should be demoted to Universe.
<tkamppeter> teward, I think it was not meant for me, as I do all the printing stuff and network-manager.
<teward> yep
<teward> well in any case
<teward> i am a patient person and will wait :)
<teward> *lurks*
<teward> ... now if only people would stop calling my phone every 3 minutes
<tkamppeter> I am also not responsible for the NEW queue.
<teward> as I said i'll wait :)
<teward> vorlon: any progress on the OpenSSL SRU for Bionic?  Just wondering, I have people emailing me asking me to push an nginx rebuild in Bionic for TLS1.3 support in -proposed but I am not going to so we don't have any blocking things preventing security updates, etc. from happening before OpenSSL 1.1.1 is done.
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (cosmic-proposed) [1:0.4.2]
<vorlon> Laney, juliank: do you know anything about why ppc64el autopkgtest queues are lagging?
<vorlon> also why is armhf zippy all of a sudden, that's very suspicious
<ddstreet> bdmurray during your sru vanguard shift today, if you have time, can you approve the qemu upload to xenial plz - it's a rather important fix for a customer issue of crashing qemu
-queuebot:#ubuntu-release- Unapproved: accepted python2.7 [sync] (bionic-proposed) [2.7.15-4ubuntu4~18.04]
<vorlon> teward: ^^ some progress
-queuebot:#ubuntu-release- Unapproved: accepted python3.6 [sync] (bionic-proposed) [3.6.8-1~18.04.1]
<coreycb> vorlon: i'm not sure why python-formencode is listed as an openstack package
<teward> vorlon: indeed.
<teward> vorlon: would you be able to take a look at nginx in the NEW queue per chance?
<vorlon> coreycb: https://bugs.launchpad.net/ubuntu/+source/python-formencode/+bug/493593
<ubot5`> Ubuntu bug 493593 in scgi (Ubuntu Lucid) "MIR for paste." [High,Fix released]
<teward> if not that's fine, it's not a huge priority
<coreycb> vorlon: actually i guess we still depend on it for py2 via swift and python-paste. looks like if and ever we get to swift py3 we may not need it.
<vorlon> teward: well I'm currently still working on those SRU reviews
<teward> ack, no problem.
<vorlon> coreycb: if you want to negotiate having another team take over ownership of it in main, that'd be between you and them :)
<coreycb> vorlon: no problem. i think i'll cross that bridge once it's no longer used by openstack packages. for now i'll shake my hand at swift.
<juliank> vorlon: only heard about armhf having no networking or something
-queuebot:#ubuntu-release- Unapproved: accepted python-cryptography [sync] (bionic-proposed) [2.1.4-1ubuntu1.3]
<tsimonq2> vorlon: You're welcome to sync.
<vorlon> xnox: ruby2.5/bionic needs rebased on the 2.5.1-1ubuntu1.2 in bionic-security (which doesn't match the one in the sru changelog)
-queuebot:#ubuntu-release- Unapproved: rejected ruby2.5 [source] (bionic-proposed) [2.5.1-1ubuntu1.3]
<tumbleweed> reverse-depends for eoan have generated
<vorlon> \o/
<vorlon> tumbleweed: thanks
-queuebot:#ubuntu-release- Unapproved: accepted python3.7 [sync] (bionic-proposed) [3.7.3-2~18.04.1]
<xnox> tumbleweed, we worship you!
<bdmurray> infinity: Were you going to do that tzdata verification?
<infinity> bdmurray: I were.  Just, y'know, swap days, and sick (how unfair is that, getting sick when you're already taking time off), etc.
<infinity> bdmurray: I can look later tonight.
<bdmurray> infinity: I'm sorry you are sick man.
<tumbleweed> xnox: pff. I'm lazy
<tsimonq2> infinity: Less derp in the pastebinit version for Disco now, thanks.
-queuebot:#ubuntu-release- Unapproved: pastebinit (disco-proposed/main) [1.5-2 => 1.5-2.2~ubuntu0.19.04.1] (core)
<Eickmeyer> tsimonq2: We all need a little less derp in our lives.
<tsimonq2> ^^
<tsimonq2> Eickmeyer: I have no clue what I was thinking when I typed 1.5-2.2ubuntu~0.19.04.1 and thought "this is totally a valid version!"
<Eickmeyer> tsimonq2: haha! Yeah, that is... wow.
 * tsimonq2 steals teward's coffee
 * Eickmeyer follows the coffee
 * Eickmeyer like a puppy dog
<tsimonq2> haha :)
 * teward appears in front of tsimonq2 with a laser sword, cuts down tsimonq2, then reclaims his coffee and walks back off as if nothing happened.
 * Eickmeyer folows the coffee like a puppy dog
-queuebot:#ubuntu-release- Unapproved: ruby2.5 (bionic-proposed/main) [2.5.1-1ubuntu1.2 => 2.5.1-1ubuntu1.4] (kubuntu, ubuntu-desktop, ubuntu-server) (sync)
<xnox> infinity, in france, if one is sick during holidays, one gets to reclaim those days!
<xnox> vorlon, ruby2.5 respun ^^^ skipped a version number, but otherwise it should be a clean diff on top of bionic-security.
<xnox> vorlon, UNAPPROVED queue (bionic/libio-socket-ssl-perl, bionic/libnet-ssleay-perl) what about these two? i only have "autopkgtests / unittests pass" as the testcase for both.
<xnox> vorlon, ah, nevermind see the emails from you now!
#ubuntu-release 2019-04-24
<infinity> xnox: BRB, moving to France.
<xnox> vorlon, ruby2.5 respun; will deal with perl after sleeping.
-queuebot:#ubuntu-release- New binary: pmdk-convert [amd64] (eoan-proposed/none) [1.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pmdk-convert [arm64] (eoan-proposed/none) [1.5.1-1] (no packageset)
<LocutusOfBorg> hello, question: freshplayerplugin can be built everywhere, but it Recommends adobe-flashplugin that is an amd64/i386 only package. Can it be built everywhere or should be restricted too? now it is restricted, but the debian package isn't...
<LocutusOfBorg> (mostly all the delta of the package can be dropped because of "new upstream release" and "debian merged most changes")
<vorlon>                                                                                                                 autopkgtest [05:46:36]: ERROR: testbed failure: sent `copyup /tmp/autopkgtest.M6jL27/build.qOq/src/ /tmp/autopkgtest-work.umz0lxj2/out/tests-tree/', got `timeout', expected `ok...'
<vorlon> that doesn't look so great in the ppc64el logs
<vorlon> but why do we need to copy these trees back to the dispatcher anyway?
<vorlon> .. in order to parse the debian/tests/control from the built tree, sigh
-queuebot:#ubuntu-release- New source: openjdk-8 (eoan-proposed/primary) [8u212-b01-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted openjdk-8 [source] (eoan-proposed) [8u212-b01-1ubuntu1]
<doko> removing openjdk-8 wasn't a bright idea, when the Debian removal only requested removal of some binaries
<cjwatson> the Debian removal *requested* that, but process-removals works off what was *actually* removed
<cjwatson> (plus human intervention, but it can be easy to miss)
<doko> can the binaries be restored in eoan?
<doko> or else it's rebootstrapping
<cjwatson> maybe if you'd asked before reuploading
<doko> I can remove that one
<cjwatson> how hard is rebootstrapping?
<cjwatson> if it's not super-difficult it might be easier
<doko> some ppa copies from older releases, then copying a clean binary build to eoan
<doko> ok
<cjwatson> mind you I suppose the worst case of remove and copy is that we might burn the -1ubuntu1 version number
<cjwatson> perhaps we're better off doing that
<doko> no problem to use a new version
<cjwatson> ok, so I suggest removing the version just uploaded to eoan, then copy-package --from ubuntu --from-suite disco --to ubuntu --to-suite eoan-proposed -e 8u212-b01-1 --include-binaries openjdk-8
<doko> so no ppa bootstrap?
<cjwatson> nope
<doko> ok
<cjwatson> assuming there are no other sources that go with this
-queuebot:#ubuntu-release- New binary: lvm2 [amd64] (eoan-proposed/main) [2.03.02-2ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: lvm2 [s390x] (eoan-proposed/main) [2.03.02-2ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: lvm2 [ppc64el] (eoan-proposed/main) [2.03.02-2ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: lvm2 [arm64] (eoan-proposed/main) [2.03.02-2ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: lvm2 [i386] (eoan-proposed/main) [2.03.02-2ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: lvm2 [armhf] (eoan-proposed/main) [2.03.02-2ubuntu1] (core)
<rbalint> rbasak, could you please approve console-setup srus? it fixes LP: #520546 that got quite hot recently
<ubot5`> Launchpad bug 520546 in console-setup (Ubuntu Disco) "Alt+KEY incorrectly behaves like Ctrl+Alt+KEY, and/or unwanted VT switch from Alt+Left/Right" [High,In progress] https://launchpad.net/bugs/520546
<rbasak> rbalint: just console-setup in Disco? Anywhere else?
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [ppc64el] (bionic-proposed/main) [5.0.0-13.14~18.04.2] (kernel)
-queuebot:#ubuntu-release- New sync: openjdk-8 (eoan-proposed/primary) [8u212-b01-1]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [amd64] (bionic-proposed/main) [5.0.0-13.14~18.04.2] (kernel)
-queuebot:#ubuntu-release- New: accepted openjdk-8 [sync] (eoan-proposed) [8u212-b01-1]
<ddstreet> rbasak during your sru vanguard shift today, can you plz approve the qemu upload to xenial
-queuebot:#ubuntu-release- Unapproved: blender (bionic-proposed/universe) [2.79.b+dfsg0-1 => 2.79.b+dfsg0-1ubuntu1.18.04.1] (ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: blender (disco-proposed/universe) [2.79.b+dfsg0-6build1 => 2.79.b+dfsg0-6ubuntu1.19.04.1] (ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: blender (cosmic-proposed/universe) [2.79.b+dfsg0-4 => 2.79.b+dfsg0-4ubuntu1.18.10.1] (ubuntustudio)
<juliank> sil2100, rbasak: There's still an update-notifier upload in trusty's unapproved queue from last monday with the final fixes for the (somewhat trusty-specific) ESM messaging. I'd like to at least get this thing completed before the esm transition happens.
<juliank> The changes compared to the one we have in proposed are minimal and covered by tests
<rbalint> rbasak, no, down to bionic and i'm testing xenial right now
<rbasak> rbalint: am I right in thinking that the workaround/fix is to reboot (or restart X), and that the SRU will only stop it breaking but not unbreak it?
<ddstreet> bdmurray when you get in, your patches for lp #1794292 appear to have caused the reports to errors.ubuntu.com and stopped plymouth phasing, can you look at that and restart the phasing if you think it's ok
<ubot5`> Launchpad bug 1794292 in plymouth (Ubuntu Cosmic) "plymouthd crashed with SIGSEGV in /sbin/plymouthd:11 in ply_renderer_set_handler_for_input_source -> ply_keyboard_stop_watching_for_renderer_input -> ply_keyboard_stop_watching_for_input -> ply_device_manager_deactivate_keyboards -> on_deactivate" [High,Fix released] https://launchpad.net/bugs/1794292
<rbalint> rbasak, it won't unbreak it, but prevents further pkg updates breaking it again
<rbasak> rbalint: if so I might adjust the bug to stop a load of affected people "failing" SRU verification because the update didn't fix it.
<rbasak> OK, thanks.
<rbalint> rbasak, i did not think about this potential confusion, thanks!
-queuebot:#ubuntu-release- Unapproved: accepted console-setup [source] (disco-proposed) [1.178ubuntu12.1]
-queuebot:#ubuntu-release- Unapproved: accepted console-setup [source] (cosmic-proposed) [1.178ubuntu9.2]
-queuebot:#ubuntu-release- Unapproved: accepted console-setup [source] (bionic-proposed) [1.178ubuntu2.9]
<rbasak> rbalint: accepted  d/c/b; ping me please when you have tested and uploaded x?
<rbasak> rbalint: are all the bug tasks for the other source packages Invalid now?
<rbalint> rbasak, thanks! i believe others are invalid, except for kbd
<rbalint> rbasak, i'm marking them
<rbasak> Thanks!
-queuebot:#ubuntu-release- Unapproved: openvpn (cosmic-proposed/main) [2.4.6-1ubuntu2 => 2.4.6-1ubuntu2.1] (ubuntu-desktop, ubuntu-server)
<sil2100> Laney: hey! britney's running on snakefruit, right? You have access there?
<Laney> sil2100: tak
<sil2100> Laney: smb noticed that there seem to be no excuses updates for bionic and xenial since last week
<sil2100> http://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/ <- generated on the 16th
<sil2100> (same for xenial)
<Laney> how intriguing
 * sil2100 looks for logs
<Laney> https://people.canonical.com/~ubuntu-archive/proposed-migration/log/bionic/2019-04-24/
<sil2100> http://people.canonical.com/~ubuntu-archive/proposed-migration/log/bionic/2019-04-24/12:57:12.log
<sil2100> Ouch
-queuebot:#ubuntu-release- Unapproved: openvpn (bionic-proposed/main) [2.4.4-2ubuntu1.1 => 2.4.4-2ubuntu1.2] (ubuntu-server)
<sil2100> First time I see britney tracebacking ;)
<Laney> vot does it mean
<smb> she's not amused
<sil2100> Laney: ok, I can look into this in detail after our sprint-load meeting, so if you're busy - don't worry about it
 * sil2100 should have checked the logs first, thought that maybe it was just not running at all on snakefruit
<Laney> I'm blaming https://bazaar.launchpad.net/~ubuntu-release/britney/britney1-ubuntu/revision/314
 * sil2100 shrugz
<sil2100> britney1
 * sil2100 knows nothing of britney1 so he slowly backs off
<sil2100> ;)
<Laney> infinity: ^- what was that commit about?
<infinity> Laney: Made disco happy.  I'm puzzling over why it made the others grumpy. :/
<Laney> Guessing you can't have a FauxPackage when there's a nonFauxPackage
<infinity> (also, why isn't FauxPackages per suite?)
<Laney> Might want per series fauxies
<sil2100> It's a bit scary, since this means we had no bionic and xenial autopkgtests ran for any of the SRUs in the last week
<infinity> That's only scary if the people processing those SRUs ignored that tests were in progress.
<sil2100> The good news is that today's the '7th day' from the last run, so yeah
<infinity> Or, rather, ignored that the packages weren't in excuses at all.
<sil2100> infinity: the pending-sru report doesn't mention running tests I think, and I doubt anyone from the SRU team looks at the excuses page at all - we rely on the pending report lisitng all the needed info
<sil2100> Which is why no one noticed it up until today, ugh!
<infinity> Ahh well, it's not the end of the world.
<sil2100> Oh well, probably we need to improve the process to at least check excuses, and maybe add some feedback to the report
<sil2100> But as said, anyway, luckily only now the aging period from last run has passed so yeah ;)
<infinity> I'll just comment that out for now, and I think I can fix fauxpackages to only create an entry if the package doesn't exist.
<infinity> So we don't get two
<sil2100> infinity: ok, thanks o/
<infinity> Cowboyed for now.  Will think harder about it tomorrow.
<infinity> I think my proposed fix should be vaguely trivialish.
<ddstreet> rbasak sil2100 if either of you could approve the qemu upload for xenial, that would be super duper awesome
<rbasak> sil2100: do you have an opinion on bug 1804513 please? I'm not sure if the major version bump as documented in the bug is acceptable as-is, because it doesn't seem to look at any behaviour breaks for existing users. Do you read it differently?
<ubot5`> bug 1804513 in mixxx (Ubuntu Cosmic) "Cosmic: Mixxx 2.1.3 is not stable with Qt5" [Critical,In progress] https://launchpad.net/bugs/1804513
<rbasak> ddstreet: any reason this needs to be prioritised over old things in the queue please?
<ddstreet> rbasak it works around a qemu crash during normal operation, in use by a customer via the trusty-mitaka UCA repo
<ddstreet> so with trusty going ESM tomorrow, we'd like to get it into X asap so it can make it into trusty-mitaka asap as well; there is a lot of uncertainty around the details of trusty-mitaka in ESM
<ddstreet> waiting in the sru upload queue doesn't help the uncertainty
<rbasak> Binary files /tmp/tmpzQ26Bn/QfP_vgKhtx/update-notifier-0.154.1ubuntu4/data/__pycache__/package_data_downloader.cpython-37.pyc and /tmp/tmpzQ26Bn/cHQOFmTiDK/update-notifier-0.154.1ubuntu5/data/__pycache__/package_data_downloader.cpython-37.pyc differ
<rbasak> juliank: ^ should that be in the source package at all?
<rbasak> tests/__pycache__/apt_check.cpython-37.pyc also
<juliank> rbasak: not really, which is why it went away, and hence differs
<rbasak> Oh. OK :)
<juliank> diff stupid
 * rbasak doesn't usually use the Launchpad diffs, but git-ubuntu is broken :-/
<juliank> It should show "file deleted" imo
-queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (trusty-proposed) [0.154.1ubuntu5]
<rbasak> ddstreet: thank you for the well written up bug - that saved me from asking a bunch of questions :)
<rbasak> ddstreet: have you had a code review from anyone on your patch?
<smb> infinity, hm, I am not sure that cowboy is too successful
<ddstreet> cpaelzer has https://code.launchpad.net/~ddstreet/ubuntu/+source/qemu/+git/qemu/+merge/366392
<rbasak> Perfect!
<rbasak> Sorry I missed the link from the bug
<Laney> smb: https://people.canonical.com/~ubuntu-archive/proposed-migration/log/bionic/2019-04-24/13:56:21.log <- looks like it's working
<smb> Laney, ok, when I looked the last log was the one before
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (xenial-proposed) [1:2.5+dfsg-5ubuntu10.37]
<sil2100> rbasak: let me take a look
<sil2100> ddstreet: I see Robie is already reviewing it, but in case he's done with his shift, I can pick it up then ;)
<rbasak> I accepted qemu/xenial ^
<rbasak> sil2100: consider me done with my shift now please, if you want to take any. I'd like to get git-ubuntu fixed. It makes my SRU shifts easier when it's working :)
<sil2100> \o/
<sil2100> rbasak: thanks for all the reviews today!
-queuebot:#ubuntu-release- Unapproved: freelan (disco-proposed/universe) [2.0-8ubuntu2 => 2.0-8ubuntu3] (no packageset)
<xnox> sil2100, please reject freelan above..... wrong suite, it's meant for eoan
<sil2100> ACK
<sil2100> Done
-queuebot:#ubuntu-release- Unapproved: rejected freelan [source] (disco-proposed) [2.0-8ubuntu3]
<tdaitx> doko: should we get openjdk-8 back into disco? I am preparing the security update, so this would be the right time to do it
-queuebot:#ubuntu-release- Unapproved: python-glance-store (cosmic-proposed/main) [0.26.1-0ubuntu2 => 0.26.1-0ubuntu2.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-glance-store (disco-proposed/main) [0.28.0-0ubuntu1 => 0.28.0-0ubuntu1.1] (openstack, ubuntu-server)
<bdmurray> sil2100: do you have a moment?
-queuebot:#ubuntu-release- Unapproved: knockd (disco-proposed/universe) [0.7-1ubuntu2 => 0.7-1ubuntu2.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: knockd (cosmic-proposed/universe) [0.7-1ubuntu1.18.10.1 => 0.7-1ubuntu1.18.10.2] (no packageset)
<sil2100> bdmurray: what's up?
<vorlon> Laney: don't know if you saw my late-night blathering, but in digging into the ppc64el queue I noticed two things; 1) data transfer between the ppc64el runners and the autopkgtest runners looks like it might be slower than for other archs (why?), and 2) this is noticeable because we are transferring multiple GB of built source trees from runner to host just to inspect the final debian/tests/
<vorlon> directory.  do you know any reason we shouldn't make runner/autopkgtest:process_actions() pull down *just* the debian/tests directory?
<bdmurray> sil2100: the phased update of plymouth has stopped because of some crashes and I believe they are legitimate but it crashes a lot less now than it used too...
<Laney> vorlon: no idea why it would be slower than anything else in the same region
<Laney> as for (2), not offhand, but please discuss with elbrus
-queuebot:#ubuntu-release- Unapproved: knockd (bionic-proposed/universe) [0.7-1ubuntu1.18.04.1 => 0.7-1ubuntu1.18.04.2] (no packageset)
<bdmurray> sil2100: the crash we are fixing happens 1k times per day while the new crashes happen a couple of times per day (but to be fair the new plymouth is only at 10% phasing). But it's also fixed in disco with similarly low counts.
<bdmurray> sil2100: so I'm inclined to let it phase
<bdmurray> s/let/make/
<sil2100> bdmurray: if it's the same crash, I'd say let's make it moving
<bdmurray> sil2100: they are new crashes https://errors.ubuntu.com/problem/bec9336475f855ea20928e187ea65b281531514a, https://errors.ubuntu.com/problem/197cb74e56a0583e15b57286f3dae38236225acf, https://errors.ubuntu.com/problem/3106debb8d0e370fe4f44e3c76ed5ca230ea0eb7
<teward> vorlon: still working on the python things or can I borrow you for a NEW review again?
<teward> s/python/other SRU/
<teward> or maybe even sil2100?  if either of you have a few minutes that is.
<sil2100> teward: eek, would love to, but I still have a few things to finish before my EOD sadly :<
<sil2100> teward: can you poke me tomorrow in case Steve or others have no time?
<teward> sil2100: yep, sure.  I poked vorlon yesterday but vorlon was inundated wtih the OpenSSL SRU and related SRUs :p
<vorlon> I'm downloading now for inspection
<sil2100> bdmurray: hm, those look similar in taste to the ones fixed by the SRU, at least that's the feeling I get
<bdmurray> sil2100: so where does that leave us?
<teward> ah cool thanks vorlon
<vorlon> Laney: ok I found the answer to my question, we need to copy the entire tree back down because we launch a separate testbed for the tests than for the package build in the Restrictions: needs-build case
<sil2100> bdmurray: I'd say let's override it - it feels to me like an improvement from the previous state, and I don't see new manual bug reports being filled for issues like this
<sil2100> bdmurray: let's let it phase and monitor if the number doesn't grow to worrying levels
-queuebot:#ubuntu-release- New: accepted nginx [amd64] (eoan-proposed) [1.15.12-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted nginx [armhf] (eoan-proposed) [1.15.12-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted nginx [ppc64el] (eoan-proposed) [1.15.12-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted nginx [arm64] (eoan-proposed) [1.15.12-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted nginx [s390x] (eoan-proposed) [1.15.12-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted nginx [i386] (eoan-proposed) [1.15.12-0ubuntu1]
<Laney> vorlon: ah right, but this happens in other cases where it might not be needed too?
<Laney> OTOH the most problematic tests (KDE) are all build-needed
<vorlon> Laney: no, the cases where I'm currently seeing the timeouts are exactly the KDE packages
<vorlon> if build is not needed, it doesn't need to stream the tree around an extra time
<teward> vorlon: i'm assuming you did the acceptance on the new NGINX plugin.  Thank you kindly!
<teward> and if it wasn't you thanks to whomever did.
<vorlon> anyway, going to do some rough network benchmarking now
<vorlon> teward: yeah that was me, y/w
<Laney> if there's a network problem it'd be good to bring that up with IS folks
<vorlon> yep
<Laney> there are multiple copies of openvswitch/neutron/... - it's possible those getting swamped could cause problems like this
<Laney> and probably different physical hardware too
<Laney> but also, general :( at KDE being at the middle of a problem again
<bdmurray> sil2100: will do, thanks for the input
-queuebot:#ubuntu-release- Unapproved: accepted kpatch [source] (bionic-proposed) [0.5.0-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted dm-writeboost [source] (bionic-proposed) [2.2.8-1ubuntu3~18.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted xtables-addons [source] (bionic-proposed) [3.0-0.1ubuntu2]
<jdstrand> Odd_Bloke: hey, curious on the timeframe of ubuntu-daily:eoan/amd64? I'm told that CPC handles those and currently the docker.io autopkgtest is failing because 'lxc launch ubuntu-daily:eoan/amd64 docker' fails
<jdstrand> Odd_Bloke: actually, not just amd64, whatever docker.io needs
<Odd_Bloke> jdstrand: I'm no longer on CPC, so that's rcj and fginther's problem. :)
<jdstrand> Odd_Bloke: ah, thanks for the point and I hope you are enjoying your new role :)
<Odd_Bloke> :)
<jdstrand> pointer*
<vorlon> Laney: so while I work through the question of whether there are network bottlenecks, what should we do about the timeouts themselves?  Do you know if we ever use that timeout to catch dead runners, or is it just getting in our way by being too low?
<vorlon> and I still have trouble diagnosing these things with any accuracy, but it looks to me like hitting the timeout may be leaving the runners in some kind of limbo state besides
<fginther> jdstrand, getting eoan images built and published is our current priority. I do expect these before end of week
<jdstrand> fginther: ack, thanks!
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1004.5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: openvpn (xenial-proposed/main) [2.3.10-1ubuntu2.1 => 2.3.10-1ubuntu2.2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: metaphlan2 (bionic-proposed/universe) [2.7.5-1 => 2.7.5-1ubuntu1] (no packageset)
<teward> was there a temporary network issue with the autopkgtests?
<vorlon> teward: what specifically are you seeing?
<teward> vorlon: "Failed to resolve ftpmaster.internal" errors in some autopkgtests triggered by the nginx upload
<vorlon> the autopkgtest infra is currently definitely network constrained because of all the KDE packages' built trees that are being streamed back and forth and timing out
<vorlon> teward: for which archs?
<teward> armhf
<teward> and only 3 of the tests
<vorlon> yeah
<vorlon> that's an ongoing issue that we thought was fixed once then recurred
<teward> ack
<teward> vorlon: so i assume then the reruns I just queued for the same tests that regressed may or may not succeed on next-run
<teward> do we just hand-wave those or do we wait for the infra to settle?
<teward> vorlon: just as an FYI, looks like my rerunning those tests reran them with the original network issue fixed, and the tests passed as they usually did
<teward> so guess I don't have to worry then :)
<teward> (it's still running the other autopkgtests, but the regressing/failing ones there I wanted to at least get handled heh)
<vorlon> teward: it's ongoing and intermittent, yeah
#ubuntu-release 2019-04-25
-queuebot:#ubuntu-release- New binary: qgis [s390x] (eoan-proposed/universe) [3.4.7+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [i386] (eoan-proposed/universe) [3.4.7+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [ppc64el] (eoan-proposed/universe) [3.4.7+dfsg-1] (no packageset)
<teward> vorlon: indeed, I didn't expect it to hit that quickly though, and I'm assuming it'll happen again.  I'll keep checking back on nginx and the autopkgtests it triggers and keep an eye on more regressions due to that intermittent issue.
<teward> if it continues TOO much then I'll probably drop by the canonical sysadmin channel and see if they can dig into it more.
<teward> (though I'm sure they're aware)
-queuebot:#ubuntu-release- New binary: qgis [amd64] (eoan-proposed/universe) [3.4.7+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [arm64] (eoan-proposed/universe) [3.4.7+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [armhf] (eoan-proposed/universe) [3.4.7+dfsg-1] (no packageset)
<acheronuk> vorlon: can you kill off the running and queued tests that are not against marble and umbrello 19.04 in proposed?
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [amd64] (bionic-proposed) [5.0.0-13.14~18.04.2]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1004.5]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [ppc64el] (bionic-proposed) [5.0.0-13.14~18.04.2]
<mvo> sil2100: hey, sorry for bothering you - I just wanted to wanted to check if the "shadow" sru for xenial/bionic is releasable now or if there is anything missing on our side?
<Laney> vorlon: it sure does catch dead things from time to time
<Laney> sorry to say this for the millionth time, but this KDE autopkgtest situation needs to be addressed
<Laney> we don't have unlimited resources to support people doing whatever they want
<sil2100> mvo: hey! Let me get to it shortly ;)
<acheronuk> Laney: I intend to go through the KDE tests this cycle and disable/skip ones that are onerous. debian already killed off tests in 38 kdepim sources, which where we followed suit significantly shortened amount of time taken up by rdep test on frameworks in later disco uploads
<acheronuk> the tests causing the issue here are ones that I had earmarked to get rid of one way or another this cycle, but honestly had forgotten to do before kicking off on eoan
<fidencio> jibel: hey/ping. any chance to have different volume-ids for Ubuntu Server and Ubuntu Live Server medias? :-)
<fidencio> jibel: if so, where could I file a bug/rfe for that?
<Laney> acheronuk: righto, that'll be appreciated, thanks
<acheronuk> Laney: in fact, the cull of KDEPIM tests meant that (I think) frameworks 5.55 rdep tests cleared in ~ 1 day in disco, whereas before it would have been several days. 5.56 update took longer due to some other 'networking' issues on the runners
<acheronuk> not saying that all is good without further work, but we are in a better place than we were
<Laney> I personally happen to think it'd be worthwhile investing in improvements to be able to build those tests at package build time, but I can't tell people what to spend their time on :>
<Laney> probably biased by having worked on https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests too
<Laney> not that we fully realise all of that in autopkgtest (the sessions are anything but 'real' desktop ones)
<acheronuk> Laney: that is something to look at indeed. debian-kde maintainers have been doing a bit more of that since migration from unstable to testing migration has gated harder on their CI test results, and deciding not to maintain tests on PIM as a result
<acheronuk> anyway Laney, just wanted to say that this is not being ignored, but it's going to be incremental improvements over this release I hope
<Laney> okey dokey
<juliank> I'm a bit confused by excuses
<juliank> the lvm2 complains about missing builds, for example for dmsetup; but they finished about 24 hours agho
<juliank> some packages went away
<juliank> ah
<juliank> there were new binaries I think
<juliank> ABI bump for  liblvm2cmd2.03 - luckily nothing outside its own source package depends on it
<cjwatson> juliank: accepted
<juliank> thanks cjwatson
-queuebot:#ubuntu-release- New: accepted lvm2 [amd64] (eoan-proposed) [2.03.02-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted lvm2 [armhf] (eoan-proposed) [2.03.02-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted lvm2 [ppc64el] (eoan-proposed) [2.03.02-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted lvm2 [arm64] (eoan-proposed) [2.03.02-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted lvm2 [s390x] (eoan-proposed) [2.03.02-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted lvm2 [i386] (eoan-proposed) [2.03.02-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted pmdk-convert [amd64] (eoan-proposed) [1.5.1-1]
-queuebot:#ubuntu-release- New: accepted qgis [amd64] (eoan-proposed) [3.4.7+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [armhf] (eoan-proposed) [3.4.7+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [ppc64el] (eoan-proposed) [3.4.7+dfsg-1]
-queuebot:#ubuntu-release- New: accepted pmdk-convert [arm64] (eoan-proposed) [1.5.1-1]
-queuebot:#ubuntu-release- New: accepted qgis [i386] (eoan-proposed) [3.4.7+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [arm64] (eoan-proposed) [3.4.7+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [s390x] (eoan-proposed) [3.4.7+dfsg-1]
<sil2100> rbalint: hey! Looking at the xenial u-u bugs now - can I poke you about something there?
<rbalint> sure
<sil2100> rbalint: so I was looking at the verification of LP: #1624644 and I just wanted you to check the strangeness that Jarno pointed out regarding the output there
<ubot5`> Launchpad bug 1624644 in unattended-upgrades (Ubuntu Xenial) "By default settings unattended-upgrade does not automatically remove kernel packages that become unused in conjunction with updating by other software" [High,Fix committed] https://launchpad.net/bugs/1624644
<sil2100> rbalint: with linux-image-extra-4.8.0-54-generic mentioned both as 'Keeping auto-removable' and then actually removing it still
<sil2100> Just to be sure there's nothing fishy there
<mvo> sil2100: thank you!
<rbalint> sil2100, it is fishy, but please see my answere there
<sil2100> rbalint: ok, thanks! Yeah, your explaination makes sense
<sil2100> mvo: yw!
<sil2100> rbalint: phew, I think that was everything - releasing \o/
 * mvo hugs sil2100 
<rbalint> sil2100, please set phasing to 0, because i'd like to fix the regressions/missing parts
<rbalint> sil2100, thanks!
<rbalint> sil2100, like the one i just mentioned in the bug
<sil2100> rbalint: done o/
-queuebot:#ubuntu-release- New binary: isl [s390x] (eoan-proposed/main) [0.21-1] (core)
<sil2100> rbalint: (hopefully setting it to 0 will stop the phasing mechanism, can't remember now if there's a special-casing for that)
-queuebot:#ubuntu-release- New binary: isl [amd64] (eoan-proposed/main) [0.21-1] (core)
-queuebot:#ubuntu-release- Unapproved: rejected gce-compute-image-packages [source] (disco-proposed) [20190315-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: update-notifier (trusty-proposed/main) [0.154.1ubuntu5 => 0.154.1ubuntu6] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: isl [i386] (eoan-proposed/main) [0.21-1] (core)
<juliank> sil2100: ^^ this should be the final edition of the update-notifier changes, I played around with it, and it works fine
-queuebot:#ubuntu-release- New binary: isl [arm64] (eoan-proposed/main) [0.21-1] (core)
<juliank> just a minor hickup in an if/else
-queuebot:#ubuntu-release- New binary: isl [armhf] (eoan-proposed/main) [0.21-1] (core)
-queuebot:#ubuntu-release- New binary: isl [ppc64el] (eoan-proposed/main) [0.21-1] (core)
<juliank> whoa, u-u/xenial released, whoa, awesome :)
<juliank> maybe I should actually re-upload the xenial SRU for python-apt and add Breaks: unattended-upgrades (<< $thesru)
<juliank> ah, gotta merge locking fixes from disco anyway
<sil2100> juliank: ACK
<sil2100> ;)
<sil2100> Let me just finish with the gce package
-queuebot:#ubuntu-release- New: accepted isl [amd64] (eoan-proposed) [0.21-1]
-queuebot:#ubuntu-release- New: accepted isl [armhf] (eoan-proposed) [0.21-1]
-queuebot:#ubuntu-release- New: accepted isl [ppc64el] (eoan-proposed) [0.21-1]
-queuebot:#ubuntu-release- New: accepted isl [arm64] (eoan-proposed) [0.21-1]
-queuebot:#ubuntu-release- New: accepted isl [s390x] (eoan-proposed) [0.21-1]
-queuebot:#ubuntu-release- New: accepted isl [i386] (eoan-proposed) [0.21-1]
<Laney> vorlon: there's huge iowait on the cloud worker, this is likely to be a big part of the problem I'd have thought
<Laney> this would be alleviated somewhat by being able to have multiple cloud workers ...
<Laney> maybe we should turn *down* concurrency until these build-needed jobs are through
<Laney> 137 tar processes running atm
<Laney> juliank: guessing you didn't start any work on the parallelisation stuff yet?
<juliank> I think I did a small part, but it does not seem to be aroundf
<juliank> The major issue (apart from actually deploying it...), is likely distributing the image building
<Laney> mmm, that's not very taxing on the host so likely the leader could do that
<juliank> yeah
<juliank> otherwise, it was just a few variable changes to add hostname + grep hostname in the list of instances to delete in maintenance script
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (disco-proposed) [20190315-0ubuntu1~19.04.0]
<sil2100> ugh, those gce package updates
<sil2100> They confuse me frequently
-queuebot:#ubuntu-release- Unapproved: rejected gce-compute-image-packages [source] (bionic-proposed) [20190315-0ubuntu1~18.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (bionic-proposed) [20190315-0ubuntu1~18.04.0]
-queuebot:#ubuntu-release- Unapproved: rejected gce-compute-image-packages [source] (xenial-proposed) [20190315-0ubuntu1~16.04.0]
-queuebot:#ubuntu-release- Unapproved: rejected gce-compute-image-packages [source] (trusty-proposed) [20190315-0ubuntu1~14.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (xenial-proposed) [20190315-0ubuntu1~16.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (trusty-proposed) [20190315-0ubuntu1~14.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted mariadb-10.1 [source] (cosmic-proposed) [1:10.1.38-0ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted mariadb-10.1 [source] (bionic-proposed) [1:10.1.38-0ubuntu0.18.04.2]
-queuebot:#ubuntu-release- Unapproved: rejected gce-compute-image-packages [source] (cosmic-proposed) [20190315-0ubuntu1~18.10.0]
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (cosmic-proposed) [20190315-0ubuntu1~18.10.0]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (disco-proposed) [3.30.6-2ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (cosmic-proposed) [3.30.2-0ubuntu11]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (bionic-proposed) [3.28.1-0ubuntu4.18.04.10]
<Laney> meh, looks like juju 1.25 documentation has been purged from the website
<Laney> guess we should probably move to juju 2 anyway ...
<Laney> I'm going to ask for a staging environment
-queuebot:#ubuntu-release- Unapproved: rejected gnome-software [source] (xenial-proposed) [3.20.5-0ubuntu0.16.04.12]
<Laney> done
-queuebot:#ubuntu-release- Unapproved: accepted python3-stdlib-extensions [source] (bionic-proposed) [3.6.8-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted python-stdlib-extensions [source] (bionic-proposed) [2.7.16-2~18.04]
<teward> I assume that the issues with tests taking eons to get done (autopkgtests) *is* known?  (12 hours+ time and no movement on any autopkgtests I can see?)
<Laney> yes, we've been talking about it in here
<Laney> there is movement, just not much
<teward> Laney: not my fault i odn't have anything but the queuebot notices in logs xD
<teward> Laney: yeah, I ran into that ftpmaster.internal failure yesterday I saw you discussing about on armhf, but those're the only tests that've finished heh.  *shrugs*
<Laney> no they're not
<teward> Laney: that *I* saw finished on the packages I'm watching
<teward> (I only focus on nginx)
<teward> and i'm lagging BAD :|
 * teward goes to diagnose what's up with the workplace internet.
<Laney> anyway, we have some architectural limitations that are creating this problem right now
<teward> ah
<Laney> I am reducing the number of parallel test runners now
<Laney> in (my) theory that should allow some of these tests to complete
<acheronuk> [06:16] <acheronuk> vorlon: can you kill off the running and queued tests that are not against marble and umbrello 19.04 in proposed?
<acheronuk> Laney: would that help? ^
<Laney> acheronuk: I'm sorry, I don't understand what that means
<Laney> there are loads of k* tests in flight
<acheronuk> yes, but it's mostly the marble and umbrello ones that keep stalling, going to *many* hrs, and then seemingly respawning, preventing much progress on some of the queues
<acheronuk> this is only from what I can observe on the status pages
<Laney> anything with build-needed is contributing to this problem
<acheronuk> yes, but those are particularly bad as far as I can see. asnd testing against an old version with a new one in proposed is wasteful
<Laney> tell you what, I'll kill them off and you re-queue what you want
<Laney> there we go
<acheronuk> Laney: thanks. I am not sure how much it might help, but seeing those keep jumping back in the queue and blocking progress is not great. If I have to re-queue behing other stuff and wait, then hey
<acheronuk> progress was not quick anyway!
<xnox> tsimonq2, how does http://launchpadlibrarian.net/388784682/casper_1.395_1.396.diff.gz work at all? e.g. why did you not just guard the 'passwd -d' call? also i cannot find passwd-del.service anywhere. Where is it supposed to come from?
-queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (trusty-proposed) [0.154.1ubuntu6]
<xnox> tsimonq2,  i see that at one point that got injected, cat > /root/lib/systemd/system/passwd-del.service << EOF but not anymore!
<xnox> tsimonq2, i'll fix it up...
<tsimonq2> xnox: Please read the bug report first.
<xnox> tsimonq2, i have read all bug reports.
<tsimonq2> I don't remember particulars here, although I can reread once I get to Seattle.
<xnox> tsimonq2, your upload makes no sense, as you symlink to enable a non-existant systemd unit.
<xnox> tsimonq2, because the systemd unit was removed in the previous upload to yours; and you didn't restore it.
<xnox> tsimonq2, net effect of your upload was to never delete passwords for everyone; instead of just in ssdm case.
<xnox> tsimonq2, also caused bad error messages on subiquity image boot.
<tsimonq2> xnox: Again, this was a complex thing I did like a year ago. I need to reread logs; there was justificatiion.
<tsimonq2> infinity and vorlon worked on it with me here iirc.
<tsimonq2> It's fuzzy, and I don't have the cycles to look until tonight.
<xnox> tsimonq2, look http://launchpadlibrarian.net/383837510/casper_1.394_1.395.diff.gz
<xnox> the job got deleted.... thus your next upload did nothing useful, but removed the thing everyone else needed.
<tsimonq2> xnox: Diffs are pretty difficult to review properly on mobile, with no context.
<xnox> tsimonq2, do $ git-ubuntu clone casper
<xnox> when you get to a desktop, and do read $ git log -p ./scripts/casper-bottom/25adduser
 * tsimonq2 comes back to this later when I can sit down and review at a computer
<xnox> my latest upload should fix things up properly for everyone now.
<tsimonq2> ...
<tsimonq2> So you JFDI before having a conversation about it? Cool, you have TIL now. ;)
<tsimonq2> If I recall correctly, it was a lightdm thing too. It was also for platform consistency, since, if I recall correctly, that was what the TB members I was working with preferred.
<acheronuk> tsimonq2: that was to fix re-login with sddm in Kubuntu live session?
<acheronuk> *in part
<tsimonq2> There was more to it, iirc.
<acheronuk> hence *in part
<tsimonq2> Platform consistency is a thing, though.
<xnox> tsimonq2, the code currently in, is broken, and doesn't work, and print error messages =) so yes, i am JFDI to revert uterly broken thing ;-)
<xnox> acheronuk, and in process of unbreaking sddm, broke everyone else ;-)
<acheronuk> xnox: if sddm live session re-login works tomorrow (or when this migrates), I'm not bothered :)
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (disco-proposed/main) [1:19.04.16.1 => 1:19.04.16.2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (disco-proposed) [1:19.04.16.2]
<Laney> ok there are barely any autopkgtests running now, will leave it this way for a bit
<Laney> load is a mere 23.58, and a trivial 31 tar processes running /o\
<teward> o.o
<xnox> acheronuk, well currently sddm live session re-login is working; and it should continue to work once things build/migrate and isos are rebuild. given the current queues, i'm not sure if that will happen tomorrow or not.
<acheronuk> Laney: is there any progress on whatever networking issue is causing the copy of the build tree to time out? or is Steve the one to ask?
<acheronuk> xnox: yeah, not much hurry :)
<Laney> not sure that there is one rather than just contention on the host, but he would be
<acheronuk> ok. np
<acheronuk> something is regressed on the infra anyway. I'm not placed to say what
<Laney> no
<Laney> it's a bug that caused a particular combination of packages to create issues on the host
<Laney> we can't handle loads of packages with large build trees simultaneously
<acheronuk> it did before. much better than this, anyway
<Laney> thanks, but this speculation isn't very helpful
<Laney> if vorlon/someone wanted to work on filtering & de-duping some of the requests in the queue, *that* would be helpful
<Laney> I'll be back later on
<Laney> o/
<acheronuk> I'm only comparing previous behaviour to current behaviour. Steve said he noticed the transfer was V slow and speculated networking
<acheronuk> hence me enquiring
<acheronuk> if we can just get back to as before, and then work on improving things, all would be good
-queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (bionic-proposed) [3.192.1.6]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (cosmic-proposed/main) [4.18.0-19.20] (core, kernel)
-queuebot:#ubuntu-release- New binary: mariadb-10.1 [s390x] (cosmic-proposed/universe) [1:10.1.38-0ubuntu0.18.10.1] (no packageset)
-queuebot:#ubuntu-release- New binary: mariadb-10.1 [s390x] (bionic-proposed/universe) [1:10.1.38-0ubuntu0.18.04.2] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (disco-proposed/main) [5.0.0-14.15] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: nova (disco-proposed/main) [2:19.0.0-0ubuntu2 => 2:19.0.0-0ubuntu2.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (disco-proposed/main) [5.0.0-14.15] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (disco-proposed/main) [5.0.0-14.15] (core, kernel)
-queuebot:#ubuntu-release- New binary: mariadb-10.1 [i386] (cosmic-proposed/universe) [1:10.1.38-0ubuntu0.18.10.1] (no packageset)
-queuebot:#ubuntu-release- New binary: mariadb-10.1 [amd64] (cosmic-proposed/universe) [1:10.1.38-0ubuntu0.18.10.1] (no packageset)
-queuebot:#ubuntu-release- New binary: mariadb-10.1 [amd64] (bionic-proposed/universe) [1:10.1.38-0ubuntu0.18.04.2] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (disco-proposed) [5.0.0-14.15]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (disco-proposed) [5.0.0-14.15]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (disco-proposed) [5.0.0-14.15]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (cosmic-proposed) [4.18.0-19.20]
-queuebot:#ubuntu-release- New binary: mariadb-10.1 [ppc64el] (cosmic-proposed/universe) [1:10.1.38-0ubuntu0.18.10.1] (no packageset)
-queuebot:#ubuntu-release- New binary: mariadb-10.1 [ppc64el] (bionic-proposed/universe) [1:10.1.38-0ubuntu0.18.04.2] (no packageset)
-queuebot:#ubuntu-release- New binary: mariadb-10.1 [i386] (bionic-proposed/universe) [1:10.1.38-0ubuntu0.18.04.2] (no packageset)
-queuebot:#ubuntu-release- New binary: mariadb-10.1 [arm64] (cosmic-proposed/universe) [1:10.1.38-0ubuntu0.18.10.1] (no packageset)
-queuebot:#ubuntu-release- New binary: mariadb-10.1 [armhf] (bionic-proposed/universe) [1:10.1.38-0ubuntu0.18.04.2] (no packageset)
-queuebot:#ubuntu-release- New binary: mariadb-10.1 [arm64] (bionic-proposed/universe) [1:10.1.38-0ubuntu0.18.04.2] (no packageset)
<bdmurray> Why aren't disco-proposed versions showing up here? http://autopkgtest.ubuntu.com/packages/ubuntu-release-upgrader/disco/amd64
-queuebot:#ubuntu-release- New binary: mariadb-10.1 [armhf] (cosmic-proposed/universe) [1:10.1.38-0ubuntu0.18.10.1] (no packageset)
#ubuntu-release 2019-04-26
<xnox> bdmurray, it looks lost to me. Neither in results nor in /running
<xnox> bdmurray, re-request to rerun them?!
<ddstreet> bdmurray i understand what the 'ppa' and 'upstream' autopkgtest.u.c queues are, and i think the 'ubuntu' queue, but what's the 'huge' queue?
<xnox> ddstreet, ubuntu, but when a single upload triggers more than X number of package tests (10?) then it goes into huge queue for scheduling purposes.
<bdmurray> xnox: the tests are running if you look at excuses - https://people.canonical.com/~ubuntu-archive/proposed-migration/disco/update_excuses.html#ubuntu-release-upgrader they just aren't showing up
<ddstreet> xnox aha ok thnx :)
<xnox> i.e. such that things that only trigger a few tests, sail through a bit quicker.
<xnox> bdmurray, yes.... a classic indication of forgotten.
<xnox> bdmurray, cause there is nothing on  http://autopkgtest.ubuntu.com/running for it to be, in fact, running.
-queuebot:#ubuntu-release- Unapproved: s390-tools (xenial-proposed/main) [1.34.0-0ubuntu8.9 => 1.34.0-0ubuntu8.10] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ubuntu-report (disco-proposed/main) [1.4.1 => 1.4.2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: ubuntu-report (bionic-proposed/main) [1.3.0~18.04 => 1.3.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pentobi (disco-proposed/universe) [16.2-1 => 16.2-1ubuntu0.1] (no packageset)
<Laney> xnox: don't give false advice please. tests *should not* get lost and we want to know about it if that happens. there's a lag between results finishing and the website being updated (https://trello.com/c/8XSNcbDH/11-update-information-on-the-web-faster) which probably explains this one
<Laney> bdmurray:
<Laney> britney is not subject to that lag, so the next time it refreshes it gets the results
<Laney> just turned more jobs back on
<Laney> 20 per arch now
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (disco-proposed/main) [2.578 => 2.578.1] (desktop-core)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1043.47] (kernel)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (cosmic-proposed/main) [2.542.1 => 2.542.2] (desktop-core)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1043.47]
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.20 => 2.525.21] (desktop-core)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (trusty-proposed/main) [4.15.0-1043.47~14.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (trusty-proposed) [4.15.0-1043.47~14.04.1]
<xnox> Laney, hm. it's just the date of the test is like 21:22 utc, and it was not visible on http://autopkgtest.ubuntu.com/packages/ubuntu-release-upgrader/disco/amd64 at like midnight :40 UTC. I am aware of the lag... but i guess the lag is much longer than the "typical" 5..30min.
<Laney> no way to check when it was published I'm afraid
<Laney> but, lost jobs: we want to know
<Laney> you can skip the web interface entirely if you do URL hacking e.g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/?format=plain&prefix=disco/amd64/u/ubuntu-release-upgrader/
<xnox> ack
<Laney> I've ramped autopkgtest back up
<Laney> going out for a bit now, will check back in later, hopefully it can cope with this
-queuebot:#ubuntu-release- New: accepted mariadb-10.1 [amd64] (cosmic-proposed) [1:10.1.38-0ubuntu0.18.10.1]
-queuebot:#ubuntu-release- New: accepted mariadb-10.1 [armhf] (cosmic-proposed) [1:10.1.38-0ubuntu0.18.10.1]
-queuebot:#ubuntu-release- New: accepted mariadb-10.1 [ppc64el] (cosmic-proposed) [1:10.1.38-0ubuntu0.18.10.1]
-queuebot:#ubuntu-release- New: accepted mariadb-10.1 [arm64] (cosmic-proposed) [1:10.1.38-0ubuntu0.18.10.1]
-queuebot:#ubuntu-release- New: accepted mariadb-10.1 [s390x] (cosmic-proposed) [1:10.1.38-0ubuntu0.18.10.1]
-queuebot:#ubuntu-release- New: accepted mariadb-10.1 [i386] (cosmic-proposed) [1:10.1.38-0ubuntu0.18.10.1]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (cosmic-proposed/main) [4.18.0-1010.11] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-147.173] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (disco-proposed/main) [5.0.0-1005.5] (core, kernel)
-queuebot:#ubuntu-release- New source: dogtag-pki (eoan-proposed/primary) [10.6.10-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-147.173]
-queuebot:#ubuntu-release- Unapproved: ceph (bionic-proposed/main) [12.2.11-0ubuntu0.18.04.1 => 12.2.11-0ubuntu0.18.04.2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (disco-proposed) [5.0.0-1005.5]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (cosmic-proposed) [4.18.0-1010.11]
<ddstreet> sil2100 do you know what's going on with the mariadb-10.1 autopkgtests?  update_excuses says it's "missing build"...?
<ddstreet> mariadb-10.1 for bionic, that is, cosmic seems to be working ok
<juliank> Laney: multiple worker WIP https://code.launchpad.net/~juliank/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/366571
<juliank> very early, just the basics
<sil2100> ddstreet: ah!
<sil2100> ddstreet: crap, I approved the binaries for cosmic but didn't for bionic
<sil2100> duuuh
 * teward finger-wags at sil2100
<ddstreet> ah ok, was this the very first non-security update for it in bionic and cosmic?  wow
<teward> all those gosh darn binaries xD
<teward> ddstreet: might take a while to even get to the migrateable state though - AFAICT autopkgtests are still bleh
<teward> which reminds me I see other autopkgtests have completed, any way to see where in the autopkgtest queue some of the nginx-triggered ones are?
<teward> or if they got 'killed' and forgotten?
<ddstreet> yep, i'll check on it again next week, give it some time :)
<sil2100> ddstreet: no no, it's because this added the new binaries, so those are in binNEW
<sil2100> Ok, bionic now also approved
<ddstreet> thnx!
-queuebot:#ubuntu-release- New: accepted mariadb-10.1 [amd64] (bionic-proposed) [1:10.1.38-0ubuntu0.18.04.2]
-queuebot:#ubuntu-release- New: accepted mariadb-10.1 [armhf] (bionic-proposed) [1:10.1.38-0ubuntu0.18.04.2]
-queuebot:#ubuntu-release- New: accepted mariadb-10.1 [ppc64el] (bionic-proposed) [1:10.1.38-0ubuntu0.18.04.2]
-queuebot:#ubuntu-release- New: accepted mariadb-10.1 [arm64] (bionic-proposed) [1:10.1.38-0ubuntu0.18.04.2]
-queuebot:#ubuntu-release- New: accepted mariadb-10.1 [s390x] (bionic-proposed) [1:10.1.38-0ubuntu0.18.04.2]
-queuebot:#ubuntu-release- New: accepted mariadb-10.1 [i386] (bionic-proposed) [1:10.1.38-0ubuntu0.18.04.2]
<juliank> Now it needs implementing leader-elected and leader-settings-changed to enable/disable the cron job for image building
<juliank> ok, this looks better
<teward> vorlon: mwhudson: I see the status on the SRU for OpenSSL was changed to "Fix Released" but only for the 'main' task and not the Bionic one.  I assume that this is just to indicate that the OpenSSL in $DEVEL is already at that version, and I should pay attention to the Bionic task specifically?
<juliank> So, what we're missing (if everything else works) is spreading the number of cloud workers - gotta figure out how many instances of the charm there are
<juliank> also spreading out N units across K hosts, and N//K*K potentially being < N
<juliank> 5 workers across 2 hosts and 2 per host we end up with 4
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (disco-proposed/main) [1.10ubuntu5 => 1.10ubuntu5.1] (core)
-queuebot:#ubuntu-release- Unapproved: ubuntustudio-controls (disco-proposed/universe) [1.7 => 1.7.1] (ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (cosmic-proposed/main) [1.5ubuntu3.18.10.3 => 1.5ubuntu3.18.10.4] (desktop-core, ubuntu-server)
#ubuntu-release 2019-04-27
<vorlon> fwiw I'm rebooting the autopkgtest master to see if that helps with the i/o issues (the system has been up for quite a while and I don't know that I trust the kernel).  However I didn't count on systemd insisting on nuking all of /tmp on boot before it lets me back in, and that's where all of the autopkgtest units' working files are, so it'll be a while before it's back up
<vorlon> (hopefully it'll come back before I timeout and have to go to bed, but there's really no telling at this point)
<vorlon> Laney, juliank: ^^ I have no idea, maybe it'll come up and be healthy, or maybe it'll need some babysitting when it comes up (to kill off instances left running?), but I can't stay up to wait for it indefinitely; if either of you happen to be at keyboard today when it comes up and want to have a look, great, otherwise I'll check in in ~8h
<Laney> vorlon: might be around a bit later on (out for a few hours now). fwiw (if rebooting doesn't help), if you reduce parallelism to say 5 units per arch then it'll probably decrease load enough to be able to chew through the chunky jobs, and it can then be increased again afterwards
<juliank> everything seems ok
<juliank> 163 tar processes running, fun, but machine is responsive
<Laney> check if the big jobs (binutils, libreoffice, chromium, k*) are actually being processed rather than timing out repeatedly
<Laney> if you see them bunched up copying back to the controller, that is a suspicious sign
<Laney> maybe watch journal for a bit to see what's actually going on
 * Laney out again
<juliank> I see exceed quota, but no timeouts so far, will look in from time to time
<juliank> Ah I think the chromium ones are running right now
<juliank>                                                                                                                 autopkgtest [09:49:23]: ERROR: testbed failure: sent `copyup /tmp/autopkgtest.7oD5ck/build.OEX/src/ /tmp/autopkgtest-work.emdsp_b7/out/tests-tree/', got `timeout', expected
<juliank> yeah, so did not help
<juliank> I guess decreasing parallelity it is
<juliank> * parallelism
<acheronuk> juliank: it did a few days ago. bigger questions is though why this problem now? the infra did used to cope. granted that some things slowed progress a fair bit, but there was not this timeout -> respawn job to front of queue paralysis. somthing on the test machines/infra/whatever has regressed
<juliank> acheronuk: I don't know
<juliank> acheronuk: I did decrease #workers to 5 per-arch
<juliank> and it seems we reduced tar processes by 50%
<juliank> I/O load hence seems lower now, which should hopefully mean we don't timeout copying anymore
<juliank> What I think we'd have to do is ensure that we only have a certain number of needs-build jobs running at the same time
<juliank> even ls /tmp works now
<juliank> it might be useful splitting that up a bit
<juliank> /tmp/autopkgtest-{fifo,work,ssh}.$randomstring
<juliank> we have that for each running autopkgtest
<juliank> that means /tmp has a lot of files in that dir
<juliank> it might make sense to build hierarchies
<juliank> e.g. /tmp/autopkgtest-{fifo,ssh,work}.1rdoc1m_ => /tmp/autopkgtest.1r/do/c1/m_/autopkgtest-{fifo,ssh,work}.1rdoc1m_
<juliank> like git does
<juliank> to not have that dir grow to a huge ton of entries
<juliank> we should see whether chromium copy worked in ~ 40 mins
<acheronuk> juliank: fine. but fact remains that this is a recent phenomena, or one whose severity and prevalence has dramatically increased lately
<acheronuk> now I think on it, I did notice that towards the end of disco cycle, some jobs did appear to struggle
<acheronuk> e.g kwin, and plasma-workspace jobs did start to at some time seem to stall for hrs, then restart, without any explanation to me where all I could do was look at user facing logs
<acheronuk> annoying, but only occasional, even when the infra was very loaded up with K* tests, and they mostly did finish the apparent subsequent go, so I did not flag it up
<acheronuk> it is possible other *BIG* tests not KDE did the same, but I did not watch those
<acheronuk> however, something has changed recently that means that, this is now more likely than not under load, and hitting a wider range of tests
<acheronuk> anyway. that is how I have observed things change recently (and I do watch a lot when many KDE tests are queued), whatever that means
<juliank> I'm sorry to inform you that copying timed out again
<juliank> oh, but one succeeded
<juliank> (of chromium-browser/s390x)
<juliank> ah no, arm64 succeeded, s390x timed out
<juliank> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/arm64/c/chromium-browser/20190427_115905_661f8@/log.gz
<juliank> wooho
<juliank> why am I not raising the copy timeout?
<juliank> it would be better than retrying again and again
<juliank> but it already is a 100 mins, so...
<juliank> it seems likely raising it by 20 mins solves some of those issues
<juliank> I increased it by 20 mins, and requested restarts once current jobs are complete
<juliank> FWIW, solving this means setting up a second cloud worker, which probably means we should do a staging cloud worker first
<juliank> that's in progress, but will probably take some time
<Laney> acheronuk: can you please stop theorising that something changed and we're missing it?
<Laney> it's simply not true (we have in fact had this problem before)
<Laney> the last time was when we created the card to work on the parallelism stuff that juliank has been doing this week
<Laney> juliank: WDYT about tagging some of the messages from the worker with their type? So we can just see like acknowledged/received request messages or something
<Laney> . o O ( journalctl ADT_MESSAGE_TYPE=ack ADT_MESSAGE_TYPE=upload ADT_MESSAGE_TYPE=running-autopkgtest ... )
<acheronuk> Laney: no, I will not. as things have clearly regressed. stating that fact is not theorising
<acheronuk> if it it a recurring problem that occurred at a time when I was not aware, then obviously it is relevant to look at what circumstances are similar to now
<acheronuk> however no matter what you say, it is a clear regression over behaviour during the vast majority of the time I have ever observed behaviour if the tests
<acheronuk> Laney: sorry. I am just trying to be helpful, by adding my observational input as I tend to tarck the running tests quite closely when mine are in play. only as in the spirit of trying to add data to help sort this
<acheronuk> *tend to track
<juliank> Laney: hmm, not sure how useful that would be, then you need to find the unit to query context
<juliank> Laney, acheronuk FWIW, there do not seem to be any timeouts anymore AFACIT
<juliank> it's been about 4 hours now, so I'd hope that's useful data
<acheronuk> juliank: :)
<juliank> FWIW, a cron job ran and failed to send email https://pastebin.canonical.com/p/VmZgzBCG9y/
<Laney> acheronuk: I'll say it as clearly as I can, one last time: your input is not needed here.
<Laney> juliank: thanks, just taking aAAAAAAAaaaaaaaaaaaaages for things to run
<acheronuk> Laney: I will says it as clearly as I can, I am just adding observations that you are ignoring in the spirit of trying to help worl out how they hell to get past this
<acheronuk> as I have a vested interest in how this goes, I will not stay quiwt when it seems they are being overlooked
<Laney> We don't need external observations. We have internal ones. We're doing all we can. Thanks.
<acheronuk> Laney: I appreciate that. I am not trying to be awkward deliberately. I want this sorted as much as anyone
<acheronuk> frustration with the current situation, and an apparent mismatch between the the 'explained situation" and observed reality, means I feel the need to at least say so
<acheronuk> I will try to dial back the 1st, but the 2nd I will still query. Politely of course
<acheronuk> thank you for helping
<Laney> OK, thanks for that. I've not been involved in any conversations about this outside of here, FWIW, but it may be difficult to follow.
<Laney> What happens is that autopkgtest-virt-ssh runs copy the source tree back to the controller, so that it can be sent to new instances, if the tests require them. If the test has Restrictions: build-needed, that is a *built* source tree.
<Laney> These jobs have a timeout (--copy-timeout).
<Laney> We can very rarely get into an unlucky situation where lots of jobs (we run more than a hundred workers in parallel normally, I think) are doing this copying stage at the same time. The machine has limited IO and network bandwidth, and if this gets capped out then the transfers start becoming very slow indeed.
<Laney> Then the job hits the copy timeout and is restarted.
<Laney> If one is going slowly then they're all going slowly, so they are all likely to timeout.
<Laney> Then they start copying again and the same problem occurs. It's difficult to get out of that hole once you're in it.
<acheronuk> yes, that is something I gathered from the last week's discussions. thanks
<Laney> So we've reduced parallelism so that fewer of these copy jobs are happening simultaneously, meaning that they can actually complete.
<acheronuk> why are we hitting that now, when we did not before during even high load of build needed jobs?
<Laney> If a log says "Removing autopkgtest-satdep (0) ..." or something like that, then it's actually doing the copy. autopkgtest doesn't ATM output anything in that case.
<Laney> Accident of timing in a way that is bad enough to make it happen. It's happened only once before to my knowledge. Usually things wouldn't line up in a way to make this problem happen - the copying is fast in the normal case, and so jobs don't tend to starve each other.
<Laney> It's only relatively few packages are actually large enough to be noticable in this way
<Laney> e.g. check that there are loads of libreoffice jobs running now - that's one of them
<acheronuk> 'accident of timing' does not seem right. there are many occasions when I have landed KDE stuff all at once, requiring that and have not seen this happen
<acheronuk> Laney: true. I did note the bazillion libreoffice jobs!
<Laney> It is right.
<Laney> Almost all of the time we manage to slip these copying operations past each other, but if enough packages lose the race with each other then there's this storm effect
<Laney> It's why juliank's work on being able to split the controller into multiple is probably going to help, since then copy jobs won't fight with each other so much
<acheronuk> so why has this happened twice on the last week, and not in the many KDE* uploads I have done in the past?
<Laney> It's not twice this week, it's the same one
<Laney> I shouldn't have turned the parallelism back up before the problem was fully drained
<Laney> KDE alone probably isn't enough to trigger it; this time we had binutils, libreoffice Ã many, chromium, ... at the same time
<Laney> all of those are the very chunky packages
<Laney> Gotta go now, hope that helps
<acheronuk> Laney: ok. I am still surprised if that is true that had not hit that before during the time I have been doing this, but hey odd things happen
<vorlon> Laney, juliank: independent of whether we need to increase the number of dispatcher instances, I think the copy timeout handling is clearly pathological; it makes sense to have a timeout to detect a dead worker, but to deal with a slow transfer by killing the jo and starting all over just makes the storm worse (and from what I've seen, neither the instances nor the transfers are stopped when the
<vorlon> timeout is hit)
<vorlon> it would be saner to just let the copies complete, however long they take, instead of restarting them and ensuring they never complete
<vorlon> looks like ppc64el and s390x queues are empty now, so I'm going to bump the number of runners on the remaining archs to 8 so that they complete faster
<juliank> vorlon: Probably should just warn about copy timeouts in cron job somehow rather than fail
<juliank> "Oh, this tar process has been running for 2 hours"
<juliank> probably want to ionice this to a lower priority after like 2 hous so that other jobs can work while long copies are going on
<vorlon> hmm, I'm not sure ionice would improve the overall throughput... since in most cases where this becomes an issue, it's because most of your units are all stuck in this state of doing source tree copies
<Laney> Maybe.
<Laney> Increasing the timeout might be sensible. Having jobs which take interminably long to run because they're copying at 1KB/s, hmm...
<Laney> A backoff solution might actually provide for better throughput.
<Laney> Looks like one hump might be over, but it's too late for me to decide whether to increase workers now...
#ubuntu-release 2019-04-28
<vorlon> I'm cranking arm64/i386/amd64 up to full blast, given the remaining queue contents don't look like they should be i/o bound
<vorlon> and I'll check in again before I turn in for the night
<juliank> woohoo, all queues seem empty
<juliank> * autopkgtest queues
<vorlon> yep! now I move on to trying to figure out why the heck busybox ftbfs on s390x in Ubuntu but not Debian :P
-queuebot:#ubuntu-release- Unapproved: cockpit (disco-backports/universe) [189-1 => 192-1~ubuntu19.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cockpit (cosmic-backports/universe) [189-1~ubuntu18.10.1 => 192-1~ubuntu18.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (cosmic-backports) [192-1~ubuntu18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (disco-backports) [192-1~ubuntu19.04.1]
-queuebot:#ubuntu-release- Unapproved: cockpit (bionic-backports/universe) [189-1~ubuntu18.04.1 => 192-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (bionic-backports) [192-1~ubuntu18.04.1]
<acheronuk> did a email ever get sent saying eoan was open? I can't see one anywhere in a place I would expect
-queuebot:#ubuntu-release- New binary: gcc-9-cross [amd64] (eoan-proposed/main) [4ubuntu5] (ubuntu-desktop)
<xnox> vorlon, well we are higher gcc abi level than debian.... zEC12 (us) vs z196 (debian)
-queuebot:#ubuntu-release- New binary: gcc-9-cross-ports [amd64] (eoan-proposed/universe) [3ubuntu5] (no packageset)
<juliank> acheronuk: don't think so. It was never really closed (opening was super quick), though, but yes, it would probably be a good idea.
#ubuntu-release 2020-04-20
<xnox> apw: https://bugs.launchpad.net/bugs/1845801 how come nvidia-drm.modeset=1 not the default? Also I think my laptop hangs on boot too, as described in the bug.
<ubot5> Ubuntu bug 1845801 in nvidia-graphics-drivers-435 (Ubuntu Eoan) "[nvidia] Automatic login fails and then all subsequent logins fail. Killing gnome-session-binary fixes it, or just not using automatic login." [Low,Confirmed]
<xnox> For me gdm hangs / never comes up.
<xnox> Also, failing to boot any arm64 images off usb.
-queuebot:#ubuntu-release- Unapproved: sugar-artwork (focal-proposed/universe) [0.116-1 => 0.117-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted sugar-artwork [sync] (focal-proposed) [0.117-1]
-queuebot:#ubuntu-release- Unapproved: sugar-toolkit-gtk3 (focal-proposed/universe) [0.116-6 => 0.117-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted sugar-toolkit-gtk3 [sync] (focal-proposed) [0.117-1]
-queuebot:#ubuntu-release- Unapproved: subtitleeditor (focal-proposed/universe) [0.54.0-3build1 => 0.54.0-4] (ubuntustudio) (sync)
-queuebot:#ubuntu-release- New sync: simde (focal-proposed/primary) [0.0.0.git.20200415-1]
<RAOF> xnox: Hm. For me, *setting* `nvidia-drm.modeset=1` resulted in all manner of broken behaviour (that was a hybrid system). This might be a hybrid/not-hybrid problem?
<xnox> Rao
<xnox> RAOF: with or without splash? And on Focal, right?
<RAOF> With splash, on focal.
<RAOF> But earlier in the cycle, and my hybrid laptop decided to die.
<RAOF> My bug was that starting X as non-root would silently fall *unless* there was an existing instance of X started as root already running.
<RAOF> Hm, now that I think if it maybe that *wasn't* focal. My laptop died earlier than that. Must have been eoan.
-queuebot:#ubuntu-release- Unapproved: rejected ruby2.7 [source] (focal-proposed) [2.7.0-5ubuntu1]
<handsome_feng> Hi, Does wallpaper changes need UIFe (Not the default wallpapers) ?
<handsome_feng> If add a new wallpaper need UIFe , can I just drop a wallpaper which have license problem?
-queuebot:#ubuntu-release- Unapproved: ruby2.7 (focal-proposed/main) [2.7.0-4ubuntu1 => 2.7.0-5ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: yubioath-desktop (focal-proposed/universe) [5.0.2-3 => 5.0.3-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted yubioath-desktop [sync] (focal-proposed) [5.0.3-1]
-queuebot:#ubuntu-release- Unapproved: ubuntukylin-wallpapers (focal-proposed/universe) [20.04.1 => 20.04.2] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: ruby2.7 (focal-proposed/main) [2.7.0-4ubuntu1 => 2.7.0-5ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: boinc (focal-proposed/universe) [7.16.6+dfsg-1 => 7.16.6+dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: sass-spec (focal-proposed/universe) [3.6.3-1.1 => 3.6.3-1.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted boinc [sync] (focal-proposed) [7.16.6+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: ruby2.7 (focal-proposed/main) [2.7.0-4ubuntu1 => 2.7.0-5ubuntu1ppa1] (i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: accepted sass-spec [sync] (focal-proposed) [3.6.3-1.1]
<LocutusOfBorg> of course the ruby2.7 ubuntu1ppa1 was meant to my ppa, not sure why dput allows me to upload on ubuntu :/ /me grabs coffee
<wgrant> LocutusOfBorg: Morning. I actually already uploaded symbol fixes based on your failed build, now waiting in the queue. Built fine everywhere in https://launchpad.net/~wgrant/+archive/ubuntu/nonvirt/+sourcepub/11195715/+listing-archive-extra
<LocutusOfBorg> nice!
<wgrant> LocutusOfBorg: Mind if I reject your two?
<wgrant> Or at least the ppa1 one :)
<LocutusOfBorg> sure!
-queuebot:#ubuntu-release- Unapproved: rejected ruby2.7 [source] (focal-proposed) [2.7.0-5ubuntu1ppa1]
<sil2100> Wimpress: hello! Can you give me the powers to update that discourse thread? ;)
-queuebot:#ubuntu-release- Unapproved: rejected ruby2.7 [source] (focal-proposed) [2.7.0-5ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected ruby2.7 [sync] (focal-proposed) [2.7.0-5]
<philroche> Wimpress: Me too please
<sil2100> apw: hey! We seem to have a few NBSes related to kernels right now
<mwhudson> LocutusOfBorg: i have a dput wrapper that stops me doing things like that
<mwhudson> LocutusOfBorg: https://github.com/mwhudson/dput-wrap
<philroche> Morning all. I am testing hyperv desktop image builds in prep for release and build is failing due to `gamemode:amd64 Depends on libinih1:amd64 < none @un H > (>= 48) can't be satisfied!` I cannot replicate this issue locally on focal install. Is anyone aware of dependency issues with 'gamemode' package?
<sil2100> tjaalton: hey! I see the new linux-oem-5.6 kernel is still blocked in -proposed, any ETA for getting it into release?
<sil2100> philroche: hm, not that I am aware of, no
-queuebot:#ubuntu-release- Unapproved: wireshark (focal-proposed/universe) [3.2.2-1 => 3.2.3-1] (no packageset) (sync)
<philroche> sil2100: ack. I'll keep digging
-queuebot:#ubuntu-release- Unapproved: accepted wireshark [sync] (focal-proposed) [3.2.3-1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntukylin-wallpapers [source] (focal-proposed) [20.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.policy [source] (focal-proposed) [3.1.0-0ubuntu1]
<tjaalton> sil2100: well, I wonder if it could be a post-release update, sort of like being a part of the current sru cycle while in reality it's a devel series kernel.. but I can also check if it could be released soon and included in the image
<tjaalton> dkms tests failing because it's 5.6, it seems
<tjaalton> thought I marked them failing for good, but apparently not
<apw> sil2100, ack
<xnox> philroche:  are you building "main-only" or "with-universe enabled"? I see that gamemode is currently in main, but not seed, and thus wants to be demoted. And libinih1 is only available in universe. Also gamemode is up for demotion at https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.html
<xnox> philroche:  should gamemode be in main, if it's seeded in the hyperv image? then we need to added to either like desktop-supported or cloud-supported?
<sil2100> tjaalton: ok, let's leave it in -proposed then
<seb128> xnox, gamemode was added to desktop-minimal on friday
<seb128> xnox, philroche, I will fix it, I overlooked that libinih was in universe when I did the gamemode update that enabled it as a depends
<xnox> seb128:  sure. but i'm trying to understand why components-missmatches wants to demote it. as if the seed change is stuck somewhere
<sil2100> Ok everyone, we're currently waiting for some staged packages to migrate out of -proposed (like glibc etc.)  and then we'll be spinning our first release candidates
<cjwatson> ddebs.u.c has caught up
<LocutusOfBorg> mwhudson, thanks, why not integrate on dput upstream?
<mwhudson> LocutusOfBorg: too lazy!
<LocutusOfBorg> converting into a dput profile!
<mwhudson> LocutusOfBorg: is that a dput-ng thing?
<mwhudson> sil2100: eta on that?
 * mwhudson wonders about a quick subiquity snap build and promote
<sil2100> mwhudson: anything critical in that?
<sil2100> Some saucy fixes?
<mwhudson> sil2100: some autoinstall bugfixes
<LocutusOfBorg> probably yes mwhudson
<Laney> vorlon: I'll let the team know
<sil2100> mwhudson: it's all tested, right? Guess build+promote is quite fast, to what I would say: yes
<mwhudson> sil2100: tested, let's say that i'm confident that it's better than what's in stable/ubuntu-20.04 right now
<LocutusOfBorg> mwhudson, probably "hooks" or similar
<LocutusOfBorg> meh, who remembers?
<sil2100> Since though glibc just migrated, there's the kylin wallpaper package that I think I'd still like to have that in the release
<sil2100> mwhudson: go for it!
<mwhudson> LocutusOfBorg: i certainly never figured it out, which is why it's a perl wrapper still!
<xnox> seb128:  running germinate locally results in: ? Unknown desktop-minimal package: gamemode
<xnox> seb128:  no idea, why
<mwhudson> sil2100: turns out the automatic import github -> lp ran at exactly the right time so the snap was already building
<philroche> xnox universe appears to be enabled
<philroche> seb128: Thank you
-queuebot:#ubuntu-release- Unapproved: accepted lubuntu-meta [source] (focal-proposed) [20.04.7]
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (focal-proposed) [1:0.9]
-queuebot:#ubuntu-release- Unapproved: ubiquity-slideshow-ubuntu (focal-proposed/main) [159 => 160] (ubuntu-desktop)
<seb128> handsome_feng, ^
<Laney> argh
<seb128> the upload fixes bug #1873543
<ubot5> bug 1873543 in ubiquity-slideshow-ubuntu (Ubuntu) "The version 159 revert the translations of ubuntukylin" [High,In progress] https://launchpad.net/bugs/1873543
<Wimpress> Morning all o/
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice-dictionaries [sync] (focal-proposed) [1:6.4.3-1]
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity-slideshow-ubuntu [source] (focal-proposed) [160]
<xnox> seb128:  ok, updated my mirror, and now germinate is happy with everything. still no idea about components-missmatches
<handsome_feng> seb128: Thanks!
-queuebot:#ubuntu-release- Unapproved: rejected spirv-headers [sync] (focal-proposed) [1.5.1+git20200409-1]
-queuebot:#ubuntu-release- Unapproved: rejected vulkan-loader [sync] (focal-proposed) [1.2.135.0-2]
-queuebot:#ubuntu-release- Unapproved: rejected spirv-tools [sync] (focal-proposed) [2020.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted python-launchpadlib [sync] (focal-proposed) [1.10.13-1]
<mwhudson> sil2100: subiquity published to the appropriate places
<sil2100> mwhudson: \o/
-queuebot:#ubuntu-release- Unapproved: gamemode (focal-proposed/main) [1.5.1-0ubuntu2 => 1.5.1-0ubuntu3] (no packageset)
<seb128> ^ that fixes the gamemode issue trying to pull a lib from universe than philroche reported a bit earlier than is breaking hyperv images (and probably problematic for Ubuntu builds as well)
<seb128> the diff is non trivial but it's basically reverted the recent .1 upload changes and going back to the codebase that was reviewing during the MIR
<philroche> seb128: Thanks. I'll verify once it's accepted
<xnox> doko:  bzr branch lp:ubuntu-archive-scripts: ./auto-accept debug => should say why things are not getting auto-accepted.
<xnox> doko:  but also i guess comment out queue accept call at the end of it, just in case it uses your AA powers.
<sil2100> seb128: hey! Could you upload it with the patch having a description of what's going on? Since we'll just be confused if we look at it in the future
<seb128> sil2100, I could, I do plan to revert than change in g* when it opens, we just need to MIR libinih
<seb128> it feels late to do that now in focal though
<cjwatson> "./auto-accept debug"> kinda needs actual option parsing
<cjwatson> Could easily enough be ./auto-accept --debug --dry-run
<xnox> Laney:  cjwatson: yeah, we can't figure out why gcc-snapshot was not auto-accepted, we thought that it should be, despite being in the "i386" seed.
<xnox> or is auto-accept off at this point?
<Laney> no it's not
<sil2100> seb128: ok, if you could upload then we'd accept that one, I'll reject the one without a patch comment
<alexaf> Hello people. I intend to create a local mirror of Ubuntu Focal after it's officially released. Is there a way to get an estimate of the needed disk space? Thanks
<seb128> sil2100, ok, that's for you paperwork lovers :)
-queuebot:#ubuntu-release- Unapproved: gamemode (focal-proposed/main) [1.5.1-0ubuntu2 => 1.5.1-0ubuntu3] (no packageset)
<seb128> sil2100, ^ enjoy
<sil2100> seb128: thank you!
<seb128> sil2100, yw!
-queuebot:#ubuntu-release- Unapproved: rejected gamemode [source] (focal-proposed) [1.5.1-0ubuntu3]
<sil2100> seb128: oh, one more thing, should we still build dep on libinih* there?
<seb128> sil2100, I'm unsure, I went for minimal risk and just revert to what we had in Debian/the archive for cycles
<doko> apw, sforshee, wgrant: can linux-riscv64 be demoted, or should it be seeded?
<sil2100> seb128: hm, ok
<sil2100> Makes sense
<seb128> sil2100, it's probably not needed no but I didn't want to start doing cleanups and risk introducing another problem because I overlooked something
-queuebot:#ubuntu-release- Unapproved: accepted gamemode [source] (focal-proposed) [1.5.1-0ubuntu3]
<seb128> opinion on syncing glib-networking from https://packages.qa.debian.org/g/glib-networking/news/20200417T084838Z.html ?
<Laney> seb128: file an SRU bug, include the bug reference
<seb128> it feels a bit late but it has basically one commit which is ' Reenable TLS 1.0/1.1 due to COVID-19 '
<seb128> Laney, do you want to maybe consider it for release? if not I just put that lower on my todo, SRUs can wait
<Laney> I mean maybe, if it's in the queue we can decide later
<seb128> k, I will deal with some other things before and see if I find the motiviation to do the SRU paperowrk after lunch :)
<doko> binutils-riscv64-linux-gnu still wants to demote, component-mismatches still doesn't include riscv64
<xnox> seb128:  we re-enabled it in Firefox, Chrome, Chromium, so humans can access covid websites. Are there any human visible browsers that use glib-networking?
<xnox> doko:  i think linux-riscv64 should be seeded
<seb128> xnox, yes, the GNOME one (epiphany-browser)
-queuebot:#ubuntu-release- Unapproved: glib-networking (focal-proposed/main) [2.64.1-1 => 2.64.2-1build1] (i386-whitelist, ubuntu-desktop)
<seb128> ^ k, in between option, uploaded with a bug reference but the bug isn't SRU compliant yet but that way it can be made later if needed
<seb128> (also I uploaded the wrong one first so rejected/uploaded again)
-queuebot:#ubuntu-release- Unapproved: rejected glib-networking [source] (focal-proposed) [2.64.2-1build1]
-queuebot:#ubuntu-release- Unapproved: glib-networking (focal-proposed/main) [2.64.1-1 => 2.64.2-1build1] (i386-whitelist, ubuntu-desktop)
<xnox> doko:  updated seeded kernel packages with audio review from apw https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/commit/?id=c0e59184d807f50ec6f89d3800758691fda1b601
-queuebot:#ubuntu-release- Unapproved: rejected qemu [source] (focal-proposed) [1:4.2-3ubuntu6]
<xnox> doko:  gcc-snapshot lack of auto-accept fix is in https://code.launchpad.net/~xnox/ubuntu-archive-scripts/auto-accept-i386-only-packages/+merge/382569
<sil2100> Ok everyone! The britney -proposed freeze block is now ON
<xnox> boom
<doko> xnox: add community-maas there as well?
-queuebot:#ubuntu-release- Unapproved: qemu (focal-proposed/main) [1:4.2-3ubuntu5 => 1:4.2-3ubuntu6] (ubuntu-server, virt)
<xnox> doko:  probably
<xnox> doko:  still need to fix community-missmatches for community stuff
<philroche> seb128: xnox: Thank you both. Desktop hyperv images now successfully build.
<seb128> philroche, great!
-queuebot:#ubuntu-release- Unapproved: accepted faudio [sync] (focal-proposed) [20.04-2]
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (focal-proposed) [6.0.0-0ubuntu8]
-queuebot:#ubuntu-release- Unapproved: accepted virglrenderer [source] (focal-proposed) [0.8.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (focal-proposed) [1:4.2-3ubuntu6]
<xnox> doko:  https://code.launchpad.net/~xnox/ubuntu-archive-tools/riscv64/+merge/382573 fixing up adding riscv64 to components-missmatches
<Laney> https://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-scripts/trunk/revision/279
<Laney> should fix mysterious non-auto-accepts that somebody was complaining about earlier
<Laney> seb128: gamemode is still in universe, could you promote it please?
<Laney> stgraber: could you add paride (~legovini) to ubuntu-qa-website-devel maybe?
<Laney> we just noticed he's missing some permissions and this seems like the simplest way to grant them
<Laney> huh, component-mismatches is from thursday
<Laney> xnox: is that something to do with you
<xnox> Laney:  thanks, so instead of revieing a branch from me https://code.launchpad.net/~xnox/ubuntu-archive-scripts/auto-accept-i386-only-packages/+merge/382569 you two create your own and merge that
<seb128> Laney, I promoted it on friday, looking at https://launchpad.net/ubuntu/+source/gamemode/+publishinghistory it looks like doko demoted it a bit earlier, unsure why?
<xnox> Laney:  please reject mine one, i guess
<Laney> didn't see it, sorry
<xnox> seb128:  it is in components-missmatches report.
<Laney> see my previous comment ab out component-mismatches
<xnox> doko:  please stop demoting things. something is odd with components-missmatches
<Laney> and I can't reject it, no permissions
-queuebot:#ubuntu-release- Unapproved: sylpheed (focal-proposed/universe) [3.5.1-1ubuntu5 => 3.7.0-6ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted sylpheed [source] (focal-proposed) [3.7.0-6ubuntu1]
-queuebot:#ubuntu-release- New sync: gcc-8-cross (focal-release/primary) [33ubuntu2]
<seb128> Laney, k, promoted again
<seb128> hopefully that doesn't trigger that bug when promoting again makes things vanish (I don't remember the specifics)
-queuebot:#ubuntu-release- New sync: gcc-8-cross-ports (focal-release/primary) [27ubuntu2]
<Laney> don't think that happens any more anyway
<Laney> ok cowboyed a fix for component-mismatche
<Laney> s
<doko> I went over component mismatches this morning. I only saw gamesmode on the list of demotions
<stgraber> Laney: done
<Laney> maybe someone in ubuntu-archive could review https://code.launchpad.net/~xnox/ubuntu-archive-tools/riscv64/+merge/382573 so I can uncowboy it
<Laney> stgraber: cheers!
<Laney> seb128: and thanks for the promotion
<kanashiro> locutus__: thanks for the heads-up about ruby2.7, I didn't notice it failed in riscv64 for instance. However, the changes you proposed FTBFS in armhf due to symbols changes: https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+sourcepub/11195317/+listing-archive-extra
<seb128> Laney, np!
<wgrant> kanashiro: https://launchpadlibrarian.net/475372268/ruby2.7_2.7.0-4ubuntu1_2.7.0-5ubuntu1.diff.gz (from the focal-proposed queue) fixes the build on 32-bit architectures.
<paride> stgraber, thanks!
<kanashiro> wgrant: great, I'll apply those changes in Debian. Thanks!
-queuebot:#ubuntu-release- Unapproved: ddtp-translations (focal-proposed/universe) [20200416.1 => 20200420.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ddtp-translations [source] (focal-proposed) [20200420.1]
<sil2100> vorlon: hey! Was looking at the twisted and pyhamcrest uploads - I see some of the dropped python-twisted- packages have some reverse dependencies that might need dealing with, one is python-cyclone (which I think would be good for removal) but the other is python-tx-tftp, which is a stale main package
<sil2100> (wonder why it's in main, it's not seeded anywhere it seems)
-queuebot:#ubuntu-release- New: accepted gcc-8-cross-ports [sync] (focal-release) [27ubuntu2]
-queuebot:#ubuntu-release- New: accepted gcc-8-cross [sync] (focal-release) [33ubuntu2]
<doko> mwhudson: golang-1.14: subscribed foundations and promoted
<doko> cpaelzer, jamespage: nova-spiceproxy is pulled in from supported-misc-servers. ok to promote?
<doko> the binary
<doko> seb128, Laney: yelp now recommends docbook-xml (universe)
<seb128> doko, feel free to promote docbook-xml, it was in main in xenial and desktop-packages is already subscribed
<doko> seb128: done, including sgml-data
<seb128> doko, thanks
<Laney> merci
<doko> jamespage, coreycb: spice-html5 recommends the websockify binary. ok to promote, or do you want to lower that to a suggests?
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-ubuntu-dock (focal-proposed/main) [67ubuntu20.04.4 => 67ubuntu20.04.5] (ubuntu-desktop)
<cpaelzer> doko: I thought that was promoted in https://bugs.launchpad.net/ubuntu/+source/websockify/+bug/1108935/comments/28
<ubot5> Ubuntu bug 1108935 in websockify (Ubuntu) "[MIR] websockify, spice-html5" [High,Fix released]
<cpaelzer> doko: did it get auto-demoted since then?
<doko> I only see it now on c-m
<cpaelzer> for  nova-spiceprox I guess the answer is yes, but would want jamespage to answer
<sforshee> sil2100, Laney: we have a networking driver bug that we're trying to confirm a fix for (bug 1871182). I don't know that this is hard respin material, but would be good to include if there's an opportunity
<ubot5> bug 1871182 in initramfs-tools (Ubuntu) "[RTL810xE] No ethernet connection" [Undecided,Confirmed] https://launchpad.net/bugs/1871182
-queuebot:#ubuntu-release- Unapproved: systemd (eoan-proposed/main) [242-7ubuntu3.7 => 242-7ubuntu3.8] (core)
<sil2100> sforshee: thanks for the heads up, the fix would be in the kernel then? What is the usual turn-around for a kernel respin?
<sil2100> sforshee: would that be only for the linux kernel or also for linux-oem-5.6 ?
<sforshee> sil2100: yes in the kernel. The build is 8-10 hours, depending on how long armhf takes. oem-5.6 should already be fixed, as the report says 5.5 tests ok
<Laney> I guess it would be good to kick off builds in parallel with verifying the fix
<sforshee> yeah, we can do that
<Laney> ð
<sil2100> popey: hello! Could you give me the power to edit that focal-release-status discourse post? :)
<popey> do you have an account now? I couldn't find you previously
<popey> nvm, found you
<popey> done
<sil2100> popey: thanks! Yeah, I didn't have an account apaprently last time
<philroche> popey: Me too please - for cloud image updates. Discourse username philroche
<popey> you already should have
<popey> i added you 3 days ago
<philroche> popey: I see no option to edit though
<sil2100> popey: hm, I think I still not see teh edit button
<popey> it's at the bottom, next to 3 little dots
<popey> https://imgur.com/a/1Dg3wfg
<sil2100> popey: weird! Don't have that, hm
<popey> one moment
<philroche> Nor me https://usercontent.irccloud-cdn.com/file/XOSBQ6eR/image.png
<sil2100> popey: Brian even screen shared and I don't seem to have that edit thingy nor the pencil on top
<popey> ah, new accounts, you're untrusted newbs :D
<popey> sil2100 try now, refresh the page
<popey> philroche same, try now (although probably not at the same time ;D)
<sil2100> Ah ha!
<sil2100> I have it now!
<popey> huzzah
<sil2100> popey: thanks ;)
<popey> feel free to let me know if any extra rls people need access
<philroche> Bingo. Me too. Thanks popey
<popey> Great Success.
-queuebot:#ubuntu-release- Unapproved: chrony (focal-proposed/main) [3.5-6ubuntu5 => 3.5-6ubuntu6] (core)
<seb128> sil2100, Laney, others: can we get the gnome-shell-extension-ubuntu-dock upload be considered for release? it's a pretty annoying issue which has different side effect on the shell, I'm a bit worried it creates other issue than the one referenced and I would prefer to see the fix in the release if possible
<popey> The vertical monitor issue with tiny icons? Yes. super annoying :)
<seb128> popey, dunno about the tiny icon, but vertical monitor which leads the overview to be like 1/8th of the screen
<popey> https://imgur.com/a/AoQKfFa this
<seb128> popey, https://launchpadlibrarian.net/473594511/Screenshot_20200408_130437-search-bar-half-visible.png is how I saw it when testing
<popey> yes, same
<seb128> by "tiny" you mean 'cut"?
<popey> no, press super, don't search for app, press "All", press super again
<seb128> (just making sure we are talking about the same thing, maybe there is also a problem where icons have the wrong size)
<popey> you'll see no icons until the animation happens
<seb128> k
<popey> well, there's two bugs here, I suspect they're rleated
<cpaelzer> hi release team, can I ask to accept chrony in focal-unapproved please
<seb128> anyway, we agree having the fix would be good :)
<cpaelzer> no need to stall the ISO build by it, but it would be great to get it into -proposed for another potential respin to pick it up
<cpaelzer> sil2100: are you the queue-master right now or can you point me to who I should ping?
<cpaelzer> I have already added a full SRU template to the bug just in case
<cpaelzer> rbalint: thanks for finding and filing BTW
<sil2100> cpaelzer: looking
<popey> sil2100 this. https://www.youtube.com/watch?v=2mZZtClVOSg
 * popey tries to find the bug 
<sil2100> Wow, those are really tiny icons
<sil2100> vorlon: ok, so I had a quick chat with sparkiegeek about the python-txtftp thingy - it's still used, but only the python3 versions, although apparently dropping python-txtftp is non-trivial
<sil2100> vorlon: (the python2 version of it)
<philroche> sil2100: popey: Wimpress: Do any of you know hoe to get edit access on https://wiki.ubuntu.com/FocalFossa/ReleaseNotes ? - currently marked as "Immutable Page"
<bdmurray> philroche: That's something with your account as I can edit it
<popey> philroche logout / login / refresh/ sacrifice a chicken in a pentagram
-queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu10.39 => 237-3ubuntu10.40] (core)
<cpaelzer> popey: your icons seem a bit like the fix to https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1869571 overshoot
<ubot5> Ubuntu bug 1869571 in OEM Priority Project "Vertical dual monitor setup with main monitor on bottom causes overview to only use one eighth of screen" [High,New]
 * philroche goes to find a chicken
<cpaelzer> formerly only half visible, now all fitting but very very small
<popey> cpaelzer yes, this was the bug we would like fixed
<sil2100> vorlon: so basically if we accept your twisted upload, this would potentially make python-tx-tftp unbuildable (and the python-txtftp binary uninstallable)
<Laney> maybe move talk of desktop bugs to #ubuntu-desktop
<Laney> seb128: will look
<sil2100> vorlon: which sadly feels like not the right way to go right now, as we potentially might need python-tx-tftp rebuildable in case of fixes/security, as it is (will) actively be used
<seb128> Laney, thanks
<cpaelzer> sil2100: thanks for looking after chrony (1 line change btw) - if you need anything please let me know
<seb128> Laney, the desktop bugs 'discussion' was for benefit of the r-t to demonstrate the impact of the bug and why we ask the fix to be accepted, no need to move it I think
<seb128> but yeah, we did enough writing on that now, we can stop :)
<Laney> it seems to be getting onto other bugs
<Laney> no need to push back thanks
<sil2100> cpaelzer: ok, let's get that in
<philroche> bdmurray: popey: Logout followed by login worked
<sil2100> cpaelzer: we most probably will have a re-spin anyway, so then this can get in
-queuebot:#ubuntu-release- Unapproved: systemd (xenial-proposed/main) [229-4ubuntu21.27 => 229-4ubuntu21.28] (core)
<cpaelzer> thanks sil2100
<popey> philroche excellent
-queuebot:#ubuntu-release- Unapproved: accepted chrony [source] (focal-proposed) [3.5-6ubuntu6]
<cpaelzer> sil2100: sad to hear that we will need another respin thou
 * cpaelzer hugs (corona safe) the release Team
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-ubuntu-dock [source] (focal-proposed) [67ubuntu20.04.5]
<popey> sil2100 / cpaelzer just tested the fix on bug 1869571 - and it totally works, and fixes the small icons issue too.
<ubot5> bug 1869571 in OEM Priority Project "Vertical dual monitor setup with main monitor on bottom causes overview to only use one eighth of screen" [High,New] https://launchpad.net/bugs/1869571
<popey> (screenshots attached)
<cpaelzer> thanks popey
<cpaelzer> I'll need to wait until I can reboot without loosing too mcuh
<popey> I just did alt+f2, R, after editing that file
-queuebot:#ubuntu-release- Unapproved: subiquity (focal-proposed/universe) [20.03.3+git147gb34aeda0 => 20.04.1+git45g5f9fae19] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted subiquity [source] (focal-proposed) [20.04.1+git45g5f9fae19]
<jamespage> doko, cpaelzer: checking now but nova-spiceproxy does need to be promoted
<jamespage> hmm actually it would be better to recommend python3-websockify as that is the package that actually provides the websockify binary.
<doko> jamespage: can you still change that?
<vorlon> sil2100: so the reason I was trying to sync pyhamcrest and twisted in the first place is that pyhamcrest is already unbuildable in main due to missing python2 build-dependencies
<sil2100> Oh hamburgers
<bdmurray> I had hamburgers last night!
<sil2100> vorlon: ok, so this is a tricky situation since it's bad either way right now, it's either pyhamcrest being unbuildable (as now) or python-tx-tftp
<vorlon> YEAH
<vorlon> oops
<vorlon> yeah
<sil2100> Not sure which one is more likely to require fixes, I see both don't have much going on
<jamespage> doko: well I can ask :)
<jamespage> choice is upload to switch depends, or promote websockify bin package to main
-queuebot:#ubuntu-release- Unapproved: spice-html5 (focal-proposed/main) [0.2.2-0ubuntu1 => 0.2.2-0ubuntu2] (no packageset)
<jamespage> hi release team - minor tweak from myself so that doko and I can avoid soiling main with a package that is not required ^^
-queuebot:#ubuntu-release- Unapproved: accepted spice-html5 [source] (focal-proposed) [0.2.2-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: python-mapnik (focal-proposed/universe) [1:0.0~20180723-588fc9062-3ubuntu2 => 1:0.0~20180723-588fc9062-3ubuntu3] (no packageset)
<jamespage> thankyou :)
<Laney> <ubuntu-archive-robot> no problem at all!
<Laney> :p
-queuebot:#ubuntu-release- Unapproved: accepted python-mapnik [source] (focal-proposed) [1:0.0~20180723-588fc9062-3ubuntu3]
<jamespage> lol
<vorlon> sil2100: should we let strace in from -proposed?  currently blocked by hint, and looks like this is the fix for the ftbfs
<sil2100> vorlon: yes, but we didn't want to let it migrate now as it's a big version jump, which we didn't feel comfortable in accepting so close to the release (though this is a debugging tool and rather low risk)
<vorlon> sil2100: so what's the plan, if not letting it migrate now?
<vorlon> migrating later is not less risky :)
<sil2100> We were thinking about getting it in as an SRU, since then it can have a proper validation scheme and aging
<vorlon> so it'll need a reupload then, since there's no SRU bug linked?
<vorlon> fwiw I personally think it would be better to take it now rather than as an SRU, just because the interfaces of strace are so narrow (debugging tool as you say) and the possible release impact is minimal
<Laney> respins spinning
<bdmurray> seb128: Are you looking at bug 1871960?
<ubot5> bug 1871960 in libgtk3-perl (Ubuntu Focal) "package libpam-modules 1.1.8-3.6ubuntu2.18.04.1 failed to install/upgrade: pre-dependency problem - not installing libpam-modules:amd64" [Critical,Confirmed] https://launchpad.net/bugs/1871960
<seb128> bdmurray, I started poking a bit but I doubt I will get to the bottom of it, if it's urgent feel free to take over or find someone with more available slot (sorry, almost time to call it a day for me, but I will resume on that first thing tomorrow if nobody else has picked it up)
<bdmurray> seb128: We think it is a blocker for enabling upgrades.
<seb128> bdmurray, ack, I agree it's important, sorry day was just crazy and I poked a bit but didn't have much success yet
<bdmurray> seb128: okay, we do have a little bit more time since it is an upgrade issue
<sil2100> vorlon: oh, right, I thought we did have those, but then I guess I said it's not needed (as I forgot about the SRU part and thought only about the block-proposed part)
<vorlon> seb128: I see that ubuntu-system-service is now a candidate for demotion because gnome-control-center no longer recommends it.  Is gnome-control-center now handling these services independently?
<vorlon> if it were completely unused I would drop it from the archive, but unity-control-center still recommends it
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Focal Final] (20200420) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Focal Final] (20200420) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Focal Final] (20200420) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Focal Final] (20200420) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Focal Final] (20200420) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Focal Final] (20200420) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi [Focal Final] (20200420) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi [Focal Final] (20200420) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Focal Final] (20200420) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Focal Final] has been updated (20200420)
<seb128> vorlon, no, the distro patch which was allowing to set a system proxy using the service was commented out some cycles ago so it's a feature gap that needs to be restored but meanwhile there is no point keeping the package in main since it's not in use...
<seb128> also I don't know if we would still use that backend if we restore the feature
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Focal Final] (20200420) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity arm64 [Focal Final] (20200420) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity ppc64el [Focal Final] (20200420) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Focal Final] (20200420) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Focal Final] (20200420) has been added
-queuebot:#ubuntu-release- Unapproved: xubuntu-default-settings (focal-proposed/universe) [20.04.3 => 20.04.4] (xubuntu)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Focal Final] (20200420) has been added
-queuebot:#ubuntu-release- Unapproved: rejected xubuntu-default-settings [source] (focal-proposed) [20.04.4]
<sforshee> vorlon: not sure who to ping about this, but since you uploaded it recently ... multipath tools isn't happy with linux-kvm, bug 1873912
<ubot5> bug 1873912 in multipath-tools (Ubuntu) "multipathd.service fails to start with linux-kvm kernel" [Undecided,New] https://launchpad.net/bugs/1873912
<sforshee> seems to want some modules what we don't have enabled in that kernel
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Focal Final] (20200420) has been added
<sforshee> sil2100, Laney: ^ fyi
-queuebot:#ubuntu-release- Unapproved: xubuntu-default-settings (focal-proposed/universe) [20.04.3 => 20.04.4] (xubuntu)
<vorlon> sforshee: mmm; shouldn't this be fixed in linux-kvm by enabling that module?
<sforshee> vorlon: it's a possibility, though at least the scsi modules have little other relevance to kvm
-queuebot:#ubuntu-release- Unapproved: rabbitmq-server (bionic-backports/main) [3.6.10-1ubuntu0.1 => 3.8.2-0ubuntu1~ubuntu18.04.1] (ubuntu-server)
<vorlon> sforshee: well it looks like it tries to modprobe any relevant modules and there are warnings for that, but the failure is "DM multipath kernel driver not loaded", so only dm-multipath may be required?
<sforshee> hmm, possibly
-queuebot:#ubuntu-release- Unapproved: rabbitmq-server (eoan-backports/main) [3.7.8-4ubuntu2 => 3.8.2-0ubuntu1~ubuntu19.10.1] (ubuntu-server)
<sforshee> vorlon: I will try it. We're respinning linux-kvm today anyway, so this is an opportune time
<vorlon> ok
-queuebot:#ubuntu-release- Unapproved: elixir-lang (bionic-backports/universe) [1.3.3-2 => 1.9.1.dfsg-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: erlang (bionic-backports/main) [1:20.2.2+dfsg-1ubuntu2 => 1:22.0.7+dfsg-1build1~ubuntu18.04.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted elixir-lang [source] (bionic-backports) [1.9.1.dfsg-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted rabbitmq-server [source] (bionic-backports) [3.8.2-0ubuntu1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted erlang [source] (bionic-backports) [1:22.0.7+dfsg-1build1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted rabbitmq-server [source] (eoan-backports) [3.8.2-0ubuntu1~ubuntu19.10.1]
<doko> rbalint: is the libc6-lse supposed to be in main?
<vorlon> doko: it is and I asked him to follow up on seeding it
<vorlon> doko: but maybe you see a good place to seed it, I didn't see an obvious precedent
<doko> ok, I'll seed it
-queuebot:#ubuntu-release- Unapproved: accepted xubuntu-default-settings [source] (focal-proposed) [20.04.4]
<doko> vorlon: you uploaded ubuntu-system-service last, which is ready for demotion. is this intended?
-queuebot:#ubuntu-release- New binary: erlang [s390x] (bionic-backports/main) [1:22.0.7+dfsg-1build1~ubuntu18.04.1] (ubuntu-desktop, ubuntu-server)
<vorlon> doko: see above discussion with seb128 (and I already demoted it)
<doko> ahh, ok
<rbalint> thanks doko!
-queuebot:#ubuntu-release- New binary: erlang [ppc64el] (bionic-backports/main) [1:22.0.7+dfsg-1build1~ubuntu18.04.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: gui-ufw (focal-proposed/universe) [20.04.1-1 => 20.04.1-1ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- New binary: erlang [amd64] (bionic-backports/main) [1:22.0.7+dfsg-1build1~ubuntu18.04.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: erlang [i386] (bionic-backports/main) [1:22.0.7+dfsg-1build1~ubuntu18.04.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: erlang [arm64] (bionic-backports/main) [1:22.0.7+dfsg-1build1~ubuntu18.04.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: erlang [armhf] (bionic-backports/main) [1:22.0.7+dfsg-1build1~ubuntu18.04.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted erlang [amd64] (bionic-backports) [1:22.0.7+dfsg-1build1~ubuntu18.04.1]
-queuebot:#ubuntu-release- New: accepted erlang [armhf] (bionic-backports) [1:22.0.7+dfsg-1build1~ubuntu18.04.1]
-queuebot:#ubuntu-release- New: accepted erlang [ppc64el] (bionic-backports) [1:22.0.7+dfsg-1build1~ubuntu18.04.1]
-queuebot:#ubuntu-release- New: accepted erlang [arm64] (bionic-backports) [1:22.0.7+dfsg-1build1~ubuntu18.04.1]
-queuebot:#ubuntu-release- New: accepted erlang [s390x] (bionic-backports) [1:22.0.7+dfsg-1build1~ubuntu18.04.1]
-queuebot:#ubuntu-release- New: accepted erlang [i386] (bionic-backports) [1:22.0.7+dfsg-1build1~ubuntu18.04.1]
<bdmurray> bluesabre: xubuntu-default-settings has migrated and xubuntu images can be built
<bluesabre> bdmurray: awesome, thanks!
<bluesabre> bdmurray: how do I do that without rebuilding everybody?
<bluesabre> I've never clicked the ominous "Request Rebuild" button before :)
<bdmurray> let me have a look
<bdmurray> bluesabre: its listed as re-building already so lets see what happens
<bluesabre> bdmurray: great!
<bdmurray> actually that might be the failed build from a couple of hours ago
<mwhudson> morning
<mwhudson> general on-fire-ness status?
<bdmurray> its a slow burn initial images were created not too long ago
<mwhudson> i suppose i should do some testing then
-queuebot:#ubuntu-release- Unapproved: qclib (focal-proposed/universe) [2.0.1-0ubuntu1 => 2.1.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted qclib [source] (focal-proposed) [2.1.0-0ubuntu1]
<bdmurray> bluesabre: we are starting the builds for xubuntu
-queuebot:#ubuntu-release- Unapproved: git (focal-proposed/main) [1:2.25.1-1ubuntu2 => 1:2.25.1-1ubuntu3] (core, i386-whitelist)
<cjwatson> bdmurray: Are there likely to be many other image builds happening tonight?  I'd like to do a Launchpad rollout tonight if I can manage it - it shouldn't actually disrupt anything, but wanted to check
<bdmurray> cjwatson: No not likely given sil2100 and Laney have taken off for the night. The xubuntu one should be the last one.
<cjwatson> OK
-queuebot:#ubuntu-release- Unapproved: horizon (focal-proposed/main) [3:18.2.1~git2020041013.754804667-0ubuntu2 => 3:18.2.1~git2020041013.754804667-0ubuntu3] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Focal Final] (20200420.1) has been added
<coreycb> hi release team, I uploaded a new version of horizon with a bug fix. I don't plan to do any more uploads this week for openstack fwiw.
-queuebot:#ubuntu-release- Unapproved: lubuntu-meta (focal-proposed/universe) [20.04.7 => 20.04.8] (lubuntu)
<The_LoudSpeaker> ^ this is to fix a previous revert
<sforshee> vorlon: enabling dm-multipath works, I
<sforshee> I'll get a new linux-kvm building
<bdmurray> The_LoudSpeaker: Could you elaborate on what you mean by "fix a previous revert" and say something about the importance of this upload so the release team can evaluate including it?
<The_LoudSpeaker> Yeah.
-queuebot:#ubuntu-release- Unapproved: remmina (focal-proposed/main) [1.4.2+dfsg-1ubuntu1 => 1.4.3+dfsg-1ubuntu1] (ubuntu-desktop)
<The_LoudSpeaker> sooo @tsimonq2 reverted a commit here https://phab.lubuntu.me/rSEEDe6e116cc8eae962950b37fad88d686191bc274b5 to remove lubuntu-grub-theme which has a important bug right now.
<The_LoudSpeaker> which lead to update of meta to 20.04.7
-queuebot:#ubuntu-release- Unapproved: python2.7 (focal-proposed/universe) [2.7.18~rc1-2 => 2.7.18-1] (i386-whitelist, kubuntu)
<The_LoudSpeaker> But if you notice that xfonts-efont-unicode which is required for Lubuntu's xscreensaver theme also got removed
<The_LoudSpeaker> 20.04.8 just adds xfonts-efont-unicode back
<The_LoudSpeaker> coressponding to https://phab.lubuntu.me/rSEED3468321dfdf2f01d04172fc7c8812f7da352c47a
<doko> ^^^please consider accepting python2.7, final release, no code changes
<The_LoudSpeaker> ^^ bdmurray
<The_LoudSpeaker> xfonts-efont-unicode is necessary as it is the font which we use in xscreensaver dialoguebox
<bdmurray> got it thanks
<sil2100> bdmurray: hey! You need help with the failed builds?
<sil2100> I can clear those out so you can press the buttan
<bdmurray> sil2100: vorlon built them
<sil2100> Excellent
<sil2100> \o/
-queuebot:#ubuntu-release- Unapproved: wine (focal-proposed/universe) [5.0-3 => 5.0-3ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: accepted wine [source] (focal-proposed) [5.0-3ubuntu1]
<wgrant> Could someone look at ruby2.7 soonish? I think it would have been autoapproved under the new i386-whitelist ignore rule
-queuebot:#ubuntu-release- Unapproved: gnome-subtitles (focal-proposed/universe) [1.4.2-1 => 1.6-2.1] (cli-mono) (sync)
-queuebot:#ubuntu-release- Unapproved: ogmrip (focal-proposed/universe) [1.0.1-2build1 => 1.0.1-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ogmrip [sync] (focal-proposed) [1.0.1-3]
-queuebot:#ubuntu-release- Unapproved: googleplay-api (focal-proposed/universe) [0.4.4-1 => 0.4.4+git20200310-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: birdtray (focal-proposed/universe) [1.7.0+ds-2 => 1.8.0+ds-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted birdtray [sync] (focal-proposed) [1.8.0+ds-1]
-queuebot:#ubuntu-release- Unapproved: accepted googleplay-api [sync] (focal-proposed) [0.4.4+git20200310-2]
-queuebot:#ubuntu-release- Unapproved: linux-kvm (focal-proposed/main) [5.4.0-1008.8 => 5.4.0-1009.9] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-kvm (focal-proposed/main) [5.4.0.1008.8 => 5.4.0.1009.9] (core, kernel) (sync)
#ubuntu-release 2020-04-21
<xnox> Laney:  vorlon: i think ubuntu-desktop ship is broken.
<xnox> we seeded nvidia-drivers, but didn't seed the right l-r-m modules for nvidia
<xnox> thus offline we will install the wrong thing
<xnox> we didn't tell which l-r-m nvidia we want so i think the pool is just wrong =)
<xnox> ./pool/restricted/l/linux-restricted-modules-aws/linux-modules-nvidia-440-5.4.0-1009-aws_5.4.0-1009.9_amd64.deb
<xnox> it has this
<xnox> when we need the ones for generic-hwe-20.04 and the one for oem
<vorlon> xnox: heh, yes we should certainly make sure we have the matching one.  you want to raise an MP?
<xnox> yes one sec
<vorlon> I think the ubuntu-drivers part is not done anyway to prefer lrm over nvidia-dkms. :P
<xnox> vorlon:  it's half done
<xnox> vorlon:  it prevers lrm over nvidia, but changes my kernel from generic => lowlatency because it got confused by linux-generic-hwe-20.04
<xnox> * over dkms
<xnox> vorlon:  https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/+merge/382619
<xnox> vorlon:  if you are happy, please merge it.
-queuebot:#ubuntu-release- Unapproved: python-ipaddr (focal-proposed/universe) [2.2.0-2ubuntu2 => 2.2.0-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-ipaddr [sync] (focal-proposed) [2.2.0-4]
-queuebot:#ubuntu-release- Unapproved: python-virtualenv (focal-proposed/universe) [20.0.13-1 => 20.0.17-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-virtualenv [sync] (focal-proposed) [20.0.17-1]
-queuebot:#ubuntu-release- New binary: python-ipaddr [amd64] (focal-proposed/universe) [2.2.0-4] (no packageset)
<xnox> anyway i think https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1873867 is worth respining the pool for
<ubot5> Ubuntu bug 1873867 in linux (Ubuntu) "ubuntu-drivers changes kernel flavour when installing nvidia" [Undecided,Incomplete]
<xnox> not sure about iso itself.... maybe if ubuntu-drivers are fixed
<vorlon> xnox: why do I not see linux generic-hwe-20.04 metapackage anywhere in the seeds?
-queuebot:#ubuntu-release- New: accepted php-text-captcha [amd64] (focal-proposed) [1.0.2-7]
-queuebot:#ubuntu-release- New: accepted python-ipaddr [amd64] (focal-proposed) [2.2.0-4]
<vorlon> xnox: merged (but I still have the question)
<vorlon> and I agree this warrants a respin
<vorlon> bdmurray: ^^
-queuebot:#ubuntu-release- Unapproved: apport (focal-proposed/main) [2.20.11-0ubuntu27 => 2.20.11-0ubuntu28] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: linux-meta (focal-proposed/main) [5.4.0.25.31 => 5.4.0.26.32] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux (focal-proposed/main) [5.4.0-25.29 => 5.4.0-26.30] (core, i386-whitelist, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-restricted-modules (focal-proposed/restricted) [5.4.0-25.29 => 5.4.0-26.30] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed (focal-proposed/main) [5.4.0-25.29 => 5.4.0-26.30] (core, kernel) (sync)
<sforshee> Laney, apw: ^ those are the kernels with the realtek ethernet driver fix
-queuebot:#ubuntu-release- Unapproved: golang-google-grpc (focal-proposed/universe) [1.22.1-1ubuntu1 => 1.27.1-1] (ubuntu-mate) (sync)
<mwhudson> i'm just releasing a new subiquity to stable/ubuntu-20.04
<sarnold> mwhudson: is this the one that you'd like ppc64el testing on?
-queuebot:#ubuntu-release- Unapproved: swiftsc (focal-proposed/universe) [0.5-1.1 => 0.5-1.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted swiftsc [source] (focal-proposed) [0.5-1.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: t-code (focal-proposed/universe) [2:2.3.1-8 => 2:2.3.1-9] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted t-code [sync] (focal-proposed) [2:2.3.1-9]
-queuebot:#ubuntu-release- Unapproved: zeromq3 (focal-proposed/universe) [4.3.2-2 => 4.3.2-2ubuntu1] (i386-whitelist, kubuntu)
<sarnold> hmm, what's the story with https://launchpad.net/ubuntu/+source/golang-1.12 https://launchpad.net/ubuntu/+source/golang-1.13 https://launchpad.net/ubuntu/+source/golang-1.14  -- I'm a bit surprised to see three golangs in focal, none of them 1.10 (as in xenial and bionic)
-queuebot:#ubuntu-release- Unapproved: tboot (focal-proposed/universe) [1.9.7-0ubuntu1 => 1.9.7-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted tboot [source] (focal-proposed) [1.9.7-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: unknown-horizons (focal-proposed/universe) [2019.1-1 => 2019.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted unknown-horizons [sync] (focal-proposed) [2019.1-2]
-queuebot:#ubuntu-release- Unapproved: 389-ds-base (focal-proposed/universe) [1.4.3.2-1build1 => 1.4.3.6-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: sssd (focal-proposed/main) [2.2.3-2 => 2.2.3-3] (ubuntu-desktop, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted 389-ds-base [sync] (focal-proposed) [1.4.3.6-1]
<tjaalton> sssd ^ fixes a typo in libnss-sss postinst script when adding an entry to nsswitch.conf, would be a shame to release with that thinko..
<tjaalton> nss-wrapper should need to be badtested on i386
-queuebot:#ubuntu-release- Unapproved: yiyantang (focal-proposed/universe) [0.7.0-5build2 => 0.7.0-6] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted yiyantang [sync] (focal-proposed) [0.7.0-6]
-queuebot:#ubuntu-release- Unapproved: yp-tools (focal-proposed/universe) [3.3-5.1ubuntu1 => 3.3-5.3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted yp-tools [sync] (focal-proposed) [3.3-5.3]
-queuebot:#ubuntu-release- Unapproved: dhewm3 (focal-proposed/multiverse) [1.5.0+git20181221+dfsg-1build1 => 1.5.0+git20181221+dfsg-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted dhewm3 [sync] (focal-proposed) [1.5.0+git20181221+dfsg-2]
-queuebot:#ubuntu-release- Unapproved: lgrind (focal-proposed/multiverse) [3.67-3.1build1 => 3.67-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted lgrind [sync] (focal-proposed) [3.67-4]
-queuebot:#ubuntu-release- Unapproved: ogmrip-oggz (focal-proposed/multiverse) [0.3-dmo1ubuntu1 => 0.3-dmo1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ogmrip-oggz [source] (focal-proposed) [0.3-dmo1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: rejected linux-meta [sync] (focal-proposed) [5.4.0.26.32]
-queuebot:#ubuntu-release- Unapproved: rejected linux-signed [sync] (focal-proposed) [5.4.0-26.30]
-queuebot:#ubuntu-release- Unapproved: rejected linux-restricted-modules [sync] (focal-proposed) [5.4.0-26.30]
-queuebot:#ubuntu-release- Unapproved: rejected linux [sync] (focal-proposed) [5.4.0-26.30]
<apw> ^ these all all good, rejected so I can ensure they are copied correctly (it is too late in the game to get this wrong)
<mwhudson> sarnold: yes
-queuebot:#ubuntu-release- Unapproved: rejected linux-kvm [sync] (focal-proposed) [5.4.0-1009.9]
-queuebot:#ubuntu-release- Unapproved: rejected linux-meta-kvm [sync] (focal-proposed) [5.4.0.1009.9]
<apw> ^ these are all good too, again ensuring they are copied correctly
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (focal-proposed/main) [5.4.0-26.30] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (focal-proposed/main) [5.4.0-26.30] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (focal-proposed/main) [5.4.0-26.30] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (focal-proposed/main) [5.4.0-26.30] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (focal-proposed) [5.4.0-26.30]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (focal-proposed) [5.4.0-26.30]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (focal-proposed) [5.4.0-26.30]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (focal-proposed) [5.4.0-26.30]
-queuebot:#ubuntu-release- Unapproved: python-pip (focal-proposed/universe) [20.0.2-4 => 20.0.2-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-pip [sync] (focal-proposed) [20.0.2-5]
-queuebot:#ubuntu-release- Unapproved: pypy3 (focal-proposed/universe) [7.3.0+dfsg-1ubuntu3 => 7.3.1+dfsg-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pypy3 [sync] (focal-proposed) [7.3.1+dfsg-2]
<vorlon> sarnold: golang-1.14 arrived too late to transition to it on all archs but is needed for riscv64 support; so that explains golang-1.1[34].  golang-1.12, appears to have no reverse-dependencies in the archive so should probably go away, if you or mwhudson wanted to file a removal request
<tumbleweed> some of the golang stuff in proposed may get unstuck with a golang-google-grpc sync, but that probably means rebuilds, and who knows how deep that rabbithole will go. I decided not to sync it
<cpaelzer> wgrant: qemu and libvirt builds worked as expected, autopkgtests are good as well and no listing of them in update_output
<cpaelzer> wgrant: seems all good for once the release team un-freezes adter the current image-spin
<wgrant> cpaelzer: yeah, some autopkgtests took a few retries, but got there in the end. They won't be mentioned in update_output because the freeze blocks them
<cpaelzer> yep, I justwanted to collect our remaining todo's on this but it seems to be as ready as we can make it
<wgrant> Indeed. Thanks for all the fixes.
<wgrant> I've been using the qemu from -proposed for my dev work all day and it seems solid
<cpaelzer> \o/
<vorlon> cpaelzer: "unfreeze" uh we're in final freeze so that doesn't happen. you'll want to flag this to the release team as a respin-worthy update to Ubuntu Server, if you want them in
<wgrant> vorlon: The plan was to let them in if a respin was otherwise required, I believe, otherwise retarget to -updates.
<vorlon> ok
<vorlon> still, there's no "unfreeze" happening at this point so it needs to get on the List of whoever's driving respins :)
<wgrant> vorlon: Separately, do you have remaining concerns about ruby2.7? I think the unapproved -5ubuntu1 fixes your issues with the -5 sync
<vorlon> wgrant: what does it buy us?
<vorlon> and ruby2.7 is on the budgie images
<wgrant> vorlon: installability of ruby stuff on riscv64 because the bootstrap ruby2.7 was badly versioned and had the bad 64-bit symbols file. But -updates would solve that too
<wgrant> Ugh, missed that
<wgrant> Does that not show up as a set somehow?
<vorlon> hmm perhaps not
<vorlon> so, needs to be coordinated with ubuntu-budgie wrt any respins
<wgrant> Huh yeah, seeded-in-ubuntu says ubuntu-budgie/daily-live, but no corresponding packageset, annoying.
<wgrant> Thanks for the pointer.
-queuebot:#ubuntu-release- Unapproved: librelp (focal-proposed/universe) [1.5.0-1ubuntu1 => 1.5.0-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted librelp [source] (focal-proposed) [1.5.0-1ubuntu2]
<vorlon> sil2100: mornin'
<sil2100> vorlon: morning o/
-queuebot:#ubuntu-release- Unapproved: intel-media-driver-non-free (focal-proposed/multiverse) [20.1.1+ds1-1 => 20.1.1+ds1-1build1] (i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: accepted intel-media-driver-non-free [source] (focal-proposed) [20.1.1+ds1-1build1]
<sil2100> How are we looking? I see the new kernels in -proposed
<sil2100> Ok, I see quite a lot of testing on the tracker, quite a few bugs reported too
<jibel> hey sil2100, almost covered Ubuntu desktop, nothing alarming so far
<didrocks> jibel: needed help? Iâm syncing latest iso
<sil2100> \o/
<jibel> didrocks, help is always welcome
<didrocks> Iâll open a bug so that xnox updates the qa tracker on http://iso.qa.ubuntu.com/qatracker/milestones/412/builds/210996/testcases/1447/results. This test case is invalid now that the entry was removed
<jibel> didrocks, I removed it, default cases must be updated to verify that checksum runs on boot
-queuebot:#ubuntu-release- Packageset: Added intel-media-driver-non-free to i386-whitelist in focal
<LocutusOfBorg> hello, can bileto gain the capability to know about riscv64?
<sil2100> LocutusOfBorg: what do you mean?
<sil2100> LocutusOfBorg: you mean the bileto britney?
<sil2100> Since bileto itself should build and track riscv64 as any other arch - but I don't think it's in the list of supported britney ADT arches
<sil2100> ...I guess I could add that, maybe to NEW_ARCHES
<LocutusOfBorg> sil2100, example: https://bileto.ubuntu.com/#/ticket/4023 shows "Successfully built", but riscv64 is still building, so somebody might click "publish" by mistake
<LocutusOfBorg> also sil2100 since you are there and blink, also autopkgtests in bileto should take in account for hints otherwise almost every autopkgtest run on lots of packages will fail for force-history-reset and similar
<sil2100> LocutusOfBorg: oh, ok, let me look into that when I have a moment
<LocutusOfBorg> sil2100, just as example: https://bileto.ubuntu.com/excuses/4023/focal.html this one is one that shows "autopkgtest failures" but all the failures are related to i386 and are already badtested
<LocutusOfBorg> so if you want to commit a patch we can use that one to test it
-queuebot:#ubuntu-release- Unapproved: rejected remmina [source] (focal-proposed) [1.4.3+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: django-housekeeping (focal-proposed/universe) [1.1-1.1 => 1.2-1~ubuntu20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted django-housekeeping [source] (focal-proposed) [1.2-1~ubuntu20.04.1]
-queuebot:#ubuntu-release- Unapproved: debian-installer (focal-proposed/main) [20101020ubuntu613 => 20101020ubuntu614] (core)
-queuebot:#ubuntu-release- Unapproved: accepted lubuntu-meta [source] (focal-proposed) [20.04.8]
-queuebot:#ubuntu-release- Unapproved: accepted git [source] (focal-proposed) [1:2.25.1-1ubuntu3]
<sil2100> Laney, apw: d-i in teh queue ^
<apw> sil2100, will review
<mwhudson> vorlon: are you timeshifting your hours or just not sleeping
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (focal-proposed) [20101020ubuntu614]
-queuebot:#ubuntu-release- Unapproved: accepted sssd [sync] (focal-proposed) [2.2.3-3]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-subtitles [sync] (focal-proposed) [1.6-2.1]
<sil2100> Ok everyone! As per the discourse thread, we are now waiting for the kernels to be ready to migrate and, once they do, I think we'll have everything for our new candidate images
<wgrant> sil2100: Where do we stand in terms of pending respins? I have a few I'd like to slip in if their images are going to be respun anyway: qemu/libvirt (server, both in -proposed and ready to migrate except for the block), ceph (server, built in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4030/+packages), zeromq3 (most non-ubuntu desktop images, built in
<wgrant> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4032/+packages), ruby2.7 (built in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4031/+packages). Sounds like qemu/libvirt can probably go in now, if we're respinning for a kernel, since they're already ready to migrate?
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (focal-proposed) [3:18.2.1~git2020041013.754804667-0ubuntu3]
<sil2100> wgrant: yeah, let me unblock those two - and Laney is reviewing/accepting the zeromq3 upload soon
-queuebot:#ubuntu-release- Unapproved: accepted zeromq3 [source] (focal-proposed) [4.3.2-2ubuntu1]
<sil2100> The rest I guess we'd like to leave out in -proposed
<wgrant> sil2100: ruby2.7 is in a subset of zeromq3's images (just ubuntu-budgie) and already built, though I guess autopkgtests might be annoying.
<sil2100> wgrant: I think for now we just wanted to have zeromq3 in -proposed, we're too close to the respins to unblock more stuff (just unblocking qemu and libvirt for now)
<wgrant> sil2100: OK cool, makes sense. Should I request the copies into -proposed of the others now, so the autopkgtests are ready if we happen to respin again?
<seb128> SRU team, could someone move bug #1781428 to updates and review the new pulseaudio/bionic SRU from the queue? OEM team has a close target and would like to see that in if possible
<ubot5> bug 1781428 in pulseaudio (Ubuntu Bionic) "please enable snap mediation support" [Medium,Fix committed] https://launchpad.net/bugs/1781428
<sil2100> seb128: I'll take a look in a moment between stuff
<seb128> sil2100, thanks
<wgrant> vorlon: fwiw for intel-media-driver-non-free a self-copy would have worked to create the i386 build
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Focal Final] has been updated (20101020ubuntu614)
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Focal Final] has been updated (20101020ubuntu614)
-queuebot:#ubuntu-release- Builds: Netboot armhf [Focal Final] has been updated (20101020ubuntu614)
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Focal Final] has been updated (20101020ubuntu614)
-queuebot:#ubuntu-release- Builds: Netboot s390x [Focal Final] has been updated (20101020ubuntu614)
<cpaelzer> SRU Team, releasing https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/1872183 into Bionic is also some sort of focal pre-req
<ubot5> Ubuntu bug 1872183 in chrony (Ubuntu Bionic) "package chrony 3.2-4ubuntu4.2 failed to install/upgrade: installed chrony package post-removal script subprocess returned error exit status 1" [Undecided,Fix committed]
<cpaelzer> it is ready and waits to be released, would be great if someone could take a look
<cpaelzer> and on a second thought, much less urgent but hanging around ready to be SRU-released for more than two weeks is https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1868012
<ubot5> Ubuntu bug 1868012 in open-vm-tools (Ubuntu Eoan) "MRE for open-vm-tools to version 11.0.5" [Low,Fix released]
<cpaelzer> oh hitting refresh showed me that sil2100 was faster than my request on the latter
<cpaelzer> thanks
<cpaelzer> still waiting for chrony is someone has a SRU-minute for it
<Laney> jibel: can you help to add the upgrade tests on the final milestone please?
<Laney> I don't know how to do that
<jibel> Laney, sure
<Laney> cheers!
-queuebot:#ubuntu-release- New binary: linux-signed-azure-4.15 [amd64] (bionic-proposed/main) [4.15.0-1082.92] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1082.92~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure-4.15 [amd64] (bionic-proposed) [4.15.0-1082.92]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1082.92~16.04.1]
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Focal Final] (20200421) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Focal Final] (20200421) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Focal Final] (20200421) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Focal Final] (20200421) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Focal Final] (20200421) has been added
<Laney> sil2100: ^- those worked
<sil2100> \o/
-queuebot:#ubuntu-release- Builds: Upgrade Kubuntu amd64 [Focal Final] (20200420) has been added
-queuebot:#ubuntu-release- Builds: Upgrade Ubuntu MATE amd64 [Focal Final] (20200420) has been added
-queuebot:#ubuntu-release- Builds: Upgrade Ubuntu Server amd64 [Focal Final] (20200420) has been added
-queuebot:#ubuntu-release- Builds: Upgrade Ubuntu Studio amd64 [Focal Final] (20200420) has been added
-queuebot:#ubuntu-release- Builds: Upgrade Ubuntu amd64 [Focal Final] (20200420) has been added
-queuebot:#ubuntu-release- Builds: Upgrade UbuntuKylin amd64 [Focal Final] (20200420) has been added
-queuebot:#ubuntu-release- Builds: Upgrade Xubuntu amd64 [Focal Final] (20200420) has been added
<jibel> Laney, done
-queuebot:#ubuntu-release- Builds: Upgrade Lubuntu amd64 [Focal Final] (20200420) has been added
<sil2100> apw, sforshee: hey! I htink the ADT situation of the linux in focal-proposed looks good, can one of you unblock the kernel via the tracking bug?
<sil2100> Or is there some special step still needed?
<apw> sil
<apw> sil2100: can do
<sil2100> apw: thanks!
<sil2100> Laney: oh, I guess this reminds me: I think we might want to remove the old i386 ubuntu-base tarball that's just being copied forward all the time
<sil2100> Let me do that in a moment
<Laney> ye
<sil2100> Laney: and I'll deploy the ubuntu-base changes - if it explodes during the rebuilds, we can always just revert and hack it in rebuild-requests ;)
<Laney>  sure, deploy and try a rebuild
<Laney> maybe just one arch at first
<sil2100> Right, good idea
<apw> sil2100, the block should come off automatically very shortly
<wgrant> Any reason I shouldn't copy my ceph, ruby2.7 into -proposed in case we respin again? They're both easy diffs.
<sil2100> wgrant: push ceph to the queue, we can then review and discuss both of them
<sil2100> We'd like to at least not accept anything right before kicking the candidate images, but afterwards we can think about that
<wgrant> sil2100: I have ruby2.7 binaries in a silo, but I'm worried it'll autoaccept since it's only in budgie which has no packageset
<wgrant> I forget exactly how the bot works
<wgrant> Or rather it's only in i386-whitelist, which I think has been added to the ignore list since the upload that's currently in the queue
<sil2100> Ah, right, Laney did change that, and it explains why the old ruby2.7 wasn't auto-accepted
<sil2100> hm
<sil2100> wgrant: can we in that case just wait for the kernel and such to migrate?
<wgrant> sil2100: Of course, no rush at all
<sil2100> If that's fine with you I'd feel better if britney had as least work to do as possible ;)
<wgrant> Well I'm in theory properly EOD in 3 or 4 hours
<wgrant> Heh yes
<wgrant> https://launchpadlibrarian.net/475376905/ceph_15.2.1-0ubuntu1_15.2.1-0ubuntu2.diff.gz is the ceph diff, fwiw. The stuff under src/test is all artifacts from symlinks.
<sil2100> wgrant: in case you'd be going EOD and we'd still want to wait, just give me a sign and I can bin-copy out of bileto for you
<wgrant> sil2100: I'm happy for ruby2.7 and ceph to both be bin-copied out; I've tested the binaries and they work fine, and it'll save hours of build time.
<wgrant> But I'll be around for a while yet.
<sil2100> uh, wanted to unblock git as well, but I don't think we'll get that in time - I see the dgit ADT tests for arm run for like 3-5 hours
<Ukikie> Urgh, that late addition of riscv is really a pain.  weechat is stuck in -proposed, it can't install a (seemingly) arch-all package and is therefore stuck in -proposed.
<wgrant> Ukikie: The new ruby2.7 will fix that, otherwise it can be hinted through.
<Ukikie> wgrant: Fantastic, thank you.  Sounds good enough to me! :)
-queuebot:#ubuntu-release- Unapproved: libslirp (focal-proposed/main) [4.1.0-2ubuntu1 => 4.1.0-2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gnome-shell (focal-proposed/main) [3.36.1-5ubuntu1 => 3.36.1-5ubuntu2] (desktop-extra, mozilla, ubuntu-desktop)
<sil2100> Ok, quick status update everyone! As per the discourse status page, we have now also identified LP: #1873867 as a blocker and are waiting for a fix for it
<ubot5> Launchpad bug 1873867 in ubuntu-meta (Ubuntu) "ubuntu-drivers changes kernel flavour when installing nvidia" [Undecided,Confirmed] https://launchpad.net/bugs/1873867
<sil2100> Depending on how long fixing it will take, we might want to hold off on the respins
 * sil2100 eyes the linux and linux-kvm packages in focal-proposed
<slizard_> Hi all, I have a package update / release freeze related question, I'm hoping someone can help with. I'm a core dev of the software package GROMACS. We would have liked if 20.04 shipped the last patch release, the current one is one behind. Does the "finalfreeze" mean even patch releases can't be updated? BTW, the package is in Debian sid https://buildd.debian.org/status/package.php?p=gromacs&suite=sid and AFAIK it's generally
<slizard_> pulled from there.
<ginggs> sil2100: do you want 2020.1-1?
<ginggs> sil2100: sorry
<ginggs> slizard_: ^^
<slizard_> ginggs: Yes, that is the latest patch release.
<ginggs> slizard_: i'll sponsor that for you. in future you can use 'requestsync gromacs'
<ginggs> i recall sponsoring this for you before
<slizard_> ginggs: thanks. Not sure, I have made similar requests before though launchpad.
<slizard_> ginggs: where do I post 'requestsync gromacs'?
<ginggs> slizard_: you run it in a terminal and it open a new bug in launchpad for you, with all the information
<slizard_> ginggs: thanks, I'll remember that for next time.
<slizard_> ginggs: As a follow-up: after final are package versions in universe frozen? Asking because our maintenance release (with some important fixes) is planned for April 30. A pointer for documentation on the policies would suffice.
<ginggs> slizard_: we can get the fixes in as a SRU - https://wiki.ubuntu.com/StableReleaseUpdates
<slizard_> ginggs: Thanks for the pointer, and for the help. Much appreciated!
<ginggs> slizard_: yw!
<wgrant> xnox: Are you planning on an ubuntu-meta upload for the l-r-m bits? If so, any thoughts on adding riscv64? -minimal/-standard/-server install fine with the two obvious additions to update.cfg.
<xnox> wgrant:  no ubuntu-meta upload.
<xnox> wgrant:  it's just a ship-live seed change, to change which files end up in the pool, as assembled by debian-cd. no ubuntu-meta upload currently planned.
<wgrant> Ah I see.
<wgrant> Fair enough.
<xnox> wgrant:  i don't mind doing riscv64 upload, but in the past that generated more problems =( because arch:all things were visible, but not installable.
<wgrant> xnox: The three arch-anys all install fine, though I didn't check Recommends.
<xnox> wgrant:  if we have the full -minimal/-standard/-server we can add it i guess. Does it need to be in release pocket for debootstrap? or can it live in updates?
<wgrant> xnox: I forget which metas debootstrap normally installs!
<wgrant> sil2100: And last missing piece of the riscv64 archive, if we have the opportunity to slip it in, is llvm-toolchain-10 (seeded in budgie and server): https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4029/+build/19180814
<xnox> wgrant:  i could upload src:ubuntu-meta-riscv64 right? as a new source package?
<xnox> wgrant:  cause we might want to update it a few times.
<sarnold> vorlon, mwhudson, thanks, https://bugs.launchpad.net/ubuntu/+source/golang-1.12/+bug/1874090 filed
<ubot5> Ubuntu bug 1874090 in golang-1.12 (Ubuntu) "is golang-1.12 a candidate for removal from focal?" [Undecided,New]
-queuebot:#ubuntu-release- Unapproved: desktop-file-utils (focal-proposed/main) [0.24-1ubuntu2 => 0.24-1ubuntu3] (desktop-core, i386-whitelist)
<wgrant> xnox: That would work if you think it's best.
-queuebot:#ubuntu-release- Unapproved: gromacs (focal-proposed/universe) [2020-2build1 => 2020.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gromacs [sync] (focal-proposed) [2020.1-1]
-queuebot:#ubuntu-release- Unapproved: openssl (focal-proposed/main) [1.1.1f-1ubuntu1 => 1.1.1f-1ubuntu2] (core, i386-whitelist)
<mdeslaur> that openssl upload is high-severity and needs to go in focal ^
<mdeslaur> pretty please with sugar on top
<sil2100> mdeslaur: does it need to go into the release?
<sil2100> mdeslaur: or can it go into focal-security?
<sil2100> wgrant: oh my, and what's the autopkgtest story for llvm-toolchain-10? How many tests is it triggering?
<xnox> wgrant:  do you have merge proposal for ubuntu-meta?
<mdeslaur> sil2100: ideally it would go in the release
<sil2100> mdeslaur: ok, reviewing
<apw> sil2100, looks ok to my eye
<xnox> mwhudson:  we do have autopkgtest lead time + riscv64 build
<wgrant> sil2100: there are only a couple of dozen reverse build depends, but not sure exactly
-queuebot:#ubuntu-release- Unapproved: accepted openssl [source] (focal-proposed) [1.1.1f-1ubuntu2]
<wgrant> xnox: into which branch/repo?
<xnox> wgrant:  good point, there is none
<xnox> wgrant:  pastebinit debdiff you had?
<xnox> wgrant: cause if there is ubiquity & ubuntu-drivers & openssl we should have time for ubuntu-meta tooo......
<wgrant> xnox: https://launchpad.net/~wgrant/+archive/ubuntu/nonvirt/+sourcepub/11198713/+listing-archive-extra
<wgrant> https://launchpadlibrarian.net/475564343/ubuntu-meta_1.449_1.450~ppa1.diff.gz
<mdeslaur> thanks sil2100 apw
 * sil2100 would like to take as few things as possible, since every change can potentially cause regressions
<xnox> wgrant:  i like it, and it does _not_ enable desktop packages (due to whitelist in debian/control)
<xnox> wgrant:  would you like to upload that into the queue?
<xnox> (with better version)
<xnox> or should i?
<wgrant> xnox: Yep, all the binaries it produces install fine.
<wgrant> Will upload
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (focal-proposed/main) [1.449 => 1.450] (core)
-queuebot:#ubuntu-release- Unapproved: update-manager (bionic-proposed/main) [1:18.04.11.11 => 1:18.04.11.12] (core)
<teward> NGINX upstream just cut 1.18 stable and I'm going to upload that so LTS is on an NGINX Stable branch.  I will need that approved before we finally release, but that'll be the last NGINX upload of this cycle.
<teward> release team: ^
<teward> no changes from 1.17.10 i uploaded a few days ago
<teward> except a version string
<sil2100> wgrant: ok, so I suppose you will be EODing soon (or should already?)
<sil2100> wgrant: could you do the syncs for the packages?
<wgrant> sil2100: Will do
<sil2100> I think we are waiting for enough other stuff so that we can at least accept those into -proposed
<xnox> wgrant:  and i think we can then publish all of the risc things to -updates. as it shouldn't matter as long as it's somewhere there this week.
<wgrant> sil2100: So not being a bileto expert, any reason I can't just copy-package out of it?
<cjwatson> Isn't there a landing button that causes snakefruit to do it for you and then arrange for the ticket to be closed out?
<wgrant> I don't like magic buttons, but if it works!
<sil2100> wgrant: you can copy-package with binaries normally - I can't remember the bileto logic, but I think there was some check that we could only publish packages that have passing autopkgtests
<sil2100> (I think there was a way to override that tho? WOuld have to check the UI again!)
<wgrant> Yeah, it seems to have a bunch of extra layers
-queuebot:#ubuntu-release- Unapproved: nginx (focal-proposed/main) [1.17.10-0ubuntu1 => 1.18.0-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected ruby2.7 [source] (focal-proposed) [2.7.0-5ubuntu1]
<sil2100> cjwatson: yeah it does, but I think bileto is very stubborn about publishing packages that it didn't run autopkgtests for
-queuebot:#ubuntu-release- Unapproved: ruby2.7 (focal-proposed/main) [2.7.0-4ubuntu1 => 2.7.0-5ubuntu1] (i386-whitelist) (sync)
<sil2100> But Robert wrote it that way that it just tracks the package even if you directly copy it
-queuebot:#ubuntu-release- Unapproved: ceph (focal-proposed/main) [15.2.1-0ubuntu1 => 15.2.1-0ubuntu2] (desktop-core, ubuntu-server) (sync)
<wgrant> Yeah
<teward> if anyone can approve the nginx upload to proposed that'd be great, it has no functional changes just a version string change.  (We'd like to get this in Focal before release, if possible, so we can be on a Stable nginx branch instead of their mainline branches.)
<wgrant> The ruby2.7 ticket is angry because there's the same version in rejected
<sil2100> So it should just close the ticket when it sees the final package migrating to the target release
<teward> oops repost of before, E:NEEDCOFFEE
<wgrant> Handy.
-queuebot:#ubuntu-release- Unapproved: llvm-toolchain-10 (focal-proposed/main) [1:10.0.0-3 => 1:10.0.0-4ubuntu1] (i386-whitelist) (sync)
<cjwatson> sil2100: Ah yes
<cjwatson> I indeed thought there was UI to override that, but it's been a long time ...
<sil2100> I thought the same but I couldn't find it now, just saw the 'ACK packaging changes' one
<sil2100> teward: what is the severity of this? Since this is just a version-bump, can't it land as an SRU instead?
<teward> sil2100: there's been precedent for this in the past, but if we can align the versions *prior* to release, that's more feasible, because I know there's some people who aren't tracking -updates and I have no idea if/when the next security patch will be out to force it to 1.18.x
<teward> i have no qualms making it an SRU but if we're going that route, which we've done in the past, we should probably keep in mind that we're going to have people filing bugs against disparate versions of the package unless they're all synced on the same version in all releases
<teward> 1.17.10 and 1.18.0 having separate bug reports on them is going to be a triaging nightmare even though functionally there's no differences
<teward> sil2100: your call which you choose to do
<teward> i have no issues regardless (hwoever it'd be nice to say we've released with the latest NGINX stable instead of post-relase SRU it)
<teward> this is the headache with NGINX - their stable cuts happen right as we release >.>
-queuebot:#ubuntu-release- Unapproved: walinuxagent (focal-proposed/main) [2.2.45-0ubuntu2 => 2.2.46-0ubuntu1] (core, ubuntu-cloud)
<rbalint> sil2100, bdmurray please accept it, it passed basic testing (upgrade, reboot vm) ^
<sil2100> rbalint: looking
<LocutusOfBorg> wgrant, did you use copy-package instead of publish for bileto?
<teward> sil2100: i was in the process of filing FFe bug for this, but if you want I can make that an SRU for post-release inclusion
<teward> though if we're doing that we should probably reject what's in the queue now and let me reup with an SRU bug reference
<sil2100> Laney, bdmurray: ^ this is for a cloud related critical issue
<wgrant> LocutusOfBorg: Yes, why?
<teward> (For nginx)
<sil2100> LocutusOfBorg: yes, I recommended that, why you ask?
<LocutusOfBorg> does it include also binaries, right?
<LocutusOfBorg> I'm worried if we copy only sources
<sil2100> I asked wgrant to do a bin-copy
<wgrant> I did a bin-copy, that was the whole point :)
<wgrant> But good to check
<LocutusOfBorg> nice! unfortunately on the web page is not shown that particular bit, and since it takes lots of days to complete, better double check :) I did that mistake too many times in the past for my node* bootstraps
<LocutusOfBorg> and ruby* :)
<LocutusOfBorg> thanks!
<wgrant> Yeah, we should possibly show some more of the json_data from the PackageCopyJob there
<wgrant> Now that binary copies are used a lot more
<wgrant> The UI was initially designed for syncs from Debian, which of course are always source-only
<sil2100> wgrant, LocutusOfBorg: checked with `queue show-urls` and all 3 look like bin-syncs indeed!
<sil2100> ;)
<seb128> Laney, bug #1874103 minir/probably too late for release now so just as a FYI
<ubot5> bug 1874103 in ubiquity (Ubuntu) "The new RST page doesn't load translations" [Undecided,New] https://launchpad.net/bugs/1874103
<wgrant> sil2100: Thanks for checking!
<Laney> seb128: thanks, annoying, I tried to upload that early specifically to make translations work :(
<Laney> if someone could dig in that would be appreciated
<seb128> I will try to have a look
<sil2100> wgrant, LocutusOfBorg: ok, accepted o/
-queuebot:#ubuntu-release- Unapproved: accepted ceph [sync] (focal-proposed) [15.2.1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ruby2.7 [sync] (focal-proposed) [2.7.0-5ubuntu1]
<wgrant> sil2100: Many, many thanks
-queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-10 [sync] (focal-proposed) [1:10.0.0-4ubuntu1]
<vorlon> sil2100, bdmurray, Laney: https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/1873867 is coming in hot, I just talked with tseliot and I'm going to do a reupload of nvidia and he's working on getting ubuntu-drivers-common landed so that the 3rd-party drivers selection on the CD is capable of picking the matching driver for the kernel
<ubot5> Ubuntu bug 1873867 in ubuntu-drivers-common (Ubuntu) "ubuntu-drivers changes kernel flavour when installing nvidia" [Undecided,Confirmed]
<LocutusOfBorg> lovely thanks!
<Laney> vorlon: thanks, we know, it's tracked on the document linked in the topic
<vorlon> ok
<sil2100> vorlon: awesome, thanks, we're waiting on this one o/
<doko> waveform, vorlon: https://launchpad.net/ubuntu/+source/linux-raspi ask for promotion, however this isn't seeded anywhere
<doko> sforshee: ^^^
<LocutusOfBorg> kanashiro, wrt ruby2.7 rb_num2int this symbol is listed twice on your debian upload, please make sure you grab the symbols file from [2.7.0-5ubuntu1]
<LocutusOfBorg> +        LIBS="-latomic" ./configure $(configure_options)
<LocutusOfBorg> and still the tab -> spaces issue that makes riscv64 FTBFS
-queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (focal-proposed) [2.2.46-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ubiquity (focal-proposed/main) [20.04.14 => 20.04.15] (core)
<vorlon> mwhudson: was just not sleeping ;)
<sil2100> doko: linux-raspi is not seeded anywhere as we don't have any per-device seeds (but maybe we should pull it somewhere), it's being pulled in via livecd-rootfs for our raspi image builds though
<vorlon> wgrant: the last time I did a self-copy, the i386 build records were not created; the code changed since then?
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-440 (focal-proposed/restricted) [440.82+really.440.64-0ubuntu4 => 440.82+really.440.64-0ubuntu5] (i386-whitelist)
<LocutusOfBorg> where is the time we process removal from debian in ubuntu? is it already past or is it coming?
<LocutusOfBorg> infinity^ IIRC you are the one doing this job before relase, right?
<vorlon> he is not
<vorlon> what specifically are you looking to have removed?
<LocutusOfBorg> I'm interested in having some package removed that is gone long time ago in debian
<LocutusOfBorg> node-run-sequence
<vorlon> because at this point we shouldn't auto-process removals because it's too late for someone to object if we take away a leaf package that's interesting to them
<vorlon> ok, I'll go back and get that one
<LocutusOfBorg> thanks, it makes pegjs migrate
<LocutusOfBorg> we still have the camitk hint to fix, it should become a bump or a testreset
<doko> sil2100: should that be seeded in platform.focal/supported-kernel-common ?
<vorlon> doko: yes
<vorlon> doko: done (and took out snapdragon while I was at it)
<doko> vorlon, waveform: the packages don't have a subscriber
<doko> kernel team?
<vorlon> doko: yeah
<doko> apw, sforshee: ^^^linux-raspi & linux-meta-raspi
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (focal-proposed) [1.450]
-queuebot:#ubuntu-release- Unapproved: accepted libslirp [source] (focal-proposed) [4.1.0-2ubuntu2]
<apw> doko, subscribed
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (focal-proposed) [20.04.15]
-queuebot:#ubuntu-release- Unapproved: spice (focal-proposed/main) [0.14.2-4ubuntu2 => 0.14.2-4ubuntu3] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-440 [source] (focal-proposed) [440.82+really.440.64-0ubuntu5]
<bdmurray> seb128: Have you made any progress on bug 1871960?
<ubot5> bug 1871960 in libgtk3-perl (Ubuntu Focal) "package libpam-modules 1.1.8-3.6ubuntu2.18.04.1 failed to install/upgrade: pre-dependency problem - not installing libpam-modules:amd64" [Critical,Confirmed] https://launchpad.net/bugs/1871960
<seb128> bdmurray, I found one potential issue for which I'm about to upload a fix but I'm not sure it's enough
-queuebot:#ubuntu-release- Unapproved: pango1.0 (focal-proposed/main) [1.44.7-2ubuntu3 => 1.44.7-2ubuntu4] (core, i386-whitelist)
<seb128> bdmurray, ^
<LocutusOfBorg> vorlon, please autopkgtest for black and camitk! (they are NBS, please hint-reset or whatever)
<bdmurray> seb128: what are your concerns about it not being enough?
<seb128> bdmurray, it's a potential case of partial upgrade problem solved but I'm not convinced there isn't upgrade ordering issues between bindings/gobject introspection/the lib
<seb128> bdmurray, it would help if I was able to trigger the buggy situation but my upgrade tests didn't fail that way
<seb128> bdmurray, in any case the change should be a step in the right direction
<bdmurray> seb128: do you have a good test case for it?
<seb128> no
<seb128> I just hit the problem where in dist-upgrades things would fail to start while pango binaries were partially upgraded
<seb128> but shrug, in session upgrades :/ I'm testing an upgrade now and pango/gtk and iU and anything gtk fails to start on hitting bug #1627564
<ubot5> bug 1627564 in gtk+3.0 (Ubuntu) "Crash due to assertion failure in ensure_surface_for_gicon [gtkiconhelper.c:493] (when png loader is missing/during upgrades)" [Medium,Confirmed] https://launchpad.net/bugs/1627564
<seb128> and it has been like 3 minutes now that gtk is out of order and packages are being set up, so I guess anything needed debconf-gtk would fail during that time
-queuebot:#ubuntu-release- Unapproved: python-pip (focal-proposed/universe) [20.0.2-5 => 20.0.2-5ubuntu1] (no packageset)
<tumbleweed> ^^ horrible hack. but should unbreak python2 virtualenvs again
-queuebot:#ubuntu-release- Unapproved: accepted python-pip [source] (focal-proposed) [20.0.2-5ubuntu1]
<Laney> seb128: this feels like a hard bug :(
<Laney> are we going to need to do something like upgrade the debconf frontend and all its dependencies first? (would that even be feasible?)
<seb128> I was wondering that, if we should upgrade libgtk-3-0 upfront
<Laney> that would have to use the noninteractive frontend I guess
<cjwatson> There's some horrible stuff in debconf's frontend code that tries to work out whether gtk is working and falls back if it isn't, but it no doubt isn't complete
<cjwatson> https://salsa.debian.org/pkg-debconf/debconf/-/blob/master/Debconf/FrontEnd/Gnome.pm#L162
<cjwatson> And maybe particularly https://salsa.debian.org/pkg-debconf/debconf/-/blob/master/Debconf/FrontEnd/Gnome.pm#L180
<cjwatson> Of course trying to fix that is difficult if debconf might not have been upgraded first?  I don't know the ordering here
<cjwatson> (Sorry about the variable naming and stuff there, it's from before my time)
<cjwatson> But I think ideally we'd extend the child process test code there to try to catch this sort of thing
<cjwatson> Of course there are other problems with being in a situation for an extended period of time where you can't start new desktop windows
<seb128> cjwatson, would that be resilient to gtk segfaulting/aborting? or would that take the debconf process down in segfault with it?
<cjwatson> seb128: That's the point of it spawning a child process there
<cjwatson> The whole idea is exactly to be resilient against gtk segfaulting/aborting
<seb128> right, I asked a bit too early, I read that now
<cjwatson> But only if the child process does enough to actually tickle the bug
<Laney> ah yeah, I guess it'd need to show some text to make the pango errors happen
<seb128> so maybe the pango fix is enough
<vorlon> LocutusOfBorg: black doesn't look like an NBS issue, it seems to be trying to download test deps from pypi and failing, that is not obviously an ignorable architecture regression
<seb128> the gtk loader/icon thing would probably be handled by the test code
<vorlon> LocutusOfBorg: camitk is easier, bumping the hint
<doko> apw: promoted
<sil2100> Hello everyone! Another status update as per the discourse thread: we will be spinning another set of test images as soon as ubiquity migrates, though we are still waiting for a few other packages before we can build real RC images
<sil2100> Basically we're waiting for: migration of openssl (CVE fix), upload of ubuntu-drivers-common (the nvidia driver installation issue)
-queuebot:#ubuntu-release- Unapproved: julia (focal-proposed/universe) [1.4.0+dfsg-0ubuntu1 => 1.4.1+dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted julia [sync] (focal-proposed) [1.4.1+dfsg-1]
<mdeslaur> apologies for the openssl upload folks, I forgot how long the autopkgtests would take
<vorlon> mdeslaur: are you expecting this to go to the release pocket?
<bdmurray> He is
<vorlon> ok
<coreycb> Hi release team, would it be ok if I seed placement for focal for bug 1805691? The MIR is already approved.
<ubot5> bug 1805691 in placement (Ubuntu) "[MIR] placement" [Undecided,In progress] https://launchpad.net/bugs/1805691
-queuebot:#ubuntu-release- Unapproved: accepted pango1.0 [source] (focal-proposed) [1.44.7-2ubuntu4]
<Laney> ^- proposed fix from seb128 for bug #1871960 which bdmurray could reproduce and will test once built in -proposed
<ubot5> bug 1871960 in libgtk3-perl (Ubuntu Focal) "package libpam-modules 1.1.8-3.6ubuntu2.18.04.1 failed to install/upgrade: pre-dependency problem - not installing libpam-modules:amd64" [Critical,Confirmed] https://launchpad.net/bugs/1871960
<vorlon> coreycb: yes, promotions to main are not blocked by freeze
<coreycb> vorlon: great, I've updated supported-misc-servers and pushed
<bdmurray> images are being rebuilt now b/c of linux and ubiquity but there will be another respin tomorrow
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Focal Final] has been updated (20200421)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Focal Final] has been updated (20200421)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Focal Final] has been updated (20200421)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Focal Final] has been updated (20200421)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Focal Final] has been updated (20200421)
-queuebot:#ubuntu-release- Unapproved: rejected shim-signed [source] (eoan-proposed) [1.39.2]
-queuebot:#ubuntu-release- Unapproved: rejected shim [sync] (eoan-proposed) [15+1552672080.a4a1fbe-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected shim-signed [source] (bionic-proposed) [1.37~18.04.6]
-queuebot:#ubuntu-release- Unapproved: rejected shim [sync] (bionic-proposed) [15+1552672080.a4a1fbe-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected shim [sync] (xenial-proposed) [15+1552672080.a4a1fbe-0ubuntu1]
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Focal Final] has been updated (20200421)
<fginther> vorlon, are you interested in reviewing some ubuntu-drivers-common code? :)
<vorlon> fginther: possibly
<fginther> vorlon, looking for a second set of (good) eyes for the update tseliot was working on
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Focal Final] has been updated (20200421)
<Laney> yes!
<Laney> (not me)
<Laney> (yes for someone to review it :>)
<fginther> these would be the commits over the past 2 days @ https://github.com/tseliot/ubuntu-drivers-common/commits/master
<vorlon> fginther: ok - I think I should be able to look it over in an hour or so.  Feedback where?
<fginther> umm, replying to the email from Alberto should be fine
<fginther> and thanks
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Focal Final] has been updated (20200421)
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Focal Final] has been updated (20200421)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Focal Final] has been updated (20200421)
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Focal Final] has been updated (20200421)
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Focal Final] has been updated (20200421)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi [Focal Final] has been updated (20200421)
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi [Focal Final] has been updated (20200421)
-queuebot:#ubuntu-release- Unapproved: vala (focal-proposed/universe) [0.48.3-1 => 0.48.4-0ubuntu1] (i386-whitelist, ubuntu-desktop)
<jbicha> Feel free to reject subtitleeditor from focal queue. I didn't realize it was seeded & the change isn't important
-queuebot:#ubuntu-release- Unapproved: rejected subtitleeditor [sync] (focal-proposed) [0.54.0-4]
-queuebot:#ubuntu-release- Unapproved: fusiondirectory (focal-proposed/universe) [1.3-1ubuntu1 => 1.3-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gosa (focal-proposed/universe) [2.7.4+reloaded3-10ubuntu1 => 2.7.4+reloaded3-11] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted fusiondirectory [sync] (focal-proposed) [1.3-2]
-queuebot:#ubuntu-release- Unapproved: accepted gosa [sync] (focal-proposed) [2.7.4+reloaded3-11]
-queuebot:#ubuntu-release- Unapproved: python-jsonrpc (focal-proposed/universe) [1.12.1-1ubuntu1 => 1.13.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-jsonrpc [sync] (focal-proposed) [1.13.0-1]
<wgrant> vorlon: self-copy build creation> Huh, very weird. If it happens again, worth pinging us to investigate since that's meant to work.
<vorlon> wgrant: ok
<wgrant> The last thing _do_direct_copy does is call createMissingBuilds unconditionally, and there isn't much opportunity for short-circuiting before that.
<sforshee> / rake
-queuebot:#ubuntu-release- Unapproved: pypy3 (focal-proposed/universe) [7.3.1+dfsg-2 => 7.3.1+dfsg-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pypy3 [sync] (focal-proposed) [7.3.1+dfsg-3]
-queuebot:#ubuntu-release- Unapproved: libguestfs (focal-proposed/universe) [1:1.40.2-7ubuntu4 => 1:1.40.2-7ubuntu5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted libguestfs [source] (focal-proposed) [1:1.40.2-7ubuntu5]
-queuebot:#ubuntu-release- Unapproved: cclib-data (focal-proposed/multiverse) [1.6.2-1 => 1.6.2-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted cclib-data [sync] (focal-proposed) [1.6.2-2]
<xnox> Laney:  it's better, but for some reason still installs nvidia-dkms-440 stuff i think it does not consider provides
<xnox> apw:  vorlon: we have missmatch again
<xnox> apt show nvidia-driver-440 | grep Depends
<xnox> nvidia-dkms-440 (= 440.82+really.440.64-0ubuntu5) | nvidia-dkms-440 (= 440.64-0ubuntu3)
<xnox> apt show linux-modules-nvidia-440-generic-hwe-20.04 | grep Provides
<xnox> nvidia-dkms-440 (= 440.82+really.440.64-0ubuntu4)
<xnox> i need to upload nvidia drivers again?
<xnox> or will there be a matching l-r-m upload?
#ubuntu-release 2020-04-22
<xnox> apw:  if you are up, feel free to just dial my mobile if you want to chat aobut what we should rebuild to make provides & depends to align
<xnox> or maybe try to catch steve if he is about
<vorlon> xnox: ah.  No, just need to reupload nvidia to adjust the hard-coded version in the | branch
<xnox> vorlon:  please do that. cause otherwise our testing of fixed up ubuntu-drivers-common goes astray and we install both lrm & dkms
<vorlon> xnox: uploaded
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-440 (focal-proposed/restricted) [440.82+really.440.64-0ubuntu5 => 440.82+really.440.64-0ubuntu6] (i386-whitelist)
<xnox> apw:  Laney: verified that ^ matches the depends provides of the linux-restricted-modules package.
 * xnox runs queue accept to be told denied
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-440 [source] (focal-proposed) [440.82+really.440.64-0ubuntu6]
<vorlon> xnox: ^^
-queuebot:#ubuntu-release- Unapproved: pypy3 (focal-proposed/universe) [7.3.1+dfsg-3 => 7.3.1+dfsg-4] (no packageset)
<tumbleweed> ^ that's a fakesync because time is getting tight and I found *another* RC bug
-queuebot:#ubuntu-release- Unapproved: accepted pypy3 [source] (focal-proposed) [7.3.1+dfsg-4]
<tumbleweed> ta
<mwhudson> releasing another subiquity to stable/ubuntu-20.04, hopefully the last one
<mwhudson> but i hoped that yesterday too!
<cpaelzer> Hi release team, I wanted to ping and ask for spice in focal-unapproved
<cpaelzer> I'm unaware of the current state of the release (re)spinnign, so itf it doesn't fit it is fine to postpone
<cpaelzer> it could to some extend be an SRU, but if the times are good to get such a set of fixes in I'd appreciate if we could do so now
-queuebot:#ubuntu-release- Unapproved: 389-ds-base (focal-proposed/universe) [1.4.3.6-1 => 1.4.3.6-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted 389-ds-base [sync] (focal-proposed) [1.4.3.6-2]
<sil2100> o/
<vorlon> cpaelzer: what kind of autopkgtests get triggered by spice, how long would they all take to run?  because it looks to me like openssl has migrated now, so there are no other blockers that I know of for the respin.  OTOH spice is only seeded on the d-i images so it could be possible to respin only those
<cpaelzer> hi vorlon, I'm checking which would be triggered
<cpaelzer> ...
<cpaelzer> vorlon: the rev-deps only hold src:qemu and src:xserver-xorg-video-qxl which both have no debian/test/... dir - spice itself has d/t/control
<cpaelzer> so its own tests would run
<cpaelzer> but I see no "others" that would be triggered
<vorlon> cpaelzer: ok. I'll turn you over to sil2100 for the actual decision, I was just asking the question :)
<cpaelzer> but really I don't want to be blocking anything, if the spin is ready pelase postpone spice
<cpaelzer> we can make it a zero day SRU at almost no difference
<cpaelzer> I say almost for the few people that test focal on a focal host
<cpaelzer> vorlon: so if you can release the respin please do not think about spice and do the spin :-)
<cpaelzer> we can work the spice fixes in later on ...
<sil2100> Let me get back to you in a minute
<sil2100> cpaelzer: hey! I see the targeted but is set to 'Critical' - when did those crashes start? Were those always around, or did kernel/other-dep-package changes suddenly cause this to get worse?
<sil2100> Just trying to understand the severity better, since we had the same version in eoan as well
<cpaelzer> hi sil2100
<cpaelzer> the crashes are potentially in there since forever but at least since the last merge (June 2019)
<cpaelzer> they exist but are not common
<cpaelzer> the resize issue is more likely to happen
<cpaelzer> as using spice isn't an uncommon setup
<cpaelzer> sil2100: are I told vorlon don't spend too mcuh time on it for the spin, do the spin and accept it afterwards as a zero-day SRU - that would be fine for me as well if that works for you
<cpaelzer> sil2100: lets drop the sev to high
<cpaelzer> initially I was unsure how liekly the crashes would be and set it to crti, but since then I have checked a bit and found no real report for them outside of the bugs linked in the commits
<sil2100> cpaelzer: yeah, so to minimize the risk of things going crazy during release, I'd opt for this to be a 0-day SRU
<cpaelzer> ack
-queuebot:#ubuntu-release- Unapproved: rejected nginx [source] (focal-proposed) [1.18.0-0ubuntu1]
<cpaelzer> sil2100: what do we do to make this happen for now?
<cpaelzer> keep i tin unapproved and revisting ... ?when?
<cpaelzer> or rather "revisiting"
<rbalint> sil2100, i have two small fixes for systemd's LP: #1870930 and LP: #1870410
<ubot5> Launchpad bug 1870930 in systemd (Ubuntu Focal) "systemctl crashed with SIGSEGV" [High,Confirmed] https://launchpad.net/bugs/1870930
<ubot5> Launchpad bug 1870410 in systemd (Ubuntu Focal) "wireless does not work on boot on RPi 3s" [Undecided,In progress] https://launchpad.net/bugs/1870410
<wgrant> sil2100: Since we're going to respin, thoughts on letting zeromq3 through? It's all good to migrate, except for the block.
<rbalint> sil2100, could they go in? working wifi on rpi2/3 would be nice out of the box
<sil2100> cpaelzer: we'll track it as a 0-day SRU, so I'll accept it into -proposed but we'll only release it after release
<sil2100> rbalint: hm, I would really like to say 'no' for now
<sil2100> Since this is systemd, this is the last thing we'd want to release right now - then again, no wifi on the Pi3's sucks
<sil2100> rbalint: do you have it staged somewhere?
<rbalint> sil2100, i'm about o upload to bileto
<rbalint> sil2100, but not yet
<rbalint> sil2100, i'm stating it and we can decide later?
<rbalint> staging
<sil2100> rbalint: yes, please
<rbalint> sil2100, 0-day sru can also be the target
<sil2100> eh
<sil2100> rbalint: I think we either take it for release or do a usual SRU, since I don't think there's much merit of it going as an 0-day SRU, since if you're affected by no-wifi, you anyway have to workaround it to get the update (if there's no ethernet)
<sil2100> rbalint: so yes, please stage it in bileto, and we then can pull it in
<sil2100> (don't run the ADT tests on it though via bileto yet)
<rbalint> sil2100, ack, i was about to ask :-)
-queuebot:#ubuntu-release- Unapproved: accepted spice [source] (focal-proposed) [0.14.2-4ubuntu3]
<rbalint> sil2100, building in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3801
<sil2100> Thanks
<rbalint> sil2100, there is also LP: #1872902 with 4 different solutions proposed but without any of them landed
<ubot5> Launchpad bug 1872902 in ubuntu-release-upgrader (Ubuntu Focal) "Upgrade to Focal now removes chrony" [Critical,Triaged] https://launchpad.net/bugs/1872902
<sil2100> rbalint: yeah, that is an upgrade issue so we can solve it later
<sil2100> rbalint: ok, so now I finally sat down on this bug and I did remember correctly this being fixed! So apparently you mention that the previous fix didn't fix all the configurations?
<sil2100> In which cases is it still broken with the current systemd?
<rbalint> sil2100, yes, wifi still fails on boot on specific boards
<rbalint> sil2100, on slow rpi3s and rpi2s
<sil2100> What are the criteria for that? Like, how many boards would be affected? Which pi3 boards are slow? Pi2 is not ciritcal as this is not a 'default' setup, since you need to have a wifi dongle or similar
<sil2100> Asking since we did not see this issue in the lab
<rbalint> i think waveform could give much better estimates than me
<sil2100> Since there is a difference between: a) wifi doesn't work on all pi3's, b) wifi doesn't work for some pi3's, c) wifi doesn't work on a few selected pi3 revisions
<rbalint> sil2100, i guess there are way more slow boards in use out there than fast ones
<waveform> sil2100, rbalint is correct there's more 3s out there than 4s, but I *suspect* (purely anecdotally, just going by what I've seen on forums and IRC) that the mix of ubuntu users on the pi skews towards people with 4s. Still, it's a serious issue for anyone wanting to use a 3B as a wifi-headless box
<waveform> so if there's a possibility of getting the fix in there, I'd like it in there
<Laney> I guess we'll have to take it then
<Laney> but this is really not ideal, it's delaying our final builds on the day before release
<sil2100> Yeah
<sil2100> We have to take it, but this being systemd we also wouldn't want to fast-track it
<sil2100> It really really sucks because systemd always introduces huge issues
<sil2100> (when things go down)
<sil2100> rbalint, waveform: once systemd builds, could you both give it a quick test? We'd want to bin-copy it ASAP when we know it's fixing all the issues
<rbalint> Laney, sil2100 is doing a respin for rpi only with only systemd 0-day let in an option?
<waveform> sil2100, will do - I'll test it on everything :)
<tseliot> sil2100, hey, any ideas why my focal installation doesn't see nvidia-driver-440 440.82+really.440.64-0ubuntu6 . My sources.list https://pastebin.ubuntu.com/p/8dkwbgnkc3/
<waveform> sil2100, Laney, and my apologies for the last minute horror!
<rbalint> sil2100, Laney, mine, too
<sil2100> rbalint: all images need to be in-sync, so every image that we publish that has systemd needs to have the same version
<sil2100> tseliot: hm, so you don't see it when trying to install with apt? I see it via rmadison, and I geuss your sources are correct
<sil2100> hm, archive mirroring issues perhaps? I guess not
<tseliot> sil2100, no, I can only see 440.82+really.440.64-0ubuntu5, no matter how often I apt-get update
<rbalint> waveform, sil2100  the package is ready in ppa:ci-train-ppa-service/3801 (riscv64 is still building)
<sil2100> tseliot: really weird! Even with the same sources I can still see ubuntu6
<tseliot> sil2100, yes, my chroot sees the update too
<waveform> rbalint, already downloading :)
<sil2100> tseliot: this is weird, last time I had issues like that was due to the mirror, but here it shouldn't be like that - feels like it's cached with an older version?
<sil2100> Not sure if anyone else has any ideas
<tseliot> sil2100, yes, I'm going to reinstall. My other testing box works fine, so I'm going to use that for now
<sil2100> Status update for the release: we have the ubuntu-drivers-common in testing, but we're also working on getting the Pi3 WiFi issue sorted - we're currently waiting for the riscv64 build to finish, but we're looking at ways to speed up the process and run archive ADT tests already
<wgrant> sil2100: You could just copy it in and let the riscv64 binary rebuild in the primary archive
<wgrant> Since that won't block autopkgtests
<wgrant> (will block migration unless overridden, though)
<Laney> That's what we're considering
<sil2100> wgrant: yep!
-queuebot:#ubuntu-release- Unapproved: systemd (focal-proposed/main) [245.4-4ubuntu1 => 245.4-4ubuntu3] (core, i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted systemd [sync] (focal-proposed) [245.4-4ubuntu3]
<sil2100> rbalint, waveform: we have already bin-copied systemd from the silo (without waiting for riscv64, we'll make it build in the archive) - so that we can get the tests running early
<waveform> sil2100, same here: https://launchpad.net/~waveform/+archive/ubuntu/systemd/+packages :)
<rbalint> sil2100, waveform my rpi's wifi is fixed with 245.4-4ubuntu3, thanks for copying it in!
<waveform> rbalint, sil2100, confirmed the fix on arm64 on 3B and 3B+, just waiting for an armhf card to flash while I test it on 4B too (just to make sure it doesn't break anything on there)
<tseliot> sil2100, xnox u-d-c will try to installÂ linux-modules-nvidia-440-generic-hwe-20.04 even thoughÂ linux-generic-hwe-20.04, which should still be correct, sinceÂ linux-generic-hwe-20.04 depends onÂ linux-image-5.4.0-26-generic (throughÂ linux-image-generic-hwe-20.04). What happens if, in the future, linux-image-generic-hwe-20.04 moves to a different major version?
<xnox> tseliot:  linux-modules-nvidia-440-generic-hwe-20.04 is the right package to install, because it is also a metapackage
<rbalint> sil2100, the crash with Unity is also gone
<xnox> tseliot:  and it moves with linux-image-generic-hwe-20.04 in tandem
<xnox> tseliot:  because the actual package that provides modules is what linux-modules-nvidia-440-generic-hwe-20.04 depends on, i.e. -5.4.0-ABI-.....
<tseliot> xnox, right, but I only have linux-generic installed here: https://pastebin.ubuntu.com/p/JczMkW6rFK/
<xnox> tseliot:  your system is missconfigured.
<xnox> tseliot: you should either have: linux-generic manually installed, with everything else as automatic.
<xnox> tseliot:  of you should have linux-generic-hwe-20.04 installed, with everything else as automatic
<xnox> tseliot:  if you have _multiple_ kernel flavours installed (i.e. both linux-generic and linux-lowlatency) i think the right thing is to install modules for _all_ metas, as one can boot all of them
<xnox> tseliot:  but our support is bad, when people have multiple kernel flavours installed (i.e. a random one becomes the default boot entry)
<tseliot> xnox, this is an upgrade from Eoan, and linux-generic was the default flavour there. This is what we should expect in most dist-upgrades
<xnox> tseliot:  upgraded systems will all have linux-generic
<xnox> tseliot:  nothing on upgrade installs linux-generic-hwe-20.04
<xnox> tseliot:  only fresh focal installs with latest focal daily install linux-generic-hwe-20.04
<xnox> apw:  cjwatson: http://paste.ubuntu.com/p/YzQ7rqScXg/
<tseliot> xnox, right. So, in that case, ubuntu-drivers should install linux-modules-nvidia-440-generic instead
<xnox> injected set -x into postinst, and running it under ubiquity, which runs under ubiquity managed debconf, which runs ubuntu-drivers, which subprocess.calls() apt-get install modules and eventually l-r-m postinst which fails
<xnox> tseliot:  what's your systems $ dpkg-query -W 'linux-image-*' | pastebinit ?
<xnox> tseliot:  also kind of at the moment trying to debug debconf postinst issue, unrelated to what ubuntu-drivers-common picks to install.
<xnox> apw:  cjwatson: i guess i should try to strace all of that as well, to see what filedescriptor 3 should be.....
<tseliot> xnox, https://paste.ubuntu.com/p/wwchyTBd3f/
<waveform> sil2100, rbalint, confirmed systemd fix works nicely on armhf and arm64 on pi 3b, 3a+, 3b+, and 4b - I'd say it's good to go
<xnox> tseliot: this is odd, you don't have secureboot on?
<xnox> tseliot:  because we never install unsigned kernel images.
<apw> if ubiquity is asking the question in advance, it could seed the answer right?
<tseliot> xnox, yes, it's off. I can enable it
<cjwatson> xnox: OK, so that definitely doesn't look like a bug in the postinst
<cjwatson> xnox: Looks like DEBIAN_HAS_FRONTEND=1 was probably set in the environment but in fact fd 3 was closed
<cjwatson> or DEBCONF_REDIR or whatever it is, I forget and am in a meeting
<sil2100> waveform, rbalint: thanks for the testing!
<xnox> cjwatson:  we do have those two variables set in the environmet..... and debconf database is locked, and we still can't add a new template, to then query it.
<xnox> so we need to ensure that fds don't get closed
<jbicha> please accept the Sugar packages from the NEW queue. They were removed earlier because of pygtk/python2 but they have switched to python3 now
-queuebot:#ubuntu-release- Unapproved: codespell (focal-proposed/universe) [1.16.0-1ubuntu1 => 1.16.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted codespell [sync] (focal-proposed) [1.16.0-2]
<mwhudson> sil2100: will we have images today?
<mwhudson> fsvo
<sil2100> mwhudson: ...hopefully? ;)
<mwhudson> sil2100: :)
<mwhudson> sil2100: good luck
 * mwhudson is going to bed
<sil2100> mwhudson: so we're still working on the ubuntu-drivers-common, and we need to wait for ALL the systemd triggered tests to finish
<mwhudson> (having had an unexpected nap on the sofa already...)
<sil2100> mwhudson: thanks, goodnight!
<kanashiro> locutus__: re ruby2.7: the symbols file is correct, there is no duplicated entry for rb_num2int. However, my text editor config did not help me and there is an extra space in that line in d/rules indeed. I am fixing it.
<tseliot> apw, xnox, let's say that, in the future, linux-generic-hwe-20.4 moves to a different kernel version e.g. 5.6, then what is the linux-image going to be called? Currently it's linux-image-5.4.0-26-generic.
<xnox> tseliot:  please not now
<xnox> tseliot:  we are currently experience severe brakage in ubiquity
<xnox> apw:  cjwatson: are you available in the hangout please?
<tseliot> ok, I'll leave things as they are then. I'm definitely not going to work over time today though.
<xnox> tseliot:  linux-generci-hwe-20.04 moving to 5.6, is no different of -25- to -26- abi change. because meta's are still going to be called the same.
<tseliot> will it be "-generic" though?
<xnox> and linux-image-generic-hwe-20.04 will depend on linux-image-5.6.0-9999-geneirc, and so will linux-modules-nvidia-4440-$flavour etc.
<xnox> tseliot:  see bionic, yes.
<tseliot> ok, that's all I needed to know
<xnox> ..
<xnox> apw:  i think i need l-r-m upload with db_get || true
<xnox> apw:  or explain to me why linux/nvidia/latelink does not exist
<tseliot> I think linux/nvidia/latelink was supposed to be created by the user. If that doesn't exist, then debconf will ask the question
<apw> xnox: which is how debconf works as far as I understand
<xnox> apw:  please join the hangout
<apw> I cannot right now, i am afk, covering kiddies due to covid
<xnox> apw:  ack
<apw> tseliot: it is allowed.to be made in advance, if not debconf is used to ask the question and fill in that file the first time you install, from then on it is fillee
<apw> xnox: ^
<apw> you can also seed over the default if the file exists I believe
<cjwatson> xnox: not for at least an hour
<cjwatson> xnox: what is the specific unabbreviated package name here please?
<sil2100> cjwatson: so the .postinst that fails because of debconf is in linux-restricted-modules
<sil2100> cjwatson: so far we're investigating what's up, since when we execute `ubuntu-drivers install` directly, we see both the debconf .config is being executed before the .postinst and then everything works
<sil2100> But when executed via ubiquity in its environment, it's only the .postinst that runs and fails as the linux/nvidia/latelink is not set up
<cjwatson> N: Unable to locate package linux-restricted-modules
<cjwatson> linux-restricted-modules seems like a source package - what's the binary package name?
<sil2100> I guess it's linux-modules-nvidia-440-5.4.0-26-generic  ? Let me just double check
<cjwatson> That binary package has the linux/nvidia/latelink template in DEBIAN/templates
<cjwatson> Which means that debconf registers the template before the postinst gets as far as trying to ask the question
<cjwatson> It is emphatically wrong to need to guard the db_get in that situation
<cjwatson> Something else is wrong if you find that you have to
<cjwatson> I disagree with tseliot that it is supposed to be created by the user.  That is not what the package metadata I see here does
<cjwatson> (I mean, sure, perhaps it may be preseeded, but it doesn't have to be
<cjwatson> 0
<apw> cjwatson, right the assumption is not that the user fills it; my understanding of what i created was it will use the last answer if there was one, else it will ask
<cjwatson> That is correct but not really what's at issue here
<apw> cjwatson, right, if you think it does that, all is well on that side of the plate
<cjwatson> The point is that the question should *exist* in the debconf db (regardless of its value) by the time that code runs
<cjwatson> The code is a bit complex and I don't want to say that it's definitely correct at this point, but it's not incorrect in this particular way as far as I can see :)
<tseliot> yes, I didn't really phrase it correctly. apw already said what I wanted to say
<Laney> We've added some tracing and the .config file isn't being executed in the 'bad' case
<Laney> not quite sure why
<locutus__> thanks kanashiro !
<sil2100> rbalint: thanks for retriggering some of the flacky tests! I retriggered the ones that had testbed issues
<sil2100> (didn't see them running yet)
<sil2100> Also unblocked systemd in case the tests finish, so far looking good
<sil2100> Ok, systemd testing looks good, I think everything finished running besides systemd's own tests and the 2 testbed failures I retried - riscv64 build also finished and will be published soon
<sil2100> Laney, xnox: crap, just looked at the bug paride poked us about LP: #1874243
<ubot5> Launchpad bug 1874243 in subiquity " An error occured handling 'dm_crypt-0': TypeError - join() argument must be str or bytes, not 'NoneType'" [Undecided,New] https://launchpad.net/bugs/1874243
<sil2100> This really feels release critical, especailly if the test case here is using LVM with encryption
<sil2100> mwhudson: (fyi once you're up ^)
<paride> sil2100, yes the case here is just using lvm with encryption
<paride> I'm not sure that's more subiquity or more curtin
<paride> rharper, ^^
<sil2100> paride: do you know if it was the case with older images? Is there a way we could pin-point when it all got bad?
<paride> sil2100, I can't tell exactly when it regressed, as we don't have an automated test for enrypted lvm
<paride> and I don't have older images around
<bdmurray> you could try the beta
<bdmurray> paride: ^
<paride> bdmurray, it's gone :/
<sil2100> http://releases.ubuntu.com/20.04/ <- will those auto-refresh subiquity?
<paride> I'm going to test 20200417 without refreshing subiquity
<paride> ah thanks sil2100, there's the beta
<paride> bdmurray, I did look only on cdimage.ubuntu.com
<sil2100> paride: it is confusing yes!
<sil2100> ;)
<jibel> bdmurray, I've another issue with upgrades from 18.04 to focal. The task "Searching for obsolete software" never ends. It's is not a loop, it's like it's trying to MarkDelete all the packages 1 by 1 and fail.
<jibel> bdmurray, I'll paste the logs somewhere
<jibel> OTOH no crash of gtk-perl
<bdmurray> jibel: hunh, that worked for me yesterday
<jibel> yes it did
<jibel> same base VM
<jibel> standard bionic install, with all updates applied
<jibel> bdmurray, main.log https://paste.ubuntu.com/p/sb5YmkQ9RS/
<jibel> bdmurray, apt.log https://people.canonical.com/~j-lallement/apt.log
<jibel> can you try to reproduce it?
<bdmurray> yes, rebooting my vm now
<paride> sil2100, bdmurray, the beta was failing already
<sil2100> Holy shit, how did we not notice
<sil2100> Do we have encrypted LVM in the test cases?
<sil2100> Guess we'll have to fill in this gap, since I don't see it on the isotracker
<paride> sil2100, there is one but only for the legacy d-i installer
<paride> the subiquity test cases really need to be expanded
<bdmurray> jibel: I always forget to use eatmydata
-queuebot:#ubuntu-release- Unapproved: libvirt (bionic-proposed/main) [4.0.0-1ubuntu8.15 => 4.0.0-1ubuntu8.16] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: qemu (eoan-proposed/main) [1:4.0+dfsg-0ubuntu9.4 => 1:4.0+dfsg-0ubuntu9.5] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: qemu (bionic-proposed/main) [1:2.11+dfsg-1ubuntu7.23 => 1:2.11+dfsg-1ubuntu7.24] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: libvirt (eoan-proposed/main) [5.4.0-0ubuntu5.2 => 5.4.0-0ubuntu5.3] (ubuntu-server, virt)
<sil2100> paride: ok, so just-in-case I checked 19.10, but we didn't actually support encrypted LVM back then - and a regular LVM install seems to work there
<paride> sil2100, wait 19.10 did support encrypted lvm
<paride> and it works
<sil2100> paride: oh, it did? I didn't see the option
<paride> you have to choose manual partitioning and it's there when you create the VG
<paride> I just re-tested it just to be sure
<sil2100> Ah, manual, ok
<sil2100> rharper, powersj: hey! We seem to be having issues with subiquity/curtin right now, looks like curtin is the one dying here - LP: #1874243
<ubot5> Launchpad bug 1874243 in subiquity " An error occured handling 'dm_crypt-0': TypeError - join() argument must be str or bytes, not 'NoneType'" [Undecided,New] https://launchpad.net/bugs/1874243
<sil2100> Can we get some of your eyeballs on it? It's a severe issue which we wouldn't want to release with
<rharper> sil2100: yes
<bdmurray> jibel: My upgrade made it to the "remove obsolete packages" dialog and gnome-software-plugin-snap is in the list of things to remove.
<sil2100> rharper: thanks o/
<jibel> bdmurray, re-running to check if it's a one time thing
<RikMills> lvm bug is subiquity only?
<RikMills> I assume
<bdmurray> paride: Is the updated systemd installed?
<paride> not the version that just migrated
<sil2100> tseliot: hello! Can you by any chance upload your ubuntu-drivers-common? I think we have a workaround for all the issues we've been seeing
<tseliot> sil2100, sure
<tseliot> sil2100, uploaded
-queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (focal-proposed/main) [1:0.8 => 1:0.8.1] (desktop-core, ubuntu-server)
<sil2100> tseliot: thank you! \o/
 * sil2100 hugs tseliot 
<tseliot> :)
<vorlon> sil2100: are you reviewing or should I?
<xnox> sil2100: vo
<xnox> vorlon:
<xnox> I think that's incomplete
<juergh> rbasak, can you check/promote an SRU upload for me? linux-firmware for xenial and bionic should be in the upload queue.
<vorlon> xnox: details?
<sil2100> paride, rharper: I think I have a fix for the dm_crypt thing, have a MP but testing it now actually
<sil2100> Laney: ^
<sil2100> bdmurray: ^ (thanks for your help in debugging!)
<rbasak> juergh: sorry, I don't think I'm going to have time today.
<doko> cpaelzer, wgrant: do we really want qemu-sparc in main?
<doko> same for mips
<xnox>  vorlon: join virtual release sprint call
<xnox> vorlon:  we are pondering if we need more than that, or not
<vorlon> xnox: not available
<vorlon> and I don't have a link to this call anyway :P
<rbasak> juergh: from a quick glance, you're missing bug references in your Bionic upload at least. And shouldn't these be going in via the security pocket?
<rharper> sil2100: did you up a PR ?  I can review, and I'm working on a unittest for my bersion
<juergh> rbasak, it's a CVE update. does it need buglinks?
<rbasak> juergh: see my second question
<rbasak> Shouldn't these be going in via the security pocket?
<rbasak> Normally all SRUs would have a buglink with SRU information, or the security team would arrange a security upload through the security pocket which is outside the SRU process. Is this upload exceptional somehow?
<sil2100> rharper: yes! https://code.launchpad.net/~sil2100/curtin/+git/curtin/+merge/382768
<sil2100> rharper: it seems to work, but I'm finishing a test install now
<sil2100> rharper: want to see if it's bootable
-queuebot:#ubuntu-release- Unapproved: rejected linux-firmware [source] (bionic-proposed) [1.173.18]
-queuebot:#ubuntu-release- Unapproved: rejected linux-firmware [source] (xenial-proposed) [1.157.23]
<sil2100> rharper: so it's not adding any new workarounds but 'fixing' an existing workaround (or maybe an actual spec assumption? Not sure!)
<juergh> rbasak, dunno. I've been told 'do this' then 'upload there' :-) it's an old CVE, nothing critical. sorry, we're trying to delegate the maintenance of linux-firmware and it's my first non-kernel SRU upload so I'm still learning.
<sil2100> rharper: ok, installation works, boots and is encrypted
<sil2100> Can you take a look at the MP?
<rbasak> juergh: read up on https://wiki.ubuntu.com/StableReleaseUpdates and https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures please
<rbasak> juergh: you need to pick which process you want to follow. Maybe talk to the security team if you're unsure. But if you want to land this through the SRU process, you need to link a bug with details.
<rbasak> (as per the documented SRU process)
<rbasak> juergh: and I'd want an explanation of why this is not appropriate for security. Because people selecting to receive security updates only won't get a regular SRU.
<rharper> sil2100: ohn you're working around in curtin
<rharper> this should get fixed in subiquity
<rharper> i'll look at your MP though
<vorlon> sil2100: so is there an ongoing conversation about nvidia? since apparently xnox won't type :)
<Laney> vorlon: I sent you an email to the hangout, come play with us
<Laney> at least I think it's an email
<vorlon> Laney: I'm not available
<Laney> I did the invite user thing
<Laney> oh
<vorlon> I'm in a meeting and then I'm afk for an hour
<Laney> well there's about to be an LRM
<Laney> which we think / hope will work around the problemo
<sil2100> rharper: I am *not* working around anything, this is an existing workaround - I am not adding anything new, this is existing curtin code and curtin expectations? ;)
<rharper> what?
<sil2100> rharper: I mean, this has been like that in curtin from the start, from when it worked. From long curting just assumed to use 'id' when 'dm_name' was not available, so I'm not adding any new 'guessing' here
<xnox> apw:  Laney: https://paste.ubuntu.com/p/ggY2bTJxSf/
<rharper> no no no
<rharper> please;  there's a schema and it's a required field for type: dm_crypt
<rharper> the dm_name needs to be present
<sil2100> rharper: so why did curtin not care previously?
<xnox> rharper:  talk to me.
<rharper> it's always required it
<sil2100> rharper: and why are there exsiting lines that default to 'id'?
<rharper> what ?
<xnox> rharper:  i believe that what we did was a guess, we didn't know what we were supposed to pass.
<bdmurray> xnox: does we in the context = curtin?
<rharper> sil2100: I see your patch
<xnox> rbasak:  do you have a patch?
<xnox> rbasak:  unping
<xnox> rharper:  do you have a patch or suggestion?
<xnox> rharper:  cause most likely both code paths are broken. "manually configure encrypted lvm" and "do guided encrypted lvm"
<sil2100> rharper: look at the code, existing code - look at lines 492
<rharper> sil2100: has one for curtin, which is a solid fix
<sil2100> rharper: and the two lines that I moved
<sil2100> Just saying, I'm not proposing any new workarounds! We don't want new workarounds ;p
<rharper> xnox: I do have a patch for subiquity but it was going to use the id of the element anyhow unless someone set a value
<rharper> I'm not proposing a workaround either
<rharper> in any case, I'll review the curtin bits , and put up the subiquity PR and we can decide from there
<xnox> rharper:  would you rather for us to always pass the dm_name & id?
<bdmurray> xnox: I think the best course of action now is to go back to the previous curtin behavior and fix it right for .1
<xnox> vorlon:  sorry, ubuntu-driver-common is good, please review & accept
<vorlon> review done, accepting now
<xnox> bdmurray:  subiquity is the only one that provides the values, but in the future maas & desktop will too. So i do want to ensure that schema is right (of things that it should accept)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-drivers-common [source] (focal-proposed) [1:0.8.1]
<Laney> vorlon: please also unblock
<vorlon> ack
<xnox> rharper:  sil2100: so i'll take sil's branch and vendorize it in the subiquity snap and prepare a release
<xnox> bdmurray:  ^
<xnox> because at this point i'm cherrypicking minimal curtin patch against the commit-id we have
<vorlon> ah
<rharper> xnox: +1
<rharper> sil2100: I added a unittest in the review, if you add that, I can approve and land it
<sil2100> rharper: \o/ thanks, looking
-queuebot:#ubuntu-release- Unapproved: linux-restricted-modules (focal-proposed/restricted) [5.4.0-26.30 => 5.4.0-26.30+1] (core, kernel)
<bdmurray> jibel: any word on your latest upgrade test?
-queuebot:#ubuntu-release- Unapproved: accepted linux-restricted-modules [source] (focal-proposed) [5.4.0-26.30+1]
<sil2100> rharper: pushed, thanks! I think I applied it correctly, since the tests seem to be passing here
<rharper> cool
<rharper> xnox: https://code.launchpad.net/~raharper/curtin/+git/curtin/+merge/382776
<rharper> for jfh 's current multipath hangup
<jfh> rharper: looks reasonable ...
<xnox> rharper:  are you asking to include that in the respin?
<rharper> xnox: yes
<xnox> rharper:  you need sign off from bdmurray Laney apw https://code.launchpad.net/~raharper/curtin/+git/curtin/+merge/382776
<rharper> xnox: out side of approval of that, if you know any more about the RHBZ where I found the details if our multipath-tools uses the disable flag or not, woudl be interesting
<rharper> https://bugzilla.redhat.com/show_bug.cgi?id=869253
<ubot5> bugzilla.redhat.com bug 869253 in device-mapper-multipath "/dev/mapper/mpathX is block device not symbolic link" [Medium,Closed: errata]
<jfh> rharper: well, that also 'explains'  a bit why that at the beginning mostly happened on (low perf) zvm and later in the days (when the system utilization starts) also on LPAR - I guess ...
<xnox> bdmurray:  Laney: sil2100: please review / approve https://github.com/CanonicalLtd/subiquity/pull/731
<gitbot> CanonicalLtd issue (Pull request) 731 in subiquity "Ship rharper hotfix for dm-name" [Open]
<xnox> oh hello gitbot
<rharper> jfh: right ...  Odd_Bloke  was asking about the "sometimes" and my read of the RHBZ mention the number of paths and load of the system, so sometimes the library beat udev to creating an entry
<jfh> rharper: yepp - drove me nearly crazy...
<cking> rharper, oh, so it was quite a racy issue then
<rharper> cking: I never knew that until today ... never had I seen a block device in /dev/mapper, only ever symlinks ... I was quite confused =/
<cking> it's certainly a complex bit of plumbing down there
-queuebot:#ubuntu-release- Builds: Upgrade Kubuntu amd64 [Focal Final] has been updated (20200421)
-queuebot:#ubuntu-release- Builds: Upgrade Ubuntu MATE amd64 [Focal Final] has been updated (20200421)
-queuebot:#ubuntu-release- Builds: Upgrade Ubuntu Server amd64 [Focal Final] has been updated (20200421)
-queuebot:#ubuntu-release- Builds: Upgrade Ubuntu Studio amd64 [Focal Final] has been updated (20200421)
-queuebot:#ubuntu-release- Builds: Upgrade Ubuntu amd64 [Focal Final] has been updated (20200421)
-queuebot:#ubuntu-release- Builds: Upgrade UbuntuKylin amd64 [Focal Final] has been updated (20200421)
-queuebot:#ubuntu-release- Builds: Upgrade Xubuntu amd64 [Focal Final] has been updated (20200421)
-queuebot:#ubuntu-release- Builds: Upgrade Lubuntu amd64 [Focal Final] has been updated (20200421)
<powersj> xnox, sil2100, rharper: sil2100's curtin branch has landed. Any others?
<xnox> powersj:  don't care aobut curtin branches. I'm building from commit ids.
<xnox> powersj:  new subiquity with all curtin hotfixes is in edge already
<powersj> xnox, ok thank you
<xnox> powersj:  but good to know that we can revert back to using curtin master when we open gutsy
<xnox> thank you
<xnox> apw:  it's amazing and works correctly, for real..
<vorlon> xnox, Laney: <squint> isn't this what the debconf passthrough frontend is supposed to be for?  did we regress something?
<kiko> howdy :-)
 * vorlon waves
<xnox> vorlon:  we try to use passthrough, we are not sure if passthrough was ever used on the host with host's debconf locked. when passthrough is used for in-target, in-targets' debconf is not locked by hosts ubiquity
<kiko> bdmurray!
<xnox> vorlon:  we have opened a task to make that work / doublecheck later, as we failed to make it work (we can talk to debconf, yet can't read/write to the ubiquity locked config.dat
<vorlon> xnox: so "host" here means "live environment" rather than target?
<vorlon> (that was unclear to me)
<xnox> vorlon:  yes
<vorlon> ok
<vorlon> for that, it probably shouldn't use passthrough but should instead inherit the environment
<vorlon> why doesn't it inherit the environment
<xnox> vorlon:  with the current l-r-m fix, we skip latelink in the live envrionment, but do attempt it in-target and it works correctly in-target (whilst being passthroughted progress to ubiquity, as i can see status messages configuring linux-moudle.s.....)
<vorlon> right
<vorlon> why do we install lrm in the host environment at all?
<vorlon> ... because ubuntu-drivers shouldn't encode special knowledge about which drivers are loadable in the live env or not
<xnox> vorlon:  so ubuntu-drivers calls apt-get install => but it calls it without setting close_fds=False & apt-get itself closes fds, thus it needs like extra -o APT::Keep-Fds::=3 or somesuch.
<xnox> vorlon:  the why do we install lrm in the host envrionment is a good question.
<xnox> vorlon:  i think we do it, to enable any hard-drives which ubuntu-drivers might create
<xnox> vorlon:  and it only gives us a package list of things to install in-target, if we do execute install
<vorlon> or network devices
<vorlon> right
<vorlon> xnox: apt-get closes fds> ugh
<xnox> vorlon:  plus if it doesn't work in live-system, it might fail in-target too, and then we just don't attempt to install them in-target and succeed to install
<vorlon> xnox: yes but if there was no other reason to install it in the live env, we don't need to test it first to decide if it will fail in target
<xnox> vorlon:  so before our fixes the experience was "apport popup with a crash, system installed correctly, without any nvidia packages in-target / nothing broken in-target" which is very resilient way of installing
<xnox> i wouldn't want to leave in-target with broken / unconfigured packages
<Laney> apw: around? we're keen to upload lrm-oem
<vorlon> or lurr-moÃ«m, as I am proposing to rename the source package
<Laney> apw: actually we think maybe it's not needed, as this shouldn't be getting installed in the live session
<apw> Laney, let me know if I need to do it
<Laney> nod
<Laney> xnox is doing some testing
<Laney> We've just kicked off hopefully final rebuilds of everything, should start popping out in an hour or so, everybody please test when they do
<Eickmeyer> Laney: Are these respins for all flavors that are coming?
<mwhudson> good morning
<mwhudson> xnox, rharper: does subiquity in edge have all the fixes?
<sil2100> Eickmeyer: yes
<Eickmeyer> sil2100: ack
<xnox> mwhudson: they have all the fixes in stable
<mwhudson> ah yes i see edge and stable/ubuntu-20.04 are the same
<sil2100> Eickmeyer: as per the status thread, the images we build now should be our first (and hopefully last) release candidate images
<sil2100> So it's the world spinning right now
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Focal Final] has been updated (20200422)
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Focal Final] has been updated (20200422)
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Focal Final] has been updated (20200422)
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Focal Final] has been updated (20200422)
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Focal Final] has been updated (20200422)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Focal Final] has been updated (20200422)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Focal Final] has been updated (20200422)
<Eickmeyer> sil2100: Thanks. Been watching this channel too.
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Focal Final] has been updated (20200422)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Focal Final] has been updated (20200422)
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Focal Final] has been updated (20200422)
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Focal Final] has been updated (20200422)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Focal Final] has been updated (20200422)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi [Focal Final] has been updated (20200422)
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi [Focal Final] has been updated (20200422)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Focal Final] has been updated (20200422)
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (bionic-proposed) [1:18.04.11.12]
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Focal Final] has been updated (20200422)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity arm64 [Focal Final] has been updated (20200422)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity ppc64el [Focal Final] has been updated (20200422)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Focal Final] has been updated (20200422)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Focal Final] has been updated (20200422)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Focal Final] has been updated (20200422)
<rharper> mwhudson: xnox: so jfh and I have been looking at the same multipath dev mapper links end up as block devices and what we have is not enough;  we still see some failures when we lose the race and /dev/mapper/mpatha is a blockdev not a symlink to dm-X  ;
<mwhudson> sil2100, Laney, bdmurray, vorlon: ^ this is a problem for server images :(
<sil2100> mwhudson: ;/
<sil2100> mwhudson: so if the fix will be only in curtin/subiquity, that might be still 'ok', since we can always respin only the subiquity images
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Focal Final] has been updated (20200422)
<mwhudson> sil2100: yeah i think at this point that's likely, do you agree rharper?
<mwhudson> the real fix is probably in src:lvm2 or src:multipath-toools but well
<rharper> mwhudson:  it's just not yet clear why we're losing the race here;  so unclear where to put a fix;
<xnox> mwhudson: rharper: can we do something to purge them and recreate them as symlinks?
<rharper> xnox: yes, but I don't know if it's stable
<rharper> so, curtin could remove then and run udevadm test --action=add /sys/class/block/dm-X
<rharper> and we get them ... but  what if some other uevent or something happens and tthose links get regenerated (and then we lose the race again)
<rharper> this could happen between actions in curtin so we create a partition correctly, but other curtin actions which rely on the mpath being links fails due to the file being a block device .   long term, curtin can learn to handle both mpath as block and symlink; but it's not a short amount of work to fix up the plumbing
<mwhudson> i guess absent understanding what's going on, the hack is still worth it?
<rharper> probably
<rharper> let's see what that looks like, gimme a few minutes
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Focal Final] has been updated (20200422)
<mwhudson> sil2100: what's the latest you would accept doing a rebuild (server only)?
<mwhudson> sil2100: i realize "not at all" is the better answer
<sil2100> mwhudson: hm, so I'd say the realistic deadline would be UTC morning, since paride can start testing only tomorrow anyway
<sil2100> And I *guess* it should be enough time for everyone interested to still give the images a spin
<mwhudson> sil2100: ok
<bdmurray> However, if it was before my / vorlon's EOD that would be better
<bdmurray> that way the images are ready first thing
<sil2100> +1 on that
<rafaeldtinoco> would someone mind to force a bad test for all versions of ipset package in Bionic ? Explanation is at lp1873447 and it will unblock Bionic kmod fix migration (lots of insmod error msgs).
<rafaeldtinoco> comment #4 explains why force a bad test instead of SRU
<tumbleweed> OK
-queuebot:#ubuntu-release- Unapproved: scribus-doc (focal-proposed/multiverse) [1.4.8+dfsg-1 => 1.5.5+dfsg-2~ubuntu20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted scribus-doc [source] (focal-proposed) [1.5.5+dfsg-2~ubuntu20.04.1]
<tumbleweed> Ah, no those belong in a SRU team repo, that I can't help you with, never mind.
-queuebot:#ubuntu-release- Unapproved: accepted pyhamcrest [sync] (focal-proposed) [1.9.0-3]
-queuebot:#ubuntu-release- Unapproved: accepted twisted [sync] (focal-proposed) [18.9.0-11]
-queuebot:#ubuntu-release- Unapproved: python-tornado (focal-proposed/universe) [6.0.3+really5.1.1-2build2 => 6.0.3+really5.1.1-3] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: python-urllib3 (focal-proposed/main) [1.25.8-1 => 1.25.8-2] (core, i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-tornado [sync] (focal-proposed) [6.0.3+really5.1.1-3]
-queuebot:#ubuntu-release- Unapproved: accepted python-urllib3 [sync] (focal-proposed) [1.25.8-2]
-queuebot:#ubuntu-release- Unapproved: xz-utils (focal-proposed/main) [5.2.4-1 => 5.2.4-1ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: weechat (focal-proposed/universe) [2.6-2ubuntu2 => 2.8-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted weechat [sync] (focal-proposed) [2.8-1]
<sil2100> vorlon, bdmurray: remember that we might need to respin pi if twisted lands as well
 * sil2100 goes 
-queuebot:#ubuntu-release- Unapproved: construct (focal-proposed/universe) [2.8.16-0.3ubuntu1 => 2.8.16-0.4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted construct [sync] (focal-proposed) [2.8.16-0.4]
<jbicha> python-twisted has too many reverse dependencies in focal still
<jbicha> reverse-depends -b
-queuebot:#ubuntu-release- Unapproved: kmod (bionic-proposed/main) [24-1ubuntu3.3 => 24-1ubuntu3.4] (core)
-queuebot:#ubuntu-release- Unapproved: linux-restricted-modules (focal-proposed/restricted) [5.4.0-26.30+1 => 5.4.0-26.30+2] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: accepted linux-restricted-modules [source] (focal-proposed) [5.4.0-26.30+2]
<xnox> Laney:  i think it's in proposed now
<xnox> i see it with rmadison, but not with apt update
<Laney> xnox: rmadison sees it, confirm on archive.u.c dists first probably
<Laney> bit of a latency there
<Laney> s/a //
<mwhudson> published new subiquity, so server could/should be respun whenever
<mwhudson> i guess lrm is on server too
<vorlon> why is lrm on server?
<mwhudson> is it?
<mwhudson> i don't know
<vorlon> no
<mwhudson> i was guessing
<mwhudson> oh ok good :)
<vorlon> it only builds nvidia modules
<mwhudson> ah
<xnox> vorlon:  i'm asking to respin all subiquity images, or at least just s390x
<mwhudson> all please
<bdmurray> Is there a change we can look at?
<xnox> we fixed quad-multipath race
<xnox> bdmurray:  yes, one second
<vorlon> xnox: well if I push this python stuff through, we're going to be respinning the d-i images also
<mwhudson> this is the curtin change https://code.launchpad.net/~raharper/curtin/+git/curtin/+merge/382798
<xnox> bdmurray:  vorlon: https://git.launchpad.net/~ubuntu-core-dev/curtin/commit/?h=ubuntu-20.04&id=a6cd01f01fccb61e89f37a2cdd11e9c103fdff65
<vorlon> so definite respins needed at this point: ubuntu-budgie, kubuntu, ubuntu-mate (for lrm, which wasn't seeded there at all but really should be), ubuntu desktop (also lrm), ubuntu server (subiquity)
<vorlon> and there is some python2 stuff in main that it would benefit security support if we got it landed but that impacts all the flavors
<xnox> vorlon: bdmurray: mapper was creating block devices instead of symlinks in /dev/mapper/* we are forcing to make them symlinks as they should be.
<bdmurray> Did I hear that there were concerns about testing on hardware
<xnox> bdmurray:  i have completed the test on the same machine that frank file the bug report on
<bdmurray> ?
<bdmurray> Okay, and what about the snapcraft.yaml change?
<xnox> bdmurray:  before going end of day, he left it at subiquity, i refreshed to subiquity from edge, and then completed the install, confirming that bad block devices were there, and then install succeeded correctly
<xnox> bdmurray:  https://github.com/CanonicalLtd/subiquity/pull/732/files
<gitbot> CanonicalLtd issue (Pull request) 732 in subiquity "one more curtin hotfix" [Closed]
<mwhudson> bdmurray: the snapcraft yaml change is to get the curtin fix
<xnox> bdmurray:  and mwhudson merged it without release team ack
<mwhudson> noone told me i should be asking for that...
<xnox> mwhudson:  we made that up during your night time =)
<bdmurray> its new didn't you get the memo?
<mwhudson> nope
<xnox> mwhudson:  normally respins & things that are respin triggers are cleared with release team prior to upload.... and apw felt that should apply to snaps too, especially if it's a classic one and is the installer
<mwhudson> xnox: so i guess i would argue that publication to the snap channel is more what should be gated but ok
<xnox> bdmurray:  we don't autorefresh
<xnox> bdmurray:  we only offer, and don't do it by default
<vorlon> so I think we're looking to respin everything in order to get the unbuildable python packages in main sorted
<xnox> mwhudson:  yeah, i think it will be part of release retrospective on how to handle subiquity respins
<xnox> mwhudson:  especially if more than one flavour starts using it. cause i bet desktop will consume subiquity as a snap
<bdmurray> I'm good with the subiquity / curtin changes
<mwhudson> xnox: yes, fair
<bdmurray> xnox: autorefresh was about ubuntu-dev-tools
<xnox> ah
<xnox> ok, sorry
<mwhudson> bdmurray: thanks
<xnox> vorlon:  bdmurray: python3-txtftp fixed, not removed?
<mwhudson> i think my goal for every release going forwards is to not be landing so much subiquity stuff so late....
<xnox> bdmurray:  yes
<xnox> bdmurray:  because linux-firmware gives people wifi working
-queuebot:#ubuntu-release- Unapproved: incremental (focal-proposed/main) [16.10.1-3.1 => 16.10.1-3.2] (edubuntu, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted incremental [sync] (focal-proposed) [16.10.1-3.2]
<wgrant> If we're respinning everything for python-urllib3, what are the chances of unblocking the zeromq3 in -proposed (test-only change) to fix the last remaining riscv64 non-leaf hole in the release pocket besides strace? Would be slightly annoying to have it only in -updates since security builds of a few things are likely to fail without it, but obviously not the end of the world.
<vorlon> Laney: ^^ I'm +1 on this
#ubuntu-release 2020-04-23
<vorlon> wgrant: zeromq3 unblocked
<wgrant> Oh there's ceph as well, but that'll get a security update soon enough and the only rbuilddeps on riscv64 are boring (qemu/libvirt have it disabled), so much less interesting and slightly less obviously completely benign
<wgrant> vorlon: Thanks!
 * vorlon nods
<mwhudson> ok well i'm going to go and be a parent for a bit, telegram me if you need anything
<xnox> vorlon:  your picture is frozen in hangout
<xnox> vorlon:  yet me and everyone else is animated
<wgrant> I mean, you're never not animated.
<vorlon> xnox: brian's camera is off, you don't have a baseline on this side of the ocean :)
<vorlon> anyway, reconnected
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Focal Final] has been updated (20200422.1)
<Laney> do not get excited about that build!!!!!!!!!
<Laney> it's just for us to test some stuff, a proper respin will be happening shortly along with all of the other flavours
<vorlon> (marked it disabled on the iso tracker)
<Laney> ð
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Focal Final] has been disabled
<wgrant> What's the best way to force the remaining riscv64 builds stuck in -proposed because some of their binaries are uninstallable due to e.g. snapd and strace? kdeplasma-addons, libguestfs, nfs-ganesha, plasma-discover are the problematic sources.
<tumbleweed> you mean force them to migrate?
<wgrant> Yeah
<vorlon> we could force the binaries in with hints
<xnox> wgrant:  force hint & unblock hint in britney
<vorlon> and leave them uninstallable in the release pocket
<wgrant> That would seem to make sense, because most of the interesting binaries install just fine.
<tumbleweed> isn't there a flag to tell britney to ignore the arch entirely?
<tumbleweed> broken_archs or somethnig like that
<vorlon> maybe but it doesn't work
<xnox> tumbleweed:  we have all of them set now, and they still don't migrate
<tumbleweed> ah I see yeah
<vorlon> so a combination of force + force-hint
<vorlon> is what actually does it
<wgrant> Is there documentation on this somewhere, or should I go digging?
<vorlon> eh
<vorlon> I don't know, I'm going from 16-year-old memory
<tumbleweed> dare I ask about g-animals?
<vorlon> you can ask, but I still haven't heard confirmation of gelephant
<bdmurray> wgrant: python-tornado failed to build on riscv64
<wgrant> bah
<bdmurray> looks like a timeout
<kryten> vorlon: On behalf of the Lubuntu Artwork team, could you please deploy the updated CD Image assets from <https://git.launchpad.net/~lubuntu-art/+git/cdimage-css> to <http://cdimage.ubuntu.com/include/lubuntu/> ?
<wgrant> Yeah, will retry, and in parallel manually confirm that it's close to the timeout
<wgrant> vorlon: Thanks, those all migrated.
<wgrant> bdmurray: The fact that it failed again in exactly the same way reminded me that I'd rebooted the VM host a few days ago, and I found that its CPU came back at a lower clock speed. I've fixed that, but will also upload some higher timeouts to a silo just in case.
<wgrant> These really aren't the most reliable tests, are they, just got two weird timeouts on amd64.
<wgrant>  Test that write() Futures are never orphaned. ... ok
<wgrant> OK (skipped=46)
<wgrant> bdmurray: Sorry about that, should be good now.
<wgrant> Server power management defaults ftl
<xnox> tumbleweed: gutsy ð
<bdmurray> wgrant: thanks
<housecat> Howdy. Couple of quick questions from over in #ubuntu: 1) I'm guessing the plan this cycle is to enable bionic -> focal do-release-upgrade once 20.04.1 is out as normal? 2) Assuming the answer to (1) is yes, is the plan also to leave do-release-upgrade -d pointing at focal until that has happened?
<housecat> istr that's how it worked for bionic, but somebody is loudly telling me i'm wrong so figured i should check :)
<vorlon> kryten: done
<bdmurray> housecat: you are correct
<bdmurray> housecat: and somebody else is wrong
<housecat> thanks. mind if i quote that?
<bdmurray> well, maybe I should give you a better quote
<bdmurray> housecat: you are absolutely correct and release upgrades from 18.04 LTS to 20.04 LTS will not be enabled until 20.04.1 and you are also correct that do-release-upgrade -d on Ubuntu 18.04 LTS will point to Ubuntu 20.04 LTS.
<tumbleweed> xnox: :P
-queuebot:#ubuntu-release- Unapproved: requests (focal-proposed/main) [2.22.0-2build1 => 2.22.0-2ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: accepted requests [source] (focal-proposed) [2.22.0-2ubuntu1]
<kryten> vorlon: Thanks!
-queuebot:#ubuntu-release- Unapproved: sphinx (focal-proposed/main) [1.8.5-7ubuntu2 => 1.8.5-7ubuntu3] (edubuntu, i386-whitelist, ubuntu-desktop, ubuntu-server)
<mwhudson> xnox, tumbleweed: gusty gibbon
-queuebot:#ubuntu-release- Unapproved: accepted sphinx [source] (focal-proposed) [1.8.5-7ubuntu3]
-queuebot:#ubuntu-release- Unapproved: python-tx-tftp (focal-proposed/main) [0.1~bzr47-0ubuntu4 => 0.1~bzr47-0ubuntu5] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted python-tx-tftp [source] (focal-proposed) [0.1~bzr47-0ubuntu5]
<vorlon> respins still pending; the packages that I tried to get in quickly at the end have not gone so quick. :/
<wgrant> vorlon: Anything others can help with? Looks like we're mostly just waiting on flaky autopkgtest retries?
<vorlon> wgrant: mostly just waiting on the time it takes to iterate britney; I wasn't going to block on the retries in this context
<wgrant> Ah
<vorlon> but requests has gone through now, so most respins are unblocked
<sil2100> vorlon: morning! I see twisted migrated to release but there are no server image respins - should I do that now?
<sil2100> mwhudson: hey, how's the subiquity situation?
<vorlon> sil2100: I just hit the button now
<vorlon> sil2100: sorry - the python stuff took much longer to shake out than planned, so the respins are only happening now. and I still need to hit sphinx with a hammer before we can respin ubuntustudio
<sil2100> vorlon: oh shit, sphinx was in the whole reverse-chain too? Did you poke Eickmeyer with a heads-up?
<vorlon> and piuparts autopkgtest failed when triggered by sphinx because today is the release date and there is no updated distro-info-data with a new devel series name ;P
<sil2100> ;p
<vorlon> sil2100: Wimpress said he was taking care of notifying flavors that we would respin the world, I didn't specifically ping anyone
-queuebot:#ubuntu-release- Unapproved: python-tx-tftp (focal-proposed/main) [0.1~bzr47-0ubuntu5 => 0.1~bzr47-0ubuntu6] (ubuntu-server)
<jibel> vorlon, I did on the telegram channel
<vorlon> ... telegram channel
<jibel> yeah, there is a channel bridge with #ubuntu-quality where the flavors are coordinating the testing.
<vorlon> mmk
<philroche> vorlon: sil2100: Are all packages, those that you are aware of anyway, made it in? If so I can start prepping cloud images. I won't release until I get a +1 of course
-queuebot:#ubuntu-release- Unapproved: python-wsgi-intercept (focal-proposed/universe) [1.9.2-0ubuntu1 => 1.9.2-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-wsgi-intercept [source] (focal-proposed) [1.9.2-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: rejected vala [source] (focal-proposed) [0.48.4-0ubuntu1]
<sil2100> vorlon: did you hear from mwhudson about any further fixes to the multipath pieces?
<sil2100> Oh, I see there was a hotfix committed
<vorlon> yeah
-queuebot:#ubuntu-release- Unapproved: accepted python-tx-tftp [source] (focal-proposed) [0.1~bzr47-0ubuntu6]
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Focal Final] has been updated (20200423)
<sil2100> philroche: I think yes
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Focal Final] has been updated (20200423)
<philroche> sil2100: ack
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Focal Final] has been updated (20200423)
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Focal Final] has been updated (20200423)
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Focal Final] has been updated (20200423)
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Focal Final] has been updated (20200423)
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Focal Final] has been updated (20200423)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Focal Final] has been updated (20200423)
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Focal Final] has been updated (20200423)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Focal Final] has been updated (20200423)
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Focal Final] has been updated (20200423)
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Focal Final] has been updated (20200423)
-queuebot:#ubuntu-release- Unapproved: python-wsgi-intercept (focal-proposed/universe) [1.9.2-0ubuntu2 => 1.9.2-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi [Focal Final] has been updated (20200423)
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi [Focal Final] has been updated (20200423)
-queuebot:#ubuntu-release- Unapproved: accepted python-wsgi-intercept [source] (focal-proposed) [1.9.2-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: vala (focal-proposed/universe) [0.48.3-1 => 0.48.5-0ubuntu1] (i386-whitelist, ubuntu-desktop)
<mwhudson> sil2100: yes, subiquity is now 100% bug free!!!
<sil2100> mwhudson: SWEET!
<sil2100> It wasn't that hard, see?
<sil2100> We now need to do the same for everything in Ubuntu
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Focal Final] has been updated (20200423)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Focal Final] has been updated (20200423)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Focal Final] has been updated (20200423)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Focal Final] has been updated (20200423)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Focal Final] has been updated (20200423)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity arm64 [Focal Final] has been updated (20200423)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity ppc64el [Focal Final] has been updated (20200423)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Focal Final] (20200423) has been added
<Laney> guess I came on at the right time eh
<sumagna> why?
<didrocks> sumagna: images just published for testing ^
<sumagna> oh ok
<tsimonq2> He was waiting for the testing giraffes to start smoke testing the fresh ISOs.
<vorlon> sil2100: do you recall if cron.source requires any options in order to DTRT?
<Laney> vorlon: no
<paride> \o/
<Laney> vorlon: take it you're taking that item then?
<vorlon> Laney: yah it's running
<Laney> great
<vorlon> (before I asked, because we could always cancel/ throw away)
<Laney> I'll mark it as in progress on the doc
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Focal Final] has been disabled
<vorlon> ^^ that's because it needs sphinx.  documented it in the discourse, and hopefully sphinx will clear in the next p-m run
<vorlon> but it's 0130 here so I think I'm going to have to leave the rest to Europe
<vorlon> https://people.canonical.com/~ubuntu-archive/testing-ports/focal_probs.html looks... sorta wrong
<vorlon> apparently does not understand versioned provides, hmph
<vorlon> someone might want to poke at https://people.canonical.com/~ubuntu-archive/priority-mismatches a bit; I've done the promotions, but I haven't checked whether the demotions are sane/safe
<vorlon> and someone please finish cleaning up https://people.canonical.com/~ubuntu-archive/nbs.html once sphinx migrates
<vorlon> sphinx has migrated, so someone can respin ubuntustudio in a few
<sil2100> vorlon: will do, thanks! ;)
<sil2100> Yeah, saw it migrating, will wait a few more minutes, manually anonftpsync and build
-queuebot:#ubuntu-release- Unapproved: libreoffice (focal-proposed/main) [1:6.4.2-0ubuntu3 => 1:6.4.3-0ubuntu0.20.04.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Focal Final] has been updated (20200422)
<philroche> sil2100: python3-requests:amd64  2.22.0-2ubuntu1 would trigger a new cloud image build. Current 20200423 cloud image has 2.22.0-2build1. From changelog I see the  2.22.0-2ubuntu1 change was to drop python2 support - cherry picked from Debian.  Is that change worthy of a full rebuild?
<sil2100> philroche: it was just dropping python2 support - so as long as we don't need to have a sync between 'release pocket' and 'cloud image contents', I don't think it needs that
<philroche> sil2100: ack. Thanks
<LocutusOfBorg> today is the day piuparts autopkgtests start failing... distro_info.DistroDataOutdated: Distribution data outdated. Please check for an update for distro-info-data. See /usr/share/doc/distro-info-data/README.Debian for details.
<LocutusOfBorg> vorlon, ^^ hint?
<tsimonq2> LocutusOfBorg: See above, he acked the failure/probably left to Europe people.
<Laney> I've just applied the block-all source and turned off the auto-accept bot
<Laney> so no more migrations, no more accepts
<sil2100> I re-kicked the source iso builds
* Laney changed the topic of #ubuntu-release to: Released: Bionic 18.04.4, Eoan 19.10 | Archive: Frozen for release | Focal release status: https://discourse.ubuntu.com/t/focal-fossa-final-release-status-tracking/15366 | Highlight ubuntu-archive for archive admin help | Focal Release Coordination | We accept payment in cash, cheque or gin | melius malum quod cognoscis
<LocutusOfBorg> lol ack
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Focal Final] has been updated (20200423)
<Eickmeyer> sil2100, vorlon: I'm awake. Does somebody want to fill me in on what's happening with Studio?
<sil2100> Eickmeyer: yes! It is rebuilt now o/
<Eickmeyer> Perfect. I'll smoke test.
<Eickmeyer> Just to make sure it's known, we ARE participating as LTS this time around. :)
<sil2100> Eickmeyer: so we had to sadly respin everything because of some python2 removals - basically no real changes (just removing python2 versions from source packages), but still best to sanity check
<Eickmeyer> sil2100: ack.
<yfsdffasdff> w-h-e-n?
<tsimonq2> yfsdffasdff: You just delayed it by an hour.
<yfsdffasdff> oh nooooo
<yfsdffasdff> shame on me
<sumagna> what?!?
<cjwatson> So can y'all not make us have to moderate this channel?
<cjwatson> This isn't #ubuntu-release-party or whatever, it's a working channel
<jfh> hi, I just noticed that there is a new daily-live image in pending with time-stamp April 23rd, but the s390x image is unusually small - just 366051328 instead of 685703168 (April 20th) - I wondered if something went wrong ?! (will give it a try anyway ...) -- http://cdimage.ubuntu.com/ubuntu-server/daily-live/pending/
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Focal Final] has been marked as ready
<jfh> like assumed it's broken and doesn't boot up ...
<Laney> jfh: paride noticed that
<Laney> and xnox is about to check!
<Eickmeyer> People are griping in my main channal about no SSL for the download. >.<
<jfh> Laney: ok - didn't saw that ...
<Laney> yeah sorry, it was a discussion on a hangout
<paride> jfh, but thanks for spotting the difference in size
<paride> that clearly indicates that something went wrong. Whan I did notice is that the image doesn't boot
<jfh> paride: yeah - the download was "way to fast" ...
<Laney> We're respinning server-live for s390x only
<Laney> there was a failure to download the squashfs ...
<jfh> ok
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Focal Final] has been updated (20200423.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Focal Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Focal Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Focal Final] has been marked as ready
<xnox> Laney:  vorlon: should mongodb be ripped out of release pocket, into updates? or we will do that later elsehow?
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Focal Final] has been marked as ready
-queuebot:#ubuntu-release- Unapproved: pycurl (focal-proposed/main) [7.43.0.2-1ubuntu5 => 7.43.0.2-1ubuntu6] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: linux-signed-gke-5.0 [amd64] (bionic-proposed/universe) [5.0.0-1035.36] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.0 [amd64] (bionic-proposed) [5.0.0-1035.36]
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Focal Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Focal Final] has been marked as ready
<philroche> sil2100: Cloud images 20200423 are ready to go. Awaiting +1
<sil2100> philroche: awesome, thanks!
<sil2100> We'll give you a sign ;)
-queuebot:#ubuntu-release- Unapproved: weechat-scripts (focal-proposed/universe) [20191009-1 => 20200421-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Focal Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Focal Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Focal Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity arm64 [Focal Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity ppc64el [Focal Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Focal Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Focal Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Focal Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Focal Final] has been marked as ready
-queuebot:#ubuntu-release- New source: sugar (focal-proposed/primary) [0.117-2~build1]
<jbicha> If y'all have time, please review the Sugar packages in the focal NEW queue. They were only removed this cycle because of py2 but that's been fixed
<jbicha> also gnome-shell-extension-dashtodock (just GNOME 3.36, not py2)
<jbicha> reverse-depends -r focal -b python-sphinx ð¢
<jbicha> some of those python-sphinx packages are Ubuntu Server stuff
<jbicha> https://paste.debian.net/1142507/
<doko> apw, sforshee: can the 5.6.0-1007-oem packages be demoted? https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Focal Final] has been marked as ready
<apw> doko, are they not NBS in fact?
<doko> apw: nothing in https://people.canonical.com/~ubuntu-archive/nbs.html
<xnox> doko:  no
<xnox> doko:  1007 is in release pocket, 1008 is in proposed
<xnox> doko:  both need to be in main
<xnox> doko:  -proposed is too pre-emptive about this.
<xnox> both are buildable, and will be published
<xnox> 1008 will go into -updates when ready
<apw> xnox, ahhh it is just lying, i love reports hwihc do that
<wings> hey, for everyone working on getting 20.04 out the door
<wings> thank you
<xnox> doko:  apw: linux-oem is documented in https://discourse.ubuntu.com/t/focal-fossa-20-04-lts-final-release-status-tracking/15366
<xnox> btw, and has been there all week? or something.
<xnox> doko:  apw: but yeah, something is broken in the -proposed report.
-queuebot:#ubuntu-release- Unapproved: netplan.io (focal-proposed/main) [0.99-0ubuntu1 => 0.99-0ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted netplan.io [source] (focal-proposed) [0.99-0ubuntu2]
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Focal Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Focal Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Focal Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Focal Final] has been marked as ready
<seb128> shrug, I tested the wrong iso ... any reason http://cdimage.ubuntu.com/daily-live/current still points to yesterday's image?
<sil2100> philroche: ok, we're basically releasing now, so please proceed with the cloud images!
<philroche> sil2100: ack
<xnox> seb128:  because pending -> current promotion for devel series is broken on release days =)
<seb128> xnox, :(
<seb128> xnox, it case it was not clear before, that would be nice to fix if that's a thing known to be broken... what's the right place to report it? if the promotion stops working at some point maybe then just symlink current to proposed during the freeze?
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi [Focal Final] has been updated (20200423.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi [Focal Final] has been updated (20200423.1)
<xnox> seb128:  for milestone testing one must never go to cdimage
<xnox> seb128:  one must always use the qa iso tracker, and use download urls listed there
<xnox> seb128:  and one can submit pending / successful test results
<xnox> seb128:  see http://iso.qa.ubuntu.com/qatracker/milestones/412/builds
<xnox> seb128:  because publication (publish-image-set from ubuntu-archive-tools) is driven by build-ids listed and marked as ready in the qa tracker with manual tests passing.
<xnox> seb128:  this is the only way we can publish mixed-build-id images on per-product basis
<seb128> xnox, one must vs real world right?
<seb128> but feel free to ignore the feedback, izfine
<seb128> keep that 'current' pointing to the wrong thing if you think it's best this way
<xnox> seb128:  all of our flavour leads, and everyone from discourse, is told to use the qa tracker
<xnox> seb128:  and they do, and submit release critical bugs via qa tracker
<seb128> that's not what I'm telling you
<seb128> shrug
<xnox> seb128:  please participate in milestone on discourse
<seb128> I've been participating and using the QA tracker thanks
<xnox> seb128:  i think you are the only person who used current image this week.....
<seb128> I found something wrong which is confusing some people
<xnox> who was confused?
<xnox> bug #?
<seb128> right, the only person in the world
<bdmurray> hold on y'all
<bdmurray> seb128: How did you get to the current image?
<seb128> bdmurray, http://cdimage.ubuntu.com/daily-live/ , the current entry was outdated when I posted my message
<seb128> it has been fixed now
<seb128> thanks to whoever did it
<xnox> no it hasn't been fixed, it's done automatically and driven by jenkins
<xnox> current image is never the latest spin we are testing
<seb128> well, jenkins maybe fixed it
<xnox> they are always published in pending
<seb128> but it has been fixed
<seb128> it's correct now
<xnox> if you want the latest build we popped out you should look at pending only
<seb128> thx, I know all that
<xnox> seb128:  current != pending if jenkins didn't finish, or failed.
<seb128> right, I got failed job emails
<seb128> which is a flaky job
<seb128> but at this point I don't think it makes sense to keep it outdated
<seb128> we regularly force copy to current
<xnox> !!!!!!
<seb128> anyway, thanks for turning simple remarks into endless arguments, always an useful use of our time to all
<sil2100> philroche: are you good from the cloud POV?
-queuebot:#ubuntu-release- Unapproved: spice (focal-updates/main) [0.14.2-4ubuntu3 => 0.14.2-4ubuntu3] (ubuntu-server) (sync)
<gaughen> Happy Release Day all!
<xnox> =)
<Laney> ð
<Laney> hey gaughen
<sil2100> \o/
<philroche> sil2100: We are good. Discourse updated too https://discourse.ubuntu.com/t/focal-fossa-20-04-lts-final-release-status-tracking/15366
<philroche> gaughen: \o
<sil2100> ð¦
<waveform> o/ gaughen
<mclemenceau> o/ gaughen
<vorlon> xnox: mongodb out of release pocket> I don't see a reason for this.  It has currently unsatisfiable build-deps but it's in universe and there are no python2-specific binary packages built so that looks fixable in update as needed
<xnox> ack
<xnox> vorlon:  To join the video meeting, click this link: https://meet.google.com/ndx-sffh-tab
<xnox> Otherwise, to join by phone, dial +44 20 3956 0723 and enter this PIN: 545 259 244#
<xnox> To view more phone numbers, click this link: https://tel.meet/ndx-sffh-tab?hs=5
<bryce> gaughen, :-)
-queuebot:#ubuntu-release- Unapproved: accepted spice [sync] (focal-updates) [0.14.2-4ubuntu3]
<vorlon> List of old libraries in testing (0):
<vorlon> yay
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi [Focal Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi [Focal Final] has been marked as ready
<sil2100> \o/
<slyon> yay!
<waveform> woohoo!
<dannf> \o/
* sil2100 changed the topic of #ubuntu-release to: Released: Focal 20.04, Bionic 18.04.4 | Archive: Frozen for release | Highlight ubuntu-archive for archive admin help | Focal Release Coordination | We accept payment in cash, cheque or gin | melius malum quod cognoscis
<cwayne> Whee
* sil2100 changed the topic of #ubuntu-release to: Released: Focal 20.04, Bionic 18.04.4 | Archive: Closed | Highlight ubuntu-archive for archive admin help | Focal Release Coordination | We accept payment in cash, cheque or gin | melius malum quod cognoscis
<ogra> 'grats !
<sil2100> We're ouut!
<philroche> \o Nice work all
<rbalint> o/
<rbalint> thanks everyone!
<Odd_Bloke> Great job, folks!
<tyhicks> congrats! :)
<sarnold> woo! congratulations :D
<willcooke> Congrats all! \o/
<Eickmeyer> YAY!
<Eickmeyer> Release team! Great job! BTW, heads up: Ubuntu Studio is switching away from Xfce to KDE Plasma next release.
<mdeslaur> congrats everyone! :)
<mapreri> \o/
<gaughen> fantastic work you all! <3
-queuebot:#ubuntu-release- Unapproved: update-manager (focal-proposed/main) [1:20.04.9 => 1:20.04.10] (core)
<sil2100> gaughen: thank you!
<sil2100> Eickmeyer: thanks o/
<sil2100> willcooke: oh oh Will! Thanks \o/
<ogra> there seems to be a bad redirect on the ubuntu.com website when using the download button
<ogra> The requested URL /repos/Ubuntu/releases/20.04/ubuntu-20.04-live-server-amd64.iso was not found on this server.
<ogra> so a 404
<ogra> seems it redirects to https://reflector.westga.edu/repos/Ubuntu/releases/20.04/ubuntu-20.04-live-server-amd64.iso
<ogra> (this is when using either download button on https://ubuntu.com/#download )
<powersj> that mirror does seem to have updated maybe? https://reflector.westga.edu/repos/Ubuntu/releases/20.04/
<ogra> ah, yeah, the isos are beta
<vorlon> rafaeldtinoco: ah so you now have the mp targeted to the right place but it has the wrong base :)
<fcanela_> As user, thank you all for your great work. I really appreciate it.
<rafaeldtinoco> vorlon: =(
<rafaeldtinoco> let me redo it
<rafaeldtinoco> its about time for me to make this right
<rafaeldtinoco> =)
<rafaeldtinoco> https://bazaar.launchpad.net/~ubuntu-sru/britney/hints-ubuntu-bionic/revision/3173
<vorlon> rafaeldtinoco: I went ahead and landed it manually :)
<rafaeldtinoco> ok you already did
<rafaeldtinoco> vorlon: i thought it was just proposing to that first target and that was it
<rafaeldtinoco> i see now there are multiple targets for the srus
<rafaeldtinoco> thanks anyway, sorry for the burden
<Kamilion> just curious if xen's going to get a point release upgrade to move to python3?
<vorlon> that is not likely to be sru material
-queuebot:#ubuntu-release- Builds: 36 entries have been added, updated or disabled
<mwhudson> congrats to all :)
<pizzaiolo> congrats team!!!! \o/
<valorie> what a great release
<valorie> thank you all, release team
<valorie> if I ever meet any of you in person, you get the best gin made
<Kamilion> so i'm stuck with python2 and xen 4.11 for another two and a half years?
<Kamilion> meh. Guess i'll have some ppas to play with.
<valorie> Kamilion: there was quite a bit of discussion about 0 day updates so don't lose hope
 * valorie always enables backports
<sarnold> valorie: I dunno, xen is a big beast. I have trouble seeing someone packaging up a version that uses py3 instead of py2 for -backports
<valorie> aha
<valorie> someone might do a PPA for it and get some testing then
<Kamilion> not expecting 0-day -- just seeing 4.13 at the first or second point release *(20.04.1 / 20.04.2)
<Kamilion> as far as i can tell, all the other requirements are in place; just nobody had time to spend looking after bringing 4.13 over from debian I guess
<Kamilion> we've already shipped multiple versioned copies of xen in previous LTSs
<powersj> Kamilion, I don't see 4.13 in debian
<powersj> https://packages.debian.org/source/sid/xen
 * Kamilion scratches head -- i could have sworn i saw a bunch of mailing list traffic about it
<Kamilion> ah well, i must be misremembering or confused
 * Kamilion double checks that it was xen 4.13 that brought py3 support
<jbicha> please review the desktop-file-utils SRU for focal. It's an important issue that early adopters are complaining about
<valorie> Kamilion: if you help Debian you help Ubuntu
<Ukikie> ...In other words, if you clutter Debian with packages, you do so in Ubuntu (most of the time) too!
<valorie> Ukikie: lol
<sarnold> Ukikie: lol
<xnox> Then Debian goes through autoremovals and Ubuntu is stuck with them forever
<xnox> We were cleaning up today NBS & Uninstallable packages that we can't install nor rebuild. Thanks to all the py2 removals in Debian.
<xnox> Well done Debian. But was painful for us, given we cut the release today.
<sarnold> we'll get them back though, we'll get a head start on removing py3 packages, and that'll show em
<Ukikie> I do actually have a package I'm a little concerned about in Ubuntu, in Debian it's not as concerning as I can pop it into backports.  It's somewhat along the lines of youtube-dl, which would be great to backport too. :3
<valorie> xnox: thank you for your work
<xnox> Thanks
<vorlon> xnox: autoremovals from unstable are processed.  lazy Debian removals from testing but not unstable are the problem
<vorlon> and https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/rcbuggy-problem-packages.html could be improved
<vorlon> (it misses various classes of why a package is problematic to still be in Ubuntu when it's removed from testing)
<Kamilion> i'm just happy 'python-is-python3' works for me in almost every case so far.
<Kamilion> i know it won't work with C extensions, but that's okay
<Kamilion> leaving it up to the site admin: good++
<xnox> Kamilion: â¤ï¸
#ubuntu-release 2020-04-24
<ricotz> hello, please get libreoffice accepted - https://launchpad.net/ubuntu/focal/+queue?queue_state=1&queue_text=
-queuebot:#ubuntu-release- Unapproved: accepted pulseaudio [source] (bionic-proposed) [1:11.1-1ubuntu7.6]
<cpaelzer> sil2100: hi, do you remember when we said spice can be a zero day SRU past the release?
<cpaelzer> sil2100: I don't know what happened exactly but its state is odd (at least to me)
<cpaelzer> I got the "it got released" mail yesterday and thought things are done
<cpaelzer> and also I see
<cpaelzer>  spice | 0.14.2-4ubuntu3          | focal-updates    | source
<cpaelzer> so far so good
<cpaelzer> but just now I got a mail about it being accepted to proposed
<cpaelzer> there must be something wrong in between release/SRU of this package
<cpaelzer> could you (or another archive/sru person) take a look and tell me if any action on my side is needed?
<cpaelzer> Laney: you released the package, let me know if there was anything special about it?
<sil2100> cpaelzer: I think everything looks fine here
<cpaelzer> ok, I was just wondering about the order the mails arrived
<cpaelzer> and would have assumed that it will be removed from -proposed
<cpaelzer> when being released
<sil2100> cpaelzer: so I see the package in both -updates and -proposed right now, with the -proposed one being published earlier than -updates, as expected
<cpaelzer> really
<cpaelzer> ok then it is just mail-ordering
<sil2100> ah, no, once a series gets stable, the -proposed removal is manual
<cpaelzer> thanks for checking sil2100
<sil2100> Like we clean out the -proposed packages after accepting SRUs manually ;)
<marcustomlinson> tjaalton: could I ask for a review on the update-manager SRU for focal. It's a very small change for a rather large impact
<tjaalton> marcustomlinson: sure
<marcustomlinson> thanks!
<tjaalton> huh, sru-review it's saying I'm not authorized to accept it
<tjaalton> maybe lp login expired, but shouldn't it refresh it?
<Laney> I think we didn't give ubuntu-sru the right access yet
<Laney> step 15 on https://wiki.ubuntu.com/NewReleaseCycleProcess - who can do that?
<tjaalton> ahah
<tjaalton> apw: ^ can you help?
<tjaalton> or sil2100 maybe..
<Laney> it's "launchpad.Edit"
<Laney> nto sure if that is ~ubuntu-drivers or an actual Launchpad admin
<tjaalton> wgrant then? :)
<wgrant> Not me.
<wgrant> Probably archive owner
<wgrant> But I forget and am afk
<tjaalton> sure, no worries
<Laney> Someone in ~ubuntu-archive might as well try
<doko> Laney: why start again with the wiki page when we have the google doc?
<Laney> because linking a private document in a public channel is quite unfriendly
<doko> then make it public? sil2100?
<Laney> The wiki pages are still canonical
<Laney> sorry this is an argument I'm not really up for having
<cjwatson> Laney: ~techboard
<cjwatson> For primary archives, launchpad.Edit needs the distribution owner
<Laney> OK, I'm not always sure how to map launchpad.Edit to a team, thanks
<cjwatson> (Or in general ~admins, i.e. IS, can nearly always do stuff)
<cjwatson> lp.security (or occasionally lp.<app>.security) defines those rules
<Laney> mdeslaur: stgraber: ^- maybe one of you could help out with that step please so we can start processing SRUs for focal?
<Laney> possibly that should be split in two and moved from NewReleaseCycleProcess to ReleaseProcess
<Laney> although ideally we would clear out PREVIOUS-proposed before, I guess ...
<rbasak> Laney: FWIW, Focal Unapproved has now appeared at https://trello.com/b/XgBxtrZ9/sru (another board driving by the same script).
<rbasak> driven by
<Laney> tjaalton: (In the meantime you could proxy your accepts through someone in ~ubuntu-archive)
<Laney> rbasak: Nice one
<Laney> I think the situation will probably be a little bit confusing for the SRU team until we've cleared the syncs out, at least
<rbasak> Of course :)
<rbasak> I didn't really expect to touch anything until the release team says so
<Laney> There's a slightly elevated risk given that focal-proposed is still full of junk, but if you're careful enough I think you can do some SRU processing for higher-priority issues
<tjaalton> only 15 packages
<ricotz> please accept libreoffice https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1874285
<ubot5> Ubuntu bug 1874285 in libreoffice (Ubuntu Focal) " [SRU] libreoffice 6.4.3 for focal" [High,In progress]
<ricotz> it will also take care of an upgrade issue from bionic
<Laney> tjaalton: actually I think I can still accept things into proposed if you want to give me a sign
<tjaalton> Laney: update-manager is fine
<mdeslaur> Laney: so, step 15 from the wiki?
<mdeslaur> Laney: done.
<tjaalton> mdeslaur: thanks, works :)
<mdeslaur> cool :)
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (focal-proposed) [1:20.04.10]
<Laney> mdeslaur: thanks!
<mdeslaur> yw!
<xnox> popey:  https://discourse.ubuntu.com/t/groovy-gorilla-release-schedule/15531 is "locked" with ACLs right? I think we are ok with comments, but people may not edit it. Similar to how the Release Tracking document was.
<popey> Ya, the release category is "see" for everyone and "create / reply / see" for the release-team. Perhaps I should add "Canonical" as create/reply/see too?
<popey> which seems reasonable
<Laney> if it's possible to sync groups on Discourse with Launchpad groups I'd probably be OK with letting ~ubuntu-dev have edit rights there
<popey> I do not think it can do that, might be a question for IS
 * tumbleweed does the distro-info-data dance
<Laney> ah
<Laney> sil2100: ^^^^
<Laney> don't you two collide
<tumbleweed> if someone else is going to, I'll happily do dayjob work instead :)
<tumbleweed> but I need to get the Debian side done, at least
<Laney> It's probably OK, I just didn't want you two to duplicate each others work
<sil2100> tumbleweed: if you want then feel free!
<sil2100> I'll do debootstrap then
<sil2100> tumbleweed: will you do the SRUs also? I can then review those
<cjwatson> FWIW I committed the debootstrap change to Debian, though haven't particularly bothered to upload
<cjwatson> we have an Ubuntu delta anyway so doesn't hurt to upload that
<tumbleweed> People at work reporting upgrades to fossa aborting because of a snap store outage :(
<tumbleweed> sil2100: +1
<cjwatson> tumbleweed: yeah, store team is on it
<sil2100> tumbleweed: thank you!
<cjwatson> and I *think* all the LP bits of opening groovy are done
<sil2100> tumbleweed: give me a sign if you have stuff uploaded ;)
<xnox> sil2100:  https://code.launchpad.net/~xnox/ubuntu-cdimage/core20-beta-builds/+merge/382932
-queuebot:#ubuntu-release- Unapproved: base-files (focal-proposed/main) [11ubuntu5 => 11ubuntu6] (core, i386-whitelist)
<sil2100> xnox: thanks!
-queuebot:#ubuntu-release- Unapproved: rejected base-files [source] (focal-proposed) [11ubuntu6]
-queuebot:#ubuntu-release- Unapproved: base-files (groovy-proposed/main) [11ubuntu5 => 11ubuntu6] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: rejected base-files [source] (groovy-proposed) [11ubuntu6]
-queuebot:#ubuntu-release- Unapproved: base-files (groovy-proposed/main) [11ubuntu5 => 11ubuntu6] (core, i386-whitelist)
<Laney> mdeslaur: are you up for running another ACL command for us please? we need queue admin for ubuntu-release in groovy now, which I think is: for pocket in proposed updates; do edit-acl -p ubuntu-sru -S groovy --pocket $pocket -t admin remove; edit-acl -p ubuntu-release -S groovy --pocket $pocket -t admin add; done
-queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (groovy-proposed) [11ubuntu6]
-queuebot:#ubuntu-release- Unapproved: distro-info-data (focal-proposed/main) [0.43ubuntu1 => 0.43ubuntu1.1] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: distro-info-data (groovy-proposed/main) [0.43ubuntu1 => 0.44ubuntu1] (core, i386-whitelist)
<mdeslaur> Laney: sure, one sec
-queuebot:#ubuntu-release- Unapproved: accepted vaultlocker [source] (bionic-backports) [1.0.6-0ubuntu0.19.10.1~ubuntu18.04.1]
<mdeslaur> Laney: done.
<Laney> mdeslaur: nice, thanks again
<mdeslaur> np
-queuebot:#ubuntu-release- Unapproved: openjdk-15 (groovy-proposed/universe) [15~19-1ubuntu2 => 15~19-1ubuntu2] (i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: distro-info-data (eoan-proposed/main) [0.40ubuntu3 => 0.40ubuntu4] (core)
-queuebot:#ubuntu-release- Unapproved: rejected openjdk-15 [sync] (groovy-proposed) [15~19-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: distro-info-data (bionic-proposed/main) [0.37ubuntu0.6 => 0.37ubuntu0.7] (core)
<tumbleweed> sil2100: ^^ all uploaded groovy back to xenial
-queuebot:#ubuntu-release- Unapproved: distro-info-data (xenial-proposed/main) [0.28ubuntu0.13 => 0.28ubuntu0.14] (core)
-queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (groovy-proposed) [0.44ubuntu1]
<tumbleweed> actually, I'll do the two ESMs too...
<tumbleweed> err one ESM
<sil2100> tumbleweed: sweet! Ok, reviewing the SRU ones now
-queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (focal-proposed) [0.43ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (eoan-proposed) [0.40ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (bionic-proposed) [0.37ubuntu0.7]
-queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (xenial-proposed) [0.28ubuntu0.14]
<bdmurray> popey / wimpress: Do you know if there is a way to get notifications about changes to a post like the Groovy release schedule?
<popey> i get notifications from it actually. dunno why
-queuebot:#ubuntu-release- Unapproved: openmpi (groovy-proposed/universe) [4.0.3-0ubuntu1 => 4.0.3-6ubuntu1] (i386-whitelist, kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: rejected openmpi [sync] (focal-proposed) [4.0.3-6ubuntu1]
<Laney> https://meta.discourse.org/t/wiki-notifications/86680 this says to me that there's a way, but it's not v. clear what that way is
-queuebot:#ubuntu-release- Unapproved: golang-defaults (groovy-proposed/main) [2:1.13~1ubuntu2 => 2:1.14~1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox [sync] (focal-proposed) [6.1.6-dfsg-2]
-queuebot:#ubuntu-release- Unapproved: virtualbox (groovy-release/multiverse) [6.1.6-dfsg-1 => 6.1.6-dfsg-2] (ubuntu-cloud) (sync)
-queuebot:#ubuntu-release- Unapproved: rejected golang-google-grpc [sync] (focal-proposed) [1.27.1-1]
-queuebot:#ubuntu-release- Unapproved: golang-google-grpc (groovy-release/universe) [1.22.1-1ubuntu1 => 1.27.1-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: rejected weechat-scripts [sync] (focal-proposed) [20200421-1]
-queuebot:#ubuntu-release- Unapproved: weechat-scripts (groovy-release/universe) [20191009-1 => 20200421-1] (no packageset) (sync)
<Laney> vorlon: or someone else on the TB: Please could you mark focal release as dirty? We changed the set of signing keys and I want it to re-publish with those.
<Laney> URGH
<Laney> NOT FOCAL
<Laney> groovy
<Laney> This is the same as me writing '2019' for all of January 2020
<cjwatson> "mark-suite-dirty -s groovy" should do it (possibly switching it to python3 in the process, which should work although I can't currently test it ...)
<cjwatson> in fact I'm just going to commit a #! change, it looks fine
-queuebot:#ubuntu-release- Unapproved: debootstrap (groovy-proposed/main) [1.0.118ubuntu1 => 1.0.123ubuntu1] (core)
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Groovy Daily] (20101020ubuntu614) has been added
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Groovy Daily] (20101020ubuntu614) has been added
-queuebot:#ubuntu-release- Builds: Netboot armhf [Groovy Daily] (20101020ubuntu614) has been added
-queuebot:#ubuntu-release- Builds: Netboot i386 [Groovy Daily] (20101020ubuntu614) has been added
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Groovy Daily] (20101020ubuntu614) has been added
-queuebot:#ubuntu-release- Builds: Netboot s390x [Groovy Daily] (20101020ubuntu614) has been added
<vorlon> Laney: changed the set of signing keys> archive signing keys?
-queuebot:#ubuntu-release- Unapproved: gcc-9 (groovy-proposed/main) [9.3.0-10ubuntu2 => 9.3.0-11ubuntu1] (core, i386-whitelist)
<vorlon> Laney, cjwatson: command run
<tsimonq2> I call dibs on creating the new wiki page for Groovy.
 * tsimonq2 runs through my personal new-release checklist (well, Lubuntu's, but...): https://phab.lubuntu.me/source/new-release/browse/master/README.md
-queuebot:#ubuntu-release- Unapproved: devscripts (focal-proposed/main) [2.20.2ubuntu2 => 2.20.2ubuntu3] (core, i386-whitelist)
<ddstreet> Groovy Gorilla, sounds fun
<tsimonq2> Indeed.
-queuebot:#ubuntu-release- Unapproved: rejected devscripts [source] (focal-proposed) [2.20.2ubuntu3]
-queuebot:#ubuntu-release- Unapproved: devscripts (groovy-proposed/main) [2.20.2ubuntu2 => 2.20.2ubuntu3] (core, i386-whitelist)
<tsimonq2> I can take care of Lintian unless someone else is already on that.
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (groovy-proposed) [1.0.123ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-9 [source] (groovy-proposed) [9.3.0-11ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted devscripts [source] (groovy-proposed) [2.20.2ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted golang-defaults [sync] (groovy-proposed) [2:1.14~1]
-queuebot:#ubuntu-release- Unapproved: network-manager (bionic-proposed/main) [1.10.6-2ubuntu1.4 => 1.10.6-2ubuntu1.5] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: network-manager (eoan-proposed/main) [1.20.4-2ubuntu2.2 => 1.20.4-2ubuntu2.3] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: network-manager (focal-proposed/main) [1.22.10-1ubuntu1 => 1.22.10-1ubuntu2] (desktop-core, i386-whitelist)
<tsimonq2> https://salsa.debian.org/lintian/lintian/-/merge_requests/304
<vorlon> sil2100, Laney, bdmurray: archive opening checklist says to create a 'feature-freeze' milestone but we haven't done that in recent past (or possibly ever) and no one has complained.  Unless one of you objects, I'm going to remove it from the checklist
<bdmurray> vorlon: it might be useful if we were to look at milestones for trello card due dates
<vorlon> bdmurray: is that an objection, then?
<bdmurray> vorlon: its a conceptual one not a strenuous one. ;-)
<vorlon> fyi I'm cleaning up priority mismatches now for groovy... so we'll find out whether that in fact breaks anything
-queuebot:#ubuntu-release- Unapproved: debootstrap (bionic-proposed/main) [1.0.95ubuntu0.5 => 1.0.95ubuntu0.6] (core)
-queuebot:#ubuntu-release- Unapproved: debootstrap (focal-proposed/main) [1.0.118ubuntu1 => 1.0.118ubuntu1.1] (core)
-queuebot:#ubuntu-release- Unapproved: debootstrap (eoan-proposed/main) [1.0.116ubuntu1.1 => 1.0.116ubuntu1.2] (core)
-queuebot:#ubuntu-release- Unapproved: debootstrap (xenial-proposed/main) [1.0.78+nmu1ubuntu1.10 => 1.0.78+nmu1ubuntu1.11] (core)
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (focal-proposed) [1.0.118ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (eoan-proposed) [1.0.116ubuntu1.2]
<Laney> vorlon: ISTR that some teams wanted to use that to track their work items
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (bionic-proposed) [1.0.95ubuntu0.6]
<Laney> but maybe it never got used, so no particular objection
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (xenial-proposed) [1.0.78+nmu1ubuntu1.11]
<sil2100> vorlon: hey!
<sil2100> vorlon: can you do the branch-livefses task? Since I suppose only buildd-admins can do that one
<sil2100> I ran the script but it failed at one point
<sil2100> (I don't have the powers to set relative_build_score it seems)
<sil2100> wgrant: hey! So regarding ceph in focal-proposed, I assume it's something you'd like to have in -updates?
<vorlon> sil2100: I will take a look at it; currently I'm looking at why proposed-migration doesn't seem to be getting anywhere on snakefruit
<vorlon> ah because I fixed the p-m run but the archive hasn't changed so archive-reports is skipping.  Easy enough to work around
<vorlon> ... and someone cowboyed an 'exit 0' into the middle of the run-proposed-migration script? pretty sure that's not in the archive opening checklist
<vorlon> anyway, running now
<vorlon> sil2100: branch-livefses not updated yet to python3?
 * vorlon pushes
<sil2100> vorlon: sadly! I think both branch-* scripts are 2.7 still
<sil2100> Thank you!
<vorlon> branch-livefses running now
<vorlon> sil2100: error because https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/groovy/buildd already exists; deleting, trying again
<vorlon> sil2100: how many of these got created when you ran it?
<vorlon> sil2100: in fact, I'm unable to set require_virtualized
<vorlon> sil2100: so it fails for me anyway
<Laney> vorlon: I'd have preferred it if you didn't remove that, was waiting for autopkgtest to be ready
<Laney> I could have been less violent though
<Laney> it's checking for test results that might not be there now
<Laney> in fact I'd better kill this; if something falsely gets an ALWAYSFAIL now it could be promoted and I don't even
<Laney> hopefully nobbled so it doesn't run for groovy only
<cjwatson> so I can probably do branch-livefses since I'm in launchpad-buildd-admins
<cjwatson> shall I do that now?
<cjwatson> (and also in ~ubuntu-cdimage)
<cjwatson> actually this is surprising, since vorlon is also in ~launchpad-buildd-admins
<cjwatson> oh, right, it needs ~launchpad-ppa-self-admins or ~launchpad-ppa-admins
<cjwatson> but I can do it if that's OK
<cjwatson> Laney,vorlon: ^-
<Laney> cjwatson: I think that'd be fine
<vorlon> cjwatson: well I'm patching the script so that it can do something reasonable on already-existing livefs builds; testing now and then I can push if you want to use it
<cjwatson> sure, tell me when
<vorlon> cjwatson: pushed
<cjwatson> vorlon: have you created the livefses, just not devirted them etc., then?
<vorlon> cjwatson: sil2100 created them
<cjwatson> vorlon: (that would be helpful since I'm not in ~cloud-images-release-managers)
<vorlon> oh I can go create those
<vorlon> I stopped at ubuntu-cdimage so far
<cjwatson> Yeah if you could do all three that'd be perfect, and then I can power them up
<vorlon> ok
<vorlon>     if [ "$SERIES" = focal ] -o [ "$SERIES" = groovy ]; then
<vorlon> >_<
<cjwatson> Where's that?
<vorlon> in britney
<vorlon> fixed now :)
<cjwatson> Yeah that's not ideal :)
<vorlon> doko, Laney: which of you is cowboying the changes to run-proposed-migration?
<vorlon> I have no idea what "proposed-migration is still seeding" is supposed to mean
<cjwatson> vorlon: (ideally soon - it's 21:43 local and I don't want to stick around much longer)
<vorlon> ah sorry, hit more errors again
<vorlon> cjwatson: ok cloud-image-release-managers and cloudware are done, ubuntu-cdimage is still working through the list
-queuebot:#ubuntu-release- Builds: Upgrade Kubuntu amd64 [Groovy Daily] (20200424) has been added
-queuebot:#ubuntu-release- Builds: Upgrade Lubuntu amd64 [Groovy Daily] (20200424) has been added
-queuebot:#ubuntu-release- Builds: Upgrade Ubuntu GNOME amd64 [Groovy Daily] (20200424) has been added
-queuebot:#ubuntu-release- Builds: Upgrade Ubuntu GNOME i386 [Groovy Daily] (20200424) has been added
-queuebot:#ubuntu-release- Builds: Upgrade Ubuntu MATE amd64 [Groovy Daily] (20200424) has been added
-queuebot:#ubuntu-release- Builds: Upgrade Ubuntu MATE i386 [Groovy Daily] (20200424) has been added
-queuebot:#ubuntu-release- Builds: Upgrade Lubuntu i386 [Groovy Daily] (20200424) has been added
-queuebot:#ubuntu-release- Builds: Upgrade Ubuntu Server amd64 [Groovy Daily] (20200424) has been added
-queuebot:#ubuntu-release- Builds: Upgrade Ubuntu Server i386 [Groovy Daily] (20200424) has been added
-queuebot:#ubuntu-release- Builds: Upgrade Ubuntu Studio amd64 [Groovy Daily] (20200424) has been added
-queuebot:#ubuntu-release- Builds: Upgrade Ubuntu Studio i386 [Groovy Daily] (20200424) has been added
-queuebot:#ubuntu-release- Builds: Upgrade Ubuntu amd64 [Groovy Daily] (20200424) has been added
-queuebot:#ubuntu-release- Builds: Upgrade Kubuntu i386 [Groovy Daily] (20200424) has been added
-queuebot:#ubuntu-release- Builds: Upgrade Ubuntu i386 [Groovy Daily] (20200424) has been added
-queuebot:#ubuntu-release- Builds: Upgrade UbuntuKylin amd64 [Groovy Daily] (20200424) has been added
-queuebot:#ubuntu-release- Builds: Upgrade UbuntuKylin i386 [Groovy Daily] (20200424) has been added
-queuebot:#ubuntu-release- Builds: Upgrade Xubuntu amd64 [Groovy Daily] (20200424) has been added
-queuebot:#ubuntu-release- Builds: Upgrade Xubuntu i386 [Groovy Daily] (20200424) has been added
<vorlon> cjwatson: ubuntu-cdimage livefses created. and the script is now more happily idempotent
<cjwatson> vorlon: OK, preferred invocation?
<cjwatson> (I mean, I only wrote this script, can't be expected to remember it ...)
<vorlon> cjwatson: for owner in cloudware ubuntu-cdimage cloud-images-release-managers; do ./branch-livefses --source-series=focal --dest-series=groovy $owner; done
<vorlon> :)
<vorlon> now afk for a spell
<cjwatson> running
<cjwatson> Seems to be doing reasonable things
<Laney> vorlon: It's me, I highlighted you and updated this channel to say I was doing it
<cjwatson> vorlon: should all be done now
<vorlon> Laney: ah sorry, missed that
<Laney> np
<Laney> the sync just finished
<Laney> so I need to do download-results on the web node now
<Laney> http://autopkgtest.ubuntu.com/packages/gzip this is getting silly, we need to do some purging
<vorlon> Laney: so I guess we should record the dependency as well for the future, to wait for autopkgtest stuff to finish before doing the p-m bits?
<Laney> vorlon: Sounds sensible, yeah
<Laney> I think results are downloaded now
 * Laney pushes config changes
<Laney> there's still some cowboys for i386 testing which I will update but should be committed
<wgrant> sil2100: ceph> yeah, though I guess that means it needs an SRU bug etc. now
<Laney> think I might finish off the rest of the autopkgtest enablement/proposed-migration tomorrow
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1050.55] (no packageset)
#ubuntu-release 2020-04-25
<sil2100> wgrant: ceph is already in -proposed and we could basically treat it as an 0-day SRU
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1050.55]
<vorlon> Laney: btw I'm not sure the i386 cowboys are actually required; I had implemented it differently in git and waffled about whether to drop the cowboyed bit
<Laney> vorlon: great, let's get that sorted out then
<Laney> right, autopkgtests look good to me
<Laney> let's do a run
<Laney> (of proposed-migration)
-queuebot:#ubuntu-release- Unapproved: accepted openmpi [sync] (groovy-proposed) [4.0.3-6ubuntu1]
-queuebot:#ubuntu-release- Unapproved: weechat-scripts (groovy-proposed/universe) [20191009-1 => 20200421-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: golang-google-grpc (groovy-proposed/universe) [1.22.1-1ubuntu1 => 1.27.1-1] (ubuntu-mate) (sync)
<Laney> could someone in ubuntu-archive reject those three syncs to groovy *release* please?
-queuebot:#ubuntu-release- Unapproved: accepted golang-google-grpc [sync] (groovy-proposed) [1.27.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted weechat-scripts [sync] (groovy-proposed) [20200421-1]
<doko> Laney: done
-queuebot:#ubuntu-release- Unapproved: rejected golang-google-grpc [sync] (groovy-release) [1.27.1-1]
-queuebot:#ubuntu-release- Unapproved: rejected weechat-scripts [sync] (groovy-release) [20200421-1]
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox [sync] (groovy-release) [6.1.6-dfsg-2]
<Laney> doko: thanks
<Laney> looks good to open to me I'd say
-queuebot:#ubuntu-release- Unapproved: gcc-9 (groovy-proposed/main) [9.3.0-11ubuntu1 => 9.3.0-11ubuntu2] (core, i386-whitelist)
<doko> yes, the s390x gcc-9 build on s390x succeeded, for the other archs it's just a normal upload
<doko> Laney: does britney migration now wait on riscv64?
<Laney> no change since focal yet
<doko> please enable that, or else transitions will be out of sync in a day or two
<juliank> Upgraded my server to focal, everything seems to work fine
<doko> during the freeze we didn't have any transitions
<Laney> ok, but it implies active fixing will likely be required so we should probably mention it in the opening email
<doko> Laney: and probably it should be enabled for focal now as well
-queuebot:#ubuntu-release- Unapproved: accepted gcc-9 [source] (groovy-proposed) [9.3.0-11ubuntu2]
<juliank> ubuntu-security-status does not give me a list of packages, sigh
<juliank> Let's enable esm-infra and esm-apps
<juliank> :)
<juliank> And I gotta upload python-apt with groovy template
<Laney> there's a list somewhere of packages that need uploading
<juliank> yes, but I already got a bug report from unhappy users about it, and it breaks a ton of autopkgtests :D
<juliank> I think it needs moving up in the list we have, because it does cause quite a few unnecessary test failures
-queuebot:#ubuntu-release- Unapproved: gcc-10 (groovy-proposed/main) [10-20200411-0ubuntu1 => 10-20200425-1ubuntu1] (i386-whitelist)
<juliank> Oh Laney, I thought it's groovy gorilla, but archive just says Groovy?
<juliank> Launchpad says Groovy, focal is The Focal Fossa
<Laney> it is, that'll be changed
-queuebot:#ubuntu-release- Unapproved: python-apt (groovy-proposed/main) [2.0.0 => 2.0.0ubuntu1] (core, i386-whitelist)
<juliank> ^ Anyhow, I'll just leave that here, accept as needed
-queuebot:#ubuntu-release- Unapproved: accepted python-apt [source] (groovy-proposed) [2.0.0ubuntu1]
<juliank> We can then sync python-apt 2.1.3 over it later (not yet available), which removes the python-apt binary package (aka python2 support)
<juliank> This way we get the minimal thing to unblock migration for various packages without entangling it with py2removal :)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-10 [source] (groovy-proposed) [10-20200425-1ubuntu1]
<juliank> groovy
<ginggs> i can't retry autopkgtests:
<ginggs> You submitted an invalid request: Unknown release groovy
-queuebot:#ubuntu-release- Unapproved: gcc-10 (groovy-proposed/main) [10-20200425-1ubuntu1 => 10-20200425-1ubuntu2] (i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-10 [source] (groovy-proposed) [10-20200425-1ubuntu2]
<doko> Laney: ^^^
<ginggs> autopkgtests retries working now, thanks whomever :)
-queuebot:#ubuntu-release- Unapproved: llvm-toolchain-10 (groovy-proposed/main) [1:10.0.0-4ubuntu1 => 1:10.0.0-4ubuntu2] (i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-10 [source] (groovy-proposed) [1:10.0.0-4ubuntu2]
<juliank> Oh, forgot distro-info-data
<juliank> Ah it's in there, just gotta retry failures
<vorlon> doko: britney did already wait for riscv64; so there's no change, and transitions should not go out of sync?
-queuebot:#ubuntu-release- Unapproved: remmina (groovy-proposed/main) [1.4.2+dfsg-1ubuntu1 => 1.4.3+dfsg-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: ruby2.7 (groovy-proposed/main) [2.7.0-5ubuntu1 => 2.7.0-6ubuntu1] (i386-whitelist)
#ubuntu-release 2020-04-26
<juliank> : No such script: /usr/share/debootstrap/scripts/groovy
<juliank> More stuff to fix?
<juliank> Ah I shall retry piuparts against proposed debootstrap
<juliank> retried piuparts with [python-apt, debootstrap] triggers
<juliank> retried livecd-rootfs with [python-apt, deboostrap] triggers
<juliank> retried sbuild against ['courier/1.0.6-1build3', 'debootstrap/1.0.123ubuntu1', 'devscripts/2.20.2ubuntu3']
<juliank> apport needs an upload, I think I pushed a fixed version to a new groovy branch yesterday, but need to confirm
<juliank> groovy is missing dists/cnf, causing command-not-found to fail
-queuebot:#ubuntu-release- Unapproved: apport (groovy-proposed/main) [2.20.11-0ubuntu27 => 2.20.11-0ubuntu28] (core, i386-whitelist)
<juliank> ^ this should make the apport tests work again, they had a wrong twisted python2 dep in there :)
<juliank> (at least they passed on my focal autopkgtest VM)
<MdAyq076> Dear Ubuntu-release team, is there anythng that prevents https://wiki.ubuntu.com/Releases from being updated concerning focal?
<cjwatson> Releases> done
<Mirv> I wonder if it would be possible to restore some historical images like Lubuntu 14.04 images to be hosted? Those have been deleted both from cdimages and not available at old-releases - some older images are found for some variants, but it seems mostly that deletion from cdimages has been according to support schedule but old-releases storage more random.
<Mirv> For the specific interest, I have a page that suggests Lubuntu 14.04.1 for machines with 192MB-256MB RAM, and I've tested that in the past - for some use cases using non-supported distribution would still give some life time to hardware for example for writing purposes.
<Mirv> (and Lubuntu 16.04 alternate installer 32-bit for machines with 256MB-512MB RAM, also tested at some point)
-queuebot:#ubuntu-release- Unapproved: protobuf (groovy-proposed/main) [3.6.1.3-2ubuntu5 => 3.11.4-4] (desktop-core, i386-whitelist, ubuntu-server) (sync)
<locutus_> I think we should do it before opening ^^
-queuebot:#ubuntu-release- Unapproved: scribus-doc (groovy-proposed/multiverse) [1.5.5+dfsg-2~ubuntu20.04.1 => 1.5.5+dfsg-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: msttcorefonts (groovy-proposed/multiverse) [3.7ubuntu6 => 3.8ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pkg-config (groovy-proposed/main) [0.29.1-0ubuntu4 => 0.29.2-1ubuntu1] (core, i386-whitelist)
<valorie> methinks the topic needs Focal > Groovy
-queuebot:#ubuntu-release- Unapproved: nginx (focal-proposed/main) [1.17.10-0ubuntu1 => 1.18.0-0ubuntu1] (ubuntu-server)
* cjwatson changed the topic of #ubuntu-release to: Released: Focal 20.04, Bionic 18.04.4 | Archive: Closed | Highlight ubuntu-archive for archive admin help | Groovy Release Coordination | We accept payment in cash, cheque or gin | melius malum quod cognoscis
<cjwatson> valorie: done, thanks
<valorie> <3
<teward> nginx has an SRU bug tied to it, just stating.  For when we get SRUs back up and operating.
-queuebot:#ubuntu-release- Unapproved: debhelper (groovy-proposed/main) [12.10ubuntu1 => 13ubuntu1] (core, i386-whitelist)
