#ubuntu-release 2010-07-30
<ttx> cjwatson, pitti,slangasek: any of you could re-trigger a Server ISO build ?
<Daviey> Is there an ETA on the new server iso?
<ttx> Daviey: it wasn't triggered yet
<Daviey> :(
<slangasek> ttx: looking
<slangasek> ttx, Daviey: scheduled
<Daviey> slangasek: rockin'
<ttx> slangasek: thanks
<ttx> smoser: ^
<smoser> whoowhoo. of course all will work this time around.
<smoser> no wammies
<Daviey> smoser: BTW you were wrong about it never, *ever* stop raining in Prague.  So i'm not confident that your prediction of this roll being without warts :)
<bjf> anyone else notice the daily live isos have not changed for 3 days?
<slangasek> yes - failing because the kernel metapackages are uninstallable ;)
<slangasek> (http://people.canonical.com/~ubuntu-archive/livefs-build-logs/maverick/ubuntu/20100730/)
<mvo> slangasek: just fyi, the apt from experimental is now in maverick, rdepends are currently building
<slangasek> whoo \o/
<slangasek> now to figure out where my ppa upload of a multiarch eglibc went
<slangasek> aha, it landed in the wrong ppa
 * slangasek fixes
#ubuntu-release 2011-07-25
<Laney> kirkland: jdstrand: will you be able to process the outstanding archive requests in the absence of the others due to debconf?
<cjwatson> I will have a look
<Laney> :-)
<jdstrand> Laney: re ubuntu archive: I will be going through the NEW queue for sure. I will try to hit the other parts as I have time
<Laney> great
<Laney> the archive days stuff from the wiki should be removed as it seems obsolete now
<persia> I don't think it ought be removed: rather there ought be corrections to have the data match behaviour.
<Laney> I didn't say that the correct situation shouldn't be added in its place (indeed it should), just that incorrect information shouldn't be presented
<slangasek> eh, why in the world did someone ask for the new upstream version of gawk to be synced?
<slangasek> causes a components-mismatch now...
<Laney> the typical build tools don't make this apparent
<slangasek> Laney: it's a silly thing for someone to have been worrying about syncing at this stage of the cycle anyway
<Laney> slangasek: I have told dupondje this numerous times. You should too.
<Laney> He seems to want to sync everything going.
<charlie-tca> alternate images fail to install today, Ubuntu and Xubuntu, VBox and hardware
<charlie-tca> blank screen right after starting
<charlie-tca> looks like a kernel panic
<jibel> charlie-tca, thanks. confirmed on all d-i based images
<jibel> bug 815962
<ubot4> Launchpad bug 815962 in debian-installer (Ubuntu) "oneiric d-i based images kernel panic on boot (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/815962
<cjwatson> I might be able to find some time to fix that
<cjwatson> wow, network here is a lot happier now
<charlie-tca> Thanks, jibel
<GrueMaster> bug 815962 affects omap4 as well.
<ubot4> Launchpad bug 815962 in udev (Ubuntu) "oneiric d-i based images kernel panic on boot (affects: 2) (dups: 1) (heat: 14)" [Critical,Fix released] https://launchpad.net/bugs/815962
 * Daviey has made some changes to the seed, with the initial work to remove eucalyptus from the installer.
<Daviey> I also removed uec-live, which i don't believe is built automagically anyway.
<Daviey> germinate runs happily, so i think we are OK..
<Daviey> .. or at least i hope i don't break the daily for tomorrow :)
<ScottK> You'll probably need a -meta upload too.
<Daviey> ScottK: server doesn't have a meta package.
<ScottK> Oh.
<Daviey> odd. i know.. Apparently the fear of sysadmins might have of removing "ubuntu-server" was enough not to have one aiui.
#ubuntu-release 2011-07-26
<Daviey> I don't suppose anyone with cdimage access is around?
<ev> Daviey: still need help with cdimage?
<ev> I charge a reasonable fee for my services.
<Daviey> ev: Nah, i wanted a branch merged before the daily spin.. cjwatson merged it this morning.
<Daviey> Thanks anyway ev!
<ev> sure thing
<pgraner> patrickmw, jibel, ping
<patrickmw> pgraner, hey
<jibel> pgraner, pong
<pgraner> patrickmw, jibel naartijie is dead, it has been replaced with aldebaran
<pgraner> all the addresses etc are the same just the name has changed
<pgraner> I'll get it loaded with 11.04 tomorrow when I slam all the disks in
<patrickmw> pgraner, ack. that server had been pissing me off
<pgraner> patrickmw, has bad mother board issues afaikt
<pgraner> patrickmw, on wazan and albali what do you have installed?
<pgraner> patrickmw, that is I need to add the new disks tomorrow and rebuild the box from scratch, so what do you need to install etc. once its done?
<patrickmw> pgraner, that's a big question. there's lots of manual config more than anything. do I have the rest of the day today to review?
<pgraner> patrickmw, yep you've got till tomorrow
<pgraner> patrickmw, really I can put the disks in and we can fix it later via IP-KVM
<pgraner> patrickmw, but I'd like to get it done tomorrow if possible
<patrickmw> pgraner, i don't see it as an issue
<pgraner> patrickmw, which brings up a good point those configs should be somewhere backed up
<pgraner> with a script to reconfig quickly
<patrickmw> pgraner: I thought they were :/
<pgraner> patrickmw, if they are I can't find the docs
<patrickmw> pgraner: I think that needs to be my top priority haha
<pgraner> patrickmw, ack
<pgraner> patrickmw, damn -EWRONGCHANNEL I thought this was -quality ... sorry lets move it there
#ubuntu-release 2011-07-27
<lamont> fyi: brief disturbance in the buildd universe, manualizing the non-virts
<lamont> in a few min
<lamont> or now, even.
<lamont> and all better
<ScottK> lamont: If you're in the mood for killing things, https://launchpad.net/ubuntu/+source/kde4libs/4:4.7.0-0ubuntu1/+build/2650993 on ross will take a long time to build and is pointless.  Given the mass give back trying to build ATM, it might be worth killing it.
<ScottK> or rather the inadvertent autosync.
<lamont> ScottK: given adare, that much is obvious, eh?  killing it
<lamont> tree nuked
<ScottK> Thanks.
<ScottK> skaet: I think the indavertent autosync deserves a mail to u-d-a so people understand why a bunch of stuff got updated.
<skaet> ScottK, agreed.   I still need to dig into backstory to understand, but if you know the backstory feel free to send.
<ScottK> skaet: All I know is it was done inadvertently as part of LP testing.
<ScottK> I'm quite happy to wait for the rest of the story.
<skaet> ScottK, that's about my level right now too...
<ScottK> seb128 seemed to know a bit more (he was explaining it in #ubuntu-devel)
<seb128> yeah, I can provide details if needed
<seb128> didrocks build lists of what got synced on http://people.canonical.com/~didrocks/sync110727/
<seb128> the soyuz guys will file some bugs about the issue we ran into I will give you the number once they are filed
<didrocks> synced_packages.txt is the raw data from soyuz
<didrocks> syncs_in_main is the fitered list of packages that was synced in main
<didrocks> I looked and fixed when necessary the ones in main
<didrocks> now, remains the 3 in universe, I'll have a look now
<didrocks> you have the ubuntu version | debian version which is now in oneiric
<didrocks> seb128: skaet: I can write the first draft of the email if you want
<seb128> so in summary what was tried is the "sync a source" button enabled for one user
<seb128> which due to a bug in the js or somewhere triggered an autosync
<didrocks> and we triggered some bugs in the javascript
<seb128> other bugs hit on the way include the autosync overwriting a few sources with ubuntu diffs
<seb128> which didrocks is fixing
<seb128> and a few cosmetic issues in the changelog and -changes emails formatting
<didrocks> if only there has been those cosmetics issue, that would have been fine :)
<skaet> ScottK, seb128, didrocks - note now sent to u-d-a about the inadvertent sync.
<didrocks> skaet: great, thanks!
<seb128> skaet, thanks!
<ScottK> skaet: I saw it.  Thanks.
<ScottK> I thought it was a good note.
<skaet> thanks.
<skaet> SpamapS, can you copy out the lucid kernel (2.6.32-333.71) from proposed to updates? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/813507
<ubot4> Launchpad bug 813507 in linux (Ubuntu Lucid) (and 10 other projects) "linux: 2.6.32-33.71 -proposed tracker (affects: 1) (heat: 12)" [High,In progress]
<skaet> its baked enough, and the other teams have signed off.
<SpamapS> skaet: yes, was a lunch.. will take a look shortly.
<skaet> SpamapS, thanks!  :)
#ubuntu-release 2011-07-28
<lamont> oh hey archive admin gods... can I get you to do NEW processing for gcc-4.6 pls?
<jibel> todays alternate and server: bug 817443
<ubot4> Launchpad bug 817443 in debian-installer (Ubuntu) "d-i based images failed to install: mount: mounting /dev on /target/dev/ failed: Invalid argument (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/817443
<lamont> there will be a brief disturbance as I put everything on manual
<lamont> and back to auto
<skaet> SpamapS, any update on making the lucid kernel (2.6.32-33.71) available in -updates?
<SpamapS> skaet: sorry I have been having huge technical difficulties and my main machine has been out of commission
<SpamapS> skaet: and now I'm at OSCON
<skaet> slangasek,  ROAF, ^^ are either of you able to move the lucid linux kernel (.71) from -proposed to -updates ??
<skaet> hmm... ROAF isn't on this channel right now.
#ubuntu-release 2011-07-29
<lamont> eglibc/armel is new.  someone wanna smack that for me?
<jamespage> morning
<jamespage> any archive admins planning on reviewing NEW source packages for oneiric this week?
<jamespage> I have 7 in the queue including jenkins which I would like to land if possible for A3
<jibel> cjwatson, should bug 817443 be fixed with today's builds ? I still get it with alternate, I'll try server after lunch
<ubot4> Launchpad bug 817443 in udev (Ubuntu Oneiric) (and 1 other project) "d-i based images failed to install: mount: mounting /dev on /target/dev/ failed: Invalid argument (affects: 4) (dups: 1) (heat: 20)" [Critical,Fix released] https://launchpad.net/bugs/817443
<cjwatson> jibel: no, I didn't get to uploading debian-installer including that patch until this morning.  server won't work either, don't bother
<cjwatson> jibel: it should be fixed tomorrow
<jibel> cjwatson, ok thanks.
<ScottK> skaet: Working on KDE 4.7.0 uploads and getting python-qt4 installable again (fallout from the inadvertent sync)
<skaet> ScottK,  thanks,  was wondering how Kubuntu was doing post sync.   Likely to get sorted out for A3,  or impact?
<ScottK> It'll get sorted
<tumbleweed> ah, the other unexpected transition wasn't actually a transition, but libreadline5-dev vanished
<tumbleweed> * libreadline-gplv2-dev: Stop providing libreadline5-dev.
<micahg> yep, that's good
<micahg> oh
<micahg> the stop providing part wasn't supposed to happen :-/
<tumbleweed> trivial enough to reverse that
<tumbleweed> (assuming you're a core-dev) :)
<micahg> eh, not worth it
<micahg> only about 30 rdepends
<tumbleweed> ok
<jdstrand> skaet: do we have a place for release notes yet? (for oneiric)
<skaet> jdstrand,  we'll be using TechnicalOverview again,  shifting it to ref. A3 is still pending.
<skaet> go ahead and make any necessary changes,  and I'll look at the diff and preserve in subsequent edits.
<jdstrand> skaet: ok, this should make it all the way to release, btw (I'll add a comment about it)
<skaet> jdstrand,  thanks!
<jibel> skaet, ubuntu-server 20110729.4 builds are ok.
<skaet> jibel,  cool.   good to know.
<chrisccoulson> when does the A3 freeze start? it's monday isn't it?
<charlie-tca> chrisccoulson: soft freeze will be August 1 at 1200 UTC
<chrisccoulson> thanks
#ubuntu-release 2011-07-30
<ScottK> Python is broken.
<ScottK> Trying to fix
<ScottK> I'm seriously confused about why
<ScottK> Needs to be fixed in python2.6
<ScottK> Let's see how that works ...
#ubuntu-release 2011-07-31
<micahg> any archive admins around to remove a binary? libglew1.5-dev provides libglew-dev and is blocking it's rdepends from building with the new libglew1.6-dev
<micahg> s/it
<micahg> s/it
<micahg> ugh
<micahg> s/it's/its/ :)
#ubuntu-release 2012-07-23
<babyface_> jamespage,  ping
<jamespage> babyface_, morning
<babyface_> jamespage, good morning!
<babyface_> jamespage, I just found that the job http://10.189.74.2:8080/view/Quantal/view/ISO%20Testing/job/quantal-server-amd64_tomcat-server/70/testReport/junit/test/TomcatServerTest/testTomcatDaemon/  failed again.  but in this bug:  https://bugs.launchpad.net/ubuntu/+source/tomcat7/+bug/1025595   you said you already increased the time
<ubot2> Ubuntu bug 1025595 in tomcat7 "tomcat7 not running on port 8005 after installation" [Undecided,Invalid]
<babyface_> jamespage, could you have a look on it?
<jamespage> babyface_, I have - but it is possible that on a really slow VM that it still does not complete in time.
<jamespage> babyface_, I am considering an alternative fix to this - to make randomness a bit quicker in the test VM for this test
<babyface_> jamespage,  yes, please.
<babyface_> jamespage, we can not just let it be unstable, that looks ugly  ;)
<jamespage> babyface_, yes - but it is a test failure rather than a bug... I will fix it but not right now...
<jamespage> babyface_, if you want a green ball just run it again - in all likelyhood it will pass..
<infinity> jamespage: Assuming this is a /dev/random entropy issue, just make the VMs use urandom for random?
<jamespage> infinity, yeah - that was my thinking
<babyface_> jamespage, ack, I know, it's not a big deal, and not a real bug in code, so take you time and fix it when you are free
<jamespage> i've just not got to it yet
<infinity> (That said, I could see it as a package bug too, if the package sometimes forks the daemon but then doesn't *actually* start for a minute, that's a bit unintuitive)
<infinity> jamespage: But it's certainly a bug/misfeature in the test framework to ever use a real /dev/random, unless the point of the test is actually to test quality of randomness (which would be a rather rare testcase, I suspect).
<jamespage> infinity, certainly not in this case
<xnox> !package haveged
<ubot2> Factoid 'package haveged' not found
<xnox> !deb haveged
<ubot2> Factoid 'deb haveged' not found
<xnox> jamespage: infinity: $ sudo apt-get install haveged
<xnox> this will give you more entropy without using urandom. I do this a lot on VMs.
<jamespage> xnox, that of course is another alternative...
 * jamespage wonders what that package actuall does...
<xnox> Linux entropy source using the HAVEGE algorithm
<xnox> french wrote it, it must be good =)
<cjwatson> stgraber: I've confirmed that all those duplicate ArchivePermission rows are gone now.
<cjwatson> stgraber: (P.S. please use edit-acl rather than edit_acl.py - at some point I'll drop that compat symlink)
<Laney> erm...
<Laney> Riddell: you're not in backporters; why are you uploading and accepting backports?
<Riddell> Laney: it's not good enough to be a core-dev?
<Laney> no, just as it isn't for SRUs
<Riddell> Laney: sorry about that
<stgraber> cjwatson: yay, thanks for cleaning that up!
<skaet> ogra_, Daviey -  I'm seeing we're still building arm server armhf+omap - who's using it/testing it?  and can it be dropped?
<skaet> mvo,  we're starting to ramp into A3 now.   Could you please do the GnomeAppInstallDatabaseUpdate now?
<balloons> I just realized we're still showing 'quantal daily' and not alpha 3 as our milestone
<ogra_> skaet, well, i switched armhf to alternate over the weekend and would greastly prefer to drop server preinstalled but i'm not sure if QA relies on preinstalled
<ogra_> skaet, alternate is only built for omap4 atm
<skaet> balloons, we'll be switching it over today
<ogra_> skaet, and server preinstalled is still broken
<skaet> ogra_,  why do we care about armhf+omap?
<skaet> for server
<ogra_> skaet, because its the easiest way to install adev setup on a beagle
<ogra_> *a dev
<ogra_> using ubuntu-core is painful to set up, the alternative is the netboot images but these indeed require a network connection
<ogra_> but i wouldnt cry if we lose them
<ogra_> skaet, as for all omap3 images, we only build them because it has such a big community ... but we're lacking testers here
<skaet> ogra_,  if we're lacking testers,  not much point in building them while we're limited for capacity.
 * Riddell wonders if he has time to slip in one extra new package into the archive for alpha 3
<ogra_> skaet, well, we get the kernel and bootloader for free (close to zero work) and we have a ton of spare beagleboards in the datacenter (former builders)
<ogra_> we should just send them out to some people :)
<micahg> Riddell: mind if I rebuild calligra-l10n today for bug #1027215
<ubot2> Launchpad bug 1027215 in calligra-l10n "calligra-l10n-xx should enhance, not recommend calligra" [High,Triaged] https://launchpad.net/bugs/1027215
 * micahg doesn't want to disrupt kubuntu alpha 3
<skaet> Riddell,  how many hours is it going to take to build?
<Riddell> micahg: yes please go ahead
<skaet> (and dependencies...?)
<Riddell> skaet: 5 minutes says launchpad, but it's actually not on the images so it shouldn't be an issue for alpha I think
<skaet> Riddell,  if its not on the image no worries,  even if it is,  we're still fine for something that small.
 * skaet more worried about kernels, unity, firefox, launchpad, etc.
 * cjwatson is still hoping to get the server squashfs work in today
<cjwatson> just fixing tasksel at the moment
<cjwatson> almost everything else is done
<cjwatson> skaet: what's the worry about launchpad?
<skaet> cjwatson,  no worry about launchpad,  just that "package" can be rather an ambiguous term in terms of build time.
<skaet> was just trying to figure if it was something smallish,  or not
<cjwatson> ok
<ScottK> infinity: What are the chances you get around to fixing the fact that soyuz makes packages with uninstallable build-deps FTBFS instead of putting them in dep wait anytime soon?
<ScottK> In Kubuntu there's discussion of rewickering the packages to work around this, but it'll be work that could be avoided if that's going to happen soonish.
<skaet> Laney, slangasek https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview/Alpha3  is ready for data to be added from the various teams now.
<Laney> great, perhaps link it from the freeze announcement
<skaet> Laney, yup,  just posting here to let you know that step is done.
<skaet> infinity,  until the new arm build infrastructure comes online,  can we drop arm server armhf+omap?   I don't think we have any testing lined up for, it,  and we're getting pretty close to capacitity with arm builds in the 24 period.
<infinity> skaet: I'm happy dropping it forever and just having netboot.
<infinity> (Same goes for all armhf+omap images)
<infinity> We discussed this last Alpha, but I think failed to come to action.
<skaet> infinity,  ok.    for all the ones you're the signoff for,  consider removed from the manifest then.
<infinity> Riddell / ScottK: Any qualms about dropping armhf+omap from Kubutu (not omap4, just omap)
<infinity> skaet: Which ones am I signed off for? :P
<skaet> infinity, https://wiki.ubuntu.com/QuantalQuetzal/ReleaseManifest
<skaet> ubuntu server pre-installed armhf+omap,  ubuntu preinstalled armhf+omap are the ones I'm spotting with your name beside
<infinity> Right.  And Kubuntu doesn't list it in the manifest anyway, so dropping that works too.
<Riddell> infinity: I'm fine with it but is there a way I can justify that to my community?
<ScottK> Riddell: I don't think we have any testers.
<infinity> Riddell: You apparently don't list it as a release image anyway... Unless that was a mistake.
<infinity> Riddell: And you so don't have testers.  I ended up testing that image for precise.
<infinity> (And it sucked... Beagleboard + KDE = lolz)
<ScottK> And the Canonical QA person who used to do it in his personal time doesn't work for Canonical anymore.
<ScottK> So no testing.
<Riddell> that'll do then, fine to drop it
<skaet> infinity,  ok,  dropped from the manifest.     nusakan need editing to reflect,  but I need to go to dentist now.   If you get to it before I return, post here please.
<infinity> Erk.
<infinity> Laney: We dropped all precise arm images?
<Laney> infinity: Apparently that was the decision.
<skaet> infinity Core should still be there.
<infinity> I missed that memo.
<infinity> Well, yes.  I don't count core when I talk about images.
<infinity> Cause it's not one.
<infinity> Not an installer, anyway. :P
<infinity> Laney: What was the driver behind ARM not being cool enough for point releases?
<skaet> https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest/12.04.1
<skaet> infinity, ^ this is for daily builds prior to LTS release.
<infinity> skaet: Kay, that doesn't give me rationale.
<skaet> and follow on from what was indicated as LTS vs. not in:  https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest
<skaet> all the arm ones were 18 month support
<infinity> Ahh, fair enough.
<infinity> Laney: That probably didn't need default-arches mangling, mind you, since "not doing daily-preinstalled builds" would have a similar effect.
<infinity> Anyhow.  No big deal.  Just conflicted with my changes. :P
<skaet> infinity,  what changes????
<infinity> ...
<Laney> hahaha
<infinity> skaet: The ones we discussed 6 minutes ago?
<skaet> heh,  ok.  :)
<skaet> sorry,  Laney's were done earlier and I was worried it was something else.
 * skaet --> dental appt.  biab
<balloons> I updated the notice board for the ETA on when the milestone builds will hit. Can we please make sure it stays up to date as we have respins, etc? Thanks!
<balloons> it's currently listed as 0600 on July 24th -- update if that day/time changes
<cjwatson> I'm switching the server images over to squashfs-base style now
<cjwatson> I guess there's some kind of fiddly pad thing I have to update?
<slangasek> for the image build list, there's http://pad.ubuntu.com/ubuntu-release
<ScottK> http://greenwellplumber.com/blog/wp-content/uploads/2011/12/Bathroom_humor_by_charfade1.jpg
<cjwatson> OK, server switched to squashfs-base, amended pad accordingly
<cjwatson> running an experimental build now, since all is quiet
<cjwatson> Oops, build failure with squashfs-base.  Fixing ...
<ScottK> Is the highbank stuff going into Quantal as well?  Precise-proposed before Quantal doesn't fit the SRU policy.
<stgraber> NCommander: ^
<NCommander> ScottK: its already in Quantal, but flash-kernel had a rewrite so its a different patch
<ScottK> OK.
<ScottK> Thanks.
<NCommander> I'm waiting for my PPA to finish building d-i to make sure I got everything sane then that gets uploaded and can be fully tested
<ScottK> Good to hear it's (at least not in the short term) another poulsbo.
 * NCommander grumbles, armhf/powerpc seems tohave dropped off my PPA
<ScottK> (which you could only ever run on one Ubuntu release)
<NCommander> ScottK: its been a bit of a pain TBH. d-i itself requires a command line option to run while everything is in proposed. There is a chance everything might work, and the moment it gets pocket copied to updates it will break
<NCommander> (I'm pretty sure it won't, but we've never built a new image on a point release before)
 * skaet back
<ScottK> The good news is that whatever it does, it's not a regression ....
<skaet> slangasek, Laney - email sent for the freeze.
<infinity> NCommander: Eh?  d-i requires no such thing.
<NCommander> infinity: ?
<infinity> NCommander: We do d-i in proposed all the time, how is that broken for you?
<NCommander> infinity: no, I'm not expecting it to break. However, because highbank's enablement bits are in proposed, we need to set apt-setup/proposed=true on the command line for testing
<skaet> slangasek,  will you be doing the debian-installer upload for the new kernel?
<infinity> Oh, sure.  Kay, I thought you meant something sketchier for building.
<infinity> skaet: I will.
<infinity> skaet: Once they all roll in.
<NCommander> I know d-i will pull udebs from updates, but a voice in the back of my head tells me to revalidate the instant highbank migrates to updates
<skaet> infinity,  what's still left to land?
<NCommander> infinity: when do you plan to upload d-i? I'm about to upload it to add highbank (I can depwaiton your patches)
<infinity> skaet: Two ARMs and a PowerPC.
 * skaet should have known.
<infinity> NCommander: Talking about quantal here.
<NCommander> oh
<infinity> NCommander: But I do need to commit a kernel ABI bump for precise-proposed too.  No reason those can't be in the same upload as your fiddling, however.
<NCommander> infinity: I committed my highbank d-i patches onto the proposed branch, and testbuilt on armhf/i386 and looks good, so if you just want to upload it tonight
<skaet> slangasek, infinity - I'm going to turn off the cron now, and point the next set of builds to start populating alpha 3 on the iso tracker.
 * skaet figures Laney's EODed by now...
<NCommander> infinity: if you plan on doing your ABI bump tonight, I'll leave it as is, else I rather upload ASAP as mahmoh and mreed need to testthis
<infinity> NCommander: I can do it tonight.  Gives me a chance to quickly review your bits too.
<NCommander> infinity: thanks
<skaet> cron for quantal disabled,   builds targetted to Quantal Alpha 3
<skaet> infinity, am looking at the changes made to the server rebuild, and its not synching up with what's in the crontab for server at the moment.  Do you know or cjwatson make the changes to the pad?
<skaet> (pad.ubuntu.com/ubuntu-release)
<infinity> skaet: They seem to reconcile fine for me, what's the issue?
<cjwatson> skaet: What infinity said.
<cjwatson> I made those changes.
<skaet> cjwatson,  seeing buildlive with for-project $p cron.daily  looked a bit odd
<cjwatson> It's correct, and it matches the crontab.
<cjwatson> It's not really a "live" build; we're using buildlive because it knows how to build squashfses, but it's just for the base system.
<cjwatson> The images still use d-i.
<skaet> thanks.  that makes a bit more sense.
<slangasek> skaet: cron> sounds good, thanks
#ubuntu-release 2012-07-24
* ChanServ changed the topic of #ubuntu-release to: Quantal Quetzal Alpha 3 prep | Archive: please upload to -proposed | Quantal Quetzal 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 birdseed | melior malum quod cognoscis
<slangasek> infinity: how far out is d-i looking?
<infinity> slangasek: Kernels are still several hours out, then promotion to -release, then d-i.
<infinity> slangasek: So, it's a "when I wander past my computer tonight" thing.
<slangasek> infinity: ok
<skaet> if it gets to be morning time for europe,  check if app-install-data-ubuntu is close to being published before kicking off the builds
<infinity> Perhaps I'll go find some dinner between now and then.
 * skaet thinking dinner might be a good idea for herself too...
<infinity> skaet: Are we expecting a new app-install-data-ubuntu sometime?
<skaet> infinity,  mvo kicked off the scripts for it earlier
<skaet> it should show up on the link in the pad,  when done.
<infinity> skaet: Well, when someone uploads it, yes. :P
<skaet> if its close to morning,  may be worth checking with mvo how close it actually is to publishing, and hold up for it.
<skaet> infinity,  was under the impression his script will do that,  but I could have misunderstood.
<infinity> skaet: If his script automates signing and uploading it, a few of us will likely tell him to stop that. :P
<infinity> skaet: But I'm pretty sure it just generates a source package that he still manually gives a once-over and uploads.
<stgraber> just what I was about to say ;)
<skaet> infinity,   ok.
<skaet> if he's online,  ask how close,  if not, go ahead and get some images started building
<skaet> or rather you, slangasek, myself, or who ever's still up when the d-i bits publish
<infinity> slangasek or Laney, according to the wiki.  I'm perfectly happy to pretend not to care about images this month. ;)
<infinity> (But I'll make sure the kernel and d-i are ready for those who are doing releasy things)
<phillw> i promise to book mark it... do you have the pad link for ubuntu-release ?
<skaet> infinity,  thanks.
<phillw> is okay.. found it :)
 * skaet just cleaned up some stale data on https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive 
<infinity> skaet: Tidied a bit more.
<skaet> hmm,   I was stimied a bit on armel since it is still an official arch for natty and oneiric, and would show up in the archive that way.    We may want to restructure this part a bit more for clarity about which archs are official for which releases, but what's there will do for now.    thanks.
<infinity> skaet: "show up in the archive that way", in what sense?
<infinity> skaet: The archive makes no distinction.
<infinity> skaet: And there's a list of which arches as they come in and out of officialness on that page, more or less.
<infinity> skaet: (Frankly, the only people who care if natty and oneiric were official on armel are paid customers, and they already know :P)
<micahg> skaet: FYI, https://wiki.ubuntu.com/SecurityTeam/FAQ#Architectures
<skaet> infinity,   lets just redirect that section to point to the link micahg points to.   That's much clearer.
<infinity> Except that the first line of that wiki section is also a lie. :)
<micahg> that's true :(
<infinity> It also says nothing about what's *currently* supported, which is probably more interesting.
<infinity> (please give me edgy security fixed for powerpc, thx)
<micahg> infinity: see footnote 1 :)
<infinity> Oh.  That's tiny.
<infinity> BOLD AND RED!
<micahg> I'll suggest it :)
<skaet> infinity,  by shows up in the archive,  I just meant it builds to armel not armhf for specific releases.  In past manifests we didn't separate between armel vs. armhf,  just used arm, so it may be confusing.  see:https://wiki.ubuntu.com/OneiricOcelot/ReleaseManifest
<micahg> skaet: yes, in precise: https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest
<micahg> ah, right no armel ther
<micahg> oh, yes there is :)
<skaet> micahg, actually there is armel in precise's
<infinity> skaet: Turns out that's a wiki and can be edited. ;)
<infinity> skaet: Anywhere where it matters from an archive perspective, armel is armel.
<skaet> infinity,  all the ones we're talking about are wiki's...   just a matter of finding them all,  and doing the edits to make them consistent.  ;)
<infinity> (And always was)
<skaet> and yes,  archive is the one place we can't change.  ;)
<infinity> And also the one place that's right?
<infinity> :P
<skaet> hmm...   definition of right seems to change with time.    when there was only arm variant,  calling it armel then may have been confusing.  :P
<ScottK> It depends on how much of the history you have.
<ScottK> There was a Debian arm port before armel.
<ScottK> (never in Ubuntu)
<ScottK> But given that history, calling armel arm was always wrong, IMO.
<skaet> Looks like the only two Release Manifests with it as arm rather than armel are Natty and Oneiric.
 * skaet figures may as well clean them up then.
<skaet> so there's consistency there.
<skaet> Natty & Oneiric Manifests are now consistent with the rest.    armel used in all.
<infinity> skaet: Yeah, it was never right to call it just "arm".
<skaet> infinity,  none of the folks doing line sign offs flagged it.  :P
<infinity> To be fair, they were mostly management.
<micahg> skaet: sorry, I seemed to have spaced on some needed Ubuntu Studio uploads, mind if I do them now?  (all smallish packages and mostly arch all)
<skaet> micahg,  we're still waiting for d-i so go ahead.     Hopefully they'll all be sorted by the time ubuntu studio starts to build.
<micahg> skaet: is that still 18:00 UTC?
<micahg> or will this be a manually triggered build?
<skaet> micahg, no,  we're off cron now,  manual triggered
 * micahg will try to get it sorted in the next hour as sleep is calling
<skaet> please log them on pad.ubuntu.com/ubuntu-release as opportunity targets if they don't go in, in next hour.
<micahg> ok
<micahg> ok, studio default settings upload, spinning up the -meta upload now
<micahg> ok, new Ubuntu Studio meta uploaded, I think that's it unless there are bugs found
<skaet> thanks micahg
<micahg> skaet: also, xubuntu is horribly oversized, don't know if I'll have an answer tonight though
<infinity> micahg: Drop the kernel, that'll solve it.
<micahg> heh
<micahg> ah, awesome, Qt got pulled in somehow
<infinity> ubuntuone?
<micahg> idk, looking
<infinity> Hrm, no, that only seems to be in Ubuntu.
<micahg> thunar-archive-plugin recommends ark
<infinity> That's a remarkably silly recommends.
<infinity> If you want to fix it, go nuts.  Still two more publisher cycles until d-i's ready.
<infinity> Or, rather, two more until I can upload it, 3 more until it's ready.
<micahg> it's an alternate recommends, that's easily clobbered...continuing to look
<skaet> infinity, looks like the kernel's finished building,     d-i upload?
<infinity> skaet: See above.
<micahg> ah, that's not it
<micahg> infinity: fglrx depends libqtcore4
<infinity> Hasn't it always done so?
<micahg> hrm, yes...
<skaet> slangasek,  still around?
<micahg> and that's not on the image
<infinity> I didn't realise Xubuntu shipped non-free drivers.
<infinity> Yeah, exactly. :P
<skaet> Laney,  if slangasek doesn't chime in before you get online,  looks like you'll get to build the first set.
 * skaet --> zzz
<micahg> ubuntu-sso-client-qt looks to be the real culprit, blacklisting
<infinity> micahg: How's it coming it?
<micahg> see above :)
<infinity> micahg: I don't see an above explaining where ubuntu-sso-client-qt is coming from. :)
<micahg> infinity: ubuntu-sso-client recommends ubuntu-sso-client-gui (qt is the only choice now)
<infinity> Ahh, erk.
<infinity> You should petition to resurrect the GTK one.
<micahg> hrm, I like Qt personally...
<micahg> how often are the germinate-output crons generated?
<micahg> s/generated/run/
<infinity> micahg: Not often, but nothing important uses that output.
<infinity> micahg: Or did you just want to see it, so you could be lazy and not run it locally? :)
<micahg> infinity: I just wanted to verify my work :)
<infinity> 2 */4 * * *             update-germinate
<infinity> I can force the issue.
<micahg> ok, so I can check in the morning
<micahg> nah, I should go to bed
<infinity> Yeah, speaking of.
<infinity> Publisher's going to run over by a couple of minutes. >:(
<infinity> I should just do my d-i upload on a sleep(1) delay and go do something else.
 * slangasek appears
<infinity> slangasek: Did you bring cookies?
<ScottK> micahg: They're dumping the Uone installer, so I think shipping the client-gui will be the only supported way.
<slangasek> infinity: no, but I'm chiming in, so <tinkle,tinkle>
<micahg> ScottK: well, IIRC, Xubuntu doesn't ship the U1 client anyways
 * slangasek blinks at two new linux flavors appearing in component-mismatches
<ScottK> OK.  Then I'm confused about what this issue was, but that's fine.  I don't need to understand it.
<ScottK> slangasek: We're not in final freeze, so they're early.
<infinity> slangasek: Hrm?  You mean the -5 stuff that's NBS?
<slangasek> ScottK: one of them's for the n900, so I'd argue it's 3 years late ;P
<ScottK> Well sure.
<infinity> Oh, the two heading to main.  Wow.
<ScottK> Maybe I'll have something to do with my n900 besides let it collect dust.
<slangasek> infinity: linux-n900, linux-qcm-msm; strangely being pulled in via open-iscsi-udeb, vlan-udeb - either a buggy dep declaration, or a c-m bug
<infinity> slangasek: That's probably just an oops from having no kernels seeded to main for a second.
<micahg> ScottK: Xubuntu ships software-center which needs oneconf which needs ubuntu-sso-client which recommends ubuntu-sso-client-gui of which there is only Qt now
<ScottK> I see, but it doesn't need a gui?
<infinity> slangasek: (In that I bumped the seeds for the mainline kernel to the new version before it was published)
<micahg> ScottK: no, it has the GTK gui in it apparently
<ScottK> I see.
<slangasek> infinity: ah
<infinity> NCommander: What was wrong with backporting the quantal highbank d-i support, instead ot rewriting it? :/
<infinity> Alright, d-i uploaded for both quantal and precise, that's EOD for me.
 * slangasek waves
<infinity> slangasek: If you feel like reviewing the precise-proposed d-i, that would be lovely.
<slangasek> ok
<infinity> slangasek: Or, you could wait until the quantal one builds successfully and appears to publish things to sane paths, since the precise one is the same code. :P
<slangasek> mmm, amd64+i386 d-i builds just failed with a "disk full" error generating the netboot images
<infinity> Oh, FFS.
<infinity> New firmware again? :/
<slangasek> no idea
<infinity> Yeahp, new firmware.
<infinity> Although, not a lot.
<infinity> Kernels might have grown too.
<slangasek> the fix for which is... to bump the fs size?
<infinity> I need to change the Makefile to give me the *^!% size of vmlinux and initrd after it trips over it.
<slangasek> are you fixing this up, or do you want me to?
<infinity> I can fix it.  Want to wait for the world to fail, first.
<slangasek> ok
<slangasek> Laney: fyi, looks like you get to kick off the builds from the pad then; I don't think I'll be around still when d-i catches up
<infinity> Actually, I might leave the d-i image size bump to someone else.  I need to try to not be awake at night tonight.
<slangasek> ok
<infinity> And it wasn't firmware growing, same version of firmware was used in the previous d-i builds.
<infinity> So, I guess the kernel grew just a bit.
<infinity> Or a lot.
<infinity> Or maybe everything's just been slowly growing by enough to finally hit the limit again.  Don't see any obvious explosions.
<infinity> Meh.
<infinity> Maybe I'll just fix it.
 * infinity wonders idly why the powerpc image appears to be growing in base10 units, and the x86 ones in base2...
<infinity> slangasek: Testing a fix here.
<slangasek> ok
<jibel> with the new format of server images, sources.list only contains cdrom entries. filing a bug
<infinity> slangasek: The good news is that the highbank stuff from the last build spit out the way I expected it to.
<infinity> slangasek: So, as soon as these amd64 and i386 local builds complete, I'll commit, upload, and go away. :)
<slangasek> infinity: sounds like a plan then :)
<infinity> (uploaded and building)
<Laney> howdy
<Laney> we building all flavours for a3?
<jibel> bug 1028301 with server 20120723.2
<ubot2> Launchpad bug 1028301 in debian-installer "Quantal Ubuntu Server - sources.list only contains cdrom entries after a preseeded installation" [Undecided,New] https://launchpad.net/bugs/1028301
<pitti> hello
<pitti> I fixed bug 1026066, I think that ought to go into alpha-3
<ubot2> Launchpad bug 1026066 in aptdaemon "software-properties-gtk crashed with ImportError in /usr/lib/python3/dist-packages/aptdaemon/client.py: No module named gobject" [Critical,Fix released] https://launchpad.net/bugs/1026066
<pitti> it breaks update-manager, software-properties, and presumably lots of other stuff
<Laney> agreed
<jibel> added to the pad. does it affect kubuntu ?
<Riddell> hmm I don't know
<Riddell> but since we have no candidate images yet then may as well wait for that
<cjwatson> Why is bug 1026964 listed as a rebuild trigger?  It's a suspend/resume bug, importance medium, not tagged rls-q-anything.  I don't see why we'd care particularly about it for image builds?
<ubot2> Launchpad bug 1026964 in linux "Lenovo T410s laptop suspends fine, won't resume any more" [Medium,Triaged] https://launchpad.net/bugs/1026964
<jibel> could be a confusion with bug 1027828 which was fixed in kernel 3.5.0-6.6
<ubot2> Launchpad bug 1027828 in linux "[Quantal] black screen on resume on 3.5.0-5.5 (regression from 3.5.0-4.4)" [High,Fix released] https://launchpad.net/bugs/1027828
<cjwatson> Seems more plausible.  I've changed the pad.
<jibel> I added a comment to the report
<ogra_> Laney, is there any reason you dropped all the arm precise preinstalled lines from default-arches ? you have to explicitly call a preinstalled build anyway so nothing would attempt to build them unless you say so
<ogra_> (having the entry helps to keep track what arches were built when, even though nothing uses this entry)
<Laney> ogra_: I was advised to do so by slangasek.
<ogra_> hmm, k
 * ogra_ doesnt get why though, its just historical data and doesnt do any harm
 * cjwatson fixes ubuntu-server/precise
<ogra_> cjwatson, is server completely switched to squashfs now ?
<cjwatson> ogra_: ubuntu-server/daily is
<ogra_> ok
<cjwatson> ogra_: just for the base system though
<ogra_> so we are depending on the live builder with it ... thats what i wanted to know
<cjwatson> no plans to go beyond that in quantal
<ogra_> (bottlenecks etc :) )
<cjwatson> it's best looked at as a cached debootstrap (although it actually has the server seed in there too)
<cjwatson> Any objection to me rebuilding world after the next publisher run completes (which will be in ~1hr since we're in the fastdowntime window)?  I believe all the rebuild triggers are at worst pending publication.
<jibel> +1 to rebuild the world
<ogra_> as long as you keep the weather do what you want with the world :)
<Daviey> cjwatson: rebuild would be good
<cjwatson> rebuilding
<cjwatson> Hah, the health checks are really pretty confused by squashfs-base.
<cjwatson> I may have to turn the installability check off for server unless I can think of something clever.
<cjwatson> Which I suppose isn't totally out of the question; maybe I can bodge something using the manifest ...
<ogra_> hmm, apt-setup failures on omap4 server
<ogra_> cjwatson, is there any way to convince live-installer to not call update-initramfs ?
<cjwatson> ogra_: are we talking performance or what?
<ogra_> it calls it before flash-kernel-installer is done (which runs apt-install u-boot-tools)
<ogra_> so it fails missing the mkimage command
<cjwatson> it's in the console-setup hook, I think, but let me check
<ogra_> i cant find a debconf key for supressing update-initramfs in live-installer :/
<cjwatson> it'll need (a) me to think about it (b) code changes
<cjwatson> hang on a bit :)
<ogra_> need a log ?
<ogra_> its slightly confusing that the actual failure shown is in apt-setup ... which fails since in-target didnt return properly
<cjwatson> wouldn't hurt but I was just doing a test install here, so if it's >0 effort don't worry about it
<ogra_> http://paste.ubuntu.com/1108095/
<ogra_> logger thinks its from live-installer
<cjwatson> right, yeah, the c-s hook
<ogra_> Jul 24 12:09:08 base-installer: warning: /usr/lib/post-base-installer.d/25live-installer-console-setup returned error code 1
<ogra_> yep
<cjwatson> surprised you didn't have the same problem with trad base-installer though
<cjwatson> you know, you could fix this in f-
<cjwatson> k
<cjwatson> if you wanted
<ogra_> how, i cant hard depend on u-boot-tools
<cjwatson> just have it do the apt-install earlier, say in a base-installer hook
<ogra_> sicne f-k deals with lots of other bootloaders too
<cjwatson> would involve splitting it up a bit
<cjwatson> it'd need some care with where you move flash-kernel out of the way
<ogra_> how about calling flash-kernel-installer as part of live-installer ?
<cjwatson> how about not :-P
<cjwatson> (I would very much rather live-installer not have to know about f-k)
<ogra_> why not? we need the bootloader setup anyway
<cjwatson> layering
<ogra_> so we could as well do it early
<ogra_> hmm, k
<cjwatson> the hooks are available so it's not necessary, anyway
<cjwatson> I mean, if you want flash-kernel-installer to run as a live-installer hook, be my guest, but you're still going to need to leave flash-kernel-installer.postinst in place and figure out a way for it to notice that it's already been called
<ogra_> well, calling it twice wouldnt do any harm
<cjwatson> I just don't think we should change live-installer for it
<ogra_> apart from wasting time
<cjwatson> there's /usr/lib/live-installer.d/ though
 * ogra_ was pondering about post-base-installer.d/20live-installer-flash-kernel
<cjwatson> live-installer.d is better, I think - this flow is specific to live-installer so better to use a hook that's also specific to live-installere
<cjwatson> *live-installer
<ogra_> ok
<cjwatson> let me just check where direct apt-install is enabled
<ogra_> hmm, but live-installer.d has no ordering
<cjwatson> never mind that, bigger problem
<ogra_> how do i make sure f-k is done before update-initramfs
<ogra_> oh ok
<cjwatson> never mind that
<cjwatson> apt-install only queues until install_extra is run
<cjwatson> which isn't until after post-base-installer.d hooks are run
<cjwatson> so this approach is a non-starter whatever way you slice it
<ogra_> :(
<ogra_> yeah
 * ogra_ wonders if there is a way to just solve it thgrough seeding ... but i guess that would mean all arm images end up with u-boot-tools again
<ogra_> *through
<cjwatson> I think I have a better idea
<cjwatson> just fleshing out the details
<ogra_> k
<cjwatson> add a post-base-installer.d hook with an early number (say 01) that dpkg-diverts update-initramfs and installs a symlink to /bin/true in its place
<cjwatson> (put that in the flash-kernel-installer udeb)
<cjwatson> then undo the diversion in flash-kernel-installer.postinst, just before you call update-initramfs
<cjwatson> actually probably before the apt-install calls so that the nslu2-utils case mentioned there still works (although I realise that doesn't matter for Ubuntu)
<cjwatson> that means we don't have to play whack-a-mole with anything that might indirectly call update-initramfs
<ogra_> ok, doesnt that also need a dep to live-installer in flash-kernel-installer ?
<cjwatson> I don't see why - it would work just as well with the other style of base system installation
<ogra_> ah, well, if it isnt there the file will be a no-op
<ogra_> yeah, thinko :)
<cjwatson> it would probably speed things up a bit
<cjwatson> which I assume you don't mind
<ogra_> its very fasdt already :) but yeah, i dont :)
<ogra_> *fats
<ogra_> bah
<cjwatson> so I think that's all doable entirely within flash-kernel - are you OK with fleshing out the details of that?
<ogra_> yes, just looking for the place the file has to go
<cjwatson> be a bit careful about interaction with ubiquity, I guess
<cjwatson> since that calls flash-kernel-installer and probably won't have done the diversion, unless you take steps for it to do so
<ogra_> ubiquity ?
<ogra_> yes, also normal d-i alternates wouldnt use it
<cjwatson> they would if you used a post-base-installer hook
<cjwatson> so you'd have to either arrange to do the same diversion in ubiquity, or else have flash-kernel-installer.postinst not mind if the diversion isn't there
<ogra_> f-k-i will have to check if the diversion exists first in any case
<cjwatson> the latter's probably a good idea in any case
<cjwatson> yeah
<cjwatson> just check for the existence of the diverted file, probably easiest
<ogra_> if it doesnt it wont try to revert it ...
<ogra_> right
<ogra_> grr, one day we should make update-noifier check for the arch of a device so it doesnt always offer me to upgrade from my armhf images on my x86 desktop
 * ogra_ just noticed the 50 or so popup messages behind his terminal window
<stgraber> ogra_: what's wrong with that, if you have qemu-user-static installed, you can totally upgrade from your armhf images ;)
<ogra_> stgraber, right, and that works very well, i once did that in the middle of a customer call
<ogra_> at the end of the call, when i rebooted my machine i noticed what had happened since it didnt boot anymore :)
<stgraber> hehe :)
<stgraber> yeah, in my experience you at least need a few important amd64 packages for it to work (upstart, libnih, mountall, iputils, isc-dhcp)
<stgraber> as qemu-user-static doesn't like ptrace or netlink
<stgraber> (and on a physical machine, you'd probably need binfmt in the initrd with the rest of the initrd being amd64)
<ogra_> cjwatson, http://paste.ubuntu.com/1108165/ does that look ok ?
<ogra_> oh, the ${ROOT} is definitely wrong
<cjwatson> ogra_: some over-indentation, I'd spell out "flash-kernel-diverted" in full, 'set -e' in the post-base-installer hook, and please make the source file for the hook be "post-base-installer.d/01live-installer-flash-kernel-diversion" rather than under live-installer/
<ogra_> ok
<cjwatson> and actually drop "live-installer-" from that - this isn't live-installer specific
<cjwatson> do you need --local on the undivert too?  I forget
<cjwatson> might be best to match there
<ogra_> i just stole the code from livecd.sh :)
<ogra_> there it worked like this
<cjwatson> mm, maybe dpkg-divert was lax, I think maybe best not to rely on it always being so though
<cjwatson> the docs say "When adding, default is --local and --divert original.distrib. When removing, --package or --local and --divert must match if specified."
<cjwatson> which implies to me that if you add with --local then you must remove with --local too
<ogra_> k
<skaet> good morning
<ogra_> cjwatson, http://paste.ubuntu.com/1108178/
 * ogra_ thinks that will fly 
 * ogra_ dputs
<Laney> hmm
<Laney> I have a work item to fix unseeded universe final freeze, but I forgot what we said
<Laney> can anyone remember?
<ogra_> skaet, i always lose the pad url (used to be in the channel topic) ... could you add a rebuild note for armhf omap4 once flash-kernel 3.0~rc.4ubuntu11 has built
<ogra_> ?
<Laney> was it that we asked people to use proposed after that point?
<ogra_> skaet, omap4 server that is
<skaet> Laney, cjwaton - In looking at the pad and tracker,  trying to figure out if the latest published set of images has the app-install-data-update or only some of them (am guessing its a some of them since a-i-d-u only published 2 hours ago)
<skaet> ogra_,  doing
<Laney> some, the rest are still churning through
<ogra_> skaet, "<cjwatson> Any objection to me rebuilding world after the next publisher run completes (which will be in ~1hr since we're in the fastdowntime window)?  I believe all the rebuild triggers are at worst pending publication."
<skaet> Laney do we know which of the built ones don't have it.
<ogra_> skaet, that was 3h ago, based on it i would a ssume a complete rebuild of everything
<skaet> ogra_,  since it published 2 hours ago,   I think it was overlooked in the full trigger
<skaet> s/it/a-i-d-u/
<skaet> so,  some have it, some don't.
<skaet> ogra_, http://pad.ubuntu.com/ubuntu-release  :)   have added your flash-kernel already,  and I'll put the link in the topic next.
<Laney> looks like the desktop images do have it
* ChanServ changed the topic of #ubuntu-release to: Quantal Quetzal Alpha 3 prep: http://pad.ubuntu.com/ubuntu-release | Archive: please upload to -proposed | Quantal Quetzal 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 birdseed | melior malum quod cognoscis
<skaet> thanks Laney.
<ogra_> skaet, thx !
<Laney> where are the logs on the server?
<ogra_> which server ?
<ogra_> nusakan ?
<Laney> ye
<ogra_>  /srv/cdimage.ubuntu.com/logs/
<Laney> ah yeah found
<ogra_> though if you need a live-build log that lives on the respective live builder machines
<ogra_> w3m celbalrai.buildd/~buildd/LiveCD ... on nusakan would give you http access to the armhf build logs
<Laney> oh, they are mirrored separately?
<ogra_> yep
<ogra_> they are created on different machines
<Laney> thought nusakan might fetch them back
<ogra_> iirc they are mirroed to the same place but with a delay
<Laney> was just going to grep for the version of app-install-data-ubuntu they got
<ogra_> http://people.canonical.com/~ubuntu-archive/ then gets them last
<ogra_> just look at the manifest and list files in the image dirs on cdimage
<skaet> ogra_,  re: dropping arm images from precise daily builds - because they're not denoted as LTS, so keeping them automatically building with the precise dailies as we ramp up to 12.04.1 wasn't needed.
<ogra_> (manifest for live, list for alternate)
<ogra_> skaet, nothing buiolds preinstalled automated :)
<skaet> Laney,  other way is to just grep the manifests of the built images for the right version.
<Laney> yeh
<ogra_> (at least for precise)
<skaet> ogra_ we're turning on the automated builds for all of the LTS participants from now until 12.04.1 FF,  which was motivation for making sure it reflected manifest.
<ogra_> skaet, right, but nothing executes daily-preinstalled in crontab for precise
<ogra_> so default-arches isnt relevant
<ogra_> anyway, its gone now, just dont blame me if in two years nobody can anser which images we built in 12.04 :)
<Laney> that's why we have vcs history
<skaet> ogra_,   fair enough.
<ogra_> Laney, heh
<Laney> you could tag it when we do a release
<ogra_> Laney, well, up to now we never touched default-arches for past releases, thats new with 12.04
<ogra_> (to make sure everything works the same as it did on release day)
<ogra_> (in case you want to do a rebuild, which never ever happened for arm)
<skaet> Laney,  tagging when doing a release is a good idea, esp now that there's new hardware being added after the release.
<Laney> I suppose using it would be difficult though, because you'd have to have either the old changes or the current
<ogra_> that might gert tricky to coordinate since the cdimage code isnt bound to ubuntu releases
<ogra_> *snap* :)
<skaet> date of change should have the info, but tagging would make it a bit easier.    yes,  being able to recreate exactly what worked on release day  is a goal we need to accomplish as well.
<ogra_> the current setup does that very well
<ogra_> all scripts that touch any release specific bits are also in release specifc subdirs in debian-cd
<skaet> ogra_ has we ever had to try it out in ernest?   ie.  was there ever a case a full recreate was executed?
<ogra_> no, but there were rebiulds for certain oem images before they switched to OBS
<ogra_> and mibile images too ... many of tehse wer built out of sync with the release schedule for older releases
<ogra_> *mobile
<ogra_> sigh, my typing starts to annoy me today
<ogra_> so for picked images that always worked ... as well as for point releases of earlier LTSes
<jibel_> wubi is missing from the tracker is it building ?
<skaet> ogra_,  heh,  its the trackpad on this machine that keeps on flipping my cursor where I don't want it to be.   Thanks for the explanation.   Was curious.
<ogra_> colin can surely give more details if needed, he designed the system with the rebuiolds in mind from the beginning
<Laney> jibel_: yeah, crunching through
<jibel_> ack
<skaet> jibel,   builders are still going,  and WUBI's last (see pad for order builds were kicked off in)
<Laney> https://wiki.ubuntu.com/FinalFreeze check what I wrote at the end there.
<Laney> separate UUFF goes away and becomes this.
<skaet> Laney,  looks good to me.   Post to ubuntu-release maillist,  with a pointer to the update, and if no issues raised by end of week,   consider it done.
<micahg> chrisccoulson: you realize that we're in alpha3 freeze, right?
<seb128> micahg, no need to crosspost that accross channels
<seb128> kenvandine, chrisccoulson: please upload to quantal-proposed during a3 time ;-)
<micahg> seb128: cross post?  sorry, I must have missed something :)
<chrisccoulson> heh, oops ;)
<seb128> micahg, doh, my IRC client played me tricks, I though that was #ubuntu-desktop
<seb128> micahg, sorry about that
<kenvandine> seb128, whoops...
<ScottK> Laney: What does the archive is frozen mean in the context of your wiki update?
<Laney> that was preexisting, but it means frozen in the launchpad sense
<ScottK> So what's the term for when we're in the "only accept things that cause babies to catch fire no matter what part of the archive it's in." state?
<ScottK> I think terminology is a significant part of why people get confused about this stuff.
<Laney> "Deadline"? :-)
<Laney> you could add a sentence abou tthat
<tumbleweed> well, the nice thing about proposed, is if you're uploading there, there isn't such a state
<Laney> it only says "consider"
<tumbleweed> if the uploads don't get to -release, they'll go to -updates
<tumbleweed> (assuming they're SRU worthy, but at that point, they should all be, right?)
<Laney> not really
<Laney> add something about how on release day all uploads must go to proposed, and if they are not SRU worthy and are too big then they may be rejected
<tumbleweed> requiring all uploads in the last 1.5 days to be SRU worthy seems reasonable to me
<Laney> that's what we had before
<tumbleweed> am I taking us around in circles? damn
<Laney> we're trying to get as many fixes as possible in
<Laney> so we should just say that the closer we get to release, the less chance your upload has of getting in
<tumbleweed> that's fairly clear, you should say it something like that
<micahg> infinity: seb128: we missed the recommends on libwebkitgtk-3.0-0 :(
 * micahg was wondering why c-m was still exploded with gstreamer goodness
<Laney> ScottK: tumbleweed: try that
<micahg> or badness in this case :)
<ScottK> Laney: Rather than say final freeze is final for unseeded universe, I think it would be clearer to say that even though the archive as a whole is frozen, final freeze doesn't start for unseeded universe until X.
<Laney> I'm trying to say that we don't have a final freeze here
<Laney> just keep uploading your stuff and use proposed so that it can become an SRU if you miss the release and your bugs are good enough
<skaet> ogra_ what's the bug number for the flash-kernel fix?
<ogra_> skaet, no bug, we immediately worked out the fix when it showed up
<skaet> ogra_,  ack.    thanks
<ogra_> it is fgallout of the squashfs change
<ogra_> *fallout
<tumbleweed> Laney: it works for me. i was going to say that it could be clearer that fixes are still welcomed. But if one reads to the end of the paragraaph, I think it is
<Laney> feel free to reword if you can improve it :-)
<skaet> Laney,  what time did you kick off the first build of everything?   (or did cjwatson do it?)
<Laney> he did a second round
<Laney> about 0800UTC
<skaet> thanks
<micahg> skaet: so,  libwebkitgtk-3.0-0 is recommending universe codecs ATM which might balloon any images with universe enabled, but since this is only an alpha release and size isn't really a blocker, and webkit take 1.15 days on armel, I think maybe it should just be release noted?
<Laney> upload it to proposed?
<micahg> yeah, was thinking to do that
<micahg> meh, was hoping not to be TIL for webkit, but whatever
<Laney> so we get it if we can, otherwise: release note
<micahg> do we need a tracking bug?
<ScottK> Laney: There is a difference though.  For a final freeze upload, you don't need test cases, etc.  Once it is an SRU, different rules apply, so it's not as simple as keep uploading.
<skaet> micahg,  yes.  tracking bug and  Release Note is appropriate.
<skaet> micahg,  go ahead and add the note to https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview/Alpha3,  we can delete if it ends up going in easily enough.
<Laney> "Hey, these images contain loads of cool stuff!"
<micahg> heh, right :)
<Laney> ScottK: Indeed, people may have to come back and do more work. Although I think zero-day SRUs are a bit more lax?
<stgraber> skaet: in case you aren't reading #ubuntu-testing, dhcpd currently fails to start on quantal, at least with LTSP, but very likely in any scenario. So far it looks like it's a potential apparmor/kernel regression. I'm trying to get someone from #security to look at it.
<tumbleweed> Laney: it's more than coming back to do more work
<tumbleweed> you need a tracking bug in the upload
<tumbleweed> and yes, zero-day SRUs could probably use better documentation
<Laney> true
<micahg> a 3 hour test build for a
<micahg> * a 3 hour test build for a control file change is fun, right?
<Laney> does it parallelise?
<micahg> no, I think that's broken ATM
<Laney> oh, woe
<Laney> was going to give it to The Cloud
<micahg> I think I have a WI somewhere for that
<skaet> Laney,   did you manage to figure out which of the images are going to need to be respun to pick up the right version of a-i-d-u?
<Laney> all will be fine
<Laney> colin's rebuilds were after it got published
<skaet> Laney,  :)  happiness indeed
<skaet> Laney,  can you take a look at http://pad.ubuntu.com/ubuntu-release,  and confirm I've got the history section accurate now,  as well as the status of the current images building/needing to rebuild?
<skaet> (history section is after the current set of images)
<ogra_> the new flash-kernel is done btw armhf server daily can be rebuild
<micahg> skaet: wiki update for webkit issue, pad updated, test build in progress, est ~2hrs until it's done
<Laney> skaet: yeah, lgtm
<Laney> what's the page that lists the bugs we're tracking?
<skaet> Laney,    http://iso.qa.ubuntu.com/qatracker/reports/defects  under Quantal Alpha 3 shows summary of what's been found so far,  once a bug is logged.
<Laney> I meant the rls-q-incoming and nominated ones
<skaet> ahh...
<skaet> http://reports.qa.ubuntu.com/reports/rls-mgr/rls-q-incoming-bug-tasks.html
<Laney> aha
<Laney> ta
<skaet> but folks aren't all adding the tag yet,  so iso tracker is good to cross check against.
 * skaet added a couple this morning already
<Laney> sure
<Laney> ogra_: so teach me, what's the right invocation to do your respin?
<ogra_> well, depends, do you onyl want to rebuilds armhf+omap4 ?
<slangasek> ogra_, Laney: yes, the fact that *all* the precise preinstalled lines were being removed escaped me; it would've been more straightforward to just make sure they weren't in the crontab
<ogra_> *sigh* my typing
<ogra_> slangasek, thats what i meant :)
<Laney> ah well
<Laney> ogra_: let's say yes for now
<Laney> I assume there's an env var you set
<ogra_> Laney, omap4 only: ARCHES="armhf+omap4" buildlive ubuntu-server daily && ARCHES="armhf+omap4" for-project ubuntu-server cron.daily
<Laney> aaaaaaaaaha
<ogra_> essentially just grab whats in crontab for a specific flavour and use ARCHES=
<ogra_> (mind you, thats usually two commands in succession so you need to set it twice)
 * skaet nods
<Laney> ok, doing
 * apw has noted that linux-lowlatency is lagging the main kernel.  i would like to update it.  i am unsure if you care to have it in A3, so i was proposing to upload it to quantal-proposed and you can either promote it before or after the freeze lifts.  is that reasonable?
<Riddell> ooh kubuntu images
<skaet> apw,  seems reasonable.
<skaet> apw,  please note it on the pad as opportunity target,  with the links so we can track.
<jibel> skaet, alternate fails to install on Mac, there is a loop on detection of USB devices. Connect/Disconnect ... forever
<jibel> skaet, I'll confirm with another hardware
<jibel> mac mini that is
<skaet> jibel,  thanks for flagging.   post bug number when you're got it.
<infinity> micahg: I thought seb uploaded for that?  Or did he miss a bit?
<micahg> infinity: missed a bit
<infinity> micahg: Poop.
<micahg> infinity: I've got a test build going and will upload to -proposed when it's done
<infinity> micahg: Hah, I was just about to suggest I bounce something to proposed, but it's all you.
<micahg> gives my machine something to do while I'm testing webkit in precise
<ogra_> no need to put any arm netboot images on the tracker, they are all broken
<ogra_> (they will need a complete overhaul for the new flash-kernel and i didnt get to them yet (next on my TODO))
<skaet> ogra_ ack.   have put a note on the pad,  and marked them for rebuild on the iso tracker.   add details/bug numbers to the pad as you get them.
<stgraber> hmm, something's wrong with the bot...
<stgraber> the disabled entries are good, but the updated ones shouldn't have shown
 * ogra_ hugs his ac100 images ... 
<ogra_> the only arm images that work ootb this time :)
<infinity> ogra_: A "complete overhaul"?
<infinity> ogra_: Did f-k not provide a sane interface on upgrade here?
<ogra_> infinity, well, f-k and upgrades are another bug i have to catch (thanks to you :P )
<ogra_> infinity, its the fact that there are no partitions on the MMC in netinst ... so f-k doesnt knwo what to do
<stgraber> skaet: looks like apparmor not logging is some kernel weirdness on my machine, the actual failure can be fixed in isc-dhcp. I'll upload a fix to -proposed in a few minutes
<infinity> ogra_: I didn't literally mean upgrades, I just meant that f-k and f-k-i should still be presenting a similar interface, so changing d-i shouldn't be required, right, just fixing f-k?
<infinity> ogra_: My netboot images all have partitions...
<ogra_> infinity, in the img file ?
<ogra_> would be intresting how you got these since d-i doesnt have any dep on any partitionintg tool :)
<infinity> Oh, maybe the d-i images don't.  My PXE images do.
<infinity> That's not "a complete overhaul", though, it's a question of a simple tweak.
<ogra_> well, i have to wrap a partiton table and a partition around them
<ogra_> and an mbr
<infinity> Yeah, cargo-cult debian-cd, that's what I did for PXE. ;)
<infinity> Better yet, now that I understand this problem, bug me about it in ~1 week, and I'll JFDI.
<ogra_> and given that we have never found a way to make omap systems recognize parted created partitions for booting (CHS binding) it will be an intresting effort
<ogra_> since i assume colin wont allow me to make d-i build-dep on fdisk or sfdisk :)
<ogra_> alternatively we could hack up parted to actually force creation of the mbr and first partition during install but thats even harder to achieve
<ogra_> (beyond parted in d-i really really scaring me)
<infinity> ogra_: Erm, it doesn't need to build-dep on them, they're essential.
<ogra_> oh !
<infinity> And I'm sure some images already use either one or both.
<ogra_> that should make it a bit easier
<ogra_> since i can just copy the logic from debian-cd then
<jibel_> bug 1028526 breaks ltsp, not sure of the importance for server
<ubot2> Launchpad bug 1028526 in isc-dhcp "dhcpd failed to start with apparmor denied: capname="dac_override"" [Undecided,New] https://launchpad.net/bugs/1028526
<jibel_> skaet, stgraber ^
<micahg> Riddell: is there supposed to be a Kubuntu DVD listed on the pad?
<Riddell> micahg: no it's gone
<apw> skaet, ok the builds are in progress and its on the tracker thingy [12]
<micahg> Riddell: ah, ok, it's still showing up in seeded-in-ubuntu (and the seeds still exist), but no worries
<stgraber> skaet, jibel_: jdstrand is preparing an upload now, we'll need to respin any image containing isc-dhcp-server
<balloons> fyi, hggdh noticed the download links are wrong for ubuntu server armhf+ompa4: http://iso.qa.ubuntu.com/qatracker/milestones/226/builds/19353/downloads
<balloons> I'm going to change to correct now
<balloons> precise should keep the -preinstalled, but quantal should move to the daily
<balloons> agreed?
<stgraber> sounds right
<ogra_> balloons, preinstalled is completely dead in quantal, yeah
<ogra_> apart from ac100
<ogra_> all arm images you care about are now identical to their x86 pendant
<balloons> yes -- we need to review all the download links for them to make sure they are pointing properly to the right images
<balloons> I'll do that
<ogra_> balloons, also note that there wont be rebuilds of preinstalled precise ...
<balloons> just wanted to make everyone aware before I dove in :-)
<ogra_> so not sure you need to keep them on the tracker at all
<balloons> ogra_, just historical purposes.. we want the old links to be correct
<ogra_> k
<stgraber> balloons: you might actually want to use "SERIES" as a placeholder in the links and not make the links series-specific, so we don't need to update them all for quantal+1
<balloons> stgraber, I'm noticing all the md5sums appear to be broken as well
<balloons> yikes yikes
<balloons> ok, just on those images.. ;-)
<ogra_> indeed they are
<ogra_> they will likely match with the broken dl paths though :)
<ogra_> lol, funny that ubiquity just informs me that the UX team is hiring ...
<balloons> stgraber, on the SERIES thing.. it seems like we don't have them linked on cdimage to allow that
<balloons> stgraber, notice there is no quantal (http://cdimage.ubuntu.com/ubuntu-server/)
<jdstrand> skaet: should this (isc-dhcp) use quantal-proposed or quantal?
<stgraber> balloons: only point releases show up as /SERIES/SERIES-<media type>-<version>.iso, so for all products at this point we should have two entries
<skaet> jdstrand,  quantal directly.
<skaet> we'll be doing a respin for it.
<stgraber> balloons: PRECISE with /ubuntu-server/SERIES/VERSION/SERIES-<media type>-<arch>.iso
<stgraber> balloons: and a generic entry with /ubuntu-server/VERSION/SERIES-<media type>-<arch>.iso
<balloons> stgraber, yes, but that will fail for quantal
<stgraber> balloons: no
<balloons> ubuntu-server/quantal is a 404
<stgraber> balloons: read again ;) you only use /SERIES/ for POINT-RELEASES
<balloons> stgraber, lol :-) I'm multitasking here.. Let's plan to review the links as post-alpha3 follow-up
<balloons> I'll add it to the agenda
<balloons> I see some download links are missing rsync's, etc
<balloons> we should clean all of them up and do best practice (aka, use series), etc
<balloons> and stgraber yes, I agree on making them as static as possible :-)
<stgraber> For Ubuntu server amd64, you'd have two entries:
<stgraber> series == precise: http://cdimage.ubuntu.com/ubuntu-server/SERIES/daily/VERSION/SERIES-server-amd64+mac.iso
<stgraber> series == NULL: http://cdimage.ubuntu.com/ubuntu-server/daily/VERSION/SERIES-server-amd64+mac.iso
<stgraber> with these two entries, we should be good until 14.04.1 where we'll have to add an entry with /SERIES/ for that series
<jdstrand> skaet: ack
<jdstrand> it'll be soon, I'm building locally and will test/upload
<Laney> doesn't 9 affect pretty much everything?
<stgraber> Laney: if you want isc-dhcp (all binaries) to be on the same version everywhere, yes. If you're just interested in the fix, no.
<stgraber> isc-dhcp-client and isc-dhcp-common are indeed on pretty much all images, though the fix will just change the init script of isc-dhcp-server, that's only seeded on server, alternate and edubuntu IIRC
<Laney> climbing time. back in ~3h
 * ogra_ wonders whgat the heck pulls redboot-tools into the omap images 
 * skaet --> lunch,  biab
<stgraber> same here, biab
<micahg> skaet: is there a reason xubuntu was left out of the rebuild commands for desktop and alternater images?
<ogra_> infinity, were you planning to do some mx5 tests ? else we should probably drop them from the tracker if no testers are around
<infinity> ogra_: I hadn't planned to do any.  I'd rather drop the image and build a netboot, to be honest. :P
<ogra_> lets do that then
<ogra_> i would have tested if i had the HW
<ogra_> but i dont and there is no community
<ogra_> (and i think we should rather keep the currently rare builder cycles for omap3 than for mx5)
 * ogra_ goes out to mow the lawn
<infinity> Grr.  Who feels good about a new d-i upload? :P
<micahg> infinity: aren't we already rebuilding the world for isc-dhcp?
<infinity> micahg: Ahh, I haven't been keeping up with the channel.
<micahg> infinity: maybe not, not sure what the call on that was
<micahg> and I don't see it on the pad except for Ubuntu Studio
<micahg> oops
<infinity> Well, the current d-i named the highbank initrd incorrectly.  Other than that, it's a no-change for other arches.
<micahg> nevermind, it's on there
<micahg> infinity: so, no plans to rebuild the world ATM :)
<infinity> Well, it doesn't throw things out of sync.  Maybe I'll just upload anyway, and if there's a rebuild later, it'll get picked up.
 * infinity does that.
<micahg> infinity: local webkit build still not done yet :(
<infinity> micahg: If it's just changing debian/control, is a test build really necessary?
<micahg> infinity: well, there's a new gobject-introspection, it really depends on if anything related in the archive has changed since the last upload I guess
 * skaet back
<skaet> micahg,  its an oversite,   just checked and  isc-dhcp-server is in the .list for the alternate.  Have added to the pad for rebuilds
 * micahg wants to cry, his 3 hour webkit test build failed due to lack of space :(
<skaet> micahg,  you're right, xubuntu wasn't in the rebuild scripts.   I've added it now.
<micahg> thanks
<skaet> Laney,  slangasek ^  does it make sense to do the builds for xubuntu desktop now?   for xubuntu alternates,  I think we should wait until the isc-dhcp-server fix lands, since its close.
<stgraber> skaet: according to rmadison isc-dhcp-server is built and published on everything but armel
<micahg> ok, let's go for a set then
<skaet> thanks stgraber.
<skaet> stgraber,   we've still got edubuntu dvd,  ubuntu studio, and wubi building to get through on the desktop,  but  we should be able to get the alternate and server build (except arm ones).
<infinity> skaet: We don't build armel images, no need for the "except arm" there.
<skaet> infinity,  d'uh.  good point.
<skaet> infinity,  is there anything else about to land for the arm images?
<infinity> Nothing ARM-specific.
<infinity> Can't speak to the work others have been doing today.
<skaet> Laney, slangasek - I've started a rebuild of the alternates for ubuntu, xubuntu and lubuntu to pick up the isc-dhcp-server fix.
<skaet> ogra_,  is there an ETA on when you'll be finished the reworking for the new flash kernel?
<jibel_> is hope to see wubi today definitely lost ?
<skaet> jibel_ no,  its just backed up behind edubuntu and ubuntu studio dvds
<skaet> edubuntu dvd is building now.
 * skaet thinks we should probably rearrange the order on the pad....
<jibel_> ok, good night then o/
 * highvoltage peeks in
<stgraber> skaet, Laney: did you use ARCHES= for edubuntu? we're not releasing omap4 for alpha3, so if you want to save a couple of hours, just override ARCHES to "amd64 i386"
<skaet> stgraber,  Laney kicked it off,  but I suspect not.
<skaet> micahg, ^ Xubuntu alternates available to try now.
<skaet> Laney, slangasek have updated the pad to make it explicit that any further rebuilds of Edubuntu are only for i386 and amd64.
<skaet> ok,  we've gotten the last of the build lives out,  next up,  Xubuntu Desktop,  then a rebuild of Ubuntu Sever
<skaet> Server even.
<shadeslayer> uhm, why does Ubuntu Server have a mac image
<shadeslayer> seems a bit pointless imo
<skaet> Daviey, ^
<shadeslayer> ( fwiw I don't see the point of mac images atm because afaik they don't do anything special and cannot be booted from USB drives )
<stgraber> amd64+mac is supposed to contain the required tricks to allow booting from Mac EFI, the standard amd64 image doesn't boot
<shadeslayer> stgraber: it does :)
<stgraber> on a clean mac without refit or any other efi tricks?
<shadeslayer> yes
<shadeslayer> I've done it before
<shadeslayer> you burn a CD/DVD , hold down the 'C' key
<shadeslayer> and it boots the CD
<shadeslayer> after installing, you hold down the option key to choose which OS to boot
<shadeslayer> here's the fun part, Fedora managed to get proper EFI boot working
<stgraber> we'd need cjwatson for the details, but in theory, the state of things on most Macs is that i386 will boot fine (holding c, then install), amd64 might boot but won't install, amd64+mac will boot and install
<stgraber> yeah, Fedora has a couple more tricks in their boot sector that Ubuntu doesn't have yet
<stgraber> that's why we still have a separate image
<shadeslayer> well ... if it's just the booting part, I am 99% confident that it just works with the standard desktop image
<shadeslayer> I'll test alpha 3 once I buy a DVD tomorrow
<micahg> hrm, shouldn't a blacklist entry prevent the inclusion of a binary and its dependency tree?
<shadeslayer> stgraber: I'd absolutely love to see Fedora's modifications included in ubuntu so that I don't have to burn DVD's
<micahg> http://bazaar.launchpad.net/~xubuntu-dev/ubuntu-seeds/xubuntu.quantal/revision/909 did I miss something?
<shadeslayer> I'd do it myself, except I have no idea how all of that works :P
 * shadeslayer can volunteer for testing however
<micahg> ah, I included the wrong binary :(
<ogra_> skaet, for netboot you mean ? i was hoping to be done by end of the week
<stgraber> shadeslayer: yeah, it's been on Colin's todo list for a few months, it's not trivial as we're not using the same tools at all and IIRC there was concern that Matthew's tricks would regress some currently working setups
<skaet> ogra_, ok,   wasn't sure if it was something needed for A3 or not,  from the comments.   I'll assume not then.
<shadeslayer> stgraber: ahh ...
<ogra_> skaet, well, its definitely to much change to get into debian-installer right now
<shadeslayer> all of it seems very magical to me tbh
<skaet> ogra_,  can you add a release note to the TechnicalOverview/Alpha3 about it?
<Daviey> shadeslayer: Was that an offer to help?
<ogra_> i actually wanted to have it ready by monday but instead had to fix the server builds first ....
<ogra_> skaet, no problem, will add something
<skaet> thanks ogra_
<shadeslayer> Daviey: sure, except I don't know shit about EFI and how stuff works in GRUB
<shadeslayer> oh plus
<shadeslayer> one more thing that needs to be done is that the i915 module should be compiled into the standard kernel, that way you can switch off discrete graphics
 * skaet has kicked off the server rebuilds
<micahg> hrm, is updating the blacklist file not enough?  I still seem to have ubuntu-sso-client-qt even though I added it to the blacklist file
<shadeslayer> Daviey: I barely have EFI booting at the moment
<shadeslayer> pure EFI boot I mean, not that BIOS emulation crap
<slangasek> shadeslayer: it may have worked for one particular mac case that you tested; it does not, in general, work reliably on EFI Macs
<shadeslayer> slangasek: right, I'm just interested in why exactly we have Mac ISO's
<slangasek> *that* is why
<slangasek> because the non-mac image does not, in general, work reliably on EFI Macs
<shadeslayer> well ... I have a EFI mac
<shadeslayer> Late July 2011, MBP (8,2)
<shadeslayer> slangasek: and didn't work as in didn't even boot?
<shadeslayer> or  did not work as in "Fans did not come up causing machine to get insanely hot"
<ScottK> No boot.
<slangasek> shadeslayer: doesn't boot.  you really need to talk to cjwatson if you want specifics; but the answer is still the same, we can't get rid of amd64+mac images until our image build scripts do the same handling for EFI boot that Fedora has now implemented
<ScottK> FSVO sane.
<ScottK> Oh, you said same.
<shadeslayer> slangasek: I'm not saying get rid of them, I'm curious as to what special magic goes into the Mac builds
<shadeslayer> and that it doesn't make sense to have mac builds for Servers
<slangasek> the special magic in the mac builds is that they don't include EFI support
<shadeslayer> they *don't* include EFI support? 0.o
<slangasek> so they *only* boot in bios compat mode, which Works
<slangasek> as for the server builds, that's certainly up to Daviey (and the Ubuntu Server folks generally) to decide
<shadeslayer> uhh .. ok
<shadeslayer> slangasek: any particular model where the standard image didn't work?
<slangasek> I wouldn't know the details
<shadeslayer> right, will wait for cj then
<Laney> stgraber: but you are having omap4 in general?
<stgraber> Laney: we have omap4 for dailies as preview images for our a10 images that we hope will start appearing a bit later this cycle
<stgraber> Laney: so we don't release omap4 as we don't want people to expect us to release an omap4 image for 12.10 as our target is a10
<Laney> ok
<Laney> so it should be in default-arches but overridden for manual milestone builds
<stgraber> right
 * Laney wonders why we have all of the for p in <one thing> there
<Laney> jibel_: skaet: wubi is starting now
<slangasek> Laney: cut'n'paste is easier? :)
<skaet> Laney,   WUBI published already with latest
<Laney> oh, well this is from the stuff i queued up this morning
<skaet> Laney,  anything else in your queue that's not on the pad?
<Laney> wubi is last in the order, so I doubt it
<skaet> Laney,  coolio.   WUBI emerged from the full rebuild that cjwatson started around an hour ago.
<Laney> wonder how his were faster
<Laney> pasted all of the timings i could find in there
<skaet> Thanks Laney
<Laney> especially the arm buildd was fighting contention though
<skaet> cjwatson started his off at 1100 UTC as one big set,   when did you start yours off?
<Laney> 0800UTC
<Laney> I just used the rune on the pad
<skaet> yeah,  I thought yours had all finished when he started his,  so must have been some weird contention going on.
<Laney> oh well
<stgraber> infinity: lp:~stgraber/ubuntu-archive/tools/detect-broken-bugs
<stgraber> infinity: lp:~stgraber/ubuntu-archive-tools/detect-broken-bugs even
<Laney> there
<Laney> skaet: are we intentionally not building alternates for kubuntu?
<skaet> Laney,   Riddell had indicated he wasn't interested in them for the Alphas, since they may be going away.
<hggdh> ogra_: there still?
<skaet> if Riddell or ScottK, want them built,  we certainly can.
<Laney> right. The manifest says they're still coming, so wanted to check.
 * Laney EODs. see ya
<skaet> Laney,  right thing to do.  :)   I'll go update the manifest to be a bit clearer on it.
<Laney> lowlatency kernels in NEW btw
<infinity> Laney: Is not.
<Laney> erm.
<Laney> well wouldya look at that
<Riddell> Laney, skaet: yeah I think we do want alternates for kubuntu still
<micahg> hrm, no answer about the seeds :(
<stgraber> micahg: I don't remember exactly how the seed blacklist works, but in most of the cases, that's not the right thing to use as it won't be respected when manually installing xubuntu-desktop or doing a netboot install
<micahg> stgraber: yes, but I don't mind these things in those cases :), just on the images
<micahg> and they're not in -desktop
<hggdh> armhf-omap4 server image -- no working keyboard, bug 1028664
<ubot2> Launchpad bug 1028664 in debian-installer "keyboard does not work on quantal-server-armhf+omap4.img" [Undecided,New] https://launchpad.net/bugs/1028664
#ubuntu-release 2012-07-25
<skaet> Riddell,  have start ed off the kubuntu alternates build.   They should show up on the iso tracker shortly.
 * skaet has updated the pad to make the rebuilds include them.
<skaet> infinity, ogra_ can you look at the bug that hggdh has flagged?
<skaet> bug 1028664
<ubot2> Launchpad bug 1028664 in debian-installer "keyboard does not work on quantal-server-armhf+omap4.img" [Critical,New] https://launchpad.net/bugs/1028664
<skaet> Riddell,  ScottK,   kubuntu alternates now posted.
<infinity> skaet: I can try to reproduce/confirm it, I probably don't have the spare cycles to spend time debugging and fixing it.
<skaet> infinity,  confirming it would be good.    We can decide what to do tomorrow after Europe comes online.
<skaet> slangasek, ^ FYI.
<slangasek> hggdh: is it only the server image that's affected?
<infinity> My guess is that Oli only tested this via serial (which is how Real Men install servers), but I'm grabbing an image to see if I get console response with a USB keyboard.
<infinity> If it works on serial but not a USB console, though, I wouldn't call that an Alpha blocker, just an annoyance that should be fixed before final release.
 * skaet nods
<infinity> Well, that's cute.  I get no USB keyboard support, but I also get no serial console.
<infinity> I wonder how this is meant to work. :P
<slangasek> hmm
<slangasek> this is with the all-new squashfs stuff, right?
<slangasek> has anyone *actually* tested it interactively up to now? :P
<infinity> Yeah, I imagine so, but I'm not sure how that should matter.
<infinity> The "make bootable" bits should be the same.
<infinity> Which should include sane commandlines, etc.
<slangasek> ah, true enough
<infinity> Well, the lack of serial console could/should be command-line issues.
<infinity> The USB keyboard thing seems more like a "blame the kernel" deal.
<infinity> But someone will need to fix A to debug B, perhaps. :P
<slangasek> the kernel, or the initramfs
<infinity> Well, the kernel, or the (lack of) kernel modules in the initrd?
<slangasek> yes
<infinity> That's all "kernel" to me. ;)
<slangasek> pretty sure the bugs in the latter are the responsibility of the foundations team to fix ;)
<infinity> Well, yes.  I wasn't referring to the team, but the bit that's not working. ;)
<infinity> Anyhow, let me have a quick poke at this card and see why it thinks I don't deserve a serial console.
<infinity> ... because it has a boot.scr-serial alongside boot.scr that isn't the default.  Intuitive!
<infinity> [    3.334655] usb 1-1.3: New USB device found, idVendor=046d, idProduct=c31c
<infinity> [    3.342926] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
<infinity> [    3.350891] usb 1-1.3: Product: USB Keyboard
<infinity> [    3.355651] usb 1-1.3: Manufacturer: Logitech
<infinity> Sure looks there to me...
<slangasek> and does it work?
<infinity> Yeah, that's harder to tell, when d-i is booted to serial.
<infinity> No console.
 * slangasek nods
<slangasek> hmm, where did you see this boot.scr-serial?
 * infinity assumes there must be a cake and eat it too option.
<infinity> slangasek: In the vfat partition.
<slangasek> I just downloaded the daily server image linked from the iso tracker, and I don't see that
<slangasek> oh
<slangasek> that wasn't a server image, sigh
 * slangasek tries again
<slangasek> infinity: by the by, where does the boot.scr get generated?
<infinity> slangasek: On nusakan.  debian-cd/tools/boot/quantal/post-boot.*
<infinity> Ish.
<slangasek> ok. because I think it would be just peachy if we would also include a suitable source representation on the image
<slangasek> without which it's bloody annoying if you have to ever edit the commandline for booting on a panda
<infinity> You mean you don't like editing out the binary bits with vim before you redo it? :)
<slangasek> I kinda don't
<infinity> Heh.
<infinity> Yeah, including the matching boot.script would be simple enough.
<infinity> I can commit that right now.
<infinity> I can commit that as soon as I get a gnome-terminal that works...
<ogra_> infinity, slangasek, cp boot.scr-serial boot.scr .... on the first partition of the SD
<infinity> ogra_: Yeah, we found it.
<ogra_> oh, ok
<ogra_> then i'm actually off to bed
<infinity> ogra_: Does the kernel not do sane autodetection like it can on x86? :(
<ogra_> autodetection of what ?
<infinity> On x86, if you have a physical console attached (ie: keyboard and monitor), you get a framebuffer d-i, if you don't, it falls back to serial.
<infinity> Which is much handier.
<ogra_> ah, no, i have never seen that working
<infinity> I'm entirely prepared to believe that the omap kernel doesn't give us enough info to pull that trick, but it's also possible that we could and we just don't.
<ogra_> on omap i even get a broken installer if i dont force the framebuffer off when using serial
<ogra_> you end up with display on framebuffer and input on serial
<infinity> Well, that would be better than the current situation, which is no input. ;)
<ogra_> that sounds like a kernel bug though
<ogra_> anyway, i'll happily look into that if its not 3am ... really off to bed now
<infinity> slangasek: Alright, future spins should have boot.script and boot.script-serial on the SD to match the compiled versions.
<slangasek> infinity: ta :)
<infinity> So, getting as far as installing the base system, then chrooting in and running a getty on tty1, my keyboard works.
<infinity> Kinda wasn't expecting it to...
<infinity> Ahh, no.  There it is.
<infinity> It was during the hardware detection stage of d-i, the keyboard sprung into existence as an input device.
<infinity> That seems like suboptimal timing.
<RAOF> Yeah, the keyboard doesn't work in the initramfs. Which is kinda annoying, because it doesn't find my root device correctly, so dumps me in the initramfs...
<infinity> RAOF: Well, in this case, it doesn't work until much after you need it to press the "make it work" key. :P
<infinity> RAOF: Which is even worse.
<RAOF> Hah!
<slangasek> infinity: do you know why it's picked up so late?
<slangasek> is it not udev-driven?
<infinity> slangasek: I imagine the module just isn't around.
<slangasek> is this not booting to the squashfs?
<infinity> No, the squash is used as source media only, I think.
<infinity> It's booting to a d-i initrd.
<slangasek> ok
<infinity> At least, that's what it looks like to me.
<infinity> This is the first time I've seen this new magic. :P
<slangasek> :)
<infinity> If I had to guess, I'd just say the hid* stuff isn't available on boot.
<infinity> But that requires more digging.
<infinity> Actually, I guess just rebooting would make that easy to confirm.
<infinity> Yeah, no /lib/modules/3.4.0-204-omap4/kernel/drivers/hid on the boot image.
<infinity> So, it gets pulled in later via udebs.  Which is, of course, useless.
 * slangasek nods
<slangasek> is this initrd being generated by d-i, or on nusakan?
<infinity> The latter, I suspect.  But that's another "not sure".
<infinity> Thankfully, debian-cd is very sane and reasonably hackab... Oh, wait.
<slangasek> comes from d-i
<slangasek> via tools/boot/quantal/boot-armhf+omap4
<slangasek> ubuntu/dists/quantal/main/installer-armhf/20101020ubuntu162/images/omap4/cdrom/
<infinity> Ahh, kay.
<infinity> Oh, right.  The cdrom bits.
<infinity> Derp.
<infinity> I knew that.
<infinity> And I'm betting no one's dusted those off in, like... Ever.
<infinity> So, looks like I need input-modules-$ver.udeb
<slangasek> build/pkg-lists/cdrom/armel/omap.cfg -> build/pkg-lists/cdrom/armel/omap4.cfg?
<infinity> I just got there. ;)
<slangasek> ok
<slangasek> you want to follow it through?
<infinity> Yep.
<infinity> netboot wanted the same treatment.
<infinity> You know, I think I even remember someone once claiming that netboot didn't work with a USB NIC.
<infinity> That would be why.
 * infinity shakes his head.
<RAOF> While we're on the subject, how can I debug why my netinst install can't find it's root on the USB device?
<infinity> RAOF: Also armhf+omap4?
<RAOF> Yes.
<infinity> precise or quantal?
<RAOF> From the quantal netinst images, circa 3 days ago or so.
<infinity> Define "find its root".
<infinity> The kernel boots, and then no root?
<infinity> Or no kernel?
<RAOF> Kernel boots, dumps me in initramfs having not found /bin/init
<RAOF> At this point I can't really tell why it hasn't found that, because no keyboard in the initramfs ;)
<infinity> Oh, this reminds me of another d-i bug I was going to fix.  But it shouldn't present that way...
<infinity> Oli was telling me that flash-kernel still just doesn't work at all, because our d-i images don't have a partition table that makes flash-kernel happy.  Or something.
<infinity> But that would present as you ending up with the installer in an infinite loop on reboot, not what you described.
<infinity> Meh, I need to wipe one of my USB drives, so I can test both of these bugs and see WTF is going on.
<infinity> Or go rustle up a USB stick.
<RAOF> Or you could make it so that the keyboard works in the initramfs, and I could tell you what had actually gone wrong :)
<infinity> RAOF: Anyhow, I'm pretty sure netboot is "known not-working", but if I can fix it in the same d-i upload with minimal effort, what the heck.
<infinity> RAOF: You netbooted... Use a serial console?
<RAOF> I don't *have* a serial console.
<RAOF> netboot-fb for me.
<infinity> I can see how that would be frustrating. ;)
<infinity> That said, I'm not sure that dumping all the usb/hid stuff in every initramfs is the right answer.
<infinity> Though, maybe it is for omap.  I dunno.
<infinity> I'll ponder that later.
<infinity> ... as he gets halfway through the install before noticing this isn't netboot.
<infinity> La la la.
<infinity> Reason number 34 for a local mirror:
<infinity> root@vishnu:~# zcat /srv/mirrors.0c3.net/ubuntu-ports/dists/quantal/main/installer-armhf/current/ima
<infinity> ges/omap4/netboot/boot.img-serial.gz > /dev/mmcblk1
<infinity> RAOF: I'd suggest you try the new server image, but.  Oops.  No keyboard. ;)
<micahg> kenvandine: freeze anyone?
<kenvandine> micahg, i was fixing the ftbfs from earlier
<micahg> kenvandine: ah, hrm, okies
<infinity> FTBFS fixes still change the archive. :P
<kenvandine> failed on i386
<infinity> That's a curious failure.
<micahg> indeed
<infinity> Okay, bored with debugging netboot, want cookies.
<infinity> Uploading the d-i fix for the server keyboard issue.
<micahg> kenvandine: I was able to replicate the FTBFS in an i386 quantal chroot
<kenvandine> i could do once
<kenvandine> but running the tests a second time they pass
<kenvandine> it's very odd
<kenvandine> and they pass first time outside of a package build
<infinity> ...
<infinity> RAOF: So, uhm.  quantal/omap4 netboot works flawlessly for me.
<infinity> RAOF: I'm now very confused as to why people claim it doesn't. :P
<RAOF> infinity: Maybe I just need to flash a new image? Has it changed in the last couple of days?
 * infinity wonders if the -fb variant is somehow broken when the -serial one works, and tries that.
<infinity> RAOF: Well, d-i has been rebuilt, I didn't think that any of the things that were supposedly broken have been unbroken.
<infinity> RAOF: But... It all works for me.
<infinity> RAOF: (on serial... Testing FB now)
<infinity> RAOF: Are you doing any funky partitioning, just just doing Guided-whole-disk?
<infinity> RAOF: It could be that partman is doing broken things in some cases, maybe.
<infinity> Man, 24 inches of HD aubergine is kinda jarring.
<RAOF> The most recent attempt was guided-whole-disk, replacing the ext4 partition with a btfrs one. I've also tried a straight guided-whole-disk in the past.
<infinity> RAOF: It's possible that between Luke's upload on the 20th and Oli's uploads yesterday, it all Just Works.
<infinity> RAOF: But none of those address the things Oli claimed were broken, so I suspect he lied to me. :)
<infinity> (But working is working, I won't complain)
<infinity> Of course, someone should fix partman thinking that I want or care about a /boot partition on this thing, but that's a minor nit, if the rest works.
<infinity> queuebot: That's a filthy lie and you know it, they're still building.
<infinity> RAOF: So, yeah, skip the current version, cause it's obsolete in 20 minutes, but please do try a 20101020ubuntu163 netboot when it's published.
<infinity> RAOF: I did make one change to it, so a confirmation that it's not buggered would be nice.
<infinity> RAOF: (My 20101020ubuntu162 run will finish shortly to confirm that it worked)
<RAOF> infinity: Oh, it doesn't need a /boot?
<infinity> RAOF: No, not that it hurts to leave the default partitioning in (which I've done in my quick test here).
<infinity> RAOF: Given that, by default, the kernel ends up on the SD card, a /boot makes no sense.
<infinity> RAOF: In the case of a uboot on SD using extload to grab the kernel from the hard drive, it *might* make sense, not sure if uboot has issues with huge disks.  But we don't boot that way by default anyway.
<RAOF> infinity: You know you've still got e2fsprogs in the precise-unapproved awaiting the pleasure of your review, right?
<infinity> RAOF: Yeah, xnox and I talked about it in Nicaragua.  And then we took the rest of the month off.
<infinity> RAOF: I should probably just reject it and work with him on it later.
<infinity> There.
<RAOF> :)
<infinity> RAOF: In exchange, review my d-i.
<infinity> (Ideally not the same way I just reviewed xnox's upload)
<RAOF> Most assuredly!
<infinity> RAOF: Actually, don't.
<infinity> RAOF: Well, review, but don't accept.
<infinity> RAOF: It'll just lead to a no-change upload later to rebuild against Colin's d-i-utils upload sitting there.
<RAOF> Shall I eat some quiche until that gets done? :)
 * infinity quickly reviews that.
<infinity> RAOF: Real men, quiche, etc.
<infinity> RAOF: Oh, did that mesa thing go before the TB or something, or were you feeling generous?
<infinity> RAOF: (I'm deliberately avoiding option C, which is that you reviewed the whole thing, but if you did, wow)
<RAOF> Went before the TB
<infinity> Cool.
<infinity> It looked like the right thing to do, IMO, but I sure as heck wasn't going to audit it.
<infinity> RAOF: When 'rmadison di-utils' claims something vaguely plausible about being published on 5 arches in precise-proposed, go nuts with debian-installer.  Just didn't make sense to me to upload twice in a row.
 * infinity thinks he might go find a cookie before the shops all close.
<RAOF> Win
<micahg> infinity: ^^ I think this is happy enough for proposed
<slangasek> infinity: maya quiche?
<infinity> RAOF: FWIW, the framebuffery netboot worked for me too.
<slangasek> infinity: uploading to quantal-proposed?
<slangasek> or is it already there?
<infinity> slangasek: d-i is in quantal already.  I was referring to testing RAOF's issues with the previous version, though.
<infinity> (Or rather, testing with the previous version, his issues were obviously with an older version)
<slangasek> ok
<infinity> slangasek: I you want to respin an omap4 server image, the new d-i should be ready for it.
<infinity> RAOF: The di-utils SRU is published on all arches -- do with that information what you will. :)
<RAOF> infinity: This is an ack on your debian-installer upload. I see armel and ppc are being slowpokes; if you notice that they've finished before me, go for it.
<RAOF> Hah! Overlap :)
<infinity> :P
<infinity> So, yeah.  All done now on ftpmaster, which is all that matters to the buildds.
<RAOF> rmadison is late, but I'll go ahead and accept.
<infinity> rmadison is from a mirror of a mirror, it's always laggy.
<infinity> Danke.
<slangasek> infinity: ack, respinning - thanks
<slangasek> hmm, crontab and pad don't seem to have been updated for the drop of preinstall images
<ogra_> oh, we have a new arch ? :P
<ogra_> Wed Jul 25 06:11:40 UTC 2012
<ogra_> No live filesystem source known for armhf-omap4
 * xnox head desk
<xnox> who rejected e2fsprogs? infinity ?
<ogra_> if i only could find out where that comes from
<infinity> xnox: I did, yes.  We can chat about it tomorrow. :)
<xnox> infinity: ok. =)
<xnox> infinity: good night (?!)
 * infinity nods.
<infinity> Night indeed.
 * xnox is not too sure. oh ok.
<ogra_> infinity, any idea ? the nusakan copy pastes also all have armhf-omap4
<ogra_> (on the pad)
<infinity> I don't see it in any commandlines on the pad...
<ogra_> it looks a bit like a cron entry that ran ... (teh mail also has no (built by ...)
<ogra_> infinity, at the bottom of the pad
<infinity> The copy and paste for output is correct, it just does project-arch-subarch
<infinity> But I'm guessing someone accidentally did a run with ARCHES=armhf-omap4 and sent you your mail, that's all.
<ogra_> then i dont get where that failed build comes from
<infinity> Probably from vorlon re-running the server image earlier tonight.
<ogra_> since SUDO_USER doesnt seem to be set ...
<ogra_> which it should from a manual run
<ogra_> (and which would trigger the mail subject to be different)
<infinity> cdimage@nusakan:~$ echo $SUDO_USER
<infinity> cdimage@nusakan:~$
<infinity> It's not always set, depends on how you sudo.
<ogra_> oh, indeed
<ogra_> i'm indeed assuming we all use the same method :P
<infinity> Old habits die hard.
<ogra_> heh
<ogra_> well, sleep well then ...
<infinity> I still use "sudo su - user" because that was sane before "sudo -u user -i" existed.
<infinity> It's muscle memory for old people. :P
<ogra_> yep, i know what you mean
<infinity> Arguably, we could/should patch shadow (or pam_env, whichever is killing it) to preserve SUDO_USER.
<infinity> But I dunno.
<ogra_> but if i get that right there was a server build supposed to happen after d-i was published, right ?
<infinity> That could have weird knock-on effects I'm not thinking about.
<infinity> ogra_: Right.  slangasek kicked it off.
<infinity> ogra_: If that never finished, that was probably the email you got. :P
<ogra_> the last server image is from yesterday 21:xx UTC
<ogra_> right
<infinity> Yeah, so feel free to spin another.
 * ogra_ will try
<infinity> It should fix the no keyboard issue, but I'd like confirmation.
<infinity> Also, netboots all work great now, thanks for fixing that.
<infinity> (Well, you and TheMuso, his fix was somewhat critical)
<ogra_> how do they work great ? they are still unbootable after install
<infinity> Are not.  Try one.
<infinity> I just did both -serial and -fb last night, both rebooted fine.
<ogra_> ?? f-k cant find /dev/mmcblk1p1 (since there is no partition)
<ogra_> or mmcbk0p1 or so
<infinity> There is on the cards I just wrote.
 * ogra_ doesnt see how that would be fixed 
<infinity> I'm not sure how netboot was doing anything with f-k at all before TheMuso's upload.
<ogra_> it uses f-k-i udeb
<infinity> (The answer being that it couldn't have been)
<infinity> Yeah, but the udeb wasn't marked for that subarch. :P
<ogra_> the images i tested yesterday definitely had lukes fix
<ogra_> and failed miserably in f-k-i
<infinity> Very weird.  Cause yeah, I just did both the omap4 images yesterday, and they were happy.
<ogra_> so i really dont get how it can have worked for you
<ogra_> f-k hardcodes /dev/mmcblk0p1
<infinity> Maybe I'm magic.
<ogra_> heh
<ogra_> did you partition the mmc using partman during install ?
<infinity> No, not unless it did so behind the scenes.
<infinity> I only partitioned my install media.
<ogra_> it doesnt usually
<infinity> Err, my target media.
<ogra_> weird
<ogra_> well, i'll do a new test later, but i dont see how a working install can be possible
<infinity> http://paste.ubuntu.com/1109757/
<infinity> ^-- Looks partitiony to me.
<ogra_> yeah
<infinity> I'm not really sure why it was having a sad for you.
<ogra_> where would these come from ?
 * ogra_ doesnt get it ... i dont think we have any code for this
<infinity> I dunno, but they must have always been there.  flash-kernel 2.0 didn't magically partition cards either, it had the same hardcoded logic.
<ogra_> they definitely werent there yesterday
<ogra_> and the last two weeks ... LethoThe2nd reported it to me on IRC monday last week and i'm 100% sure no d-i build had them until yesterday
<infinity> boot/arm/generate-partitioned-filesystem
<infinity> ^--- From the d-i netboot bits.
 * ogra_ scratches head
<infinity> Which does basically the same thing as debian-cd.
<infinity> Cargo-culted code, even.
<infinity> So, I'm puzzled as to what error was being seen. :/
<infinity> Oh.  Unless it has the same off-by-one error that I fixed in debian-cd last year.
<ogra_> err, wait, i tested omap
<infinity> Which would come and go as the initrd/kernel grows and shrinks.
 * ogra_ wonders if tehre is any difference
<infinity> omap and omap4 use the same code here.
<infinity> But the off-by-one thing is entirely possible.
<infinity> I can look at that in the morning.
<infinity> Or you can dig through debian-cd logs and find the fix and compare.
<infinity> Whichever.
<ogra_> yep, will do, i only do testing today anyway (and some paperwork)
<infinity> ogra_: bzr diff -r1722..1723
<ogra_> where, in d-i ?
<infinity> ogra_: In debian-cd.
<infinity> ogra_: Though that may not apply to d-i.  There's already a spare 512 there that wasn't in debian-cd.
<infinity> So, I could be barking up the wrong tree.
<ogra_> yeah, d-i doesnt use that
<infinity> Maybe you should just re-test omap3 and see if it's still borked, and we'll debug from there. :P
<infinity> (Or, if you can find an image that's broken)
<ogra_> all d-i build logs of the last four builds show that the partitioning code is run
<infinity> ogra_: Yeah, the code is obviously being run, the question is if it's broken subtly.
<infinity> ogra_: Hence my guessing at the off-by-one thing.
<infinity> ogra_: Since the debian-cd partitioning bits and the d-i ones are very similar in history.
<ogra_> thats a weird diff btw
<ogra_>  modified file 'tools/boot/oneiric/post-boot-armel+mx5'
<infinity> You're welcome. ;)
<ogra_> heh
<infinity> I probably should have named it "MBR" instead of "LEAD_IN", but there were enough confusing variables already, adding to them was fun.
<ogra_> i mean that bzr shows the first half of the patch for one link name and the second one for the actual file
<infinity> ogra_: Huh?  Those are two files.
<infinity> ogra_: Or, they were back then, if they're not now.
<ogra_> ah, k
<infinity> Same fix, applied twice, to two slightly different bits of code.
<ogra_> well, oneric, old stuff ...
<infinity> Only the omap one is relevant, I imagine.
<ogra_> yep
<infinity> But, like I said, there's a spare 512+ in d-i already anyway, so this could be a red herring.
<infinity> I'd like to find an image that breaks for you, and try to reproduce.
<ogra_> well, all images i tested didnt have any partition after dd'ing
<ogra_> i usually re-plug the SD before i move it to the board
<infinity> Even after pulling and re-inserting the card.
<ogra_> yeah
<infinity> Many/most card readers won't re-scan partitions.
<infinity> Kay.
<infinity> They need a media change event, which some readers also don't do properly.
<infinity> ogra_: But if, say, 20101020ubuntu161 was broken for you, let me know, and I'll dig into the WTF of it all.
<ogra_> http://paste.ubuntu.com/1109783/
<infinity> ogra_: If not, then we could have a harder time finding older ones.  Unless you have one sitting around.
<ogra_> i still have them around, but i downloaded from the /current link (still have the tab open) ... timestamp on the page is jul 24th 07:03
<ogra_> -rw-rw-r-- 1 ogra ogra  31457280 Jul 19 15:34 boot.img-fat-fb
<ogra_> -rw-rw-r-- 1 ogra ogra  31457280 Jul 19 15:34 boot.img-fat-fb.1
<ogra_> -rw-rw-r-- 1 ogra ogra  31457280 Jul 24 09:03 boot.img-fat-serial
<infinity> Oh, wait.
<infinity> That's the fat.
<infinity> That's not an image.
<ogra_> all of them are omap though
<ogra_> oh SH*T !!!
<ogra_> indeed you are right
<ogra_> hooray for informative naming
 * ogra_ goes to stand in the corner for a while
<infinity> Well, it does say "fat".  As in, "hi, I'm a filesystem". ;)
<ogra_> yes
<ogra_> well, we can then release it, great, saves me one release note to write :)
<infinity> *grin*
<ogra_> and while making a fool out of me nusakan has finished the server images
<ogra_> great
<infinity> So I saw.
<infinity> So you can test those and see if you get a USB keyboard.
<infinity> And I'll sleep, honest.
<ogra_> will do
<ogra_> great, sleep tight
<infinity> If it's still buggered, reopen the bug and yell at me.
<infinity> Or fix it. :P
<ogra_> i'll do the latter :)
<infinity> (But I'd like to know either way)
 * ogra_ goes getting some coffee
 * infinity goes to have a bedtime smoke.
<xnox> infinity: i hope you have a smoke alarm in your bedroom
<ogra_> better than in his bedtime at least :P
<ogra_> k, so omap netboot is definitely a no-go ... seems the NIC driver is missing
<ogra_> weird, omap4 as well
<ogra_> hmm, in fact there are no USB devices at all
 * ogra_ is confused
 * ogra_ tries the framebuffer image instead
<ogra_> aha, that works
<infinity> ogra_: Hrm, I didn't remove any drivers, just added some...
<ogra_> yeah, it seems to randomly not work
<ogra_> i had two boots of the serial image where no usb disk was found, three where it was
<ogra_> smells like a udev race
<ogra_> i have a framebuffer install working atm, lets see if it gets completely through, then i'll dig more into the usb bits
<infinity> It could be the vm.min_free_kbytes thing.
<ogra_> though testing the normal server image first is probably more important
<infinity> Though, I can't see that being an issue on boot, we haven't eaten the RAM yet.
<ogra_> yep
<ogra_> also see my last comment on that bug ...
<ogra_> i would actually like to try that suggested kernel fix from marvin24
<ogra_> instead of having the hack in userspace again
<infinity> If it works, sure.
<infinity> It's not the easiest thing to test, mind you.
<ogra_> why ? if i can get a patched kernel ...
<infinity> I mean it's not the easiest thing to reliably reproduce to the point where one can be sure it's fixed.
<ogra_> running apachebench seems to trigger it reliably
<infinity> But we'll let the kernel team comment on it.  I'll bring it up with them.
<ogra_> i pinged paolo about it already, lets see what he says
<infinity> In theory, the easiest test is just "do something to consume all the RAM", "do heavy reads from USB disk" and "do heavy network I/O".
<infinity> But it's still not what I'd call "reliable".
<ogra_> sigh, base-install seems to take ages here
<infinity> I was installing to a USB key last night, it wasn't that awful.
 * ogra_ does the same here 
<infinity> Certainly nicer when netbooting, but the SD copy isn't world-endingly bad.
<ogra_> and the stick usually gets me 24-25M/s
<ogra_> definitely the fastest one i have
<ogra_> this *is* netboot
<ogra_> the framebuffer one
<ogra_> and its not the download that was slow ... configuring the packages seems to take aeons
<infinity> Ahh, well, netboot is still faster than the SD image.
<infinity> Though, the SD copy isn't actually that bad.
<ogra_> yeah, the new server is pretty fast
<ogra_> though as you guessed, i only tested serial yesterday
<infinity> It should be blindingly fast on x86.
<infinity> On ARM, we trade off that live-install is faster than base-install with the fact that SD cards suck. :P
<ogra_> and havent had a chance to test my f-k fixes in production yet
<infinity> There still must be a way to do the x86ish auto-detect of fb versus serial.
<ogra_> i guess thats a matter of a sane framebuffer driver
<infinity> Maybe.  I've never looked to see what x86 is doing.
<infinity> Well, fsvo "sane".
<infinity> It fails when hooked up to a KVM, so most "real server admins" force the command line anyway.
<infinity> But it's certainly a nice hack for image testing.
<ogra_> well, likely one that doesnt create a framebuffer device if no monitor is attached instead of having some hardcoded thing
<infinity> Plug in keyboard/monitor, get framebuffer, unplug, get serial.
<apw> infinity, i note that linux-lowlatency binaries are in universe, i am supprised that works for the image builds?
<infinity> omapdrm might be the sanity we're looking for, but I don't think we get a remotely sane version of that until Paolo moves to 3.5, or maybe even 3.6
<infinity> apw: It's for an image that builds from universe, so it works fine.
<ogra_> apw, kernels in main are only needed for images that are involved with d-i
<infinity> apw: Pretty much all of ubuntustudio is in universe.
 * apw adds that to his mental model, tha
<infinity> Well, ubuntustudio does have alternates, that do involve d-i.  And we cheat and put the generic kernel on their alternates (ie: we use the ubuntu cdrom bits). :/
<infinity> (And then we install lowlatency during the install)
<infinity> It's hackish.
<apw> infinity, hackish :) indeed
<ogra_> cute
<infinity> Anyhow, I seem to be failing at sleeping again, and we have a family^Wteam meeting in 3.5 hours.  Hrm.
<infinity> I should try again to nap.
<ogra_> go for it, good luck !
<infinity> apw: Care to throw a seasoned kernel dude opinion at https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/746137/comments/16 ?
<ubot2> Ubuntu bug 746137 in jasper-initramfs "Page allocation failure on Pandaboard and Beagle XM" [Undecided,Fix released]
<ogra_> infinity, ppsati is on it too
<ogra_> apw, ^^^
<infinity> ogra_: Yeah, I know, I just wanted a gut feeling from Andy.
<ogra_> (but additional opinions surely dont do harm :) )
<infinity> (Besides, we want it in master too, not just ti-omap4)
<ogra_> right, though i think omap4 is the place to test it
<ogra_> less intrusive
<infinity> omap4 test kernels are a good place to test it, but ultimately, committing to master and rebasing feels saner.
<ogra_> ++
<infinity> It's the same driver, same level of intrusive. :P
<ogra_> it is surely a lot easier to reproduce oin the beagle
<ogra_> though i guess booting a panda with mem=512M should do the same
<infinity> Or 256, if it's my Beagle. :(
<ogra_> or that
<infinity> I should put the thing out of its misery.
 * ogra_ uses his 256M beagles as printserver and router :)
<infinity> And beg someone to ship me an xM.
<infinity> I'd rather use mine as a frisbee.
<apw> infinity, surley you can just order one
<infinity> apw: I could, but we have a ton in London that aren't being used.
<infinity> apw: Since we decommissioned them as buildds.
 * ogra_ wants one that isnt revA 
<apw> infinity, and just how much would it cost to send one from the UK to you, i suspect more than they are worth
<infinity> And 20 bucks shipping seems saner than 150 for a new board.
<ogra_> yeah
<apw> heh, $20 shipping, from here to there, yeah right
<infinity> It doesn't have to be overnight. :P
<ogra_> someone should just bring them to UDS and give them out to the teams
<infinity> The good ol' postal service will do it for that, or less.
<ogra_> no costs at all :)
<infinity> We spoiled brats and our FedEx and DHL need to occasionally remember that regular mail actually works just fine. :P
<ogra_> haha
<apw> ogra_, you say 'kernel fix above' but i am not seeing it (likely i am just missing it but)
<infinity> apw: I linked to it. :P
<ogra_> apw, comment 16
<infinity> apw: It's a verbal patch, not a literal one.
<ogra_> "replace GFP_ATOMIC by GFP_KERNEL in the relevant kmallocs which worked for the rt2x00 wifi driver in the ac100 armhf kernel"
<ogra_> that driver had exactly the same prob
<apw> hmmm they are probabally _ATOMIC so they can be performed out of the interrupt handlers handling incoming packets
 * apw wonders what it is with us dropping every userspace package which ever configured the kernel, so that we have to configure every damn kernel 15 ways to make up for it
<apw> the kernel has these interfaces for a reason, there is no sane default for many of these things
<infinity> apw: In this case, the userspace hack is, well, an obvious hack.
<apw> we only need the new hack because the old place went away
<infinity> The old place?
<ogra_> we dont have anything that puts the old hack in place atm
<apw> which is my point.  keybuk was always removing things and saying hte kernel should do it right
<ogra_> and it is and always was a hack
<infinity> I don't mean that *how* we configure is a hack, I mean the configuration itself is a hack.
<apw> jasper-initramfs went away
<ogra_> right
<infinity> IMO, if you have to configure vm.min_free_kbytes, something's gone wrong.
<ogra_> because it was hacks and hacks only
<apw> define a hack, the machine needs more reserve with that board, that actually might be right
<ogra_> this probalem is widely known and not arm or panda specific at all
<apw> infinity, by that definition the min_free_kbytes itself is a hack
<ogra_> if you have to set min_free_kbytes *everywhere* why not use a sane default in the driver itself
<apw> infinity, the kernel has to have a reserve and its size is a usecase/hw in the machine thing
<infinity> apw: For a "normally-running system", it *is* a hack if you need it to function.  min_free_kbytes is more about performance tuning.
<apw> ogra_, no this is only for one rtl device right?
<ogra_> the kernel should know how much ram is available and be able to determine a proper value
<ogra_> apw, smsc USB NIC
<infinity> apw: But, meh.  If you claim it's machine-dependent, then the kernel should have sane defaults for that machine. ;)
<apw> only if you have that device you need it.  now yes in your case all machines we care about have it
<ogra_> and i know this driver has the same issues on x86
<infinity> apw: But, okay, one could also make it a udev rule, if it's specific to that device.
<infinity> apw: Which seems like a sane place for it.
<apw> ogra_, indeed it is a terrible driver, rtl drivers always are
<infinity> If the driver has issues on all platforms, a udev rule seems like the right answer.
<apw> infinity, that might make some sense.  and indeed if the driver needs to be ATOMIC (and i'll let ppisati test that) then either udev or something in the kernel init for that driver makes more sense.
<infinity> (or the driver not sucking)
 * ogra_ thinks a fix of the driver seems like a better answer :)
<apw> though for me removing the driver appeals too
<ogra_> LOL
<infinity> apw: Removing the driver is a bit of a non-starter when it's the NIC soldered to every Panda. :P
<ogra_> tell that to the teams doing netinstall tests on pandaboards :)
<apw> those boards all should just be put in the crusher and put out of my misery, for a start because they have any RTL kit on them
<ogra_> though we have a wlan card on it as well :)
<ogra_> apw, you could donate half of your salary to TI every month so they can buy more expensive NICs :)
<ogra_> if its really causing so much misery for you that seems like a cheap solution :P
<infinity> apw: smsc95xx is rtl, or are you confusing the two buggy drivers?
<infinity> s/is/isn't/
 * ogra_ yawns watching pkgsel progressing slowly
<apw> but it sounds like a sane plan to try the _ATOMIC change and see
<ogra_> ++
<infinity> apw: To try to s/ATOMIC/KERNEL/ that is.
<infinity> http://lists.metaprl.org/pipermail/cs134-labs/2002-October/000025.html
<apw> indeed
<infinity> ^-- That seems to imply that _KERNEL "tries harder".
<infinity> I'm all for things trying harder. :P
<apw> infinity, indeed _KERNEL can sleep waiting for memory to be reaped, i suspect though we cannot wait its common to be in interrupt handler pulling packets out of the receieve ring like mad
<infinity> apw: On a slow NIC (they're 100bT over USB2, after all), I'm not sure if the practical issue of ring flooding is nearly as bad as the theoretical.
<apw> i assume we are dropping large packets here given 'turbo' has to be enable to trigger it
<apw> and i asusme that leads us to allocate like 16 or 32k pages not normal easily available ones
<infinity> Well, disabling turbo "makes it go away", but I'm not sure that's actually true, or if it just makes it "vanishingly less likely to happen because you're suddenly shuffling less data".
<ogra_> ppisati, haha, ++ to your last comment on bug 10268780 ("bad design decision")
 * infinity reads more about what's illegal under spin_lock_irqsave(), and wonders how much one would have to trace back through smsc95xx and usbnet to decide if we're violating that.
<ogra_> err bug 1026780 that was
<ubot2> Launchpad bug 1026780 in flash-kernel "3.0~rc.4ubuntu4 doesn't honor bootargs from /boot/boot.script anymore" [High,New] https://launchpad.net/bugs/1026780
<infinity> apw: I think this is mostly just teaching me the valuable lesson that having your storage and NIC on USB is dumb.
<ogra_> well, USB 3.0 will fix that in the long term
<infinity> ogra_: Wait, what?  f-k 3.0 is hardcoding root=?
<infinity> ogra_: That means f-k 3.0 initramfses aren't generic.  That's completely wrong.
<ogra_> it reads fstab and dumps a config snippet into the initrd
<ogra_> unless you tell it not to
<infinity> ogra_: Do we tell it not to?
<ogra_> in which case you would need to add root= tro a package shipped source file that gets overwritten on package upgrades
<ogra_> so no, we dont atm
<infinity> Right, well, I've heard we can write to /boot and /etc
<infinity> Like every other bootloader config.
<ogra_> i want an /etc/flash-kernel/ bootscript.d
<ogra_> that overrides the hardcoded crap
<infinity> Personally, whoever does the work, I think that crazy needs fixing.
<ogra_> but that will have to wait until i'm back from the QA sprint
<infinity> And it needs fixing in Debian before squeeze too.  I wasn't aware of this misfeature. :/
<ogra_> and additionally we need some migration love
<infinity> I've already had long and angry arguments with people who wanted to hardcode fstab bits in initrds to support mounting /usr
<ogra_> well, loic seems to think its sane
<infinity> Don't really want to have the argument all over.
<infinity> Loic's wrong. :P
<ogra_> and having override capabilities is a nice to have
<infinity> And I'll be happy to tell him.
<ogra_> yeah
<infinity> Distro-generated initrds NEED to be generic.
<ogra_> i told him :)
<ogra_> yeah, thats not the prob
<ogra_> ust a simple switch in the db file ...
<infinity> That's the obvious problem I see with hardcoding root=. :P
<ogra_> the prob is to make it accept modified input files the package doesnt overwrite
<infinity> You mean, like... Conffiles?
<ogra_> switching off the hardcoding is there, using the alternative isnt
<infinity> It's kinda like Debian 101.
 * infinity shakes his head.
<ogra_> do conffiles not have to live in /etc ?
<infinity> Remind me of this bug when you're sprinting, so I can get angry about it again.
<ogra_> i think it was explicit that they are in /usr/share
<Laney> micahg: I'm not sure your xubuntu blacklisting had the effect you wanted
<Laney> https://bugs.launchpad.net/ubuntu/+source/xubuntu-meta/+bug/1016925/comments/7
<ubot2> Ubuntu bug 1016925 in xubuntu-meta "12.10 Alternate installer fails with libavformat53 unmet dependencies" [High,Fix released]
<ogra_> so dpkg doesnt make tehm conffiles
<ogra_> (which doesnt save you from overwriting on package upgrade')
<infinity> ogra_: You can mark anything a conffile, but no, people shouldn't be editing stuff in /usr/share.
<infinity> ogra_: But having both defaults and overrides isn't rocket science.  Look at initramfs-tools.
<ogra_> well, thats the input source :)
<ogra_> oh, indeed
<ogra_> it wont take more than 1h to implement and even fully test but i need to find that spare hour :)
<ogra_> (and a board that isnt occupied by install tests)
<infinity> Like I said, remind me when you're sprinting, and I'll fix it in anger, and give Loic about 30 seconds to agree it's awesome before I NMU it.
<ogra_> LOL !
<ogra_> will do, probably i have time during the sprint but i doubt that
<ogra_> and as long as it is fixed in final thats sufficient
<infinity> Yeah, but I don't want squeeze shipping this way either.
<ogra_> ++
<infinity> And as the freeze plods on, exceptions get harder to get approved.
<ogra_> if you actually NMU you could pull armadaxp and highbank in as well, i doubt NCommander forwarded anything of this
<ogra_> saves us carrying a patch
<infinity> I can sync it mostly wholesale, though they don't ship kernels for either one.
<ogra_> (theoretically 80% of the changes since the sync should be pushed into debian in fact)
<infinity> But I guess if f-k supports it, then people could install Ubuntu kernels and it would "just work".  Well, if our kernels didn't depend on packages that aren't in Debian...
<infinity> Friggin' crda crap.
<ogra_> yeah
<ogra_> f-k 3.0 doesnt have any package check anymore
<ogra_> nor subarch
<ogra_> if you just have /lib/modules and /boot/vmlinuz-$version it will work
<ogra_> it is a lot easier on all the checks
<infinity> Anyhow.  NMUing probably won't be necessary.  I don't think Loic actually WANTS to own f-k anymore, he's just stuck with it cause no one else wants it.
<infinity> So, I'm sure adding myself to uploaders and accidentally co-maintaining it will not upset him in the least.
<infinity> I'll ask, though. :P
 * ogra_ would take it but fears the responsibilty and misses DD upload privs
<infinity> And file nasty RC bugs and NMU if he says no.
<ogra_> (fearing the responsibility simply because it supports so much HW i cant even remotely test)
<ogra_> oh finally !
<ogra_> netinst rebooting ...
<ogra_> so that was framebuffer netinst omap4 with working kbd ...
<ogra_> next i'll check server
<ogra_> tsk, the ubuntu on the plymouth text theme splash looks so lost on 1920x1080
<ogra_> ok, all working even after reboot
<infinity> ogra_: It was only server that was broken, netboot was fine.
<ogra_> ah, k
<ogra_> dd is running ... we'll see
<infinity> Somewhere in the anals of time when omap moved to omap4, someone missed symlinking some bits, which we never cared about, cause we never used the d-i "cdrom" images until now. :P
<infinity> Annals, even.  Though, looking at some of the ARM enablement messes that have been made, anals seems appropriate.
<ogra_> infinity, i has keyboard on server framebuffer
<infinity> ogra_: Eggsellent.
<ogra_> :)
<ogra_> hmm, but it doesnt seem to move after kbd selection
 * ogra_ sits in front of an empty violet screen, hoping its just slow
<ogra_> hmm, seems to be cdrom-detect
<ogra_> it lists sda1, sda2, mmcblk0p1 and mmcblk0p2 as possible source devices ... but it only probes for installation media on sda*
<infinity> Really?  It all Just Worked for me before.
<infinity> I can't see how adding HID drivers would have broken it...
 * infinity zsyncs a new image.
<ogra_> yeah, i doubt thats related to HID
 * ogra_ reboots 
<ogra_> "mount: sending ioctl 5310 to a partition!"
<ogra_> thats all i see
<infinity> That's perfectly normal.
<ogra_> and i was wrong, i also have sda3 4 and 5
<ogra_> it seems to stop after sda2
<ogra_> which i think is the partition with the former install
<ogra_> aha, and the processlist shows a mount -t iso9660 /dev/sda3 /cdrom
<ogra_> whcih doesnt seem to proceed
<infinity> Is there something wonky on your USB key?
<ogra_> i just did a netinst ...
<infinity> Well, specifically /dev/sda3
<ogra_> cant imagine that something is wonky with that, it booted and worked fine
<ogra_> thats likely a virtual partition holding sda5
<ogra_> hmpfs and indeed i cant kill the mount
 * ogra_ zreoes the mbr and starts over
 * infinity sloooowly writes a test image out to SD.
<ogra_> aha, now it works
<ogra_> looks like cdrom-detect has a bug
<ogra_> needs to check partition type or so
<infinity> Or your partition tables were just that messed up and weird somehow.
<infinity> But then mount has a bug for hanging. :P
<ogra_> well, d-i created it in the former install
<infinity> (Well, it does anyway, clearly)
<ogra_> i just picked guided partitioning, nothing fancy
<ogra_> oh, wait
<ogra_> iirc we create an ext2 /boot partition (for whatever reason) ...
<ogra_> might be that we dont have ext2 support or so
<infinity> We do.
<ogra_> not in my cat /proc/filesystems here
<ogra_> oh, wait
<ogra_> its there, just not listed near the other ext* ones
<ogra_> k, so its not that, sad, that would have been easy
<infinity> Well, it's reproducible. :/
<infinity> I also have a default install on my USB key, and have a hanging mount -t iso9660
<ogra_> ah, see, loic answered on the bug :)
<ogra_> i *think* we can preseed the filesystem type for cdrom-detect
<ogra_> would be an easy workaround if its the iso9660 bit thats broken
 * ogra_ crosses fingers that his flash-kernel fix works
<infinity> Yeah, but what the heck is it doing? :/
<ogra_> well, what kind of partition is sda3 ?
<ogra_> hardcoding root= in initrd is good because it is consistently broken according to his comment :P
<infinity> Yeah, I read his comment.
<infinity> We'll still want to fix it. :P
<infinity> Anyhow.
<infinity> sda3 is the Extended container, as you guessed.
<infinity> But you'd think this same thing would happen on x86.
 * ogra_ cries 
<micahg> laney: no, it didn't and I'm not sure why
<infinity> Unless mount is fundamentally broken on ARM.
<ogra_> f-k failed it seems
<infinity> ogra_: What did it fail to do?
<infinity> ogra_: It worked for me last night, and it hasn't changed since, has it?
<Laney> micahg: Is that kind of blacklisting supposed to work?
<ogra_> did you test server or netinst ?
<infinity> server
<infinity> Well, both.
<ogra_> live-installer calls update-initramfs before f-k is configured shich makes the world explode
<infinity> But I did server serial once through.  I think.
<ogra_> *which
<micahg> laney: that's how I understood blacklisting, but I could be wrong
<ogra_> i added a live-installer script that diverts u-m until f-k-i runs
<infinity> Maybe I didn't finish server.
 * micahg checks the docs
<ogra_> hmm, and that script isnt there #
<infinity> ogra_: I like how your last upload was just a changelog. :P
<ogra_> err, huh ?
<infinity> http://launchpadlibrarian.net/111061999/flash-kernel_3.0~rc.4ubuntu10_3.0~rc.4ubuntu11.diff.gz
<infinity> Oh, diff doesn't show mode changes, if that was all it was.
<ogra_> sigh !
<ogra_> well, still, you are right it seems
<infinity> Still counting on +x to persist on unpack is still sketchy, you should do that in debian/rules when you install the file.
<Laney> micahg: I see this in the manpage: "It is not intended for the purpose of working around buggy packâ age relationships, and attempts to do so will not work because apt has no way to know about blacklist entries in seeds.
<Laney> "
<ogra_> infinity, well, flash-kernel isnt installed in the environment so the file isnt there
<Laney> that is about "!" entries though, not about the blacklist file
<micahg> laney: ah, it's just for the -meta...
<infinity> ogra_: Did you mean to have it in f-k-i, not f-k?
<ogra_> the prob is that i cant install it manually either
<ogra_> the broken update-initramfs kept the handle on apt-install
<ogra_> so apt-install refuses to do anything
<micahg> it's too bad that the ubuntu-sso-client-gtk drop was only half completed...
<infinity> ogra_: Oh, it is in f-k-i.
<ogra_> yeah
<infinity> But yeah, f-k-i is only installed on-demand.
<Laney> this is fallout from that?
<infinity> All bootloader installers are.
<ogra_> right and only at the end
<infinity> Exactly.
<ogra_> i doubt colin would be happy with me putting the file into live-installer itself though
<infinity> ogra_: What are you actually trying to do here?
<infinity> ogra_: Just avoid f-k running before it's configured?
<ogra_> so i guess i need a f-k-prereq udeb that is always installed or some such
<ogra_> i try to make update-initramfs a no-op
<infinity> ogra_: Okay, but why?
<ogra_> so it doesnt run before f-k is ready to handle it
<ogra_> because f-k-i installs mkimage
<infinity> ogra_: Ultimately, this isn't about initramfs-update, but about f-k, correct?
<ogra_> and without mkimage in place update-initramfs fails
<infinity> ogra_: As in, update-initramfs will trigger f-k, which fails?
<ogra_> it is about ordering of the bits
<ogra_> right
<ogra_> f-k is already in 7target
<ogra_>  /target
<infinity> Kay, we used to work around that by having f-k exit 0 if it wasn't configured yet.
<ogra_> but f-k-i sdidnt run and installed mkimage yet
<infinity> Can we not just do the same thing we used to?
<ogra_> we probably could by putting a flag in place or so but thats ugly
<ogra_> in the past we checked for /etc/flash-kernel.cof
<ogra_> *conf
<ogra_> thats gone with 3.0 ... as any other runtime configuration is
<infinity> Oh, right.  Thanks Loic. :/
<infinity> So, what's there to "configure"?
<infinity> You just mean that the deps aren't there.
<ogra_> apt-install u-boot-tools
<ogra_> or redboot-tools ... or $bootloader-tools
<infinity> ogra_: Isn't the solution, then, to have u-boot-tools in the live image?
<ogra_> seeding it ?
<ogra_> we cant realyl do that subarch based
<ogra_> which means you end up with u-boot-tools on every arm image
<infinity> Erm.
<infinity> It's a live image.
<infinity> Made by livecd-rootfs, I assume.
<infinity> Which knows about subarches.
<ogra_> it is a d-i image
<ogra_> using a squashfs
<infinity> What creates it?
<ogra_> instead of running debootstrap in base install
<ogra_> live-build indeed
<ogra_> but its essentially just debootstrap squashed up
<ogra_> and i dont thinnk there is any removal of packages happening in the whole process
<ogra_> yet
<infinity> We don't want removal, we want addition.
<ogra_> we want removal on subarches the dont use u-boot
<ogra_> *that
<infinity> No, we want to not add it. :P
<ogra_> but yiu cant seed it on a per subarch base
<ogra_> do you wnat to hardcode it in livecd-rootfs ?
<infinity> Dude, we do this all the time.
<ogra_> *want
<infinity> Yes.
<ogra_> ah, k
<infinity> Your image already has other bits in it, I'm sure.
<ogra_> that doesnt really sound like a proper solution, but it will make it work indeed
<infinity> Actually, let me find a livefs log for this.
<ogra_> since f-k is still broken
<ogra_> in context with live-installer
<ogra_> i think the diversion is the better way, but hard to implement without touching live-installer itself
<infinity> It's only broken if the target doesn't have the right bits.
<infinity> So, the target needs to have the right bits.
<ogra_> right, but by design the right bits can only come in at the end
<infinity> ...
<ogra_> yes, which is why we have f-k-i
<infinity> Or, they can be there the whole time.
<ogra_> one way would be to split f-k-i into two parts
<infinity> But okay, the other possible solution is to make live-installer divert things wholesale, and undivert before the final boot-method setup.
<ogra_> having the one that runs the apt-install $bootloader_tools at the beginning and the actual end-configuration at the end
<infinity> Which isn't entirely unreasonable.
<infinity> ubiquity already does this.
<ogra_> yep
<ogra_> thats why colin suggested a diversion to me yesterday
<infinity> Sure, but ubiquity does it for everyone, to avoid multiple update-initramfs calls.
<ogra_> right
<infinity> I don't see why that should belong to flash-kernel.
<infinity> Assuming you can get the divert/undivert timing sane so it doesn't break anything.
<ogra_> because it behaves different from other bootloaders due to supporting multiple subarches
<ogra_> which means different tools packages
<ogra_> unlike any other bootloader
<ogra_> so technically it should ship the fix itself ... for the breakage it causes
<infinity> Yes, but I'm saying the "fix" is also an optimisation.
<ogra_> yes
<infinity> If you don't think of it as having anything to do with flash-kernel. :P
<ogra_> right, but f-k is the only thing being broken due to it
<ogra_> anyway, for now lets "seed" it from live-build so we can get A3 out ... and discuss it with colin once he's back
<ogra_> i dot want to hack up live-installer without him being around
<infinity> Anyhow.
<infinity> Yeah, right now, that subarch stuff in livecd-rootfs is still being respected for -server builds.
<infinity> So, just adding u-boot-tools to the list for omap* would fix you up.
<infinity> Which I'm doing right now.
<ogra_> ah, k, i was doing the same :)
 * ogra_ holds back
<infinity> Also.. Is ti-omap4-ppa still a thing?
<ogra_> and let me revert the f-k stuff at the same time since its useless
<infinity> Didn't we kill that?
<ogra_> we did
<ogra_> remove it please
<ogra_> i was planning a cleanup run after FF
<ogra_> ricardo actually sounded yesterday as if he had a breakthrough with the PVR mess btw
<ogra_> f-k uploaded
<infinity> And livecd-rootfs.
<infinity> ogra_: f-k was just a revert to ubuntu9?
<ogra_> yes
<infinity> Seems sane.
<ogra_> where is queuebot btw
<ogra_> stgraber, ^^^
<infinity> They're not in the queue.
<ogra_> (or does it currently only watch precise)
<ogra_> no but there were other uploads
<infinity> It only watches unapproved/new
<infinity> quantal-* gets accepted, we're not frozen.
<ogra_> ah
<ogra_> i thought we are in a theoretical freeze :)
<infinity> A soft freeze, yeah.  Not one with technology to back it up. :)
<ogra_> k
<infinity> Just social pressure.
<infinity> And ridicule.
<ogra_> heh
 * ogra_ refrains from commenting :)
 * ogra_ grumbles 
<infinity> Hrm?
<ogra_> so the pad tells me i need to reconnect and clicking the button gets me to a 404
<ogra_> yay userfriendlyness
<infinity> Oh, yeah.  It's special.
<infinity> livecd-rootfs built.
<infinity> And f-k built.
<ogra_> great
<ogra_> added info to the pad
<infinity> Publisher doesn't look horribly upset about life, so you should be able to respin again in ~30m, if you feel the urge.
 * ogra_ wonders how we can improve the netboot situation ... there must be a way to name the vfat stuff more descriptive so people dont fall into that trap
<ogra_> intrestingly these files arent even in the MANIFEST
<infinity> -fat-partition or something, maybe.  But it's been named the way it is for so long, I'd rather not break anyone who relies on the names in scripts.
<ogra_> well, alternatively putting a  README in place (generated from the MANIFEST entries) might help
<infinity> Or, people can learn, like you did. ;)
<ogra_> learning ?!?
<ogra_> sigh ... thats hard
<infinity> Making the MANIFEST more descriptive would probably do it, though.
<ogra_> it is very descriptive
<infinity> Including adding some of the missing files.
<ogra_> just doent have any entry for any of the fat files
<ogra_> right
<ogra_> so who drives the isotracker atm ?
<ogra_> wouldbe good to re-enable netinst again so we can log results
<infinity> You're in the right team to do that, aren't you?
<infinity> Or maybe it's locked down to release now.
<ogra_> oh, they are enabled
<ogra_> i asked yesterday morning to drop them, seems that didnt happen, so nothing to revert :)
<infinity> I don't see any...
<ogra_> http://iso.qa.ubuntu.com/qatracker/milestones/226/builds
<infinity> Because I only had "tested" clicked..
<infinity> *sigh*
<ogra_> heh
<infinity> And yay, you have test results to log!
<ogra_> we should lock stgraber and mpt into a room for 1h or so  next UDS
<infinity> But I kinda like stgraber...
<ogra_> LOL !
<ogra_> yeah, might be a somewhat mean plan
 * ogra_ isnt sure what to make out of the USB randomly not working bit from the netboot install
 * infinity wonders why netboot i386 has a ubiquity bug attached to it.
<ogra_> i cant even file a bug without at least having a log or something from when it shows up
<infinity> I did two installs last night and didn't see that.  I guess we'll have to see how reproducible it is.
<ogra_> right
 * ogra_ sets his netboot test to passed for now 
<stgraber> ...
<ogra_> infinity, bug 1028905 in case you want to add something
<ubot2> Launchpad bug 1028905 in cdrom-detect "cdrom-detect in quantal omap4 hangs trying to look for install media on an extended partition" [Undecided,New] https://launchpad.net/bugs/1028905
<infinity> ogra_: Nope, but I'll me too it.
 * ogra_ notices the time and thinnks abut breakfast
<infinity> ogra_: Publisher's done, you can re-spin server if you want.
<Daviey> ogra_: What is the state of arm server images?
<infinity> Daviey: netboot is good, the fancy new d-i/live hybrid thingee needs a respin, but then should be good.
<Daviey> infinity: thanks
<Laney> micahg: so, can we revert your change and release note it?
<ogra_> ubuntu arm server rebuild running
<micahg> laney: revert which change?
<Laney> the blacklist
 * infinity sets an alarm for 34m from now and goes to lie down.
<Laney> oh, hang on, it's not that is it
<micahg> laney: ah, I think I should've used ! instead of the blacklist file for what I wanted...
<Laney> want to consult someone who knows? We can then try again â¦
<micahg> who's the backup seed expert?
<ogra_> backup seed ?
 * ogra_ wasnt aware we had such a thing
<micahg> no, seed expert :)
<ogra_> well, whats your issue ?
<micahg> as in cjwatson isn't around :)
<ogra_> everyone whjo ever uploaded -meta should also be able to at least roughly understand seeds :)
<micahg> I need to stop ubuntu-sso-client-qt and gstreamer0.10-ffmpeg from being pulled into xubuntu
<micahg> ogra_: I understand that part :)
<micahg> I added them to the blacklist file, but germinate still pulls them in
<ogra_> right, i think ! isnt so wrong :)
<micahg> I'm thinking to add them to ! entries in the ship sseeds
<ogra_> though why are they there in the first place ?
<Laney> recommends of webkit
<ogra_> any dep that pulls them in ?
<ogra_> ah
<micahg> ogra_: well, the gstreamer thing is fixed in -proposed, but won't get in in time
<ogra_> i'm not sure you can override recommends of packages through seeds
<micahg> ubuntu-sso-client was a partial transition that really shouldn't have been done before alpha3
<micahg> the only other thing I can think of is temporarily adding a conflicts through the xubuntu-default-settings package or something
<Laney> why isn't gst a problem for other universe flavours too?
<micahg> laney: it is, but no one seems to have cared enough
<Laney> hmm
<micahg> it's on the technical overview
<Laney> I mean that it pulls in libavcodec53 which is !ed out in the seeds
<micahg> hrm, no idea
<Laney> ah, only {l,x}ubuntu have it
<Laney> no, seeded-in-ubuntu lies
<micahg> kubuntu seems to have it also
<ScottK> Which "it"?
<ogra_> that
<ogra_> :)
<micahg> a block on libavcodec
<Laney> libwebkitgtk-3.0-0 recommends gstreamer0.10-ffmpeg depends libavcodec53 which is blocked
<micahg> right, so if I conflict something on gstreamer0.10-ffmpeg, that would temporarily fix it
<micahg> or find more hamsters for the arm* builds
<Laney> and make everyone remove it ...
<micahg> well, idk if it's an issue for an alpha release anyways
<micahg> assuming others don't have the tasksel issue
<hggdh> infinity: (since you fixed it) will the server armhf-omap4 be rebuilt?
<Laney> it just was
 * micahg wonders if hggdh is ignoring queuebot
<ogra_> hggdh, i'm just done with it, feel free to zsync
<ogra_> (praying that fixes the flash-kernel issues now)
<hggdh> micahg: duh, read the download link wrong.
 * hggdh really needs some coffee
<hggdh> ogra_: syncing and testing
<ogra_> great, me too :)
<blitzkrieg3> can I get a sponsor for bug 873027?
<ubot2> Launchpad bug 873027 in unity-2d "DBUS_STARTER_ADDRESS and DBUS_STARTER_BUS_TYPE aren't always unset from environment making gedit and possibly others fail to start" [High,In progress] https://launchpad.net/bugs/873027
<blitzkrieg3> into precise
<blitzkrieg3> s/precise/oneiric/
<hggdh> ogra_: just to be sure, it is the 25.3  image, correct?
<ogra_> hggdh, yep
<hggdh> roj
<stgraber> blitzkrieg3: you might have more luck in #ubuntu-devel. Also, you may want to subscribe ubuntu-sponsors so that the bug shows up on the sponsoring report.
<blitzkrieg3> stgraber: okay, thanks
<ogra_> probably even better in #ubuntu-desktop
<ogra_> bah
 * ogra_ hits bug 1028905 again
<ubot2> Launchpad bug 1028905 in cdrom-detect "cdrom-detect in quantal omap4 hangs trying to look for install media on an extended partition" [High,Confirmed] https://launchpad.net/bugs/1028905
 * ogra_ zeroes the target and tries again
<ogra_> grrr
<ogra_> zeroing the target partition while it is mounted leaves the partition table in place
<ogra_> err target device
<ogra_> nasty bug that is ...
<stgraber> ogra_: you usually need to ask the kernel to re-read the partition table after zeroing (hdparm -z) but that's only possible if the block device isn't in use.
<ogra_> stgraber, yeah, well, i just zeroed it in my desktop , had to kill the installer anyway
<ogra_> i really wonder why nobody else runs into this bug though
<ogra_> i would assume many people use a target device multiple times without seeing the hang
<hggdh> ogra_: is this related to the "unable to find /main/debian-installer/..."?
<ogra_> err, no ?
<ogra_> where do you see that ?
<ogra_> the only two bugs with server i'm currently aware of are flash-kernel (seemingly) breaking apt-setup and the one above
<hggdh> ogra_: on the armhf-omap4 server install -- installation fails because it cannot find any of the Packages or Packages.gz files
 * hggdh goes dd-ing the SD again
<ogra_> hggdh, scroll up in the log, thats not thae cause ... there is likely an update-initramfs run failing above
<ogra_> and apt-install/in-target are blocked through that so apt-setup cant finish
<ogra_> the last upload of livecd-rootfs and flash-kernel should have fixed that though
<hggdh> ogra_: nope, no visible failure relating to initram
<ogra_> i see "/dev/mmcblk0p1 is not a block device"
<ogra_> which is the actual error ... since /dev isnt bind mounted during teh live-installer run
<hggdh> ogra_: not here... but the additional storage I am using had a 12.04 install image
<hggdh> here dev/mmcb* mounts OK (seemingly)
<ogra_> can you put your syslog somewhere ?
<hggdh> ogra_: I will try again and save it. Now both disks (SD and memstick) are already destroyed
<ogra_> k
<hggdh> on marvelous, now I do not have the super key anymore
 * hggdh will try a reboot
 * ogra_ hands hggdh a super key from a spare kbd he has around
<skaet> ogra_, did the last rebuild take care of bug [13] from the pad?
<ogra_> skaet, yes, and shoed another bug
<ogra_> *showed
<skaet> backscroll indicates it may have but.... want to make sure.
<ogra_> but i'm waiting for hggdh's syslog to see we have the same issue
<ogra_> the new live-installer code unconditionally runs an update-initramfs ... thats fine on all arches that dont use flash-kernel ...
<ogra_> but f-k expects some pre-setup to have happened before it can even run the first time
<ogra_> and that setup is usually the very last step on the installation ...
<ogra_> which doesnt really help when tring to use these bits before
<hggdh> ogra_: starting a new install
<ogra_> great
 * ogra_ has a super ugly hackist workaround but that should at least make A3 possible
<hggdh> ogra_: is it expected that the d-i should start straight into the language screen?
<ogra_> yep
<ogra_> we dont have the shiny grub menu stuff or isolinux on arm
<hggdh> ogra_: it went past the error now. I reformatted the memory stick (taking out the 12.04 install media there), and reimaged the SD
<ogra_> oh
<ogra_> weird
<hggdh> different issue now, though, it did not recognise the memorey stick, so rebooting and retrying
<ogra_> hggdh, thats bug 1028905
<ubot2> Launchpad bug 1028905 in cdrom-detect "cdrom-detect in quantal omap4 hangs trying to look for install media on an extended partition" [High,Confirmed] https://launchpad.net/bugs/1028905
<ogra_> zero the device
<hggdh> but it did not hang, it kept on, just telling me I would not be able to repartition the SD
<ogra_> weird
<ogra_> you seem to have very intresting issues over there
<ogra_> here is only fails after live-installer has run ... and i think infinity saw the same
<hggdh> ogra_: not really, I do not match the bug -- I have no extended partition
<hggdh> (I had two partitions before, but I reformatted the memstick to one single, ext4)
<ogra_> ah, well, might be the same bug in a different manifestation ... pleas file a bug with syslog etc
<hggdh> ogra_: against d-i?
<ogra_> it isnt clear yet why cdrom-detect fails at all, might be a kernel issue or mount
<ogra_> hggdh, for now, i'll re-assign then to the right package
<hggdh> ogra_: OK.
<hggdh> ah, I see why it did not get sda -- unsupported optional features (248)
<ogra_> hmm, that shouldnt be fatal though
<hggdh> it is not fatal, installation seems to be able to proceed -- I only do not have the option to install on sda
<ogra_> very strange
<ogra_> skaet, so i have one very hackish and ugly solution to the arm server problem, but i dont really want to upload it until someone like slangasek, cjwatson or infinity have taken a look and nodded it off ... it would give us A3 but i would revert it asap after that again
 * ogra_ points at http://paste.ubuntu.com/1110307/
<skaet> ogra_,  upload it to -proposed, and we don't copy it over to -release if they don't sign off on it?
 * skaet figures that way its building while we're waiting for review....
<Laney> this kubuntu alternate test install is taking some time ...
<Laney> but i confirmed that xubuntu alternate is hosed
 * Laney feeds hamsters to webkit
 * micahg is going to cry, the armel webkit build restarted, so no chance of a copy to release at this point
<ogra_> skaet, it builds in a few seconds, publisher will be the bigger concern :)
<micahg> unless we just copy once the other archs finish
<Laney> it restarted?!
<micahg> yeah, the panda farm has had some weird issues as of late
<Laney> woe
<ogra_> pfft, armel, we really should finally drop that
<Laney> i knew it was having problems at chroot setup time, but not at others
<ogra_> as long as armhf builds i wouldnt worry to much
<micahg> I had a build over the weekend that infinity had to start several times, upload was fri, finshed mon night
<stgraber> ogra_: is something removing that file afterwards?
<ogra_> stgraber, no, else f-k would never work
<Laney> what happens to the copy if all builds aren't finished though?
<Laney> does it work?
<ogra_> it needs to stay in place
<ogra_> 8until f-k -0ubuntu14 lands and a proper fix comes around)
<micahg> well, we can kill the one in -proposed and restart it in the release pocket I think
<stgraber> Laney: if only it'd ;) IIRC it copies the source + any built binaries
<stgraber> Laney: then the remaining binaries are built in -proposed but can't be copied to -release and you can't get them to build in -release as they already exist in -proposed
<stgraber> Laney: tldr, don't do that ;)
<Laney> sigh
<Laney> it'll still be rather late anyway
<micahg> I was going to ask, when's the cutoff for respins?  armhf is 8-11 hours away still
<Laney> I suppose not everything has to release at the same time
<Laney> skaet: ?
<ogra_> surely not the flavours
<ogra_> and we had milestones in the past wehere the DVDs were a week late
<micahg> well, just means the freeze shouldn't be lifted until everyone releases though
<ogra_> which freeze ?
<Laney> sigh, I didn't make the disk image big enough so kubuntu failed for that
<ogra_> :)
<micahg> alpha 3 :)
<ogra_> we dont have freezes :P
<stgraber> ...
<micahg> we still have freezes :)
<ogra_> we have self inflicted social feet calming :P
<ogra_> (technically quantal isnt frozen ... its just nobody uploading)
<micahg> it's a soft freeze, but we expect people to respect it
<Laney> just because we don't have launchpad enforcing it doesn't mean that there isn't a freeze
<ogra_> asdk rick, we dont have freezes :P
<ogra_> *ask even
<micahg> ogra_: that plan is something for the future, as I recall, the consensus was that Ubuntu would like to head in that direction, but isn't ready yet
<Laney> indeed
<Laney> for the current policy see devel-announce
 * ogra_ didnt really plan to discuss that now ... i was just trying to be funny and obviously failed ... 
<Laney> heh
 * micahg hands ogra_ a whoopie cushion
<ogra_> heh
<skaet> Laney,  what's ready for A3 goes out as A3.   For full respins,  we're pretty much past it right now, unless its a true kitten killer (aka linux kernel bug we can't work around).   For selective images,  like armhf, we'll respin up for a bit yet.
<Laney> I'm just wondering if xubuntu can do theirs later and still call it A3.
<Laney> also, what that means for the freeze and turning the dailies back on
<skaet> Once we announce, we swap where the output is directed
<skaet> so,  it will go to the dailies
<skaet> unless we hold up all the dailies...
<Laney> so that's a no then
<skaet> yup.
<Laney> poor xubuntu :(
<ogra_> skaet, oh, and wrt netboot arm i seemingly was mislead, the images are fine (omap4 at least, which i tested) and can be released
<ogra_> so that saves me some paperwork :)
<skaet> Laney,  they've got the dailies and can point folks at that image -  if the dailies are tested, we can probably look at manually copying it over to the A3 publishing directory, so it stays around.
<skaet> ogra_, :)  ack
<Laney> ok
<skaet> Laney, micahg,  what's the timing on all the pieces landing for it?
<Laney> day or so
<micahg> skaet: can probably get the new images built before the freeze to be lifted
<Laney> + spin + validation
<micahg> hrm, I can just do a hack right now so we can respin the images now and not wait...it's not ideal, but should fix the issues
<Laney> not the Conflicts ...
<micahg> hrm, no, that will break existing users
 * micahg thinks harder
<skaet> slangasek, can you give ogra_'s hack a review, and see if we can live with it for A3? http://paste.ubuntu.com/1110307/
<slangasek> ogra_: please put your flag file under /var/lib, not /usr/share, at least
<ogra_> slangasek, ok, no prob
<slangasek> ogra_: and of course, this only ensures tha the package must have been configured *once* before being called... is that sufficient?
<ogra_> the next upload would remove it from apostinst snippet anyway
<slangasek> is there a bug # for this?
<ogra_> for d-i it is
<slangasek> the next upload needs to remove the file too :)
<ogra_> and no, there isnt a bug, we always immediately worked out a fix the last two days
<ogra_> yes, i meant removing the file :)
 * skaet would like the bug number for the pad, since this needs to be tracked to make sure we back it out.
<ogra_> but i should probably file one now :)
<ogra_> just not sure against what
<ogra_> effectively the breakage is caused by console-setup running update intramfs
<ogra_> but live-installer calls it ...
<ogra_> and flash-kernel breaks it
<ogra_> can someone reject my proposed upload so i can re-upload with a change to /var
<micahg> ogra_: it's auto-accepted when not frozen
<ogra_> hey, you just taught me we are frozen :P
<ogra_> *g*
<micahg> we are, it's just not enforced by launchpad :)
<ogra_> ok, i'll bump the versio then
<jibel_> stgraber, bug 1028972 on ltsp, not a3 critical
<ubot2> Launchpad bug 1028972 in ltsp "Empty session menu in ltsp client" [High,New] https://launchpad.net/bugs/1028972
<stgraber> jibel_: oh right, yeah, I saw that one, can't think of how it'd be LTSP's fault, probably a bug in indicator-session or in unity-2d
<ogra_> uploaded
<stgraber> jibel_: marked the ltsp task invalid and commented with some more information on what LTSP does so they have a chance to reproduce it easily
<jibel_> stgraber, ok I added ltsp because I cannot reproduce in another environment
<hggdh> ogra_: bug 1028983
<ubot2> Launchpad bug 1028983 in partman-base "armhf-omap4: a disk formatted with ext4 fails to mount with partman" [Medium,New] https://launchpad.net/bugs/1028983
<ogra_> thx
<ogra_> YIPPIE !
<ogra_> applying the fix manually makes me get through
<stgraber> jibel_: testing a simple testcase for it now
<ogra_> hggdh, dont forget the syslog :)
<stgraber> jibel_: hmm, that's really odd, using Xephyr with the same configuration as LTSP I can't reproduce it anymore... wondering if it's something to do with the graphic card being used
 * ogra_ reboots his panda and crosses fingers
<ogra_> oh, thats odd
<ogra_> seems there is another ordering problem with live-installer
<ogra_> i had the reboot system message .... after confirming it runs "remove-live-packages" now instead of doing the reboot
<ogra_> ah, now it reboots
<ogra_> yippie... a prompt
<ogra_> phew
<hggdh> ogra_: the syslog should be there
<ogra_> i dont see it on the website
<hggdh> ogra_: yeah, LP surprised me, and did not add it in when I filled in the bug. It is now there
<ogra_> yup, i see it but i cant see any error in it
<ogra_> Jul 25 15:20:34 kernel: [  210.396301] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
<ogra_> it even mounts it properly
<ogra_> i guess thats something for dr. watson :)
<hggdh> it does indeed. Go figure :-(
<stgraber> skaet: ltsp-live is busted on Edubuntu, preparing a fix now, will need a respin
<stgraber> Laney: ^
<stgraber> balloons: do you know android-lee? he marked these tests as passed yesterday, but the code is completely broken and there's absolutely no way he'd have been able to test that
<balloons> stgraber, I do know android-lee.. jibel has found something similar in the past
<balloons> I'll have a chat with him again
<stgraber> balloons: can you talk to him? because if that happens again I'll have to disable his account (at least for the images where I'm the product manager)
<stgraber> it looks to me like he's just marking them as pass without even testing, and that's by far worse than not having test results
<hggdh> ogra_: I am reinstalling it again; I can bypass the loop by removing the memory stick and re-inserting it. I want to be sure I can repeat the install (i.e., this is the single issue left)
<ogra_> ok
<balloons> stgraber, yes.. do let me know when it happens
<balloons> I understand the situation is he has access to a large number of machines, which is why he's able to test so much.. However, if his results are incorrect because he's testing improperly (or not at all) that's not helping
<jibel> balloons, he never reports a failure, which to me seems unlikely if he is really testing, and adds no value to his testing
<balloons> https://bugs.launchpad.net/~android-lee -- indeed so it appears
<jibel> 927 results without a single failure. stop all dev we have the perfect release.
<balloons> jibel, heh.. I have been talking to him, because my guess is that he is testing improperly since I wasn't seeing many bugs (when I found some in the same images).. This is concerning however that he's never reported any!?, and that we have confirmation of success when it clearly was impossible
<balloons> I'll keep you and stgraber informed..
<hggdh> ogra_: is this known? http://pastebin.com/uzB8xkBS
<hggdh> ogra_: I just retagged the test as failed. I cannot repeat the install
 * hggdh is off for lunch
<stgraber> skaet: uploading edubuntu-netboot directly to the release pocket. I'll kick the Edubuntu rebuild (will update the pad in a sec)
<stgraber> uploaded
<skaet> stgraber,  ack
<skaet> Laney,  slangasek,  ^ FYI
<ogra_> hggdh, whats known ? your paste seems to be a bunch of encoded stuff
<ogra_> skaet, can flash-kernel be moved over to the release pocket so that we can re-roll arm server ?
<skaet> ogra_,  ok.   can you do the move?
<ogra_> i'm not an archive admin
<skaet> slangasek, ^ you around,  or should I go experiment.
 * skaet goes to start experimenting.
<stgraber> ogra_: you don't need to be an AA for that btw :)
<micahg> ogra_: you can do the copy, just not the deletion in -proposed
<ogra_> where is the doc ?
 * ogra_ didnt know 
<shadeslayer> so if someone can help out *just* a little bit, I might have EFI booting from a USB stick working in time for alpha 3
<micahg> ogra_: it's generally not a good idea for most people to do this type of copying, but in this case, it doesn't make a difference
<shadeslayer> I was wondering why init looks for /dev/sr0
 * micahg wonders if sru-release -r will DTRT
<ogra_> micahg, right, my question is rather "how ?" :)  i didnt even know thats possible for non AAs
<shadeslayer> because I get to grub, I can boot stuff, but init fails while looking for /dev/sr0
<stgraber> lp-shell production devel
<stgraber> archive=lp.distributions['ubuntu'].archives[0]
<stgraber> archive.copyPackage(from_archive=archive, include_binaries=True, source_name="flash-kernel", to_pocket="release", to_series="quantal", version="VERSION")
<stgraber> ogra_: ^
<stgraber> ogra_: just replace VERSION and that should work fine
 * ogra_ installs lptools
 * micahg still thinks sru-release -r would be simpler if we knew it to work
<ogra_> hmm, https://launchpad.net/ubuntu/+source/flash-kernel/3.0~rc.4ubuntu14 still says proposed
<micahg> ogra_: it worked
<micahg> that might take a publisher cycle to update
<stgraber> ogra_: copyPackage is async, can take a few seconds for LP to update, then it'll appear for both quantal and quantal-proposed until an AA cleans up -proposed
<ogra_> great
<micahg> :q
<stgraber> ogra_: quantal-changes and your mailbox are usual good indicators to whether the copy worked ;)
<ogra_> oh, ah
<ogra_> heh
<ogra_> my mail is async, it takes a while to arrive :P
 * skaet comes back to the channel after digging in some docs, sees its been handled :)
<ogra_> skaet, so after the next publisher run arm server is good to go
<skaet> ogra_ ok,   I'll kick it off.
<skaet> (when i see all the bits in the right place)
<ogra_> awesome ! :)
<skaet> ogra_,  what was the bug number for flash-kernel?
 * skaet wanting to get the pad updated so we don't forget this needs to be backed out.
<stgraber> skaet: ltsp's failing post-install on Edubuntu, checking if I can fix that in edubuntu-netboot, so no rebuilt yet please (I updated the pad)
<skaet> stgraber,  yup.  seen the updates.     will only do an arm server rebuild.
<skaet> (and thanks for putting the updates in!  :) )
<highvoltage> stgraber: ok
<highvoltage> (oops, stgraber was telling that to skaet, I have 'edubuntu' highlighted and sometimes that confuses me)
<utlemming> stgraber: can you kindly add http://cloud-images.ubuntu.com/quantal/20120725 to the tracker?
<stgraber> utlemming: sure
<utlemming> stgraber: thank you kindly
<stgraber> Can't find: eu-west-1-amd64-hvm
<stgraber> utlemming: ^ is that a new one?
<utlemming> stgraber: yes sir, brand new
<stgraber> ok, so I guess it needs some setting up on the tracker before I can publish that one
<utlemming> hvm was added to eu-west ~3 weeks ago
<stgraber> ok, pushing again, should only be adding the missing entry
<stgraber> infinity: https://code.launchpad.net/~stgraber/ubuntu-archive-tools/add-eu-west-hvm/+merge/116721
<skaet> ogra_ have kicked off the arm server build for armhf+omap4
<hggdh> ogra_: sorry, gave you the wrong link. Here it is, installation fails on configure the package manager: http://paste.ubuntu.com/1110679/
<ogra_> hggdh, no, its the bug thats fixed with the new images (hopefully) ... see line 825 and 826
<ogra_> everything below is fallout of in-target not properly returning
<Laney> that ^ is the fix for [18]?
<hggdh> ogra_: I thought it might be, but the bug is sort of short in details, and I wanted to be sure
<stgraber> skaet: found a couple more bugs in Edubuntu LTSP. Uploading a new edubuntu-live now fixing these. Will be ready for a respin after that one.
<stgraber> (apparently somebody synced ldm from Debian at some point during alpha-2 and alpha-3 breaking Edubuntu in a very subtile way ;))
<ogra_> Laney, heh, someone only copied the last changelog entry :)
<ogra_> the actual fix is the one before
<skaet> stgraber,  ok.
<Laney> please to be updating :-)
<ogra_> err ... s/fix/horrible horrible hack/
<hggdh> OK, burning the new image
<skaet> ogra_, hggdh,  you've spotted that the image has posted....
<skaet> :)
<skaet> yup.
<skaet> ogra_,  what did the bug number for it end up being?
<hggdh> skaet: heh
 * skaet --> get some lunch,  biab
<ogra_> skaet, bug 1029083
<ubot2> Launchpad bug 1029083 in flash-kernel "ordering issue when flash-kenrel is used with live installer" [High,Triaged] https://launchpad.net/bugs/1029083
<ogra_> i'm not sure it wont turn into a live-installer bug though
<slangasek> I think it's a facet of a general issue
 * slangasek reads the bug
<ogra_> the missing /dev bindmount is definitely something going wrong in there
<slangasek> ah
<slangasek> what's the failure mode?
<ogra_> mode ?
<ogra_> run-parts in update-initramfs fails which makes post-base-installer.d/25live-installer-console-setup fail ... which in turn makes in-target not return properly (?!?) ... the next in-target call makes the world explode
<ogra_> thats also the reason why hggdh sees the error during apt-setup and not during live-installer
<slangasek> hmm, interesting
<ogra_> looks like at least three bugs
<ogra_> missing /dev bindmount, in-target not returning, flash-kernel running even though its unconfigured
<slangasek> and 25live-installer-console-setup only calls update-initramfs?
<ogra_> i think so
<slangasek> you might want to compare with /etc/kernel/postinst.d/zz-update-grub
<ogra_> grub has a config it can check for etc
<slangasek> except that's a *kernel* hook, and you're talking about an initramfs hook
<slangasek> ah
<slangasek> so fixing the lack of config for flash-kernel would fix this too? ;)
<ogra_> flash-kernel currently doesnt leave any trace of being configured
 * slangasek nods
<ogra_> right, see bug 1026780 thats related
<ubot2> Launchpad bug 1026780 in flash-kernel "3.0~rc.4ubuntu4 doesn't honor bootargs from /boot/boot.script anymore" [High,New] https://launchpad.net/bugs/1026780
<ogra_> once we have the config dir we can check it for content and know there is a default config
<slangasek> ogra_: how does flash-kernel know what device to install to?
<ogra_> it has a database
<ogra_> based on the output of /proc/cpuinfo
<slangasek> ...
<ogra_> namely the Hardware: field
<ogra_> it is tricky to find a generic way to get HW info if you dont have a dim ;)
<ogra_> *dmi
<slangasek> I would've thought this would be configurable
<ogra_> i think debian once picked the smallest denominator and that stuck
<ogra_> all configuration is done in the DB
<ogra_> which is just a textfile
<slangasek> ok, so I think a stamp file in /var/lib may actually be appropriate even in the long term
<slangasek> there may be other bugs that also need fixing
<ogra_> well, we will need a bootscript.d (or something similar)
<slangasek> for boot params?
<ogra_> we cant ship something that always reverts user configs on package updates
<ogra_> yeah
<slangasek> right
<ogra_> and if thats there we can easily have a check if the default bootconfig was copied in place
<ogra_> that will make the /var stuff obsolete
<hggdh>  ogra_: just to add insult to injury, my new install stopped at the beginning, with a kernel oosp on slow-path
<slangasek> so I think the right way of this would be to have a single /etc/default/flash-kernel file with your boot option information; and this file is generated at package install time; so if the file exists you know it's configured
<ogra_> hggdh, ouch !
<slangasek> but the /var/lib/ stamp file is definitely an ok interim solution
<ogra_> ok
<ogra_> hggdh, thats a bit odd, given the image is pretty identical to the last one
<ogra_> only the flash-kernel package should have changed
<hggdh> ogra_: I retried, taking out the memory stick (the to-be /dev/sda). I did not see the oops, and installation is going on
<ogra_> weird ... but i was suspecting USB issues ... i had one today too that went away after i powered off the board once ... same image worked fine the next try
<hggdh> matches a bit of what I am seeing -- not always being able to reproduce
<ogra_> as long as the kernel slightly works i wont complain though i rather see paolo invest his time in the 3.5 port than spending to much on the current kernel we will likely not ship
<ogra_> though it should be tracked down indeed
<ogra_> it might be related to bug 746137  which shows up again after we switched the image type
<ubot2> Launchpad bug 746137 in jasper-initramfs "Page allocation failure on Pandaboard and Beagle XM" [Undecided,Fix released] https://launchpad.net/bugs/746137
<ogra_> (preinstaled had a tool where we coudl easily dump sysctl.d bits in that were applied during resize ... thats gone so the issue is back)
<ogra_> i have seen this bug with various NICs and wlan cards and also have seen it affecting USB stability in general before (not on a panda yet though)
<Laney> ogra_: could that cause the machine to crash?
<Laney> I've been seeing my panda going away every couple of days and kern.log is filled with that kind of stuff
<Laney> -rw-r----- 1 syslog adm 2.4G Jul 25 20:54 kern.log
<Laney> ...
<ogra_> Laney, it can eat your ram
<ogra_> yay, the germinate fix is in
<Laney> I set vm.min_free_kbytes. We'll see...
<ogra_> good luck :)
<hggdh> ogra_: update_initramfs still barfs
<ogra_> barfs as in "kills the install" ? or barfs as in "makes some log noise" ?
<hggdh> prints out "installation will most likely be broken" and keeps on. But it seems it lost the network
<ogra_> these seem unrelated
<ogra_> i would blame USB for the network :)
<ogra_> as long as it moves on, dont worry
<hggdh> what me worry?
<ogra_> lol
<ogra_> this update-initramfs run is totally bogus anyway
<ogra_> the actual initramfs you will use will be created at the bootloader setup time
<ogra_> (and that one will be usable, i promise) :)
<hggdh> if I reach that point, you mean ;-)
<ogra_> i suppose you will ... i reached it with my last test install when making flash-kernel just exit 0 at the top
 * ogra_ finds it funny how update-initramfs runs three times in a row ... always with the message "deferring update (trigger activated)"
<ogra_> but still building a new initrd indeed
<hggdh> uh-ho. sequence of tcp_recvmsg errors in the log
<hggdh> recvmsg bug: copied yadda yadda
<ogra_> that smells very much like 746137
<hggdh> darn!
<hggdh> OK. if nothing else works, power it off, count to 10, power it on again
<ogra_> no promises ... just guessing here :)
<ogra_> if you prefer to find a new bug ...
<hggdh> I will be more than happy hitting a known bug, thank you
<hggdh> now I deleted the partition for /dev/sda, no lockups on start (so far)
<stgraber> skaet, Laney, slangasek: starting the Edubuntu respin now
<skaet> stgraber, ack
<slangasek> stgraber: ack
<Laney> gogogo
<infinity> ogra_: I haven't read all of backscroll, but saw the pastebinned f-k "fix".  I assume you've sorted out by now why it'd bad?
<infinity> ogra_: s/it'd/it's/
<infinity> ogra_: Oh, no, you uploaded it. :/
<infinity> ogra_: So, that just broke every upgrade and every system not installed with f-k-i.
<slangasek> oh, that was being done in the flash-kernel-*installer* postinst?  sigh
<slangasek> sorry, reading fail
<infinity> slangasek: If it was in the f-k postinst, it still wouldn't DTRT, since f-k is installed during the livefs build.
<slangasek> ah
<infinity> (But yeah, in this case, it was f-k-i)
<infinity> I'm trying to sort out what problem he was trying to solve with this.
<slangasek> infinity: flash-kernel being called via update-initramfs before it's usable
<infinity> slangasek: I guess installing u-boot-tools was determined to not be sufficient somehow, then?  *sigh*
<slangasek> I only know what scrollback and the bug report say
<slangasek> u-boot-tools was not mentioned
<slangasek> there was some issue with /dev not being bind-mounted, though
<infinity> slangasek: Hrm.  Well, it looks like it's only the /dev mount missing that's the issue, from the log, unless I'm missing something critical.
<slangasek> infinity: see any obvious root cause?
<infinity> slangasek: But the better and saner answer is probably violently diverting update-initramfs in live-installer.
<blahdeblah> Hi.  Can anyone tell me why http://changelogs.ubuntu.com/meta-release-lts doesn't list precise as an LTS?
<slangasek> blahdeblah: so that users aren't automatically upgraded from lucid to precise until 12.04.1 comes out
<stgraber> blahdeblah: my guess is that this is the file being checked by the upgrader and we don't allow upgrades until the point release
<blahdeblah> So that is intended behaviour?
<stgraber> yes
<stgraber> 12.04.1 will appear on there when the point release is released, on the 23rd of August
<jbicha> blahdeblah: I think you can run update-manager -d if you want to upgrade 10.04 to 12.04 before .1 is released
<blahdeblah> Cool - thanks for the help folks.
<hggdh> OK, finally, a working install of server on a pandaboard
<infinity> As in, a respin with ogra's hack worked for you?
<hggdh> no, it did not. What seems to work (still to confirm) is to have /dev/sda with an empty partition table (so ogra_'s hack does not seem to fully work)
<infinity> Well, ogra's hack didn't relate to partition tables at all.
<infinity> Two entirely different bugs.
<hggdh> but I had a truckload of different errors
<hggdh> sorry, ogra's original bypass
<hggdh> as in bug 1028905
<ubot2> Launchpad bug 1028905 in cdrom-detect "cdrom-detect in quantal omap4 hangs trying to look for install media on an extended partition" [High,Confirmed] https://launchpad.net/bugs/1028905
<infinity> Maybe the solution to the bootloader issue is just to not install flask-kernel in the livefs at all, and let f-k-i do its job...
<infinity> flash-kernel, even.
<infinity> Would need icky special-casing just for server. :/
<ogra_> infinity, nah, lets just implement bootscript.d or as slangasek suggested use /etc/default/flash-kernel
<ogra_> then we can have a check if its configured and make it gracefully exit
<slangasek> neither of which actually seem to solve the problem
<infinity> ogra_: It's not being "configured" in the first place, though.
<slangasek> if flash-kernel is installed in the livefs, *everything* that would indicate configuration is there too
<infinity> ogra_: It's configured from the point it's installed, you're pretending it's not because something else on the system is broken.
<ogra_> how about making live-installer simply divert update-initramfs and remove that diversion at the end is recreating the initrd actually necessary in that step ?
<ogra_> i really cant see a reason for running it at that point of the install
<infinity> It's just a postinst from a package it's installing in /target
<infinity> Not a deliberate call to update-initramfs.
<ogra_> it is called three times here
<slangasek> it's necessary to ensure you've generated an up-to-date initramfs before the end of the install; it is not necessary to generate one at each package install along the way
<ogra_> but yeah, its a postinst trigger that runs it
<slangasek> *however*, it's *also* necessary to ensure there's an up-to-date initramfs before you do things like calling the kernel package hooks on x86
<slangasek> since that's where grub.cfg gets generated
<slangasek> and this is not at all congruent with what flash-kernel does
<infinity> Well, flash-kernel is a bit weird with good reason.
<ogra_> no, definitely not
<slangasek> flash-kernel is "when a new initramfs is generated, call flash-kernel so it gets written to the right disk."  grub is "when a new kernel is installed, update the grub config".
<slangasek> see, they're so different they don't even agree on whether end-sentence punctuation belongs inside the quotes or outside
<ogra_> *grin*
<slangasek> so aside from this one bug of /dev not being correctly bind-mounted, everything else is probably just an optimization
<slangasek> and for now we should probably focus on fixing the /dev bind mount rather than further hackery on live-install or flash-kernel
<ogra_> well, flash-kernel needs changes in any case, but for that bug fixing the bindmount will suffice
<infinity> (And please revert the previous two f-k revisions)
<ogra_> hmm, the tracker isnt up to date it seems
<ogra_> infinity, with sugar and kisses
<infinity> Thankfully, with only f-k-i dropping that file places, I guess we don't need to worry about cleaning the unowned file up on upgrade.
<infinity> Cause, like, 3 people have it.
<ogra_> oh, and it also still says preinstalled on the tracker, hmm
<stgraber> sounds like a case where nobody created the non-preinstalled variant on the tracker, so it doesn't auto-publish there
<ogra_> well, intrestingly enough the build number has been updated up to 20120725.1
<ogra_> (last preinstalled was in june)
<stgraber> hmm, either post-qa on nusakan needs some tweaking or somebody updated it manually ;)
<ogra_> someone did ... but i cant remember who
 * ogra_ checks irclogs
<stgraber> ogra_: oh, I see... someone renamed the product on the tracker but didn't hack post-qa, so post-qa has no clue where to post the new build
<ogra_> ah, k
<stgraber> ogra_: hmm "Added build (20120725.4) with ID: 19500" so it auto-posted fine, and I see 20120725.4 on the tracker at the moment... what are you looking at ? :)
<ogra_> stgraber, right, it showed up right now
<ogra_> http://iso.qa.ubuntu.com/qatracker/milestones/226/builds/19500/testcases
<ogra_> that still says preinstall
<ogra_> (minor thing indeed)
 * ogra_ adds his result and finally calls it a day
<stgraber> yeah, balloons or someone else will have to deal with the testcases. We probably want to keep the preinstall testcases for < quantal (so history is consistent) and then have a regular set of server testcases for >= quanal
<skaet> ogra_,  are you trying to do the f-k reverts  and the /dev bind mount, today/early tomorrow.  or are we giving up on the arm server for A3?
 * skaet can't quite figure plan from backscroll...
#ubuntu-release 2012-07-26
 * skaet --> EOD
<babyface_> anybody know why there is no Quanta  build on July 25 ?
<micahg> babyface_: we're working on alpha 3, the dailies are on hold until it's released
<micahg> babyface_: alpha 3 images available for testing on the ISO tracker
<babyface_> micahg,  ack.  thanks
<slangasek> skaet: the discussion in scrollback is principally about how and why the fix ogra applied this morning isn't correct; but we knew already that it wasn't correct when he uploaded it
<slangasek> skaet: and it doesn't appear that there were any further problems with flash-kernel once installed
<slangasek> indeed, I see a 'pass' on server armhf+omap4
<infinity> Yeah, it works right now, but that version of f-k should be reverted, since it breaks upgrades.
<infinity> So...
<infinity> We either fix the root problem, or we're shipping a broken f-k just fot A3 to "fake" the test results?
<slangasek> the wrong f-k is already in the archive; there's no burning need to fix that between now and tomorrow
<infinity> No, I'm just not sure it's doing us any favours to have a broken f-k in the archive just for the sake of having a pass on an image, when it's something we wouldn't actually want to ship.
<slangasek> I think it's more the sake of having installable images, A3 or otherwise
<slangasek> can we just get to the bottom of the /dev issue, and /then/ revert it?
<infinity> That does seem vaguely sane, yes.
<slangasek> ok
<slangasek> then I don't think there's anything here that jeopardizes A3
<infinity> Obviously, something (bind-)mounts /dev into /target later in the install process, or all the bootloader installers would explode, so probably just need to hunt that down and judiciously cargo-cult it into live-installer.
<infinity> Or base-installer.
<infinity> Or something.
 * slangasek nods
<infinity> Time to do a full Debian d-i checkout of doom, I think, so I can grep more effectively.
<infinity> slangasek: Oh, it could just be a question of moving some code 20 or 30 lines up in live-installer.postinst. :P
<slangasek> neato
<infinity> I'll have to look over logs again and make sure that's sane, but if it is, I'll commit and upload something later tonight.
<infinity> Maybe after I've had some breakfast.
<slangasek> I recommend the skirt steak with chile relleno
<infinity> Or whatever meal it is when you realise you've forgotten to eat for ~20h.
 * micahg wonders where infinity is that it's breakfast now
<stgraber> micahg: you're assuming timezones vaguely apply to infinity ;)
<slangasek> micahg: he's copying your meal schedule, obviously ;)
<micahg> heh
<infinity> micahg: I'm infinite, which places me in every timezone.  And every restaurant.
<infinity> No wonder I'm getting fatter.
<infinity> micahg: (PS: I'm raiding your fridge right now)
<micahg> infinity: heh, joke's on you then :)
<infinity> Yeah, say.  Where do you keep the bacon cheeseburgers in this joint? >:(
<micahg> unless you like tofu and rice tortillas
 * micahg thought webkit on armhf would be done by now, but it'll take another 12 hours
<infinity> I need to figure out how to incorporate peanuts into bacon cheeseburgers, so that they become not just religiously offensive, but also deadly.
<slangasek> eew
<stgraber> skaet: ^ boots, installs and still boots, good enough for a3 unless something major shows up.
<micahg> infinity: well, for some people, just being around peanuts is deadly
<infinity> There's something invigorating about eating food that you know can kill a rather large segment of the population.
<slangasek> that's why I subsist on a diet of rattlesnake meat
<micahg> infinity: does the death have to be immediate?
<infinity> Rattlesnake only kills when it's alive. :P
<infinity> (Also, it's pretty tasty)
<infinity> micahg: I dunno.  Anaphylaxis is pretty dramatic.  "I got a tummy ache and then died 30 years later from a steadily imperfect diet" is somehow less cool.
<slangasek> you could invent supergluten
<micahg> umm, we already have that
<slangasek> we have supergluten?
<infinity> Wonderbread?
<slangasek> that's just superlative quantities of regular gluten
<jbicha> infinity: you could just be muslim for a month, fast during the day, feast at night
<slangasek> I want supergluten
<micahg> slangasek: http://www.adm.com/en-US/Milling/Glutens/Pages/Supergluten80.aspx
<slangasek> made from horses
<infinity> jbicha: I'd need a better beard.
<slangasek> heh
<slangasek> micahg: that's beautiful :)
<slangasek> Color: Light tan
<infinity> I wonder if it has a theme song.
<infinity> Right, enough of this silliness.  Breakfast calls.  Then debian-installer redux.
<babyface_> jamespage,  hi James, are you around?
<jamespage> babyface_, here now
<babyface_> jamespage, some test failed in Jenkins on quantal server - minimal virtual    http://10.98.0.1:8080/view/Quantal/view/ISO%20Testing/job/quantal-server-amd64_minimal-virtual/72/#showFailuresLink
<babyface_> jamespage, could you help to have a look on it ?
<jamespage> babyface_, minimal virtual is broken atm - there is already a bug and it should be release noted for alpha3
<babyface_> jamespage,  ack.   could you give me the bug number ?
<jamespage> babyface_, bug 1028453 - its linked off the ISO qa tracker
<ubot2> Launchpad bug 1028453 in ubuntu-meta "Quantal Ubuntu Server minimal install oversized" [High,New] https://launchpad.net/bugs/1028453
<babyface_> jamespage, got it!  thanks!
<babyface_> jamespage, have a nice day! ;)
<jamespage> np
<infinity> slangasek: Hrm, there might be a reason the live-installer postinst is broken the way it is, given that the setup_dev waypoint was intentionally commented out.  I'm not sure I feel confident trying to fix this blind before A3 and without consulting Colin, since I don't see much of a window to really test what it breaks to make the (seemingly) obvious fix.
<ogra_> infinity, well, i would rather have looked for the breakage in in-target or the way its called
<ogra_> iirc it can mount proc sys and dev
<infinity> There's no "in_target" for lots of this.
<ogra_> oh my
<ogra_> k
<ogra_> ah, and the doc say in-target only automounts proc and sys
<ogra_> *docs
<infinity> Also, if we fix d-i to DTRT here, we need to scour everything that thinks it doesn't. :P
<infinity> (like the flash-kernel-installer postinst, for instance...)
<ogra_> fun :/
<infinity> This may be why setup_dev is commented out.  It might have cause issues in other packages trying to do it themselves.  Dunno.
<infinity> Anyhow, I'm going to try to sleep while it's dark.  Cause I hear that's what normal people do.
<infinity> Wish me luck. :/
 * ogra_ does so
 * ogra_ finds it funny that none of these scripts check if /dev is already bindmounted ... i wonder with how many /dev mounts you actually end up in a normal install
<henrix> infinity: not sure if you're already on it, but lucid kernel packages need override fixes (#1027831)
<psivaa> apw, infinity, ogra_   ./install/netboot/ubuntu-installer/i386/pxelinux.cfg/default file failed MD5 checksum verification for A3 quantal-server-i386
<psivaa> occurring when i 'check disk for errors'
<ogra_> netboot "check disk for errors" ??
<ogra_> what disk would it be supposed to check on a netboot install ? you dont have any source media
<psivaa> its check disk for defects in usb installation
<ogra_> oh, sorry, i was mislead by the path
<ogra_> file a bug against debian-installer
<psivaa> ok will do thanks :)
<Laney> hmm
<Laney> Riddell: you don't want ppc images?
<Riddell> Laney: I don't but others in the kubuntu community take a "if someone tests them why not" attitude
<ScottK> \o
 * ScottK is one of those people.
<ScottK> So far we got testers, some at the last minute, for at least the final images.
<Laney> ok then
<Laney> perhaps you could edit the manifest: https://wiki.ubuntu.com/QuantalQuetzal/ReleaseManifest
<Laney> also to confirm that you want alternates
<ScottK> Is that the Alpha 3 manifest or the one for the release?
<ScottK> I think in the end we don't want alternates, but that's dependent on Ubiquity work that's not done yet.
<ScottK> Riddell: Mind if I add the PPC ones?  I'm fine with putting myself down as sign off contact, so you needn't be bothered.
<Riddell> ScottK: go ahead
<Laney> AFAIK there's only one manifest
<Laney> you're supposed to decide what you want finally by FF
<ScottK> Added powerpc.
<ScottK> The alternates are already listed with an appropriate note, so I think we're good.
<Laney> yep. I thought you'd decided to keep them, but if it's correct alreay then more's the better. Thanks.
<skaet> good morning Laney
<Laney> howdy
 * skaet goes to stare at the iso tracker, and pad
<Laney> can't see anything that's going to move
<knome> good luck with that, and i hope you'll win the no-blinking competition
<skaet> knome,  apparently so,   looks like Xubuntu didn't get respun while I slept
<knome> skaet, awwh
<Laney> webkit still isn't finished
<Laney> if armel didn't get restarted then it probably would have been this morning
<skaet> knome,  did you want the desktop ones to go out at least?
<skaet> ie. are they usable enough for developers?
 * skaet knows alternates are no hope until the respin
<knome> um, you should ask micahg...
<knome> :)
<knome> or maybe pleia2
<jibel_> testing report published on the wiki https://wiki.ubuntu.com/QATeam/ReleaseReports/QuantalAlpha3TestReport
<skaet> knome, ?   thought you were xubuntu lead this cycle...   did I miss something?
<skaet> jibel_,   thanks!  :)
<knome> skaet, i am, but unfortunately i'm not quite knowledgeable with the current situation - i've been away quite a lot lately :)
<skaet> Laney,  am not seeing ScottL/scott-work online,   the Ubuntu Studio images haven't been tested at all,  can you help me figure out if someone's going to test them,  or if they're a no ship for A3.
<Laney> I'll go ask in their IRC channel
<astraljava> skaet: Laney: I intend to give either one a spin in a few hours.
<Laney> astraljava: Oh OK. Do you fancy asking in the channel then to see if anyone else wants to do it? It would be good to have results sooner rather than later.
<skaet> astraljava, ok, if you make it in before the announce we can include them.    Won't hold it up though at this point.
<astraljava> Laney: Just did, waiting for answers.
<Laney> thanks
<astraljava> skaet: When were you planning to announce?
<skaet> astraljava,  trying for before EOD in london,  since we need one of the folks there to help with the web side.
<astraljava> skaet: Excellent, since I'm two hours ahead, it'll give me some time.
<skaet> astraljava,  key word in there was "before".  :)   we'll leave it late binding then.
<skaet> knome,  can you make sure that the Technical Overview has the key feature changes listed then for Xubuntu.
<astraljava> Sure.
<Laney> skaet: so I can mark as ready the ones which have all mandatory tests done and nothing concerning in the rport?
<skaet> Laney,  yes
<skaet> thanks. :)
<slangasek> infinity: ok - leaving live-installer as-is for now, then?
<ogra_> slangasek, we could probably just add a bindmount right before the dpkg-reconfigure console-setup in post-base-installer.d/25live-installer-console-setup
<ogra_> that would only wrap the one call that breaks
<slangasek> which sounds like another kludge?
<ogra_> well, at least it wouldnt break other scripts if adam thinks generally having it mounted is bad
<slangasek> we already have a kludge in place; we don't need more kludges, we should understand what should really be happening and upload that
<micahg> laney: gst-plugins-bad0.10 is still on images ATM :(
<skaet> ogra_, can you add to the https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview/Alpha3 a note on how to bring up arm server in the known issues part.
<ogra_> skaet, sure, np
<skaet> ogra_ ,   thanks.   will you be reverting those last two fixes,  so when we turn on the dailies again, we don't cause problems with the hacks?
<Laney> micahg: woe indeed, but it won't cause any problems at this point
<Laney> skaet: what about images with only one mandatory test uncompleted?
<Laney> like kubuntu which are missing wubi
<skaet> Riddell,  ScottK,  ^  what do you feel comfortable letting get released on these.
<Riddell> skaet: yes I'm fine with that
<ScottK> Personally, I call "missing wubi" a feature.
<ogra_> skaet, that will make the images uninstallable until another fix is added, if thats fine i can upload to proposed immediately
<Riddell> but I guess I should work out how to get wubi tested before beta
<Riddell> ScottK: you don't like it?
<ScottK> Riddell: Since all it does now (AIUI) is point you to the web site to download the real wubi, it seems somwhat pointless.
<ScottK> Also, I've never been convinced it's worth all the trouble it causes.
<ScottK> It could be that more people use it than I suspect though.
<Laney> http://testcases.qa.ubuntu.com/Install/DesktopWubi
<Laney> it's that
<skaet> Laney,  at this point,  since its Alphas,  if the leads recommend it as ok,  and if there's been some testing we'll let it go out with the alphas,  things start to tighten up for the betas,  since they're not targetted at developers.
<Laney> ok
<Laney> Daviey: Server OK from your side?
<ogra_> make sure to not release the other side then :)
<utlemming> Daivey: Cloud Images are good to go
<micahg> skaet: so, webkit is done on all archs except for armel, that'll be another 7.5-15 hours, since it's alpha3, I don't know if it's worth it to play around with the builds to get alternates
<micahg> are we on track to get rid of the alternates this cycle
<skaet> micahg,  last I heard from slangasek,  yes.   But he'll know more than me.  ;)
<skaet> micahg,  so do you want to let Xubuntu desktop out as is?  and put some comments in the release notes?   or punt on shipping for this release?
<micahg> skaet: I think it's fine for alpha with release notes
<skaet> micahg,  ok,   can you add now,  and I'll go mark up the iso tracker.
 * micahg thought pleia2 and knome did that already
<skaet> vanhoof,  netboot for highbank hasn't been tested,  any data from your team?
<Laney> micahg: I think skaet means that the release notes are still TODO
<Laney> albeit with astraljava's name
<skaet> thanks Laney,  yes micahg,  release notes about the issues still left (in known issues section).
<utlemming> saket: Cloud Images are ready for release
<skaet> thanks utlemming  :)
<hggdh> ogra_: how do I reinstall a panda after being installed? if I take out the memstick (/dev/sda) I get dropped to busybox
<ogra_> you write the image newly to SD indeed
<ogra_> at least the first partition
 * skaet dropping i386 Server from list,  see release notes. 
<Laney> oh, I read that as saying that they wanted it in A3
<Laney> but were declaring it unofficial
<skaet> Daviey,  arsoales - MAAS (juju and server) tests haven't been marked as run for the amd64 server image.   any data sitting elsewhere?
<skaet> Daviey,  do you want us releasing i386 server image or not as part of A3?   seems to be some confusion.
<cody-somerville> Is arsoales intended to be a pun?
<skaet> *sigh*  typo on my part
<skaet> arosales, ^
<Laney> hahaha
<arosales> skaet: I'll follow up wth roaksoax. I think he had been doing some work around this area. I will confirm.
<skaet> thanks arosales
<arosales> skaet: re dropping i386 for server for A3 let go ahead and proceed (pending any objections from Daviey) in order to get feedback from users.
<skaet> thanks arosales
<Laney> proceed with having it?
<skaet> proceed with dropping it
<arosales> sorry proceed with dropping i386 for A3
<Laney> dropping it in order to get feedback doesn't seem to compute
<Laney> except to collect complaints?
<arosales> Laney: I believe Daviey announced on the -devel list, would also like to get feedback for A3 if folks are missing it
<Laney> ok then
<arosales> so yes to get feedback on it being a large disruption to users
<arosales> rather than waiting for the beta
<arosales> at least that was the thought
<Laney> fair enough
<Laney> so for server, just waiting on remaining tests for amd64
<Laney> not sure about desktop armhf+omap4
<Laney> ogra_: any thoughts? have you tried it?
<hggdh> Laney: trying the manual partition, just had the panda turn off DVI and completely lock, will reboot and try again
 * arosales is posting and update for MAAS testing.  MAAS in quantal that is currently broken pending https://code.launchpad.net/~andreserl/maas/bzr777_packaging_updatesÂ 
<Laney> sentence or two on the release notes would be welcomed
<ogra_> Laney, yes, i had logged my results too
<ogra_> good to go
<skaet> arosales,  please add it to the known issues for server then too.
<arosales> skaet: will do
<Laney> hggdh: fun
 * hggdh is starting to hate pandas
<ogra_> hey, they are endangered animals !
<skaet> ogra_, some of the manditory tests haven't run for arm desktop,  hggdh is looking into one right now,  but there is another without results, so not so sure its good to go...
<micahg> hggdh: try feeding them bamboo
<ogra_> skaet, ah, well ... imho its good to go, but if you guys insist :)
<hggdh> I think cyanide broth would be better
<skaet> ogra_  feel free to take it up with QA if you think the tests shouldn't be mandatory ;)
<ogra_> seriously, its an alpha release, if there is *a* way to install that works it should be fine, even though if others might have issues
<skaet> ogra_ its a matter of warning folks too about known issues,  which the manditory tests do expose.
<ogra_> for aplhas i'm personally happy if accepting the defaults results in a working system, everything beyond that are nice to have, bug should be filed and fixed but that shouldnt be a blocker
<skaet> ogra_ if the test would result in a corrupted system,  probably want to know that and then make a decision to release or not.
<ogra_> if it did that i would release note it :) but definitely not block the release ... for a beta i would be more strict ...
<ogra_> anyway, not my call :)
<hallyn> hggdh: for bug 1029201, is that blocking a milestone?  Should the fix go to quantal or to quantal-proposed?
<ubot2> Launchpad bug 1029201 in qemu-kvm "qemu-system-x86_64 crashed with SIGSEGV in virtio_pci_mask_vq()" [Critical,In progress] https://launchpad.net/bugs/1029201
<Laney> the release will happen pretty soon, so there won't be a freeze for much longer
<hggdh> hallyn: it is only blocking my usage of qemu-kvm; I think -proposed is OK
<hallyn> hggdh: thanks
<hallyn> Laney: how soon?  a few hours?
<Laney> at most a couple I guess
<hallyn> Laney: ok, thanks.  i'll wait then rather than cause overhead with having to copy out of proposed
<hggdh> skaet: Laney: there is hope for manual partitioning on omap4 desktop, finally installation is proceeding
<skaet> thanks hggdh.  :)
<slangasek> skaet, micahg: we are, shall we say, doing our best to get rid of alternates this cycle; but none of the code has landed yet so it's a bit early to say yes/no
<bdmurray> slangasek: how does this look? https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/979661/comments/29
<ubot2> Ubuntu bug 979661 in update-manager "oneiric to precise: debconf: unable to initialize frontend: Gnome and falls back to Dialog" [Critical,Fix committed]
<bdmurray> or anyone
<skaet> astraljava,  are you going to be able to get to ubuntu studuio amd64?  or should we just release with i386?
<astraljava> skaet: If you can give me 1.5 hours, I can confirm, or is that too late already?
<skaet> astraljava,  go ahead and confirm.   we're close, and its likely to be ok, if the other one is.
<astraljava> skaet: Actually, it seems that it is just about done. Please for a few more minutes for resukts.
<skaet> astraljava, :)   I like that answer.   you have your minutes
<astraljava> Please wait*, funny how I can't multi-task efficiently, was on the phone.
<ScottK> No one can multi-task efficiently.  It's a myth.
<skaet> server has all tests run and those not passing have bugs, so marking it ready now.
<astraljava> skaet: Studio can be marked ready now.
<skaet> thanks astraljava.
<astraljava> ScottK: True, I've seen some footage on tests for that. People drive like idiots on tracks when speaking on the phone, even with hands-free.
<astraljava> skaet: Have you received release notes from Studio, from Scott L?
<skaet> astraljava,  https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview/Alpha3 has them.   I think someone else put them in this time.
 * skaet just happy they're there. ;)
<astraljava> Well, me too, obviously. These new contributors seem to rock plenty. :)
<skaet> indeed.  :)
<slangasek> bdmurray: looks good to me
<infinity> slangasek: Yeah, I think leaving it be until post-A3 is sane, and then we can experiment a bit with what the right answer is.
<ScottK> Does anyone other than the not present cjwatson have experience unbreaking MoM?   It died a week ago.
<pleia2> ok, I think I'm done making edits for xubuntu on the release notes
<skaet> thanks pleia2 :)
<hggdh> skaet: desktop armhf-omap4 is good to go
<skaet> thanks hggdh
<Daviey> skaet: ack, dropping i386 for this milestone
 * ogra_ hugs hggdh 
<ogra_> thnaks for the effort !
<hggdh> ogra_: welcome :-)
 * hggdh hugs ogra_ back, and jots down the need for a beer next UDS
<ogra_> ++ !
<ogra_> hggdh, arent you at the QA sprint next week ?
<hggdh> ogra_: yes. You will be there?
<ogra_> yeah,m we can have it there then :)
<hggdh> s/next UDS/next week/g
<hggdh> :-)
<bdmurray> Is it okay for me to apporve an upload to -proposed that I sponsored?
<micahg> bdmurray: no
<micahg> you can verify it though :)
<bdmurray> Actually I'm not positive I uploaded it...
<micahg> bdmurray: you should have an e-mail saying waiting for approval if you did
<ScottK> That or check the signature on the changes file.
<micahg> that would be more reliable than e-mail :)
<bdmurray> this? http://launchpadlibrarian.net/110566856/parted_2.3-8ubuntu5.1_source.changes
<bdmurray> there is no signature
<ScottK> Or the .dsc
<ScottK> I don't think it gets stripped from that.
<ScottK> Signature stripping is a security feater.
<ScottK> (but it only applies to .changes)
<stgraber> bdmurray: hey there. I just noticed that lxc is kind of broken once the fix in bug 974584 lands... I'll now push a matching lxc SRU to precise-proposed so you can accept both at the same time and both can land in -updates in the same batch (or container creation will fail)
<ubot2> Launchpad bug 974584 in sysvinit "Semaphores cannot be created in lxc container" [High,In progress] https://launchpad.net/bugs/974584
<stgraber> bdmurray: (the fix will also land in quantal later today as part of a bugfix uploaded by hallyn)
<stgraber> bdmurray: lxc fix uploaded now. Would greatly appreciate if you could review sysvinit and lxc today as creating quantal containers on precise is currently broken (that's breaking my daily QA tests)
<bdmurray> stgraber: I'll try
<stgraber> bdmurray: thanks
<Laney> slangasek: is a source daily something we should spin?
<Laney> publish-images gives me a line to publish them, but apparently it does not exist
<skaet> Daviey,  stgraber ^ any thoughts?
<stgraber> I'm wondering exactly what Laney is trying to do and what he's running :)
<Laney> so you run publish-images.py
<Laney> and at the end it gives you this: for-project ubuntu publish-release source current src no alpha-3
<stgraber> because I believe at this point he sound be running publish-image-set from ubuntu-archive-tools, but the script is broken (working on fixing it now)
<stgraber> *should
<Laney> yeah, that
<Laney> it's not that broken :P
<Laney> anyway that line errors out
<stgraber> ERROR: Cannot handle product Ubuntu Desktop Preinstalled armhf+ac100
<stgraber> aren't you getting that one?
<Laney> yep, but I hacked it
<stgraber> oh, I see the source bit... weird, never noticed that before :)
<Laney> yeah. what is it?
<stgraber> looks like the last time it was built was for 12.04's release
<Laney> stgraber: how are images synced to the cdimage.u.c machine?
<Laney> is there a cron job?
<stgraber> IIRC one of the scripts triggers a rsync back from the various cdimage machines
<Laney> right
<stgraber> so considering we haven't had a source build for a1 or a2, I wouldn't worry about a3 ;)
<Laney> cool
<infinity> sync-mirrors syncs the mirrors.
<infinity> publish-release even helpfully reminds you to run it.
<Laney> yeah.
<Laney> Want to make sure nothing automatic was going to do it.
<infinity> Nope.
<infinity> It only get automagically called from image building.
<infinity> s/get/gets/
<elmo> why is there a 12.10 directory on releases.u.c ?
<elmo> with some arm thing
<elmo> ubuntu-12.10-no-preinstalled-desktop-armhf+ac100.bootimg and friends
<skaet> Laney, ^
<Laney> where?
<Laney> it's probably me cocking it up
<Laney> although I didn't sync anything yet.
 * skaet notes that all the results are now in for A3 on the iso tracker
<stgraber> bdmurray: thanks!
<elmo> Laney: it's on acai at least - not all machines
<elmo> Laney: which is alarming in of itself
<elmo> looks like it came across in a sync a few hours ago
<Laney> I invoked the script wrong for that image
<Laney> surprised that it synced it though ...
<infinity> Well, uninvoke and sync. :/
<infinity> (I suppose it's not critical, no one's polling releases.u.c for new ac100 releases and getting excited, I'm sure)
<infinity> But, yeah.  Is it fixed on nusakan?
<Laney> yes.
<slangasek> Laney: so yeah, we should have a source image built... dunno why it doesn't exist
<stgraber> Laney: I "think" this is the fix we need for publish-image-set: http://paste.ubuntu.com/1112420/
<utlemming> Cloud Images are published
<stgraber> Laney: hmm, I might be missing something, the publish path for server on arm looks wrong with that patch
<stgraber> infinity: one more for you, https://code.launchpad.net/~stgraber/ubuntu-archive-tools/fix-preinstalled-images/+merge/116943
<stgraber> Laney: ^ that one gives me the output I'd expect
<Laney> nice
<balloons> stgraber, looks like all the precise download links are broken
<infinity> stgraber: Has that server publishing change been discussed somewhere?
<balloons> the syntax is http://cdimage.ubuntu.com/precise/daily-live/ not http://cdimage.ubuntu.com/daily-live/precise. I started manually updating them, but that's silly.. can you script a change/
<balloons> ?
<stgraber> balloons: yeah, I should be able to script a change, I believe I have a python script I used to do something like that in the past
<stgraber> balloons: probably not today though
<balloons> stgraber, right no worries
<balloons> just a heads up :-)
<stgraber> infinity: what change? all I changed for server is make the armhf images publish at the same place as the i386 and amd64 ones
<infinity> stgraber: Yeah, that's a change...
<stgraber> infinity: I believe this wasn't a problem in that past as daily-preinstalled was hardcoded to ubuntu-server/daily-preinstalled, but daily-live didn't have it hardcoded
<slangasek> Laney: shall I nuke the 12.10 stuff from www/simple?
<Laney> please
<slangasek> done
<Laney> double check the image diff for me?
<stgraber> infinity: so I'm just trying to have the server daily armhf publish under the same product as the server preinstalled armhf used to
<infinity> stgraber: Alrighty.  Merging.
<Laney> given previous cock ups I'm now scared to push it
<slangasek> Laney: we should really be archiving off the alpha-1 and alpha-2 stuff; dunno why this wasn't already done at alpha-2 time
<slangasek> is that in the checklist somewhere?
<stgraber> infinity: I "think" the logic is right and the output looked sane here, but these scripts as such a mess of mapping dicts and regexps that I'm never sure I didn't miss a corner case...
<Laney> yes it is
<slangasek> "if there is a previous milestone [...]" yah
<slangasek> we don't have particularly good scripting for that part
<slangasek> shall I?
<Laney> goferit
<Laney> will sync-mirrors delete that borked thing on releases?
<slangasek> grr, the alpha-1 directories are all owned by the wrong user
<slangasek> elmo: ^^ who should I pester about this?  uid 3237 doesn't even have a name, but owns all the alpha-1 dirs, so I can't move them away for archival
<Laney> it's probably tiaz; he was fixing something for me
<Laney> will check with him
<slangasek> ok
<slangasek> alpha-2 is all moved, anyway
<Laney> slangasek: 26/07 20:24:49 <tiaz> fixed
<slangasek> yay
<slangasek> Laney: so the diff looks like what I expect, but I never used that www.prev and don't know whose idea it was to add it to the publish-image-set script :)
<Laney> heh
<Laney> I like the safety net
<slangasek> I don't find it provides much safety because the diff is too large to eyeball
<Laney> it lets you go back to the old state in case of problems
 * Laney shrugs :)
<Laney> just 'sync-mirrors'?
<slangasek> are the HEADER.html supposed to be updated manually?
<Laney> yeah, the script gives you seddery
<slangasek> full/releases/quantal/alpha-3/HEADER.html doesn't look updated yet
<slangasek> will you do the seddery?
<Laney> there we go
<ogra_> heh, nice, ac100 made it to /release ?
<Laney> probably because I did it and then regenerated that ac100 image correctly
<Laney> ogra_: It's the most important!
<ogra_> heh
<Laney> slangasek: good to go then?
<slangasek> Laney: looks good to me!
 * Laney has The Fear
<Laney> just sync-mirrors?
<slangasek> Laney: yep
<slangasek> skaet: ^^ are we ready to announce?
<skaet> slangasek,  yes
<slangasek> ok
<Laney> hmm
<Laney> I got errors from some hosts
<highvoltage> 444343
<Laney> highvoltage: the winning lottery numbers?
<knome> skaet, the tech overview was done already. i left astraljava there if there was something me and pleia2 missed.
<jbicha> precise-dailies have -proposed enabled by default?
<micahg> at this point
<highvoltage> Laney: tbph I don't know what that was
<highvoltage> (but it was during a dying ssh connection)
<Laney> I bought a ticket, I'll let you know.
<highvoltage> Laney: good luck!
<skaet> knome,  thanks its good now
<knome> skaet, yes, as i imagined :)
<knome> just wanted to get back to you - unfortunately today was again bad day for being available online :)
<phillw> skaet: is there an ETA for the links at https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview/Alpha3#Download_the_Alpha_3 goin live?
<phillw> *going*
<skaet> phillw, its in progress.   I'll send out the email when I know they're good
<phillw> thanks, I've got my finger hovering over the send button for the Lubuntu team :)
<slangasek> Laney, skaet: is cloud image publishing already dealt with?
<Laney> slangasek: utlemming said so
<slangasek> okie
<slangasek> just double-checking since I hadn't seen - thanks :)
<ScottK> micahg: Doesn't enabling proposed by default largely defeat the purpose of using proposed?
<micahg> ScottK: well, it'll be switched when we get closer to 12.04.1
<infinity> ScottK: precise images will ... what he said.
<ScottK> Right, but even now.
<micahg> the idea is to catch issues as early as possible
<stgraber> ScottK: we need that to test d-i fixes, udeb fixes, ...
<ScottK> I thought the point of proposed was to keep archive skew from hitting people.
<Laney> not in stable releases
<ScottK> Yes, but in quantal.
<infinity> Well, that's also a nice side-effect of proposed in stable releases.
<ScottK> Agreed.
<infinity> But the real point is testing crap before we break everything.
<ScottK> Oh.  Right.  I forgot it's the new Unstable.
<ScottK> And -release is Testing.
<infinity> None of this is about quantal...
<ScottK> OH.
<ScottK> Sorry.
<infinity> jbicha asked about the precise dailies.
<infinity> Which have proposed on.
<ScottK> Nevermind.
<infinity> (for now)
<ScottK> Right.  Makes complete sense for that.
<ScottK> Too much Alpha 3 on the brain.
<infinity> That scrubs right off.
 * ScottK <-- Emily Litella
<infinity> I think you just dated yourself.
<micahg> heh
 * Laney googled it
 * micahg too
<ScottK> Certainly, but it's not like I hide being ancient in FOSS terms.
<skaet> slangasek, can you check and see if you can get the torrents to work?
<slangasek> skaet: tracker is rejecting my torrent request; I think this needs an IS poke?
<Laney> how do the torrents get added to the tracker?
 * skaet nods and goes to poke.
<slangasek> Laney: supposed to be part of sync-mirror
<Laney> well I did see magellanic in there, which is torrent.u.c
<stgraber> yeah, as I said to skaet in a private discussion, the torrent box had a pretty hard time reading the images for alpha1
<stgraber> it took hours for it to hash all the files and start seeding
<stgraber> though, that was after IS also had to kick the bittorrent process as it was somehow stuck
<Laney> oh, hashing, of course
<skaet> have put a ping into IS
<Laney> great
<Laney> skaet: can lift the freezes now
<Laney> (I would say)
<skaet> Laney,  yes,  back to business as usual.
<Laney> an op will have to fix the topic here
* ChanServ changed the topic of #ubuntu-release to: Quantal Quetzal Alpha 3 prep in progress... | Archive: open | Quantal Quetzal 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 birdseed | melior malum quod cognoscis
<Laney> probably shouldn't say Alpha 3 either :-)
<skaet> Laney,  won't change that until the email goes out  ;)   Was hoping to just do one update,  but seems not meant to be.
<Laney> also, can we fix the oversize limits?
<infinity> I thought we did.
<infinity> I guess not. :P
<Laney> do you get the daily emails?
<infinity> Nope, I took myself out of the list years ago.
<Laney> ah, well they currently say that $world is oversized
<infinity> Yeah, I see the red text all over daily-live/current/ :P
<Laney> we should stop calling it a CD there too :P
<skaet> Laney,  yeah, its on my list to do in a quiet moment.
<Laney> not so urgent indeed.
<Laney> isotracker.conf switched back
<Laney> enabled dailies again?
<Laney> s/d//
<skaet> Laney,  yes please.
<Laney> done
<skaet> Laney,  I just switched the iso tracker back to Dailies as well, and move A3 to released.
<Laney> yeah, you got there before me :P
<skaet> milestone alpha 3 disabled
<skaet> Laney,  can you see if the torrents will work for you now?
<stgraber> skaet: still not working here btw
<skaet> thanks stgraber.
<skaet> *sigh*
<infinity> If it takes "hours" to hash all the ISOs, asking 30m later probably won't make it be done. ;)
<infinity> And, on a lighter note, quoting from livecd.sh, which I'm now cargo-culting to live-build configs:
<infinity>     # End horrible linux-header launchpad workaround.  Hopefully this is temporary.
<infinity> Temporary, my ass.
<skaet> indeed.
<Laney> skaet: nah, not yet. I guess we do indeed have to wait.
<skaet> ok,  torrents seem to be working,   time to declare this release announced ;)
 * skaet hits send on email.
<skaet> Thanks Laney!
<Laney> only 2 armel buildds?
<tumbleweed> I see omgubuntu jumped the gun by a few hours :) http://www.omgubuntu.co.uk/2012/07/ubuntu-12-10-alpha-3-released (20:23 UTC)
<infinity> Laney: I'm doing some mangling.
<stgraber> tumbleweed: that never happens ;)
<infinity> Laney: Will be less crap soon.
<skaet> tumbleweed,  oh,  they always do that.    rather rude, but ....
<Laney> infinity: Righto.
<tumbleweed> exactly :)
<skaet> tumbleweed,  its when they get the download links wrong it gets really irritating... ;)
 * Laney giggles at the links to the (then) broken torrents
<ScottK> tumbleweed: That's hardly news.
* ChanServ changed the topic of #ubuntu-release to: Quantal Quetzal Alpha 3 prep released! | Archive: open | Quantal Quetzal 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 birdseed | melior malum quod cognoscis
<Riddell> whee
<skaet> Laney,  can you handle the announce in #ubuntu-devel?
* ChanServ changed the topic of #ubuntu-release to: Quantal Quetzal Alpha 3 released! | Archive: open | Quantal Quetzal 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 birdseed | melior malum quod cognoscis
<micahg> webkit armel is almost done 2 days later :-/
<Laney> just in time
<Laney> oh. oh wait.
<skaet> ...  ?
<Laney> it's the build that we needed for xubuntu alternates
<micahg> yeah
<micahg> so, xubuntu skipped alternates for alpha3
 * skaet nods
<skaet> phillw,  we're released now.
<phillw> skaet: I saw the release areas go live, so I had guessed. but, as ever, thanks for informing me.
<skaet> phillw,  goodness.   :)   your welcome.
<phillw> as we get closer to final release, we will have all the fun of different so called 'news' sites announcing it :)
<phillw> I prefer your system, of getting all the mirrors synched up & then announcing it :)
<stgraber> rebuilding a set of alternates for precise, want to check if I get the right kernel in /pool then
<stgraber> (d-i expected -27 but pool contained -26)
<infinity> micahg: That's because it built twice.  Sorry about that. :/
<infinity> micahg: Blame TI.
<micahg> infinity: heh, yeah, I know
<utlemming> is changelogs.ubuntu.com out again?
<infinity> micahg: We're working on it.  This is annoying me far more than you. :P
<utlemming> I'm seeing missing changelogs
<Laney> utlemming: checked a couple that were ok
<micahg> well, once webkit is copied over, component-mismatches should shrink by a nice bit
<utlemming> laney: http://changelogs.ubuntu.com/changelogs/pool/main/b/bind9/bind9_2.4-1ubuntu0.1/changelog and http://changelogs.ubuntu.com/changelogs/pool/main/l/landscape-client/landscape-client_0.7.25.3ubuntu9.13/changelog are missing
<Laney> I like the webkit node on the SVG
<Laney> its own way of saying "yeah, you probably did it wrong"
<micahg> heh, yeah
<Laney> utlemming: those version numbers don't seem right?
<utlemming> yeah, your right, it looks like my text parser is doing it wrong
<infinity> Quite wrong. ;)
<stgraber> infinity: what am I missing? AFAICT precise alternates are building with the d-i from -proposed which uses -27, linux-image is -27 on the media but the kernel udebs are all -26...
<stgraber> so not too surprisingly, d-i is complaining that it can't find its kernel modules udebs
<infinity> stgraber: On a CD, or a netboot?
<stgraber> infinity: cd
<infinity> Well, I was about to suggest that your CD might not be building against proposed, but -27 is in updates now.
<infinity> The d-i image itself is correctly all -27-
<infinity> I can't even fathom where -26- is coming from in your case.
<infinity> stgraber: Oh.
<infinity> stgraber: Let me fix.
<stgraber> infinity: what was it?
<infinity> stgraber: Seeds.
<stgraber> good, matches my interpretation of the build log. Didn't know the seeds needing updating though, so will be good to know next time something like that happens ;)
<stgraber> so now I know where the "Allowing d-i kernel versions:" comes from, one less blurry step on the whole CD build process.
<infinity> And added highbank to the precise seeds too.
<infinity> All better.
<infinity> stgraber: Life should be more pleasant now.
<stgraber> ok, respinning
<infinity> I assume (I hope?) that debian-cd uses a fresh checkout of bzr for germinate, and not some cronned mess.
<infinity> * Fetching branch of http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.precise/
<infinity> Good, good.
<infinity> It uses fresh seeds.  Should be happy, then.
<skaet> infinity,  cron job still has  buildlive ubuntu-server daily-preinstalled && for-project ubuntu-server cron.daily-preinstalled,   should this be removed now?
<skaet> also,  did ogra_  upload his reverts, or are we going to have problems?
<infinity> skaet: His stuff isn't reverted yet, we want to fix live-installer first.
<infinity> skaet: As for removing server preinstalled, I'm sure that's planned, I'm not sure if all the parties who need to agree to it have come to that conclusion yet (I've been staying out of the CD game this month...)
<skaet> infinity,  ack.
<skaet> thanks
<infinity> Well, as out of things as I can stay.  People keep pulling me back in. ;)
<infinity> stgraber: This kernel headers hack is going to be even uglier in live-build than it was in livecd.sh.  Special.
<infinity> Can we just retroactively fix germinate and regen all the Packages files for precise instead?  Thx.
<stgraber> as long as it's understandable, works and gives me smaller cds, I don't care how ugly it's ;)
<infinity> Awesome.  I'll do it in lisp.
<infinity> Actually, lisp would be really good at this sort of thing.
<infinity> Please don't tell live-build upstream that.
 * infinity shudders.
<stgraber> success! latest alternate build looks good. Now to spin kubuntu alternate so I can actually verify that SRU :)
<infinity> stgraber: \o/
<phillw> stgraber: do not forget that the lubuntu testers are always 'game for a respin', and will even go test other flavours if it is for the better good.
<nm_geo> true that
<phillw> hiyas nm_geo :)
<nm_geo> hi phillw
<phillw> nm_geo: good news about Ron wanting to come on board :)
<nm_geo> Yes sir he has some good MAC kits
<nm_geo> I mean yes Phillw.. did it again huh?
<slangasek> could I bother an AA to review efilinux/amd64 in quantal unapproved?
<infinity> slangasek: Did you have a specific AA in mind?
 * infinity tries to sort out why it's in unapproved in the first place...
<slangasek> infinity: it's in unapproved because that's where it lands before launchpad signs it
<infinity> slangasek: As in, every raw-efi upload needs approval?
<slangasek> yes
<infinity> slangasek: That's a bit... Odd.
<infinity> But okay.
<slangasek> infinity: because anybody can upload one
<slangasek> so the AA is our security check
<infinity> Ahh, there's that.
<infinity> stgraber: Oo, I think I have a more elegant solution.
#ubuntu-release 2012-07-27
<infinity> I freakin' win.  Much nicer.
<infinity> stgraber: That live-build in -proposed should fix your kernel headers sadness, I believe.
<infinity> stgraber: I uploaded the same to quantal, if you'd like to watch a quantal daily run or two to make sure it DTRT.
<infinity> stgraber: (Or, to watch it do not much of anything, I suppose)
<stgraber> infinity: I'll take a look. I supposed that the fact that we're building with -proposed enabled for the livefs won't magically make the builders use the live-build from proposed right?
<stgraber> (which would be quite convenient to very the SRU)
<infinity> stgraber: I can't recall if we asked IS to enable proposed in the livefs chroots or not, TBH.
<infinity> stgraber: But when the time comes, we can ask either if that's so (it might be), or if they can upgrade live-build.
<ScottK> slangasek: Is the raw efi stuff for AA's to do documented?
<slangasek> ScottK: not in the least
<slangasek> ScottK: where do you think we should document this?  wiki.u.c/ArchiveAdministration?
<ScottK> I was thinking there.  yes.
<ScottK> Unless there's something that's sekrit.
<slangasek> nah
<slangasek> it's just early days and therefore undocumented
<ScottK> I suspected as much.  Best to start writing it up from the beginning before infinity's just cargo culting because he always did it that way before.
<ScottK> ;-)
<slangasek> ScottK: done,https://wiki.ubuntu.com/ArchiveAdministration#Raw_UEFI_uploads
<ScottK> Thanks.
<ScottK> Wow.  Built on all archs faster than I could review the next source.
<seb128> could somebody get larsu in ubuntu-community-contributors so he get tracking on status
<seb128> skaet, ^
<brendand> skaet, release meeting today?
<jibel> skaet, is it planned an Ubuntu chinese edition for 12.04.1 ?
<ScottK> stgraber: FYI: I've got two more issues that should be gotten to for 12.04.1 - Bug #1029640  and Bug #1023550.  I expect to have them uploaded today and don't anticipate any delays due to verification.
<ubot2> Launchpad bug 1029640 in python2.7 "Bad characters in Python logger output when using rsyslog" [High,Fix released] https://launchpad.net/bugs/1029640
<ubot2> Launchpad bug 1023550 in postfix "Postfix missing libresolv in chroot jail" [High,In progress] https://launchpad.net/bugs/1023550
<stgraber> ScottK: both look like things we want fixed indeed and we still have enough time to verify these and get them to -updates, so all good. Thanks for the update
<Daviey> skaet: I mostly won't be at the release meeting, clashing call.
<Daviey> arosales: ^
<skaet> brendand, Daviey,  I'm cancelling the release meeting today,  day after release, and nothing immediately urgent for next week to discuss.
<Daviey> wfm :)
<ogra_> skaet, awesome !
<skaet> seb128, larsu's been added
<seb128> skaet, thanks
<arosales> Daviey: that worked well for you :-)
<Daviey> arosales: yes sir!
<jibel> stgraber, during manual upgrade testing I found bug 1029531. I think it should be fixed for 12.04.1
<ubot2> Launchpad bug 1029531 in update-manager "cdromupgrade from Lucid to Precise failed with unmet dependencies without network connection" [Undecided,New] https://launchpad.net/bugs/1029531
<stgraber> jibel: hmm, do you know what package is missing on the media? the logs don't make it easy to figure out
<jibel> stgraber, no I didn't investigate it yet.
<stgraber> jibel: so, short answer is, yes, I think this should be targeted to the point release, but we'll need to know what's the source of the problem and see how we can deal with that
<jibel> stgraber, ack assigning to foundation for the moment
<stgraber> jibel: it might involve having to SRU some dependency fixes to lucid or precise or change some cleanup logic in update-manager or even (and I certainly hope not), seed some extra stuff to make the upgrade possible
<stgraber> jibel: sounds good
<stgraber> sru team: bug 1018579 being a race but milestoned to the point release, I'm going to do a standard install of dovecot and check that it works as expected, review the diff again and consider it verification-done if I don't see anything wrong
<ubot2> Launchpad bug 1018579 in dovecot "dovecot panic" [Critical,Fix committed] https://launchpad.net/bugs/1018579
<stgraber> slangasek: around?
<stgraber> slangasek: my understanding of bug 988819 is that the fix is now limited to just the two apache plugins and that's how I've been testing them. Shouldn't apache2 itself be pulled from -proposed?
<ubot2> Launchpad bug 988819 in modsecurity-apache "[SRU] wrong path to libxml2.so.2 in mod_security - broken by multiarch enabled libraries" [High,Fix committed] https://launchpad.net/bugs/988819
<stgraber> it's making testing harder as it contains the old fix that was then discarded (bug task is marked invalid)
<slangasek> stgraber: I hadn't been tracking that SRU; if the module package has been reuploaded with a more self-contained (and IMHO more sensible) fix, then yes, we should withdraw apache2 from -proposed
<slangasek> stgraber: removed
<stgraber> thanks
<bjf> slangasek, (or any AA) can you accept my kernel packages in the upload queues? (natty & lucid)
<slangasek> sure, looking
<slangasek> bjf: this may be the first time I've done this part of it; is this supposed to be a binary sync, or a source only sync?  LP shows me only a single item in the queue so I'm not sure how to interpret this
<slangasek> (I suspect https://wiki.ubuntu.com/ArchiveAdministration#Copying_PPA_kernels_to_proposed is not at all current)
<bjf> slangasek: it should be a binary sync
<bjf> slangasek: it's a "pocket-copy" from our ppa
 * slangasek nods
<slangasek> well, I hope this is right then, since LP won't show me any details :)
<slangasek> accepted
<bjf> slangasek: what could go wrong? :-)
<slangasek> bjf: it could be a source-only sync and we'd have to wait for the kernels to be built anew... so no big deal :)
#ubuntu-release 2012-07-28
<infinity> slangasek: When you play kernel SRU monkey, you should update tasks in the tracking bugs (and, in the case of ABI bumps, fix overrides when the packages all land in the wrong places).
<infinity> slangasek: I've done both for you.
<slangasek> infinity: right; I had meant to double-back and look at ABIs after the binaries landed but didn't get to it, so thanks
<infinity> slangasek: *nod*... If nothing else, twiddling the tasks as soon as you accept is helpful, cause if you forget to do the overrides, the bot will yell at you later. ;)
<infinity> slangasek: But it won't do its scan-and-be-grumpy dance until someone twiddles the copy task.
<slangasek> infinity: where are the necessary bug-twiddling changes documented?
<slangasek> pending-sru points at https://wiki.ubuntu.com/ArchiveAdministration#Copying_PPA_kernels_to_proposed, which doesn't seem to apply anymore
<slangasek> when the kernel team sync, the *only* thing you get in the queue is an ack/nack button on the sync
<infinity> That does kinda mention tracking bugs, but yeah, it doesn't seem to mention what to do about them. :P
<infinity> And yes, syncs are very opaque, it's a known misfeature in LP.
<infinity> Ideally, not only would they be more transparent, but they'd also let us override in the queue.
<infinity> I do believe there are bugs open for both.
<slangasek> ah right; I skimmed over that section of the instructions on account of it not having any useful links, and me not having a useful .changes file :)
<infinity> That wiki bit should probably be updated to have a reference to http://status.qa.ubuntu.com/reports/kernel-bugs/reports/sru-report.html
<infinity> Which nicely hilights tracking bugs (the magnifying glass), and such.
<slangasek> thanks for volunteering to update it ;)
<infinity> I'm allergic to wikis.
<infinity> (opening the editor window...)
<infinity> I can't help but think the kernel team had this all documented somewhere...
<infinity> Oh, right, https://wiki.ubuntu.com/Kernel/kernel-sru-workflow
<infinity> (As referenced in every tracking bug)
<slangasek> right
<slangasek> the tracking bug I couldn't find ;D
<infinity> Check.
<infinity> slangasek: There, have some "I'm not a tech writer" documentation.
<infinity> I'm tempted to just tear the whole section out and replace it with a few lines.
<infinity> "Reports here, if broken, fix overrides, don't do bad things, if do bad things, fix bad things."
 * slangasek grins
<seb128> ^ sorry about the nux screwups, GUADEC internet fail, I uploaded several times because it didn't seem to go through
<seb128> rejected the extra ones, that should be sorted out
<seb128> or ^ (bot lag)
#ubuntu-release 2012-07-29
<infinity> ^-- Seems to suffer some quoting issues in quantal, testing locally and fixing before I reupload. :/
<stgraber> well, at least these were spotted before it landed in precise ;)
<infinity> stgraber: That was why I uploaded it to quantal too. ;)
<infinity> This'll teach me to not have a BuildLiveCD setup on my laptop.
<infinity> (Rectified now, and testing)
<infinity> I do so appreciate that colin cargo-culted my 0c3.net local mirror setup in livecd-rootfs when he did the live-build switch. :P
<ScottK> If any SRU person has a moment, both postfix ^^^ and python SRU's that are waiting for accept are ones that'd be really good to get in soon for 12.04.1.
<infinity> stgraber: Alright, all fixed, and tested in "no headers installed" (ubuntu-core), "one set of headers installed" (ubuntu quantal), and "two sets of headers installed" (ubuntu precise-proposed) cases.
<stgraber> infinity: awesome! do you know the squashfs size of your precise test run?
<infinity> stgraber: Filesystem size 685670.83 Kbytes (669.60 Mbytes)
<infinity> stgraber: It really doesn't save much space, since squashfs already de-dupes all the identical files between the two headers packages (which is nearly all of them).
<infinity> stgraber: Before and after:
<infinity> Number of duplicate files found 26971
<infinity> Number of duplicate files found 10451
<stgraber> infinity: what architecture was that? (so I can compare to a current one)
 * stgraber will need to figure out what to drop or tweak to save that 9MB... (at least we have two langpacks we could drop if needed)
<infinity> stgraber: amd64.
<infinity> Filesystem size 687821.18 Kbytes (671.70 Mbytes)
<infinity> Filesystem size 685670.83 Kbytes (669.60 Mbytes)
<infinity> stgraber: ^-- It dropped 2MB here.
<infinity> stgraber: Which is something, I guess, but not huge.  It's mostly about saving (tons of) space on the target installation.
<infinity> stgraber: What grew by 9MB?  firefox/thunderbird upstream revision aggressiveness?
<stgraber> 2MB is already quite good. I haven't tracked down what caused the live images to go oversize, it's on my list of this week but yeah, libreoffice/firefox/thunderbird are pretty likely the cause of it.
<infinity> Well, we could buy you a ton of space by cleaning /var/lib/apt/lists/, but it would come with a hefty penalty for people on slow network connections.
<stgraber> I guess we could clean updates and security without much cost as these are likely to change and require re-download right after install anyway
<stgraber> but it's probably not going to save nearly as much space as the release pocket ;)
<infinity> Yeah, cleaning the !release pockets won't buy you much of anything.
<infinity> Looks to be maybe about 500k compressed.
<infinity> Not worth the debugging time to make sure it doesn't eff something up, I suspect.
<infinity> stgraber: You could, however, just start finding large packages to SRU with an s/gz/xz/ no-change upload. ;)
<infinity> Oh, wait.  livefs.
<infinity> I'm not awake.
<infinity> La la la.
#ubuntu-release 2013-07-22
<cjwatson> adam_g,zul: do you think you could merge novnc from Debian?  websockify in saucy-proposed Breaks: novnc (<< 1:0.4+dfsg+1-6), which causes nova-novncproxy to be uninstallable
<cjwatson> (This is why nova's autopkgtests are failing, although proposed-migration would reject the uninstallable package anyway)
<cjwatson> jbicha: ^- since you synced websockify
<jbicha> and I blame angelabad ;)
<cjwatson> sync requests: not always as easy sponsorship as they look
<ScottK> Since it's pick on jbicha day, your sflphone sync needs some looking after too.
<ScottK> I got as far as libgnutls28-dev and libgnutls-dev conflicting in build-depends depends and gave up.
<zul> cjwatson:  yeah can do it tomorrow
<cjwatson> zul: thanks
<cjwatson> I keep running across things in -proposed that are awaiting Debian NEW processing.  Do you think if I constructed a list (not today) and handed it to one of our illustrious new ftpassistants that they might be able to get priority?
<cjwatson> (Presumably the absences of their build-deps constitute RC bugs in Debian too.)
<jbicha> ScottK: yeah that's particularly ugly http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=716855
<ubot2`> Debian bug 716855 in libucommon-dev "libucomon-dev: Dependency on libgnutls28-dev makes sflphone unbuildable" [Serious,Open]
<ScottK> jbicha: Which is why it's nice to test build before doing the sync ...
<jbicha> well sflphone was broken anyway with one of these library transitions
<jbicha> I didn't make the mess any worse :(
 * Riddell out until later this afternoon
<ogra_`> cjwatson, hmm, there is something weird happening with the touch images http://paste.ubuntu.com/5899769/ i didnt run mark-current since the 16th but the recovery images get linked to the 19.1 build
<ogra_`> (i re-ran it manually now to have the symlink back pointing to a dir since the QA stuff relies on it for version checking)
<stgraber> ogra_`: I did that change on Friday, so you now just broke --ubuntu-boostrap...
<stgraber> ogra_`: it's valid for current to be a directory containing symlinks instead of it being directly a symlink
<cjwatson> yeah, indeed, that seems OK
<cjwatson> even if done by hand and unlogged :)
<cjwatson> ogra_`: exactly what check does "the QA stuff" perform?
<infinity> cjwatson: My assumption would be 'readlink current', or the equivalent thereof.
<ogra_`> stgraber, except that phable-flash completely breaks without a dir there
<ogra_`> err
<ogra_`> without a link
<stgraber> ogra_`: yeah, seems like we need to have it work with a dir considering it's a valid thing for mark-current to do...
<ogra_`> people that dont use pending will ahh have failing installs
<ogra_`> *all
<stgraber> ogra_`: anyway, I have another hack in place on nusakan to make --ubuntu-bootstrap work (just replaced the recovery images in 20130716 by the new ones)
<cjwatson> infinity: yeah, but not so pleasant over rsync
<cjwatson> ogra_`: I have been telling people for weeks/months that they need to STOP assuming that that's always a symlink
<cjwatson> if people don't listen then by this point they're negligent
<ogra_`> jut have mark-current put a stamp file in place
<ogra_`> *just
<ogra_`> hmm, well, or better cdimage
<cjwatson> no, phablet-flash needs to do the equivalent of readlink -f, I think
<cjwatson> it's a bit tricky over rsync but should be possible
<ogra_`> stgraber, also, it is a bad idea to shove a single img file from another build into current ... especiasslly in the light that nothing that had not been through the utah auto testing is allowed in there
<ogra_`> (how do you know the 19.1 kernel isnt busted on one of the arches for example
<cjwatson> so, stgraber's hack was needed to make system-image-updates work, which is required for this week
<stgraber> ogra_`: is there UTAH auto-testing for recovery? because if there was it'd have found that 20130716 was busted ;)
<cjwatson> I think it would be best to aim for having both of your use cases work, not one or the other ...
<ogra_`> no, there *needs* to be one now
<ogra_`> by new mgmt order everything we release as stable has to have a test run before it goes released
<stgraber> ogra_`: 20130719.1 recovery was tested by 3 people on all 4 devices with flipped and flipped+loop so at least in my book that's tested
<stgraber> and that probably was way more than what Jenkins ever did with the recovery image
<ogra_`> stgraber, utah counts
<ogra_`> stgraber, thats the reason we havent released anyyhing since the 16th
<ogra_`> we need to have an autotest for all bits we change from android default recovery at least
<ogra_`> all images since the 16th had manual tests but werent released ...
<ogra_`> (they are even all fine mostly)
<ogra_`> cjwatson, what cant (and never should) work is to mix up different android imgs  of different builds  (this will definitely be solved once the livefs builders create them from the packages for pending at least)
<xnox> ^^^^^^ can only go into multiverse or restricted
<infinity> xnox: Would have been helpful if you set the section correctly in debian/control, then.
<infinity> xnox: Especially if it's ever going to Debian, it should be non-free/otherosfs
<infinity> xnox: (Which our queue will automagically map to multiverse by default)
<xnox> infinity: i've used "multiverse/otherosfs" was that not good enough? was i meant to use debian's "non-free/otherosfs"?
<xnox> infinity: first time trying to use a prefix for an upload =/
<ogra_`> infinity, we probably actually want it in restricted (we do image builds with it) ... even though that brreaks the restricted policy
<xnox> ogra_`: well, i'd rather have explicit promote from multiverse -> restricted with a MIR and some-such.
<infinity> xnox: Oh, huh.  That should have worked.  Whatever.  I can override it.
<ogra_`> yeah
<xnox> infinity: ok, thanks. will use "non-free/" next time, and will see if that works.
<ogra_`> xnox, it should definitely not just go into restricted indeed :)
<infinity> xnox: Well, once I override it, what's in the package doesn't matter anyway. :P
<ogra_`> just saying we need a policy exception for it
<ogra_`> since it is more than just drivers
<infinity> (But it's nice if they match)
<xnox> infinity: oh, I have more stuff to go into multiverse =))))
<xnox> ogra_`: do you have a tick in the nick, to denote the very hot weather in Germany? =)
<ogra_`> xnox, i heard its hotter in the uk
<ogra_`> we only got ~28C today
<xnox> ogra_`: well, yeah, it is boiling hot. i take 4 showers a day + a swim.
<ogra_`> good move :)
<infinity> xnox: So, hilariously, the auto-override stuff only works for non-free and contrib, but not for our own components. :P
<infinity> xnox: But non-free is what you'd want if it ever went to Debian anyway.
<didrocks> ogra_`: lucky you, it's 35 here
<tumbleweed> it's suprisinigly warm (17C) for midwinter, here, today
<xnox> infinity: I guess, it's good time for me to do a launchpad patch then =)
<ogra_`> didrocks, yeah, germany only gets the edge of the heat wave
<didrocks> ogra_`: don't use that to make more promising anything during the hangout :p
<ogra_`> haha
<didrocks> really man, I feel so slowâ¦
<ogra_`> didrocks, i'll send you one icecream for each blindly nodded off thing :)
<didrocks> ogra_`: ahah, blackmailing! even before starting to negociate! :p
<ogra_`> :)
<ogra_`> need to prepare the grounds :)
<didrocks> heh
<xnox> ogra_`: copyright file is only 2.1MB =)
<ogra_`> xnox, thats 2M less than i had at least
<xnox> ogra_`: my tarball is less than 100MB. I trimmed the fat.
<ogra_`> sexy !
<ScottK> infinity: Done.
<ScottK> (Uber block)
<infinity> ScottK: Nice response time.
<Laney> ScottK: is yours just for Kubuntu or for all flavours?
<xnox> ScottK: .... did we have ubiquity upload with all the ubiquity/kde fixes in?!
<ScottK> Pretty sure it's all.
<ScottK> xnox: Dunno.
<Laney> hmm
 * ScottK looks
<Laney> my script generates a larger block
<ScottK> Laney: Feel free to replace it.
<ScottK> I just grabbed Alpha 1 and reused it, so a current one is likely better.
<Laney> fair enough, wilco
<xnox> ScottK: unmerged branch for bug 1187762
<ubot2`> Launchpad bug 1187762 in ubiquity (Ubuntu) "[ubiquity-frontend-kde] language drop down list closes on first click" [Undecided,New] https://launchpad.net/bugs/1187762
<ScottK> Probably not then.
<ScottK> That looks like one it's be good to get in.
<Laney> pushed a new one
<infinity> ScottK: Should I bug you or Riddell about the language-pack-kde-en -> calligra-l10n-engb NBS situation?
<infinity> ScottK: I'd just upload a fix, but I assume the next automagically-generated-by-scripts upload would undo it.
<ScottK> Riddell is a better person to bother.
<infinity> Riddell: ^
<stgraber> infinity: any idea why ubuntu-archive is subscribed to bug 1175533?
<ubot2`> Launchpad bug 1175533 in mesa-lts-raring (Ubuntu) "[HSW] intel VGA driver i915 doesn't support new haswell graphics [8086:0a2e] " [Undecided,In progress] https://launchpad.net/bugs/1175533
<infinity> stgraber: Because reasons?
<infinity> stgraber: Likely because it required some action on our part at some point.  Is that helpful? :P
<tseliot> can an admin please approve nvidia-persistenced in Saucy (NEW) and then move it to main? The package was reviewed by cjwatson (some time ago) and I applied all the requested changes to the package
<xnox> infinity: i think, it's just queuebot as both androids are shown in multiverse component (one was multiverse the other was non-free)
<infinity> xnox: I already overrode it in the queue, that's why. :P
<xnox> infinity: :P mega-powers =)
<xnox> infinity: i guess that's why you are on AA team =)
<infinity> xnox: It's mostly just because I'm so very, very pretty.
<xnox> infinity: filed MIR bug 1203800 and pinged security team about. not sure what other details I can include.
<ubot2`> Launchpad bug 1203800 in gcc-arm-linux-androideabi (Ubuntu) "[MIR] Android, CynogenMod, Clockworkmod, et al" [Undecided,New] https://launchpad.net/bugs/1203800
<infinity> xnox: Oh dear, those won't be fun.
<xnox> infinity: 100MB xz compressed tarball for android, and has all time favourites like openssl, gnupg, libm, icu and other hits like busybox =)
<infinity> xnox: ...
<xnox> infinity: it's kind of like ia32-libs, if only we had a debian port to androideabi / bionic out of the box.
<StevenK> xnox: Mentioning that package name in this channel is forbidden. :-P
<xnox> StevenK: my amazon order of bird seeds has not arrived yet... oh wait. No longer accepted as payment? gosh I'll have to find a futures broker to exchange into beer.
<infinity> xnox: It would only be like ia32-libs if it was pulling source from the archive.  If it's forked/different versions, it's really not.
<xnox> infinity: it pulls some _some_ packages from the archive......
<xnox> infinity: and the plan is to convert a few others (where possible). There is still a fair amount of original code.
<xnox> infinity: and so far it is better than the original 2GB compressed tarball =)
<infinity> xnox: And now I need to go drink heavily.  Thanks.
<doko>  infinity, after you make that eglibc upload?
<xnox> infinity: and merge initramfs-tools ?! :))))))))))
<cjwatson> Laney: Were you planning to merge mono?
<cjwatson> (blocks xsp in -proposed)
#ubuntu-release 2013-07-23
<zul> what does the trying: sqlalchemy, skipped: sqlaclhemy mean in the update_output.txt report
<micahg> zul: the dependencies listed aren't installable
<micahg> that's weird, I uploaded alembic...
<micahg> oh, it's probably the rdepends of alembic (openstack) which I didn't touch
<zul> micahg:  i uploaded them on friday/today
<micahg> zul: I'd suggest checking the entries of each one, nova isn't installable either
<zul> micahg:  weird becaues i was able to install it
<micahg> well, with everything else in proposed maybe
<micahg> zul: cinder seems problematic
<zul> micahg:  i thinks its because of the autopkgtest...anyways thanks ill look at it
<micahg> yes
<robert_ancell> Hi, lightdm 1.7.6-0ubuntu1 has a serious bug in it (bug 1203711) but neither the fix in 1.7.6-0ubuntu2 or 1.7.7-0ubuntu1 have moved out of -proposed into main. Is something blocking it?
<ubot2`> Launchpad bug 1203711 in lightdm (Ubuntu) "uninitialised list pointer in configuration directory handling" [High,Fix committed] https://launchpad.net/bugs/1203711
 * ScottK looks
<ScottK> robert_ancell: No one has verified Bug 951000 is fixed in either release.
<ubot2`> Launchpad bug 951000 in OEM Priority Project "disable guest session screen lock using gsettings" [High,In progress] https://launchpad.net/bugs/951000
<micahg> ScottK: robert_ancell: block request for alpha2
<micahg> I think...was by Laney
<ScottK> Oh, Yes.
<robert_ancell> micahg, ScottK, is there a way to let the saucy version through? It's an important fix that has no relation to that
<ScottK> Looking again in the right place.
<micahg> well, depending how bad, the ISOs should probably be respun
<ScottK> It's only Monday.  I'll let it through.
<robert_ancell> micahg, it was picked up in a test lab based on the ISOs
<ScottK> If I got the syntax right, it'll be unblocked on the next publisher run.
<robert_ancell> ScottK, thanks!
<robert_ancell> ScottK, Appears to be in main now, thanks again!
<ScottK> You're welcome.
<jbicha> since it's still Monday here, here's an unblock list for Ubuntu GNOME http://paste.ubuntu.com/5902731/
<micahg> jbicha: freezes generally start at 2100 UTC FWIW
<jbicha> but gtk+3.0 is also blocked because notify-osd's test has been failing for a few weeks
<jbicha> micahg: or we could release note them all :)
<jbicha> and it's not clear when the Alpha Freeze exactly starts...
<micahg> jbicha: I'm not saying they shouldn't necessarily be unblocked, but you seem unclear when freezes start :)
<jbicha> yes, it's not on https://wiki.ubuntu.com/SaucySalamander/ReleaseSchedule
<micahg> jbicha: second bullet point
<jbicha> right, but there isn't an alpha freeze on the schedule
<micahg> hrm, it's always been Tues before (Mon 2100)
<jbicha> if gvfs didn't need to go through the new queue, it probably would have been in before the block this morning
<micahg> but that is an oversight...
<ScottK> jbicha: If you're still the release person for Ubuntu Gnome, I'll be glad ot unblock whatever you need.
<ScottK> Just say go.
<jbicha> ScottK: see it's still Monday for you too :)
<micahg> jbicha: he's on the release team, he can let stuff through when it's needed :)
<jbicha> ScottK: can we skip the notify-osd test?
<ScottK> Oh, it's past when we freeze, but I'm easy about blocks this early.
<ScottK> Is it a problem with the test, do we know?
<jbicha> I have no idea https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-notify-osd/lastCompletedBuild/ARCH=i386,label=adt/console
<micahg> jbicha: has that been escalated to whoever is in charge of those daily builds?
<jbicha> micahg: no but I can make sure I tell people in the morning
<ScottK> It looks like that test has passed before.
<ScottK> So it should be investigated.
<micahg> yeah, and there's a "please report" address at the bottom :)
<ScottK> I'll do the unblocks, but not override the test failure.
<jbicha> ScottK: thanks, that will work
<ScottK> Once someone investigates, someone else can do that.
<micahg> lubuntu would be affected by any GTK breakage, so that seems prudent
<ScottK> .
<jbicha> that email address bounces :(
<bluesabre> hello, I'm on the Xubuntu Release team, and we would like to opt in for Alpha 2.  Whom should I email regarding this?
<cjwatson> zul: You need to look at the "Trying easy from autohinter: sqlalchemy" block, not the part where it tries sqlalchemy on its own.
<cjwatson> zul: But, indeed, the short answer is probably to figure out cinder's autopkgtest failure.
<cjwatson> xnox: android-src-vendor's debian/copyright is fairly general.  Have we checked that all the licences in question permit us to redistribute the files on Ubuntu mirrors (not just Canonical)?
<cjwatson> xnox: For the next version it would be nice to actually quote the licences.  debian/copyright isn't meant to have external references, except to /usr/share/common-licenses/.
<xnox> cjwatson: ok. Let me dig out the original license texts for each and every blob. In general yes, one can redistribute them, as long as they are intended and used on the targeted Nexus series devices and no other.
<cjwatson> Right.  Good enough for multiverse ...
 * apw notes there is a block request on the current kernel, if the images have -4 that was not a very happy kernel
<xnox> cjwatson: updated copyright. all of them allow "non-commercial redistribution". http://paste.ubuntu.com/5903575/
<cjwatson> xnox: Thanks.  I hope you'll forgive me not reading through all that now :-)
<infinity> apw: I'll make sure that gets through and people get fresh images.
<apw> infinity, thanks... sorry for the timeing, only really getting proper confirmation that this is resolving peoples issues today
<xnox> cjwatson: to be honest it's the same text for all of them. +/-  different name of the company with/without "no reverse engineering" clauses.
<xnox> =)
<infinity> jibel: The linux autopkgtest is still running out of space, which makes the sadness of my pandas great.
<apw> infinity, perhaps we should just be removing that test if the system cannot cope with it
<infinity> apw: Nah, we should fix jibel's system. :P
<jibel> infinity, how much space will you pandas be happy with? will 20G be enough?
<cjwatson> It's not obvious that that test is massively improving anyone's life, mind you.  Would it improve anyone's life even if it were fixed?
<infinity> cjwatson: The idea of the test is to trigger kernel/glibc/gcc/binutils in a bit of a circle-jerk to make sure no one breaks the others.
<infinity> cjwatson: The part where it's also triggered by linux-signed being uploaded is unfortunate. :P
<infinity> jibel: No idea.  Build a kernel and see?  :)
<cjwatson> infinity: Mm.  But it's only testing buildability, which we'd notice the next time we tried to upload anything anyway, not really anything that's going to break users if things are promoted.
<infinity> Possibly, yeah.  I don't feel strongly about it.
<infinity> It wasn't my test. :P
<apw> the way pitti pitched it it was mostly useless for the kernel itself, in a perfect world it would not be triggered on the kernel for a kernel upload only on the uploads from the dependancy packages
<apw> so if gcc changes we have to build the kernel to prove it is ok
<apw> but there is no way to say in the autopkgtest control that we don't do it for us only others
<cjwatson> Yeah, but like I say, you'd find that out at the next build anyway.
<cjwatson> I don't really see "does it still build" as a terribly useful use of autopkgtest.
<apw> cjwatson, well the point is to stop gcc from migrating when it is changed
<cjwatson> But that makes no useful difference
<cjwatson> Because you build with what's in -proposed anyway
<cjwatson> Blocking migration is helpful when the migration is going to break users
<apw> heh, point indeed.  so its useless for its intended use
<cjwatson> But in this case it seems like a weird artificial thing that isn't helping much
<apw> it is cirtainly not helping for its intended function it seems
<apw> not considering how expensive and slow it is
<infinity> apw: The kernel test being nothing but a build test, with no testsuite involved, it probably can just go, yeah.
<apw> infinity, yeah as i under stood things it was meant to hold gcc or libc if things went wrong, but that doesn't do us much good
<apw> so i am in your hands, if you think it is usless i am happy to wack it
 * xnox 'd like to add autopkgtests to build dkms modules when new kernel is uploaded, to know which ones need fixing, but somehow not block kernel migration because of dkms modules =/
<cjwatson> Honestly I think that would be better done in some other system ...
<cjwatson> We don't have to hit all nails with the same hammer :-)
<cjwatson> xnox: Huh, I thought saucy-preinstalled-touch-*.zip were the Ubuntu bits.  Did I misunderstand?
<cjwatson> Oh, not saucy-preinstalled-touch-armel+*.zip
<ogra_> cjwatson, -armhf.zip are the ubuntu bits
<cjwatson> Yeah, my mistake
<ogra_> cjwatson, btw, will it stay in multiverse or do we say "it is HW enablement" and can put it into restricted ?
<ogra_> technically it is
<ogra_> even though its way more than drivers
<cjwatson> I understood there was an inclusion review already in progress
<xnox> cjwatson: that android package builds both flipped & unflipped: the recovery and android portions. The ubuntu chroot is build by livefs/rootfs-builder. And we deliver both as *.zips to be compatible with adb way of upgrading android phones.
<ogra_> xnox, uh, why unflipped ?
<ogra_> kthats wasted buildtime imho
<ogra_> we wont go back
<cjwatson> xnox: Built-Using would be nice, not that we support it properly in Launchpad yet
<cjwatson> xnox: I thought we were going to build the application-level stuff (e.g. openssl) as Arch: all -bionic binary packages built out of the corresponding Ubuntu source package?
<cjwatson> xnox: Are there bugs for all of the external/* things?  I'm not happy about that staying there for release
<xnox> cjwatson: where we can, yes. The priority is to convert - platform-api, libhybris, stgrabers upgrader / recovery bits to do that, to avoid building android package, just to update those faster moving bits. But that means that livefs builder should learn how to fetch -bionic binary packages and update/create .zip & .img files inplace.
<cjwatson> It doesn't mean that
<ogra_> does it need to ?
<cjwatson> You could still assemble it all in the android binary package, just not ship copies of the sources in the android source package
<ogra_> we might get away with the system-image.u.c machine doing that
<cjwatson> I'm perfectly happy with the stuff in the android package that does assembly of other things
<ogra_> since it modifies the files from cdimage anyway
<cjwatson> This is a sane thing to do at package build time
<xnox> cjwatson: i see what you mean. de-duplicate on source code level.
<cjwatson> I just don't want copies of the sources there
<xnox> cjwatson: ok. i'll do analysis on what we can do there. In parallel, i'd like to keep $ repo git forest tree working, to bootstrap/develop new devices.
<xnox> ogra_: I am pondering about git-bzr support in repo tool
<ogra_> well, preferably the bzr trees should vanish
<cjwatson> I'll accept this since it's still an improvement on what we're already doing, but I do feel it needs to improve further, especially if we're contemplating moving it to restricted
<cjwatson> xnox: Also, I'm happy-ish with the stuff you're doing in the android build that grabs source packages from elsewhere (although it's certainly creative), so you could do that instead if you prefer not to add loads more -bionic binary packages and awkward build-deps
<xnox> cjwatson: yeah, i don't think it's wise to add gcc cross-toolchain and adroid build system as a build-dep for low-level packages like busybox / openssl / etc.
<cjwatson> Arguably putting the bionic stuff in the android package is better than spreading it all over the archive, I don't know
<cjwatson> Yeah
<infinity> I think I prefer this crazy ia32-libs style method.
<ogra_> well, we need s few bits built with the toolchain that might or might not need android headers
<ogra_> (the above mentioned bzr trees should all go into packages)
<ogra_> s/s/a
<ogra_> (hybris and platform-api, i think the rest of bsr trees is dead anyway)
<ogra_> *bzr
<xnox> ogra_: but e.g. ondrejs patches to gnupg to add Android.mk, should be applied to gnupg src-package, which then is fetched by "android" package or "repo checkout" and built inline with everything else.
<ogra_> oh, yeah, definitely
<doko> infinity, eglibc ping
<xnox> cjwatson: at the moment android package has the source and does four flavour builds (for each device). This can be "parallised" to have android package create android-src, and then have 4 device source packages, which build-dep on android-src and do only 1 flavour build each. Then the build time will be cut from 41min on one buildd, to 4x15minute builds across 4 buildds. Would that be a useful optimisation, or false economy with slightly increased
<xnox> maintenance?
<doko> I think that would be wrong. 41min is nothing to optimize
<xnox> doko: ok.
<cjwatson> xnox: Yeah, I wouldn't bother.  That sort of machine time isn't expensive compared to human time figuring it out later.
<cjwatson> You could try parallelising the build on a single machine ...
<xnox> cjwatson: well each flavour is build with "--parallel". So the compile steps are fast (the whole build system is single makefile with top level targets).
<cjwatson> OK.  I wouldn't worry about it too much.
<cjwatson> Are you building faster than Jenkins? :-)
<slangasek> cjwatson, infinity: do you guys know what the current holdup is for the linux package? is it this out-of-date d-i that's the last blocker?
<cjwatson> slangasek: blocked for alpha-2 AFAIK
<cjwatson> oh, it's being unblocked
<slangasek> yes
<cjwatson> yeah, it's just d-i
<slangasek> and d-i FTBFS on powerpc due to an oversized image :/
<cjwatson> slangasek: right, infinity is fighting with that at the moment
<slangasek> AIUI the -4 kernel has some serious video regressions (which is probably why the freeze has been overridden)
<slangasek> cjwatson: so I should keep my nose out and let him work? :)
<cjwatson> probably :)  he is swearing
<slangasek> heh
<infinity> slangasek: Yeah, I unblocked that kernel because of the nasty bug, but the d-i thing is irksome.
<slangasek> yep
<slangasek> infinity: it's not as simple as upping the size of the disk image?
<cjwatson> it's by 150M
<infinity> slangasek: If I want to increase it by 150MB, sure.
<slangasek> blink
<infinity> slangasek: Two of the four PPC flavours have spontaenously stopped being stripped.
<infinity> slangasek: Not yet spotting an obvious reason why.
<rbasak> Freeze? Because it's Alpha 2 week? The topic says "Archive: open". Is that for something else?
<slangasek> and if we forced it with the ppc out-of-date, what would that break for flavors trying to do an alpha2 on ppc?
<infinity> rbasak: The archive is open.  britney, on the other hand...
<slangasek> rbasak: freeze on saucy-proposed -> saucy migrations, only for packages used in the images of those flavors that are doing the opt-in alpha2
<rbasak> I see. Got it - thanks.
<infinity> slangasek: Probably.
<mlankhorst> can all the lts-raring packages be moved to -updates now?
<slangasek> infinity: "what would that break" -- "probably" > ok, message received ;)
<infinity> slangasek: I missed the "what". :)
<infinity> slangasek: So, given that these are both -0 ABIs, but probably not ABI-compatible, the old d-i build (against 0.3) is likely to not work so well with the -0.5 udebs in the archive.
<infinity> slangasek: So, fundamentally, any d-i-based install method would be broken.  Livecds would be fine, but massively oversized (so, broken from most tester's POV)
<slangasek> powerpc CDs have been oversized for a while
<infinity> Anyhow, I may just disable ppc/ppc64 flavours in d-i for now, declate that no one gets a PPC flavour for Alpha2, and investigate later.
<slangasek> right, I'm inclined to think this would be the best option given the degree of breakage in the current -4 kernel
<infinity> slangasek: Then again, -5 looks fun too.
<infinity> slangasek: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1204005
<ubot2`> Ubuntu bug 1204005 in linux (Ubuntu) "[saucy] kvm host hangs of guest boot with 3.10.0-5" [Critical,Triaged]
<slangasek> and if we get fixed ppc kernels quickly, there might still be time to revisit for alpha2
<infinity> slangasek: Spinning a quick test-build with ppc/ppc64 disabled and will upload that and give people the bad news. :P
<slangasek> why do you need a rebuild?  You can just force the out-of-date in britney
<infinity> slangasek: Because I'd rather have it build correctly.
<slangasek> for the flavors that aren't oversized?
<infinity> slangasek: Indeed.
<slangasek> ok
<infinity> slangasek: And I'd rather have it build, period.  forcing things should be a last-resort, not a knee-jerk go-to
<slangasek> it's not a knee-jerk go-to to unbreak x86 kernels for users
<slangasek> we can force it, *while* it's building on powerpc
<infinity> slangasek: *shrug*... If you want to force it, go ahead.  Note that -5 will break for a different set of users.
<infinity> (And people who are already broken have already rebooted into -3, or are stuck not being able to figure out how to upgrade to -5 at all)
<slangasek> infinity: except for those of us who don't reboot that often and are still running -2, but don't want to be affected by this bug on next reboot ;-)
<infinity> slangasek: Right, well, new d-i is uploading now anyway.
<slangasek> ack
<slangasek> how long does it take to build?
<infinity> slangasek: ~60m on armhf.
<slangasek> ok
<stgraber> ScottK, Riddell: fine with me letting kubuntu-meta through once it's built? (it's currently part of the big block)
<Riddell> stgraber: yeah but is it needed?
<stgraber> Riddell: it's not strictly required but I'd love to get rid of appmenu and if I do it now I'll break your builds and from what I understand, the kernels are a bit broken at the moment so you're likely to need a respin anyway
<infinity> No likely about it, everyone's getting a respin for the new kernel unless they make a REALLY good argument.
<Riddell> stgraber: ok go for it
<stgraber> Riddell: ok, doing then
<jbicha> could I have empathy 3.8.3-0ubuntu5 unblocked for Ubuntu GNOME?
<infinity> jbicha: Yep.
<jbicha> could we get the UG cron job stopped too? thanks :)
<infinity> jbicha: Sure. You're going to get new images for this kernel, probably.
<Riddell> if we're letting new stuff in I might let in kde-runtime cos it didn't get the .95 version in and is out of step with the rest of kde sc
<jbicha> that's fine and today's was fine; I just don't need an auto-build tomorrow :)
<infinity> Riddell: Go nuts.
<Riddell> infinity: that's a dangerous thing to say to me!
<infinity> Riddell: It's your Alpha, unblock what you want. :)
<xnox> infinity: when kernel lands, will you also respin ubuntu images? as i was trying to do some ubiquity work, but the cd no worky in qemu.
<infinity> xnox: Do you expect -5 to work in qemu?
<infinity> xnox: Is this the kvm_intel=1-not-passed-correctly bug (which is fixed in -5), or the "cirrus video in kvm blows up the host" bug, which isn't?
<infinity> xnox: Anyhow, sure, I can respin ubuntu.  It's not uncronned, mind you, so it'll do itself.
<xnox> infinity: i think both, but i guess the latter one will kill me anyway. *sigh*
 * xnox only was aware of the former one.
<xnox> I guess I need cloud images respun as well.
 * xnox goes to use debian d-i
<utlemming> xnox: ?
<xnox> utlemming: auto-package-testing uses cloud images, to run the tests. And that's what I was working on, qemu-ubiquity-autopilot-auto-package-test
<utlemming> xnox: ack, let me know when you need a new cloud image and I'll kick the build for you
<utlemming> xnox: I can have an image ~20 minutes but full publication can take about 3 hours
<xnox> utlemming: next daily should be fine. or respin after -5 is published, but that's not urgent, as I am a niche case. nothing alpha/release blocking.
<phillw> I've requested a full respin of lubuntu on the qa-tracker; can you check that the request has gone through. Many thanks.
<stgraber> phillw: it's running
<stgraber> phillw: if the tracker says "(re-building)" instead of "(disabled)", that means it's been queued properly and is building somewhere
<elfy> stgraber: anyway to find out when the Xubuntu spin will get added?
<stgraber> elfy: when you request it? it's self-service nowadays
<elfy> someone asked about 8 hours ago I thought
<stgraber> elfy: so you need to go on the daily milestone on the tracker, tick the images you want to build and select re-build at the bottom of the page
<stgraber> elfy: there's no xubuntu build request in the DB, so no
<elfy> mmmm - this is all new to me
<stgraber> yeah, sorry, this was introduced in alpha-1 but you didn't participate so weren't contacted back then
<elfy> yea
<elfy> stgraber: sorry - not quite what I meant - ALL of this release stuff is new to me :)
<stgraber> ok ;)
<elfy> stgraber: so - how do we get xubuntu build request in the DB
<elfy> I can see a mail to the release list from knome about 6 hours ago
<elfy> I'll talk to knome later this evening - but we do want to participate
<stgraber> elfy: go to http://iso.qa.ubuntu.com/qatracker/milestones/299/builds
<elfy> yep
<stgraber> elfy: tick your products, go at the bottom of the page and click "Update rebuild status"
<rsalveti> xnox: one thing, the name android there can be a bit confusing, as we're not building directly from aosp, for example
<stgraber> elfy: ah, wrong page, I meant the Daily page, sorry
<elfy> stgraber: done
<elfy> oops
<rsalveti> xnox: we're using a custom cm-10.1 based source tree, with our changes on top
<infinity> phillw: Your full respin was premature, I'm going to be pushing a new kernel into the release pocket shortly, and I'm pretty sure you'll want that.
<stgraber> elfy: I meant http://iso.qa.ubuntu.com/qatracker/milestones/270/builds
<stgraber> elfy: right
<elfy> re-building
<rsalveti> xnox: we could as well have one image based on aosp directly in there later on, once we're able to share some of the code
<elfy> stgraber: and that will create alpha2?
<phillw> stgraber: I'll go cancel, then!
<stgraber>  54 | Xubuntu Desktop amd64                    | 2013-07-23 13:05:15 |                     | elfy        |      0
<stgraber>  55 | Xubuntu Desktop i386                     | 2013-07-23 13:05:15 |                     | elfy        |      0
<stgraber> elfy: yeah, those are on the manifest so they'll show up as alpha-2
<cjwatson> phillw: you can't, once it's building
<elfy> stgraber: excellent - that was painless - I like that :)
<xnox> rsalveti: sure. we have a mixture of: aosp, cynogenmod, clockwork mod, our patches, our upstream projects, and external gnu and non-gnu fsf stuff, oh and 3rd party vendor bits.
<stgraber> elfy: any product on this list http://iso.qa.ubuntu.com/qatracker/series/37/manifest will automatically be copied from Daily to the current milestone
<xnox> rsalveti: if and when we have another "flavour" of android, we can start namespacing them somewhat more sensible.
<phillw> cjwatson: indeed not :/
<xnox> rsalveti: but android-asop-cynogenmod-gnu-fsf-et-al would be too long of a name =)
<rsalveti> xnox: right, actually this is just cm-10 + our patches :-)
<rsalveti> in the android sense
<elfy> stgraber: k - think I understand that - don't click the wrong buttons :)
<rsalveti> we could have android-cm-10.1 and android-aosp
<rsalveti> for example
<infinity> phillw: Also, your PPC images are going to probably be non-functional for A2.  You might just want to skip it entirely for this Alpha (we'll fix after).
<rsalveti> we don't need to care much about the rest
<xnox> rsalveti: i guess we will need to use better names, once we have a second branch, based on top of next aosp or next cm.
<phillw> I'll delay sending the email and add in that it has a new kernel. infinity they un functioning in a1 as well. But I'll the PPC testers know not to bash their brains in. Thanks for the heads up.
<rsalveti> xnox: but yeah, not for now, just a heads up, as I know we might have some requests to get this built on top of aosp soon as well
<rsalveti> xnox: right
<xnox> rsalveti: ok. at that point, we can do a rename as well. cause there will be a few things that will need to change to accomodate android flavours.
<rsalveti> xnox: how are you creating the source package?
<infinity> phillw: My point was that respinning PPC images is probably a horrible waste of time too.
<rsalveti> xnox: using http://phablet.ubuntu.com/export/?
<xnox> (flavours? forks? brands? release branches?)
<xnox> rsalveti: no. I use $ repo sync, with my manifest, which is reduced manifest of the phablet-10.1 branch.
<rsalveti> right, and why can't we reduce the original manifest?
<xnox> rsalveti: and the debian/rules get-orig-source target generates the proper upstream tarball for me.
<rsalveti> specially now with the phablet-saucy branch
<rsalveti> sure, it's just that we already have a dump of the repositories there
<xnox> rsalveti: we can, it's just it's a few changes, and e.g. jenkins build will fail unless modified accordingly to install additional dependencies.
<xnox> rsalveti: and the porting guide needs update, as more things need to be installed, and only available in saucy at the moment.
<rsalveti> xnox: right, and we don't want that actually
<xnox> rsalveti: awesome.
<rsalveti> xnox: so are are you using your branch as base there? or just your custom manifest?
<rsalveti> xnox: I'm planning to move our stuff to use the phablet-saucy branch today
<xnox> rsalveti: I'll draft an email with patch series and everything that needs changing.
<xnox> rsalveti: oh, I see.
<phillw> infinity: stgraber they can be removed from the A2 manifest. I've just emailed the PPC lubuntu team to let them know.
<rsalveti> right, so that's why I want to get the most changes you had there in that branch
<rsalveti> so we can start using that branch as base for your source package
<rsalveti> and remove whatever repo we want during build time, so we don't need to maintain 2 different manifests
<xnox> rsalveti: http://paste.ubuntu.com/5904749/
<stgraber> phillw: just don't request a build for it and it won't show up again
<xnox> rsalveti: that's the changes to my manifest, wait that's not all.
<xnox> rsalveti: http://paste.ubuntu.com/5904752/
<infinity> phillw: Cool, thanks.  Ben and I will get the kernel issue fixed post-Alpha.
<phillw> stgraber: okies :)
<rsalveti> xnox: cool, guess we can remove most but the prebuilts
<rsalveti> as we're replacing that with local tools and such
<xnox> rsalveti: all prebuilts are gone =)
<xnox> rsalveti: i pushed my manifest as people/xnox branch in the manifest repo, but well it needs rebasing/merging with phablet-saucy branch.
<rsalveti> sure, no worries
<rsalveti> will get some of your stuff merged and see if I can still produce a valid build
<rsalveti> then we just need to sync to update your package, but probably tomorrow
<xnox> rsalveti: android packaging the top level "debian/" dir is: https://github.com/xnox/android
<xnox> rsalveti: and in there you will see 6 patches
<rsalveti> xnox: right
<rsalveti> xnox: why not a bzr branch?
<rsalveti> somewhere where core-devs could also push stuff
<xnox> rsalveti: they are fairly self-explanatory. The tricky ones are that, prevent arbitrary network access. E.g. in debian/rules I sue chdist to access ubuntu mirror to pull things instead of using pull-lp-bin / pull-lp-source
<rsalveti> xnox: right
<rsalveti> that might need a bit of rework, but should be fine
<xnox> rsalveti: i want it in git, to be able to do $ repo sync, but I guess this can be made into a bzr branch. Afterall we are fetching a bunch of stuff inline anyway from all over the place.
<xnox> rsalveti: i can look into reworking it, right after I am back from the gym.
<phillw> infinity: can you please give me a ping / send an email to ubuntu-release when the new the kernel is read for triggering a rebuild. Thanks :)
<xnox> rsalveti: it's EOD here. And i guess I should help with rebasing those patches on to the saucy branch =)
<xnox> rsalveti: i'm off on holiday till monday as well.
<infinity> phillw: It'll probably be after A2, so it'll be in a cronned daily, no need to force any rebuilds.
<xnox> rsalveti: are there phablet-saucy branches for most projects? i can rebase and push those patches one by one.
<xnox> rsalveti: or do you prefer me to email them, for peer review from sergiusens & yourself?
<rsalveti> xnox: I'll review all the patches there, and get those applied (the ones that are not package specific)
<rsalveti> xnox: seems you're manually doing repo init and sync, right?
<rsalveti> that's not part of get-orig-source
<xnox> rsalveti: some of them change behaviour drastically, for example instead of prebuilt sdk/ndk, I ask all modules to link against the just-compiled-bionic and some such. Which might not be abi stable. But we are not at the moment providing bionic in a way for other packages to compile for androideabi.
<xnox> rsalveti: right, yes, just $ repo init; repo sync. Clone in the debian (can't remember if i added it to the manifest or not).
<rsalveti> right
<xnox> rsalveti: get-orig-source target only generates the tarball as appropriate for upload into the archive.
<xnox> rsalveti: so it's very packaging specific.
<rsalveti> xnox: right, but it'd be nice to automate the repo sync part as well
<rsalveti> so I can just fire up a command and get a tarball in the end
<stgraber> elfy: there you go ^ note that those are broken and you'll need to respin once we get the new kernel+d-i in the release pocket (or infinity will just respin everyone)
<rsalveti> that's why I was thinking if we could already use the exported tarball from phablet.u.c
<rsalveti> we can strip that one if needed
<rsalveti> like, you're not pointing out your custom manifest in the package itself
<xnox> rsalveti: i would be nice to publish daily tarball, without all the extra bits. I didn't find where/how the export tarball is generated at the moment.
<rsalveti> so it's hard to reproduce and create the same orig tarball unless you really know what is happening there :-)
<xnox> rsalveti: if you look at the debian/rules, it's using my manifest, ignores a few extra files / partially selects what to include and tars everything up under a $name.
<rsalveti> xnox: there's a cron job that takes care of that in phablet.u.c, we can change that to create the tarball we need for this package
<xnox> rsalveti: that would be nice. cause then we can do $ uscan && uupdate && debuild -S && dput ubuntu ../*.changes
<rsalveti> exactly
<rsalveti> xnox: alright, I'll put some time into this, we can sync once you're back
<xnox> rsalveti: and fully automatically do the uploads, and only get repo tool involved in the android development.
<rsalveti> right, that would be nice indeed
<elfy> stgraber: thanks
<xnox> rsalveti: right, i'm off to the gym, but ping me if there is anything else. will be back later to read scrollback =)
<rsalveti> xnox: sure, thanks, enjoy
<infinity> slangasek: Kernel's promoted sorry about the delay.  bad_timing++
<slangasek> infinity: thanks for following through :)
<phillw> infinity: ack
<infinity> Rebuilding all the A2 images for the new kernel.  Enjoy.
<phillw> infinity: I'll send a new email :)
<phillw> infinity: I take it that this will *not*  solve the PPC issue and this is still going to be post alpha 2?
<infinity> phillw: Right.
<phillw> infinity: thanks! (I've got a meeting in 1.5 hours and I do like to have the most up to date information for all the testers :) )
<jbicha> the amd64 manifest is outdated on http://cdimage.ubuntu.com/ubuntu-gnome/daily-live/current/
<xnox> rsalveti: sent email with first rebase of patches and a small todo list of remaining things i should rebase and send your way =)
<rsalveti> xnox: great, thanks
<rsalveti> xnox: nothing here yet
<xnox> rsalveti: https://lists.launchpad.net/ubuntu-phone/msg03304.html
<rsalveti> xnox: thanks
<xnox> rsalveti: i wonder if you seen my previous patches i have been sending the same way...... or simply lag =)
<rsalveti> xnox: we just had 2 crazy weeks, so might still be in the backlog
<rsalveti> but will check, things are getting back to normal
<darkxst> infinity, hi, can you turn of the ubuntu gnome cron jobs?
<Laney> darkxst: they are off
<darkxst> ok cool
<rsalveti> can someone look at maliit-frameworks? new release, and a new lib package
<rsalveti> slangasek: in case you're around ^ this will remove another package from our ppa
<rsalveti> sergiusens: ^^
#ubuntu-release 2013-07-24
<darkxst> ubuntu GNOME 20130723.2 images have not appeared on cdimage.u.c
<darkxst> is something broken?
<phillw> darkxst: they are not showing as rebuilding on http://iso.qa.ubuntu.com/qatracker/milestones/270/builds it does not even show a .1 rebuild on there>?
<phillw> correction, the .1 rebuild IS there, but it does show as marked for a respin
<phillw> *does NOT show*.... wanders off for a ciggie.
<slangasek> darkxst, phillw: I think you probably want http://iso.qa.ubuntu.com/qatracker/milestones/299/builds fwiw.  There is a '20130723.2' listed there, but it never built; I don't know what that means, but I'll go ahead and trigger a manual rebuild
<slangasek> rsalveti: maliit-frameworks> ack, will have a look :)
<phillw> sorry, slangasek I'd moved back to look at the PPC images on the dailes.... Darn easy to be on the wrong area :/
<phillw> infinity: are you still around?
<jbicha> UG's 20130723.1 amd64 iso was a bit weird too as the .manifest wasn't updated
<ScottK> If there's a respin for something, please also let kubuntu-meta and kubuntu-settings through to go with it.
<jdstrand> can someone deNEW click-apparmor? it is fine in universe for now
<ogra_> infinity, ubuntu-core seems unwell
<ogra_> (or rather debootstrap)
<infinity> ogra_: debootstrap being unwell is less than good.
 * infinity looks.
<ogra_> it trips over python2.7-minimal seemingly
<infinity> ogra_: Erm, unwell how?  The build log looks sane.
<ogra_> not in the mail i just got
<ogra_> oh, wait
<ogra_> thats precise
 * ogra_ missed that in the subject
<ogra_> W: Failure while configuring base packages.  This will be re-attempted up to five times.
<ogra_> I: Configuring python2.7-minimal...
<ogra_> W: Failure while configuring base packages.  This will be re-attempted up to five times.
<infinity> Oh, precise may well be sad.
<infinity> Breaking the world on the way to the point release.
<ogra_> ah
 * ogra_ will ignore it then
<ogra_> sorry for the noise ... if i had noticed its precise ...
<cjwatson> ogra_: that looks like a pandabug to me
<ogra_> cjwatson, could well be
<phillw> infinity: I have a rather odd email regarding PPC in 13.10. After a month of not working, the ISO from 23rd July now works.... There's nothing more peculiar than testing!
<phillw> this has been confirmed by another of the testers....
<jdstrand> infinity: hi! I am looking at https://launchpad.net/ubuntu/+source/apparmor/2.8.0-0ubuntu23/+build/4820740
<jdstrand> infinity: it looks like the build died, but it is still showing as building and I don't have a way to retry it. can you help?
<infinity> jdstrand: I can get it killed, sure.
<infinity> jdstrand: Quite possible that the buildd had a sad, given where it's stalled.
<jdstrand> infinity: thanks
<seb128> infinity, cjwatson: hey, britney question ... maliit has been doing qt4 -> qt5, which means it stopped building on ppc (rather in depwait), what's the right way to get the new version to migrate to saucy? delete the old ppc binaries?
<cjwatson> yes, assuming they have no revdeps
<infinity> seb128: Yeah, and rdeps.
<infinity> (It does have some... I suspect some of those things need rebuilding anyway)
<seb128> it does?
<seb128> well, maliit has 2 sources
<seb128> the rdepends should be only binaries from those
<rsalveti> yeah
<infinity> * maliit-keyboard               (for maliit-framework)
<infinity> * nemo-keyboard                 (for maliit-framework)
<infinity> * ubuntu-touch [amd64 armhf i386]  (for maliit-framework)
<infinity> One of those is arch:all though, I think.
<cjwatson> checkrdepends on lillypilly will tell you
<seb128> infinity, which one?
<infinity> nemo-keyboard
<infinity> Ahh, and it's in -proposed too.  So, yeah.
<cjwatson> 'checkrdepends maliit' on lillypilly isn't showing anything
<infinity> We can transition this.
<infinity> I'll whack the PPC binaries from the release pocket now.
<cjwatson> Ah, seb128 didn't give me the exact source name
<seb128> cjwatson, sorry
<seb128> infinity, cjwatson: thanks for the help
<infinity> seb128: Done.  We'll see if that makes it happier.
<seb128> rsalveti, ^
<seb128> infinity, thanks ;-)
<rsalveti> great, thanks all
<Riddell> infinity: there's a nasty kmail bug on the candidate images and I think I'd like to respin, can I do that now from the iso tracker?
<infinity> Riddell: Yup.
<Riddell> infinity: remind me again how?
<Riddell> ooh I see a button
<Riddell> groovy, rebuilding
<slangasek> infinity: when you respun for the kernel update last night, do you happen to know what build # ubuntu-gnome was at?  Because a problem turned up later where the tracker listed a version that had never been built (no log on nusakan, etc)
<slangasek> dunno if that was because someone manually fiddled, or because the rube goldberg failed
<infinity> slangasek: No idea.  I just clicked the boxes and mashed the button.
<slangasek> ok
<infinity> slangasek: Logs would be potentially enlightening, and cjwatson and stgraber might care about the above result.
<slangasek> infinity: logs of what?
<infinity> slangasek: Oh, you said there were no logs on nusakan for that build?  Fun.
<slangasek> right
<infinity> slangasek: So, this is all stgraber, I guess.
<slangasek> stgraber: ^^ fyi, this is all in scrollback from yesterday too (around 1am BST)
<mlankhorst> is lts-raring in -updates yet?
<jbicha> 0723 was the regular cronjob, 0723.1 was the one for the kernel rebuild (but amd64 didn't have the new kernel and the .manifest was outdated), 0723.2 was the phantom rebuild darkxst triggered last night to correct that (it was announced in this channel but never showed up), finally fixed by 20130724
<infinity> mlankhorst: The kernel, or the whole stack?
<infinity> mlankhorst: http://people.canonical.com/~ubuntu-archive/pending-sru.html will tell you that the stack is still in proposed.
<stgraber> qatracker=> SELECT qatracker_build.id, qatracker_product.title, users.name, qatracker_build_milestone.date, qatracker_milestone.title FROM qatracker_build LEFT JOIN qatracker_build_milestone ON qatracker_build_milestone.buildid=qatracker_build.id LEFT JOIN qatracker_product ON qatracker_product.id=qatracker_build.productid LEFT JOIN users ON users.uid=qatracker_build_milestone.userid LEFT JOIN qatracker_milestone ON qatracker_milestone.id
<stgraber>   id   |           title            |  name   |        date         |     title
<stgraber> -------+----------------------------+---------+---------------------+---------------
<stgraber>  49691 | Ubuntu GNOME Desktop i386  | darkxst | 2013-07-23 20:16:03 | Saucy Daily
<stgraber>  49691 | Ubuntu GNOME Desktop i386  | darkxst | 2013-07-23 19:26:56 | Saucy Alpha 2
<stgraber>  49690 | Ubuntu GNOME Desktop amd64 | darkxst | 2013-07-23 20:16:03 | Saucy Daily
<stgraber>  49690 | Ubuntu GNOME Desktop amd64 | darkxst | 2013-07-23 19:26:56 | Saucy Alpha 2
<stgraber> (4 rows)
<stgraber> slangasek: so it looks like darkxst manually added 20130723.2 to the tracker, the timing is a bit odd though
<stgraber> slangasek: anyway, that's not my script as it'd have shown up as ubuntu-cdimage otherwise
<mlankhorst> infinity: the stack parts
<slangasek> stgraber: AIUI infinity launched the rebuild and it didn't show up
<slangasek> stgraber: n/m, looking at scrollback, infinity's rebuild was 20130723.1
<slangasek> so I don't know why darkxst wanted 20130723.2, or why he added it manually
<mlankhorst> infinity: yeah I marked it as verification-done now because I've been running it locally for a while :-)
<infinity> mlankhorst: Alright.  I'll try to have a look at that all later.
<Riddell> is there a current list of flavour leads?  the ReleaseManifest pages don't exist any more and I don't think it can be taken out of iso tracker?
<phillw> there is somewhere, but I can't find it at the moment :/
<infinity> Riddell: http://iso.qa.ubuntu.com/qatracker/series/37/manifest ?
<Riddell> infinity: ooh that website is a mine of cool stuff now
<infinity> Riddell: Linked from the front page on the series list, FWIW.
<infinity> "Milestones for 'Saucy' series (product manifest | testsuites)"
<infinity> etc.
<phillw> A quick question.. there was a kernel release yesterday that got into the alpha 2 re-build for lubuntu, uname -a reports me as having 3.10.0-0-generic but bug 1204005 reports 3.10.0-5 has there been an interim kernel release?
<ubot2`> Launchpad bug 1204005 in linux (Ubuntu) "[saucy] kvm host hangs of guest boot with 3.10.0-5" [Critical,Triaged] https://launchpad.net/bugs/1204005
<slangasek> phillw: are you testing on powerpc?
<phillw> slangasek: nope, I'm on amd64
<slangasek> hmm
<phillw> slangasek: ahh, let me just check if my own system has been updated... (egg on face)
<phillw> I'm smoke testing 13.10 :)
<phillw> sorry, there are updates for my host machine :/
<phillw> I'll update and add an 'affects me' to the bug once I confirm it still happens.
<phillw> oh,  a kernel developer is on the case, so an affects me will simply subscribe me. Thanks, slangasek
<slangasek> sure
<phillw> slangasek: sorry to be back, but apt-get upgrade is telling me that it is holding back (amongst others) linux-generic linux-headers-generic linux-image-generic would you know why?
<slangasek> because apt-get upgrade is the wrong tool
<slangasek> you should be using apt-get dist-upgrade
<phillw> thank you, will add that to the wiki page :)
<slangasek> what wiki page?
<phillw> for how to do upgrades when smoke testing ubuntu+1
<slangasek> "what wiki page" - please tell me the url
<phillw> the page is going to be written tonight :)
<slangasek> hmm
<phillw> I don't like to keep coming here asking you guys stuff.
<slangasek> I find it hard to believe that there aren't existing wiki pages that cover this stuff... or should do so
<phillw> slangasek: I will look, as https://wiki.ubuntu.com/Testing/Testing_The_Devlopment_Release is a header page holding links to others.
<phillw> (as is it's parent page)
<darkxst> stgraber, yes I manually added ubuntu GNOME  20130723.2 via tracker but the images never showed up on cdimage. ( 20130723.1 still had a broken kernel)
<slangasek> darkxst: manually adding is not how you trigger a rebuild
<slangasek> darkxst: you should be using the 'request a rebuild' option at the bottom of http://iso.qa.ubuntu.com/qatracker/milestones/299/builds
<darkxst> slangasek, manually as in through tracker admin page?
<darkxst> oh never saw the box at the bottom there
#ubuntu-release 2013-07-25
<Riddell> JackYu: ubuntu kylin not doing alpha 2?
<Riddell> knome: how's the xubuntu testing going?
<knome> Riddell, so-so; i should be able to squeeze in a few tests myself today
<Riddell> knome: think you'll be able to declare it ready?
<knome> Riddell, when's the deadline?
<Riddell> knome: "today" :)
<Riddell> infinity: any preferred time to release?
<knome> sure, i'll be able to do that (or tell it's not ready if it seems totally broken)
<knome> Riddell, ^
<Riddell> groovy
 * Riddell starts on http://pad.ubuntu.com/saucy-alpha-2
<infinity> Riddell: No, preset release times are pointless.  When we're happy with the testing that's been done and each flavour gives a yes/no on their images.
<Riddell> knome: able to update this too? https://wiki.ubuntu.com/SaucySalamander/Alpha2/Xubuntu
<knome> Riddell, i'll get that done
<infinity> Riddell: Well, okay, *I* have a preferred release time of "within the next five or six hours" cause I had plans tonight.  But, really, if it's still Thursday somewhere in the world, meh.  I leave it up to you and the leads participating when to call it good (and/or to decide someone's not releasing).
<Riddell> infinity: presumably if needs you to be around to copy the images over?
<infinity> Riddell: Yeah.  Well, s/me/someone with cdimage access/, but I was the one who signed up for that. ;)
<phillw> infinity: a bit of advice, please.... We're happy enough with our A2's, but there is a little gremlin in the i386 alternate which is solved by using the 3.10.0-5 kernel (it's currently on 3.10.0-4). As this is more a bug fix; can I mark it for a respin and accept the test results from before?
<darkxst> phillw, 3.10.0-4 is nasty!
<infinity> phillw: Erm, I rebuilt everything for the new kernel, didn't I?
<infinity> phillw: And confirmed, the current image has -5 in it.
<darkxst> infinity, something went funny there, our first (ubuntu GNOME) respin did not pick up -5 kernel
<phillw> infinity: in that case, I'll go and kick the tester :)
<jbicha> http://cdimage.ubuntu.com/lubuntu/daily/current/saucy-alternate-i386.list syas 3.10.0-4
<jbicha> *says
<phillw> jbicha: I'll not go and kick the tester... :)
<infinity> Oh, stgraber only checked the desktop image. ;)
<infinity> I'll respin the alternate.
<infinity> Or, wait.  Yeah.  You can. :P
<jbicha> as does amd64 and amd64+mac
<infinity> phillw: Respin away.
<phillw> infinity: if we respin all the alternates, that will resolve any 3.10.-4 niggles and then we're good to go :)
<Riddell> phillw: this is lubuntu?
<phillw> Riddell: yes, (we're the only one with alternates :) )
<Riddell> phillw: can you get someone to update https://wiki.ubuntu.com/SaucySalamander/Alpha2/Lubuntu ?
<phillw> Riddell: I certainly will.
<Riddell> awooga
<darkxst> I am off for the night, but ubuntu GNOME images are good to go!
<jbicha> darkxst: thanks
<phillw> Riddell: I've to go out for a couple of hours, I'll do the release notes on my return (the respins should be complete by then) I've marked the bug as fix released re the -4 kernel issue.
<JackYu> Riddell, we will:)
<Riddell> JackYu: marked ready with no tests complete?
<JackYu> Riddell, a mistaken, will retest soon
<JackYu> Riddell, our QA team is testing this new version.
<maclin> Riddell: we are still doing tests
<Riddell> groovy
<knome> Riddell, i'm pretty happy with the xubuntu tests, so if you're only pending on us, we can make them ready; but if you need to wait for others as well, we might run a few more tests later
<knome> release managers, wondering if bug 1185396 is xubuntu-specific or if it affects everybody
<ubot2`> Launchpad bug 1185396 in gnome-system-tools (Ubuntu) "users-admin crashed with SIGSEGV in gst_user_profiles_get_for_user()" [Undecided,Confirmed] https://launchpad.net/bugs/1185396
<knome> Riddell, https://wiki.ubuntu.com/SaucySalamander/Alpha2/Xubuntu is pretty much also done if you decide to release
<jbicha> knome: well not "everybody" as several flavors don't ship gnome-system-tools
<jbicha> it's unmaintained upstream
<knome> jbicha, right... so what do they use to create users and groups?
<jbicha> Ubuntu, Kylin, and GNOME use gnome-control-center; Kubuntu uses systemsettings
<jbicha> gnome-control-center doesn't do groups; someone is either Standard or Administrator
<ScottK> Actually Kubuntu uses userconfig, but that may change soon as there's a new replacement coming.
<Riddell> so just lubuntu alternates we're waiting on
 * Riddell out for an hour
<Riddell> phillw: lubuntu all ok?
<Riddell> without tests?
<phillw> Riddell: it was just a respin to fix a known bug in the old kernel, that bug is marked fix released as manually updating the kenel removed the critter http://launchpad.net/bugs/1203852
<ubot2`> Ubuntu bug 1203852 in debian-installer (Ubuntu) "Lubuntu Saucy fails to boot after installation" [Undecided,Fix released]
<phillw> the alternates didn't get respun when the new kernel was globally updated :)
<Riddell> phillw: so you're happy to release untested images for this alpha?
<phillw> quite happy, I've looked at the bugs from the previous build, the only critical one was re: the kernel.
<Riddell> okay dokay
<Riddell> infinity: wants to pull the release leaver?
<phillw> https://wiki.ubuntu.com/SaucySalamander/Alpha2/Lubuntu has been updated.
<infinity> Riddell: When I'm out of this meeting, yeah.  How's 1700 BST (or so) for you?
<Riddell> infinity: lovely
<knome> does that convert to 18UTC?
<Riddell> other way
<infinity> knome: 16UTC
<knome> okay
<Riddell> anyone got comments on http://pad.ubuntu.com/saucy-alpha-2 ?
<knome> Riddell, s/XFCE/Xfce/ (i did that, but for future)
<Riddell> knome: but it's still pronounced x.f.c.e. ?
<knome> yup
<Riddell> hard to pronounce that as a word really
<Riddell> I've always said Gnome should be written as a word but they never listened to me
<knome> it used to be an acronym, but the acronym wouldn't be technically correct any more, so it's just Xfce :)
<knome> agreed with the GNOME thing, it's just obtrusive in a block of text ;)
<knome> btw, was there something else to be fixed in the xubuntu alpha page on the wiki or was it just that we needed to fill in?
<knome> Riddell, ^
<Riddell> just needed filled in
<knome> oki
<jbicha> GNOME!
<jbicha> I think the exclamation point helps
<knome> yes, the name itself doesn't stand out as much :P
<Riddell> removing Laney's mega block
<Laney> :'(
<Riddell> Laney: but we won't forget you!
<Laney> desecration of art, that is
<cafetiere> Benc. Will do.
<Riddell> cafetiere ?
<cafetiere> Wrong channel ...
<phillw> I missed those two! hope I'm not too late :)
<infinity> phillw: Too late, you don't get to upgrade.
<stgraber> knome: do you plan on releasing amd64?
<knome> stgraber, sure. as i said to Riddell, i'm ok with releasing stuff but if we're waiting for others, i might have had time to do more tests
<knome> stgraber, so if you're going to push the button... please also release our amd64 ;)
<infinity> knome: It's releasy time, so mark it ready for me.
<knome> i will
<infinity> Just building the source ISOs now.
<knome> done.
<Riddell> infinity: ETA?
<stgraber> Riddell: in progress
<infinity> Riddell: Iz publishing.  Pushing mirrors shortly.
<infinity> Riddell: Syncing mirrors.
<Riddell> infinity: is there a secret to being able to send to ubuntu-devel-announce?
<infinity> Riddell: Nope.  Did you already post?
<infinity> Riddell: Apparently not.
<infinity> Riddell: It's moderated (by me, and a few others), feel free to send your announce, and I'll accept it as soon as the mirrors settle down on their rsync.
<Riddell> infinity: send
<Riddell> infinity: sent
 * Riddell out
<infinity> Riddell: Cool.  Just waiting on mirrors.  Still. :P
<infinity> Riddell: Sync done, announce out.  Thanks.
<phillw> infinity: whilst you wait on that, is there an email addy I could send you a recent email regarding PPC? It not only runs as liveCD, it installs and a long time bug has vanished.
<infinity> phillw: Sure.
<phillw> infinity: sent to your ubuntu account
<ChrisTownsend> Hi!  I'd like to get an opinion on a Raring SRU Unity bug: https://bugs.launchpad.net/unity/+bug/1074038 - Some of the strings pointed out by the bug reporter are still not translated.  The code is good and is needed in order to have the strings translated, but until a new language pack is done, some of the strings won't be translated.  Should I consider this verification-done or verification-failed since some
<ubot2`> Ubuntu bug 1074038 in Ubuntu Translations "Unity: Some untranslatable and wrong strings in the previews" [Medium,Triaged]
<phillw> Riddell: and to put your (and anyone elses mind at rest), the team have been busily checking the respin of the alternate images for lubuntu and are very happy that the bugs seen in the -4 kernel are gone with the -5 and there are no regressions (which I guess was always going to be a concern). Thank-you to the team for allowing such a late respin.
<phillw> Riddell: I'll be quiet soon, honest! for Alpha 1 the release notification was also sent to ubuntu-release@lists.ubuntu.com I've just joined the ubuntu-devel-announce listing, so I suspect some other people may not have recived the notification.
<ScottK> phillw: Anyone involved in Ubuntu development is supposed to subscribe to u-d-a.  u-r is really just for the release team.
<phillw> ScottK: I'm new... I have now joined :)
<phillw> there seems precious little info for new people as to what to do, I'm flying by the seat of my pants on which teams / mailing lists etc. I should be on :D
<mlankhorst> phillw: because usually it's the other way around, and people just get something done first and then find those things out later
<phillw> mlankhorst: as is the case with me :) I thank you good people for your patience... especially when I goof up  big time!
#ubuntu-release 2013-07-26
<rtg> when is the Saucy kernel currently lodged in -proposed gonna get promoted ? Is it automagic ?
<cjwatson> It is automagic if you get it right
<infinity> rtg: Sometime, and maybe.
<cjwatson> I'm currently writing docs on how it all works ...
<cjwatson> (Well, modifying Debian's docs to taste)
<cjwatson> Looks like the linux-signed/amd64 autopkgtest is running
<cjwatson> Or rather the linux/amd64 autopkgtest, triggered by linux-signed
<cjwatson> As previously discussed there's an argument that that test is useless as well as broken
<infinity> (Forcing it for now anyway)
<infinity> rtg: Should squirt out the other end into release in the next cycle.
<infinity> rtg: We'll discuss the uselessness of that test in general when we're in the same room next week.
<rtg> otp - be with you in  a sec
<infinity> rtg: The point of the above was that I don't need you, enjoy your phone call.
<rtg> infinity, ack
<phillw> Hi good people, would anyone have the time to look over the two lubuntu ppc images and see if they can be put on a quick diet to get them back to CD size for tonights autobuild as I've asked the testers to give them a thorough test over the weekend. Thanks.
<infinity> phillw: They're broken anyway, remember?
<infinity> phillw: BenC and I need to do some playing with the kernel before it's worth looking at the CD images.
<phillw> infinity: that's the odd thing... they're not! I did send you an email :)
<infinity> phillw: The alternates are definitely broken.  The live ones may or may not be.  They probably weren't testing the absolute latest.
<cjwatson> The live ones are using an old squashfs.
<cjwatson> Success is irrelevant.
<cjwatson> You should unask your testers.
<phillw> okies, will do!
<cjwatson> infinity: https://wiki.ubuntu.com/ProposedMigration
<rtg> cjwatson, how about 'Migrating packages from -proposed to -updates' ? Otherwise it sounds like an idea that you're putting forth, rather then a fait accompli. It also a bit more searchable IMHO.
<cjwatson> Probably true except that it's not to -updates
<cjwatson> Changed the page title; do I have to rename it as well?  I've already linked to it from a couple of places :)
<rtg> cjI'm fine with that :)
<rtg> cjwatson, ^ (dang tab completion)
<cjwatson> When we create the devel* links that page will get a lot more comprehensibly drafted
<cjwatson> Very fed up with writing "the release pocket"
#ubuntu-release 2013-07-27
<jbicha> it looks like alsa-utils won't migrate until the sl-modem-daemon amd64 binary is removed
<ScottK> Is there a bug?
<jbicha> http://ftp-master.metadata.debian.org/changelogs/non-free/s/sl-modem/unstable_changelog says "Build sl-modem-daemon for i386 only"
<ScottK> OK.
<cjwatson> Not really sure how that got past proposed-migration ...
<cjwatson> Removed, anyhow
#ubuntu-release 2013-07-28
<micahg> do we have a way to see who binNEWd something?
<ScottK> No.
<micahg> great, I just got a notice that something that was rejected in Debian by ftpmasters seems to have passed Ubuntu review, do we allow packaging to be licensed under a conflicting license with the upstream source (which might result in trouble is upstream needs patching)?
<micahg> so, we're only tracking rejects then?
<infinity> micahg: We don't track rejects either, except via the email you get.
<infinity> (This is all being worked on actively right now, mind you)
<micahg> ok
<infinity> micahg: Anyhow, if you could be a bit more explicit about "the thing that Debian rejected and we didn't", maybe we could look into it.  Positing hypothetical scenarios is less helpful.
<micahg> sorry
<micahg> python-warlock apache 2 (source) + GPL (packaging)
<infinity> That said, if it's just mismatched source/package licensing, that's not a legal problem, just a style issue, as you need to explicitly license your patches, OR get hunted down later when someone wants to submit them upstream.
<infinity> (I agree that it's a valid reason for Debian to reject on the basis of teaching maintainers to not be silly)
<micahg> hrm, so debian/* in d/copyright doesn't really mean that?
<infinity> Erm, also, python-warlock has been in Ubuntu since Quantal...?
<micahg> right, it seems the new python3 package
<infinity> micahg: No, it means what you think it means.
<infinity> micahg: I meant that it doesn't make the package itself a legal issue, it just makes things a hassle if someone wants to forward patches later.
<micahg> oh, patching an apache license package with gpl code is not a problem?
<infinity> micahg: Anyhow, I assume ftpmaster's rejection will lead to a relicensing by the maintainer, and the world will be sunshine and kittens.
<infinity> micahg: Depends.  Is the packaging 2, 2+, 3...?
<micahg> 2+
<infinity> micahg: Yeah, then it's fine.
<micahg> ah, apache 2.0 + GPL 3 is fine, so GPL-3 is implicitly used in that case
<infinity> micahg: Of course, it has the weird side-effect of making the whole package be relicensed as GPL-3.  Probably not the desired effect. ;)
<micahg> hrm...sorry for the noise I guesss
<infinity> micahg: It's still a problem, I agree with Debian ftpmasters, but I imagine it'll now get fixed and we'll get the trickle-down, so I'm not too concerned.
<micahg> ok
<infinity> micahg: It's not something we can't legally distribute, so I'm fine with waiting on Debian to fix.
<micahg> I was just wondering if we're missing a check on our side so stuff like this doesn't make its way into the Ubuntu archive
<micahg> (more hypothetical)
<infinity> micahg: As a general rule, binNEW doesn't trigger people to do a full source audit.  The Debian ftmaster that did so must have been either (a) a keener, or (b) had a nitpick about something in the binary package he was looking at, and dug deeper.
<infinity> micahg: binNEW for me usually consists of looking at the file lists for sanity, and if there's some funky migration business going on, conflict/replaces and maintainer scripts.  I tend to trust that souce new caught the glaring badness in the rest of the source.
<micahg> ok
<infinity> micahg: Though, now that debian/copyright is occasionally machine parseable, Debian might be running a tool that looks for obvious things (like upstream/package license mismatch) and warn on it whenever something's in NEW.  Dunno.
<infinity> I wish it was just policy for all debian/* packaging to always be in X11/MIT/Expat or similar.
<micahg> it would make sense
<infinity> Cause I really doubt people check the debian/* licensing before cargo-culting from package A to package B anyway.
<infinity> (And I also really doubt anyone cares about their precious debian/* copyleft)
<micahg> right, TBH, the thought's not crossed my mind
<micahg> it would be a sane thing to check indeed
<darkxst> mozjs update has been sitting in the new queue for two months now
<darkxst> we really want to get this in for saucy since it brings huge performance improvements for ubuntu GNOME/gnome-shell
<infinity> darkxst: Was there a reason for the new source package, instead of revving the current one?
<infinity> darkxst: And are there plans to get mozjs17 into Debian too?
<infinity> darkxst: Also, it looks like a ton of files have changed their license headers from MPL/GPL/LGPL to just MPL.  Is that going to be a problem for GNOME?
<infinity> darkxst: Ahh, MPL2.0 has built-in GPL/LGPL compat.  Handy.
<darkxst> infinity, it is not backwards compatible with old one. it would be quite a ton of work to port all the rdepends, and atleast couchdb can't work with the new mozjs
<darkxst> infinity, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709434
<ubot2`> Debian bug 709434 in src:mozjs "mozjs: Please upgrade to last release (mozjs17.0.0)" [Wishlist,Open]
<darkxst> I imagine it will get into debian eventually but right now there doesnt seem to be much interest from them.
<infinity> darkxst: Well, Chris maintains the Debian mozjs, no?  Would make sense for him to get this one in too.
<infinity> darkxst: I mostly just don't want to see it done independently in Ubuntu and Debian and have you guys shoot yourselves in the foot with a painful migration later to sync up.
<infinity> darkxst: Other than that, it looks fine, and I'm inclined to let it in.  Just trying to look out for overall archive health on that point.
<infinity> chrisccoulson: You have any opinions on the mosjz17 in saucy/NEW, or any inclination to maintain it in Debian?
<jbicha> we've tried pinging Chris before; I didn't get the impression he was at all interested in maintaining mozjs
<jbicha> https://lists.ubuntu.com/archives/ubuntu-devel/2013-February/036532.html
<jbicha> I think people are just hoping someone else will review it :|
<infinity> jbicha: I'm happy to review it in Ubuntu, I just don't want to see Debian go another route and cause a massice headache while people migrate packaging to match.
<infinity> jbicha: If there's a strong commitment to maintain it in Ubuntu and no current interest in doing so in Debian, I'm sure you could find a sponsor.
<infinity> jbicha: (Maybe Laurent, who filed the bug)
<darkxst> infinity, right now gjs is the only project using it
<darkxst> and probably it will stay like that until its more widely available
<darkxst> well newer polkit supports it as well, but that will still build with old version
<jbicha> I don't think the Debian packaging will diverge significantly and the Ubuntu GNOME maintainers will take care of fixing things if it does
<infinity> Mmkay.
<infinity> Will this need an MIR as well, or is universe fine for now?>
<infinity> darkxst, jbicha ^
<darkxst> infinity, universe would be fine for now, gjs/gnome-shell are in universe anyway
<infinity> darkxst: Accepted, then.
<infinity> And now I need to go file my own MIR for the new eglibc build-deps.  Grr.
<darkxst> infinity, thanks! ;)
#ubuntu-release 2014-07-21
<wgrant> stgraber, xnox: Should be fixed.
<xnox> \o/ got accept email =)
<ochosi> hey folks, if anyone could push this no-brainer SRU so our new users also get the fix (we forgot to flip the settings-switch with the previous SRU): https://bugs.launchpad.net/ubuntu/+source/xubuntu-default-settings/+bug/1342065
<ubot93> Launchpad bug 1342065 in xubuntu-default-settings "[SRU] xubuntu-default-settings 14.04.5" [Undecided,Fix committed]
<ochosi> the xubuntu users will appreciate it! :)
<ochosi> infinity: ^
<ogra_> cjwatson, infinity, shouldnt raring be on old-releases.u.c ? seems it isnt there
<Laney> http://old-releases.ubuntu.com/ubuntu/dists/
<Laney> Looks there to me
<ogra_> oh, silly me ... i looked at http://old-releases.ubuntu.com/releases/
<Laney> ah, not sure about the images
<ogra_> yeah, i was actually just looking for debs ... thinko :)
<Laney> who's running 14.04.1?
<stgraber> infinity:
<stgraber> https://wiki.ubuntu.com/UtopicUnicorn/ReleaseTaskSignup
<Laney> oh it's on *Utopic*
<Laney> for some strange reason I didn't look there ;-)
<stgraber> come on, it totally makes sense :)
<Laney> added it to T too
<infinity> Laney: Yeah, it's arranged by cycle, I guess.
<Laney> infinity: I get why, just never thought to look there.
<Laney> infinity: You expecting the current date to happen?
<infinity> Laney: Do you see a reason why it can't?  Freeze today, test images, release Thursday.
<infinity> If the reason is "people want to put more fixes in" that's on them for not reading the schedule. :P
<Laney> infinity: Nope. We were just chatting about it in #ubuntu-desktop. I think maybe there were more announcements in advance of 12.04 point releases or something.
<infinity> Laney: Some of them may have had a pre-freeze warning (though, not all of them did, I don't think).
<infinity> Laney: But dot-one should be pretty low key.  No HWE stack or anything, so it's really just "all the fixes we've SRUed over the last three months", and if you didn't have time to land something, warning wouldn't have created time. ;)
<Laney> I'm remembering the freezes on https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule
<ochosi> infinity: any chance we could get that xubuntu-default-settings sru in that i linked to before?
<ochosi> it's only a default settings change to fix suspend+lock for new installs (the fix is already there, just the new default setting isn't)
<infinity> ochosi: Is it in the queue or in -proposed, or still needs uploading?
 * infinity reads backscroll.
<ochosi> it's already in -proposed afaik
<ochosi> https://bugs.launchpad.net/ubuntu/+source/xubuntu-default-settings/+bug/1342065
<ubot93> Launchpad bug 1342065 in xubuntu-default-settings "[SRU] xubuntu-default-settings 14.04.5" [Undecided,Fix committed]
<ochosi> infinity: ^
<infinity> ochosi: So it is.  But it hasn't been verified.
<ochosi> yeah, i know, but it's a settings change...
<ochosi> (if i wouldn't sit behind such a bad connection right now i'd dl a new image just to confirm it)
<ochosi> infinity: what's the final final deadline for this to get verified?
<infinity> ochosi: Well, please get someone to verify it, and we can slide it in.
 * ochosi goes on a pinging rampage
<infinity> ochosi: The deadline is around nowish.  But it's up to whoever is coordinating testing your images if they want to respin and retest after this is promoted.
<ochosi> well i'd prefer to just get it in now instead of respinning...
<infinity> ochosi: Sure, I would too, but I don't want to revert it if someone finds an issue with it either, hence the verification step being useful. :P
<ochosi> thing is, if there's an issue, it'd be with the already verified SRU (xfce4-power-manager and light-locker-settings patches)
<ochosi> infinity: ok, just got our QA lead to verify
<ochosi> infinity: let me know if there's anything else standing in the way of getting this into 14.04.1
<infinity> ochosi: That should do.
<ochosi> great
<ochosi> phew
<ochosi> thanks again infinity
#ubuntu-release 2014-07-22
<jibel> infinity, are you coordinating the release of 14.04.1? Can you add it to the tracker?
<jamespage> infinity, I think that I have most of the proposed docker SRU prepared and ready for upload - care to review bug 1338768?
<ubot93> bug 1338768 in golang-pty-dev "[SRU] Update to 1.0.0 release" [High,New] https://launchpad.net/bugs/1338768
<infinity> jamespage: Not just now, but soon, yeah.
<jamespage> infinity, ta
<infinity> jibel: Should be added.
<jibel> infinity, thanks. There is no build, is 20140722 the first candidate or you'll do a new build?
<xnox> infinity: well, I was hoping to have bug #1275162 published for point release, but  bug #1314134  is not verified yet. Both bugs affect the installation itself.
<ubot93> bug 1275162 in grub2 "incorrect efibootmgr command is set by update-grub under OVMF" [High,Fix committed] https://launchpad.net/bugs/1275162
<ubot93> bug 1314134 in grub2 "network stack never yields control on busy networks" [High,Fix committed] https://launchpad.net/bugs/1314134
<jibel> xnox, I can do the verification of 1275162
<jibel> ah, nm, it's verified.
<xnox> jibel: that one is verified, the haevy traffic needs verification.
<xnox> jibel: yeap.
<xnox> cjwatson: stgraber: any clue how to simulate / test bug #1314134 ?
<ubot93> bug 1314134 in grub2 "network stack never yields control on busy networks" [High,Fix committed] https://launchpad.net/bugs/1314134
<infinity> jibel: There will be new builds soon(ish)
<cjwatson> xnox: honestly, if grub works at all, I'd just go for it ...
<infinity> Quality advice on quality, right here folks. ;)
<cjwatson> \o/
<cjwatson> unless you happen to have a netboot setup already
<infinity> But since the last d-i build would have been with that grub, we're vaguely committed anyway.
<infinity> And it's been in proposed for eons, with no complaints.
<infinity> So, let's do it.
<infinity> Hrm, I guess I should turn off cron.
<xnox> cjwatson: daily isos are netbooted in the test infrastructure, on jenkins. so that works, and our network should be busi-ish? or is this some kind of special busy?
<xnox> trusty is 100% both on desktop-netboot and server images.
<cjwatson> xnox: I doubt the netbooting goes through grub
<xnox> cjwatson: oh. ok. so it's grub networking =/ no idea about that.
<infinity> jibel: The RC builds should start spitting out soon now, if you want to remind flavour testers that they're all LTS this time around. :P
<infinity> jibel: (especially mythbuntu, who completely forgot at release time...)
<tgm4883> infinity: I don't suppose this will include our sru packages still in the queue
<Pici> I'm seeing an update for base-files to 7.2ubuntu5.1 in trusty-updates.. which just caused some confusion in #ubuntu. Is this intended?
<infinity> Pici: What confusion did it cause?
<infinity> Pici: And yes, it's intended.  We're releasing 14.04.1 on Thursday, which means needing to update base-files a bit in advance so we can spin and test images.
<Pici> infinity: Well, we sometimes ask people to post the contents of /etc/issue to determine which version of Ubuntu they are running.  Seeing 14.04.1 just threw us for a loop.
<Pici> infinity: okay.
<infinity> Pici: This happened 4 times in 12.04, you'd think people would be used to it by now. :)
<infinity> Pici: If you want a number that never changes, you want 'lsb_release -rs'
<infinity> Pici: /etc/issue is purely cosmetic.
<Pici> infinity: Yeah, but thats a lot of typing for people who can barely use the terminal.  But thanks :)
<infinity> cjwatson: Argh, why didn't we fix the linux-signed-in-live-seed issue? :(
<cjwatson> damn, I thought I had
<infinity> I'm going to see if there's something I can do that's less painful than the "stop using tasks" thing.
<infinity> Though, I guess we need that change for 14.04.2 anyway.
<pfsmorigo> hi, what's the diff between 20140722.1 and 20140722 in daily?
<infinity> pfsmorigo: The former is newer.
<pfsmorigo> infinity: you mean 20140722.1, right? why there isn't ppc64el in it?
<infinity> pfsmorigo: For which image?
<infinity> pfsmorigo: trusty server?
<infinity> Actually, that's a good question.
<pfsmorigo> infinity: yep... http://cdimage.ubuntu.com/ubuntu-server/trusty/daily/20140722.1/
<pfsmorigo> infinity: I need to check a bug fix. Can I use 20140722?
<infinity> pfsmorigo: Depends on which bug.
<pfsmorigo> infinity: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1334649/comments/2
<ubot93> Launchpad bug 1334649 in debian-installer "ppc64el/cdrom: ieee1275/cdrom devalias doesn't work on all machines" [High,Fix released]
<infinity> pfsmorigo: You can test that with a d-i mini.iso
<pfsmorigo> infinity: nice!
<infinity> pfsmorigo: http://ports.ubuntu.com/ubuntu-ports/dists/trusty-proposed/main/installer-ppc64el/20101020ubuntu318.3/images/netboot/
<pfsmorigo> infinity: let me check.. tls
<pfsmorigo> s/tls/tks/
<infinity> genisoimage: Volume ID string too long
<infinity> FFS.
<infinity> Indeed, I bet this is why the powerpc ISOs are "ppc" instead of "powerpc".
<infinity> cjwatson: Preference on how to cheat here?  s/ppc64el/ppc64/?  s/ppc64el/POWER/?
<infinity> cjwatson: Adding ".1" to the string sent it over the edge. :P
<infinity> slangasek: ^-- You like to have opinions about this sort of thing.
 * infinity will probably just go with ppc64, not terribly confusing on Ubuntu, where we don't have that dpkg arch.
<infinity> Well, that's helpful, apt.
<infinity> (trusty-amd64)root@cthulhu:~# apt-get install ubuntu-live^ linux-image-3.13.0-24-generic- linux-signed-image-3.13.0-24-generic- linux-image-extra-3.13.0-24-generic- linux-headers-3.13.0-24-generic- linux-headers-3.13.0-24-
<infinity> [...]
<infinity> The following held packages will be changed:
<infinity>   linux-headers-3.13.0-24 linux-headers-3.13.0-24-generic linux-image-3.13.0-24-generic
<infinity>   linux-image-extra-3.13.0-24-generic linux-signed-image-3.13.0-24-generic
<infinity> In other words, "I heard you, and I'm going to install them anyway, nyah nyah."
<infinity> cjwatson: Huh, the plot thickens.  These builds were working in -proposed (ie: not pulling in two kernels), but don't work with proposed turned off.
<infinity> That doesn't even make sense...
<slangasek> infinity: opinions> I don't know that I'd say I like to have them; they're a cross I bear
<slangasek> infinity: if this is for genisoimage volume ID, I'm not sure I really care :) what's the actual limit?
<cjwatson> ppc64 would be fine; we use ppc for powerpc
<cjwatson> the limit is documented next to the code that does that
<cjwatson> I think
<cjwatson> oh, it's documented in cdimage/lib/cdimage/project.py
<cjwatson> see r1406
<cjwatson> infinity: dodgy tasks or something?
<infinity> cjwatson: I can't sort out how to reproduce the issue by pulling add_task out of livecd-rootfs and abusing manually. :/
<infinity> cjwatson: Then again, the quoting on this makes my head hurt.
<infinity> I think it amounts to this, though:
<infinity> apt-cache dumpavail | grep-dctrl -nsPackage \( -XFArchitecture amd64 -o -XFArchitecture all \) -a -wFTask ubuntu-live -a --not -Pe "^linux-(headers|image|signed)"
<infinity> And I can't get that to give me a kernel with or without proposed enabled.
<infinity> Which it shouldn't.
<infinity> So, WTF.
<cjwatson> if you can wait an hour or two I can look properly
<infinity> cjwatson: I'd appreciate it.  It sure looks like you fixed this, so why it's unfixing itself is a mystery to me.
<infinity> I might have some breakfast.
<cjwatson> infinity: link me the failure while you have it?
<infinity> At least ppc64el is fixed.
<infinity> cjwatson: https://launchpadlibrarian.net/180527763/buildlog_ubuntu_trusty_amd64_ubuntu_FAILEDTOBUILD.txt.gz
<infinity> cjwatson: Compare to success at https://launchpadlibrarian.net/180455287/buildlog_ubuntu_trusty_amd64_ubuntu_UPLOADING.txt.gz
<infinity> cjwatson: Or, you know, your stellar UI at https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/trusty/ubuntu ;)
<cjwatson> shush you
<cjwatson> I'll fix it at some point :)
<infinity> Hey, it works.
<infinity> It's just impossible to find.
<cjwatson> needs an index of livefses
<infinity> cjwatson: The log is twice the size because, unshockingly, linux-headers is all dupe files.  Othwerwise, they're pretty much identical, save proposed/!proposed, and one getting two kernels for no discernable reason.
<cjwatson> infinity: it's using the wrong livecd-rootfs version ...
<infinity> Well, more than two kernels, two kernels, headers, etc.  So, it really looks like the task filter is failing to filter.
<cjwatson> so um argh how do we fix that in time
<cjwatson> 2.208 vs. 2.208.1
<infinity> Err, so it is.
<infinity> Not pulling from -updates. :(
<cjwatson> I think I know
<cjwatson> It should work if we give it pocket="Updates"
<cjwatson> Mostly it doesn't matter, but it does for livecd-rootfs
<infinity> It matters in general, IMO, since we want to be able to update our build tools.
<infinity> But, in practice, that's usually just livecd-rootfs and live-build, sure.
<infinity> So, this bit here:
<cjwatson> Right, I mean it doesn't matter for the inside of the livefs
<infinity>     if config["PROPOSED"]:
<infinity>         kwargs["pocket"] = "Proposed"
<infinity>         metadata_override["proposed"] = True
<infinity>     else:
<infinity>         kwargs["pocket"] = "Release"
<cjwatson> Right, I'm just fixing that
<cjwatson> config["DIST"].is_latest is the relevant thing, so it stays Release for utopic but goes to Updates for <utopic
<infinity> Mangling it to just hardcode precise, trusty for now?
<infinity> Ahh, or that.
<infinity> Much cleaner.
<cjwatson> infinity: try now
 * infinity retries ubuntu-desktop
<infinity> Will do the rest when this appears good.
<cjwatson> re dupe files, I canned that in utopic, just not in trusty
<cjwatson> because we haven't cared for years
<infinity> It's an interesting metric, but only if someone actually reads it.
<infinity> It's just useless data in the wind otherwise, and a waste of CPU time.
<cjwatson> More to the point, it can be computed latr.
<cjwatson> *later
<infinity> True, that too.  Could be a QA test.
<cjwatson> Yeah, we could stick it on ci.ubuntu.com if we felt like it.
<cjwatson> I don't think anyone cares enough though
<infinity> Well, it was an interesting metric that led to things like pkgbinarymangler deduping copyright/changelog, etc.
<infinity> Though, not sure if the livefs builds were directly responsible, or just someone saying "look, that's pointless duplication".
<infinity> But a QA/CI read on pointless duplication wouldn't go amiss.
<infinity> Both exact duplication (identical files, like fdupes was telling us), and suspicious possible duplication (multiple versions of libfoo[0-9] installed, for instance) would be interesting.
<infinity> tgm4883: Sorry, missed your question in the dramatic backscroll there.
<infinity> tgm4883: Which packages were you curious about?
<tgm4883> infinity: we've been trying to SRU the mythtv packages, but haven't had any comments in about a month now  https://bugs.launchpad.net/ubuntu/trusty/+source/mythtv/+bug/1323391
<ubot93> Launchpad bug 1323391 in mythtv "Update to 0.27.1 point release" [Undecided,In progress]
<tgm4883> I don't want to just ping this room every day, but I don't know what else to do
<infinity> tgm4883: Hrm, the last comment there implies that there's a 0.27.2 around the corner.
<phillw> hi, could some make the builds for the rest of lubuntu builds? This will be .2 builds?...
<tgm4883> infinity: While that is true, since we weren't getting any comments on that we didn't want to have to start the process over by uploading a new one
<infinity> tgm4883: Anyhow, short answer, no that won't be able to make the point release ISO, even if I review and accept it today.  But yes, we should push forward with this, and users can upgrade post-install.
<tgm4883> infinity: ok, should I upload the latest point release then?
<infinity> phillw: I'll rebuild lubuntu in a second after we verify our amd64 fix is happy.
<tgm4883> I mean, we really only planned on doing this (SRU's) for point releases, but yes we should give them something they can upgrade to
<infinity> tgm4883: I think moving to the latest point release is smart, but we also need to review this fairly extensively (though, I think ideally, we'll want to get you guys to apply for an MRE for this).
<infinity> tgm4883: "For point releases" is somewhat meaningless anyway, a package upgrade is an upgrade, if it's on an ISO only really matters if it affects the installation.
<tgm4883> infinity: I thought MRE's were only needed for packages with new features?
<phillw> infinity: thanks.. sorry to be the person here... our TL is just back from a meeting and our other Release manager is at osscon
<infinity> tgm4883: No, the point of an MRE is to say "there's extensive upstream QA on this, and lots of changes and we're not going to test every single commit/fix in Ubuntu to verify it".
<tgm4883> infinity: that is true, but many of our users treat our distro as an appliance. Which means install it and forget it (for better or worse)
<infinity> tgm4883: Without an MRE, you need to enumerate every single upstream change and validate each one.
<tgm4883> infinity: ah ok. Is there documentation for doing an MRE, I'm only aware of what superm1 gave me, which is the SRU documentation
<cjwatson> https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
<tgm4883> (I can go looking for it too)
<infinity> ^
<tgm4883> reading it now
<infinity> tgm4883: Cause, yeah, this 480K diff isn't something any of us can realistically review properly, not something you guys can realistically QA properly.  So, we need to rely on assurances that it's already sane before uploading (hence the MRE concept).
<infinity> s/not something/nor something/
<tgm4883> infinity: that makes sense.
<phillw> infinity: do you if jluien got his SRU's in, in time for our bugs on lubuntu?
<phillw> *do you know*
<infinity> phillw: No idea, since I don't know which those were.
<phillw> infinity: bug 1326740 and bug 1308348
<ubot93> bug 1326740 in xfce4-power-manager "[SRU] Please backport xfce4-power-manager 1.2.0-3ubuntu6 to trusty" [Critical,Fix released] https://launchpad.net/bugs/1326740
<ubot93> bug 1308348 in lxsession "network settings indicator missing from panel" [High,Fix released] https://launchpad.net/bugs/1308348
<cjwatson> if you have the bug numbers, you can look at the bug states
<phillw> cjwatson: both say fix released... will they be in the .1 release?
<cjwatson> that would imply yes
<infinity> phillw: If they were Fix Released before, uhm, now, then yes.
<infinity> phillw: Since I already pointed out that I was going to respin everything. :)
<phillw> infinity: it was close to time called, julien is busy after a conference, so I'm a bit stuck on witing up a set of release notes... any crumbs would be apprreciated :D
<phillw> infinity: Ahh, but are they in the list :P
<infinity> The List?
<phillw> the list of SRU's / bug fixes approved?
<infinity> phillw: If it's Fix Release, it's in The List.  We build from -updates, we don't hand pick packages to update.
<phillw> infinity: thanks... was not too sure how the diffeence between  'fix relased' and 'SRU'
<phillw> We had 'fix released' but were told it then needed an SRU
<infinity> phillw: It's Fix Released *in trusty* that's the important bit here.  Which both of those bugs are.
<phillw> infinity: that's good news, they were really annoying bugs
<phillw> bad press of people complaining is never good :)
<phillw> I will let you good people get on. thankyou for not kick-banning me. I still do care :)
<cjwatson> infinity: \o/
<phillw> infinity: have you respun the world now?
<infinity> phillw: That was just Ubuntu, not the world, but the world will now follow. ;)
<phillw> when can the lubunteers expect images (we have alt and desktop)
<infinity> And they're off.
<phillw> oh, and as you know, when we've done ours, we always help out other flavours :)
<infinity> phillw: Probably 1-2h for everything to be done.
<phillw> I'll try to hang on for at alts.... they will hopefully be a quick zsync unless you guys have done some thing major?
<infinity> And once these are all happy, I'll re-enable the flavour self-service stuff.
<phillw> infinity: both of who are afk.... c'est la vie :)
<phillw> infinity: lubuntu builds done, or still queued?
<cjwatson> phillw: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/trusty/lubuntu/+build/2646
<cjwatson> it got a slower builder on powerpc, but making progress
<infinity> phillw: Alternates are done, desktop are in progress, as cjwatson points out.
<phillw> Ill start off with alternates :)
<phillw> thanks
#ubuntu-release 2014-07-23
<phillw> anyone in from the complaints department?
<phillw>  trusty-alternate-amd64.iso != http://cdimage.ubuntu.com/lubuntu/releases/trusty/release/lubuntu-14.04-alternate-amd64.iso ?
<cjwatson> Good
<phillw> the name ing structure has been changed?
<cjwatson> Dailies are always like that
<cjwatson> Have been for the last ten years
<phillw> cjwatson: are we on name or number.
<cjwatson> Dailies by name, release by number
<phillw> cjwatson: it has not not for the last 4 years as there was a script that captured the ISOS.... in fact, I do recall you grabbing a lubuntu one from my mirror?....
<cjwatson> I beg to differ.
<cjwatson> Perhaps your mirror renames stuff or something, but dailies have always been like this.  I wrote the initial code ten years ago and have done most of the work on it ever since.
<phillw> some one changed it, as the script no longer works and the guy who wrote it has said he cannot be bothered to re write the entire thing... and he is a ubuntu member :P
<cjwatson> No, nobody changed this.
<cjwatson> If your script broke then it isn't for this reason.
<phillw> cjwatson: go argue with a ubuntu member who wrote the script and leave me out of it... bottom line... no backups now done.
<cjwatson> For example maybe it hardcodes codenames and just needs to be updated with recent ones.
<cjwatson> No, you're dragging me into it.
<cjwatson> Stop.
<cjwatson> Don't drag me into something and then tell me to leave you out of it.
<cjwatson> Not to mention that I have no idea where this script is or who I might talk to (but it's really not my responsibility, since as I say we didn't change the naming structure on our end).
<phillw> cjwatson: nope, I only provide the hosting area, it is a ubuntu guy who's code has worked to mirror up until this release.... I'm just letting you know. The guy is unit193 ... As I've had so much fun with the non-pae kernel working... I'll let you chat, if you wish, to wxl
<phillw> cjwatson: someone changed the naming system
<cjwatson> he's welcome to come and ask for help, but I'm not going to independently chase up the authors of various third-party mirroring scripts.
<cjwatson> No, nobody changed it.
<phillw> cjwatson: I'll ask him to get in touch.
<cjwatson> Yep, the scheme of naming dailies by codename is literally over ten years old.  First code for that predates my initial checkin of cdimage on 14 July 2004.
<phillw> cjwatson: he now does not wish to come on here for you to actually state that the naming has changed...
<cjwatson> Though admittedly it was "warty-i386-1.iso" back then.  The first point where it's recognisably the modern naming scheme was r28 on 12 October 2004.
<cjwatson> phillw: I'm happy to look at the script if pointed to the current running source code
<phillw> cjwatson: kk, let me just fetch it.
<phillw> cjwatson: as always, thanks... I'm just grabbing it now...
<cjwatson> phillw: That script only contains code to mirror milestone releases of one kind or another.  It contains no code to mirror daily builds.
<cjwatson> So I wouldn't expect it to work for the current 14.04.1-candidate daily builds.
<phillw> cjwatson: it is only there to hold mailestones, but it seems that naming was changed in a1 for 14.04
<cjwatson> What URL exactly?
<cjwatson> All you said was "trusty-alternate-amd64.iso".
<phillw> cjwatson: it changed... -rw-r--r--. 1 root root 665845760 Feb 25 16:36 lubuntu-14.04-beta1-alternate-amd64.iso
<phillw> the release number was replaced with name
<cjwatson> What URL exactly?
<phillw> This is very new.
<phillw> it was cdimagae
<cjwatson> What URL exactly?
<cjwatson> Seriously, there's no point giving me other information - this is the information I need
<phillw> http://cdimages.ubuntu.com/lubuntu/releases/12.04/release/lubuntu-12.04-alternate-amd64.iso
<phillw> notice any difeerence?
<cjwatson> No, that's a URL that works.  I need you to give me a URL that doesn't work.
<cjwatson> I can't notice any difference because you haven't given me the thing to compare against.
<phillw> using name instead of number
<cjwatson> What URL exactly?
<cjwatson> Where is the URL that uses a name, that you are complaining about?
<phillw> cjwatson: zsync http://cdimage.ubuntu.com/lubuntu/daily/20140623.1/utopic-alternate-amd64.iso.zsync
<cjwatson> That's a daily build.
<cjwatson> Your script doesn't mirror daily builds.
<cjwatson> So it can't be that.
<phillw> cjwatson: http://iso.qa.ubuntu.com/qatracker/milestones/317/builds
<phillw> that's the link for the buiold
<phillw> *build*
<cjwatson> Finally!  You're talking about utopic alpha-1.
<cjwatson> You said "trusty-alternate-amd64.iso" above, and "14.04".
<phillw> always worked in the past.. not working this time :)
<cjwatson> You never once mentioned utopic.
<cjwatson> So, alphas have been named like daily builds (i.e. using the codename instead of number) at least back to August 2010, possibly before but I don't have accurate records before then.  (Reference: http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/revision/132, lines 94-95)
<cjwatson> We only start using the version numbers once we reach beta
<phillw> cjwatson: I have a a guy who just runs the script.. he said it did not work as "someone" had messed yp the naming. As I'm not the most popular person on release I've kept quiet. However after today's "get the first point release out" I though I may try my luck at chatting and getting a kick ban :)
<cjwatson> I therefore strongly suspect that this script has always been broken for alphas, but nobody noticed; it will have worked as of beta
<phillw> cjwatson: the script had alphas....
<cjwatson> But I can assure you that this is not a recent change.  You're only noticing it now because you're actively paying attention to an alpha.
<cjwatson> The script may have done, but they did not work.
<cjwatson> In the form you showed me, it will only have worked for betas on, back as far as I can remember.
<phillw> cjwatson: you're a boss, you're also a boss I follow exactly... As always, thank you for your time. There is a completely crazy question I'd like to ask about alternate install....
<cjwatson> (Before 2010, it was reliant on whoever happened to be doing the publishing holding the correct rule in their head, so it's possible there was some inconsistency then, although I don't remember any.  Since mid-2010 it's been scripted.)
<phillw> cjwatson: why does the alternate ISO try to grab all the info from internet instead of using what is on the ISO?
<cjwatson> It doesn't grab it all from the network, only some.  The "some" is because in general it has to in order to provide things like complete language support.
<phillw> cjwatson: okiees, seems like I need to beg for a couple of scripters to tidy things up. If they do have proposed fixes, is there any on the release team who would review and sponsor?
<cjwatson> People are welcome to propose merges and they land in our mailbox, but as far as I can see there is nothing to change on our end.
<phillw> cjwatson: for lubuntu it grabs 729 / 729.... I disable internet when it tries
<cjwatson> The naming is a matter of policy.
<phillw> I recall when an alternate ISO could actually do an upgrade.... happy days :)
<phillw> I was told that I would need someone to update that script?...
<cjwatson> phillw: That script has nothing to do with us.
<cjwatson> So you may well need somebody to update it, but not the release team.
<cjwatson> And, as I say, the fact that alpha release files are named using the codename rather than the release version is a matter of longstanding policy.
<phillw> cjwatson: I have issued an invite to you... it is, of course, to you if you accept
<phillw> cjwatson: some times coders telling coders stuff is easier on us guys who do tsting :)
<cjwatson> It's much easier if you get into the habit of reporting problems literally rather than paraphrasing.
<cjwatson> This would have been much quicker if I'd had an expected/observed URL right from the start.
<phillw> hi, anyone got working links for the 14.04.1 ISOS@
<infinity> phillw: I sent out an email explaining how to fix them.
<ginggs> Is the someone who could approve nvidia-graphics-drivers-* in the Trusty queue, please?
<bluesabre> Hey everyone!
<bluesabre> We've reached verification-done for the following packages... is it possible to release them into trusty-updates?
<bluesabre> https://bugs.launchpad.net/ubuntu/+source/lightdm-gtk-greeter/+bug/1331871
<ubot93> Launchpad bug 1331871 in lightdm-gtk-greeter "[SRU] Please backport lightdm-gtk-greeter 1.8.5 to trusty" [High,Fix committed]
<bluesabre> https://bugs.launchpad.net/ubuntu/trusty/+source/menulibre/+bug/1323405
<ubot93> Launchpad bug 1323405 in menulibre "[SRU] Please backport menulibre-2.0.4 to trusty" [High,Fix committed]
<bluesabre> cjwatson, as today's vanguard, would you mind taking a look at the above?
<cjwatson> bluesabre: I'm not going to touch trusty right now due to 14.04.1 in preparation - any changes to trusty-updates may require respins
<cjwatson> bluesabre: talk with infinity
<bluesabre> infinity, would you mind taking a look?  One of the bugs fixed in menulibre is of a critical nature... when the issue happens with the current package, alacarte and menulibre will no longer function without deleting the menu file
<bluesabre> At the very least, if we could get menulibre uploaded, only the xubuntu isos would request respins
<Riddell> kubuntu images are oversized, removing gdb from them seems the best way to fix that, I've uploaded apport to do so but it needs a rapid SRU, not sure if that's possible. bug 1347565
<ubot93> bug 1347565 in apport "apport recommends gdb" [Undecided,New] https://launchpad.net/bugs/1347565
<Riddell> infinity: are you the dude to bless trusty changes â ?
<xnox> Riddell: isn't the best way to explicitly seed gdb-minimal, before seeding apport-kde, instead of uploading sru like that?
<xnox> and then upload updated meta (if needed)
<Riddell> hmm, maybe
<Riddell> infinity: which would you prefer?
<jibel> where can I find the livefs build logs of 14.04.1?
<jibel> nm, I got the answer
<xnox> infinity: cjwatson: i'm failing to work out why lubuntu trusty daily-live does not have btrfs-tools, yet it's present in utopic.
<xnox> https://bugs.launchpad.net/ubuntu-cdimage/+bug/1347345
<ubot93> Launchpad bug 1347345 in ubiquity "lubuntu/trusty/i386 missing btrfs-tools and hence fails to create btrfs filesystem" [High,Triaged]
<cjwatson> good question
<cjwatson> xnox: Needs r194 from lubuntu.utopic seeds backported to lubuntu.trusty
<cjwatson> xnox: Sorry, r294
<xnox> cjwatson: makes sense.
<cjwatson> However we have a bit of a problem applying that because updating tasks post-release is hard
<cjwatson> I'd recommend backporting it anyway, but I think it might unfortunately be necessary to SRU livecd-rootfs with changes to install the relevant additional packages manually in the case of Lubuntu
<cjwatson> Fortunately it's just five packages or six for powerpc (you can disregard wamerican from platform.trusty/live-common for this purpose, I think)
<cjwatson> am I making sense?
<xnox> yeah, kind of. you lost me at SRU livecd-rootfs though =)
<cjwatson> live-build/auto/config, look for the main lubuntu config block, add some appropriate "add_package live ..." lines
<cjwatson> with the justification that these packages were accidentally left out of the lubuntu-live task in trusty and are now hard to get in there properly
<xnox> cjwatson: ack. kind of like ever-moving signed kernels. but in this case "forgotten" packages.
<cjwatson> Yeah, sort of.  Bit of a mess :(
<zequence> Hi. The links to Ubuntu Studio images at http://iso.qa.ubuntu.com/qatracker/milestones/318/builds/73692/downloads and http://iso.qa.ubuntu.com/qatracker/milestones/318/builds/73693/downloads are pointing to the wrong url paths
<jibel> zequence, known issue. I fixed some but not all
<zequence> jibel: Ok
<jibel> zequence, links to ubuntu studio images are fixed
<zequence> jibel: Thanks
<jibel> infinity, for mythbuntu, ubutnu-core, ubuntu-gnome, ubuntu-kylin, ubuntu-server the build number on the tracker is 20140722.2 (.3 for server) but they don't exist on cdimage.u.c
<jibel> latest build is either 20140722 or 23
<jibel> infinity, nm, wrong release, too much copy/paste
<jibel> I'll fix the links on the tracker for those too
<jibel> I fixed the download links on the tracker for the flavors and ubuntu desktop. Ubuntu server and core will have to live with broken links for the moment
<jibel> superm1, hey, mythbuntu is untested and the release of 14.04.1 is tomorrow.
<superm1> tgm4883: ^ have you looked at all?
<jibel> stgraber, same for edubuntu, there is no result on the tracker.
<jibel> JackYu, ypwong can you test ubuntu-kylin before the release tomorrow.
<JackYu> jibel, sure, we  will do it asap.
<jibel> JackYu, great, thanks!
<apw> who manages the text which is shown for update-manager release notes
<apw> as i think the utopic ones are still saying trusty, and when testing with the bad test descriptions we have for upgrades
<xnox> apw: it's a tarball in the archive that bdmurray typically uploads?
<apw> it makes detecting you did it wrong hard
<xnox> or mvo
<jibel> apw, I replied to your bug report and asked bdmurray to have a look
<apw> jibel, great thanks
<jibel> isn't trusty-update frozen. There are updates of oxide available after a fresh installation.
<infinity> Riddell: Do we actually care deeply about oversized images anymore?
<infinity> jibel: I assume the security team is happily disregarding any such freezes.
<Riddell> infinity: not too much, although the html page looks ugly
<infinity> Riddell: The HTML page for the release doesn't list oversized, just the dailies do. ;)
<Riddell> not a problem then
<infinity> Riddell: Anyhow, SRUing apport to swap the recommends wouldn't help, as gdb will remain in the desktop task.
<infinity> Riddell: Since we can't fix tasks post-release. :/
<Riddell> okey dokay, we'll go with these
<Riddell> time to crack on testing
<infinity> Riddell: A hack to livecd-rootfs to swap the packages would work (it'd be ugly, but work), if you deeply cared.
<Riddell> nah
<infinity> Riddell: Anyhow, yeah, if you don't actually care about point releases being a bit over 1G, easier to take the "it's the same as release but a bit bigger, so probably no regressions, yay" approach, and test away. :)
<infinity> bluesabre: If you guys are committed to a rapid testing turnaround, we can look at squeezing a fix in for you.  Looks like menulibre is only on xubuntu images.
<infinity> jibel: stgraber is on vacation, I'm getting the kernel team to test edubuntu for him.
<infinity> bluesabre: Just let me know how you want to proceed.  We can promote menulibre to updates and re-spin just for you if you're down with re-testing ASAP.
<slangasek> stgraber: hmm, so you're not available to do the edubuntu point release validation? :)
<jibel> infinity, okay, I'll cover the LTSP test if no one have the setup ready.
<bluesabre> infinity: Yes, please do. Got confirmation from our QA lead, and I will also be available to image testing (sounds like we have more on board as well)
<elfy> infinity: yea, xubuntu is commited to a rapid test turnaround
<elfy> what time do we need to mark them as released?
<infinity> bluesabre: Alright, I'll make it happen right now.
<elfy> thanks infinity
<bluesabre> infinity: thanks!
<infinity> bluesabre: Unfortunately, the lightdm-gtk-greeter change would force a respin of lubuntu, studio, and myth as well, so I'd rather not do that one unless you can get them all to agree to re-test.
<infinity> bluesabre: But menulibre, we can do with minimal impact.
<bluesabre> infinity: yeah, we can leave lightdm-gtk-greeter out for now
<elfy> result of having a small team I guess
<infinity> bluesabre: Just waiting on that to publish and then I'll re-do your ISOs shortly.
<bluesabre> great, thanks again :)
<tgm4883> jibel: let me look
<jibel> tgm4883, also a tester reported bug 1347779 and bug 1347823 specific to mythbuntu. If you can confirm or add a comment on the report
<ubot93> bug 1347779 in syslinux "FAMILY boot screen doesn't show up" [Undecided,New] https://launchpad.net/bugs/1347779
<ubot93> bug 1347823 in ubuntu-manual-tests "System stuck when pressing the "Watch TV" button" [Undecided,New] https://launchpad.net/bugs/1347823
<tgm4883> jibel: i'll test those as well
<infinity> Something I'm pretty sure Unity8/Mir still doesn't do right.
<infinity> Err.
<infinity> Paste fail.
<infinity> La la la.
<Riddell> infinity: what's new in these images?
<tgm4883> Does this mean I should hold off on testing the http://cdimage.ubuntu.com/mythbuntu/trusty/daily-live/20140722.2/trusty-desktop-amd64.iso image?
<infinity> Riddell: Those aren't new images, just the upgrade testing tasks.
<infinity> tgm4883: See above.
<Riddell> gotcha
<tgm4883> ok
<tgm4883> so i'll test on then
<infinity> The only images I'm respinning currently are xubuntu's, everyone else's are staying put.
<jibel> infinity, netboot and cloud images are not on the tracker. are they added manually?
<utlemming> jibel:  I'll add cloud images early next week
<infinity> jibel: netboot is added when d-i is uploaded, which happened before the milestone was created.
<infinity> jibel: But since netboot isn't actually tied to a point release (ie: I can update d-i any time), I'm not amazingly fussed either.
<jibel> okay
<infinity> jibel: If you want to spin through a quick smoketest of current netboot just to confirm it's not broken (though, really, I suspect half our infrastructure would fall over if it was), that wouldn't hurt my feelings, I guess. :P
<jibel> infinity, I'll do it after dinner
<jibel> hm, upgrade from saucy is broken https://jenkins.qa.ubuntu.com/view/Upgrade/job/upgrade-ubuntu-saucy-trusty-desktop-amd64/139/
<infinity> Ugh, that's the same subtle apt loop breaking bug we were working around at release time...
<jibel> bdmurray, did you see reports with this failure http://paste.ubuntu.com/7843200/ ?
<infinity> I don't think there's much we can do about it in the next two days.
<tgm4883> Where do I go to edit test cases again?
<tgm4883> jibel: anything special I need to do to pass these ISOs, I've invalidated both bugs due to incorrect test cases, and I'm testing the last test case now
<infinity> bluesabre / elfy ^^
<bluesabre> infinity: thanks!
<jibel> tgm4883, mark the tests as passed for mythbuntu on the tracker http://iso.qa.ubuntu.com/qatracker/milestones/318/builds
<jibel> tgm4883, the project for the test cases is lp:ubuntu-manual-tests
<tgm4883> jibel: already marked as passed, I'll take a look at that project
<balloons> tgm4883, yes you can simply checkout lp:ubuntu-manual-tests and propose corrections
<tgm4883> balloons: I'm doing something wrong then
<tgm4883> I tried doing a merge request, but it says it's not mergable
<tgm4883> https://code.launchpad.net/~mythbuntu/mythbuntu/mythbuntu-testcase
<balloons> tgm4883, you should bzr push to the ubuntu-manual-tests projects.. so like  lp:~mythbuntu/ubuntu-manual-tests/mythbuntu-testcase
<balloons> that should make proposing easy
<tgm4883> balloons: I thought I tried that, but let me do it again
<balloons> tgm4883, it just makes it easier for the mp, as the target branch should be correct, etc
<tgm4883> balloons: as usual, you are correct. That worked much better, thanks
<tgm4883> https://code.launchpad.net/~mythbuntu/ubuntu-manual-tests/mythbuntu-testcase/+merge/227994
<balloons> just the 1 line change? I can approve and push now
<tgm4883> yea just the 1
<balloons> k, just a sec
<balloons> k, should be updated on the tracker tgm4883
<tgm4883> balloons: looks great. Thanks
<balloons> ty!
#ubuntu-release 2014-07-24
<JackYu> jibel, hi, Ubuntu Kylin is ready for release. Will is the URL of Ubuntu release note? Do we need to prepare one for Ubuntu Kylin?
<infinity> JackYu: I'm not sure individual announcements are really necessary for the point release, but if you want want to, you can.
<JackYu> infinity, I think so:)
<JackYu> infinity, so, I choose to share the Ubuntu one:).
<jibel> jamespage, hey, could you update the tracker with the results for the tests for 14.04.1 server images?
<jamespage> jibel: I thought that was automated?
<jamespage> jibel, I can certainly help with the iscsi testing as I normally do - beisner will be around later to co-ordinate the rest
<infinity> jibel: I'll do server on the powerpcs and core on ppc and arm64 tonight.  How are we looking otherwise?
<infinity> tgm4883: You good to go to mark mythbuntu ready?
<infinity> elfy: Ditto for xubuntu?
<jibel> infinity, images are fine, upgrades are not so good. bug 1348067 , bug 1347964 (ubuntu-desktop fails to upgrade) and the failure with procps from saucy to trusty found yesterday
<ubot93> bug 1348067 in update-manager "update-manager crashed with TypeError: pulse() takes exactly 1 argument (2 given)" [High,In progress] https://launchpad.net/bugs/1348067
<ubot93> bug 1347964 in ubuntu-release-upgrader "Precise w/Trusty HWE -> Trusty release upgrade fails critically" [High,Triaged] https://launchpad.net/bugs/1347964
<infinity> jibel: check.  Those are archive issues rather than image issues (not to downplay them, they need investigation, but shouldn't hold up the ISOs)
<jibel> jamespage, tests are automated I'm just not sure if anyone look at the results
<infinity> jibel: We saw a variation on your saucy->trusty issue a day or two before release and reverted something that made apt happy, but clearly not happy enough.  The real bug needs hunting and fixing. :/
<apw> infinity, oh is it _that_ one
<apw> back to haunt us
<jibel> infinity, sure these upgrade issues don't affect the images themselves
<highvoltage> Is there a wiki page that lists what have changed in the 14.04.1 point release?
<infinity> apw: Yeah, looks like it's the same bug.
<jamespage> jibel, looking at https://jenkins.qa.ubuntu.com/view/Trusty/view/Smoke%20Testing/ the server iso tests have not run for a bit now
<jibel> jamespage, pfff, I'll talk to CI.
 * jibel clears the results on the tracker
<highvoltage> jibel: hey there
<jibel> highvoltage, hi
<highvoltage> jibel: I see you tested edubuntu 14.04.1 and passed ltsp, what hardware was that on?
<jibel> highvoltage, in VMs
<highvoltage> jibel: kvm?
<jibel> highvoltage, no virtualbox, 1rst has 2 NICs (1 for external network and 1 for internal network) and 2nd VM has 1 NIC connected to the internal network
<highvoltage> jibel: ok, thanks. I had some trouble with it under kvm, but my host was under load so I'll try again
<jibel> highvoltage, you must install vbox extensions to pxe boot the client
<highvoltage> jibel: my kvm thin client boots, but ldm doesn't start, but I'll troubleshoot further in a bit...
<highvoltage> weird, it works fine when I set my virtual display card to anything that's not 'cirrus'.
<xnox> i have no clue why cirrus is still the default, when it's that bad, and nobody has hardware like that any more.
<highvoltage> xnox: yeah, strangely enough my host vm was also set to cirrus and that started X up just fine oO
<pfsmorigo> infinity: is there a way to get an "older" daily?
<pfsmorigo> like 1 month old
<cjwatson> Dailies are purged after a while; we don't have space to keep them for very long.
<pfsmorigo> cjwatson: I'm doing tests with the daily and the system seems to freeze during the first reboot after the installation
<pfsmorigo> cjwatson: talking about ppc64el here
<pfsmorigo> cjwatson: I want to test with some older versions after 14.04
<cjwatson> It'll probably have to be investigated directly rather than by bisection, sorry.
<cjwatson> We don't have the old dailies any more.
<infinity> pfsmorigo: Is this on P7 or P8?  Real hardware or VM?
<infinity> pfsmorigo: I was just about to test on a P7 VM.
<pfsmorigo> cjwatson: qemu
<pfsmorigo> infinity: ^
<pfsmorigo> infinity: do you have a powerkvm to test?
<infinity> pfsmorigo: I do, yes.
<pfsmorigo> infinity: nice, so you just have to create a disk and install using the default options. the problem happens after the installation is over.
<infinity> pfsmorigo: And if I fail to reproduce it?
<infinity> pfsmorigo: Note that the kernel on the CD and the kernel you're rebooting into are identical, so it's curious if it's freezing on reboot. :/
<pfsmorigo> infinity, cjwatson: https://gist.github.com/pfsmorigo/1a9f21bc7d0b6a48d818
<pfsmorigo> infinity, cjwatson: it freezes after that
<infinity> pfsmorigo: That's not frozen, that's a lack of console.
<pfsmorigo> infinity: hmm. how do I "fix" it?
<infinity> I'm not sure how you broke it.
<infinity> OF stdout device is: /vdevice/vty@30001000
<infinity> On every other SLOF install I've done, that's /vdevice/vty@30000000
<pfsmorigo> infinity: good point
<elfy> infinity: I somehow knew that I'd see a ping when I got in for lunch :p marked ours ready :)
<infinity> elfy: Ta.
<elfy> infinity: you going to need release notes?
<infinity> elfy: Hand't planned on extensive flavour notes, unless anyone really wants to do some of their own.
<infinity> Hadn't, even.
<elfy> awesome - suits me perfectly tbh :)
<infinity> pfsmorigo: So, I guarantee I won't be able to reproduce your issue on my VMs, where my SLOF defaults to a different console device.
<pfsmorigo> infinity: the bug reporter use virsh and his xml has serial set to 30001000
<infinity> pfsmorigo: The question then is, is this a new version of SLOF, or some weird way you're invoking qemu?
<pfsmorigo> infinity: will try using 30000000
<infinity> pfsmorigo: Oh, he's explicitly using a non-standard port? :(
<infinity> *sigh*
<pfsmorigo> infinity: cool, isn't? :P
<infinity> So, we could very much improve the way we detect this, to be fair.
<infinity> But, if you just let qemu/slof do their default thing, it works fine.
<pfsmorigo> infinity: agree
<infinity> pfsmorigo: A bug report that says "when I pick a non-standard serial setup, it all goes to poop" and some explanation of how to reproduce would be nice.
<infinity> pfsmorigo: Reported against "finish-install".
<pfsmorigo> infinity: he just attached the xml that he used to test the distro. don't know why he uses a non-standard port
<infinity> pfsmorigo: Because your testers like to confuse me. :)
<infinity> pfsmorigo: It's definitely still a bug that we fail to detect that situation, just not a critical one, since I can't see how "normal" users would do that by accident.
<pfsmorigo> infinity: glad we solve it before it turns into a obscure kernel bug :P
<pfsmorigo> infinity: the serial/console in his xml is like this: https://gist.github.com/pfsmorigo/32ada7e5439ef80d8e5e
<infinity> Have I ever mentioned how much I hate virsh/libvirt?
<infinity> If you just call qemu raw, you get a sane console on 0x30000000 which is, in fact, what you get when you boot a "real" openfirmware system via PowerVM or SLOF on bare metal too.
<pfsmorigo> infinity: I used qemu directly and had the same "freeze"
<infinity> pfsmorigo: Testing independently here to see what I get.
<infinity> pfsmorigo: Out of curiosity, where does SLOF report your console being?  And how did you call qemu?
<infinity> pfsmorigo: An install and reboot went fine here.
<pfsmorigo> infinity: qemu-system-ppc64 -enable-kvm -M pseries -smp 4,cores=2,threads=4 -m 4G -nographic -device spapr-vscsi -device spapr-vlan,netdev=net0,mac=4C:45:42:45:06:41 -netdev bridge,br=br0,id=net0 -nodefaults -monitor stdio -serial pty -drive file=disk.img
<pfsmorigo> infinity: then: screen /dev/pts/xx
<infinity> pfsmorigo: SLOF **********************************************************************
<infinity> QEMU Starting
<infinity>  Build Date = Oct 15 2013 03:55:10
<infinity>  FW Version = mockbuild@(private build)
<infinity>  Press "s" to enter Open Firmware.
<infinity> Populating /vdevice methods
<infinity> Populating /vdevice/vty@71000000
<infinity> Populating /vdevice/nvram@71000001
<infinity> Populating /vdevice/l-lan@71000002
<infinity> Populating /vdevice/v-scsi@71000003
<infinity>        SCSI: Looking for devices
<infinity>           8000000000000000 DISK     : "QEMU     QEMU HARDDISK    1.6."
<infinity>           8200000000000000 CD-ROM   : "QEMU     QEMU CD-ROM      1.6."
<infinity> Populating /vdevice/v-scsi@71000004
<infinity>        SCSI: Looking for devices
<infinity> Populating /pci@800000020000000
<infinity>  Adapters on 0800000020000000
<infinity>                      None
<infinity> Scanning USB
<infinity> Using default console: /vdevice/vty@71000000
<infinity>   Welcome to Open Firmware
<infinity>   Copyright (c) 2004, 2011 IBM Corporation All rights reserved.
<infinity>   This program and the accompanying materials are made available
<infinity>   under the terms of the BSD License available at
<infinity>   http://www.opensource.org/licenses/bsd-license.php
<infinity> Trying to load:  from: disk ...   Successfully loaded
<infinity> * finddevice /memory grub workaround *
<infinity> error: no suitable video mode found.
<infinity> error: failure writing sector 0x1044888 to `ieee1275/disk'.
<infinity> * finddevice /memory grub workaround *
<infinity> * finddevice /memory grub workaround *
<infinity> Press any key to continue...
<infinity> OF stdout device is: /vdevice/vty@71000000
<infinity> Preparing to boot Linux version 3.13.0-32-generic (buildd@denneed04) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #57-Ubuntu SMP Tue Jul 15 03:50:31 UTC 2014 (Ubuntu 3.13.0-32.57-generic 3.13.11.4)
<infinity> Detected machine type: 0000000000000101
<infinity> Max number of cores passed to firmware: 2048 (NR_CPUS = 2048)
<infinity> Calling ibm,client-architecture-support... done
<infinity> command line: BOOT_IMAGE=/boot/vmlinux-3.13.0-32-generic root=UUID=d3530761-1c4f-4858-a284-79190eb52841 ro splash quiet vt.handoff=7
<infinity> memory layout at init:
<infinity>   memory_limit : 0000000000000000 (16 MB aligned)
<infinity>   alloc_bottom : 0000000004e10000
<infinity>   alloc_top    : 0000000030000000
<infinity>   alloc_top_hi : 0000000300000000
<infinity>   rmo_top      : 0000000030000000
<infinity>   ram_top      : 0000000300000000
<infinity> instantiating rtas at 0x000000002fff0000... done
<infinity> prom_hold_cpus: skipped
<infinity> copying OF device tree...
<infinity> Building dt strings...
<infinity> Building dt structure...
<infinity> Device tree strings 0x0000000004e20000 -> 0x0000000004e20727
<infinity> Device tree struct  0x0000000004e30000 -> 0x0000000004e40000
<infinity> Calling quiesce...
<infinity> returning from prom_init
<infinity>  -> smp_release_cpus()
<lool> this is going to take some time
<infinity> spinning_secondaries = 7
<infinity>  <- smp_release_cpus()
<infinity>  <- setup_system()
<infinity> CF000012
<infinity> CF000015ch
<infinity> Linux ppc64
<infinity> #57-Ubuntu SMP T * Starting Mount filesystems on boot                    [ OK ]
<infinity>  * Starting Populate /dev filesystem                                     [ OK ]
<infinity>  * Starting Populate and link to /run filesystem                         [ OK ]
<infinity>  * Stopping Populate /dev filesystem                                     [ OK ]
<infinity>  * Stopping Populate and link to /run filesystem                         [ OK ]
<infinity>  * Stopping Track if upstart is running in a container                   [ OK ]
<infinity>  * Starting Signal sysvinit that the rootfs is mounted                   [ OK ]
<infinity>  * Starting Initialize or finalize resolvconf                            [ OK ]
<infinity>  * Starting Signal sysvinit that virtual filesystems are mounted         [ OK ]
<infinity>  * Starting Signal sysvinit that virtual filesystems are mounted         [ OK ]
<infinity>  * Starting Bridge udev events into upstart                              [ OK ]
<infinity>  * Starting Signal sysvinit that remote filesystems are mounted          [ OK ]
<infinity>  * Starting Clean /tmp directory                                         [ OK ]
<infinity>  * Starting device node and kernel event manager                         [ OK ]
<infinity>  * Stopping Clean /tmp directory                                         [ OK ]
<infinity>  * Starting load modules from /etc/modules                               [ OK ]
<infinity>  * Starting cold plug devices                                            [ OK ]
<infinity>  * Starting log initial device creation                                  [ OK ]
<infinity>  * Starting Signal sysvinit that local filesystems are mounted           [ OK ]
<infinity>  * Stopping Mount filesystems on boot                                    [ OK ]
<infinity> GAH.
<infinity> WRONG MOUSE BUTTON.
<infinity> pfsmorigo: http://paste.ubuntu.com/7847407/
<infinity> pfsmorigo: So, I'm assuming '-serial pty' does something funky.  But this isn't new either, it would have been broken this same way since release (indeed, since we started the port).
<infinity> lool: Sorry.  Middle click fail. :/
<infinity> lool: Not sure how I didn't get kicked.
<pfsmorigo> infinity: https://gist.github.com/pfsmorigo/245ae92f1ff682f473db
<pfsmorigo> infinity: this is what I get in the screen
<xnox> lool: serial console over IRC is the best with rate limiting =)
<infinity> pfsmorigo: Oh, kay, so you're getting a device we should be setting up correctly (the same one I just pasted).
<infinity> pfsmorigo: Err, did you *install* with that setup, or are you rebooting an already broken install?
<pfsmorigo> infinity: second option
<infinity> pfsmorigo: Kay, right.  So, broken.
<infinity> pfsmorigo: The installer detects if it should set up a console on hvc[01] based on magic openfirmware nodes existing at install time.
<infinity> pfsmorigo: So, if you run an install under that setup there, it'll work fine.
<pfsmorigo> infinity: ok, let me do some tests here
<infinity> pfsmorigo: As you can see from my paste, which matches yours, but has a getty with a login prompt. :)
<lool> xnox: yeah it felt like 100 bauds or something
<ogra_> ls
<ogra_> pwd
<lool> ogra_: Password:
<pfsmorigo> lol
<ogra_> 123456
<ogra_> oops !
<infinity> ogra_: That's the same combination I have on my luggage!
<ogra_> lol
<lool> haha
<davmor2> ogra_: I expect something more inventive from you like 123456!
<ogra_> 123456Ã¤Ã¶Ã¼
<ogra_> ;)
<davmor2> ogra_: or hunter2
<pfsmorigo> infinity: I found some tickets about this problem. https://bugs.launchpad.net/ubuntu/+bug/1347967
<ubot93> Launchpad bug 1347967 in ubuntu "ISST-KVM:Ubuntu14.04:LE guest failed to boot on its first reboot after installation" [Undecided,New]
<pfsmorigo> infinity: "From what I know, there is no difference/limitation between these two values to Libvirt, it just address assigned to the device. Althrough 30000000 is defined for VIO_ADDR_SERIAL specificly, both works fine as serial address."
<infinity> pfsmorigo: Kay, so a Kimchi bug (and yes, also an Ubuntu bug)
<infinity> pfsmorigo: For the record, the default in SLOF appears to be 71000000 (which we handle fine), and we also handle 30000000, but not 30001000.
<pfsmorigo> infinity: ok, got it
<infinity> pfsmorigo: Going forward, I plan to try to rewrite this to detect things a bit more sanely but, for now, it might be nice if Kimchi wasn't doing silly non-standard things.
<infinity> pfsmorigo: If there's already an install base of systems that will be trying 30001000 though, we can certainly fix the hardcoding in the installer to also look there for now.
<infinity> pfsmorigo: Not for the point release, but for a later update.
<pfsmorigo> infinity: ok
<tgm4883> infinity: yes Mythbuntu is good to go
<infinity> tgm4883: \o/
 * infinity spins source ISOs.
<highvoltage> is there an estimated time for the release if everything goes well?
<infinity> highvoltage: Not going to make estimates, but "today, in my timezone".
<infinity> highvoltage: Which gives you, uhm, 16.5 hours of wiggle room. :P
<highvoltage> infinity: *shrug*, good enough :)
<jibel> infinity, ubuntu looks good, server tests are done, I'm updating the tracker. The most critical bugs found are upgrade crashes mentioned earlier, someone from foundations will have to look at them.
<infinity> jibel: Agreed, we'll have to make some time to take a closer look ASAP.
<infinity> jibel: And possibly hold off on flipping the meta-release upgrade switch until we know WTF is going on.
<infinity> jibel: Though, have you seen the issue with precise->trusty, or just saucy->trusty?
<jibel> infinity, +1 holding off flipping the switch
<jibel> infinity, I reproduced 1347964
<jibel> bug 1347964
<ubot93> bug 1347964 in ubuntu-release-upgrader "Precise w/Trusty HWE -> Trusty release upgrade fails : ubuntu-desktop fails to configure" [High,Triaged] https://launchpad.net/bugs/1347964
<jibel> twice
<jibel> and it leaves the system in a completely broken state, if you reboot you cannot even login
<infinity> jibel: Oh, that's an entirely different bug, and probably a pure packaging issue.  But yes, that should also be fixed. :/
<mdeslaur> infinity: can the eglibc package be removed in utopic?
<infinity> mdeslaur: Need to fix all the cross-buildy stuff, but that's the plan, yes.
<mdeslaur> infinity: ah, ok, thanks
<mdeslaur> infinity: if you still care about the lucid sparc eglibc FTBFS, now would be the time to get me that patch you had
<infinity> mdeslaur: Oh, is it security time?  Whee.  No need to do utopic, BTW, I'll merge with Debian (assuming it's the CVE covered in unstable a week or so ago).
<mdeslaur> infinity: yeah, that's the one
<infinity> mdeslaur: I don't actually remember what the sparc issue was.  I'm not sure I remember even having the conversation. :)
<infinity> mdeslaur: Oh, it was a breakage in the most recent security update.  Yeah, I think we pulled a patch or two for that in Debian.  Can I look tomorrow, or are you doing it Right Now?
<mdeslaur> infinity: https://launchpad.net/~ubuntu-security/+archive/ubuntu/ppa/+build/5068250
<mdeslaur> infinity: yeah, you can look tomorrow
<infinity>   * patches/any/cvs-CVE-2013-4237-alignment.diff: Fix alignment of the
<infinity>     directory block in dirstream.h, fixing readdir regression on sparc.
<ubot93> sysdeps/posix/readdir_r.c in the GNU C Library (aka glibc or libc6) 2.18 and earlier allows context-dependent attackers to cause a denial of service (out-of-bounds write and crash) or possibly execute arbitrary code via a crafted (1) NTFS or (2) CIFS image. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4237)
<infinity> mdeslaur: Looks like it would be that one.
<mdeslaur> infinity: thanks, I'll take a look when I work on lucid
<infinity> mdeslaur: Possibly might also want to look at:
<infinity>   * patches/any/cvs-CVE-2013-4332-memalign-2.diff: patch from upstream to
<ubot93> Multiple integer overflows in malloc/malloc.c in the GNU C Library (aka glibc or libc6) 2.18 and earlier allow context-dependent attackers to cause a denial of service (heap corruption) via a large value to the (1) pvalloc, (2) valloc, (3) posix_memalign, (4) memalign, or (5) aligned_alloc functions. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4332)
<infinity>     address some remaining issues from CVE-2013-4332.
<infinity> mdeslaur: If you have troubles hunting those down (cause they're likely merged upstream by now, and thus not patches in utopic), I can help you tomorrow.
<mdeslaur> infinity: thanks, I'll let you know
<mvo_> could someone reject my upload for update-manager to precise-proposed please?
<infinity> mvo_: Sure.
<mvo_> tthanks infinity
<mvo_> and if someone could review the update-manger in precise-proposed that would be great - its for the hwe-support so would be good to get it in
<jibel> infinity, I published the testing report, is there a changes summary or a script to generate it like https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/ChangeSummary/12.04.4 ?
<cjwatson> jibel: I'm going to make a start on that in a bit
<infinity> jibel: I think we can promise it'll be at the obviously guessable URL, and it can just 404 for now.
<jibel> cjwatson, okay
<xdatap1> Hi everybody
<xdatap1> I'm from the Italian LoCo Team. We realese a localized version of Ubuntu. Is the 14.04.1 already out? Can we release our image?
<zul> can an archive admin promote python-hacking please (#1331490)
<Riddell> infinity: are we nearly there yet?
<Riddell> zul: done
#ubuntu-release 2014-07-25
<tumbleweed> utopic buildd chroots appear to be broken
<mlankhorst> I want to transition to 1.16, but fglrx won't be ready until somewhere in september, could we temporarily remove fglrx from the archive?
<infinity> tumbleweed: Chroots aren't broken, per se, that's an apt bug. :/
<tumbleweed> that explains why the log made no sense to me
<infinity> tumbleweed: I'll work around it after I've had a bit of food, but the real bug in apt needs hunting.
<cjwatson> Yay, that all looks like an improvement.
<cjwatson> let's see if calligra will sort its life out now
<zul> can someone approve python-flake8 (#1331468) and python-mccabe (#1331467) please?
<cjwatson> zul: done python-mccabe; waiting for python-flake8 not to be mid-proposed-migration before touching it
<zul> cjwatson: ack
<ginggs> would someone approve nvidia-graphics-drivers-* in the trusty queue, please?
<xnox> infinity: OMG! you made me cry dude =) thanks a lot. *sob* =)
<zul> cjwatson: python-oslo.config is still blocked for some reason as well
<barry> cjwatson or infinity.  i was chatting with pitti about the zope.security promotion.  i think something about the way i did the python-zope.security-untrustedpython migration may be confusing britney because it's not getting promoted out of -proposed, though i think it should
<barry> python-zope.security-untrustedpython is now a Provides: of python-zope.untrustedpython
<barry> hmm -> #u-devel
<cjwatson> Riddell,shadeslayer: can somebody fix up the analitza/armhf build?  blocking other things
<shadeslayer> cjwatson: ack
<cjwatson> thanks
<cjwatson> I've been going through and retrying KDE builds that failed due to uninstallable build-dependencies
<cjwatson> since that's made the libav transition unintelligible ...
<cjwatson> Riddell: What's the plan for cantor on architectures that don't have libluajit-5.1-dev?  Should we perhaps make cantor-backend-lua architecture-dependent?
<shadeslayer> cjwatson: fixed btw
<shadeslayer> cjwatson: re cantor, that seems like the most sensible thing to do
#ubuntu-release 2014-07-26
<cjwatson> ScottK: Do you know what's up with the gwenview autopkgtest?
<cjwatson> yofel: Any chance of sorting out symbols for kde4libs/armhf too?  The combination of this and the previous problem makes it rather hard to see what's going on in -proposed.
<ScottK> cjwatson: I don't know.  I did have a look at it. And it looks like a real thing, but not related to the stuff it's blocking on, so it's probably OK to override.  agateau is upstream for gwenview, so I had intended to ping him about it.
<ScottK> pinged.
<yofel> cjwatson: looking
<kirkland> howdy!  can someone approve byobu 5.77-0ubuntu1.2 to supercede 5.77-0ubuntu1.1 in trusty-proposed?
<cjwatson> yofel: yay, thanks
#ubuntu-release 2014-07-27
<cjwatson> ScottK: I've hinted force-badtest gwenview/4:4.13.2-0ubuntu2, at least for now
<ScottK> cjwatson: Thanks.
<ScottK> I think that's reasonable.
#ubuntu-release 2015-07-20
<sil2100> Hello release team! I need to disable the s-i importer for some stable image copies
<sil2100> Importer re-enabled!
<robru> I just hit publish on unity-scope-snappy, it'll need a NEW review if anybody's around
<kyrofa> I'm looking for someone to take a look at unity-scope-snappy... any takers? Should be a pretty quick review
<infinity> kyrofa: Should be and will be don't always align for NEW reviews.
<kyrofa> infinity, heh, indeed
<teward> generic SRU question: how long after -proposed is hit and verification-done is it before it migrates to -updates?  I forget what the actual timeperiod is, and the wiki's timing out for me
<teward> s/it migrates/an upload migrates/
<infinity> teward: 7ish days, unless fasttracking is argued for, in which case someone like me will do a more in-depth re-review, make sure you've tested insanely well, and release it early.
<teward> for some reason I had 14-days in my mind o.O
<teward> and it didn't sound right, hence the question :)
<teward> thanks, infinity
<infinity> teward: So, since you're worrying about nginx/vivid (which looks ready today), can I bug you to do something about nginx/precise?
<infinity> teward: You realize you can verify your own bugs/uploads, right?  You don't need to keep begging in the bug for someone else to verify it.
<teward> infinity: that's something not told to me o.O
<teward> nor documented, so no i didn't realize that part
<teward> newInfo.Learned
<infinity> teward: Well, it's not documented that you can't. :P
<teward> :P
<infinity> teward: If you have a test case and execute it and show evidence of that in a bug comment (ie: don't just say "yeah, this works in precise because I uploaded it and I'm awesome and I say so"), then yay.
<teward> infinity: i've got to prep a merge debdiff in the interim the TB approves the proposed plan for nginx, but what's broke in precise, other than naxsi which can't be fixed.
<teward> (not without violating every facet of SRUing)
<infinity> teward: Err, what's broken in precise is an SRU in -proposed that's 159 days old.
 * teward looks
<infinity> https://launchpad.net/ubuntu/+source/nginx/1.1.19-1ubuntu0.8
<teward> infinity: i'll take a peek after I get home, can't download a Precise ISO here to spin up to test
<teward> but yeah i've been meaning to look at that, just been pulled left/right/up/down/forwards/backwards/crossdimensionally by work
<teward> infinity: also, wrt 1.1.19-1ubuntu0.8, i can go poke that and see if it's there.  as for the vivid-proposed fix lately, yeah, for that I can verify, and I did (I think) in tags :)
<teward> i've done that once or twice on obscure edge cases too... usually try not to, but usually do if it's something that needs fixed to fix debugging in the future (like with the Vivid bugs and no debug data)
<teward> ... lucky me, i found a 12.04 VM lying around...
<teward> infinity: BTW, if you need to be in -meeting, feel free to prioritize that
<teward> my initial question regarding the migration timeline for verification-done items was to refresh my memory
<teward> since i'm writing an email to someone about the 'bad bugs' issue
<teward> infinity: to follow up: precise SRU for nginx that's 159 days old (1.1.19-1ubuntu0.8) verification-done
<infinity> teward: Ta.
<wxl> my irc client died. did anyone have a chance to look into why lubuntu ppc alternate is failing?
<wxl> that's a good question, Kamilion. haven't had a chance to mess with it actually. Unit193 would probably know.
 * wxl nods
<wxl> actually neale MAY know, too, considering he's built his own init system in the past and now works for canonical.
<wxl> argh wrong channel as usual
 * wxl sighs
<cjwatson> if anything I'm a little puzzled that everything else didn't fail
<cjwatson> but it's priority mismatches, I'll fix
<wxl> cjwatson: agree. thanks
<wxl> cjwatson: let me know when you got it fixed up and i'll schedule a rebuild
<cjwatson> wxl: just do it in an hour from now, I'm not going to watch the publisher exactly
<wxl> cjwatson: kthx
#ubuntu-release 2015-07-21
<coreycb> hello, can an archive admin please promote the following to main?  python-awsauth, python-os-brick, python-oslo.service, python-designateclient, python-pathlib
<coreycb> this should help get some of the liberty openstack packages out of dependency waits
<cjwatson> coreycb: looking
<cjwatson> coreycb: all done, with python-{monotonic,manilaclient,zaqarclient} as well
<coreycb> cjwatson, awesome, thanks
<wxl> cjwatson: thanks for the ppc fix. whatever you did worked
<cjwatson> good.  I cleared up the pending demotions from important priority on http://people.canonical.com/~ubuntu-archive/priority-mismatches.html
#ubuntu-release 2015-07-22
<cjwatson> ^- would appreciate review, fixes some previously-mysterious segfaults that were reported to me in Landscape PPA builds
<cjwatson> I was initially worried that scalingstack was broken or something ...
<cjwatson> oh, hm, incorrect changelog, self-rejecting and reuploading
<cjwatson> ^- should be better now
<kenvandine> anyone around that can override ubuntu-system-settings promotion to release in wily?  It's held because of a missing depends in autopilot, which I've proposed a fix to autopilot for
<infinity> kenvandine: Or, we could get the fixed autopilot and retry all the tests that failed because of it, so we know they pass?
<kenvandine> infinity, http://d-jenkins.ubuntu-ci:8080/view/Wily/view/AutoPkgTest/job/wily-adt-ubuntu-system-settings-online-accounts/68/ARCH=amd64,label=adt/console
<kenvandine> that's the log of the failure
<infinity> kenvandine: I know.
<kenvandine> https://code.launchpad.net/~ken-vandine/autopilot/depends_for_gsettings/+merge/265580
<kenvandine> and the fix :)
<kenvandine> the qa guys are going to prepare a landing
<kenvandine> but i want to build other silos for settings :)
<kenvandine> and
<kenvandine> ubuntu-system-settings isn't failing, it's ubuntu-system-settings-online-accounts that's failing, which we depend on
<infinity> kenvandine: And you're not allowed to build a new silo until the old one is migrated?
<kenvandine> well, the current landing isn't merged yet
<kenvandine> until it goes to release
<kenvandine> so i'll need to rebuild again
<infinity> kenvandine: I'd rather not skip a test that we can fix.  Sort of the point of tests.  If we have process elsewhere that is forcing your hand on forcing this to migrate, we should fix that process.
<kenvandine> i can work around that, just in the past we've just forced the migration when we knew the issue
<infinity> kenvandine: If the person forcing the migration also has first-hand knowledge that the tests will pass after unrelated-bug-X is fixed, sure.  I don't, however, and I'd rather see the tests pass.  Which is, really, what we should be aiming for.
<kenvandine> it might even take then a couple days to release autopilot :/
<infinity> kenvandine: So, prod them with a bigger stick to fix autopilot, please.
<kenvandine> ok, thx
<infinity> kenvandine: Or get a core-dev to cherrypick the fix and upload to the archive, if they're taking their sweet time jamming it through CI.
<kenvandine> i could do that myself :)
<kenvandine> the old fashioned way!
<infinity> Then do so.  Upstream ownership shouldn't get in the way of the distro running smoothly.
<kenvandine> if it's still lingering in the morning i'll do it
<flexiondotorg> infinity, Do I need to register my interest in participating in Alpha 2 with your good self?
<infinity> flexiondotorg: Not with me, I'm not the one running it.
<infinity> flexiondotorg: Might want to nag Laney to send out an email about it.
<infinity> Laney: ^
<flexiondotorg> infinity, I won't nag, I'll ask nicely :-)
<flexiondotorg> infinity, When is 14.10 getting the boot?
<infinity> flexiondotorg: https://lists.ubuntu.com/archives/ubuntu-announce/2015-July/000197.html
<flexiondotorg> infinity, Perfect. Thank you.
#ubuntu-release 2015-07-23
<flexiondotorg> Laney, I've seen you email about Alpha 2.
<flexiondotorg> Laney, I could arrange to take the 29th and 30th off work to do this.
<flexiondotorg> Laney, I just want to understand if I would be sending the release announcement of if I would just be composing it?
<Laney> flexiondotorg: that's nice... but I wouldn't do that
<Laney> maybe you could team up with someone else
<Laney> release announcement> both
<flexiondotorg> Laney, Well, I want Alpha 2 to happen.
<flexiondotorg> So, I feel I need to step up.
<flexiondotorg> Xubuntu have opted out.
<flexiondotorg> Laney, Even if I team up I can't be doing this on my works time.
<Laney> flexiondotorg: I don't think it'll be much effort, especially if few flavours join in
<Laney> flexiondotorg: You could check in a bit in the evenings, I guess
<Laney> flexiondotorg: Another option is to not have it, or do it unofficially on your side by designating a daily as "Alpha 2".
<Laney> You could still do whatever QA you want on any daily
<flexiondotorg> Laney, I'll contact some of the other flavours. I'll see if Ubuntu GNOME want to play.
<flexiondotorg> Laney, I appreciate your all busy but is there any chance you could sponsor an upload for me?
<Laney> flexiondotorg: I'm going to do my shift soon and I'll look then
<Laney> Just got a few annoying things to get out of the way
<flexiondotorg> Laney, many thanks. I have several small updates but this is the most important - https://bugs.launchpad.net/ubuntu/+bug/1476653
<ubot93> Launchpad bug 1476653 in Ubuntu "[needs-packaging] ubuntu-mate-welcome" [Wishlist,New]
<flexiondotorg> Laney, cyphermox took a quick look last night but got busy with multi-path SRU.
<cyphermox> Laney: flexiondotorg: ubuntu-mate-welcome is in NEW.
<flexiondotorg> cyphermox, Thank you!
<arges> bdmurray: infinity : upload for nova in trusty-proposed (bug 1362863) is verification failed and causing other openstack related SRUs to fail, is this OK to remove from proposed to unblocked others until nova gets fixed propoerly?
<ubot93> bug 1362863 in Cinder "reply queues fill up with unacked messages" [Undecided,New] https://launchpad.net/bugs/1362863
<arges> not nova. oslo.messaging btw
<jamespage> arges, I'm +1 on that please :-)
<infinity> arges: That's between you, the uploader, and your mutual religious intersection.
<infinity> arges: Just so long as removing A doesn't go breaking dependencies for B, C, and D.
<infinity> In which case, the only way forward is to fix it.
<arges> jamespage: nothing deps on that particular version of oslo.messaging atm, so it shouldn't break deps
<arges> infinity: ok i'll triplecheck before i trash anything
<infinity> bdmurray: Does sru-review locally cache debdiffs or something?
<infinity> bdmurray: I keep getting the diff for a package I rejected instead of the new upload.  Which is annoying, since the bug refs are different. :P
<infinity> Maybe it's an LP frontend hating me or something.
<bdmurray> infinity: it might python-launchpadlib being helpful, I usually just wait a bit when happens to me
<infinity> bdmurray: Yeah, it cleared up eventually.
<teward> stupid question but today's the last day utopic is supported right?  Or is today the day it dies?
<infinity> teward: It amounts to pretty much the same thing.
<mdeslaur> teward: you get to pick :)
<infinity> teward: On a technical level, it's "supported" until I flip the switch in LP to "obsolete".
<infinity> teward: On a social level, it's supported until I send the email (which is around when I flip the switch).
<infinity> teward: Realistically, it's dead already, cause no one's going to try to start a week-long SRU process on a series that dies today, and the security team isn't likely to try to jam one last fix through (and test it) before this afternoon.
<mdeslaur> I deleted my VMs this morning, so no security update from me :P
<infinity> mdeslaur: Yeah, I rebuilt a laptop and didn't create utopic schroots.  It felt good.
<teward> i torpedoed by nginx and znc build folders for utopic yesterday, and officially "EOL'd" Utopic on the nginx PPAs, so... :P
<cyphermox> bdmurray: do you still do SRU reviews on Thursdays? if so, could you please review parted in trusty qeueu & network-manager in trusty and utopic?
<teward> and micahg said yesterday late in -motu to disregard anything for utopic-backports XD
<teward> infinity: mdeslaur: so from a technical/social/announcements perspective, utopic is dead once those things happen (announcement, flip it to "obsolete" on LP).  but effectively it's dead today
<bdmurray> cyphermox: utopic?
<cyphermox> bah
<teward> hehehe
<teward> well i can recover 25GB of space in my hypervisor now, i can purge my 14.10 VM xD
<bdmurray> cyphermox: did you mean network-manager-applet in trusty?
<cyphermox> yes, sorry :)
<bdmurray> no problem, just want to make sure I'm looking at the right thing
<teward> cyphermox: i think you need this coffee more than I do :)  (just kidding)
<teward> infinity: mdeslaur: thanks for confirming what i thought - that today is effectively the 14.10 death date, whether the announce goes out and switches flip, or not :)
<jderose> does anyone know if there will be a libegl1-mesa-drivers-lts-vivid package for the *-lts-vivid HWE? what are the vivid instructions equivalent to the lts-utopic instructions documented here - https://wiki.ubuntu.com/Kernel/LTSEnablementStack
<teward> infinity: saw the Utopic Is Dead notice
<teward> glad to hear that, one less thing on my radar xD
<wxl> heh, wore my utopic shirt yesterday in honor ;)
<teward> wxl: heheh
#ubuntu-release 2015-07-24
<Logan> is it possible to copy a newer version of a package down to a supported release instead of manually uploading an SRU?
<ScottK> No, since the version would have already been used.
<ScottK> Also, even if you could do it, you'd still need to go through the SRU process.
<ScottK> Actually, the copy would probably succeed, but there's no guarantee that the binaries would work on the older toolchain, so it'd be a bad idea.
<infinity> Logan: We don't copy backward for the reason ScottK stated.  Sometimes, if the versions already matched before, I'll consider copying forward (ie: sru to vivid, copy to wily, that sort of thing).
<Logan> gotcha, thanks!
<Riddell> infinity, stgraber: lordievader here wants to lead on kubuntu alpha 2 next week cos we're all away at akademy otherwise
<Riddell> can you give him admin powers on iso tracker?
<lordievader> Do note I have no idea what 'taking the lead' means, I'm just a simple tester ;)
<Laney> Riddell: can you reply to the thread and say you want to participate please?
<Laney> and it's some team "kubuntu release" but I can't see its launchapd ID
<Riddell> lordievader: test the ISOs, poke others into testing the ISOs, decide if it's good enough for an alpha or not, poke people to make fixes if not
<Riddell> lordievader: what's your e-mail?
<flexiondotorg> Riddell, Someone else has sponsored ubuntu-mate-welcome. It is in the new queue right now.
 * Riddell looks
<flexiondotorg> Riddell, The issue you've seen "works" on Ubuntu MATE because the mate-menu package is installed by default.
<Riddell> then it should pre-depend on mate-menu
<flexiondotorg> Riddell, But I will release a 1.0.1 which address the dependency issue you caught.
<flexiondotorg> Riddell, Yes, I've added that, but not release yet. Like I say, it "works" for Ubuntu MATE.
<Riddell> ok
<Riddell> gosh fonts are so complex, flexiondotorg what's an fontawesome-webfont.eot file ?
<Riddell> what's the .eot ?
<Riddell> flexiondotorg: data/css/font-awesome.css does say the font is OFL 1.1 so you can remove the comment in copyright about no versions being specified
<Riddell> flexiondotorg: accepted!
<Riddell> ping me about the binaries in a bit
<flexiondotorg> Riddell, Well, the fonts are essentially icons.
<flexiondotorg> Riddell, Thanks.
<lordievader> Riddell: Its on launchpad: https://launchpad.net/~oliviervdtoorn
<Riddell> lordievader: "No public address provided. " but I found it
<lordievader> Ah, oke ;)
<flexiondotorg> Riddell, eot are embedded OpenType fonts.
<flexiondotorg> Riddell, Many thanks for your help.
<Riddell> flexiondotorg: the font can be removed https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-welcome/+bug/1477962
<ubot93> Launchpad bug 1477962 in ubuntu-mate-welcome (Ubuntu) "lintian warnings" [Undecided,New]
<Riddell> binary accepted!
<flexiondotorg> Riddell, OK, I'll look at that bug later. ubuntu-mate.org is under DDoS attack right now, so I'm dealing with that.
<rtg> infinity, re-uploaded blktap-dmks for Trusty with yet another compatibility patch, this time for Linux 3.13, courtesy of smb. bug #1477718
<ubot93> bug 1477718 in blktap-dkms (Ubuntu Trusty) "blktap-dkms FTBS on kernels >= 4.1" [Undecided,Fix committed] https://launchpad.net/bugs/1477718
<Daviey> arges: bug 1464253 is referenced in an SRU but still marked as Private, i guess this should be made Public now
<Daviey> (it might have made more sense for it to be a sec upload IMO)
<arges> Daviey: i'll takea  look
<arges> Odd_Bloke: is it ok if bug 1464253 be made public security?
<arges> Daviey: actually I grepped through my logs, he ACKd making this public before. So its done now.
<Daviey> arges: Super, thanks
<Odd_Bloke> arges: Yeah, definitely.
<Odd_Bloke> Oh, caught up.
<Odd_Bloke> Cool. :)
<slangasek> Laney: I see you force-badtest'ed lava-server... I don't think that was correct, that means that lava-server /itself/ was let into wily, when it was the new package that was broken
<slangasek> (when I did this for lava-dispatcher, I also removed the broken lava-dispatcher from -proposed first)
#ubuntu-release 2015-07-25
<doko> please could somebody review python-ipaddress? ^^^ python2 compat, code already is in python3.x
<Laney> slangasek: I considered adding a block too, but the previous version was failing in the same way already so didn't
<teward> ^ that nginx upload is the SRU for https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1314740 and applies Debian's solution to the issue here.
<ubot93> Launchpad bug 1314740 in nginx (Ubuntu Trusty) "[SRU] init script pid parsing has failure cases" [Medium,In progress]
#ubuntu-release 2016-07-25
<michi_> robru: ping
<robru> michi_: it's Monday somewhere, isn't it?  ;-)
<michi_> Oh, sorry, forgot. Never mind!
<robru> michi_: no no I'm free if you need something
<michi_> It looks like I have a stuck build.
<robru> What ticket?
<michi_> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-054/+packages
<michi_> The thumbnailer xenial armhf build seems to be going nowhere:
<michi_> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-054/+build/10513903
<robru> michi_: only 22 minutes? How long does that normally take?
<michi_> All the others are finished.
<michi_> And I've never seen it getting stuck on syncing the clock.
<robru> Ok I'll retry it
<robru> michi_: ok cancelled it, not sure how long until it lets me hit retry
<michi_> It claims it succeeded now.
<michi_> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-054/+build/10513897
<michi_> Wonder whether that's bogus.
<robru> michi_: that's vivid
<michi_> Ah, sorry, yes.
<michi_> OK, xenial is building. Thanks for your help!
<robru> michi_: you're welcome!
<michi_> robru: built and tested OK this time, thanks!
<robru> michi_: you're welcome!
<Mirv> could I get binNEW review (before landing) for https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-024/+sourcepub/6736687/+listing-archive-extra : libqt53dquickinput5 libqt53dquickrender5  libqt53drender5 and https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-024/+sourcepub/6737342/+listing-archive-extra : qt5-qmltooling-plugins . the new packages are unmodified from D
<Mirv> ebian.
<Mirv> (I asked seb128 a few hours ago, but now expanding the archive admins reach)
<seb128> the queue copy bypass binNEW? I though they did go over sourceNEW
<seb128> in any case if the new binaries are from Debian it should be fine
<cjwatson> seb128: https://bugs.launchpad.net/launchpad/+bug/993120
<ubot5> Launchpad bug 993120 in Launchpad itself "Copy from PPA with binaries evades NEW and puts new packages in their default component" [High,In progress]
<seb128> cjwatson, thanks, I tried to look in my IRC look and could find it, I though it was bypassing sourceNEW
<cjwatson> no, source NEW works
<seb128> k, so it's the other way around of what I though... ;-)
<infinity> cjwatson: Curious definition of "In Progress" being used for the status of that bug.
<infinity> bdmurray: ^-- I need a review/accept on the above ASAP.
<bdmurray> infinity: back, will look now
<infinity> bdmurray: Ta.
<infinity> bdmurray: Will be a trusty d-i with similar urgency shortly, once my PPA test build is done.
<infinity> bdmurray: ^-- And there's the d-i.
<infinity> bdmurray: And thanks again.
#ubuntu-release 2016-07-26
<infinity> tjaalton: Trusty dailies with hwe-x should be popping out in about 3hr.
<infinity> tjaalton: I do have a concern that you dropped a bunch of video drivers from video-all for this backport.
<infinity> tjaalton: While dropping support for those in xenial was fine, I'm concerned when we upgrade users who installed with hwe-u/v/w to hwe-x, they may not have a video driver anymore.
<Mirv> Qt 5.6.1 ongoing. It will be stuck in proposed for a while, Kubuntu folks will now start uploading their updates that will then sort out the autopkgtest problems.
<tjaalton> infinity: ok, easy to add back
<jbicha> is Kubuntu skipping Alpha2 then?
<tsimonq2> infinity: the Lubuntu team is ready for an LXQt image to be spun up on a daily basis, so we can start getting it to work, we have the *qt* seeds (not bolded, wildcards on both sides) ready to go, and we just need an image spun up now
<tsimonq2> infinity: I don't know much about how seeds work, but if you have any questions about the Qt/LXQt ones, let me know
<tsimonq2> infinity: and can we just get desktop for now until we do some testing and further manipulation of the seed?
<tsimonq2> infinity: also, if it matters, can it be something like lubuntu-next instead of lubuntu-qt?
<Mirv> jbicha: if you asked regarding the Qt, they are fine it being in the proposed and I guess it will take more than two days for everything to be resolved (but they can at least start now)
<yofel> jbicha: yes, kubuntu is skipping a2. There's no point in testing the current archive state
<yofel> on a side note: did the discussion about adding ~ubuntu-dev to ~ubuntu-transition-trackers ever get anywhere?
<sil2100> Hello release team!
<sil2100> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#address-book-app
<sil2100> address-book-app fails to migrate because of arm64 left-over binaries, but those were only in -proposed
<sil2100> I reverted the addition of those binaries as they caused uninstallability issues currently
<tsimonq2> infinity: seems like a little bit more work than just asking someone to do it, right? https://wiki.ubuntu.com/RecognizedFlavors says a couple of things such as getting an IS signoff, but since we already have a set of images, what out of that page would still need to be done?
<sil2100> Could anyone just remove those old binaries? Otherwise it won't migrate
<sil2100> And we won't enable arm64 binaries on it until we won't get unity8 arm64 building
<apw> sil2100, that then is just NBS in yakkety-proposed ...
<sil2100> Well, proposed migration doesn't want to let it through now
<sil2100> Just want it to migrate, as the arm64 binaries never went out of -proposed and should not exist
<apw> sil2100, sorry yes, and that will jam up indeed, i am confused that the new one still builds on arm64, i thought that was to revert it
<apw> (not that primary binary packages, but still some qt* ones)
<apw> oh ok, they are pre-existing ignore me
<apw> sil2100, ok should be gone
<sil2100> apw: thanks!
<sil2100> :)
<Laney> yofel: I've invited them - you need the DMB to approve the invitation
<rbasak> yofel, Laney: done
<yofel> \o/
<tsimonq2> rbasak: seems you are on the DMB, so let me ask you. Is the process complicated if a flavor wants to have another image built? Does it have to go through IS and everything that is on the wiki page even if the flavor already has some images?
<tsimonq2> rbasak: (wiki page I'm talking about is https://wiki.ubuntu.com/RecognizedFlavors )
<rbasak> tsimonq2: sorry, that's not really a DMB thing. I think it probably falls under the release team, so try asking on the ubuntu-release ML if you don't get an answer here.
<tsimonq2> rbasak: oh so it isn't? good to know, thanks
 * tsimonq2 's definition of DMB is probably mixed up, Googling
<tsimonq2> yeah sorry rbasak, confused DMB with tech board :)
<rbasak> Ah, yes. It's presumably either under the release team's remit, or falls back to the TB if not. In practice, you'll probably end up with someone on both teams to handle it :)
<tsimonq2> rbasak: I pinged Adam earlier, he's on both, so I think that's a safe bet :)
<Dataforce> Hey all - when are 14.04 users going to start being prompted for 16.04? I was expecting it last week but http://changelogs.ubuntu.com/meta-release-lts still just lists trusty and I'm not seeing the prompts or getting a release prompt from `do-release-upgrade` (I know I could use -d to force it but that's not the point ;))
<apw> Dataforce, i know it was not enabled immediatly, that the decision was going to be made early this week
<Dataforce> apw: ah ok thanks, I'm just wondering when it'll happen so that I can monitor our mirror server for the (presumed) extra traffic
<jibel> infinity, upgrade tests are done, nothing to report. and it worked on preinstalled 14.0 'on dell too
<jibel> infinity, I think it's good to open the upgrade to 16.04.1
<infinity> jibel: That was a much more promising (and boring) report than I was expecting.
<infinity> jibel: But thanks!
<flocculant> infinity jibel: I know that I've at least tested for me upgrading - have other flavours at least checked?
<flocculant> I'd have hoped so - but I rarely saw anything on the tracker
<jbicha> UGNOME has a tester who did upgrade testing and he didn't report any issues
<tsimonq2> I personally tested with Lubuntu
<tsimonq2> infinity: speaking of Lubuntu, how would I go about getting that image built?
<infinity> tsimonq2: Merge proposals for livecd-rootfs and debian-cd, for a start.
<infinity> s/debian-cd/ubuntu-cdimage/
<infinity> Brain not awake yet.
<tsimonq2> alright
<tsimonq2> yay, Bazaar... :P
<tsimonq2> infinity: do you need me to make a debian/changelog entry on livecd-rootfs?
<tsimonq2> I'm assuming not?
<ogra_> your commit should have a changelog entry ... against UNRELEASED
<tsimonq2> alright thanks ogra_
<tsimonq2> there: https://code.launchpad.net/~tsimonq2/livecd-rootfs/lubuntu-next-image/+merge/301202
<tsimonq2> I don't have experience with this so let me know how I did :P
<tsimonq2> infinity: https://code.launchpad.net/~tsimonq2/ubuntu-cdimage/lubuntu-next-image/+merge/301203 and https://code.launchpad.net/~tsimonq2/livecd-rootfs/lubuntu-next-image/+merge/301202 is good to go, what now?
<bdmurray> infinity: When are you thinking about making the meta-release change?
<tsimonq2> infinity: what's the ETA for getting Alpha 2 prepared? (iso.qa.ubuntu.com etc.)
<infinity> tsimonq2: Dunno.  Note the complete lack of anyone signing up to do A2: https://wiki.ubuntu.com/YakketyYak/ReleaseTaskSignup
<tsimonq2> infinity: Lubuntu is, putting Lubuntu there
<tsimonq2> oh I see
<tsimonq2> infinity: I can do it if you are fine with it, although I'm not *officially* a release manager
<tsimonq2> (the checklist tracking)
<tsimonq2> infinity: I just helped flexiondotorg for Alpha 1
<tsimonq2> in addition to that, I don't know who *can* do Nusakan publishing
<tsimonq2> I can't
<flocculant> tsimonq2: that'd be someone canonical'ish
<tsimonq2> flocculant: you talking about Nusakan or checklist tracking? because I can totally do the latter
<flocculant> you were asking about publishing
<tsimonq2> flocculant: I was just sort of pointing out the former
<tsimonq2> yeah sorry
<flocculant> there's not been an A2 message on release either I see
<tsimonq2> flocculant: you think it's too late to send a message and ask who's participating?
<flocculant> not that it actually affects Xubuntu
<flocculant> tsimonq2: of course it is - gets to the list today, wait for timezones, it's thursday
<tsimonq2> flocculant: yeah so I don't know if it's too late :(
<flocculant> people need to actually do the flavour stuff - the mail from 'canonical' about all that is at least 4 cycles old I'm sure
<tsimonq2> about?
<tsimonq2> you talking about checklist tracking?
<flocculant> https://lists.ubuntu.com/archives/ubuntu-release/2014-December/003166.html
<flocculant> it's been like that for a while now, so trying to catch up 2 days before release seems a bit silly
<flocculant> and I'm not pointing nor talking about you specifically :)
<tsimonq2> alright :)
<tsimonq2> so what do you suggest happens from here, flocculant?
<flocculant> tsimonq2: nothing to do with me - I said weeks ago we're not bothering till Final ;)
<tsimonq2> alright flocculant :)
<flocculant> part of *my* reasoning was all of this - some flavours make the effort - others don't
<tsimonq2> for the time being, I'll put my name on Alpha 2's checklist tracking, and if anyone has a problem with that, please let me know ASAP
<flocculant> in fact iirc it has been Lubuntu/Xubuntu/Kubuntu and Mate doing all the running for flavours
<infinity> tsimonq2: FWIW, I'm inclined to agree with flocculant on this.  If no one thought to volunteer, put out a call for participants, etc, until Tuesday, I'd be inclined to just skip it.  Too little, too late.  There's no obligation to do pre-beta-2-milestones.
<infinity> tsimonq2: Yes, Canonical can hunt down someone to do the backend bits if the community wants to do them, but the contract there was that the community had to step up and drive the process.  That really didn't happen here.
<tsimonq2> infinity: I wasn't aware of this so I had no idea. It would be great if Lubuntu could release an Alpha 2 image but if it can't happen, I understand
<wxl> i'd be shocked if at least mate doesn't want in
<tsimonq2> yeah
<flocculant> that's not the point thought is it
<tsimonq2> flocculant: how so?
<flocculant> it's Tuesday and no-one bothered to start the ball rolling last week
<flocculant> really not hard to understand tsimonq2
<flocculant> yes there was other things happening - but it's just an e-mail to do that
<rbasak> I wonder if it would help this kind of thing if there were a flavor lead on the release team generally looking after non-Canonical flavors. Did that help when we had that in the past?
<infinity> rbasak: Did we have that in the past?
<infinity> (The answer is no)
<rbasak> Scott?
<flocculant> rbasak: how would that help - surely a flavour knows when it wants to do something - if that doesn't get flagged up early enough - then they should shout out
<infinity> We had member of the release team who happened to work more with a specific flavour than with Ubuntu (Scott and Jonathan), but they didn't go chasing other flavours and babysitting.
<flocculant> rbasak: and last week was when I would have shouted if xubuntu was taking part
<rbasak> I meant socially, rather than technically, if there's someone volunteering to think about these things. Just a thought.
<infinity> We're trying to move in the other direction, though. ;)
<wxl> i don't think chasing/babysitting is an issue that the flavors can't take care of. however, since they're often little teams, a little heads up would be nice.
<rbasak> What direction's that?
<infinity> The point of this contract was to allow flavours to step up and help themselves do something that, largely, many of us think is pointless. ;)
<infinity> (To put it bluntly)
<flocculant> wxl: surely the release schecdule is sufficient heads up?
<infinity> I'd like to ditch all pre-final-beta milestones entirely and replace them with community testing parties, where people gather on IRC, order in some pizza, grab a few dailies, file a bunch of bugs, have a good time, but there's no milestone released.
<flocculant> I used to add the dates to the xub trello tool, then later to the xub calendar
<infinity> Because releasing blessed ISO milsetone images is, frankly, bad.
<rbasak> I'm only suggesting something that would assist with helping flavours step up.
<wxl> i'd say that's a fair notion infinity
<infinity> rbasak: Sure, and anyone could do that, if they so choose.
<infinity> rbasak: It's not the release team's responsibility to be a personal calendar, mind you.
<rbasak> But anyway, I don't have a strong opinion on this. I just wondered if people thought that might help. Perhaps not then.
<tsimonq2> to be honest, I've had my eye on this for a while, and it surprised me that *today* nobody was thinking about it
<tsimonq2> Lubuntu could very well release Alpha 2
<tsimonq2> *could* - we need release team support
<wxl> tsimonq2: well it's a fair notion to expect us to figure out exactly who's participating and who's not ahead of time
<wxl> in all honesty, doing away with milestones would be really nice
<wxl> i think quite possibly it might lead to more testing
<wxl> so many testers seem to wait until the milestone, which is really not ideal
<wxl> it's the wrong effort
<wxl> we need testing of a wider scope
<infinity> wxl: Right, the counter-argument is that understaffed flavours can't test every day, so milestones provide a rallying point.  Hence my suggestion to just turn milestones into IRC beer and pizza bughunting day.  No pressure to RELEASE a thing, just find all the bugs you can and have fun fixing.
<wxl> infinity: yes, but we could certainly test with the same amount of frequency
<tsimonq2> infinity: devil's advocate: an excuse to procrastinate, if it's informal, they have the option to postpone
<tsimonq2> infinity: whereas with a release it's more urgent
<tsimonq2> just saying :P
<tsimonq2> but I agree with the points made
<wxl> i think it's worth a test some cycle
<wxl> and a non-LTS one at that
<tsimonq2> the question is, what are we doing *now* ?
<infinity> tsimonq2: milestones are optional anyway (as is community participation in testing them), so...
<tsimonq2> what's our plan?
<tsimonq2> yeah infinity :P
<tsimonq2> are we going to release Alpha 2?
<wxl> i think the other flavor leads are probably afk
<infinity> Depends on if you get responses to your mail.
<infinity> But, honestly, by the time you do, you're leaving a day for spin/test/respin before release.
<infinity> Which effectively means spin/release.
<infinity> So, sure.  I could release today's daily as a milestone for you.  But that would be worthless. ;)
<wxl> what about the others that seem to be signed up? https://wiki.ubuntu.com/YakketyYak/Alpha2
<tsimonq2> ^
<wxl> flexiondotorg created that so i'm sure that means mate's in (hwich would be my guess anyways based on the past)
<wxl> similarly kylin released an alpha 1 so i doubt they don;t want to release 2
<wxl> my vote is to include the three of us and make a milestone
<tsimonq2> I agree with that
<tsimonq2> because we have a general idea
<wxl> and follow it up with an email discussing that this will be the LAST TIME we do this without communication from flavors
<tsimonq2> agreed as well
<tsimonq2> infinity: thoughts?
<infinity> wxl: Fair enough.  We can set it up for Lu/Ky/MATE.
<infinity> wxl: I might have to find someone else to do the release bits for you on Thursday.
<infinity> Laney: Feel like being a community release sucker for A2?  My hands are full with 14.04.5
<infinity> wxl, tsimonq2: I'll set up the milestone and put in a britney block after I've found some lunch and such.
<tsimonq2> thanks infinity, wxl's out to lunch too :)
<tsimonq2> infinity: could you also please review those MPs when you get a minute?
<tsimonq2> infinity: whatever Lubuntu Next images that are set up as a result of that won't go into A2
<flocculant> wxl: not read the whole backlog - but xubuntu tries to push those likely to actually test to run dev/current
<infinity> flocculant: Yeah, still need occasional install testing, too.
<infinity> I do so love how all the critical installer bugs seem to be found and fixed a week before final release. :P
<flexiondotorg> wxl, Yes. Ubuntu MATE is in for Alpha 2 :-)
<tsimonq2> \o/
<tsimonq2> hello flexiondotorg :)
<flexiondotorg> tsimonq2, o/
<tsimonq2> flexiondotorg: just setting up Mumble to go on LUP, but I'm glad that we're good in that area :)
<flocculant> infinity: I do this every now and again http://dev.xubuntu.org/#tab-qa
<flocculant> which matches up to the tracker
<flocculant> trying to get people an easy way to see current status
<flocculant> of course I really need a vbox column too :p
<infinity> Alright, Alpha 2 set up.  Not going to impose the block or build the first images until autopkgtesting and proposed-migration have settled down a bit.
<infinity> So, in a few hours.
<flocculant> infinity: I try and find installer issues asap, but on the other hand - at least this cycle when Nick had moved on - I found install issues, but because no tracker home, hard to know who to tell
<flocculant> in the end cyphermox idles in xubuntu-dev so pinged him I think
<flocculant> I try not to hassle people in here as much as I can
<flocculant> I kind of hoped that if 'bug' 'install' yaketty' people noticed
<flocculant> if tagging bugs on tracker doesn't actually do much - that's useful info
 * flocculant wouldn't actually (unless asked) tag a person or team
<flocculant> kind of expect the tool to do that
<flocculant> but it is hard out here in 'flavour' land to know what to do for the best
<flocculant> wxl flexiondotorg might comment
<tsimonq2> infinity: can you look at my MPs?
#ubuntu-release 2016-07-27
<cyphermox> flocculant: I'd say for me, don't be afraid to ping me on IRC in any channel, I'll tell you if I'm otherwise busy
<cyphermox> installer bugs are usually easy enough to handle by interruption.
<infinity> tjaalton: Around?
<Laney> infinity: I can do nusakan bits
<infinity> Laney: Ta.  I already uncronned, I'm waiting for a publisher run or two to get a couple of packages in, then britney blocking, spinning candidates, and sleeping.
<Laney> 'k
<infinity> Laney: If yuo can take over from there, I'll be happy.
<Laney> Is someone lined up to do the cat herding and release announcement?
<infinity> Laney: Annoy wxl/flexiondotorg until one volunteers. :P
<infinity> Laney: (or a kylin dude, if you want your announcement in Chinese)
<Laney> ni hao
<infinity> Or maybe flexiondotorg will spin his own before I get a chance to. :P
<flexiondotorg> infinity, :-)
<infinity> flexiondotorg: I was waiting a publisher run to get snapd in and then landing the britney block.
<flexiondotorg> If Ubuntu MATE spins again, that is fine with me :-)
<infinity> Actually, I guess I can block now.  It's migrating.
 * infinity goes to watch some Futurama while that all settles down.
<willcooke> infinity, Spoke to j_ibel last night and he's +1 on enabling the upgrade notifications now.  Is that something you take care of?
<willcooke> If so, I have a blog post to push out in sync with that.
<infinity> willcooke: More likely to happen during my day than right now, while I'm groggy and not sure I've crossed and dotted all the right letters.
<willcooke> infinity, no problem at all.  Could you poke me when you're about to do it/have done it?
<infinity> willcooke: I can try to remember.
 * infinity writes a big note on his monitor.
<willcooke> infinity, ta :)
<tjaalton> infinity: officially on vacation
<infinity> tjaalton: Oh.  Did we get any yay/nay test results on the dailies with HWE-X, so I can promote the world?
<infinity> tjaalton: Also, I'd love a new video-all that resurrects all the drivers that were in main in HWE-{U,V,W}
<infinity> tjaalton: But I suppose I can figure out how to do that myself if I have to.
<tjaalton> infinity: i'll download daily and test
<infinity> tjaalton: You're my hero.
<infinity> willcooke: Can you get your team to grab the trusty daily and smoketest booting the live session on some random real hardware?
<infinity> willcooke: Just to make sure the HWE-X stack appears mostly not FUBAR?
<infinity> tjaalton / willcooke: I'll look forward to nick highlights in the morning from both of you. :)
<willcooke> infinity, ack - will do
<infinity> tjaalton: As for the driver resurrection, I can do that myself if you don't have the time.  Shouldn't be rocket science.
 * infinity wanders off to fall into bed.
<tjaalton> infinity: I'll test the image with virt-manager, will look into the metapackage too
<willcooke> night infinity
<infinity> tseliot: Erm, speaking of HWE-X.. Are we missing nvidia updates in trusty for the xenial HWE stack?
<tseliot> infinity: why? Does nvidia fail to build?
<tjaalton> nvidia has correct deps already
<infinity> tseliot: No idea, I just noticed the lack of 361 in trusty.  But maybe it's not necessary?
<infinity> tjaalton: Kay.
<tjaalton> just needs that it supports the ideo abi
<tjaalton> +v
<tjaalton> and provides it
<tseliot> infinity: yes, I think we'll skip that one in trusty
<infinity> Right.  But since this is all about HWE, I figured maybe 361 supported more devices. :P
<infinity> s/more/newer/
<tseliot> I suppose HWE already uses newer drivers
<infinity> Fine with skipping it, though, people with shiny new video cards can upgrade to xenial.
<tseliot> I really need to get a new driver into Yakkety though...
<tseliot> s/driver/nvidia driver/
<balloons> can someone approve juju-core 2.0~beta12-0ubuntu1.16.04.1 for xenial? It's not clear of what status it has in the queue, and I don't see it in proposed
<tjaalton> infinity: yep, image looks good that it installs the right stuff at least
<tjaalton> infinity: uploaded new xorg-lts-xenial that added the video drivers to -video-all for i386/amd64, guess that's enough
<infinity> tjaalton: Seems to be a bit of a crufty upload.
<infinity> tjaalton: Also, looks like most of those should be on powerpc too.
<xnox> infinity, debdiff should really show file-permission changes, cause you know 3.0 format does encode them, and permissions-only diff really does break things =)
 * xnox ponders where to file that.
<xnox> it should be git formatted permissions change thing
<cjwatson> xnox: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691250
<ubot5> Debian bug 691250 in devscripts "[debdiff] support source format 3.0 containing executables and symbolic links in debian/" [Wishlist,Open]
<willcooke> infinity, few rounds of testing on 3 different machines show no obvious new problems
<bdmurray> infinity: What's the status on changing the meta-release file?  The masses are clamoring bug 1606850 among others.
<ubot5> bug 1606850 in Ubuntu "LTS upgrade should be opened on Release Date of 1st Pointrelease" [Undecided,New] https://launchpad.net/bugs/1606850
<teward> bdmurray: last i heard via pici, 28th (tomorrow) was when they were opening it
<teward> i.e. release path opening delayed 7 days (and happens to coincide with 15.10 EOL)
<jbicha> bdmurray: I think i_nfinity posted here that he was doing it after he wakes up
<jbicha> but that's not exactly what he said either, so who knows? I guess it's already thurs in some places
<teward> whenever it's opened up, i'm one of the ones in the upgrade queue.  I have a full image of my existing hard drive as a backup too, in case it fails (and I go back to 14.04 heh)
<bdmurray> using -p with do-release-upgrade will do the same thing
<bdmurray> the same thing as if the meta-release file was updated
<teward> right, but i'm the one who waits for it to be opened - not in a rush to upgrade in case it breaks and destroys things on my computer
<davmor2> infinity, bdmurray: I've marked https://bugs.launchpad.net/bugs/1604441 as verified that is everything I need to do right?  Once this lands can we have new netboot images please :)
<ubot5> Launchpad bug 1604441 in debian-installer (Ubuntu Trusty) "D-I on 16.04.1 breaks on usb probe and networking setup on secureboot" [Critical,Fix committed]
<infinity> davmor2: You have new netboot images already.  Your wish is granted. :)
<infinity> bdmurray: We're all good, except for confirming with IS that we won't break their network.
<infinity> elmo: ^
<cyphermox> infinity: it's not too late to break networks.
<slashd> good afternoon arges, can you nominate LP: #1574342 that affects Xenial and Yakkety ?
<ubot5> Launchpad bug 1574342 in zfs-linux (Ubuntu) "Ship arcstat.py and arc_summary.py with zfsutils-linux" [Medium,In progress] https://launchpad.net/bugs/1574342
<apw> slashd, nominated
<slashd> apw, tks
<tsimonq2> infinity, Laney: I volunteered to do the release notes as my name is on https://wiki.ubuntu.com/YakketyYak/ReleaseTaskSignup
#ubuntu-release 2016-07-28
<davmor2> infinity: wonderbar
<willcooke> infinity, did the upgrade notifications go live?  (Want to press publish on this blog post and then forget about it)
<apw> willcooke, i do not see xenial in the meta-release-lts as yet ...
<willcooke> apw, oki, thanks apw
<willcooke> apw, is there something (a URL?) I can look at which would save me bothering you guys?
<Laney> willcooke: http://changelogs.ubuntu.com/meta-release-lts
<willcooke> thanks Laney
<willcooke> Laney, so when I see Xenial appear in that list, we are go?
<Laney> That means it's active, I'm sure that it won't simply happen silently though
<Laney> tsimonq2: thanks, so your task if you choose to accept it is to get http://iso.qa.ubuntu.com/qatracker/milestones/364/builds to be all "ready"
<tsimonq2> Laney: well Kylin is done, flexiondotorg is handling MATE (I'll do some a bit later if he can't), and that's the one thing for Lubuntu I don't have permissions for :P
<Laney> tsimonq2: I can tick them if you want
<tsimonq2> Laney: that would be awesonme
<tsimonq2> *awesome
<Laney> done
<Laney> this is a nice and small alpha
<Laney> let's get it done before lunch
<tsimonq2> Laney: also, could you please take a look at the two PRs I have open adding the Lubuntu Next (LXQt) image?
<tsimonq2> \o/
<tsimonq2> Laney: no PowerPC, uncheck that please
<tsimonq2> Laney: we don't release PowerPC on non-LTS
<tsimonq2> Laney: plus that has a pretty bad PowerPC-specific bug on it
<Laney> ok
<Laney> we should get it off the manifest then
<tsimonq2> alright
<Laney> done...
<Laney> I think.....
<tsimonq2> Laney: alternate still needs the boot
<Laney> nein, check again
<tsimonq2> Laney: thanks
<flexiondotorg> Laney, I've just marked Ubuntu MATE ready.
<flexiondotorg> One issue with PowerPC images, but can be worked around and documented in the release announcement.
<flexiondotorg> Looks like we have a full house.
<tsimonq2> great! :)
<tsimonq2> Laney: is it time then to send out the global announcement if we're all marked as ready?
<flexiondotorg> tsimonq2, My understanding is someone has be push the images around the distribution network first.
<flexiondotorg> Then we get to announce.
<flexiondotorg> tsimonq2, Have you written a release announcement email?
<apw> publishing first i believe yes
<tsimonq2> flexiondotorg: working on it
<flexiondotorg> :-D
<tsimonq2> flexiondotorg: help, what should I use for a quote? :P
<flexiondotorg> tsimonq2, I'll sort that for you...
<tsimonq2> flexiondotorg: thanks, I'll get the rest of the announcement :D
<Laney> Indeed
<Laney> I'll do that shortly
<Laney> freeze block is lifted
<flexiondotorg> tsimonq2, You've been supplied a quote. All yours now. Just wait for Laney to give you the nod before posting the email :-)
<tsimonq2> thanks a lot flexiondotorg :)
<Laney> tsimonq2: ok, I just pushed the button
<Laney> give it a few minutes for torrents to start working
<tsimonq2> alright
<tsimonq2> Laney: give me like 20 mins and I'll send it
<Laney> i'll put the cron builds back on
<tsimonq2> yay
<tsimonq2> Laney: in the meantime, speaking of that, can I get my two PRs looked at please? :)
<Laney> I can't right now, but i_nfinity or s_langasek would be better in the first instance anyway
<Laney> lemme know on monday if you're still waiting
<Laney> (patch piloting then)
<slangasek> Laney: fyi that fails to miss my highlight regexp
<Laney> is it deliberately wide enough to catch that kind of thing?
<slangasek> Laney: no, but you matched my last name ;)
<tsimonq2> slangasek: so can you? :D
<slangasek> I didn't see the actual question
<slangasek> "my two PRs" - where?
<Laney> heh
<tsimonq2> slangasek: can you look at the merge proposals I sent a few days ago adding a Lubuntu Next image?
<slangasek> ok
 * tsimonq2 hunts them down
<slangasek> I think I'm going to have to defer that to infinity fwiw
<slangasek> am at a work sprint right now so ENOTIME, sorry
<tsimonq2> alright slangasek :)
<tsimonq2> flexiondotorg, Laney: global release announcement sent
<tsimonq2> I need approval for ubuntu-devel-announce, can someone please do that?
<Laney> I would wait 10 minutes for all the rsyncing to finish
<Laney> (don't have the moderator password for u-d-a anyway)
<tsimonq2> alright
<slangasek> I can do that part
<slangasek> tsimonq2: fyi the quote thing was traditionally a "first milestone of the cycle" thing
<slangasek> am I waiting before approving, or am I pushing the button?
<tsimonq2> slangasek: /me blames flexiondotorg
<tsimonq2> :P
 * flexiondotorg doesn't know any better.
<flexiondotorg> I've always put a quote in.
<tsimonq2> I don't know any better either :P
<tsimonq2> slangasek: it doesn't hurt, right? :)
<Laney> slangasek: I don't see any rsync processes any more, so go for it
<tsimonq2> Laney: posting to Fridge then too, after I correct some trivial things
<Laney> my work here is done
 * Laney lunch
<tsimonq2> o/ Laney :)
<flexiondotorg> tsimonq2, Laney Thanks for your help :-)
<tsimonq2> thanks for yours as well flexiondotorg :)
<wxl> tsimonq2: were you going to send a followup email to ubuntu-release about the necessity for the community to be self-motivating if they want to release milestones?
<tsimonq2> wxl: no were you?
<wxl> tsimonq2: i can, if need be
<tsimonq2> wxl: go ahead :)
<rbasak> I feel that somebody from the community flavours needed to coordinate to stop being unhappy. Thank you for taking that up and sending the email.
<rbasak> wxl: ^
<wxl> np rbasak
<infinity> bdmurray: We have QA's and IS's +1 on the LTS->LTS upgrade switch.  Do you want to do the honors?
<bdmurray> infinity: Okay.  What's the status of the xorg lts-xenial stack for Trusty?
<infinity> bdmurray: Going to upload a fix on top of tjaalton's stuff, and then release it all to -updates.
<infinity> bdmurray: I'm told it tests fine on a variety of hardware.
<bdmurray> infinity: okay, I'm waiting on that to add HWE support stuff to Trusty's update-manager
<infinity> bdmurray: Erk.  Kay.  Surely, you could have tested while it was all in proposed?
<infinity> bdmurray: But I'll get all those Ts and Is dotted and crossed in the next few hours.
<bdmurray> infinity: I've tested it but I didn't want to upload it because the HWE upgrade didn't go to well for me with an X kernel and a W xorg stack.
<infinity> bdmurray: Well, yes, I meant you could have tested with X and X, since the X X is in proposed.
<infinity> Anyhow, will get on it this afternoon.
<bdmurray> infinity: And yes that's what I did.  Oh, I guess if anybody installed the proposed update-manager they'd have had proposed enabled so would get the X X from proposed.
<infinity> bdmurray: Oh, while you're committing to changelogs, you can s/Supported: 1/Supported: 0/ for wily too, I'm sending the EOL mail today.
<bdmurray> infinity: sure
#ubuntu-release 2016-07-29
<infinity> tjaalton: I cleaned up your cruft and added powerpc into that xorg-lts-xenial and reuploaded.
<tsimonq2> infinity: ping
<infinity> tsimonq2: Pong.  And no, I haven't looked at your MP.
<infinity> tsimonq2: I recommend being more interested in testing 14.04.5 dailies. ;)
<tsimonq2> infinity: sorry for bothering you :P
<tsimonq2> oh my god, our Trusty alternate images are 11 months old...
<infinity> tsimonq2: We don't do alternates for trusty point releases, just desktop.
<infinity> pitti: I'll give you big money and fabulous prizes if you claim the apparmor SRU review.
<infinity> pitti: (Or if you talk Steve into it -- he's in your timezone today)
<tsimonq2> infinity: oh alright
<pitti> infinity: 22 kB? not good enough, I want half a pony too for that
<tsimonq2> infinity: and fwiw about being interested in testing, I'm at someone else's house on a Chromebook right now, so I can't do much testing :P
<infinity> pitti: The pony is the fabulous prize.
<pitti> infinity: a bit internet deprived right now, but I'll have a look ASAP
<pitti> infinity: quite intrusive, but test coverage is really good, and I didn't see anything that looked wrong (just fixed up the bug tasks)
<LocutusOfBorg> can anybody please process trusty new queue?
<LocutusOfBorg> pitti, ^^^
<LocutusOfBorg> oh already accepted
<slangasek> mmm? :)
<ginggs> any archive-admins in the house?
<apw> ginggs, always best to ask for what you need done ...
<ginggs> remove old binaries LP: #1606469, i386-only package won't migrate LP: #1585058, finish boost1.60 transition http://people.canonical.com/~ubuntu-archive/transitions/html/html/boost1.60.html, remove all powerpc fpc-related packages LP: #1562480
<ubot5> Launchpad bug 1606469 in deal.ii (Ubuntu) "Remove deal.ii binaries from archs where it is missing build-deps" [Undecided,New] https://launchpad.net/bugs/1606469
<ubot5> Launchpad bug 1585058 in pixfrogger (Ubuntu) "Sync pixfrogger 1.0-4 (universe) from Debian unstable (main)" [Wishlist,Fix committed] https://launchpad.net/bugs/1585058
<ubot5> Launchpad bug 1562480 in glibc (Ubuntu) "fp-compiler not installable on powerpc since glibc 2.23" [High,New] https://launchpad.net/bugs/1562480
<ogra_> oooh ! "Ubuntu 16.04 is available" ...
 * ogra_ hugs the prompt
<Saviq> hey, if anyone's around, can you please remove indicator-keyboard s390x - it's fallout from the upstart removal - thanks :)
<infinity> Saviq: Expand on that a bit?
<infinity> Saviq: We're working on removing upstart deps from the system, not removing things that depend on upstart.
<infinity> (Though indicator-keyboard doesn't appear to depend on upstart anyway...)
<Saviq> infinity, it does, through liburl-dispatcher
<Saviq> infinity, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-073/+build/10535687
<Saviq> oh wait
<Saviq> sorry wrong link https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-073/+build/10535637
<Saviq> infinity, â
<infinity> pitti: When is the upstart removal stuff landing?
<Saviq> still, looks like ubuntu-system-settings has the same problem
<infinity> Saviq: Yeah, removing all the things that transitively depend on upstart is a mess.  It'd be much better to get the work from the upstart removal sprint landed ASAP.
<infinity> Saviq: Erm, but I'm also not seeing that problem in the archive...?
<infinity> Saviq: Did an upstatr dep get *added* in a PPA?
<Saviq> infinity, no, I thought the binaries simply got removed?
<Saviq> infinity, ack, anyway, if the plan is to have a different solution, fine by me - thought the plan was to remove them
<infinity> Saviq: Yes, what I'm saying is that liburl-dispatcher1-dev in the archive doesn't depend on upstart.
<Saviq> interesting
<Saviq> and it's even available https://launchpad.net/ubuntu/+source/url-dispatcher/0.1+16.04.20151110-0ubuntu2
<infinity> Oh.  Someone removed liburl-dispatcher1-dev itself from yakkety.  WTF.
<Saviq> ugh
<Saviq> anyway, I suppose there's a plan so we'll clarify on Monday
<infinity> Steve did it yesterday.  \o/
<infinity> slangasek: Why the liburl-dispatcher1-dev/s390x removal?
<infinity> slangasek: Can I see "grep ANAIS ~/.bash_history" please? :P
<dmj_s76> Has anyone seen issues installing with the Ubuntu 14.04.5 iso and nvme drives?
<dmj_s76> infinity: First boot after installing 14.04.5 onto an nvme drive fails and drops to an initramfs prompt
<dmj_s76> this is consistent across multiple machines.
<slangasek> infinity: sure; that returns no output because my shell history has already rolled over.  so ''
<slangasek> infinity: per discussion on #ubuntu-ci-eng, I was working through trying to remove packages that are revdeps on upstart/s390x and also FTBFS
<slangasek> infinity: url-dispatcher declares a build-depends: upstart, so is clearly marked for death
<slangasek> (on s390x)
 * slangasek wonders who promoted libpod-constants-perl to main before the MIR was closed out...
#ubuntu-release 2016-07-31
<LocutusOfBorg> slangasek, ^^ pretty please :)
<LocutusOfBorg> and next time you accept some lts stack updates, could you please ping me and accept vbox too? it will make my life easier
<LocutusOfBorg> also, maybe you can make initramfs-tools migrate, since the failures aren't related to my changes (at least to my poor checks)
<pitti> infinity: the last bit of infra landed Friday afternoon, so I'll do the main switch on Monday; but https://requests.ci-train.ubuntu.com/#/ticket/1710 contains the other half of the transition, not sure when this lands
#ubuntu-release 2017-07-24
-queuebot:#ubuntu-release- New binary: numba [amd64] (artful-proposed/universe) [0.34.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-tidal [ppc64el] (artful-proposed/universe) [0.8.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-tidal [i386] (artful-proposed/universe) [0.8.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-tidal [s390x] (artful-proposed/universe) [0.8.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-tidal [amd64] (artful-proposed/universe) [0.8.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-tidal [armhf] (artful-proposed/universe) [0.8.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-tidal [arm64] (artful-proposed/universe) [0.8.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-dirtyread [s390x] (artful-proposed/universe) [1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-dirtyread [amd64] (artful-proposed/universe) [1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-django-imagekit [amd64] (artful-proposed/universe) [4.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-dirtyread [ppc64el] (artful-proposed/universe) [1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-dirtyread [arm64] (artful-proposed/universe) [1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-dirtyread [i386] (artful-proposed/universe) [1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-rtmidi [s390x] (artful-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-dirtyread [armhf] (artful-proposed/universe) [1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-rtmidi [ppc64el] (artful-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-rtmidi [amd64] (artful-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-rtmidi [armhf] (artful-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-rtmidi [arm64] (artful-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-rtmidi [i386] (artful-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-tidal [amd64] (artful-proposed) [0.8.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-tidal [armhf] (artful-proposed) [0.8.2-1]
-queuebot:#ubuntu-release- New: accepted pg-dirtyread [arm64] (artful-proposed) [1.1]
-queuebot:#ubuntu-release- New: accepted pg-dirtyread [i386] (artful-proposed) [1.1]
-queuebot:#ubuntu-release- New: accepted pg-dirtyread [s390x] (artful-proposed) [1.1]
-queuebot:#ubuntu-release- New: accepted python-rtmidi [amd64] (artful-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted python-rtmidi [armhf] (artful-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted python-rtmidi [ppc64el] (artful-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-tidal [arm64] (artful-proposed) [0.8.2-1]
-queuebot:#ubuntu-release- New: accepted pg-dirtyread [armhf] (artful-proposed) [1.1]
-queuebot:#ubuntu-release- New: accepted python-django-imagekit [amd64] (artful-proposed) [4.0.1-1]
-queuebot:#ubuntu-release- New: accepted python-rtmidi [i386] (artful-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted pg-dirtyread [amd64] (artful-proposed) [1.1]
-queuebot:#ubuntu-release- New: accepted python-rtmidi [arm64] (artful-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted pg-dirtyread [ppc64el] (artful-proposed) [1.1]
-queuebot:#ubuntu-release- New: accepted python-rtmidi [s390x] (artful-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted github-backup [amd64] (artful-proposed) [1.20170301-1]
-queuebot:#ubuntu-release- New: accepted github-backup [armhf] (artful-proposed) [1.20170301-1]
-queuebot:#ubuntu-release- New: accepted github-backup [s390x] (artful-proposed) [1.20170301-1]
-queuebot:#ubuntu-release- New: accepted haskell-tidal [ppc64el] (artful-proposed) [0.8.2-1]
-queuebot:#ubuntu-release- New: accepted libalgorithm-permute-perl [amd64] (artful-proposed) [0.14-1]
-queuebot:#ubuntu-release- New: accepted libalgorithm-permute-perl [armhf] (artful-proposed) [0.14-1]
-queuebot:#ubuntu-release- New: accepted libalgorithm-permute-perl [ppc64el] (artful-proposed) [0.14-1]
-queuebot:#ubuntu-release- New: accepted numba [amd64] (artful-proposed) [0.34.0-2]
-queuebot:#ubuntu-release- New: accepted xf86-input-multitouch [arm64] (artful-proposed) [1.0~rc3-1]
-queuebot:#ubuntu-release- New: accepted xf86-input-multitouch [i386] (artful-proposed) [1.0~rc3-1]
-queuebot:#ubuntu-release- New: accepted github-backup [arm64] (artful-proposed) [1.20170301-1]
-queuebot:#ubuntu-release- New: accepted haskell-tidal [i386] (artful-proposed) [0.8.2-1]
-queuebot:#ubuntu-release- New: accepted libalgorithm-permute-perl [arm64] (artful-proposed) [0.14-1]
-queuebot:#ubuntu-release- New: accepted libalgorithm-permute-perl [s390x] (artful-proposed) [0.14-1]
-queuebot:#ubuntu-release- New: accepted xf86-input-multitouch [armhf] (artful-proposed) [1.0~rc3-1]
-queuebot:#ubuntu-release- New: accepted xf86-input-multitouch [s390x] (artful-proposed) [1.0~rc3-1]
-queuebot:#ubuntu-release- New: accepted github-backup [i386] (artful-proposed) [1.20170301-1]
-queuebot:#ubuntu-release- New: accepted libalgorithm-permute-perl [i386] (artful-proposed) [0.14-1]
-queuebot:#ubuntu-release- New: accepted xf86-input-multitouch [ppc64el] (artful-proposed) [1.0~rc3-1]
-queuebot:#ubuntu-release- New: accepted haskell-tidal [s390x] (artful-proposed) [0.8.2-1]
-queuebot:#ubuntu-release- New: accepted xf86-input-multitouch [amd64] (artful-proposed) [1.0~rc3-1]
<Laney> apw: slaying the linux tests again
<apw> Laney, so that didn't work ...
<LocutusOfBorg> slangasek, can we kick haskell-github [ppc64el], haskell-http-link-header [ppc64el] out? I'm going to open probably an RC in debian too
<LocutusOfBorg> hello, do you have any advice for a syncpackage -f perl?
<LocutusOfBorg> e.g. after python3.6 transition?
<LocutusOfBorg> also, if an archive admin can ack removal of openscenegraph, openscenegraph-3.4, osgearth all on armhf
<LocutusOfBorg> we don't have that egl stuff ready, and I really don't think such software can run on armhf
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (xenial-proposed/partner) [154.0.0-0ubuntu1~16.04.0 => 163.0.0-0ubuntu1~16.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (zesty-proposed/partner) [154.0.0-0ubuntu1~17.04.0 => 163.0.0-0ubuntu1~17.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: samba (zesty-proposed/main) [2:4.5.8+dfsg-0ubuntu0.17.04.4 => 2:4.5.8+dfsg-0ubuntu0.17.04.5] (core)
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (trusty-proposed/partner) [154.0.0-0ubuntu1~14.04.0 => 163.0.0-0ubuntu1~14.04.0] (no packageset)
<rbasak> chiluk: around? Reviewing intel-microcode.
<rbasak> In principle the change seems OK, but I'm confused by things mismatching the descriptions in debian/changelog
<rbasak> "source: remove unneeded intel-ucode/ directory" - removed from where? I don't see this in the current packages for Xenial nor in Zesty.
<rbasak> "source: remove superseded upstream data file: 20170511" - this is not true for Xenial. You remove other files instead.
<rbasak> Though if we're removing superseded files, why do some remain? Are we following a pattern of leaving old files there, or removing old files? I'm not sure I follow why your proposed SRUs appear to do both. Is there some nuance I'm missing?
<apw> rbasak, that is an xnox uploda isn't it ?
<xnox> rbasak, sounds like the changelog documents things relative what was done to the artful package to make this backport; rather than relative to what is changing relative xenial.
<xnox> and yes removing 20170511 makes sense (and not taking it) as it was fully superseeded by the 20170707 release.
<xnox> apw, thank you for the highlight.
<ginggs> would an archive admin please remove mathicgb s390x binaries from artful?  it only ever built there once because someone "fixed it" by disabling the tests :-/
<xnox> mwhudson, slangasek: demoting to proposed these three reproduciblebuilds/rebootstrappy debian native packages should make python3-defaults a valid candidate for migration. https://bugs.launchpad.net/debian/+source/botch/+bug/1706089
<ubot5> Ubuntu bug 1706089 in reprotest (Ubuntu) "FTBFS with new binutils; python3.6; demote to proposed until fixed" [Undecided,Confirmed]
<rbasak> xnox: did you sponsor these uploads? I'm not sure Launchpad will tell me until I accept.
<xnox> rbasak, i have not.
<xnox> simply making an observation / explanation.
<rbasak> OK, thanks.
<rbasak> I think that we need to describe the update from the perspective of what the user is receiving. A backport would include all the changelog entries in the middle but this does not. It should describe the diff being applied in the SRU, not anything else.
<bashfulrobot> hey guys, I'm wiuth the Ubuntu Budgie team, and I was hoping to Get a request off to get images spun up. I'm pretty new at this, so I'm sorry if I'm not following portocol.
<bashfulrobot> Also it was mentioned to me to also aske for volunteers for Nusakan...
-queuebot:#ubuntu-release- Packageset: Removed libxml-parser-perl from kubuntu in artful
-queuebot:#ubuntu-release- Packageset: Removed libxml-namespacesupport-perl from ubuntu-desktop in artful
-queuebot:#ubuntu-release- Packageset: Removed libxml-sax-base-perl from ubuntu-desktop in artful
-queuebot:#ubuntu-release- Packageset: Removed libxml-sax-perl from ubuntu-desktop in artful
-queuebot:#ubuntu-release- Packageset: Added libxml-libxml-perl to core in artful
-queuebot:#ubuntu-release- Packageset: Removed libxml-libxml-perl from ubuntu-desktop in artful
-queuebot:#ubuntu-release- Packageset: Removed libxml-sax-expat-perl from ubuntu-desktop in artful
-queuebot:#ubuntu-release- Packageset: Added libxml-namespacesupport-perl to core in artful
-queuebot:#ubuntu-release- Packageset: Added libxml-sax-base-perl to core in artful
-queuebot:#ubuntu-release- Packageset: Added libxml-sax-perl to core in artful
-queuebot:#ubuntu-release- Packageset: Added gcompris-qt to kubuntu in artful
-queuebot:#ubuntu-release- Packageset: Removed libxml-parser-perl from ubuntu-desktop in artful
-queuebot:#ubuntu-release- Packageset: Added libxml-parser-perl to core in artful
-queuebot:#ubuntu-release- Packageset: Added libxml-simple-perl to core in artful
-queuebot:#ubuntu-release- Packageset: Added golang-petname to kubuntu in artful
-queuebot:#ubuntu-release- Packageset: Added libgpod to kubuntu in artful
-queuebot:#ubuntu-release- Packageset: Added libmygpo-qt to kubuntu in artful
-queuebot:#ubuntu-release- Packageset: Removed libxml-simple-perl from ubuntu-desktop in artful
-queuebot:#ubuntu-release- Packageset: Added amarok to kubuntu in artful
-queuebot:#ubuntu-release- Packageset: Added liblastfm to kubuntu in artful
-queuebot:#ubuntu-release- Packageset: Added qtscriptgenerator to kubuntu in artful
-queuebot:#ubuntu-release- Packageset: Added libxml-sax-expat-perl to core in artful
-queuebot:#ubuntu-release- Packageset: Added loudmouth to kubuntu in artful
-queuebot:#ubuntu-release- Packageset: Added websocket-client to ubuntu-server in artful
-queuebot:#ubuntu-release- Packageset: Added python-zunclient to ubuntu-server in artful
<bashfulrobot> infinity and slangasek - it was suggested I tag you fine people. :-)
<bashfulrobot> (not pushing for a rush).
<mdeslaur> infinity: I just released xorg-server updates, and there's an xorg-server-hwe-16.04 in -proposed....can I upload over it to include the security fix? how do you want me to handle that?
<mdeslaur> I'm not sure what the SRU is waiting on
<tsimonq2> Archive Admins: I see bashfulrobot pinged earlier, but it would be great to get Alpha 2 out of the way this week. Could someone please set the archive block and spin up the images?
<tsimonq2> I see slangasek did Alpha 2 last release cycle, would you be interested in helping this cycle?
<bashfulrobot> Thanks tsimonq2.
<chiluk> rbasak xnox here... yes the changelog entry is there to match the artful changelog entry... As for the bins, I made the bins match what is available in the artful package without modifying the install or control scripts.
<chiluk> basically as this is such a black box to us, who are we to say that one bin is or is not superceded, so I just made it match what is in Artful.  In reality, I think we could probably remove some of the other firmwares.
<chiluk> I probably could have put a comment in the d/changelog saying something to the effect of below changelog matches changes from zesty... I also thought about pulling all the intermediary changelog entries in, or pulling nothing in...
<chiluk> I didn't want to go through and hand edit the intermediate changelog entries between 20151106 and 20170707 from debian...
<chiluk> I also didn't like the idea of adding those entries to the changelog for x when they were never released.
<chiluk> I guess my changelog entry would have been bettery served with the word sync instead of backport... so the resulting changelog entry would have read
<chiluk> "This is mostly a sync of the dat files from debian version 3.20170707.1
<chiluk> "
-queuebot:#ubuntu-release- Unapproved: ubiquity (xenial-proposed/main) [2.21.63.3 => 2.21.63.4] (core)
<slangasek> so why has borgbackup autopkgtest been triggered for python3-defaults when it had already passed?  and with no name associated with the triggering
<slangasek> xnox: is ubuntu-make not on your list for python3-defaults?
<slangasek> tsimonq2, bashfulrobot: I'm off work today and don't have time to look at this, sorry
<bashfulrobot> slangesak: thanks for the reply - understandable.
<mwhudson> slangasek: thanks
-queuebot:#ubuntu-release- New binary: ocaml-reins [amd64] (artful-proposed/universe) [0.1a-7] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-reins [armhf] (artful-proposed/universe) [0.1a-7] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-reins [ppc64el] (artful-proposed/universe) [0.1a-7] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-reins [arm64] (artful-proposed/universe) [0.1a-7] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-reins [s390x] (artful-proposed/universe) [0.1a-7] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-reins [i386] (artful-proposed/universe) [0.1a-7] (no packageset)
<mwhudson> slangasek: i think demoting ubuntu-make is reasonable but can also try to fix it today
<mwhudson> slangasek: oh, you need to remove botch too?
<bdmurray> stgraber: How can I fix the "LTS Desktop Upgrade (Trusty)" item here? http://iso.qa.ubuntu.com/qatracker/milestones/376/builds/152798/testcases
<bdmurray> I added test suite saying Xenial but I can't figure out how to replace the Trusty one with Xenial for Artful.
<bdmurray> I think testing upgrades from Trusty to Xenial is still useful so didn't just do a rename of Trusty to Xenial.
-queuebot:#ubuntu-release- Unapproved: update-manager (zesty-proposed/main) [1:17.04.4 => 1:17.04.5] (core)
<stgraber> bdmurray: http://iso.qa.ubuntu.com/admin/config/services/qatracker/products
<stgraber> bdmurray: then find the product you want to change and click the "linked testsuite" link. You can then remove the old testsuite for artful and add the new one.
<bdmurray> stgraber: got it thanks. I heard a rumor that you thought reordering the series with Artful before Zesty would be hard is that true?
<stgraber> bdmurray: shouldn't really be hard, ordering by id should do the trick. The hard part would likely be to get the code deployed. I don't remember what that involves since no change has landed in quite a while :)
#ubuntu-release 2017-07-25
<bdmurray> stgraber: Finally are the testcases supposed to be automatically imported?
<stgraber> bdmurray: auto-imported from where? so I guess the answer is no :)
<bdmurray> bzr+ssh://bazaar.launchpad.net/+branch/ubuntu-manual-tests/
<bdmurray> balloons: do you know anything about ubuntu-manual-tests and updating iso.qa.ubuntu.com?
<stgraber> hmm, I don't believe there's any code in the tracker which pulls from there. Maybe there's code that pushes those into the tracker somehow?
<bdmurray> stgraber: oh yeah, there's a qa_tracker_update.pl script in ubuntu-manual-tests
<bdmurray> which is broken of course
-queuebot:#ubuntu-release- Unapproved: update-manager (xenial-proposed/main) [1:16.04.7 => 1:16.04.8] (core)
-queuebot:#ubuntu-release- Unapproved: update-manager (trusty-proposed/main) [1:0.196.23 => 1:0.196.24] (core)
<balloons> bdmurray, stgraber, I believe they just duplicate the jobs in the tracker anymore. There was a python script at some point using the tracker api, but seems it's gone now
<balloons> if you need help editing / arranging, I certainly can help
<tsimonq2> slangasek: Ok.
<infinity> mdeslaur: Did you have xorg-server-hwe-16.04 1.19 fixes staged somewhere?
<infinity> mdeslaur: I was going to release that SRU Very Soon, but I certainly don't want to regress people who literally just got security updates 8 hours ago.
-queuebot:#ubuntu-release- New binary: yder [ppc64el] (artful-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-bgentry-go-netrc [amd64] (artful-proposed/none) [0.0~git20140422.0.9fd32a8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: yder [armhf] (artful-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-erikstmartin-go-testdb [amd64] (artful-proposed/none) [0.0~git20160219.0.8d10e4a-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-ssor-bom [amd64] (artful-proposed/none) [0.0~git20170718.0.6386211-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-pault-go-ykpiv [amd64] (artful-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: yder [s390x] (artful-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-pault-go-gecos [amd64] (artful-proposed/none) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: yder [arm64] (artful-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-yuin-gopher-lua [amd64] (artful-proposed/none) [0.0~git20170626.0.2243d71-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-is-object [amd64] (artful-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-agate [amd64] (artful-proposed/none) [1.6.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: yder [i386] (artful-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-crypto-browserify [amd64] (artful-proposed/none) [3.11.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: yder [amd64] (artful-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-path-browserify [amd64] (artful-proposed/none) [0.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fastnetmon [i386] (artful-proposed/none) [1.1.3+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-ultron [amd64] (artful-proposed/none) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-aiosmtpd [amd64] (artful-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fastnetmon [amd64] (artful-proposed/none) [1.1.3+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-reinterval [amd64] (artful-proposed/none) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-querystring-es3 [amd64] (artful-proposed/none) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Artful Alpha 2] (20170725) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Artful Alpha 2] (20170725) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Artful Alpha 2] (20170725) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Artful Alpha 2] (20170725) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Artful Alpha 2] (20170725) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Artful Alpha 2] (20170725) has been added
<ginggs> would an archive admin please remove mathicgb s390x binaries from artful?  it only ever built there once because someone "fixed it" by disabling the tests :-/
-queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop amd64 [Artful Alpha 2] (20170725) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop i386 [Artful Alpha 2] (20170725) has been added
<apw> ginggs, so they did, removed
<ginggs> apw: thanks!
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Artful Alpha 2] (20170725) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Artful Alpha 2] (20170725) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Artful Alpha 2] (20170725) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Artful Alpha 2] (20170725) has been added
<ginggs> apw: would you also please 'force-badtest mathicgb/1.0~git20170104-1ubuntu2/armhf' ? warnings on stderr - see https://wiki.ubuntu.com/GCC7
<apw> ginggs, do we no strategy other than ignoring the results ever single time
<ginggs> apw: if i understand correctly, warning only appeared in recent gcc 6 last month, and will disappear in gcc 7.1, so i wouldn't want to 'force-badtest mathicgb/all/armhf'
<apw> ginggs, ok done
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Artful Alpha 2] (20170725.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Artful Alpha 2] (20170725.1) has been added
-queuebot:#ubuntu-release- Unapproved: rejected intel-microcode [source] (xenial-proposed) [3.20170511.1~ubuntu16.04.0]
-queuebot:#ubuntu-release- Unapproved: rejected intel-microcode [source] (xenial-proposed) [3.20170707.1~ubuntu16.04.0]
-queuebot:#ubuntu-release- Unapproved: rejected intel-microcode [source] (zesty-proposed) [3.20170707.1~ubuntu17.04.0]
<ginggs> apw: thanks again
<jamespage> sil2100: morning - with regards to our discussion last week re openstack SRU's
<jamespage> sil2100: we already had something documented - https://wiki.ubuntu.com/OpenStack/StableReleaseUpdates
<jamespage> sil2100: would that be suitable to add to the 'special cases' list
<jamespage> ?
<jamespage> that would cover openstack packages, openvswitch and ceph
<jamespage> I can make that more explicit
<sil2100> jamespage: morning! Let me take a look :)
<jamespage> sil2100: thanks - just made the update to scope to OpenStack + Open vSwitch and Ceph
<sil2100> jamespage: let me get back to you in up to 30 minutes, need to finish up something first
<xnox> slangasek, ubuntu-make uploaded. demoting or bad-testing botch is the only remaining issue then. https://bugs.launchpad.net/ubuntu/+source/botch/+bug/1706089
<ubot5> Ubuntu bug 1706089 in botch (Ubuntu) "FTBFS with new binutils; python3.6; demote to proposed until fixed" [Undecided,Confirmed]
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-88.111~14.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-88.111~14.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-88.111] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-88.111]
-queuebot:#ubuntu-release- Unapproved: ubuntu-image (xenial-proposed/universe) [1.1+16.04ubuntu1 => 1.1+16.04ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ubuntu-image (zesty-proposed/universe) [1.1+17.04ubuntu1 => 1.1+17.04ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-facebookgo-grace [amd64] (artful-proposed/universe) [0.0~git20170218.0.4afe952-2] (no packageset)
-queuebot:#ubuntu-release- New binary: yder [amd64] (artful-proposed/universe) [1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: yder [armhf] (artful-proposed/universe) [1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: yder [ppc64el] (artful-proposed/universe) [1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-go-macaron-i18n [amd64] (artful-proposed/universe) [0.0~git20160612.0.ef57533-2] (no packageset)
-queuebot:#ubuntu-release- New binary: yder [i386] (artful-proposed/universe) [1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: yder [arm64] (artful-proposed/universe) [1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: yder [s390x] (artful-proposed/universe) [1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-zxcvbn [amd64] (artful-proposed/universe) [4.4.15-1] (no packageset)
<infinity> xnox: I demoted botch, but now I'm questioning that.  Is it the package that's broken or the test?
<infinity> xnox: Kinda looks like maybe the test is just silly.
<infinity> (Expecting exact output of data structure dumps)
<xnox> infinity, whilst true, i sorted & uniqufied the strings. Given a static dump of the archive, it determined different amount of dependency links in that case (found new ones, and is missing some).
<infinity> xnox: Curious.  Has anyone reported this in Debian?
<xnox> infinity, i do not know if botch detection algos are meant to be deterministic or not, given a static snapshot input. I would expect as much from a test suite.
<xnox> infinity, i have.
<infinity> Ahh, found it.
<infinity> Kay, I might just remove it wholesale, then.  Demoting won't really do the trick without a version bump to force a new test baseline.
-queuebot:#ubuntu-release- New: accepted fastnetmon [amd64] (artful-proposed) [1.1.3+dfsg-1]
-queuebot:#ubuntu-release- New: accepted golang-github-bgentry-go-netrc [amd64] (artful-proposed) [0.0~git20140422.0.9fd32a8-1]
-queuebot:#ubuntu-release- New: accepted golang-github-facebookgo-grace [amd64] (artful-proposed) [0.0~git20170218.0.4afe952-2]
-queuebot:#ubuntu-release- New: accepted golang-github-ssor-bom [amd64] (artful-proposed) [0.0~git20170718.0.6386211-1]
-queuebot:#ubuntu-release- New: accepted golang-pault-go-gecos [amd64] (artful-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted node-crypto-browserify [amd64] (artful-proposed) [3.11.0-1]
-queuebot:#ubuntu-release- New: accepted node-path-browserify [amd64] (artful-proposed) [0.0.0-1]
-queuebot:#ubuntu-release- New: accepted fastnetmon [i386] (artful-proposed) [1.1.3+dfsg-1]
-queuebot:#ubuntu-release- New: accepted golang-github-go-macaron-i18n [amd64] (artful-proposed) [0.0~git20160612.0.ef57533-2]
-queuebot:#ubuntu-release- New: accepted golang-pault-go-ykpiv [amd64] (artful-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted node-querystring-es3 [amd64] (artful-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-erikstmartin-go-testdb [amd64] (artful-proposed) [0.0~git20160219.0.8d10e4a-1]
-queuebot:#ubuntu-release- New: accepted node-is-object [amd64] (artful-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-yuin-gopher-lua [amd64] (artful-proposed) [0.0~git20170626.0.2243d71-1]
-queuebot:#ubuntu-release- New: accepted node-reinterval [amd64] (artful-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted ocaml-reins [amd64] (artful-proposed) [0.1a-7]
-queuebot:#ubuntu-release- New: accepted ocaml-reins [armhf] (artful-proposed) [0.1a-7]
-queuebot:#ubuntu-release- New: accepted ocaml-reins [ppc64el] (artful-proposed) [0.1a-7]
-queuebot:#ubuntu-release- New: accepted python-agate [amd64] (artful-proposed) [1.6.0-3]
-queuebot:#ubuntu-release- New: accepted python-zxcvbn [amd64] (artful-proposed) [4.4.15-1]
-queuebot:#ubuntu-release- New: accepted yder [arm64] (artful-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted yder [i386] (artful-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted yder [s390x] (artful-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted yder [arm64] (artful-proposed) [1.1-2]
-queuebot:#ubuntu-release- New: accepted node-ultron [amd64] (artful-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted ocaml-reins [i386] (artful-proposed) [0.1a-7]
-queuebot:#ubuntu-release- New: accepted python-aiosmtpd [amd64] (artful-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted yder [armhf] (artful-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted yder [amd64] (artful-proposed) [1.1-2]
-queuebot:#ubuntu-release- New: accepted yder [i386] (artful-proposed) [1.1-2]
-queuebot:#ubuntu-release- New: accepted ocaml-reins [arm64] (artful-proposed) [0.1a-7]
-queuebot:#ubuntu-release- New: accepted yder [amd64] (artful-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted yder [armhf] (artful-proposed) [1.1-2]
-queuebot:#ubuntu-release- New: accepted ocaml-reins [s390x] (artful-proposed) [0.1a-7]
-queuebot:#ubuntu-release- New: accepted yder [s390x] (artful-proposed) [1.1-2]
-queuebot:#ubuntu-release- New: accepted yder [ppc64el] (artful-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted yder [ppc64el] (artful-proposed) [1.1-2]
<smb> Laney, as a work-around until finding the issue behind bug 1706283, I have disabled running the breakpoints tests when running on artful. As the tests are pulled from git, this should be effective already. Could you trigger a manual run to verify its no longer causing loops?
<ubot5> bug 1706283 in linux (Ubuntu) "ADT tests fail since 4.11.0-11.16" [Undecided,Triaged] https://launchpad.net/bugs/1706283
<Laney> hey smb
<Laney> sure, lemme get that running now
<smb> cheers
<Laney> iz running
<Laney> smb: is it a sign that something is busted in the kernel though, or a bad test?
<smb> Laney, Well busted or changed in unexpected ways. We need to figure out what is causing this for sure. To disable the test is just a quick action to not loose all the other testing while investigating
<Laney> OK - just worried about promoting a kernel based on a skipped test if there's a real bug there.
<Laney> I guess you have the blocking bug(s) though
<smb> I would not close the bug and talk with Seth and/or Andy later. And I would not close the bug report you opened
-queuebot:#ubuntu-release- Unapproved: open-iscsi (xenial-proposed/main) [2.0.873+git0.3b4b4500-14ubuntu3.3 => 2.0.873+git0.3b4b4500-14ubuntu3.4] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: open-iscsi (zesty-proposed/main) [2.0.873+git0.3b4b4500-14ubuntu17 => 2.0.873+git0.3b4b4500-14ubuntu18] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: xorg-server-hwe-16.04 (xenial-proposed/main) [2:1.19.3-1ubuntu1~16.04.1 => 2:1.19.3-1ubuntu1~16.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted xorg-server-hwe-16.04 [source] (xenial-proposed) [2:1.19.3-1ubuntu1~16.04.2]
<LocutusOfBorg> ^^ does this mean we have to retest everything hwe related?
<LocutusOfBorg> mmh just CVE fixes, probably not I hope
<infinity> LocutusOfBorg: Would be nice if somoene could test that the built binaries are still an Xserver and still start a session, but no, no need to do deep testing of the stack.
<LocutusOfBorg> ack
<infinity> LocutusOfBorg: If you still have an env for that from your vbox testing, I wouldn't mind. :)
<LocutusOfBorg> I have it :)
<infinity> LocutusOfBorg: \o/
<infinity> LocutusOfBorg: So yeah, if you can dist-upgrade to the new version when it builds/publishes and just lemme know that it still sucks the same amount as the previous version, that would be great.
<LocutusOfBorg> after all my daily bothering, the minimum I can do is test something back <3
<LocutusOfBorg> infinity, it starts
-queuebot:#ubuntu-release- Unapproved: kmod (xenial-proposed/main) [22-1ubuntu4 => 22-1ubuntu5] (core)
-queuebot:#ubuntu-release- Unapproved: accepted kmod [source] (xenial-proposed) [22-1ubuntu5]
-queuebot:#ubuntu-release- Unapproved: squid3 (xenial-proposed/main) [3.5.12-1ubuntu7.3 => 3.5.12-1ubuntu7.4] (ubuntu-server)
-queuebot:#ubuntu-release- New sync: diffoscope (artful-proposed/primary) [84]
<slangasek> tsimonq2, bashfulrobot: FYI I have not frozen the archive for the alpha2 milestone; we have the python3.6 transition (python3-defaults) about ready to land, which will not affect installability of artful (as is the norm) but will impact image builds
-queuebot:#ubuntu-release- New: accepted diffoscope [sync] (artful-proposed) [84]
-queuebot:#ubuntu-release- Unapproved: aodh (zesty-proposed/main) [4.0.0-0ubuntu2 => 4.0.1-0ubuntu0.17.04.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cinder (zesty-proposed/main) [2:10.0.2-0ubuntu1 => 2:10.0.4-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ceilometer (zesty-proposed/main) [1:8.0.1-0ubuntu2 => 1:8.0.2-0ubuntu0.17.04.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: heat (zesty-proposed/main) [1:8.0.1-0ubuntu1 => 1:8.0.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: horizon (zesty-proposed/main) [3:11.0.2-0ubuntu1 => 3:11.0.3-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron-lbaas (zesty-proposed/universe) [2:10.0.0-0ubuntu2 => 2:10.0.1-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: nova (zesty-proposed/main) [2:15.0.5-0ubuntu1 => 2:15.0.6-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron-fwaas (zesty-proposed/main) [1:10.0.0-0ubuntu2 => 1:10.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron (zesty-proposed/main) [2:10.0.2-0ubuntu1 => 2:10.0.2-0ubuntu1.1] (openstack, ubuntu-server)
<xnox> slangasek, well, based on output, it seems like we still have things to fix before python3-defaults will go in, no?
<xnox> i see autohinter trying to migrate a bunch of stuff and printing things to fix.
<infinity> xnox: Hopefully that's because some things were blocked and/or not migrating for other reasons, rather than things that need fixing.
<xnox> infinity, well due to https://github.com/donnemartin/gitsome/issues/105#issuecomment-286078468 gitsome hardcodes python3.4 or 3.5; it doesn't support 3.5
<xnox> leaf package, should be demoted. I guess i should file a bug.
-queuebot:#ubuntu-release- Unapproved: intel-microcode (xenial-proposed/restricted) [3.20151106.1 => 3.20170707.1~ubuntu16.04.0] (ubuntu-desktop, ubuntu-server)
<xnox> https://bugs.launchpad.net/ubuntu/+source/gitsome/+bug/1706387
<ubot5> Ubuntu bug 1706387 in gitsome (Ubuntu) "FTBFS on python3.6 / doesn't support python3.6" [Undecided,New]
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Artful Alpha 2] has been updated (20170725.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Artful Alpha 2] has been updated (20170725.1)
-queuebot:#ubuntu-release- Unapproved: intel-microcode (zesty-proposed/restricted) [3.20170511.1~ubuntu17.04.0 => 3.20170707.1~ubuntu17.04.0] (ubuntu-desktop, ubuntu-server)
<xnox> there is libsane migration
<xnox> postgresql-multicorn (1.3.3-1 to 1.3.3-2build1) fails tests.
<chiluk> rbasak, I incorporated your review comments, and re-uploaded intel-microcode... thanks for taking a look at that btw.
<LocutusOfBorg> xnox, is sane blocked by something?
<rbasak> chiluk: will look. Thanks!
<xnox> hm, possibly by libsane-perl somehow.
<LocutusOfBorg> condor is RC buggy in debian  #868905
<ubot5> Debian bug 868905 in src:condor "condor: FTBFS: ld: final link failed: Bad value" [Serious,Open] http://bugs.debian.org/868905
<LocutusOfBorg> demoting in proposed would be appreciated
<xnox> as it is trying python3-default with sane migration in one go.
<xnox> yes libsane-perl is insane
<xnox>  Depends: libc6 (>= 2.4), libsane1 (>= 1.0.24), perl (>= 5.24.1-7ubuntu1), perlapi-5.24.1, libsane (>= 1.0.19)
<xnox> how you depend on both ABIs?!
<xnox> unless it is normal to depend on both libsane1 and libsane
<LocutusOfBorg> probably it picked up both because it has been rebuilt with a wrong timing
<xnox> ok fixed.
<xnox> LocutusOfBorg, nah, it had an explicit dep for no reason onto the old one.
<xnox> also uploaded multicorn
<xnox> and something is going on with the whole of kopanocore
<LocutusOfBorg> thanks xnox
<LocutusOfBorg> I think also gdal needs to go with sane, right?
<LocutusOfBorg> opencv depends on both gdal and python-defaults
<slangasek> xnox: yes, and freezing the archive while we sort through those things would handicap us from working on it
<slangasek> LocutusOfBorg: hi, if you want packages removed from the archive (e.g. osgearth) and you're not going to be on IRC to discuss it, please file bugs so there's somewhere we have an opportunity to discuss
<slangasek> I have not removed the armhf binaries because I do not agree with the conclusion that these "can't work on armhf".  If it works with EGL, we have hw-accelerated EGL drivers on armhf.  If it doesn't work with EGL because it needs non-EGL APIs and hasn't been ported, that's another matter
<slangasek> hahaha
<slangasek> fail
<slangasek> also fail: everything about cmake's output when there's a build failure
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Artful Alpha 2] has been updated (20170725.1)
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Artful Alpha 2] has been updated (20170725.1)
-queuebot:#ubuntu-release- Unapproved: neutron (xenial-proposed/main) [2:8.4.0-0ubuntu3 => 2:8.4.0-0ubuntu4] (openstack, ubuntu-server)
<xnox> infinity, trying to fix kopanocore thing. am reminded how much i hate c++
-queuebot:#ubuntu-release- New binary: golang-github-gin-contrib-sse [amd64] (artful-proposed/universe) [0.0~git20170109.0.22d885f-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gopkg-go-playground-assert.v1 [amd64] (artful-proposed/universe) [1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: silversearcher-ag-el [amd64] (artful-proposed/universe) [0.47-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-olekukonko-ts [amd64] (artful-proposed/universe) [0.0~git20140412.0.ecf753e-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-commist [amd64] (artful-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-rubyist-tracerx [amd64] (artful-proposed/universe) [0.0~git20150602.0.d7bcc0b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-pault-go-technicolor [amd64] (artful-proposed/universe) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-thomsonreuterseikon-go-ntlm [amd64] (artful-proposed/universe) [0.0~git20151030.0.b00ec39-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-proto-list [amd64] (artful-proposed/universe) [1.2.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pybtex [amd64] (artful-proposed/universe) [0.21-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tagpy [ppc64el] (artful-proposed/universe) [2013.1-6] (no packageset)
-queuebot:#ubuntu-release- New binary: node-help-me [amd64] (artful-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-pumpify [amd64] (artful-proposed/universe) [1.3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-mqtt-packet [amd64] (artful-proposed/universe) [5.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tagpy [s390x] (artful-proposed/universe) [2013.1-6] (no packageset)
-queuebot:#ubuntu-release- New binary: swi-prolog [ppc64el] (artful-proposed/universe) [7.4.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tagpy [i386] (artful-proposed/universe) [2013.1-6] (no packageset)
-queuebot:#ubuntu-release- New binary: swi-prolog [s390x] (artful-proposed/universe) [7.4.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: swi-prolog [i386] (artful-proposed/universe) [7.4.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: byte-buddy [amd64] (artful-proposed/universe) [1.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tagpy [amd64] (artful-proposed/universe) [2013.1-6] (no packageset)
<tsimonq2> slangasek: ack
-queuebot:#ubuntu-release- New binary: swi-prolog [amd64] (artful-proposed/universe) [7.4.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tagpy [armhf] (artful-proposed/universe) [2013.1-6] (no packageset)
-queuebot:#ubuntu-release- New binary: gecode [s390x] (artful-proposed/universe) [5.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tagpy [arm64] (artful-proposed/universe) [2013.1-6] (no packageset)
-queuebot:#ubuntu-release- New binary: swi-prolog [armhf] (artful-proposed/universe) [7.4.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: swi-prolog [arm64] (artful-proposed/universe) [7.4.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted byte-buddy [amd64] (artful-proposed) [1.7.1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-gin-contrib-sse [amd64] (artful-proposed) [0.0~git20170109.0.22d885f-1]
-queuebot:#ubuntu-release- New: accepted golang-github-rubyist-tracerx [amd64] (artful-proposed) [0.0~git20150602.0.d7bcc0b-1]
-queuebot:#ubuntu-release- New: accepted golang-gopkg-go-playground-assert.v1 [amd64] (artful-proposed) [1.2.1-1]
-queuebot:#ubuntu-release- New: accepted node-commist [amd64] (artful-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted node-mqtt-packet [amd64] (artful-proposed) [5.4.0-1]
-queuebot:#ubuntu-release- New: accepted node-pumpify [amd64] (artful-proposed) [1.3.5-1]
-queuebot:#ubuntu-release- New: accepted silversearcher-ag-el [amd64] (artful-proposed) [0.47-2]
-queuebot:#ubuntu-release- New: accepted gecode [s390x] (artful-proposed) [5.1.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-thomsonreuterseikon-go-ntlm [amd64] (artful-proposed) [0.0~git20151030.0.b00ec39-1]
-queuebot:#ubuntu-release- New: accepted node-help-me [amd64] (artful-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted pybtex [amd64] (artful-proposed) [0.21-1]
-queuebot:#ubuntu-release- New: accepted golang-github-olekukonko-ts [amd64] (artful-proposed) [0.0~git20140412.0.ecf753e-1]
-queuebot:#ubuntu-release- New: accepted node-proto-list [amd64] (artful-proposed) [1.2.4-1]
-queuebot:#ubuntu-release- New: accepted golang-pault-go-technicolor [amd64] (artful-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted swi-prolog [amd64] (artful-proposed) [7.4.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted swi-prolog [i386] (artful-proposed) [7.4.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted swi-prolog [s390x] (artful-proposed) [7.4.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted tagpy [arm64] (artful-proposed) [2013.1-6]
-queuebot:#ubuntu-release- New: accepted tagpy [i386] (artful-proposed) [2013.1-6]
-queuebot:#ubuntu-release- New: accepted tagpy [s390x] (artful-proposed) [2013.1-6]
-queuebot:#ubuntu-release- New: accepted swi-prolog [armhf] (artful-proposed) [7.4.2+dfsg-1]
<sil2100> jamespage: hey! The doc looks goodish, we might consider doing some small changes here and there but I guess it's goot for a MRE - but let me take care of it formally tomorrow
-queuebot:#ubuntu-release- New: accepted tagpy [amd64] (artful-proposed) [2013.1-6]
-queuebot:#ubuntu-release- New: accepted tagpy [ppc64el] (artful-proposed) [2013.1-6]
-queuebot:#ubuntu-release- New: accepted swi-prolog [ppc64el] (artful-proposed) [7.4.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted tagpy [armhf] (artful-proposed) [2013.1-6]
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Artful Alpha 2] has been updated (20170725.1)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Artful Alpha 2] has been updated (20170725.1)
-queuebot:#ubuntu-release- New binary: gecode [i386] (artful-proposed/universe) [5.1.0-1] (no packageset)
<xnox> uploaded kopanocore, the python3-defaults migration should get better after that.
<xnox> will see what to fix next after that.
<xnox> mwhudson, infinity ^^^^
<flexiondotorg> tsimonq2 Did you request those re-spins or is the world be remade?
 * xnox pub o'clock
<slangasek> ftr the openscenegraph build failure (which blocks osgearth->gdal->python3-defaults) is a straightforward mis-detection of libGLES at build time, there is no fundamental portability issue here, only bugs
<slangasek> as for fixing those bugs, I'm sure I won't hate anything about trying to diagnose the cmake problem
-queuebot:#ubuntu-release- New: accepted gecode [i386] (artful-proposed) [5.1.0-1]
-queuebot:#ubuntu-release- New: accepted swi-prolog [arm64] (artful-proposed) [7.4.2+dfsg-1]
<slangasek> openscenegraph uploaded
<balloons> Can someone act on bug 1669507 and remove juju-core from artful?
<ubot5> bug 1669507 in juju-core (Ubuntu) "Remove juju-core from artful" [Undecided,New] https://launchpad.net/bugs/1669507
<mdeslaur> jdstrand: can you remove that? ^
<rbasak> ^ \o/
-queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop amd64 [Artful Alpha 2] has been updated (20170725.1)
-queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop i386 [Artful Alpha 2] has been updated (20170725.1)
-queuebot:#ubuntu-release- Unapproved: whoopsie (zesty-proposed/main) [0.2.55.1 => 0.2.55.2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: whoopsie (xenial-proposed/main) [0.2.52.4 => 0.2.52.5] (kubuntu, ubuntu-desktop)
<tsimonq2> flexiondotorg: I think that was slangasek. Wasn't me.
<tsimonq2> (would be logical as he was saying something about Python)
<slangasek> tsimonq2: I haven't requested any respins
<slangasek> tsimonq2: OTOH I also didn't freeze the crontab
<slangasek> I can do that now
<tsimonq2> slangasek: That would make sense, thanks.
-queuebot:#ubuntu-release- Unapproved: samba (zesty-proposed/main) [2:4.5.8+dfsg-0ubuntu0.17.04.4 => 2:4.5.8+dfsg-0ubuntu0.17.04.5] (core)
-queuebot:#ubuntu-release- Unapproved: rejected samba [source] (zesty-proposed) [2:4.5.8+dfsg-0ubuntu0.17.04.5]
-queuebot:#ubuntu-release- New binary: hoel [ppc64el] (artful-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hoel [amd64] (artful-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hoel [armhf] (artful-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hoel [s390x] (artful-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hoel [arm64] (artful-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hoel [i386] (artful-proposed/none) [1.1-1] (no packageset)
#ubuntu-release 2017-07-26
-queuebot:#ubuntu-release- Unapproved: keystone (xenial-proposed/main) [2:9.3.0-0ubuntu2 => 2:9.3.0-0ubuntu3] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: nova (xenial-proposed/main) [2:13.1.4-0ubuntu1 => 2:13.1.4-0ubuntu2] (openstack, ubuntu-server)
<LocutusOfBorg> slangasek, I was not saying sagemath can't build on armhf, but "nobody with an armhf processor will likely run sagemath, due to performances" :)
<LocutusOfBorg> but thanks for fixing, I tried hard to understand that cmake failure and I failed, even in a chroot
-queuebot:#ubuntu-release- New binary: diffoscope [amd64] (artful-proposed/universe) [84build1] (no packageset)
<LocutusOfBorg> welcome back fixed diffoscope :)
<xnox> /o\
<ginggs> LocutusOfBorg: Wolfram expect people to run Mathematica on a Raspberry Pi
<LocutusOfBorg> wow
<LocutusOfBorg> I still don't undestand that EGL delta between debian and Ubuntu
<ginggs> LocutusOfBorg: neither do i, it affects some games too
-queuebot:#ubuntu-release- New binary: notmuch [ppc64el] (artful-proposed/main) [0.25~rc1-2] (core)
-queuebot:#ubuntu-release- New binary: notmuch [s390x] (artful-proposed/main) [0.25~rc1-2] (core)
-queuebot:#ubuntu-release- New binary: notmuch [amd64] (artful-proposed/main) [0.25~rc1-2] (core)
-queuebot:#ubuntu-release- New binary: notmuch [i386] (artful-proposed/main) [0.25~rc1-2] (core)
-queuebot:#ubuntu-release- New binary: notmuch [arm64] (artful-proposed/main) [0.25~rc1-2] (core)
-queuebot:#ubuntu-release- New binary: notmuch [i386] (artful-proposed/main) [0.25~rc1-2ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: notmuch [amd64] (artful-proposed/main) [0.25~rc1-2ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: notmuch [ppc64el] (artful-proposed/main) [0.25~rc1-2ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: notmuch [armhf] (artful-proposed/main) [0.25~rc1-2ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: notmuch [arm64] (artful-proposed/main) [0.25~rc1-2ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: notmuch [s390x] (artful-proposed/main) [0.25~rc1-2ubuntu1] (core)
-queuebot:#ubuntu-release- New: accepted diffoscope [amd64] (artful-proposed) [84build1]
-queuebot:#ubuntu-release- New: accepted hoel [arm64] (artful-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted hoel [i386] (artful-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted hoel [s390x] (artful-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted notmuch [arm64] (artful-proposed) [0.25~rc1-2]
-queuebot:#ubuntu-release- New: accepted notmuch [ppc64el] (artful-proposed) [0.25~rc1-2]
-queuebot:#ubuntu-release- New: accepted notmuch [amd64] (artful-proposed) [0.25~rc1-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted notmuch [armhf] (artful-proposed) [0.25~rc1-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted notmuch [ppc64el] (artful-proposed) [0.25~rc1-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted hoel [amd64] (artful-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted hoel [ppc64el] (artful-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted notmuch [i386] (artful-proposed) [0.25~rc1-2]
-queuebot:#ubuntu-release- New: accepted notmuch [arm64] (artful-proposed) [0.25~rc1-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted notmuch [s390x] (artful-proposed) [0.25~rc1-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted hoel [armhf] (artful-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted notmuch [s390x] (artful-proposed) [0.25~rc1-2]
-queuebot:#ubuntu-release- New: accepted notmuch [amd64] (artful-proposed) [0.25~rc1-2]
-queuebot:#ubuntu-release- New: accepted notmuch [i386] (artful-proposed) [0.25~rc1-2ubuntu1]
-queuebot:#ubuntu-release- New binary: golang-github-ngaut-go-zookeeper [amd64] (artful-proposed/universe) [0.0~git20150813.0.9c3719e-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-github-ngaut-go-zookeeper [amd64] (artful-proposed) [0.0~git20150813.0.9c3719e-2]
<sil2100> jamespage: hey! Question regarding new openstack stable point-releases - do those generally only have bugfixes, or enable new features as well?
<LocutusOfBorg> any opinion against a debhelper upload?
<LocutusOfBorg> I tried some builds and it seems fine
<sil2100> jamespage: ok, so I took the document you have provided to me, trimmed it down to a more condensed format and added a proposed SRU template - could you take a look, correct and say if it's ok from your POV?
<sil2100> jamespage: https://wiki.ubuntu.com/OpenStackUpdates
<sil2100> The template is not required usually, but I guess it'd be nice for SRU people to get instant info about what's up
 * LocutusOfBorg uploads in some minutes
<sil2100> jamespage: I was also thinking if maybe you could add some nicely-worded rationale of why keeping openstack up-to-date is important - it *obviously* is but yeah, a nice sentence summing it up might be a nice decoration
<sil2100> In the first section, the overview of the wikipage
 * jamespage looks
<sil2100> jamespage: it's your doc just cut down ;)
<jamespage> I like the template
<rbasak> sil2100: are you doing this in response to my email, or something else?
<rbasak> To be clear, I only think that something like what I did for GNOME is needed if (and only if) the changes do not comply with the requirements at https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases
<rbasak> I'm under the impression that the openstack microrelase updates exceed our QA expectations there.
<rbasak> Though perhaps the autopkgtest requirement could be relaxed to "autopkgtest _or_ an Ubuntu team performs equivalent CI" as autopkgtest doesn't really make sense for openstack and wouldn't be sufficient anyway.
<sil2100> rbasak: no, not really in response to the e-mail, just as part of good practice - we started the discussion about this a bit earlier
<rbasak> Well I certainly have no objection to documenting more stuff :)
<sil2100> Documentation of such cases is good as it allows new members that didn't handle reviews of such updates before not wasting time looking through previous uploads, how the microreleases are being tested etc.
<rbasak> Agreed. As long as you don't think that I was suggesting it was required here :)
<rbasak> But yeah, for all the reasons you said, it's a good thing anywa.
-queuebot:#ubuntu-release- Unapproved: accepted squid3 [source] (xenial-proposed) [3.5.12-1ubuntu7.4]
-queuebot:#ubuntu-release- Unapproved: accepted open-iscsi [source] (xenial-proposed) [2.0.873+git0.3b4b4500-14ubuntu3.4]
<sil2100> slashd: hey!
<sil2100> slashd: I was just about to approve open-iscsi for zesty but then I'm a bit worried about the version number - since because you bumped it normally without the .1 notation, in case someone drops the open-iscsi that's currently in artful-proposed and decides to leave the last version, zesty will have a higher version number than artful
<sil2100> slashd: can you make sure that the artful-proposed version migrates and is not dropped?
<sil2100> slashd: not to block on that considering that I already accepted xenial, I'll change the version and re-upload
-queuebot:#ubuntu-release- Unapproved: rejected open-iscsi [source] (zesty-proposed) [2.0.873+git0.3b4b4500-14ubuntu18]
<apw> sil2100, good call
-queuebot:#ubuntu-release- Unapproved: open-iscsi (zesty-proposed/main) [2.0.873+git0.3b4b4500-14ubuntu17 => 2.0.873+git0.3b4b4500-14ubuntu17.1] (ubuntu-desktop, ubuntu-server)
<slashd> sil2100, It's block by a MIR --> https://bugs.launchpad.net/ubuntu/+source/open-isns/+bug/1689963
<ubot5> Ubuntu bug 1689963 in open-isns (Ubuntu) "[MIR] open-isns" [Undecided,Fix released]
<slashd> infinity, was okay with us uploading open-iscsi in artful knowing that fact
<slashd> sil2100, ^
<sil2100> Ah, ok, anyway, better safe than sorry
<slashd> sil2100, does that unblock you ?
<apw> slashd, that MIR is approved and implmented
<sil2100> I already changed the version number, will accept it anyway ;)
<sil2100> (approved)
<slashd> sil2100, much appreciated
<slashd> apw, I didn't look the status of the MIR recently
<slashd> apw, thanks
-queuebot:#ubuntu-release- Unapproved: accepted open-iscsi [source] (zesty-proposed) [2.0.873+git0.3b4b4500-14ubuntu17.1]
<apw> slashd, it looks to be held for failurs in its own test suite
<sil2100> Yeah, re-ran those
<sil2100> I mean, I recycled them some minutes ago to make sure they're not anything transient
<nacc> right, it's something real
<nacc> it's on my radar, but was at a sprint last week
<sil2100> ACK
<apw> sil2100, even more sensible to change the number to 17.1
<bdmurray> arges: Could you look at releasing the SRUs for bug 1700829 (u-r-u and u-m)?
<ubot5> bug 1700829 in update-manager (Ubuntu Zesty) "-d switch isn't accurately described" [High,Fix committed] https://launchpad.net/bugs/1700829
<LocutusOfBorg> (perl transition starting in some hours/minutes)
-queuebot:#ubuntu-release- New source: ubuntu-advantage-tools (trusty-proposed/primary) [2]
<nacc> could someone reject the above? I will reupload with a bug reference.
<apw> nacc, u-a-tools ?
<apw> nacc, gone
<nacc> apw: thanks
-queuebot:#ubuntu-release- New: rejected ubuntu-advantage-tools [source] (trusty-proposed) [2]
<apw> nacc, you know i am going to ask why that is not in artful etc, hopefully that is detailed in the bug
<nacc> apw: it is, sort of :)
<nacc> apw: it's going to be uploaded to trusty and copied forward
<nacc> apw: i think that's the last few comments; hopefully makes it a bit clearer
<nacc> dpb1: --^ i think it'd be good to put that in the top level comemnt
<apw> nacc, it is going to be copied forwards ... that is rather unusual
<apw> i assume soeone has signed off on that
<dpb1> nacc: OK
<dpb1> nacc: will update now
 * apw will wait for the new upload, so he can find the bug number to read those
<nacc> apw: yeah, it has been
<nacc> apw: and agree, it's unusual :)
<dpb1> nacc: updated the bug
<nacc> dpb1: thanks
-queuebot:#ubuntu-release- New binary: slurm-llnl [s390x] (artful-proposed/universe) [17.02.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: slurm-llnl [ppc64el] (artful-proposed/universe) [17.02.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: slurm-llnl [arm64] (artful-proposed/universe) [17.02.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: slurm-llnl [armhf] (artful-proposed/universe) [17.02.6-1] (no packageset)
<slangasek> apw: yeah, I signed off on it, because it's a shellscript-only package that we don't care about rebuilding for each release
-queuebot:#ubuntu-release- New source: ubuntu-advantage-tools (trusty-proposed/primary) [2]
-queuebot:#ubuntu-release- New binary: perl [s390x] (artful-proposed/main) [5.26.0-4] (core)
-queuebot:#ubuntu-release- New binary: perl [ppc64el] (artful-proposed/main) [5.26.0-4] (core)
<infinity> LocutusOfBorg: *poke*
-queuebot:#ubuntu-release- New binary: slurm-llnl [i386] (artful-proposed/universe) [17.02.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: slurm-llnl [amd64] (artful-proposed/universe) [17.02.6-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted slurm-llnl [amd64] (artful-proposed) [17.02.6-1]
-queuebot:#ubuntu-release- New: accepted slurm-llnl [armhf] (artful-proposed) [17.02.6-1]
-queuebot:#ubuntu-release- New: accepted slurm-llnl [ppc64el] (artful-proposed) [17.02.6-1]
-queuebot:#ubuntu-release- New: accepted slurm-llnl [arm64] (artful-proposed) [17.02.6-1]
-queuebot:#ubuntu-release- New: accepted slurm-llnl [s390x] (artful-proposed) [17.02.6-1]
-queuebot:#ubuntu-release- New: accepted slurm-llnl [i386] (artful-proposed) [17.02.6-1]
<slangasek> LocutusOfBorg, ginggs: the EGL delta is because no one really has hardware with hw-accelerated OpenGL drivers; but Debian also doesn't ship any of the non-free EGL drivers so has mostly not bothered with this
-queuebot:#ubuntu-release- New binary: perl [armhf] (artful-proposed/main) [5.26.0-4] (core)
-queuebot:#ubuntu-release- New binary: perl [arm64] (artful-proposed/main) [5.26.0-4] (core)
-queuebot:#ubuntu-release- New binary: perl [i386] (artful-proposed/main) [5.26.0-4] (core)
<ginggs> slangasek: thanks, so which packages in ubuntu have the EGL delta?
<slangasek> as many of them as possible ;)
<slangasek> or rather, as many as don't pick up EGL support automatically via Debian
<ginggs> i mean which package(s) in ubuntu provide the EGL support?
-queuebot:#ubuntu-release- New binary: perl [amd64] (artful-proposed/main) [5.26.0-4] (core)
<infinity> ginggs: If you mean "which drivers ship EGL acceleration", I'm not sure we currently ship any in the distro.  We have done in the past (like pvr-omap4)
<slangasek> right, it's possible we don't have any in the current series
<slangasek> the phones had them
<infinity> ginggs: If you mean "which userspace components assume EGL and cause a cascading ripple effect", the most obvious offender is Qt.
<infinity> Which, IMO, is a Qt bug.  There are other layers like cogl that manage to transparently support both.
<ginggs> infinity: the latter, yes
<infinity> But it's a bug/misfeature we've had to live with for ages.
<slangasek> also, moving to OpenGLv3 is meant to bridge the GL vs. EGL gap, so we can look forward to a distant future where we don't have differing sets of drivers
<infinity> slangasek: I'm not convinced that master plan will ever come to fruition, with Vulkan being the new hotness there instead.
<infinity> slangasek: But yes, "some day", we can stop making the distinction, somehow.  Maybe.  Ish.
<infinity> Oh look, all the perl builds rolled in while this was going on.
 * infinity crosses his fingers and accepts.
<ginggs> now I'm wondering whether the Raspberry Pi has GL or EGL drivers. I think the Nvida Jetson would have been full GL
-queuebot:#ubuntu-release- New: accepted perl [amd64] (artful-proposed) [5.26.0-4]
-queuebot:#ubuntu-release- New: accepted perl [armhf] (artful-proposed) [5.26.0-4]
-queuebot:#ubuntu-release- New: accepted perl [ppc64el] (artful-proposed) [5.26.0-4]
-queuebot:#ubuntu-release- New: accepted perl [arm64] (artful-proposed) [5.26.0-4]
-queuebot:#ubuntu-release- New: accepted perl [s390x] (artful-proposed) [5.26.0-4]
-queuebot:#ubuntu-release- New: accepted perl [i386] (artful-proposed) [5.26.0-4]
<infinity> ginggs: Pi/Pi2/Pi3 is EGL.  Most nvidia ARM boards are EGL.
<infinity> ginggs: It's true that nvidia ARM parts have GeForce-ish GPUs and *could* ship full OpenGL ICDs, but they don't.
<infinity> It's not really about what the hardware supports (you could go full GL on Mali too), it's what the ecosystem demands from their software stack.
<infinity> So it's a nasty feedback loop of "it ain't gonna change until the specs converge".
<infinity> As it stands, most modern "EGL" GPUs support all the extensions required for GL and, similarly, the major modern "GL" GPUs support the EGL extensions that aren't part of older GL specs.
<infinity> So, if heads were removed from various orifices, convergence could just happen, and no one would care.
<infinity> (Then you get to the fun where if you want to support older binaries, you need a libEGL.so shim that calls into libGL, but that's really trivial after all the committees and specs are dealt with)
<ginggs> ah,freemat is a typical example of the armhf EGL failures - "error: conflicting declaration âtypedef double GLdoubleâ" - and yes, it is built with Qt
<apw> slangasek, thanks for the background
<LocutusOfBorg> slangasek, thanks
<LocutusOfBorg> infinity, <3
<LocutusOfBorg> btw, is cmake-extras droppable now that the phone stuff is dying? reverse-depends -r artful src:cmake-extras shows nothing
<slangasek> perhaps; please file a bug against the package and subscribe ubuntu-archive
-queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop amd64 [Artful Alpha 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop i386 [Artful Alpha 2] has been marked as ready
<LocutusOfBorg> slangasek, I prefer to prod xnox once the list of stuff to remove gets filled in
<LocutusOfBorg> I won't forget, because each new cmake release I have to rebuild it :)
<LocutusOfBorg> I think there already is some sort of list
-queuebot:#ubuntu-release- New source: statistics (artful-proposed/primary) [1.0-0ubuntu1]
<arges> bdmurray: done
<bdmurray> arges: cool, thanks!
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Artful Alpha 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Artful Alpha 2] has been marked as ready
-queuebot:#ubuntu-release- New binary: libwebp [ppc64el] (artful-proposed/main) [0.6.0-3] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: libwebp [amd64] (artful-proposed/main) [0.6.0-3] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: libwebp [s390x] (artful-proposed/main) [0.6.0-3] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: libwebp [i386] (artful-proposed/main) [0.6.0-3] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: libwebp [arm64] (artful-proposed/main) [0.6.0-3] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: libwebp [armhf] (artful-proposed/main) [0.6.0-3] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: python-transitions [amd64] (artful-proposed/universe) [0.5.3-1] (no packageset)
#ubuntu-release 2017-07-27
-queuebot:#ubuntu-release- New: accepted libwebp [amd64] (artful-proposed) [0.6.0-3]
-queuebot:#ubuntu-release- New: accepted libwebp [armhf] (artful-proposed) [0.6.0-3]
-queuebot:#ubuntu-release- New: accepted libwebp [ppc64el] (artful-proposed) [0.6.0-3]
-queuebot:#ubuntu-release- New: accepted python-transitions [amd64] (artful-proposed) [0.5.3-1]
-queuebot:#ubuntu-release- New: accepted libwebp [arm64] (artful-proposed) [0.6.0-3]
-queuebot:#ubuntu-release- New: accepted libwebp [s390x] (artful-proposed) [0.6.0-3]
-queuebot:#ubuntu-release- New: accepted libwebp [i386] (artful-proposed) [0.6.0-3]
-queuebot:#ubuntu-release- New binary: golang-github-kurin-blazer [amd64] (artful-proposed/none) [0.0~git20170711.0.612082e-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-agate-dbf [amd64] (artful-proposed/none) [0.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-agate-sql [amd64] (artful-proposed/none) [0.5.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-agate-excel [amd64] (artful-proposed/none) [0.2.1-3] (no packageset)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Artful Alpha 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Artful Alpha 2] has been marked as ready
-queuebot:#ubuntu-release- New: accepted golang-github-kurin-blazer [amd64] (artful-proposed) [0.0~git20170711.0.612082e-1]
-queuebot:#ubuntu-release- New: accepted python-agate-excel [amd64] (artful-proposed) [0.2.1-3]
-queuebot:#ubuntu-release- New: accepted python-agate-dbf [amd64] (artful-proposed) [0.2.0-2]
-queuebot:#ubuntu-release- New: accepted python-agate-sql [amd64] (artful-proposed) [0.5.2-2]
<ginggs> would someone please update 'force-badtest winff/1.5.5-2/armhf' ?
<sil2100> apw: hey! Would you have some free cycles to do some gce-compute-image-packages SRU reviews today? ;) Those are the standard ugly straight-backports from artful
<apw> sil2100, lovely
<apw> ginggs, done
<ginggs> apw: thanks!
<apw> sil2100, there is a gce-compute-image-packages | 20170622-0ubuntu1~14.04.1 sitting in trusty-proposed, what do you want doing with that
<apw> sil2100, and is that fix included in the updates ?
<sil2100> apw: yeah, I took the -proposed version and rebased on top of it - both changes are now in the upstream tarball actually
<apw> sil2100, for next time, the trusty one has delta, it would be nice to enumerate the retained delta in the changelog
<apw> python -> python3 etc
<apw> or the opposite
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (zesty-proposed) [20170718-0ubuntu1~17.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (xenial-proposed) [20170718-0ubuntu1~16.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (trusty-proposed) [20170718-0ubuntu1~14.04.0]
<sil2100> apw: ok, noted! Thanks :)
<apw> sil2100, ^ all yours ...
<sil2100> I was always going ekhm, the easy way
<sil2100> But the easy way isn't the best way of course
<xnox> slangasek, next batch of u8rm https://bugs.launchpad.net/ubuntu/+bugs?field.tag=u8rm
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Artful Alpha 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Artful Alpha 2] has been marked as ready
<jamespage> please could the nova upload waiting for review in the zesty queue be rejected - I have another fix I need to include with that
-queuebot:#ubuntu-release- Unapproved: rejected nova [source] (zesty-proposed) [2:15.0.6-0ubuntu1]
<apw> jamespage, ^
<jamespage> apw: ta
<doko> does retrying autopkg tests with -a include s390x these days?
<xnox> doko, huh? i'm confused what you mean by "-a" using all of proposed, usually is not a good idea.
<xnox> doko, also, there has not been a day when s390x did not have autopkgtests.
<xnox> doko, i only click on hand crafted urls, and usually retry individual arches/builds with hand picked trigger combinations.
<xnox> doko, note the huge backlog of autopkg tests, anything you retry will be done in only a few days time.
<xnox> http://autopkgtest.ubuntu.com/running look at queue lengths
<doko> xnox: at some time, autopkg tests were not triggered on s390x when not specifiying any arch
<xnox> doko, using what?
<doko> no arch option
<xnox> no arch option... to what script?
<xnox> britney triggers s390x adt tests all the time correctly, and retry urls are available and do work on s390x
<apw> jez ... that is some backlog, 13k pending tests
 * xnox clicks on recycle icons on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<xnox> doko, how do you retry adt tests?
<xnox> doko, or what/which api call?
<xnox> maybe something needs fixing, if you tell me, what you do to cause such a question from you =)
<doko> searching the wiki page ...
<doko> xnox: pitti's run-something alias, sshing into some machine
<xnox> doko, that is long gone; and has been replaced by a cgi script that people can trigger from urls on the status pages on autopkgtest.ubuntu.com or on the proposed_updates.sh
<xnox> doko, ssh access should have been removed.
<xnox> doko, also checkout lp:ubuntu-archive-tools retry-autopkgtest-regressions
<doko> xnox: clicking on the recycle icon doesn't run against proposed
<xnox> doko, it runs against a collection of packages from triggers. you can tweak the URL with &all-proposed=1 if you need all proposed.
<xnox> and the triggered by, are pulled from -proposed.
<xnox> doko, so it's best to add &trigger=foo/version&trigger=bar/version -> if you know that something needs to test with both foo and bar from proposed.
<xnox> alternatively add &all-proposed=1
<xnox> to the url.
<doko> so I have to do that for all failing perl tests? with explicit triggers?
<xnox> doko, look at the retry-autopkgtest-regressions script in the ubuntu-archive-tools, that automates retrying stuff.....
<xnox> doko, you can run everything with all-proposed if you feel that is the right thing to do for perl*
<xnox> doko, but i'd rather you _not_ retry _any_ perl yet. and let it do the first pass of 13k tests.
<xnox> doko, and wait for the automatic cron to retry failing tests with proposed.
<Laney> what automatic cron?
<doko> when will that happen?
<xnox> doko, you do know there is bot running that retries things with all-proposed apportunistically?
<Laney> ...
<Laney> who is running this bot?
 * apw suspects the cron job is actually Laney
<doko> it's fun to see who knows about that job ...
<xnox> Laney, maybe i am imagining things, but somebody or soemthing does run retry-autopkgtest-regressions with all-proposed all the time. As e.g. systemd tests keep being retried over, and over, and over again.
<Laney> Not me
<Laney> I think some people learned about it and now abuse it
<Laney> "this test fails, let's just try it with all-proposed"
<cjwatson> Might be worth a bit of access.log analysis
<apw> we should update that script to exit 1 at the top and see if it stops
<xnox> logs should have the requester field recorded with the launchpad id.
<Laney> I can see a lot of all-proposed in the queue at the minute with no requester
<Laney> That means they got inserted into the queue without going through request.cgi
<apw> there arn't many people who can do that are there ?
<Laney> It's that script doko was just talking about
<xnox> http://autopkgtest.ubuntu.com/running ctrl+f for "requester" there are a couple, but those look legit.
<Laney> run-autopkgtest on snakefruit
<xnox> wow....
<apw> Laney, right, so lets change that script to add a requester of $SUDO something
<xnox> Laney, given that we have cgi script that records launchpad id requestor, run-autopkgtest from snakefruit should be removed.
<xnox> imho.
<Laney> It's actually what britney uses to queue the tests
<xnox> hm
<xnox> well, the snakefruit club of people should sort it out then.
<Laney> I think...
 * Laney checks
<apw> the equivalent of ${SUDO_USER:-$USER}
<xnox> ideally - humans should use the cgi script, rather than ssh into snakefruit.
<Laney> no, I lie
<Laney> right
<apw> xnox, that isn't very sensible for a bulk put back
<xnox> apw, ./retry-all-proposed | xargs parallel xdg-open -- ? very bulk friendly
<xnox> or whatever that script is that generates the retry urls, retry-autopkgtest-regressions
<xnox> apw, i can see snakefruit used to rerun all of the release, to get the baseline results on open and some such.
<apw> xnox, not that friendly when it opens 2000 tabs in your firefox
<xnox> but that too whould record who requested all of that.
<Laney> I don't really mind archive admins being able to do it
<apw> xnox, right which is what i am suggesting
<Laney> just....
<Laney> ...don't abuse it
<Laney> is there a good reason for these all-proposed requests or should I kill them off?
 * Laney is in favour of logging the user though and hopes apw investigates doing that :-)
<doko> well, having the perl tests not running against all-proposed will fail with uninstallabilities ...
<xnox> Laney, i am guessing all of perl is fail, or e.g. the triggers should include perl from proposed.
<Laney> they will do, no?
<apw> Laney, carding self
<Laney> dh-make-perl {"triggers": ["perl/5.26.0-4"], "all-proposed": true}
<xnox> but e.g. not:
<xnox> libanyevent-dbi-perl {"triggers": ["libanyevent-perl/7.130-2build1"]}
<apw> Laney, that looks fun to cull
<xnox> it should be and perl from proposed too..... although i hope that depends are right and things work.
<xnox> doko, do you have failed logs with uninstallability in them?
<doko> anyway, the uninstallability issues for perl are all resolved, so I'd appreciate a simple way of giving back all failed tests triggered by perl
<xnox> such that we can look what triggers were used.
<xnox> doko, but is all of perl installable in proposed?
<doko> yes, except for one package on amd64
<xnox> ack.
<doko> http://people.canonical.com/~ubuntu-archive/transitions/html/perl5.26.html
<Laney> retry-autopkgtest-regressions is the way to generate commands
<Laney> | grep perl or similar
<doko> xnox: example: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/amd64/a/apt-file/20170726_202230_26588@/log.gz
-queuebot:#ubuntu-release- Unapproved: nova (zesty-proposed/main) [2:15.0.5-0ubuntu1 => 2:15.0.6-0ubuntu1] (openstack, ubuntu-server)
<LocutusOfBorg> the failed package is now good (TM)
<LocutusOfBorg> needs a publisher run
-queuebot:#ubuntu-release- Unapproved: accepted intel-microcode [source] (xenial-proposed) [3.20170707.1~ubuntu16.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted intel-microcode [source] (zesty-proposed) [3.20170707.1~ubuntu17.04.0]
<slashd> bdmurray, sil2100, morning do you have a moment to release rsyslog for LP: #1429427 in -updates ? It reaches the minimum aging of 7 days today, and it's all green. Thanks in advance.
<ubot5> Launchpad bug 1429427 in rsyslog (Ubuntu Trusty) "Unexplainable time jumps in CRON" [Medium,Fix committed] https://launchpad.net/bugs/1429427
<sil2100> slashd: hey!
<sil2100> slashd: let me take a look in a moment
<slashd> sil2100, tks
-queuebot:#ubuntu-release- Unapproved: libapache2-mod-auth-pgsql (trusty-proposed/main) [2.0.3-6 => 2.0.3-6ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libapache2-mod-auth-pgsql (zesty-proposed/main) [2.0.3-6.1 => 2.0.3-6.1ubuntu0.17.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: libapache2-mod-auth-pgsql (xenial-proposed/main) [2.0.3-6.1 => 2.0.3-6.1ubuntu0.16.04.1] (ubuntu-server)
<sil2100> Ok, finally can go to my SRU duties
<sil2100> slashd: done!
<slashd> sil2100, thanks ;)
-queuebot:#ubuntu-release- Unapproved: gtk+2.0 (zesty-proposed/main) [2.24.31-1ubuntu1 => 2.24.31-1ubuntu1.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gtk+2.0 (xenial-proposed/main) [2.24.30-1ubuntu1.16.04.1 => 2.24.30-1ubuntu1.16.04.2] (ubuntu-desktop)
<slangasek> xnox: and it looks like my all-proposed retests for perl have disappeared from the queue, hmm
<ginggs> ah, slangasek was the bot!
<xnox> slangasek, yes, because we identified that as the abuse of the queue!
<xnox> slangasek, you should add requester "slangasek" when hogging the queue like that.
<xnox> apw, Laney ^^^^^
<slangasek> xnox: it was hardly hogging the queue, it was a couple of dozen requests
<xnox> ah, we had duplicates of everything i think.
<slangasek> if there were duplicates, then why are there zero in now?
<xnox> not sure.
<slangasek> I only requested one retest per package
<slangasek> and there was no requester because it used the admin interface
<slangasek> (snakefruit)
<slangasek> which should be a clue who the bot is, since the REST API doesn't let you do that :)
<xnox> i think at this point we need to wait for the queue to drain, see the follow out, and retry things via api.
<slangasek> these are already-failed tests which I know need to be retried
<slangasek> and they're blockers for perl, which is at the heart of the mess
<xnox> slangasek, why not use the api generator? to request things? also can we add in the snakefruit script to demand requester and it should be "britney" or "slangasek" etc.?
<xnox> horum sad.
<slangasek> because the API generator is a PITA to script
<slangasek> run-autopkgtest on the commandline is saner
<slangasek> if there is a run-autopkgtest that will work with the API the way retry-autopkgtest-regressions does, I would be willing to transition
<xnox> ./retry-autopkgtest-regressions | xargs parallel xdg-open -- ? very bulk friendly
<slangasek> retry-autopkgtest-regressions does not let me specify which packages
<slangasek> or specify trigger arguments
<xnox> slangasek, also you can in google chrome, right click on the retry button to copy as cURL command (it includes the cookies) and even execute the lot via curl, without opening 2000 pages in firefox.
<xnox> slangasek, it does have all-proposed option, and i guess we should add options for extra triggers and/or subset of packages, or feed a package list.
<xnox> create a card for tooling work?
<slangasek> xnox: the tooling work is not a priority for me; the only thing that gets you is attribution of the requests
<slangasek> which you already have in the sense of "someone with snakefruit access"
<xnox> slangasek, i think for us was priority to modify the snakefruit script, to e.g. include the SUDO user name into the requestor field.
<xnox> that was disccuess, but i'm not part of the snakefruit gang.
<slangasek> if there were a way to tag these requests to the 'huge' queue, /that/ would be a useful enhancement
<xnox> hm, yes.
<xnox> i forgot to eat today, going out to find food.
<slangasek> xnox: and now I've read scrollback, and if there were duplicates it was probably because doko and I were both retrying tests (and both via snakefruit).  However, that still doesn't account for all of the test requests being removed instead of half of them ;)
<slangasek> (would be really great if autopkgtest merged duplicate requests...)
<slangasek> xnox, Laney, doko: as for someone regularly retrying systemd tests with --all-proposed, that is definitely *not* me; --all-proposed should almost never be used, it's appropriate for perl specifically because of it being a large transition but otherwise it is offensive.  AFAIK we don't keep a record of the requester anywhere useful after the test has completed?
<tsimonq2> infinity, slangasek: Would one of you happen to be around?
<slangasek> tsimonq2: hi
<tsimonq2> slangasek: So I have figured out the root cause for bug 1633913 I believe.
<ubot5> bug 1633913 in lubuntu-meta (Ubuntu) "lubuntu and ubuntustudio are missing pool; can not install without internet connection" [Undecided,Confirmed] https://launchpad.net/bugs/1633913
<tsimonq2> slangasek: Since the split of the Lubuntu seed into GTK and Qt parts, ship-live is empty, but we have ship-live-{gtk,qt} and ship-live-share.
<tsimonq2> slangasek: I'll have a patch for lp:ubuntu-cdimage soon that should allow these to be picked up.
<slangasek> tsimonq2: why would that belong to lp:ubuntu-cdimage, as opposed to changing the seed?
<tsimonq2> slangasek: Maybe that's an option, but from what I can see, we can fix the problem by adding the appropriate seeds here: http://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/view/head:/lib/cdimage/germinate.py#L296
<slangasek> tsimonq2: or you can fix the structure of your seeds so that ship-live depends on whatever it actually is that you want included
<tsimonq2> i.e. if mode is ship-live, see if project is lubuntu or lubuntu-next, if it is, yield ship-live-share, if it's lubuntu yield ship-live-gtk, and if it's lubuntu-next yield ship-live-qt
<slangasek> ah
<slangasek> you shouldn't need to yield ship-live-share either, surely that's a dependency of ship-live-{qt,gtk} in the STRUCTURE
<tsimonq2> Welp, let me check
<tsimonq2> yep, you're right
<slangasek> but ok, yes if you have two different images with disjoint requirements for ship, you're right to change ubuntu-cdimage
<tsimonq2> Ok cool
<slangasek> tsimonq2: assuming this is also a new change post-xenial, please be sure to include a version guard so as to not break point release builds
<tsimonq2> slangasek: wfm
<tsimonq2> slangasek: How does this look? https://code.launchpad.net/~tsimonq2/ubuntu-cdimage/different-ship-live-names-lubuntu/+merge/328182
<slangasek> Laney, xnox: ftr I consider rerunning the perl-triggered autopkgtests a high priority because this is a major version bump and the likelihood of this introducing some regressions is high - in which case there is human effort required to finish this transition which can only begin once we have the signal in the results of what's actually regressed
<slangasek> tsimonq2: looking
-queuebot:#ubuntu-release- New source: stawk (artful-proposed/primary) [1.1-0ubuntu1]
<tsimonq2> slangasek: ack
<slangasek> tsimonq2: you want a respin, I assume?
<slangasek> (branch landed)
<tsimonq2> slangasek: I can take care of it :)
<slangasek> tsimonq2: I'd rather do it here so if there are issues on the deploy I can notice and track
<slangasek> (running now)
<tsimonq2> slangasek: ack
<tsimonq2> slangasek: In that case, please do.
<LocutusOfBorg> and doko wants to do gcc in some days, so better find regressions quickly if possible :)
<tsimonq2> Oh, thanks for reminding me LocutusOfBorg
<tsimonq2> xnox: What's the status of the Ubuntu Touch removals in the archive? As soon as that's done, we can land a new Qt. :)
<xnox> tsimonq2, i filed a bunch of removal bugs.
<xnox> there are a lot more to do.
<xnox> but i'm not an archive admin.
<tsimonq2> xnox: Oh, thought you were. Do you have any sort of ETA?
<xnox> http://bugs.launchpad.net/ubuntu/+bugs?field.tag=u8rm -> this is hardly a complete list, just the currently leaf packages to remove.
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Artful Alpha 2] has been updated (20170727)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Artful Alpha 2] has been updated (20170727)
<xnox> just the current round of pending removals.
<tsimonq2> Oh, ok.
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Artful Alpha 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Artful Alpha 2] has been marked as ready
<tsimonq2> slangasek: Uh oh, alternate images are failing...
<tsimonq2> slangasek: http://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/artful/daily-20170727.log
<tsimonq2> Missing debootstrap-required libpython3.5-minimal
<tsimonq2> Missing debootstrap-required libpython3.5-stdlib
<tsimonq2> Missing debootstrap-required python3.5
<tsimonq2> Missing debootstrap-required python3.5-minimal
<tsimonq2> slangasek: Erm, it's related to the Python transition, but... wat?
<cjwatson> http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt
 * cjwatson fixes
<tsimonq2> cjwatson: Thank you.
-queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop amd64 [Artful Alpha 2] has been updated (20170727)
-queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop i386 [Artful Alpha 2] has been updated (20170727)
<slangasek> tsimonq2: ^^
<tsimonq2> slangasek: ack
<tsimonq2> slangasek: Right now the next step is to get priority mismatches sorted out (cjwatson was doing that). But for the time being, I'll see if I can get these new images tested.
<slashd> bdmurray, Good day, do you have a moment to release "kexec-tools" in -updates for LP: #1705054 ? Thanks in advance.
<ubot5> Launchpad bug 1705054 in kexec-tools (Ubuntu Trusty) "Trusty kexec-tools suffer from upstream code regression. Fix not included." [Medium,Fix committed] https://launchpad.net/bugs/1705054
-queuebot:#ubuntu-release- New: rejected statistics [source] (artful-proposed) [1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected stawk [source] (artful-proposed) [1.1-0ubuntu1]
<tsimonq2> cjwatson: Out of curiosity, what's involved in sorting out priority matches?
<cjwatson> change-override by an AA (with discretion)
-queuebot:#ubuntu-release- New source: calc-stats (artful-proposed/primary) [1.2-0ubuntu1]
<cjwatson> takes a publisher cycle, so should be done around now, though I haven't checked
<tsimonq2> Ok.
<tsimonq2> cjwatson: Am I safe to rebuild Lubuntu Alternate images now?
<cjwatson> tsimonq2: looks like it
<tsimonq2> cjwatson: Thanks!
<cjwatson> np
<bdmurray> slashd: done
<slashd> bdmurray, thanks
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (xenial-proposed) [1.2.24]
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (zesty-proposed) [1.4.6~17.04.1]
<flexiondotorg> tsimonq2 What is the current status?
<tsimonq2> flexiondotorg: Testing Lubuntu images.,
<flexiondotorg> ETA?
<tsimonq2> 2-3 hours.
 * flexiondotorg sighs
<tsimonq2> flexiondotorg: Sorry. I know it's getting late for you :/
<tsimonq2> flexiondotorg: If you want to help speed it along, help us test ;)
<flexiondotorg> I'm packing.
<tsimonq2> Ok.
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Artful Alpha 2] has been updated (20170727.1)
<tsimonq2> :/ why would amd64 not build?
<doko> ohh no, now I get emails for all 500 perl packages stuck in -proposed .... \o/
<Ukikie> ...RIP inbox.
<tsimonq2> cjwatson, slangasek: *scratches head* why wouldn't Lubuntu Alternate amd64 build? O__o
<tsimonq2> From the log it looks like it didn't even detect that the amd64 image was supposed to build as well...
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Artful Alpha 2] has been marked as ready
<tsimonq2> 1 down, 5 to go
<slangasek> tsimonq2: which log are you looking at?
<tsimonq2> slangasek: http://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/artful/daily-20170727.1.log
<tsimonq2> slangasek: Am I correct in saying that?
<slangasek> tsimonq2: it does look like that log did not include amd64, yes. Was this a rebuild triggered via the iso tracker?
<tsimonq2> slangasek: Yes it was, I rebuilt it for both amd64 and i386...
<slangasek> tsimonq2: if so, and if you triggered them both at the same time, I would speculate that they were queued separately; but that wouldn't explain why a log has shown up for only one of the builds
<slangasek> tsimonq2: try triggering amd64 again?
<tsimonq2> slangasek: I did a little bit ago, want me to do it again?
<slangasek> tsimonq2: so you tried to trigger them together, then you tried to trigger just amd64?
<tsimonq2> slangasek: Correct.
<slangasek> ok
<slangasek> let me see what I can see
<slangasek> tsimonq2: I could see your rebuild request but I couldn't act on it through the script, nor could I cancel it through the web ui; I've cancelled it now by hand and re-triggered, let's see what happens
<tsimonq2> slangasek: Alright.
<slangasek> tsimonq2: I don't see any obvious bugs, I'm not going to try to debug it further.  If the problem recurs I'll dig deeper
<tsimonq2> slangasek: ack
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Artful Alpha 2] has been updated (20170727.2)
<tsimonq2> slangasek: ^ \o/
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Artful Alpha 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop i386 [Artful Alpha 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop amd64 [Artful Alpha 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Artful Alpha 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Artful Alpha 2] has been marked as ready
-queuebot:#ubuntu-release- Unapproved: accepted gnome-applets [source] (zesty-proposed) [3.22.0-2ubuntu0.1]
<tsimonq2> slangasek: Ship It, please.
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (zesty-proposed) [2.5.0-3ubuntu5.4]
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (xenial-proposed) [1.3.1-1ubuntu10.12]
<slangasek> tsimonq2: looking
<slangasek> tsimonq2: lp:ubuntu-archive-tools / publish-image-set doesn't know what to do with Lubuntu Next yet
<slangasek> so there'll be a short delay in publishing while I address that
<tsimonq2> slangasek: I think when stgraber did Alpha 1, he might have fixed that but not pushed it.
<tsimonq2> I could be wrong.
<stgraber> oh
<stgraber> quite possible
<stgraber> let me check
<slangasek> tsk :)
<slangasek> ARCHES='amd64 i386' for-project lubuntu-next publish-release daily-live 20170727 desktop no alpha-2
<slangasek> that looks right
<slangasek> stgraber: are you pushing?
<stgraber> yeah
<stgraber> trying to remember how to bzr :)
<slangasek> tsimonq2: lubuntu-next images are oversized?
<slangasek> (do you need to pick a different size?)
<stgraber> slangasek: pushed
<tsimonq2> slangasek: Didn't get an answer when I pinged about it :P
<tsimonq2> slangasek: But yes
<slangasek> stgraber: I don't see your push?
<tsimonq2> slangasek: 1.5 GB sounds sane to me until we (Lubuntu) can look at reducing it
<flexiondotorg> I just pulled
<slangasek> stgraber: n/m, it applied without conflicts so bzr didn't bother telling me ;)
<tsimonq2> flexiondotorg: hello!
<flexiondotorg> o/
<slangasek> tsimonq2: "sounds sane" == "you'd like me to commit that"?
<tsimonq2> slangasek: Yes.
<tsimonq2> :P
<slangasek> k, I'm down with having zero nag emails and zero manual steps in the publishing
<tsimonq2> slangasek: I'll be around for the next 30 mins (work needs me to come in) but since I'm signed up with bashfulrobot, he's agreed to just publish the announcement, if that's OK with you.
<tsimonq2> Yes, zero nag emails :P
<slangasek> tsimonq2: I'll be hitting the final 'publish' button here in about 5m
<tsimonq2> slangasek: Alright, I just didn't know what your timing was. Works for me.
<tsimonq2> slangasek: (i.e. please ping both me and bashfulrobot when it's ready for announcement publishing, if you could)
-queuebot:#ubuntu-release- New binary: node-tty-browserify [amd64] (artful-proposed/none) [0.0.0-2] (no packageset)
<slangasek> tsimonq2: http://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/revision/1672
<tsimonq2> slangasek: ack, thanks
<slangasek> hmph, 12 CPU threads and we block on a single-threaded checksumming operation
-queuebot:#ubuntu-release- Unapproved: accepted aodh [source] (zesty-proposed) [4.0.1-0ubuntu0.17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted ceilometer [source] (zesty-proposed) [1:8.0.2-0ubuntu0.17.04.1]
<cjwatson> valid point on lack of multiprocessing, but it's supposed to copy the checksums from the dailies it's publishing, and if it doesn't do that then it's a bug worth looking into
<slangasek> cjwatson: I noticed the delay on the src images
-queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (zesty-proposed) [2:10.0.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted heat [source] (zesty-proposed) [1:8.0.2-0ubuntu1]
<slangasek> ...which also don't appear to have been regenerated since alpha-1
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (zesty-proposed) [3:11.0.3-0ubuntu1]
<slangasek> tsimonq2 bashfulrobot: alpha-2 mirroring in progress
<tsimonq2> slangasek: ack
<slangasek> infinity, cjwatson, stgraber: how are the src images meant to be built, since they don't appear to be happening automatically by cron and aren't listed on https://wiki.ubuntu.com/MilestoneProcess ?
<stgraber> slangasek: I usually call cron.source manually (takes quite a long time), make sure to set the right env so it only generates for the participating flavors (bash history should help)
<cjwatson> I fear it is manual but I have long forgotten the details
<slangasek> artful milestone marked as released; crontab reset
<stgraber> slangasek: you will also have to move them around a bit so that the publish process works, otherwise it's going to be looking for them at the wrong place
 * stgraber -> out for a bit
<cjwatson> it's probably the buggiest bit of cdimage
<slangasek> k, regenerating, and added to https://wiki.ubuntu.com/MilestoneProcess
 * tsimonq2 -> AFK for the next two hours, bashfulrobot should be around any minute (spoke with him on Telegram) to publish the announcement. o/
<tsimonq2> s/two/three/ - that's more realistic
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (zesty-proposed) [2:10.0.2-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (xenial-proposed) [2:8.4.0-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted neutron-fwaas [source] (zesty-proposed) [1:10.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron-lbaas [source] (zesty-proposed) [2:10.0.1-0ubuntu1]
<infinity> stgraber: The "wrong place" thing is fixable with a symlink.  I do it every release. :/
<slangasek> which symlink is this?
<infinity> Well, I say that, but now I can't find weird symlinks.  It is possible I fixed the source instead?
<infinity> That sounds less likely.
-queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (zesty-proposed) [163.0.0-0ubuntu1~17.04.0]
<infinity> slangasek: Anyhow, not sure if I fixed something, or someone unfixed filesystem hacks, but if it spits out source in someplace other than where the current/pending/20170630 live, just shuffle it around.
<slangasek> groovy
-queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (xenial-proposed) [163.0.0-0ubuntu1~16.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (trusty-proposed) [163.0.0-0ubuntu1~14.04.0]
#ubuntu-release 2017-07-28
-queuebot:#ubuntu-release- New: rejected ubuntu-advantage-tools [source] (trusty-proposed) [2]
-queuebot:#ubuntu-release- New source: ubuntu-advantage-tools (trusty-proposed/primary) [2]
-queuebot:#ubuntu-release- Unapproved: rejected update-manager [source] (xenial-proposed) [1:16.04.8]
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (xenial-proposed) [2.21.63.4]
-queuebot:#ubuntu-release- Unapproved: accepted whoopsie [source] (xenial-proposed) [0.2.52.5]
-queuebot:#ubuntu-release- Unapproved: accepted whoopsie [source] (zesty-proposed) [0.2.55.2]
-queuebot:#ubuntu-release- New: accepted ubuntu-advantage-tools [source] (trusty-proposed) [2]
-queuebot:#ubuntu-release- New binary: ubuntu-advantage-tools [i386] (trusty-proposed/none) [2] (no packageset)
<bashfulrobot> slangasek: Yup - I'm around for sure. Just ping when ready.
<slangasek> bashfulrobot: that was the ping :)
<bashfulrobot> ok, Will announce!
<slangasek> mirroring is triggered, the rest is up to you
<bashfulrobot> Thanks!
<bashfulrobot> On it!
<slangasek> you might want to check that it's visible on the mirrors before announcing just to be sure
<slangasek> i.e. that cdimage.ubuntu.com shows what you expect
<bashfulrobot> slangasek: Good point. I'm still editing the email anyways. Will check before sending.
-queuebot:#ubuntu-release- New binary: libhtp [ppc64el] (artful-proposed/none) [1:0.5.25-1] (no packageset)
-queuebot:#ubuntu-release- New binary: suricata [ppc64el] (artful-proposed/universe) [4.0.0-beta1-1~exp1] (no packageset)
-queuebot:#ubuntu-release- New binary: libhtp [amd64] (artful-proposed/universe) [1:0.5.25-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libhtp [s390x] (artful-proposed/universe) [1:0.5.25-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libhtp [arm64] (artful-proposed/universe) [1:0.5.25-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libhtp [armhf] (artful-proposed/universe) [1:0.5.25-1] (no packageset)
-queuebot:#ubuntu-release- New binary: suricata [amd64] (artful-proposed/universe) [4.0.0-beta1-1~exp1] (no packageset)
-queuebot:#ubuntu-release- New binary: libhtp [i386] (artful-proposed/universe) [1:0.5.25-1] (no packageset)
-queuebot:#ubuntu-release- New binary: suricata [i386] (artful-proposed/universe) [4.0.0-beta1-1~exp1] (no packageset)
-queuebot:#ubuntu-release- New binary: suricata [arm64] (artful-proposed/universe) [4.0.0-beta1-1~exp1] (no packageset)
-queuebot:#ubuntu-release- New binary: suricata [armhf] (artful-proposed/universe) [4.0.0-beta1-1~exp1] (no packageset)
-queuebot:#ubuntu-release- New binary: suricata [s390x] (artful-proposed/universe) [4.0.0-beta1-1~exp1] (no packageset)
-queuebot:#ubuntu-release- New: accepted suricata [amd64] (artful-proposed) [4.0.0-beta1-1~exp1]
-queuebot:#ubuntu-release- New: accepted suricata [armhf] (artful-proposed) [4.0.0-beta1-1~exp1]
-queuebot:#ubuntu-release- New: accepted suricata [arm64] (artful-proposed) [4.0.0-beta1-1~exp1]
-queuebot:#ubuntu-release- New: accepted suricata [s390x] (artful-proposed) [4.0.0-beta1-1~exp1]
-queuebot:#ubuntu-release- New: accepted libhtp [amd64] (artful-proposed) [1:0.5.25-1]
-queuebot:#ubuntu-release- New: accepted libhtp [armhf] (artful-proposed) [1:0.5.25-1]
-queuebot:#ubuntu-release- New: accepted libhtp [ppc64el] (artful-proposed) [1:0.5.25-1]
-queuebot:#ubuntu-release- New: accepted node-tty-browserify [amd64] (artful-proposed) [0.0.0-2]
-queuebot:#ubuntu-release- New: accepted suricata [ppc64el] (artful-proposed) [4.0.0-beta1-1~exp1]
-queuebot:#ubuntu-release- New: accepted libhtp [arm64] (artful-proposed) [1:0.5.25-1]
-queuebot:#ubuntu-release- New: accepted libhtp [s390x] (artful-proposed) [1:0.5.25-1]
-queuebot:#ubuntu-release- New: accepted libhtp [i386] (artful-proposed) [1:0.5.25-1]
-queuebot:#ubuntu-release- New: accepted suricata [i386] (artful-proposed) [4.0.0-beta1-1~exp1]
<tsimonq2> doko, Laney: Hello, when would be a good time to land the Qt 5.7.1 -> 5.9.1 transition? Feature Freeze is in less than a month, and we have a Perl transition going on, GCC next week... could I get your thoughts on when we can land it?
<tsimonq2> (to be clear, I just pinged those people because they were on the release team, thoughts from anyone else are appreciated)
<tsimonq2> s/were/are/
<tsimonq2> doko, Laney: I'd also like to note that it's ready to land whenever, it's in https://bileto.ubuntu.com/#/ticket/2819 and LocutusOfBorg has been my sponsor to get things in there, so he'll likely be the one to press the button to land if it's approved.
<slangasek> tsimonq2: "on the release team" - https://launchpad.net/~ubuntu-release/+members
<slangasek> but I don't have a particular sense of when is a good time to land it
<tsimonq2> slangasek: LocutusOfBorg told me to ping them and to get a release team ack, didn't check that page and assumed they were both release team members  :P
<tsimonq2> s/told me to/suggested I/
<LocutusOfBorg> asking doko was not with his RT hat, but because he will start a big transition and I don't want to delay it :)
<LocutusOfBorg>  and Laney, I would like to know your opinion wrt autopkgtestsuites, will qt trigger too many of them? will they have higher priority than perl ones?
<LocutusOfBorg> (sorry I was on train, and I couldn't be here)
-queuebot:#ubuntu-release- Unapproved: accepted gjs [source] (zesty-proposed) [1.48.5-0ubuntu0.1]
<acheronuk> morning: could someone please temp badtest the kmail test here for 4:16.12.3 against qtbase http://autopkgtest.ubuntu.com/packages/k/kmail/artful/armhf to hopefully get that qtbase migrated
<acheronuk> failing due to new cmake 3.9 as far as I can see. the replacement kmail 17.04.3 kmail that I'll be uploading sometime reasonably soon seems not to fail, but it would be good to get that qtbase migrated in the meantime if possible
<LocutusOfBorg> I agree, that migration is blocking the qt5.9 transition, and the SRU in zesty for a crash with file opener
<LocutusOfBorg> btw getting emails because something has not migrated in *one* day is somewhat strange
<rbasak> Only for transitions, surely? Usually if it's not migrated in a day something's wrong.
<LocutusOfBorg> only when the package doesn't trigger an hundred autopkgtests :)
<rbasak> Ah. There is that.
<LocutusOfBorg> e.g. if the package is haskell or perl or transition, do not bother for at least a week or two
<LocutusOfBorg> if autopkgtests are still running, do not bother
<rbasak> Could the presence of an entry in the transtiion tracker be used?
<rbasak> Just a thought. I'm not proposing to write any of this.
<LocutusOfBorg> mmm lots of transitions have no tracker
<LocutusOfBorg> I would appreciate the "auto-trackers" appear as in the debian way
<LocutusOfBorg> they will save people from asking britney and understanding its answers :)
<LocutusOfBorg> (if uploader==me, don't send emails :D)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.10.0-29.33~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.10.0-29.33~16.04.1]
<infinity> LocutusOfBorg: "If tests are still running, don't bother" is meant to be true.
<infinity> But maybe that bit's buggy.
<apw> there are some oddities with NBS bits when those clear you are assume guilty for all of the delay to that point and emailed instantly
<LocutusOfBorg> infinity, I honestly don't know if it is buggy or not, I receive too many emails to understand why I got them :)
<sil2100> jamespage: hey! Did you have a moment to take a look if that SRU template on the wiki sounds okayish to you?
<jamespage> sil2100: +1 lgtm coreycb ^^
<coreycb> sil2100: can you pass me a link to the sru template?
<teward> coreycb: this one?  https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template
<teward> oh a different one.  Nevermind.  :)
<coreycb> teward: maybe, thanks anyway :)
<teward> coreycb: i only saw your question, that's why I was confused :)
 * teward has an issue where HexChat doesn't show all the scrollback from ZNC
<sil2100> coreycb: https://wiki.ubuntu.com/OpenStackUpdates at the bottom
<teward> *updates lists*
<teward> oops wrong window
<teward> damned laptop..
-queuebot:#ubuntu-release- Unapproved: sysdig (xenial-proposed/universe) [0.8.0-1ubuntu1 => 0.8.0-1ubuntu2] (no packageset)
<coreycb> sil2100: looks good. i'd probably drop "new features" from the impact section since SRUs typically don't include any.
<coreycb> sil2100: thanks for providing the template
-queuebot:#ubuntu-release- Unapproved: accepted sysdig [source] (xenial-proposed) [0.8.0-1ubuntu2]
<sil2100> coreycb: that's the feedback I wanted, thanks!
<sil2100> Since I wasn't sure if new point-releases have usually features or not
-queuebot:#ubuntu-release- New: accepted ubuntu-advantage-tools [i386] (trusty-proposed) [2]
-queuebot:#ubuntu-release- New sync: ubuntu-advantage-tools (xenial-proposed/primary) [2]
-queuebot:#ubuntu-release- New sync: ubuntu-advantage-tools (artful-proposed/primary) [2]
-queuebot:#ubuntu-release- New sync: ubuntu-advantage-tools (zesty-proposed/primary) [2]
-queuebot:#ubuntu-release- New: accepted ubuntu-advantage-tools [sync] (artful-proposed) [2]
-queuebot:#ubuntu-release- New: accepted ubuntu-advantage-tools [sync] (xenial-proposed) [2]
-queuebot:#ubuntu-release- New: accepted ubuntu-advantage-tools [sync] (zesty-proposed) [2]
<rbasak> [2]
-queuebot:#ubuntu-release- New binary: gettext-maven-plugin [amd64] (artful-proposed/universe) [1.2.9-1] (no packageset)
<rbasak> Took me a while to figure out WTF that meant.
<infinity> Heh.
<infinity> Not a lot of single-digit versions out there.
<acheronuk> could someone please temp badtest the kmail test here for 4:16.12.3 against qtbase http://autopkgtest.ubuntu.com/packages/k/kmail/artful/armhf to hopefully get that qtbase migrated
<acheronuk> failing due to new cmake 3.9 as far as I can see. the replacement kmail 17.04.3 kmail that I'll be uploading sometime reasonably soon seems not to fail, but it would be good to get that qtbase migrated in the meantime if possible
<LocutusOfBorg> autopkgtest for foo/unknown: armhf: failed :(
<LocutusOfBorg> lots of them
<LocutusOfBorg> oh it seems the systemd armhf udev bug
<ginggs> why does that bug only appear on weekends?
<LocutusOfBorg> mmm friday is not weekend :p
-queuebot:#ubuntu-release- New: accepted gettext-maven-plugin [amd64] (artful-proposed) [1.2.9-1]
<xnox> infinity, but binutils/arm64 will remain strict then? so i cannot build a few ocaml things now.
<xnox> infinity, one solution is to disable dynamic linking and/or some thing on arm64 that debian maintainers are proposing, until ocaml is fixed to emit better assembly.
<xnox> i fear i will need to rebuild ocaml on arm64 /o\ and thus rebuild the world.....
-queuebot:#ubuntu-release- Unapproved: accepted keystone [source] (xenial-proposed) [2:9.3.0-0ubuntu3]
<xnox> the systemd I uploaded is really bad /o\
<xnox> fails to upgrade udev on armhf it seems in a container.
 * apw wishes he could remember what xnox told me i should be doing before i uploaded a kernel which was sick; so i could tell him to have done it
<xnox> apw, burn baby burn
 * xnox is dying
<xnox> FATALITY
<apw> xnox, is this the systemd in -proposed ?
<xnox> apw, yes. I will check that ADT is not insane, by reproducing the test locally, and if it really bad, I think it will make sense to remove that upload from proposed.
<apw> xnox, ok
<xnox> but failing to upgrade udev in lxc is critical.
<LocutusOfBorg> do you remember that sigkill invalid instruction that was probably a glibc/binutils/gcc regression? I did a strace of that notmuch test, and the output is there
<LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/13161434
<LocutusOfBorg> this happens only on armhf, and started a while ago (before xenial and zesty)
<LocutusOfBorg> I would appreciate help in debugging it, the strace is between lines "BEGIN OUTPUT" and "END OUTPUT"
<sil2100> ahasenack: hey! I'm doing some SRU -proposed cleanup - I see that LP: #1574900 is verification-failed for xenial and from the discussion I see it's been agreed that the proposed solution is not good enough
<ubot5> Launchpad bug 1574900 in pam-mysql (Ubuntu Yakkety) "libpam-mysql undefined symbol: make_scrambled_password" [Undecided,Fix committed] https://launchpad.net/bugs/1574900
<sil2100> ahasenack: can I trash it?
<sil2100> ahasenack: it's in -proposed for too long so it's a candidate for removal
<ahasenack> sil2100: let me check
<LocutusOfBorg> here a log with valgrind instead of strace https://launchpadlibrarian.net/331034962/buildlog_ubuntu-artful-armhf.notmuch_0.25~rc1-2ubuntu3_BUILDING.txt.gz
<ahasenack> sil2100: correct, that package does not have the right fix
<LocutusOfBorg> maybe we should blame python?
<sil2100> ahasenack: thanks!
<LocutusOfBorg> infinity, ^^ :)
<xnox> apw, cannot reproduce with arm64 on arm64 lxd; nor armhf on arm64 lxd; onto lxc testing.
-queuebot:#ubuntu-release- Unapproved: update-manager (xenial-proposed/main) [1:16.04.7 => 1:16.04.8] (core)
-queuebot:#ubuntu-release- New binary: lua-torch-sys [ppc64el] (artful-proposed/universe) [0~20161027-gf073f05-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ulfius [ppc64el] (artful-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lua-torch-sys [amd64] (artful-proposed/universe) [0~20161027-gf073f05-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ulfius [amd64] (artful-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ulfius [s390x] (artful-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lua-torch-sys [i386] (artful-proposed/universe) [0~20161027-gf073f05-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ulfius [i386] (artful-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lua-torch-sys [s390x] (artful-proposed/universe) [0~20161027-gf073f05-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lua-torch-sys [armhf] (artful-proposed/universe) [0~20161027-gf073f05-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ulfius [armhf] (artful-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ulfius [arm64] (artful-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lua-torch-sys [arm64] (artful-proposed/universe) [0~20161027-gf073f05-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [ppc64el] (artful-proposed/universe) [2.14.17+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [s390x] (artful-proposed/universe) [2.14.17+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [i386] (artful-proposed/universe) [2.14.17+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [armhf] (artful-proposed/universe) [2.14.17+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [arm64] (artful-proposed/universe) [2.14.17+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [amd64] (artful-proposed/universe) [2.14.17+dfsg-1] (no packageset)
<tsimonq2> Hey Archive Admins/Release Team (cc infinity, slangasek), I saw acheronuk said something earlier, but it would be really great to have this temp badtested so that qtbase can migrate: http://autopkgtest.ubuntu.com/packages/k/kmail/artful/armhf
<slangasek> tsimonq2: my stock policy for such requests is to ignore them in favor of someone actually fixing the autopkgtest regression
<slangasek> unless you can show me that this is not a regression vs. the set of packages currently in the release pocket
-queuebot:#ubuntu-release- New: accepted lua-torch-sys [amd64] (artful-proposed) [0~20161027-gf073f05-1]
-queuebot:#ubuntu-release- New: accepted lua-torch-sys [armhf] (artful-proposed) [0~20161027-gf073f05-1]
-queuebot:#ubuntu-release- New: accepted lua-torch-sys [ppc64el] (artful-proposed) [0~20161027-gf073f05-1]
-queuebot:#ubuntu-release- New: accepted lua-torch-sys [arm64] (artful-proposed) [0~20161027-gf073f05-1]
-queuebot:#ubuntu-release- New: accepted lua-torch-sys [s390x] (artful-proposed) [0~20161027-gf073f05-1]
-queuebot:#ubuntu-release- New: accepted lua-torch-sys [i386] (artful-proposed) [0~20161027-gf073f05-1]
<tsimonq2> slangasek: ack
<slangasek> (which can be done by triggering a test of the package with itself as the trigger)
-queuebot:#ubuntu-release- New: accepted qgis [amd64] (artful-proposed) [2.14.17+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [armhf] (artful-proposed) [2.14.17+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [ppc64el] (artful-proposed) [2.14.17+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ulfius [amd64] (artful-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted ulfius [armhf] (artful-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted ulfius [ppc64el] (artful-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted qgis [arm64] (artful-proposed) [2.14.17+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [s390x] (artful-proposed) [2.14.17+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ulfius [i386] (artful-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted qgis [i386] (artful-proposed) [2.14.17+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ulfius [s390x] (artful-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted ulfius [arm64] (artful-proposed) [2.1.0-1]
<tsimonq2> slangasek: Ok.
<acheronuk> kmail {"requester": "rikmills", "triggers": ["kmail/4:16.12.3-0ubuntu1"]}
<tsimonq2> slangasek: ^
<slangasek> ok
<acheronuk> a test build in a ppa shows that for amd64 so far, that version FTBFS with cmake 3.9 https://launchpadlibrarian.net/331058888/buildlog_ubuntu-artful-amd64.kmail_4%3A16.12.3-0ubuntu2~ppa1_BUILDING.txt.gz
<acheronuk> so can't see why that test would be different. but lets see
<acheronuk> slangasek: http://autopkgtest.ubuntu.com/packages/k/kmail/artful/armhf
<slangasek> acheronuk: thanks, happily badtesting
<acheronuk> tahnk you
<acheronuk> *thank
<tsimonq2> Thanks slangasek :)
<LocutusOfBorg> hello, did the kmail bad-testing force fail somewhere? it should make qtbase and mesa migrate finally :)
<tsimonq2> slangasek: ^ :)
<LocutusOfBorg> also, please force it everywhere, not just armhf (since the failure is cmake specific)
 * LocutusOfBorg thinks that cmake should rebuild the world before migrate :p
<slangasek> it didn't fail; it was committed after the most recently-completed britney run had started
<slangasek> wrt ignoring it everywhere, only armhf appears to be currently failing; http://autopkgtest.ubuntu.com/packages/k/kmail/artful/amd64 and http://autopkgtest.ubuntu.com/packages/k/kmail/artful/i386 show recent successes
<slangasek> retrying kmail against the new mesa
<acheronuk> slangasek: success on the 20th. whereas new cmake landed on 25th
<slangasek> acheronuk: ok, but I still expect to see something on those pages above showing me (and others who look) that it's regressed in the release before I add a hint
<acheronuk> re-runs some tests and I'm pretty certain you will get just that
<slangasek> it's fine that you're certain of it, but the tests need to actually be run so that this is logged
<slangasek> so that someone can work out what's going on from the results page, and not based on opaque knowledge
<acheronuk> fair enough
<acheronuk> fail http://autopkgtest.ubuntu.com/packages/k/kmail/artful/s390x
<acheronuk> duh. that wouldn't build anyway.
<LocutusOfBorg> retried
<LocutusOfBorg> (on amd64)
<LocutusOfBorg> slangasek, can we please force badtest disaspora? rationale is: it can't be installed because it depends on a ruby-twitter that depends on equalizer 0.0.10, but 0.0.11 landed some hours ago
<LocutusOfBorg>     twitter (~> 5.16) was resolved to 5.16.0, which depends on
<LocutusOfBorg>       equalizer (= 0.0.10)
<LocutusOfBorg> (speaking for imagemagick,, not diaspora in general, because there is a new twitter in proposed that might have some fixes)
<slangasek> Setting up diaspora (0.6.0.1+debian-1) ...
<slangasek> /var/lib/dpkg/info/diaspora.postinst: 38: /var/lib/dpkg/info/diaspora.postinst:
<slangasek> -e: not found
<slangasek> Setting up environment varibales...
<slangasek> good show
<slangasek> LocutusOfBorg: adding the hint; but is someone going to lart the ruby-twitter maintainer for not having correct versioned dependencies?
<LocutusOfBorg> well, this isn't actually the problem
<LocutusOfBorg> yep sure
<LocutusOfBorg> this is also failing in -proposed
<LocutusOfBorg> because of the new twitter
<slangasek> yes, the stuff I quoted isn't the cause of the autopkgtest failure, it just shows questionable packaging quality
<LocutusOfBorg> so, ruby itself is self contained correctly, but disaspora needs fixed
<LocutusOfBorg> slangasek, I got it, sure :)
<LocutusOfBorg> I would even open an RC probably
<LocutusOfBorg> #866877
<LocutusOfBorg> nevermind
<LocutusOfBorg>  It depends (transitively) on ruby-actionpack-action-caching, ruby-devise, ruby-jquery-rails, ruby-kaminari, ruby-net-scp, ruby-sass-rails and ruby-sham-rack, affected by RC bug(s) 868750, 869033, 869039, 869044, 869050, 869052 and 869164
<LocutusOfBorg> sigh, I would personally kick everything out, since it requires sourceful uploads anyway
<LocutusOfBorg> but this will kick out gitlab and a lot of other stuff :(
<acheronuk> hmmm. I wonder if these kmail tests might pass if the autotest builders do the build phase slightly different to the main ppa builders
<LocutusOfBorg> slangasek, https://launchpad.net/ubuntu/+source/python-3to2 please kick it out :) (already removed in debian)
<acheronuk> if they build in the tests, but FTBFS in my staging ppa, then that will be another oddity to chalk up for the tests
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/python-3to2/+bug/1705136
<ubot5> Ubuntu bug 1705136 in python-3to2 (Ubuntu) "please remove this package from ubuntu" [Undecided,New]
<acheronuk> looks like the amd64 is building in the kmail tests. I wonder how the test manages that, when it fails in any normal build elsewhere?
<acheronuk> something about the test build is sidestepping the issue with new cmake. not that I am complaining at all :)
<slangasek> xnox: count(https://bugs.launchpad.net/ubuntu/+bugs?field.tag=u8rm) == 0
<xnox> slangasek, i have been getting emails. thank you. waiting for reverse-depends cache to update, to file more.
<xnox> biased towards unity8 / ubuntu-settings apps a bit, thus a set higher priority from bugs of that chain.
<jbicha> please remove python-3to2 to help with the py36 transition LP: #1705136
<ubot5> Launchpad bug 1705136 in python-3to2 (Ubuntu) "please remove this package from ubuntu" [Undecided,New] https://launchpad.net/bugs/1705136
-queuebot:#ubuntu-release- New binary: mythtv [ppc64el] (artful-proposed/multiverse) [2:29.0+fixes.20170728.696806310a-0ubuntu1] (mythbuntu)
#ubuntu-release 2017-07-29
-queuebot:#ubuntu-release- New binary: mythtv [s390x] (artful-proposed/multiverse) [2:29.0+fixes.20170728.696806310a-0ubuntu1] (mythbuntu)
-queuebot:#ubuntu-release- New binary: mythtv [i386] (artful-proposed/multiverse) [2:29.0+fixes.20170728.696806310a-0ubuntu1] (mythbuntu)
-queuebot:#ubuntu-release- New binary: mythtv [amd64] (artful-proposed/multiverse) [2:29.0+fixes.20170728.696806310a-0ubuntu1] (mythbuntu)
-queuebot:#ubuntu-release- New binary: mythtv [arm64] (artful-proposed/multiverse) [2:29.0+fixes.20170728.696806310a-0ubuntu1] (mythbuntu)
-queuebot:#ubuntu-release- New binary: mythtv [armhf] (artful-proposed/multiverse) [2:29.0+fixes.20170728.696806310a-0ubuntu1] (mythbuntu)
<flocculant> infinity: hi - not often I shout out, but we've now been trying to sort out our 'simple' Xubuntu since 16.04.1 https://code.launchpad.net/~xubuntu-dev/livecd-rootfs/xubuntu-base https://code.launchpad.net/~xubuntu-dev/debian-cd/xubuntu-base https://code.launchpad.net/~xubuntu-dev/ubuntu-cdimage/xubuntu-base
<flocculant> not sure what we really need to be doing but, we would really like to see this sorted in one way or the other for the next lts
<tsimonq2> flocculant: Why don't you add something to the official infra (like with Kubuntu's (deprecated) other images and Lubuntu Next, for example)? Just curious.
<flocculant> tsimonq2: iirc we tried all that 2 years ago - really just want offical answers here now thanks
<tsimonq2> flocculant: Sure, I just know Adam's a busy guy, wanted to see if I could give you a hand, but if you'd like to wait for him, that's your choice :)
<tsimonq2> Had a discussion in another channel, forget I said anything here.
<flocculant> but you had to comment ...
<flocculant> sigh
<LocutusOfBorg> can you please remove libldap-2.4-2-dbg, slapd-dbg?
<infinity> LocutusOfBorg: Wrong question.
<infinity> LocutusOfBorg: Or rather, you wanted to add "in artful-proposed".
<infinity> (done)
<LocutusOfBorg> thanks, but the dbg package exists in release, not in proposed... sorry if I wasn't clear, but I don't get it :)
<LocutusOfBorg> btw do you have any clue for my notmuch debug logs? with strace and valgrind
<infinity> LocutusOfBorg: You were asking me to remove them because britney was listing them as "old binaries left..."
<infinity> LocutusOfBorg: "old binaries left on amd64: libldap-2.4-2-dbg, slapd-dbg (from 2.4.44+dfsg-8ubuntu2)"
<infinity> LocutusOfBorg: Note the version there.  That's not the version in the release pocket, it was a previous upload that never made it out of proposed.
<infinity> LocutusOfBorg: (Yes, they exist in the release pocket too, but they SHOULD, until migration happens)
<LocutusOfBorg> ok thanks
-queuebot:#ubuntu-release- New binary: farmhash [amd64] (artful-proposed/universe) [0~20170626-g23eecfb-1] (no packageset)
-queuebot:#ubuntu-release- New binary: farmhash [s390x] (artful-proposed/universe) [0~20170626-g23eecfb-1] (no packageset)
-queuebot:#ubuntu-release- New binary: farmhash [ppc64el] (artful-proposed/universe) [0~20170626-g23eecfb-1] (no packageset)
-queuebot:#ubuntu-release- New binary: farmhash [arm64] (artful-proposed/universe) [0~20170626-g23eecfb-1] (no packageset)
-queuebot:#ubuntu-release- New binary: farmhash [i386] (artful-proposed/universe) [0~20170626-g23eecfb-1] (no packageset)
-queuebot:#ubuntu-release- New binary: farmhash [armhf] (artful-proposed/universe) [0~20170626-g23eecfb-1] (no packageset)
<LocutusOfBorg> infinity, sorry for  being pesty, but an hint for notmuch will be so much appreciated, I'm really worried about miscompilation of our toolchain on armhf
<infinity> LocutusOfBorg: Sorry, I haven't really been paying attention.  What have you tried, and what have you managed to discover?  Logs, notes?
<LocutusOfBorg> I did a run of the test under strace gdb and another with valgrind gdb
<LocutusOfBorg> I see SIGKILL being started
<LocutusOfBorg> this one with valgrind https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/13166232
<LocutusOfBorg> the valgrind output is between BEGIN LOG and END LOG
<LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/13161434 this one is with strace
<LocutusOfBorg> (keyword is BEGIN OUTPUT=
<LocutusOfBorg> 	+==15994== Invalid read of size 4
<LocutusOfBorg> 	+==15994==    at 0x499D362: ??? (in /usr/lib/arm-linux-gnueabihf/libpython3.6m.so.1.0)
<LocutusOfBorg> this in particular looks scary to me
-queuebot:#ubuntu-release- New: accepted farmhash [amd64] (artful-proposed) [0~20170626-g23eecfb-1]
-queuebot:#ubuntu-release- New: accepted farmhash [armhf] (artful-proposed) [0~20170626-g23eecfb-1]
-queuebot:#ubuntu-release- New: accepted farmhash [ppc64el] (artful-proposed) [0~20170626-g23eecfb-1]
-queuebot:#ubuntu-release- New: accepted farmhash [arm64] (artful-proposed) [0~20170626-g23eecfb-1]
-queuebot:#ubuntu-release- New: accepted farmhash [s390x] (artful-proposed) [0~20170626-g23eecfb-1]
-queuebot:#ubuntu-release- New: accepted farmhash [i386] (artful-proposed) [0~20170626-g23eecfb-1]
<LocutusOfBorg> infinity, if you want I did both logs in a single run https://launchpadlibrarian.net/331134898/buildlog_ubuntu-artful-armhf.notmuch_0.25-2ubuntu1_BUILDING.txt.gz
<infinity> LocutusOfBorg: So, this is curious.  I just ran the build (with testsuite) on a machine basically identical to the builders, and it passed.
<infinity> The only exception is that I didn't run it under linux32.  I'll try that now.
<infinity> LocutusOfBorg: Aaaand, went fine under linux32 as well.  So, uhm.  Wat.
<infinity> I wonder if this is a qemu/kvm bug. :/
<infinity> LocutusOfBorg: I think it's fair to say that notmuch itself isn't being miscompiled here.  However, that leaves open the question of WTF *is* going wrong with the testsuite on the buildds.
<LocutusOfBorg> the question now is: did the qemu/kvm got upgraded in the meanwhile?
<LocutusOfBorg> the latest successful build is here  created on 2016-03-13  https://launchpad.net/ubuntu/+source/notmuch/0.21-3ubuntu2/+build/9344826
<LocutusOfBorg> and the first bad is this one:  Started on 2016-08-31  https://launchpad.net/ubuntu/+source/notmuch/0.22.1-2ubuntu1/+build/10600002
<LocutusOfBorg> Kernel version: Linux kishi10 3.2.0-98-highbank #138-Ubuntu SMP PREEMPT Mon Jan 11 13:24:41 UTC 2016 armv7l
<LocutusOfBorg> Kernel version: Linux bos01-arm64-024 4.2.0-42-generic #49-Ubuntu SMP Tue Jun 28 21:24:20 UTC 2016 aarch64
<LocutusOfBorg> so, in the first case armhf was ran on top of an armv7 kernel, in the other case it became an arm64 one
<LocutusOfBorg> this might not even be a regression in qemu/kvm, but rather a change in buildd system that spot a new bug
<LocutusOfBorg> I'm doing a xenial build here https://launchpad.net/%7Ecostamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa/+delete-packages
<LocutusOfBorg> just to see if this is still building on xenial toolchain
<LocutusOfBorg> something strange is happening on autopkgtest builders
<LocutusOfBorg> nplan is building since days, being retried continuously (according to the webpage)
<LocutusOfBorg> Triggers:	['python3-defaults/3.6.1-0ubuntu2']
<LocutusOfBorg> Requester:	costamagnagianfranco
<LocutusOfBorg> the log seems to be however not showing it
<LocutusOfBorg> Laney, can you please have a quick look? :)
<infinity> LocutusOfBorg: The successful build you pointed at wasn't done under qemu.
<infinity> LocutusOfBorg: kishi was bare metal armv7, bos01* are qemu/kvm instances on armv8 hardware.
<infinity> LocutusOfBorg: My local test was on hardware nearly identical to bos01*, but not under qemu/kvm.
<LocutusOfBorg> in fact, I retried a xenial build, and it failed now
<infinity> LocutusOfBorg: Hence my blaming qemu/kvm, for now.
<LocutusOfBorg> now, I tried a xenial build with strace, so I can see if the SIGILL is the same
<LocutusOfBorg> in case, how to report such qemu/kvm issues?
<infinity> Might take some more digging to make it a useful bug report.
<LocutusOfBorg> yep, but I don't know how to easily reproduce, and I don't have access to the infra
<infinity> But for now, "fails the testsuite under qemu/kvm, works fine on real hardware" filed against qemu *and* linux (could be kernel or qemu) would be a start.
 * infinity goes to get some sleep.
 * LocutusOfBorg just woke up :p
<LocutusOfBorg> thanks infinity I will, and maybe subscribe you for knowledge if you want
<LocutusOfBorg> since armhf is fine, can we please have a rebuild of perl stuff against proposed pocket?
<LocutusOfBorg> can anybody please remove libjaxp1.3-java-gcj? it seems to be NBS libjaxp1.3-java (1.3.05-2ubuntu3 to 1.3.05-3)
<slangasek> doko, apw: looks like binutils 2.29 is blocked for a bit in artful-proposed because linux-tools still has a dep on binutils (< 2.29); what would be the timeline for 4.11.0-12?
<slangasek> LocutusOfBorg: buh, how does proposed-migration not get that case right?  sorting
<LocutusOfBorg> I don't know, sorry :) sometimes I'm not sure about what is automagic and what needs hammer
<slangasek> LocutusOfBorg: yeah, my griping here is that this seems like something we *ought* to have made automagic before now but it clearly isn't
<slangasek> this is the "source package previously did arch: any builds, now is arch: all only"
<LocutusOfBorg> mmm I don't fully get it
<LocutusOfBorg> ok the any-> all move, but two binaries disappeared too
<LocutusOfBorg> (well, one  because the dbgsym is not a real binary I guess for your system)
<slangasek> something in the code assumes that if there are no arch-specific binaries and it previously saw some, this means the package isn't yet built :P
<LocutusOfBorg> oh, interesting :)
<LocutusOfBorg> meh, as long as you are around, my minions are happy to do more work
<apw> slangasek, it ought to be copyable out to -proposed on monday
<apw> slangasek, possibly before if we decide we don't care about the one that is there
<slangasek> apw: Monday sounds fine to me. how long from copy-to-proposed to ready-to-migrate?
<apw> normally testing is a day assuming it is good
 * slangasek hits a bunch more perl autopkgtests with a hammer, then goes afk
<slangasek> apw: yeah, a couple more days is fine, thanks.  I just wanted to understand whether we were looking at 3 weeks of blockage or something, given that the gcc-7 transition is due to start next week
<LocutusOfBorg> thanks slangasek for perl :D
<LocutusOfBorg> I did a no-change rebuild of src:stacks because of armhf and s390 were in some "new queue", before they were not built, and after they appeared after the package migrated
<LocutusOfBorg> for this reason they ended up in some "limbo" in artful-proposed
<LocutusOfBorg>  stacks | 1.46-1        | artful/universe          | source, amd64, arm64, i386, ppc64el
<LocutusOfBorg>  stacks | 1.46-1        | artful-proposed/universe | armhf, s390x
<LocutusOfBorg> hopefully rebuilding should work
 * LocutusOfBorg goes AFK, have a nice saturday to everybody
<slangasek> LocutusOfBorg: I don't know why you reuploaded samtools.  samtools was already built against libhts2 and was already a candidate for migration; now the libhts transition is delayed further
<slangasek> LocutusOfBorg: and stacks was also fine, the new binaries simply depended on the newer samtools migrating first because the samtools in artful had no s390x or armhf builds
<slangasek> LocutusOfBorg: in fact, it looks like you reuploaded all the revdeps of htslib without checking whether this was required
<LocutusOfBorg> I didn't get the stacks issue, I thought this was a "migrating in different timelines" issue
<LocutusOfBorg> I saw that all of them were already built, and I even looked at build logs, but I thouth britney wasn't able to let them migrate because of same versions already in archive or something similar
<LocutusOfBorg> I remember in the past some race-condition caused similar issues, and no-change rebuilding was the fix
<LocutusOfBorg> sorry!
<slangasek> LocutusOfBorg: did you look at update_output.txt?
<slangasek> it should have shown that all of these packages were ready to migrate and that only blasr was holding up - they literally would've migrated in the next p-m run :)
<slangasek> anyway, they've migrated now, with a bit of skiptesting of the redundant test runs
<LocutusOfBorg> yes, I looked at it, and I saw samtools on s390x
<LocutusOfBorg> I looked at runtime dependencies of samtools, to see if some perl was holding it
<LocutusOfBorg> and I found nothing, literally nothing
<LocutusOfBorg> and then I though about a race condition, nice to see it fixed :)
<LocutusOfBorg> probably britney was showing s390x because it is the first architecture tested?
<LocutusOfBorg> starting by amd64 would be better, at least "testable" in my pbuilder environment
<LocutusOfBorg> and auto-trackers will save me for badly understanding britney!
<LocutusOfBorg> anyway, g'night!
<LocutusOfBorg> doko, lots of qt stuff will fail with gcc-7, so I presume I will upload 5.9 after gcc-7 switch, to avoid useless bug fixing
<LocutusOfBorg> qt is already mostly ready-to-land in silo
<LocutusOfBorg> tsimonq2, ^^
<tsimonq2> Works for me.
#ubuntu-release 2017-07-30
<slangasek> xnox: there appear to be a couple of genuine regressions on s390x autopkgtests with perl 5.26
<tsimonq2> Release Team (cc cjwatson): Lubuntu Alternate images are failing to build because of this: "Missing debootstrap-required ubuntu-advantage-tools", could someone look into it?
<slangasek> tsimonq2: cjwatson: fixing (and this is archive admin, not release team)
<tsimonq2> slangasek: Thanks
<slangasek> fixing it by temporarily demoting ubuntu-advantage-tools to optional per http://people.canonical.com/~ubuntu-archive/priority-mismatches - it will come back in as important later once seeds are updated, but I'm not doing that at quarter to midnight on a Saturday
<tsimonq2> (a lot of the people overlap so sometimes I have a hard time distinguishing which is appropriate to ping :) )
<tsimonq2> slangasek: Fair enough. :P
<tsimonq2> No rush. :)
-queuebot:#ubuntu-release- New binary: libevent [amd64] (artful-proposed/main) [2.1.8-stable-3] (core)
-queuebot:#ubuntu-release- New binary: libevent [ppc64el] (artful-proposed/main) [2.1.8-stable-3] (core)
-queuebot:#ubuntu-release- New binary: libevent [i386] (artful-proposed/main) [2.1.8-stable-3] (core)
-queuebot:#ubuntu-release- New binary: libevent [s390x] (artful-proposed/main) [2.1.8-stable-3] (core)
-queuebot:#ubuntu-release- New binary: gtts-token [amd64] (artful-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libevent [armhf] (artful-proposed/main) [2.1.8-stable-3] (core)
-queuebot:#ubuntu-release- New binary: libevent [arm64] (artful-proposed/main) [2.1.8-stable-3] (core)
-queuebot:#ubuntu-release- New binary: libdrm [amd64] (artful-proposed/main) [2.4.82-1] (core, xorg)
-queuebot:#ubuntu-release- New binary: pyee [amd64] (artful-proposed/universe) [3.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gtts-token [amd64] (artful-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted libevent [amd64] (artful-proposed) [2.1.8-stable-3]
-queuebot:#ubuntu-release- New: accepted libevent [armhf] (artful-proposed) [2.1.8-stable-3]
-queuebot:#ubuntu-release- New: accepted libevent [ppc64el] (artful-proposed) [2.1.8-stable-3]
-queuebot:#ubuntu-release- New: accepted pyee [amd64] (artful-proposed) [3.0.3-1]
-queuebot:#ubuntu-release- New: accepted libdrm [amd64] (artful-proposed) [2.4.82-1]
-queuebot:#ubuntu-release- New: accepted libevent [i386] (artful-proposed) [2.1.8-stable-3]
-queuebot:#ubuntu-release- New: accepted libevent [arm64] (artful-proposed) [2.1.8-stable-3]
-queuebot:#ubuntu-release- New: accepted libevent [s390x] (artful-proposed) [2.1.8-stable-3]
#ubuntu-release 2018-07-23
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (bionic-proposed) [2:17.0.5-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (xenial-proposed) [2:13.1.4-0ubuntu4.3]
-queuebot:#ubuntu-release- Unapproved: accepted syslog-ng-incubator [source] (xenial-proposed) [0.3.3-2ubuntu1]
<Trevinho> sil2100: hey, could you instead have a look on those SRUs from LP I've mentioned last friday?
<Trevinho> from LP => from bileto
<apw> Trevinho, if they have a bionic component then it is hard to get things out if they are main because of the point release freez
<Trevinho> apw: uff... They were waiting for weeks, and they have to be in .1 or some installs will break...
<apw> infinity, ^
<Trevinho> I had to ping again maybe, but I asked already few times
<apw> and it is helpful if you could point at the silo and/or the packages
<Trevinho> Nux and xorg
-queuebot:#ubuntu-release- Unapproved: openvswitch (bionic-proposed/main) [2.9.0-0ubuntu1 => 2.9.2-0ubuntu0.18.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: intel-mkl [s390x] (cosmic-proposed/multiverse) [2018.3.222-1] (no packageset)
-queuebot:#ubuntu-release- New binary: intel-mkl [ppc64el] (cosmic-proposed/multiverse) [2018.3.222-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-certbot-dns-gehirn [amd64] (cosmic-proposed/universe) [0.26.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-certbot-dns-sakuracloud [amd64] (cosmic-proposed/universe) [0.26.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-certbot-dns-linode [amd64] (cosmic-proposed/universe) [0.26.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-certbot-dns-gehirn [amd64] (cosmic-proposed) [0.26.1-1]
-queuebot:#ubuntu-release- New: accepted python-certbot-dns-sakuracloud [amd64] (cosmic-proposed) [0.26.1-1]
-queuebot:#ubuntu-release- New: accepted python-certbot-dns-linode [amd64] (cosmic-proposed) [0.26.0-1]
-queuebot:#ubuntu-release- New binary: intel-mkl [i386] (cosmic-proposed/multiverse) [2018.3.222-1] (no packageset)
<ginggs> ^^^^ intel-mkl (libmkl-local) on s390x and pcc64el makes no sense, so please don't accept these binaries, if that's an option - the next upload will fix this
-queuebot:#ubuntu-release- New binary: intel-mkl [amd64] (cosmic-proposed/multiverse) [2018.3.222-1] (no packageset)
-queuebot:#ubuntu-release- New binary: intel-mkl [arm64] (cosmic-proposed/multiverse) [2018.3.222-1] (no packageset)
-queuebot:#ubuntu-release- New binary: intel-mkl [armhf] (cosmic-proposed/multiverse) [2018.3.222-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted intel-mkl [amd64] (cosmic-proposed) [2018.3.222-1]
-queuebot:#ubuntu-release- New: accepted intel-mkl [armhf] (cosmic-proposed) [2018.3.222-1]
-queuebot:#ubuntu-release- New: accepted intel-mkl [ppc64el] (cosmic-proposed) [2018.3.222-1]
-queuebot:#ubuntu-release- New: accepted intel-mkl [arm64] (cosmic-proposed) [2018.3.222-1]
-queuebot:#ubuntu-release- New: accepted intel-mkl [s390x] (cosmic-proposed) [2018.3.222-1]
-queuebot:#ubuntu-release- New: accepted intel-mkl [i386] (cosmic-proposed) [2018.3.222-1]
<LocutusOfBorg> apw, force-badtest php-horde-http/2.1.7-1
<LocutusOfBorg> can you please update it to 2.1.7-3?
<LocutusOfBorg> it is under pitti file
<apw> LocutusOfBorg, done
<ginggs> apw: would you bump the r-cran-curl/3.2-2build1/arm64 in vorlon's hints please?
<LocutusOfBorg> thanks!
<rbasak> LocutusOfBorg: are you looking at PHP stuff in general?
<rbasak> LocutusOfBorg: I intend to give it some attention if needed
<LocutusOfBorg> rbasak, I want to make phpunit I boostrapped migrate, and then forget about all this stuff
<LocutusOfBorg> :)
<LocutusOfBorg> php-mockery php-net-ldap2 needs fixes, otherwise I'll ask to kick them to proposed and then block-proposed with a bug
<LocutusOfBorg> rbalint, also php-horde-http needs fixes for testsuite, I made the "obvious" patch, but we are now to the old error https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+sourcepub/9276312/+listing-archive-extra
<LocutusOfBorg> and no, I wont' upload a partial testsuite fix, because we have hints
<LocutusOfBorg> apw, proposal: kick php-mockery and php-net-ldap2 to proposed, until they are fixed in Debian (they are both RC buggy, no upstream fixes, they do have broken testsuite, leaf packages, out from buster too)
<LocutusOfBorg> so we can move forward with phpunit, the whole phpstack, and pcre3
<LocutusOfBorg> I don't think we should have a bug with "block-proposed" hint, because they are safe to migrate once fixed automatically
<LocutusOfBorg> also imagemagick is blocked by that php
-queuebot:#ubuntu-release- Unapproved: linux-meta-hwe (xenial-security/main) [4.15.0.29.51 => 4.15.0.29.51] (kernel) (sync)
<apw> LocutusOfBorg, a tollerable plan i suspect, but php-net-ldap2 looks to have rdeps
<LocutusOfBorg> simpleid-ldap and php-net-ldap3 are both rc buggy, out of buster
<LocutusOfBorg> apw, ^^ does this sound plausible too?
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-hwe [sync] (xenial-security) [4.15.0.29.51]
-queuebot:#ubuntu-release- Unapproved: accepted libapache2-mod-perl2 [source] (xenial-proposed) [2.0.9-4ubuntu1.1]
<seb128> apw, unsure how the SRUs are being handled but something is buggy, the xorg SRU has been in the queue waiting for a month and is an important fix since the issue is that upgraders that remove unity without purging it are using software rendering
<apw> seb128, it is a sync, which is much harder to review, so it doesn't get hit in peoples drive-bys i am sure
<rbasak> I tend to assume there's something special going on. Special reviews sometimes take half or a whole day of SRU session, so I don't do them very frequently :-/
<seb128> apw, oh come on "much harder", it's 2 clicks away to get to the diff, https://launchpadlibrarian.net/375418303/xorg_1%3A7.7+19ubuntu7_1%3A7.7+19ubuntu7.1.diff.gz
<seb128> the queue has a link to the ppa which has the diff
<rbasak> seb128: breaks the review tooling
<apw> seb128, only if you know that _that_ sync is special from a place that has the extra info
<apw> and it is a manual process, and yes it should have been done
<seb128> apw, at this end it's just an upload, worth case if you don't know anything it's dget and debdiff
<seb128> don't tell me it's that hard
<rbasak> I don't think he's saying it's hard so he's not doing it.
<apw> as rbasak points out, it is out of process, so it gets shoved 'later'
<rbasak> He's saying it looks hard without further investigation and that may explain why it wasn't looked at before.
<apw> anyhow, it sounds like something one would want in the point release
<seb128> those have been part of our reality for years, it sounds like a lame excuse to let an important LTS issue unreviewed/unfixed for .1 to me
<rbasak> AFAIK, the SRU team in general don't make a commitment to process SRUs FIFO or anything like that.
<rbasak> Informally we've relied on being poked for important things.
<seb128> yeah, that's part of the issue
<apw> seb128, right they have, and all the time i have hated on them :)
<infinity> The PPA doesn't have the diff.
<rbasak> That's not to say that I object to the process being changed or anything.
<seb128> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3298/+packages has a "
<seb128>     diff from 1:7.7+19ubuntu7 (in Ubuntu) to 1:7.7+19ubuntu7.1 (1.2 KiB)
<seb128> " line
<infinity> seb128: The PPA has the xorg diff, but not the nux diff, and as soon as someone gets that far, they may decide they have better things to do. :P
<rbasak> I'm just explaining the current situation.
<infinity> Anyhow, we should get it in today, and it can be released with .1
<seb128> infinity, I think the bottom line is that the process is unprofessional
<seb128> nobody commits to get important fixes reviewed
<infinity> It doesn't need to be on the media, since it's an upgrade issue.
<seb128> and people just hand wave that it's not done because the SRU team is "best effort" and "not commiting to anything"
<infinity> seb128: Who defines what's "important"?
<seb128> well, I guess I'm arguing that from the Canonical side we should have a process to nominate bugs
<seb128> and have people commiting to have those fixes reviewed
<rbasak> seb128: I agree with that bit.
<apw> you do, you come ask for them here
<seb128> apw, nagging people is something some consider rude and don't like doing
<rbasak> seb128: AIUI, the way it works inside Canonical is that if an SRU isn't getting addressed the managers nominate an SRU team member who is a Canonical employee to sort it out.
<seb128> it's also not documented nor fair
<apw> which was done yesterday to my knowledge, and we were already in freeze, so it needed the release-team member doing the work to ok it
<seb128> we shouldn't end up in that situation in the first place
<seb128> if sync are an issue and are not processed it should be documented
<rbasak> The trouble is that there are a large number of SRUs that are hell to properly review.
<infinity> It's been mentioned many times that syncs are a pain.
<rbasak> I prefer to favour traditional bugfixes coming from volunteers since I want to encourage more of those.
<infinity> Like, for years.
<infinity> Anyway.  Can we maybe refrain from having a two hour debate about it?
<infinity> apw: Can you review xorg/nux?
<apw> infinity, sure
<seb128> if we don't have a debate it's going to come back as an issue again
<infinity> apw: Ta.
<infinity> seb128: If we do have a debate, it'll also come back as an issue again.
<infinity> seb128: If we resolve the debate with useful action, maybe not, but that's less likely to happen in the middle of a release week.
<seb128> unless we take steps to address the problem
<LocutusOfBorg> apw, do you need any paperwork for the 4 php packages to kick out from release?
<seb128> k, fair enough
<rbasak> seb128: IMHO, it's something you need to resolve internally with Canonical's Foundations team. Other SRU team members are essentially volunteers.
<rbasak> (and you can't force volunteers to do some particular review)
<seb128> rbasak, right
<seb128> rbasak, but if the team position about sync is "we can't be bothered reviewing them because dget & debdiff is too difficult" that should at least be documented
<apw> seb128, i would say, that though there are diffs, they are only advisory, so one has to redo them, which is where the pain comes from
<rbasak> You can document what makes SRUs more painful to review, sure.
<seb128> apw, it's dget && debdiff, not exactly rocket science either...
<rbasak> And that volunteers will tend to do things that seem less painful :)
<rbasak> See my recent post to ubuntu-release@ about making diff review easier with git ubuntu :)
<apw> seb128, compared to looking at a pregenerated diff in the officially tooling, it is
<rbasak> (plug: it works with syncs!)
<seb128> k, well I guess I made my point, thx for listening :)
<seb128> (and for reviewing)
<rbasak> seb128: it's a valid concern, but honestly, I think the right place to raise it is with your manager (to talk to the Canonical Foundations manager, etc)
<rbasak> Separately if someone who doesn't have internal access to SRU team members needs to get an urgent SRU through, I think this channel is the right place to request review still.
<seb128> rbasak, you are right
<seb128> it's a bit annoying how SRUs/point release are being handled nowadays, but that's mostly from a Canonical perspective yes
<seb128> like there is no communication on the project list about now being tme for getting fixes in, freeze starting, etc
<seb128> rbasak, and yeah, I've no issue asking here or pinging people for reviews but others feel like nagging is rude and don't do it
<seb128> it's a cultural thing and not easy to fix :/
<rbasak> It's unfortunate, but wearing my Ubuntu hat, if you have volunteers reviewing for other volunteers then review work can't really be enforced at all. The only ways I see around it are polite requests or if a volunteer wants to commit to always reviewing everything.
<seb128> yeah
-queuebot:#ubuntu-release- Unapproved: accepted crash [source] (xenial-proposed) [7.2.3+real-1~16.04.1]
<LocutusOfBorg> rbasak, php-imagick  is a sad thing now :/ blocking imagemagick transition, and I don't want to look at the failure
-queuebot:#ubuntu-release- Unapproved: accepted lttng-modules [source] (xenial-proposed) [2.8.0-1ubuntu1~16.04.7]
-queuebot:#ubuntu-release- Unapproved: accepted python-wadllib [source] (bionic-proposed) [1.3.2-3ubuntu0.18.04.1]
<infinity> seb128: While we're complaining about people's responsibilities WRT SRUs, the nux upload fixing the conffile was accepted to xenial and artful over a month ago and never verified.
<infinity> seb128: Which means artful EOLed without the fix being promoted to updates.
<infinity> seb128: And xenial still doesn't have the fix.
<cjwatson> Just a note about python-wadllib to whoever reviewed it - the xenial diff is all but identical so should be easy to review at the same time
<cjwatson> (and thanks)
<cjwatson> sil2100: ^- aha, that was you
<LocutusOfBorg> doko, https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/1340250
<ubot5> Ubuntu bug 1340250 in gcc-defaults (Ubuntu) ""#pragma weak" symbol is 0 even when defined" [Undecided,New]
<LocutusOfBorg> this is what is breaking libunistring and libidn
<sil2100> cjwatson: in progress!
<sil2100> :)
<LocutusOfBorg> why is this an ubuntu only bug?
<sil2100> (got distracted)
<cjwatson> sil2100: \o/
<sil2100> (wanted to have it in xenial for the .5)
-queuebot:#ubuntu-release- Unapproved: accepted python-wadllib [source] (xenial-proposed) [1.3.2-3ubuntu0.16.04.1]
<doko> LocutusOfBorg: no updates for these packages since 2014?
<LocutusOfBorg> but the example code returns correctly 0 in debian, and 2 in ubuntu
<LocutusOfBorg> so I presume this is a real bug, and I'm trying to understand what else changed in the meanwhile
<LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+delete-packages I already reverted glibc and glib2.0 uploads
<LocutusOfBorg> this is a real bug, a nochange rebuild in bionic fails now
<doko> try with -Wl--no-as-needed
<LocutusOfBorg> do you have some archive rebuilds of the months before bionic release so we can bisect what changed?
<doko> on qa.ubuntuwire.org
<LocutusOfBorg> 2018-03-26 libidn was good
<LocutusOfBorg> sadly no rebuilds after 20180408
<LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/15160733
<LocutusOfBorg> interestingly, forcing that weak stuff to disable works
<LocutusOfBorg> now checking the as-needed
<LocutusOfBorg> doko, do you have build logs for the rebuilds?
<LocutusOfBorg> found them nvm
<doko> could be a change in binutils 2.31 as well
<LocutusOfBorg> let me try with released packages, no updates pocket
<LocutusOfBorg> +-  /* Don't generate dynamic GOT relocation against undefined weak
<LocutusOfBorg> +-     symbol in executable.  */
<LocutusOfBorg> ++  /* Don't generate dynamic GOT relocation against resolved undefined weak
<LocutusOfBorg> ++     symbols in an executable.  */
<LocutusOfBorg> mmmm
<seb128> could somebody skip the udisks2/s390x autopkgtest, it's buggy and it's not new (or better, update the hint's version)?
-queuebot:#ubuntu-release- Unapproved: accepted xl2tpd [source] (bionic-proposed) [1.3.10-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted xl2tpd [source] (xenial-proposed) [1.3.6+dfsg-4ubuntu0.16.04.2]
<sil2100> Trevinho: hey! I'll try taking a look at those again now
<LocutusOfBorg> doko_, wl-asneeded didn't work
<LocutusOfBorg> ./vorlon:force-badtest abi-compliance-checker/2.2-2ubuntu1/arm64
<LocutusOfBorg> apw, ^^ bump please?
<LocutusOfBorg> to avoid bothering, please bump directly to version  2.3-1
<LocutusOfBorg> it is in debian deferred queue
<slangasek> LocutusOfBorg: done
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.2 => 2.525.3] (desktop-core)
<infinity> sil2100: ^-- livecd-rootfs review svp.  Try not to vomit.
<LocutusOfBorg> thanks!
<LocutusOfBorg> wow double hint! so now I don't need anymore the --proposed pocket for the kde retries, nice thanks!
<sil2100> infinity: ACK
<sil2100> infinity: do we know if having it as the first snap in the list is also a valid fix?
<infinity> sil2100: mvo said yes.
<sil2100> Ah, we did
<sil2100> Ok, I've seen worse hacks around
<Trevinho> sil2100: great, thanks
<sil2100> ;)
<infinity> sil2100: I've written worse hacks, doesn't mean I'm proud of this one existing. :P
<infinity> sil2100: And, for the record, as far as SRU rules go, I refuse to "fix" this in cosmic, as I think the glaring bug needs to continue to exist to force people to fix it properly.
<infinity> Cause WTF.
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.525.3]
<infinity> "We are designing a new package format that doesn't require dependencies, but also, it has untracked dependencies."
<infinity> Well job.
<sil2100> infinity: that's fine in this case, cosmic is still rolling on dailies only and it only affects images, so as long as it's fixed before release I think it's ok
-queuebot:#ubuntu-release- Unapproved: accepted nux [sync] (bionic-proposed) [4.0.8+18.04.20180622.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted xorg [sync] (bionic-proposed) [1:7.7+19ubuntu7.1]
<sil2100> Trevinho: so for nux in xenial there's the previous part of the fix still in xenial-proposed
<sil2100> Trevinho: since it's the same bug, I'll just approve it
-queuebot:#ubuntu-release- Unapproved: accepted nux [sync] (xenial-proposed) [4.0.8+16.04.20180622.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted xorg [sync] (xenial-proposed) [1:7.7+13ubuntu3.1]
<Trevinho> sil2100: yeah, I will get someone to approve both. Thanks
-queuebot:#ubuntu-release- New binary: libhinawa [s390x] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libhinawa [ppc64el] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libhinawa [amd64] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-lzo [s390x] (cosmic-proposed/universe) [1.12-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libvirt-dbus [s390x] (cosmic-proposed/universe) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libhinawa [i386] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-lzo [ppc64el] (cosmic-proposed/universe) [1.12-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libvirt-dbus [ppc64el] (cosmic-proposed/universe) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libvirt-dbus [i386] (cosmic-proposed/universe) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-lzo [amd64] (cosmic-proposed/universe) [1.12-2] (no packageset)
-queuebot:#ubuntu-release- New binary: expeyes [amd64] (cosmic-proposed/universe) [4.4.3+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-lzo [i386] (cosmic-proposed/universe) [1.12-2] (no packageset)
-queuebot:#ubuntu-release- New binary: graphviz-dot-mode [amd64] (cosmic-proposed/universe) [0.4+41+gc456a2b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-marcel [amd64] (cosmic-proposed/universe) [0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libvirt-dbus [amd64] (cosmic-proposed/universe) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libhinawa [arm64] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libhinawa [armhf] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octavia [amd64] (cosmic-proposed/universe) [2.0.1-1] (no packageset)
<infinity> bdmurray: Can you verify that vte2.91/bionic SRU ASAP?
-queuebot:#ubuntu-release- Unapproved: accepted vte2.91 [source] (bionic-proposed) [0.52.2-1ubuntu1~18.04.2]
-queuebot:#ubuntu-release- New binary: python-lzo [arm64] (cosmic-proposed/universe) [1.12-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-lzo [armhf] (cosmic-proposed/universe) [1.12-2] (no packageset)
<bdmurray> infinity: Sure, but it only affects upgrades from bionic to cosmic.
-queuebot:#ubuntu-release- New binary: libvirt-dbus [arm64] (cosmic-proposed/universe) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libvirt-dbus [armhf] (cosmic-proposed/universe) [1.2.0-1] (no packageset)
<infinity> bdmurray: Ahh, okay.  I misread that, then.
<infinity> bdmurray: Still nice to verify, but indeed, not point-release-critical.
-queuebot:#ubuntu-release- New: accepted expeyes [amd64] (cosmic-proposed) [4.4.3+dfsg-2]
-queuebot:#ubuntu-release- New: accepted libhinawa [amd64] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted libhinawa [armhf] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted libhinawa [ppc64el] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted libvirt-dbus [amd64] (cosmic-proposed) [1.2.0-1]
-queuebot:#ubuntu-release- New: accepted libvirt-dbus [armhf] (cosmic-proposed) [1.2.0-1]
-queuebot:#ubuntu-release- New: accepted libvirt-dbus [ppc64el] (cosmic-proposed) [1.2.0-1]
-queuebot:#ubuntu-release- New: accepted octavia [amd64] (cosmic-proposed) [2.0.1-1]
-queuebot:#ubuntu-release- New: accepted python-lzo [arm64] (cosmic-proposed) [1.12-2]
-queuebot:#ubuntu-release- New: accepted python-lzo [i386] (cosmic-proposed) [1.12-2]
-queuebot:#ubuntu-release- New: accepted graphviz-dot-mode [amd64] (cosmic-proposed) [0.4+41+gc456a2b-1]
-queuebot:#ubuntu-release- New: accepted libhinawa [i386] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted libvirt-dbus [arm64] (cosmic-proposed) [1.2.0-1]
-queuebot:#ubuntu-release- New: accepted libvirt-dbus [s390x] (cosmic-proposed) [1.2.0-1]
-queuebot:#ubuntu-release- New: accepted python-lzo [armhf] (cosmic-proposed) [1.12-2]
-queuebot:#ubuntu-release- New: accepted python-lzo [s390x] (cosmic-proposed) [1.12-2]
-queuebot:#ubuntu-release- New: accepted libhinawa [arm64] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted libvirt-dbus [i386] (cosmic-proposed) [1.2.0-1]
-queuebot:#ubuntu-release- New: accepted python-lzo [ppc64el] (cosmic-proposed) [1.12-2]
-queuebot:#ubuntu-release- New: accepted libhinawa [s390x] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-marcel [amd64] (cosmic-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New: accepted python-lzo [amd64] (cosmic-proposed) [1.12-2]
-queuebot:#ubuntu-release- Unapproved: aodh (bionic-proposed/main) [6.0.1-0ubuntu1 => 6.0.1-0ubuntu1.1] (openstack, ubuntu-server)
<doko_> LocutusOfBorg: I said:  -Wl--no-as-needed
<infinity> -Wl,--no-as-needed even.
<doko_> ohh, while you are here, do we have an update of the buildd chroots?
<infinity> doko_: Colin and I have been working on making them all fancy and automated.  That probably needs another round of review before we get around to using them, though, so I can do one more manual refresh.
<doko_> infinity: ok, then maybe wait for gcc-8.2.0 next weekend
<infinity> doko_: Next weekend, you can bug me in person instead. :P
-queuebot:#ubuntu-release- Unapproved: aodh (xenial-proposed/universe) [2.0.6-0ubuntu1 => 5.1.0-0ubuntu1~cloud1] (openstack)
-queuebot:#ubuntu-release- Unapproved: base-files (bionic-proposed/main) [10.1ubuntu2 => 10.1ubuntu2.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (bionic-proposed) [10.1ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: rejected aodh [source] (xenial-proposed) [5.1.0-0ubuntu1~cloud1]
<LocutusOfBorg> doko_, I said, -Wl,--no-as-needed nothing changes...
<LocutusOfBorg> doko_, of course I did bad copy-pasting... -no-as-needed worked...
<LocutusOfBorg> is this a real fix?
<LocutusOfBorg> oh... I forgot to mention you in changelog, bad me :(
<infinity> LocutusOfBorg: FWIW, when no-as-needed "fixes" a binary at runtime, that generally means the build system is broken and the binary is being underlinked.
<infinity> LocutusOfBorg: And it's just random luck that the underlinking is papered over by some other random linkage accidentally fixing it in passing. :P
#ubuntu-release 2018-07-24
-queuebot:#ubuntu-release- Unapproved: ubiquity (bionic-proposed/main) [18.04.14.3 => 18.04.14.4] (core)
-queuebot:#ubuntu-release- Unapproved: rejected ubiquity [source] (bionic-proposed) [18.04.14.4]
-queuebot:#ubuntu-release- Unapproved: ubiquity (bionic-proposed/main) [18.04.14.3 => 18.04.14.4] (core)
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (bionic-proposed) [18.04.14.4]
-queuebot:#ubuntu-release- Unapproved: ubiquity (bionic-proposed/main) [18.04.14.4 => 18.04.14.5] (core)
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (bionic-proposed) [18.04.14.5]
<LocutusOfBorg> infinity, you are right as usual, I'll fix that in the right way (TM)
<LocutusOfBorg> it has been months since my last underlinking fix, but usually we spot them in package, not in testsuite, this is what tricked me
<LocutusOfBorg> (btw a simple missing pthread link)
<LocutusOfBorg> infinity, sorry again, but seems that even adding -pthread manually, the ldd doesn't show it
<LocutusOfBorg> probably because there are lots of "pragma weak" stuff?
<LocutusOfBorg> no-as-needed works, but manual link addition doesn't
<LocutusOfBorg> infinity, https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1340250
<ubot5> Ubuntu bug 1340250 in libunistring (Ubuntu) ""#pragma weak" symbol is 0 even when defined" [Undecided,New]
<LocutusOfBorg> is this a real bug?
<infinity> LocutusOfBorg: It could be a toolchain bug, or upstream may just say it's an oddity of how weak symbols work, and you need to -Wl,--no-as-needed -lpthread -Wl,--as-needed -lother -lstuff
<infinity> LocutusOfBorg: Agreed that said response is a bit gross. :P
<infinity> LocutusOfBorg: But that's, for instance, the only way you can intentionally link something that's not referenced at all.  And weak references are a weird grey area.
<infinity> LocutusOfBorg: So yeah, I wasn't saying that your fix was necessarily wrong, just that it was worth investigating.
<LocutusOfBorg> I agree this is grey area, but I want something that I can submit upstream
<LocutusOfBorg> did you see the bug? I updated it
<LocutusOfBorg> and you are right, how can the linker decide if a library has to be added or not, when symbols are weak?
<infinity> I haven't looked at it recently, but I'm familiar with the odd behaviour.
<LocutusOfBorg> tltr; pthread symbols are all declared as weak in the code, linker strips pthread.
<infinity> And it gets really muddy when you look at things like plugins (where weak symbols are the norm).
<infinity> And you intentionally don't link plugins to the libraries that the runtime already links.
<infinity> So, in that case, --no-as-needed gets it right.
<LocutusOfBorg> my opinion is that wl,as-needed by default is a pain :)
<LocutusOfBorg> (at least the divergence from debian is)
<infinity> It's marginally goofy.  The solution is to get more people using it.
<infinity> We're not the only distro, thankfully.
<LocutusOfBorg> true :)
<infinity> Just, as you say, we haven't gotten Debian to do it.
<LocutusOfBorg> do you think I should a) remove weak references b) enclose no-as-needed to every pthread linking?
<LocutusOfBorg> I think b might be upstreamable
<infinity> I'm honestly not sure how weak references make sense in the context where you then expect them to always exist.  Unless you expect all your callers to link to pthread.
<infinity> (Which might indeed be an expected thing via linker script or a pkg-config bit or some such)
<infinity> At some point, something needs to get pthread into your address space, or you've lost.
<LocutusOfBorg>    of the program don't use them.  Here we use them, because we don't want
<LocutusOfBorg>    every program that uses libintl to depend on libpthread.  This assumes
<LocutusOfBorg>    that libpthread would not be loaded after libintl; i.e. if libintl is
<LocutusOfBorg>    loaded first, by an executable that does not depend on libpthread, and
<LocutusOfBorg>    then a module is dynamically loaded that depends on libpthread, libintl
<LocutusOfBorg>    will not be multithread-safe.  */
<LocutusOfBorg>    whether a function pointer's value, such as &pthread_mutex_init, is
<LocutusOfBorg>    non-NULL.  However, some versions of GCC have a bug through which, in
<LocutusOfBorg>    PIC mode, &foo != NULL always evaluates to true if there is a direct
<LocutusOfBorg>    call to foo(...) in the same function.  To avoid this, we test the
<LocutusOfBorg>    address of a function in libpthread that we don't use.  */
<infinity> That's some serious acrobatics to avoid sanity.
<LocutusOfBorg> seriously, I'm getting lost
<infinity> I'd certainly say the Debian/Ubuntu solution should be to force it to be linked, full stop.
<LocutusOfBorg> so, link libintl and libunistring to pthread, end of the story
<infinity> The upstream solution, if they're intent on this weird "we want to only be thread-safe if you ask us as runtime to be" nonsense is pretty unclear.
<LocutusOfBorg> this makes sense, but meh, I found even a "USE_POSIX_THREADS_WEAK" define
<LocutusOfBorg> let me debug it
<LocutusOfBorg> autoconf, why you so damn hard
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Bionic 18.04.1] (20101020ubuntu543.1) has been added
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Bionic 18.04.1] (20101020ubuntu543.1) has been added
-queuebot:#ubuntu-release- Builds: Netboot armhf [Bionic 18.04.1] (20101020ubuntu543.1) has been added
-queuebot:#ubuntu-release- Builds: Netboot i386 [Bionic 18.04.1] (20101020ubuntu543.1) has been added
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Bionic 18.04.1] (20101020ubuntu543.1) has been added
-queuebot:#ubuntu-release- Builds: Netboot s390x [Bionic 18.04.1] (20101020ubuntu543.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Bionic 18.04.1] (20180724) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Bionic 18.04.1] (20180724) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Bionic 18.04.1] (20180724) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Bionic 18.04.1] (20180724) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Bionic 18.04.1] (20180724) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Bionic 18.04.1] (20180724) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Bionic 18.04.1] (20180724) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Bionic 18.04.1] (20180724) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Bionic 18.04.1] (20180724) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Bionic 18.04.1] (20180724) has been added
<infinity> jibel: So, mvo has a theory that with my latest livecd-rootfs fix, your snapd bug will disappear on the next image.
<infinity> jibel: I'm heading to bed soon after I trigger the last round of builds, but would be nice if you could confirm that.
<infinity> jibel: (for bionic, I haven't hacked up cosmic)
<jibel> infinity, yes thanks, I read his comment on #u-devel. I'll try on next build.
<infinity> jibel: Shiny.  Just triggered all the desktop builds, they should trickle out over the next few hours.
<infinity> jibel: Would also be awesome if you could maybe put out a call for testing to QA, flavours, ubuntu-release, etc.  I'm too brain dead to work a mail client.
<jibel> infinity, I'll do that. enjoy your bed
<infinity> jibel: Also note, Studio isn't LTS, so don't be surprised if they don't respond (and maybe remind them if they do :P)
<infinity> There are no studio point release images.
<infinity> jibel: And thanks.
<infinity> Oh FFS.
<infinity> jibel: Also, I'm an idiot and the images still have PROPOSED enabled.
<infinity> Always forget one thing...
<sil2100> infinity: should I re-spin after these are done then?
<infinity> sil2100: I'll get it when the dust settles.  Staying awake and watching TV is easy, I don't have to think. ;)
<infinity> Actually, on second thought, I imagine bugs will be found anyway.  Naive to believe these will be perfect.
<infinity> So, just let 'em be as they are.
<infinity> I'll respin after I've woken up if there's nothing else to fix first.
<infinity> jibel: But yeah, mention in your call for testing that the images have proposed enabled and are, thus, not final.  But people should test them as if they are, so we don't have to iterate ad nauseum.
<sil2100> infinity: ok!
<infinity> sil2100: Also, after I've slept, remind me that I only have a couple of days to help land a bunch of stuff for your xenial point release next week. :P
<sil2100> infinity: ;)
<infinity> Most notably, systemd and d-i and almost certainly some livecd-rootfs fixes, cause builds are broken right now, AFAIK.
<sil2100> Broken builds? How?
<infinity> sil2100: Oh, but if you're looking for something helpful to do for bionic, when the desktop images start spitting out, can you grab all the manifest files from the milestone images and diff (minus versions, obviously) with the release images, and maybe toss the results (if non-0) somewhere for me to look at?
<infinity> sil2100: Broken as in a bunch of them were failing last I saw.  But maybe that resolved itself.
<sil2100> infinity: I mean, I only checked the daily desktop one but it seems to be working
<infinity> sil2100: But also willing to bet there are manifest oopses due to HWE stack shuffle.
<sil2100> (testing langpacks)
<sil2100> infinity: as for bionic, sure o/
<infinity> sil2100: I'm pretty sure I've seen xenial failures zip by my inbox.  For some flavours, at least.
<sil2100> I have the kernel bumps for d-i ready, but I'm still waiting with that until I know if we have all the d-i bits in place already
<sil2100> So I'll probably push those out on Thursday or something
<infinity> sil2100: We don't have all the d-i bits ready.
<infinity> sil2100: (see systemd)
<sil2100> Yeah, which is why I didn't push it out yet, didn't want to have to re-upload for no reason
<sil2100> Ok!
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Bionic 18.04.1] (20180724) has been added
<infinity> sil2100, jibel: Oh, other useful thing one of you can do is to fix all the URLs for bionic on the tracker.  They all need bionic/ inserted in them, as we have to do for every LTS, or people who don't know how to drive a web browser complain that the images don't exist. :P
<sil2100> infinity: on it o/
<infinity> Ta.
<sil2100> (might be a bit slow with that since my laptop is suspiciously slow with a VM installing in the background)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Bionic 18.04.1] (20180724) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Bionic 18.04.1] (20180724) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Bionic 18.04.1] (20180724) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Bionic 18.04.1] (20180724) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Bionic 18.04.1] (20180724) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Bionic 18.04.1] (20180724) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Bionic 18.04.1] (20180724) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Bionic 18.04.1] (20180724) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Bionic 18.04.1] (20180724) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Bionic 18.04.1] (20180724) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Bionic 18.04.1] (20180724) has been added
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Bionic 18.04.1] (20180724) has been added
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Bionic 18.04.1] (20180724) has been added
<sil2100> jibel: if anything, I'm in progress of updating the DL links
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Bionic 18.04.1] (20180724) has been added
<sil2100> Lots of click-click
<jibel> sil2100, I'm doing a sanity check of pending then will send the CFT
<doko_> sil2100: please update the version for the libreoffice/i386 hint
<doko_> oSoMoN: ^^^
<jibel> sil2100, are you done with the links?
<ginggs> would someone please bump the r-cran-curl/3.2-2build1/arm64 in vorlon's hints?
<apw> ginggs, helpful if you tell us what to, and hint as to why in the line above
<apw> ginggs, and that appears to be in sil2100s hints
<ginggs> apw: vorlon's hints has:
<ginggs> # crash in an unrelated module used only for testing
<ginggs> force-badtest r-cran-curl/3.1-2/arm64 r-cran-curl/3.2-1/arm64
<apw> sil2100:force-badtest r-cran-curl/3.2-2build1/ppc64el r-cran-curl/3.2-2build1/s390x
<apw> but ... sil has that, which is the current version
<apw> right?  so do you actually need a change ?
<ginggs> please make it 'force-badtest r-cran-curl/3.1-2/arm64 r-cran-curl/3.2-1/arm64 r-cran-curl/3.2-2build1/arm64' in vorlon's hints
<apw> oh god, disjoin arches in different files ... ugg
<ginggs> apw: i think they are different issues too - so i think keep arm64 in vorlon's file
<apw> ginggs, the discription in sil2100's sounds like the same thing
<ginggs> apw: ok, if you think it's better to merge, then please do
<apw> ginggs, i see the debian bug is yours, but that bug is for amd64 in actuality
<sil2100> jibel: still ongoing, it's not a super slow process but there's a lot of products
<apw> ginggs, yeah it is crashing in the amd64 one against the bug sil is quoting
<apw> so it seems plausible
<apw> ginggs, nayhow, i've done something vaguly sensible to make this less confusing, and kicked the can
<ginggs> apw: many thanks!
<jibel> sil2100, need help?
<jibel> can someone moderate my email to ubuntu-release ML ?
<sil2100> jibel: I'm almost finished I guess
<sil2100> jibel: ok, only the server+base ones are left, I'll finish those in a few moments - most important is that the desktop ones are all done for all flavours
<sil2100> jibel: if you feel like copy-pasting then I guess you could pick up the base ones, but if you have better things to do I'll get to those eventually
<jibel> sil2100, k
<sil2100> jibel: server done, should I move on to base?
<oSoMoN> doko_, done
<jibel> sil2100, i'm on it
<jibel> sil2100, the issue with preinstalled snaps is not fixed
<jibel> but gedit is installable now
<sil2100> eh
<jfh> thx for fixing (server)
<jibel> sil2100, done
<sil2100> jibel: thanks!
-queuebot:#ubuntu-release- New binary: ruby-bindex [amd64] (cosmic-proposed/none) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-bindex [i386] (cosmic-proposed/none) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-bindex [s390x] (cosmic-proposed/none) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-bindex [ppc64el] (cosmic-proposed/none) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-bindex [arm64] (cosmic-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-bindex [armhf] (cosmic-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mutter (bionic-proposed/main) [3.28.2-2~ubuntu18.04.1 => 3.28.3-1~ubuntu18.04.1] (desktop-extra, ubuntu-desktop)
<ginggs> r-base migrated \o/ thanks apw!
<apw> ginggs, miracles
-queuebot:#ubuntu-release- Unapproved: gnome-shell (bionic-proposed/main) [3.28.2-0ubuntu0.18.04.1 => 3.28.3-0ubuntu0.18.04.1] (desktop-extra, mozilla, ubuntu-desktop)
<jibel> sil2100, in only-ubiquity mode keyboard pre-selection is broken. for example if I select french as language the keyboard is set to Afghan (1st on the list)
<jibel> it works with the release image
<sil2100> jibel: ok, let me look into that, I have some leads
<jibel> sil2100, bug 1783326
<ubot5> bug 1783326 in ubiquity (Ubuntu) "Wrong keyboard layout is preselected in only-ubiquity mode" [Undecided,New] https://launchpad.net/bugs/1783326
<tsimonq2> slangasek: pinentry/1.1.0-1build2/amd64 decided it would be a fun idea to pass... can I get an updated hint please?
<ahasenack> hi, what's the usual solution to a package that is in main, and inadvertently growed a runtime dependency on a package that that particular version of ubuntu doesn't even have?
<ahasenack> https://bugs.launchpad.net/ubuntu/+source/crmsh/+bug/1687095 case in point
<ubot5> Ubuntu bug 1687095 in crmsh (Ubuntu) "crm cluster health: NameError: global name 'parallax' is not defined" [High,Confirmed]
<ahasenack> in xenial, it's in main, and has a runtime dependency on python-parallax which was only added in artful, and to universe
<apw> ahasenack, we typically avoid that happening
<apw> (which clearly we did not in this case)
<ahasenack> yeah :/
<apw> perhaps it should be backed out
<apw> (on the assumption it is an SRU which broke it so
<apw> or was it broken in the -release pocket
<ahasenack> it's in the release pocket, no update
<ahasenack>  *** 2.2.0-1 500
<ahasenack>         500 http://br.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
<ahasenack> I also added UCA, thinking that maybe it would have an updated version, of even python-parallax available, but no
<ahasenack> I thought openstack relied on crmsh (clustering) a lot for HA deployments
<apw> given crmsh got dropped to universe in a later series, that likely was done to fix the dependency issues
<apw> and indeed it starts depending on python-parallax somewhen
<ahasenack> yes
<ahasenack> one alternative could be to downgrade the xenial version back to when it wasn't requiring parallax, but that has its own problems, like possibly missing functionality
<apw> yeah, this is a true mess, and i am unsure what all options are even valid given the nominal component missmatch
<slangasek> tsimonq2: can I get a baseline retest of the pinentry in cosmic release with no proposed packages, please, to be sure it's genuinely a flaky test?
<cyphermox> slangasek: tsimonq2: pinentry?
<cyphermox> nvm
-queuebot:#ubuntu-release- Unapproved: openssl-ibmca (xenial-proposed/universe) [1.3.0-0ubuntu2.16.04.1 => 1.3.0-0ubuntu2.16.04.2] (no packageset)
<LocutusOfBorg> I did schedule it tsimonq2
<jibel> sil2100, any update on the kbd layout selection issue?
<LocutusOfBorg> slangasek, https://autopkgtest.ubuntu.com/packages/pinentry/cosmic/amd64
<slangasek> LocutusOfBorg: ta, hinting
<LocutusOfBorg> thanks!
<sil2100> jibel: no, still investigating, I thought that maybe the latest console-setup update caused it but I'm not sure now
<sil2100> jibel: I mean, I tried reverting it but I'm not sure if that's enough, as the changes were in the postinst
<sil2100> (also reverted ubiquity and had the same result)
<sil2100> So now I'm actually debugging it normally from scratch
<tsimonq2> LocutusOfBorg, slangasek: thanks.
<tsimonq2> Bad tests are bad...
-queuebot:#ubuntu-release- New binary: apache-mode-el [amd64] (cosmic-proposed/universe) [2.1+4.g97bf66c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-csv-core [ppc64el] (cosmic-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: capstone [s390x] (cosmic-proposed/universe) [3.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-csv-core [s390x] (cosmic-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: boxquote-el [amd64] (cosmic-proposed/universe) [2.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: capstone [i386] (cosmic-proposed/universe) [3.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: capstone [amd64] (cosmic-proposed/universe) [3.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-csv-core [amd64] (cosmic-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-csv-core [armhf] (cosmic-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: capstone [ppc64el] (cosmic-proposed/universe) [3.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-csv-core [i386] (cosmic-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-csv-core [arm64] (cosmic-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: capstone [arm64] (cosmic-proposed/universe) [3.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: capstone [armhf] (cosmic-proposed/universe) [3.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gmbal-pfl [amd64] (cosmic-proposed/universe) [4.0.1-b003-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nova [amd64] (cosmic-proposed/main) [2:18.0.0~b2-0ubuntu3] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New binary: hyperscan [i386] (cosmic-proposed/universe) [5.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hyperscan [amd64] (cosmic-proposed/universe) [5.0.0-2] (no packageset)
<infinity> jibel: Still around?
-queuebot:#ubuntu-release- Unapproved: console-setup (bionic-proposed/main) [1.178ubuntu2.2 => 1.178ubuntu2.3] (core)
<tsimonq2> infinity: Bug 1783416 is something one of my testers just found. It looks like fun.
<ubot5> bug 1783416 in syslinux (Ubuntu) "18.04.1 release candidate fails to boot " [Undecided,New] https://launchpad.net/bugs/1783416
-queuebot:#ubuntu-release- Unapproved: ubiquity (xenial-proposed/main) [2.21.63.6 => 2.21.63.7] (core)
<slangasek> tsimonq2: using what process to copy the image to the USB stick?
<lynorian> slangasek, dd
<slangasek> ok
<slangasek> (not usb-creator, is the important thing, since that routinely creates unbootable things due to bugs in usb-creator rather than the image)
<tsimonq2> lynorian: You ran "sync" after dd, right? :P
<infinity> Neither syslinux nor its configs have changed since release, so failing there can't possibly be a regression.
<lynorian> not explictly but I did leave it on for a little while after it finished
<infinity> lynorian: Leaving it in for a little bit doesn't guarantee much. :)
<lynorian> ok will try sync
<lynorian> this could be a bit embarasing
<lynorian> oops pebkac
<tsimonq2> l
<tsimonq2> lynorian: Thanks for testing though :)
<tsimonq2> Was that it?
<lynorian> yes how have I not come across that before
-queuebot:#ubuntu-release- Unapproved: localechooser (bionic-proposed/main) [2.71ubuntu2 => 2.71ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: accepted console-setup [source] (bionic-proposed) [1.178ubuntu2.3]
-queuebot:#ubuntu-release- Unapproved: accepted localechooser [source] (bionic-proposed) [2.71ubuntu3]
-queuebot:#ubuntu-release- Unapproved: ubiquity (bionic-proposed/main) [18.04.14.5 => 18.04.14.6] (core)
-queuebot:#ubuntu-release- New binary: simavr [s390x] (cosmic-proposed/universe) [1.6+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: simavr [i386] (cosmic-proposed/universe) [1.6+dfsg-1] (no packageset)
<Kamilion> just like to point out, if you prefer commandline tools to GUI tools, `dc3dd if=file.iso of=/dev/sdX` has worked tremendously well for me for nearly a decade now. Automatic sector size selection so no bs=, and it will sync before returning unless asked not to with the nosync option.
-queuebot:#ubuntu-release- New binary: simavr [ppc64el] (cosmic-proposed/universe) [1.6+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: simavr [amd64] (cosmic-proposed/universe) [1.6+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: simavr [arm64] (cosmic-proposed/universe) [1.6+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: simavr [armhf] (cosmic-proposed/universe) [1.6+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (bionic-proposed) [18.04.14.6]
-queuebot:#ubuntu-release- New: accepted simavr [amd64] (cosmic-proposed) [1.6+dfsg-1]
-queuebot:#ubuntu-release- New: accepted simavr [armhf] (cosmic-proposed) [1.6+dfsg-1]
-queuebot:#ubuntu-release- New: accepted simavr [ppc64el] (cosmic-proposed) [1.6+dfsg-1]
-queuebot:#ubuntu-release- New: accepted simavr [arm64] (cosmic-proposed) [1.6+dfsg-1]
-queuebot:#ubuntu-release- New: accepted simavr [s390x] (cosmic-proposed) [1.6+dfsg-1]
-queuebot:#ubuntu-release- New: accepted simavr [i386] (cosmic-proposed) [1.6+dfsg-1]
-queuebot:#ubuntu-release- New: accepted nova [amd64] (cosmic-proposed) [2:18.0.0~b2-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted capstone [amd64] (cosmic-proposed) [3.0.5-1]
-queuebot:#ubuntu-release- New: accepted capstone [armhf] (cosmic-proposed) [3.0.5-1]
-queuebot:#ubuntu-release- New: accepted capstone [ppc64el] (cosmic-proposed) [3.0.5-1]
-queuebot:#ubuntu-release- New: accepted ruby-bindex [amd64] (cosmic-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-bindex [armhf] (cosmic-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-bindex [ppc64el] (cosmic-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted capstone [arm64] (cosmic-proposed) [3.0.5-1]
-queuebot:#ubuntu-release- New: accepted capstone [s390x] (cosmic-proposed) [3.0.5-1]
-queuebot:#ubuntu-release- New: accepted ruby-bindex [i386] (cosmic-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted capstone [i386] (cosmic-proposed) [3.0.5-1]
-queuebot:#ubuntu-release- New: accepted ruby-bindex [s390x] (cosmic-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-bindex [arm64] (cosmic-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted apache-mode-el [amd64] (cosmic-proposed) [2.1+4.g97bf66c-1]
-queuebot:#ubuntu-release- New: accepted gmbal-pfl [amd64] (cosmic-proposed) [4.0.1-b003-1]
-queuebot:#ubuntu-release- New: accepted boxquote-el [amd64] (cosmic-proposed) [2.1-2]
-queuebot:#ubuntu-release- New: accepted hyperscan [amd64] (cosmic-proposed) [5.0.0-2]
-queuebot:#ubuntu-release- New: accepted rust-csv-core [amd64] (cosmic-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted rust-csv-core [armhf] (cosmic-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted rust-csv-core [ppc64el] (cosmic-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted hyperscan [i386] (cosmic-proposed) [5.0.0-2]
-queuebot:#ubuntu-release- New: accepted rust-csv-core [i386] (cosmic-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted rust-csv-core [arm64] (cosmic-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted rust-csv-core [s390x] (cosmic-proposed) [0.1.4-1]
#ubuntu-release 2018-07-25
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Bionic 18.04.1] has been updated (20180724.1)
-queuebot:#ubuntu-release- Unapproved: debian-installer (bionic-proposed/main) [20101020ubuntu543.1 => 20101020ubuntu543.2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (bionic-proposed) [20101020ubuntu543.2]
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Bionic 18.04.1] has been updated (20101020ubuntu543.2)
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Bionic 18.04.1] has been updated (20101020ubuntu543.2)
-queuebot:#ubuntu-release- Builds: Netboot armhf [Bionic 18.04.1] has been updated (20101020ubuntu543.2)
-queuebot:#ubuntu-release- Builds: Netboot i386 [Bionic 18.04.1] has been updated (20101020ubuntu543.2)
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Bionic 18.04.1] has been updated (20101020ubuntu543.2)
-queuebot:#ubuntu-release- Builds: Netboot s390x [Bionic 18.04.1] has been updated (20101020ubuntu543.2)
-queuebot:#ubuntu-release- Unapproved: tlp (bionic-proposed/universe) [1.1-2 => 1.1-2ubuntu1] (ubuntu-budgie)
-queuebot:#ubuntu-release- Unapproved: accepted tlp [source] (bionic-proposed) [1.1-2ubuntu1]
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Bionic 18.04.1] has been updated (20180725)
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Bionic 18.04.1] has been updated (20180725)
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Bionic 18.04.1] has been updated (20180725)
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Bionic 18.04.1] has been updated (20180725)
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Bionic 18.04.1] has been updated (20180725)
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Bionic 18.04.1] has been updated (20180725)
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Bionic 18.04.1] has been updated (20180725)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Bionic 18.04.1] has been updated (20180725)
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Bionic 18.04.1] has been updated (20180725)
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Bionic 18.04.1] has been updated (20180725)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Bionic 18.04.1] has been updated (20180725)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Bionic 18.04.1] has been updated (20180725)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Bionic 18.04.1] has been updated (20180725)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Bionic 18.04.1] has been updated (20180725)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Bionic 18.04.1] has been updated (20180725)
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Bionic 18.04.1] has been updated (20180725)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Bionic 18.04.1] has been updated (20180725)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Bionic 18.04.1] has been updated (20180725)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Bionic 18.04.1] has been updated (20180725)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Bionic 18.04.1] has been updated (20180725)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Bionic 18.04.1] has been updated (20180725)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Bionic 18.04.1] has been updated (20180725)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Bionic 18.04.1] has been updated (20180725)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Bionic 18.04.1] has been updated (20180725)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.3 => 2.525.4] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (bionic-proposed) [2.525.4]
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Bionic 18.04.1] has been updated (20180725)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.3 => 2.525.4] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.525.4]
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.4 => 2.525.5] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.525.5]
-queuebot:#ubuntu-release- New binary: flask-assets [amd64] (cosmic-proposed/universe) [0.12-3] (no packageset)
-queuebot:#ubuntu-release- New binary: flask-oauthlib [amd64] (cosmic-proposed/universe) [0.9.5-2] (no packageset)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Bionic 18.04.1] has been updated (20180725.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Bionic 18.04.1] has been updated (20180725.1)
-queuebot:#ubuntu-release- New binary: mir [s390x] (cosmic-proposed/main) [0.32.1-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: mir [ppc64el] (cosmic-proposed/main) [0.32.1-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: mir [amd64] (cosmic-proposed/main) [0.32.1-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: mir [i386] (cosmic-proposed/main) [0.32.1-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: mir [armhf] (cosmic-proposed/main) [0.32.1-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: mir [arm64] (cosmic-proposed/main) [0.32.1-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-shell (bionic-proposed/main) [3.28.2-0ubuntu0.18.04.1 => 3.28.3-0ubuntu0.18.04.2] (desktop-extra, mozilla, ubuntu-desktop)
<Laney> maybe reject the older gnome-shell to avoid accidents
<Laney> it's a bit bad :-)
<didrocks> Laney: flushed
<Laney> ð½
<Laney> thanks!
<didrocks> :)
-queuebot:#ubuntu-release- Unapproved: rejected gnome-shell [source] (bionic-proposed) [3.28.3-0ubuntu0.18.04.1]
 * apw boggles at what utf-8 has allowed as a 'character'
<Laney> ð
<Laney> bet there's an interesting story about how those square icon ones got in there
<Laney> ð  <- ???
<apw> you always need an NG, so you can ð
<apw> ðð
<apw> well lets just say ... that isn't working very well for me
<apw> appearing and dissappearing at random, qualit
<infinity> Those are all just diamonds with question marks for me.  I really need to fix that some day.
<infinity> Or maybe I don't.  Keep the mystery alive.
<Laney> Yep, you're missing out on being down with da kidz
<Laney> In this context apw and I are kidz
<infinity> Yeah, when I think "hip and cool", you're the first two that spring to mind.
 * apw *beams*
<Laney> ITYM ð
<infinity> didrocks: Thanks for getting Trevinho's fixes into cosmic.  Maybe I can go to debconf with a laptop that works. :P
 * apw is infinity's 'da kidz' Laney is mine
<didrocks> infinity: this was his secret plan to have you switching back to Unity ;)
<infinity> apw: What does that even MEAN?
<infinity> didrocks: Hahaha.
<infinity> didrocks: If I hadn't purged it with fire already, I totally would have swapped back yesterday.
<apw> infinity, _so_ old
<didrocks> infinity: heh ;)
<infinity> didrocks: Instead, I just spent many hours being very angry every time I hit <Super> until I discovered what to blame and downgrade.
<apw> infinity, does that imply that if i updated yesterday and have yet to reboot, i probabally shouldn't
<infinity> apw: Yeah.  Don't log out.
<apw> yay
<infinity> apw: Or, upgrade gnome-shell with what just hit the release pocket 20m ago.
<apw> i'll do the latter
<didrocks> infinity: yeah, at least, downgrading was easyâ¦
<apw> yay for distractions that stop you doing things
<infinity> apw: It was a pretty brutal bug.  Hitting <Super> made all your application windows forever inaccessible, and the only fix was to log out, log back in, and TRY VERY HARD TO NOT HIT SUPER AGAIN.
<infinity> (Or downgrade gnome-shell)
<apw> that would make me throw things, hard
<Laney> "occasional, even frequent, breakage"
<Laney> YEEHAW
<apw> "occastional, even frequent, huge annoyance inducing, breakage"
<infinity> It really just continues to show that, no matter how hard you try, you can't automate testing of GUI software.  You just have to fling it at a user and wait for them to throw something heavier back at your head.
<infinity> (Though, a little bit of local testing might have been nice *cough*)
<apw> does gnome-shell run on mac osx ?
<infinity> In theory, it could.
<infinity> Not sure if anyone would.
<Laney> Why am I so crap at wrapping presents?
<Laney> Oops, didn't mean to field that question to #ubuntu-release
<Laney> But now you can share my angst
<infinity> Laney: We can solve a lot of problems here, but your hand-eye coordination isn't one of them.
-queuebot:#ubuntu-release- New source: yaru-theme (cosmic-proposed/primary) [18.10]
<Ukikie> Laney: I find copious amounts of ducttape help, if nothing else then it adds some humor to it. >_>
<apw> Laney, because you are a perfectionist
<tsimonq2> infinity: From the Twitter response I've been getting, it seems we're seeing an increasing amount of people who have trained their cats to test ISOs. :P
-queuebot:#ubuntu-release- New binary: clevis [ppc64el] (cosmic-proposed/universe) [10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libconvert-scalar-perl [ppc64el] (cosmic-proposed/none) [1.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: clevis [s390x] (cosmic-proposed/universe) [10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libconvert-scalar-perl [s390x] (cosmic-proposed/none) [1.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: clevis [i386] (cosmic-proposed/universe) [10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-stem [amd64] (cosmic-proposed/universe) [1.6.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: clevis [amd64] (cosmic-proposed/universe) [10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libconvert-scalar-perl [i386] (cosmic-proposed/universe) [1.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libconvert-scalar-perl [amd64] (cosmic-proposed/universe) [1.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ivulncheck [amd64] (cosmic-proposed/universe) [0.1.65-1] (no packageset)
-queuebot:#ubuntu-release- New binary: clevis [arm64] (cosmic-proposed/universe) [10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: clevis [armhf] (cosmic-proposed/universe) [10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libu2f-host [amd64] (cosmic-proposed/main) [1.1.6-1] (desktop-core)
-queuebot:#ubuntu-release- New binary: libconvert-scalar-perl [arm64] (cosmic-proposed/universe) [1.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libconvert-scalar-perl [armhf] (cosmic-proposed/universe) [1.12-1] (no packageset)
<tsimonq2> infinity, slangasek: Could I please get a review on this MP? https://code.launchpad.net/~tsimonq2/software-properties/port-away-from-kde/+merge/349592
<infinity> 18k line diff?
<infinity> Pass.
<tsimonq2> infinity: Lots of mv'ing.
<tsimonq2> Fell free to diff the files. :P
<tsimonq2> *Feel
<infinity> I mean, sure, some day.  But that day won't be soon.  So you might want to find another victim. :P
<tsimonq2> Hah.
<infinity> (I go straight from 18.04.1 to the airport)
<tsimonq2> Oh, nice.
<infinity> I guess.
<tsimonq2> debconf?
<infinity> Aye.
<tsimonq2> Sounds like fun.
<infinity> Thus proving you've never attended DebConf.
<tsimonq2> Hah.
<tsimonq2> I haven't.
<tsimonq2> I want to, though.
<infinity> If you have a desperate need to see middle aged nerds in kilts, you'll love it.
<tsimonq2> Hahahahahaha.
<sil2100> wow
<sil2100> ;)
<tsimonq2> What's the ratio of kilted people to non-kilted people? :P
<infinity> I mean, it's mostly (but not exclusively) the Debian UK folks who are fond of the (registered, if I recall?) Debian tartan, and the kilts they had made using it, but there are a fair few of that group.
<infinity> Let me tell you, being good at writing system software has exactly zero correlation with how pretty your knees are.
<tsimonq2> Ah.
<tsimonq2> Hah.
<infinity> tsimonq2: https://wiki.debian.org/Tartan
<tsimonq2> infinity: You weren't kidding!
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (cosmic-proposed/main) [4.17.0-6.7] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (cosmic-proposed) [4.17.0-6.7]
<ddstreet> sil2100, rbasak, other sru people, you might want to review lp #1779863 as it has the potential to need rebuilding for a lot of packages in Bionic.  not uploaded yet.
<ubot5> Launchpad bug 1779863 in nodejs (Ubuntu Cosmic) "Ubuntu nodejs package isn't ABI compatible with mainline nodejs." [Medium,In progress] https://launchpad.net/bugs/1779863
<ddstreet> just fyi
<apw> ddstreet, people use pre-built binaries from random people ... uggg
<ddstreet> apw indeed, which is why i highlighted it here...it's got potential for large headaches for lots of people
<ddstreet> alternately, if we do nothing, it seems there's an existing group of poeple who currently have headaches...
<apw> ddstreet, this is a somewhat confusing statement as the abi change is openssl and nothing to do with nodejs, well unless nodejs changes its ABI based on that library which seems a little ludicrous
<apw> and if that is true ought to tell us their abi managemenet is next to insane; nearly as bad as binutils
<ddstreet> apw yeah it's a bit hard to follow and there's quite a lot of discussion around that in the debian bug, but essentially people pre-build nodejs 'addon
<ddstreet> ' binaries
<ddstreet> and then distribute those addon pre-built binaries with 'npm'
<apw> so if we just called our version 8.1.ubuntu, then they couldn't make prebuilt ones
<ddstreet> and, since they're pre-built, they link against whatever openssl that the upstream nodejs used
<apw> that really sounds like insane behaviour to expect that to work, as there must be many other things which could make that break
<ddstreet> well, blocking them from using prebuilt nodejs binaries is possible i suppose, but wouldn't really gain us anything other than further upsetting those people who distribute/use pre-built nodejs addon binaries
<infinity> ddstreet: I have a hard time believing it would actually require rebuilding all 1090 rdeps, or even a small fraction of that.
<ddstreet> oh i don't disagree with it being insane...
<ddstreet> infinity possibly not - i only rdep'ed it
<ddstreet> did not look into any of the rdeps
<infinity> apw: It's slightly more insane that expecting a perl5 or python2.7 script to work with a Debian perl or python, but not by much.  Upstream guarantees ABI stability and we broke it.  *shrug*
<apw> infinity, well we only broke it because they are (presumably) exposing an internal openssl data type through their own ABI
<ddstreet> their argument is npm is similar to pip or other non-distro package installers
<infinity> ddstreet: Tearing them all apart and looking for refs to any symbols dropped between 1.0 and 1.1 shouldn't be hard to script.  It's probably a fairly small set.
<infinity> apw: Oh, sure, the fact that they don't opaquely wrap OpenSSL is perhaps a bit insane. :P
<ddstreet> infinity probably not many of them actually directly use openssl symbols - but really i have no idea
<apw> well its not insane if you build nativly for every platform, but if you make binary blobs with code in, and ship it ...
<infinity> apw: But when one of your library deps breaks both ABI and API as drastically as OpenSSL did, you have the decision to try to wrap it backward-compatibly or throw your hands in the air.  They went for the latter.
<infinity> apw: Either way, upstream bundles openssl and lists it as part of their ABI promise.
<apw> then they should bundle it in their binary give-aways too
<infinity> apw: We unbundle it, because of course we do, because maintaining two copies is dumb.
<apw> as this requires all and every distro to maintain their exact pairings
<infinity> apw: Err, who is "they"?
<apw> 'the shit which makes binaries which need random unrelated packages to be the right version'
<infinity> apw: Upstream nodejs bundles openssl and it's part of their promised ABI.  The people distributing against that ABI aren't the same people.
 * apw cralws off into a corner sobbing
<infinity> apw: Imagine if libc6, which includes libm and libpthread, suddenly broke ABI in libm, only on Ubuntu, cause we decided some new math routines were better.
<infinity> That's kinda what this is. :P
<infinity> In other words, I think it's a legit bug.
<infinity> I think it would also be legit for us to say "sucks to be you" and not action it, but it's worth investigating the actual impact first.
<apw> but that leaves us in a horrible place where we cannot update openssl becuase nodejs is in the archive
<apw> which is insane in its own way
<infinity> We have openssl1.0 in main anyway.
<infinity> This isn't about needing an *identical* version to upstream's bundle, just ABI-compatible.
<infinity> So 1.0, not 1.1
 * apw huddles tighter into the corner
<infinity> I'm not convinced we can actually support openssl1.0 for 5 years, but that's the security team's problem.
<infinity> And nodejs is is universe, so that's even less of a problem.
<rbasak> Well that was fun to read.
<jibel> sil2100, xenial pending promoted to current
-queuebot:#ubuntu-release- New: accepted yaru-theme [source] (cosmic-proposed) [18.10]
-queuebot:#ubuntu-release- New: accepted clevis [amd64] (cosmic-proposed) [10-1]
-queuebot:#ubuntu-release- New: accepted clevis [armhf] (cosmic-proposed) [10-1]
-queuebot:#ubuntu-release- New: accepted clevis [ppc64el] (cosmic-proposed) [10-1]
-queuebot:#ubuntu-release- New: accepted clevis [arm64] (cosmic-proposed) [10-1]
-queuebot:#ubuntu-release- New: accepted clevis [s390x] (cosmic-proposed) [10-1]
-queuebot:#ubuntu-release- New: accepted clevis [i386] (cosmic-proposed) [10-1]
<didrocks> hum, I have never seen this, anything I should worry about? https://launchpad.net/ubuntu/+source/yaru-theme/18.10/+build/15167072
<Laney> didrocks: looks like it's still working to me - see the "." and "o" at the start of some of the lines
-queuebot:#ubuntu-release- New: accepted flask-assets [amd64] (cosmic-proposed) [0.12-3]
<didrocks> Laney: indeed
<didrocks> let's wait then
-queuebot:#ubuntu-release- New: accepted flask-oauthlib [amd64] (cosmic-proposed) [0.9.5-2]
-queuebot:#ubuntu-release- New: accepted libconvert-scalar-perl [amd64] (cosmic-proposed) [1.12-1]
-queuebot:#ubuntu-release- New: accepted libconvert-scalar-perl [armhf] (cosmic-proposed) [1.12-1]
-queuebot:#ubuntu-release- New: accepted libconvert-scalar-perl [ppc64el] (cosmic-proposed) [1.12-1]
-queuebot:#ubuntu-release- New: accepted libu2f-host [amd64] (cosmic-proposed) [1.1.6-1]
-queuebot:#ubuntu-release- New: accepted ivulncheck [amd64] (cosmic-proposed) [0.1.65-1]
-queuebot:#ubuntu-release- New: accepted libconvert-scalar-perl [i386] (cosmic-proposed) [1.12-1]
-queuebot:#ubuntu-release- New: accepted python-stem [amd64] (cosmic-proposed) [1.6.0-3]
-queuebot:#ubuntu-release- New: accepted libconvert-scalar-perl [arm64] (cosmic-proposed) [1.12-1]
-queuebot:#ubuntu-release- New: accepted libconvert-scalar-perl [s390x] (cosmic-proposed) [1.12-1]
 * Laney holds breath
<didrocks> ;)
<Laney> didrocks: done!!!!
<didrocks> Laney: indeed, nice! were you refreshing the page? I just did it 30s ago and it wasn't :)
<Laney> yes I had to know when to breathe again
<didrocks> heh
-queuebot:#ubuntu-release- New binary: yaru-theme [amd64] (cosmic-proposed/universe) [18.10] (no packageset)
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (bionic-proposed/main) [1.1ubuntu1.18.04.5 => 1.1ubuntu1.18.04.6~rbalint2] (desktop-core, ubuntu-server)
<rbasak> rbalint: ^ wrong destination?
<infinity> ypwong: Not sure if you noticed the call for testing, but I haven't seen any Kylin 18.04.1 testing, so thought I'd poke you (maybe it's just a timezone issue)
<apw> rbasak, either way we're going to reject it for version
-queuebot:#ubuntu-release- Unapproved: linux-base (trusty-proposed/main) [3.5ubuntu4 => 4.5ubuntu1~14.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted openssl-ibmca [source] (xenial-proposed) [1.3.0-0ubuntu2.16.04.2]
-queuebot:#ubuntu-release- Unapproved: rejected unattended-upgrades [source] (bionic-proposed) [1.1ubuntu1.18.04.6~rbalint2]
<rbalint> rbasak, ah, yes, pleas reject it
-queuebot:#ubuntu-release- Unapproved: keepalived (xenial-proposed/main) [1:1.2.19-1ubuntu0.2 => 1:1.2.24-1ubuntu0.16.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: emacs-session [amd64] (cosmic-proposed/universe) [2.4b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-fido2 [amd64] (cosmic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rawtran [amd64] (cosmic-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: nodejs (bionic-proposed/universe) [8.10.0~dfsg-2 => 8.10.0~dfsg-2ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted emacs-session [amd64] (cosmic-proposed) [2.4b-1]
-queuebot:#ubuntu-release- New: accepted rawtran [amd64] (cosmic-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted python-fido2 [amd64] (cosmic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted yaru-theme [amd64] (cosmic-proposed) [18.10]
-queuebot:#ubuntu-release- New: accepted mir [amd64] (cosmic-proposed) [0.32.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mir [armhf] (cosmic-proposed) [0.32.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mir [ppc64el] (cosmic-proposed) [0.32.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mir [arm64] (cosmic-proposed) [0.32.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mir [s390x] (cosmic-proposed) [0.32.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mir [i386] (cosmic-proposed) [0.32.1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: libio-fdpass-perl [amd64] (cosmic-proposed/none) [1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libio-fdpass-perl [s390x] (cosmic-proposed/none) [1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libproc-fastspawn-perl [i386] (cosmic-proposed/none) [1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libio-fdpass-perl [i386] (cosmic-proposed/none) [1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libproc-fastspawn-perl [s390x] (cosmic-proposed/none) [1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libproc-fastspawn-perl [amd64] (cosmic-proposed/none) [1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libio-fdpass-perl [ppc64el] (cosmic-proposed/universe) [1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libproc-fastspawn-perl [ppc64el] (cosmic-proposed/universe) [1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libio-fdpass-perl [arm64] (cosmic-proposed/universe) [1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libio-fdpass-perl [armhf] (cosmic-proposed/universe) [1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libproc-fastspawn-perl [armhf] (cosmic-proposed/universe) [1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libproc-fastspawn-perl [arm64] (cosmic-proposed/universe) [1.2-1] (no packageset)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Bionic 18.04.1] has been updated (20180725.1)
#ubuntu-release 2018-07-26
-queuebot:#ubuntu-release- New: accepted libproc-fastspawn-perl [amd64] (cosmic-proposed) [1.2-1]
-queuebot:#ubuntu-release- New: accepted libproc-fastspawn-perl [armhf] (cosmic-proposed) [1.2-1]
-queuebot:#ubuntu-release- New: accepted libproc-fastspawn-perl [ppc64el] (cosmic-proposed) [1.2-1]
-queuebot:#ubuntu-release- New: accepted libproc-fastspawn-perl [arm64] (cosmic-proposed) [1.2-1]
-queuebot:#ubuntu-release- New: accepted libproc-fastspawn-perl [s390x] (cosmic-proposed) [1.2-1]
-queuebot:#ubuntu-release- New: accepted libproc-fastspawn-perl [i386] (cosmic-proposed) [1.2-1]
-queuebot:#ubuntu-release- New: accepted libio-fdpass-perl [amd64] (cosmic-proposed) [1.2-1]
-queuebot:#ubuntu-release- New: accepted libio-fdpass-perl [armhf] (cosmic-proposed) [1.2-1]
-queuebot:#ubuntu-release- New: accepted libio-fdpass-perl [ppc64el] (cosmic-proposed) [1.2-1]
-queuebot:#ubuntu-release- New: accepted libio-fdpass-perl [arm64] (cosmic-proposed) [1.2-1]
-queuebot:#ubuntu-release- New: accepted libio-fdpass-perl [s390x] (cosmic-proposed) [1.2-1]
-queuebot:#ubuntu-release- New: accepted libio-fdpass-perl [i386] (cosmic-proposed) [1.2-1]
-queuebot:#ubuntu-release- New binary: libanyevent-fork-perl [amd64] (cosmic-proposed/universe) [1.31-1] (no packageset)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Bionic 18.04.1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Bionic 18.04.1] has been marked as ready
-queuebot:#ubuntu-release- New: accepted libanyevent-fork-perl [amd64] (cosmic-proposed) [1.31-1]
-queuebot:#ubuntu-release- New binary: software-properties [amd64] (cosmic-proposed/main) [0.96.25] (desktop-core, ubuntu-server)
<LocutusOfBorg> tsimonq2, ^^^^^^^
<tsimonq2> LocutusOfBorg: ack thanks
<LocutusOfBorg> now, wait for complains :)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Bionic 18.04.1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Bionic 18.04.1] has been marked as ready
<jamespage> please can the openvswitch update in the bionic unapproved queue be rejected - I spotted a new dep that I need to deal with via cosmic uploads
<sil2100> jamespage: ok
<jamespage> sil2100: ta
-queuebot:#ubuntu-release- Unapproved: rejected openvswitch [source] (bionic-proposed) [2.9.2-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Bionic 18.04.1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Bionic 18.04.1] has been marked as ready
-queuebot:#ubuntu-release- Unapproved: systemd (xenial-proposed/main) [229-4ubuntu21.2 => 229-4ubuntu21.3] (core)
<infinity> sil2100: ^ systemd for you.
<sil2100> infinity: thanks, on it!
<sil2100> infinity: and ubuntukylin just confirmed they started testing of .1 isos
<infinity> jibel: Kylin testers seem to be MIA, if you happen to know anyone who excels at simple boot/install/reboot smoketesting to tell me those images aren't poop.
<sil2100> So we should have 'official' test results soon
<infinity> sil2100: Oh, hah.  Jinx.
<sil2100> infinity: ;)
<infinity> jibel: Or not. :P
<infinity> sil2100: If you're in conversation with them, you might want to point out to them that testing RIGHT BEFORE RELEASE is effectively useless if they find bugs.
<infinity> sil2100: Cause it's too late to fix and respin.
<handsome_feng> infinity: Hi, Sorry for the delay, and I got it.
<sil2100> infinity: the good thing is that I sanity tested both amd64 and i386 installations and they were booting and allowed doing 'things', so at least that!
<handsome_feng> sil2100: Thanks!
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (xenial-proposed) [229-4ubuntu21.3]
-queuebot:#ubuntu-release- New binary: feedreader [s390x] (cosmic-proposed/none) [2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [s390x] (cosmic-proposed/universe) [173-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [ppc64el] (cosmic-proposed/universe) [173-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [amd64] (cosmic-proposed/universe) [173-1] (no packageset)
-queuebot:#ubuntu-release- New binary: feedreader [i386] (cosmic-proposed/universe) [2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: feedreader [amd64] (cosmic-proposed/universe) [2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [i386] (cosmic-proposed/universe) [173-1] (no packageset)
-queuebot:#ubuntu-release- New binary: feedreader [ppc64el] (cosmic-proposed/universe) [2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [arm64] (cosmic-proposed/universe) [173-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [armhf] (cosmic-proposed/universe) [173-1] (no packageset)
-queuebot:#ubuntu-release- New binary: feedreader [arm64] (cosmic-proposed/universe) [2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: feedreader [armhf] (cosmic-proposed/universe) [2.2-1] (no packageset)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Bionic 18.04.1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Bionic 18.04.1] has been marked as ready
-queuebot:#ubuntu-release- New: accepted feedreader [amd64] (cosmic-proposed) [2.2-1]
-queuebot:#ubuntu-release- New: accepted feedreader [armhf] (cosmic-proposed) [2.2-1]
-queuebot:#ubuntu-release- New: accepted feedreader [ppc64el] (cosmic-proposed) [2.2-1]
-queuebot:#ubuntu-release- New: accepted software-properties [amd64] (cosmic-proposed) [0.96.25]
-queuebot:#ubuntu-release- New: accepted feedreader [arm64] (cosmic-proposed) [2.2-1]
-queuebot:#ubuntu-release- New: accepted feedreader [s390x] (cosmic-proposed) [2.2-1]
-queuebot:#ubuntu-release- New: accepted feedreader [i386] (cosmic-proposed) [2.2-1]
-queuebot:#ubuntu-release- New: accepted cockpit [amd64] (cosmic-proposed) [173-1]
-queuebot:#ubuntu-release- New: accepted cockpit [armhf] (cosmic-proposed) [173-1]
-queuebot:#ubuntu-release- New: accepted cockpit [ppc64el] (cosmic-proposed) [173-1]
-queuebot:#ubuntu-release- New: accepted cockpit [arm64] (cosmic-proposed) [173-1]
-queuebot:#ubuntu-release- New: accepted cockpit [s390x] (cosmic-proposed) [173-1]
-queuebot:#ubuntu-release- New: accepted cockpit [i386] (cosmic-proposed) [173-1]
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Bionic 18.04.1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Bionic 18.04.1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Bionic 18.04.1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Bionic 18.04.1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Bionic 18.04.1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Bionic 18.04.1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Bionic 18.04.1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Bionic 18.04.1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Bionic 18.04.1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Bionic 18.04.1] has been marked as ready
<infinity> powersj, dpb1: Good to sign-off on 18.04.1 Server images being ready?
<infinity> jibel, willcooke: I already marked 18.04.1 Ubuntu Desktop ready, complain now if I shouldn't have. :P
<jibel> infinity, it's fine thanks
<willcooke> infinity, all good, merci
<infinity> yofel: *poke*
<infinity> yofel: You happy with the state of Kubuntu 18.04.1?
<dpb1> infinity: powersj should be here in a few minutes, let's wait as he was doing the testing
<powersj> infinity: server is a go
<acheronuk> tsimonq2 mparillo valorie: is kubuntu iso good to go?
<acheronuk> infinity: yofel isn't around much at the moment, and I've been ill so have no clue
<acheronuk> infinity: I can't complete the one remaining amd64 test today, so I'd say just risk it if push comes to shove
<tsimonq2> The earliest I can be at a computer to test is two hours.
<infinity> acheronuk: Yeah, based on test results, I was going to release Kubuntu without a formal OK anyway, but I'd rather have a sign-off.
-queuebot:#ubuntu-release- Unapproved: debian-installer (xenial-proposed/main) [20101020ubuntu451.23 => 20101020ubuntu451.24] (core)
<tsimonq2> rbasak, sil2100: Ping, I don't know if you saw my follow-up ping regarding VLC a week or so ago. sarnold asked if it go in via bionic-updates first and from there it can be no-change rebuilt for bionic-security.
<tsimonq2> I'd like to get that in bionic-proposed right after things open up from 18.04.1 if that's OK.
<tsimonq2> (The sooner the better, because of the CVE.)
<mparillo> acheronuk: It is still a bit early for valorie, but I was happy with the 64-bit live session, and full disk installs (regular and encrypted) in a VM. The two bugs I found were old (not regressions) and minor. And I saw that all test cases were passed for 32-bit.
<mparillo> And no bugs at all for 32-bit.
<infinity> tsimonq2: Err, wat?
<infinity> tsimonq2: Why on earth would we do updates then a no-change rebuild for security?
<infinity> tsimonq2: ubuntu-security-proposed exists for this very reason.
<infinity> sarnold: ^
<tsimonq2> infinity: To get testing, release to -updates, and then rebuild against -security to prevent rebuildish regressions.
<infinity> tsimonq2: Right, but the ubuntu-security-proposed PPA is exactly for this.  We build in that PPA in a "security-clean" way, then copy to -proposed, where it can bake and get testing, then it can be released to both updates *and* proposed without having to rebuild and test all over.
<infinity> Err, both updates and security, I mean.
<tsimonq2> infinity: Ah, got it. Could you button press there since you're an AA?
<infinity> It's daft to do a security release to updates and then rebuild for security.  That invalidates all the testing you did in proposed the first time around.
<tsimonq2> (I'm generally assuming you need AA powers to copy from a PPA to -proposed.)
<infinity> tsimonq2: Being an AA doesn't do much for me there, but I'm also a member of the security team so yes. :P
<tsimonq2> infinity: OK.
<infinity> tsimonq2: By which I mean I need to be a member of the security team to use their PPA.  Literally anyone with upload rights can copy from PPAs to the queue.
<infinity> Though they generally shouldn't.
<tsimonq2> infinity: To the queue, but does that include binaries?
<infinity> It does if you tell copy_package to do so.
<tsimonq2> I also thought that was only a thing private PPAs and Bileto could do.
<tsimonq2> So, TIO.
<tsimonq2> s/TIO/TIL/
<infinity> It's a thing any appropriately-configured PPA can do.
<infinity> Of which there aren't many, to be fair.
<tsimonq2> What qualifies a PPA?
<tsimonq2> Just "it builds against the right things"?
<infinity> Being configured the same way as the primary archive.
<tsimonq2> Got it.
<infinity> Devirt, debug symbols, etc.
<infinity> Not that "devirt" means anything these days, as all our builders are virt, but we still use the flag to mean "build stuff the same as PRIMARY", so it's meaningful in the copy case. :P
<tsimonq2> infinity: I ask because in the next couple of weeks I'll be trying to find a victim^MSRU team member to help me land Qt 5.9.6 via SRU, so all of this is good to know. :P
<tsimonq2> I might just use Bileto.
<infinity> tsimonq2: Err, you're doing an ABI transition in an SRU?
<tsimonq2> infinity: That isn't needed if we mangle it just right.
<infinity> tsimonq2: Well, if it's not a transition, then I don't see why it needs to be done as a single "transaction" via a PPA/bileto.
<infinity> tsimonq2: If the uploads can be processed in any order, please don't use binary copies.
<tsimonq2> infinity: OK.
<infinity> tsimonq2: I mean, you can still prep it in a PPA to make sure you got it right, but then upload the sources normally to the queue.  It'll be much less painful for us to review and deal with.
<tsimonq2> infinity: In that case, I might do some testing in Bileto before landing, then use copy-package to only copy sources over and then delete the PPA.
<tsimonq2> infinity: So, basically what you just said, but s/manually upload/copy-package/.
<infinity> tsimonq2: Don't use copy-package at all.  Just upload the sources.
<infinity> tsimonq2: copied sources are opaque queue objects, not source packages.  Which means hunting down the origin and dealing with it in the PPA.
<tsimonq2> infinity: Makes sense.
<infinity> tsimonq2: Yes, all wonderful infra bugs on our side, but Very Hard to fix, so I'd prefer not to be exposed to them in the first place. :P
<tsimonq2> infinity: :P
<tsimonq2> infinity: In this case, I was also going to talk to the Security Team more about landing qtwebengine-opensource-src 5.9.6 via bionic-security.
<tsimonq2> infinity: It's fun in that it ships an embedded Chromium.
<tsimonq2> (It also takes anywhere between 12 and 24 hours to build, depending on the arch. :P)
<xnox> tsimonq2, i mean, if you don't embed chromium, are you even writting software?!
<xnox> =)))))))))))))))))))
<tsimonq2> xnox: True. >:D
<tsimonq2> xnox: "Oh, I just wrote this hello world program, but it takes literally five days to build because it embeds yet another copy of Chromium." :P
-queuebot:#ubuntu-release- Unapproved: rax-nova-agent (bionic-proposed/main) [2.1.13-0ubuntu3 => 2.1.15-0ubuntu1~18.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: util-linux (bionic-proposed/main) [2.31.1-0.4ubuntu3.1 => 2.31.1-0.4ubuntu3.2] (core)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Bionic 18.04.1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Bionic 18.04.1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Bionic 18.04.1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Bionic 18.04.1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Bionic 18.04.1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Bionic 18.04.1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Bionic 18.04.1] has been marked as ready
<sarnold> infinity: <3 thanks
<tsimonq2> Hey sarnold.
<sarnold> hey tsimonq2 :)
<tsimonq2> Hm, is it in the private security PPA? I don't see it in the public one.
<infinity> sarnold: It's in neither?
<infinity> Unless someone uploaded it.  I didn't.
<sarnold> there's only one package in the private security ppa, an embargoed update
<tsimonq2> Ah, I thought you said you would, infinity.
<infinity> That doesn't mean I did!
<infinity> I'm working on the point release.
<tsimonq2> Ah, OK. No problem.
<infinity> tsimonq2: The vlc in the queue?
<tsimonq2> infinity: That, yep.
<tsimonq2> infinity: The one with the uniquely-named orig tar. :P
<tsimonq2> (They decided to do 3.0.3-1 upstream instead of 3.0.3.1, sigh.)
 * infinity shivers at the version of VLC in cosmic...
<infinity> 3.0.3-1-2
<infinity> Well job.
<tsimonq2> Â¯\_(ã)_/Â¯
<infinity> tsimonq2: Upstream being silly is no excuse for downstream repeating the silliness.  Files can be renamed. :P
<infinity> But since Debian already did it, oh well.
<infinity> tsimonq2: https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages
<tsimonq2> infinity: Thanks.
<tsimonq2> infinity: I'll do copy-package stuff when it's built.
-queuebot:#ubuntu-release- Unapproved: rejected vlc [source] (bionic-proposed) [3.0.3-1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: vlc (bionic-proposed/universe) [3.0.2-0ubuntu0.1 => 3.0.3-1-1ubuntu1] (kubuntu, mozilla) (sync)
-queuebot:#ubuntu-release- Builds: 31 entries have been added, updated or disabled
<tsimonq2> bdmurray, sil2100: Could the vlc SRU please be reviewed today, so it doesn't have to wait until Monday?
<bdmurray> tsimonq2: reviewed for releasing to -updates? for what release?
<tsimonq2> bdmurray: Review to go into -proposed.
<tsimonq2> bdmurray: Bionuc.
<tsimonq2> *Bionic
<bdmurray> that could happen on Friday
<tsimonq2> The only problem is it then has to wait until Aug 6th to get released.
<tsimonq2> Unless it's released a day early.
<fossfreedom> infinity, just seen the release announcement - the link https://www.ubuntu.com/community/get-involved returns a 404
<infinity> fossfreedom: Fixing server-side...
* infinity changed the topic of #ubuntu-release to: Released: Xenial 16.04.4, Bionic 18.04.1 | Archive: open | Cosmic 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
-queuebot:#ubuntu-release- Unapproved: cockpit (bionic-backports/universe) [172-1~ubuntu18.04.1 => 173-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (bionic-backports) [173-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: cockpit (xenial-backports/universe) [172-1~ubuntu16.04.1 => 173-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (xenial-backports) [173-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New binary: cockpit [s390x] (bionic-backports/universe) [173-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [amd64] (bionic-backports/universe) [173-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [ppc64el] (bionic-backports/universe) [173-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [s390x] (xenial-backports/universe) [173-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [ppc64el] (xenial-backports/universe) [173-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [amd64] (xenial-backports/universe) [173-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [powerpc] (xenial-backports/universe) [173-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [i386] (bionic-backports/universe) [173-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [i386] (xenial-backports/universe) [173-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [arm64] (bionic-backports/universe) [173-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [armhf] (bionic-backports/universe) [173-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [arm64] (xenial-backports/universe) [173-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [armhf] (xenial-backports/universe) [173-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: jitterentropy-rngd [ppc64el] (cosmic-proposed/none) [1.0.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jp [ppc64el] (cosmic-proposed/none) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jitterentropy-rngd [s390x] (cosmic-proposed/none) [1.0.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jp [s390x] (cosmic-proposed/none) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-iwlib [s390x] (cosmic-proposed/none) [0.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-encoding-rs [ppc64el] (cosmic-proposed/none) [0.8.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ppx-tools-versioned [s390x] (cosmic-proposed/none) [5.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-encoding-rs [s390x] (cosmic-proposed/none) [0.8.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fwupdate [amd64] (cosmic-proposed/main) [12-1] (core)
-queuebot:#ubuntu-release- New binary: jitterentropy-rngd [amd64] (cosmic-proposed/none) [1.0.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-zyedidia-clipboard [amd64] (cosmic-proposed/none) [0.0~git20180718.bd31d74-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fwupdate [arm64] (cosmic-proposed/main) [12-1] (core)
-queuebot:#ubuntu-release- New binary: haskell-iwlib [ppc64el] (cosmic-proposed/universe) [0.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: lektor [amd64] (cosmic-proposed/universe) [3.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fwupdate [i386] (cosmic-proposed/main) [12-1] (core)
-queuebot:#ubuntu-release- New binary: haskell-lzma [s390x] (cosmic-proposed/universe) [0.0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pgzero [amd64] (cosmic-proposed/universe) [1.2.post4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-nodrop [s390x] (cosmic-proposed/universe) [0.1.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-nodrop [ppc64el] (cosmic-proposed/universe) [0.1.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fwupd [i386] (cosmic-proposed/main) [1.1.0-1] (desktop-core)
-queuebot:#ubuntu-release- New binary: haskell-iwlib [i386] (cosmic-proposed/universe) [0.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-num-integer [ppc64el] (cosmic-proposed/universe) [0.1.39-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-iwlib [amd64] (cosmic-proposed/universe) [0.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-ipfix [amd64] (cosmic-proposed/universe) [0.9.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fwupd [amd64] (cosmic-proposed/main) [1.1.0-1] (desktop-core)
-queuebot:#ubuntu-release- New binary: jp [amd64] (cosmic-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-num-integer [s390x] (cosmic-proposed/universe) [0.1.39-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-regex [s390x] (cosmic-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-scoped-tls [s390x] (cosmic-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jitterentropy-rngd [i386] (cosmic-proposed/universe) [1.0.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-regex [ppc64el] (cosmic-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-strsim [s390x] (cosmic-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jp [i386] (cosmic-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-same-file [s390x] (cosmic-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-same-file [ppc64el] (cosmic-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-scoped-tls [ppc64el] (cosmic-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-scoped-tls [amd64] (cosmic-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-strsim [ppc64el] (cosmic-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fwupd [armhf] (cosmic-proposed/main) [1.1.0-1] (desktop-core)
-queuebot:#ubuntu-release- New binary: rust-encoding-rs [amd64] (cosmic-proposed/universe) [0.8.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-num-integer [i386] (cosmic-proposed/universe) [0.1.39-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ppx-tools-versioned [ppc64el] (cosmic-proposed/universe) [5.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-encoding-rs [i386] (cosmic-proposed/universe) [0.8.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-nodrop [amd64] (cosmic-proposed/universe) [0.1.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-regex [i386] (cosmic-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-regex [amd64] (cosmic-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-scoped-tls [i386] (cosmic-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fwupd [arm64] (cosmic-proposed/main) [1.1.0-1] (desktop-core)
-queuebot:#ubuntu-release- New binary: libfortran-format-perl [amd64] (cosmic-proposed/universe) [0.90-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-num-integer [amd64] (cosmic-proposed/universe) [0.1.39-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-strsim [amd64] (cosmic-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-lzma [ppc64el] (cosmic-proposed/universe) [0.0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-same-file [amd64] (cosmic-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-morph [amd64] (cosmic-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-strsim [i386] (cosmic-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-lzma [amd64] (cosmic-proposed/universe) [0.0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ppx-tools-versioned [amd64] (cosmic-proposed/universe) [5.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-same-file [i386] (cosmic-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-lzma [i386] (cosmic-proposed/universe) [0.0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: weevely [amd64] (cosmic-proposed/universe) [3.6.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-nodrop [i386] (cosmic-proposed/universe) [0.1.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ppx-tools-versioned [i386] (cosmic-proposed/universe) [5.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jitterentropy-rngd [arm64] (cosmic-proposed/universe) [1.0.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jitterentropy-rngd [armhf] (cosmic-proposed/universe) [1.0.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-iwlib [arm64] (cosmic-proposed/universe) [0.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: jp [arm64] (cosmic-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-iwlib [armhf] (cosmic-proposed/universe) [0.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: jp [armhf] (cosmic-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-encoding-rs [arm64] (cosmic-proposed/universe) [0.8.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-nodrop [armhf] (cosmic-proposed/universe) [0.1.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-num-integer [armhf] (cosmic-proposed/universe) [0.1.39-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-nodrop [arm64] (cosmic-proposed/universe) [0.1.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-num-integer [arm64] (cosmic-proposed/universe) [0.1.39-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-encoding-rs [armhf] (cosmic-proposed/universe) [0.8.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-same-file [armhf] (cosmic-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-same-file [arm64] (cosmic-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-scoped-tls [arm64] (cosmic-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-regex [arm64] (cosmic-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-regex [armhf] (cosmic-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-scoped-tls [armhf] (cosmic-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-strsim [arm64] (cosmic-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ppx-tools-versioned [arm64] (cosmic-proposed/universe) [5.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-strsim [armhf] (cosmic-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ppx-tools-versioned [armhf] (cosmic-proposed/universe) [5.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-lzma [arm64] (cosmic-proposed/universe) [0.0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-lzma [armhf] (cosmic-proposed/universe) [0.0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-iwlib [arm64] (cosmic-proposed) [0.1.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-lzma [arm64] (cosmic-proposed) [0.0.0.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-lzma [i386] (cosmic-proposed) [0.0.0.3-1]
-queuebot:#ubuntu-release- New binary: golang-github-zyedidia-clipboard [amd64] (cosmic-proposed/universe) [0.0~git20180718.bd31d74-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jitterentropy-rngd [amd64] (cosmic-proposed/universe) [1.0.8-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-iwlib [armhf] (cosmic-proposed) [0.1.0-2]
-queuebot:#ubuntu-release- New binary: fwupdate [amd64] (cosmic-proposed/main) [12-1] (core)
-queuebot:#ubuntu-release- New binary: rust-encoding-rs [ppc64el] (cosmic-proposed/universe) [0.8.4-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-lzma [armhf] (cosmic-proposed) [0.0.0.3-1]
-queuebot:#ubuntu-release- New binary: haskell-iwlib [s390x] (cosmic-proposed/universe) [0.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-iwlib [amd64] (cosmic-proposed) [0.1.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-iwlib [ppc64el] (cosmic-proposed) [0.1.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-lzma [amd64] (cosmic-proposed) [0.0.0.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-lzma [s390x] (cosmic-proposed) [0.0.0.3-1]
-queuebot:#ubuntu-release- New binary: jitterentropy-rngd [s390x] (cosmic-proposed/universe) [1.0.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jp [s390x] (cosmic-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ppx-tools-versioned [s390x] (cosmic-proposed/universe) [5.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-iwlib [i386] (cosmic-proposed) [0.1.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-lzma [ppc64el] (cosmic-proposed) [0.0.0.3-1]
-queuebot:#ubuntu-release- New binary: jp [ppc64el] (cosmic-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-encoding-rs [s390x] (cosmic-proposed/universe) [0.8.4-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-iwlib [s390x] (cosmic-proposed) [0.1.0-2]
-queuebot:#ubuntu-release- New source: kubernetes (cosmic-proposed/primary) [1.0]
-queuebot:#ubuntu-release- New binary: jitterentropy-rngd [ppc64el] (cosmic-proposed/universe) [1.0.8-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-encoding-rs [amd64] (cosmic-proposed) [0.8.4-1]
-queuebot:#ubuntu-release- New: accepted rust-encoding-rs [armhf] (cosmic-proposed) [0.8.4-1]
-queuebot:#ubuntu-release- New: accepted rust-nodrop [amd64] (cosmic-proposed) [0.1.12-1]
-queuebot:#ubuntu-release- New: accepted rust-nodrop [armhf] (cosmic-proposed) [0.1.12-1]
-queuebot:#ubuntu-release- New: accepted rust-num-integer [amd64] (cosmic-proposed) [0.1.39-1]
-queuebot:#ubuntu-release- New: accepted rust-num-integer [armhf] (cosmic-proposed) [0.1.39-1]
-queuebot:#ubuntu-release- New: accepted rust-regex [amd64] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-regex [armhf] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-same-file [amd64] (cosmic-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted rust-same-file [armhf] (cosmic-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted rust-encoding-rs [arm64] (cosmic-proposed) [0.8.4-1]
-queuebot:#ubuntu-release- New: accepted rust-nodrop [arm64] (cosmic-proposed) [0.1.12-1]
-queuebot:#ubuntu-release- New: accepted rust-num-integer [arm64] (cosmic-proposed) [0.1.39-1]
-queuebot:#ubuntu-release- New: accepted rust-regex [arm64] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-same-file [arm64] (cosmic-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted rust-scoped-tls [amd64] (cosmic-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted rust-scoped-tls [armhf] (cosmic-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted rust-scoped-tls [ppc64el] (cosmic-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted rust-strsim [arm64] (cosmic-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-strsim [i386] (cosmic-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-encoding-rs [i386] (cosmic-proposed) [0.8.4-1]
-queuebot:#ubuntu-release- New: accepted rust-num-integer [i386] (cosmic-proposed) [0.1.39-1]
-queuebot:#ubuntu-release- New: accepted rust-same-file [i386] (cosmic-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted rust-scoped-tls [i386] (cosmic-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted rust-strsim [armhf] (cosmic-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-nodrop [i386] (cosmic-proposed) [0.1.12-1]
-queuebot:#ubuntu-release- New: accepted rust-scoped-tls [arm64] (cosmic-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted rust-strsim [ppc64el] (cosmic-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-regex [i386] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-strsim [amd64] (cosmic-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-encoding-rs [ppc64el] (cosmic-proposed) [0.8.4-1]
-queuebot:#ubuntu-release- New: accepted rust-nodrop [ppc64el] (cosmic-proposed) [0.1.12-1]
-queuebot:#ubuntu-release- New: accepted rust-num-integer [ppc64el] (cosmic-proposed) [0.1.39-1]
-queuebot:#ubuntu-release- New: accepted rust-regex [ppc64el] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-same-file [ppc64el] (cosmic-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted rust-scoped-tls [s390x] (cosmic-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted rust-encoding-rs [s390x] (cosmic-proposed) [0.8.4-1]
-queuebot:#ubuntu-release- New: accepted rust-num-integer [s390x] (cosmic-proposed) [0.1.39-1]
-queuebot:#ubuntu-release- New: accepted rust-same-file [s390x] (cosmic-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted rust-nodrop [s390x] (cosmic-proposed) [0.1.12-1]
-queuebot:#ubuntu-release- New: accepted rust-strsim [s390x] (cosmic-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-regex [s390x] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted fwupd [amd64] (cosmic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted fwupd [armhf] (cosmic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted fwupdate [amd64] (cosmic-proposed) [12-1]
-queuebot:#ubuntu-release- New: accepted fwupdate [i386] (cosmic-proposed) [12-1]
-queuebot:#ubuntu-release- New: accepted fwupd [arm64] (cosmic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted fwupdate [arm64] (cosmic-proposed) [12-1]
-queuebot:#ubuntu-release- New: accepted fwupd [i386] (cosmic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted jp [amd64] (cosmic-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted jp [armhf] (cosmic-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted jp [ppc64el] (cosmic-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted ppx-tools-versioned [amd64] (cosmic-proposed) [5.2-1]
-queuebot:#ubuntu-release- New: accepted ppx-tools-versioned [armhf] (cosmic-proposed) [5.2-1]
-queuebot:#ubuntu-release- New: accepted ppx-tools-versioned [ppc64el] (cosmic-proposed) [5.2-1]
-queuebot:#ubuntu-release- New: accepted jp [arm64] (cosmic-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted jp [s390x] (cosmic-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted ppx-tools-versioned [i386] (cosmic-proposed) [5.2-1]
-queuebot:#ubuntu-release- New: accepted jp [i386] (cosmic-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted ppx-tools-versioned [s390x] (cosmic-proposed) [5.2-1]
-queuebot:#ubuntu-release- New: accepted ppx-tools-versioned [arm64] (cosmic-proposed) [5.2-1]
-queuebot:#ubuntu-release- New: accepted jitterentropy-rngd [amd64] (cosmic-proposed) [1.0.8-1]
-queuebot:#ubuntu-release- New: accepted jitterentropy-rngd [armhf] (cosmic-proposed) [1.0.8-1]
-queuebot:#ubuntu-release- New: accepted jitterentropy-rngd [ppc64el] (cosmic-proposed) [1.0.8-1]
-queuebot:#ubuntu-release- New: accepted jitterentropy-rngd [arm64] (cosmic-proposed) [1.0.8-1]
-queuebot:#ubuntu-release- New: accepted jitterentropy-rngd [s390x] (cosmic-proposed) [1.0.8-1]
-queuebot:#ubuntu-release- New: accepted jitterentropy-rngd [i386] (cosmic-proposed) [1.0.8-1]
-queuebot:#ubuntu-release- New: accepted golang-github-zyedidia-clipboard [amd64] (cosmic-proposed) [0.0~git20180718.bd31d74-1]
-queuebot:#ubuntu-release- New: accepted libfortran-format-perl [amd64] (cosmic-proposed) [0.90-1]
-queuebot:#ubuntu-release- New: accepted python-ipfix [amd64] (cosmic-proposed) [0.9.7-1]
-queuebot:#ubuntu-release- New: accepted weevely [amd64] (cosmic-proposed) [3.6.2-1]
-queuebot:#ubuntu-release- New: accepted lektor [amd64] (cosmic-proposed) [3.1.1-1]
-queuebot:#ubuntu-release- New: accepted python-morph [amd64] (cosmic-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted pgzero [amd64] (cosmic-proposed) [1.2.post4+dfsg-1]
#ubuntu-release 2018-07-27
-queuebot:#ubuntu-release- Unapproved: accepted vlc [sync] (bionic-proposed) [3.0.3-1-1ubuntu1]
<LocutusOfBorg> good morning release team, what is your opinion wrt removing flint-arb and sagemath on armhf?
<LocutusOfBorg> apw, ^^ they are FTBFS on armhf in Debian too, not easy fix
<rbalint> tjaalton, could you please accept rax-nova-agent to bionic-proposed in today's sru round?
<LocutusOfBorg> tsimonq2, software-properties needs some MIRing?
<LocutusOfBorg> oh... somebody seems to have wrongly accepted software-properties :)
<LocutusOfBorg> software-properties-qt replaces software-properties-kde, the former has been accepted in main, while the latter was in universe... can any AA please move the binary?
<LocutusOfBorg> so, today requests are: 1) move software-properties-qt BINARY to universe 2) flint-arb and sagemath removals on armhf (they might come back eventually if somebody fixes the armhf aligment issues, there is a new release out that is going in debian new soon, but sagemath needs porting 3) kick out from release the following packages php-net-ldap2 php-net-ldap3 simpleid-ldap php-mochery and enjoy the phpunit migration (and
<LocutusOfBorg> symphony is now testsuite fixed!)
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (xenial-proposed) [20101020ubuntu451.24]
<infinity> LocutusOfBorg: software-properties-qt overridden to universe, not going to process the rest of that laundry list between now and when I get on a plane. :P
<Ukikie> infinity: Try it while on the plane, I hear the wifi is very stable!
<doko_> sil2100, apw: please update the version for the linux/s390x badtest
<apw> doko_, ack
<apw> doko_, and done
<tjaalton> rbalint: i'm off today
<rbalint> tjaalton, ah, sorry, thanks
<LocutusOfBorg> infinity, have a nice trip! and thanks for 1) :)
<rbalint> then slangasek, please take a look at rax-nova-agent in bionic unapproved and pyxs in xenial-proposed as part of the sru round
<LocutusOfBorg> apw, maybe I can ping you for 2) and 3) ?
<apw> LocutusOfBorg, if notone gets to it before me
-queuebot:#ubuntu-release- Unapproved: util-linux (bionic-proposed/main) [2.31.1-0.4ubuntu3.1 => 2.31.1-0.4ubuntu3.2] (core)
-queuebot:#ubuntu-release- Unapproved: rejected util-linux [source] (bionic-proposed) [2.31.1-0.4ubuntu3.2]
-queuebot:#ubuntu-release- Unapproved: accepted util-linux [source] (bionic-proposed) [2.31.1-0.4ubuntu3.2]
-queuebot:#ubuntu-release- Unapproved: debian-installer (xenial-proposed/main) [20101020ubuntu451.24 => 20101020ubuntu451.25] (core)
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (xenial-proposed) [20101020ubuntu451.25]
<ginggs> would someone please 'force-badtest cmake-extras/1.3+17.04.20170310-1ubuntu4/ppc64el' ? i believe it has regressed in release
-queuebot:#ubuntu-release- New binary: libattribute-storage-perl [ppc64el] (cosmic-proposed/none) [0.09-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libredis-fast-perl [ppc64el] (cosmic-proposed/none) [0.21-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libstring-tagged-perl [amd64] (cosmic-proposed/none) [0.15-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libattribute-storage-perl [s390x] (cosmic-proposed/none) [0.09-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-csv [s390x] (cosmic-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libredis-fast-perl [s390x] (cosmic-proposed/none) [0.21-3] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-csv [ppc64el] (cosmic-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libattribute-storage-perl [amd64] (cosmic-proposed/none) [0.09-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbio-tools-run-alignment-clustalw-perl [amd64] (cosmic-proposed/none) [1.7.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libfile-copy-recursive-reduced-perl [amd64] (cosmic-proposed/none) [0.006-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libnet-async-irc-perl [amd64] (cosmic-proposed/none) [0.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libnet-cidr-set-perl [amd64] (cosmic-proposed/none) [0.13-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libppix-quotelike-perl [amd64] (cosmic-proposed/none) [0.006-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libredis-fast-perl [i386] (cosmic-proposed/none) [0.21-3] (no packageset)
-queuebot:#ubuntu-release- New binary: python-lupa [s390x] (cosmic-proposed/universe) [1.6+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libattribute-storage-perl [i386] (cosmic-proposed/none) [0.09-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmodule-build-pluggable-perl [amd64] (cosmic-proposed/none) [0.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libperl-critic-policy-variables-prohibitlooponhash-perl [amd64] (cosmic-proposed/none) [0.005-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libuuid-urandom-perl [amd64] (cosmic-proposed/none) [0.001-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbio-tools-run-alignment-tcoffee-perl [amd64] (cosmic-proposed/none) [1.7.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libredis-fast-perl [amd64] (cosmic-proposed/none) [0.21-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libnet-async-tangence-perl [amd64] (cosmic-proposed/none) [0.14-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-lupa [amd64] (cosmic-proposed/universe) [1.6+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-csv [i386] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-lupa [i386] (cosmic-proposed/universe) [1.6+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: emacs-pod-mode [amd64] (cosmic-proposed/universe) [1.03-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-csv [amd64] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libredis-fast-perl [arm64] (cosmic-proposed/universe) [0.21-3] (no packageset)
-queuebot:#ubuntu-release- New binary: python-lupa [arm64] (cosmic-proposed/universe) [1.6+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libredis-fast-perl [armhf] (cosmic-proposed/universe) [0.21-3] (no packageset)
-queuebot:#ubuntu-release- New binary: python-lupa [armhf] (cosmic-proposed/universe) [1.6+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libattribute-storage-perl [arm64] (cosmic-proposed/universe) [0.09-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-csv [armhf] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-csv [arm64] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libattribute-storage-perl [armhf] (cosmic-proposed/universe) [0.09-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted emacs-pod-mode [amd64] (cosmic-proposed) [1.03-1]
-queuebot:#ubuntu-release- New: accepted libattribute-storage-perl [arm64] (cosmic-proposed) [0.09-1]
-queuebot:#ubuntu-release- New: accepted libattribute-storage-perl [i386] (cosmic-proposed) [0.09-1]
-queuebot:#ubuntu-release- New: accepted libattribute-storage-perl [s390x] (cosmic-proposed) [0.09-1]
-queuebot:#ubuntu-release- New: accepted libbio-tools-run-alignment-tcoffee-perl [amd64] (cosmic-proposed) [1.7.4-1]
-queuebot:#ubuntu-release- New: accepted libattribute-storage-perl [amd64] (cosmic-proposed) [0.09-1]
-queuebot:#ubuntu-release- New: accepted libattribute-storage-perl [ppc64el] (cosmic-proposed) [0.09-1]
-queuebot:#ubuntu-release- New: accepted libattribute-storage-perl [armhf] (cosmic-proposed) [0.09-1]
-queuebot:#ubuntu-release- New: accepted libbio-tools-run-alignment-clustalw-perl [amd64] (cosmic-proposed) [1.7.4-1]
-queuebot:#ubuntu-release- New: accepted libfile-copy-recursive-reduced-perl [amd64] (cosmic-proposed) [0.006-1]
-queuebot:#ubuntu-release- New: accepted libmodule-build-pluggable-perl [amd64] (cosmic-proposed) [0.10-1]
-queuebot:#ubuntu-release- New: accepted libnet-async-irc-perl [amd64] (cosmic-proposed) [0.11-1]
-queuebot:#ubuntu-release- New: accepted libnet-cidr-set-perl [amd64] (cosmic-proposed) [0.13-1]
-queuebot:#ubuntu-release- New: accepted libppix-quotelike-perl [amd64] (cosmic-proposed) [0.006-1]
-queuebot:#ubuntu-release- New: accepted libnet-async-tangence-perl [amd64] (cosmic-proposed) [0.14-1]
-queuebot:#ubuntu-release- New: accepted libperl-critic-policy-variables-prohibitlooponhash-perl [amd64] (cosmic-proposed) [0.005-1]
-queuebot:#ubuntu-release- New: accepted libredis-fast-perl [amd64] (cosmic-proposed) [0.21-3]
-queuebot:#ubuntu-release- New: accepted libredis-fast-perl [armhf] (cosmic-proposed) [0.21-3]
-queuebot:#ubuntu-release- New: accepted libredis-fast-perl [ppc64el] (cosmic-proposed) [0.21-3]
-queuebot:#ubuntu-release- New: accepted libredis-fast-perl [arm64] (cosmic-proposed) [0.21-3]
-queuebot:#ubuntu-release- New: accepted libredis-fast-perl [s390x] (cosmic-proposed) [0.21-3]
-queuebot:#ubuntu-release- New: accepted libredis-fast-perl [i386] (cosmic-proposed) [0.21-3]
-queuebot:#ubuntu-release- New: accepted libstring-tagged-perl [amd64] (cosmic-proposed) [0.15-1]
-queuebot:#ubuntu-release- New: accepted rust-csv [amd64] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-csv [armhf] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-csv [ppc64el] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted libuuid-urandom-perl [amd64] (cosmic-proposed) [0.001-1]
-queuebot:#ubuntu-release- New: accepted rust-csv [i386] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-csv [arm64] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-csv [s390x] (cosmic-proposed) [1.0.0-1]
<xnox> Laney, v239 systemd passes all tests on amd64, on armhf-in-lxd-on-arm64 etc.... if one disable apparmor confinement or has old kernel.
<xnox> Laney, apparmor fixes are in progress, hence systemd is currently blocked-proposed.
<xnox> this is all cosmic (host, lxd, guest)
<doko_> apw: please could you have a look at the linux/arm64 autopkg test triggered by python3-defaults?
<apw> doko_, ack
<apw> doko_, if i am reading the logs correctly ... then i think both the py2 and py3 variants of that test are failing when doing a check on python2 and comparing it unfavourably to python2.7
<LocutusOfBorg> apw, how would you feel if I request to drop camitk binaries from everywhere except amd64 and i386? Debian never enabled such architectures, and I strongly think that insighttoolkit4 should only build where testsuite passes, and disabling testsuite just to make it build hides errors, that might be not tolerable on some use-cases (specially where ITK is used)
<LocutusOfBorg> upstream is willing to accept patches, but nobody is really working on itk4 port
<LocutusOfBorg> so, I would drop itk4 and reverse deps from all except amd64 and i386.
<LocutusOfBorg> now camitk fails testsuite, and I'm not really in the mood of "disable stuff for a first build" and then keep testsuite disabled forever (like we did with itk4)
-queuebot:#ubuntu-release- Unapproved: rejected linux-base [source] (trusty-proposed) [4.5ubuntu1~14.04.1]
<apw> doko_, ok so that is meant to be resolved, so you could just rerun that one, and expect it to go green
<slangasek> rbalint: I saw there had been discussion about an SRE for rax-nova-agent; I don't see that one has been approved yet, and part of the process of approving is to make sure a "generic" SRU test case is sufficient to catch problems.  I would really like an explanation here of the specific problem being solved by changing the systemd unit dependencies
-queuebot:#ubuntu-release- Unapproved: vala (bionic-proposed/universe) [0.40.4-1 => 0.40.8-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: rust-arrayvec [s390x] (cosmic-proposed/none) [0.4.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-shared-child [s390x] (cosmic-proposed/none) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lief [s390x] (cosmic-proposed/none) [0.8.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: lightbeam [amd64] (cosmic-proposed/universe) [2.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-arrayvec [amd64] (cosmic-proposed/none) [0.4.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-arrayvec [i386] (cosmic-proposed/none) [0.4.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-shared-child [i386] (cosmic-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-shared-child [amd64] (cosmic-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-arrayvec [ppc64el] (cosmic-proposed/universe) [0.4.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-shared-child [ppc64el] (cosmic-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lief [amd64] (cosmic-proposed/universe) [0.8.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: lief [i386] (cosmic-proposed/universe) [0.8.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-arrayvec [arm64] (cosmic-proposed/universe) [0.4.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-arrayvec [armhf] (cosmic-proposed/universe) [0.4.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-shared-child [armhf] (cosmic-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-shared-child [arm64] (cosmic-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lief [arm64] (cosmic-proposed/universe) [0.8.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: lief [armhf] (cosmic-proposed/universe) [0.8.3-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted lief [amd64] (cosmic-proposed) [0.8.3-3]
-queuebot:#ubuntu-release- New: accepted lief [armhf] (cosmic-proposed) [0.8.3-3]
-queuebot:#ubuntu-release- New: accepted lief [s390x] (cosmic-proposed) [0.8.3-3]
-queuebot:#ubuntu-release- New: accepted lief [arm64] (cosmic-proposed) [0.8.3-3]
-queuebot:#ubuntu-release- New: accepted lief [i386] (cosmic-proposed) [0.8.3-3]
-queuebot:#ubuntu-release- New: accepted rust-shared-child [amd64] (cosmic-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted rust-shared-child [armhf] (cosmic-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted rust-shared-child [ppc64el] (cosmic-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted rust-shared-child [arm64] (cosmic-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted rust-shared-child [s390x] (cosmic-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted rust-shared-child [i386] (cosmic-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted lightbeam [amd64] (cosmic-proposed) [2.1.0-2]
-queuebot:#ubuntu-release- New: accepted rust-arrayvec [arm64] (cosmic-proposed) [0.4.7-1]
-queuebot:#ubuntu-release- New: accepted rust-arrayvec [i386] (cosmic-proposed) [0.4.7-1]
-queuebot:#ubuntu-release- New: accepted rust-arrayvec [s390x] (cosmic-proposed) [0.4.7-1]
-queuebot:#ubuntu-release- New: accepted rust-arrayvec [amd64] (cosmic-proposed) [0.4.7-1]
-queuebot:#ubuntu-release- New: accepted rust-arrayvec [ppc64el] (cosmic-proposed) [0.4.7-1]
-queuebot:#ubuntu-release- New: accepted rust-arrayvec [armhf] (cosmic-proposed) [0.4.7-1]
-queuebot:#ubuntu-release- New: accepted python-lupa [amd64] (cosmic-proposed) [1.6+dfsg-3]
-queuebot:#ubuntu-release- New: accepted python-lupa [armhf] (cosmic-proposed) [1.6+dfsg-3]
-queuebot:#ubuntu-release- New: accepted python-lupa [s390x] (cosmic-proposed) [1.6+dfsg-3]
-queuebot:#ubuntu-release- New: accepted python-lupa [arm64] (cosmic-proposed) [1.6+dfsg-3]
-queuebot:#ubuntu-release- New: accepted python-lupa [i386] (cosmic-proposed) [1.6+dfsg-3]
#ubuntu-release 2018-07-28
-queuebot:#ubuntu-release- Unapproved: accepted maas [source] (bionic-proposed) [2.4.0-6981-g011e51b7a-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- New binary: tabbar-el [amd64] (cosmic-proposed/none) [2.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted tabbar-el [amd64] (cosmic-proposed) [2.2-1]
-queuebot:#ubuntu-release- Unapproved: rejected ostree [source] (bionic-proposed) [2018.6-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted apache2 [source] (bionic-proposed) [2.4.29-1ubuntu4.3]
-queuebot:#ubuntu-release- Unapproved: accepted tomcat8 [source] (bionic-proposed) [8.5.30-1ubuntu1.3]
<ginggs> would someone please kick the can along 'force-badtest python-xarray/0.10.8-1/arm64' in stefanor's hints
 * tumbleweed can
<tumbleweed> ginggs: when does this can hit the wall?
<tumbleweed> also, we miss you at debconf :(
<ginggs> tumbleweed: i believe it's this https://github.com/numpy/numpy/issues/8325 (so not in xarray itself)
<gitlab-bot> numpy issue 8325 in numpy "np.nan incorrectly casted into datetime on powerpc, leading to failing tests of pandas" (comments: 28) [Open]
<ginggs> tumbleweed: i miss y'all too!
<ginggs> tumbleweed: and please 'force-badtest cmake-extras/1.3+17.04.20170310-1ubuntu4/ppc64el' - i believe the latest test shows it has regressed in release http://autopkgtest.ubuntu.com/packages/c/cmake-extras/cosmic/ppc64el
<tumbleweed> ginggs: xarray only on arm64?
<ginggs> tumbleweed: yes, the i386 was floating point precision, and seems fixed now
<rbalint> slangasek, the rax-nova-agent changes to systemd unit dependencies are due to upstream changes which made part of our patches obsolete and the agent seem to be working well in their cloud, matching their claims
<rbalint> slangasek, if needed i can add more explanation to the bug as well and the SRE is there for the package, indeed, but IMO it would be reasonable to approve one
<tumbleweed> ginggs: sorry, was doing some video stuff, but committed the bump now
<ginggs> tumbleweed: np, thanks!
<tumbleweed> do we know what's up with cmake-extras?
<tumbleweed> what regressed it?
<ginggs> tumbleweed: no ideas what caused it, but it wasn't googletest
<tumbleweed> ginggs: ok, committing a badtest
<ginggs> tumbleweed: thanks again!  we can probably blame doko for cmake-extras :p
<tumbleweed> he's here if you'd like me to apply the blame in person
-queuebot:#ubuntu-release- Unapproved: linux-base (trusty-proposed/main) [3.5ubuntu4 => 4.5ubuntu1~14.04.1] (core) (sync)
-queuebot:#ubuntu-release- New binary: golang-github-gdamore-encoding [amd64] (cosmic-proposed/none) [0.0~git20151215.b23993c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php-composer-xdebug-handler [amd64] (cosmic-proposed/none) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gmbal-commons [amd64] (cosmic-proposed/universe) [3.2.1-b003-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mimepull [amd64] (cosmic-proposed/universe) [1.9.7-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gmbal-commons [amd64] (cosmic-proposed) [3.2.1-b003-1]
-queuebot:#ubuntu-release- New: accepted mimepull [amd64] (cosmic-proposed) [1.9.7-1]
-queuebot:#ubuntu-release- New: accepted golang-github-gdamore-encoding [amd64] (cosmic-proposed) [0.0~git20151215.b23993c-1]
-queuebot:#ubuntu-release- New: accepted php-composer-xdebug-handler [amd64] (cosmic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New binary: gmbal [amd64] (cosmic-proposed/universe) [4.0.0-b002-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gmbal [amd64] (cosmic-proposed) [4.0.0-b002-1]
-queuebot:#ubuntu-release- New binary: bar-cursor-el [amd64] (cosmic-proposed/universe) [2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-git-lfs-gitobj [amd64] (cosmic-proposed/universe) [0.0~git20180705.5aa0c18-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-subtitles [s390x] (cosmic-proposed/universe) [1.4-1] (cli-mono)
-queuebot:#ubuntu-release- New binary: initsplit-el [amd64] (cosmic-proposed/universe) [1.8+3+gc941d43-1] (no packageset)
-queuebot:#ubuntu-release- New binary: eproject-el [amd64] (cosmic-proposed/universe) [1.5+git20180312.068218d-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-subtitles [ppc64el] (cosmic-proposed/universe) [1.4-1] (cli-mono)
-queuebot:#ubuntu-release- New binary: limesuite [s390x] (cosmic-proposed/universe) [18.06.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-subtitles [i386] (cosmic-proposed/universe) [1.4-1] (cli-mono)
-queuebot:#ubuntu-release- New binary: limesuite [amd64] (cosmic-proposed/universe) [18.06.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: limesuite [ppc64el] (cosmic-proposed/universe) [18.06.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-subtitles [amd64] (cosmic-proposed/universe) [1.4-1] (cli-mono)
-queuebot:#ubuntu-release- New binary: limesuite [i386] (cosmic-proposed/universe) [18.06.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: limesuite [armhf] (cosmic-proposed/universe) [18.06.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: limesuite [arm64] (cosmic-proposed/universe) [18.06.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-subtitles [arm64] (cosmic-proposed/universe) [1.4-1] (cli-mono)
-queuebot:#ubuntu-release- New binary: gnome-subtitles [armhf] (cosmic-proposed/universe) [1.4-1] (cli-mono)
-queuebot:#ubuntu-release- New: accepted bar-cursor-el [amd64] (cosmic-proposed) [2.0-1]
-queuebot:#ubuntu-release- New: accepted gnome-subtitles [amd64] (cosmic-proposed) [1.4-1]
-queuebot:#ubuntu-release- New: accepted gnome-subtitles [armhf] (cosmic-proposed) [1.4-1]
-queuebot:#ubuntu-release- New: accepted gnome-subtitles [ppc64el] (cosmic-proposed) [1.4-1]
-queuebot:#ubuntu-release- New: accepted golang-github-git-lfs-gitobj [amd64] (cosmic-proposed) [0.0~git20180705.5aa0c18-1]
-queuebot:#ubuntu-release- New: accepted limesuite [amd64] (cosmic-proposed) [18.06.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted limesuite [armhf] (cosmic-proposed) [18.06.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted limesuite [ppc64el] (cosmic-proposed) [18.06.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted eproject-el [amd64] (cosmic-proposed) [1.5+git20180312.068218d-1]
-queuebot:#ubuntu-release- New: accepted gnome-subtitles [i386] (cosmic-proposed) [1.4-1]
-queuebot:#ubuntu-release- New: accepted initsplit-el [amd64] (cosmic-proposed) [1.8+3+gc941d43-1]
-queuebot:#ubuntu-release- New: accepted limesuite [i386] (cosmic-proposed) [18.06.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted gnome-subtitles [arm64] (cosmic-proposed) [1.4-1]
-queuebot:#ubuntu-release- New: accepted limesuite [arm64] (cosmic-proposed) [18.06.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted gnome-subtitles [s390x] (cosmic-proposed) [1.4-1]
-queuebot:#ubuntu-release- New: accepted limesuite [s390x] (cosmic-proposed) [18.06.0+dfsg-1]
-queuebot:#ubuntu-release- New binary: libtickit-perl [s390x] (cosmic-proposed/universe) [0.65-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libcircle-be-perl [amd64] (cosmic-proposed/universe) [0.173320-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtickit-perl [i386] (cosmic-proposed/universe) [0.65-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libtickit-perl [amd64] (cosmic-proposed/universe) [0.65-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libtickit-perl [ppc64el] (cosmic-proposed/universe) [0.65-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libtickit-perl [arm64] (cosmic-proposed/universe) [0.65-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libtickit-perl [armhf] (cosmic-proposed/universe) [0.65-2] (no packageset)
#ubuntu-release 2018-07-29
-queuebot:#ubuntu-release- New: accepted libcircle-be-perl [amd64] (cosmic-proposed) [0.173320-1]
-queuebot:#ubuntu-release- New: accepted libtickit-perl [arm64] (cosmic-proposed) [0.65-2]
-queuebot:#ubuntu-release- New: accepted libtickit-perl [i386] (cosmic-proposed) [0.65-2]
-queuebot:#ubuntu-release- New: accepted libtickit-perl [s390x] (cosmic-proposed) [0.65-2]
-queuebot:#ubuntu-release- New: accepted libtickit-perl [amd64] (cosmic-proposed) [0.65-2]
-queuebot:#ubuntu-release- New: accepted libtickit-perl [ppc64el] (cosmic-proposed) [0.65-2]
-queuebot:#ubuntu-release- New: accepted libtickit-perl [armhf] (cosmic-proposed) [0.65-2]
-queuebot:#ubuntu-release- New binary: libtickit-async-perl [amd64] (cosmic-proposed/universe) [0.21-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libtickit-async-perl [amd64] (cosmic-proposed) [0.21-1]
-queuebot:#ubuntu-release- New binary: saaj [amd64] (cosmic-proposed/universe) [1.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted saaj [amd64] (cosmic-proposed) [1.4.0-2]
-queuebot:#ubuntu-release- New binary: jaxws-api [amd64] (cosmic-proposed/universe) [2.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted jaxws-api [amd64] (cosmic-proposed) [2.3.0-1]
<acheronuk> something wrong with auotests? seem to have quite a few stuck (possibly) having been running 10-12 hrs, when usually would run a 10th of that at most
<doko> I can't say that, the queue is empty, and I see these processed for new uploads
<acheronuk> doko: not sure if someone poked, or something auto kicked in, but all the ones which were hanging at 10-12 hrs eventually restarted their test runs from scratch
-queuebot:#ubuntu-release- New binary: pg-qualstats [ppc64el] (cosmic-proposed/none) [1.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-crossbeam-utils [s390x] (cosmic-proposed/none) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-memoffset [s390x] (cosmic-proposed/none) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-stat-kcache [ppc64el] (cosmic-proposed/none) [2.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-core [s390x] (cosmic-proposed/none) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-indexmap [s390x] (cosmic-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmodule-build-pluggable-ppport-perl [amd64] (cosmic-proposed/universe) [0.04-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-qualstats [i386] (cosmic-proposed/universe) [1.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-stat-kcache [i386] (cosmic-proposed/universe) [2.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cloudabi [arm64] (cosmic-proposed/universe) [0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cloudabi [ppc64el] (cosmic-proposed/universe) [0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-crossbeam-utils [armhf] (cosmic-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-crossbeam-utils [ppc64el] (cosmic-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-fuchsia-zircon [arm64] (cosmic-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-futures [i386] (cosmic-proposed/universe) [0.1.23-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-futures [s390x] (cosmic-proposed/universe) [0.1.23-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-qualstats [amd64] (cosmic-proposed/universe) [1.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cloudabi [amd64] (cosmic-proposed/universe) [0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cloudabi [s390x] (cosmic-proposed/universe) [0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-fuchsia-zircon [amd64] (cosmic-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-futures [ppc64el] (cosmic-proposed/universe) [0.1.23-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-humantime [s390x] (cosmic-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-indexmap [ppc64el] (cosmic-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-try-lock [amd64] (cosmic-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-stat-kcache [amd64] (cosmic-proposed/universe) [2.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-crossbeam-utils [i386] (cosmic-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-humantime [ppc64el] (cosmic-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-language-tags [s390x] (cosmic-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cloudabi [i386] (cosmic-proposed/universe) [0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-indexmap [amd64] (cosmic-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-futures [amd64] (cosmic-proposed/universe) [0.1.23-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtickit-widgets-perl [amd64] (cosmic-proposed/universe) [0.29-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cloudabi [armhf] (cosmic-proposed/universe) [0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-humantime [amd64] (cosmic-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-language-tags [amd64] (cosmic-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-memoffset [amd64] (cosmic-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-redox-termios [amd64] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-time [amd64] (cosmic-proposed/universe) [0.1.40-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-try-lock [i386] (cosmic-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pygtrie [amd64] (cosmic-proposed/universe) [2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-humantime [i386] (cosmic-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-memoffset [i386] (cosmic-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-time [i386] (cosmic-proposed/universe) [0.1.40-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-crossbeam-utils [arm64] (cosmic-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-redox-termios [i386] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-language-tags [i386] (cosmic-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unicode-bidi [i386] (cosmic-proposed/universe) [0.3.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-language-tags [ppc64el] (cosmic-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-memoffset [ppc64el] (cosmic-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libconvert-color-xterm-perl [amd64] (cosmic-proposed/universe) [0.05-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-stat-kcache [s390x] (cosmic-proposed/universe) [2.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-core [i386] (cosmic-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-try-lock [ppc64el] (cosmic-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unicode-bidi [amd64] (cosmic-proposed/universe) [0.3.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unicode-bidi [s390x] (cosmic-proposed/universe) [0.3.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-qualstats [s390x] (cosmic-proposed/universe) [1.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-core [ppc64el] (cosmic-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unicode-bidi [ppc64el] (cosmic-proposed/universe) [0.3.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-crossbeam-utils [amd64] (cosmic-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-try-lock [s390x] (cosmic-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-indexmap [i386] (cosmic-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-core [amd64] (cosmic-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-indexmap [arm64] (cosmic-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-futures [arm64] (cosmic-proposed/universe) [0.1.23-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-humantime [arm64] (cosmic-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-indexmap [armhf] (cosmic-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-language-tags [armhf] (cosmic-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-memoffset [armhf] (cosmic-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-core [armhf] (cosmic-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-futures [armhf] (cosmic-proposed/universe) [0.1.23-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-language-tags [arm64] (cosmic-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-core [arm64] (cosmic-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-humantime [armhf] (cosmic-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-memoffset [arm64] (cosmic-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-redox-termios [armhf] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-time [armhf] (cosmic-proposed/universe) [0.1.40-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-try-lock [armhf] (cosmic-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-try-lock [arm64] (cosmic-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unicode-bidi [arm64] (cosmic-proposed/universe) [0.3.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-qualstats [arm64] (cosmic-proposed/universe) [1.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-stat-kcache [arm64] (cosmic-proposed/universe) [2.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unicode-bidi [armhf] (cosmic-proposed/universe) [0.3.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-qualstats [armhf] (cosmic-proposed/universe) [1.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-stat-kcache [armhf] (cosmic-proposed/universe) [2.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted pg-qualstats [amd64] (cosmic-proposed) [1.0.5-1]
-queuebot:#ubuntu-release- New: accepted pg-stat-kcache [i386] (cosmic-proposed) [2.1.1-1]
-queuebot:#ubuntu-release- New: accepted pg-qualstats [ppc64el] (cosmic-proposed) [1.0.5-1]
-queuebot:#ubuntu-release- New: accepted pg-stat-kcache [ppc64el] (cosmic-proposed) [2.1.1-1]
-queuebot:#ubuntu-release- New: accepted libconvert-color-xterm-perl [amd64] (cosmic-proposed) [0.05-1]
-queuebot:#ubuntu-release- New: accepted pg-qualstats [armhf] (cosmic-proposed) [1.0.5-1]
-queuebot:#ubuntu-release- New: accepted pg-qualstats [s390x] (cosmic-proposed) [1.0.5-1]
-queuebot:#ubuntu-release- New: accepted pg-stat-kcache [arm64] (cosmic-proposed) [2.1.1-1]
-queuebot:#ubuntu-release- New: accepted pg-stat-kcache [s390x] (cosmic-proposed) [2.1.1-1]
-queuebot:#ubuntu-release- New source: kubernetes (cosmic-proposed/primary) [1.0]
-queuebot:#ubuntu-release- New binary: rust-crossbeam-utils [s390x] (cosmic-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-memoffset [s390x] (cosmic-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New source: vaultlocker (cosmic-proposed/primary) [1.0.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted pg-qualstats [arm64] (cosmic-proposed) [1.0.5-1]
-queuebot:#ubuntu-release- New: accepted pg-stat-kcache [amd64] (cosmic-proposed) [2.1.1-1]
-queuebot:#ubuntu-release- New source: hvac (cosmic-proposed/primary) [0.5.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: rust-indexmap [s390x] (cosmic-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted pg-qualstats [i386] (cosmic-proposed) [1.0.5-1]
-queuebot:#ubuntu-release- New binary: rust-cloudabi [s390x] (cosmic-proposed/universe) [0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted pg-stat-kcache [armhf] (cosmic-proposed) [2.1.1-1]
-queuebot:#ubuntu-release- New binary: rust-rand-core [s390x] (cosmic-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-crossbeam-utils [amd64] (cosmic-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted rust-futures [armhf] (cosmic-proposed) [0.1.23-1]
-queuebot:#ubuntu-release- New: accepted rust-humantime [armhf] (cosmic-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-indexmap [armhf] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-language-tags [arm64] (cosmic-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-language-tags [ppc64el] (cosmic-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-memoffset [armhf] (cosmic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-core [amd64] (cosmic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-core [armhf] (cosmic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-core [ppc64el] (cosmic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-futures [arm64] (cosmic-proposed) [0.1.23-1]
-queuebot:#ubuntu-release- New: accepted rust-indexmap [arm64] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-language-tags [armhf] (cosmic-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-memoffset [ppc64el] (cosmic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-core [i386] (cosmic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-time [armhf] (cosmic-proposed) [0.1.40-1]
-queuebot:#ubuntu-release- New: accepted rust-try-lock [armhf] (cosmic-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-try-lock [s390x] (cosmic-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-unicode-bidi [arm64] (cosmic-proposed) [0.3.4-1]
-queuebot:#ubuntu-release- New: accepted rust-unicode-bidi [ppc64el] (cosmic-proposed) [0.3.4-1]
-queuebot:#ubuntu-release- New: accepted rust-humantime [arm64] (cosmic-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-memoffset [arm64] (cosmic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-redox-termios [armhf] (cosmic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-try-lock [ppc64el] (cosmic-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-unicode-bidi [armhf] (cosmic-proposed) [0.3.4-1]
-queuebot:#ubuntu-release- New: accepted rust-indexmap [i386] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-try-lock [arm64] (cosmic-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-unicode-bidi [s390x] (cosmic-proposed) [0.3.4-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-core [arm64] (cosmic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-unicode-bidi [amd64] (cosmic-proposed) [0.3.4-1]
-queuebot:#ubuntu-release- New: accepted rust-cloudabi [amd64] (cosmic-proposed) [0.0.3-1]
-queuebot:#ubuntu-release- New: accepted rust-cloudabi [armhf] (cosmic-proposed) [0.0.3-1]
-queuebot:#ubuntu-release- New: accepted rust-crossbeam-utils [arm64] (cosmic-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted rust-crossbeam-utils [i386] (cosmic-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted rust-fuchsia-zircon [arm64] (cosmic-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted rust-futures [i386] (cosmic-proposed) [0.1.23-1]
-queuebot:#ubuntu-release- New: accepted rust-humantime [amd64] (cosmic-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-humantime [ppc64el] (cosmic-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-indexmap [ppc64el] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-language-tags [i386] (cosmic-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-cloudabi [arm64] (cosmic-proposed) [0.0.3-1]
-queuebot:#ubuntu-release- New: accepted rust-crossbeam-utils [armhf] (cosmic-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted rust-futures [amd64] (cosmic-proposed) [0.1.23-1]
-queuebot:#ubuntu-release- New: accepted rust-humantime [i386] (cosmic-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-language-tags [amd64] (cosmic-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-memoffset [i386] (cosmic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-redox-termios [i386] (cosmic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-time [i386] (cosmic-proposed) [0.1.40-1]
-queuebot:#ubuntu-release- New: accepted rust-try-lock [i386] (cosmic-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-cloudabi [ppc64el] (cosmic-proposed) [0.0.3-1]
-queuebot:#ubuntu-release- New: accepted rust-futures [ppc64el] (cosmic-proposed) [0.1.23-1]
-queuebot:#ubuntu-release- New: accepted rust-memoffset [amd64] (cosmic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-time [amd64] (cosmic-proposed) [0.1.40-1]
-queuebot:#ubuntu-release- New: accepted rust-unicode-bidi [i386] (cosmic-proposed) [0.3.4-1]
-queuebot:#ubuntu-release- New: accepted rust-fuchsia-zircon [amd64] (cosmic-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted rust-redox-termios [amd64] (cosmic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-indexmap [amd64] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-try-lock [amd64] (cosmic-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted libmodule-build-pluggable-ppport-perl [amd64] (cosmic-proposed) [0.04-1]
-queuebot:#ubuntu-release- New: accepted python-pygtrie [amd64] (cosmic-proposed) [2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-cloudabi [s390x] (cosmic-proposed) [0.0.3-1]
-queuebot:#ubuntu-release- New: accepted rust-crossbeam-utils [s390x] (cosmic-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted rust-humantime [s390x] (cosmic-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-language-tags [s390x] (cosmic-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-core [s390x] (cosmic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted libtickit-widgets-perl [amd64] (cosmic-proposed) [0.29-2]
-queuebot:#ubuntu-release- New: accepted rust-crossbeam-utils [ppc64el] (cosmic-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted rust-indexmap [s390x] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-cloudabi [i386] (cosmic-proposed) [0.0.3-1]
-queuebot:#ubuntu-release- New: accepted rust-memoffset [s390x] (cosmic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-futures [s390x] (cosmic-proposed) [0.1.23-1]
-queuebot:#ubuntu-release- New binary: libtickit-widget-tabbed-perl [amd64] (cosmic-proposed/universe) [0.021-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtickit-widget-scroller-perl [amd64] (cosmic-proposed/universe) [0.23-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libtickit-widget-scroller-perl [amd64] (cosmic-proposed) [0.23-1]
-queuebot:#ubuntu-release- New: accepted libtickit-widget-tabbed-perl [amd64] (cosmic-proposed) [0.021-1]
-queuebot:#ubuntu-release- New binary: golang-github-lucasb-eyer-go-colorful [amd64] (cosmic-proposed/none) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-ulule-limiter [amd64] (cosmic-proposed/none) [2.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-smira-go-aws-auth [amd64] (cosmic-proposed/none) [0.0~git20160320.0070896-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyside2 [amd64] (cosmic-proposed/universe) [5.11.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-github-lucasb-eyer-go-colorful [amd64] (cosmic-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-ulule-limiter [amd64] (cosmic-proposed) [2.2.0-2]
-queuebot:#ubuntu-release- New: accepted golang-github-smira-go-aws-auth [amd64] (cosmic-proposed) [0.0~git20160320.0070896-1]
-queuebot:#ubuntu-release- New: accepted pyside2 [amd64] (cosmic-proposed) [5.11.0-1]
-queuebot:#ubuntu-release- New binary: emacs-non-dfsg [amd64] (cosmic-proposed/multiverse) [1:25.2+1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: emacs [s390x] (cosmic-proposed/universe) [1:25.2+1-8] (no packageset)
-queuebot:#ubuntu-release- New binary: emacs [ppc64el] (cosmic-proposed/universe) [1:25.2+1-8] (no packageset)
-queuebot:#ubuntu-release- New binary: emacs [amd64] (cosmic-proposed/universe) [1:25.2+1-8] (no packageset)
-queuebot:#ubuntu-release- New binary: emacs [i386] (cosmic-proposed/universe) [1:25.2+1-8] (no packageset)
-queuebot:#ubuntu-release- New binary: emacs [armhf] (cosmic-proposed/universe) [1:25.2+1-8] (no packageset)
#ubuntu-release 2019-07-22
-queuebot:#ubuntu-release- Unapproved: cockpit (disco-backports/universe) [196-1~ubuntu19.04.1 => 198-1~ubuntu19.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (disco-backports) [198-1~ubuntu19.04.1]
-queuebot:#ubuntu-release- Unapproved: cockpit (cosmic-backports/universe) [196-1~ubuntu18.10.1 => 198-1~ubuntu18.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (cosmic-backports) [198-1~ubuntu18.10.1]
-queuebot:#ubuntu-release- Unapproved: cockpit (bionic-backports/universe) [196-1~ubuntu18.04.1 => 198-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (bionic-backports) [198-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (disco-proposed) [2:19.0.1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted python-libmaas [source] (disco-proposed) [0.6.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted dahdi-linux [source] (bionic-proposed) [1:2.11.1~dfsg-1ubuntu4.1]
-queuebot:#ubuntu-release- Unapproved: accepted sysdig [source] (bionic-proposed) [0.19.1-1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: spice-html5 (xenial-proposed/universe) [0.1.4-1 => 0.1.4-1ubuntu1.16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1047.52] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1047.52]
-queuebot:#ubuntu-release- New source: mysql-8.0 (eoan-proposed/primary) [8.0.14-0ubuntu2]
<rbasak> vorlon: ^ please review. Identical to 8.0.14-0ubuntu1 except for the new changelog entry. No orig tarball uploaded - I presume that's OK.
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (eoan-proposed) [2.04-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (eoan-proposed) [2.04-1ubuntu2]
<rbasak> I only found clickhouse and rmysql as sources in eoan-proposed that directly depend on libmysqlclientX, so I don't think the transition will entangle with anything currently in progress.
-queuebot:#ubuntu-release- Unapproved: kdevelop-php (disco-proposed/universe) [5.3.2-0ubuntu1 => 5.3.3-1ubuntu1] (kubuntu)
<RikMills> ^^ please reject. done in wrong git branch, so went to disco instead of eoan
-queuebot:#ubuntu-release- Unapproved: accepted qtwebengine-opensource-src [source] (bionic-proposed) [5.9.8+dfsg-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected kdevelop-php [source] (disco-proposed) [5.3.3-1ubuntu1]
<rbasak> ^ done
<RikMills> thanks
-queuebot:#ubuntu-release- Unapproved: accepted rpi.gpio [source] (bionic-proposed) [0.6.5-1ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: linux-firmware-raspi2 (bionic-proposed/multiverse) [1.20180919-0ubuntu0.18.04.2 => 1.20190215-0ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cloud-utils (disco-proposed/main) [0.31-0ubuntu1 => 0.31-0ubuntu1.1] (core, edubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware-raspi2 [source] (bionic-proposed) [1.20190215-0ubuntu0.18.04.1]
<sergiusens> vorlon: hi! is the autopkgtest infra down? I got a 500 when trying to trigger from github and I see no test currently running (https://autopkgtest.ubuntu.com/running)
<vorlon> sergiusens: http://autopkgtest.ubuntu.com/running shows there are a number of tests currently running, but there is no backlog.  I don't know why you would've gotten a 500
<vorlon> sergiusens: newly-queued tests are starting fine
<sergiusens> vorlon: hmm, maybe this is only affecting github triggered ones using https://git.launchpad.net/autopkgtest-cloud/plain/tools/retry-github-test?
<sergiusens> which we call like "retry-github-test https://api.github.com/repos/snapcore/snapcraft/pulls/2636 https://autopkgtest.ubuntu.com/request.cgi?release=bionic&arch=arm64&package=snapcraft&ppa=snappy-dev%2Fsnapcraft-daily /tmp/tmp.5Hkp5Febse/sec.txt"
<vorlon> sergiusens: I'm afraid I don't know anything about that tool
<Odd_Bloke> sergiusens: GH has had a big outage today, which they say is resolved; are you still seeing issues?
<vorlon> sergiusens: it's called 'retry', but is this what is used to trigger tests in all cases or only for manual retries?
<vorlon> right, there's that too
<sergiusens> vorlon: manual retries, I disabled the GH webhook as our snapcraft tests can really load the system
<sergiusens> I will see if the webhook stuff works next
<vorlon> sergiusens: there is at least one github-triggered test running right now http://autopkgtest.ubuntu.com/running#pkg-systemd-upstream
<sergiusens> Odd_Bloke: the 500 comes from autopkgtest.ubuntu.com
<sergiusens> ok, that gives me hope for the webhook
<sergiusens> vorlon: Odd_Bloke retry seems to be working, just returning a 500 and it may be relayed from GH, so Odd_Bloke might be correct
<Laney> It sends a POST request to github so that it can update the PR to show you the test is running
<Laney> if that breaks, you probably get a 500
<sergiusens> the webhook triggers the test correctly but never shows up on the Github status/checks box
<sergiusens> Laney: that seems to be the case
<Laney> I'm also being spammed with weird emails about this now
<sergiusens> Laney: you are probably being encouraged to fix the issue :-)
<Laney> I guess at best I could make the error message better
 * Laney coughs
<Laney> sergiusens: can you reissue bionic i386/s390x/ppc64el by that script you've got pls?
<Laney> maybe that shuts this up
<Odd_Bloke> sergiusens: As there is no way to be sure, I will opt for being 100% correct. ;)
<sergiusens> Laney: about to trigger
<sergiusens> Laney: triggered
<sergiusens> Odd_Bloke: well you sort of got confirmation that a 500 on post was just relayed back to the caller
<sergiusens> Laney: oh, one sec, I did xenial/amd64, doing those arch/release combos now
<Laney> merci
<Odd_Bloke> sergiusens: Oh, I only read the line pinging me, cool!
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (disco-proposed/main) [1.431 => 1.431.1] (core)
<rbalint> infinity, could you please accept the second ubuntu-meta upload?
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (disco-proposed/main) [1.431 => 1.431.1] (core)
<infinity> rbalint: Dunno, but I can reject the first, if you like.
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-meta [source] (disco-proposed) [1.431.1]
<infinity> rbalint: Wait, you can run X applications in WSL now?
<connor_k> I think that's been the case for awhile now provided one has an X server installed and they set the right DISPLAY env variable
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (disco-proposed) [1.431.1]
<rbalint> infinity, https://balintreczey.hu/blog/introducing-ubuntu-wsl-the-package-making-ubuntu-better-and-better-on-wsl/ :-)
<rbalint> infinity, testing q3arena is on my todo list
#ubuntu-release 2019-07-23
-queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (disco-proposed) [19.0.8-0ubuntu0~19.04.1]
-queuebot:#ubuntu-release- Unapproved: snapd-glib (disco-proposed/main) [1.48-0ubuntu0.19.04.0 => 1.49-0ubuntu0.19.04.0] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: snapd-glib (bionic-proposed/main) [1.47-0ubuntu0.18.04.0 => 1.49-0ubuntu0.18.04.0] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: bmusb [amd64] (eoan-proposed/universe) [0.7.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bmusb [s390x] (eoan-proposed/universe) [0.7.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bmusb [i386] (eoan-proposed/universe) [0.7.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bmusb [ppc64el] (eoan-proposed/universe) [0.7.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gajim-openpgp [amd64] (eoan-proposed/universe) [1.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: geotranz [amd64] (eoan-proposed/universe) [3.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: geotranz [i386] (eoan-proposed/universe) [3.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bmusb [armhf] (eoan-proposed/universe) [0.7.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: geotranz [s390x] (eoan-proposed/universe) [3.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: geotranz [ppc64el] (eoan-proposed/universe) [3.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: zbar [s390x] (eoan-proposed/universe) [0.23-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: bmusb [arm64] (eoan-proposed/universe) [0.7.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: zbar [ppc64el] (eoan-proposed/universe) [0.23-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: zbar [i386] (eoan-proposed/universe) [0.23-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: geotranz [arm64] (eoan-proposed/universe) [3.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: zbar [amd64] (eoan-proposed/universe) [0.23-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: geotranz [armhf] (eoan-proposed/universe) [3.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: zbar [arm64] (eoan-proposed/universe) [0.23-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: zbar [armhf] (eoan-proposed/universe) [0.23-1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: mesa (bionic-proposed/main) [19.0.2-1ubuntu1.1~18.04.2 => 19.0.8-0ubuntu0~18.04.1] (core, xorg)
-queuebot:#ubuntu-release- New: accepted bmusb [amd64] (eoan-proposed) [0.7.4-2]
-queuebot:#ubuntu-release- New: accepted bmusb [armhf] (eoan-proposed) [0.7.4-2]
-queuebot:#ubuntu-release- New: accepted bmusb [ppc64el] (eoan-proposed) [0.7.4-2]
-queuebot:#ubuntu-release- New: accepted bmusb [arm64] (eoan-proposed) [0.7.4-2]
-queuebot:#ubuntu-release- New: accepted bmusb [s390x] (eoan-proposed) [0.7.4-2]
-queuebot:#ubuntu-release- New: accepted bmusb [i386] (eoan-proposed) [0.7.4-2]
-queuebot:#ubuntu-release- New: accepted cairosvg [amd64] (eoan-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- New: accepted gajim-openpgp [amd64] (eoan-proposed) [1.1.2-1]
-queuebot:#ubuntu-release- New: accepted geotranz [arm64] (eoan-proposed) [3.7-1]
-queuebot:#ubuntu-release- New: accepted geotranz [i386] (eoan-proposed) [3.7-1]
-queuebot:#ubuntu-release- New: accepted geotranz [s390x] (eoan-proposed) [3.7-1]
-queuebot:#ubuntu-release- New: accepted guile-ssh [arm64] (eoan-proposed) [0.11.3-2]
-queuebot:#ubuntu-release- New: accepted guile-ssh [i386] (eoan-proposed) [0.11.3-2]
-queuebot:#ubuntu-release- New: accepted guile-ssh [s390x] (eoan-proposed) [0.11.3-2]
-queuebot:#ubuntu-release- New: accepted mescc-tools [arm64] (eoan-proposed) [0.6.1-2]
-queuebot:#ubuntu-release- New: accepted mescc-tools [i386] (eoan-proposed) [0.6.1-2]
-queuebot:#ubuntu-release- New: accepted exadrums [amd64] (eoan-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted geotranz [armhf] (eoan-proposed) [3.7-1]
-queuebot:#ubuntu-release- New: accepted guile-ssh [amd64] (eoan-proposed) [0.11.3-2]
-queuebot:#ubuntu-release- New: accepted guile-ssh [ppc64el] (eoan-proposed) [0.11.3-2]
-queuebot:#ubuntu-release- New: accepted mescc-tools [armhf] (eoan-proposed) [0.6.1-2]
-queuebot:#ubuntu-release- New: accepted mescc-tools [s390x] (eoan-proposed) [0.6.1-2]
-queuebot:#ubuntu-release- New binary: rust-assert-cli [s390x] (eoan-proposed/universe) [0.6.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-caps [s390x] (eoan-proposed/universe) [0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-darling-macro [s390x] (eoan-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ipnetwork [i386] (eoan-proposed/universe) [0.14.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted geotranz [amd64] (eoan-proposed) [3.7-1]
-queuebot:#ubuntu-release- New: accepted guile-ssh [armhf] (eoan-proposed) [0.11.3-2]
-queuebot:#ubuntu-release- New: accepted mescc-tools [ppc64el] (eoan-proposed) [0.6.1-2]
-queuebot:#ubuntu-release- New binary: rust-bumpalo [s390x] (eoan-proposed/universe) [2.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-diesel [i386] (eoan-proposed/universe) [1.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted geotranz [ppc64el] (eoan-proposed) [3.7-1]
-queuebot:#ubuntu-release- New binary: baloo [s390x] (eoan-proposed/universe) [4:4.14.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-static-assertions [i386] (eoan-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted mescc-tools [amd64] (eoan-proposed) [0.6.1-2]
-queuebot:#ubuntu-release- New binary: rust-core-arch [s390x] (eoan-proposed/universe) [0.1.5-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted nyacc [amd64] (eoan-proposed) [0.94.0-2]
-queuebot:#ubuntu-release- New: accepted nyacc [armhf] (eoan-proposed) [0.94.0-2]
-queuebot:#ubuntu-release- New: accepted nyacc [ppc64el] (eoan-proposed) [0.94.0-2]
-queuebot:#ubuntu-release- New: accepted nyacc [arm64] (eoan-proposed) [0.94.0-2]
-queuebot:#ubuntu-release- New: accepted nyacc [s390x] (eoan-proposed) [0.94.0-2]
-queuebot:#ubuntu-release- New: accepted nyacc [i386] (eoan-proposed) [0.94.0-2]
-queuebot:#ubuntu-release- New: accepted r-bioc-lpsymphony [amd64] (eoan-proposed) [1.12.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-lpsymphony [armhf] (eoan-proposed) [1.12.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-lpsymphony [ppc64el] (eoan-proposed) [1.12.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted redfishtool [amd64] (eoan-proposed) [1.0.8-2]
-queuebot:#ubuntu-release- New binary: rust-darling-macro [i386] (eoan-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gettext-rs [i386] (eoan-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ppv-lite86 [amd64] (eoan-proposed/universe) [0.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted r-bioc-lpsymphony [arm64] (eoan-proposed) [1.12.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-lpsymphony [s390x] (eoan-proposed) [1.12.0+dfsg-1]
-queuebot:#ubuntu-release- New binary: rust-doc-comment [i386] (eoan-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted r-bioc-lpsymphony [i386] (eoan-proposed) [1.12.0+dfsg-1]
-queuebot:#ubuntu-release- New binary: rust-http-body [amd64] (eoan-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-darling-macro [amd64] (eoan-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-http-body [amd64] (eoan-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-http-body [s390x] (eoan-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-http-body [i386] (eoan-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-ipconfig [amd64] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-ipconfig [s390x] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-ipconfig [i386] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New binary: rust-getrandom [i386] (eoan-proposed/universe) [0.1.6-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-ipnetwork [amd64] (eoan-proposed) [0.14.0-1]
-queuebot:#ubuntu-release- New: accepted rust-ipnetwork [s390x] (eoan-proposed) [0.14.0-1]
-queuebot:#ubuntu-release- New: accepted rust-ipnetwork [i386] (eoan-proposed) [0.14.0-1]
-queuebot:#ubuntu-release- New: accepted rust-md5-asm [amd64] (eoan-proposed) [0.4.3-1]
-queuebot:#ubuntu-release- New binary: swift [amd64] (eoan-proposed/universe) [2.22.0~b1~git2019071110.e62f07d98-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- New: accepted rust-md5-asm [i386] (eoan-proposed) [0.4.3-1]
-queuebot:#ubuntu-release- New binary: swift [amd64] (eoan-proposed/universe) [2.22.0~b1~git2019071110.e62f07d98-0ubuntu2] (openstack)
-queuebot:#ubuntu-release- New: accepted rust-nom-4 [amd64] (eoan-proposed) [4.2.3-1]
-queuebot:#ubuntu-release- New: accepted rust-nom-4 [s390x] (eoan-proposed) [4.2.3-1]
-queuebot:#ubuntu-release- New: accepted rust-nom-4 [i386] (eoan-proposed) [4.2.3-1]
-queuebot:#ubuntu-release- New: accepted rust-ppv-lite86 [amd64] (eoan-proposed) [0.2.5-1]
-queuebot:#ubuntu-release- New: accepted rust-ppv-lite86 [s390x] (eoan-proposed) [0.2.5-1]
-queuebot:#ubuntu-release- New: accepted rust-quick-xml [i386] (eoan-proposed) [0.14.0-1]
-queuebot:#ubuntu-release- New: accepted rust-ppv-lite86 [i386] (eoan-proposed) [0.2.5-1]
-queuebot:#ubuntu-release- New: accepted rust-quick-xml [s390x] (eoan-proposed) [0.14.0-1]
-queuebot:#ubuntu-release- New: accepted rust-quick-xml [amd64] (eoan-proposed) [0.14.0-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-core-0.3 [amd64] (eoan-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-core-0.3 [s390x] (eoan-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-core-0.3 [i386] (eoan-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted rust-stackvector [amd64] (eoan-proposed) [1.0.6-1]
-queuebot:#ubuntu-release- New: accepted rust-stackvector [s390x] (eoan-proposed) [1.0.6-1]
-queuebot:#ubuntu-release- New: accepted rust-static-assertions [i386] (eoan-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted zbar [amd64] (eoan-proposed) [0.23-1]
-queuebot:#ubuntu-release- New: accepted zbar [armhf] (eoan-proposed) [0.23-1]
-queuebot:#ubuntu-release- New: accepted rust-stackvector [i386] (eoan-proposed) [1.0.6-1]
-queuebot:#ubuntu-release- New: accepted rust-static-assertions [s390x] (eoan-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted zbar [ppc64el] (eoan-proposed) [0.23-1]
-queuebot:#ubuntu-release- New: accepted rust-static-assertions [amd64] (eoan-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted zbar [arm64] (eoan-proposed) [0.23-1]
-queuebot:#ubuntu-release- New: accepted zbar [i386] (eoan-proposed) [0.23-1]
-queuebot:#ubuntu-release- New: accepted zbar [s390x] (eoan-proposed) [0.23-1]
-queuebot:#ubuntu-release- New: accepted baloo [amd64] (eoan-proposed) [4:4.14.3-3]
-queuebot:#ubuntu-release- New: accepted baloo [s390x] (eoan-proposed) [4:4.14.3-3]
-queuebot:#ubuntu-release- New: accepted baloo [i386] (eoan-proposed) [4:4.14.3-3]
-queuebot:#ubuntu-release- New: accepted chicken [amd64] (eoan-proposed) [5.1.0-1]
-queuebot:#ubuntu-release- New: accepted chicken [i386] (eoan-proposed) [5.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-assert-cli [arm64] (eoan-proposed) [0.6.3-1]
-queuebot:#ubuntu-release- New: accepted rust-assert-cli [s390x] (eoan-proposed) [0.6.3-1]
-queuebot:#ubuntu-release- New: accepted rust-bumpalo [armhf] (eoan-proposed) [2.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-assert-cli [armhf] (eoan-proposed) [0.6.3-1]
-queuebot:#ubuntu-release- New: accepted rust-bumpalo [s390x] (eoan-proposed) [2.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-bumpalo [arm64] (eoan-proposed) [2.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-caps [arm64] (eoan-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New: accepted rust-caps [i386] (eoan-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New: accepted rust-caps [armhf] (eoan-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New: accepted rust-caps [s390x] (eoan-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New: accepted rust-core-arch [amd64] (eoan-proposed) [0.1.5-1]
-queuebot:#ubuntu-release- New: accepted rust-core-arch [armhf] (eoan-proposed) [0.1.5-1]
-queuebot:#ubuntu-release- New: accepted rust-core-arch [arm64] (eoan-proposed) [0.1.5-1]
-queuebot:#ubuntu-release- New: accepted rust-core-arch [s390x] (eoan-proposed) [0.1.5-1]
-queuebot:#ubuntu-release- New: accepted rust-darling-macro [amd64] (eoan-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted rust-darling-macro [i386] (eoan-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted rust-darling-macro [arm64] (eoan-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted rust-darling-macro [s390x] (eoan-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted rust-data-encoding-macro-internal [arm64] (eoan-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted rust-data-encoding-macro-internal [s390x] (eoan-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted rust-data-encoding-macro-internal [armhf] (eoan-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted rust-diesel [amd64] (eoan-proposed) [1.4.2-1]
-queuebot:#ubuntu-release- New: accepted rust-diesel [s390x] (eoan-proposed) [1.4.2-1]
-queuebot:#ubuntu-release- New: accepted rust-diesel [i386] (eoan-proposed) [1.4.2-1]
-queuebot:#ubuntu-release- New: accepted rust-dirs-sys [s390x] (eoan-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted rust-doc-comment [amd64] (eoan-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted rust-doc-comment [s390x] (eoan-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted rust-getrandom [s390x] (eoan-proposed) [0.1.6-1]
-queuebot:#ubuntu-release- New: accepted rust-doc-comment [i386] (eoan-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted rust-gettext-rs [s390x] (eoan-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted rust-getrandom [i386] (eoan-proposed) [0.1.6-1]
-queuebot:#ubuntu-release- New: accepted rust-gettext-rs [amd64] (eoan-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted rust-gettext-rs [i386] (eoan-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New binary: r-bioc-ihw [amd64] (eoan-proposed/universe) [1.12.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: geos [s390x] (eoan-proposed/universe) [3.7.2-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: geos [amd64] (eoan-proposed/universe) [3.7.2-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: geos [i386] (eoan-proposed/universe) [3.7.2-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: geos [ppc64el] (eoan-proposed/universe) [3.7.2-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: geos [arm64] (eoan-proposed/universe) [3.7.2-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: geos [armhf] (eoan-proposed/universe) [3.7.2-1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: gnome-flashback (bionic-proposed/universe) [3.28.0-1ubuntu1.3 => 3.28.0-1ubuntu1.4] (edubuntu)
-queuebot:#ubuntu-release- Unapproved: gnome-flashback (disco-proposed/universe) [3.30.0-1ubuntu6 => 3.30.0-1ubuntu6.1] (edubuntu)
<Trevinho> anyone can free mutter in disco and mutter+gnome-shell in bionic queues? :)
-queuebot:#ubuntu-release- New: accepted geos [amd64] (eoan-proposed) [3.7.2-1]
-queuebot:#ubuntu-release- New: accepted geos [armhf] (eoan-proposed) [3.7.2-1]
-queuebot:#ubuntu-release- New: accepted geos [ppc64el] (eoan-proposed) [3.7.2-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-ihw [amd64] (eoan-proposed) [1.12.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted geos [arm64] (eoan-proposed) [3.7.2-1]
-queuebot:#ubuntu-release- New: accepted geos [s390x] (eoan-proposed) [3.7.2-1]
-queuebot:#ubuntu-release- New: accepted geos [i386] (eoan-proposed) [3.7.2-1]
-queuebot:#ubuntu-release- New binary: symfony [amd64] (eoan-proposed/universe) [4.3.2+dfsg-1ubuntu1~build1] (no packageset)
<ginggs> would someone please remove the p4est i386 and armfh binaries from release?  deal.ii, the only thing that uses it, is already 64-bit only
<LocutusOfBorg> ^^ that symfony ~build1 versioning is correct, I plan to reupload once I have a clear history of regressions
<teward> can someone point me to where the Ubuntu Studio packageset is defined (if it's defined)?
<teward> need to review it for reasons
<rbasak> https://people.canonical.com/~ubuntu-archive/packagesets/eoan/ubuntustudio
<rbasak> Is a view on the definition within Launchpad
<rbasak> It may be automatically generated from https://git.launchpad.net/~developer-membership-board/+git/packageset/tree/ - I don't recall
<Eickmeyer> rbasak: What does it take to get items added to the packageset? We have a few recent additions that could be added.
<teward> and there's a lot I'd like the DMB to review as well, because I don't think some of these should be directly in the package set IMO (not sure the Studio team should be poking python-regex or such...)
<teward> though IIRC that was being discussed a while ago
<rbasak> Eickmeyer: email devel-permissions@ with a request and details please.
<Eickmeyer> rbasak: Thanks!
<rbasak> Eickmeyer: I remember that there was some debate to do with the flavour packageset and individual uploader PPUs
<rbasak> I don't recall the details, but the request will have to be considered in light of whatever decision was made I guess
<Eickmeyer> rbasak: True.
<Eickmeyer> rbasak: I've been encouraged to apply for packageset since I've been working hard on packaging, and have added 3 (soon to be 4) packages to the archive since May.
<rbasak> Sounds good!
<teward> > soon to be 4 <
<teward> that depends on my review ;)
<teward> i may NACK the package if yo udid something abhorrent Eickmeyer ;)
<Eickmeyer> ^True
<slashd> infinity, sil2100, stgraber or any archive admin, is there a way to get still have access to a package that got deleted/superseeded 4 hours ago ? ceph - 12.2.11-0ubuntu0.18.04.2 -> https://launchpad.net/ubuntu/+source/ceph/+publishinghistory
<slashd> vorlon, ^
<rbasak> slashd: define "have access"
<rbasak> slashd: Launchpad retains the build logs and builds indefinitely
<rbasak> slashd: click on the version string on the publishing history page
 * slashd looking
<cjwatson> Launchpad doesn't promise to retain the build *output* indefinitely, though we do currently retain build logs indefinitely
<slashd> rbasak, that's exactly what I wanted, big thanks
<rbasak> cjwatson: have you deleted old builds in practice, OOI?
<cjwatson> Yes
<cjwatson> For obsolete series
<rbasak> Good to know, thanks!
<slashd> cjwatson, rbasak thanks for quick answer
<cjwatson> And old build output files in PPAs are deleted relatively quickly (something like a week)
-queuebot:#ubuntu-release- New binary: apriltag [amd64] (eoan-proposed/universe) [0.10.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: balboa [amd64] (eoan-proposed/universe) [2.0.0+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: apriltag [i386] (eoan-proposed/universe) [0.10.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: hydra-el [amd64] (eoan-proposed/universe) [0.15.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: balboa [i386] (eoan-proposed/universe) [2.0.0+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: fxt [amd64] (eoan-proposed/universe) [0.3.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: apriltag [s390x] (eoan-proposed/universe) [0.10.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: fxt [s390x] (eoan-proposed/universe) [0.3.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmurmurhash [amd64] (eoan-proposed/universe) [1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmurmurhash [i386] (eoan-proposed/universe) [1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fxt [i386] (eoan-proposed/universe) [0.3.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmurmurhash [armhf] (eoan-proposed/universe) [1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-shell-extension-top-icons-plus [amd64] (eoan-proposed/none) [22-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libmurmurhash [s390x] (eoan-proposed/universe) [1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: apriltag [arm64] (eoan-proposed/universe) [0.10.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: fxt [ppc64el] (eoan-proposed/universe) [0.3.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: myproxy [amd64] (eoan-proposed/universe) [6.2.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: apriltag [ppc64el] (eoan-proposed/universe) [0.10.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-157.185] (core, kernel)
-queuebot:#ubuntu-release- New binary: libmurmurhash [ppc64el] (eoan-proposed/universe) [1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: balboa [s390x] (eoan-proposed/universe) [2.0.0+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: apriltag [armhf] (eoan-proposed/universe) [0.10.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: balboa [ppc64el] (eoan-proposed/universe) [2.0.0+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libmurmurhash [arm64] (eoan-proposed/universe) [1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fxt [arm64] (eoan-proposed/universe) [0.3.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fxt [armhf] (eoan-proposed/universe) [0.3.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: balboa [arm64] (eoan-proposed/universe) [2.0.0+ds-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted balboa [arm64] (eoan-proposed) [2.0.0+ds-2]
-queuebot:#ubuntu-release- New: accepted fxt [arm64] (eoan-proposed) [0.3.9-1]
-queuebot:#ubuntu-release- New: accepted balboa [ppc64el] (eoan-proposed) [2.0.0+ds-2]
-queuebot:#ubuntu-release- New: accepted fxt [armhf] (eoan-proposed) [0.3.9-1]
-queuebot:#ubuntu-release- New: accepted apriltag [arm64] (eoan-proposed) [0.10.0-4]
-queuebot:#ubuntu-release- New: accepted apriltag [ppc64el] (eoan-proposed) [0.10.0-4]
-queuebot:#ubuntu-release- New: accepted fxt [ppc64el] (eoan-proposed) [0.3.9-1]
-queuebot:#ubuntu-release- New: accepted libmurmurhash [ppc64el] (eoan-proposed) [1.5-1]
-queuebot:#ubuntu-release- New: accepted apriltag [armhf] (eoan-proposed) [0.10.0-4]
-queuebot:#ubuntu-release- New: accepted libmurmurhash [arm64] (eoan-proposed) [1.5-1]
-queuebot:#ubuntu-release- New: accepted balboa [s390x] (eoan-proposed) [2.0.0+ds-2]
-queuebot:#ubuntu-release- New: accepted myproxy [amd64] (eoan-proposed) [6.2.4-2]
-queuebot:#ubuntu-release- New: accepted apriltag [s390x] (eoan-proposed) [0.10.0-4]
-queuebot:#ubuntu-release- New: accepted fxt [s390x] (eoan-proposed) [0.3.9-1]
-queuebot:#ubuntu-release- New: accepted libmurmurhash [amd64] (eoan-proposed) [1.5-1]
-queuebot:#ubuntu-release- New: accepted libmurmurhash [i386] (eoan-proposed) [1.5-1]
-queuebot:#ubuntu-release- New: accepted fxt [i386] (eoan-proposed) [0.3.9-1]
-queuebot:#ubuntu-release- New: accepted libmurmurhash [armhf] (eoan-proposed) [1.5-1]
-queuebot:#ubuntu-release- New: accepted gnome-shell-extension-top-icons-plus [amd64] (eoan-proposed) [22-2]
-queuebot:#ubuntu-release- New: accepted libmurmurhash [s390x] (eoan-proposed) [1.5-1]
-queuebot:#ubuntu-release- New: accepted apriltag [amd64] (eoan-proposed) [0.10.0-4]
-queuebot:#ubuntu-release- New: accepted balboa [amd64] (eoan-proposed) [2.0.0+ds-2]
-queuebot:#ubuntu-release- New: accepted fxt [amd64] (eoan-proposed) [0.3.9-1]
-queuebot:#ubuntu-release- New: accepted apriltag [i386] (eoan-proposed) [0.10.0-4]
-queuebot:#ubuntu-release- New: accepted hydra-el [amd64] (eoan-proposed) [0.15.0-1]
-queuebot:#ubuntu-release- New: accepted balboa [i386] (eoan-proposed) [2.0.0+ds-2]
-queuebot:#ubuntu-release- Unapproved: rejected ceph [source] (cosmic-proposed) [13.2.6-0ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Unapproved: rejected initramfs-tools [source] (cosmic-proposed) [0.131ubuntu15.3]
-queuebot:#ubuntu-release- Unapproved: rejected landscape-client [source] (cosmic-proposed) [18.01-0ubuntu4.3]
-queuebot:#ubuntu-release- Unapproved: rejected mixxx [source] (cosmic-proposed) [2.2.0~dfsg-1ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Unapproved: rejected fonts-noto-cjk [source] (cosmic-proposed) [1:20190409+repack1-0ubuntu0.18.10]
-queuebot:#ubuntu-release- Unapproved: rejected librabbitmq [source] (cosmic-proposed) [0.8.0-1ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Unapproved: rejected initramfs-tools [source] (cosmic-proposed) [0.131ubuntu15.3]
-queuebot:#ubuntu-release- Unapproved: rejected snapd-glib [source] (cosmic-proposed) [1.48-0ubuntu0.18.10.0]
-queuebot:#ubuntu-release- New: rejected octavia-dashboard [source] (cosmic-proposed) [2.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected python-tornado4 [source] (cosmic-proposed) [4.5.3-3~ubuntu18.10.1]
-queuebot:#ubuntu-release- New: accepted mysql-8.0 [source] (eoan-proposed) [8.0.14-0ubuntu2]
<tsimonq2> rbasak, bdmurray, vorlon: Could I please get a review of the usb-creator SRUs? bug 1629715
<ubot5> bug 1629715 in usb-creator (Ubuntu Disco) "[SRU] usb-creator-kde shows the install popup after a few seconds of launching without any input" [High,In progress] https://launchpad.net/bugs/1629715
<tsimonq2> rbasak, bdmurray, vorlon: The bug itself affects functionality of the usb-creator-kde exec and we'd like to get the fix in ASAP.
<tsimonq2> It just needs queue reviewal.
-queuebot:#ubuntu-release- New binary: mysql-8.0 [s390x] (eoan-proposed/universe) [8.0.14-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: mysql-8.0 [ppc64el] (eoan-proposed/universe) [8.0.14-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-157.185]
-queuebot:#ubuntu-release- New binary: mysql-8.0 [armhf] (eoan-proposed/universe) [8.0.14-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapd-glib (xenial-proposed/main) [1.47-0ubuntu0.16.04.0 => 1.49-0ubuntu0.16.04.0] (no packageset)
-queuebot:#ubuntu-release- New binary: mysql-8.0 [arm64] (eoan-proposed/universe) [8.0.14-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: systemd (disco-proposed/main) [240-6ubuntu5.2 => 240-6ubuntu5.3] (core)
-queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu10.24 => 237-3ubuntu10.25] (core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (xenial-proposed/main) [1.361.3 => 1.361.4] (core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (bionic-proposed/main) [1.417.2 => 1.417.3] (core)
-queuebot:#ubuntu-release- New binary: saga [s390x] (eoan-proposed/universe) [7.3.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: saga [amd64] (eoan-proposed/universe) [7.3.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: saga [i386] (eoan-proposed/universe) [7.3.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: saga [ppc64el] (eoan-proposed/universe) [7.3.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: otb [amd64] (eoan-proposed/universe) [6.6.1+dfsg-2] (no packageset)
#ubuntu-release 2019-07-24
-queuebot:#ubuntu-release- New binary: otb [i386] (eoan-proposed/universe) [6.6.1+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: saga [armhf] (eoan-proposed/universe) [7.3.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: saga [arm64] (eoan-proposed/universe) [7.3.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New source: raysession (eoan-proposed/primary) [0.7.2-0ubuntu1]
<Eickmeyer> \o/
-queuebot:#ubuntu-release- New binary: deal.ii [s390x] (eoan-proposed/universe) [9.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: deal.ii [amd64] (eoan-proposed/universe) [9.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: deal.ii [ppc64el] (eoan-proposed/universe) [9.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (eoan-proposed/main) [5.2.0-9.10] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (eoan-proposed/main) [5.2.0-9.10] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (eoan-proposed/main) [5.2.0-9.10] (core, kernel)
-queuebot:#ubuntu-release- New: accepted deal.ii [amd64] (eoan-proposed) [9.1.1-2]
-queuebot:#ubuntu-release- New: accepted deal.ii [ppc64el] (eoan-proposed) [9.1.1-2]
-queuebot:#ubuntu-release- New: accepted deal.ii [s390x] (eoan-proposed) [9.1.1-2]
-queuebot:#ubuntu-release- New: accepted otb [i386] (eoan-proposed) [6.6.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted saga [arm64] (eoan-proposed) [7.3.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted saga [i386] (eoan-proposed) [7.3.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted saga [s390x] (eoan-proposed) [7.3.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted otb [amd64] (eoan-proposed) [6.6.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted saga [armhf] (eoan-proposed) [7.3.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted saga [amd64] (eoan-proposed) [7.3.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted saga [ppc64el] (eoan-proposed) [7.3.0+dfsg-1]
<ginggs> would someone please remove the p4est i386 and armfh binaries from release?  deal.ii, the only thing that uses it, is already 64-bit only
<ginggs> also please remove r-bioc-biocinstaller from release, it is not compatible with r-base >= 3.6
<LocutusOfBorg> please accept symfony
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (eoan-proposed) [5.2.0-9.10]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (eoan-proposed) [5.2.0-9.10]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (eoan-proposed) [5.2.0-9.10]
<apw> ginggs, looking
-queuebot:#ubuntu-release- New: accepted symfony [amd64] (eoan-proposed) [4.3.2+dfsg-1ubuntu1~build1]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1052.57] (kernel)
-queuebot:#ubuntu-release- New: accepted fwupd-signed [source] (bionic-proposed) [1.2~ubuntu18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1052.57]
-queuebot:#ubuntu-release- Packageset: 6901 entries have been added or removed
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (disco-proposed/main) [5.0.0-22.23] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (disco-proposed/main) [5.0.0-22.23] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (disco-proposed/main) [5.0.0-22.23] (core, kernel)
<ginggs> apw: thanks!
-queuebot:#ubuntu-release- New source: xrdp-hwe-18.04 (bionic-proposed/primary) [0.9.5-2~18.04.1]
<vorlon> apw, stgraber: did one of you accept fwupd-signed into bionic-proposed?
<stgraber> nope
<apw> vorlon, looking at when it happened it might have been me, it would have been a fat finger if so
<vorlon> apw: a fat finger accept of a package from the bionic-proposed new queue? :/
<apw> vorlon, i was accepting linux-signed packages around that time, i do not recall doing it specifically
<vorlon> ok
<infinity> Seems unlikely, given that your other ACCEPT in that window was in another release.
<apw> then perhaps it wasn't me
<vorlon> so there's a small set of people who could've accepted it from bionic/new
<apw> but if i did do it, it cirtainly was an error
<infinity> vorlon: All of ~ubuntu-archive being the small set.
<vorlon> yeah
<vorlon> I suppose it could've been a non-SRU-team AA
-queuebot:#ubuntu-release- New: accepted libxmlb [source] (bionic-proposed) [0.1.8-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- New binary: libxmlb [arm64] (bionic-proposed/universe) [0.1.8-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: libxmlb [i386] (bionic-proposed/universe) [0.1.8-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: libxmlb [s390x] (bionic-proposed/universe) [0.1.8-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: libxmlb [amd64] (bionic-proposed/universe) [0.1.8-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: libxmlb [ppc64el] (bionic-proposed/universe) [0.1.8-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: libxmlb [armhf] (bionic-proposed/universe) [0.1.8-1~ubuntu18.04.1] (no packageset)
<sil2100> It wasn't done via sru-review as well, so just a direct queue accept
 * rbasak starts his SRU shift
<apw> vorlon, can it be repaired
<vorlon> well I need to probably remove some packages from -proposed but I'm also trying to figure out if anything got signed as a result of this that shouldn't have been
-queuebot:#ubuntu-release- New binary: mysql-8.0 [s390x] (eoan-proposed/universe) [8.0.16-0ubuntu1] (no packageset)
<vorlon> it looks like the corresponding fwupd is still in NEW
<sil2100> I see the packages are in dep-wait right now - would it cause binaries to be signed even without the builds succeeding
<sil2100> ?
<vorlon> no, the binaries submitted for signing come from the fwupd source package
<vorlon> so, we're ok currently
<apw> so nothing got signed, and it is just waiting on the primary
<apw> that is a thing at least
<vorlon> and I will annotate the bug more clearly
<sil2100> It did seem like a strange thing, seeing the -signed ones depwaiting in -proposed without the corresponding main package
<vorlon> so that everyone knows not to accept fwupd until they have a solid proposal for how we handle fwupdate->fwupd migration in an SRU, instead of requiring us to sign two streams of UEFI binaries for the same basic functionality and one of them deprecated
<sil2100> Understood, +1 on that
<sil2100> I actually hoped that they did resolve that and that this was the reason why I have been poked about it
<sil2100> Though I'd also expect to see an fwupdate upload in the queue then
<vorlon> indeed, that's not done yet
<bdmurray> rbasak: I missed my shift yesterday. How might we work together or when do you plan to wrap up?
-queuebot:#ubuntu-release- New binary: mysql-8.0 [amd64] (eoan-proposed/universe) [8.0.16-0ubuntu1] (no packageset)
<rbasak> bdmurray: I'm just about done with the pending-sru report for releases to updates. How about you process the Bionic queue to start, and I'll do Xenial?
<rbasak> Or, in any case, I'll start with Xenial, working oldest first, and I can let you know when I switch to something else.
-queuebot:#ubuntu-release- New binary: mysql-8.0 [ppc64el] (eoan-proposed/universe) [8.0.16-0ubuntu1] (no packageset)
<rbasak> bdmurray: I'll be wrapping up in an hour though for my EOD
<bdmurray> rbasak: okay
<bdmurray> rbasak: I'll just wait then
<rbasak> np
-queuebot:#ubuntu-release- Unapproved: rejected biosdevname [source] (xenial-proposed) [0.4.1-0ubuntu9.1]
-queuebot:#ubuntu-release- New binary: mysql-8.0 [armhf] (eoan-proposed/universe) [8.0.16-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: mysql-8.0 [i386] (eoan-proposed/universe) [8.0.16-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libvirt (xenial-proposed/main) [1.3.1-1ubuntu10.27 => 1.3.1-1ubuntu10.28] (ubuntu-server, virt)
<Eickmeyer> Any AA have a quick moment to look at raysession in NEW?
<Eickmeyer> Really simple package.
-queuebot:#ubuntu-release- Unapproved: rejected libvirt [source] (xenial-proposed) [1.3.1-1ubuntu10.27]
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (xenial-proposed) [1.3.1-1ubuntu10.28]
-queuebot:#ubuntu-release- Unapproved: nss (xenial-proposed/main) [2:3.28.4-0ubuntu0.16.04.6 => 2:3.28.4-0ubuntu0.16.04.7] (core)
-queuebot:#ubuntu-release- Unapproved: nss (disco-proposed/main) [2:3.42-1ubuntu2.1 => 2:3.42-1ubuntu2.2] (core)
-queuebot:#ubuntu-release- Unapproved: nss (bionic-proposed/main) [2:3.35-2ubuntu2.3 => 2:3.35-2ubuntu2.4] (core)
-queuebot:#ubuntu-release- Unapproved: accepted ruby2.3 [source] (xenial-proposed) [2.3.1-2~ubuntu16.04.13]
<rbasak> bdmurray: over to you. I've looked at everything in the Xenial queue older than usb-creator except ubuntu-meta, landscape-client and snapd-glib.
-queuebot:#ubuntu-release- New binary: mysql-8.0 [arm64] (eoan-proposed/universe) [8.0.16-0ubuntu1] (no packageset)
<rbasak> vorlon: ^ all archs ready for binNEW now please. I fixed the previous FTBFS with a new upstream microrelease upload (and related packaging fixes).
-queuebot:#ubuntu-release- New: accepted mysql-8.0 [ppc64el] (eoan-proposed) [8.0.14-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted mysql-8.0 [s390x] (eoan-proposed) [8.0.14-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted mysql-8.0 [arm64] (eoan-proposed) [8.0.14-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted mysql-8.0 [amd64] (eoan-proposed) [8.0.16-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mysql-8.0 [armhf] (eoan-proposed) [8.0.16-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mysql-8.0 [ppc64el] (eoan-proposed) [8.0.16-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mysql-8.0 [armhf] (eoan-proposed) [8.0.14-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted mysql-8.0 [i386] (eoan-proposed) [8.0.16-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mysql-8.0 [arm64] (eoan-proposed) [8.0.16-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mysql-8.0 [s390x] (eoan-proposed) [8.0.16-0ubuntu1]
-queuebot:#ubuntu-release- New binary: glare [amd64] (eoan-proposed/universe) [0.5.0-4ubuntu1] (no packageset)
#ubuntu-release 2019-07-25
-queuebot:#ubuntu-release- New binary: pygac [amd64] (eoan-proposed/universe) [1.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-language-python [s390x] (eoan-proposed/universe) [0.5.6-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (disco-proposed) [5.0.0-22.23]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (disco-proposed) [5.0.0-22.23]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (disco-proposed) [5.0.0-22.23]
<ddstreet> sil2100 if you have time today, could you review systemd uploads for b/d?  i'm out on vac starting tomorrow
<sil2100> ddstreet: hey! Sure, was waiting for the librarian to get back up
<sil2100> I think it's still work-in-progress though
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-340 (bionic-proposed/restricted) [340.107-0ubuntu0.18.04.2 => 340.107-0ubuntu0.18.04.3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: snapd (disco-proposed/main) [2.39.2+19.04 => 2.40+19.04] (core)
-queuebot:#ubuntu-release- Unapproved: snapd (bionic-proposed/main) [2.39.2+18.04 => 2.40+18.04] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.39.2ubuntu0.2 => 2.40] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (xenial-proposed/main) [1.361.3 => 1.361.4] (core)
<rbalint> kenvandine: ^ i included your changes in my upload if you don'd mind since you were the first in the queue, thanks rbasak for the heads-up
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-56.62] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-56.62] (core, kernel)
<rbalint> sil2100, could you please reject my xenial ubuntu-meta upload from yesterday?
<rbasak> rbalint: ah, I just did that, and kenvandine's one, to avoid confusion
<rbasak> Thank you for squashing them
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-meta [source] (xenial-proposed) [1.361.4]
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-meta [source] (xenial-proposed) [1.361.4]
-queuebot:#ubuntu-release- Unapproved: rtl8812au (bionic-proposed/universe) [4.3.8.12175.20140902+dfsg-0ubuntu8.1 => 4.3.8.12175.20140902+dfsg-0ubuntu12~ubuntu18.04.1] (no packageset)
<kenvandine> rbalint: thanks!
<sil2100> o/ Since it's past 1400 UTC, I'll be copying the langpacks that have been tested so far
<rbalint> rbasak, thanks! sil2100, while i just asked for rejection i would not mind if the merged upload could be accepted later ;-)
<sil2100> rbalint: will do! Librarian seems to be generating diffs once again so I'll resume my SRU shift shortly
<cjwatson> (librarian stores/serves diffs rather than generating them.  but yes)
<sil2100> cjwatson: ah, right! Guess my mind just groups all things into one entity, whoops
 * rbasak plugs "git ubuntu queue" again, which does a better job of diffs that Launchpad's generation for packages that are being imported :-P
<rbasak> (it does mean that you need to clone the repo though, which can be a pain for a small number of very large packages)
<sil2100> rbalint, ddstreet: will get to your SRUs shortly, just need to sort out the langpack update situation for .3 and then I'm good to go
<sil2100> Ok, I suppose there's quite a backlog of stuff, so no debdiffs for the new uploads yet - let me diff those by hand
-queuebot:#ubuntu-release- Unapproved: libblockdev (disco-proposed/main) [2.20-7 => 2.20-7ubuntu0.1] (desktop-core)
<Laney> that libblockdev is a data loss issue, fairly important imo
<sil2100> rbalint: before handling the xenial ubuntu-meta, I think we'll need to get the bionic ubuntu-meta accepted - and for that to be accepted, we need the ubuntu-meta currently in bionic-proposed released
<rbalint> sil2100, yes, i was about to ask about the previous upload
<rbalint> kenvandine, ^ the ffe seems incomplete and LP: #1795959 is verification-needed
<ubot5> Launchpad bug 1795959 in ubuntu-meta (Ubuntu Xenial) "[FFe] Seed xdg-desktop-portal-gtk" [Medium,New] https://launchpad.net/bugs/1795959
<rbalint> kenvandine, do you plan finishing those? i'd like to get the new upload approved :-)
<kenvandine> rbalint: i thought it was...
<kenvandine> rbalint: what do i need done?
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox-ext-pack [source] (bionic-proposed) [5.2.30-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox-hwe [source] (bionic-proposed) [5.2.30-dfsg-0~ubuntu18.04.1]
<kenvandine> i guess the xenial status changed?
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox-guest-additions-iso [source] (bionic-proposed) [5.2.30-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox [source] (bionic-proposed) [5.2.30-dfsg-0~ubuntu18.04.1]
<kenvandine> by the release team
<rbalint> kenvandine, the upload does not seem to be verified on bionic
<kenvandine> rbalint: i'll be verifying that in bionic today
<kenvandine> already started installing in a VM :)
<Laney> vorlon: hi, regarding https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1837068/comments/2 - I don't see that; it seems like a change in libss*h* itself is provoking this failure and that's what seb128 was asking for help with
<ubot5> Ubuntu bug 1837068 in valgrind (Ubuntu) "libssh armhf autopkgtest failure on valgrind unhandled instruction: 0xEBAD 0x1CCA" [High,New]
<vorlon> Laney: I think I posted a second comment saying I'm wrong
<Laney> ah sorry, let me refresh
<Laney> thanks
<Laney> as you were :-)
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox [source] (bionic-proposed) [5.2.32-dfsg-0~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox-hwe [source] (bionic-proposed) [5.2.32-dfsg-0~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (bionic-proposed/multiverse) [5.2.18-dfsg-3~ubuntu18.04.3 => 5.2.32-dfsg-0~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-hwe [source] (bionic-proposed) [5.2.32-dfsg-0~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-ext-pack [source] (bionic-proposed) [5.2.32-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-guest-additions-iso [source] (bionic-proposed) [5.2.32-1~ubuntu18.04.1]
<kenvandine> rbalint: verified
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (disco-proposed) [240-6ubuntu5.3]
<sil2100> ddstreet: will review bionic in a moment ^
<sil2100> kenvandine, rbalint: thanks! In this case I'll check the verification, release ubuntu-meta and then try to review the new one
<sil2100> That being said, I need to go AFK for a bit now
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-56.62]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-56.62]
-queuebot:#ubuntu-release- Unapproved: accepted usb-creator [source] (disco-proposed) [0.3.5ubuntu19.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted usb-creator [source] (bionic-proposed) [0.3.5ubuntu18.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted usb-creator [source] (xenial-proposed) [0.3.2ubuntu16.04.2]
-queuebot:#ubuntu-release- New binary: bobcat [s390x] (eoan-proposed/universe) [5.00.02-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bobcat [amd64] (eoan-proposed/universe) [5.00.02-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bobcat [i386] (eoan-proposed/universe) [5.00.02-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bobcat [ppc64el] (eoan-proposed/universe) [5.00.02-2] (no packageset)
-queuebot:#ubuntu-release- New binary: build-essential [amd64] (eoan-proposed/main) [12.6ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: bobcat [armhf] (eoan-proposed/universe) [5.00.02-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bobcat [arm64] (eoan-proposed/universe) [5.00.02-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (bionic-proposed) [237-3ubuntu10.25]
-queuebot:#ubuntu-release- New: accepted build-essential [amd64] (eoan-proposed) [12.6ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (bionic-proposed) [1.417.3]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (xenial-proposed) [1.361.4]
#ubuntu-release 2019-07-26
<juliank> So it seems that autopkgtest request.cgi is hanging after auth check
<juliank> Restarted rabbitmq-server, seems to have fixed it
<juliank> (it was stuck reading from amqp, so maybe it got into some weird state or something)
<sil2100> cjwatson: hey! I assume it's because there's a huge backlog, but I noticed that debdiffs for many packages in the queues aren't available yet - poking in case there's something that needs to be poked
<sil2100> Manually
-queuebot:#ubuntu-release- New source: rtl8821ce (eoan-proposed/primary) [5.2.5.2.1.30816.20190425-0ubuntu1]
<Trevinho> tjaalton: can you please look at mutter / shell SRUs in bionic / disco?
<tjaalton> Trevinho: I'm off this week and most of next one too
<vorlon> Laney: well I'm having fun with LP: #1837068, because so far I'm not able to get the 0.8.7 to pass correctly either, it hangs strangely
<ubot5> Launchpad bug 1837068 in valgrind (Ubuntu) "libssh armhf autopkgtest failure on valgrind unhandled instruction: 0xEBAD 0x1CCA" [High,New] https://launchpad.net/bugs/1837068
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1016.18] (no packageset)
<tjaalton> vorlon: if you have time, could you poke mesa for bionic, it's the new stable release (plus some ice lake patches) which was accepted for disco earlier this week but the bionic upload was missing at that point
<vorlon> tjaalton: ack, will do
-queuebot:#ubuntu-release- Unapproved: rejected erlang [source] (bionic-proposed) [1:20.2.2+dfsg-1ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: rejected snapd-glib [source] (bionic-proposed) [1.48-0ubuntu0.18.04.0]
<tjaalton> vorlon: sweet, thanks!
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [source] (bionic-proposed) [3.28.4-0ubuntu18.04.2]
<juliank> Laney: https://code.launchpad.net/~juliank/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/370679
<Laney> gr8
<Laney> m8
-queuebot:#ubuntu-release- Unapproved: rejected libarchive [source] (bionic-proposed) [3.2.2-3.1ubuntu0.3.1]
-queuebot:#ubuntu-release- Unapproved: libarchive (bionic-proposed/main) [3.2.2-3.1ubuntu0.3 => 3.2.2-3.1ubuntu0.4] (core)
<vorlon> coreycb: not processing your software-properties bionic SRU because there's another one ahead of you in -proposed that's been awaiting verification for 15 days. Can you work with seb128 to get that verified so that yours can go through?  (Or alternatively if you want to commit to doing the verification of all 3 sru bugs I can accept your upload now over the one in -proposed)
<rbasak> vorlon: did you read my bug comment?
<vorlon> rbasak: no
<rbasak> Bundling with an existing SRU would mitigate it
<vorlon> indeed
-queuebot:#ubuntu-release- Unapproved: accepted cmake [source] (bionic-proposed) [3.10.2-1ubuntu2.18.04.1]
<vorlon> haha LP: #1836361
<ubot5> Launchpad bug 1836361 in spice-html5 (Ubuntu Disco) "Windows guest display is inverted vertically" [Medium,In progress] https://launchpad.net/bugs/1836361
<vorlon> "almost unusable"
-queuebot:#ubuntu-release- Unapproved: accepted spice-html5 [source] (bionic-proposed) [0.1.7-2ubuntu1]
<ginggs> well, if you hold a mirror below your screen and look down...
<coreycb> vorlon: np that's trivial anyway
<vorlon> coreycb: what's your preference? do you want us to accept it and then you work w/ seb128 to get all the fixes released?
<coreycb> vorlon: sure that'll work
-queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (bionic-proposed) [0.96.24.32.11]
<coreycb> thanks vorlon
<LocutusOfBorg> any AA, please remove missing build on armhf: alt-ergo (from 1.30+dfsg1-2)
<LocutusOfBorg> it has been removed in Debian already, thanks
<LocutusOfBorg> missing build on amd64: libssreflect-ocaml, libssreflect-ocaml-dev (from 1.6.1-3build1)
<LocutusOfBorg> also this one, needs NBS-proposed decruft
<vorlon> alt-ergo/armhf removed
-queuebot:#ubuntu-release- New binary: menhir [amd64] (eoan-proposed/universe) [20190626-2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: menhir [ppc64el] (eoan-proposed/universe) [20190626-2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: menhir [i386] (eoan-proposed/universe) [20190626-2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: menhir [s390x] (eoan-proposed/universe) [20190626-2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: menhir [s390x] (eoan-proposed/universe) [20190626-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: menhir [amd64] (eoan-proposed/universe) [20190626-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: menhir [ppc64el] (eoan-proposed/universe) [20190626-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: menhir [i386] (eoan-proposed/universe) [20190626-3ubuntu1] (no packageset)
<LocutusOfBorg> please accept menhir, with that one fixed, we should be mostly ready for ocaml migration
-queuebot:#ubuntu-release- New binary: menhir [armhf] (eoan-proposed/universe) [20190626-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: menhir [arm64] (eoan-proposed/universe) [20190626-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted swift [amd64] (eoan-proposed) [2.22.0~b1~git2019071110.e62f07d98-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted swift [amd64] (eoan-proposed) [2.22.0~b1~git2019071110.e62f07d98-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted swift [amd64] (eoan-proposed) [2.22.0~b1~git2019071110.e62f07d98-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted ironic-ui [amd64] (eoan-proposed) [3.4.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted zaqar-ui [amd64] (eoan-proposed) [7.0.0~b1~git2019071614.472d462-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted python-os-net-config [amd64] (eoan-proposed) [11.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted qtstyleplugins-src [amd64] (eoan-proposed) [5.0.0+git23.g335dbec-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted qtstyleplugins-src [armhf] (eoan-proposed) [5.0.0+git23.g335dbec-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted qtstyleplugins-src [ppc64el] (eoan-proposed) [5.0.0+git23.g335dbec-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted qtstyleplugins-src [arm64] (eoan-proposed) [5.0.0+git23.g335dbec-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted qtstyleplugins-src [s390x] (eoan-proposed) [5.0.0+git23.g335dbec-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted qtstyleplugins-src [i386] (eoan-proposed) [5.0.0+git23.g335dbec-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted bobcat [amd64] (eoan-proposed) [5.00.02-2]
-queuebot:#ubuntu-release- New: accepted bobcat [armhf] (eoan-proposed) [5.00.02-2]
-queuebot:#ubuntu-release- New: accepted bobcat [ppc64el] (eoan-proposed) [5.00.02-2]
-queuebot:#ubuntu-release- New: accepted haskell-language-python [s390x] (eoan-proposed) [0.5.6-1]
-queuebot:#ubuntu-release- New: accepted bobcat [arm64] (eoan-proposed) [5.00.02-2]
-queuebot:#ubuntu-release- New: accepted bobcat [s390x] (eoan-proposed) [5.00.02-2]
-queuebot:#ubuntu-release- New: accepted bobcat [i386] (eoan-proposed) [5.00.02-2]
-queuebot:#ubuntu-release- New: accepted pygac [amd64] (eoan-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- New: accepted glare [amd64] (eoan-proposed) [0.5.0-4ubuntu1]
-queuebot:#ubuntu-release- New: rejected menhir [amd64] (eoan-proposed) [20190626-2ubuntu2]
-queuebot:#ubuntu-release- New: rejected menhir [ppc64el] (eoan-proposed) [20190626-2ubuntu2]
-queuebot:#ubuntu-release- New: rejected menhir [i386] (eoan-proposed) [20190626-2ubuntu2]
-queuebot:#ubuntu-release- New: rejected menhir [s390x] (eoan-proposed) [20190626-2ubuntu2]
-queuebot:#ubuntu-release- New: accepted menhir [amd64] (eoan-proposed) [20190626-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted menhir [armhf] (eoan-proposed) [20190626-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted menhir [ppc64el] (eoan-proposed) [20190626-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted menhir [arm64] (eoan-proposed) [20190626-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted menhir [s390x] (eoan-proposed) [20190626-3ubuntu1]
<vorlon> LocutusOfBorg: ^^
-queuebot:#ubuntu-release- New: accepted menhir [i386] (eoan-proposed) [20190626-3ubuntu1]
#ubuntu-release 2019-07-27
<vorlon> tjaalton: why is icl-backport.diff only in the bionic mesa upload, not in the disco one?  what happens to users who upgrade from bionic to disco?
-queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (bionic-proposed) [19.0.8-0ubuntu0~18.04.1]
<tjaalton> vorlon: disco kernel doesn't support icl
<tjaalton> so I thought it wouldn't matter there
<vorlon> tjaalton: well, a) why not, isn't it expected that the kernels in the later non-LTS releases include the same features as the LTS kernels? (I see linux-oem-osp1 is present in bionic and disco at roughly the same versions)
<vorlon> and b), what does happen to a user of one of these machines when they upgrade to disco?
<tjaalton> vorlon: well, true, if a user is on osp1 kernel on bionic it should still have it after upgrade..
<tjaalton> but what happens is that things won't suddenly break. in fact we've had the stock disco mesa while enabling icl and I haven't heard any complaints yet
<tjaalton> the patches do fix some issues like the dri driver complaining that icl is still 'premature' if an app is launched from the terminal, for instance
<vorlon> ok
<ginggs> would someone please 'force-badtest python-sparse/0.2.0-1/i386' ? - it has regressed in release
<ginggs> also please 'force-badtest satpy/0.16.1-1'
#ubuntu-release 2019-07-28
<LocutusOfBorg> last day I saw the light
<LocutusOfBorg> I saw the hol-light, and that light told me: "please can you kick me out from Ubuntu at least to proposed pocket? I'm holding the ocaml transition, I'm a leaf package, nobody cares about me, and I'm out from Debian testing since a while"
<LocutusOfBorg> please AA, ^^
<LocutusOfBorg> please also NBS cleanup missing build on armhf: artemis (from 17.0.1+dfsg-1)
<LocutusOfBorg> ^^
-queuebot:#ubuntu-release- New binary: golang-go.opencensus [amd64] (eoan-proposed/universe) [0.22.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: librsync [amd64] (eoan-proposed/universe) [2.0.2-1] (ubuntu-budgie, ubuntu-mate)
-queuebot:#ubuntu-release- New binary: librsync [i386] (eoan-proposed/universe) [2.0.2-1] (ubuntu-budgie, ubuntu-mate)
-queuebot:#ubuntu-release- New binary: librsync [ppc64el] (eoan-proposed/universe) [2.0.2-1] (ubuntu-budgie, ubuntu-mate)
-queuebot:#ubuntu-release- New binary: librsync [arm64] (eoan-proposed/universe) [2.0.2-1] (ubuntu-budgie, ubuntu-mate)
-queuebot:#ubuntu-release- New binary: librsync [armhf] (eoan-proposed/universe) [2.0.2-1] (ubuntu-budgie, ubuntu-mate)
-queuebot:#ubuntu-release- New binary: librsync [s390x] (eoan-proposed/universe) [2.0.2-1] (ubuntu-budgie, ubuntu-mate)
#ubuntu-release 2020-07-20
-queuebot:#ubuntu-release- New binary: sjfonts [amd64] (groovy-proposed/universe) [2.1-2] (kubuntu)
-queuebot:#ubuntu-release- New source: oem-somerville-beric-icl-meta (focal-proposed/primary) [20.04~ubuntu1]
-queuebot:#ubuntu-release- New source: oem-somerville-meera-tgl-meta (focal-proposed/primary) [20.04~ubuntu1]
-queuebot:#ubuntu-release- New source: oem-stella.cmit-charizard-meta (focal-proposed/primary) [20.04~ubuntu1]
-queuebot:#ubuntu-release- New source: oem-sutton.newell-cadby-meta (focal-proposed/primary) [20.04~ubuntu1]
-queuebot:#ubuntu-release- New source: oem-sutton.newell-cadee-meta (focal-proposed/primary) [20.04~ubuntu1]
-queuebot:#ubuntu-release- New source: oem-somerville-bulbasaur-meta (focal-proposed/primary) [20.04~ubuntu1]
-queuebot:#ubuntu-release- New source: oem-sutton.bachman-banaing-meta (focal-proposed/primary) [20.04~ubuntu1]
-queuebot:#ubuntu-release- New source: oem-sutton.newell-cadence-meta (focal-proposed/primary) [20.04~ubuntu1]
-queuebot:#ubuntu-release- New source: oem-somerville-samwell-tgl-meta (focal-proposed/primary) [20.04~ubuntu1]
-queuebot:#ubuntu-release- New source: oem-sutton.newell-cade-meta (focal-proposed/primary) [20.04~ubuntu1]
<Laney> sil2100: ^- happy monday :>
<sil2100> yay
<sil2100> ;)
<sil2100> ekhm, will pick those up in a moment
<Laney> sil2100: apw: btw I just started drafting the SRU thing https://wiki.ubuntu.com/StableReleaseUpdates/OEMMeta
<Laney> going to ask the CE team to fill in a bug template for future ones
-queuebot:#ubuntu-release- New: accepted linux-signed-azure-4.15 [amd64] (bionic-proposed) [4.15.0-1092.102]
<frederikf[m][m]> test
<Laney> it worked :>
<frederikf[m][m]> yay, my goodness.. IRC is to complex for me ð
<frederikf[m][m]> Hello - Trevinho told me to ask here to get the yaru package into focal: https://launchpad.net/ubuntu/focal/+queue?queue_state=1&queue_text=
<frederikf[m][m]> I am not sure I understood exactly what I should do but yes, here I am asking to get it into focal ð @sil
<frederikf[m][m]>  * Hello - Trevinho told me to ask here to get the yaru package into focal: https://launchpad.net/ubuntu/focal/+queue?queue_state=1&queue_text=
<frederikf[m][m]> I am not sure I understood exactly what I should do but yes, here I am asking to get it into focal ð @sil2100 @bdmurray @rbasak
<sil2100> frederikf[m][m]: ok, I see it in the queue, is it a fix for something high-impact?
<frederikf[m][m]> sil2100: it includes bug fixes and some improvements. I think one bug we've fixed there is kind of important, the wacom overlay not showing up correctly in gnome-shell. The rest is also important ofc, but this one was a quiet big bug imo. The full list can be seen here: https://github.com/ubuntu/yaru/pull/2239#issue-447283432
<gitbot> ubuntu issue (Pull request) 2239 in yaru "WIP: Prepare for Ubuntu 20.04 first point release" [Closed]
<frederikf[m][m]> ah okay now I understand. It would need to  be manually promoted if it has a important bug fix, but it will land in focal now anyways since it's in the queue?
<sil2100> frederikf[m][m]: so generally things in the SRU queues for stable series are handled in-order, but sometimes we can pick up something earlier if it's priority
<sil2100> frederikf[m][m]: I'll look at it now, but I can't guarantee it will land for 20.04.1!
<frederikf[m][m]> @sil2100 okay ð Would be really cool to get it into 20.04.1 - thanks in advance!
<sil2100> frederikf[m][m]: also, a tip for the future: in the test case please mention using the -proposed package instead of building from master ;) Since we need users to test the actual packages that they'll be getting!
<sil2100> I updated the descriptions already
<frederikf[m][m]> We are good at github but really need to learn more about launchpad - sorry â¹ï¸ We try to improve!
<sil2100> frederikf[m][m]: no worries! The paperwork for the bugs seems quite solid by itself
<frederikf[m][m]> ð Cool! Fingers crossed ð¤
<sil2100> frederikf[m][m]: just one quick question (this is a non-blocker): I see the upload has some .pngs added in a .github/ directory
<sil2100> You might want to clean that up with the next upload, if those are not meant to be in the debian package!
<sil2100> No need to do it now, just giving a heads up that there are those files there
<frederikf[m][m]> oh hm... I would need to talk to clobrano how to detach the github stuff from the debian packages
<sil2100> That's fine! Anyway, accepting into focal-proposed o/
<frederikf[m][m]> Oh, cool? So it's happening? ^^
-queuebot:#ubuntu-release- Unapproved: accepted yaru-theme [sync] (focal-proposed) [20.04.8]
<sil2100> Yes ^
<frederikf[m][m]> Nice, thank you very much!
<mwhudson> i think it's fairly certain https://autopkgtest.ubuntu.com/packages/s/slime/groovy/armhf has regressed in release
<mwhudson> also https://code.launchpad.net/~mwhudson/britney/hints-ubuntu/+merge/387658 if any ubuntu-release people are around
-queuebot:#ubuntu-release- New binary: golang-github-avast-apkverifier [s390x] (groovy-proposed/universe) [0.0~git20191015.7330a51-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-avast-apkverifier [amd64] (groovy-proposed/universe) [0.0~git20191015.7330a51-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-avast-apkverifier [armhf] (groovy-proposed/universe) [0.0~git20191015.7330a51-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-avast-apkverifier [arm64] (groovy-proposed/universe) [0.0~git20191015.7330a51-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-avast-apkverifier [riscv64] (groovy-proposed/universe) [0.0~git20191015.7330a51-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-avast-apkverifier [ppc64el] (groovy-proposed/universe) [0.0~git20191015.7330a51-1] (no packageset)
<kanashiro> ubuntu-archive: could someone take a look at LP #1868500 ?
<ubot5> Launchpad bug 1868500 in golang-github-prometheus-client-golang (Ubuntu) "Please remove binaries for 0.9.2-0ubuntu3" [Undecided,New] https://launchpad.net/bugs/1868500
-queuebot:#ubuntu-release- Unapproved: linux-firmware-raspi2 (focal-proposed/multiverse) [1.20200212-0ubuntu1 => 1.20200601+arm64-0ubuntu2~20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: linux-firmware-raspi2 (bionic-proposed/multiverse) [1.20190819-0ubuntu0.18.04.1 => 1.20200601+arm64-0ubuntu2~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: pcl [s390x] (groovy-proposed/universe) [1.11.0+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New source: rpi-eeprom (groovy-proposed/primary) [7.8-0ubuntu1]
-queuebot:#ubuntu-release- New binary: pcl [ppc64el] (groovy-proposed/universe) [1.11.0+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New: rejected rpi-eeprom [source] (groovy-proposed) [7.8-0ubuntu1]
-queuebot:#ubuntu-release- New source: rpi-eeprom (groovy-proposed/primary) [7.8-0ubuntu1]
-queuebot:#ubuntu-release- New source: rpi-eeprom (focal-proposed/primary) [7.8-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: openvswitch (xenial-proposed/main) [2.5.5-0ubuntu0.16.04.2 => 2.5.9-0ubuntu0.16.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: pcl [amd64] (groovy-proposed/universe) [1.11.0+dfsg-3] (no packageset)
<Laney> I should upload https://code.launchpad.net/~ubuntu-core-dev/livecd-rootfs/+git/livecd-rootfs/+merge/387515 I guess
<Laney> be good to have an unborked studio
<vorlon> xnox, mwhudson: oh, and ancientminister is focal, so if there are differences now in the behavior of different xorriso versions...
-queuebot:#ubuntu-release- New: accepted rpi-eeprom [source] (groovy-proposed) [7.8-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted rpi-eeprom [source] (focal-proposed) [7.8-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- New binary: rpi-eeprom [amd64] (groovy-proposed/multiverse) [7.8-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rpi-eeprom [amd64] (focal-proposed/multiverse) [7.8-0ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: pcl [arm64] (groovy-proposed/universe) [1.11.0+dfsg-3] (no packageset)
<vorlon> really finding the new britney difficult to work with wrt transitions, because I can only see one blocking issue per iteration of britney :/
<vorlon> rolling back qemu since it causes significant regressions and blocks nettle+ghc
-queuebot:#ubuntu-release- New: accepted rpi-eeprom [amd64] (focal-proposed) [7.8-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- New: accepted rpi-eeprom [amd64] (groovy-proposed) [7.8-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted oem-somerville-beric-icl-meta [source] (focal-proposed) [20.04~ubuntu1]
-queuebot:#ubuntu-release- New binary: oem-somerville-beric-icl-meta [amd64] (focal-proposed/none) [20.04~ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted oem-somerville-bulbasaur-meta [source] (focal-proposed) [20.04~ubuntu1]
-queuebot:#ubuntu-release- New: accepted oem-somerville-beric-icl-meta [amd64] (focal-proposed) [20.04~ubuntu1]
-queuebot:#ubuntu-release- New binary: oem-somerville-bulbasaur-meta [amd64] (focal-proposed/none) [20.04~ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: covtobed [ppc64el] (groovy-proposed/none) [1.1.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: jskeus [s390x] (groovy-proposed/none) [1.2.4+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: covtobed [s390x] (groovy-proposed/none) [1.1.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: jskeus [ppc64el] (groovy-proposed/none) [1.2.4+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: jskeus [amd64] (groovy-proposed/none) [1.2.4+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: covtobed [armhf] (groovy-proposed/none) [1.1.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: covtobed [arm64] (groovy-proposed/none) [1.1.2+dfsg-2] (no packageset)
<ginggs> should src:nvidia-graphics-drivers-tesla-418 be removed from proposed and added sync-blacklist?
-queuebot:#ubuntu-release- New binary: jskeus [armhf] (groovy-proposed/universe) [1.2.4+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: covtobed [amd64] (groovy-proposed/universe) [1.1.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: jskeus [arm64] (groovy-proposed/universe) [1.2.4+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: covtobed [riscv64] (groovy-proposed/universe) [1.1.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: jskeus [riscv64] (groovy-proposed/universe) [1.2.4+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: dolfin [s390x] (groovy-proposed/universe) [2019.2.0~git20200218.027d9cc-12] (no packageset)
<hellsworth> sil2100: hey could you please take a look at https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1886692
<ubot5> Ubuntu bug 1886692 in libreoffice (Ubuntu) " [SRU] libreoffice 6.4.5 for focal" [High,In progress]
<hellsworth> thanks :)
-queuebot:#ubuntu-release- New binary: dolfin [ppc64el] (groovy-proposed/universe) [2019.2.0~git20200218.027d9cc-12] (no packageset)
-queuebot:#ubuntu-release- New binary: dolfin [amd64] (groovy-proposed/universe) [2019.2.0~git20200218.027d9cc-12] (no packageset)
-queuebot:#ubuntu-release- New: accepted oem-somerville-bulbasaur-meta [amd64] (focal-proposed) [20.04~ubuntu1]
-queuebot:#ubuntu-release- New: accepted oem-somerville-meera-tgl-meta [source] (focal-proposed) [20.04~ubuntu1]
-queuebot:#ubuntu-release- New binary: oem-somerville-meera-tgl-meta [amd64] (focal-proposed/universe) [20.04~ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted oem-somerville-samwell-tgl-meta [source] (focal-proposed) [20.04~ubuntu1]
-queuebot:#ubuntu-release- New: accepted oem-somerville-meera-tgl-meta [amd64] (focal-proposed) [20.04~ubuntu1]
-queuebot:#ubuntu-release- New binary: dolfin [armhf] (groovy-proposed/universe) [2019.2.0~git20200218.027d9cc-12] (no packageset)
-queuebot:#ubuntu-release- New binary: dolfin [arm64] (groovy-proposed/universe) [2019.2.0~git20200218.027d9cc-12] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware-raspi2 [source] (focal-proposed) [1.20200601+arm64-0ubuntu2~20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware-raspi2 [source] (bionic-proposed) [1.20200601+arm64-0ubuntu2~18.04.1]
-queuebot:#ubuntu-release- New binary: pcl [riscv64] (groovy-proposed/universe) [1.11.0+dfsg-3] (no packageset)
<mwhudson> vorlon: i tested stuff on focal and xenial when hacking around, didn't notice any differences
<mwhudson> oh apart from focal supporting some flag xenial doesn't
<mwhudson> vorlon: badtest slime/armhf/2:2.24+dfsg-2 pls, i think that's all that is holding up gcc-10
<xnox> vorlon:  not sure if it's Britney or like the fact that we need to wait for 10h to get riscv build.
<vorlon> rolling back dnsmasq, new upstream version breaks network-manager autopkgtests and block nettle transition
<vorlon> mwhudson: why badtest it given that your latest test of slime by itself passed?
<mwhudson> vorlon: oh did it?
<mwhudson> hadn't refreshed this morning apparently
 * mwhudson retries with ecl again then
<mwhudson> it's the sbcl tests that are failing though
-queuebot:#ubuntu-release- New binary: libcpuid [amd64] (groovy-proposed/universe) [0.5.0+repack1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ddcutil [amd64] (groovy-proposed/universe) [0.9.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cwiid [s390x] (groovy-proposed/universe) [0.6.91-1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: ddcutil [s390x] (groovy-proposed/universe) [0.9.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cwiid [amd64] (groovy-proposed/universe) [0.6.91-1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: cwiid [ppc64el] (groovy-proposed/universe) [0.6.91-1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: cwiid [arm64] (groovy-proposed/universe) [0.6.91-1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: ddcutil [ppc64el] (groovy-proposed/universe) [0.9.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cwiid [armhf] (groovy-proposed/universe) [0.6.91-1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: haskell-secret-sharing [s390x] (groovy-proposed/universe) [1.0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-secret-sharing [amd64] (groovy-proposed/universe) [1.0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-secret-sharing [ppc64el] (groovy-proposed/universe) [1.0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ddcutil [arm64] (groovy-proposed/universe) [0.9.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: eclipse-platform-team [amd64] (groovy-proposed/universe) [4.16+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ddcutil [armhf] (groovy-proposed/universe) [0.9.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: phosh [amd64] (groovy-proposed/universe) [0.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-secret-sharing [arm64] (groovy-proposed/universe) [1.0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-secret-sharing [armhf] (groovy-proposed/universe) [1.0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tao-json [amd64] (groovy-proposed/universe) [0.0+git20200604.f357d72-1] (no packageset)
<mwhudson> still hate that delay between a test finishing and the result page updating
-queuebot:#ubuntu-release- New: accepted ddcutil [arm64] (groovy-proposed) [0.9.9-1]
-queuebot:#ubuntu-release- New: accepted eclipse-platform-team [amd64] (groovy-proposed) [4.16+dfsg-3]
-queuebot:#ubuntu-release- New: accepted haskell-secret-sharing [armhf] (groovy-proposed) [1.0.1.2-1]
-queuebot:#ubuntu-release- New: accepted tao-json [amd64] (groovy-proposed) [0.0+git20200604.f357d72-1]
-queuebot:#ubuntu-release- New: accepted ddcutil [armhf] (groovy-proposed) [0.9.9-1]
-queuebot:#ubuntu-release- New: accepted phosh [amd64] (groovy-proposed) [0.3.1-2]
-queuebot:#ubuntu-release- New: accepted haskell-secret-sharing [arm64] (groovy-proposed) [1.0.1.2-1]
-queuebot:#ubuntu-release- New: accepted cwiid [amd64] (groovy-proposed) [0.6.91-1]
-queuebot:#ubuntu-release- New: accepted cwiid [armhf] (groovy-proposed) [0.6.91-1]
-queuebot:#ubuntu-release- New: accepted cwiid [s390x] (groovy-proposed) [0.6.91-1]
-queuebot:#ubuntu-release- New: accepted ddcutil [ppc64el] (groovy-proposed) [0.9.9-1]
-queuebot:#ubuntu-release- New: accepted haskell-secret-sharing [amd64] (groovy-proposed) [1.0.1.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-secret-sharing [s390x] (groovy-proposed) [1.0.1.2-1]
-queuebot:#ubuntu-release- New: accepted cwiid [arm64] (groovy-proposed) [0.6.91-1]
-queuebot:#ubuntu-release- New: accepted ddcutil [amd64] (groovy-proposed) [0.9.9-1]
-queuebot:#ubuntu-release- New: accepted haskell-secret-sharing [ppc64el] (groovy-proposed) [1.0.1.2-1]
-queuebot:#ubuntu-release- New: accepted cwiid [ppc64el] (groovy-proposed) [0.6.91-1]
-queuebot:#ubuntu-release- New: accepted ddcutil [s390x] (groovy-proposed) [0.9.9-1]
-queuebot:#ubuntu-release- New: accepted covtobed [riscv64] (groovy-proposed) [1.1.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted dolfin [arm64] (groovy-proposed) [2019.2.0~git20200218.027d9cc-12]
-queuebot:#ubuntu-release- New: accepted dolfin [ppc64el] (groovy-proposed) [2019.2.0~git20200218.027d9cc-12]
-queuebot:#ubuntu-release- New: accepted jskeus [arm64] (groovy-proposed) [1.2.4+dfsg-2]
-queuebot:#ubuntu-release- New: accepted libcpuid [amd64] (groovy-proposed) [0.5.0+repack1-1]
-queuebot:#ubuntu-release- New: accepted dolfin [amd64] (groovy-proposed) [2019.2.0~git20200218.027d9cc-12]
-queuebot:#ubuntu-release- New: accepted dolfin [s390x] (groovy-proposed) [2019.2.0~git20200218.027d9cc-12]
-queuebot:#ubuntu-release- New: accepted pcl [riscv64] (groovy-proposed) [1.11.0+dfsg-3]
-queuebot:#ubuntu-release- New: accepted dolfin [armhf] (groovy-proposed) [2019.2.0~git20200218.027d9cc-12]
-queuebot:#ubuntu-release- New: accepted jskeus [riscv64] (groovy-proposed) [1.2.4+dfsg-2]
-queuebot:#ubuntu-release- New: accepted covtobed [amd64] (groovy-proposed) [1.1.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted covtobed [armhf] (groovy-proposed) [1.1.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted covtobed [s390x] (groovy-proposed) [1.1.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted jskeus [armhf] (groovy-proposed) [1.2.4+dfsg-2]
-queuebot:#ubuntu-release- New: accepted jskeus [s390x] (groovy-proposed) [1.2.4+dfsg-2]
-queuebot:#ubuntu-release- New: accepted covtobed [arm64] (groovy-proposed) [1.1.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted jskeus [amd64] (groovy-proposed) [1.2.4+dfsg-2]
-queuebot:#ubuntu-release- New: accepted pcl [arm64] (groovy-proposed) [1.11.0+dfsg-3]
-queuebot:#ubuntu-release- New: accepted covtobed [ppc64el] (groovy-proposed) [1.1.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted jskeus [ppc64el] (groovy-proposed) [1.2.4+dfsg-2]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (focal-proposed) [1:20.04.22]
-queuebot:#ubuntu-release- New: accepted golang-github-avast-apkverifier [amd64] (groovy-proposed) [0.0~git20191015.7330a51-1]
-queuebot:#ubuntu-release- New: accepted golang-github-avast-apkverifier [armhf] (groovy-proposed) [0.0~git20191015.7330a51-1]
-queuebot:#ubuntu-release- New: accepted golang-github-avast-apkverifier [riscv64] (groovy-proposed) [0.0~git20191015.7330a51-1]
-queuebot:#ubuntu-release- New: accepted pcl [amd64] (groovy-proposed) [1.11.0+dfsg-3]
-queuebot:#ubuntu-release- New: accepted pcl [s390x] (groovy-proposed) [1.11.0+dfsg-3]
-queuebot:#ubuntu-release- New: accepted golang-github-avast-apkverifier [arm64] (groovy-proposed) [0.0~git20191015.7330a51-1]
-queuebot:#ubuntu-release- New: accepted golang-github-avast-apkverifier [s390x] (groovy-proposed) [0.0~git20191015.7330a51-1]
-queuebot:#ubuntu-release- New: accepted golang-github-avast-apkverifier [ppc64el] (groovy-proposed) [0.0~git20191015.7330a51-1]
-queuebot:#ubuntu-release- New: accepted pcl [ppc64el] (groovy-proposed) [1.11.0+dfsg-3]
-queuebot:#ubuntu-release- New: accepted gnome-feeds [amd64] (groovy-proposed) [0.13.4+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted haskell-dhall [arm64] (groovy-proposed) [1.30.0-1]
-queuebot:#ubuntu-release- New: accepted sjfonts [amd64] (groovy-proposed) [2.1-2]
-queuebot:#ubuntu-release- New: accepted xmonad-wallpaper [arm64] (groovy-proposed) [0.0.1.4-7]
-queuebot:#ubuntu-release- New: accepted xmonad-wallpaper [ppc64el] (groovy-proposed) [0.0.1.4-7]
-queuebot:#ubuntu-release- New: accepted haskell-dhall [amd64] (groovy-proposed) [1.30.0-1]
-queuebot:#ubuntu-release- New: accepted xmonad-wallpaper [amd64] (groovy-proposed) [0.0.1.4-7]
-queuebot:#ubuntu-release- New: accepted xmonad-wallpaper [riscv64] (groovy-proposed) [0.0.1.4-7]
-queuebot:#ubuntu-release- New: accepted haskell-dhall [ppc64el] (groovy-proposed) [1.30.0-1]
-queuebot:#ubuntu-release- New: accepted xmonad-wallpaper [armhf] (groovy-proposed) [0.0.1.4-7]
-queuebot:#ubuntu-release- New: accepted xmonad-wallpaper [s390x] (groovy-proposed) [0.0.1.4-7]
<mwhudson> ah that failure was a bit more informative, things are timing out
#ubuntu-release 2020-07-21
<mwhudson> is there a sensible way to restrict autopkgtests to certain architectures?
<mwhudson> skip-not-installable is sorta related but also not really right
<vorlon> rolling back haskell-cborg, which got synced and delays the transition
<vorlon> rolling back haskell-optparse-simple, haskell-pretty-simple, haskell-streaming-commons which got synced and delay the transition
<mwhudson> vorlon: i think https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#glib2.0 is also relevant
<mwhudson> (via qemu)
<vorlon> >_<
<vorlon> will look in a moment
<mwhudson> https://autopkgtest.ubuntu.com/packages/libx/libxmlb/groovy/ppc64el looks like something to badtest
<mwhudson> not sure what's going on though
<mwhudson> maybe oom
<mwhudson> systemd seems to be flakiness in test-in-lxd
<vorlon> update_excuses mentions built-using glib2.0 but I'm hoping that's not a blocker
<mwhudson> and sbd is just strange
<mwhudson> i thought built-using was a blocker now
<mwhudson> guess we'll find out in the next run
<vorlon> ... it hasn't been discussed that it would be
<vorlon> and the output doesn't say that it's blocking
<vorlon> but systemd autopkgtest failure would block
<mwhudson> oh "Installability of Build-Depends is now considered for migrating"
<mwhudson> not built-using
<vorlon> ugh that also makes things more fragile
<mwhudson> uh huh "Invalidated by built-using"
<vorlon> :|
<vorlon> why does qemu declare Built-Using anyway
<vorlon> well when that's the only blocking issue, I'll override
<vorlon> but we should also probably correct that policy for Ubuntu, because we don't retain old binaries in the release pocket referenced by Built-Using, therefore this just causes pointless delays
 * mwhudson drums fingers
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (focal-proposed/main) [1:20.04.22 => 1:20.04.23] (core)
-queuebot:#ubuntu-release- New binary: tao-config [amd64] (groovy-proposed/universe) [0.0+git20200604.84a7383-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tao-config [amd64] (groovy-proposed/universe) [0.0+git20200604.84a7383-2] (no packageset)
<mwhudson> vorlon: i think it might be shoving time
<mwhudson> (i.e. qemu just held back by built-using constraints)
<vorlon> mwhudson: hint added
<mwhudson> vorlon: <dramatic music>
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (focal-proposed) [1:20.04.23]
<sil2100> tseliot_: hey! Looking at your focal ubuntu-drivers-common SRU - I see the .changes file mentions LP: #1882402, but I don't see a clear test case for that bug - and not sure if it was actually fixed?
<ubot5> Launchpad bug 1882402 in ubuntu-drivers-common (Ubuntu) "Ubuntu-drivers allows installation of (nvidia-340) drivers, which are broken/break things (Kubuntu 20.04)" [Undecided,Incomplete] https://launchpad.net/bugs/1882402
-queuebot:#ubuntu-release- Unapproved: nss (bionic-proposed/main) [2:3.35-2ubuntu2.9 => 2:3.35-2ubuntu2.10] (core)
<xnox> looks like it's migrating
-queuebot:#ubuntu-release- Unapproved: nss (focal-proposed/main) [2:3.49.1-1ubuntu1.2 => 2:3.49.1-1ubuntu1.3] (core, i386-whitelist)
<mwhudson> yeah seems so
<xnox> so, i feel like i must copy the new ghc inplace now that fixes big-endian bug
<mwhudson> that means retriggering all the autopkgtests in the world but no transition?
<xnox> mwhudson:  i don't think haskell has any autopkgtests, does it?
<mwhudson> oh maybe not
<xnox> i mean it effectively does static linking and runs all tests at build time, how wrong could things go?
<xnox> i see ghc tries to compile hello-word as an autopkgtest
<LocutusOfBorg> but does this require to rebuild everything, right?
<LocutusOfBorg> because of s390x abi changes?
<xnox> Yeap
<xnox> But ghc has just migrated, so it's not too bad.
<LocutusOfBorg> I would like to do something before the world comes back
<LocutusOfBorg> like protobuf
-queuebot:#ubuntu-release- Unapproved: ubuntu-dev-tools (bionic-proposed/universe) [0.175~18.04.1 => 0.175~18.04.2] (no packageset)
<LocutusOfBorg> and icu?
-queuebot:#ubuntu-release- New binary: protobuf [s390x] (groovy-proposed/main) [3.12.3-2] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: protobuf [s390x] (groovy-proposed/main) [3.12.3-2ubuntu1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: protobuf [amd64] (groovy-proposed/main) [3.12.3-2] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: protobuf [ppc64el] (groovy-proposed/main) [3.12.3-2] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: protobuf [ppc64el] (groovy-proposed/main) [3.12.3-2ubuntu1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: protobuf [amd64] (groovy-proposed/main) [3.12.3-2ubuntu1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: protobuf [armhf] (groovy-proposed/main) [3.12.3-2ubuntu1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: protobuf [arm64] (groovy-proposed/main) [3.12.3-2ubuntu1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: mutter (focal-proposed/main) [3.36.3-0ubuntu0.20.04.1 => 3.36.4-0ubuntu0.20.04.1] (desktop-core, desktop-extra)
-queuebot:#ubuntu-release- Unapproved: gnome-shell (focal-proposed/main) [3.36.3-1ubuntu1~20.04.2 => 3.36.4-1ubuntu1~20.04.1] (desktop-extra, mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted tao-config [amd64] (groovy-proposed) [0.0+git20200604.84a7383-1]
-queuebot:#ubuntu-release- New: accepted tao-config [amd64] (groovy-proposed) [0.0+git20200604.84a7383-2]
<tseliot_> sil2100, that bug report is just a false positive, not an actual bug. The "fix" is about not showing the error
-queuebot:#ubuntu-release- New binary: gxr [amd64] (groovy-proposed/multiverse) [0.15.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gxr [ppc64el] (groovy-proposed/multiverse) [0.15.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gxr [s390x] (groovy-proposed/multiverse) [0.15.1-2] (no packageset)
<Laney> I just pushed https://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu/commit/?id=ebbc7b5d0ef58b1601a01413c7008a7161ec5ce6
<Laney> should make excuses a bit clearer wrt transitions
-queuebot:#ubuntu-release- New binary: gxr [armhf] (groovy-proposed/multiverse) [0.15.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gxr [arm64] (groovy-proposed/multiverse) [0.15.1-2] (no packageset)
<doko> LocutusOfBorg: fyi, protobuf ftbfs on i386
-queuebot:#ubuntu-release- New binary: gxr [riscv64] (groovy-proposed/multiverse) [0.15.1-2] (no packageset)
<Laney> vorlon: I'll disable the Built-Using policy now, agreed it doesn't make much sense if the referenced source can disappear, but I think we should enable it once the Launchpad support is in place - should be this cycle.
-queuebot:#ubuntu-release- Unapproved: openjdk-14 (focal-proposed/universe) [14.0.1+7-1ubuntu1 => 14.0.2+12-1~20.04] (i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: openjdk-13 (focal-proposed/universe) [13.0.3+3-1ubuntu2 => 13.0.4+8-1~20.04] (i386-whitelist)
<LocutusOfBorg> doko, yep thanks
<LocutusOfBorg> doko, do you have any clue for the failure?
<LocutusOfBorg> vorlon, I think you will appreciate a lot this approach from mapreri https://salsa.debian.org/debian/bzip2/-/commit/7103774c39080518e74aff988c38c033d6433a8c
<LocutusOfBorg> no need to define anything, with this bash syntax
<seb128> hey there, when are the expect dates for getting things in focal .1? Until when do we have to get things accepted in proposed to still be able to make it?
<xnox> seb128:  there is still time, but it is tight.
<xnox> seb128:  what sort of things?
<xnox> seb128:  i think we are hoping to have candidates on the 30th. Ideally things should be in -updates by then. Thus i guess you can still upload stuff today/tomorrow.
<xnox> seb128:  but there a chance that a block will be placed on them preventing from migrating.
<seb128> xnox, well, I'm concerned that some updates are in the queue for 15 days and not getting reviewed
<seb128> we aimed at getting GNOME 3.36.4 in .1
<seb128> but things are not moving :-/
<seb128> we probably would like to get some other updates that are waiting like the ubuntu-drivers-common one
<seb128> or the new bug fix libreoffice update
 * xnox checks if libreoffice built on riscv64 and how many weeks it takes there
<xnox> seb128:  so, gnome does not sound like it's critical to be on the iso, right? it doens't prevent installation on any hardware?
<xnox> seb128:  which ubuntu-drivers-common fixes are they? => do those prevent completing the installation on any hardware?
<xnox> seb128:  cause otherwise they can all go as SRUs post .1 release media.
<xnox> seb128:  we must not delay .1 release.
<seb128> xnox, it's not install critical no, still we worked on timeline to get the current stack of our upstream included and it's frustrating that we get to ship an outdated version because we are not able to get things reviewed in a timelined fashion
<xnox> *nod*
<xnox> at least oem-* packages are being cranked through all the cranks at a priority
<seb128> right, that's probably more important than normal updates, so that at least makes sense
<xnox> yeap focal queue is long 32 packages
<sil2100> tseliot_: then let me remove it from the changelog then - if for an SRU anything is in the changelog, it needs to go through the usual verification process
<sil2100> tseliot_: and this is not it
<tseliot_> sil2100, ok, thanks
<ginggs> tseliot_: hi, should src:nvidia-graphics-drivers-tesla-418 be removed from proposed and added sync-blacklist?
<tseliot_> ginggs, yes, we have the -server series for that. We should definitely blacklist all the -teslas
-queuebot:#ubuntu-release- New binary: llvm-toolchain-snapshot [s390x] (groovy-proposed/universe) [1:12~++20200715052739+d6e79e3dd6d-1~exp1] (no packageset)
-queuebot:#ubuntu-release- New binary: protobuf [riscv64] (groovy-proposed/main) [3.12.3-2ubuntu1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-drivers-common [source] (focal-proposed) [1:0.8.4~0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (focal-proposed/main) [1:0.8.1.1 => 1:0.8.4~0.20.04.1] (desktop-core, ubuntu-server)
<hellsworth> hey bdmurray could you please take a look at https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1886692
<ubot5> Ubuntu bug 1886692 in libreoffice (Ubuntu) " [SRU] libreoffice 6.4.5 for focal" [High,In progress]
<ginggs> sil2100: would you please remove nvidia-graphics-drivers-tesla-418 as above?  can you do the sync-blacklist too?
<ginggs> maybe as well sync-blacklist nvidia-graphics-drivers-tesla-450 as well, currently in debian NEW
-queuebot:#ubuntu-release- Unapproved: munin (xenial-proposed/universe) [2.0.25-2ubuntu0.16.04.3 => 2.0.25-2ubuntu0.16.04.4] (no packageset)
<sil2100> ginggs: hey! Will try to get to that in a moment ;)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-drivers-common [source] (focal-proposed) [1:0.8.4~0.20.04.1]
<Trevinho> bdmurray: hey, do you have some time to look at the mutter (there's an old version to remove at this point), gnome-shell and libfprint SRUs?
-queuebot:#ubuntu-release- Unapproved: accepted simple-scan [source] (focal-proposed) [3.36.3-0ubuntu0.20.04.0]
<xnox> ghc incoming
-queuebot:#ubuntu-release- Unapproved: accepted im-config [source] (focal-proposed) [0.44-1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted budgie-extras [source] (focal-proposed) [1.0.2-0ubuntu1]
-queuebot:#ubuntu-release- New binary: llvm-toolchain-snapshot [ppc64el] (groovy-proposed/universe) [1:12~++20200715052739+d6e79e3dd6d-1~exp1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted sudo [source] (focal-proposed) [1.8.31-1ubuntu1.1]
-queuebot:#ubuntu-release- New: accepted gxr [amd64] (groovy-proposed) [0.15.1-2]
-queuebot:#ubuntu-release- New: accepted gxr [armhf] (groovy-proposed) [0.15.1-2]
-queuebot:#ubuntu-release- New: accepted gxr [riscv64] (groovy-proposed) [0.15.1-2]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-snapshot [ppc64el] (groovy-proposed) [1:12~++20200715052739+d6e79e3dd6d-1~exp1]
-queuebot:#ubuntu-release- New: accepted gxr [arm64] (groovy-proposed) [0.15.1-2]
-queuebot:#ubuntu-release- New: accepted gxr [s390x] (groovy-proposed) [0.15.1-2]
-queuebot:#ubuntu-release- New: accepted gxr [ppc64el] (groovy-proposed) [0.15.1-2]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-snapshot [s390x] (groovy-proposed) [1:12~++20200715052739+d6e79e3dd6d-1~exp1]
-queuebot:#ubuntu-release- New: accepted infinity [source] (groovy-proposed) [1.5-0ubuntu1]
<Eickmeyer> ubuntu-archive: I'm back from my two week vacation. I must say, I'm disappointed as I have been watching the queue a little in this time. If it's truly a queue, then why haven't the 8 package uploads been reviewed yet?
<sil2100> Eickmeyer: from the NEW queue on groovy you mean?
<Eickmeyer> Correct.
-queuebot:#ubuntu-release- New binary: infinity [amd64] (groovy-proposed/none) [1.5-0ubuntu1] (no packageset)
<Eickmeyer> sil2100: Specifically, the 8 packages uploaded exactly two weeks ago (2020-07-07)
-queuebot:#ubuntu-release- New: accepted infinity [amd64] (groovy-proposed) [1.5-0ubuntu1]
<sil2100> Yeah, due to the point-releases and other, I sadly didn't have the time to do any unrelated NEW reviews, will try to allocate some cycles for that
<Eickmeyer> sil2100: Thanks. Speaking of the point-releases, Ubutnu Studio Focal is still FTBFS and I thought there were going to be some fixes (I think xnox was working on that iirc) to get it to build.
<bdmurray> Trevinho: For which release(s)?
<Trevinho> bdmurray: focal
-queuebot:#ubuntu-release- Unapproved: ubiquity (focal-proposed/main) [20.04.15.1 => 20.04.15.2] (core)
<xnox> Eickmeyer:  Laney prepared a fix, i did review it, but i think it's not uploaded?
<Eickmeyer> xnox: Ok, thanks for the update. Still getting FTBFS emails, so that's what was concerning.
-queuebot:#ubuntu-release- Unapproved: rapid-photo-downloader (focal-proposed/universe) [0.9.22-0ubuntu1 => 0.9.24-0ubuntu0.20.04.1] (ubuntustudio)
<Eickmeyer> bdmurray: ^ That's for bug 1873944, initially rejected by you since I had the bug number wrong in the changelog. Fixed.
<ubot5> bug 1873944 in rapid-photo-downloader (Ubuntu Focal) "[SRU] Upgrade rapid-photo-downloader to version 0.9.24" [High,In progress] https://launchpad.net/bugs/1873944
<Eickmeyer> bdmurray: If you have a cycle free, plz expedite that as it would be good for that to land in 20.04.1.
<bdmurray> Eickmeyer: I have concerns about that upload because it is a version bump and only references one bug and there is no mirorelease exception for rapid-photo-downloader.
<bdmurray> And not autopkgtests
<Eickmeyer> bdmurray: Well, apparently the version in focal is crashing, so there's that.
<bdmurray> Eickmeyer: so just fix the crash
<Eickmeyer> bdmurray: That's what this does, straight from the dev. The dev wrote the SRU.
<bdmurray> Eickmeyer: I mean only that crash and not the dozen other things that are in this upload.
<Eickmeyer> bdmurray: I don't know how to do that. I'm not a coder. I only package things.
<sil2100> ginggs: package removed! (sorry it took a while)
<sil2100> ginggs: also, added it to the sync blacklist
-queuebot:#ubuntu-release- Unapproved: smart-notifier (focal-proposed/universe) [0.28-5build1 => 0.28-6~ubuntu20.04.1] (no packageset)
<bdmurray> sil2100: Is there anything special I should do if I sru-release libsecomp? You mentioned the -security pocket in bug #1861177.
<ubot5> bug 1861177 in libseccomp (Ubuntu Focal) "seccomp_rule_add is very slow" [Medium,Fix committed] https://launchpad.net/bugs/1861177
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (focal-proposed/main) [2.664.2 => 2.664.3] (desktop-core, i386-whitelist)
<Laney> ^- sil2100 one of your changes there, the bug needs SRUing
<Laney> please also could someone review ubiquity, it's needed for .1 and I would like to give the team a chance to test it so I can follow up if it needs it
<bdmurray> Laney: I can do ubiquity
<blackboxsw> cjwatson: or stgraber If either of get a min to moderate ubuntu-release mailing list. I have just sent another email waiting on moderator approval  entitled "SRU Exception Proposal: ubuntu-advantage-tools/ubuntu-advantage-pro package".
<Laney> bdmurray: cheers
<blackboxsw> bdmurray: thanks again for the ua-client fix and your patience there. landed
<cjwatson> blackboxsw: done
<bdmurray> seb128: Did you test keybindings with eog in focal? bug 1886480.
<ubot5> bug 1886480 in eog (Ubuntu Focal) "SRU the current 3.36.3 stable update " [Undecided,Fix committed] https://launchpad.net/bugs/1886480
<seb128> bdmurray, I don't remember if I did at the time I did the verification but I just gave those a round of testing and they work without issue
<bdmurray> seb128: okay, I'll go ahead and release it then.
<seb128> bdmurray, thanks!
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (focal-proposed) [20.04.15.2]
<Laney> ð
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-desktop-icons (focal-proposed/main) [20.04.0-2~ubuntu20.04.1 => 20.04.0-3~ubuntu20.04.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (focal-proposed/main) [2.3 => 2.3ubuntu0.1] (core)
<hellsworth> hey bdmurray could you please take a look at https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1886692
<ubot5> Ubuntu bug 1886692 in libreoffice (Ubuntu) " [SRU] libreoffice 6.4.5 for focal" [High,In progress]
<bdmurray> hellsworth: its on my list for the day
<blackboxsw> thanks cjwatson
 * cjwatson adds Laney to ~ubuntu-archive
<tumbleweed> o_O :)
<tumbleweed> REMOVE ALL THE PACKAGES
<cjwatson> (after some internal discussion)
<seb128> Laney, welcome on board!
<seb128> cjwatson, thanks for doing the actually adding
<cjwatson> hardest thing on my todo list for today (er not really)
<seb128> :-)
<Laney> ah great, thanks cjwatson & seb128
<cjwatson> thank *you*
<Laney> that's been a trivially short journey
<Laney> ahem
<ginggs> sil2100: thank you!
<sil2100> Laney: welcome to the team!
<Eickmeyer> bdmurray: For rapid-photo-downloader, should I apply for an SRU exception?
<Eickmeyer> Laney: If you would like, I can fix ubuntustudio-default-settings as part of that SRU for focal.
<Laney> Eickmeyer: Go for it if you want, it's tidier that way
<Eickmeyer> Laney: ack
 * Laney high fives sil2100 
<Eickmeyer> Laney is an archive admin?? AWESOME! Congrats!
<Laney> ð
<Eickmeyer> Laney: Do you feel that weight? That's the burden on your shoulders. :)
<bdmurray> Eickmeyer: You might want to look at what it takes to get an SRU exception before heading down that route.
<Eickmeyer> bdmurray: Ok, sounds good. Thing is, you've neither rejected the upload nor the SRU, so I'm guessing it's still under consideration?
<bdmurray> Eickmeyer: I'll just reject it, we can save still accept things from that queue if we need to.
<Eickmeyer> bdmurray: Ok. I assume you'll comment on the SRU as to why so the dev knows why? In the meantime, I'll probably just throw it in Ubuntu Studio Backports.
<bdmurray> Eickmeyer: yes, looking at the upstream Changelog again it seems to me like SRU'ing 0.9.23a1 would just fix the segfault and be the quickest path forward to get it fixed in focal-updates.
 * RikMills congratulates Laney
<Eickmeyer> bdmurray: Ok, I'll see if I can do that.
<bdmurray> Eickmeyer: It looks like this rev has that fix only https://bazaar.launchpad.net/~dlynch3/rapid/zeromq_pyqt/revision/1247
-queuebot:#ubuntu-release- Unapproved: python-taskflow (focal-proposed/main) [4.1.0-0ubuntu1 => 4.1.0-0ubuntu1.1] (ubuntu-server)
<Eickmeyer> bdmurray: I'll take a look shortly and see if I can get it going. :)
 * Eickmeyer is catching up after vacation
-queuebot:#ubuntu-release- New binary: rust-automod [amd64] (groovy-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-dlv-list [amd64] (groovy-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pest-derive [amd64] (groovy-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-entities [amd64] (groovy-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-basic-auth [amd64] (groovy-proposed/universe) [2.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unchecked-index [amd64] (groovy-proposed/universe) [0.2.2-1] (no packageset)
<tsimonq2> Laney: Hey, I have a package for you to review. Should be hitting source NEW shortly.
-queuebot:#ubuntu-release- New source: laneys-giraffe (groovy-proposed/primary) [0.1]
-queuebot:#ubuntu-release- New binary: rust-automod [s390x] (groovy-proposed/universe) [0.2.0-1] (no packageset)
<ahasenack> laneys-giraffe?
<tsimonq2> Precisely.
<ahasenack> is that an initiation thing? :)
-queuebot:#ubuntu-release- Unapproved: rejected rapid-photo-downloader [source] (focal-proposed) [0.9.24-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- New binary: rust-dlv-list [s390x] (groovy-proposed/universe) [0.2.2-1] (no packageset)
<tsimonq2> Something like that.
-queuebot:#ubuntu-release- New binary: rust-entities [s390x] (groovy-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pest-derive [s390x] (groovy-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unchecked-index [s390x] (groovy-proposed/universe) [0.2.2-1] (no packageset)
<Eickmeyer> Laney: Since it's a native package, would a quick version bump for ubuntustudio-default-settings for the SRU (20.04.3 => 20.04.4) be acceptable for this?
-queuebot:#ubuntu-release- New binary: rust-automod [arm64] (groovy-proposed/universe) [0.2.0-1] (no packageset)
<bdmurray> Eickmeyer: that version number sounds fine
<Eickmeyer> bdmurray: Thanks. :)
-queuebot:#ubuntu-release- New binary: rust-automod [armhf] (groovy-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-dlv-list [armhf] (groovy-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-dlv-list [arm64] (groovy-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-entities [arm64] (groovy-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-entities [armhf] (groovy-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unchecked-index [arm64] (groovy-proposed/universe) [0.2.2-1] (no packageset)
<bdmurray> hellsworth: Is this new version in groovy yet?
-queuebot:#ubuntu-release- New binary: rust-pest-derive [armhf] (groovy-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ubuntustudio-default-settings (focal-proposed/universe) [20.04.2 => 20.04.4] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: rust-unchecked-index [armhf] (groovy-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pest-derive [arm64] (groovy-proposed/universe) [2.1.0-1] (no packageset)
<Eickmeyer> ubuntu-archive: Please reject ubuntustudio-default-settings 20.04.4, I didn't realize that it includes a different delta that's incompatible without an upload of ubuntustudio-menu.
 * Eickmeyer hangs head in shame
-queuebot:#ubuntu-release- Unapproved: accepted libfprint [source] (focal-proposed) [1:1.90.2+tod1-0ubuntu1~20.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected ubuntustudio-default-settings [source] (focal-proposed) [20.04.4]
<Eickmeyer> bdmurray: Thanks. New upload on that incoming.
-queuebot:#ubuntu-release- Unapproved: ubuntustudio-default-settings (focal-proposed/universe) [20.04.2 => 20.04.2.1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: rust-automod [ppc64el] (groovy-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-entities [ppc64el] (groovy-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unchecked-index [ppc64el] (groovy-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-dlv-list [ppc64el] (groovy-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pest-derive [ppc64el] (groovy-proposed/universe) [2.1.0-1] (no packageset)
<bdmurray> Eickmeyer: how did rapid-photo-downloader end up in the focal queue again?
-queuebot:#ubuntu-release- Unapproved: rejected mutter [source] (focal-proposed) [3.36.3-0ubuntu0.20.04.2]
<Eickmeyer> bdmurray: Uh... just now? I didn't upload except that one earlier today.
<Eickmeyer> bdmurray: Only other one I uploaded was ubuntustudio-default-settings.
<Eickmeyer> I see your reject: [10:30:43 am] [queuebot] Unapproved: rejected rapid-photo-downloader [source] (focal-proposed) [0.9.24-0ubuntu0.20.04.1]
<Eickmeyer> But, I didn't upload after that, bdmurray.
<Eickmeyer> (sorry for the delay on that response, had a minor breaker trip here)
<bdmurray> Eickmeyer: the one I rejected was uploaded 2020-07-01
<Eickmeyer> bdmurray: Weird. I didn't see that upload when I checked earlier today, so I thought I had forgotten to upload it. Feel free to reject again.
<Eickmeyer> bdmurray: And sorry about that. My mistake.
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (focal-proposed) [2.664.3]
<bdmurray> Eickmeyer: No big deal, the timing was just confusing! I think the queue had / has two pages worth of uploads at the moment.
-queuebot:#ubuntu-release- Unapproved: rejected rapid-photo-downloader [source] (focal-proposed) [0.9.24-0ubuntu0.20.04.1]
<vorlon> Laney: Built-Using> ta
<vorlon> LocutusOfBorg: bzip2> wfm though I think such such posix shell tricks are less readable for many people :)
<bdmurray> rbasak, vorlon, sil2100... ubuntu-sru-team meeting?
<vorlon> bdmurray: I'm off today
<bdmurray> vorlon: ah, I see that now - sorry!
<LocutusOfBorg> vorlon, at the end I did something like this:
<LocutusOfBorg> +eval $(dpkg-architecture -s)
<LocutusOfBorg> +PKG_CONFIG=$DEB_HOST_GNU_TYPE-pkg-config
<LocutusOfBorg> +CC=$DEB_HOST_GNU_TYPE-gcc
<LocutusOfBorg> this works nicely and its readable :)
-queuebot:#ubuntu-release- New: rejected laneys-giraffe [source] (groovy-proposed) [0.1]
<rbasak> bdmurray: sorry, with previous poor attendence I stopped holding my evenings for it unless I know it's happening, and I didn't get round to asking in advance this time
<bdmurray> rbasak: That's fair, I feel like I need a reminder to update the agenda the day before.
-queuebot:#ubuntu-release- Unapproved: accepted mutter [source] (focal-proposed) [3.36.4-0ubuntu0.20.04.1]
<kanashiro> ubuntu-archive: sorry for bothering but could you please take a look at LP #1868500 ?
<ubot5> Launchpad bug 1868500 in golang-github-prometheus-client-golang (Ubuntu) "Please remove binaries for 0.9.2-0ubuntu3" [Undecided,New] https://launchpad.net/bugs/1868500
<kyrofa> Hey bdmurray, any chance we could get this into proposed? https://bugs.launchpad.net/ubuntu/+source/orocos-kdl/+bug/1871725
<ubot5> Ubuntu bug 1871725 in orocos-kdl (Ubuntu Focal) "python3-pykdl: PyKDL crashes Python 3 interpretter (SIGABRT) if any API accepting a str is used" [Medium,In progress]
-queuebot:#ubuntu-release- Unapproved: accepted orocos-kdl [source] (focal-proposed) [1.4.0-7ubuntu1]
<kyrofa> Ahh, thank you
-queuebot:#ubuntu-release- Unapproved: accepted evince [source] (focal-proposed) [3.36.7-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected smokeping [source] (focal-proposed) [2.7.3-2ubuntu20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted dpdk [source] (focal-proposed) [19.11.3-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted dpdk [source] (bionic-proposed) [17.11.10-0ubuntu0.1]
<ahasenack> hi, apt can't find recode:i386, but it exists in lp: https://launchpad.net/ubuntu/+source/recode/3.6-24
<ahasenack> maybe something went wrong when groovy was created, since the last build was from focal?
<ahasenack> oh, and let me rephrase, I cannot find recode:i386 for groovy, that is
<ahasenack> and firebird 3.0 i386 is stuck pending this: https://launchpad.net/ubuntu/+source/firebird3.0/3.0.6.33328.ds4-2
<ahasenack> ubuntu-archive ^
-queuebot:#ubuntu-release- New binary: llvm-toolchain-snapshot [amd64] (groovy-proposed/universe) [1:12~++20200715052739+d6e79e3dd6d-1~exp1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-panel [source] (focal-proposed) [1:3.36.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ipxe [source] (focal-proposed) [1.0.0+git-20190109.133f4c4-0ubuntu3.2]
-queuebot:#ubuntu-release- Unapproved: accepted bluebird-gtk-theme [source] (focal-proposed) [1.3-1ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted openscap [source] (focal-proposed) [1.2.16-2ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: accepted nss [source] (focal-proposed) [2:3.49.1-1ubuntu1.3]
-queuebot:#ubuntu-release- Unapproved: accepted nss [source] (bionic-proposed) [2:3.35-2ubuntu2.10]
-queuebot:#ubuntu-release- Unapproved: accepted openscap [source] (bionic-proposed) [1.2.15-1ubuntu0.2]
<mwhudson> ubuntu-archive a while ago src:continuity got mistakenly deleted from proposed (what should have happened is that the binary package of the same name needs to be removed from release)
<mwhudson> ubuntu-archive: can one of you fix this up? I don't think it's somehting I can do
-queuebot:#ubuntu-release- Unapproved: accepted epiphany-browser [source] (focal-proposed) [3.36.3-0ubuntu1]
<RAOF> "mwhudson" (https://matrix.to/#/@freenode_mwhudson:matrix.org): so you just need the binary removed from release, right?
<mwhudson> RAOF: yes, and my attempt to re-sync the package from debian failed
<mwhudson> so i might need help with that bit too
<mwhudson> RAOF: also http://michael.hudsondoyle.geek.nz/raof.png
<RAOF> Hah. I see the IRC bridge needs updating for some formatting changes ð
-queuebot:#ubuntu-release- Unapproved: accepted gnome-boxes [source] (focal-proposed) [3.36.5-0ubuntu1]
<mwhudson> yeah
<RAOF> Why does the continuity binary need to be removed from release?
<mwhudson> because the package in unstable no longer builds that binary
<mwhudson> RAOF: ^
<RAOF> Fair cop.
<bryce> RAOF, heya, don't know if you saw andreas' question earlier about recode:i386; it exists in lp but seems to be lacking a build for groovy.  This is making firebird3.0 stuck, which in turn php7.4 depends on.
<bryce> RAOF, would a no-change rebuild unstick recode?  Or do you have a cleverer solution?
 * RAOF has a look
<mwhudson> most things are not built for i386 on groovy
<mwhudson> why is php?
<bryce> mwhudson, I was wondered that question myself, too :-)
<mwhudson> is launchpad being slow for everyone or just me?
<mwhudson> all requests seem to sit for ~5s before anything happens
<bryce> mwhudson, yeah it seems a touch slower than usual for me today
<mwhudson> vorlon: any idea why php7.4 is getting built for i386?
<mwhudson> "  * No-change rebuild to enable build for i386" back in february
<mwhudson> bah
<mwhudson> RAOF: can you reject pam from focal unapproved?
-queuebot:#ubuntu-release- Unapproved: pam (focal-proposed/main) [1.3.1-5ubuntu4 => 1.3.1-5ubuntu4.1] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: rejected pam [source] (focal-proposed) [1.3.1-5ubuntu4.1]
 * mwhudson tries again
-queuebot:#ubuntu-release- Unapproved: pam (focal-proposed/main) [1.3.1-5ubuntu4 => 1.3.1-5ubuntu4.1] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: pam (bionic-proposed/main) [1.1.8-3.6ubuntu2.18.04.1 => 1.1.8-3.6ubuntu2.18.04.2] (core)
#ubuntu-release 2020-07-22
<RAOF> Hm. The continuity sync fails because of pre-existing binaries, but what binaries?
-queuebot:#ubuntu-release- Unapproved: pam (xenial-proposed/main) [1.1.8-3.2ubuntu2.2 => 1.1.8-3.2ubuntu2.3] (core)
<mwhudson> i guess the golang-github-containerd-continuity-dev binary package has deleted binaries?
<mwhudson> i can't remember how/if you can see the publishing history for a binary
<mwhudson> https://launchpad.net/ubuntu/groovy/amd64/golang-github-containerd-continuity-dev/0.0~git20200107.26c1120-1
<mwhudson> oh are the binaries still published in focal?
<mwhudson> no
<mwhudson> and there are no binaries with that version actually published: http://archive.ubuntu.com/ubuntu/pool/universe/c/continuity/
<RAOF> Yeah, not that I can see.
<mwhudson> maybe needs a wgrant or similar opinion
<RAOF> You could always work around this with a fakesync.
<mwhudson> yeah
<mwhudson> let's do that
<mwhudson> Fakesync not required, aborting.
 * mwhudson does it by hand
<RAOF> bryce: I don't believe a rebuild will unstick recode, as it's not in the i386-whitelist.
<RAOF> Also, I can't quite see why recode would be blocking firebird3.0?
<RAOF> Because AFAICT firebird3.0 doesn't build-depend on recode at all?
<RAOF> ??
<RAOF> Oh, no. Launchpad was just lying about a diff?
<bdmurray> cjwatson: The git link here is incorrect. https://code.launchpad.net/~ubuntu-release/britney/britney2-ubuntu
<bryce> RAOF, possibly I misunderstand https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<bryce> for firebird3.0 it is listing:
<bryce> firebird3.0 unsatisfiable Build-Depends(-Arch) on i386: recode
<RAOF> Yeah. The package in proposed does have that build dependency. But the package in the archive does not, as far as I can tell, nor does the diff on LP from -release to -proposed add that build-dependency.
<RAOF> It was just confusing.
<bryce> weird
-queuebot:#ubuntu-release- Unapproved: carla (focal-proposed/universe) [2.1-0ubuntu1 => 2.2.0~rc1-0ubuntu1~ubuntu20.04.1] (i386-whitelist, ubuntustudio)
<Eickmeyer> ubuntu-archive ^ accidental upload, please reject.
-queuebot:#ubuntu-release- Unapproved: rejected carla [source] (focal-proposed) [2.2.0~rc1-0ubuntu1~ubuntu20.04.1]
<Eickmeyer> RAOF: Thanks!
-queuebot:#ubuntu-release- Unapproved: accepted evolution-data-server [source] (focal-proposed) [3.36.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted evolution [source] (focal-proposed) [3.36.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted evolution-ews [source] (focal-proposed) [3.36.4-0ubuntu1]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-187.217] (core, kernel)
<mwhudson> RAOF: ok so now can you delete the binaries from groovy release? https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#continuity
-queuebot:#ubuntu-release- New binary: rust-automod [riscv64] (groovy-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-entities [riscv64] (groovy-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-dlv-list [riscv64] (groovy-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unchecked-index [riscv64] (groovy-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pest-derive [riscv64] (groovy-proposed/universe) [2.1.0-1] (no packageset)
<RAOF> mwhudson: Enjoy.
-queuebot:#ubuntu-release- New binary: nim-unicodedb [amd64] (groovy-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-bsd-indent [s390x] (groovy-proposed/universe) [2.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-bsd-indent [amd64] (groovy-proposed/universe) [2.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-bsd-indent [ppc64el] (groovy-proposed/universe) [2.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-bsd-indent [arm64] (groovy-proposed/universe) [2.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-bsd-indent [armhf] (groovy-proposed/universe) [2.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-bsd-indent [riscv64] (groovy-proposed/universe) [2.1.1-1] (no packageset)
<LocutusOfBorg> Laney, why is this page still there without a ben file? https://people.canonical.com/~ubuntu-archive/transitions/html/ghc-new.html
<ginggs> tseliot: why were the ppc64el binaries of nvidia-graphics-drivers-*-server dropped?
<tseliot> ginggs, because we don't have the hardware to do any kind of testing on it
<Laney> LocutusOfBorg: Old output gets removed separately: https://bazaar.launchpad.net/~ubuntu-transition-trackers/ubuntu-transition-tracker/configs/view/head:/go#L71
<ginggs> tseliot: ok, thanks
<LocutusOfBorg> thanks Laney ! how often does it run?
<Laney> every minute if the suite has changed and there's no previous run, so every publisher run approximately
<LocutusOfBorg> mmm I don't understand then... the commit is from 22h ago http://bazaar.launchpad.net/~ubuntu-transition-trackers/ubuntu-transition-tracker/configs/revision/828
<LocutusOfBorg> I would have expected it to be deleted by now
<Laney> LocutusOfBorg: It's find ... -mtime +1
<Laney> so adjust your expectations :>
<LocutusOfBorg> lol! thanks :D
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-snapshot [amd64] (groovy-proposed) [1:12~++20200715052739+d6e79e3dd6d-1~exp1]
-queuebot:#ubuntu-release- New: accepted nim-unicodedb [amd64] (groovy-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted pg-bsd-indent [arm64] (groovy-proposed) [2.1.1-1]
-queuebot:#ubuntu-release- New: accepted pg-bsd-indent [ppc64el] (groovy-proposed) [2.1.1-1]
-queuebot:#ubuntu-release- New: accepted pg-bsd-indent [s390x] (groovy-proposed) [2.1.1-1]
-queuebot:#ubuntu-release- New: accepted pg-bsd-indent [amd64] (groovy-proposed) [2.1.1-1]
-queuebot:#ubuntu-release- New: accepted pg-bsd-indent [riscv64] (groovy-proposed) [2.1.1-1]
-queuebot:#ubuntu-release- New: accepted pg-bsd-indent [armhf] (groovy-proposed) [2.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-pest-derive [amd64] (groovy-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-pest-derive [armhf] (groovy-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-pest-derive [riscv64] (groovy-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-pest-derive [arm64] (groovy-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-pest-derive [s390x] (groovy-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-pest-derive [ppc64el] (groovy-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-entities [amd64] (groovy-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-entities [armhf] (groovy-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-entities [riscv64] (groovy-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-unchecked-index [amd64] (groovy-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-unchecked-index [armhf] (groovy-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-unchecked-index [riscv64] (groovy-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-entities [arm64] (groovy-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-entities [s390x] (groovy-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-unchecked-index [ppc64el] (groovy-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-entities [ppc64el] (groovy-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-unchecked-index [s390x] (groovy-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-unchecked-index [arm64] (groovy-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted node-basic-auth [amd64] (groovy-proposed) [2.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-automod [amd64] (groovy-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-automod [armhf] (groovy-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-automod [riscv64] (groovy-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-dlv-list [amd64] (groovy-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-dlv-list [armhf] (groovy-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-dlv-list [riscv64] (groovy-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-automod [arm64] (groovy-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-automod [s390x] (groovy-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-dlv-list [ppc64el] (groovy-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-automod [ppc64el] (groovy-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-dlv-list [s390x] (groovy-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-dlv-list [arm64] (groovy-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New binary: qgis [s390x] (groovy-proposed/universe) [3.10.8+dfsg-1ubuntu1] (no packageset)
<cjwatson> bdmurray: While I registered that branch, I'm no longer in ~ubuntu-release which owns that branch, so I can't edit its description
<Laney> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/focal/ubuntustudio/+build/229383 <- good
-queuebot:#ubuntu-release- Unapproved: zfs-linux (focal-proposed/main) [0.8.3-1ubuntu12.2 => 0.8.3-1ubuntu12.3] (core)
<LocutusOfBorg> hello vorlon , is python2.7 eligible for an i386 permanent hint? https://autopkgtest.ubuntu.com/packages/p/python2.7/groovy/i386
<LocutusOfBorg> looks like python-gdbm is gone in i386
-queuebot:#ubuntu-release- New binary: qgis [ppc64el] (groovy-proposed/universe) [3.10.8+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-187.217]
<LocutusOfBorg> xnox, can I do some haskell rebuilds?
-queuebot:#ubuntu-release- New binary: qgis [amd64] (groovy-proposed/universe) [3.10.8+dfsg-1ubuntu1] (no packageset)
<xnox> LocutusOfBorg:  yes please, from https://people.canonical.com/~ubuntu-archive/transitions/html/ghc.html I untick partial & unknown. And then rebuild things that still have ?! for s390x. I did level3 last time. Level4 is next.
<xnox> LocutusOfBorg:  builds & publication is quite fast, as one only needs to wait for s390x things to build & publish.
<LocutusOfBorg> yep sure, I was wondering if doing them both was a problem
<LocutusOfBorg> I can do level 4 5 6 by today, with some sleep on my bash script
<Laney> Eickmeyer: can you try http://cdimage.ubuntu.com/ubuntustudio/focal/dvd/20200722/ please and then report back in the bug?
-queuebot:#ubuntu-release- New: accepted oem-stella.cmit-charizard-meta [source] (focal-proposed) [20.04~ubuntu1]
-queuebot:#ubuntu-release- New binary: oem-stella.cmit-charizard-meta [amd64] (focal-proposed/universe) [20.04~ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted oem-sutton.bachman-banaing-meta [source] (focal-proposed) [20.04~ubuntu1]
-queuebot:#ubuntu-release- New binary: oem-sutton.bachman-banaing-meta [amd64] (focal-proposed/none) [20.04~ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted oem-sutton.newell-cadby-meta [source] (focal-proposed) [20.04~ubuntu1]
-queuebot:#ubuntu-release- New binary: oem-sutton.newell-cadby-meta [amd64] (focal-proposed/none) [20.04~ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted oem-sutton.newell-cadee-meta [source] (focal-proposed) [20.04~ubuntu1]
-queuebot:#ubuntu-release- New binary: oem-sutton.newell-cadee-meta [amd64] (focal-proposed/none) [20.04~ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted oem-sutton.newell-cade-meta [source] (focal-proposed) [20.04~ubuntu1]
-queuebot:#ubuntu-release- New binary: oem-sutton.newell-cade-meta [amd64] (focal-proposed/none) [20.04~ubuntu1] (no packageset)
<doko> LocutusOfBorg, vorlon: building python-stdlib-extensions now again.  If we keep 2.7 on i386, we should keep both, or drop both python2.7 and python-stdlib-extensions, and python-defaults. not just one of them
-queuebot:#ubuntu-release- New: accepted oem-sutton.newell-cadence-meta [source] (focal-proposed) [20.04~ubuntu1]
-queuebot:#ubuntu-release- New binary: oem-sutton.newell-cadence-meta [amd64] (focal-proposed/none) [20.04~ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Packageset: Added gcc-snapshot to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added python-stdlib-extensions to i386-whitelist in groovy
-queuebot:#ubuntu-release- New: accepted oem-stella.cmit-charizard-meta [amd64] (focal-proposed) [20.04~ubuntu1]
-queuebot:#ubuntu-release- New: accepted oem-sutton.newell-cadby-meta [amd64] (focal-proposed) [20.04~ubuntu1]
-queuebot:#ubuntu-release- New: accepted oem-sutton.newell-cadee-meta [amd64] (focal-proposed) [20.04~ubuntu1]
-queuebot:#ubuntu-release- New: accepted oem-sutton.bachman-banaing-meta [amd64] (focal-proposed) [20.04~ubuntu1]
-queuebot:#ubuntu-release- New: accepted oem-sutton.newell-cadence-meta [amd64] (focal-proposed) [20.04~ubuntu1]
-queuebot:#ubuntu-release- New: accepted oem-sutton.newell-cade-meta [amd64] (focal-proposed) [20.04~ubuntu1]
<vorlon> doko: python2.7 / python-stdlib-extensions / python-defaults if they are present at all on i386 are only there for build-dependency closure for the buildds.  There will be zero end-user installations of these packages for focal+.  We shouldn't manually whitelist more packages here that aren't needed for build-dependencies
<vorlon> LocutusOfBorg: python2.7/i386 should definitely be permanently badtested yes
-queuebot:#ubuntu-release- Packageset: 176 entries have been added or removed
<LocutusOfBorg> thanks!
<LocutusOfBorg> vorlon, maybe you can also do it for libyang? its not built anymore on i386
<vorlon> LocutusOfBorg: done
<vorlon> xnox: so we have a large number of haskell packages that have been rolled back and which we will want to roll forward again; but I think we need to get the libffi transition done first?
<vorlon> are we ready to start that?
<vorlon> mwhudson: php7.4: via libsoup2.4 build-dependency
<vorlon> (per germinate output)
-queuebot:#ubuntu-release- New binary: qgis [armhf] (groovy-proposed/universe) [3.10.8+dfsg-1ubuntu1] (no packageset)
<LocutusOfBorg> vorlon, yes please :)
<LocutusOfBorg> I'm doing the rebuild to unbreak s390x abi changes
<LocutusOfBorg> I'm at level 9, I think I'll finish by tomorrow
<vorlon> LocutusOfBorg: yes please for starting the libffi transition?
<LocutusOfBorg> I'm already rebuilding haskell for the new transition
<LocutusOfBorg> so, better finish this one, do libffi/protobuf/icu whatever and then sync again haskell from debian?
<vorlon> ack
<LocutusOfBorg> the current one is trivial, just s390x changes, and fast architecture, I don't even need to finish building everywhere to start the next level
<LocutusOfBorg> but if you have a different opinion, we can change the track
<vorlon> yeah, it seems you're at level 9 and the ben tracker hasn't even updated once ;)
<doko> vorlon: afaik, not yet. we cannot just bump the soname for an upstream snapshot
<vorlon> doko: not yet what? libffi?
<doko> yes
<vorlon> doko: please sync with xnox then
<mdeslaur> Could someone please unblock mysql-8.0 migration...the two bugs are fixed or there are workarounds in the package in -proposed
<vorlon> doko: he was ready to land this for CET and was only held up because of the existing ongoing transitions
<vorlon> mdeslaur: are you talking about mysql-8.0 in groovy?  It's blocked due to riscv64 ftbfs
<vorlon> (the bugs are not blocking)
<mdeslaur> vorlon: oh, hrm
<mdeslaur> that's not going to be an easy fix... "short type on this platform does not have an always-lock-free property. Bailing out"
<mdeslaur> who's the riscv64 expert?
<vorlon> indeed; but it needs fixing, regressing mysql-8.0 on riscv64 would be a big problem for the port
<vorlon> mdeslaur: probably wgrant :P but should probably go to the server team first as it's their package
<mdeslaur> hrm, ok, thanks
<LocutusOfBorg> vorlon, the new tracker is the old one, and the old one is going to be deleted today
<vorlon> LocutusOfBorg: I don't follow
<LocutusOfBorg> (see this channel log, around 10 am this morning)
<LocutusOfBorg> if you look at this one: https://people.canonical.com/~ubuntu-archive/transitions/html/ghc-new.html
<LocutusOfBorg> its wrong
<LocutusOfBorg> this one is good: https://people.canonical.com/~ubuntu-archive/transitions/html/ghc.html
<vorlon> ok
<vorlon> so why does new ben have a garbage '?!' in various fields instead of a color?
<Laney> it means that it matches the good and bad criteria
<vorlon> ugh
<Laney> :(
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (focal-proposed) [2.3ubuntu0.1]
-queuebot:#ubuntu-release- New binary: qgis [arm64] (groovy-proposed/universe) [3.10.8+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: horizon (focal-proposed/main) [3:18.3.2-0ubuntu0.20.04.1 => 3:18.3.2-0ubuntu0.20.04.2] (openstack, ubuntu-server)
<sil2100> whoops, sorry for the appliance build-log spam!
<sil2100> Made a small mistake
<sil2100> Trying again!
-queuebot:#ubuntu-release- New binary: effcee [amd64] (groovy-proposed/none) [2019.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hachoir [amd64] (groovy-proposed/universe) [3.1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyct [amd64] (groovy-proposed/universe) [0.4.7a3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-multistate [amd64] (groovy-proposed/universe) [0.8.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-discogs-client [amd64] (groovy-proposed/universe) [2.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libdrpm [amd64] (groovy-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmodulemd [amd64] (groovy-proposed/universe) [2.9.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libdrpm [s390x] (groovy-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: freehep-vectorgraphics [amd64] (groovy-proposed/universe) [2.4+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libmodulemd [s390x] (groovy-proposed/universe) [2.9.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-multistate [s390x] (groovy-proposed/universe) [0.8.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kiwix [amd64] (groovy-proposed/universe) [2.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vedo [amd64] (groovy-proposed/universe) [2020.3.3+dfsg3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: effcee [ppc64el] (groovy-proposed/universe) [2019.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-multistate [ppc64el] (groovy-proposed/universe) [0.8.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libdrpm [ppc64el] (groovy-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmodulemd [ppc64el] (groovy-proposed/universe) [2.9.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: massxpert [s390x] (groovy-proposed/universe) [6.0.0-1] (no packageset)
<Eickmeyer> Laney: I'll give it a shot.
-queuebot:#ubuntu-release- New binary: massxpert [amd64] (groovy-proposed/universe) [6.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: massxpert [ppc64el] (groovy-proposed/universe) [6.0.0-1] (no packageset)
<Eickmeyer> Laney: ack
-queuebot:#ubuntu-release- New binary: libdrpm [arm64] (groovy-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libdrpm [armhf] (groovy-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmodulemd [arm64] (groovy-proposed/universe) [2.9.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmodulemd [armhf] (groovy-proposed/universe) [2.9.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kiwix [arm64] (groovy-proposed/universe) [2.0.4-1] (no packageset)
<kanashiro> sil2100: do you have time today to take another look at LP #1868500 ?
<ubot5> Launchpad bug 1868500 in golang-github-prometheus-client-golang (Ubuntu) "Please remove binaries for 0.9.2-0ubuntu3" [Undecided,New] https://launchpad.net/bugs/1868500
-queuebot:#ubuntu-release- New binary: haskell-multistate [arm64] (groovy-proposed/universe) [0.8.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kiwix [armhf] (groovy-proposed/universe) [2.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-multistate [armhf] (groovy-proposed/universe) [0.8.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: massxpert [armhf] (groovy-proposed/universe) [6.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: massxpert [arm64] (groovy-proposed/universe) [6.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-multistate [arm64] (groovy-proposed) [0.8.0.2-1]
-queuebot:#ubuntu-release- New: accepted kiwix [arm64] (groovy-proposed) [2.0.4-1]
-queuebot:#ubuntu-release- New: accepted libmodulemd [arm64] (groovy-proposed) [2.9.4-1]
-queuebot:#ubuntu-release- New: accepted massxpert [arm64] (groovy-proposed) [6.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-multistate [armhf] (groovy-proposed) [0.8.0.2-1]
-queuebot:#ubuntu-release- New: accepted libmodulemd [armhf] (groovy-proposed) [2.9.4-1]
-queuebot:#ubuntu-release- New: accepted kiwix [armhf] (groovy-proposed) [2.0.4-1]
-queuebot:#ubuntu-release- New: accepted massxpert [armhf] (groovy-proposed) [6.0.0-1]
-queuebot:#ubuntu-release- New: accepted effcee [ppc64el] (groovy-proposed) [2019.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-multistate [s390x] (groovy-proposed) [0.8.0.2-1]
-queuebot:#ubuntu-release- New: accepted libdrpm [armhf] (groovy-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted libmodulemd [ppc64el] (groovy-proposed) [2.9.4-1]
-queuebot:#ubuntu-release- New: accepted massxpert [ppc64el] (groovy-proposed) [6.0.0-1]
-queuebot:#ubuntu-release- New: accepted vedo [amd64] (groovy-proposed) [2020.3.3+dfsg3-1]
-queuebot:#ubuntu-release- New: accepted haskell-multistate [ppc64el] (groovy-proposed) [0.8.0.2-1]
-queuebot:#ubuntu-release- New: accepted libdrpm [ppc64el] (groovy-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted massxpert [s390x] (groovy-proposed) [6.0.0-1]
-queuebot:#ubuntu-release- New: accepted libdrpm [arm64] (groovy-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted massxpert [amd64] (groovy-proposed) [6.0.0-1]
-queuebot:#ubuntu-release- New: accepted freehep-vectorgraphics [amd64] (groovy-proposed) [2.4+dfsg-3]
-queuebot:#ubuntu-release- New: accepted haskell-multistate [amd64] (groovy-proposed) [0.8.0.2-1]
-queuebot:#ubuntu-release- New: accepted libdrpm [amd64] (groovy-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted libmodulemd [amd64] (groovy-proposed) [2.9.4-1]
-queuebot:#ubuntu-release- New: accepted pyct [amd64] (groovy-proposed) [0.4.7a3-1]
-queuebot:#ubuntu-release- New: accepted hachoir [amd64] (groovy-proposed) [3.1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted libdrpm [s390x] (groovy-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted python-discogs-client [amd64] (groovy-proposed) [2.3.1-1]
-queuebot:#ubuntu-release- New: accepted kiwix [amd64] (groovy-proposed) [2.0.4-1]
-queuebot:#ubuntu-release- New: accepted libmodulemd [s390x] (groovy-proposed) [2.9.4-1]
-queuebot:#ubuntu-release- New: accepted effcee [amd64] (groovy-proposed) [2019.1-1]
-queuebot:#ubuntu-release- New: accepted protobuf [ppc64el] (groovy-proposed) [3.12.3-2]
-queuebot:#ubuntu-release- New: accepted protobuf [amd64] (groovy-proposed) [3.12.3-2]
-queuebot:#ubuntu-release- New: accepted protobuf [s390x] (groovy-proposed) [3.12.3-2]
-queuebot:#ubuntu-release- Unapproved: rasdaemon (focal-proposed/universe) [0.6.5-1ubuntu1 => 0.6.5-1ubuntu1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: crazydiskinfo [ppc64el] (groovy-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libfduserdata [amd64] (groovy-proposed/universe) [0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-xlzd-gotp [amd64] (groovy-proposed/universe) [0.0~git20181030.c8557ba-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nlinline [amd64] (groovy-proposed/universe) [0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: crazydiskinfo [s390x] (groovy-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-mozillazg-go-pinyin [ppc64el] (groovy-proposed/universe) [0.18.0+ds.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: procdump [amd64] (groovy-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-rubocop-ast [amd64] (groovy-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: discodos [amd64] (groovy-proposed/universe) [1.0~rc2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-webdavclient [amd64] (groovy-proposed/universe) [3.14.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libstropt [amd64] (groovy-proposed/universe) [0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: strcase [amd64] (groovy-proposed/universe) [0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-mozillazg-go-pinyin [s390x] (groovy-proposed/universe) [0.18.0+ds.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libfduserdata [s390x] (groovy-proposed/universe) [0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libstropt [s390x] (groovy-proposed/universe) [0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: plpgsql-check [amd64] (groovy-proposed/universe) [1.11.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libfduserdata [ppc64el] (groovy-proposed/universe) [0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libvolatilestream [ppc64el] (groovy-proposed/universe) [0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libstropt [ppc64el] (groovy-proposed/universe) [0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: crazydiskinfo [amd64] (groovy-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gtherm [s390x] (groovy-proposed/universe) [0.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sup-mail [amd64] (groovy-proposed/universe) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: crazydiskinfo [arm64] (groovy-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: userbindmount [amd64] (groovy-proposed/universe) [0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hypothesis-auto [amd64] (groovy-proposed/universe) [1.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gtherm [ppc64el] (groovy-proposed/universe) [0.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libfduserdata [armhf] (groovy-proposed/universe) [0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libvolatilestream [arm64] (groovy-proposed/universe) [0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-optional-args [amd64] (groovy-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: procdump [arm64] (groovy-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libstropt [arm64] (groovy-proposed/universe) [0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: crazydiskinfo [armhf] (groovy-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-mozillazg-go-pinyin [arm64] (groovy-proposed/universe) [0.18.0+ds.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gtherm [amd64] (groovy-proposed/universe) [0.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-selective [amd64] (groovy-proposed/universe) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libvolatilestream [amd64] (groovy-proposed/universe) [0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: plpgsql-check [arm64] (groovy-proposed/universe) [1.11.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-mozillazg-go-pinyin [amd64] (groovy-proposed/universe) [0.18.0+ds.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-managed [amd64] (groovy-proposed/universe) [1.0.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libvolatilestream [s390x] (groovy-proposed/universe) [0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-mozillazg-go-pinyin [armhf] (groovy-proposed/universe) [0.18.0+ds.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libstropt [armhf] (groovy-proposed/universe) [0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gtherm [arm64] (groovy-proposed/universe) [0.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-selective [ppc64el] (groovy-proposed/universe) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libvolatilestream [armhf] (groovy-proposed/universe) [0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: plpgsql-check [ppc64el] (groovy-proposed/universe) [1.11.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: procdump [armhf] (groovy-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: procdump [s390x] (groovy-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: userbindmount [s390x] (groovy-proposed/universe) [0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gtherm [armhf] (groovy-proposed/universe) [0.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: plpgsql-check [armhf] (groovy-proposed/universe) [1.11.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: procdump [ppc64el] (groovy-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-selective [s390x] (groovy-proposed/universe) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: userbindmount [ppc64el] (groovy-proposed/universe) [0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: plpgsql-check [s390x] (groovy-proposed/universe) [1.11.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-managed [s390x] (groovy-proposed/universe) [1.0.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libfduserdata [arm64] (groovy-proposed/universe) [0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-optional-args [s390x] (groovy-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-managed [ppc64el] (groovy-proposed/universe) [1.0.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: userbindmount [arm64] (groovy-proposed/universe) [0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-optional-args [ppc64el] (groovy-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: userbindmount [armhf] (groovy-proposed/universe) [0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-managed [arm64] (groovy-proposed/universe) [1.0.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-tesla-450 [amd64] (groovy-proposed/multiverse) [450.51.05-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-selective [arm64] (groovy-proposed/universe) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-tesla-450 [ppc64el] (groovy-proposed/multiverse) [450.51.05-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-managed [armhf] (groovy-proposed/universe) [1.0.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-optional-args [armhf] (groovy-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-optional-args [arm64] (groovy-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-selective [armhf] (groovy-proposed/universe) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-tesla-450 [arm64] (groovy-proposed/multiverse) [450.51.05-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted discodos [amd64] (groovy-proposed) [1.0~rc2-1]
-queuebot:#ubuntu-release- New: accepted hypothesis-auto [amd64] (groovy-proposed) [1.1.4-1]
-queuebot:#ubuntu-release- New: accepted python-webdavclient [amd64] (groovy-proposed) [3.14.5-1]
-queuebot:#ubuntu-release- New: accepted strcase [amd64] (groovy-proposed) [0.1-2]
-queuebot:#ubuntu-release- New binary: protobuf [armhf] (groovy-proposed/main) [3.12.3-2ubuntu1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: qgis [s390x] (groovy-proposed/universe) [3.10.8+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-github-xlzd-gotp [amd64] (groovy-proposed) [0.0~git20181030.c8557ba-1]
-queuebot:#ubuntu-release- New: accepted ruby-rubocop-ast [amd64] (groovy-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New binary: protobuf [riscv64] (groovy-proposed/main) [3.12.3-2ubuntu1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New: accepted nlinline [amd64] (groovy-proposed) [0.1-2]
-queuebot:#ubuntu-release- New binary: protobuf [arm64] (groovy-proposed/main) [3.12.3-2ubuntu1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New: accepted sup-mail [amd64] (groovy-proposed) [1.0-2]
-queuebot:#ubuntu-release- New source: intervals (groovy-proposed/primary) [0.9.0-0ubuntu1]
#ubuntu-release 2020-07-23
-queuebot:#ubuntu-release- Unapproved: apache2 (xenial-proposed/main) [2.4.18-2ubuntu3.15 => 2.4.18-2ubuntu3.16] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: crazydiskinfo [riscv64] (groovy-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libstropt [riscv64] (groovy-proposed/universe) [0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libfduserdata [riscv64] (groovy-proposed/universe) [0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libvolatilestream [riscv64] (groovy-proposed/universe) [0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: procdump [riscv64] (groovy-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: userbindmount [riscv64] (groovy-proposed/universe) [0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-mozillazg-go-pinyin [riscv64] (groovy-proposed/universe) [0.18.0+ds.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: plpgsql-check [riscv64] (groovy-proposed/universe) [1.11.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gtherm [riscv64] (groovy-proposed/universe) [0.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-managed [riscv64] (groovy-proposed/universe) [1.0.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-optional-args [riscv64] (groovy-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-tatsushid-go-prettytable [amd64] (groovy-proposed/universe) [0.0~git20141013.ed2d14c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ox-texinfo-plus [amd64] (groovy-proposed/universe) [2.2.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: alertmanager-irc-relay [ppc64el] (groovy-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: alertmanager-irc-relay [s390x] (groovy-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: alertmanager-irc-relay [amd64] (groovy-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-dslabs [amd64] (groovy-proposed/universe) [0.7.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: alertmanager-irc-relay [armhf] (groovy-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pique [amd64] (groovy-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: alertmanager-irc-relay [arm64] (groovy-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: openvswitch (bionic-proposed/main) [2.9.5-0ubuntu0.18.04.1 => 2.9.6-0ubuntu0.18.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: intelrdfpmath [amd64] (groovy-proposed/universe) [2.0u2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: alertmanager-irc-relay [riscv64] (groovy-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-ghc-lib-parser [amd64] (groovy-proposed/universe) [8.8.3.20200412.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-ghc-lib-parser [ppc64el] (groovy-proposed/universe) [8.8.3.20200412.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-text-manipulate [amd64] (groovy-proposed/universe) [0.2.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-text-manipulate [ppc64el] (groovy-proposed/universe) [0.2.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-text-manipulate [s390x] (groovy-proposed/universe) [0.2.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-text-manipulate [arm64] (groovy-proposed/universe) [0.2.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-text-manipulate [armhf] (groovy-proposed/universe) [0.2.0.1-2] (no packageset)
<slyon> Hey all! Is it OK to drop an armhf binary package (badger) from groovy-release? Upstream is not really supporting 32bit architectures and the armhf build fails (during dh_auto_test), holding back the migration of badger 2.0.3-1. Or would it be better to ship a (possibly broken) armhf binary, which might or might not get fixed in a future release?
-queuebot:#ubuntu-release- New binary: haskell-text-manipulate [riscv64] (groovy-proposed/universe) [0.2.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-selective [riscv64] (groovy-proposed/universe) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ox-texinfo-plus [amd64] (groovy-proposed) [2.2.4-1]
-queuebot:#ubuntu-release- New: accepted r-cran-dslabs [amd64] (groovy-proposed) [0.7.3-1]
-queuebot:#ubuntu-release- New: accepted gtherm [amd64] (groovy-proposed) [0.0.2-1]
-queuebot:#ubuntu-release- New: accepted gtherm [armhf] (groovy-proposed) [0.0.2-1]
-queuebot:#ubuntu-release- New: accepted gtherm [riscv64] (groovy-proposed) [0.0.2-1]
-queuebot:#ubuntu-release- New: accepted pique [amd64] (groovy-proposed) [1.0-1]
-queuebot:#ubuntu-release- New binary: userbindmount [amd64] (groovy-proposed/universe) [0.1-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted gtherm [arm64] (groovy-proposed) [0.0.2-1]
-queuebot:#ubuntu-release- New: accepted gtherm [s390x] (groovy-proposed) [0.0.2-1]
-queuebot:#ubuntu-release- New: accepted gtherm [ppc64el] (groovy-proposed) [0.0.2-1]
-queuebot:#ubuntu-release- New: accepted procdump [amd64] (groovy-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted intelrdfpmath [amd64] (groovy-proposed) [2.0u2-1]
-queuebot:#ubuntu-release- New: accepted procdump [armhf] (groovy-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted procdump [riscv64] (groovy-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New binary: golang-github-mozillazg-go-pinyin [s390x] (groovy-proposed/universe) [0.18.0+ds.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libstropt [amd64] (groovy-proposed/universe) [0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: plpgsql-check [amd64] (groovy-proposed/universe) [1.11.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted procdump [arm64] (groovy-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted procdump [s390x] (groovy-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New binary: libstropt [ppc64el] (groovy-proposed/universe) [0.1-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted procdump [ppc64el] (groovy-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New binary: libfduserdata [ppc64el] (groovy-proposed/universe) [0.1-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted crazydiskinfo [amd64] (groovy-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted crazydiskinfo [armhf] (groovy-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted crazydiskinfo [riscv64] (groovy-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted crazydiskinfo [arm64] (groovy-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted crazydiskinfo [s390x] (groovy-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted crazydiskinfo [ppc64el] (groovy-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted alertmanager-irc-relay [amd64] (groovy-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted alertmanager-irc-relay [armhf] (groovy-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted alertmanager-irc-relay [riscv64] (groovy-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-tesla-450 [amd64] (groovy-proposed) [450.51.05-1]
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-tesla-450 [ppc64el] (groovy-proposed) [450.51.05-1]
-queuebot:#ubuntu-release- New binary: protobuf [arm64] (groovy-proposed/main) [3.12.3-2ubuntu1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: protobuf [riscv64] (groovy-proposed/main) [3.12.3-2ubuntu1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: qgis [s390x] (groovy-proposed/universe) [3.10.8+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted alertmanager-irc-relay [arm64] (groovy-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted alertmanager-irc-relay [s390x] (groovy-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New binary: protobuf [amd64] (groovy-proposed/main) [3.12.3-2ubuntu1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: qgis [ppc64el] (groovy-proposed/universe) [3.10.8+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted alertmanager-irc-relay [ppc64el] (groovy-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New binary: protobuf [armhf] (groovy-proposed/main) [3.12.3-2ubuntu1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-tesla-450 [arm64] (groovy-proposed) [450.51.05-1]
-queuebot:#ubuntu-release- New: accepted userbindmount [amd64] (groovy-proposed) [0.1-2]
-queuebot:#ubuntu-release- New: accepted userbindmount [armhf] (groovy-proposed) [0.1-2]
-queuebot:#ubuntu-release- New: accepted userbindmount [riscv64] (groovy-proposed) [0.1-2]
-queuebot:#ubuntu-release- New: accepted userbindmount [arm64] (groovy-proposed) [0.1-2]
-queuebot:#ubuntu-release- New: accepted userbindmount [s390x] (groovy-proposed) [0.1-2]
-queuebot:#ubuntu-release- New: accepted userbindmount [ppc64el] (groovy-proposed) [0.1-2]
-queuebot:#ubuntu-release- New: accepted libstropt [amd64] (groovy-proposed) [0.1-2]
-queuebot:#ubuntu-release- New: accepted libstropt [armhf] (groovy-proposed) [0.1-2]
-queuebot:#ubuntu-release- New: accepted libstropt [riscv64] (groovy-proposed) [0.1-2]
-queuebot:#ubuntu-release- New: accepted plpgsql-check [amd64] (groovy-proposed) [1.11.3-1]
-queuebot:#ubuntu-release- New: accepted plpgsql-check [armhf] (groovy-proposed) [1.11.3-1]
-queuebot:#ubuntu-release- New: accepted plpgsql-check [riscv64] (groovy-proposed) [1.11.3-1]
-queuebot:#ubuntu-release- New source: bchoppr (groovy-proposed/primary) [1.6.2-0ubuntu1]
-queuebot:#ubuntu-release- New source: bshapr (groovy-proposed/primary) [0.9-0ubuntu1]
-queuebot:#ubuntu-release- New source: dragonfly-reverb (groovy-proposed/primary) [3.2.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libstropt [arm64] (groovy-proposed) [0.1-2]
-queuebot:#ubuntu-release- New: accepted libstropt [s390x] (groovy-proposed) [0.1-2]
-queuebot:#ubuntu-release- New: accepted plpgsql-check [ppc64el] (groovy-proposed) [1.11.3-1]
-queuebot:#ubuntu-release- New source: bsequencer (groovy-proposed/primary) [1.4.2-0ubuntu1]
-queuebot:#ubuntu-release- New source: new-session-manager (groovy-proposed/primary) [1.3.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libstropt [ppc64el] (groovy-proposed) [0.1-2]
-queuebot:#ubuntu-release- New: accepted plpgsql-check [s390x] (groovy-proposed) [1.11.3-1]
-queuebot:#ubuntu-release- New: accepted plpgsql-check [arm64] (groovy-proposed) [1.11.3-1]
-queuebot:#ubuntu-release- New source: bslizr (groovy-proposed/primary) [1.2.6-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-github-mozillazg-go-pinyin [amd64] (groovy-proposed) [0.18.0+ds.1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-mozillazg-go-pinyin [armhf] (groovy-proposed) [0.18.0+ds.1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-mozillazg-go-pinyin [riscv64] (groovy-proposed) [0.18.0+ds.1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-tatsushid-go-prettytable [amd64] (groovy-proposed) [0.0~git20141013.ed2d14c-1]
-queuebot:#ubuntu-release- New: accepted golang-github-mozillazg-go-pinyin [arm64] (groovy-proposed) [0.18.0+ds.1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-mozillazg-go-pinyin [s390x] (groovy-proposed) [0.18.0+ds.1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-mozillazg-go-pinyin [ppc64el] (groovy-proposed) [0.18.0+ds.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-optional-args [amd64] (groovy-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-optional-args [armhf] (groovy-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-optional-args [riscv64] (groovy-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-selective [amd64] (groovy-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-selective [armhf] (groovy-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-selective [riscv64] (groovy-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-text-manipulate [amd64] (groovy-proposed) [0.2.0.1-2]
-queuebot:#ubuntu-release- New: accepted haskell-text-manipulate [armhf] (groovy-proposed) [0.2.0.1-2]
-queuebot:#ubuntu-release- New: accepted haskell-text-manipulate [riscv64] (groovy-proposed) [0.2.0.1-2]
-queuebot:#ubuntu-release- New: accepted haskell-optional-args [arm64] (groovy-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-optional-args [s390x] (groovy-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-selective [ppc64el] (groovy-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-text-manipulate [arm64] (groovy-proposed) [0.2.0.1-2]
-queuebot:#ubuntu-release- New: accepted haskell-text-manipulate [s390x] (groovy-proposed) [0.2.0.1-2]
-queuebot:#ubuntu-release- New: accepted haskell-optional-args [ppc64el] (groovy-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-selective [s390x] (groovy-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-selective [arm64] (groovy-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-text-manipulate [ppc64el] (groovy-proposed) [0.2.0.1-2]
-queuebot:#ubuntu-release- New: accepted haskell-managed [amd64] (groovy-proposed) [1.0.7-1]
-queuebot:#ubuntu-release- New: accepted haskell-managed [armhf] (groovy-proposed) [1.0.7-1]
-queuebot:#ubuntu-release- New: accepted haskell-managed [riscv64] (groovy-proposed) [1.0.7-1]
-queuebot:#ubuntu-release- New: accepted haskell-managed [arm64] (groovy-proposed) [1.0.7-1]
-queuebot:#ubuntu-release- New: accepted haskell-managed [s390x] (groovy-proposed) [1.0.7-1]
-queuebot:#ubuntu-release- New: accepted haskell-managed [ppc64el] (groovy-proposed) [1.0.7-1]
-queuebot:#ubuntu-release- New: accepted libfduserdata [amd64] (groovy-proposed) [0.1-2]
-queuebot:#ubuntu-release- New: accepted libfduserdata [armhf] (groovy-proposed) [0.1-2]
-queuebot:#ubuntu-release- New: accepted libfduserdata [riscv64] (groovy-proposed) [0.1-2]
-queuebot:#ubuntu-release- New: accepted libvolatilestream [amd64] (groovy-proposed) [0.1-2]
-queuebot:#ubuntu-release- New: accepted libvolatilestream [armhf] (groovy-proposed) [0.1-2]
-queuebot:#ubuntu-release- New: accepted libvolatilestream [riscv64] (groovy-proposed) [0.1-2]
-queuebot:#ubuntu-release- New: accepted libfduserdata [arm64] (groovy-proposed) [0.1-2]
-queuebot:#ubuntu-release- New: accepted libfduserdata [s390x] (groovy-proposed) [0.1-2]
-queuebot:#ubuntu-release- New: accepted libvolatilestream [ppc64el] (groovy-proposed) [0.1-2]
-queuebot:#ubuntu-release- New: accepted libfduserdata [ppc64el] (groovy-proposed) [0.1-2]
-queuebot:#ubuntu-release- New: accepted libvolatilestream [s390x] (groovy-proposed) [0.1-2]
-queuebot:#ubuntu-release- New: accepted libvolatilestream [arm64] (groovy-proposed) [0.1-2]
<Laney> slyon: Should be OK to remove that, it has no rdeps, same as debian bug #953370
<ubot5> Debian bug 953370 in ftp.debian.org "RM: badger [armel armhf i386] -- ROM; 32bit archs not supported" [Normal,Open] http://bugs.debian.org/953370
<slyon> Thanks Laney, I will prepare a corresponding LP bug.
<Laney> slyon: ok, let me know the number when it's ready and I can do the removal
<Laney> omg, my first ubuntu-archive action
<seb128> :-)
<Laney> heh whoops, sorry for the highlights
<slyon> Here you go, Laney: https://bugs.launchpad.net/ubuntu/+source/badger/+bug/1884753 â will the other successful (64bit) builds auto-migrate after armhf is removed, or do we need to trigger those autopkgtests again?
<ubot5> Ubuntu bug 1884753 in badger (Ubuntu) "Please remove badger/armhf binaries" [Undecided,New]
<Laney> slyon: done, I think it should wake up and migrate now, but wait and see what britney says
<slyon> Laney: great, thank you very much!
-queuebot:#ubuntu-release- New binary: org-roam [amd64] (groovy-proposed/universe) [1.2.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntustudio-default-settings [source] (focal-proposed) [20.04.2.1]
-queuebot:#ubuntu-release- Unapproved: accepted pam [source] (focal-proposed) [1.3.1-5ubuntu4.1]
<sil2100> ddstreet: hey! Looking at systemd in focal, strangely it seems that the umockdev/armhf test seems to keep failing against the latest systemd, but succeeds with the old version (the updates pocket)
<sil2100> ddstreet: could you take a look at that and assess what's going on? I wonder why it's regressing?
<sil2100> Or is it just bad luck?
<slyon> Hey core-devs! Could somebody please trigger this test for me: https://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=ppc64el&package=rsync&trigger=libzstd%2F1.4.5%2Bdfsg-3 (to unlock the libzstd migration) â The rsync autoconf problem is already resolved as of rsync 3.2+ (we have 3.2.1-1ubuntu2 now). I verified the test runs successfully on groovy/ppc64el via Canonistack LXD.
<mitya57> slyon: done
<slyon> Thanks mitya57! Could you also please re-trigger this test for amd64, arm64, ppc64el and s390x? https://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=amd64&package=badger&trigger=libzstd%2F1.4.5%2Bdfsg-3 â It is part of the same libzstd migration and now that badger 2.0.3-1 hit the archive this tests will pass.
<mitya57> slyon: done too
<slyon> mitya57: awesome, thank you!
-queuebot:#ubuntu-release- Unapproved: iproute2 (bionic-proposed/main) [4.18.0-1ubuntu2~ubuntu18.04.1 => 4.15.0-2ubuntu1.2] (core)
<ddstreet> sil2100 i'll take a look but i'm pretty sure the umockdev tests are just *super* flaky - they depend on timing, which causes problems on loaded test systems. i'll see if i can improve the umockdev autopkgtests to not be so timing sensitive
-queuebot:#ubuntu-release- New source: google-osconfig-agent (groovy-proposed/primary) [20200625.00-0ubuntu1]
<ddstreet> Laney it looks like all the armhf testbeds are 4-cpu? i guess they all run in lxd container on a 'large' arm64 virtual instance?
<ddstreet> interestingly it causes umockdev build tests to run as 'make -j1 check' on all archs except armhf, where it runs as 'make -j4 check'
-queuebot:#ubuntu-release- New binary: gce-compute-image-packages [amd64] (groovy-proposed/main) [20200626.00-0ubuntu1] (core, ubuntu-cloud)
<Laney> ddstreet: correct
<Laney> pretty sure pitti would be amenable to people making the tests more reliable :>
<sil2100> ddstreet: hey! If those are indeed super flaky, I guess we can just skip that then
<sil2100> ddstreet: hah!
<sil2100> ddstreet: yes, I see the latest test run succeeded
<ddstreet> sil2100 i have had lp #1831467 open for the flaky tests for a while
<ubot5> Launchpad bug 1831467 in umockdev (Ubuntu) "test-umockdev tests flaky on armhf" [Undecided,New] https://launchpad.net/bugs/1831467
<sil2100> ddstreet: proceeding in that case!
<ddstreet> i'll try to look closer at it to improve flakiness for future runs
<ddstreet> thanks!
-queuebot:#ubuntu-release- New source: google-compute-engine-oslogin (groovy-proposed/primary) [20200507.00-0ubuntu1]
-queuebot:#ubuntu-release- New source: google-guest-agent (groovy-proposed/primary) [20200617.00-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rpi-eeprom (focal-proposed/multiverse) [7.8-0ubuntu0.20.04.1 => 7.8-0ubuntu0.20.04.2] (no packageset)
<kanashiro> ubuntu-archive: can I remind you again of LP #1868500 ? It is blocking some prometheus related packages
<ubot5> Launchpad bug 1868500 in golang-github-prometheus-client-golang (Ubuntu) "Please remove binaries for 0.9.2-0ubuntu3" [Undecided,New] https://launchpad.net/bugs/1868500
<rbalint> ubuntu-archive, could you please accept NEW uploads to groovy matching gce-* google-* and golang-* ?
-queuebot:#ubuntu-release- New: accepted haskell-ghc-lib-parser [amd64] (groovy-proposed) [8.8.3.20200412.1-1]
-queuebot:#ubuntu-release- New: accepted org-roam [amd64] (groovy-proposed) [1.2.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted haskell-ghc-lib-parser [ppc64el] (groovy-proposed) [8.8.3.20200412.1-1]
<vorlon> xnox: fwiw for some reason the round of NBS removals I did for kernel binaries yesterday didn't take; doing it again
<vorlon> and why are there so many packages in the ghc transition tracker marked as uninstallable on !amd64 right now
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Focal 20.04.1] (20200723) has been added
-queuebot:#ubuntu-release- New binary: haskell-ghc-lib-parser-ex [amd64] (groovy-proposed/universe) [8.8.5.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-ghc-lib-parser-ex [ppc64el] (groovy-proposed/universe) [8.8.5.8-1] (no packageset)
<LocutusOfBorg> vorlon, something has been syncd in the meanwhile from debian I guess
<vorlon> LocutusOfBorg: but why would it only affect !amd64?
<LocutusOfBorg> vorlon, I see amd64 sadness here https://people.canonical.com/~ubuntu-archive/transitions/html/ghc.html
<LocutusOfBorg> vorlon, for some publisher runs, amd64 has been faster in building today, so maybe you are just looking at an incomplete report
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Focal 20.04.1] (20200723) has been added
<xnox> vorlon:  a library in level 11 has changed ABI on all arches.
<xnox> vorlon:  hence the "just big-endian ghc rebuild" becomes a full-on "asn1 abi transition" from level 11 down.
 * xnox ponders up?!
<xnox> vorlon:  i think there are multiple versions of kernels that need NBS, because multiple version got accepted but never migrated, and are now superseeded. or something like that.
-queuebot:#ubuntu-release- New binary: charliecloud [s390x] (groovy-proposed/universe) [0.16-1] (no packageset)
-queuebot:#ubuntu-release- New binary: charliecloud [amd64] (groovy-proposed/universe) [0.16-1] (no packageset)
-queuebot:#ubuntu-release- New binary: charliecloud [ppc64el] (groovy-proposed/universe) [0.16-1] (no packageset)
-queuebot:#ubuntu-release- New binary: eclipse-platform-ui [amd64] (groovy-proposed/universe) [4.16-2] (no packageset)
-queuebot:#ubuntu-release- New binary: equinox-p2 [amd64] (groovy-proposed/universe) [4.15-2] (no packageset)
-queuebot:#ubuntu-release- New binary: purple-mm-sms [amd64] (groovy-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-xstatic-lodash [amd64] (groovy-proposed/universe) [4.16.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-adsf [amd64] (groovy-proposed/universe) [1.4.3+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: purple-xmpp-http-upload [amd64] (groovy-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-argparse [amd64] (groovy-proposed/universe) [2.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-xstatic-moment [amd64] (groovy-proposed/universe) [2.8.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gsoap [s390x] (groovy-proposed/universe) [2.8.104-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libflame [amd64] (groovy-proposed/universe) [5.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: purple-xmpp-http-upload [s390x] (groovy-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: purple-mm-sms [s390x] (groovy-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-markovchain [amd64] (groovy-proposed/universe) [0.8.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: charliecloud [armhf] (groovy-proposed/universe) [0.16-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-markovchain [s390x] (groovy-proposed/universe) [0.8.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: charliecloud [arm64] (groovy-proposed/universe) [0.16-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libflame [s390x] (groovy-proposed/universe) [5.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gsoap [amd64] (groovy-proposed/universe) [2.8.104-1] (no packageset)
-queuebot:#ubuntu-release- New binary: charliecloud [riscv64] (groovy-proposed/universe) [0.16-1] (no packageset)
-queuebot:#ubuntu-release- New binary: purple-mm-sms [riscv64] (groovy-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: purple-xmpp-http-upload [riscv64] (groovy-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gsoap [ppc64el] (groovy-proposed/universe) [2.8.104-1] (no packageset)
-queuebot:#ubuntu-release- New binary: purple-mm-sms [ppc64el] (groovy-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: purple-xmpp-http-upload [ppc64el] (groovy-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libflame [ppc64el] (groovy-proposed/universe) [5.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-markovchain [ppc64el] (groovy-proposed/universe) [0.8.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: purple-mm-sms [arm64] (groovy-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: purple-xmpp-http-upload [arm64] (groovy-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: purple-mm-sms [armhf] (groovy-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: purple-xmpp-http-upload [armhf] (groovy-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-markovchain [arm64] (groovy-proposed/universe) [0.8.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-markovchain [armhf] (groovy-proposed/universe) [0.8.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gsoap [armhf] (groovy-proposed/universe) [2.8.104-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libflame [arm64] (groovy-proposed/universe) [5.2.0-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (focal-proposed/main) [2.664.3 => 2.664.4] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: libflame [armhf] (groovy-proposed/universe) [5.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gsoap [arm64] (groovy-proposed/universe) [2.8.104-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-markovchain [riscv64] (groovy-proposed/universe) [0.8.5-1] (no packageset)
<xnox> sil2100:  --	Notice(queuebot): Unapproved: livecd-rootfs (focal-proposed/main) [2.664.3 => 2.664.4] (desktop-core, i386-whitelist) would be nice for 20.04.1 release. I tested this in groovy it all works correctly.
<xnox> sil2100:  SRU paperwork in order.
<xnox> sil2100:  and it is trivial to test this out of proposed, with temporary change to seed, which we want permanent.
<xnox> stgraber:  ^^^^
<xnox> https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1882374
<ubot5> Ubuntu bug 1882374 in livecd-rootfs (Ubuntu Focal) "Support inclusion of snap from specific track/channel/branch" [High,In progress]
-queuebot:#ubuntu-release- New: accepted gsoap [arm64] (groovy-proposed) [2.8.104-1]
-queuebot:#ubuntu-release- New: accepted libflame [arm64] (groovy-proposed) [5.2.0-2]
-queuebot:#ubuntu-release- New: accepted purple-mm-sms [arm64] (groovy-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted purple-xmpp-http-upload [arm64] (groovy-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-markovchain [arm64] (groovy-proposed) [0.8.5-1]
-queuebot:#ubuntu-release- New: accepted r-cran-markovchain [riscv64] (groovy-proposed) [0.8.5-1]
-queuebot:#ubuntu-release- New: accepted gsoap [armhf] (groovy-proposed) [2.8.104-1]
-queuebot:#ubuntu-release- New: accepted purple-mm-sms [armhf] (groovy-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted r-cran-markovchain [armhf] (groovy-proposed) [0.8.5-1]
-queuebot:#ubuntu-release- New: accepted libflame [armhf] (groovy-proposed) [5.2.0-2]
-queuebot:#ubuntu-release- New: accepted purple-xmpp-http-upload [armhf] (groovy-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted charliecloud [arm64] (groovy-proposed) [0.16-1]
-queuebot:#ubuntu-release- New: accepted charliecloud [riscv64] (groovy-proposed) [0.16-1]
-queuebot:#ubuntu-release- New: accepted gsoap [ppc64el] (groovy-proposed) [2.8.104-1]
-queuebot:#ubuntu-release- New: accepted libflame [s390x] (groovy-proposed) [5.2.0-2]
-queuebot:#ubuntu-release- New: accepted purple-mm-sms [riscv64] (groovy-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted purple-xmpp-http-upload [riscv64] (groovy-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-markovchain [s390x] (groovy-proposed) [0.8.5-1]
-queuebot:#ubuntu-release- New: accepted charliecloud [armhf] (groovy-proposed) [0.16-1]
-queuebot:#ubuntu-release- New: accepted libflame [ppc64el] (groovy-proposed) [5.2.0-2]
-queuebot:#ubuntu-release- New: accepted purple-xmpp-http-upload [ppc64el] (groovy-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted gsoap [amd64] (groovy-proposed) [2.8.104-1]
-queuebot:#ubuntu-release- New: accepted r-cran-markovchain [ppc64el] (groovy-proposed) [0.8.5-1]
-queuebot:#ubuntu-release- New: accepted purple-mm-sms [ppc64el] (groovy-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted gsoap [s390x] (groovy-proposed) [2.8.104-1]
-queuebot:#ubuntu-release- New: accepted purple-mm-sms [amd64] (groovy-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted purple-xmpp-http-upload [amd64] (groovy-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted python-xstatic-lodash [amd64] (groovy-proposed) [4.16.4.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-argparse [amd64] (groovy-proposed) [2.0.1-2]
-queuebot:#ubuntu-release- New: accepted libflame [amd64] (groovy-proposed) [5.2.0-2]
-queuebot:#ubuntu-release- New: accepted purple-xmpp-http-upload [s390x] (groovy-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-markovchain [amd64] (groovy-proposed) [0.8.5-1]
-queuebot:#ubuntu-release- New: accepted purple-mm-sms [s390x] (groovy-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted python-xstatic-moment [amd64] (groovy-proposed) [2.8.4.2-1]
-queuebot:#ubuntu-release- New: accepted charliecloud [amd64] (groovy-proposed) [0.16-1]
-queuebot:#ubuntu-release- New: accepted charliecloud [s390x] (groovy-proposed) [0.16-1]
-queuebot:#ubuntu-release- New: accepted equinox-p2 [amd64] (groovy-proposed) [4.15-2]
-queuebot:#ubuntu-release- New: accepted haskell-ghc-lib-parser-ex [ppc64el] (groovy-proposed) [8.8.5.8-1]
-queuebot:#ubuntu-release- New: accepted charliecloud [ppc64el] (groovy-proposed) [0.16-1]
-queuebot:#ubuntu-release- New: accepted haskell-ghc-lib-parser-ex [amd64] (groovy-proposed) [8.8.5.8-1]
-queuebot:#ubuntu-release- New: accepted eclipse-platform-ui [amd64] (groovy-proposed) [4.16-2]
-queuebot:#ubuntu-release- New: accepted ruby-adsf [amd64] (groovy-proposed) [1.4.3+dfsg1-2]
<vorlon> xnox: yeah, chasing all these kernel binaries now
-queuebot:#ubuntu-release- Unapproved: python-apt (focal-proposed/main) [2.0.0 => 2.0.0ubuntu0.20.04.1] (core, i386-whitelist)
<xnox> vorlon:  i wish we had nbs-proposed report
-queuebot:#ubuntu-release- Packageset: 43 entries have been added or removed
<sil2100> xnox: hey! Thanks!
<sil2100> xnox: looking now
<sil2100> xnox: ok, accepted o/
<sil2100> I would like to kick the first candidates before this is released though
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (focal-proposed) [2.664.4]
-queuebot:#ubuntu-release- Unapproved: accepted python-apt [source] (focal-proposed) [2.0.0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Focal 20.04.1] (20200723.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Focal 20.04.1] (20200723.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Focal 20.04.1] (20200723.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Focal 20.04.1] (20200723.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Focal 20.04.1] (20200723.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Focal 20.04.1] (20200723.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Focal 20.04.1] (20200723.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi [Focal 20.04.1] (20200723.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi [Focal 20.04.1] (20200723.1) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Focal 20.04.1] (20200723.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Focal 20.04.1] has been updated (20200723.1)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Focal 20.04.1] has been updated (20200723.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Focal 20.04.1] (20200723) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Focal 20.04.1] (20200723.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity arm64 [Focal 20.04.1] (20200723.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity ppc64el [Focal 20.04.1] (20200723.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Focal 20.04.1] (20200723.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Focal 20.04.1] (20200723) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Focal 20.04.1] (20200723.1) has been added
-queuebot:#ubuntu-release- New binary: ipcalc-ng [s390x] (groovy-proposed/none) [0.4.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: xrdesktop [s390x] (groovy-proposed/multiverse) [0.15.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ipcalc-ng [arm64] (groovy-proposed/none) [0.4.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ipcalc-ng [armhf] (groovy-proposed/none) [0.4.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: xrdesktop [amd64] (groovy-proposed/multiverse) [0.15.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: xrdesktop [armhf] (groovy-proposed/multiverse) [0.15.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: xrdesktop [arm64] (groovy-proposed/multiverse) [0.15.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ipcalc-ng [amd64] (groovy-proposed/none) [0.4.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ipcalc-ng [riscv64] (groovy-proposed/universe) [0.4.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ipcalc-ng [ppc64el] (groovy-proposed/universe) [0.4.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: xrdesktop [ppc64el] (groovy-proposed/multiverse) [0.15.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: xrdesktop [riscv64] (groovy-proposed/multiverse) [0.15.1-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted ipcalc-ng [ppc64el] (groovy-proposed) [0.4.1-2]
-queuebot:#ubuntu-release- New: accepted xrdesktop [riscv64] (groovy-proposed) [0.15.1-2]
-queuebot:#ubuntu-release- New: accepted xrdesktop [ppc64el] (groovy-proposed) [0.15.1-2]
-queuebot:#ubuntu-release- New: accepted ipcalc-ng [amd64] (groovy-proposed) [0.4.1-2]
-queuebot:#ubuntu-release- New: accepted ipcalc-ng [armhf] (groovy-proposed) [0.4.1-2]
-queuebot:#ubuntu-release- New: accepted ipcalc-ng [s390x] (groovy-proposed) [0.4.1-2]
-queuebot:#ubuntu-release- New: accepted xrdesktop [arm64] (groovy-proposed) [0.15.1-2]
-queuebot:#ubuntu-release- New: accepted xrdesktop [s390x] (groovy-proposed) [0.15.1-2]
-queuebot:#ubuntu-release- New: accepted ipcalc-ng [arm64] (groovy-proposed) [0.4.1-2]
-queuebot:#ubuntu-release- New: accepted xrdesktop [amd64] (groovy-proposed) [0.15.1-2]
-queuebot:#ubuntu-release- New: accepted ipcalc-ng [riscv64] (groovy-proposed) [0.4.1-2]
-queuebot:#ubuntu-release- New: accepted xrdesktop [armhf] (groovy-proposed) [0.15.1-2]
#ubuntu-release 2020-07-24
-queuebot:#ubuntu-release- New binary: qgis [riscv64] (groovy-proposed/universe) [3.10.8+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyzbar [amd64] (groovy-proposed/universe) [0.1.8-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fwupd (groovy-proposed/main) [1.3.11-2 => 1.3.11-2] (core)
-queuebot:#ubuntu-release- New binary: haskell-butcher [amd64] (groovy-proposed/universe) [1.3.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: abseil [arm64] (groovy-proposed/universe) [0~20200225.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: abseil [armhf] (groovy-proposed/universe) [0~20200225.2-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fwupd (groovy-proposed/main) [1.3.11-2 => 1.3.11-2] (core)
-queuebot:#ubuntu-release- Unapproved: fwupd (groovy-proposed/main) [1.3.11-2 => 1.3.11-2] (core)
-queuebot:#ubuntu-release- New binary: haskell-butcher [arm64] (groovy-proposed/universe) [1.3.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-butcher [s390x] (groovy-proposed/universe) [1.3.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-butcher [riscv64] (groovy-proposed/universe) [1.3.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: abseil [ppc64el] (groovy-proposed/universe) [0~20200225.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-butcher [armhf] (groovy-proposed/universe) [1.3.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-butcher [ppc64el] (groovy-proposed/universe) [1.3.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted qgis [amd64] (groovy-proposed) [3.10.8+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted qgis [armhf] (groovy-proposed) [3.10.8+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted qgis [riscv64] (groovy-proposed) [3.10.8+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted qgis [arm64] (groovy-proposed) [3.10.8+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted qgis [s390x] (groovy-proposed) [3.10.8+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted qgis [ppc64el] (groovy-proposed) [3.10.8+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [amd64] (groovy-proposed) [20200626.00-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted pyzbar [amd64] (groovy-proposed) [0.1.8-1]
-queuebot:#ubuntu-release- New: accepted haskell-butcher [amd64] (groovy-proposed) [1.3.3.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-butcher [armhf] (groovy-proposed) [1.3.3.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-butcher [riscv64] (groovy-proposed) [1.3.3.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-butcher [arm64] (groovy-proposed) [1.3.3.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-butcher [s390x] (groovy-proposed) [1.3.3.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-butcher [ppc64el] (groovy-proposed) [1.3.3.1-1]
<doko> I'm doing the GCC-10 defaults change today. we see ftbfs in -proposed with updated symbols changes imported from Debian
<LocutusOfBorg> can anybody please NBS-cleanup qgis? missing build on amd64: libqgis-3d3.10.7, libqgis-analysis3.10.7, libqgis-app3.10.7, libqgis-core3.10.7, libqgis-customwidgets, libqgis-dev, libqgis-gui3.10.7, libqgis-native3.10.7, libqgis-server3.10.7, libqgisgrass7-3.10.7, libqgispython3.10.7, python3-qgis, python3-qgis-common, qgis, qgis-api-doc, qgis-common, qgis-plugin-grass, qgis-plugin-grass-common, qgis-provider-grass,
<LocutusOfBorg> qgis-providers, qgis-providers-common, qgis-server (from 3.10.7+dfsg-1ubuntu1)
<LocutusOfBorg> not everything from that list of course
<juliank> Laney: Wondering whether to add epson-inkjet-printer-escpr/arm64 to long_test, it basically gets killed two tests before the end
<juliank> not sure it's worth it
<juliank> but better than force-badtesting it
<Laney> long_tests is reasonable there I think
<juliank> Laney: merge https://code.launchpad.net/~juliank/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/388037
<juliank> I also added armhf, seems the same there
<juliank> I pushed that into production too
<juliank> Laney: I pulled the git branch on the lxd worker, and that one was quite outdated
<juliank> 22c1e65..731a88e
<juliank> that was 32 commits behind
<Laney> ð
<juliank> I still need to restart the worker I think so it picks up the new config
<juliank> ?
<Laney> HUP
<Laney> can't I give you push permissions for the git repository on Launchpad somehow?
<juliank> right, the backlog only had pkill -ef worker/worker :D
<juliank> Laney: Yes, with acls
<Laney> I thought that was something you could do
<Laney> but how do I get to the UI
<juliank> Laney: I don't know, xnox does
<Laney> maybe it's an admin thing
<juliank> worker's pkill -ef -HUP worker/worker
<juliank> :D
-queuebot:#ubuntu-release- New binary: haskell-tar-conduit [ppc64el] (groovy-proposed/universe) [0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-tar-conduit [s390x] (groovy-proposed/universe) [0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-ormolu [ppc64el] (groovy-proposed/universe) [0.0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-tar-conduit [amd64] (groovy-proposed/universe) [0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-ormolu [amd64] (groovy-proposed/universe) [0.0.3.1-1] (no packageset)
<cjwatson> Laney: "Manage permissions" on the git repository in question
<Laney> cjwatson: would that be on https://code.launchpad.net/autopkgtest-cloud ?
<cjwatson> Laney: Slightly confusing from a project - you need to find the link that says "lp:autopkgtest-cloud" and go to that
<Laney> ah
<cjwatson> Laney: Then "Manage permissions" from there and see https://blog.launchpad.net/code/git-per-branch-permissions
-queuebot:#ubuntu-release- New binary: haskell-tar-conduit [arm64] (groovy-proposed/universe) [0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New source: wireguard (xenial-proposed/primary) [1.0.20200513-1~16.04.1]
-queuebot:#ubuntu-release- New source: wireguard-linux-compat (xenial-proposed/primary) [1.0.20200611-1ubuntu1~16.04.1]
<Laney> Righto, that looks like it might have done it
<Laney> juliank: hopefully that works next time you have something
<Laney> and wip/mojo-juju-2 for the retry work :>
<juliank> Seems to do the trick
<Laney> LocutusOfBorg: looks like someone sorted out qgis
-queuebot:#ubuntu-release- New binary: haskell-tar-conduit [armhf] (groovy-proposed/universe) [0.3.2-1] (no packageset)
<Laney> that was confusing for a bit because I couldn't work out what to do, but then the next proposed-migration refresh cleared the problem
<LocutusOfBorg> yep thanks :)
<Trevinho> tjaalton: hey, could you maybe look at gnome-shell SRU in the focal queue?
-queuebot:#ubuntu-release- New binary: haskell-tar-conduit [riscv64] (groovy-proposed/universe) [0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted wireguard [source] (xenial-proposed) [1.0.20200513-1~16.04.1]
-queuebot:#ubuntu-release- New: accepted wireguard-linux-compat [source] (xenial-proposed) [1.0.20200611-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New binary: wireguard [amd64] (xenial-proposed/universe) [1.0.20200513-1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: wireguard [ppc64el] (xenial-proposed/universe) [1.0.20200513-1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: wireguard [powerpc] (xenial-proposed/universe) [1.0.20200513-1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: wireguard [s390x] (xenial-proposed/universe) [1.0.20200513-1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: wireguard [armhf] (xenial-proposed/universe) [1.0.20200513-1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: wireguard-linux-compat [amd64] (xenial-proposed/none) [1.0.20200611-1ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: fonts-meera-inimai [amd64] (groovy-proposed/universe) [2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: wireguard [arm64] (xenial-proposed/universe) [1.0.20200513-1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: wireguard [i386] (xenial-proposed/universe) [1.0.20200513-1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted fonts-meera-inimai [amd64] (groovy-proposed) [2.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-tar-conduit [amd64] (groovy-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-tar-conduit [armhf] (groovy-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-tar-conduit [riscv64] (groovy-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-tar-conduit [arm64] (groovy-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-tar-conduit [s390x] (groovy-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-tar-conduit [ppc64el] (groovy-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New binary: gcc-defaults [amd64] (groovy-proposed/main) [1.188ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New: accepted gcc-defaults [amd64] (groovy-proposed) [1.188ubuntu1]
-queuebot:#ubuntu-release- New binary: linux-signed-bluefield [arm64] (focal-proposed/universe) [5.4.0-1005.7] (no packageset)
<kanashiro> sil2100: ubuntu-archive a gentle reminder about LP #1868500
<ubot5> Launchpad bug 1868500 in golang-github-prometheus-client-golang (Ubuntu) "Please remove binaries for 0.9.2-0ubuntu3" [Undecided,New] https://launchpad.net/bugs/1868500
<kanashiro> it is blocking prometheus and some other packages
-queuebot:#ubuntu-release- New binary: gcc-defaults-ports [ppc64el] (groovy-proposed/universe) [1.188ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: gcc-defaults-ports [arm64] (groovy-proposed/universe) [1.188ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: gcc-defaults-ports [amd64] (groovy-proposed/universe) [1.188ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: gcc-defaults-ports [i386] (groovy-proposed/universe) [1.188ubuntu1] (i386-whitelist)
<juliank> should we force-badtest snapd/ppc64el?
<juliank> it fails most of the time, but sometimes succeeds
<juliank> it used to pass reliably
-queuebot:#ubuntu-release- New: accepted gcc-defaults-ports [amd64] (groovy-proposed) [1.188ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-defaults-ports [i386] (groovy-proposed) [1.188ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-defaults-ports [arm64] (groovy-proposed) [1.188ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-defaults-ports [ppc64el] (groovy-proposed) [1.188ubuntu1]
<juliank> Maybe should just force-skiptest xz-utils once epson-inkjet-printer-escpr has migrated
<juliank> (snapd will be fixed supposedly)
<sil2100> kanashiro: hey! Let me get to it in a moment :)
<sil2100> kanashiro: sorry for the lack of response, was a bit busy with .1 and .5 stuff
<kanashiro> sil2100: np, thanks a lot!
<sil2100> kanashiro: done!
<kanashiro> yay!
<xnox> sil2100: Laney: so iso tracker doesn't match www publication. The www publication is correct right? But doesn't cdimage the one that is pushing the URLs to the iso tracker? is it pushing a wrong url in the api call to "add" an image?
<Laney> There's per-series patterns in the ISO tracker's database
<xnox> or does iso-tracker self-creates them? I don't know how that works.
<Laney> focal -> use this pattern substitution the version
<xnox> oh, and the per-series pattern changes for LTS after LTS ships,no?!
<Laney> substituting*
<xnox> Laney:  is the pattern now fixed?
<Laney> I have no idea how that gets initialised, they are missing for subiquity
<Laney> I fixed s390x but it is really really tedious to do
<Laney> so not the other arches
<xnox> ack
<Laney> each of the entries in the download information is a database row basically
<Laney> so click add -> focal -> type in all the fields
<Laney> don't get it wrong
<Laney> there's probably a better way to do this, hoping somoene else knows what it is
<xnox> i'm glad i do not have permissions to access that page =)
<Laney> I can't imagine someone did this manually for all of the other products
<Laney> so I feel like there must be a thing somewhere that needs to be set up for subiquity
<Laney> bdmurray: stgraber: ^- maybe one of you knows?
<Laney> http://iso.qa.ubuntu.com/admin/config/services/qatracker/products/15/downloads e.g. this one has 'focal' entries, but they are missing for subiquity
<Laney> any idea how that gets done?
<bdmurray> Not really
<Laney> dunno why I thought you would :>
<bdmurray> Because I might have database access but I don't know if that would help.
<sil2100> You mean the download links on the ISO tracker?
<sil2100> I was always editing those manually
<sil2100> It's a pain in the ass
<sil2100> I already told xnox I'll fix the subiquity ones
<Laney> cool
<Laney> you mean you go through every product and add all the links for the new series manually?
<Laney> that must take ages, dear me
<sil2100> Not sure if Adam had some magic way of doing that, but I was usually just fixing a few missing ones usually
-queuebot:#ubuntu-release- New: accepted linux-signed-bluefield [arm64] (focal-proposed) [5.4.0-1005.7]
-queuebot:#ubuntu-release- New binary: wlroots [amd64] (groovy-proposed/universe) [0.11.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-blackfriday-v2 [amd64] (groovy-proposed/none) [2.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: wlroots [s390x] (groovy-proposed/universe) [0.11.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: wlroots [ppc64el] (groovy-proposed/universe) [0.11.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: wlroots [riscv64] (groovy-proposed/universe) [0.11.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: wlroots [armhf] (groovy-proposed/universe) [0.11.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: wlroots [arm64] (groovy-proposed/universe) [0.11.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-aeson-extra [s390x] (groovy-proposed/universe) [0.4.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-aeson-extra [ppc64el] (groovy-proposed/universe) [0.4.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-aeson-extra [amd64] (groovy-proposed/universe) [0.4.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-aeson-extra [arm64] (groovy-proposed/universe) [0.4.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-aeson-extra [armhf] (groovy-proposed/universe) [0.4.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-aeson-extra [riscv64] (groovy-proposed/universe) [0.4.1.3-1] (no packageset)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Focal 20.04.1] has been updated (20200724)
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Focal 20.04.1] has been updated (20200724)
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Focal 20.04.1] (20200724) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Focal 20.04.1] has been updated (20200724)
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Focal 20.04.1] has been updated (20200724)
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Focal 20.04.1] has been updated (20200724)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi [Focal 20.04.1] has been updated (20200724)
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi [Focal 20.04.1] has been updated (20200724)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Focal 20.04.1] has been updated (20200724)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Focal 20.04.1] has been updated (20200724)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Focal 20.04.1] has been updated (20200724)
-queuebot:#ubuntu-release- New: accepted haskell-aeson-extra [amd64] (groovy-proposed) [0.4.1.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-aeson-extra [armhf] (groovy-proposed) [0.4.1.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-aeson-extra [riscv64] (groovy-proposed) [0.4.1.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-aeson-extra [arm64] (groovy-proposed) [0.4.1.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-aeson-extra [s390x] (groovy-proposed) [0.4.1.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-aeson-extra [ppc64el] (groovy-proposed) [0.4.1.3-1]
-queuebot:#ubuntu-release- New: accepted golang-blackfriday-v2 [amd64] (groovy-proposed) [2.0.1-2]
-queuebot:#ubuntu-release- New: accepted wlroots [arm64] (groovy-proposed) [0.11.0-2]
-queuebot:#ubuntu-release- New: accepted wlroots [ppc64el] (groovy-proposed) [0.11.0-2]
-queuebot:#ubuntu-release- New: accepted wlroots [s390x] (groovy-proposed) [0.11.0-2]
-queuebot:#ubuntu-release- New: accepted wlroots [amd64] (groovy-proposed) [0.11.0-2]
-queuebot:#ubuntu-release- New: accepted wlroots [riscv64] (groovy-proposed) [0.11.0-2]
-queuebot:#ubuntu-release- New: accepted wlroots [armhf] (groovy-proposed) [0.11.0-2]
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Focal 20.04.1] has been updated (20200724)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Focal 20.04.1] has been updated (20200724)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Focal 20.04.1] has been updated (20200724)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Focal 20.04.1] has been updated (20200724)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity arm64 [Focal 20.04.1] has been updated (20200724)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity ppc64el [Focal 20.04.1] has been updated (20200724)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Focal 20.04.1] has been updated (20200724)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Focal 20.04.1] has been updated (20200724)
-queuebot:#ubuntu-release- New binary: haskell-http-client-restricted [s390x] (groovy-proposed/universe) [0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-http-client-restricted [amd64] (groovy-proposed/universe) [0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-containers-common [amd64] (groovy-proposed/universe) [0.14.4+ds1-2] (no packageset)
<xnox> vorlon:  apw: Laney: I do not believe https://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu/commit/?id=e41799e6e9af450d4de533f7f05f307967d8c302 is correct.
<xnox> and it is currently causing cirular non-considered.
<xnox> as it makes linux & linux-meta build-depend on each other virtual, making neither's of the packages build-dependencies to be installable, making both packages not considered, because of each other.
<xnox> can we revert that?
<xnox> Laney:  also linux & linux-meta are insufficient groupings. Complete grouping is linux, signed, meta, restricted-modules.
<xnox> Laney: also the generated build-dep doesn't take into account that on i386 linux is not built.
<xnox> yet synthesized build dep doesn't take that into account.
<xnox> Can we turn `new_dep = '%s (>= %s)' % (dep_pkg_name, dep_pkg_version)`
<xnox> into `new_dep = '%s (>= %s) [!i386]' % (dep_pkg_name, dep_pkg_version)` at least?
<apw> xnox, doesn't that stop britney releasing linux without meta?
<vorlon> it currently stops britney releasing linux at all
<xnox> apw:  it generates a dep, which will never exist on i386, making linux forever "build-deps non-installable"
<xnox> vorlon:  shall i submit pull requests?
<vorlon> xnox: yes please
<xnox> i boot VM
<xnox> it doesn't have cdrom
<xnox> my cloud-metadata is connected via cdrom
 * xnox ponders if i should just switch to the "pass metadata url via qemu smbios"
<xnox> and yet focal cloud image has no cdrom
-queuebot:#ubuntu-release- New binary: abseil [s390x] (groovy-proposed/universe) [0~20200225.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: abseil [ppc64el] (groovy-proposed/universe) [0~20200225.2-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: youtube-dl (focal-backports/universe) [2020.03.24-1 => 2020.06.16.1-1~ubuntu20.04.1] (ubuntu-budgie, ubuntukylin)
-queuebot:#ubuntu-release- New binary: eclipse-linuxtools [amd64] (groovy-proposed/none) [7.4.0+dfsg.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: singleapplication [amd64] (groovy-proposed/none) [3.1.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: abseil [amd64] (groovy-proposed/universe) [0~20200225.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: gcolor3 [amd64] (groovy-proposed/none) [2.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: eclipse-xsd [amd64] (groovy-proposed/none) [2.22.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jakarta-validation-api [amd64] (groovy-proposed/none) [3.0.0~M1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: felix-scr [amd64] (groovy-proposed/none) [2.1.20-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-casa-client [s390x] (groovy-proposed/universe) [0.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-xmpp4r [amd64] (groovy-proposed/none) [0.5.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-ncls [amd64] (groovy-proposed/none) [0.0+git20200225.f9894b0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-casa-client [ppc64el] (groovy-proposed/universe) [0.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: topplot [amd64] (groovy-proposed/none) [0.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: abseil [arm64] (groovy-proposed/universe) [0~20200225.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: abseil [armhf] (groovy-proposed/universe) [0~20200225.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-ormolu [amd64] (groovy-proposed/universe) [0.0.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libhandy-1 [amd64] (groovy-proposed/none) [0.84.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gcolor3 [s390x] (groovy-proposed/none) [2.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-casa-client [arm64] (groovy-proposed/universe) [0.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libhandy-1 [s390x] (groovy-proposed/none) [0.84.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: singleapplication [s390x] (groovy-proposed/universe) [3.1.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-ncls [s390x] (groovy-proposed/none) [0.0+git20200225.f9894b0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-ormolu [ppc64el] (groovy-proposed/universe) [0.0.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gcolor3 [armhf] (groovy-proposed/universe) [2.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gcolor3 [arm64] (groovy-proposed/universe) [2.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-casa-client [armhf] (groovy-proposed/universe) [0.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gcolor3 [ppc64el] (groovy-proposed/universe) [2.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: singleapplication [arm64] (groovy-proposed/universe) [3.1.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-ncls [arm64] (groovy-proposed/universe) [0.0+git20200225.f9894b0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: singleapplication [ppc64el] (groovy-proposed/universe) [3.1.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: singleapplication [armhf] (groovy-proposed/universe) [3.1.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libhandy-1 [ppc64el] (groovy-proposed/universe) [0.84.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-ncls [ppc64el] (groovy-proposed/universe) [0.0+git20200225.f9894b0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libhandy-1 [arm64] (groovy-proposed/universe) [0.84.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libhandy-1 [armhf] (groovy-proposed/universe) [0.84.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: singleapplication [riscv64] (groovy-proposed/universe) [3.1.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gcolor3 [riscv64] (groovy-proposed/universe) [2.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-ncls [riscv64] (groovy-proposed/universe) [0.0+git20200225.f9894b0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: abseil [riscv64] (groovy-proposed/universe) [0~20200225.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-casa-client [amd64] (groovy-proposed/universe) [0.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted abseil [amd64] (groovy-proposed) [0~20200225.2-3]
-queuebot:#ubuntu-release- New: accepted abseil [armhf] (groovy-proposed) [0~20200225.2-3]
-queuebot:#ubuntu-release- New: accepted abseil [riscv64] (groovy-proposed) [0~20200225.2-3]
-queuebot:#ubuntu-release- New: accepted eclipse-linuxtools [amd64] (groovy-proposed) [7.4.0+dfsg.1-1]
-queuebot:#ubuntu-release- New: accepted felix-scr [amd64] (groovy-proposed) [2.1.20-1]
-queuebot:#ubuntu-release- New: accepted gcolor3 [arm64] (groovy-proposed) [2.3.1-2]
-queuebot:#ubuntu-release- New: accepted gcolor3 [ppc64el] (groovy-proposed) [2.3.1-2]
-queuebot:#ubuntu-release- New: accepted gcolor3 [s390x] (groovy-proposed) [2.3.1-2]
-queuebot:#ubuntu-release- New: accepted abseil [arm64] (groovy-proposed) [0~20200225.2-3]
-queuebot:#ubuntu-release- New: accepted abseil [s390x] (groovy-proposed) [0~20200225.2-3]
-queuebot:#ubuntu-release- New: accepted gcolor3 [amd64] (groovy-proposed) [2.3.1-2]
-queuebot:#ubuntu-release- New: accepted gcolor3 [riscv64] (groovy-proposed) [2.3.1-2]
-queuebot:#ubuntu-release- New: accepted abseil [ppc64el] (groovy-proposed) [0~20200225.2-3]
-queuebot:#ubuntu-release- New: accepted gcolor3 [armhf] (groovy-proposed) [2.3.1-2]
-queuebot:#ubuntu-release- New: accepted eclipse-xsd [amd64] (groovy-proposed) [2.22.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-containers-common [amd64] (groovy-proposed) [0.14.4+ds1-2]
-queuebot:#ubuntu-release- New: accepted jakarta-validation-api [amd64] (groovy-proposed) [3.0.0~M1-1]
-queuebot:#ubuntu-release- New: accepted ruby-xmpp4r [amd64] (groovy-proposed) [0.5.6-1]
-queuebot:#ubuntu-release- New: accepted singleapplication [amd64] (groovy-proposed) [3.1.4-2]
-queuebot:#ubuntu-release- New: accepted singleapplication [armhf] (groovy-proposed) [3.1.4-2]
-queuebot:#ubuntu-release- New: accepted singleapplication [riscv64] (groovy-proposed) [3.1.4-2]
-queuebot:#ubuntu-release- New: accepted topplot [amd64] (groovy-proposed) [0.0.4-1]
-queuebot:#ubuntu-release- New: accepted singleapplication [arm64] (groovy-proposed) [3.1.4-2]
-queuebot:#ubuntu-release- New: accepted singleapplication [s390x] (groovy-proposed) [3.1.4-2]
-queuebot:#ubuntu-release- New: accepted singleapplication [ppc64el] (groovy-proposed) [3.1.4-2]
-queuebot:#ubuntu-release- New binary: libhandy-1 [riscv64] (groovy-proposed/universe) [0.84.0-1] (no packageset)
#ubuntu-release 2020-07-25
-queuebot:#ubuntu-release- New: accepted abseil [arm64] (groovy-proposed) [0~20200225.2-2]
-queuebot:#ubuntu-release- New: accepted abseil [ppc64el] (groovy-proposed) [0~20200225.2-2]
-queuebot:#ubuntu-release- New: accepted abseil [armhf] (groovy-proposed) [0~20200225.2-2]
-queuebot:#ubuntu-release- New: accepted libhandy-1 [amd64] (groovy-proposed) [0.84.0-1]
-queuebot:#ubuntu-release- New: accepted libhandy-1 [armhf] (groovy-proposed) [0.84.0-1]
-queuebot:#ubuntu-release- New: accepted libhandy-1 [riscv64] (groovy-proposed) [0.84.0-1]
-queuebot:#ubuntu-release- New: accepted libhandy-1 [arm64] (groovy-proposed) [0.84.0-1]
-queuebot:#ubuntu-release- New: accepted libhandy-1 [s390x] (groovy-proposed) [0.84.0-1]
-queuebot:#ubuntu-release- New: accepted libhandy-1 [ppc64el] (groovy-proposed) [0.84.0-1]
-queuebot:#ubuntu-release- New binary: haskell-casa-client [riscv64] (groovy-proposed/universe) [0.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-casa-client [amd64] (groovy-proposed) [0.0.1-2]
-queuebot:#ubuntu-release- New: accepted haskell-casa-client [riscv64] (groovy-proposed) [0.0.1-2]
-queuebot:#ubuntu-release- New: accepted python-ncls [ppc64el] (groovy-proposed) [0.0+git20200225.f9894b0+ds-1]
-queuebot:#ubuntu-release- New: accepted haskell-casa-client [armhf] (groovy-proposed) [0.0.1-2]
-queuebot:#ubuntu-release- New: accepted python-ncls [riscv64] (groovy-proposed) [0.0+git20200225.f9894b0+ds-1]
-queuebot:#ubuntu-release- New: accepted python-ncls [arm64] (groovy-proposed) [0.0+git20200225.f9894b0+ds-1]
-queuebot:#ubuntu-release- New: accepted haskell-casa-client [arm64] (groovy-proposed) [0.0.1-2]
-queuebot:#ubuntu-release- New: accepted haskell-casa-client [s390x] (groovy-proposed) [0.0.1-2]
-queuebot:#ubuntu-release- New: accepted haskell-http-client-restricted [s390x] (groovy-proposed) [0.0.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-ormolu [ppc64el] (groovy-proposed) [0.0.3.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-ormolu [ppc64el] (groovy-proposed) [0.0.3.1-2]
-queuebot:#ubuntu-release- New: accepted python-ncls [s390x] (groovy-proposed) [0.0+git20200225.f9894b0+ds-1]
-queuebot:#ubuntu-release- New: accepted haskell-casa-client [ppc64el] (groovy-proposed) [0.0.1-2]
-queuebot:#ubuntu-release- New: accepted haskell-ormolu [amd64] (groovy-proposed) [0.0.3.1-1]
-queuebot:#ubuntu-release- New: accepted python-ncls [amd64] (groovy-proposed) [0.0+git20200225.f9894b0+ds-1]
-queuebot:#ubuntu-release- New: accepted haskell-http-client-restricted [amd64] (groovy-proposed) [0.0.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-ormolu [amd64] (groovy-proposed) [0.0.3.1-2]
-queuebot:#ubuntu-release- New binary: eclipse-wtp [amd64] (groovy-proposed/universe) [3.18-1] (no packageset)
-queuebot:#ubuntu-release- New binary: grpc [s390x] (groovy-proposed/universe) [1.30.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: grpc [amd64] (groovy-proposed/universe) [1.30.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: grpc [ppc64el] (groovy-proposed/universe) [1.30.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-adrianmo-go-nmea [amd64] (groovy-proposed/none) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libhash-defhash-perl [amd64] (groovy-proposed/none) [0.071-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dh-cmake [amd64] (groovy-proposed/none) [0.5] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-sean--pager [amd64] (groovy-proposed/none) [0.0~git20180208.666be9b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-shenwei356-natsort [amd64] (groovy-proposed/none) [0.0~git20190418.600d539-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-goburrow-serial [amd64] (groovy-proposed/none) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-shenwei356-bpool [amd64] (groovy-proposed/none) [0.0~git20160710.f9e0ee4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-alexcesaro-log [amd64] (groovy-proposed/none) [0.0~git20150915.61e6862-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-sean--seed [amd64] (groovy-proposed/none) [0.0~git20170313.e2103e2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-malfunkt-iprange [amd64] (groovy-proposed/none) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xmonad-contrib [ppc64el] (groovy-proposed/universe) [0.16-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xmonad-contrib [s390x] (groovy-proposed/universe) [0.16-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xmonad-contrib [amd64] (groovy-proposed/universe) [0.16-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xmonad-contrib [arm64] (groovy-proposed/universe) [0.16-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xmonad-contrib [armhf] (groovy-proposed/universe) [0.16-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted dh-cmake [amd64] (groovy-proposed) [0.5]
-queuebot:#ubuntu-release- New: accepted golang-github-adrianmo-go-nmea [amd64] (groovy-proposed) [1.2.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-goburrow-serial [amd64] (groovy-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-sean--pager [amd64] (groovy-proposed) [0.0~git20180208.666be9b-1]
-queuebot:#ubuntu-release- New: accepted golang-github-shenwei356-bpool [amd64] (groovy-proposed) [0.0~git20160710.f9e0ee4-1]
-queuebot:#ubuntu-release- New: accepted libhash-defhash-perl [amd64] (groovy-proposed) [0.071-1]
-queuebot:#ubuntu-release- New: accepted eclipse-wtp [amd64] (groovy-proposed) [3.18-1]
-queuebot:#ubuntu-release- New: accepted golang-github-malfunkt-iprange [amd64] (groovy-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-shenwei356-natsort [amd64] (groovy-proposed) [0.0~git20190418.600d539-1]
-queuebot:#ubuntu-release- New: accepted golang-github-alexcesaro-log [amd64] (groovy-proposed) [0.0~git20150915.61e6862-1]
-queuebot:#ubuntu-release- New: accepted golang-github-sean--seed [amd64] (groovy-proposed) [0.0~git20170313.e2103e2-1]
-queuebot:#ubuntu-release- New binary: snapraid [s390x] (groovy-proposed/universe) [11.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: snapraid [ppc64el] (groovy-proposed/universe) [11.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: snapraid [amd64] (groovy-proposed/universe) [11.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-shenwei356-util [amd64] (groovy-proposed/universe) [0.0~git20190523.f71ff37-2] (no packageset)
-queuebot:#ubuntu-release- New binary: snapraid [arm64] (groovy-proposed/universe) [11.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: snapraid [armhf] (groovy-proposed/universe) [11.5-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-github-shenwei356-util [amd64] (groovy-proposed) [0.0~git20190523.f71ff37-2]
-queuebot:#ubuntu-release- New binary: golang-github-shenwei356-bwt [amd64] (groovy-proposed/universe) [0.0~git20200418.ae79c98-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-shenwei356-bio [amd64] (groovy-proposed/universe) [0.0~git20200505.5afc28c-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-github-shenwei356-bio [amd64] (groovy-proposed) [0.0~git20200505.5afc28c-1]
-queuebot:#ubuntu-release- New: accepted golang-github-shenwei356-bwt [amd64] (groovy-proposed) [0.0~git20200418.ae79c98-2]
-queuebot:#ubuntu-release- New binary: xmonad-contrib [riscv64] (groovy-proposed/universe) [0.16-1] (no packageset)
-queuebot:#ubuntu-release- New binary: uuagc [amd64] (groovy-proposed/universe) [0.9.52.2-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: uuagc [ppc64el] (groovy-proposed/universe) [0.9.52.2-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: uuagc [s390x] (groovy-proposed/universe) [0.9.52.2-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: uuagc [arm64] (groovy-proposed/universe) [0.9.52.2-2ubuntu1] (no packageset)
<LocutusOfBorg> please accept uuagc and xmonad-contrib, thanks!
<LocutusOfBorg> haskell transition is mostly over, waiting for 3 builds to finish and publish
-queuebot:#ubuntu-release- New binary: golang-github-jung-kurt-gofpdf [amd64] (groovy-proposed/universe) [2.17.2+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-golang-x-arch [amd64] (groovy-proposed/universe) [0.0~git20200511.f7c7858-2] (no packageset)
-queuebot:#ubuntu-release- New binary: elfutils [amd64] (groovy-proposed/main) [0.180-0ubuntu2] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: elfutils [s390x] (groovy-proposed/main) [0.180-0ubuntu2] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: elfutils [ppc64el] (groovy-proposed/main) [0.180-0ubuntu2] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: uuagc [armhf] (groovy-proposed/universe) [0.9.52.2-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: elfutils [i386] (groovy-proposed/main) [0.180-0ubuntu2] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: elfutils [armhf] (groovy-proposed/main) [0.180-0ubuntu2] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: elfutils [arm64] (groovy-proposed/main) [0.180-0ubuntu2] (core, i386-whitelist)
<Laney> xnox: I think it'd just be easier if you give me a patch
<Laney> I don't want to be responsible forever for doing everything on this codebase
<Laney> sorry if it's not all right immediately, it's a big task for one person to do
<Laney> it should look for a package that actually exists on the arch in question
<Laney> in fact
-queuebot:#ubuntu-release- New binary: elfutils [riscv64] (groovy-proposed/main) [0.180-0ubuntu2] (core, i386-whitelist)
-queuebot:#ubuntu-release- New: accepted golang-github-jung-kurt-gofpdf [amd64] (groovy-proposed) [2.17.2+ds-1]
-queuebot:#ubuntu-release- New: accepted golang-golang-x-arch [amd64] (groovy-proposed) [0.0~git20200511.f7c7858-2]
-queuebot:#ubuntu-release- New: accepted xmonad-contrib [amd64] (groovy-proposed) [0.16-1]
-queuebot:#ubuntu-release- New: accepted xmonad-contrib [armhf] (groovy-proposed) [0.16-1]
-queuebot:#ubuntu-release- New: accepted xmonad-contrib [riscv64] (groovy-proposed) [0.16-1]
-queuebot:#ubuntu-release- New: accepted xmonad-contrib [arm64] (groovy-proposed) [0.16-1]
-queuebot:#ubuntu-release- New: accepted xmonad-contrib [s390x] (groovy-proposed) [0.16-1]
-queuebot:#ubuntu-release- New: accepted xmonad-contrib [ppc64el] (groovy-proposed) [0.16-1]
-queuebot:#ubuntu-release- New: accepted elfutils [amd64] (groovy-proposed) [0.180-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted elfutils [armhf] (groovy-proposed) [0.180-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted elfutils [ppc64el] (groovy-proposed) [0.180-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted elfutils [s390x] (groovy-proposed) [0.180-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted elfutils [arm64] (groovy-proposed) [0.180-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted elfutils [riscv64] (groovy-proposed) [0.180-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted elfutils [i386] (groovy-proposed) [0.180-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted protobuf [amd64] (groovy-proposed) [3.12.3-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted protobuf [armhf] (groovy-proposed) [3.12.3-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted protobuf [riscv64] (groovy-proposed) [3.12.3-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted protobuf [arm64] (groovy-proposed) [3.12.3-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted protobuf [s390x] (groovy-proposed) [3.12.3-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted protobuf [ppc64el] (groovy-proposed) [3.12.3-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted uuagc [amd64] (groovy-proposed) [0.9.52.2-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted uuagc [armhf] (groovy-proposed) [0.9.52.2-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted uuagc [s390x] (groovy-proposed) [0.9.52.2-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted uuagc [arm64] (groovy-proposed) [0.9.52.2-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted uuagc [ppc64el] (groovy-proposed) [0.9.52.2-2ubuntu1]
-queuebot:#ubuntu-release- New binary: xmonad-extras [s390x] (groovy-proposed/universe) [0.15.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xmonad-extras [amd64] (groovy-proposed/universe) [0.15.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xmonad-extras [ppc64el] (groovy-proposed/universe) [0.15.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xmonad-extras [arm64] (groovy-proposed/universe) [0.15.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-mmcloughlin-avo [amd64] (groovy-proposed/universe) [0.0~git20200523.4439b6b-2] (no packageset)
-queuebot:#ubuntu-release- New binary: xmonad-extras [armhf] (groovy-proposed/universe) [0.15.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: grpc [armhf] (groovy-proposed/universe) [1.30.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: grpc [arm64] (groovy-proposed/universe) [1.30.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: xmonad-extras [riscv64] (groovy-proposed/universe) [0.15.2-1] (no packageset)
<Laney> sorry went to watch ghostbusters
<Laney> I think that if we just do the arch-specific thing it might indeed create a circular situation
<Laney> perhaps making a LinuxPolicy is the better solution
<Laney> which would look to see if the -meta is invalid, and invalidate the linux too if so
-queuebot:#ubuntu-release- New binary: golang-github-viant-toolbox [amd64] (groovy-proposed/universe) [0.33.0-10] (no packageset)
-queuebot:#ubuntu-release- New binary: os-autoinst [amd64] (groovy-proposed/universe) [4.5.1527308405.8b586d5-4.2] (no packageset)
#ubuntu-release 2020-07-26
-queuebot:#ubuntu-release- New binary: python-email-validator [amd64] (groovy-proposed/universe) [1.1.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: grpc [s390x] (groovy-proposed/universe) [1.30.2-2build1] (no packageset)
-queuebot:#ubuntu-release- New binary: grpc [amd64] (groovy-proposed/universe) [1.30.2-2build1] (no packageset)
-queuebot:#ubuntu-release- New binary: grpc [ppc64el] (groovy-proposed/universe) [1.30.2-2build1] (no packageset)
-queuebot:#ubuntu-release- New binary: grpc [arm64] (groovy-proposed/universe) [1.30.2-2build1] (no packageset)
-queuebot:#ubuntu-release- New binary: grpc [armhf] (groovy-proposed/universe) [1.30.2-2build1] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-github-mmcloughlin-avo [amd64] (groovy-proposed) [0.0~git20200523.4439b6b-2]
-queuebot:#ubuntu-release- New: accepted os-autoinst [amd64] (groovy-proposed) [4.5.1527308405.8b586d5-4.2]
-queuebot:#ubuntu-release- New: accepted xmonad-extras [amd64] (groovy-proposed) [0.15.2-1]
-queuebot:#ubuntu-release- New: accepted xmonad-extras [armhf] (groovy-proposed) [0.15.2-1]
-queuebot:#ubuntu-release- New: accepted xmonad-extras [riscv64] (groovy-proposed) [0.15.2-1]
-queuebot:#ubuntu-release- New: accepted golang-github-viant-toolbox [amd64] (groovy-proposed) [0.33.0-10]
-queuebot:#ubuntu-release- New: accepted xmonad-extras [arm64] (groovy-proposed) [0.15.2-1]
-queuebot:#ubuntu-release- New: accepted xmonad-extras [s390x] (groovy-proposed) [0.15.2-1]
-queuebot:#ubuntu-release- New: accepted python-email-validator [amd64] (groovy-proposed) [1.1.1-3]
-queuebot:#ubuntu-release- New: accepted xmonad-extras [ppc64el] (groovy-proposed) [0.15.2-1]
-queuebot:#ubuntu-release- New: accepted grpc [amd64] (groovy-proposed) [1.30.2-2]
-queuebot:#ubuntu-release- New: accepted grpc [armhf] (groovy-proposed) [1.30.2-2]
-queuebot:#ubuntu-release- New: accepted grpc [s390x] (groovy-proposed) [1.30.2-2]
-queuebot:#ubuntu-release- New: accepted grpc [arm64] (groovy-proposed) [1.30.2-2build1]
-queuebot:#ubuntu-release- New: accepted grpc [ppc64el] (groovy-proposed) [1.30.2-2build1]
-queuebot:#ubuntu-release- New: accepted grpc [arm64] (groovy-proposed) [1.30.2-2]
-queuebot:#ubuntu-release- New: accepted grpc [amd64] (groovy-proposed) [1.30.2-2build1]
-queuebot:#ubuntu-release- New: accepted grpc [s390x] (groovy-proposed) [1.30.2-2build1]
-queuebot:#ubuntu-release- New: accepted grpc [ppc64el] (groovy-proposed) [1.30.2-2]
-queuebot:#ubuntu-release- New: accepted grpc [armhf] (groovy-proposed) [1.30.2-2build1]
-queuebot:#ubuntu-release- New: accepted snapraid [amd64] (groovy-proposed) [11.5-1]
-queuebot:#ubuntu-release- New: accepted snapraid [armhf] (groovy-proposed) [11.5-1]
-queuebot:#ubuntu-release- New: accepted snapraid [s390x] (groovy-proposed) [11.5-1]
-queuebot:#ubuntu-release- New: accepted snapraid [arm64] (groovy-proposed) [11.5-1]
-queuebot:#ubuntu-release- New: accepted snapraid [ppc64el] (groovy-proposed) [11.5-1]
-queuebot:#ubuntu-release- New binary: golang-github-viant-assertly [amd64] (groovy-proposed/universe) [0.5.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-francoispqt-gojay [armhf] (groovy-proposed/universe) [1.2.13-3] (no packageset)
-queuebot:#ubuntu-release- New binary: pidcat [amd64] (groovy-proposed/none) [2.1.0-3] (no packageset)
<Laney> ok, https://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu/commit/?h=wip/linux-policy&id=8c3b9e58932bbfc6219fb0d355d977efccfe2349
<Laney> couldn't resist in the end ...
<Laney> (not merged, but sample output https://people.canonical.com/~ubuntu-archive/laney/proposed-migration/update_excuses.html#linux - without autopkgtest)
-queuebot:#ubuntu-release- New source: binutils-bpf (groovy-proposed/primary) [0ubuntu1]
-queuebot:#ubuntu-release- New source: gcc-bpf (groovy-proposed/primary) [0ubuntu1]
-queuebot:#ubuntu-release- New binary: phoc [amd64] (groovy-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: phoc [s390x] (groovy-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: phoc [arm64] (groovy-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-itemadapter [amd64] (groovy-proposed/none) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: phoc [armhf] (groovy-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: phoc [ppc64el] (groovy-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gcc-10-cross-mipsen [ppc64el] (groovy-proposed/universe) [2+c1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: phoc [riscv64] (groovy-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gcc-10-cross-mipsen [amd64] (groovy-proposed/universe) [2+c1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: x264 [amd64] (groovy-proposed/universe) [2:0.160.3011+gitcde9a93-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: x264 [i386] (groovy-proposed/universe) [2:0.160.3011+gitcde9a93-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: x264 [arm64] (groovy-proposed/universe) [2:0.160.3011+gitcde9a93-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: x264 [armhf] (groovy-proposed/universe) [2:0.160.3011+gitcde9a93-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: x264 [riscv64] (groovy-proposed/universe) [2:0.160.3011+gitcde9a93-2] (i386-whitelist, kubuntu)
