#ubuntu-release 2010-09-06
<bradm> howdy - is someone able to clear out cdimages a bit?  the servers are pretty full - alpinecurrent only has 5G free
<ScottK> Probably slangasek or cjwatson if they are around.
<bradm> I'm trying to see what I can do elsewhere to free up some space too
<nhandler> Didn't cjwatson just clear up 40G the other day there?
<bradm> nhandler: I believe so, things are still pretty tight.
<slangasek> I can nuke the old hardy daily dirs, we aren't doing any more point releases there; that only gains ~5GB though
<slangasek> hmm, no, I guess there's more than that scattered about after all
<slangasek> um... ok, someone is building hardy "mobile" images on there as of three days ago (?!)
<bradm> slangasek: that'd be great if its not needed
<bradm> huh, that seems odd
<slangasek> yes, it is
<slangasek> er, no; only the directory timestamps have changed
<slangasek> so that's another 7.1GB we could free, but should probably confirm with the mobile team before we nuke these since they all have codenames I'm unfamiliar with
<bradm> slangasek: that's a great start
<bradm> gives us a bit of breathing room anyway
<persia> slangasek, The hardy (really 8.06) lpia mobile images were advertised for 18 months support, no revised LTS images.  There ought be no reason they can't be dropped at this point.
<slangasek> persia: I'm referring to the stuff under http://cdimage.ubuntu.com/mobile/hardy/, that doesn't look like moblin stuff?
<persia> As far as I understood, from feisty through intrepid, most of the "mobile" stuff was based on moblin 1.0.  Then Intel did things differently, and nobody cared enough to pick up the pieces.
<persia> Note that this is *different* from ubuntu-moblin-remix, which was based on Moblin 2.0 (much later), and used an entirely different set of technologies, target platform, etc.
<persia> I *think* the "moblin" and "mobile" directories are related (one a symlink to the other), but it may be worth verifying this.
<persia>  /tocd/ and /tocd3.1/ may also be interesting candidates, if you're deleting stuff: that's all pre-Dapper
<bradm> slangasek: antimony's getting close too if you're able to do anything about that?
<persia> aren't we talking about antimony, or has my mapping between hostnames and machines gone wonky?
<bradm> persia: antimony / alpinecurrant / chromium / beryllium
 * persia thought the latter three were mirrors of a subsection of the first, but has every reason to have incomplete, outdated, or incorrect data
<slangasek> persia: tocd/ and tocd3.1/ - yes, those have been there since before I came along, I assumed somebody who remembers what they were would remove them as appropriate :)
<bradm> persia: the conversation started with talking about alpinecurrant, not sure if slangasek is looking at antimony as well
<persia> slangasek, They are "The Open CD" for hoary/breezy : open source software you can use on your Windows install.
<slangasek> I'll move the mobile stuff off to old-images, but that only helps once someone archives old-images off
<slangasek> bradm: er, I'm /only/ looking at antimony, I don't have any direct access to alpinecurrant
<bradm> slangasek: oh, ok :)
<slangasek> and alpinecurrant mirrors from antimony, so that's where I'd be looking anyway :)
<bradm> slangasek: thats weird, because when you were talking about removing stuff, alpinecurrant was going down, but antimony wasn't
<bradm> slangasek: thats obviously what confused me
<slangasek> well, the stuff I removed was removed on antimony :)
<bradm> slangasek: odd.
<bradm> slangasek: it hasn't gotten any more free space yet
<bradm> slangasek: but the others have
<persia> Might be an open-files issue: files dropped from directories aren't being mirrored, but still reserved until closed, or something?
<bradm> thats possible
<persia> Also, moving stuff to old-images will affect mirrors more than antimony
<bradm> alpinecurrant's gone to 35G free from 5G
<bradm> antimony hasn't moved
<bradm> so that could explain it
<persia> Might be worth touching base with the gobuntu folks: they don't seem to have participated in a point release since 8.04.1, and might no longer need the images.
<persia> same for kubuntu-kde4
 * persia wonders why kubuntu-netbook has lucid images for armel and not i386, thinking someone probably cleaned up differently than expected
<persia> slangasek, Is /ubuntu-mid/ a symlink, or an actual empty directory?  I think last release was intrepid, so this might be a candidate to drop (even if there were files).  There was work towards jaunty, but the result was unreleasable (IIRC)
<slangasek> persia: empty dir; nuked
<bradm> slangasek: are you just moving the bulk of the data to an old-{releases,image} folder to be cleaned up later?  or deleting stuff directly?
<slangasek> bradm: most stuff I deleted; the moblin stuff I moved to old-images
<bradm> slangasek: ok, still trying to work out why the free space isn't going up
<bradm> no deleted files still open from what I can see
<bradm> heh,the backup directory has files from 2005
<persia> bradm, maybe hardlinks somewhere?
<ogra> slangasek, bug 630825 is a duplicate of a kernel bug that was fixed for beagle a while ago, intresting that it shows on gumstix now, iirc it had to do with a broken MMC driver
<ubot4> Launchpad bug 630825 in linux (Ubuntu) (and 1 other project) "Preinstalled Maverick netbook image won't boot on Gumstix Overo (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/630825
 * ogra looks up the daisy chain issue
<ogra> Bug 594382
<ubot4> Launchpad bug 594382 in linux (Ubuntu Maverick) (and 1 other project) "Wake up daisy chain activation failed on omap3 (affects: 1) (heat: 46)" [Critical,Fix released] https://launchpad.net/bugs/594382
<ogra> slangasek, oh, and manifest is on my TODO, buut rather low down on the list (we need to get new u-boot and x-loader for the omap4 ES2 hardware in, after that i'll have some time)
<cjwatson> bradm,slangasek: there was a www.prev backup hardlink tree on antimony from beta release time; I've nuked it
<ogra> cjwatson, slangasek, does http://paste.ubuntu.com/489156/ look ok to you (to copy .manifest for preinstalled images) ?
<cjwatson> ogra: yes
<ogra> great
 * ogra commits
<Daviey> Would a member of the release teem be able to comment on bug #631451, please?
<ubot4> Launchpad bug 631451 in eucalyptus (Ubuntu) "[UIFe] UEC Web Portal has old logo, and css needs tweaking. (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/631451
<persia> Doesn't the docs team usually make the call on UIFe requests?
<cjwatson> no, https://wiki.ubuntu.com/UserInterfaceFreeze
<Daviey> persia, In honesty - this is the first UIFe i've applied for - so you may know more than i do :)
<cjwatson> is eucalyptus even subject to the UI freeze?
<Daviey> cjwatson, Pass!
<cjwatson> approved, anyway
<Daviey> it's a UI.. so seemed safer to :/
<persia> Ah, approval by RT, *notification* to docs/translations.  That's a subtlety I missed before.  Thanks.
<Daviey> cjwatson, you rock!
<ogra> hmm, publish-daily doesnt seem to have picked up the manifest :(
<cjwatson> which build?
<ogra> 20100906.1
<ogra> hmm, i dont see it in /srv/cdimage.ubuntu.com/scratch/ubuntu-netbook/ports_daily-preinstalled/debian-cd/armel+omap4/
<cjwatson> no no
<cjwatson> which ... that
<ogra> so the issue seems to be before publish-daily even
<cjwatson> I'll look
<ogra>  /srv/cdimage.ubuntu.com/scratch/ubuntu-netbook/ports_daily-preinstalled/preinstalled/ has it
<cjwatson> you put your code in a target which isn't called for preinstalled images
<cjwatson> I've moved it to the right place
<ogra> oh
<cjwatson> go ahead and try a rebuild
<ogra> will do without livefs rebuild
 * ogra hugs cjwatson ... all working, thanks !
<stgraber> cjwatson: hello, just a quick reminder for the edubuntu gfxboot logo ;)
<cjwatson> done
<stgraber> rocks, thanks!
<Laney> cjwatson: don't suppose you could do one more sync? I forgot to do gkeyfile-sharp (experimental)
<Laney> & to the packageset
#ubuntu-release 2010-09-07
<cjwatson> Laney: done
<Laney> thanks
<Laney> hopefully now banshee builds (once everything is out of NEW)
<Daviey> Hi, would an AA be able to publish eucalyptus 1.6.2-0ubuntu30.4 to proposed?
<Daviey> hmkm.. perhaps devel would have been a better place
<lamont> oh btw release gods, acorn might be a tad slow for a while... testing the bootstrappability of fpc
<lamont> acorn back to just being normally slow
#ubuntu-release 2010-09-08
<ogra> lamont, sigh ... arcorn is dead once again
<ogra> i dont get why it suddenly fails so often
<lamont> ogra: ditto for hawthorn, it appears
<lamont> interestingly, it seems to be the same machines each time.
<ogra> yes
<lamont> one could almost suspect that it's not exactly workload related
<ogra> and i have a feeling that its either related to dove builds or to kubuntu ... it seems to have started when NCommander enabled either
<ogra> and they were enabled around the same time
<ogra> sycamore is rather rarely affected and doesnt build dove or kubuntu images atm
<persia> Do we know when it crashes, or what it was doing when it crashed?
 * ogra doesnt, i dont get a long and usually only notice it once the machine is gone 
<ogra> s/long/log/
 * NCommander runs
<NCommander> Its not my fault it broke! :-P
<lamont> ogra: acorn is up...
<ogra> thanks
<lamont> heh.  up 33 minutes
<ogra> oh
<lamont> I suspect someone cycled it
<ogra> i tried a build about 1h ago :)
<lamont> persia: sadly, it is opaque in that regard
<lamont> we know that it does not spew upon the serial console during its death throws
<NCommander> lamont: you have console debug messages on?
<lamont> NCommander: and I stuff what where to get that?
<NCommander> lamont: huh?
<persia> syslog config, I'd think.
 * NCommander kicks stuff
<lamont> <NCommander> lamont: you have console debug messages on? <-- how turn on console debug messages?  IO
<lamont> I'm betting either printk foolery in sysctl.conf
<NCommander> lamont: remove quiet from the command line and add verbose ;-)
<persia> Oh, heh.
<lamont> heh. ok
<lamont> NCommander: and then reboot, I bet. :-p
<lamont> I'll do that later today
<NCommander> lamont: acord is omap4, right?
<lamont> they're all bbg3
<lamont> we have nothing else online
<NCommander> lamont: ah, acorn realized it was building the competition and committed suidice!
<ogra> NCommander, acorn is omap3 and dove
<ogra> sycamore is omap4
<ogra> (target wise)
<ogra> *and* we dont build kubuntu for omap4 yet
<ogra> so acron is omap3/dove for ubuntu-netbook and kubuntu currently
<ogra> dove and kubuntu were both enabled at a similar time
 * ScottK would say that at work Kubuntu or Dove exposed an existing problem.  I don't they either actually "caused" a problem.
<ogra> yeah, i didnt say they case one :)
<ogra> *cause
<ogra> we just dont see it on sycamore which onyl builds ubuntu-netbook-omap4 currently, it might as well be just a load issue or something
<lamont> except that they all serialize, so you're only ever building one
<lamont> I suppose you could trade roles and see if sycamore starts faceplanting
<ogra> i could do that but we have an agreement to keep one buildd exclusively for omap4
<ogra> though i dont really expect it to be caused by dove ubuntu builds they are 98% identical to omap3 or 4 (just different kernel packages being unpacked)
<ogra> that shouldnt cause more load or anything, whereas kubuntu builds install a completely different set of packages
<ogra> it would be good to know the exact time it dies
<ogra> then we could easily verify against the crontab
<lamont> 1 hr 9 min 20 seconds ago
<lamont> or as much as 5 min before that..
<ogra> very very weird
<ogra> it should have been idlin at that time
<ogra> *idling
<ogra> 55 1 * * *      ARCHES='armel+omap armel+omap4' OPTIONS="-f ext3" buildlive ubuntu-netbook && ARCHES='armel+omap armel+omap4' for-project ubuntu-netbook cron.ports_daily-preinstalled
<ogra> 13 3 * * *      ARCHES='armel+omap armel+omap4' OPTIONS="-f ext3" buildlive kubuntu && ARCHES='armel+omap armel+omap4' for-project kubuntu cron.ports_daily-preinstalled
<ogra> oh, my copy was outdated
<ogra> there is 45 6 * * *      ARCHES='armel+omap armel+omap4' OPTIONS="-f ext3" buildlive kubuntu-mobile && ARCHES='armel+omap armel+omap4' for-project kubuntu-mobile cron.ports_daily-preinstalled
<ogra> NCommander, why the heck are we building all these omap4 targets ?
<ogra> (i'm pretty sure i asked you not to)
<ogra> bah
<ogra> the crontab in the branch *totally* differs from the actual one
 * ogra sighs deeply
<ogra> so kubuntu-mobile is actually the last thing we build, starting at 6:45
<ogra> and according to http://cdimage.ubuntu.com/kubuntu-mobile/ports/daily-preinstalled/20100908/ they finished today at ~8:00
<ogra> so it was actually idle when it died
<ogra> lamont, are both systems identical software wise (same cron-daily entries etc) ?
<ogra> i wonder if its a system cronjob that makes it die
<lamont> as far as I know, yes
<lamont> sigh. brainfart.  that was when the machine was rebooted.
<lamont> I'll be able to give you a time the next time it dies...
<NCommander> ogra: ?, how does it diff, last time I updated the cron, it matched bzr 100%
<ScottK> I'd appreciate it if someone else on the release team would have a look at Bug #631413.  They are reasonably ready to push an upload and IME it's demonstrably better than what we have now, but I'm hardly dispassionate on the question.
<ubot4> Launchpad bug 631413 in mesa (Ubuntu) "[FFe] Mesa 7.9 (affects: 4) (heat: 26)" [Undecided,New] https://launchpad.net/bugs/631413
#ubuntu-release 2010-09-09
<lamont> skaet: I'm planning to roll new tarballs tonight and deploy them tomorrow morning, fyi
<lamont> the dst-upgrade in the chroot is getting kind of silly
<ScottK> slangasek: What are your thoughts on bug 631413?
<ubot4> Launchpad bug 631413 in mesa (Ubuntu) "[FFe] Mesa 7.9 (affects: 4) (heat: 26)" [Undecided,New] https://launchpad.net/bugs/631413
<skaet> lamont,  thanks for the head's up.
<slangasek> ScottK: I'm very nervous about it, mesa changes can easily contribute to hardware-specific regressions that go unnoticed
<lamont> new maverick chroot tarballs going live
<lamont> now if only there were pending i386 builds
<lamont> skaet / slangasek : there should be a lucid-proposed upload of apt_0.7.25.3ubuntu9.3 waiting for approval... could you accept that pls>?
<ScottK> slangasek: I know, but so far the worst test result I've seen is "No change".
<ScottK> For me it's the difference between compositing on every machine in my house or none of them.
<slangasek> ScottK: hem, point
<slangasek> lamont: looking now
#ubuntu-release 2010-09-10
<ScottK> skaet, robbiew, ttx: FYI, clamav will need update before release.  I'm not going to bring it up in the release meeting itself because it involves an embargoed security issue.  We might make it by final freeze, but it might have to go in a bit later.
<ttx> ScottK: ack
<skaet> ScottK, ack.
<robbiew> ScottK: thanks for the heads up
<skaet> ScottK,  is there a bug number associated with it?
<ScottK> Just a moment.
<ScottK> Bug #625849 - but I doubt you'll be able to see it.
<ubot4> ScottK: Bug 625849 on http://launchpad.net/bugs/625849 is private
 * ScottK can only see it because he reported it.
<skaet> Thanks.  :)
<charlie-tca> any chance of getting the fsck back in the recovery menu?
<cjwatson> /usr/share/recovery-mode/options/fsck still seems to be there ...?
<cjwatson> dropped in karmic, restored in lucid, no changes in maverick
<cjwatson> it triggers it on the next reboot, to avoid problems with some services running in single-user mode
<charlie-tca> but it doesn't show up if I go to the recovery mode menu
<charlie-tca> It helps to be able to have the user run it manually sometimes
<ScottK> skaet: One thing that I don't recall coming up during the meeting is Ubuntu theme updates.  I recall seeing some discussion on the Ayatana ML that an update was prepared and aimed Maverick.
<ScottK> robbiew: ^^^
<robbiew> hmmm...I wasn't aware of it, but that doesn't mean it's not a possibility
<ScottK> robbiew: Also discussed in #ayatana ~ 5 or 6 hours ago.
<robbiew> ok
<skaet> ScottK, Thanks for the heads up.
<ScottK> You're welcome.
<iulian> ScottK: Mail sent.
 * iulian wonders if he missed something.
 * ScottK looks
<ScottK> iulian: Looks good.  Thanks.
<iulian> Excellent.
#ubuntu-release 2011-09-05
<kees> micahg: i imagine if it's not new to the package. which package?
<micahg> kees: various xfce related packages
<jamespage> morning - please could I get an OK from the release team for bug 837990 and 837979 - thanks
<iulian> jamespage: Looking.
<iulian> jamespage: You should've subscribed -release to the other 2 bugs as well.
<iulian> Oh, those are bug fixes, nevermind.
<iulian> jamespage: Looks good, please go ahead and get them in.
<jamespage> iulian: ack - and thanks for reviewing
<iulian> micahg: What is the status of bug 836324?
<micahg> iulian: haven't had time to test yet, I don't see it being any worse than what's currently in the distro though and fixes multiple RC bugs from Debian
#ubuntu-release 2011-09-06
 * Laney is testing importing the sync blacklist into dogfood
<Laney> http://people.ubuntu.com/~laney/sync-blacklist.new.txt
<Laney> http://people.ubuntu.com/~laney/import-blacklist.py http://people.ubuntu.com/~laney/sync-blacklist.py
<Laney> please excuse my python
<tumbleweed> probably better than my haskell / mono :P
<tumbleweed> Laney: launchpadlib knows how to deal with _link
<tumbleweed> comment_author = comment.comment_author.name
<Laney> oh
<Laney> i did it like that because when i tried ot call.name on it to print it out I just go tthe whol elinkdd
<Laney> lag
<Laney> silly microwave
<nigelb> IRC-ing from a microwave?
<Laney> it's warm in here
<tumbleweed> Laney: python also has builtin for filtering: comment_text = [c for c in comment.body_text.splitlines() if c and not c.startswith("Ignored")]
<Laney> is that better than using filter?
<tumbleweed> I think it's faster in some cases, but also more readable (filter isn't used much in modern python)
<tumbleweed> obviously nothing wrong with what you had :)
<Laney> in haskell that's [ c | c <- comment.body_text.splitlines(), c, not c.startswith("Ignored") ]
<Laney> but filter is also very common
<Laney> that's why I was more than happy to use it
<Laney> thank fuck i havent had to do any of that
<Laney> erm, excuse me
<Laney> . o O ( seriously, /one day/ I will figure out how to disable the x clipboard )
<tumbleweed> Laney: the current blacklist has comments at the top of blocks of packages, it doesn't look like you import those
<Laney> correct
<Laney> I didn't fancy complicating it much more, thought it would be easier to just copy them down
<Laney> patches welcome etc
<tumbleweed> my one in is_blacklisted does, if you want an example
<Laney> there were also missing DSDs on dogfood, but I didn't see the same on production
<Laney> so some stuff couldn't be blacklisted at all
<tumbleweed> yeah, the copy of lp data is ancient
<Laney> your stuff looks applicable. fancy integrating it?
<tumbleweed> oh, all right :P
<Laney> :-)
 * Laney has to do Real Workâ¢ for a bit
<tumbleweed> Laney: http://people.ubuntu.com/~stefanor/tmp/
 * Laney didn't know about current_series
<Laney> good work
<Laney> you could make that change in sync-blacklist too
<Laney> tumbleweed: do you think we should start using this now?
<Laney> or at least import the data into production
<tumbleweed> Laney: remaining issue I see is determining which comment is the blacklist reason, and I don't think there is any way to do that (which is why we are using all the comments, everywhere)
<Laney> right, that's a launchpad presentation thing
<tumbleweed> cjwatson said he wanted to manually check the list when importing, to remove the mismatched-tarballs, as they don't need to be imported if the sync tool can detect them
<Laney> yep
<Laney> whoever runs the script can sanity check the input
<tumbleweed> I don't know what else is impacted by the blacklist. mom?
<Laney> if we keep on generating it for now from launchpad then old stuff will keep working
<tumbleweed> yup
<Laney> apart from things which are removed for the import
<tumbleweed> they can be statically added to the export, if necessary
<cjwatson> probably won't be necessary; I don't expect to use sync-source -a again
<tumbleweed> any progress on the new mass sync tool?
<Laney> cjwatson: want to take a look at running http://people.ubuntu.com/~stefanor/tmp/import-blacklist.py ?
<jdstrand> ScottK: hi! I'd like to sync rails from Debian for a security update. Daviey tells me this is desirable from the server team's perspective as well. is this ok?
<cjwatson> Laney: not today, but could you mail that to me and I will?
<cjwatson> tumbleweed: not yet, expected later this week though
<jdstrand> ScottK: (bug #842667)
<Laney> k
<ScottK> jdstrand: Go for it.
<jdstrand> ScottK: thanks!
<Daviey> Hmm, Server ISO hasn't been built since beta.. Can someone flip the switch please?
<cjwatson> wonder why it was commented out
<cjwatson> uncommented
<cjwatson> and running a build for you now
<Daviey> cjwatson: Ah, thanks!  Just noticed.
#ubuntu-release 2011-09-07
<Daviey> Hmm, is the archive wedged in Update-in-Progress?
#ubuntu-release 2011-09-08
<micahg> does a new binary package (-dbg) need a freeze exception?
<ScottK> Yes.
<micahg> thanks
<skaet> cjwatson, good morning, on the daily CD report, there are a lot of amd64 packages suddenly producing uninstallable binaries.  Is root cause known?
<cjwatson> skaet: those are usually transient; I haven't checked in this case
 * cjwatson runs daily-checks --stdout since he's deleted that mail
<skaet> cjwatson,  :) have forwarded the email to you.   Will be curious to see what the current daily-checks produces and compare.
<cjwatson> skaet: webkit built a bit sooner on amd64 than on i386 (https://launchpad.net/ubuntu/+source/webkit/1.4.3-0ubuntu1), and libwebkitgtk-1.0-0 depended on a newer libwebkitgtk-1.0-common which is architecture-independent and only built on i386
<cjwatson> skaet: didn't need a forward :)
<cjwatson> the current daily-checks says nothing different because CDs haven't rebuilt
<cjwatson> skaet: anyway, it was transient and will go away with the next build
<skaet> cjwatson, coolio.  That makes sense.   Thanks!
<cjwatson> FWIW I normally don't worry much about single-architecture spikes in the output unless (a) we're almost at a milestone or (b) they persist for more than one day
<skaet> thanks.   Will keep that in mind.
<cjwatson> unless both amd64 and i386 fail, in which case it's probably a real problem
 * skaet nods
<cjwatson> ha!  fix for the grotty octave-symbolic NBS coming up.
<jamespage> please could I get a release team OK for https://bugs.launchpad.net/ubuntu/+source/tomcat7/+bug/844745
<ubot4> Launchpad bug 844745 in tomcat7 (Ubuntu) "[FFE] Sync tomcat7 7.0.21-1 (universe) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New]
<jamespage> ta
<jdstrand> if someone could ping me on ^, I'll do the sync
<ScottK> Great.
<Laney> How is it decided which bugs are milestoned?
<Laney> .
<ScottK> I developer decides it should be milestoned and does it.
<ScottK> I/A
<Laney> OK, didn't know if it needed Official Seals of Approval or anything. Ta.
<Laney> how come we don't have a beta freeze for B2?
<cjwatson> isn't that within final freeze?
<cjwatson> oh, huh, no, that got moved
<cjwatson> um
<cjwatson> skaet: ^-- we probably ought to have at least a few days there
<Laney> 15th would be in line with B1
<Laney> but that's rather close to now I guess
<cjwatson> things should be slowing down anyway ...
<skaet> cjwatson, Laney - hmm,  that's an oversight, the intention was that it would be 1 week before B2 (ie. 15th).   I'll clarify that in the release meeting tomorrow.
<Laney> Adding it to the wiki and letting people know would be a good idea.
<seb128> skaet, cjwatson, pitti: GNOME 3.1.92 is on the 19th
<seb128> would that still be ok to get in beta2?
<skaet> seb128,  ouch, that timing is too tight.   Probably not, unless everything else is looking smooth.
<seb128> skaet, ok, it means we will have to deal with the 3 weeks of bug fixes to land after beta2
<seb128> and test non current versions
<seb128> which is a bit of a shame...
<seb128> like most beta-2 bug will probably be useless for GNOME
<skaet> seb128,  hmm.   good points, any way the bug fixes applied up til beta freeze can get cherry picked in?  (ie. pull in the candidate for 3.1.92?)
<skaet> any down sides?
<seb128> we could
<seb128> it just mean we would have to cherry pick some hundred commits
<seb128> it's weeks of work
<seb128> or we can probably git snapshot half of GNOME next week
<seb128> to update again after beta2
<seb128> knowing that I'm on holidays next week so let's see what the other guys can do
<skaet> seb128,   ok, lets see if someone can pick up the snapshot,  otherwise, lets see where we are on the 19th.
<charlie-tca> I wonder how much of Xubuntu those gnome upgrades will break this late?
<skaet> Am worried about not having enough time to recover if there is an interaction with other components,  so close to the beta2.   On monday we should have the first set of candidate images, and if they're usable, maybe look at taking the risk.
<seb128> skaet, well, GNOME is feature frozen, ui and string frozen
<seb128> skaet, so those updates will just be some weeks of bug fixing
<seb128> we really need to revisit the schedule next cycle to have something which work compared to GNOME, if we can't get .92 in beta2 it will cost us on beta2 quality and usefulness of the feedback we will get since the bugs that we will receive might be fixed already and we will miss new ones
<skaet> seb128,  understood, but if there are 100's of commits coming in, unexpected interactions from someone's fix, with someone else's workaround might occur.
<skaet> ie. one of the gnome fixes, might snag up one of the interfacing components.   May not, but may.
<ScottK> Right, but is it better to find that out before beta 1 or after?
<skaet> ScottK,  Very much would like it before, but don't want to risk not having images we can ship either.   And this could be an image breaker/non recoverable.
<ScottK> IIRC it doesn't take that long to get a Gnome release built.
<ScottK> I think there should still be time to manage.
<seb128> we would get things in and built on monday
<skaet> If .92 lands on monday,  it will get built into images on Monday night.  Issues will be noticed on Tuesday testing, interaction debugging could be ??.  Last set of fixes would need to be figured on on Wednesday for those affected, and put into builds on Wednesday night and tested Thurs morning.  It would be a repeat of the Beta 1 cycle.
<seb128> we did that for quite some cycles, it usually works fine since GNOME freezes tend to be solid and the updates at the end of the cycle stable
<seb128> well, other option is to wait after beta2
<seb128> we will not likely update GNOME on a friday
<seb128> which means we would start testing those one week later
<seb128> and get non useful feedback from beta2
<ScottK> Then if there's problems you've lost a week and upstream says "You were using an old version, try again"
<seb128> then we need to test the new version, get feedback on those, start seing issue
<dblawson> I'm putting the buildd's on manual for a package bootstrap
<skaet> If we have a fall back set of images created on monday morning that test out okay - we could look consider it.
<seb128> we loose a good 10 days of work if we go this way
<ScottK> dblawson: You aren't killing existing builds are you?
<dblawson> ScottK: Nope
<skaet> seb128,  we could get much of the same benefit though by taking a snapshot, and then refreshing too though.
<ScottK> OK.  Good.
<ScottK> skaet: Not really.  You still end up with upstream telling you to retry with the current version.
<Laney> For useful testing, you really want people to be running the latest version
<skaet> the current version will be in the daily images on the 23rd,  so we'll see pretty quickly, if the issue is there.
<seb128> skaet, yeah, out of the fact that rather than packaging the tarballs they will test and roll we will have to do snapshots ourselves next week
<seb128> but as I'm not sure next week so I will let pitti and other decide and see what they can do
<skaet> I do understand your points though.   Want to do some more digging to see if there are some options to increase the likelyhood of shippable images.   Lets revisit tomorrow at the end release meeting.
<seb128> ok
<pitti> skaet: we could also update the apps on monday (which wouldn't lead to complete image failures), and do snapshots of the base libs like glib/gtk before
<skaet> thanks for bringing it up seb128.   Very much appreciate it being on the radar now, rather than on the 19th ;)
<Laney> it would be good to have a calendar that shows all major upstream cycles for products on the images
<skaet> pitti,  yeah something like that might be worth trying.
<pitti> GNOME and KDE release are special enough for us to justify adding it to our existing release interlock pages?
<skaet> Laney, https://wiki.ubuntu.com/OneiricReleaseInterlock
<skaet> pitti, yeah,  I think we shold add them to the interlock page.
<Laney> skaet: yes, like that but with upstreams
<skaet> Laney - last column.
<micahg> skaet: do you want the same for Mozilla now that they have a schedule?
<Laney> doesn't look particularly complete
<Laney> only shows gnome final for example
<skaet> micahg,  adding in Mozilla on the interlocks would be good.
<dblawson> Done, buildd's are back to auto
<micahg> chrisccoulson: ^^ could you handle that
<skaet> Laney,  yeah its not as complete as it should be,  but if we get in the habit of adding them, it makes it easier to remember to look for them for the next cycle too.
 * skaet encourages everyone who is aware of an upstream date that's significant to add it there. 
<ScottK> Given the early October release date, the last KDE date of significance was probably last Monday, but I'm double checking.
<ScottK> Err, Tuesday.
<skaet> thanks ScottK
<chrisccoulson> am i ok to edit https://wiki.ubuntu.com/OneiricReleaseInterlock then, to add the Mozilla dates
<chrisccoulson> ?
<micahg> chrisccoulson: yeah, skaet said that was a good idea
<ScottK> skaet: I added the KDE 4.7 dates to the Oneiric interlock schedule.  Ask expected, release is a week too early for us to get 4.7.2.
<chrisccoulson> pk, done
<chrisccoulson> **ok
<ScottK> skaet: Here's the link for KDE 4.8 to use for planning for "P".  It would be REALLY nice to be able to get 4.8.2 in at relase, which would require release April 19 or the next week.
<ScottK> http://techbase.kde.org/Schedules/KDE4/4.8_Release_Schedule
<chrisccoulson> skaet, if you ping me when you have a P equivalent of https://wiki.ubuntu.com/OneiricReleaseInterlock, then I can give you the next 6 months of Mozilla release dates ;)
<skaet> Thanks for adding them ScottK.    Will be doing a scrub on the P schedule early next week,  then cloning it into the PReleaseInterlock, so seeing how things lay out will help with tuning.
<skaet> chrisccoulson, will do.  :)   Thanks
<stgraber> skaet: hi! bug 575469 has been targeted for beta2. I now have a fix for it but it's a pretty substential change to friendly-recovery and minimal changes to a bunch of other packages.
<ubot4> Launchpad bug 575469 in newt (Ubuntu Oneiric) (and 3 other projects) "[UIFe] [FFe] recovery mode mounts filesystems read-write rather than read-only (affects: 2) (heat: 12)" [Undecided,Invalid] https://launchpad.net/bugs/575469
<stgraber> skaet: I'm currently waiting for some reviews of the changes before actually subscribing ubuntu-release for the exceptions
<skaet> stgraber, thanks for the head's up.   Yeah,  lets make sure the other component reviewers are happy before this lands.  Timing is ok as long as the others affected are comfortable with the changes.
<utlemming> Hi, can I have a reviewer approve a byobu change that fixes https://bugs.launchpad.net/ubuntu/+source/byobu/+bug/844994?
<ubot4> Launchpad bug 844994 in byobu (Ubuntu Oneiric) (and 1 other project) "byobu initialization is slow KVM cloud-images (affects: 1) (heat: 6)" [High,Fix committed]
<ScottK> utlemming: It's a bugfix, so no release team review is needed.
<ScottK> Talk to kirkland about when he plans to upload it.
<utlemming> Scott: okay, thank you kindly
<kirkland> utlemming: thanks, will upload shortly
#ubuntu-release 2011-09-09
<jamespage> hello - do I need a FFE to get a package removed from the archive?  I need todo some re-jigs first but euca moving out of main means I can do a bit of housekeeping...
<doko> jamespage, which one?
<jamespage> doko: libcommons-fileupload-java-universe - libcommons-fileupload-java is now in universe so we can drop the -universe version and restore its full feature set with a sync from debian
<jamespage> doko: Documenting here - https://bugs.launchpad.net/ubuntu/+source/libcommons-fileupload-java/+bug/845541
<ubot4> Launchpad bug 845541 in solr (Ubuntu) (and 5 other projects) "Remove libcommons-fileupload-java-universe from the Oneiric archive (affects: 1) (heat: 8)" [Undecided,New]
<doko> jamespage, once it's not built anymore it will show up in NBS
<cjwatson> removals don't typically require FFEs anyway, no
<doko> pitti: FFE above ^^^
<doko> so, is ubuntuone-couch now wanted in main?
<pitti> jamespage: this sounds fine, removing duplicate sources is really cleanup and not a feature
<jamespage> pitti: OK - but I do need a couple of FFE's to support this removal - re-syncs from Debian
<jamespage> testing and documenting ATM
<pitti> doko: it's an rrecommends of deja-dup, so I guess yes
<doko> pitti, but we did move the rest out of main ...
<pitti> doko: did we?
<pitti> I thought it's back
<pitti> U1 really ought to be in main
<pitti> desktopcouch, ubuntuone-client etc. are all in main
<doko> insighttoolkit built on powerpc, five more days now on armel ...
<pitti> that's bigger than kernel and LibO together, isn't it?
<pitti> must be a helluva tib
<pitti> s/tib/lib/
<doko> ahh, bug 844995
<ubot4> Launchpad bug 844995 in python-couchdb (Ubuntu) (and 4 other projects) "Archive demotion to universe (affects: 1) (heat: 12)" [Undecided,New] https://launchpad.net/bugs/844995
<doko> pitti: couchdb, not ubuntuone
<doko> pitti: thanks for taking the ladvd ftbfs ;-P
<pitti> doko: two tests fail, they look a bit weird (it's trying a chroot() call); if they fail on the buildds as well, I'll have a closer look
<pitti> gearmand built fine here, so I synced Debian's version as there is no delta any more
<pitti> and I removed python-event; FUBAR, and no rdepends
<doko> pitti, they did
<pitti> that should take care of the libevent-1.4-2 ones
<pitti> doko: ah, interestingly the chroot() one passed on the buildds
<pitti> so I'll examine the http one
<pitti> doko: BTW, I followed up to the ptlib/opal bug, asking for other release team member opinions; either we update the whole stack or remove them all
<cjwatson> I'd rather not have to remove ekiga frankly
<pitti> me neither
<cjwatson> it may be a bit weird and shonky sometimes but it's definitely used
<pitti> I had used it for years without much problem
<pitti> these days I prefer empathy, but according to the changelog it's still quite alive
<pitti> I just don't feel unbiased enough any more to say "let's update it all"
<tumbleweed> sorry I totally dropped the ball on that, thanks for looking at it. It looked like updating the whole stack would do the trick
<pitti> tumbleweed: yes, I followed up there some hours ago; it took the better part of my morning, but I have all packages ready for upload now
<ScottK> It would be good to have Daviey check out the asterix aspect of it.
<pitti> the main risk here AFAICS is breakig asterisk due to the new spandsp
<ScottK> Fortunately we know someone who's very familiar with the package.
<pitti> that version is in unstable, of course, so I'd think that asterisk breakage would have been detected there
<pitti> but better checking twice at this point
<doko> jamespage,  libcommons-fileupload-java synced
<jamespage> doko: thanks
<jamespage> hrm - although I think that needed a FFE ack from ubuntu-release as its a minor version upgrade
<jamespage> plus it generates a new -java-doc package for the API documentation which is now in NEW
<cjwatson> jamespage: you only need an FFE if there are new features in that minor version upgrade, not just because of the version change
<doko> jamespage, hmm sorry, had the impression pitti had given one
<jamespage> cjwatson: ah-ha - I missed that point of detail - thanks for clarifying
<cjwatson> pitti: non-binding opinion :-) added to the bug
<jamespage> doko: so that sync was OK - my mistake
<cjwatson> (as in, probably worth giving other people a chance to respond)
<jamespage> doko: with that new nugget of information I don't believe the minor version upgrade to libspring-java needs an FFE either - great
<jamespage> well at least I tested it well and learn't something new today :-)
<pitti> cjwatson: *nod*
<doko> pitti: is calling dpkg-gensymbols -c4 really a good idea for an 48h building package like webkit?
<pitti> well, wasn't my idea :) but in general I do -c4 in my packages as well
<cyphermox_> fyi, I'd like to upload the release tarballs of 0.9.0 for the different vpn plugins (vpnc, openconnect). They are all just bugfix. mostly making sure all strings are translatable (the translations should already be available, just not getting used in code)
<cyphermox_> openvpn needs an update too bug that one will get a UIFE, since there is one extra combo
<ScottK> lamont: Are you around?  I've got a problem that might need some of your help to diagnose.
<lamont> bah
<lamont> I mean, wassup?
<ScottK> Hi.
<ScottK> kde-runtime FTBFS because patches wouldn't unapply.
<ScottK> It works fine for everyone locally.
<lamont> neat
<ScottK> Tried the same package in a PPA an it magically built on i386, but failed on amd64.
<lamont> bzr branch lp:~lamont/launchpad-buildd/chroot-scripts; chroot-scripts/make-chroot.sh -d oneiric --lp
<lamont> that is most strange
<ScottK> So I was wondering if you had some way to capture the debris of the build and examine it's entrails?
<lamont> not trivially
<lamont> and certainly not expostfacto
<ScottK> Right, but if you were prepared, we could retry it.
<ScottK> I'll suggest someone try to replicate it with your sbuild branch first.
<lamont> that branch just gives you a launchpad build-chroot as it should exist after dist-upgrade
<ScottK> OK.
<ScottK> If you get bored, the PPA version of the 'bad' thing in question is https://launchpad.net/~kubuntu-active/+archive/ppa/+sourcepub/1932597/+listing-archive-extra
<lamont> ok.  I see boredom coming sometime in 2040 at this rate
<ScottK> OK.  Just checking.
<lamont> ScottK: if it's still not solved on monday, poke me and we'll figure out a time (prolly wednesdayish) to work on it
<ScottK> lamont: Thanks.
<skaet> lamont,  is there an ETA on https://bugs.launchpad.net/ubuntu/+source/gradle/+bug/796769
<ubot4> Launchpad bug 796769 in gradle (Ubuntu Oneiric) (and 1 other project) "gradle needs a manual build using the unstable binaries (affects: 2) (heat: 12)" [High,Confirmed]
<skaet> ?
<micahg> skaet: re firefox for beta 2, chrisccoulson and I were discussing yesterday with upstream, it seems that we'll be shipping the final beta for Firefox/Thunderbird 7 for beta 2 and uploading the release builds once the freeze is lifted (Firefox/Thunderbird 7 final is what oneiric will hopefully ship with)
<micahg> should be minimal if any changes from final beta to release
<micahg> skaet: did you miss my notes before?
<skaet> micahg, yes, appear to have.   Changing rooms at the conference.
<lamont> skaet: deej bootstrapped it yesterday
<micahg> ah, well, this can wait till, monday, but wanted to give you a heads up
<micahg> [12:22] <micahg> skaet: re firefox for beta 2, chrisccoulson and I were discussing yesterday with upstream, it seems that we'll be shipping the final beta for Firefox/Thunderbird 7 for beta 2 and uploading the release builds once the freeze is lifted (Firefox/Thunderbird 7 final is what oneiric will hopefully ship with)
<micahg> [12:23] <micahg> should be minimal if any changes from final beta to release
<lamont> skaet: all of which is to say "I have no clue why the bug should have been assigned to me"
<skaet> lamont,  it was one of a set from a while back.   entropy I imagine.   If deej has done it,  would be good if the status can be updated.  :)
<lamont> yeah, I'll go kill the bug
<skaet> lamont,  Thanks!
<lamont> no worries.
<skaet> micahg,  thanks for the head's up.  When will the version for beta 2 be landing?
<lamont> skaet: as a heads up, syowa is going to retire early next week.  it has served us well as syncproxy.ubuntu.com these past 7+ years or so.
<micahg> skaet: chrisccoulson might have a better idea, my guess is either day before or day of beta 2 freeze
<skaet> lamont,  earlier is better than later in the week.
<lamont> skaet: that is a major point in why I'm not rushing to finish it today. :p
 * skaet trying to minimize opportunities for murphy around beta freeze.
<skaet> lamont,  :)  indeed.
<lamont> OTOH, the announcement to the mirror community will go out todayish, and I expect that "early" == tuesday
<skaet> lamont,  that should work out ok.  We have wednesday to recover then before beta freeze.  :)
<lamont> oh, it only affects things mirroring.  nothing big or anything. :(
<lamont> actually only about a dozen or two boxes where we don't have total control.
<lamont> OTOH, not replacing syowa is even worse in its expected consequences
<skaet> micahg:  thanks I'll follow up with you and chriscoulson on monday then.
<skaet> lamont,  starting to show its age, huh?
<lamont> that's a polite way to say it
<skaet> gotcha
<ScottK> lamont: I got the problem sorted.  It'd be nice if when dh_quilt can't unapply the patch it'd actually say that instead of just error in the build log.  Thanks for the offer.
#ubuntu-release 2012-09-03
 * infinity is finally home.
<stgraber> infinity: that was a long trip back home
<infinity> ogra_: That -lGL bit will fail on powerpc.
<infinity> stgraber: The bit where I was in hospital for a day slowed me down.
<stgraber> infinity: ouch, what happened to you?
<infinity> stgraber: Kidney stones.  Fun times.
<mdeslaur> infinity: ouch :(
<ogra_> infinity, why ?
<ogra_> no meas on ppc ?
<ogra_> *mesa
<infinity> ogra_: Err, no, you're only setting -lGL on x86_64 and i686
<infinity> ogra_: Whereas, previously, it was on all arches.
<ogra_> oh, right, whats the machine string for ppc again ?
<infinity> ogra_: You probably want NOT STREQUAL "armv7l" or something.
<infinity> ogra_: Since that's what you mean.  Listing every GL arch is silly.
<ogra_> what i want is "else"
<ogra_> but silly cmake doesnt have that
<infinity> ogra_: Better yet, not making it arch qualified at all, don't we already have a magic "using gles" flag we can test?
<ogra_> or the guarantee that one set overrides a former one
<ogra_> infinity, looking at the build it actually sets everything properly already i think its not needed at all
<infinity> They do override the former, except that it's being done in an additive fashion.
<infinity> And dropping -lGL and -lGLU entirely, if the flags are added elsewhere, is an even better option, yeah.
<ogra_> right, i was waiting for rsalveti's feedback for that one
<ogra_> my cmake hack is rather thought as a last resort
<infinity> if (${CMAKE_SYSTEM_PROCESSOR} STREQUAL "armv7l")
<infinity>     set (UNITY_STANDALONE_LADD "-lunity-core-${UNITY_API_VERSION} -lm")
<infinity> else ()
<infinity>     set (UNITY_STANDALONE_LADD "-lunity-core-${UNITY_API_VERSION} -lm -lGL -lGLU")
<infinity> endif ()
<infinity> ^-- From /CMakeLists.txt
<ogra_> fun
<infinity> Assuming UNITY_STANDALONE_LADD is used for the subproject, you can probably just ditch that bit from dash/previews/CMakeLists.txt
<ogra_> yeah, i wonder why they define it at all
<infinity> Though, it doesn't appear to be..
<infinity> Still this is all silly and fragile to be doing it based on uname and not a config flag. :/
<infinity> It should be based on BUILD_GLES
<ogra_> yep, but at least its consistently odd :)
<infinity> Which is defined.
<ogra_> yup ... like -fPIC that should be set based on defaults :)
<infinity> I'd just move that armv7l bit into the BUILD_GLES stanza that follows.
<ogra_> but i surely wont rewrite the unity build system tonight
<infinity> fPIC should just be the default, period.
<infinity> I'm sure the only reason it isn't is because they added it to fix a build failure on amd64, not realising that they really want it on all arches.
<ogra_> heh, take a look at any of the CMakeList.txt files in the unity tree
<infinity> Yeah, I'm looking right now.
<infinity> Silly.
<infinity> ogra_: http://paste.ubuntu.com/1182617/
<infinity> ogra_: Something like that should do.
<infinity> ogra_: (Not fixing the fPIC mess with that, just cargo-culting as you did)
<infinity> ogra_: But that should fix the linking issue.
<infinity> ogra_: Want me to test and push something along those lines?
<infinity> ogra_: It's pretty late for you. :P
 * infinity reapplies against the current version and tests.
<infinity> http://paste.ubuntu.com/1182627/
<infinity> ogra_: ^-- Testing that patch right now.
<ogra_> infinity, my testbuild with the first patch just finished
<ogra_> so at least there are no subsequent build issues
<infinity> ogra_: Alright.  well, I'm testing mine on all 5 arches.
<infinity> ogra_: If it seems happy, I think I'll upload it.
<ogra_> great
<ogra_> thanks so much ... i'll make Åukasz pay us a lot beers at UDS :)
<ogra_> though probably seb should pay half of it ... he was the actual uploader and signer
<infinity> Applying patch disable_standalone-clients.patch
<infinity> patching file CMakeLists.txt
<infinity> Hunk #1 FAILED at 156.
<infinity> 1 out of 1 hunk FAILED -- rejects in file CMakeLists.txt
<infinity> Patch disable_standalone-clients.patch does not apply (enforce with -f)
<infinity> ^-- Why the heck is that non-fatal?!
<ogra_> heh
<slangasek> infinity: because of the hand-hacked rules for coping with arch-specific series files, which should be taken out and shot?
<slangasek> (but most importantly, taken out)
<ogra_> on my TODO
<slangasek> I would suggest it be done now
<infinity> Yeah.  I suspect that patch isn't even necessary now.
<infinity> If this stuff all builds, then it clearly isn't necessary.
<infinity> Given that it DIDN'T APPLY ANYWAY.
<ogra_> yeah
<infinity> So, if this pass works everywhere, I'll drop that hunk of sad.
<ogra_> though it didnt apply because you edited CMakeLists.txt, no ?
<infinity> ogra_: No, it had nothing to do with my edits, unless this is the pickiest quilt ever.
<slangasek> well, either way, the directory referenced by that patch doesn't exist
<slangasek> so it should be dropped
<slangasek> and debian/rules sanitized
<infinity> Yeah, doing.
 * ogra_ isnt sure we should put that much cleanup worn in 
<ogra_> *work
<infinity> It's 5 seconds.
<infinity> And I've already done it. :P
<infinity> Plus, I'm on drugs.  CMake projects make sense right now.
<ogra_> i mean, the whole thing needs to be repacked from scratch anyway
<ogra_> non-native ... cleaned up etc
<slangasek> the non-native issue is orthogonal
<ogra_> well, if its done already ... *shrug*
<slangasek> and as infinity has just shown, the existing rules are so broken that they would prevent the package from FTBFS reliably if something comes un-stuck with this current fix.  Ripping out the bad code is definitely the right thing to do
<ogra_> true
<ogra_> anyway, 3am ... i'll crawl towards my bed ...
<ogra_> what a weekend ...
<slangasek> ogra_: 'night... :)
<shadeslayer> infinity: thanks for fixing telepathy qt
<infinity> slangasek: I had a bit of an accidental nap while testbuilding, unity's uploaded now. :P
<rsalveti> infinity: I'm testing the same patch now
<rsalveti> infinity: the older one that is part of the specific rules can also be gone
<rsalveti> which helps if you want to remove the hack at rules
<rsalveti> another thing that I just changed as well is removing the dependency on gcc-4.6
<rsalveti> as it's not needed anymore
<infinity> rsalveti: I removed the patch and the arch-specific patch hack completely.
<rsalveti> cool
<infinity> rsalveti: I didn't drop the gcc build-dep, I'll let that wait until post-beta.
<infinity> rsalveti: My diff: http://launchpadlibrarian.net/114595044/unity_6.4.0-0ubuntu3_6.4.0-0ubuntu4.diff.gz
<rsalveti> infinity: why is this a native package
<rsalveti> ?
<infinity> rsalveti: I'm sure more cleanup could be done (like -fPIC for all arches, for instance), but this was a minimal "make it work" thing.
<rsalveti> sure
<infinity> rsalveti: No idea why it's native, not going to switch/fix that for them today. :P
<rsalveti> I just dropped the gcc because I was using icecc to build
<rsalveti> and it was forcing gcc-4.6, which was then skipping icecc
<infinity> shadeslayer: NP.
<rsalveti> infinity: yup, just installed and it worked fine
<rsalveti> infinity: so this patch is good to get it all working
<rsalveti> and it's quite fast I must say, just missing the kernel fix to avoid the flickering, which we'll try to fix after b1
<rsalveti> and, built fine with gcc-4.7 for amd64 and armhf
<rsalveti> so we can drop it later on
 * infinity drugs himself up and goes back to bed.
<ScottK> infinity: Thanks for taking care of telepathy-qt.
<infinity> ScottK: Want to review and accept that unity in the queue as compensation? :)
<infinity> ScottK: (Test-built it on all 5 arches here, seems good)
<ScottK> Depends on how long I last before I time out.  I've been offline all of today and most of yesterday, so I have a pile of stuff in the queue.
<stgraber> infinity: accepted
<stgraber> debdiff looks reasonable and matches what I've read on IRC today. Hoping that one will finally work for everyone...
<pitti> hello
<pitti> does anyone from the release team happen to be awake?
<pitti> I'd like to discuss postgresql-9.1
<Mirv> infinity: can you do a merge request of your CMakeLists.txt changes against lp:unity at some point so that the changes don't get forgotten?
<slangasek> ogra_: unity runs for me now \o/ but it seems to flicker a lot; have you seen this?
<pitti> slangasek: got a minute for discussing postgresql-9.1?
<slangasek> pitti: hmm, I can try :)
<pitti> so, I uploaded 9.1.5-2 to unapproved last Friday with two bug fixes that are milestoned for b1
<pitti> I didn't get an IRC response or review, so I re-synced the same thing into quantal-proposed where it built
<pitti> slangasek: -2 is still in the unapproved queue and shoudl be rejected, but I kept it to provide the queue diff for the -release review
<pitti> slangasek: I'd recommend getting this in, as it fixes upgrades from precise which we hope to get testers for
<pitti> so if I get a +1, I can reject the unapproved upload and copy -proposed to quantal
<Laney> yay, unity
<iulian> Can I accept those syncs from unapproved if I'm happy with them?
<slangasek> pitti: ah, I reviewed it and accepted before seeing the last comment
<Laney> iulian: yeah
<iulian> OK.
<Laney> using 'queue' is preferred to the web UI, although I forget exactly what the UI does wrong
<pitti> slangasek: oh, does that even work? the same versino is already in -proposed, after all?
<slangasek> pitti: sorry, I meant I copied from -proposed
<pitti> slangasek: ah, c'est parfait
<pitti> slangasek: merci
<iulian> Laney: Yup, I've been teaching myself how to use those tools. Well, just queue and queuediff.
<cjwatson> The only thing the web UI does desperately wrong is that it doesn't present binary overrides sensibly
<cjwatson> It's fine to use it for accepts and such
<Laney> one thing I did have to use it for is to reject one copy of the same (source, version)
<Laney> how do I do that with queue?
<cjwatson> reject by ID
<cjwatson> queue reject <seven-digit-number>
<cjwatson> which you can get from queue info
<Laney> ah, that works, cool
<cjwatson> For the experimental freeze a while back I asked people to use the API client because we were specifically testing that
<cjwatson> But that wasn't a long-term prescription or anything
<cjwatson> That said I personally prefer using the client
 * Laney switches default_milestone
<Laney> pitti: will you copy postgres over?
<pitti> Laney: slangasek already did
<Laney> hm, I don't see it
<pitti> https://launchpad.net/ubuntu/+source/postgresql-9.1/+publishinghistory
<Laney> oh, +pu
<Laney> yeah
<pitti> not published yet
<Laney> the version page doesn't
<Laney> cheers
 * Laney disables cronned builds
<iulian> Hmm, no queuebot?
<iulian> Is there a log somewhere I can look at to see who did what?
<Laney> not sure how far along queue audit is
<Laney> there's certainly been some work on it
<Daviey> I don't believe there is anything of use right now.
 * iulian nods.
<Laney> https://bugs.launchpad.net/launchpad/+bug/885739
<ubot2`> Ubuntu bug 885739 in launchpad "queue and override manipulations should have an audit trail" [High,In progress]
 * iulian looks.
<cjwatson> StevenK has been working on an auditor interface, much of which has landed, but I have no idea how to get at the audit logs
<cjwatson> cyphermox: would it be possible to resolve the evolution-related items on http://people.canonical.com/~ubuntu-archive/nbs.html before beta, at least those in main, preferably without taking a whole new upstream of the evolution stack?  I tried rebuilding evolution-exchange but it FTBFS ...
<iulian> Nice.
<cjwatson> cyphermox: everything I've tried there so far dies with direct-inclusion errors
<Laney> someone was porting -exchange
<Laney> perhaps it was cyphermox, but something in my head is telling me chrisccoulson
<chrisccoulson> it wasn't me :)
<Laney> Riddell: ScottK: Should we be building kubuntu active for B1?
<seb128> cjwatson, re evo, those are non trivial, the upstream apis had quite some changes
<seb128> cjwatson, we should probably drop some of those sources like contacts or dates, stuff that are unmaintained upstream for years
<cjwatson> I don't especially care but I'm not removing anything without audit-trail bugs :-)
<Laney> ok, building a set of images
<seb128> cjwatson, when do you want that sorted? is end of day today or tomorrow ok?
<seb128> cjwatson, I want to talk to cyphermox first before dropping stuff, but he's not up before a few hours
<Riddell> Laney: yes please, although it needs a bugfix first
<Laney> ok, well it'll build but we can spin it again later
<cjwatson> seb128: sure, that's fine, just post-holiday "what's the archive looking like" checks
<seb128> cjwatson, sorry about that, part my fault, with Didier on holidays I had to step up to help getting the stuff from #ps landing for ff and I didn't manage to do lot of +1 due to that :-(
<xnox> Please accept ubiquity 2.11.27 it fixes bug 1044545 which prevents opening manual partitioning in ubiquity.
<ubot2`> Launchpad bug 1044545 in ubiquity "ubiquity crashed with AttributeError in on_partition_use_combo_changed(): 'PageGtk' object has no attribute 'partition_format_checkbutton'" [Critical,In progress] https://launchpad.net/bugs/1044545
<xnox> Laney: ^^^^
<Laney> xnox: when the diff appears
<xnox> Laney: ok thanks. And I guess I owe 14 birdseeds to the release team by now....
<Laney> did you mean to not sponsor it properly for Omer?
<seb128> Laney, did you guys consider the stuff I mailed the list about on saturday?
<seb128> like indicator-session
<Laney> seb128: not yet
<seb128> :-(
<Laney> I'll look at it in a minute
<Laney> you want indicator-session s-c-p indicator-messages considered?
<xnox> Laney: no, I did not mean to sponsor it properly for Omer. I did mean to have multi-maintainer changelog.
<Laney> ok, well, looks "DOH" enough
 * Laney accepts
<xnox> Laney: thanks.... and respin later?! =)
<Laney> yes. later.
<Laney> after considering these desktop updates
<ogra_> slangasek, yay, awesome, thanks for testing :)
<xnox> also is the release bot asleep? =)
 * Laney wonders how long these guys upstairs need to assemble a desk
<seb128> Laney, yes
<ogra_> slangasek, oh, and yes, i have seen the flickering too, but i think thats post-beta stuff, having a desktop at all was my beta target :)
<cjwatson> xnox: needs stgraber to fix
<xnox> ok
<xnox> So am I allowed to upload to quantal-proposed for stuff which is not critical for beta1
<xnox> e.g. fix for bug 523896
<ubot2`> Launchpad bug 523896 in shadow "useradd: cannot lock /etc/passwd; try again later." [High,In progress] https://launchpad.net/bugs/523896
<xnox> ?
<cjwatson> Yeah
<cjwatson> Or you can dump it in the unapproved queue and we can ignore it until later :-)
<cjwatson> (i.e. upload to quantal, if it's relatively unlikely anyone else will need to for that package)
<xnox> ok.
<cjwatson> slangasek: Could you review efilinux-signed in NEW?
<Laney> seb128: accepted
<seb128> Laney, thanks!
<Laney> np, will respin later
<cjwatson> seb128: is bug 1028363 OK?  compizconfig-settings-manager and compizconfig-python are obvious, I just wanted to check on whether you're fine with dropping the binary package compiz-fusion-plugins-extra from compiz-plugins-extra
<ubot2`> Launchpad bug 1028363 in compizconfig-settings-manager "Please remove old compiz sources from quantal archive" [Undecided,New] https://launchpad.net/bugs/1028363
<cjwatson> jdstrand: could you confirm bug 1033107?
<ubot2`> Launchpad bug 1033107 in ubuntu "Please remove python-pyftpdlib from the blacklist and sync from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/1033107
<seb128> cjwatson, yes, they are all fine, we just support "compiz" in quantal, those 3 sources can be dropped
<seb128> cjwatson, I commented on the bug saying so
<cjwatson> thanks
<cjwatson> Ah, yes, compiz-plugins-extra exists since natty
<Laney> psivaa: hey, do you think you guys could put your nicks on the ReleaseTaskSignup page? I'm not yet familiar with your first names ;-)
 * Laney will edit for the names of the RT
<psivaa> Laney, could i have the link for the page?
<Laney> psivaa: https://wiki.ubuntu.com/QuantalQuetzal/ReleaseTaskSignup
<Laney> I'm trying to figure out who to ping when respinning :-)
<psivaa> Laney, sure ill add my nick
<Laney> the others too if you know them
<Laney> sorry for being clueless
<psivaa> Laney, ok no worries, done for the 3 qa contacts
<Laney> thank you
<Laney> so FYI we're currently looking at some respins as listed on the pad http://pad.ubuntu.com/ubuntu-release
<Laney> but the first cut images aren't all done yet, so will be kicked off in a few hours
<cjwatson> Laney: so I'm still kind of coping with piles of post-holiday stuff; for today, maybe best if you lob things in my direction as needed?
<Laney> cjwatson: sure, no probs, handling it for now
<Laney> the kind gentle folk from across the Atlantic should be along soon too
<cjwatson> mostly trying to clean up archive bugs
<cjwatson> which seem to have got rather behind
<seb128> Laney, not sure what people you are talking about but it's labor day in the U.S so those people will not be here today
<seb128> ;-)
<Laney> oh, really?
 * Laney panics
<seb128> yes...
<Laney> not really :P
<seb128> bit of an unfortunate timing, release people being at plumber on friday and U.S being off on monday
 * cjwatson eyes bug 1011053
<ubot2`> Launchpad bug 1011053 in glew1.5 "Please remove libglew1.5-dev and libglewmx1.5-dev and the glew1.5 source from quantal" [Wishlist,Confirmed] https://launchpad.net/bugs/1011053
<cjwatson> I think the simplest fix for this is: remove libglew1.5-dev and libglewmx1.5-dev binaries, *then* rebuild all the reverse-deps (because libglew-dev Provides: libglew1.5-dev), then remove glew1.5 source
<cjwatson> Anyone object to that?
<Laney> poor celbalrai
<cjwatson> There are no runtime deps on libglew1.5
<cjwatson> Sorry, libglew1.5-dev
<cjwatson> Or libglewmx1.5-dev for that matter
<cjwatson> There are three seeded packages involved that I can see: enblend, hugin, and hugin-tools (all Kubuntu daily-preinstalled)
<xnox> cjwatson: well. libglew is at 1.8 now. And did a transition tracker and it shows 43 bad packages.
<xnox> so my guess is, no rush?!
<cjwatson> Yes
<cjwatson> Well
<cjwatson> I want to clear the archive bug queue
<cjwatson> It's non-urgent +1 work I suppose but it does have to be unstuck at some point
<Riddell> no bot for the queue this time?
<Laney> it's down
<cjwatson> Riddell: 11:06 <cjwatson> xnox: needs stgraber to fix
<Laney> perhaps we can run it on some shared machine
<Daviey> Laney: write a juju charm for it. :)
<cjwatson> Say his name and he shall appear
<cjwatson> Riddell: Is startactive for beta-1?
<Riddell> cjwatson: yep
<cjwatson> OK, accepted
<cjwatson> Daviey: can you write a juju charm to keep server team MIRs up to date?
<Daviey> cjwatson: Unlikely.
<cjwatson> I guess that needs more resources than are readily available in the cloud
<Daviey> Yeah.  It might be easier to write a charm to distill flippant people :)
<cjwatson> touchÃ©
<cjwatson> though seriously, having horizon uninstallable due to unfiled MIRs three days before beta seems kind of suboptimal
<cjwatson> (well, uninstallable when using only main)
<cjwatson> and something in that stack is trying to pull python-support back in
<Daviey> cjwatson: it doesn't require a MIR.. It requires work to remove the the C-M
<cjwatson> OK ... is that work in progress?
<Daviey> cjwatson: we don't want to pull node into Main.  It's only needed to compress some CSS.. which should be done at source package creation time IMO.
<Daviey> cjwatson: yeah, it is.
<cjwatson> OK, good
<Daviey> cjwatson: well, two approaches are being investigated atm.. Compressing at source package creation time or making less,node/universe a suggests and doing a posh [ -f /usr/bin/node ] compress() at runtime.
<psivaa> Laney, just a smal Q :)..
<psivaa> Laney, I have just seen a few rebuilding but the pad does not say that in the history, will that be updated later?
<cjwatson> psivaa: it's probably not realistic to rely on the pad having a full history, since it's pretty cumbersome to update
<psivaa> cjwatson, ahh ok, thanks
<cjwatson> Personally I think adding that to the pad was a bad idea - if history's important, can't we track this some other way that would be more reliable?
<cjwatson> I guess reasons are hard to capture automatically though
<psivaa> cjwatson, yea thats true, i was just wondering cuz i missed that there is a respin at the moment, but the iso tracker shows it though so that's fine by me
<Daviey> cjwatson: I agree that pad's suck for this.  bzr would be far superior IMO, but at the very least wiki.
<cjwatson> Well
<cjwatson> What I'd actually like to do is complete and land my python rewrite of the cdimage tools, then write something on top which respins an image or set of images and reports the reason to some service
<cjwatson> Any system where we have separate action and tracking-of-action is bound to fail
<Daviey> oooo, that sounds ideal.
<cjwatson> Laney,QA: So, respin status - how would that be affected by accepting c2esp?
<cjwatson> Will let us fix a problem showing up on http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html
<cjwatson> (Which IMO should be clear before anything is even considered as a candidate, but what do I know ...)
<cjwatson> Binaries from that source package are in nearly all non-core images, though
<Daviey> cjwatson: horizon isn't shipped.. so no a candidate blocker IMO.
<cjwatson> Right, that's supported-misc-servers so we can get away with that, but it would still help clear noise if it were fixed
<cjwatson> The problem with ignoring noise manually is that we can't just say "it's green, next check"
<xnox> Laney or others: above ubiquity fixes the warning label in ubiquity / arm images
<cjwatson> And if we accept that, we'll need to respin most of everything anyway, so I think we should take c2esp too
<cjwatson> psivaa: ^- above ten lines or so, assuming you're current QA contact on duty
<psivaa> cjwatson, just reading it :)
<cjwatson> I only see five test results posted so far, and those are on netboot
<psivaa> cjwatson, i do not have any objections in including that on a respin if thats the question is..
<cjwatson> It is, thanks
<seb128> is there any chance we could get libreoffice considered if we respin?
 * ogra_ thought that was already considered anyway 
<cjwatson> What's its build status?
<seb128> the armel build is running dh_builddeb
<seb128> which is the last build to complete
<cjwatson> ogra_: it's not on the pad
<ogra_> oh, ok
<ogra_> its just because so many people cared on the weekend that got me this impression
<Laney> If it can be copied to -release then sure
<seb128> well, we really should get the new one, the current archive one spams dbus appmenu to no end and creates 100% cpu use while lo is running
<cjwatson> psivaa: ^- any objections?  don't know if much libreoffice testing has been done yet
<seb128> it's spamming so much that unity,dbus keep using 100%cpu for a while after libreoffice is closed
<ogra_> i should test on arm them with the current one ... sounds liek a good CPU stresstest :)
<ogra_> *like
<seb128> ogra_, ahah
<cjwatson> seb128: ouch
<seb128> cjwatson, yeah, they didn't the "update menu" plugged in at ff time and they though that having a "refresh every second" callback would be a good workaround
<seb128> didn't have*
<ogra_> hmm, apart from the fact that we dont seem to ship it currently
<ogra_> on arm
<ogra_> thats a histroical change we should probably revert
<Laney> why is it like that?
<ogra_> because we constantly had issues making the milestones due to slow builders
<seb128> Laney, I guess it was not working on arm at some point...
<Laney> hmm
<seb128> or that ;-)
<cjwatson> We've had to do that in the past as an emergency milestone band-aid, yeah
<cjwatson> It's easy to forget to undo it after the milestone
<ogra_> it always worked (somehow) but it always got in the way during milestones
<Laney> should we undo it now?
<psivaa> cjwatson, we do not do any manual release time libreoffice testing at the production level, so i would say that it does not affect ys
<psivaa> 8us
<psivaa> *us
<Laney> still have a couple of publishers to wait at a minimum
 * ogra_ greps for arm in the seeds ...
<cjwatson> OK, so as long as it's installable basically
<ogra_> ... and finds gnucharmap :P
<cjwatson> http://people.canonical.com/~ubuntu-archive/testing/quantal-proposed_probs.html has nothing relevant
<ogra_> oh, its [i386 amd64] ... not [!armhf]
<ogra_> so we dont ship it on ppc either
 * ogra_ will revert that but keep that change for after beta so we can test first
<Laney> yay, LO finished
<seb128> Laney, \o/
<plars> the -server versions are good I assume since they don't seem to be expected to be impacted by the things causing respins elsewhere?
<Laney> right, the respins are all desktoppish so far
<cjwatson> -server ships oem-config which comes from ubiquity
<Laney> hmm
<cjwatson> Though it won't actually be affected by the bug in question - it'd just be for the sake of version consistency
<cjwatson> So I'll drop [6] from the pad there
<cjwatson> Riddell: is kubuntu-active-meta for beta-1?
<cjwatson> Looks likely, and you're respinning anyway I believe
<cjwatson> Ah, there goes libcupsdriver1{,-dev}
<cjwatson> So just evolution-exchange and horizon on quantal_probs now
<Riddell> cjwatson: yep
<cjwatson> OK, accepted
<tjaalton> hey, I'm updating mesa to a newer snapshot, but there are two issues: it requires a newer libdrm (2.4.39 vs. 2.4.38 quantal has), and libglu has been split off from it, requiring a new package
<tjaalton> libglu is packaged, but would need to go through NEW
<tjaalton> libdrm would just need an ack to upload, not much changed there
<cjwatson> I'm removing the whole sync-helper / backport-helper / mass-sync edifice from ubuntu-archive-tools; we haven't had any bugs that required their use for at least a month or two now, and with that flow it's perfectly feasible to just use syncpackage / backportpackage for the odd exceptional case
<cjwatson> Docs updated accordingly
<tumbleweed> which reminds me. ScottK: now that we have ubuntu-archive-tools' queue, do you still need dgetlp?
<skaet> goodmorning cjwatson,  am about to start reading the logs, but anything on the urgent list from QA for today's images?
<cjwatson> not AFAICS but I have mostly been clearing the archive bug queue
<cjwatson> there's a pending respin of $most
<cjwatson> (due mainly to a fairly important ubiquity bug)
<cjwatson> [6] on the pad
 * skaet seeing...
<cjwatson> And I think there was consensus to copy over the new libreoffice
<tjaalton> can I upload the new libdrm? only seven upstream commits on top of the current one http://paste.ubuntu.com/1183673/
<cjwatson> Laney: ^- did that happen?
<Laney> still publishing armel afaics
<cjwatson> tjaalton: You can upload in any event and it'll land in the queue
<ogra_> armel has no images
<tjaalton> cjwatson: ok
<Laney> it still needs to happen for the copy
<cjwatson> tjaalton: We prefer to review things from the queue where possible - better tools for the job
<tjaalton> cjwatson: understood
<ogra_> ah, k
<cjwatson> Laney: It's publishing at the moment - took it ~20 minutes to think about the attached translation tarball
<cjwatson> Must fix that, that really doesn't have to be done on pepo
<Laney> such joy
<cjwatson> It's in ls-lR now, shouldn't be much longer
<cjwatson> Actually it's published in every sense that matters for copying
<cjwatson> So you might as well copy it now if you're going to
<Laney> I've never copied anything
<Laney> what's the incantation?
<cjwatson> sru-release -r quantal libreoffice
<cjwatson> in this case
<Laney> ah
<Laney> I would have reached for copy-package
<cjwatson> That's the general form for -proposed => release copying
<cjwatson> It's possible with copy-package too, but easier to use the canned tool even if it is a bit oddly named heree
<Laney> will it break because I can't delete from -proposed?
<cjwatson> *here
<cjwatson> No - it won't delete
<cjwatson> That gets GCed later semi-manually
<Laney> fair
 * Laney fires
<cjwatson> Although, you have just as much access to -proposed as you have to the release pocket, no
<cjwatson> ?
<cjwatson> Queue Administration Rights for ubuntu-release: archive 'primary', pocket 'Release' in quantal
<cjwatson> Queue Administration Rights for ubuntu-release: archive 'primary', pocket 'Proposed' in quantal
<Laney> I wasn't aware that let me delete
<cjwatson> Oh, looks like deletion is restricted to the archive owner
<cjwatson> OK *shrug*
<Laney> nae mind
<Laney> seems the copy worked anyhow
<cjwatson> Yeah, like I say no deletion involved
 * skaet marked Quantal Daily as released on iso tracker to avoid confusion now that Beta1 is online.
<Laney> skaet: wasn't expecting to see you today ;-)
<cjwatson> https://launchpad.net/ubuntu/quantal/+source/libreoffice/1:3.6.1~rc2-1ubuntu3 indeed
<skaet> hiya Laney,  needed to finish off a couple of things, so figured better to work than worry.
<Laney> fair cop
<Laney> should be able to respin $world after next publisher then
<cjwatson> I have to go out for a bit to return a couple of hired suits to the shop
<cjwatson> Guess it'll take me an hour or so
<Riddell> yay, queuebot!
<iulian> Now we've got two of them!
<Laney> ruh roh
<iulian> :)
<Laney> ubQueBot is running in the Canonical cloud
<tumbleweed> but who is running it. Can we kill it now?
<Laney> It Is A Mystery
<tumbleweed> thanks to the unaddressed command syntax we can't just ask one to mute itself. (although we could kick one)
<skaet> cjwatson, https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/987418 - do you know if we're likely to get a fix for this, this week?
<ubot2`> Ubuntu bug 987418 in ubiquity "manual partitioner: /dev/sdb (installation media) selected by default as device for boot loader installation" [High,Triaged]
<Laney> ok, we apparently have LO published now
<Laney> â spinning
<skaet> Laney, can you take note of the time it gets for all of them to be spun now?   I'm estimating it will be about 3 hours.
<Laney> OK, but I will be out in 3 hours
<skaet> Laney,  did you spin from the commands on the pad?   if so,  I'll use the last published one as the estimate then.
<Laney> skaet: yeah
<skaet> cjwatson,  https://bugs.launchpad.net/ubuntu/+bug/1029351 needs to have a decision made about fix/not and priority assigned.
<ubot2`> Ubuntu bug 1029351 in ubuntu "ISO testing: Cannot do an OEM installation a UEFI system" [Undecided,Confirmed]
<skaet> ok Laney,  will use that then.
<Laney> celbralai is the main bottleneck
<Laney> but we're getting another arm image builder I understand?
<skaet> infinity will know the details here.  Not sure what will come on line first more arm hardware for the isos or livefs in soyuz work.
<ogra_> well, we need both :)
<ogra_> still hoping we will get one of the highbank machines into the DC
<ogra_> Laney, there is another mandaboax that should have been up since ages (20 pandas in a 4U case)
<ogra_> *mandabox
<Laney> yeah, I saw
<Laney> at least one will be an image builder?
<skaet> ogra_, can you look at https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/746137
<ubot2`> Ubuntu bug 746137 in jasper-initramfs "Page allocation failure on Pandaboard and Beagle XM" [Undecided,Fix released]
<Laney> hahahaha, that bug, he loves it
<skaet> it seems to have stalled out, and it staying in the state "incomplete" seems wrong.
<skaet> ?
<ogra_> skaet, we have a fix for it apparently, but ppisati want on vacation before we coudl do more with it
<ogra_> *went
<ogra_> and then to plumbers ...
<skaet> ogra_, could you add a comment to the bug to that affect and mark it as inprogress then?
<ogra_> i'll change to confirmed, no idea why jsailsbury has set it to incomplete
<skaet> thanks
<ogra_> (surely not on anyones request)
<skaet> jamespage, could you please provide more info on: https://bugs.launchpad.net/ubuntu/+bug/1028458?  its sitting as incomplete.
<ubot2`> Ubuntu bug 1028458 in ubuntu "iSCSI root based servers appear to fail to boot completely" [High,Incomplete]
<jamespage> skaet, yes - missed that one - sorry
<skaet> thanks jamespage
<ogra_> skaet, erm, why did you open all these precise tasks ?
<skaet> ogra_, based on infinity's comment it should be backported to precise.
<ogra_> no, thats not possible easily
<ogra_> jasper-initramfs handles it in precise
<ogra_> (since natty actually)
 * skaet stomped on ogra_'s update by accident,... unstomped.
<ogra_> not sure if the kernel team will want to backport it ... its worked around in userspace, while kernel might be cleaner its not actually necessary
<skaet> Laney,  what's it showing you on the terminal where you kicked things off,  I would have expected some to have published by now and not seeing queuebot reporting them or much on the iso tracker.
<skaet> ?
<Laney> still waiting for armhf
<skaet> none of the alternates should be awiting on that, so I would have expected them to go through already.
 * skaet wondering if 3 sessions were set up or just 1?
<Laney> oh whoops, I forgot to do those :P
<Laney> going
 * skaet notes that Beta1 Technical Overview notes are now available for editing/updates by the leads.
<Daviey> Ah ubQueBot was me.
<Laney> sorry about the image failures, I noticed that I was going to respin server so had to kill it
<Daviey> skaet: Can you mute ubQueBot please?
<Daviey> Laney: why is server being span, i missed that?
<infinity> ogra_: If there's a kernel fix for that that can be isolated and backported, it absolutely should be.
<cjwatson> back, sorry for delay, had to take my bike to the shop for a couple of repairs
<infinity> ogra_: jasper isn't the only installer we have, after all.
<cjwatson> skaet: I'll look at those bugs; at the moment, since I've been away for a week, you should assume I don't know much about anything
<skaet> cjwatson,  fair 'nuf,  and thanks.
<Laney> Daviey: it is not. I ran a respin that included server by mistake, but aborted it before it got that far
<Daviey> ahh
<cjwatson> Daviey: mute> how about I just kick it?
 * Laney wonders how long the lock is held for
<Daviey> cjwatson: Well, seemed easy enough to keep it as a hot-spare.. no?
<Daviey> I can just kill it if not.
<cjwatson> You can start it up again if needed, surely, we don't need it hanging around all the time :)
<cjwatson> I thought the point of the cloud was that you could bring instances up and down quickly
<Daviey> smarty pants
<infinity> TouchÃ©.
<Laney> I have to go out now
<Laney> hopefully someone can make it so we can spin alternates again ;-)
 * Laney hides a bit
<cjwatson> hm what?
<cjwatson> Ubuntu alternate was intentionally disabled, AIUI
<Laney> other alternates
<cjwatson> Give me a specific example and I'll look
<Laney> {x,k,l} afaics
<infinity> Did you break the fragile locking mechanism somehow?
<Laney> yes I did
<infinity> *slowclap*
<Laney> for-project xubuntu cron.daily
<infinity> Yay for labor day, and my not caring.
<Laney> see your nusakan mailbox for much spam
<cjwatson> It only just arrived
<infinity> Ooo, yay, my libreoffice upload actually built on all arches.  That's, like, some sort of miracle.
<Laney> yeah, my apologies
<cjwatson> Oh, I see, OK
<cjwatson> I think just removing that file is correct
<cjwatson> Done
<cjwatson> I'll run Xubuntu alternate now as a test
<Laney> cool
<cjwatson> Yeah, that should be working now
<cjwatson> skaet: bug 1029351 is an ubuntu-cdimage bug and should be relatively easy to fix, but it'll need any amd64 images built before the fix respun (not livefses)
<ubot2`> Launchpad bug 1029351 in ubuntu-cdimage "ISO testing: Cannot do an OEM installation a UEFI system" [High,Triaged] https://launchpad.net/bugs/1029351
<skaet> cjwatson,  ok.  have added it to the pad a a rebuild trigger.
<skaet> ah good,  queuebot's announcing again.  :)
 * Laney giggles at .7
<skaet> Laney, cjwatson - there's Ubuntu DVD on pad,  that's not part of manifest for Quantal,  must be an oversite from 12.04.1 - removing
<cjwatson> Laney: something wrong with it or just the number?
<cjwatson> skaet: nowt to do with me :)
<Laney> cjwatson: just the number yeah
<Laney> we haven't been building the dvd, so yeah just delete the line
<ogra_> infinity, sure, but thats a nice to have, not something that deserves critical or high bug prio
<Laney> doing k/l alternates
<cjwatson> ta
<cjwatson> Rolled out fix for 1029351 immediately to minimise respin requirements
<cjwatson> I think I was in time for Kubuntu
 * Laney wonders where live images are
<cjwatson> Which ones?
<Laney> ah, CD image ubuntu/quantal/daily-live failed to build on 20120903.3
<Laney> we got Xubuntu but I didn't see Ubuntu come out
<Laney> so luckily you'll get your fix there too
<cjwatson> Hmm, I think I was just a fraction too late for Kubuntu
<Laney> kubuntu live is still building
<Laney> livefs
<skaet> Laney,  can you add a [9] to all the images that look they need to be respun to pick up cjwatson's latest?
<Laney> I think it's just xubuntu
<skaet> thanks
<skaet> I wasn't sure from the comments if it was Kubuntu or not as well.
<Laney> Kubuntu livefses are still going
<skaet> k
 * Laney sees no chinese edition on the pad
<infinity> Mirv: https://code.launchpad.net/~adconrad/unity/gles-fixes/+merge/122558
<skaet> Laney,  && env UBUNTU_DEFAULTS_LOCALE=zh_CN buildlive ubuntu daily-live && build-chinese-edition; date
<Laney> I just added that ;-)
<skaet> oh
<skaet> :)
<Laney> won't be in the current pipeline though
 * skaet nods,  ok,  let me know if you leave before triggering it, and I'll kick it off from here.
<Laney> I definitely will
<Laney> loathe to put anything else onto celbalrai right now
<cjwatson> Laney: Chinese edition images are amd64/i386 only
<Laney> oh
<skaet> That one is only for i386, amd64 so shouldn't be an issue though.
<cjwatson> grep zh_CN ~/cdimage/etc/default-arches
<Laney> there aren't any chinese arm users?
<cjwatson> We don't cater for them in the Chinese edition images
<cjwatson> If PES want it they can ask
<skaet> http://china-images.ubuntu.com/quantal/daily-live/current/
<Laney> 10 june eh
<Laney> that looks healthy
<skaet> http://china-images.ubuntu.com/precise/daily-live/20120902/
<Laney> it is spinning
<skaet> hmm... wondering how I got that precise in there...
<skaet> interesting,  not seeing any i386 images in the latest quantal ones.
<skaet> http://china-images.ubuntu.com/quantal/daily-live/20120831.1/
<Laney> I see a fail from the 30th
<cjwatson> Uh, I thought I'd finally managed to fix the quantal builds
<cjwatson> (amd64)
<cjwatson> amd64 was failing long-term until quite recently
<cjwatson> i386 failed for a while following my live-build work
<cjwatson> Error mail from build-chinese-edition must be buggy; damn those hacks
<cjwatson> The livefses seem to be building fine
<cjwatson> Oh, livecd-rootfs is meant to produce .iso for that image type but it's only giving us a squashfs
<cjwatson> +  * Naming resulting binary isohybrid image binary.hybrid.iso from now
<cjwatson> +    on for consistency with the different hdd images later on.
<cjwatson> Sigh, GRATUITOUS CHANGES 'R' US
<Laney> and we were expecting something else?
<cjwatson> binary-hybrid.iso
<Laney> classy
<cjwatson> live-build upstream likes to change things around pointlessly for "consistency"
<cjwatson> it's an utter pain in the arse
<cjwatson> But hey, it must be better, it has an upstream
<cjwatson> And PES use it
<cjwatson> Love and fluffy kittens
<cjwatson> livecd-rootfs 2.82 uploaded; please review once it hits the queue
<Laney> I am being summoned to the Organ Grinder I'm afraid
<Laney> Important date with 568.26ml
<cjwatson> Yes, I have to go shortly as well
<cjwatson> skaet: ^- please review livecd-rootfs?  it's a one-liner
<cjwatson> Well, once LP gives you a diff in the queue, anyway
<cjwatson> Oh, it's there now, I wonder why queuediff won't show it
 * skaet looking
<skaet> cjwatson,  done.
<cjwatson> Thanks
<skaet> Laney,  what's left to rebuild/kick off again?
 * skaet --> lunch,  back in an hour or so.
<slangasek> ogra_: is there a bug filed for the flickering?  I'm fine for it to be post-beta, but think it should get on the unity team's radar
<ogra_> slangasek, seems its a kernel issue, i just talked to rsalveti in #ubuntu.arm
<slangasek> ogra_: ok
<ogra_> seems he also already has a fix
<slangasek> cjwatson: looking at efilinux-signed
<slangasek> cjwatson: btw, I'm working on shim here; need to do some tests to verify that I've got the cert embedding working correctly before I go uploading it
<infinity> cjwatson: I'm not against switching back to livecd.sh and seeing how long it takes people to notice. :P
<ogra_> ++
<ogra_> and double plus !
<slangasek> cjwatson: strange; linux-amd64, not amd64, for the arch?
<infinity> slangasek: As opposed to linux-any or any-amd64, both of which would be wrong, I assume.
<infinity> slangasek: Though, "amd64" on its own would have the same effect. :P
<slangasek> infinity: as opposed to 'amd64', which is the canonical name for the arch :)
<infinity> slangasek: Maybe it's a subtle hint that, with some mangling, it could be appropriate for any-amd64?
<infinity> slangasek: Despite the name, I'm guessing it doesn't need to be linux-specific.
<slangasek> infinity: I'm not going to speculate randomly about cjwatson's motivation :)
<infinity> slangasek: It's labour day.  It's either speculate randomly, or accidentally work on your day off.  And you wouldn't be doing the latter, would you?  *suspicious look*
<infinity> slangasek: Or, you can come share my narcotics.  Whee.
<slangasek> infinity: oh, labour day?  I thought this was Libor day; sorry for the misunderstadning
<phillw> it could not have fallen at a worse weekend :(
<infinity> phillw: My kidney agreed.
<infinity> s/agreed/agrees/
<phillw> infinity: would http://pastebin.com/vns501PK be okay to send to the testers?
<slangasek> infinity: get yourself some jagua fruit juice
<phillw> the L-QA ones know me, I'm not sure about cc'ing ubuntu-qa mailing list.
<infinity> phillw: Seems pretty negative.  I dunno.  Respins happen.  Lots of them just mean that people are paying attention? ;)
<infinity> phillw: (And paying attention is something I've not been doing this weekend, so I'm not a good person to talk to about this)
<phillw> infinity: well, the lack of any beta-1 for the whole weekend with the exception of minimal is quite a major mess up?
<phillw> infinity: I'll just send it to lubuntu, we had nothing at all.
<phillw> kate & nicholas are not about, they usually proof read my emails :)
<phillw> I'll leave you guys in peace.
<phillw> infinity: FYI, http://pastebin.com/SyzRjDCY is what got sent to L-QA
<Daviey> phillw: erm, are you sure you've had 7 spins?
<phillw> Daviey: not us, but the count is 20120903.7 for some, it was commented upon earlier, else I wouldn't even have noticed :)
<Daviey> phillw: Maybe  misread your mail, but it sounded like Lubuntu had 7 spins today.
<phillw> Daviey: not at all, it does state 'some'
<Daviey> phillw: "one of the re spins is on .7 (Yes, that is 7 re spins in the same day)".. but ok
<jibel> phillw, , xubuntu alternate is numbered .7 but have seen only 2 builds not 8, other builds were just attempts blocked by a lock file according to the build logs.
<Daviey> To clarify,  .7 doesn't mean that any image was re-span 7 times
<Daviey> It's also a global counter, not a per flavour/product/image counter.
<gilir> skaet, indicator-applications-gtk2 uploaded, new review in NEW queue
<skaet> thanks gilir, can you remind me of bug number?
<phillw> Daviey: jibel believe it, or not, I was attempting to reduce the frustration factor of the testers. http://pastebin.com/SyzRjDCY I was being PM'd and had no information to give them
<phillw> I'm working on this one now.
<gilir> skaet, sure, bug 1044442
<ubot2`> Launchpad bug 1044442 in ubuntu "Re-introduce indicator-applications-gtk2" [High,In progress] https://launchpad.net/bugs/1044442
<skaet> Thanks gilir,  adding to pad.
<gilir> skaet, thanks
<skaet> ScottK,  could you help out by doing a review on ^ ?
<Daviey> phillw: oh, sure.. appreciate that.. but i wanted to comment that your mail might have made it sound worse than it is :)
<Daviey> gilir: The tracking bug really lacks, any, erm depth
<knome> hey gilir :)
<phillw> Daviey: it gets slightly worse, as Julien (Lubuntu) did not 'pull' lubuntu builds from the Friday build .. it was assumed
<gilir> Daviey, I can give you any details you want :-)
<Daviey> phillw: Oh, in Lubuntu world.. i can't comment. :).. But the suggestion of some images up to 7. things being a little haywire in -release, and post-mortems isn't accurate.
<Daviey> gilir: The tracking bug would be better if it documented the reason for it's existence.. a plain "tracking bug" with no expansion is really hard to work out why it is tracking :)
<phillw> Daviey: I was only refelcting an 'lol' from earlier on today on this channel
<skaet> gilir,   +1 what Daviey says ;)
<gilir> ok ok, I will add some details :-)
<knome> skaet, beta1/techoverview updated to the best of my knowledge
<skaet> thanks knome.  :)
<knome> oh, there's that another section for known issues
<gilir> skaet, and just to make it clear, if it's not fixed for Beta 1, it's not a blocker for Lubuntu
 * knome will reorganize
<knome> ^ done
<phillw> whilst not wishing to get anyone into trouble for having a sense of humour ... (17:54:02) ***Laney giggles at .7
<phillw> my apologies if I have caused offence
<skaet> gilir, do you know if its a blocker for Xubuntu or Ubuntu Studio?
<gilir> skaet, probably not if they removed it from the seed, but I can't talk for them :-)
<Daviey> phillw: oh, none taken.. i just wanted to clear up any ambiguity. :)
<skaet> gilir,  fair enough.
<skaet> Daviey,  could you take a pass at reviewing the indicator-applications-gtk2 in new?
<skaet> I'd like to get those images respun to include it before the testing gets started,  or at least have it ready to go if it does turn out to be a blocker for those teams.
<Daviey> skaet: it's a real pain not having the full story in the bug, as to why it needs to be reintroduced.. etc.
<Daviey> If it's because of the removal bug i'm thinking of.. it thought there was a compat package already?
<gilir> Daviey, I added more details on the bug, tell me if you need more background about the issue
<Daviey> ah, thanks gilir :)
<skaet> Daviey,  it came up in the status' last week.  ie.  https://lists.ubuntu.com/archives/ubuntu-release/2012-August/001850.html
<Daviey> gilir: is this just to unlock for beta.. or are you expecting this NEW to be in final quantal?
<gilir> Daviey, we expect it in final quantal
<Daviey> gilir: The status mail states it's to fix build failures, but the only xubuntu set one i can see is.. https://launchpad.net/ubuntu/+source/libopenraw/0.0.9-3 ?
<gilir> Daviey, probably because indicator-applications-gtk2 was part of the seed at some point, which may cause a build failure of ISO
<Daviey> ahh, i thought it was package build failures.
<gilir> Daviey, but I don't think it's now the case, as they remove it from their seed
 * skaet not sure why Laney added the preinstalled and ARM builds in with the rest of the desktop....   rearranging pad.
<Daviey> gilir: ugh.. the diff from when this was last in the archive is much larger than i expected.. http://pb.daviey.com/C4DP/
<gilir> Daviey, because it's rebased on upstream version 12.10.0 which is in quantal, but not in precise
<gilir> Daviey, and I think most of the diff is autofoo changes because of the new version
<Daviey> gilir: ahh, debian/changelog made me think it was based off precise
<skaet> seb128, around?
 * skaet sees not
<cjwatson> slangasek: I was matching efilinux, which is a Daniel Baumann package
<cjwatson> He tends to overspecify
<Daviey> gilir: accepted.
<cjwatson> Daviey: the .7 counter is per flavour/product/image, not global
<cjwatson> Daviey: you may have been misled by the fact that I never got round to making it per-series
<Daviey> cjwatson: Hmm, I don't follow.. I was sure i had seen flavours jump when other flavours were built inbetween.
<cjwatson> I've never been aware of that being the case
<cjwatson> It's been per flavour/image since 2005
<Daviey> cjwatson: ok, i must be mistaken.
<cjwatson> STAMP="$CDIMAGE_ROOT/etc/.next-build-suffix-$PROJECT-$IMAGE_TYPE"
<cjwatson> is the relevant line
<Daviey> cjwatson: Hmm.. Can you grok why there wasn't a ubuntu-server .1 today? http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/quantal/ ?
<gilir> Daviey, great, thanks :-)
<Daviey> cjwatson: I mean, it's clear that you are correct.. i just want to understand why i thought i had seen jumps before.
<cjwatson> Daviey: As I say, the count (buggily) isn't per-series
<cjwatson> Daviey: So if there are precise and quantal builds both happening daily, one will get <date> and the other will get <date>.1, depending on which comes first
<Daviey> ahh
<cjwatson> Daviey: compare http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/precise/ and you should find it fills in the gaps
<Daviey> yep, thanks cjwatson
<cjwatson> This is certainly confusing and I plan to fix it at some point
<cjwatson> It just isn't very high priority :-)
<Daviey> i'd say it was sub-low priority
<cjwatson> It's only not no priority because it confuses people and thus indirectly takes up time
<cjwatson> slangasek: I'm going to move efilinux-signed to universe because it needs to be at least as far out as efilinux, which hasn't been MIRed yet
<cjwatson> (in order to build)
<cjwatson> Though I perhaps ought to deal with a MIR there at some point
<cjwatson> OK, so working with a current desktop image in kvm is now barely usable again, but unity is horrifically slow and it's even slowing down my host desktop.  Do any of you good folks have a trick for making it reasonable again?  Otherwise I'm going to have serious trouble working on any installer bugs.
<cjwatson> Well, it's a little less awful once I get as far as starting ubiquity.
<plars> is a respin really going to happen on server? skaet mentioned it earlier, but I haven't seen it reflected on iso tracker yet
<skaet> plars,  Laney said he started them off on order listed on pad.ubuntu.com/ubuntu-release, and based on that I'd have expected them to have published by now
<skaet> so,  given that respin wasn't necessary for them, not sure if they should be respun or not at this point.
 * skaet is just expecting WUBI to show up now
<plars> skaet: that's good by me then :)
<cjwatson> The last ubuntu-server respin that happened started at 12:02 UTC
<cjwatson> Somebody with more brain can correlate that
<skaet> hmm,  that seems a bit weird.  one on iso tracker right now is from 12:09 UTC.
<cjwatson> That's consistent.  :02 was the start time.
<cjwatson> :09 would have been about when the i386 build finished.
<skaet> yeah, but amd64 finished at :06, and the armhf+omap4 image at :08,  manifests put in there from a couple hours prior.
 * skaet suspects the respin is going to happen, its just locked behind WUBI at the moment. :P
<skaet> http://cdimage.ubuntu.com/ubuntu-server/daily/20120903.2/
<cjwatson> skaet: That all looks entirely normal
<cjwatson> I expect there was a long queue of livefs builds in the morning
<cjwatson> The ISO9660 part was the part that started at 12:02, not the livefs building part
<slangasek> cjwatson: ok
<bdrung> can someone accept ncurses in oneiric-proposed?
<xnox> kubuntu is affected by bug 1038522
<ubot2`> Launchpad bug 1038522 in ubiquity "manual partitioning in installer crashes" [High,Confirmed] https://launchpad.net/bugs/1038522
<xnox> this is unrelated to the recent ubiquity bugs in the gtk frontend.
<xnox> Some comments on the duplicates are rude.
#ubuntu-release 2012-09-04
 * skaet notices WUBI not on iso tracker,  starts it off
<Laney> !?!?!?!?
<Laney> the reason it was up to .7 is because it got retried several times while clearing the locking bug
<Laney> there weren't 7 respins...
<babyface_> upgrade from precise to quantal failed(both i386 and amd64) with a error ::41:20,898 ERROR Dist-upgrade failed: 'The package 'unity-2d' is marked for removal but it is in the removal blacklist.'
<babyface_> anybody has idea on this?
<jibel> babyface_, yes, please file a bug
<babyface_> jibel,  ok. thanks.
<jibel> babyface_, against update-manager
<babyface_> jibel, ack.
<Laney> babyface_: jibel: the blacklist lives in ubuntu-release-upgrader-core (so bugs for it to ubuntu-release-upgrader)
<jibel> Laney, right, sorry
<Laney> np
<babyface_> Laney,  ok, thanks .
<Laney> thanks for noticing it
<Laney> I can reupload with that entry dropped if someone confirms to me that doing that is necessary and sufficient
<mvo> jibel, Laney: uh, I can fix this, I guess that does no longer makes sense :)
<Laney> ah, great, thanks mvo
<Laney> didn't the automated tests catch this?
<mvo> Laney: a good question, I don't know
<jibel> Laney, it did, that how babyface_ found it.
<mvo> babyface_: is there a bugreport already that I should reference? if not, I can just upload as its a pretty small change
<jibel> https://jenkins.qa.ubuntu.com/job/quantal-upgrade-precise-desktop/126/ARCH=amd64,LTS=non-lts,PROFILE=desktop,label=upgrade-test/artifact/results/main.log
<babyface_> mvo, not yet
<babyface_> mvo, so feel free to upload
<mvo> babyface_: ok, don't worry, I just upload
<mvo> thanks for the report babyface_
<babyface_> mvo, yw
<Laney> jibel: that is good. is this a new test? the change happened about 3 weeks ago IIRC
<jibel> Laney, it is not a new test, and it is the first time it is detected. Something must have changed the upgrade path.
<Laney> interesting
<Laney> mvo: are those other changes automated?
<mvo> Laney: yes
<Laney> cheers
<Laney> approving them
<mvo> Laney: its demoted packages that are automatically calculcated on each build
<Laney> then
<mvo> ta
<Laney> jibel: ^-- would you be able to re-run this test when the new package is available?
<jibel> Laney, of course, no problem.
<Laney> \o/
 * jibel wishes next release will be named 'rapid rabbit', Q is soo sloow without the appropriate hardware.
<cjwatson> I suspect what happened with unity-2d is that I only got around to moving it to universe yesterday IIRC
<cjwatson> The transitional packages that is
<Laney> aha
<Laney> are we really trying to get the gtk2 indicators back in for b1?
<ogra_> lubuntu and xubuntu would likely like that
<Daviey> Laney: it should be done.. universe only.
<Laney> Daviey: with seed changes / respins
<Laney> gah
<Laney> knome: Hey, you here? Is anyone taking care of the seed changes to get the indicators back, do you know?
<Laney> micahg: ^ you might know
<Laney> plars: psivaa: babyface_: Are you relatively happy so far?
<Daviey> Laney: I'm going to guess, gilir doing the change and phillw will help let the communities know.
<Laney> Daviey: I tried to nick complete gilir but he's not here so that failed :-)
<Laney> ah, phillw: I wanted to clear up your confusion from yesterday
<Daviey> Laney: I'd just wait out, it's not ohnoes urgent to get it span, right?
<Laney> .7 didn't mean there were 7 respins, just that the script to increment the release number was called 7 times
<Laney> there was infact only one
<Laney> Daviey: Well, it's up to them. I'm trying to provide people with as much time as possible to do their validation. ;-)
<psivaa> Laney, is this question about the time given for testing or the quality in general?
<Laney> all of it
<Laney> I saw there was a bit of confusion yesterday where people were expecting server respins that weren't happening
<psivaa> i know plars was talking about a possible server respin yesterday but i was not sure what made him think, could verify that today when he comes online
<cjwatson> There was talk about it at one point but we decided against it, I think.
<ogra_> psivaa, possible respins should be in the pad
<cjwatson> Because ubiquity was uploaded and builds packages on the server image, but in practice the bug in question didn't affect server.
<ogra_> hrm, why is the pad url gone from the topic again ?
<ogra_> i know skaet added it last milestone
<Laney> needs an op to fix (preferably to set mode -t)
<cjwatson> We occasionally get -party refugees in here so I think I prefer +t, but
* cjwatson changed the topic of #ubuntu-release to: Quantal Quetzal Alpha 3 released! | Archive: Beta Freeze | http://pad.ubuntu.com/ubuntu-release | 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
<iulian> Heh.
<Daviey> aww, topics. I remember reading those.
<ogra_> cjwatson, thanks !
<xnox> opportunity translation ('french') respin for ubiquity see bug 1045695
<ubot2`> Launchpad bug 1045695 in ubiquity "ubiquity-debconf need translations refreshed from launchpad (e.g. french is incomplete)" [Undecided,New] https://launchpad.net/bugs/1045695
<cjwatson> We don't normally respin for translation improvements - we'd be there all day
<cjwatson> It can ride along with some other upload, but I wouldn't bother listing it explicitly in the pad or anything
<xnox> ok.
<iulian> Laney: Someone just filed an FFe bug but what he really wants is a backport. Do you guys want a new bug filed or can he just edit the existing one?
<Laney> reassign it to backports
<iulian> Okey-dokey.
<Laney> it would be nice if you could ask him to include the template information too (open requestbackport and paste it into the existing bug description)
<Laney> or close it and ask him to file a new one with requestbackport, whatever you think's best
<iulian> OK. I'll just close it and tell him to file a new one using requestbackport.
<Laney> grand
<cjwatson> I'm trying to resolve various NBS and such which has led me down the path of poking at the tiff transition.  As part of this I'm syncing sdl-image1.2 from experimental, which drops some dependencies of libsdl-image1.2-dev.  This isn't the whole story for sdl-image1.2, but I'm pretty sure that it will improve buildability of reverse-deps, some of which currently fail due to trying to mix libtiff4-dev and libtiff5-dev.  ...
<cjwatson> ... I'll test reverse-deps after sdl-image1.2 has built and fix up anything that breaks.
<knome> Laney, i don't know
<mvo> could someone please reject the apt waiting for review to go into precise-proposed? as its not in yet I will add another fix to it and re-upload
<ogra_> hmm, omap4 server doesnt look so good
 * ogra_ blames Daviey 
<seb128> mvo, done
<mvo> seb128: thanks!
<seb128> yw ;-)
 * cjwatson develops a nasty suspicion about bug 987418
<ubot2`> Launchpad bug 987418 in ubiquity "manual partitioner: /dev/sdb (installation media) selected by default as device for boot loader installation" [High,Triaged] https://launchpad.net/bugs/987418
<cjwatson> Don't tell me that it's misbracketing
<cjwatson> It is.  How embarrassing.
<plars> psivaa: regarding the server respin, I was told that there had been one kicked off on accident so it was just going to happen even though it wasn't really needed.
<knome> cjwatson, at least its fixed now.
<knome> :)
<psivaa> plars, ahh ok, was wondering if there was any of such information at the pad
<cjwatson> Laney,psivaa: I would like to fix bug 987418 for beta-1.  The fix is http://paste.ubuntu.com/1185617/, but would of course require a respin of pretty much everything.  What do you think?
<ubot2`> Launchpad bug 987418 in ubiquity "manual partitioner: /dev/sdb (installation media) selected by default as device for boot loader installation" [High,Triaged] https://launchpad.net/bugs/987418
<cjwatson> Well, everything except core/server/netboot.
<cjwatson> I'd probably want to do a translation update at the same time, per xnox.
<xnox> =)
<Laney> I defer to QA: it seems like it should be alright to release note that and get it in immediately after, but also the bug is irritating. If they don't mind re-QAing then fine by me.
<cjwatson> We've been release-noting it (or at least I think we have) for a while, but it's the kind of bug people don't notice and then end up with a subtly trashed system.
<psivaa> i agree with Laney, for redoing the whole images for a single use case seem less efficient :), and getting forgotten after release noting does not seem to be a good reason for resping imho
<jamespage> query re: radosgw - its been promoted to main in quantal but it still has a pending MIR review - bug 1017978
<ubot2`> Launchpad bug 1017978 in libfcgi "[MIR] libfcgi, ceph (radosgw)" [Medium,Fix released] https://launchpad.net/bugs/1017978
<jamespage> radosgw and rest-bench (both built from ceph) should be in universe until that is sorted one way or the other...
<cjwatson> psivaa: You're fine with a release note that basically says you must use manual partitioning if you're installing from USB?
<cjwatson> jamespage: oh, I didn't notice that there was per-binary MIRing going on
<cjwatson> jamespage: moved back to universe
<jamespage> cjwatson, yeah - sorry - its a little obfuscated...
<jamespage> ta
<psivaa> cjwatson, yes, i  guess because as per the bug this is occurring only for side-by side installation
<cjwatson> I'm not convinced about that.
<cjwatson> Let me see if I can reproduce it otherwise.
<psivaa> cjwatson, please and if we tried usb installations and they worked fine apart from side by side
<psivaa> s/please and if//
<ogra_> stgraber, hmm, could i get a testcase for armhf+ac100 lubuntu-desktop on the tracker ?
<cjwatson> psivaa: Hmm, it may be that the "erase disk" option overrides the boot device in some way I've forgotten
<cjwatson> I'm uncomfortable with this, but I guess I'm not the one who has to do the testing.
<psivaa> cjwatson, i understand your concern, but when you see this bug was first reported on  2012-04-23 and we have managed to live with it.. even for precise
<cjwatson> I've used the "we released with this before" argument myself, but I think this has resulted in rather a lot of subtly corrupted installations.  Subtle corruption scares me.
<cjwatson> Distressingly, this appears to have been a late regression I introduced in precise due to fixing bug 984989.
<ubot2`> Launchpad bug 984989 in ubiquity "grub install fails. installing from /dev/sda to /dev/sdb" [High,Fix released] https://launchpad.net/bugs/984989
<cjwatson> The test case I added there didn't work quite right because I didn't consider the case where boot_device is None.
<cjwatson> Which happens when partitioning hasn't been done yet.
<cjwatson> (IOW, we only released precise with it because it was a sufficiently late and subtle regression that we didn't have time to realise its importance.)
<cjwatson> Anyway, I've said my piece.
<psivaa> cjwatson, well, as i said that's very a valid bug that needs urgent fixing but i am not personally convinced that this has to be done 2 days before the release, as you said above the fixes are regression prone
<stgraber> ogra_: sure, I guess I can just copy what's currently assigned to the armel one?
<ogra_> stgraber, well, its lubuntu-desktop now
<stgraber> ogra_: oh right, sorry my eyes missed the "l" ;)
<Riddell> kubuntu upgrade bug 1029150 should be fixed with lightdm-kde in queue
<ubot2`> Launchpad bug 1029150 in lightdm-kde "precise to quantal upgrade does not work" [Undecided,Confirmed] https://launchpad.net/bugs/1029150
<Laney> cjwatson: do you want to upload as an opportunity target? e.g. for kubuntu ^
<cjwatson> Laney: I was wondering whether I might be able to fix bug 1038522 if I was doing that
<ubot2`> Launchpad bug 1038522 in ubiquity "manual partitioning in installer crashes" [High,Triaged] https://launchpad.net/bugs/1038522
<cjwatson> Combination of (a) you have to use manual partitioning when installing side-by-side from USB and (b) manual partitioning busted with KDE frontend is kind of unhelpful
<cjwatson> (Though to be fair I've not tested whether (a) happens with Kubuntu)
<Laney> sounds reasonable
<cjwatson> Riddell: ^- unless you think somebody might be able to attack that ASAP?
<cjwatson> The KDE frontend is a bit outside my comfort zone these days
<Riddell> currently the candidate desktop image for kubuntu doesn't seem to be working well :(
<Riddell> was going to try and recreate that bug
<cjwatson> Urgh, you can't even get that far?
<Riddell> it's just rediculously slow
<cjwatson> 3D?
<Riddell> cjwatson: dunno, kwin has accelatation off
<jibel> xnox, I get bug 1045812 with LVM (not sure if doing the installation in French has anything to do with the crash)
<ubot2`> Launchpad bug 1045812 in ubiquity "Partitioner failed with "Failed to partition hard drive" with LVM selected" [Undecided,New] https://launchpad.net/bugs/1045812
<xnox> Volume group "ubuntu" has insufficient free space (4034 extents): 4028254 required.
<xnox> jibel: =/
<xnox> jibel: thank you very much for testing all this by the way! you are finding bugs that I was not hitting in my testing!
<jibel> xnox, /bin/perform_recipe_by_lvm: 136: [: Illegal number: 16919822,34
<jibel> xnox, blame French
<cjwatson> Well
<jibel> , instead of .
<cjwatson> . wouldn't work either there
<cjwatson> [ wants integers
<xnox> it must be integer, yeah.
<xnox> fixing partman-lvm will result in respinning everything but the cloud images and maybe netboot images?!
<cjwatson> Wouldn't need to respin netboot for that, no
<cjwatson> Might want to retest it, but server tests would probably be enough
<xnox> jibel: was the second time in a row you were installing onto the same disk? or am I missreading the logs that say "activate existing ubuntu VG"
<skaet> cjwatson, am not spotting the updated Chinese image from yesterday on: http://china-images.ubuntu.com/quantal/daily-live/
<skaet> Laney,  did anything happen with the build?
<Laney> let's look
<cjwatson> skaet: I didn't rebuild it; I uploaded the fix and then said I was leaving
<Laney> I was under the impression it was going to break and need to be respun though
<cjwatson> The last respin of the Chinese edition was before my fix.
<cjwatson> I mean the last attempt.
<skaet> cjwatson,  the version there is from 08/31,  so am wondering if some publishing glitch?
<Laney> I'll retry it now
<cjwatson> skaet: No.  Nobody attempted to rebuild following my fix.
<Laney> going
<jibel> xnox, on this system, I reinstalled over and existing installation, but the second message ("No root filesystem") is with a fresh disk (fresh = no partition table at all)
<skaet> cjwatson,  that would explain it.    I thought it was included in the build set that Laney ran.
<Laney> it was, but it was broken at that point
<cjwatson> skaet: It might have been, but that was before my fix, wasn't it
<cjwatson> ?
<Laney> no failure mail, though
<cjwatson> No, build-chinese-edition doesn't implement that
<cjwatson> Life was too short
<skaet> if it was at the end though,  it would have been included I would have thought.
<cjwatson> skaet: Honestly, it was before my fix.
<cjwatson> I've checked, twiwce.
<cjwatson> *twice
<xnox> jibel: from the code it's comparing to variables guided & free space, it does convert guided space into bytes / integer value before hand. Not sure if the free space is the one that is decimal. What was the size of the virtual drive?
<cjwatson> 17:40
<cjwatson> That's probably UTC, but either way I didn't upload my fix until 18:41 +0100
<skaet> cjwatson,  gotcha.    sorry.      rebuilding now will catch it.
<jibel> xnox, 16.00GB
<cjwatson> I think it was indeed pretty much at the end, although I don't know what was happening with Wubi.
<Riddell> I can't recreate bug 1038522 it must be doing some action in the manual partitioner I'm not doing
<ubot2`> Launchpad bug 1038522 in ubiquity "manual partitioning in installer crashes" [High,Triaged] https://launchpad.net/bugs/1038522
<Riddell> xnox: have you recreated it or did you just spot the bug?
<xnox> Riddell: received 2 duplicates & two more comments on the duplicate. Maybe it's precise only? From comments you need to have a few existing partitions (existing dual/triple boot) installs and then enter partitioning to generate the crash.
<xnox> Riddell: I was hoping that for Qt people it would be obvious why the traceback says that some attribute is missing
<skaet> cjwatson,  I triggered a rebuild last night - but am not seeing it on the iso tracker.
<skaet> rebuild came back looking positive.
<cjwatson> Rebuild of ...?
<jibel> xnox, I added /var/log/installer/debug with ubiquity -d if it helps
<xnox> jibel: let me look =)
<skaet> rebuild of WUBI
<cjwatson> odd, doesn't seem to be a log file
<cjwatson> There's one yesterday from 07:37 and one today from 07:09 (?)
<skaet> ubuntu-wubi-i386 on cardamom.buildd finished at 2012-09-04 07:09:05 (success)
<skaet> Tue Sep  4 07:09:43 UTC 2012
<cjwatson> Oh, your last night not my last night :-)
<cjwatson> Bah timezones
<skaet> its the one today,  that was kicked off earlier.
<skaet> yes,  sorry,  still need coffee on this side.  ;)
<cjwatson> Nah, that was my fault
<cjwatson> The log claims to have posted to the tracker
<Laney> http://china-images.ubuntu.com/quantal/daily-live/current/
<Laney> haz chinese images
<cjwatson> And it seems to be on the tracker ...
<cjwatson> "Ubuntu Wubi amd64" version 20120904, i386 likewise
<skaet> thanks Laney
<skaet> *blink*,  ok bad web page cache refresh on my side then.  sorry.
<Riddell> Laney: can lightdm-kde be let in?  it's not needed for the images only for upgrade
<Laney> do we not get the zh_CN images on the tracker?
<Laney> Riddell: oh, yes, let me look
<cjwatson> We should do ...
<Laney> I don't see them for .1 either
<Laney> unless we didn't release it then
<cjwatson> Oh, maybe not
<cjwatson> No post-qa in publish-chinese-edition
<cjwatson> Bah
<cjwatson> Well, except wasn't it supposed to be QAed by PES, or on the localised tracker, or something?
<cjwatson> localized-iso.qa.ubuntu.com has a product entry for Chinese
<cjwatson> But I don't think we have configuration for auto-posting there at the moment
<cjwatson> How about I say "not yet" and leave it at that
<skaet> cjwatson,  ok by me
<skaet> I'm pointing the PES folk at them directly.   Would be nice to get it hooked up before beta 2 though.
<skaet> s/them/web page/
<cjwatson> Somebody should probably file an ubuntu-cdimage bug as a reminder
<Laney> Riddell: there you go
 * skaet doing
<cjwatson> It could be posted to the tracker manually
<cjwatson> xnox: so do you think jibel's problem is respin-worthy?  if so we probably need to run that past the QA contact ...
<Laney> Riddell: so you don't need it on the images because the previous postinst would DTRT due to it always being a fresh install?
<Riddell> Laney: yes
<cjwatson> (and in that case I'd definitely like my fix for 987418 to ride along)
<jibel> (+1 for 987418)
<Laney> if we're building up a stock of installer fixes then it makes respinning more compelling for me
<skaet> plars, ^ since you're on point for QA this cycle.  Any comments?
<xnox> cjwatson: i don't know yet. trying to reproduce it locally with extra debugging.
<xnox> and have a fix.
<cjwatson> psivaa nacked it on its own but one of his arguments involved undesirability of respin-for-single-fix
<plars> skaet: having trouble sorting which thing in the backlog you're referring to
<plars> bug #987418 ?
<ubot2`> Launchpad bug 987418 in ubiquity "manual partitioner: /dev/sdb (installation media) selected by default as device for boot loader installation" [High,Fix committed] https://launchpad.net/bugs/987418
<plars> or jibel's problem? (and which was that?)
<skaet> plars,  yes both.   However I don't know the bug number for jibel's either  (lost some backscroll from earlier)
<plars> looks like 987418 is jibel's too
<xnox> catching rides Bug 744283 is an a11y theming fix.
<ubot2`> Launchpad bug 744283 in ubiquity "Steps "Preparing to install" and "Erase disk" are unreadable with high-contrast theme enabled" [Medium,Fix committed] https://launchpad.net/bugs/744283
<xnox> diff is a bit poluted by glade changes.
<cjwatson> that wasn't the bug of jibel's I was referring to - I meant the LVM issue several pages deep in scrollback
<plars> ah, maybe bug #1038522
<ubot2`> Launchpad bug 1038522 in ubiquity "[kde] manual partitioning in installer crashes" [High,Triaged] https://launchpad.net/bugs/1038522
<cjwatson> bug 1045812 I think
<ubot2`> Launchpad bug 1045812 in ubiquity "Partitioner failed with "Failed to partition hard drive" with LVM selected" [High,Confirmed] https://launchpad.net/bugs/1045812
<plars> jibel, cjwatson is that the one?
<cjwatson> no
<henrix> infinity: when you have a minute, could you please copy into -updates (and -security) the kernels from bugs 1036553, 1036178 and 1041217?
<ubot2`> Launchpad bug 1036553 in linux "linux: 2.6.32-42.96 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1036553
<ubot2`> Launchpad bug 1036178 in linux "linux: 3.0.0-25.41 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1036178
<ubot2`> Launchpad bug 1041217 in linux "linux: 3.2.0-30.48 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1041217
<cjwatson> that's unreproducible at this time apparently
<cjwatson> (1038522)
<Laney> u-cdimage bug filed
 * Laney goes out for ~1h
<skaet> cjwatson, plars, jibel -  has the status of the bugs in play, been captured accurately now?
<plars> skaet: don't think so
<cjwatson> plars: So, for clarity, I'm asking xnox to look into whether bug 1045812 is reproducible and reasonably fixable, and asking QA whether it's reasonable for my committed fix for bug 987418 to ride along with such a fix
<ubot2`> Launchpad bug 1045812 in ubiquity "Partitioner failed with "Failed to partition hard drive" with LVM selected" [High,Confirmed] https://launchpad.net/bugs/1045812
<ubot2`> Launchpad bug 987418 in ubiquity "manual partitioner: /dev/sdb (installation media) selected by default as device for boot loader installation" [High,Fix committed] https://launchpad.net/bugs/987418
<plars> ok, so it is that one
<skaet> plars, please make edits to pad for waht you believe is missing.
<skaet> *what
<skaet> seb128, https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/971353 - is it going to be possible we can get a fix for this one today?
<ubot2`> Ubuntu bug 971353 in gnome-settings-daemon "power : gnome-settings-daemon crashed with SIGSEGV in gnome_rr_screen_get_dpms_mode " [High,Confirmed]
<plars> do we even have a fix for https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1045812 already?
<ubot2`> Ubuntu bug 1045812 in ubiquity "Partitioner failed with "Failed to partition hard drive" with LVM selected" [High,Confirmed]
<plars> cjwatson: ^
<xnox> no. working on it. will let you know asap
<cjwatson> as above, "... to look into whether [that] is reproducible and reasonably fixable"
<seb128> skaet, no, it's there since before precise, why is it important now for quantal beta1?
<plars> xnox: do you believe it's possible that it could really be language related? I haven't tried lvm by itself, but I have done lvm+encrypted and it worked ok
<xnox> plars: it's nothing to do with language. There is invalid sell syntax passed to expr
<xnox> s/sell/shell/
<xnox> i need to work out which of the 2 variables, trace it back and make sure it's converted/rounder correctly to an integer
<plars> ok, good, I wouldn't have thought so
<skaet> seb128, lot seem to be running into it, and it came up in the testing yesterday.
<skaet> https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1045419
<ubot2`> Ubuntu bug 1045419 in gnome-settings-daemon "[power]: gnome-settings-daemon crashed with SIGSEGV in gnome_rr_screen_get_dpms_mode() (dup-of: 971353)" [Undecided,New]
<ubot2`> Ubuntu bug 971353 in gnome-settings-daemon "power : gnome-settings-daemon crashed with SIGSEGV in gnome_rr_screen_get_dpms_mode " [High,Confirmed]
 * skaet wishes tags would copy over from duplicate to master.  :P
<cjwatson> I think that's a philosophical thing - the problem with copying metadata from duplicate to master is that it gets tricky if you realise you made a mistake and want to unduplicate
<cjwatson> the current design makes undoing mistaken duplication a lossless process
<len-dt> cjwatson, in ubuntustudio with bug 1045650, is it best to just set automounting off? (the DE mounts ubiquity's freshly formated partition and ubiquity won't install) or is there a ubiquity timing issue? It used to work fine this way.
<ubot2`> Launchpad bug 1045650 in ubiquity "after ubiquity formats drive it automounts and ubiquity fails" [Undecided,New] https://launchpad.net/bugs/1045650
<Riddell> skaet: superficial but important bug in kubuntu, bug 1045839, I think I want rebuilt images
<ubot2`> Launchpad bug 1045839 in kde-workspace "plasma init script not run " [Undecided,New] https://launchpad.net/bugs/1045839
<seb128> skaet, errors.ubuntu.com disagrees with the "lot seem to be running into it", the only g-s-d issue showing up on the mainpage is a one in the xsettings plugin which score 25 reports today where we have bugs > 300 for jockey and ubuntuone-installer
<cjwatson> len-dt: Maybe your desktop environment changed the interface to disabling automounting yet again?  See http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/ubuntu/2008-04-12-desktop-automount-pain.html
<cjwatson> len-dt: Find what the new method is and we can add that too ...
<len-dt> cjwatson, thanks
<skaet> Riddell,  ok. mark it up on the pad please,  has a fix been uploaded?
<seb128> skaet, so this g-s-d issue is some magnitude bellow other bugs we hit, somewhat it seems qa guys run into it often though, it might be a "under kvm" issue
<Riddell> skaet: kde-workspace there is the fix ^^
<cjwatson> len-dt: What DE is this?
<seb128> skaet, or a "on CD only", like a timeout reached because of the media slowness
<skaet> psivaa, ^ can you provide more background to seb128:?
<len-dt> xfce4.10
<len-dt> cjwatson, ^^
<skaet> Riddell,  ok, as soon as publisher run has it up there,  we'll retrigger,  unless you want to wait for some of the other fixes to land.
<cjwatson> We currently try devkit-disks --inhibit and udisks --inhibit in addition to the methods listed in that blog post
<cjwatson> And possibly a couple of others
<len-dt> cjwatson, I think I will just set it to default off. It is probably better for our use anyway.
<psivaa> seb128, i was able to rerproduce it a number of times using the actual hardware, (mac-mini -amd64+mac amd dell inspiron-amd64)
<cjwatson> I'd like to know how to fix this in ubiquity anyway
<cjwatson> Otherwise somebody makes a derivative, changes the default to automount, and their installer explodes
<cjwatson> Not ideal
<Riddell> Laney: can you review and accept that kde-workspace?
<cjwatson> Are you still using thunar?
<seb128> psivaa, is that on CD,slow medias?
<len-dt> cjwatson, I understand, we use thunar as the desktop background but nowhere else
<cjwatson> Do you know what specific component does the automounting?
<cjwatson> We used to be able to poke ~/.config/Thunar/volmanrc
<psivaa> seb128, it was on a usb
<len-dt> The config ends up in the thunar config.
<seb128> psivaa, ok, I dunno then, can you reproduce it on demand?
<len-dt> cjwatson, ack! default system and user are different. I will have to do some looking. I had better boot the live to make sure I know exactly.
<len-dt> cjwatson, I will get back to you.
<plars> xnox: psivaa was able to reproduce it with french on desktop, but not english.  On server, I tried french and got through the partitioning just fine (also fine with english)
<plars> skaet: ^
<plars> so it appears to be fairly isolated
<xnox> plars: i saw.
<psivaa> seb128, sure it occurs almost every time on amd64+mac.
<seb128> psivaa, ok, I will try to find somebody to have a look
<psivaa> seb128, thanks
<psivaa> xnox, the bug is not reproducible in some other indian language as well
<skaet> Riddell, no Kubuntu Active?   just Desktop and Alternate?
<bencer> anybody from the -release team could have a look at this FFe #1043654?
<Riddell> skaet: no for the respin no
<Riddell> skaet: not for the respin no
<skaet> Riddell,  ack.
<len-live> cjwatson, in xfce4.10 thunar's automounting seems to happen in ~/.config/xfce4/xfconf/xfce-perchannel-xml/thunar-volman.xml
<iulian> bencer: I shall have a look at it in a few hours if no one beats me to it. In the meantime, could you please attach the build/install/run logs to the bug report?
<ogra_> how sad ... moving fromm a nice rc file to xml
<cjwatson> len-live: yow
 * cjwatson wonders how many tons more code that'll be
<ogra_> heh
<ogra_> but its *standard* now :P
<cjwatson> len-live: I don't suppose there's some kind of interface to it that isn't poking the XML directly?
<cjwatson> There must be some kind of configuration frontend
<cjwatson> If I could reuse a library or something from Python that would help
<len-live> cjwatson, the settings manager does this.
<len-live> but that means an app that shows in the settings manager container
<cjwatson> Well, I certainly don't mean starting an application; I mean whatever code it uses
<cjwatson> Behind the scenes
<len-live> cjwatson, I understand. I am just looking for what I can find
<len-live> cjwatson, thunar-volman-settings is a binary
<bencer> iulian: as i said in the ticket, there is no migration path, and current status is broken, kind of special situation :)
<xnox> cjwatson: reproduced jibel 's LVM bug.
<xnox> cjwatson: it compares if $guided_size -ge $free_size
<xnox> where guided size is 16900000000 (which is 16.9 TB, yet it's only 16 GB system....)
<xnox> and free size is 16919822,34
<cjwatson> I guess guided_size is actually bytes.
<cjwatson> On a call now though.
<xnox> which looks slightly better.
<xnox> cjwatson: ok.
<xnox> cjwatson: ok. I will upconvert free_size to bytes and check if that is correct.
<cjwatson> Yeah, it's bytes
<cjwatson> Note e.g. 'guided_size="$free_size"000'
<xnox> yea.
<cjwatson> Oh, no, wait
<xnox> why does it do that assignment and then compare the two of them.....?!
<cjwatson> See the comment just above, "Convert back to (decimal) kilobytes"
<cjwatson> So it actually should be KB by that point
<cjwatson> You might want to get a set -x trace
<cjwatson> Sorry, the code isn't desperately type-safe or anything
<doko> cjwatson, please could you reject the openjdk-6 and openjdk-7 uploads? will build these in a ppa first for testing, then maybe propose a copy after testing
<xnox> cjwatson: free_size=$(vgs -o vg_free --units K --noheading --nosuffix $VG_name | sed -e 's/^[[:space:]]*//; s/\..*//g')
<xnox> if only all locales / languages used '.' to separate decimal places
<xnox> jibel: it is l18n issue =) when vgs "helpfully" uses localised number formatting
<xnox> cjwatson: so prefixing that with LANG=C solves it.
<cjwatson> Ah - that makes sense
<cjwatson> Maybe LC_ALL=C for safety
<xnox> ok.
<xnox> jibel: english can't write numbers correctly =) it should be ' for thousand's separator and , for decimals. For once russian & french agree =)
<jibel> xnox, I kindly disagree it should be space for thousand's separator ;)
 * xnox ..
 * tumbleweed wonders why all our FFe bugs are suddenly coming in with status=Triaged
<xnox> tumbleweed: you know what to do ;-)
<tumbleweed> already done, but it appears taht we need to slap people too
<iulian> bencer: I'm not talking about the current status but the future one, that's what matters. I'm interested in how the packages behave after this update. And thus, logs are essential.
<bencer> iulian: current packages won't install as they are not compatible with current depends on the archive, after uploading zentyal-common and zentyal-core, but i can attach an update from precise, true
<tumbleweed> yeah, it isn't particularly easy for us to objectively review a FFe when it fixes breakage caused by an upload that should have waited for an FFe
<bencer> tumbleweed: yup, i agree, current situation is a bit messy, that's why i wanted to upload the new stuff and leave it in a working state
<bencer> iulian: tumbleweed which logs should i attach? dpkg.log? upgrade output?
<tumbleweed> the output is fine
<bencer> ok, going to check that now
<Riddell> apport nice to have for release but doesn't effect images ^^
<Riddell> no upgrade target on http://iso.qa.ubuntu.com/qatracker/milestones/232/builds ?
<Riddell> Laney: new kde-workspace packages are on the archive, could you respin kubuntu i386 and amd64 images?
<hallyn> would it be possible to get a judgement on FFE for bug 1043052 ?
<ubot2`> Launchpad bug 1043052 in lxc "[FFE] add pre-mount container startup hook" [Medium,New] https://launchpad.net/bugs/1043052
<xnox> Please approve partman-auto-lvm this is the one out of two uploads required to fix bug 1045812
<ubot2`> Launchpad bug 1045812 in partman-auto-lvm "Partitioner failed with "Failed to partition hard drive" with LVM selected" [High,In progress] https://launchpad.net/bugs/1045812
<xnox> the second upload of ubiquity, will follow after that one is published.
<xnox> it affects most installations of lvm which are done in a locale which uses ',' for decimal separator
<ogra_> so all the sane one then
<ogra_> :)
<ogra_> *ones
<xnox> ogra_: Ja, naturlich ;-)
<ogra_> haha
<xnox> ogra_: more importantly it affect's the default Quantal's locale - French
<xnox> ;)
<Laney> Riddell: I think we should wait for these ^ installer fixes; do you agree?
<Riddell> Laney: yeah if there's stuff coming in sure
<Laney> xnox: approving, but you changed the timestamp of an old d/changelog entry somehow(!)
<Riddell> I noticed timestamp changing on old changelogs in my apport upload, an extra dch that gets it out of sync maybe?
<Laney> skaet: so, looks like we're going to be respinning for these fixes
<skaet> summary of specific bug numbers?
<skaet> ie.  s/these/actual bug numbers... /  please
<Laney> 14 + 12 on the pad
<xnox> Laney: hmm... well yeah the old upload was not committed, so I had to fake it. Obviously I didn't do a good job at faking it =)
<Laney> that's... bug 1045812 bug 987418
<ubot2`> Launchpad bug 1045812 in partman-auto-lvm "Partitioner failed with "Failed to partition hard drive" with LVM selected" [High,In progress] https://launchpad.net/bugs/1045812
<ubot2`> Launchpad bug 987418 in ubiquity "manual partitioner: /dev/sdb (installation media) selected by default as device for boot loader installation" [High,Fix committed] https://launchpad.net/bugs/987418
<xnox> Laney: please wait. I need partman-auto-lvm published & reupload ubiquity.
<Laney> i am waiting
<xnox> ok =)
<henrix> RAOF: do you have some time to copy the kernels from bugs 1036553, 1036178 and 1041217 into -updates (and -security)?
<ubot2`> Launchpad bug 1036553 in linux "linux: 2.6.32-42.96 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1036553
<ubot2`> Launchpad bug 1036178 in linux "linux: 3.0.0-25.41 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1036178
<ubot2`> Launchpad bug 1041217 in linux "linux: 3.2.0-30.48 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1041217
<skaet> Laney,  refactor the rebuilds so that the arm triggering ones aren't mixed in with the others.
<skaet> on the pad.   We should be able to pull down the rebuild time.
<Laney> you mean have a separate arm step?
<Laney> set ARCHES everywhere?
<highvoltage> eek! it's beta1 week already!
<xnox> well ubiquity fixes affect arm desktop images....
<xnox> highvoltage: yeah... it's been hectic for me since friday....
<Laney> xnox: the problem is that we wait for all arches to get live filesystem builds and then build the cd images
<xnox> I see.
<Laney> which means that you bunch up behind the slowest one, ie arm
<skaet> Laney, no,  just move those with ARM in them to their own set.
<skaet> so the others don't bunch up behind.
<Laney> what doesn't build arm?
<skaet> trigger in 3 separate windows,   1 for only i386/amd64,  1 for only alternates,  1 for i386/amd64/armhf/powerpc
<Laney> edubuntu lubuntu ubuntustudio
<skaet> Laney,  Xubuntu, Edubuntu Studio -
<Laney> and x
<cjwatson> Is it worth it?  More manual rearrangement => more risk of error
<cjwatson> doko: Looks like somebody did that - sorry for delay
<Laney> Indeed â can't we fix the pipeline more generally?
<cjwatson> Blocked on the Python rewrite, really
<cjwatson> It's too difficult to improve in the current context
<skaet> we had a different pipeline (more along lines set up above) for alpha 3
<skaet> just want to go back to something closer to that.
<Laney> can you dig it up?
<skaet> yeah,  I'll dig.
<cjwatson> Haven't other things changed, though?
<skaet> cjwatson, fewer alternate and images dropped.
<cjwatson> So it would be a complex reverse merge, not just reverting ...
<cjwatson> I dunno.  Your call.  It just makes me nervous.
<skaet> Laney,  while I'm digging, can you update the pad with the targets that need rebuild to pick up 12, 14, and 15?  so we can get multiple eyes looking at them.
<skaet> cjwatson,  the blocking that went on yesterday seemed a bit of a waste, and we're going to want the respun images in folks hands as soon as possible.   What's there right now, won't do it thanks to the arm limitations.
<Laney> which of the ubiquity ones are specific to the gtk+ frontend?
<cjwatson> I'm not prepared to say that any of mine are specific to the GTK+ frontend.  It might be possible that they are due to some odd frontend-specific behaviour but I haven't demonstrated it.
<cjwatson> skaet: Trade-off between computer time and human attention, I guess.
<Laney> fine, we're respinning everything that could be affected anyway so it was just bookkeeping
<Laney> I don't see any flavours fixing their seeds for the gtk2 indicators so they don't get those this time
 * skaet nods
<len-dt> cjwatson, just for clarification should I change ubuntustudio-default-settings to no automount for now or is a ubiquity fix likely? I'm ok either way.
<xnox> len-dt: no fix in ubiquity, unless you tell us what api needs changing =)
<len-dt> xnox, I will change our settings then thanks
<xnox> len-dt: preferably pragmatically e.g. CLI tool to change that setting.
<skaet> Laney,  cjwatson,  can you turn off image purging so we don't loose this image set?
<xnox> len-dt: do you know if you can run  pseudo-code `$ xubuntu-settings-daemon set automount off`
<xnox> or something like that?
<xnox> Thunar and Xfce4 are in transition from using HAL and ThunarVFS, being currently deprecated, to using GIO, ConsoleKit, PolicyKit and the kernel udev architecture for detecting and automounting removable media.
<xnox> hmm...
<len-dt> xnox I'm not up on it myself.
<xnox> len-dt: tell me about it.... neither am I.
<len-dt> xnox, I can make three edits to a config file commit it and beta 1 will work. That I know how to do :)
<xnox> len-dt: go for it.
<len-dt> xnox, on my way.
 * skaet just went and enabled the Upgrade tracking tests.
<cjwatson> skaet: done
<cjwatson> (purge-old-images disabling)
<Daviey> skaet: I'd quite like to get a new maas upload into beta.
<Daviey> it's on the cd.
<skaet> thanks cjwatson
<Daviey> skaet: do you hate me for that? :)
<skaet> Daviey, have you added it to the pad with a bug number?    what's it affecting and is QA ok with retesting it?
<skaet> :)
<Daviey> skaet: no
<skaet> hmm... no to pad/bugnumber,  no to QA being ok.  ?   correct interpretation?
<Daviey> correct. :)
<Daviey> skaet: it was just put my way.
<xnox> len-dt: xfconf-query -c thunar-volman -p /automount-drives/enabled -s true or false
<xnox> len-dt: can you test it locally with a usb stick and check if (i) it prevents auto-mounting (ii) changes the xml settings same way you wanted to do it (iii) that xfconf-query is available on affected images (xubuntu, lubuntu, ubuntu studio?! others?!)
<xnox> len-dt: and then maybe we can add it to the ubiquity upload which will be done soon for the respins.
<cjwatson> xnox: FYI you don't *have* to wait for partman-auto-lvm to be published, it's just easier
<xnox> yeah...
<cjwatson> You can: cd d-i; mv manifest manifest.old; rm -r source/partman-auto-lvm; dpkg-source -x /path/to/partman-auto-lvm.dsc source/partman-auto-lvm; ./update-control; ./update-changelog
<xnox> cjwatson: so xfconf is seeded on all those XFCE~ish images. worth a try?
<cjwatson> I've got a Xubuntu image here
<len-dt> xnox, cjwatson ubuntustudio-default-settings is commited I need someone to release it. I normally ask micahg , but his nick says away
<cjwatson> Let's see
<xnox> cjwatson: yeah, i was doing that when testing my 'local' udeb packages.
<plars> skaet: as far as I've heard, only desktop is requiring a respin at this point, but the MAAS update would require a server respin
<cjwatson> len-dt: I think a Ubiquity change would be lower net risk, if we can manage it
<plars> I'm not sure who tests maas, I think server team handles that part
<cjwatson> But if you think that's an appropriate *permanent* change for studio then I could upload that for you
<plars> but if we respin server we'd have to retest them all
<cjwatson> If you gave me the URL
<skaet> Daviey,  will you please put a bug number on the pad in the under consideration, and mark the images affected.   Right now server testing is mostly done, and need to understand the tradeoffs a bit better.
<plars> it would probably need to be really convincingly bad to warrant a respin late on a Tuesday
<xnox> len-dt: i don't think you want to disable automounting in live-cd mode permamently, because it is useful to plugin in stuff during live session for testing e.g. photo cameras.
<len-dt> cjwatson, https://code.launchpad.net/~ubuntustudio-dev/ubuntustudio-default-settings/UbuntuStudio. Having something automount while recording could be bad too.
<skaet> plars, understood.
<len-dt> most of the auto mounts are turned off already
<xnox> plars: for what it's worth parman-auto-lvm and oem-config packages do go onto server CDs, while they shouldn't change anything on the server CDs , it is a different package version....
<xnox> len-dt: ok.
<xnox> are xubuntu folks here? cause they also reported thunar misbehaving, e.g. during manual partitioning.
<plars> xnox: but there's no need to respin server for them at this point as I understood things
<xnox> plars: correct.
<Laney> indeed, we haven't been caring about that
<len-dt> xnox, cjwatson fixning ubiquity is beyond my talents right now. I agree it needs to be done though.
<cjwatson> OK, let's just change u-d-s for beta-1 then and defer the ubiquity change
<cjwatson> len-dt: I'm fixing up the bug task so that you don't claim to have already done it, then :-)
<len-dt> No problem...
<cjwatson> len-dt: Uploaded
<len-dt> cjwatson, Thank You.
<cjwatson> ^- somebody else please review
<stgraber> cjwatson: doing
<skaet> cjwatson,  what is the difference between lubuntu and lubuntu-preinstalled on the rebuild set on the pad?  I'm not seeing what lubuntu-preinstalled corresponds to on the iso tracker
<Laney> http://cdimage.ubuntu.com/lubuntu/daily-preinstalled/current/
<Laney> it appears not to post
<Laney> cruft?
<skaet> also not sure why we're building mythbuntu - its not part of 12.10
<xnox> ogra_: ^^^^ preinstall images are cruft?
<Laney> mythbuntu is likewise cruft - remove it
<skaet> ogra_:  ^,  what xnox said.   You releasing this for beta 1
<Laney> and from crontab too please
<skaet> Laney,  not so sure about the crontab for mythbuntu,  thought the agreement had been reached to keep the dailies going.
<Laney> really?
<Laney> fair enough if that's what you want
<skaet> we just were not publishing as part of development releases.
<Laney> i suppose that's why I put it in the pipeline though; I constructed it from what was being cronned
<cjwatson> skaet: No idea, sorry
<Laney> on the expectation that daily builds match what we want to release
<skaet> Laney,  not quite,  some arches we don't publish
<cjwatson> If we don't keep the Mythbuntu dailies going, we'll have to fix 18 months of accumulated problems at the start of the R cycle
<skaet> cjwatson,  its ok,  Laney pointed me at it,  its ac100+armhf - am moving it to arm specific builds.   waiting to hear from ogra_ if it needs to be on the iso tracker for community testing or not.
<cjwatson> I thought I asked for this to be a requirement when the Mythbuntu LTS plan came up before the TB
<skaet> cjwatson,  that matches my memory.
<Laney> sounds good
<Laney> a comment then ;-)
<xnox> skaet: I think I saw ogra_ asking stgraber to add ac100+armhf to the isotracker for desktop testing (it's ubuntu desktop, but using lubuntu due to lack of graphics power)
<Laney> .
 * xnox s/R cycle/T cycle/
<ogra_> skaet, would be nice to hav, but its lubuntu anyway now
<skaet> gilir,  phillw - is there someone lined up to test it?
<skaet> s/it/lubuntu ac100+armhf/
<ogra_> skaet, i will test it
<skaet> ogra_, akc.
<ogra_> (as usual)
<ogra_> i'll ask community people too for additional testing indeed :)
 * ogra_ is off for the evenin
<ogra_> g
<phillw> ogra_: thanks, I know one of the lubuntu devs has arm hardware - Nicholas has already been in touch with him, but his free time is very limited and cannot commit to testing on a regular basis.
<skaet> phillw,  its not on the iso tracker right now, but will be added later today.   Please ask anyone able to test to consult http://cdimage.ubuntu.com/lubuntu/daily-preinstalled/current/ for now.
<ogra_> phillw, well, that build is for a specific netbook, but there is a community of users that are also willing to help
<phillw> skaet: I'll give Jonathan a ping
<ogra_> anyway, really out now :)
<phillw> he's the only one who came forward when I asked our mailing list for those who have ARM hardware.
<phillw> skaet: balloons is the one holding the list, AFAIK
<skaet> phillw, ack.
<skaet> Laney, can your review http://pad.ubuntu.com/ubuntu-release to make sure I've got the brackets correct (see Revised section,  I left the originals intact)
<skaet> ?
<stgraber> xnox: yeah, it's on my todo
<Laney> skaet: what's the first lot?
<skaet> DESKTOPS (no arm, but powerpc):
<Laney> and actually I'd probably rather someone who will be up runs these respins
<Laney> oh hang on
<skaet> Laney,  ok,  I'll handle it.
<Laney> you put an ARM: in the first set
<Laney> but that's core
<skaet> see lower down
<skaet> Revised version
<Laney> yes, I get it, but it looked like the first lot had been changed too
<skaet> yes,  my bad
<skaet> I started to change there, and decided best to leave those completely alone for now.
<skaet> (didn't undo the print statement)
<Laney> I think you might as well keep core separate; doesn't take much time
<Laney> otherwise I can't spot anything, but it's hard to without running it
<xnox> ^ fixes respin triggers #12, #14
<Laney> hoho, /me just went to ping about ^
<Laney> then it was in queue "27 seconds ago"
<Laney> stgraber: would you care to review it?
<stgraber> Laney: can do
<Laney> thanks
<xnox> Laney: can I go to the pub now then ;-) wel... tescos to get crisps =)
<Laney> no, you can go to your local independent store :-)
<xnox> i don't think respin trigger #13 will make it at all. As the current fix is incomplete.
<xnox> Laney: they are rip off 24h corner shops
<xnox> I am in London remember ;-)
<xnox> I'll wait for review/approval. In case it needs fixing.
<xnox> it's massive because of translation updates dump....
<stgraber> xnox: there's that usual tzsetup template diff... probably because your system wasn't clean when building the source package...
<stgraber> I've seen that a few times and it doesn't seem to be a problem, so will ignore, but that's an extra delta making the diff harder to read...
<xnox> stgraber: i did clean the tree twice and once after a build and both times they came out with it.
<xnox> stgraber: i wonder if the .28 was dirty
<stgraber> xnox: could be
<stgraber> I usually do a bzr push to another directory, then build from there to avoid it
<xnox> stgraber: it gets rebuild / re-sorted anyway
<xnox> stgraber: i see... will remember to do that.
<stgraber> changelog is missing mention of test_misc being updated
<bjf> ls
<balloons> cjwatson, when you get a moment, I'd like to chat about how ubiquity uses the network during installation
<stgraber> anyway, rest looks good and matches changelog, so accepting
<xnox> stgraber: that entry is not under my name
 * xnox is whistling like nothing happened
 * xnox \0/
 * skaet starts waiting for the publishing....
<stgraber> bumped the score for armhf and powerpc so we don't have to wait 3 hours for them to build
<skaet> thanks stgraber
<phillw> skaet: if gilir does appear can you let him know, he's active as there are bug emails coming in from him. I'd like him to be told before the email goes out :)
<skaet> phillw,  I'll ping gilir before I start off the rebuilds, and mark them on the tracker then.
<phillw> skaet: he'll be okay, it is a courtesy I would afford our head of dev :)
<phillw> skaet: you have mail
<kenvandine> ubuntu-wallpapers included a wallpaper that wasn't actually submitted by the original creator, bug 1045841
<ubot2`> Launchpad bug 1045841 in ubuntu-wallpapers "Ownership of Blue Dandelion image cannot be confirmed so it must be removed from 12.10 release" [Undecided,New] https://launchpad.net/bugs/1045841
<kenvandine> i have the package prepared removing it, should i go ahead and upload? or wait until after beta1?
<kenvandine> i'd like to get it in before b1, so we don't end up with the image in b1
<kenvandine> skaet, ^^
<skaet> kenvandine, go ahead.  Ill wait for it.   Less problems long term
<kenvandine> indeed
 * skaet still waiting for ubiquity on powerpc and armhf
<skaet> stgraber, slangasek if either of you is around could you review ubuntu-wallpapers please?
<stgraber> skaet: sure, will do
<skaet> thanks stgraber
<skaet> Riddell,  [15] is already under rebuild triggers,  why add it again in under consideration section on the pad?
<iulian> highvoltage: zentyal: I'd appreciate it if you could provide something more useful than that, preferably some logs that show that it is indeed a low-risk update.
<stgraber> kenvandine, skaet: accepted
<skaet> thanks stgraber
 * skaet sees that arm is now finished and published,  still waiting on powerpc for ubiquity :P
<kenvandine> stgraber, thanks
<Riddell> skaet: mm I don't remember adding it twice
<Riddell> feel free to tidy up
<skaet> Riddell,  ok.  thanks.
<highvoltage> iulian: ok
<iulian> highvoltage: If something goes wrong with zentyal, then I shall blame you. I don't usually accept FFes just because the package doesn't affect anything else.
<iulian> highvoltage: If you have logs on the way, then please attach them to the report anyway.
<highvoltage> iulian: I forwarded your message on to bencer. I don't like responsibility if I can avoid it so maybe I'll just delete my bug comment to be safe :) (before I have iulians chasing me in my dreams)
 * skaet grumbles that universe ghc is building on powerpc, and still waiting for ubiquity to start.  :P
<skaet> Daviey,  why is maas going into quantal-release/main with binaries right now?
<iulian> highvoltage: I've told him earlier, see above. He didn't seem to do what I've told him to do. :(
<iulian> Ahh, GHC! When did that get uploaded? \o/
<iulian> skaet: It's not a very small package so it takes a bit of time to build. You might want to make sure that ubiquity is next in line.
<iulian> highvoltage: Do you know if bencer has the packages ready for upload? If he does, then it's just a matter of clicking on a few things to attach the logs.
<skaet> iulian, yeah,  ubiquity should have been before it.  Scores for ubiquity were bumped 1.5 hours ago, so must have just missed it.  ubiquity is next.   Any feel how long it will take?
<skaet> s/it/ghc/
 * iulian checks the build log.
<iulian> skaet: It finished on powerpc. It's still building on arm*.
<stgraber> slangasek, skaet: regarding the oversizedness warning on the tracker, my plan is to simply implement it in post-qa on nusakan and pass it in the note field. That way it'll show up in the e-mail sent out to testers and at the top of the build page on the tracker.
<skaet> stgraber,  sounds good to me.
<skaet> balloons, plars:  will the proposal above work for you?  ^
<Daviey> skaet: hey.. it's an opportunity target now.
<balloons> hmm.. will cdimage show a warning also?
<skaet> balloons, cdimage page should be unchanged
<stgraber> balloons: it always did
<stgraber> I'm actually planning on checking the file generated on cdimage and use that to add a warning to the build (well, checking for the .OVERSIZED file on the fs)
<plars> skaet, stgraber: sorry, not familiar with this. Is this concerning the bigger images in quantal? or are we adjusting the size check so that it now only does the OVERSIZED if >800MB?
<skaet> plars,  just making it more visible on the iso tracker what should occur when OVERSIZED is triggered.
<stgraber> plars: the limit was already changed by slangasek, we're just adding an extra warning on iso.qa.ubuntu.com if an image is oversized so we don't miss it like we did for 12.04.1
<balloons> stgraber, right.. just double-checking..in other words, it will be more of a warning now :-)
<stgraber> balloons: right
<plars> sounds useful :)
<iulian> skaet: It should be finishing on arm* in roughly 20 minutes by the looks of it.
 * skaet happy that ubiquity now building on ross
<skaet> thanks iulian,  its off powerpc now,  which was the blocker I was waiting to resolve.  :)
<iulian> Great.
<bencer> iulian: should be ready on my ppa, let me check
<bencer> iulian: https://launchpad.net/~bencer/+archive/zentyal-2.3-p/+packages ready there
<iulian> bencer: Brilliant.
 * iulian looking.
<highvoltage> iulian: what kind of logs do you mean? package update logs from apt?
<iulian> bencer: What version do you want to get in? Those logs are from March.
<iulian> highvoltage: And build.
<iulian> bencer: 2.3.3 is already in quantal.
<bencer> iulian: https://launchpad.net/~bencer/+archive/zentyal-2.3-p/+packages packages are ready there
<bencer> pending to upload as commented in that ffe: zentyal-users, zentyal-squid, zentyal-samba
 * iulian is confused.
<highvoltage> bencer: hmm, those packages were all published in that ppa in march, are you sure that's the right link?
<micahg> they're also all targetted at precise
<bencer> sorry, wrong link
<bencer> https://launchpad.net/~bencer/+archive/zentyal-2.3-q/+packages
<bencer> with the q :)
<iulian> bencer: So, 2.3.12 is the version you're planning to get in, correct?
<iulian> I can't see that in the bug report.
<bencer> iulian: yes, i didnt specify that on the bug report, right
<bencer> we plan to upload final zentyal 3.0 packages before the final freeze
<iulian> Could you please edit that bug report saying that because I'm getting quite confused here.
<bencer> iulian: sure
<bencer> iulian: basically, this new version contain all the important changes from the version in precise
<highvoltage> bencer: ah, I thought your original plan was to upload an rc version of 3.0 and then when the final version is released upload that?
<bencer> now zentyal is frozen, we are finish bugfixing, so if we upload newer pakcages later, before the final freeze, we will get more bugfixes
<iulian> bencer: Whilst you're on it, please have a look at https://wiki.ubuntu.com/FreezeExceptionProcess.
<bencer> highvoltage: right, our release is 13th september
<bencer> iulian: yes, 13th september if before the final freeze
<bencer> but i want to upload this now, so the new upload later on is smaller
<bencer> iulian: do u want me to explain this on the ffe then?
<iulian> bencer: I think it's better to just wait for the final one. If it's on the 13th, then it's all good.
<bencer> iulian: i would prefer not... this is working now
<bencer> dont know if will appear more bugfixes or not
<iulian> bencer: Uploading this now and then the final one on the 13th makes no sense.
<bencer> iulian: my point is if we upload the final on 13th, the diff between precise and that upload, will be bigger than if we upload now an already frozen and working version
<bencer> and then just a small diff on top of that containing only bugfixes
<iulian> bencer: Well, it's going to be the same thing, isn't it?
<bencer> iulian: the new upload, if it happens, will only contain bugfixes
<iulian> bencer: So, this version contains some new features and after that it's just bugfixes?
<bencer> iulian: new features, that's why i dont want to wait more
<bencer> samba4, kerberos
<micahg> iulian: to be fair, AIUI, the earlier the better for FFes, right (assuming the rest is just bug fix)?
<iulian> OK then. Please follow the instructions from that wiki page I've given you earlier and you can also paste this log in to the bug report. If everything's fine, then we shall get this version in and then the next one will just contain bugfixes which you can just upload without needing an FFe.
<bencer> micahg: yup, that was my thought
<tumbleweed> erm, what did I miss? nobody approved the maas FFe that I saw
<bencer> iulian: the thing is the previous zentyal-samba was samba3 based, and this new one is samba4 based
<bencer> and i'm afraid there is no migration path
<iulian> micahg: Indeed.
<iulian> bencer: OK, please give as much information as you can in the bug report and I shall go through it.
<bencer> iulian: i've commented the lack of migration path, and why, going to add what we said about uploading later (eventually) a bugfixing only upload
<iulian> bencer: If it's just a bug fix upload, then you don't have to talk to the release team about it. In the case that you're not certain whether it's a bug fix release or not, then the recommended way to solve this is to get in touch with -release.
<bencer> iulian: ok, understood, but i need this ffe now as this new upload contains new features, right?
<Laney> heya
<iulian> bencer: Yes, it's new features all the way down which is why I hesitate in letting it in. Could you also mention the version you'd like to get in? There's an edit button so you don't have to comment every time you want to add something.
<iulian> bencer: Have you seen that wiki page I've given you 20 minutes ago? That explains what you have to do.
<bencer> iulian: yes, i know we are late, but we discussed about this in the uds, was within the edubuntu plans and we didnt upload before because was not finished upstream
<bencer> and also leaving like it is now is not an option and current zentyal-samba version wont work with current zentyal-common and zentyal-core versions
<tumbleweed> bencer: if you can't get an upload in before FF, you can file an FFe in advance
<Laney> maas> indeed
<Laney> was that discussed somewhere out of band?
<tumbleweed> (and yes, that is preferable to intentionally landing a half-finished thing before FF)
<tumbleweed> Laney: I commented on the bug
<bencer> tumbleweed: yup, i realized this for the next time :)
<Laney> tumbleweed: I don't see it
<iulian> bencer: If I accept it now, do you have the packages ready for upload?
<tumbleweed> Laney: e-mail probably still in flight
<Laney> ah
<iulian> bencer: Just to let you know, I'm still trying to gather more information about this. ;)
<bencer> iulian: so let me clarify, missing stuff: information of version we want to upload, anything else?
<iulian> If I'm being too picky here, then please jump in. tumbleweed, Laney. ^
<iulian> bencer: See the wiki page.
<Laney> I'm not following it iulian, sorry
<iulian> bencer: That wiki page explains every step that you have to do.
<bencer> iulian: yes, i know, but i agree some steps doesnt make sense on this case, because for example a debdiff would be huge containing all the new features
<phillw> skaet: you have a reply. As I knew, Julien said okay.
<skaet> phillw,  ok.
<phillw> when do you expect the iso's to land? I know there is a large queue of builds.
<skaet> phillw,  looks like those last bits have landed and published.   I'll be starting off the builds in the order on the pad.
<tumbleweed> bencer: just because it's huge, doesn't mean you shouldn't attach it
<tumbleweed> bencer: I've looked at your FFes once or twice, but there really isn't much there to go on. See the FFe page for a list of useful information to include
<phillw> permission to let people know ARM will be arriving?
<stgraber> skaet: http://iso.qa.dev.stgraber.org/qatracker/milestones/219/builds/16291/testcases <- is that visible enough?
<skaet> phillw,  its not on the tracker yet.   But I'll finish sorting it as soon as I mark the others as rebuilding.
<plars> stgraber: bold and/or red letters would probably be nice to make it really stand out
<skaet> stgraber,  yup.   feel free to make it red too ;)
<phillw> kk
<plars> blink tags, popups, nyancat music... :)
<stgraber> skaet: yeah, need to figure out how to make it red, pretty sure the current Drupal filter won't let me use style="color:red"
<stgraber> skaet: well, I can do bold easily, will go with that for now ;)
<stgraber> can someone from ubuntu-archive land: https://code.launchpad.net/~stgraber/ubuntu-archive-tools/add-note-to-tracker/+merge/122761 ?
<stgraber> this is required for my next change to nusakan
<knome> xubuntu alternate updated?
<knome> i thought those were dropped :)
<slangasek> Ubuntu alternate is dropped; other flavors make their own decisions about which images to release
<Laney> not according to the manifest
<knome> slangasek, we did, and i sent that information to skaet
<slangasek> ah
<Laney> although that still also says ubuntu alternates on ppc :-)
<knome> not pointing fingers, just wondering :)
<stgraber> Daviey: looks like you manually commited something on nusakan (etc/notify-addresses) preventing pulling the new revisions of cdimage-deployment... I "fixed" it by uncommiting your change for now
<stgraber> Daviey: looks like you may have commited directly to /srv/cdimage.ubuntu.com instead of pushing to cdimage-deployment, then doing "bzr pull" in /srv/cdimage.ubuntu.com
<stgraber> skaet: landed the change manually on nusakan for now as I need to check that the path I'm checking is correct
<Daviey> stgraber: oo,err
<slangasek> knome: ok, doesn't seem to have percolated through the system yet.  But since you're listed on https://wiki.ubuntu.com/QuantalQuetzal/ReleaseManifest as the contact, I guess I can take your word for it and drop them now :)
<stgraber> skaet: I'm not expecting anything that may affect the beta builds, worst case I'll just get a debug message in the log that I can use to fix my change
<knome> slangasek, yep, sure you can. if you ask anybody else on our community, they will tell to ask me :P
<tumbleweed> slangasek: oh, btw, re the zombie bug 990740 which you also replied to a bit. I suspect it's just collecting everyone who had a broken upgrade, as this failure is a symptom of their recovery attempt
<ubot2`> Launchpad bug 990740 in python-defaults "upgrading from lucid to precise fails" [High,Confirmed] https://launchpad.net/bugs/990740
<tumbleweed> one person replied to me privately, saying his system was so b0rked that apport wouldn't work. And it wouldn't suprise me if that was the case for most of them
<dobey> anyone on here moderates ubuntu-translators@?
<slangasek> tumbleweed: but there could be several reasons for apport not working... since python is implicated and apport is written in python
<tumbleweed> yeah
<knome> dobey, ubuntu-translators list run by david.planella at ubuntu.com
<tumbleweed> I think I'll stick a big notice at the top of the bug asking people to create a new bug, and attach /var/log/update-manager, if apport odesn't work for them
<dobey> ah
<dobey> thanks knome
<plars> so the status of alternate as "still being decided" on https://wiki.ubuntu.com/QuantalQuetzal/ReleaseManifest
<knome> dobey, np. there might be other *moderators* though, but that's the best way to get a hold of them
<plars> that is decided as no longer supported for quantal on all archs now?
<plars> is that correct?
<dobey> knome: right, but he's away for the evening i'm sure :)
<plars> or is it happening?
<slangasek> stgraber: branch landed
<plars> I'm asking about Ubuntu specifically btw
<plars> not k/l/x/etc
<knome> dobey, dunno. :) doesn't seem to be on irc at least though, but i don't think he is always anyway
<slangasek> plars: I only see that written for Kubuntu
<slangasek> it has been decided for Ubuntu - alternates are being dropped
<dobey> knome: right, and he's in europe. so it's almost wednesday for him now :)
<knome> dobey, yup. :)
<plars> slangasek: thanks, just verifying
<stgraber> slangasek: thanks
<dobey> knome: anyway, it's fine. just wanted to prod someone to get my mail through, so i can stick the URL on this FFe bug :)
<knome> dobey, or you and register to the list and resend
<dobey> knome: right; i'll just wait :)
<knome> dobey, good luck in waiting :)
<slangasek> knome: and xubuntu alternate is dropped dropped, right, not "we'll see if anyone complains after beta1" dropped?
<knome> slangasek, hehe. thanks :)
<cjwatson> stgraber: I didn't mention test_misc because it went with the parenthesisation fix - I don't believe in listing changes file by file in general in debian/changelog
<cjwatson> stgraber,xnox: the way to avoid the tzsetup diff is to do debian/rules update (or equivalent) last, after any test runs
<stgraber> cjwatson: ah, ok. Looking at the diff it didn't immediately strike me as related, that's why I mentioned it.
<stgraber> cjwatson: good to know for tzsetup, will save me the extra bzr branch before building the source package
<cjwatson> stgraber: one of these days I might fix the bug that causes it, but people only ever complain about it around milestone prep :)
<stgraber> skaet, slangasek: tested the post-qa change as much as I can without actually getting an oversized image, so far it looks good. "Hopefully" we'll be getting an oversized image soon after the freeze so I can actually see it work :)
<cjwatson> stgraber: test_misc was TDD and everything ... ;-)
<stgraber> cjwatson: hehe, because apparently that's the only time people actually look at the diff... ;)
<slangasek> stgraber: I suppose you could touch a .OVERSIZED file to test it by hand? :)
<cjwatson> exactly
<stgraber> slangasek: if we don't get any oversize in b1, I'll simply lower the limit for a product on Friday and trigger a rebuild to make sure everything works ;) just didn't want to give someone an heart attack by doing it today :)
<stgraber> actually, looks like kubuntu and xubuntu have some oversized daily-live, that should do the trick ;)
<cjwatson> balloons: well, basically it configures apt at a certain point during installation, and from that point on presence of network will mean that it'll try to get packages from the network; in some cases this can change behaviour a bit
<cjwatson> balloons: there are other things such as geolocation, but apt configuration is the main thing that tends to permute presence of bugs
<balloons> cjwatson, yes, I did a little testing after I found that funny behavoir. And it does indeed go after packages if it detects a working connection
<cjwatson> balloons: this is after copying the squashfs - we're talking things like language packs, sometimes hardware-specific packages, etc.
<balloons> I wasn't sure if there's a specific bug in here.. perhaps a wishlist or clarification.
<cjwatson> balloons: in general we consider it a bug if it breaks either with or without, but it's not a bug that behaviour may differ
<balloons> cjwatson, yes, in my case I'm wondering if it will ever continue on
<balloons> aka, I have local network only, not external
<cjwatson> if you don't have network, bits of the desktop may later report that you don't have full language support, for instance
<cjwatson> sounds like you have a buggy firewall that drops packets rather than rejecting them
<cjwatson> Don't Do That
<balloons> silent dropping is fun :-)
<balloons> but no, I don't think that's the case here.. it might be
<cjwatson> if it rejects apt will move on as it's supposed to.  if it drops, apt can't tell the difference between crap firewall and just slow without a long timeout.
<balloons> but it should eventually continue on by itself, yes.. it's all up to apt to finish
<cjwatson> that of course assumes that it's stuck in apt
<cjwatson> you should be able to tell from the tail of syslog
<balloons> cjwatson, yes, it was stuck in apt
<skaet> knome, ^ new images up now (no alternates)
<stgraber> skaet, slangasek: http://iso.qa.ubuntu.com/qatracker/milestones/232/builds/22538/testcases <- looks like the code is well working, that's the first detected oversized image
<cjwatson> balloons: https://wiki.ubuntu.com/NetworklessInstallationFixes - historical context
<cjwatson> AFAIK that was all implemented years ago but perhaps there's been a regression in some edge case
<skaet> stgraber,  looks good.    lets see if knome wants to do something about it, or we release note Xubuntu desktop being oversized.
<knome> skaet, i don't think there is anything for us to do now, so let's release note it being oversize
<skaet> knome,  ok.
<balloons> cjwatson, http://paste.ubuntu.com/1186023/
<balloons> it *seems* like it hung for 10 mins? I can definitely re-test to check things out.. I will know that I have the full context and understanding of course
<xnox> stgraber: CSS love =) warning should be *red* color
<stgraber> xnox: yeah, as I said earlier, the Drupal filter used for this field doesn't really allow anything fancy
<stgraber> xnox: though as it's an admin-only field, I may just switch it to full-html in the next release
<Laney> the colour really interests people
<balloons> in that log, I eventually noticed and hit skip.. it finished rather quickly after that
<cjwatson> balloons: That does look rather like an apt regression - maybe it specifically fails to handle the case where packets are dropped on the way to your nameserver?  (speculation)
<cjwatson> Well I mean it handles it but it doesn't do the multiple-consecutive-timeout avoidance thing
<cjwatson> AFAICS
<balloons> right.. ok. Well O
<cjwatson> That really is a badly hosed network though :)
<balloons> I'll play around a bit more and try and see if I can track down what exactly isn't being well handled.. I'll test some various network configs and see how apt does
<balloons> and yes, it definitely is mangled :-)
<cjwatson> Definitely something at name resolution time anyway
<balloons> It's just interesting because I'm surprised it tried to hit the network.. in the beginning it wouldn't let me check the download updates (since there's no connectiity)
<balloons> I get it now, your simply issuing an apt-get update, but it contains the full sources.list
<cjwatson> Right, that's deliberate
<cjwatson> We don't want to be in the situation where you never get updates because you weren't on the network when you installed
<balloons> could you not disable it if no network is present?
<cjwatson> Not a good idea
<cjwatson> See above :)
<cjwatson> apt is supposed to quickly continue
<balloons> lol.. yes, I'm assuming it is your sources.list
<balloons> you wouldn't want to enable the full list @ the end
<cjwatson> The installer shouldn't attempt to work around it failing to do so - that creates other problems
<cjwatson> We agreed this all years ago :)
<balloons> fair enough..
<cjwatson> "download updates" is a different thing
<cjwatson> but usability means we aren't allowed to give a full explanation in the UI :P
<balloons> cjwatson, what do you mean?
<balloons> your prevented from giving technical details?
<xnox> balloons: the fact that we are hitting the network and trying is "internal implementation detail"
<xnox> balloons: usability is all about little white lies and cheats =)
<xnox> balloons: for the sake of sanity
<cjwatson> balloons: I'm being cynical for comic effect
<balloons> xnox, haha.. well thank you cjwatson and xnox. I'll let that one lie for now ;-) I appreciate the insight and background on the networking stuff.. I'll let you know if anything comes of it
<xnox> balloons: i am interested to know what is the User Experience like with Desktop CD, Networking Enabled, But proxy settings required. You may not use Live Session CD, only Install now mode.
<balloons> xnox, sure I can test that.. proxy was on the list after today's experience :-)
<xnox> balloons: and not transparent proxies something with username and password. Not sure if you can set that up.
<cjwatson> balloons: But I think "Download upgraded versions of packages in the live filesystem, in order that they will immediately be ready to upgrade without further download time after installation; we don't install these upgrades immediately during installation because that would complicate an already delicate part of the installer and increase the chance of unrecoverable failures" would likely fail any reasonable usability test
<xnox> balloons: because alternative CD throws a dialog in your face to setup proxy, but desktop cd might be more fun.... and if proxy is not setup at install time try to do it after the install is complete =)
<cjwatson> In any event the installer used the network long before the "Download updates" feature was implemented
<xnox> cjwatson: followed by "If and only if you like formal logic, you may submit a bug report with full apport attachments."
<xnox> ;)
<balloons> lolol
<cjwatson> I still want to require a Nethack ascension before you can complete installation
<cjwatson> It would cut down on those annoying bug reports
<Laney> The Amulet of Shuttleworth
<cjwatson> new player class: Developer
<balloons> am I allowed to play in 3d, or do I have to play old-school inside a term window in the installer?
<cjwatson> old-school ASCII is the one true way
<Laney> telnet nethack.alt.org. no other way.
<xnox> balloons: only if you have triple core cpu, llvmpipe works and you will see flickering at the most crucial points.
<cjwatson> Meh, I would if my network was about 5x more reliable
<balloons> skaet, notice what the release teams turns into while awaiting builds? :-)
<skaet> balloons,  more likely a function of the time and that they're still awake...  ;)
<balloons> as long as your not blaming me :-)
<xnox> balloons: i like your spelling and grammar there =) keeps me on my toes guessing
 * xnox ponders where my upload is
<balloons> xnox, I have this horrible habit of typing 'your' instead of 'your are'.. I don't even notice anymore :-)
<balloons> just enunciate it :-)
<xnox> here it is =) (well the top one)
<Laney> xnox: Is that diff right though?
<Laney> That's an update for conjunction, but I'd think the test wants disjunction, no?
<xnox> Laney: let me look at it again.
<xnox> Laney: are you saying ORs are missing
<Laney> for or you have to duplicate the <match> and change the test
<Laney> I showed you a diff like that a while ago if you remember
<xnox> vaguely yes.
<Laney> see comment #23 in that bug
<xnox> Laney: can you reject those two uploads then?
<Laney> are you mailing him / commenting on the bug?
<xnox> fonts-droid & fonts-unfonts-core
<xnox> Laney: yes, I follow up since I started sponsoring it.
<Laney> ok
<Laney> make sure they're being forwarded upstream too please
<xnox> Laney: he did file debian bugs.
<xnox> Laney: with patches that will now need resending.....
<Laney> maybe the fonts-droid one is right?
<xnox> Laney: not the second chunk.
<xnox> the first one is maybe ok.
<Laney> ah, that one is eq, indeed
<Laney> ok, uploads go bye bye
<xnox> Laney: merci.
<Laney> good job we had a freeze eh
<xnox> I'm calling it a night =)
<xnox> cause if I can't parse boolean logic..... it's really not the best time to code =)
<slangasek> || 1
<xnox> slangasek: hehe
<NCommander> Daviey: did you approve the maas upload to the archive?
<Laney> NCommander: roaksoax said so (https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1044367/comments/6)
<ubot2`> Ubuntu bug 1044367 in maas "[FFe] Feature freeze exception for maas in Quantal" [Undecided,Fix released]
<NCommander> Laney: yeah, I'm trying to figure out why. That's a massive upload during a period when we want the archive more or less in one piece. It doesn't seem like it was critical enough to warrent an exemption for beta freeze
<Laney> I was under the impression that it was nacked for the beta earlier today actually
<NCommander> Laney: well it introduced a new package so it went into the binNEW queue, so it can still be rejected
<NCommander> I get really anstys on adding new packages to images when we are in bloody freeze
<RAOF> Primary?
<cjwatson> Archive, as opposed to partner.
<RAOF> Ah.
<Laney> that appears to be FFeless?
 * Laney gives up and goes to bed
<Laney> I just walked laptop-first into a doorframe
<slangasek> NCommander: we certainly shouldn't be rejecting binaries from the NEW queue due to freezes, that just makes more work for people later
 * xnox giggles at Laney 
<NCommander> slangasek: I rather not give free pass to people violating freezes. Its safer to do a rollback upload especially since the new upload adds a package
<slangasek> NCommander: if there's a rollback, then yeah, a reject would make sense.  However, you're saying Daviey approved the upload, so it doesn't sound like any freezes have been violated here.
<NCommander> slangasek: I don't know if he did. There is a comment that he did, but there's no official ACK on the bug
<skaet> slangasek,  yes, it suddenly appear, no FFE in place or referenced,  no risk assessment,  QA not lined up for retesting,  so a bit worrying all around.
<slangasek> NCommander: well, someone also has to have accepted the package?
<NCommander> slangasek: and given what the upload is, a NACK is more apprioate given its an entirely new version
<cjwatson> Daviey didn't explicitly mention it on IRC, but talked about it in a way that indicated that he'd approved it.
<cjwatson> s/it/an approval/
<NCommander> I consider it very concerning that an upload is approved with a complete disregard to our normal FFE processes.
<cjwatson> I haven't looked at the FFe so can't really speak to it; my only comment is that I don't remotely buy the "contains new binary packages => automatically requires freeze exception" line of argument
<NCommander> cjwatson: that gives me pause. What concerns me is its not a minor fix, its an entirely new version of MAAS that was uploaded
<cjwatson> Doesn't seem any more valid to me than the presumption that new upstream releases are automatically more problematic than new packaging revisions, which is a notion I think we disposed of a while back
<cjwatson> Yeah, that part I can't speak to
<xnox> IMHO cherry-picking is more problematic than taking new revisions/releases. As that really makes you run a forked code base, that nobody else is running.
<NCommander> cjwatson: I mis-spoke. A new upstream version and/or new binary is not grounds for an auto-FFe REJECT, but I damn well want to see why it was done
<NCommander> xnox: unless it was a soul-crushing critical bug (which this was marked as even though it doesn't seem to meet the criteria), it could have waited 'til friday
<slangasek> wanting to see why it was done is an entirely different thing than proposing to roll it back after the release team member who approved it is EOD, which is what it sounds like to me
<cjwatson> I certainly have no objection to a desire for transparency, indeed
<NCommander> slangasek: because I rather want to avoid having to do respins of all the server images to pick up the new MAAS and invalidate all the testing. If it sits in the queue, and then approved on Wednesday, then we have to fracitically retest everything on Wednesday with no window to get bug fixes in
<xnox> there was chatter about that upload on #ubuntu-server earlier today, but the scrollback is rather incomplete / missing full context about the upload.
<NCommander> slangasek: and MAAS testing isn't trivial since you need to both test the client and server aspects of it and unless you are explicately setup for it, can be a damn well four letter word to do
<NCommander> Now I advocate a binary reject, not because its the easy thing to do, or even the "right" thing to do, but it does avoid the MAAS retesting nightmare. Failing that, then reuploading the old revision and respinning with that (followed by copying the test results to the new images) is the next best course of action
 * NCommander is fully aware rejected binaries go straight into /dev/null
<slangasek> NCommander: and how is it better to reject a binary and force a re-upload, than to either a) hold the binaries in the queue until after beta, or b) accept the binaries without respinning anything?
<slangasek> if there are *any* respins you have to retest anyway
<slangasek> and there's nothing on the pad at http://pad.ubuntu.com/ubuntu-release suggesting maas was considered critical for a respin
 * micahg also wonders why it wasn't uploaded to proposed
<slangasek> I agree that we want more transparency here and that we should revisit why this was accepted when it was (since it doesn't sound like it's critical), but there's no reason to be punitive by rejecting binaries
<slangasek> micahg: why should it have been?  it's arch: all so there's no installability issue
<NCommander> slangasek: fair enough. if MAAS's binaries sit in the new queue until friday, thats satisifactory
<slangasek> NCommander: well, I'm not promising that; we might find that Daviey really does consider this beta-critical.  I'm only saying that a binary reject doesn't make sense to me
<micahg> slangasek: package that affects image that's marked as an opportunity target (last minute respin might not want to take it)
<NCommander> slangasek: I don't want to have to scramble on Wednesday to retest everything
<micahg> IMHO of course since I'm not a release team member
<slangasek> micahg: a) that's not what -proposed is for, b) we already had the option to not take it from the unapproved queue and somebody exercised the option to take it
<jbicha> slangasek: wasn't -proposed also supposed to be used for updates of seeded packages that aren't milestone blockers?
<skaet> gilir, phillw, ogra_ - I've added lubuntu ac100+armhf image to the iso tracker.  Should show up when the next image finishes building.  Please doublecheck that the links are ok.  I went ahead and made the testcases the same as what was used for the ac100+armhf in Ubuntu.   Let me know if it should point to something else.
 * skaet --> dinner and visit with friends,  will check in on the image rebuilds when return.
<slangasek> jbicha: that was the case for alpha milestones with only a soft freeze on the archive... I don't think it was ever explicitly discussed for beta
<micahg> it wasn't which puzzled me slightly
<bkerensa> skaet: Is there a set date for when the ReleaseNotes wiki page is created for a release to begin populating information
<skaet> bkerensa,  I've got most of the template in place already,  just need to clean up one thing for the 12.10 Release Notes.    For the 12.10 Beta 1 release,  use: https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview/Beta1
<bkerensa> Thanks
#ubuntu-release 2012-09-05
<phillw> skaet: do you have a few minutes to spare?
<Daviey> slangasek: Sorry, i've been afk.  It's a well tested upload, that isn't *entirely* beta critical.. as in, does not warrant a respin.  It is an opportunistic include, which cannot impact other testcases.
<slangasek> NCommander: ^^
<slangasek> Daviey: it sounds to me like NCommander's biggest concern was that even taking it opportunistically would be a problem for him on ARM maas validation for beta-2
<Daviey> slangasek: considering the current version in the archive is known not to work, i can't see why it would upset NCommander
<Daviey> note, that rbasak as purely been working on arm support for that upload for the last 2 weeks.
<Daviey> So this one, has a higher chance of some success.. compared to known suckage
<slangasek> ah, well, then I don't know
<NCommander> Daviey: the lack of documentation upsets me. Nowhere at a quick glance can I see that MAAS as it was in the archive was totally broken.
 * NCommander was at dinner
<NCommander> (well, I knew it didn't work on ARM, but I didn't know it was totally foobar'ed
<NCommander> )
<skaet> all builds finished,  lubuntu ac100+armhf image now accessible from tracker.
 * skaet --> zzz
<Daviey> NCommander: The fact that you had no idea it was broken, troubles me more TBH.
<knome> there somebody who could help or point to somebody could help with problems during ubiquity?
<knome> xubuntu is affeted by both bug #924909 and bug #101087 and we think this has something to do with the ubiquity config
<ubot2> Launchpad bug 924909 in xfwm4 "Windows have grey traces in Ubiquity" [Medium,Confirmed] https://launchpad.net/bugs/924909
<ubot2> Launchpad bug 101087 in silva "request for get_ordered_ids()" [Wishlist,Won't fix] https://launchpad.net/bugs/101087
<Laney> knome: you probably meant something else for the second one?
<knome> yes...
<knome> bug #1010487
<ubot2> Launchpad bug 1010487 in ubiquity "Xubuntu - black windows" [High,Confirmed] https://launchpad.net/bugs/1010487
<knome> is there some settings how ubiquity/xfce is run or similar we could look at?
<xnox> knome: #924909 is funny. There is an upstart job which launches ubiquity in the greeter mode. But it looks like the background is not repainted, maybe something needs to be done there to ask thunar to repaint itself?
<cjwatson> bin/ubiquity-dm in the ubiquity source might be worth looking at, assuming this is in the "Install Xubuntu" mode and not "Try Xubuntu without installing"
<cjwatson> You can generally tell whether something's a ubiquity-dm bug by seeing if behaviour in those two modes differs
<cjwatson> (significantly)
<xnox> knome: cjwatson reply is better =)
<cjwatson> We might quite plausibly not be launching some bit of your desktop infrastructure
<Laney> the bugs both confirm that
<cjwatson> I didn't look :-)
<knome> cjwatson, yeah, the grey bits is only in "install" mode
<knome> and probably the other bug as well..
<knome> though somebody reported to have it on "live", but not when running "install" from live
<knome> cjwatson, bin/ubiquity-dm where? :)
<cjwatson> As I said, in the ubiquity source
<cjwatson> bzr branch lp:ubiquity
<knome> oh, right. just woken up.. sorry! :)
<cjwatson> have it on "live", but not when running "install" from live> that sounds confused as ubiquity doesn't run in "live" mode unless you run install ... I suspect they meant "install" mode for the formere
<cjwatson> *former
<knome> yeah.
<knome> probably
<xnox> knome: the second one might be a dupe of bug 744283 but I am not entirely sure. There are changes to two files in that branch (gtk_ui.py & ubiquity.ui you could replace them in place and see if helps, replace on the tty1 and do $ sudo restart lightdm to retest the "greeter" mode)
<ubot2> Launchpad bug 744283 in ubiquity "Steps "Preparing to install" and "Erase disk" are unreadable with high-contrast theme enabled" [Medium,In progress] https://launchpad.net/bugs/744283
<knome> :o
<xnox> we do need consistent terms for "greeter", "try ubuntu" & "install ubuntu". Cause live/alternate are the traditional counter parts =)
<cjwatson> desktop/alternate are the traditional counterparts
<cjwatson> live -> desktop and install -> alternate were simultaneous changes
<cjwatson> I sometimes call them "live session" and "only-ubiquity" modes
<xnox> ok.
<cjwatson> bit jargonish which is why I tend to use the boot menu names when talking to non-ubiquity-developers
<cjwatson> And of course only-ubiquity and maybe-ubiquity are not quite identical.  Terrible naming there
<cjwatson> maybe-ubiquity is the greeter mode (i.e. what you get if you let an Ubuntu desktop image boot without touching it)
<xnox> cjwatson: which are not visible by default & no logo either. See the video from the 924909. Why is there no isolinux ubuntu logo shown?! only unless you click Esc...
<xnox> gray logic ftw =)
<knome> heh
<cjwatson> That video shows the "press key for options" rebus icon
<cjwatson> Which is as expected
<cjwatson> If you don't press a key there, you get maybe-ubiquity mode
<cjwatson> Which I think is what you're calling "greeter"
<xnox> yeah.
<cjwatson> It's sort of an uneasy compromise
<xnox> I think it would be nice to show ubuntu logo & the rebus. But I am sure there are reasons for it =) e.g. wrong resolution, low color depth, etc....
<cjwatson> Design didn't want to show the boot menu by default; I wasn't happy with showing text before we know the user's language
<cjwatson> And yes, the Ubuntu logo is kind of a no-go there because the aspect ratio is very likely to be wrong
<cjwatson> And syslinux is a bit too primitive to be able to do much about that
<cjwatson> At least not while preserving my sanity
<xnox> well remaining sanity bits, need preserving =))))))) totally agree with you there!
<knome> anyway, thanks for the help
<knome> we'll look at this and hopefully fix it soon!
 * iulian is not getting any mails from Launchpad when he comments in bugs where ubuntu-release is subscribed.
<iulian> Any idea why?
<xnox> iulian: what's your bug mail preferences? you can choose not to receive spam about your own updates =)
<iulian> xnox: I've no idea what my bug mail preferences are. :)
<iulian> Where do I check that?
<iulian> It used to work before.
<xnox> iulian: it's somewhere on your personal page http://pad.lv/~iulian ?
<xnox> iulian: also #launchpad support on #launchpad? =)))))))))))) ;-)
<smartboyhw> iulian: Follow xnox's advice and go to #launchpad for Launchpad Mail help:)
<Laney> you don't get your own comments back
<xnox> you can =)
<xnox> I do =)
<iulian> Laney: We used to get them. What happened?
<Laney> eww
<xnox> 1046206 dupe of 1010487 ? I am suspecting a thunar change
<Laney> I see a somewhat relevant sounding setting on http://launchpad.net/~/+edit
<iulian> I cannot remember each bug I commented on and it makes reviewing things a bit harder. :(
<iulian> OK, let's see.
<iulian> I've got the "Send me bug notifications..." ticked already.
 * iulian sighs.
 * iulian goes to #launchpad.
<xnox> jibel: bug 1046175 debdiff attached, fixed in lp:ubiquity . Tested locally created 4 primary, delete 4th primary, create 3 logical.... the partition type is now shown in the create dialog.
<ubot2> Launchpad bug 1046175 in ubiquity "[regression] Manual partitioner only creates primary partitions" [High,Confirmed] https://launchpad.net/bugs/1046175
<xnox> release team please see bug 1046175 and check if you want to: release note it, respin opportunity or trigger.
<xnox> the manual partitioner currently creates only primary partitions. so you are limited to create maximum 4 partitions when starting from scratch. If starting from existing system you can only create (4 - # of existing primary partitions)
<cjwatson> I think that's at least worth uploading so that we can take the decision about whether to respin for it (potentially) in your absence
<cjwatson> Worth noting that many systems have three primary partitions from the factory so it can be very difficult to install at all without using logical partitions
<xnox> ok.
<xnox> in the mean time I will continue on implementing manual lvm controls.
<cjwatson> xnox: Have you tested the behaviour when editing an existing partition as well?
<xnox> cjwatson: yes.
<xnox> although I do not understand why partman decides to check for bad blocks while doing edit =/ remove+add are instant, yet edit are not.
<cjwatson> I wouldn't expect bad blocks checks until you commit
<xnox> edit decided that "previous changes need to be committed", although there were no previous changes (just restarted ubiquity).
<xnox> change 3 partitions / repartitioned.
<xnox> and the primary/logical options are not shown on edits.
 * ogra_ wonders whats the reason that http://iso.qa.ubuntu.com/qatracker/milestones/232/builds/22564/testcases/1167/results tells him the last update was on may 9th 
<ogra_> :P
<ogra_> (read: cant we use sane date strings ?)
<Daviey> +1
<xnox> ogra_: drupal has no clue about browser locales =)
<Laney> heh
 * xnox +1 for ISO dates 2012-09-05
<ogra_> xnox, well, i dont need a date in my personal locale necessarily ... a more international way would already suffice
<ogra_> and yeah, ISO would be good
<xnox> ogra_: you made a slight assumption there that american is not internation way ;-)
<ogra_> no, i made a hard claim ;)
<cjwatson> Yeah, no real excuse for not using ISO dates in an international project
<iulian> Yummy.
<Laney> I'd have thought -dpkg needed re-merging or syncing
<Laney> (the interface changed)
<iulian> Right, should we reject this one and sync it instead?
<Laney> think so
<Laney> test build the debian version and see
<iulian> Already started building it.
<skaet> good morning
<iulian> Laney: Status: successful. I'm rejecting the one in the queue right now and sync it.
<iulian> Morning skaet.
<skaet> good afternoon iulian :)
<skaet> Laney, cjwatson - pad looks quiet.    Any concerns emerging from latest set of images?
<skaet> Riddell,  has anyone been able to duplicate https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1046244?
<ubot2> Launchpad bug 1046244 in casper "plasma-desktop crashes with SIGFAULT on boot" [Undecided,New]
<cjwatson> skaet: bug 1046175
<ubot2> Launchpad bug 1046175 in ubiquity "[regression] Manual partitioner only creates primary partitions" [High,Confirmed] https://launchpad.net/bugs/1046175
<cjwatson> xnox: ^- still awaiting an upload for that, I think ...
<xnox> ok.
<Riddell> skaet: no I couldn't recreate that plasma crash but I'm asking for more testers
<skaet> Riddell,  thanks.
<Laney> iulian: please take a look at silently and ghc-syb-utils (my uploads, so I can't do them myself)
<iulian> Laney: Done.
<iulian> I reckon that ghc.html page will look nicer. :)
<Laney> cheers
<iulian> queuebot is on holiday again.
<Laney> Daviey: go!
<iulian> Is he bringing a new robot from the clouds?
<skaet> Daviey, can you provide more background on the MAAS upload on the pad, and a bit more background?
<skaet> in general - ie. what are the implications if we don't respin, and just make it available as SRU?
<Laney> SRU?
 * skaet needs more coffee
<skaet> first update after we put out beta 1.    Had concept of 0-day SRU in my head,  where 0-day was for Beta 1,  but term SRU is inappropriate.   Development Update?  DU
 * xnox 's machine locked up. On reboot I have 15 apport windows..... *sigh* I am submitting them all!
<cjwatson> just "update" is fine
<skaet> fair 'nuf ;)
<skaet> bug 1046228
<ubot2> Launchpad bug 1046228 in ubiquity "Quantal Desktop AMD64 installation failed with: ubiquity.install_misc.InstallStepError: Plugin console_setup failed with code 1" [Undecided,Confirmed] https://launchpad.net/bugs/1046228
<skaet> cjwatson, xnox - is one of you looking at this as well?
 * skaet --> vet,  back in 2 hours.
<xnox> not yet. needs follow up as nobody else is reproducing this yet.
<xnox> maybe the reported did something non-standard to get that.
<xnox> but then again. I am not that good with console-setup
<psivaa> xnox, i reported the bug, but did not do anything non standard,
<psivaa> xnox, let me try a coupld more times to see if i could nail the steps to reproduce
<cjwatson> I'll have a look once I get some I/O back from this GRUB build
<cjwatson> But the move to 3D unity only means I'm kind of hamstrung in terms of doing much in the way of installer debugging in kvm
<cjwatson> psivaa: If you're running it again, please add the "debug-ubiquity" boot parameter
<cjwatson> That will produce more helpful logs
<cjwatson> psivaa: You also didn't say which language, location, and keyboard layout/variant you selected
<cjwatson> Actually, never mind, those bits are in the log
<psivaa> cjwatson, i could add the debug-ubiquity but i need to look up how to do that
<cjwatson> f6 at boot menu
<psivaa> cjwatson, thats good enough thanks v much
<Daviey> skaet: i'm not sure it requires more content.. it's an opportunity include.
<cjwatson> probably best to add  maybe-ubiquity debug-ubiquity  to make it as similar as possible to the previous scenario
<jibel> xnox, skaet , I filed bug 1046323, which I think should be marked in red in the release notes if not fixed.
<ubot2> Launchpad bug 1046323 in ubiquity "Ubuntu installs on first drive without asking when 'Encrypt disk' is selected on a dual drive system " [Undecided,New] https://launchpad.net/bugs/1046323
<xnox> jibel: are both disks same size?
<xnox> jibel: or one bigger than the other.
<jibel> xnox, yes, same disks
<xnox> jibel: then does it matter which one to install onto? since we can't install on to both.
<xnox> jibel: if they are different size, maybe it does matter.
<jibel> xnox, what if there is an existing system on sda and want to install to sdb ? the content of sda is lost
<xnox> jibel: if existing OS are detected, it's a different code path and you should always see selection.
<jibel> xnox, if the user doesn't select to encrypt the drive, there is an additional page to select the target drive
<xnox> jibel: plus you would be choosing side-by-side install, which is differe from wipe disk and install.
<xnox> jibel: no, there isn't. It became optional, if there are no choices for the users to make.
<xnox> jibel: as per design spec.
<xnox> I recently commented on the armhf bug that testcases need adjustment.
<jibel> xnox, I have the choice, there are 2 disk drives on the system
<xnox> both are empty, both are the same size, and can be enumerated in random order. so you don't know which is sda and which is sdb => you have no choice =)
<xnox> I am not sure if selection should be presented.
<jibel> xnox, hm install precise on disk1, precise on disk 2, then quantal with entire drive + luks
<jibel> don't tell me it selects to wipe a random disk
<xnox> jibel: is that what you did?
<jibel> xnox, it was not precise but pretty much
<xnox> jibel: cause the entire drive becomes => "delete $existingos and do clean install"
<xnox> jibel: if you have existing system and you want to preserve it, you should select "install side-by-side"
<xnox> then you should be able to choose which drive to install onto.
<jibel> xnox, ok, let me try again
<xnox> and by the way you can currently only use "lvm & crypt" options on "wipe & install"
<xnox> it should not offer those on dual boot options
<xnox> they will be gray.
<xnox> the reason it's ambigious where to do the dual boot at: disk level, crypt level or lvm level.
<xnox> jibel: please take screenshots / read carefully (prefferably in english, If you want to file bugs about it. Maybe there is something lost in translation?!)
<xnox> or both locales....
<jibel> xnox, I'm reinstalling lucid on sda, precise on sdb and will tell you what happens with no lvm, lvm only, lvm+luks.
<xnox> jibel: using automatic installer?
<xnox> jibel: hmmmm =/ i expect something ugly will happen.
<xnox> cjwatson: skaet ^^^ upload for bug 1046175
<ubot2> Launchpad bug 1046175 in ubiquity "[regression] Manual partitioner only creates primary partitions" [High,Confirmed] https://launchpad.net/bugs/1046175
<jibel> xnox, I expect it too, and why I think it should be documented
<jibel> I could have windows on my first drive, and want to try new shiny features of Quantal on an additional drive.
<xnox> jibel: it's different code paths if it is existing $windows + $ubuntu vs ($windows + $other_linux or 3+ OS)
<xnox> jibel: if you have lucid/sda and precise/sdb. You should see "You have multiple OS installed, what do you want to do?". The option that will offer crypt or lvm, should have a Red Warning label saying everything will be destroyed.
<xnox> not sure about exact text of that option.
<xnox> psivaa: any more luck reproducing your console-setup crash?
<psivaa> xnox, not yet, but trying
<jibel> xnox, ok, I'll try with windows too
<cjwatson> plars: So, skaet's away for a bit, but she asked me to talk to you about bug 1046175
<ubot2> Launchpad bug 1046175 in ubiquity "[regression] Manual partitioner only creates primary partitions" [High,Confirmed] https://launchpad.net/bugs/1046175
<xnox> psivaa: i wonder if something went very wrong in that install.... see my last comment on your bug. That's from ubiquity syslog
<cjwatson> plars: This is a pretty nasty bug that I reckon renders the installer unusable for a number of classes of users, and is certainly deeply confusing
<plars> cjwatson: I'm looking at that one right now and talking to jibel about it
<cjwatson> plars: I can't personally speak to its testing, but xnox has tested his own fix
<cjwatson> plars: What do you think about the chances of a respin?
<cjwatson> 'cos I know QA love that
<phillw> lol
<plars> cjwatson: heh, well... if we kick off a respin now, we are looking at late night for most of the team but me by the time it's ready
<cjwatson> Yeah, and we need to accept the new ubiquity and get it built and published
<cjwatson> It's not ideal
<plars> cjwatson: yeah, I know
<psivaa> xnox, yes i saw that, but this is a vm install so not sure what exactly might have gone wrong there
 * xnox doesn't consider bug 1046175 respin worthy. maybe opportunity candidate. I'm not  in release team or anything like that.
<ubot2> Launchpad bug 1046175 in ubiquity "[regression] Manual partitioner only creates primary partitions" [High,Confirmed] https://launchpad.net/bugs/1046175
<cjwatson> Perhaps I should get it built and published anyway?  At the very least, we aren't going to build images without this fix
<cjwatson> Yeah, I think I'll do that
<xnox> psivaa: anything can happen, I had virt-manager loosing track of it's storage pools and producing very interesting virtualisations of hardware failures ;-)
<plars> I was actually about to talk to jibel to see if we have any standard criteria for respinning at milestones that differ from release.  Certainly for release we would need to respin, but for beta, in my thinking, is there a big difference between release noting something like this and telling people that if this is a big deal for you, you should pick up tomorrow's daily build instead for testing?
<stgraber> having it in the archive as an opportunity target sounds good
<plars> indeed
<cjwatson> plars: Depends how many support mails we want to answer :-)
<cjwatson> The day after a milestone, daily builds are often broken, of course
<cjwatson> But we'll see ...
<psivaa> xnox, hmm ok, could not reproduce it yet, the vm installation on that particular system is very slow though
<xnox> psivaa: most of my testing is in kvm, and I didn't see that one yet. I blame solar winds =)
<stgraber> oh, fun, Edubuntu only has xserver-xorg-video-dummy installed, no other video driver. That certainly explains why I'm not getting any X session...
<highvoltage> stgraber: yeah I noticed that yesterday too and wondered what was going on
<highvoltage> (I assumed it was a global ubuntu problem, is it not?)
<stgraber> I don't think so or we'd have a lot more people panicing ;)
<stgraber> xserver-xorg-video-all seems to be missing, trying to figure out why
<psivaa> xnox, hmm possibly, let me try if that wind is persistent :) but owing to its lack of frequency, i dont think its very important for today
<stgraber> highvoltage: hmm, might be because we're shipping arkose which ships xpra which depends on xfvb which depends on xserver-xorg-video-dummy
<stgraber> highvoltage: xserver-xorg-video-dummy meets the "xorg-driver-video" criteria part of xserver-xorg so xserver-xorg-video-all never gets installed
<highvoltage> ah, weird that we didn't run into it before.
<highvoltage> I guess the dependencies/recommends got updated with the new X stack that got uploaded.
<stgraber> something must have changed recently, either xvfb/xpra using xserver-xorg-video-dummy or some change on xserver-xorg-video-dummy so it now provides xorg-driver-video...
<stgraber> trying to figure out what the right fix is... I can see why someone would wnat to install xserver-xorg with only xserver-xorg-video-dummy as I'm actually doing that for some containers/auto-upgrade-testing... I'll just add xserver-xorg-video-all to edubuntu-desktop for now
<stgraber> Laney, skaet, cjwatson: I'm going to push a new edubuntu-meta to fix that missing X driver issue we're having (seed change pushed already), then will respin with whatever other fixes will have landed by then
<Laney> are we expecing a new ubiquity?
<Laney> you might want to wait for that if so
<cjwatson> stgraber: Let's wait until ubiquity has published
<cjwatson> Laney: It's building or publishing or something
<cjwatson> stgraber: But yes, makes sense to upload edubuntu-meta in the meantime
<stgraber> cjwatson: ok, will add the ubiquity fix as rebuild trigger for Edubuntu then
<Laney> ah, it's being release noted for everything else?
<cjwatson> I don't think we've decided
<Laney> just going by the pad
<stgraber> ^ can someone please review edubuntu-meta? (diff should be tomboy replacing gnote and xserver-xorg-video-all added)
<Laney> doing
<stgraber> the gnote -> tomboy part is bug 1046345 which I mentioned in the seed commit but forgot in the upload
<ubot2> Launchpad bug 1046345 in edubuntu-meta "[ffe] Change from gnote to tomboy in Edubuntu" [Medium,Confirmed] https://launchpad.net/bugs/1046345
<Laney> (yay tomboy)
<Laney> done
<stgraber> Laney: thanks
<phillw> could someone spare a bit of time to look at the powerpc builds for lubuntu? Both are 'fail', two different bugs.
<phillw> bug http://launchpad.net/bugs/1041625
<ubot2> Launchpad bug 1041625 in openchrome "X not starting after install [openchrome]" [Critical,Confirmed]
<phillw> bug http://launchpad.net/bugs/1040544
<ubot2> Launchpad bug 1040544 in ubiquity "Installer dialog does not come up" [Undecided,New]
<phillw> ahh, there has been a comment on the X bug :)
<tumbleweed> grumble, ppc buildd has been hit with lots of PPA builds today
<phillw> tumbleweed: sorry... I know ppc can be a pain in the neck.
<skaet> plars, cjwatson, Laney - looks like we'll be getting in a security fix as well.
<Laney> for what?
<tumbleweed> phillw: not your fault. I just don't want to accept too many unseeded things until the backlog has cleared
<plars> skaet: which packages are affected? we have the fix already?
<cjwatson> Is it a security fix that *has* to be on the live session rather than being upgraded latere?
<cjwatson> *later
<xnox> isn't it kernel?!
<jdstrand> which package is it?
<cjwatson> Well, I don't know, I haven't been told
<jdstrand> we've been uploading userpace things to quantal-proposed. they don't need to be on the CD unless someone explicitly asks for it
<utlemming> stgraber: can you add http://cloud-images.ubuntu.com/quantal/20120905/ to the tracker for B1?
<stgraber> utlemming: sure
<utlemming> stgraber: thank you kindly :)
<stgraber> Can't find: us-west-2-amd64-hvm
<stgraber> utlemming: is that something new? ^
<utlemming> stgraber: yes, that's new. It came online the day of A3
<skaet> jdstrand,  openjdk6 and openjdk7
<jdstrand> those are probably coming from doko
<skaet> yes,  jamespage has been working with him on testing.
<cjwatson> skaet: Why do those need to be updated on the images?  12.04 is vulnerable too, surely
<stgraber> utlemming: ok, I'll need a bit more time for that one then
<doko> skaet, yes, as mentioned earlier
<jdstrand> but I don't see why they need to be on the image per se-- but the server team might want it...
<cjwatson> If it's vital that it be in 12.10 beta 1 for some reason, I'm not sure why logically we aren't scrambling to do a snap 12.04 point release
<skaet> cjwatson,  I believe that's in progress as well.
<doko> cjwatson, 12.04 has the openjdk security updates
<cjwatson> doko: In the 12.04.1 images?
<cjwatson> skaet: A snap point release?
<cjwatson> That's kind of a big deal, surely we need to talk about that
<cjwatson> We didn't even do that for the OpenSSL vulnerability of death
<skaet> cjwatson, agreed.    No discussion of a snap point release for 12.04 yet.
<doko> sorry, didn't get this with the point release
<iulian> There's a sync (octave) sitting in the queue. It takes more than 1 hour to build on amd64/i386 and roughly 4 hours on arm* and ppc. If you need the buildds to be free, then let it stay in the queue.
<cjwatson> I understand that the Java plugin has serious vulnerabilities, but web stacks have vulnerabilities all the time - we generally just let people upgrade afterwards and move on
<micahg> The java browser plugin wasn't shipped in 12.04.1 anyways and isn't on any media for quantal
<stgraber> utlemming: there you go ^
<cjwatson> Yeah, indeed - so at least the Java vulnerabilities I've heard about don't seem urgent for images
<utlemming> stgraber: most appreciated :)
<cjwatson> Well, icedtea-6-plugin is on the Kubuntu DVD actually
<cjwatson> Ah, but we've stopped building that by the looks of things
<skaet> server and edubuntu?
<cjwatson> AIUI the vulnerabilities are only critical for things that ship icedtea*-plugin
<cjwatson> i.e. Java on the security boundary rather than YA language interpreter
<stgraber> can someone from ubuntu-archive please merge: https://code.launchpad.net/~stgraber/ubuntu-archive-tools/ami-add-us-west-2-amd64-hvm/+merge/122903 ?
<doko> cjwatson, hmm, no, the ones from last week are in the jdk
<cjwatson> doko: Please expand
<cjwatson> doko: Are they attacks by malicious applications on the language runtime/VM?  That's what I understood
<doko> http://lwn.net/Articles/514274/
<cjwatson> doko: In that case they only matter if the application comes from a different security context
<cjwatson> We don't care about the possibility that a local application might exploit a local VM to do something malicious with its own user privileges
<cjwatson> Only things on security boundaries matter, such as the web plugin
<doko> well, ok
<stgraber> Laney, cjwatson, skaet: edubuntu-artwork and ubiquity are published on all architectures, can we respin Edubuntu now?
<skaet> stgraber,  ok for respinning Edubuntu
<skaet> Laney,  will you trigger it, or do you want me to?
<cjwatson> plars: so I gather there's some debate about whether to respin desktop, and we should talk about it here
<cjwatson> we let in the ubiquity fix kind of as an opportunity target, or at least because there was no reason not to
<cjwatson> I understand QA time is tight but I think it's very bad to release with a broken manual partitioner
<plars> cjwatson: I had just been reading the backscroll, it sounded like most here were in agreement that it should be updated, but no respin?
<cjwatson> prepared to be overruled, but we shouldn't all assume we agree without clear discussion :)
<plars> oh, I thought you meant about the java bug
<stgraber> skaet, Laney: as neither of you seems to have done it yet, I'm triggering the rebuild
<skaet> stgraber,  ack.
<cjwatson> I don't think the Java bug needs a respin, no, but the ubiquity issue remains
<plars> cjwatson: which ubiquity bug specifically? do you mean https://launchpad.net/bugs/1046175
<ubot2> Launchpad bug 1046175 in ubiquity "[regression] Manual partitioner only creates primary partitions" [High,Fix released]
<cjwatson> Yes
<plars> or https://launchpad.net/bugs/1046167
<ubot2> Launchpad bug 1046167 in ubiquity "Cannot use manual partitioner if an LVM partition already exists (dup-of: 1042647)" [Undecided,New]
<ubot2> Launchpad bug 1042647 in ubiquity "[FFe] [UIFe] Manual Partitioning LVM" [High,Confirmed]
<cjwatson> No, 1046175
<cjwatson> The only image for which that's relevant that also contains OpenJDK is the Edubuntu DVD, BTW
<stgraber> skaet, Laney: doh... I forgot to set ARCHES... so looks like we'll get an armhf build for Edubuntu (not published though), sorry for the extra time it'll take to build that one for nothing...
<plars> I've been trying to reproduce 1046175 and so far, not able to
<cjwatson> xnox: ^-
<plars> maybe because I was testing it on mac?
<cjwatson> Yes
<cjwatson> Macs use GPT which does not have a primary/logical distinction
<cjwatson> Testing that bug on Macs is a waste of time :)
<plars> ah, ok I had wondered if there was a diff there.. (I just got this mac from jibel, never used one before)
<highvoltage> I wish people would stop doing silly things like buying Macs.
 * xnox if only everyone used GPT like I also do.....
<cjwatson> Oh don't get me wrong it's a much better partition table format
<cjwatson> But
<plars> cjwatson: there's another one to be aware of too...
<plars> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1046323
<ubot2> Launchpad bug 1046323 in ubiquity "Ubuntu installs on first drive without asking when 'Encrypt disk' is selected on a dual drive system " [High,Confirmed]
<cjwatson> jibel and xnox were going round on that; I didn't keep up
<xnox> this is IMHO expected behaviour. But I still need to review jibel's screenshots.
<cjwatson> I'm not sure I agree, but I'm not sure now is the time for that debate either :-)
<xnox> I only offer lvm/crypt on clean installs, not dual boot configs / reinstall / upgrades etc.
<plars> xnox: my understanding was that if you have two disks, and you are trying to install on the second drive with encrypted disk, you're first drive is going to get wiped instead
<cjwatson> It seems to lack defence in depth against data loss
<xnox> i need to review jibel's pdf before doing any fixes.
<xnox> plars: ubiquity partitioning does not currently offer automatic option "install on the second drive with encryption".
<plars> ok, so it's back to just bug 1046175 then
<ubot2> Launchpad bug 1046175 in ubiquity "[regression] Manual partitioner only creates primary partitions" [High,Fix released] https://launchpad.net/bugs/1046175
<xnox> that one is uploaded.
<plars> didn't there used to be an option to get the latest ubiquity before starting the install?
<plars> or is that gone now
<xnox> if there was, it was way before my time.
<cjwatson> There is, but it relies on a remote trigger to activate
<cjwatson> xnox: ubiquity/auto_update.py
<xnox> ok.
<plars> cjwatson: I think this would surely be critical if it were final release, but for beta1, would we have normally done a respin in the past with <24 hours for something like this?
 * plars just started on the team this week, so I don't yet have a good feel for the history of things like this
<cjwatson> certainly have in the past
<cjwatson> depends how far in the past you mean I suppose, I only have records in wetware memory
<plars> cjwatson: my concern is that there may not be enough time to rerun all the tests
<cjwatson> well, I don't know, as I say I'm prepared to be overruled if you think there isn't enough time
<cjwatson> although I think it is a process failing if there isn't enough time, because we've certainly done shorter-notice respins than this in the past, and we've cut down on our image sets so that QA would be quicker
<plars> skaet: what time do we actually release tomorrow?
<plars> cjwatson: what do you mean by "cut down our image sets"?
<cjwatson> I mean if we stop shipping alternates and QA takes twice as long, that seems kind of odd
<plars> cjwatson: could be ok, as I said, just started, don't have a good sense of time on this yet
<skaet> plars, its variable,  we certainly have time for a round of testing from europe in the morning, as well as the rest of the afternoon here.
<Laney> stgraber: OK. I was never going to do it because you said you would. ;-)
<plars> skaet: ok, sounds good then... it's just desktop respin right?
<cjwatson> I don't want to steamroller this through by force of personality or whatnot; if other people don't think it's desperately important I'll step back
<cjwatson> xnox said he didn't feel it was respin-worthy
<cjwatson> Anyone else?
<skaet> cjwatson,  I'd rather it get fixed and out there as well,   and since there is still time to retest, that's my preference
<skaet> plars, yes, just desktop respin.
<skaet> for Ubuntu.
<plars> +1 then
<xnox> well it affects all images that use gtk-ubiquity so: ubuntu desktop, lubuntu desktop, xubuntu desktop, ubuntu studio desktop, edubuntu (is already respinning)
<skaet> Riddell, gilir, knome - do you want respins to pick this up for yours?
 * skaet snaps with xnox
<xnox> does not affect Kubuntu
<cjwatson> Yeah, doesn't appear to affect Kubuntu
 * xnox snap
<skaet> xnox,  cjwatson,  ack.  Riddell - relax ;)
 * Riddell relaxes
<phillw> skaet: the lubuntu testers will dive back in if warned.
<xnox> well the question is whether you care about setting primary & logical partitions in manual partitioning.....
<skaet> phillw,  yours and gilir's call.    How critical is this case to your userbase?
<skaet> scott-work,  do you want ubuntu-studio respun?
<phillw> lubuntu users tend to be adventurous, so the lack of using extended partitions could well cause problems.
<skaet> xnox,  does this affect the alternates?
<knome> skaet, when was the testing deadline again and will this affect all builds?
<cjwatson> skaet: no
<cjwatson> it's purely at the ubiquity UI level
<skaet> knome, ^ per cjwatson,  just desktop.
<knome> skaet, i meant i386/amd64, but that probably affects both ;)
<knome> skaet, please respin for xubuntu
<skaet> knome, testing deadline is by 1200 UTC
<skaet> knome,  ok.
<phillw> skaet: when will the iso's land?
<utlemming> skaet: it looks like we're going to rebuild our cloud images in light of LP: #1046115
<cjwatson> I'll start off respins nowish
<scott-work> skaet: ubuntu studio will not ask for a respin
<skaet> scott-work,  ok
<skaet> utlemming,  ack
<cjwatson> It is *so annoying* that etherpad reconnection doesn't work
<phillw> cjwatson: indeed!
<utlemming> skaet: I'll let you know ASAP on that
<cjwatson> so Ubuntu Lubuntu Xubuntu then?  I suspect that Xubuntu and Lubuntu users are pretty similar in adventurousness
<knome> cjwatson, i already confirmed xubuntu wants a respin :)
<phillw> I'm happy for a lubuntu respin
<cjwatson> Oh I missed that, sorry
<skaet> phillw,  marked it.
<knome> np
<Laney> you guys don't want to change your seeds to bring indicators back?
<skaet> phillw,  after edubuntu comes out,  will be looking to see ubuntu desktop,  xubuntu desktop and lubuntu desktop emerge.
<xnox> and silencing thunar is opportunity in ubiquity.
<xnox> (silencing auto mounting)
<skaet> stgraber, on the pad, you've got Edubuntu respinning for [20] did you mean [19]?
<cjwatson> On its way now
<phillw> skaet: I'll keep an eye open & alert L-QA as soon as they land. Is it all the Desktop ones (i386, AMD, PPC, AMD-MAC)?
<cjwatson> Yeah
<cjwatson> Oh I suppose I needn't have respun amd64+mac but it's a bit late now
<phillw> he he
<skaet> thanks cjwatson.
<cjwatson> If you want to skip the tests for amd64+mac and set the ISO tracker back to the previous version after it lands (you may need to get stgraber to do that, I forget), that's fine by me
<cjwatson> I expect that would speed things up a bit
<phillw> Lars hadn't tested amd64-mac last time I looked, so it's okay.
<cjwatson> Actually come to think of it it isn't worth retesting powerpc for this either; only completely and utterly ancient powerpc systems use DOS partition tables, pretty much
<cjwatson> Damn, could have saved some time there
<cjwatson> I suppose I can C-c this
 * skaet nods - powerpc is the slow poke.
<phillw> cjwatson: hmm, I was hoping that we would get a working ppc out of desktop & alternate :(
<cjwatson> I'll do that after amd64 and i386 livefs builds have finished
<cjwatson> phillw: Is there a reason to believe that a respin would make any difference?  I didn't know anything relevant had changed.
<cjwatson> lubuntu-quantal-desktop-powerpc.iso hangs at a black screen for me in qemu, but I'm not sure if that isn't just qemu being hideously slow
<phillw> ubuiquity does not start doe the Desktop?
<skaet> phillw,  its just that the code path changed is not exercised on PPC was how I read it.
<phillw> Lars has tested on hardware.
<cjwatson> Yeah, but with only a screenshot I can't do much
<cjwatson> Was hoping to reproduce it lolcally
<cjwatson> skaet is correct
<phillw> lars is pretty good, from past experience, at getting you guys the logs you need. Ask him on the bug report.
<cjwatson> What I need is to reproduce it locally :)
<Riddell> skaet: we have a likely cause for bug 1046244 I think I want to upload qt and respin the amd64 images
<ubot2> Launchpad bug 1046244 in qt4-x11 "plasma-desktop crashes with SIGFAULT on boot" [Undecided,New] https://launchpad.net/bugs/1046244
<cjwatson> This stuff is a pain to fix any other way ...
<phillw> cjwatson: My guess is that the hang you see is not qemu being hideously slow?
<cjwatson> I think it's a video problem that has little to do with the image
<cjwatson> But I can't remember how I invoked qemu-system-ppc
<njin> slow, hang... last build of quantal, yes for me in real haardware
<utlemming> skaet: rebuild triggered for Cloud images. New image ETA ~1.5 hours.
<cjwatson> njin: Unrelated
<njin> ok
<phillw> cjwatson: https://wiki.ubuntu.com/Lubuntu/Testing/PPC%26Mac64#How_to_test_on_any_architectures_.28using_qemu.29 Is the one that gilir (Julien) wrote up for us.
<cjwatson> This is powerpc under emulation; vanishingly unlikely to have anything to do with whatever you're seeing or indeed anything remotely normal
<cjwatson> phillw: Thanks, that exactly matches what I'm doing though
<cjwatson> Except that I have to use oneiric's qemu-system-ppc because precise/quantal's doesn't even get to OF
<phillw> cjwatson: I'll rally the other couple of guys with ppc kit to double check as soon as there is an image for them.
<cjwatson> Ah, it's doing something though, break=top works
<phillw> I think we now have 5 testers with actual kit.
<cjwatson> Maybe I just need to be more patient
<cjwatson> If one of those testers wants to turn developer and dig into the bug themselves, that wouldn't hurt :)
<phillw> he he, indeed.
<skaet> Riddell,  add it to the pad,  and we'll respin after the current lot gets through.
<skaet> utlemming,  thanks.
<cjwatson> OK, Ctrl-ced those builds and doing it manually just for amd64/i386
<cjwatson> (ignore the failures you may have just got by mail)
<cjwatson> Ah, one of live-nosplash and nomodeset helped, I think
<skaet> thanks cjwatson.
<skaet> utlemming have added your respin to the pad
<utlemming> saket, thanks
<Riddell> Laney: can you review that qt4-x11 upload please
<cjwatson> I can
<cjwatson> Riddell: There isn't an Ubuntu bug reference in that patch; what are the chances that this will bring back some other problematic bug?
<cjwatson> Oh, let me read your refs in this bug
<Riddell> cjwatson: I don't think the original issue was ever reported to ubuntu
<Riddell> the patch was just recommended by upstream
<cjwatson> Right, OK, if Debian removed it too then cool
<cjwatson> Accepted
<cjwatson> Aha, a Lubuntu/powerpc desktop
<phillw> :)
<skaet> balloons, phillw - am marking iso tracker for the images currently being rebuilt now.
<balloons> skaet, ty
<phillw> ty
<skaet> balloons,  can you update the notice board?
<balloons> yep
<cjwatson> Probably not much point, the last pair is ~2 minutes off completion
<cjwatson> Well maybe a little more but not much
<balloons> did any opportunity targets make it?
<skaet> balloons, nope
<cjwatson> Builds> Eh, not sure what that was
<cjwatson> Oh, your mass-disabling
<skaet> cjwatson,  me.   checked edubuntu hasn't updated, and assumed rest were blocked behind it.
<skaet> so worth marking the ones being rebuilt.
<cjwatson> Why did you disable the Lubuntu one that just built?
<cjwatson> And Ubuntu desktop, too
<skaet> cjwatson,  it was a mistake,  undoing
<cjwatson> queuebot's been announcing them :)
<balloons> :-)
<cjwatson> Ah, and the EC2 stack would account for the rest
<skaet> edubuntu and xubuntu still need to be updated though, so left them marked rebuilding/.
<phillw> skaet: Lubuntu Desktop amd64 [Quantal Beta 1] has been marked as ready ?? Does this mean they don't need re-testing?
<skaet> phillw, finger fumble my part.   fixed.   yes they need testing.
<phillw> skaet: he he :)
<Riddell> why do the upgrade test cases on http://iso.qa.ubuntu.com list upgrade from lucid?
<cjwatson> phillw: It took forever (partly due to a bug which I've diagnosed and will fix) but the installer window comes up for me on Lubuntu powerpc in qemu
<skaet> Riddell,   looks like they're hold over from precise testing.
<phillw> cjwatson: so, is it ask the testers to be patient? (about how long is reasonable for them to wait on hardware)?
<skaet> balloons,  can you look at the upgrade tests and see if they need adjusting?
<cjwatson> phillw: Well, no, the partial display in that bug wouldn't be the result of slowness, I think
<cjwatson> I suggest seeing if somebody else can reproduce it ...
<phillw> cjwatson: okies, I'll go 'rally the troops' :) Thanks.
<cjwatson> Maybe it's qemu vs. real hardware, or maybe it's a race condition, or maybe it's bizarre cosmic rays
<micahg> meh, before someone accepts wader, I'm having second thoughts about it, I'm not sure if it needs an FFe as there's new HW enabled in there and the changes seem extensive, maybe if someone wants to just wants to reject for now and we'll deal with it after beta 1?
<balloons> i don't think we can remove them until lts testing is over
<balloons> so it lists LTS Desktop upgrade
<micahg> cjwatson: Laney: can one of you reject wader please, I think I'm going to ask the request for an FFe
<skaet> balloons, can we make it so that those test cases don't apply to quantal?
<balloons> skaet, sadly I don't think we can..
<balloons> let me try
<balloons> i seem to remember the fact that we cannot.. but I don't know why
<skaet> thanks.   if not,  maybe a comment at the top of each?
<cjwatson> phillw: Of course that bug is from 2012-08-23 so it may just have been fixed
<balloons> lol.. http://iso.qa.ubuntu.com/qatracker/milestones/232/builds/22521/testcases
<balloons> skaet, I think it's done.. I'm confused
<phillw> cjwatson: I did wonder myself, but with the cron respins crashing, I was unsure if he was running the only (then latest) iso.
<phillw> I'm going to call for a full retest.
<skaet> balloons,  looks like done for Ubuntu, but Kubuntu still has Lucid ref.   http://iso.qa.ubuntu.com/qatracker/milestones/232/builds/22515/testcases
<skaet> possibly all the flavors have this still?
<balloons> yes
<balloons> flavors are universally not migrated to new testcases
<balloons> let me see if there's something that can be done there
<balloons> perhaps that was what we were stuck on
<skaet> thanks balloons
<skaet> Riddell, ^
<balloons> on that side note however, we could certainly push all the default (ubuntu) testcases to the flavors
<balloons> skaet, yes, in order to fix it, they have to move to the new format
<balloons> legacy mode is stuck as-is
<skaet> I think they should be participating in the decision one way or another.
<balloons> for instance, I just switched http://iso.qa.ubuntu.com/qatracker/milestones/232/builds/22515/testcases
<skaet> Riddell,  phillw, knome, astraljava, stgraber, highvoltage ^  any preferences?
<balloons> that upgrade testcase is really generic.. nothing ubuntu specific in it.. others may or may not be
<knome> balloons, so, i think my question is the same as before:
 * highvoltage hasn't been paying attention *catching up*
<Riddell> I never worked out what the difference is
<knome> balloons, when i create a testcase, can i "include" another testcase or a part of a test to it, or do we need to maintain every testcase separately, even if they had overlapping parts?
<balloons> when you create a testsuite, you can include any testcase you wish
<micahg> cjwatson: Laney: unping, iulian took care of it for me
<balloons> testsuites can be assigned to products
<phillw> skaet: lubuntu has not yet started on specific test cases, so I'm happy to use the generic ones.
<balloons> so for example, the ubuntu desktop amd64 has 3 testsuites attached to it, with varying numbers of testcases
<knome> balloons, yes... but if i have a testcases for say "xubuntu desktop (whole disk)" and "xubuntu desktop (manual partitioning)", there's no way i could maintain the desktop-test part of those in one place?
<balloons> ubuntu desktop has 4 testcases, ubuntu desktop mandatory extras has 2, and the ubuntu desktop run-once has 8
<balloons> knome, I'm still not following.. but ok, you created two testcases
<phillw> balloons: I think we were working to make the basic ones flavour agnostic?
<balloons> phillw, I believe so.. honestly I'm not sure of much that is specific in them, apart from the post-installation bits
<balloons> (bits of which I'd like to can somehow as it is anyway)
<balloons> knome, after you make those 2 testcases, what do you want to do with them?
<knome> balloons, yeah. in the other test, the user should use the whole disk; on the other test, the user should manually partition. i understand that this is two testcases.
<balloons> and what is your worry?
<phillw> balloons: as the mandatory is 'does it install and boot' it should be flavour agnostic.
<knome> balloons, now, after each of those installations, we would like the users to test if our desktop stuff works - obviously, with both testcases
<balloons> ok, so post-installation tests
<knome> balloons, is there a way that i can maintain this desktop testing in one place, or should i just copy it to both testcases, and when we need to change it, i go to both testcases and manually edit them?
<phillw> knome: I think they will fall into the 'test once', which will be flavour specific - eg pcmanfm for lubuntu
<knome> balloons, phillw: ok, so what you are suggesting is to create another testcase for post-installation tests only?
<balloons> knome, yes ideally I think these post-installation tests should be migrated out of the installation tests
<knome> ok, that clears it quite a bit
<balloons> as it stands, there are a couple of "post-installation" bits at the end of some of the testcases
<balloons> this happened during the migration.. I'd like to remove them if possible
<balloons> sounds like people are in agreement they should be seperated
<phillw> e.g. testing firefox on a flavour that uses chromium is not a lot of help :)
<knome> so what you are proposing is to use the general testcases for all flavor testsuites
<balloons> yes, I don't think there is any harm in that
<balloons> and the upside is there's only one set to maintain
<balloons> between ALL flavors ;-)
<xnox> Xubuntu, Lubuntu, Ubuntu Studio: please see w.r.t. ubiquity auto-mounting partitions https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/719338/comments/5
<ubot2> Launchpad bug 719338 in ubiquity "[Xubuntu, Studio?, Lubuntu?] Disable automount" [Medium,Triaged]
<knome> i agree, but will those say "ubuntu", when it might read "xubuntu" in the xubuntu installation?
<balloons> knome, yes atm they do say "click install ubuntu", etc
<balloons> we could expand this a little to make it more generic.. people would have to understand what they are installing
<knome> balloons, ok, so will those stay as is, or will we get to change that at some point
<knome> maybe some variables that can be set for each testsuite
<balloons> knome, your on the team.. you can change them :-)
<balloons> xnox, I did it again ^^
<knome> eg. in all xubuntu testsuites, PRODUCT=Xubuntu
<balloons> your=you are
<phillw> knome: under the new system, each flavour can edit the master and save as new test case.
<knome> phillw, yeah, but that means there's two test cases to maintain.
<knome> phillw, i want to avoid that
<balloons> phillw, I'd prefer we used the same were possible
<knome> phillw, i'll sell you my mum to avoid that
<balloons> and had flavors only maintain the bits that are specific to them
<phillw> knome: which leaves the issue as what do we call them?
<knome> phillw, as i proposed, enable "variables" for testsuites
<balloons> so knome should have the 1 or 2 extra testcases he wants only for xubuntu to maintain
<balloons> and that's it
<knome> 20:59  knome: eg. in all xubuntu testsuites, PRODUCT=Xubuntu
 * xnox =)
<phillw> lubuntu have no issues with an upgrade from 11.10 --> 12.04 being called "Ubuntu"
<knome> and then in the testcase, refer to $PRODUCT
<knome> phillw, this is just the simplest example
<balloons> knome, long term i think this is totally doable.. We should ask stgraber to implement.. in the interim, we can simply say ubuntu/xubuntu/lubuntu/mythbuntu/edubuntu/ubuntu studio :-)
<knome> yep
<balloons> lol.. I don't think it will be the end of the world.. people will get it
<phillw> The installer and 1st run, are Ubiquity & alternate (for flavours). Those instructions are flavour agnostic.
<knome> saying "ubuntu" is fine with me as long as there is some motion to get it changed
<skaet> seb128,  around?
<seb128> skaet, yes
<seb128> ^ could people accept that glib-networking update?
<knome> xnox, hmm... can you shed some light on the implications of your question? :)
<seb128> some stuff segfault with the glib in quantal-proposed without it
<balloons> ok, so that's signoff from lubuntu and xubuntu I take it?
<knome> balloons, yes
<knome> balloons, at least from xubuntu, i'm fine with the new tests
<xnox> knome: there were / are bugs about thunar automounting partitions/filesystems that ubiquity detects / creates. There are bugs open about it (one from Studio, Two from Xubuntu). Studio I believe change thunar default config for the CD, while xubuntu/lubuntu have not done that yet.
<knome> bug #1039375 ?
<xnox> knome: see duplicate bug
<ubot2> Launchpad bug 1039375 in thunar "Duplicate partitions shown" [Undecided,Confirmed] https://launchpad.net/bugs/1039375
<xnox> no.
<seb128> slangasek, skaet, cjwatson: can you accept glib-networking to quantal-proposed? the glib there has issue with the version mismatch
<xnox> knome: see duplicate on the bug i posted. I got to go. I will be back later.
<dobey> can i bother a release teamer to poke at a UI/FF exception for u1?
<knome> xnox, how does the different ways of doing this differ apart from the obvious thing that it's done from a different plae
<knome> xnox, ok, see you
<skaet> dobey,  bug #?
<dobey> skaet: bug #974637
<ubot2> Launchpad bug 974637 in ubuntu-sso-client/trunk "[UIFe] [FFe] Qt Registration and Log-in dialogs have no way to perform the other action" [High,In progress] https://launchpad.net/bugs/974637
<knome> balloons, are you working with the testcases/-suites right now?
<balloons> knome I'm not going to swap them in until after beta
<balloons> but I'm looking at them :-)
<knome> balloons, do you mind if i do?
<balloons> knome, no we can swap now.. I just don't want to lose results
<knome> ah, that's the implication :)
<knome> there's no tests on xubuntu though ;)
<balloons> xubuntu has nothing atm
<balloons> we can swap them
<knome> will you take care of i386, i'll take amd64?
<balloons> interesting
<knome> once i find it...
<balloons> your manual partitioning is a run-once?
<knome> yeah
<balloons> k, I can make both
<balloons> to replace what's there
<knome> ok, thanks
<knome> i'll add stuff after that then - much appreciated!
<knome> (the management is a mess with too much stuff ;))
<balloons> yea.. feel free to make the testcases
<balloons> yes.. the ui will need improvement.. but eh, it works :-)
<knome> kind of...
<knome> ;)
<knome> balloons, will you ping me once you've migrated to the new testcases - ta! :)
<balloons> in about 30 secs
<knome> heh
<knome> so slow...
<balloons> have a look
<dobey> thanks skaet
<knome> mm, good
<knome> balloons, what about i386/amd64?
<knome> balloons, how would you go with that
<balloons> knome, what do you mean?
<knome> balloons, doesn't it matter which arch runs the tests?
<balloons> the testcases are the same, though when you check arch it should reflect properly
<knome> so... the new testsuites will create the arches itself?
<balloons> knome if you'd like, we can chatterbox more in #ubuntu-testing so the release team doesn't hang me for spamming there channel all day :-)
<skaet> :)
<skaet> thanks balloons
<seb128> skaet, slangasek, cjwatson, others: did one of you read one my pings before? glib segfaults in quantal-proposed and it would be good to get that glib-networking upload accepted to quantal-proposed to fix that...
<skaet> seb128,  think it got lost in the backscroll...
<seb128> skaet, I asked twice and I highlighted you guys directly the second time :-(
<slangasek> seb128: looking now
<seb128> slangasek, thanks
<skaet> sorry seb128,  thanks slangasek
<seb128> slangasek, the queue diff got it wrong, it diff with an old version for some reason
<seb128> slangasek, the diff is smaller than that in fact
<slangasek> seb128: yeah, because launchpad doesn't know how to stack -proposed vs. -release vs. -updates for diffing
<seb128> ok, makes sense
<slangasek> seb128: so once this goes in, what ensures the packages are upgraded in lockstep on users's systems to prevent segfaulting there?
<seb128> slangasek, I guess we need another glib upload with a Breaks: glib-networking (<< 2.32.12)
<slangasek> seb128: ack
<seb128> slangasek, thanks
<stgraber> skaet: we'll need another edubuntu respin
<stgraber> skaet: I just got my first "working" image and spotted a few pretty annoying bugs. Preparing the fixes while I test the rest to avoid another respin
<skaet> stgraber,  ok.   no arm please though ;)
<stgraber> skaet: yeah, I'll be careful to use ARCHES= this time around ;)
<skaet> please add the fixes to the pad, so we can keep track
 * skaet makes a note to go scrub it again.
<stgraber> will do
<skaet> cjwatson, are the Kubuntu amd64 images queued up for rebuild, or is that still pending?
<stgraber> can someone please review ^ ?
<slangasek> looking
<slangasek> stgraber: accepted
<stgraber> slangasek: can you also look at edubuntu-netboot?
<slangasek> done
<roadmr> Hi folks, about this UIFe/FFe bug: https://bugs.launchpad.net/ubuntu/+source/checkbox/+bug/1044037 I see it got marked as confirmed by the janitor, is this correct?
<ubot2> Launchpad bug 1044037 in checkbox "[FFe] [UIFe] Controls in the test screen are confusing and should be rearranged." [Undecided,Confirmed]
<slangasek> roadmr: 'confirmed' doesn't mean anything
<slangasek> the launchpad bot uses is to mean "more than one user is seeing this bug"; this effectively means that 'confirmed' and 'new' bugs are indistinguishable
<roadmr> slangasek: I see, so it doesn't affect the bug being looked at by a human at some point? I just don't want it to fall off the radar
<stgraber> slangasek: thanks
<knome> can we get an UIFe for bug #1043170 and will somebody take care of that (since i understood it needs a change in ubiquity) ?
<ubot2> Launchpad bug 1043170 in xubuntu-default-settings "Update Xubuntu wallpaper for Quantal" [High,Fix released] https://launchpad.net/bugs/1043170
<slangasek> roadmr: as to that, I couldn't say; I'm saying in practice there's no difference between new and confirmed, but it's possible the release team has overlooked this
<roadmr> slangasek: well I'm still waiting for -doc and -translators to OK the exception so I guess I'll poke them, then bring to release team's attention.
<slangasek> ok
<roadmr> thanks :)
<mterry> psivaa, ping about reproducing bug 971353
<ubot2> Launchpad bug 971353 in gnome-settings-daemon "power : gnome-settings-daemon crashed with SIGSEGV in gnome_rr_screen_get_dpms_mode " [High,Confirmed] https://launchpad.net/bugs/971353
<mterry> psivaa, I've got a potential fix, but can't reproduce myself
<knome> uhm, that's the respin?
<knome> :)
<knome> was the earlier respin today just normal?
<knome> gwaah
<knome> "Failed to create a file system"
<Riddell> Laney: could I get new kubuntu amd64 images?
<plars> skaet: what triggered the 20120905.2 respin now?
<skaet> plars - which image?
<skaet> Riddell,   I just triggered the alternate amd64 for kubuntu
<plars> skaet: all ubuntu desktop images?
<skaet> ????
<plars> skaet: http://iso.qa.ubuntu.com/qatracker/milestones/232/builds
<plars> I knew about the .1, but now isotracker is showing .2 for this
<Riddell> skaet: ooh thanks, desktop too at some point?
<skaet> Riddell,  yes will do the desktop next.
<Riddell> groovy
<skaet> plars, Ubuntu Desktop 20120905.2 spins were the ones that cjwatson triggered earlier after our discussion with the ubiquity fix included.
<plars> skaet: I thought there was no need to respin mac? and that's why there was no .1 for mac
<skaet> plars,  we'll need to confirm with cjwatson, but based on the backscroll,  I'm guessing he respun it by accident.   Prior results should apply, and we can reset the image to the tested one,  once we hear from him.
<plars> skaet: ok, there's a bit of confusion at the moment, I've been running tests on .1 since it showed up, and jibel has now pulled down .2 and started testing on it :)
<skaet> plars,  understood.    We'll sort it.
<plars> thanks!
<jibel> and if you ask me to test .1 I'll go to the pub
<skaet> Riddel,  your Kubuntu desktop amd64 is building now too.
<knome> bug #1046536
<ubot2> Launchpad bug 1046536 in ubiquity "Failed to create a file system" [Undecided,New] https://launchpad.net/bugs/1046536
<knome> any logs you want?
<skaet> stgraber, slangasek ^
<stgraber> skaet, Laney: finising a test install of Edubuntu with the fixes manually applied, if that works I'll kick the respin
<skaet> ok stgraber,  kubuntu desktop should be finishing up shortly.
<skaet> its just an ARCHES=amd64 image
<stgraber> knome: the usual (/var/log/syslog and /var/log/install/*)
<knome> stgraber, will those be collected by 'ubuntu-bug ubiquity' ?
<stgraber> skaet: ok, should still be another 10min before my test install is complete (internet less, weird language, oem install with ltsp, gives us reasonable code coverage in one go)
<stgraber> knome: yep
<stgraber> skaet: gah, test install found another critical bug (edubuntu-specific), looking into that now, will likely need another upload of edubuntu-live for that one...
<stgraber> skaet: well, actually, no, I'll need an ltsp upload for that one
<micahg> I thought packages in proposed wouldn't be copied to the release pocket if there were bugs tagged regression-proposed, or is that only for SRUs?
 * skaet --> vet,  back in an hour.
<stgraber> micahg: that's SRU-only. -proposed for the dev release is just a way of avoiding skews, nobody looks at bugs before copying
<micahg> shoot, I should've mentioned Bug #1044657 then :(
<ubot2> Launchpad bug 1044657 in libreoffice "[regression] Missing LO menus when not run in Unity" [High,Triaged] https://launchpad.net/bugs/1044657
<micahg> not a blocker for beta 1 though
<stgraber> well, that could be a blocker for kubuntu/xubuntu/lubuntu no?
<stgraber> should have said !ubuntu/!edubuntu actually
<knome> beta1 doesn't look good :(
 * knome was more satisfied with alpha3
 * micahg adds Qt back to the Xubuntu images for knome to make him feel better
<knome> hah
<micahg> stgraber: kubuntu is the only one shipping libreoffice (I thought they switched to calligra), for the rest, the images themselves aren't affected
<stgraber> micahg: ok, good
<stgraber> skaet: preparing the ltsp upload now. AFAICT that fix should do it, though I can't really test without a respin... good news is that the fix is Edubuntu-specific, so no need to respin anything else containing ltsp
<stgraber> uploaded
<Riddell> stgraber: kubuntu doesn't ship libreoffice by default
<micahg> ah, right, it's not on the live images
<micahg> so, we're good then, not a beta 1 blocker
<knome> xnox, re #719338: if you can disable it for xubuntu at installation time only, please do that
<stgraber> can I get someone to look at ltsp? ^
<Laney> ahoy
<stgraber> Laney: can you look at ltsp in unapproved?
<Laney> what was the -a i386 for?
<Laney> iow do you get the same effect now without it?
<Laney> stgraber: ^
<stgraber> Laney: -a i386 used to mean "update the i386 chroot" the -a was removed and the command now always update them all
<stgraber> the only chroot we have on Edubuntu is i386, so yeah, same result
<Laney> cool
<Laney> here goes
<stgraber> thanks
<ochosi> any ubiquity-wizards around?
<knome> stgraber, crawl out of your cave! :)
<stgraber> :)
<stgraber> ochosi: what's the issue?
<ochosi> stgraber: salut :) i'm currently looking into xubuntu's ubiquity-greeter issues
<ochosi> one thing is that we want to disable the compositor in the install-only mode
<ochosi> which seems pretty straightforward to me
<ochosi> but testing ubiquity-greeter is hard...
<ochosi> (basically s/xfwm4/xfwm4 --compositor=off/ here: http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/bin/ubiquity-dm#L391)
<xnox> knome: upon launching ubiquity yes. I am not sure if we flip it back on.
<xnox> ochosi: ubiquity-greeter - switch to tty1 $ sudo /etc/init.d/$login-manager restart
<xnox> or whatever the job is called, e.g. lightdm.
<ochosi> xnox: for that i need a real install plus a test-box i guess
<xnox> ochosi: VM & no need to finish the install.
<xnox> ochosi: or is there no tty on xubuntu cd's?
<ochosi> xnox: good question, never tried tbh :)
<stgraber> ochosi: testing is actually fairly easy. Boot in greeter mode. Once on the greeter, switch to command line, then do "stop lightdm&" and "stop ubiquity&", then "pkill -9 X", then do any change you want and do "start ubiquity" to test.
<stgraber> sounds similar to what xnox described
<ochosi> ok, so once i get there, there's another thing i wanted to ask about
<stgraber> (and use "stop ubiquity && pkill -9 X" to clean up before doing another "start ubiquity")
<knome> xnox, i ran into bug #1046536 today, and i believe this has to do with automounting...
<ubot2> Launchpad bug 1046536 in ubiquity "Failed to create a file system" [Undecided,New] https://launchpad.net/bugs/1046536
<ochosi> specifically it looks like either 1) our gtk-theme is breaking (which doesn't happen in desktop-session) or 2) something in gtk3 isn't loaded properly or 3) our gtk theme isn't set properly
<utlemming> cloud image respin just cleared smoke tests and is now under going full suite of tests
<ochosi> and i wanted to see whether that's connected to http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/bin/ubiquity-dm#L413
<xnox> stgraber: nice thanks. noting down on a piece of wiki page.
<ochosi> xnox, stgraber: so what really happens here: http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/bin/ubiquity-dm#L413 ? is it just that xfsettingsd is loaded (and with it xubuntu's default settings)?
<xnox> I don't know. Haven't looked at that code.
<xnox> If there are theming issues (contrast) I have a fix for that.
<ochosi> oh, you do?
<knome> ochosi, didn't you look at the paste i showed you? >:)
<ochosi> i did
<xnox> in my quantal-proposed branch. I will be committing it to trunk. It's actually to fix high-contrast a11y, but the point is that we were relying at @dark_[fg|bg]_color being set in the theme, which is not the case for !$light-themes
<ochosi> oh right
<ochosi> yeah, that could be the reason why it's breaking
<ochosi> but the thing is that all widgets break
<xnox> I am pondering to do a quantal-proposed upload of ubiquity. But not at 10:30pm ;-)
<ochosi> that's kinda harsh
<knome> xnox, if you can ping me and ochosi when you've done that, i'd be really happy :)
<ochosi> xnox: yeah, for the meantime i'll try to test it by adding those color-defs to our theme
 * knome tries not to promise to offer too many beers at UDS this close to it
<knome> (don't want to empty my bank account)
<xnox> ochosi: knome: well you can just download three files from lp:~xnox/ubiquity/quantal-proposed.
<xnox> you need gtk_ui.py, ubiquity.ui and segmented_bar.py (or maybe it's called segmented.py)
<xnox> it's just not in a .deb format
<ochosi> ok, i'll try that
<xnox> although I could publish a ppa..... =)
<ochosi> heh
<ochosi> no, as long as i find ubiquity on the usb-stick in tty, i'm fine with that
<ochosi> stgraber: hm, when i try to stop lightdm or ubiquity i get "regected send message" errors
<ochosi> rejected
<stgraber> ochosi: are you root?
 * ochosi feels stupid
<xnox> ochosi: it's ok, you are not used to $livecd sessions =)
<ochosi> on the one hand that's true, but still, it's silly silly :)
<utlemming> stgraber: can we update the cloud images tracker with http://cloud-images.ubuntu.com/quantal/20120905.2/ ?
<ochosi> hmm, i can't modify ubiquity-dm because it's read-only filesystem
 * ochosi wonders if he's silly again
<ochosi> xnox: if i may pester you again ^ (hopefully the last time, keeping my fingers crossed)
<xnox> common =)
<ochosi> i did use "sudo" that time :)
<cjwatson> skaet: I didn't do anything with Kubuntu respins
<cjwatson> I'll look into the bizarre phantom Ubuntu desktop respins when I don't have two children on top of me
<skaet> cjwatson,  yup figured it out.  Triggered them earlier and they're published now.
<skaet> thanks cjwatson,  I was wondering if it might have been a side effect of killing the build.
<skaet> s/them/Kubuntu amd64 rebuilds/
<stgraber> utlemming: sure, doing that now
<utlemming> stgraber: thank you kindly
<stgraber> utlemming: done
<cjwatson> I don't think so and I thought I'd checked there were no relevant processes running after I interrupted it
<cjwatson> But I'll check later tonight
<ochosi> xnox: seriously, i'm a bit stuck (and ashamed)
<cjwatson> read-only fs - check syslog for kernel oopses or similar
<cjwatson> since that shouldn't normally happen
<ochosi> so it shouldn't be ro?
<ochosi> aha
<cjwatson> no, it's supposed to be a writable overlayfs on top of the ro squashfs
<cjwatson> it might go ro if you wrote enough stuff to the overlayfs to run out of memory
<cjwatson> the remedy's probably a reboot anyway
<ochosi> OK, TRYING THAT NOW
<ochosi> oops
<ochosi> sry
<ochosi> cjwatson: are there any potential vbox settings that could interfere with rw?
<ochosi> ok, sry, you're right, the restart fixed it all
<ochosi> cjwatson: last question, /usr/bin/ubiquity-dm only affects the "install only" or "ubiquity only" session/mode?
<phillw> cjwatson: is xserver-xorg-video-openchrome package to 0.3.1 a post Beta1 install?
<ochosi> xnox: so theoretically, if i add the @define dark_fg/bg_color to the gtk theme, the bug should go away? (or do i need to pull the changed files from your branch?)
<cjwatson> phillw: Dunno
<cjwatson> ochosi: Right - well, also what you get if you just let the image boot noninteractively
<cjwatson> But basically anything where you boot straight into a session that runs ubiquity rather than a live session
<ochosi> ok, sounds good
<ochosi> btw, this just loads xfsettingsd (i.e. xubuntu's default settings), no? http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/bin/ubiquity-dm#L413
<cjwatson> And runs xsetroot, yes.  In general we need help from desktop maintainers in refining that stuff
<cjwatson> It's meant to be "this is the minimum stuff we need to run to make things look roughly right" rather than "full DE experience"
<ochosi> ok
<ochosi> yeah, makes sense
<cjwatson> Bearing in mind that we don't typically want the normal panels and stuff
<ochosi> ok, so i have a tiny patch to fix a bug with xubuntu and ubiquity-only
<ochosi> i guess i need to propose a branch for review/merging? (even though it's just 7chars or so)
<cjwatson> That would be easiest for us if you wouldn't mind, although we can deal with plain old patches too
<cjwatson> (diff -u though, not ancient-style plain diff)
<ochosi> ok, i'll try to do that (branch)
<ochosi> basically it's s/xfwm4/xfwm4 --compositor=off/
<ochosi> quite the teeny-weeny patch :)
<cjwatson> skaet,jibel: So, yeah, the .2 respin was an accident.  I suggest we go with .1
<cjwatson> (Ubuntu desktop)
<cjwatson> My terminal scrollback suggests there may have been accidental respins of Lubuntu and Xubuntu too
<skaet> cjwatson,  whats the difference between the contents of .1 and .2?
<skaet> most of the testing has been done on .2 at this time.
<cjwatson> skaet: Zero for amd64 and i386
<cjwatson> skaet: amd64+mac and powerpc got the new ubiquity, which shouldn't have affected them either way in practice
<cjwatson> 2.11.29 -> 2.11.30
<skaet> ok,  we'll just amalgamate test results then between the two builds and go with .2 then.
<cjwatson> Yeah, should be fine
<skaet> Thanks for clearing that up.
<cjwatson> Sorry for the mistake - I evidently didn't kill off those processes
<cjwatson> All this manual stuff needs to die a painful death :-)
<skaet> getting a better kill switch would be nice at some point ;)
<skaet> +100 on the manual stuff going bye-bye
<highvoltage> sounds like you've got the painful part down, at least
<cjwatson> The problem with killing is mostly that this enormous manual shell pipeline is subtly wrong in a few places
<cjwatson> A more souped-up Python reimplementation wouldn't be likely to suffer from the same problem
 * skaet has it on the wish list ;)
<skaet> elmo,  any concerns about the mirrors for our images tomorrow?   I'm thinking that since we've cut down on the images now,  there shouldn't be. ;)   But just wanted to check.
<jbicha> please reject gdm, I'm re-uploading with one more bugfix
<slangasek> jbicha: done
<stgraber> cjwatson: are you aware of anything weird going on with the publisher? ltsp finished building on everything but powerpc over an hour ago, yet rmadison still reports 5.4.3-0ubuntu3 instead of 5.4.3-0ubuntu4 when asking for ltsp-client-core
 * stgraber checks if it's just rmadison lying
<stgraber> looks like it's just rmadison, my local apt sees 5.4.3-0ubuntu4 at least on 64bit
<stgraber> skaet: rebuilding Edubuntu now
<ochosi> hm, i just filed a merge-request for a tiny patch in ubiquity, somehow the diff is huge suddenly
<ochosi> (to be clear, i bzr branched lp:ubiquity, modified, committed and pushed to my own ~ochosi/ubiquity/quantal-proposed branch, then requested a merge)
<skaet> hmm... chinese images haven't been respun since the ubiquity fixes,  I'm kicking off a respin of them now.
#ubuntu-release 2012-09-06
<skaet> chinese images built.
<stgraber> Edubuntu looks good so far, we might have our beta1 image ;)
<skaet> \o/
 * skaet crosses fingers
<skaet> by the way,   I set up:  http://localized-iso.qa.ubuntu.com/qatracker/milestones/233/builds
<stgraber> cool, now we just need testers ;)
<skaet> to start tracking the chinese images,    catbus2 has been testing.  :)
<skaet> known bugs so far are at: http://goo.gl/8QNDe
<stgraber> do we have a bug number for kvm starting with a silly resolution on 12.10? (> 2000px wide) I remember someone mentioning that issue here
<skaet> stgraber, I've not seen a bug resembling that today cross my radar.   please open it.
<skaet> pad looks reasonable right now,   results coming in to iso tracker....
<skaet> ok,  EOD time.
<phillw> skaet: it's now in the laps of the Gods. have a good rest. I was going to but have a wiki guy wanting to help out on the QA wiki area.
<cjwatson> ochosi: I'm pretty certain that you must have branched lp:ubuntu/ubiquity, not lp:ubiquity.  I'm afraid they're not the same and we don't use the former.
<knome> cjwatson, 12:15  cjwatson: bzr branch lp:ubiquity
<cjwatson> knome: I know that's what ochosi said he did, but it doesn't match the evidence, so I think he must have made a mistake
<cjwatson> LP should really warn you when you try to propose a merge where your branch has no revisions in common with the target
<psivaa> mterry, pong about 971353, if that's about reproducing it, this crash occurred almost every other vm installations using live session, ill try to see if this is still the case after .2
<ochosi> cjwatson: sorry you're right, i really branched lp:ubuntu/ubiquity by accident (it was late already...). i'll do it again
<ochosi> cjwatson: ok, works now
<ochosi> xnox: i tested your patch btw, it seems to do what it should!
<xnox> ochosi: ok. will merge.
<ochosi> xnox: i even got xubuntu's ubiquity-only session entirely bug-free once or twice, but then xfsettingsd was always defunct (i guess because i restarted ubiquity so often or something)
<ochosi> so the theme wasn't set correctly
<xnox> ok.
<xnox> ochosi: just the colour/contrast bug # is 744283 if you need to mark any of your bugs as duplicates of that one.... please do.
<smartboyhw> I do wonder: When is http://localized-iso.qa.ubuntu.com/ introduced?
<cjwatson> smartboyhw: end of March 2012
<ochosi> xnox: ok, thanks a lot!
<smartboyhw> Oh thanks cjwatson
<psivaa> cjwatson, is the live-session path the only supported one for side-by-side installation of amd64+mac?
<cjwatson> I can't think of a reason why that would be the case
<cjwatson> If partitioning depends on how you start ubiquity then we have a pretty weird bug somewhere
<psivaa> cjwatson, direct install does not present me an option to do side-by-side installation
<psivaa> cjwatson, the previous installed version had lvm and encrytion ticked during its installation
<cjwatson> Well that's bizarre.  Maybe xnox can think of a reason for it; I can't.
<cjwatson> Sounds like a bug though.
<smartboyhw> I do wonder then: Who does the coding of Ubuntu Chinese version/
<smartboyhw> Is there a Launchpad team or sth>
<psivaa> cjwatson, ill report one then and then leave it for discussion, also quitting the installer at this point (because it did not have side-by-side option) i get bug 1027648
<ubot2> Launchpad bug 1027648 in ubiquity "ubiquity crashed with ValueError in command(): I/O operation on closed file." [High,Confirmed] https://launchpad.net/bugs/1027648
<cjwatson> The differences in the Chinese edition consist of (a) some slightly different image build system code which the ubuntu-cdimage team maintains and (b) the different desktop-side configuration which is controlled by the ubuntu-defaults-zh-cn package.
<cjwatson> closed file> not again :(
<cjwatson> Useless error message, must do something about that one of these days
<smartboyhw> Oh
<psivaa> cjwatson, i could reproduce that quite often pls let me know if you need anything for it
<smartboyhw> cjwatson: How come is there no testcase description for the localized ISO QA tracker???
<cjwatson> psivaa: It's a generic error that can happen for all kinds of different reasons
<cjwatson> smartboyhw: No idea, I don't maintain the tracker
<psivaa> cjwatson, ok cool
<cjwatson> psivaa: It basically means "argh a backend process died and I don't know why"
<smartboyhw> OH alright
<psivaa> cjwatson, right, so if that needs to be narrowed down, i have a test case for it :)
<cjwatson> You have a test case for one of the many possible reasons it might occur ...
<cjwatson> I'll try to have a look at some point but I'm mostly working on GRUB at the moment
<psivaa> ok fine, i understand not so urgent too
<xnox> psivaa: have you filed a bug? I am monitoring and fixing bugs in launchpad as they are reported.... Pings on IRC do get lost =)
<psivaa> xnox, just doing it should be finished in 2 mins
<xnox> psivaa: thanks. Preferrably reported with ubuntu-bug with all the logs.
<psivaa> xnox, thats what i did but please check bug 1046779
<ubot2> Launchpad bug 1046779 in ubiquity "No option to perform side-byt-side installation for amd64+mac on quantal" [Undecided,New] https://launchpad.net/bugs/1046779
<xnox> psivaa: given that we do not currently have a way to unlock encrypted volumes and it is unsafe to resize locked encrypted volumes, what did you expect?
<xnox> psivaa: with locked encrypted volume we do not know how big the filesystem is inside it, nor how much disk space is used.
<psivaa> xnox, right i thought i gave this information prior to reporting the bug :), was doubtful if that's the reason
<xnox> psivaa: it's good. I am commenting on the bug and will mark it won't fix for now.
<xnox> psivaa: I am sure you are not the only person who will ask for this =)
<xnox> psivaa: so better keep it for reference.
<psivaa> xnox, ok cool
<knome> when's the sign off time?
<knome> 12UTC?
<smartboyhw> cjwatson, then who maintains the ISO QA Tracker? stgraber, xnox or skaet?
<smartboyhw> Ah, maybe the QA Team
<psivaa> smartboyhw, i think its balloons
<smartboyhw> Oh alright, the I will have to wait until 3 hours later:(
<cjwatson> stgraber maintains the software, I believe, but balloons may maintain the content
<xnox> smartboyhw: file a bug againsg ubuntu-qa-website somebody will get to it =)
<xnox> smartboyhw: worked for me both code & content wise
<xnox> smartboyhw: there is a link at the bottom of the site
<smartboyhw> xnox: I mean in the localized ISO QA Tracker mate
<xnox> smartboyhw: same
<smartboyhw> Well even the Testcase Admins Team can't edit the testcases:( I will find balloons
<xnox> smartboyhw: bugs are easier to track than irc, but maybe that's just me.
<smartboyhw> xnox: Yep, not for me LOL
<knome> skaet, i'm thinking that xubuntu will skip beta 1 looking at all the fails.
<cjwatson> Mainly bitten by the automounting vs. ubiquity problems I gues
<cjwatson> *guess
<cjwatson> Wonder why this is only biting us hard now given that the bug was first filed in Feb 2011
<xnox> there were further changes to xfce to use/not use hal/udisks/whatnot so maybe one of those "fail-backs" used to work yet thunar now "tries harder" to automount =/ this is a wild guess though on my part.
<cjwatson> Yeah, mustbe
<cjwatson> What is it with my keyboard today anyway
<xnox> cjwatson: well my VMs are on an external hard-drive (gotta love 1TB drives) and I am bitten by bug 1045781
<ubot2> Launchpad bug 1045781 in linux "usb 3.0 external hard drive spins downs and gets ejected" [Medium,Incomplete] https://launchpad.net/bugs/1045781
<cjwatson> That looks deeply irritating.  Not noticed that with my external terabyte disk
<cjwatson> Not via a docking station though
<xnox> cjwatson: I wonder if the problem is with missing partition tables though. As it is "whole disk lvm" which overrides / doesn't use partition table.
<bencer> iulian: ive updated this ffe as you requested https://bugs.launchpad.net/ubuntu/+source/zentyal-samba/+bug/1043654
<ubot2> Launchpad bug 1043654 in zentyal-samba "[FFe] New version of zentyal-samba" [Undecided,New]
<mterry> psivaa, hello!  Is it possible for you to try to reproduce bug 971353 after installing my gnome-settings-daemon package with the fix from quantal-proposed?
<ubot2> Launchpad bug 971353 in gnome-settings-daemon "power : gnome-settings-daemon crashed with SIGSEGV in gnome_rr_screen_get_dpms_mode " [High,Confirmed] https://launchpad.net/bugs/971353
<psivaa> mterry, i could do that
<psivaa> mterry, but i need to look up how to get the package
<mterry> psivaa, https://wiki.ubuntu.com/Testing/EnableProposed
<psivaa> mterry, thanks
<skaet> good morning
<smartboyhw> Good morning skaet
<skaet> smartboyhw,   questions about the iso tracker can be asked in #ubuntu-iso-tracker channel.
<smartboyhw> There IS that channel? Oh I don't know!
<skaet> people with perms to change things usually hang out there.   :)
<smartboyhw> Alright I will:)
<skaet> yup,  its on Freenode
<skaet> cjwatson, not seeing much change on the tracker or in the backscroll,   other than knome deciding xubuntu's a no-go for beta1,  anything else of note?
<skaet> Laney, ^ ?
<Laney> lack of ppc testing is notable I guess
<skaet> Laney,    ok,  those images need to get removed from the iso tracker then, if not tested by now.
<Laney> skaet: OK. I'll remove Xubuntu too as well.
<smartboyhw> Bye bye xubuntu!
<skaet> Thanks.  :)
<Laney> there
<Laney> I probably won't be around this evening to press the buttons BTW
<cjwatson> Nothing else that I've seen; all has been pretty quiet
<cjwatson> And I agree with knome's assessment
<cjwatson> I can be around for a while this evening, though I would significantly prefer it not to be very late
<skaet> thanks cjwatson,   I'll try to hurry up collecting the status from the teams, and go/no go decisions where its ambiguous.
<skaet> and on that note...
<skaet> Riddell,   which of your images are you comfortable with releasing?
<Laney> I will probably be back later on, but you'll be done by then ;-)
 * skaet hopes so. ;)
<skaet> gilir, phillw - images look pretty well tested on the lubuntu side except for powerpc desktop.   and amd64+mac desktop.   Anything else you want held back?
<skaet> utlemming,  how are the cloud images looking?    test results ok?
<Riddell> skaet: i386 and amd64 alternate and desktop kubuntu, kubuntu-active and kubuntu armhf tests due shortly
<Riddell> hmm that could be a confusing sentence
<Riddell> skaet: i386 and amd64 alternate and desktop kubuntu, kubuntu-active good for release.  kubuntu armhfkubuntu armhf tests due shortly
<brendand> skaet, release meeting - or no because of beta1?
<cjwatson> Ubuntu server armhf+omap4 looks kind of wonky
<skaet> brendand,  likely to have meeting tomorrow
 * skaet basically planning on it,  unless release goes on late into the night
<utlemming> skaet: cloud images are looking good after the respin. Test looks good too
<Daviey> cjwatson: wonky?
<cjwatson> bug 1045788 mosty
<ubot2> Launchpad bug 1045788 in linux-ti-omap4 "screen on quantal server images stays black" [High,New] https://launchpad.net/bugs/1045788
<cjwatson> *mostly
<cjwatson> Is that release-notabe?
<skaet> yeah,  was wondering if it was usable or not with that one.
<skaet> anyone else reproduced it?
<cjwatson> The bug does say there's a way to install over serial
<Daviey> ugh
<Daviey> ogra_ is occupied atm.. would like him to expand when he is back.
<smartboyhw> Lubuntu Alternate powerpc looks conky to me, 1 fail for EACH testcase. Desktop too
<skaet> Daviey,  what about MAAS server tests not being run,  I'm assuming its because the version there isn't usable.   Has that been release noted?
<Daviey> skaet: No, the version is usable.. and tested.. it just hasn't been captured
<Daviey> Oh, wait.
<Daviey> There is a release note to add. Thanks.
<skaet> utlemming,   cool.  :)   please update the tracker, so we can mark them as ready.
<utlemming> skaet: tracker is updated. The tests showing as 1/2 are marked that way because the tests aren't performed
<ogra_> cjwatson, i need to write release notes for that, yeah, serial install is possible with the current server images
<psivaa> mterry, i keep getting "E: Release 'quantal-proposed' for 'gnome-settings-daemon' not found" message when trying to install the package
<cjwatson> OK, so not a blocker?
<cjwatson> There's no gnome-settings-daemon in quantal-proposed right now ...
<ogra_> not after i wrote some documentation :) (or if people are clever enough to discover that there is a preEnv.txt-serial they can copy over preEnv.txt  on the first partition of the SD)
<smartboyhw> Suddenly all the Server EC2 images are all tetsed
<smartboyhw> Wow
<skaet> smartboyhw,  utlemming had done the runs on another machine, and just triggered the copying of the results over.
<smartboyhw> OH yeah!
<smartboyhw> More importantly, the upgrade testcases
<smartboyhw> Edubuntu and Lubuntu upgrades: nobody
<skaet> highvoltage, are we ok on the Edubuntu Upgrade tests?
<skaet> phillw, gilir - either of you around?
<smartboyhw> skaet: Apparently not:)
<skaet> Riddell,  did anyone test Netboot for a Kubuntu install?   if so,  any issues?
<Riddell> skaet: hmm no, I haven't tested that in ages, can do if it's needed though
<skaet> Riddell,  might be nice to make sure no surprises,  esp.  since Xubuntu's not participating.
<ogra_> phew, my release notes change will become a novel this round
<skaet> :)
<ogra_> so many changes in arm land
<jamespage> skaet, sorry - might just have conflicted a change on the tech overview change with you
<jamespage> change/page
<skaet> jamespage,  I'm out now.   can you double check?
<skaet> scott-work,  can you update the https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview/Beta1 for Ubuntu Studio?
<cjwatson> urgh.  sore throat and feeling a bit rubbish.  going to lie down with a lemsip for a bit in order that I can be useful later
<skaet> cjwatson,  thanks for letting me know.
<cjwatson> sms me if world explodes
<skaet> will do.
<ogra_> though the boom shoudl wake you up anyway :)
<skaet> xnox,  could you take a pass at writting up an explanation in https://help.ubuntu.com/community/QuantalUpgrades of how to do upgrades without Alternates now,   and add some information to https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview/Beta1 on the subject as well?
<xnox> possibly.
<xnox> slangasek: what are our upgrade options now? over the network with release manager & ubiquity/d-i reinstall with preserving settings
 * smartboyhw will quit now to sleep
<xnox> skaet: since reinstall is not mentioned already the alternate cd section should be gone.
<skaet> xnox, go ahead and edit as seems appropriate,  we can review later and improve.
<highvoltage> skaet: no
<skaet> highvoltage, ok, we're missing those tests and updates to https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview/Beta1
<jamespage> skaet, looks OK - my changes are still there
<stgraber> skaet, highvoltage: I'm running them as we speak
<highvoltage> stgraber: awesome
<skaet> highvoltage, can you take care of the TechnicalOverview ?
<stgraber> was just about to say that ^ :)
<highvoltage> yes, not right at this minute because I'm in a heated meeting at the office, but yes.. soon
<xnox> skaet: which flavours have alternate CDs still?
<skaet> Riddell,  of the Kubuntu images not marked ready on http://iso.qa.ubuntu.com/qatracker/milestones/232/builds,  which are likely to still get results, and which should just be removed at this point?
<skaet> xnox,  Lubuntu and Kubuntu
<xnox> skaet: and Xubuntu in general has them, but it's not released.
<Riddell> skaet: armhf+omap4 just got a tick of approval
<bdmurray> skaet: if a bug is targetted to quantal shouldn't it not be tagged rls-q-incoming?
<skaet> bdmurray,  yes,  I should have removed the tag if it was there.   (my bad if I missed it)
<Riddell> skaet: powerpc I'm not fussed at all about, scrap it. amd64+mac jibel was good enough to test last time but I'm also not very fussed about it
<skaet> Riddell,  thanks,  done.
<tremolux> ScottK: hi! I just wanted to ping you to see if you are good with this FFe for Software Center: https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/1044107
<ubot2> Launchpad bug 1044107 in software-center "Feature Freeze Exception: Recommender feedback (no UI change)" [Undecided,New]
<Riddell> xnox: at some point I need to chat to you about what needs done to ubiquity kde frontend to get rid of alternates
<ScottK> tremolux: Commented.
<phillw> skaet: hi, sorry I've been ridding the works computer of mal-ware :(
<xnox> Riddell: sure, just chat to me any time =)
<phillw> just got back home
<tremolux> ScottK: thanks! I appreciate your attention to this one!
<skaet> thanks phillw,   there are some lubuntu images without testing,  trying to figure out if they are release/not.
<phillw> the mad-mac has been trouble free for ages. I'm happy for it to go through.
<phillw> *amd-mac*
<phillw> the powerpc with the bug is to be reported in release notes (it also affects i386)
<ogra_> wasnt that mad-max ?
<phillw> lol
<skaet> ok,  I see now that Lubuntu Desktop amd64+mac had full results in 20120904 image,  marking it ok.
<skaet> phillw,  Lubuntu alternate powerpc though doesn't have a history of tests being run, and all tests in it, are marked failed.  So I think that one better stay off the release list,  unless there is more data that hasn't been added?
<phillw> bug 1041625 is getting attention, I think to release lubuntu ppc desktop with the note in release?
<ubot2> Launchpad bug 1041625 in openchrome "X not starting after install [openchrome]" [Critical,Confirmed] https://launchpad.net/bugs/1041625
<skaet> lubuntu ppc desktop looks reasonable,  its the alternate ppc one that looks bad.
<skaet> Laney,  can you do a link check on the pre-publishing scripts?
<phillw> sorry, alternate. If the proposed fix hasn't worked Then I reckon its still borken. The bug is highly active, so they are working on it.
<phillw> as long as we have one ppc then we'll survive :)
<skaet> phillw,  ok,  can you make sure there's a note on it in the TechnicalOverview,  and we'll go out with just the desktop one.  :)
<phillw> skaet: do you have the link for the notes & I'll get right on it.
<skaet> phillw, https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview/Beta1
<skaet> thanks!  :)
<phillw> skaet: under lubuntu or under kniown issues, Graphics & Display?
<Laney> ERROR: Cannot handle product Lubuntu preinstalled armhf+ac100
<Laney> let's see
<stgraber> Laney: oh yeah, that's a new one, the script will need some updating... want me to do it?
<skaet> phillw,  under lubuntu please.
<skaet> Daviey, arosales - have you finished your edits for Server and Cloud to the TechnicalOverview?
<Laney> stgraber: sure
<Laney> thanks
<Daviey> skaet: Need to check once more
<skaet> Daviey, ack.     Also,  can you please check you agree with the images I've marked as ready on the iso tracker for server too.
<stgraber> Laney: actually, the problem is on the tracker's side, fixing there
<Laney> no 'desktop'?
<Daviey> skaet: looking now
<skaet> thanks
<stgraber> Laney: right
<phillw> done
<arosales> skaet: was going to check with Daviey :-)
<skaet> thanks phillw!
<stgraber> Laney: publish-image-set looks happy now
<Laney> yep, good work
<ogra_> yay
<ogra_> \o/
<Daviey> skaet: confirmed, that is good
<skaet> Thanks Daviey
<xnox> skaet: I updated the upgrade wiki page and the upgrade subsection on the technical overview.
<phillw> skaet: lubuntu desktop ppc has vanished?
<skaet> xnox,  thanks,  I'll review it.
<skaet> phillw,  checking...
<Laney> skaet: which links?
<Laney> in the HEADER.html files?
<skaet> Laney,  links in the https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview/Beta1 will match where the pre-publishing script expects them to go.
<cjwatson> OK, back
<skaet> phillw, ok, its back on the tracker for desktop, but are you really sure you want a ppc going out with the release?   results don't look that good on this one either,  although it has historically had more testing than the ppc alternate though.
<skaet> hiya cjwatson,   I think we're pretty close to our release set now,  just a few last checks.
<Laney> yeah can't see anything wrong there
<Laney> no link to china-images?
<phillw> skaet: as there have been changes made and cj had it run okay (albeit in VM) I think it is good to go.
<cjwatson> phillw: I didn't do a full install, and somebody else reported the same inability to see anything useful in the installer
<cjwatson> Laney: the Chinese edition typically needs manual handling for milestone publication
<cjwatson> I can take care of that for now
<phillw> cjwatson: if you think it is 'toast' then there is no point releasing.
<Laney> yeah I understand that
<Laney> I was referring to the list on the TechnicalOverview
<slangasek> xnox: correct
<cjwatson> phillw: My experiment was more "I can't figure out how to reproduce this problem" than "it doesn't exist"
<phillw> both the ppc's will re-appear as dailies. further investigation can be carried out there.
<phillw> it's only Beta 1, we have time to fix them :)
<xnox> slangasek: It would be nice to be able to have a command to generate package list & have something parse that list and download _signed_ releases & tarball + partial mirror of packages. Modify update-manager to be able to use that. And generate a USB stick or something to enable offline support.
<xnox> slangasek: mvo said update-manager can work against a mirror.
<slangasek> xnox: sure; getting u-m to use an unofficial mirror is a bit fiddly though.  IIRC cjwatson knows something about those runes
<cjwatson> I have:
<mvo> xnox: parts of this you could do with synpatic by doing a dist-upgrade and then create a download script but I guess you are looking for something more cli friendly
<cjwatson> $ cat /etc/update-manager/release-upgrades.d/local-mirrors.cfg
<cjwatson> [Sources]
<cjwatson> ValidMirrors=/etc/update-manager/local-mirrors
<slangasek> synaptic> eeew ;)
<mvo> slangasek: ;)
 * mvo is *old*
<cjwatson> $ cat /etc/update-manager/local-mirrors
<cjwatson> http://mirror/ubuntu
<cjwatson> http://mirror.pelham.vpn.ucam.org/ubuntu
<cjwatson> http://gb.archive.ubuntu.com/ubuntu
<cjwatson> http://archive.canonical.com/ubuntu
<cjwatson> http://extras.ubuntu.com/ubuntu
<cjwatson> http://security.ubuntu.com/ubuntu
<cjwatson> Which basically works although perhaps there is a more elegant way
<slangasek> yeah, that's basically what I remember
 * mvo &
<slangasek> i.e., you have to duplicate the mirror list, you can't append to it?
<mvo> oh? if so, that should be easy to fix
<mvo> could someone remind me about this tomorrow please? if its really not appending
<cjwatson> Well, that was the case years ago when I did this
<cjwatson> That file is timestamped May 2011 here and might have been created earlier ..
 * mvo nods
<skaet> Laney,  Chinese images generally get announced through PES processes, rather than on TechnicalOverview.
<Laney> k
<xnox> mvo: I am ideally looking for something that is part of update-manager & by magic supported in 12.04.0 release =)
<xnox> mvo: both gui & cli
<skaet> xnox,  looks like we've lost mvo from the channel.
<xnox> cjwatson: I had no clue about those! that's awesome =)
<xnox> skaet: noticed no tab-completion.
<xnox> mvo: read irclogs.ubuntu.com =)
<skaet> phillw,  removing the desktop ppc.  Dailies is best until its more usuable.
<gilir> skaet, do you need more info for lubuntu beta 1 ?
<phillw> skaet: is it possible to copy those two beta 1 candidtaes over to dailies, instead of having the old ones there until the next respin?
<skaet> gilir,  they're actually in the dailies right now.   Just have to go to them through the web page,  but yes,  remind me later, and I'll make them explicitly there.
<skaet> oops.
<skaet> phillw, ^
<phillw> skaet: thanks
<skaet> gilir,  could you please review the publishing set on the iso tracker and make sure you're ok with them?
<skaet> plars, how looks the upgrade WUBI tests?
<plars> skaet: slow
<plars> skaet: they take a *very* long time
<plars> skaet: psivaa is running on i386 right now, and I'm running on amd64
<gilir> skaet, it's ok for me, thanks
<skaet> gilir, phillw,  how do the upgrade lubuntu tests look?
<skaet> thanks gilir
<Riddell> kubuntu netboot good
<phillw> skaet: I've not looked at them
<Riddell> skaet: I'm off out for a few hours, I think kubuntu is good to go
<Riddell> skaet: mparillo is our new web man to be poked when the announce goes out
<skaet> thanks Riddell.   will poke mparillo when we're ready then.  :)
<skaet> cjwatson,  I think our image set is pretty close,   can you start the pre-publishing?
<skaet> heh,  and utlemming shows up just in time ;)
<cjwatson> On its way
<skaet> utlemming, can you start the pre-publishing of the cloud images now too.
<cjwatson> sync-mirrors disabled
<utlemming> skaet: pre-published already, just waiting for the go ahead to make public
<skaet> utlemming,  ok.
<cjwatson> pre-publication syncing out
<highvoltage> my wiki search skills are failing me, where's the current technical overview page?
<xnox> highvoltage: grep this channel logs up.....
<xnox> highvoltage: https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview/Beta1
<wxl> skaet: do we need any further testing beyond the mandatory tests for beta1?
<highvoltage> hmm, I thought I tried that one, possibly just had a typo. thanks xnox
<highvoltage> stgraber: did ltsp go ok or do we need to release note something?
<skaet> wxl,  a bit more context?
<wxl> skaet: trying to figure out if i should bother testing stuff that's already got all of its mandatory tests done
<skaet> wxl,  any information and key issues that can be found now is welcome.
<skaet> we can continue to add to the beta 1 release notes,  even after the images get published.
<wxl> i take that as a no. :)
<skaet> wxl,  actually I was trying to say,  please do continue testing.   More results welcome. ;)
<skaet> when we publish though,   the iso tracker will be set back to daily images though, so feel free to record results there if needed.
<wxl> skaet: i guess what i'm thinking is if we've satisfied the major tests, now i can move on to testing the release and all of its software more. more of a usability test than an install test.
<skaet> wxl,  ok.
<wxl> and then of course go back to the dailies :)
<wxl> i guess i was surprised the beta testing wrapped up so quick
<wxl> ok thanks for the help
<stgraber> highvoltage: you may want to mention bug 1039155
<ubot2> Launchpad bug 1039155 in nux "Unity fails to load on old hardware. Missing automatic fallback to LLVMpipe" [High,Confirmed] https://launchpad.net/bugs/1039155
<stgraber> highvoltage: some virtual thin clients may get an empty desktop because of it
<highvoltage> stgraber: ok
<cjwatson> skaet: If you don't mind, I think I might start the publication process on nusakan nowish, just with sync-mirrors disabled
<cjwatson> And then we can just shove that out when you're ready
<scott-work> skaet: i will update that
<cjwatson> skaet: Is the ISO tracker ready status complete (for the purposes of publish-image-set - so I don't care about upgrades and such) or is there more to do?
<cjwatson> Actually I don't care about netboot either, so it looks complete to me
<skaet> cjwatson,  sounds like a plan.
<skaet> scott-work,  thanks.
<cjwatson> skaet: On its way.
<skaet> cjwatson,  any processing needed on the quantal queues before we unfreeze the archive?
<skaet> utlemming,  you may as well start publishing now too.
<utlemming> skaet: publishing images now
<cjwatson> skaet: Not AFAIK
<cjwatson> I figured it'd just be 'queue -Q unapproved accept'
<cjwatson> (and wait for the *thud*)
<skaet> cjwatson, ok.   will ask for them to be unfrozen now then.
<utlemming> skaet: images are public; cloud-images.ubuntu.com is now syncing
<highvoltage> stgraber: I think Edubuntu is ok on the technicaloverview
<stgraber> highvoltage: ok, thanks
<utlemming> skaet: cloud image sync done
<skaet> ok, archive is now open again.
<jbicha> hey, so there's an interesting bug where clutter needs to be built with the new gobject-introspection so it would save a rebuild if you held off on approving clutter-1.0
<cjwatson> Right
<cjwatson> skaet: Want me to walk through the queue once I'm done publishing, then?
<skaet> cjwatson,  please
<skaet> scott-work,   have you made your changes?
<cjwatson> skaet: publication now completely staged on nusakan, I believe
<cjwatson> skaet: if you want to give it a quick once-over, now's a good time
 * skaet looking
<infinity> Hrm, I should do a round of chroot-updating to deal better with this unapproved flood.
<skaet> cjwatson, Laney - can you take a review pass at: https://wiki.ubuntu.com/QuantalQuetzal/Announcement/Beta1?
 * skaet still missing bits from Ubuntu Studio, but hopefully have not left accidental 12.04 refs in the wrong place :P
<cjwatson> infinity: Yes please
<cjwatson> infinity: If you can actually update chroots following the DC move
<infinity> cjwatson: I can from cocoplum... *cough*
<cjwatson> infinity: Oh, that's still up and running?
<infinity> Yep.
<infinity> Cronjobs are all off, of course, but it still has the LP tree and all the right perms.
<skaet> cjwatson, not spotting anything wrong,  go ahead with the sync and I'll start checking the links.
<infinity> Of course, fixing sudo access on pepo would be preferable...
<cjwatson> skaet: Made a couple of minor changes.  Perhaps we should mention that Xubuntu isn't dead, to forestall panic?
<skaet> cjwatson - good point.
 * skaet likes forstalling panic
<cjwatson> Oh, blast, I forgot to do .manifest before syncing
<cjwatson> I'll sort that in a bit
<cjwatson> Should be on releases now; cdimage is sorting itself out gradually
<scott-work> skaet: no i haven't yet, i'm pretty busy today at work, when do you absolutely need it done?
<skaet> scott-work.  1200 UTC this morning.   Its on critical path for announce going out right now.
<scott-work> skaet: i'll do it now
 * cjwatson turns to the queue
<skaet> cjwatson, ok
<skaet> thanks scott-work.
<cjwatson> Also: I'd like to leave in no more than half an hour so that I can get dinner and get my stepson to bed in time for school tomorrow
<cjwatson> infinity: Probably best not get into that habit too much though; wouldn't take too many schema changes to break things.
<skaet> cjwatson, can you check that the torrents are working?
<cjwatson> Not easily, I'm NATted
<stgraber> skaet: just assume they aren't and start poking IS ;)
<skaet> stgraber,  indeed.    can you help out with the checking?
<skaet> cjwatson, http://cdimage.ubuntu.com/ubuntu-core/releases/quantal/beta-1/
<skaet> not spotting the core images published yet?
<stgraber> skaet: sure, I can test
<cjwatson> skaet: It's still syncing
<cjwatson> skaet: Look on nusakan, they're there
 * skaet double checks and puts on her patient hat.
<cjwatson> I can't make rsync go faster I'm afraid :-)
<skaet> :)
<cjwatson> Note that rsync tends to create all the directories first
<stgraber> skaet: doesn't work
<cjwatson> As long as you see Archive-Update-in-Progress-blah at the top of cdimage.ubuntu.com, it's still going
<stgraber> skaet: getting the usual "Requested download is not authorized..."
<cjwatson> Yeah, almost certainly needs the tracker restarted
<stgraber> skaet: torrent.ubuntu.com is the one returning that. ipv6.torrent.ubuntu.com works but has no seeder (as the seedbox on torrent.ubuntu.com is probably broken again)
<skaet> *sigh*
 * cjwatson fights through repeated queue timeouts.  I really must get that async branch finished and landed
<cjwatson> Oh dear goodness accepting apt might be fun.  *How* many duplicates?
<slangasek> why are the amd64+mac images being published to a different place than amd64/i386?
<cjwatson> slangasek: s'what the manifest says
<cjwatson> I gave up fighting that a while back
<slangasek> mm?
<cjwatson> I guess because it's less used than amd64 (presumably anyway) and the criterion for releases.u.c publication is popularit
<infinity> Wasn't there some magical hope of ditching +mac this cycle anyway?
<cjwatson> y
<skaet> slangasek,  historical mostly.  I think it had to do with what we considered supported hardware.
<slangasek> skaet: no, it has nothing to do with what we consider supported hardware
<cjwatson> infinity: Yeah, although I've not had what you might call glorious success with that yet
<cjwatson> skaet: If it did, then somebody has misunderstood the purpose of releases.u.c - given that ARM images aren't there
<infinity> cjwatson: Did you try buying Matthew alcohol and locking yourself in a room with him?
<cjwatson> infinity: What I need to do is buy myself alcohol and lock myself in a room with his blog and a hexdump of our images
<infinity> Heh.
<slangasek> cjwatson: what're you drinking? ;P
 * slangasek looks for an online liquor store that ships to the UK
<skaet> slangasek,  well,  since didn't have amd64+mac hardware until just recently for the testing farms,  it felt like a second class citizen.
<cjwatson> Talisker 30yo, if you're buying :-P
<slangasek> haha
<skaet> :)
<infinity> Right, let's see if I can update chroots without a kernel panic this time.
 * infinity stares at his laptop.
<slangasek> skaet: so, especially given that we no longer have the space issues on releases.u.c (thanks to the alternates going away), I think we should reconsider putting amd64+mac and armhf+omap4 to releases.u.c for beta2
<infinity> +1
<cjwatson> We should remember to clear out maverick from there at some point, though not today
<slangasek> btw, I see powerpc images aren't published at all
<slangasek> or even listed for testing on the tracker?
<cjwatson> publish-image-set didn't show me any powerpc entries, so I assume there was some failure (but haven't been keeping track)
<cjwatson> Queue mostly flushed.  Wasn't totally sure whether the X stack involved any ABI changes, and didn't have time to check, so left it there for now; feel free to accept if it's all fine.  Left clutter-1.0 there per jbicha's comment an hour or so ago.  Left apt there because I'm going to need to get an op later to accept it for me.
<slangasek> the bot reported a powerpc desktop image about 24h ago, but I don't see it linked from the tracker at all now
<cjwatson> And I really ought to go now; can the rest of you take it from here
<cjwatson> ?
<infinity> Yup.
<infinity> apt's timing out on bug closures, I assume?
<cjwatson> Yeah, it's trying to close a bug that has a zillion dupe.
<cjwatson> +s
<infinity> Fun.
<infinity> Try in a loop and hope for a hot cache? :P
<cjwatson> I have a branch up that'll fix this for good; just needs a bit of deployment dancing.
<cjwatson> It'd have to be boiling
<cjwatson> Take a look at the RH column of bug 346386
<infinity> Not sure boiling caches are an option in our setup.
<ubot2> Launchpad bug 346386 in apt "[MASTER] Update fails with invalid package files with "Encountered a section with no Package: header"" [High,Fix released] https://launchpad.net/bugs/346386
<infinity> Oh, you clever trickster, sending me to a bug that will obviously timeout when I try to read it. :P
<cjwatson> WFM
<infinity> Second time's the charm.
<cjwatson> It's finding the set of subscribers to all the bugs that's hideously slow
<cjwatson> >>> len(lp.bugs[346386].duplicates)
<cjwatson> 365
<slangasek> workaround: hop in time machine, close bug 4 years ago
<ubot2> Launchpad bug 4 in launchpad "Importing finished po doesn't change progressbar" [Medium,Fix released] https://launchpad.net/bugs/4
<cjwatson> Thanks, ubot2, that was helpful
<infinity> He's just trying to remind slangasek that style guides recommend writing small integers in English.
<infinity> "bug four years ago" wouldn't trigger bot annoyance. :P
<cjwatson> Damnit I thought about saying that and decided it would be too pedantic. :-)
 * slangasek laughs
<jbicha> should the -proposed stuff be pushed to quantal too?
<slangasek> only after someone's checked that it gives a consistent archive
<jbicha> ok
<mterry> psivaa, any luck reproducing that g-s-d crash?
<plars> mterry: I think he left a bit ago, I've seen it a few times too, but I'm afraid I don't have a reliable way to reproduce it.  Seems a bit random at the moment
<plars> mterry: did you have some ideas about how to poke at it in a way that might trigger it more reliably?
<plars> not sure what you discussed with him previously
<mterry> plars, no, no ideas
<mterry> plars, just a possible fix
<ScottK> What's the Canonical IS IRC channel again?  It looks like kubuntu.org just died.
<skaet> slangasek,  re: contents for releases.u.c - as long as the product owners agree,  I'm +1 on it.   Will simplify tracking from my perspective.
<skaet> slangasek,  powerpc images were on tracker.  Got removed so wouldn't publish, due to some not tested, others with too many bugs.    see /history
<stgraber> ScottK: #canonical-sysadmin
<ScottK> Or stunningly slow.
<ScottK> stgraber: Thanks.
<ScottK> Fixed itself as soon as you told me the IRC channel.  Perfect.
<stgraber> :)
<infinity> cjwatson: apt accepted fine from the web UI, oddly enough.
<slangasek> skaet: yeah, I can't imagine the product owners are going to object to moving the images somewhere central.  Though, note that this doesn't move *all* the images to releases.u.c, since powerpc and armhf+omap would still be on cdimage as community ports
<slangasek> skaet: what's /history?
<skaet> slangasek,  on iso tracker s/builds/history/
<skaet> will let you see all the subsequent images published.
<slangasek> ah.  that's not linked at all in the UI, it seems?
<slangasek> oh, there it is, "See removed and superseded builds too"
<Laney> well done folks
<ScottK> Are we there yet?
 * ScottK wonder if Laney's comment means we are.
 * Laney checks omgubuntu to be sure
<highvoltage> heh
<iulian> :)
<dobey> i take it all the ppa builders have been comandeered for image respins or something?
<Laney> no, doesn't work like that
<infinity> Hardware certification, perhaps.
<Laney> click a disabled builder's name and you can see why it's disabled (if it's filled in)
<infinity> And for the red Xs, more likely just some "issues".
<infinity> Since kidnapping for certification tends to take them right off the list.
<dobey> oh; half the i386 ones are just Disabled :(
<xnox> mterry: the g-s-d crash you are talking about... are there any symptoms that are inspectable in the logs on a live cd?
<xnox> mterry: cause ubiquity forgets to use ubuntu font when g-s-d crashes
<xnox> mterry: in "Install Now" mode. And it's fairly reliably crashing g-s-d.
<mterry> xnox, not that I know of
<xnox> mterry: e.g. does a crash produce /var/crash/* or something like that?
<xnox> mterry: cause in that mode there is no whoopsie running.
<mterry> xnox, oh, it should yeah
<mterry> apport does that, right?  and is that not running?
<slangasek> whoopsie and apport should both be running; but you may not have any way to ack whoopsie's request to submit
<xnox> ok. I'll try testing then & see what's going on.
 * xnox Beta1 is out. Thank you everyone, and sorry for all the ubiquity caused respins =/
<ScottK> xnox: It's not out until the release announcement is sent.
<ScottK> (i.e. not yet)
<iulian> We can still go to the pub.
<xnox> oh ok. So omgubuntu is ahead of the time.
<ScottK> xnox: Like every single release.
<Laney> it doesn't say it has been released
<Laney> 'made available for download'
<xnox> lol =)
<xnox> I bet they even watch this channel
<xnox> Omg!ubuntu reveal yourself =)
 * skaet sees most now, except for core and ubuntustudio...
 * infinity wonders why the base buildd chroots have grown by ~4MB...
<xnox> infinity: apt-get clean ?
<infinity> xnox: Yeah, did that. :P
<xnox> =)
<infinity> xnox: I'll compare in a sec.  It's a rather curiously large bloat.
<xnox> infinity: python3 sneaked in?
<infinity> No new packages, just upgrades.
<infinity> So, something got a lot fatter.
<infinity> Or lots of things got a little fatter.
<infinity> Which does happen over the course of every release, but 4M in a month or two seems large.
<infinity> 4M compressed, even, so lots of fat uncompressed.
<infinity> cjwatson: Dangit, you were right.  Schemas have already diverged to the point where manage-chroot on cocoplum doesn't work anymore. :P
<cjwatson> infinity: I have a branch lying around to allow submitting chroot tarballs in the webapp - maybe I should get that in sooner rather than later
<infinity> cjwatson: That won't just end in timeout tears?
<cjwatson> infinity: I don't think so - it's more like apport blobs
<infinity> cjwatson: (I wonder if one couldn't make poppy and the queues do double-duty here somehow...)
<cjwatson> But I haven't actually tried it end-to-end :-)
<cjwatson> We could use process-upload for it, yes.  I don't think it's necessary, but it would be one option.
<infinity> No, perhaps not necessary, but chroots map directly to DASes, so it feels like something one could do custom-uploady, and get an audit trail for free.
<infinity> And then I could just jam all 5 arches in one .changes and let it go.
<bdmurray> I'm looking at bug 909996 which has an sru in oneiric-proposed and I'm not sure how to proceed.  I'm leaning towards rejecting it per it not being fixed all the way.
<ubot2> Launchpad bug 909996 in b43-fwcutter "firmware-b43legacy-installer errors "17: missing"" [Medium,Fix committed] https://launchpad.net/bugs/909996
<ScottK> Does it represent progress from the current state of affairs?
<bdmurray> Yes but it is still broken.  So should we have people update for something that is still broken?
<cjwatson> I'm slightly reluctant to do the process-upload bit because I'd have to extend .changes to support uploading to things that aren't source or binary.
<infinity> cjwatson: Oh, do we have no custom types that aren't, ultimately, attached to a sourcey or binaryey thing?  Yeah, nevermind.
<ScottK> If it's not broken enough to be useful in some cases, I'd say it's OK.  If it's less broken, but still never succeeds, then I agree it should get rejected.
<cjwatson> infinity: Indeed not.  The last anomalous case was DDTP, and we fixed that.
<infinity> cjwatson: I'm just irrationally distrustful of submitting blobs over http.  I'm sure if someone writes a highly unreliable python wrapper that does it for me and I ignore the tracebacks, I'll never need to know it's a massive http POST! ;)
 * Riddell arrives back
<phillw> Riddell: wb
* ChanServ changed the topic of #ubuntu-release to: Quantal Quetzal Beta 1 released! | Archive: Open | http://pad.ubuntu.com/ubuntu-release | 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 cjwatson, Laney,   looks like we're out now.
<Laney> \o/
 * Laney marks as released
<skaet> :)
 * Laney twiddles .isotracker.conf and re-enables cron
<skaet> thanks Laney :)
<Laney> will you speak to webops to get the freeze lifted?
<Laney> or is it done?
<Laney> it is
<skaet> already done earlier.  :)
<skaet> soon as we had the image set,  seemed good to do it.   cjwatson cleaned out the queue.
<Laney> makes sense
<skaet> Laney, can you do the debian-cd/CONF.sh changes?
<Laney> I don't know how that works
<Laney> someone could teach me
<cjwatson> Too tired to teach but I can do it and you can look at my revision
<Laney> oui
<cjwatson> Haha
<cjwatson> Nobody changed it to Beta in the first place
<cjwatson> So nothing to do
<cjwatson> Process win
<cjwatson> Still says OFFICIAL="Alpha"
<Laney> you need professional, come to us
<Laney> what effect does that variable have?
<cjwatson> Volume labels
<cjwatson> Worth doing for polish but not world-shattering
<skaet> unfortunate... needs to be automated ;)
<cjwatson> Right, knackered.  /me -> bedwards
<Laney> tata
<skaet> sleep well.
<phillw> skaet: hi, thanks for the release notes, I've passed on to Lubuntu-QA team. you asked that I remind you later about getting the failed ppc - QA beta 1's onto daily tracker. The guys have been busy tonight working on it, so if you do get chance to do the manual edit it would be appreciated for when Dailies are turned back on.
<skaet> thanks phillw,  I needed the reminder.   :)  taking care of it now.
<phillw> we kidnapped -testing earlier as we have a new ppc tester who wanted a bit of a tutorial, it went well. More information has been supplied :)
<skaet> phillw,  image references are on http://iso.qa.ubuntu.com/qatracker/milestones/219/builds now.
<skaet> phillw, unfortuneately I don't know the correct runes to copy the test results over, but if there are more results you can add them there now.
<skaet> until the next daily image is published.
<xnox> skaet: is the last respin of xubuntu 0905.1 the best image for me to use? (i'm working on unbreaking it, with a few fixes already in bzr)
<skaet> xnox,  yes.   the cron jobs are back on,  but if you want a respin off cycle,  just chime in.
 * xnox is worried that next daily images will be flaky due to flood gates.
<Laney> you'd hope not
<xnox> skaet: only if i push out ubiquity will all the fixes. I need two more.
<xnox> Laney: no, you'd hope not. I don't have that much hope =)
<xnox> skaet: thanks for the offer though =)
<skaet> xnox,  np.    Speak up in next hour or so,  or catch one of the other release team members to trigger it.   I'll be afk in a bit.
<Laney> he shouldn't be working this late :P
<xnox> Laney: well this early. 7th of September for the win
<xnox> skaet: ok. I am sure infinity will be up =)
<infinity> xnox: Up, yes, but I might not be around.
<infinity> If I can get my razor to stay charged long enough to trim the other half of my face...
<xnox> ok.
 * xnox can imagine......
<xnox> infinity: dressing up for the Global Jam? =)
<infinity> Sure, let's say it's that.
<infinity> Cause the other conversation could be awkward.
<infinity> "You see, young xnox, when mommies and daddies love each other very much (or are drunk)..."
<xnox> infinity: stop right there, thank you very much.
<Laney> spice girls lyrics?
 * xnox why do xubuntu daily isos have the same names as ubuntu daily isos!
<xnox> Laney: ;-)
<xnox> skaet: good that we didn't release xubuntu. I was horrified a few times already. Started the desktop now.
 * skaet nods
<knome> mm-hmm
<xnox> knome: i am taking notes. will talk about it later, after the first round of ubiquity fixes are uploaded.
<knome> yeah
<knome> xnox, do you think there is something we aren't able to fix or...? :)
<knome> xnox, just want to prepare on how bad the situation is... ;)
<xnox> let's just say that modern advances in xfce did not propagate back into ubiquity which tries hard at faking old xfce
<xnox> =)
<knome> humm..
<knome> aren't beta2 images first released on monday 17th?
<xnox> knome: i thought 24th?
<smartboyhw> FIRST released?!!?
<knome> ah, of course.
<knome> but monday, good...
<xnox> smartboyhw: candidates published.....
<smartboyhw> Oh you mean that.
<smartboyhw> I thought the official release
#ubuntu-release 2012-09-07
<bjf> how can i see where my jobs are in the build queue?
<Daviey> bjf: I don't think you can't see their ordering.. you can only see their score and estimated build time.
<bjf> that stinks :-)
<bjf> but thanks
<Daviey> estimated time to build, rather
<bjf> i'm waiting on ppc, it should just say "good luck with that"
<xnox> bjf: were in or after the beta1 freeze flood gate opening?
<bjf> xnox: yup, but my job was in the queue early today. i do SRU kernels
<micahg> bjf: https://launchpad.net/ubuntu/+builds?build_text=&build_state=pending
<bjf> micahg: thanks
<bjf> micahg: does that page cover non-virtualized ppas?
<micahg> bjf: probably not
<bjf> micahg: oh well, thanks for the link anyway
 * infinity blinks at the binaries for unity-lens-help ...
<infinity> Did I miss the memo about "raw-meta-data" upload types, or is that on crack?
 * micahg didn't know binary packages have Icon/Appname/Category fields...
<stgraber> fun :)
<stgraber> infinity: I'd suggest rejecting
 * infinity reje... Yeah.
<stgraber> they copied some package from extras.ubuntu.com
<infinity> extras does this craziness?
<micahg> phew, dpkg-deb also didn't know about those fields :)
<stgraber> that extra metadata (logos) and package fields are what we had for extras.ubuntu.com in the past until someone fixed MyApps/SoftwareCenter
<ajmitch> sorry, I missed those fields, too used to seeing them for ARB packages
<stgraber> infinity: we used to until the MyApps API took over the task of providing all that stuff to software-center
<infinity> I suspect if I hadn't rejected, it would have just OOPSed on accept anyway.
<infinity> I hope.
<infinity> ajmitch: I get to blame you for this?
<ajmitch> infinity: of course
<infinity> ajmitch: Does this mean you can communicate the issue and get it fixed? :P
<infinity> Cause I'm two beers deep and unhelpful right now.
<stgraber> infinity: not sure, works great in PPAs at least, so maybe something would blow up at publishing, but the rest should work
<ajmitch> infinity: it means I can fix & upload instead to make it faster
<infinity> ajmitch: Snazzy.
<infinity> stgraber: Kinda hope something would blow up, cause the only other conclusion would be that the publisher would actually do "something" with the custom files, and I'm not sure what that something would be.
<ajmitch> could be interesting to find out
<infinity> I disagree. ;)
<stgraber> infinity: for the extra PPA, it puts them in a separate folder of http://extras.ubuntu.com/ that's http://extras.ubuntu.com/meta/
<jbicha> hi, could we get glib-networking & glib2.0 moved from -proposed?
<phillw> stgraber: I know balloons has been too busy with the global bug-jam, but I did register my, and the testers, thanks to you for the work you did on iso tracker to carry bugs over.
<phillw> stgraber: do you have a couple of moments spare?
<phillw> https://wiki.ubuntu.com/QATeam/Meetings/QA/20120905 has not appeared on https://wiki.ubuntu.com/QATeam/Meetings Any ideas as to wht (I have) gone wrong?
<slangasek> did someone here move gobject-introspection from quantal-proposed to quantal?
<jbicha> slangasek: yes, that was my mistake
<slangasek> jbicha: ok; please don't copy packages from -proposed, this is meant to be done by the archive admins
<slangasek> (actually, it's supposed to all be automated with britney, but that's another story)
<fabo> skaet: could you approve linaro-image-tools FFE ? bug 1045188
<ubot2> Launchpad bug 1045188 in linaro-image-tools "[FFE] Sync linaro-image-tools 2012.08.1-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1045188
<mvo> hi, I looked at the current unattended-upgrades bzr branch and merged some debian fixes in that would be useful for us. now the ubuntu branch is converted to py3 but not uploaded yet, do I need a freeze exception for the py3 version if I want to upload that now?
<bencer> hi, someone from the -release team could have a look at this FFe, please? https://bugs.launchpad.net/ubuntu/+source/zentyal-samba/+bug/1043654
<ubot2> Launchpad bug 1043654 in zentyal-samba "[FFe] New version of zentyal-samba" [Undecided,New]
<Daviey> slangasek: wait, "please don't copy packages from -proposed, this is meant to be done by the archive admins" .. we discussed that a few weeks ago.. and the consensus aiui was that for the development series, a dev with the upload access should be able to do it.. Or did i miss-follow that
<Daviey> cjwatson: ^ was that your understanding ?
<Laney> well, I was told / allowed to copy LO earlier in the week
<jamespage> morning all
<jamespage> I'd like to sync the latest version of irqbalance from Debian testing to resolve bug 974450
<ubot2> Launchpad bug 974450 in irqbalance "irqbalance classifies network interfaces with custom/renamed interfaces as class other" [Medium,In progress] https://launchpad.net/bugs/974450
<Daviey> jamespage: and i'd like a sparkly pony.
<jamespage> not finished yet
<jamespage> its a new upstream release; its been in testing for some time so I'm comfortable that its not going to break
<jamespage> but upstream lack a changelog other than 'Look at the VCS commits'
<jamespage> a) I assume this will need a FFe and b) any guidance on what to provide for the changelog - is the VCS history sufficient?
 * jamespage gives Daviey and sparkly pony
<jamespage> Daviey: all yours - http://www.geekosystem.com/wp-content/uploads/2010/04/272e9652-550x548.jpg
<jamespage> sorry - I said 'sync' mean't 'merge'
<Daviey> jamespage: i was going to question that... but sid's changelog is based on Ubuntu packaging.. so what needs to be carried?
<jamespage> Daviey, just digging at that now - may be minimal based on comment on that bug report
<jamespage> Daviey, actually I think we can just sync it
<Daviey> debdiff ubuntu/*.dsc debian/*.ds == uhttp://pb.daviey.com/9oB8/
<jamespage> Daviey, just looking at the dropped patch - which is my one point of concern
<jamespage> but its so significantly difference in 1.0.3 I can't really tell TBH
<Daviey> jamespage: infinity's applied patch?
<jamespage> yeah
<jamespage> looking at changelog upstream now for something similar
<Daviey> jamespage: It has no bug number, no indication what it changed.. a really crappy upload.  Thanks infinity :)
<jamespage> Daviey, http://paste.ubuntu.com/1190390/
<Daviey> jamespage: I assume this version has been tested by people, including vanhoof?
<jamespage> Daviey, If you want to make that a condition of upload I'll get jmleddy to test it first in PPA
<jamespage> I personally think that would be a good idea
<Daviey> jamespage: So.. I'm happy to approve it, providing jm-leddy/vanhoof commit to testing it, and offer support to resolve any fallout.
<jamespage> Daviey, ack - great - I'll update the bug report and get things moving forwards again
<Daviey> i'll document that on the bug
<jamespage> ta
<cjwatson> Daviey: developers with upload access *can* do it, but generally shouldn't unless given guidance
<Daviey> cjwatson: Hmm, that wasn't my understanding from the output when we discussed it a few weeks ago.
<Daviey> but ok, i guess i missunderstood.
<Daviey> echo $BETTER_UNDERSTANDING >> ~/wishy-washy-policy.txt :)
<psivaa> mterry, I could not get the fixed package to a live session, this crash being occurring right after we go into live session installing the fixed package during the live session will not help. Further i noticed the bug is marked fix released, so waiting for an image with the fix to be published
<Laney> psivaa: I'm spinning some updated images now (the ones this morning failed)
<didrocks> warning: people having a i915 card, don't upgrade to latest mesa: it seems it's causing bug #1046933 and so no ui
<ubot2> Launchpad bug 1046933 in mesa "glsl/linker: array buffer overrun [CVE-2012-2864]" [Undecided,New] https://launchpad.net/bugs/1046933
<didrocks> oupss, bug #1047306 I meant
<ubot2> Launchpad bug 1047306 in mesa "[Quantal] [Intel Atom] Mesa 2012/09/07 updates broke it all" [Critical,Confirmed] https://launchpad.net/bugs/1047306
<didrocks> just reverting will reintroduce the CVE issue though
<psivaa> Laney, ok thanks, ill wait for them and try 971353
<didrocks> working with tjaalton to see if we can revert to the previous version + reintroducing the CVE patch
<tjaalton> it's not all i915, just some
<tjaalton> 965, snb working fine here
<tjaalton> so older than 965 then I guess
<didrocks> tjaalton: netbook ones typically?
<Laney> nah, still failing
<tjaalton> well, 915 is also a chip generation, like 945 so those that are using i915_dri are broken it seems
<tjaalton> like they were before the unity stack updates, just in some other way now
<didrocks> ok, got it
<tjaalton> I'll diff the changes there
<didrocks> thanks tjaalton :)
<tjaalton> I have 30min :)
<tjaalton> or maybe 45
<didrocks> heh
<Laney> psivaa: sorry, didn't work
<ogra_> The following packages have unmet dependencies:
<ogra_>  mcp-account-manager-uoa : Depends: signon-plugin-password but it is not installable
<ogra_> ...
<ogra_> (thats what arm shows for your last attempt)
<ogra_> ah, same on x86
<psivaa> there was a bug reported for this bug 1047247
<ubot2> Launchpad bug 1047247 in empathy "Failed to install Quantal alternate amd64 and i386 daily build(20120907) : mcp-account-manager-uoa : Depends: signon-plugin-password but it is not installable" [Undecided,New] https://launchpad.net/bugs/1047247
<ogra_> likely a missing MIR
<cjwatson> No, binary-only
<ogra_> hm
<psivaa> right, report.html lists this as one of the uninstallable packages, not sure it needs a bug for it
<cjwatson> I've moved it to main now
<cjwatson> psivaa: It doesn't
<Laney> missing move to main anyway
<Laney> explains why my test install didnt notice it
<Laney> so I assumed it was transient
<psivaa> cjwatson, so the report.html is a heads up for saying these packages wont get installed?
<cjwatson> Yes
<cjwatson> It's automatic dependency analysis
<psivaa> cjwatson, so the relevant packages take their own action to recover this based on this report?
<cjwatson> For images, if report.html is non-empty you generally might as well consider the image toast and not bother testing it
<cjwatson> No, it'll likely cause a hard failure
<cjwatson> Depending slightly on which packages are involved
<cjwatson> The package can't take any action, though, because the package manager will refuse to install it with unsatisfiable dependencies
<psivaa> just wondering how to trigger a solution without a bug against the package
<cjwatson> Asking here is fine.
<psivaa> ahh ok :)
<cjwatson> The package maintainer may well not be able to do anything about it; often requires an archive admin.
<cjwatson> Depending on whether it's a move-to-main kind of problem or something else.
<psivaa> understand, thanks for the clarification
<mterry> skaet, hello!  Might you be able to take another look at FFe bug 1040221 and bug 1044447?
<ubot2> Launchpad bug 1040221 in lightdm-remote-session-freerdp "FFe request: Provide remote login options" [Medium,In progress] https://launchpad.net/bugs/1040221
<ubot2> Launchpad bug 1044447 in unity-lens-photos "[FFe, MIR] unity-lens-photos in quantal" [Undecided,New] https://launchpad.net/bugs/1044447
<cjwatson> slangasek: Could you have a look at the efilinux-signed binary in NEW?
<xnox> mini.iso should get a refreshed look =) bug 1047376
<ubot2> Launchpad bug 1047376 in ubuntu-cdimage "mini.iso has old branding" [Undecided,New] https://launchpad.net/bugs/1047376
<didrocks> FYI, reverting mesa now
<tseliot> hi, can an archive admin remove nvidia-graphics-drivers-96 and nvidia-graphics-drivers-96-updates from quantal, please?
<skaet> mterry,  done.
<mterry> skaet, thanks!
<skaet> ogra_, didrocks, popey, Daviey, arosales, brendand, psivaa_afk, and others interested.... - am cancelling meeting today,  not enough of the reports landed in time, and I've not had time this morning to go through the rest.      Please ask questions in email on #ubuntu-release
<popey> skaet, ok
<ogra_> skaet, bah, so i'm missing the milestone to end my week !
<brendand> skaet, ok - thanks
<ogra_> :)
<skaet> ogra_,  sorry...  ;)
<psivaa> skaet, ok, thanks
<didrocks> skaet: ok
<arosales> skaet: ok, thanks for the ping
<mvo> hi, I looked at the current unattended-upgrades bzr branch and merged some debian fixes in that would be useful for us. now the ubuntu branch is converted to py3 but not uploaded yet, do I need a freeze exception for the py3 version if I want to upload that now?
<skaet> mvo,  is the only change the move to py3, or are there new features with it?
<mvo> skaet: its moving to py3 and some fixes from debian, let me double check that there is no new feature in there, I *think* its just fixes
<ScottK> tseliot: What do I give for the removal reason?
<tseliot> ScottK: the driver won't be updated to match the new X ABI
<ScottK> Thanks.
<skaet> mvo,  if its just fixes and py3 which is a stated target, we're good.  Otherwise, best a FFe, so we can make sure no other implications.
<mvo> skaet: great, thanks for this advice, I will check the bzr logs and either upload or do a FFe, but its good to know that py3 itself is ok (the testsuite is also pretty good so I don't expect any issues really)
<ScottK> tseliot: Done.
<tseliot> ScottK: thanks a lot!
<tumbleweed> a python3 port is a significant change to a package's build system, but not as risky as a dh_python2 port
<xnox> tumbleweed: nah
<tumbleweed> xnox: is that nah applied to before or after the comma?
<xnox> tumbleweed: port to python3 is insignificant change to a package's build system if it already has been using dh_python2
<tumbleweed> yeah, the most likely result of a screwup is a broken python3 package
<tumbleweed> which wouldn't be a regression
<xnox> unattended-upgrades is a leave package, even if it does depend on python-apt/debian, which (i) have been ported, (ii) are solid~ish, (iii) want more usage.
<cjwatson> It doesn't depend on python-debian as far as I can see.
<cjwatson> Unless that's a change in this version.
<ScottK> It may be a leaf package, but it provides important platform functionality.
<iulian> Yikes!
<tumbleweed> there doesn't seem to have been much SRU review recently, either
<ScottK> I'll review those, but I haven't done much with SRUs lately either.
<infinity> tumbleweed: It's been an off week or two for SRU reviewy types, the backlog should clear soon.
<slangasek> I'm on the hook for those today; won't get to them until later today though
<tumbleweed> it seemed that everyone took a bit of a holiday after the point release :)
<infinity> Some of my SRU stuff got pre-empted by "more important" SRU stuff, then Labor Day happened this week.
<infinity> Can't speak to others.
<infinity> But there was also just a backlog in general due to the .1 freeze.
<slangasek> tumbleweed: I'm quite certain this has not been a holiday for me ;)
<tumbleweed> :)
<cyphermox> hey, could someone please approve https://bugs.launchpad.net/ubuntu/+source/networkmanagement/+bug/1046918 ? :)
<ubot2> Launchpad bug 1046918 in wpa "[FFe] Enable RSN (WPA2) encryption support for IBSS (ad-hoc)" [Undecided,New]
<ScottK> cyphermox: Can you put the networkmanagement diff in the bug too?
<cyphermox> sure
<cyphermox> ScottK: https://launchpadlibrarian.net/115086274/nmgmt-diff.txt
<cyphermox> looks to me like there was no ~kubuntu-packagers branch for this one, so it's against the UDD branch
<ScottK> cyphermox: Go for it.
<cyphermox> ScottK: Thanks
<ScottK> You're welcome.  Thanks for making sure it works everywhere and not just on one flavor.
<cyphermox> after just enough reminding ;)
<ScottK> You know you're too far into queue processing mode when you do "./queue -Q done -s precise fetch postgresql-common".
<ScottK> lazr.restfulclient.errors.ServerError: HTTP Error 503: Service Unavailable
#ubuntu-release 2012-09-08
<micahg> if queuebot pops up a note about packagekit being removed from desktop-extra, I did that since it's in core
 * micahg is gone now until Sat night US time
<xnox> were cron jobs re-enabled? or is ubuntu daily-live simply failing to build?
<slangasek> it was failing to build
<xnox> slangasek: hmmm... And don't see the logs at http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/quantal/
<xnox> I guess I am not special enough to find out about it
<slangasek> xnox: my guess is the nature of the failure happened so early that it left no log
<xnox> =) and Laney had faith that CDs will build after the flood gates open =)
<infinity> xnox: If the livefs fails, there'll be no cd build log.
<infinity> xnox: You want livefs-build-logs
<infinity> Where you'll find failures such as:
<infinity>  mcp-account-manager-uoa : Depends: signon-plugin-password but it is not installable
<xnox> infinity: found it. Thanks.
<xnox> infinity: cd/livefs build logs are more friendly to navigate than iso tracker to find out what has / hasn't been build.
 * infinity thinks that it might be time to EOW after another batch of kernel SRUs have been dealt with.
<infinity> Or I could promote quantal's kernel and do a d-i tonight, I suppose.
<xnox> me and ubiquity are EOW, after the upload I just did.
<xnox> infinity: thanks for kernels
<slangasek> xnox: well, the CD failure was specifically because of packages being hit-and-miss copied from quantal-proposed into quantal; the floodgates themselves didn't seem to impact building
<slangasek> oh, there's the uoa thing too
<adam_g> are packages with new biniares currently being held in queue for approval?
<infinity> adam_g: They always are.
<adam_g> eek
<adam_g> shouldnt have stepped away. was going to see about NACK'ing that quantum
<infinity> adam_g: Oh?
<infinity> adam_g: Why for?
<adam_g> infinity: someone uploaded it prematurely. the new binaries in that upload are probably wrong and will be replaced with other, new binaries when its updated correctly. :|
<infinity> Ahh.  Was a bit difficult to divine that when reviewing it.
<infinity> Anyhow, no big deal, upload the new version with corrections, and the old binaries will go NBS and get removed.
<infinity> Not world-ending.
<adam_g> good to know. not world ending, but definitely week ending.  thanks, have a good one.
<infinity> Toodles.
<Laney> what is http://changelogs.ubuntu.com/bigfile ?
 * ScottK suspects it's an mvo test file.
<knome> huh? xubuntu alternate images seem to be around again.
<knome> ^ release team, what's up with that? i thought they were dropped, twice
<Laney> where?
<stgraber> knome: according to crontab, it's only building for precise
<stgraber> and the last published one for quantal was 4 days ago
<knome> stgraber, http://iso.qa.ubuntu.com/qatracker/milestones/219/builds (quantal daily) has testsuites for alternate, and the download links work
<knome> stgraber, actually, the image is from 0902, but those testsuites still shouldn't show up
<Laney> gone
<knome> Laney, ta
<Laney> wonder why the 04 one didn't get poster to the tracker though
<Laney> oh, would have gone to beta
<knome> mmh :)
<stgraber> Laney: probably because it was during beta1 so the milestone was disabled and nusakan was pointing to beta
<stgraber> right
#ubuntu-release 2012-09-09
<phillw> knome: ping
<knome> any release team member around?
<tumbleweed> !ask|knome
<ubot2> knome: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience
<knome> we need an FFe for bug #1048217
<ubot2> Launchpad bug 1048217 in ubuntu "Re-introduce indicator-sound-gtk2/ido-gtk2" [Undecided,New] https://launchpad.net/bugs/1048217
<micahg> can we get an out of band xubuntu desktop respin if it's not too much trouble?
<cjwatson> Sure, on its way
<micahg> thanks
<cjwatson> There's an Ubuntu Studio build occupying the x86 buildds at the moment, so I don't know how long it will take
<micahg> ok, was just hoping for some time today,
<knome> hey cjwatson
<cjwatson> hi
<knome> bug #1048217
<ubot2> Launchpad bug 1048217 in ubuntu "Re-introduce indicator-sound-gtk2/ido-gtk2" [Undecided,Triaged] https://launchpad.net/bugs/1048217
<knome> can we have a FFe for that please?
<cjwatson> uh, not really in an FFe frame of mind just now - been poking a transition for a while and need to go and do laundry
<cjwatson> oh, ScottK already approved it on condition that you find an AA
<cjwatson> sure, I can do the NEW review when you have it uploaded
<knome> cjwatson, so, should i just tell people to upload? and should i prefix the bug with [FFe]?
<cjwatson> (a) yes (b) I don't care
<knome> heh, ok :) thanks!
<micahg> cjwatson: would the release team want an FFe for packages adding a symbols file or removing a static library to insure that the rdeps are not affected?
<cjwatson> dunno
<cjwatson> I lose track of what different people want FFes for
<cjwatson> if it isn't documented on the wiki you'll have to ask the list
<Laney> if it's risky why bother at this point?
<Laney> the point of the FFe for me would be "have you made sure this isn't going to break anything?"
<Laney> but you can ask that just as well as I can
<micahg> ok
<cjwatson> right, I think I've DoSed the builders quite enough for today
<micahg> nonsense, the queue is almost empty :)
<cjwatson> but that should be the glew1.5 transition and the best part of the tiff transition done once everything finishes
<cjwatson> dozen or two more to do for tiff
<micahg> cjwatson: thanks for that BTW :)
<cjwatson> gotta get past fourth place on upload-activity somehow
 * micahg is down to 12 :(, will hope to fix that next month
<Laney> how is jbicha so high?!
<cjwatson> course I still have a +1 stint coming up
 * Laney resigns
<micahg> me too hopefully :)
<cjwatson> Laney: gnomebuntu I guess
<micahg> he's been syncing lots of stuff from Debian
<Laney> surprises me that requires so many uploads
<ajmitch> Laney: I'm sure you could do another few hundred uploads to catch up
<Laney> I don't have so much imagination
<cjwatson> wish the pie charts had raw numbers available somewhere as well
<Laney> http://www.haskell.org/ghc/download_ghc_7_6_1 ?
<Laney> somewhere> udd :-)
<ajmitch> yet another ghc transition?
<cjwatson> you could fix all our build failures
<cjwatson> Laney: yeah but I can't be bothered
<micahg> from my changes box I have jbicha at 684 and Laney at 508
<Laney> who doesn't love writing sql?
<micahg> it has cjwatson at 512 now :)
<cjwatson> not off the clock :P
<cjwatson> micahg: rah
<ajmitch> so Laney is falling behind
<micahg> I need at least 60 uploads to catch pitti
<Laney> bug closures is probably a more interesting measure
<cjwatson> micahg: mm, my numbers from quantal-changes are close to that but have Riddell at 364, so obviously don't quite match the SQL
 * ajmitch won't even try & catch up
<micahg> cjwatson: yeah, I saw that
<micahg> ajmitch: you can fix launchpad to allow backports for devel :)
<cjwatson> Laney: I'm sure Brian had a report along those lines somewhere
<Laney> yeah I remember one
<ajmitch> micahg: was doing that this weekend
<micahg> awesome
<ajmitch> I think cjwatson is probably the best person to ask about where to put tests about uploading to backports when the current series isn't frozen/supported
<ajmitch> micahg: had to do some yak shaving to get there, fixing up lpsetup, using lxc, etc :)
<cjwatson> eh, generally put LP tests in the test file named after the model code you're changing
<cjwatson> ah, here we go
<cjwatson> http://reports.qa.ubuntu.com/reports/bug-fixing/quantal-fixes-report.html
<cjwatson> I didn't think lpsetup was quite production yet
<cjwatson> I just use https://dev.launchpad.net/Running/Schroot since I already have a working schroot setup for other reasons (as I'd expect many Ubuntu developers do)
<jbicha> yeah I do much worse at actually fixing bugs ;)
<cjwatson> ajmitch: lib/lp/archiveuploader/tests/test_uploadpolicy.py is probably where tests should go - grep for PROPOSED there for examples
<ajmitch> cjwatson: thanks
<ajmitch> lpsetup was announced so I thought I'd try it out, it just didn't quite work on quantal due to a small bug
<cjwatson> I'm pretty conservative about these things when what I'm trying to do is fix a bug rather than experiment with infrastructure
<cjwatson> I think LP suffers from having slightly too many gadgets and different lines of development here
<ajmitch> I don't think you'd get any disagreement from LP developers on that one
<knome> cjwatson, indicators (bug #1048217) uploaded
<ubot2> Launchpad bug 1048217 in ubuntu "[FFe] Re-introduce indicator-sound-gtk2/ido-gtk2" [Undecided,Triaged] https://launchpad.net/bugs/1048217
#ubuntu-release 2013-09-02
<smartboyhw> Ubuntu Release Team: Please unblock ubuntustudio-meta (uploaded by micahg)
<smartboyhw> We need it in
<infinity> smartboyhw: Done.
<smartboyhw> infinity, \o/ thanks
<Laney> stgraber: hmm, not sure why the script picked that up
<Laney> let me debug
<Laney> hmm, not there now
<lool> Hi folks, would someone please hint libgpod 0.8.2-7ubuntu3?  I've tested an amd64 build locally, I don't get a segfault from iphone-set-info anymore with the new one; also grepped the log for "incompatible pointer type" warnings, and none remains; built on all arches
<lool> (saucy)
<Laney> sgtm, doing
<Laney> & done
<lool> thanks
<phillw> hi, in what direction should I point bug 1205643 ?
<ubot2`> Launchpad bug 1205643 in xorg (Ubuntu) "VIA P4M800 graphics broken in Lubuntu/Xubuntu Saucy" [Undecided,Confirmed] https://launchpad.net/bugs/1205643
<phillw> affect 23 machines....
<Laney> hmm
<Laney> ubuntu-system-settings turned up on edubuntu
<ogra_> edubuntu touch !
<ogra_> :)
<highvoltage> :)
<Laney> why isn't it in the germinate output?
<Laney> ah, that is newer than the images
<Laney> why is /that/?
<cjwatson> germinate output runs every six hours and isn't synchronised with images
<cjwatson> or some schedule like that
<Laney> Sure, I mean why haven't they had images
<Laney> oh, I do have failure mails
<Laney> blank ones - never learned how to debug those
<cjwatson> It shouldn't be happening any more
<highvoltage> yeah you have to get it by url
<cjwatson> But it is
<highvoltage> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/saucy/edubuntu-dvd/20130902/livecd-20130902-i386.out
<cjwatson> I think it may be trying to fetch the log from edubuntu rather than edubuntu-dvd, perhaps
<cjwatson> Haven't had a chance to debug
<cjwatson> It used to be because we couldn't predict the version number on the livefs builder side, but we now have http://people.canonical.com/~ubuntu-archive/livefs-build-logs/saucy/edubuntu-dvd/latest/livecd-i386.out
<highvoltage> Ah nice.
<cjwatson> xnox: ^- looks like that failure is yours
<cjwatson> Could you fix it?
<highvoltage> I don't think it's xnox's
<cjwatson> I do
<highvoltage> ok, I trust you then.
<cjwatson> ubiquity shouldn't be failing to configure when the U1 plugin is missing
<highvoltage> it started happening after I added a divert to move out that ubuntu one registration step based on stgraber's advise.
<cjwatson> Oh
<cjwatson> OK, in that case maybe it isn't xnox's fault :-)
<cjwatson> Maybe you need to put a blank no-op plugin in its place or something
<highvoltage> I thought that it might get fixed if I make edubuntu-live depend on ubiquity, did that yesterday and it didn't solve it.
<highvoltage> so not sure what's causing dpkg to behave like that.
<cjwatson> Not dpkg
<highvoltage> cjwatson: I thought so too but stgraber assured me that it's not necessary. maybe we'll end up doing that just to get round that error.
<xnox> highvoltage: maybe it's time to put the check in ubiquity it-self?
<cjwatson> Is ubi-ubuntuone.py by chance a dangling symlink?
<cjwatson> The error is from py3compile ...
<highvoltage> cjwatson: I can check, but I think it's highly unlikely. when I installed the newer edubuntu-live package on the last working livecd, it moved ubi-ubuntuone.py to ubi-ubuntuone.py.disabled successfully.
<highvoltage> (bbl)
<cjwatson> Should probably be possible to run a test build with livecd-rootfs and then chroot in to see what's wrong.
<cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel/2011-June/033458.html
<cjwatson> PROJECT=edubuntu SUITE=saucy in this case of course
<cjwatson> Sorry, PROJECT=edubuntu-dvd
<xnox> cjwatson: highvoltage: in ubiquity we already detect each flavour, and e.g. if get_release_name says it's edubuntu, I could just set UBIQUITY_NO_SSO environmental variable and disable the u1 plugin.
<cjwatson> Possible.  Judgement call on whether this belongs in Ubiquity or in an Edubuntu package.
<cjwatson> I suspect Edubuntu isn't the only flavour that might want to disable the U1 plugin so it seems that it should be possible for flavours to disable it neatly ...
<xnox> (well U1 is already disabled in a few cases, e.g. when u1 packages are not installed in the livefs)
 * smartboyhw has to run a Ubuntu Studio ISO to see if U1 is included
<xnox> cjwatson: right, the other way I was thinking that maybe ubiquity should source environment variables from somewhere in .disk/* ?
<cjwatson> Maybe something a bit less fragile like a configparser configuration file, but yes
<cjwatson> That would be one approach
 * xnox needs to check for kernel cmd environment variables are preserved across the pkexec, i suspect they are not....
<xnox> thus we should probably be re-reading the kernel arg line =/
<cjwatson> Although the practicalities of that aren't completely ideal; that means people have to ask for merges into bits of cdimage in order to change things, rather than uploading a package under their own authority
<cjwatson> Are u1 packages installed in the Edubuntu livefs then?
<xnox> cjwatson: yes.
<cjwatson> ok
<xnox> installed, but removed from the launcher. It's a pre-installed, optional, aftermarket feature which people can login into. But it's not actively promoted.
<xnox> (in edubuntu that is)
<xnox> other flavours are: Kylin, Gnome. So far there were bug reports / feature requests from jbicha. But only edubuntu at the moment express desire to disable u1 plugin by default.
<darkxst> xnox, we don't even ship u1 on ubuntu GNOME
<xnox> darkxst: http://cdimages.ubuntu.com/ubuntu-gnome/daily-live/current/saucy-desktop-amd64.manifest ubuntuone-client has 3 hits.
<xnox> darkxst: so, yes you do ship u1, in a sense that there is something that will be able to use the u1 token from gnome-keyring.
<xnox> my reasoning here is that if ubuntuone is shipped, it would also have some benefit to be able to sign in / up for u1 at installation time.
<highvoltage> xnox: I actually prefer your solution of setting UBITUIQY_NO_SSO automatically when it's on edubuntu
<xnox> highvoltage: let me try a patch here locally & i'll pastebinit to you.
 * xnox fetching edubuntu amd64 dvd takes some time =)
<xnox> highvoltage: http://paste.ubuntu.com/6054987/ this is the patch, in live system it's to be applied against /usr/lib/ubiquity/bin/ubiquity
<xnox> highvoltage: with this patch total number of steps is 9 (no dot for ubuntuone), with user login details as the last one before slideshow.
<xnox> highvoltage: commited in ubiquity and pushed to lp:ubiquity, let me know if you want this uploaded but it will need to be unblocked anyway. So maybe stgraber can upload & unblock.
<highvoltage> xnox: ok, sounds like you tested it fine already but will check it out too and ask stgraber to acknowledge the upload
<highvoltage> (well, approve it)
<xnox> and then other tweaks/hacks will need to be backed out from the other package this has been attempted to be tweaked.
<highvoltage> xnox: yep, I'll go ahead and do that
<xnox> highvoltage: shall i upload ubiquity now then as well?
<highvoltage> xnox: I think it will be fine, yes.
<highvoltage> xnox: I'll poke stgraber to let both packages through
<seb128> Laney, hey, why are ubuntu-system-settings and ubuntu-ui-toolkit are "block request by laney (contact #ubuntu-release if update is needed) "
<seb128> ?
<Laney> seb128: try "seeded-in-ubuntu $package"
<Laney> buggily included in edubuntu
<seb128> why is u-s-s seeded?!
<seb128> hum, k
<seb128> can we unblock it then? ;-)
<Laney> it'll fix when they get their respin built
<seb128> ok
<seb128> JackYu, did you want ubuntukylin-default-settings and ubuntukylin-theme updates in beta1?
<seb128> those are blocked as well it seems
<JackYu> seb128, yes, please:)
<seb128> Laney, ^
<Laney> yes
<stgraber> highvoltage, xnox: both packages look good, letting them through
<xnox> stgraber: thanks.
<Riddell> mlankhorst: you're into mesa right? this seems like a significant problem on arm bug 1219869
<ubot2`> Launchpad bug 1219869 in mesa (Ubuntu) "ld.so.conf incorrect on arm" [Undecided,New] https://launchpad.net/bugs/1219869
<mlankhorst> Riddell: no that might be correct
<mlankhorst> Riddell: update-alternatives --display armhf-linux-gnu_egl_conf ?
<Riddell> mlankhorst: hang on will need to boot it up again
<mlankhorst> Riddell: armhf is fun, the only officially supported platform is panda, which requires a weird reverted xserver :P
<highvoltage> thanks xnox and stgraber
<ogra_> Riddell, mlankhorst, the alternative points to the correct dir ... (it always should point to the device specific gles libs)
<ogra_> Riddell, mlankhorst if the PVR libs really end up in some mesa dir that would be horridly wrong
<mlankhorst> ogra_: the mentioned file is a symlink to /etc/alternatives
<ogra_> yeah
<mlankhorst> well there is no supported hw in mesa anyway
<mlankhorst> we *could* add freedreno probably
<ogra_>  /usr/lib/pvr-omap4-egl should be the right dir ... and that should be populated if DKMS did its duty properly
<mlankhorst> but kernel team wouldn't support it, so no point :P
<ogra_> it is definitely not an issue of the ld.so.conf link
<mlankhorst> yeah the bug's amrked invalid now
<ogra_> (i could imagine DKMS didnt run or the pvr driver isnt installed properly or some such)
<Riddell> kubuntu@kubuntu:~$ update-alternatives --display armhf-linux-gnu_egl_conf
<Riddell> update-alternatives: error: no alternatives for armhf-linux-gnu_egl_conf
<Riddell> mlankhorst: ^^
<ogra_> ouch
<ogra_> so it looks like pvr was installed during build at some point but then removed or some such
<Riddell> libwayland-egl.so.1 is in /usr/lib/arm-linux-gnueabihf/mesa-egl/
<ogra_> well, but the device specific libs wont
<mlankhorst> hm i doubt you'd have a system without egl :P
<ogra_> no, but since that setup is bound to the alternatives system you only have either/or
<ogra_> its either mesa or the vendor blob
<Riddell> it's just the daily build of kubuntu running on a pandaboard
<ogra_> if you want to mix and mash you will need to re-design that on top of something else than alternatives
<ogra_> i also belive you would want a libwayland thats actually built against the PVR driver for it to make any use of accelerated graphics (i might be wrong though)
<mlankhorst> Riddell: meh that would need some build logs, is pvr-omap4 installed in the image?
<ogra_> mlankhorst, well, if he wants to use libwayland it will break anyway
<Riddell> mlankhorst: yes it looks like it is
<ogra_> there should be a dkms log somewhere
 * ogra_ forgot where 
<ogra_> panda is sooo long ago
<ogra_> (and Mir makes arm graphics so lovely easy ... compared to that old cruft)
<Laney> Setting up pvr-omap4 (1.9.0.5.1.1-0ubuntu7) ... update-alternatives: using /usr/lib/pvr-omap4-egl/ld.so.conf to provide /etc/ld.so.conf.d/arm-linux-gnueabihf_EGL.conf (arm-linux-gnueabihf_egl_conf) in auto mode
<ogra_> looks fine
<Laney> it's not what you asked him to --display earlier
<ogra_> oh, indeed, it is the capitalized one that is used
<Riddell> ogra_: well it's not fine if it stops us finding libwayland surely?
<ogra_> Riddell, see above, someone would have to re-design the thing witout alternatives
<ogra_> in the armhf Xorg wold EGL is an either/or thing ... if you switch to mesa its all SW rendered ... if you switch to the binary blob, mesa cant be used ... thats why the alternative was initially used
<Riddell> wibble
<Riddell> so wayland on arm is just broken?
<ogra_> if libwayland from the mesa dir now works with the binary blob it should either be shipped in another dir or you need to re-work the setup to not use alrenatives
<ogra_> *alternatives
<ogra_> Riddell, for a test i would copy libwayland to /usr/lib, run ldconfig and see if it works then
<Riddell> ogra_: yep kwin starts if I do that
<ogra_> dunno, i never used it
<ogra_> Riddell, so i would ship it in its  own path as a quick fix
<ogra_> or alternatively find a solution for the alternatives :)
<Riddell> mlankhorst: does that sound like an acceptable change to the mesa package?
<ogra_> i mean, what would happen if you install MIr on a system that has wayland installed ... you probably  want something like a "compositor-lib" alternative
<ogra_> (or the other way around)
<ogra_> Riddell, wayland Mir coexistence should probably have been a vUDS topic ... to solve exactly such setup probs ...
<cjwatson> stgraber,Ursinha: I guess we're skipping the mumble call today due to the US holiday?
<stgraber> cjwatson: sounds good, not much to cover anyway (and I'm not supposed to be around since it's also an holiday in Canada)
<cjwatson> OK, I couldn't remember :)
<lool> Hi folks, would someone please check gvfs 1.17.90-0ubuntu1 and hint it if it seems ok?  it fixes the libimobiledevice issue I've described on the list; I did some testing with current gvfs binaries and could reproduce the bug with an ios device plugged, and browsing the device worked when updating the binaries; I've also checked the upstream git log between our saucy and and saucy-proposed upstream versions and it was fixes and cleanups
<lool> pitti and Laney weren't sure on the value vs. cost in lost testing, so feel free to push back if it seems too low priority to address for beta1
<pitti> hello
<pitti> lool pointed out that our current saucy gvfs doesn't work any more with the new libimobiledevice 1.1.5 that we got into saucy recently
<pitti> it's causing crashes now
<pitti> I uploaded a new gvfs upstream version to s-proposed which fixes that (lool confirmed with ipod); I tested locally with other hw (usb, mtp, etc.) and the autopkgtest (which cover gphoto, mounting, cd, archive, etc.) are also green
<pitti> so we might want to consider leaving that through unless it unduly sets back daily testing
<pitti> lool: ^ replied on u-release as well, FTR
<lool> thanks
<Laney> lool: pitti: I'll get that one in
<Laney> how do I edit the milestone manifest?
<stgraber> Laney: http://iso.qa.ubuntu.com/admin/config/services/qatracker/series/37/manifest
<Laney> stgraber: what's the UI path to that?
<Laney> (thanks!)
<stgraber> Laney: just enable/disable as appropriate, don't remove anything unless it's meant never to be released in the series
<stgraber> Laney: Admin => Series => Manifest
<Laney> ah under series
<Laney> I tried to find it from Products and Milestones
<stgraber> yeah, the manifest is per-series not per-milestone, we just enable/disable stuff in it to match what we want in the milestone
<Laney> got it
<Laney> B1 should be right now
<Laney> Don't think I'll be able to get on later to de-cron so I can either do it now, someone else can later or I can tomorrow morning
<Laney> OK, did it
<Laney> respin if you need to
<Laney> might want to wait for gvfs though
 * Laney waves
<phillw> Laney: are the partakers of beta 1 now frozen on cron job and is the last build the most up to date (considering FFes)
<Laney> Don't know what that means
<phillw> It's darn annoying when queuebot answers the question :D
<Laney> I'll do a respin of everything tomorrow though
<phillw> yikes? Why?
<phillw> Laney: ^^
<phillw> Laney: is it worth testers from all the community teams to go test the B 1 as you are going to do a global respin? This does shorten down the time for testing, but I'm sure the teams would much rather await you re-spin. Can you please ley us know what time (UTC) this will occur so we can let our testers know. Thanks, phillw
<phillw> gilir: hi boss, maybe stgraber or Laney will explain as to what the respin tomorrow is about, before I task the tsters.
<phillw> *testers*
<Laney> I did them just now
<Laney> assuming I drove the website correctly
<Laney> ttyl
<phillw> Laney: so no respin tomorrow?
<gilir> Laney, you blocked the migration of openbox ?
<phillw> gilir: as and when you get
<phillw> gilir: as and when you get a reply from Laney about respins, would you please let the lubuntu-qa team know (it may be a big help if you cc it to the ubuntu testing team). I'll not announce 13.10 beta 1 testing to lubuntu or any of the of the other teams until this re-spin has been finalised. Thanks, Phill.
<slangasek> Laney: fyi I'm unblocking rpcbind; I was not expecting a beta freeze to be in effect so soon before beta1, and did not see any announcements to this effect - I think if we're going to have freezes for base packages for opt-in milestones (which I don't think is a good idea anyway), they need to be announced rather than relying on people remembering that they're there
<slangasek> according to http://iso.qa.ubuntu.com/qatracker/milestones/302/builds, only Lubuntu has candidate images so far, with no testing - I don't think it's reasonable to have base packages frozen for 3 days before there are candidates
<phillw> slangasek: I was wondering why we were the only people there, hence my asking my head of dev.
<phillw> slangasek: I'm told that it is a public holiday over in the US of A
<slangasek> phillw: given the above, would you like a respin of lubuntu images for the updated rpcbind (when in publishes in a few minutes)?
<slangasek> phillw: it is a public holiday here, yes.
<pkern> slangasek working on holidays...
<cjwatson> So what's new?
<phillw> slangasek: if that brings in the latest, I'd really appreciate it, Can you do it easily, or should I request it via the system?
<slangasek> pkern: checking up on my package uploads on holidays to see why people are filing duplicate reports of bugs I fixed two days ago, not the same thing
<slangasek> phillw: if I push it from my side, I can trigger it immediately and make sure it picks up the right package version as soon as it's available
<phillw> slangasek: press the button Mr President!
<phillw> slangasek: with this build, do we have a Beta 1 that the guys and galls can test?
<slangasek> phillw: well, at least until the next issue pops up that warrants a respin ;)
<phillw> slangasek: WE KNOW THAT :p
<slangasek> phillw: well, it's always the case when we do a respin that we expect it to be worth testing
<phillw> I'll put the announcement out of that B-1 is building.
<phillw> as long as that is okay with you? slangasek
<slangasek> it appears that only lubuntu alternate is affected - live / preinstalled don't have rpcbind so I won't respin them
<slangasek> before I give you the green light, though, let me scan the proposed-migration list for other updates that ought to get in
<phillw> slangasek: are any other flavours going to join http://iso.qa.ubuntu.com/qatracker/milestones/302/builds ? IIRC, we flavours all wanted a B 1
<phillw> I'll await, some news sites are infamous for premature ejactulation
<slangasek> phillw: yes, Laney said on channel an hour and a half ago that he was starting the respin of all flavors (in lieu of his original plan of respinning everything tomorrow)
<slangasek> and Ubuntu-GNOME should also already be there now
<phillw> slangasek: yeah, it is... only ~4 more flavours to add:D
<slangasek> stgraber: it appears that packages that are part of the Ubuntu Desktop have a freeze block on account of edubuntu.  I don't think this makes sense given that these components are covered by our daily quality testing; blocking them holds up Ubuntu development and doesn't improve the quality of the Edubuntu milestone, and we know that archive inconsistency is no longer an issue for milestones due to -proposed.  Do you think it would be reasonable
<slangasek> ... drop the block for packages that are only used by Edubuntu+Ubuntu?  (At least in the future?)
<phillw> slangasek: is there still a need for for the Lubuntu Desktop Preinstalled armhf+ac100 ? I've not had any reports back from what used to be the arm team. Is it still of use or just using cpu for builds?
<slangasek> phillw: you're asking the wrong person.  The flavors decide for themselves which targets they want to support.
<stgraber> slangasek: yeah, I don't think highvoltage or I ever requested that big a block. Personally I'm happy to not have a block at all as I can always block specific packages if I feel it's too risky (I watch -changes pretty much in real time, so I have plenty of time to add a block rule before it gets migrated to the release pocket)
<slangasek> certainly if it's not getting tested and not getting released, we would like to drop it - but that's something Lubuntu needs to decide to do
<slangasek> stgraber: ok, thanks for confirming.  I'm not going to try to unwind the whole block right now, but I see bamf is currently blocked for this so I'll unblock it
<phillw> slangasek: lubuntu were asked by what was the arm team to allow Lubuntu Desktop Preinstalled armhf+ac100 We have no real interaction. Is there still any semblance of an arm-100 team or has everyone upgraded?
<slangasek> phillw: you probably want to talk to ogra
<jbicha> slangasek: aren't the Ubuntu desktop packages also blocked by Kylin?
<phillw> slangasek: I'll try to catch him/her to ask if they still want to have the low RAM version,
<slangasek> jbicha: mmm.  I suppose kylin would also be affected, yes (and doesn't show up because they aren't currently using seeds).  Of course, their testers also aren't going to be online at this hour, so I'll take care of a respin if necessary.
<slangasek> phillw: it's not about having a low RAM version, it's about having something that works on that hardware at all
<phillw> slangasek: I know, lubuntu is the only DE that will fit on there. My only question is does 13.10 still work? :)
<phillw> stgraber: slangasek who disabled the lubuntu alt images? or was it an incorrect "the rebuilds will not effect alternates"  :P
<phillw> Cut me some slack guys. I'm trying to write an email :)
<slangasek> phillw: I said *only* alternate images are affected.
<phillw> slangasek: are they expected to build?
<slangasek> yes
<phillw> slangasek: any time scale? I know time scale is a PITA for you guys, but I so have to 'rally the troops' to test the darn things :)
<phillw> Oy,, who said it all had to be done by Thursday :)
<phillw> slangasek: I do not see an alt for ppc in the list of alternate?
<slangasek> phillw: so the last britney run should have picked up my rpcbind unblock hint but did not; I'm looking to see why it didn't.
<slangasek> phillw: alt for ppc> I haven't done anything that would change this recently, whatever archs are currently listed for lubuntu in the stock config are what's getting built
<phillw> slangasek: alt for ppc was being built, it dropped out on the alpha cycle as the kernel team finally got some man hours to work on the kernel issue.
<phillw> slangasek: as the work they did was for ppc server, I'm puzzled as to it vanishing from the lubuntu suite? Can you look into why the build is not happening?
<phillw> slangasek: http://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/view/head:/etc/crontab
<slangasek> phillw: what about the crontab?
<phillw> slangasek: it shoud call the alt for PPC :)
<slangasek> no, it should not
<slangasek> we don't configure the architecture list in etc/crontab, we configure it in etc/default-arches
<slangasek> heh, looks like my hints file may have been ignored because my username is referenced in the Debian britney config. :-P
<phillw> slangasek: well, it was building, and we could not test it because the kernel team told us it was broken. So, if you can turn the little critter back on, we can then go back to "This ISO is ovdrsized
<phillw> *Oversized*
<slangasek> phillw: lubuntu powerpc images are being attempted, but the build is failing with an error:
<slangasek> Missing debootstrap-required iproute
<slangasek> CD1 missing some packages needed by debootstrap
<slangasek> make: *** [/srv/cdimage.ubuntu.com/scratch/lubuntu/saucy/daily/tmp/saucy-powerpc
<slangasek> /packages-stamp] Error 1
<slangasek> infinity: ^^ is that something you want to have a look at?
<phillw> cjwatson: also has a soft spot for PPC  ^^
<cjwatson> That's a priority-mismatches thing
<infinity> Indeed.
<cjwatson> I'll poke at it now
<infinity> Too late.
<slangasek> is it?  they seem to be 'required' already?
<slangasek> (what am I missing?)
<cjwatson> infinity: Oh dear, did we double-override?
<cjwatson> slangasek: required and shouldn't be.
<infinity> cjwatson: Should be alright.  Oh.  Wait.
<slangasek> cjwatson: oh.  then why was this only a problem on powerpc?
<infinity> slangasek: iproute2 is required now, iproute is transitional and needed dropping.
<cjwatson> slangasek: No idea; I'd have expected a problem on all alternatives.
<cjwatson> *alternates
<infinity> Why this only showed on powerpc, though, is a mystery.  Funsies with ordering in the packages file?
<infinity> debootstrap is a fragile beast.
<slangasek> ok
<cjwatson> Normally things in required/important that should be in lower priorities cause that (confusing) error.
<infinity> cjwatson: BTW, don't smack around the rest of priority-mismatches just yet, I'm leaving a few of those there as a reminder that I need to do a cyrus-sasl2 upload to Debian and sync it to tear some crap out of my buildd chroots. :P
<cjwatson> Yeah, I'll leave it now
<cjwatson> Will you check that iproute doesn't vanish after the next publisher run? :)
<infinity> cjwatson: Oh balls, iproute is arch:all.  We probably just disappeared it.
<infinity> Go us.
<infinity> HATE THAT BUG SO MUCH.
<infinity> If it's gone, I'll copy it back in.
<infinity> S'what I get for working on a day off. :P
<phillw> infinity: it's actually worse thab
 * slangasek mildly observes that a workaround for this bug is to actually take the advisory lock on IRC when someone asks you if you're going to look at it. :)
<infinity> Yeah, had I typed "fixing" instead of "Indeed", maybe we could have avoided it. :P
<infinity> Or maybe we both would have typed something and alt-tabbed without reading.
<phillw> infinity:  than that,,, you get people to test stuff :D
<infinity> cjwatson: Oh, wait.  We may be saved.  I think I hit "yes" after you did.  And the publisher ran right in between us.
<infinity> cjwatson: Looking back, mine was a no-op.
<infinity> 4 publications remained the same.
<infinity> Yay for publisher frequency increases papering over races.
<cjwatson> Neat.
<phillw> so, is http://iso.qa.ubuntu.com/qatracker/milestones/302/builds getting rebuilt with the alt versions and the ppc alt version?
<phillw> colin? ^^6
<cjwatson> I have no idea; I'm not getting involved in b1
<cjwatson> (Other than occasionally sticking my oar in regarding archive issues that people have historically got confused about if I don't speak up ...)
<phillw> infinity: are you a a
<phillw> b1 person?
<infinity> phillw: Looks like B1 is Laney's baby.
<phillw> cjwatson: the critters are not building, so how the heck they can go to beta is not really a beta issue?..... <begs>
<cjwatson> Sorry, can't help
<cjwatson> Need to do childcare if nothing else
<cjwatson> Bug somebody else please :)
<phillw> infinity: I do not think myself and Laney will exchanging Christmas Cards after the 'fun' on release email channel got a person who insists on dotting the 'i"s etc.
<phillw> cjwatson: it will be my utmost delight to bug Laney :D You possibly realise how much of a delight it will be :D
<slangasek> cjwatson: so even after cowboy patching britney on lillypilly, it's refusing to read my hints file; any idea what's going on there?
<slangasek> (in the meantime I will just shove my hint into someone else's hint file :P)
<cjwatson> slangasek: you don't appear to be in lp:~ubuntu-release/britney/britney2-ubuntu britney.conf, nor the corresponding checkout on lillypilly
<cjwatson> you want HINTS_VORLON = ALL there
<cjwatson> and now I really must go
<phillw> oops, there goes another Christmas
<phillw> Crs
<phillw> card >)
<infinity> phillw: Dude, it's 11pm for Laney right now.  Just how much of his day do you expect him to dedicate to you?  (Not everyone is as crazy as cjwatson and I)
 * micahg was about to respond to the ML with similar notes (and thinks he will anyways)
<phillw> m
<phillw> micahg: infinity do please reply, after you have done so, read the logs of this channel :)
<phillw> then you will see the guidance he offered :D
<phillw> Do I now tell all the teams who opted in for Beta 1 on the ML that the person charged with that task has failed?  Heck, I don't even know what to tell the lubuntu people.
<skat> phillw,  looking into it now.
<phillw> hi skat this is an un holly mess. the release team have, as ever been stars. Thats's
<phillw> what they do
<skaet> phillw,  I've been having IRC issues with my main system, and have switched to another for now.
<skaet> can you bring me up to speed on a PM?
<phillw> sure... never ask to pm me, just do it.
<micahg> phillw: please read my mail on the ML
<jbicha> I think the problem is that Laney had things he wanted to do today after 6 pm
<micahg> I don't think that's a problem, he's entitled to have a personal life
<jbicha> right
<phillw> cjwatson: / stgraber have all the ISO's now built (i.e,. can I make an announcement for them to be tested a.s.a.p.)
<skaet> phillw,  please make the announcement for them to start being tested, and if an expected image is missing,  please ask them to post in this channel.
<phillw> skaet: will do.
<phillw> Hi,
<phillw> the Beta 1's are now available for testing. They are the pretty much the finished article (art work follows a bit later). If you want to see how 13.10 behaves on your system and ensure it behaves, now is a really good time to grab it!!
<phillw> http://iso.qa.ubuntu.com/qatracker/milestones/302/builds
<phillw> Regards,
<phillw> Phill.
<phillw> --Â 
<phillw> https://wiki.ubuntu.com/phillw
<phillw> it's been posted to failbook and G+
<skaet> slangasek or stgraber -   can you double kubuntu is in the builder?   It is the only one of the set I've not seen post yet.
<stgraber> not sure, they were scheduled, started building but never published to the tracker so my best guess is that they failed to build. I'll retry them now.
<skaet> Thanks stgraber
#ubuntu-release 2013-09-03
<slangasek> cjwatson: aha, thanks
<darkxst> Hi, can we get gdm, gnome-session and gnome-shell-extensions unblocked for ubuntu GNOME bug 1212408
<slangasek> darkxst: done
<darkxst> slangasek, thanks!
<Laney> Not sure I want to read up. :P
<mlankhorst> don't do it!
<Laney> slangasek: I just applied the same algorithm we've done before, and followed the release schedule. Sure, we can discuss adjusting it in future.
<mlankhorst> Riddell: if it works probably
<Laney> slangasek: (I agree that it's probably overly conservative but we didn't work out anything more limited up to now)
<Laney> Furthermore there was a bug where a load of Touch and Ubuntu-only patches showed up in Edubuntu images which bloated the hint a lot
<smartboyhw> Laney, phillw is a bit tempermental some times, so don't put the "insult" in your mind too much:(
<Laney> I didn't get to update it as the Edubuntu respin hadn't popped out before I had to leave yesterday
<Laney> The script works off tumbleweed's parsed image manifest data
<xnox> smartboyhw: i'd rather see phillw stop insulting, rather than other people "dealing to ignore those".
<smartboyhw> xnox, I do too
<Laney> Never mind, I'm not bothered.
<highvoltage> +1
<highvoltage> also, happy birthday xnox!
<Laney> Thanks to everyone for replying though.
<Laney> All the expected images there now?
<smartboyhw> xnox, happy birthday:)
 * Laney gives xnox the birthday bumps
<Laney> 18 today!
<infinity> Laney: Oh please, I doubt he's a day over 15.
 * infinity tickles xnox.
<xnox> :-P
 * xnox *giggle*
<smartboyhw> How old IS xnox BTW:P
<Laney> Nobody knows. He has fake ID.
<xnox> smartboyhw: 78
<Laney> See!
<smartboyhw> -.-
<xnox> Laney: s/ID/IDs/
<infinity> He *claims* to be 25, but that's clearly a lie.
<czajkowski> aloha
<infinity> Everyone always overshoots their first fake ID to try to be "realistic".
<infinity> "Oh, I can't claim to be 18, that's too obvious, I'll go for 35."
<czajkowski> I'm pretty sure xnox and Laney need to still carry their ID around today :)
<Laney> Mine's embarrassing because I haven't learned to drive so I just have the learners license with a big red "L" on it
<infinity> Laney: Is the big red L on your forehead?  That would be really embarrassing.
<Laney> They told me I was too drunk when I tried to get that tattoo
<iulian> Heh.
<xnox> Laney: i used to walk around with citizen card as proof of age.
<smartboyhw> skaet, thank you for the link
<smartboyhw> Laney, speaking of which: Should upgrade testcases be enabled for flavours?
<Laney> shadeslayer: Can be. You want?
<Laney> shadeslayer: sorry
<Laney> smartboyhw: ^
 * smartboyhw thinks Laney pinged the wrong person:P
<smartboyhw> Laney, well, I'm still asking the Ubuntu Studio people, since we disabled it for 13.04
<smartboyhw> But, other flavours would want it I think
<mlankhorst> infinity: oh I'm still curious about saucy->precise xserver backport.. there is going to be nastiness with pointer barriers one way or another. :P I was thinking of copying libxi/x11 unrenamed from saucy, and give unity an internal copy of the old function calls, deciding at runtime which pointer barrier api to use..
<Laney> Didn't have it for A2
<Laney> I checked raring beta 1 and it didn't get great coverage then
<Laney> but I'm happy to copy them if (a) I find out how and (b) people ask for it
<Laney> assuming they can't do it themselves that is
<Laney> Looks like you can ;-)
<smartboyhw> Laney, yes
<smartboyhw> But, I think the flavour leads will forget that:P
<smartboyhw> I mean, adding the upgrades
<Laney> smartboyhw: If you like, you can mail the list to remind.
<smartboyhw> Laney, syre
<Laney> "Ubuntu Studio decided to enable upgrade test cases because of blah blah blah. You might want to do the same, but you don't have to."
<darkxst> Laney, smartboyhw, we added uprade test cases for Ubuntu GNOME
<Laney> okey pokes
<smartboyhw> darkxst, no need to tell me, it's your team's own decision and discretions:P
<darkxst> just saying its not like it need release team intervention!
 * Laney nods
<mlankhorst> infinity: want to know what's even more fun? backporting llvm-3.3 to precise :P
<mlankhorst> it seems to want a newer binutils..
<Riddell> mlankhorst: I think putting in symlinks from the pvr directory to the mesa libwayland would solve it, how does that sound?
<Riddell> stgraber: I'm getting lost in iso tracker again, how do I enable upgrade for kubuntu?
<ogra_> Riddell, is that libwayland in all mesa installs ?
<ogra_> i.e from which package does it come ?
<Riddell> ogra_: yeah it's part of libegl1-mesa-drivers
<ogra_> if its the generic mesa package such a symlink will likely breal Mir
<ogra_> *break
<ogra_> as i said yesterday, we might need a new alternative for something like "system-compositor-lib" or some such to solve that cleanly
<smartboyhw> Riddell, in "Builds" of the adminstration tab just check the "Upgrade" products, type in the version no. and choose the correct milestone
<mlankhorst> Riddell: I think you need to move wayland-egl out from mesa-egl dir
<mlankhorst> if it's a generic support library that works regardless of egl implementation
<Riddell> smartboyhw: ^^ got it, after some trips :)
<smartboyhw> Riddell, um, I think you better alter Lubuntu's upgrade build
<smartboyhw> Since I saw an Lubuntu message in there
<Riddell> smartboyhw: yeah I removed it again
<smartboyhw> Riddell, good:)
<mlankhorst> oh right I don't need newer binutils, it was just used for -fuse-ld=gold in link flags
<ogra_> hmm, i merged initramfs-tools-ubuntu-touch  and ubuntu-touch-generic-initrd ... which results in initramfs-tools-ubuntu-touch producing a new binary, shouldnt it get stuck in NEW due to that ?
<ogra_> (i dont see it in the NEW queue)
<cjwatson> Not if the same binary was already in the archive from another source package.
<ogra_> ok
<ogra_> great !
 * ogra_ files a removal bug for the ubuntu-touch-generic-initrd source then
<ogra_> bug 1220218 for any archive admin around
<ubot2`> Launchpad bug 1220218 in ubuntu-touch-generic-initrd (Ubuntu) "please remove the ubuntu-touch-generic-initrd source package from the archive" [Undecided,New] https://launchpad.net/bugs/1220218
<ogra_> stgraber, ^^^ since it makes your life easier :)
<cyphermox> Laney: hey :)
<Laney> cyphermox: hi, was at lunch
<Laney> If it's about NM it is due to the beta freeze
<cyphermox> Laney: hey ;)
<cyphermox> yeah, just making sure
<Laney> well, that and the fact that adt-britney is incorrectly saying that the test fails
<cyphermox> well, it used to fail
<Laney> sure but the latest one is ok
<Laney> cyphermox: anyway, do you need it now or is tomorrow OK?
<cyphermox> asap would be better, this is stuff for the phone, but I wouldn't feel OK telling you to override things like this, let me check with others
<tumbleweed> is something broken with Debian imports atm?
<seb128> tumbleweed, what debian imports?
<tumbleweed> the debian archive gets imported into LP
<cjwatson> tumbleweed: The relevant machine was only just recovered after a failure that required physical intervention
<tumbleweed> aah, thanks
<cjwatson> tumbleweed: And I don't think the cron job has run yet
<cjwatson> But it's up
<cjwatson> (i.e. I can rsync logs off it)
<smartboyhw> ^ It's me, all the testcases passed, so don't be surprised that I marked it so early
<zul> ^^^ Can I get an archive admin to review python-dogpile.cache and python-dogpile.core please they are new build deps for keystone
<ogra_> xnox, why would removing the old source pakcage require any changes in phablet.u.c ? i hope you only use the binary
<xnox> ogra_: if binary simply moved to a different source package, it should be fine. I didn't realise that.
<infinity> mlankhorst: That binutils versioned build-dep is probably bogus, but the -fuse-ld=gold will need to be backed out.  I might just do that in saucy too, so you can backport unmangled.
<ogra_> xnox, right, else i would have not filed the removal bug yet :)
<ogra_> and committed goit changes first
<ogra_> *git
<xnox> ogra_: ok, cool =)
<infinity>  * only build android-tools-adbd on armhf, i386 and amd64 until powerpc
<infinity>     tablets and phones show up on teh market.
<infinity> ogra_: ^-- Why that abritrary restriction?
<ogra_> infinity, because itr FTBFS ... there was a fix from lool later that makes it build
<ogra_> probably the Architecture field wasnt updated along ?
<infinity> ogra_: The changelog might have wanted to say that, then, not the other. :P
<ogra_> it saidf exacvtly what i uploaded at that point
<ogra_> well, modulo mentioning FTBFS
<lool> infinity: BTW it should be almost syncable
<infinity> No, I mean, it should say "disable because it's broken" not some nonsensical "disable because devices don't exist".
<ogra_> lool, ?
<lool> infinity: haven't rechecked in the last month or so
<ogra_> i thought it was synced ages ago
<lool> infinity: at some point, Debian version was just missing testing from either ogra or rsalveti
<lool> ogra_: was it?
<ogra_> lool, i thought so, but i might be wrong
<ogra_> (i dont think i have looked at that package since this upload above)
<infinity> Of course, that FTBFS being fixed wouldn't help now, since it now depends on libhybris-utils, which is only on 3 arches.
<infinity> For similar odd reasons, I'm guessing?
<ogra_> likely
<ogra_> libhybris needs android headers i think
<ogra_> well, thought utils probably doesnt
<infinity> Meh.  Too much to unwind right now.
<infinity> ogra_: All this boils down to "initramfs-tools-ubuntu-touch should be arch-restricted".
<infinity> (Or the whole stack it depends on shouldn't be)
<ogra_> infinity, the binary it produces is armhf
<ogra_> the script package it produces was supposed to be arch all but that didnt work out thanks to launchpad
<ogra_> bug 1063188
<ubot2`> Launchpad bug 1063188 in Launchpad itself "Launchpad doesn't try to build the "all" packages if i386 isn't in the Architecture field" [Low,Triaged] https://launchpad.net/bugs/1063188
<infinity> ogra_: Okay, but it produces a powerpc.deb that depends on something that can't be installed.  I'm not sure I need the history why. :P
 * infinity just fixes.
<ogra_> oh
<ogra_> heh, i totally didnt get your point
<ogra_> yeah fix away+
<lool> infinity: I just did a quick grep in hybris to see how arch specific it was, and it does indeed seem to have specific linker code for ARM, x86 and some SH code; like ELF fields and types; I'm not sure whether we want to invest in porting to powerpc
<infinity> lool: Yeah, not deeply concerned.  It's something I could poke at when I'm bored some day.  For now, I just arch-restricted the thing that was depending on it.
<mdeslaur> Laney: nas is stuck in -proposed, reason says "Not touching package due to block request by laney (contact #ubuntu-release if update is needed) "
<mdeslaur> Laney: could you push it?
<Laney> mdeslaur: yep
<mdeslaur> Laney: thanks
<mlankhorst> infinity: heh.. https://launchpadlibrarian.net/149247846/buildlog_ubuntu-precise-amd64.mesa-lts-saucy_9.2-1ubuntu1~~2ppa1_FAILEDTOBUILD.txt.gz llvm-3.3 has a dependency on zlib1g-dev? :P
<infinity> mlankhorst: That -lz is coming from llvm, not mesa?
<mlankhorst> infinity: hm good question, more digging is needed
<mlankhorst> infinity: positive :p
<mlankhorst> ~$ llvm-config-3.3 --ldflags
<mlankhorst> -L/usr/lib/llvm-3.3/lib  -lz -lpthread -lffi -lrt -ldl -lm
<mlankhorst> hm weird
<mlankhorst> it doesn't link it on saucy
<mlankhorst> meh nm then, I'll just add zlib1g-dev to the backported llvm-toolchain
<mlankhorst> sorry for the noise :)
<mlankhorst> *gone*
<slangasek> Laney: for my edification, what/where's the script that's used for assembling the freeze block list?  Does it look at ubuntukylin at all currently?
<Laney> slangasek: It's just something I threw together, and it's supposed to
<Laney> I can pastebin it if you'll be nice. :-)
<Laney> There are some kylin things in the block so I believe it is at least partially working for that purpose
<Laney> http://paste.ubuntu.com/6059440/
<Laney> Seems Edubuntu and Lubuntu alternates are missing test results
<Laney> If we can get those and the other remaining in over the UK night then we should be able to do B1 quite early tomorrow, all being well
 * Laney goes away for a bit, SMS me if the world ends or anything
<jbicha> Laney: but tomorrow's Wednesday?
<infinity> Days of the week are confusing.
<skaet> jbicha,  release is scheduled for Thursday
<adam_g> can someone please nack that misdirected dput ^
<slangasek> adam_g: looking
<slangasek> adam_g: done
<adam_g> slangasek, thanks
<xnox> Laney: highvoltage: cjwatson: jbicha: For the bug 1218175 I have now implemented package split: ubuntuone plugin is in a separate package, which can be seeded / unseeded as needed.
<ubot2`> Launchpad bug 1218175 in ubiquity (Ubuntu) "u1: Allow Ubuntu flavors to opt out of U1 feature" [Medium,Confirmed] https://launchpad.net/bugs/1218175
<xnox> not sure if you want this uploading, as the plugin will need to go through new and seeds will need to be adjusted.
<jbicha> xnox: a separate package won't work for Edubuntu
<xnox> jbicha: yes it will. ubiquity-frontend-gtk does not depend on it. it needs explicit seed, and i believe you can blacklist / negate install in the seed.
<xnox> jbicha: ubuntu-desktop will not depend on that plugin.
<jbicha> ok
<slangasek> that aside, I would be surprised if the edubuntu folks would actually want to maintain a delta with the Ubuntu Desktop wrt such features of the installer (regardless of whether they're personally happy with those features)
<xnox> slangasek: well edubuntu did request to remove that plugin, and they have their own custom plugins in ubiquity already (for task selection, server install & config, etc.)
<slangasek> xnox: ok.  Hadn't seen that request from edubuntu, and only the G+ post was referenced above
<stgraber> slangasek: we already maintain a delta to drop the shopping lens and drop the amazon and ubuntuone launcher entries by default as we don't think any of those are suitable for our target audience.
<slangasek> alright
<slangasek> (pff, what's wrong with having the kids shopping while at school ;)
<stgraber> :)
<xnox> stgraber: separate package would work, for edubuntu seeds right? (negating / blacklisting from the cd?!)
<stgraber> xnox: sure, we could just have edubuntu-live conflict with it then
<stgraber> xnox: so ubiquity could recommend that package (but not depends or the conflict would make ubiquity go away)
<xnox> stgraber: no, ubiquity will not recommend it.
<slangasek> you aren't really meant to use conflicts in seeds, though, and blacklists in seeds only result in failures when those packages show up - they don't work for the actual exclusion
<xnox> stgraber: it should be explicitly seeded, which will happen for ubuntu-live / kylin for example
<slangasek> just not depending on it is better, which seems to be the plan
<slangasek> cjwatson: so bug #1219589 is getting some static regarding getting the UbuntuHashes page updated.  The ubuntu-docs team doesn't seem to actually have access to update the darn thing.  Who does / how should we know who does? (checklist page points the finger at ubuntu-docs currently)
<ubot2`> Launchpad bug 1219589 in ubuntu-docs (Ubuntu) "ubuntu-12.04.3-desktop-amd64.iso md5sum missing from https://help.ubuntu.com/community/UbuntuHashes" [Undecided,Confirmed] https://launchpad.net/bugs/1219589
<slangasek> sarnold: ^^ ;)
<sarnold> slangasek: ah! :) thanks :)
<czajkowski> infinity: ping a ling
<czajkowski> infinity: I swear if I broke LP and builds you'd appear :)
<bdmurray> slangasek: could you have a look at update-manager in the raring proposed queue?
<jbicha_> phillw: I think your release announcement yesterday is easy to misinterpret, see http://lubuntublog.blogspot.com/2013/09/beta-1-is-out.html
<slangasek> bdmurray: update-manager-0.186.2/tags seems to be some added cruft in the upload?
<slangasek> bdmurray: not sure if you want to reupload to fix
<bdmurray> slangasek: yeah, I'll reupload
#ubuntu-release 2013-09-04
<bdmurray> slangasek: reuploaded
<micahg> ScottK: any chance I could get a quick approval on Bug #1219613 ?
<ubot2`> Launchpad bug 1219613 in libsigrok (Ubuntu) "FFe: Sync libsigrok 0.2.0-2 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1219613
<ScottK> micahg: It's already in New.
<ScottK> Oh, wait
<ScottK> It's not.
<micahg> that was libsigrokdecode
<micahg> unless it was rejected
<ScottK> Done
<micahg> thanks
<ScottK> Actually I was thinking of libgingotts, which is in New and I got an FFe for earlier today that I marked invalid.
<ScottK> ging/gring
<micahg> and Uwe uploaded the fix for sigrok-cli, so once this is published, I'll look at getting that over as well (which should then clear at least 3 packages out of proposed)
<ScottK> Great.
<cjwatson> slangasek: I have edit access - I've updated it for 12.04.3 now
<cjwatson> I've noted that I can do it on PointReleaseProcess
<sarnold> cjwatson: thanks! :)
<slangasek> bdmurray: and accepted
<slangasek> cjwatson: ok
<Laney> Yesterday I was under the impression that it was Wednesday, if you didn't guess from what I said before I left. :P
<Laney> I was talking to my girlfriend and managed to utterly confuse her before we figured out that misunderstanding.
<Laney> So ignore things I said that were coloured by this, and imagine that I said them at the same time today instead. ;-)
<mlankhorst> morning
<mlankhorst> Laney: your mind makes it real :-o
<Laney> Can someone remove gst-libav1.0 from proposed please?
<Laney> libav 9 looks less likely and so we'll carry on with the stable series of that one
 * sil2100 looks at infinity with small 'XIM' labels in his eyes
<mlankhorst> ogasawara: bah, you've beat me with the s-lts-backports :P I'm preparing the xserver, but it will take a bit longer due to pointer barrier abi breakage..
<xnox> ocaml-estring library used to be part of ocaml-batteries, but isn't anymore, thus to unbreak e.g. ocaml-sqlexpr, ocaml-estring is now a separate source package.
<xnox> synced from Debian.
<cyphermox> Laney: can we unblock NM ?
<xnox> it only has changes for ubuntu-touch right?
<Laney> cyphermox: Should be able to
<Laney> cyphermox: there you go
<cyphermox> Laney: thanks
<Laney> yw
<cyphermox> Laney: do you know how to convince it to recheck the test status?
<Laney> cyphermox: you say "Oh jibel, why oh why isn't network-manager at PASSED?" and then magically it gets fixed
<cyphermox> awesome :)
 * Laney runs
<cyphermox> Oh jibel, why oh why isn't network-manager at PASSED?
<cyphermox> ;D
<Laney> I think there's a problem where it doesn't notice tests it didn't request
<Laney> i.e. pitti started this one manually
<cyphermox> aye
<rsalveti> can someone unblock pulseaudio? latest upload was just a simple rebuild, to get the right headers when building for armhf
<Laney> sure
<Laney> done
<rsalveti> awesome, thanks
<Riddell> kubuntu good to go, although notable bug in installer and oem-config bug 1220193
<ubot2`> Launchpad bug 1220193 in ubiquity (Ubuntu) "ubiquity kde frontend crash setting up wireless when ubiquity only or oem-config" [Undecided,New] https://launchpad.net/bugs/1220193
<ogra_> cjwatson, ugh ... could you take a look at the last ubuntu-touch failure mail ?
<ogra_> looks like something is wrong with /etc/default-arches or some such
 * ogra_ ran "for-project ubuntu-touch cron.daily-live --live" so nothing special
<cjwatson> ogra_: You sure you don't have ARCHES set in your environment?
<ogra_> i freshly logged in to nusakan
<ogra_> i can try again, but there shouldnt be any ARCHES
<cjwatson> default-arches is fine
<ogra_> cdimage@nusakan:~$ echo $ARCHES
<ogra_> cdimage@nusakan:~$
<cjwatson> Leave it for now please
<ogra_> k
<cjwatson> I'll look after this meeting
<ogra_> thanks
<cjwatson> oh, which has just ended
<ogra_> heh
<cjwatson> Oh
<cjwatson> You ran the wrong thing
<cjwatson> 02 8,20 * * *   for-project ubuntu-touch cron.daily-preinstalled --live
<ogra_> oh, sigh
<ogra_> grepping ~/bash_history for teh command wasnt so clever then :P
<ogra_> no idea why i didnt use crontab as i usually do
<cjwatson> crontab is usually a safer thing to grep
<cjwatson> yeah
<ogra_> sorry for the nise
<cjwatson> np
<ogra_> *noise too
<slangasek> blink, who tried to build ubuntu-touch/powerpc?
<slangasek> ah, scrollback read ;)
<Laney> ogra leaks existence of secret new device
<xnox> it's like android publishing atari II devices trees for android =)
<ogra_> slangasek, well, infinity fixed installability of initramfs-tools-ubuntu-touch on powerpc yesterday, so i thought i should try :P
<slangasek> :P
<xnox> =)
 * ogra_ wont tell anyone about the new oracle winterphone that warms your pocket with a sparc :)
 * xnox ponders why lubuntu testers always mark "release notes link doesn't open release notes" as affecting their test images..... 13.10 is not released yet, hence the links are not active =)
<slangasek> xnox: historically the release notes links would load beta release notes
<slangasek> is this not being done now?
<JackYu> cjwatson, hi, may I know the deadline of beta1 QA?
<xnox> slangasek: well ubuntu & core/foundations bits are certainly not up, since well ubuntu is not participating.
<slangasek> xnox: right; I think it's a valid request regardless, even if it's not currently a priority for the web team to address this
<xnox> slangasek: I did request for draft release notes to be started via email to you & infinity =) for core stuff. Not sure when it has usually been typically done.
<xnox> slangasek: sure, but e.g. under https://wiki.ubuntu.com/SaucySalamander there are no releasenotes pages, I'll go and look if/where flavours typically have them.
<slangasek> JackYu: I believe skaet is running the milestone this time, she's the one to ask about the deadline
<JackYu> cjwatson, ok, thanks.
<slangasek> xnox: oh, if this is about *preparing* the release notes, as opposed to making links active under www.ubuntu.com, then yeah, if the flavors want those for beta-1 they should be writing something :)
<xnox> slangasek: yeah =) redirect goes to ubuntu.com if there is nothing to show ;-) it's a 404 fallback
<slangasek> gotcha
 * xnox just filters to ignore comments on that bug. the redirector is correct..... there is simply nothing to show.
<adam_g> any SRU friends able to take a look at the openstack packages in queue raring-proposed (quantum, nova, keystone, horizon, glance, cinder)?  trying to get them out under their MRE before security updates start hitting whats  currently in -updates
<bdmurray> adam_g: I'll have a look today
<adam_g> bdmurray, thanks so much
<bdmurray> slangasek: I've verified bug 1211511 now and was wondering if we could expidite its release
<ubot2`> Launchpad bug 1211511 in update-manager (Ubuntu) "update-manager hides but wants to install ignored phased updates" [High,Triaged] https://launchpad.net/bugs/1211511
<slangasek> bdmurray: yes, I'm happy to release it
<slangasek> meh, it would be nice if sru-release and sru-review had consistent commandline options for 'release'
<mlankhorst> om nom nom builds
#ubuntu-release 2013-09-05
<skaet> JackYu, slangasek - when all the teams have got the images marked ready who want to release,  we'll be releasing.
<skaet> since Laney will be driving the bits,  we'll be trying to get it all ready during the UK working day timezone.
<skaet> xnox - links to each of the flavors announce and images can be found: https://wiki.ubuntu.com/SaucySalamander/Beta1
<skaet> Laney,  can you double check that the links for the downloads in ^ are matching the locations we'll be publishing to.
<skaet> ?
<skaet> Laney, and on that note,  if it hasn't been done already,  can you pre-publish the CD images?
<skaet> when you come on line.
<skaet> :-)
 * skaet --> zzz,   see you on the flip side.
<xnox> skaet: i have not idea what to do with those links to flavour release notes.
<xnox> s/not/no/
<cjwatson> xnox: the web team has a redirection table that can be per-flavour
<xnox> cjwatson: would it help for lubuntu cd to have .disk/release_notes_url ?
<cjwatson> It sure would
<cjwatson> xnox: done, also for Mythbuntu and Ubuntu GNOME
<cjwatson> (for the next build, of course)
<xnox> thanks...... I wonder if they would want to respin =/
<cjwatson> Seems a pretty minor point to respin for
<xnox> cjwatson: what os= names did you give them? mythbuntu ubuntugnome lubuntu
<xnox> cjwatson: kylin also missing release_notes_url.
<xnox> are the urls set on the nusakan?
<cjwatson> xnox: mythbuntu lubuntu ubuntu-gnome (as standard in cdimage)
<cjwatson> yes they are
<cjwatson> ah yes, ubuntukylin too ...
 * cjwatson applies that one as well
<cjwatson> lp:~ubuntu-cdimage/debian-cd/ubuntu tools/add_live_filesystem FWIW
<xnox> cjwatson: #web-team has setup the redirects, but the os= field seems to get truncated at 10 characters limit, thus e.g. ubuntustudio, ubuntu-gnome, ubuntukylin are too long, get chopped and fail to redirect.
<cjwatson> xnox: I very much doubt that's the fault of our end :)
<xnox> cjwatson: should #webteam work on apache redirects to make those work, or can we reasonably change to shorter names, e.g. studio, gnome, kylin?
<cjwatson> they should fix that
<xnox> cjwatson: ok.
<cjwatson> I don't want to make things irregular at our end - it will just be confusing later
<cjwatson> I have real trouble believing that their software stack cannot be fixed
<cjwatson> (and not by apache redirects, but by just handling longer values of os= directly)
<xnox> cjwatson: yeap, Peter agreed but asked for an RT ticket, which I am filing.
<cjwatson> ok
<Laney> highvoltage: how you looking for b1?
<Laney> Think I'm going to lift the block
<smartboyhw> Laney, what is missing now for the release of Beta 1 to be official?
<Laney> readiness of the remaining flavours, skaet to be around to send the announcement[D[D[Ds
<Laney> with less mangling
<smartboyhw> Laney, OK
<Laney> I'm rusty on how to drive the release scripts so it might take a short while
<highvoltage> Laney: we had an ltsp live problem but it doesn't have to block anything
<Laney> yeah, saw that one
<Laney> OK, unblocking
<Laney> highvoltage: don't forget to mark as ready if you are happy enough
 * cjwatson moves ruby-augeas to main since it's just a rename of libaugeas-ruby
<sil2100> Hi! I would need anyone from the release team to take a look at the https://bugs.launchpad.net/ubuntu/+source/autopilot/+bug/1220494 FFe - it's important for our daily-release process, as it's impacting us heavily
<ubot2`> Launchpad bug 1220494 in autopilot (Ubuntu) "[FFe] Add check so we can determine if the Mouse is caught in an endless loop." [Undecided,Confirmed]
<cjwatson> sil2100: approved
<highvoltage> stgraber: I went ahead and marked them as ready ^^^ - will just have to note the ltsp-live breakage
<sil2100> cjwatson: thank you!
<darkxst> Laney, Hi, sorry I was away bike fixing
<darkxst> we are good to go, images are ready so you can remove the migration blocks!
<smartboyhw> \o/
<smartboyhw> darkxst, it has been removed before you said it:P
<darkxst> smartboyhw, ok
<NikTh> Hello,
<amjjawad> NikTh: hi :)
<amjjawad> good to see you here
<NikTh> I know that most of people don't use these sites, but have a look here please
<NikTh> http://old-releases.ubuntu.com/releases/12.04.0/
 * smartboyhw wonders who uses 12.04.0 -.-
<amjjawad> Laney: are you there? it appears that I have no access to set a build to ready: http://iso.qa.ubuntu.com/qatracker/milestones/302/builds
<NikTh> It has 12.04.2 instead of 12.04.0 .. I know that 12.04.0 is in the DIR (if you scroll down..) but maybe it would more ... correct ... if it had 12.04.0 at the top
<amjjawad> darkxst: already have done that but for the next time, I guess I can do it but I have no admin panel
<skaet> Riddell,  ScottK - you ok with the updgrade testing on Kubuntu?   or still finishing off some tests?
<skaet> amjjawad,  what are you wanting to change on the admin panel
<skaet> ?
<amjjawad> skaet: hi
<smartboyhw> skaet, I think he wants to mark the images ready
<Riddell> skaet: yeah that's fine
<amjjawad> skaet: Laney has asked to mark the build as Ready for Beta 1 but I don't have access
<Riddell> skaet: the Upgrade (image) test for kubuntu should be scrapped but I always get lost in that tracker for some reason so not been brave enough to do it
<amjjawad> skaet: it is done already by Tim but for the next time, I'd like to do it myself
<NikTh> amjjawad: -) hi , we had some unexpected news lately .. a ? (Team Leader.. etc)
<smartboyhw> Riddell, image-based upgrades failed for us:P
 * smartboyhw hates that *unexpected* news
<skaet> amjjawad,  makes sense.
<skaet> smartboyhw,  bug number for the release notes?   Anything specific you want to write up?
<smartboyhw> skaet, I wrote all the bugs we found in the release notes
<smartboyhw> So we are fine
<amjjawad> skaet: so, how can I do that without having access? :)
<skaet> amjjawad, :-)  you can't, and we need to fix that.
<amjjawad> skaet: ok, thanks!
<amjjawad> skaet: anything from my side to be done? email to be sent or something?
<smartboyhw> amjjawad, it's marked ready anyways
 * skaet will look after she finishes some initial tasks,  and if she can't figure it out...  will ask stgraber.  :-)
<smartboyhw> skaet, I think amjjawad has to join the Ubuntu GNOME Release Team or something
<skaet> amjjawad,  are your release notes for UbuntuGNOME up to date
<skaet> smartboyhw,  yes, its something like that.
<smartboyhw> skaet, wait, amjjawad IS in the team
<smartboyhw> amjjawad, are you logged in? -.-
<amjjawad> skaet: I need to double check with jbicha, he already updated it
<amjjawad> I was out of town and came back home last night with so bad migraine so trying to make my way without having migraine back
<amjjawad> smartboyhw: of course I am logged in :)
<smartboyhw> amjjawad, -.- sigh
<skaet> JackYu, do you have any  feedback on the update testing for UbuntuKylin?
<Laney> starting image publishing now
<smartboyhw> Laney, \o/
<smartboyhw> skaet, Laney BTW upgrades using images is NOT working
<smartboyhw> http://launchpad.net/bugs/1220986
<ubot2`> Launchpad bug 1220986 in ubiquity (Ubuntu) "On upgrade from image testcase ubiquity shows no upgrade option." [Undecided,New]
<smartboyhw> (For both UbuntuKylin and Ubuntu Studio)
<Laney> OK, make sure it's in your release notes
<Laney> also that xnox knows ;-)
<smartboyhw> Laney, I put it in Ubuntu Studio's release notes
 * Laney has never actually tried an upgrade like that
<smartboyhw> xnox, do take note of the bug:P
<xnox> Laney: smartboyhw: that bug is invalid, see my comment on the bug.
<smartboyhw> xnox, -.- But UbuntuKylin is failing the test too
<smartboyhw> I think they need to report a seperate bug
<smartboyhw> ypwong, JackYu maclin ^
<xnox> Laney: smartboyhw: with multiple operating systems installed we do not provide upgrade option, as per design. As it's imposible to adequately present which one of the multiple ubuntu instlalations to upgrade.
<skaet> phillw,  is there anyone working on getting results for Lubuntu desktop preinstall for armhf+ac100?  or do we drop it from the list?
<Laney> The testcase should say this then
<smartboyhw> skaet, ogra_ is working on it (I told him to do so:P)
<xnox> smartboyhw: before filing upgrade bug, do check the tables in the design spec, as depending on what other installations are present there are various options present.
<ogra_> working on what ?
<smartboyhw> Laney, I will edit it soon.
<smartboyhw> ogra_, you are testing the armhf+ac100 image of Lubuntu right>
<ogra_> smartboyhw, i told you i'll do one test before final
<smartboyhw> ogra_, ah OK
<ogra_> i dont have the time to do beta testing
<smartboyhw> So, dump it then?
<xnox> smartboyhw: Laney: there are 8 typical variants of options available. and I'd rather not change the test-case as ideally we would do a matrix test of all 8 options, which is hard to cover/expose in the testcase.
<ogra_> for beta ? yeah, just leave the daily around
<maclin> xnox, you mean the upgrade option will be displayed only on a single OS?
<Laney> xnox: The test cases can't tell people to do things that aren't allowed
<Laney> That doesn't make sense
<smartboyhw> skaet, phillw resigned yesterday as Lubuntu QA lead and Release Manager, so you will find difficulties in finding somebody to ACK -.-
<xnox> maclin: https://docs.google.com/document/d/1bZ4yQIVgGaUGSYu3qiUHnQt3ieBZoqunP_DcleHCr3I/preview?pli=1#bookmark=id.35db66d9d3b3
<skaet> smartboyhw,  ack.  ok, I'll mark it as not part of the release.
<smartboyhw> skaet, sure
<xnox> maclin: that's the table outlining when/which options should be shown. "Upgrade or Reinstall" should be available when there is only one ubuntu installation.
<skaet> Laney,  ^ can you double check it isn't in the images you're pushing out?
<Laney> it is not
<skaet> Thanks Laney
<Laney> I guess I should remove old alpha images at the same time
 * skaet nods
<maclin> xnox, I got it. Maybe we misunderstand the upgrade(image) testcase. we will do the test again,thanks:)
<skaet> highvoltage, stgraber - what's the status of the release notes for Edubuntu?   ETA?
<skaet> amjjawad, are all the Ubuntu GNOME release note edits done for your team?  or is there still some coming?
<amjjawad> skaet: should be unless jbicha wants to add something else?
<Laney> Do I need to build source images? If so, how?
<cjwatson> cron.source
<Laney> does the project matter?
<skaet> jbicha,  any further updates to Ubuntu GNOME release notes from your perspective?
<skaet> thanks amjjawad
<amjjawad> skaet: at your service :)
<smartboyhw> skaet, changed the Ubuntu Studio announcement link on the annoucement draft wiki page
<skaet> Thanks smartboyhw  :-)
<JackYu> skaet, hi, I was in a meeting just now. Did I miss something? BTW, the release notes for UbuntuKylin is ready.
<skaet> JackYu,  Thanks.    The upgrade tests for UbuntuKylin haven't been marked as ready yet.  Anything we're waiting on from there?
<jbicha> skaet: amjjawad: I think the UG release notes are fine
<smartboyhw> skaet, we are waiting for maclin to complete the Upgrade (image) tests
<maclin> xnox, I do the upgrade with 13.10 image to upgrade installed 13.04,but the upgrade option is disabled. There is only one 13.04
<xnox> maclin: hm that's a bug. Can you open terminal / switch to tty1 with Ctrl-Alt-F1, to get the logs from within that run?
<xnox> maclin: with $ ubuntu-bug ubiquity
<JackYu> skaet, we could not open http://iso.qa.ubuntu.com/ since five hours ago:(
<skaet> maclin - bug:1220986?
<maclin> smartboyhw, I can't open the tracker page since 19:30
<smartboyhw> maclin, I can
<smartboyhw> Just refreshed
<smartboyhw> maclin, JackYu did the Chinese government blocked the webpage?
<smartboyhw> -.-
<smartboyhw> Yep, full access whatsoever
<smartboyhw> skaet, I will remove the amd64 upgrade testcase for Studio, I am blocked on doing it (not much bandwidth on internet in a VBox)
<skaet> JackYu,  am able to access http?://iso.qa.ubuntu.com/  any thing you want me to update for you
<skaet> ?
<jbicha> skaet: bug 1220986 was marked invalid so should it be removed from the release notes?
<ubot2`> Launchpad bug 1220986 in ubiquity (Ubuntu) "On upgrade from image testcase ubiquity shows no upgrade option." [Undecided,Invalid] https://launchpad.net/bugs/1220986
<smartboyhw> jbicha, it is removed from mine
<smartboyhw> Not sure on the main ones though:P
<skaet> jbicha,  yup - doing.  thanks.
<smartboyhw> Hmm, both maclin and JackYu went MIA
<smartboyhw> Not good:(
<smartboyhw> JackYu, welcome back:P
<JackYu> skaet, we change another network and it works. We will finish it soon. Thanks.
<skaet> JackYu,  :-)  Thanks!
<xnox> FFe granted for eclipse-eclox bug #1220362
<ubot2`> Launchpad bug 1220362 in Ubuntu "[NEW] [FFe] Sync eclipse-eclox 0.10.0-1 (universe) from Debian unstable (main)" [Undecided,Fix released] https://launchpad.net/bugs/1220362
<smartboyhw> skaet, \o/ everything is ready:P
<xnox> ScottK: ^ eclipse-eclox synced into new queue.
<skaet> smartboyhw,  :-)
<smartboyhw> skaet, waiting for your call:)
<skaet> Laney, images are all signed off and ok to go now.   Let us know when we should start looking for them on the server and testing the links/etc.
<Laney> cron.source is still running
<skaet> ok.
<Laney> oop, just finished
<smartboyhw> LOL
<Laney> skaet: just triggered the mirrors
<skaet> thanks Laney
<smartboyhw> I think we can release soon!
<Laney> take a few minutes to sync up
<skaet> smartboyhw,  working through the release notes and checking the links all working will take some time.
<smartboyhw> skaet, sure;)
<stgraber> Laney: if you care about bittorrent, you should wait around an hour
<stgraber> (it's fine not to care)
<Laney> yep
<Laney> skaet's call at this point
<skaet> stgraber, Laney - prefer that bittorrent is working
<Laney> skaet: I'm getting data on xubuntu-13.10-beta1-desktop-amd64.iso now
<Laney> torrent
<skaet> Laney,  ok will start checking through the links
<Laney> I'm seeding to myself
<Laney> this is fun
<Laney> s/seeding/whatever it's called when you haven't finished downloading/
<smartboyhw> Laney, skaet: How is the checking going?
<Laney> omgubuntu already announced the beta for us :-)
<skaet> Laney,  typical\
<skaet> :-P
<smartboyhw> heh
<smartboyhw> So it isn't officially announced by Ubutnu Release Team (yet)?
<Laney> not until you see the mail
 * smartboyhw does not know how fast can he see the mail:P
<skaet> yup.
<smartboyhw> Sigh, got to sleep now
<skaet> stgraber, highvoltage - link isn't working for Edubuntu notes - do I have the correct one?   or should I just point to the Beta1/Edubuntu page?
<skaet> smartboyhw,  thanks for your help getting this ready.   Sleep well.
<Laney> Can someone please remove gst-libav1.0 from s-proposed?
<skaet> stgraber, highvoltage: is http://www.edubuntu.org/news/13.10-beta1 the right link to use?
<amjjawad> Funny what OMG Ubuntu is always trying to prove: https://www.facebook.com/omgubuntu/posts/660809390598268
<amjjawad> I couldn't help it, I had to leave a tiny small note :)
<stgraber> skaet: no idea, let me check
<skaet> thanks stgraber.
<stgraber> skaet: yep, looks right (even if it doesn't seem to exist)
<skaet> stgraber,  any feel for when it can be made to exist?
<stgraber> skaet: no idea, I don't really have time for this at the moment, so hopefully highvoltage can take care of it
<skaet> stgraber, ack.   Let me know if you hear back from him,  its now on critical path for sending out the announce.
<stgraber> skaet: I created a basic one now
<cjwatson> amjjawad: OMG Ubuntu once removed my comments pointing out that they'd jumped the gun on a release announcement
<skaet> thanks stgraber
<stgraber> skaet: let me know when to mark it public
<amjjawad> cjwatson: I'm not surprised but for me, I will keep posting and correcting the FUDs they are spreading :D
<Laney> post it on a forum you control if you want to do that :P
<cjwatson> amjjawad: (I was explicitly posting on behalf of the release team)
<amjjawad> cjwatson: I had a word with them before
<skaet> stgraber,  go ahead and mark it public.   Rest of flavors are visible.
<amjjawad> I have also talked to web upd8 once because they have posted something incorrect as well about Lubuntu. Web Upd8 have edited their post and they did not remove my comments :)
<skaet> all the links to the images seem to be working,  and that's the last link left.
<amjjawad> but for OMG Ubuntu guys, they don't really reply your comments! at least, that what I've seen so far
<xnox> cjwatson: i wonder if we can make a joke about OMG ubuntu in BetaFinal release announcement, to make their readers backslash at them ;-)
<xnox> cjwatson: i did email Joey, why it's causing problems (e.g. for final release mirrors are not synced up)
<stgraber> skaet: marking it public will immediately post it to planet ubuntu
<Laney> stgraber: Can you take care of the gst-libav1.0 removal request I asked for ^ please?
<Laney> (sorry to ping but general requests are going unanswered)
<xnox> cjwatson: at least OMG don't blog about leaks, which is better than some Ubuntu Members.
<cjwatson> xnox: Needling them is unlikely to be productive, I think
<stgraber> Laney: sure
<Laney> ty
<stgraber> Laney: got a bug report?
<Laney> nop, want one?
<stgraber> please
<stgraber> that makes it easier to figure out why something got removed later on (and avoids overly long removal comments)
<Laney> k, didn't know if you cared for proposed
<utlemming> I guess the bot doesn't supress the builk add any more....sorry :)
<Laney> stgraber: bug #1221322
<ubot2`> Launchpad bug 1221322 in gst-libav1.0 (Ubuntu) "Remove 1.1.3-1 from saucy-proposed" [Undecided,Confirmed] https://launchpad.net/bugs/1221322
<xnox> utlemming: there is a magic command to silence / unsilence the bot, but i don't remeber the syntax.
<Laney> I thought it was supposed to buffer / abbreviate for mass build additions
<stgraber> Laney: done
<Laney> fanx
<stgraber> the bot has flood protection, but if you're unlucky enough to push the builds while it's scanning, it sees them as two smaller batches and so skips the flood protection
<xnox> cjwatson: hm. making locations 503 to general public? or will that block mirroring?
<cjwatson> xnox: it would block mirroring and it's not worth it for the relatively minor irritation caused
<xnox> ok.
<cjwatson> or at least it could block some mirroring
<cjwatson> and generally, I don't think we should inconvenience ourselves because people suck :)
<cjwatson> for instance it's useful for us to be able to examine our own web pages pre-release
<skellat> Any possible way to break the OMG download links?
<skaet> ok,  announce email has been sent off...
<stgraber> I think we had to publish a 301 to some html page once when slashdot announced a release before it happened, but in that case we had a check on the referrer and the links were pointing to the wrong ISO image to being with
<skaet> stgraber,  go ahead and make your link public.
<stgraber> skaet: done
<xnox> yeah.... at my old workplace we special cased all employee sub-nets to allow viewing changes ahead of releasing the lockdown. Not feasible for a public project the size of Ubuntu =)
<Laney> I'll re-cron and mark the milestone as released
<xnox> \o/
<Laney> utlemming: want to mark your cloud images as ready?
<Laney> not sure what difference that makes, mind
<cjwatson> skellat: it's not worth it
<skaet> stgraber,  can you update the header for this channel and #ubuntu-devel?
<stgraber> skaet: I can't, no ACL
<Laney> you both can
<Laney> no +t
<stgraber> oh, good point
<stgraber> skaet: you can do it yourself
<skaet> stgraber,  I've got a password snag going, can't authenticate.
<stgraber> skaet: don't need to
<skaet> (or would have)
<skaet> ?? ok trying
<stgraber> skaet: the topic isn't protected in either channel
 * skaet sees 12.04.2 should go to 12.04.3 and fixes at the same time.
* skaet changed the topic of #ubuntu-release to: Released: 13.10 Beta 1, 13.04, and 12.04.3 | Archive: open | Saucy Salamander Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or beer | melior malum quod cognoscis
<skaet> coolio.  :-) that worked.
<utlemming> Laney: yeah, I was just looking why my results for tests didn't land...working on that now
<Laney> stgraber: will he still be able to update the status if the milestone is released?
<Laney> I re-cronned and don't really want new builds to land there
<Laney> Or I could just turn off build publication for that one
<Laney> doing that
<Laney> skaet: Think you picked up some whitespace damage in that email
<skaet> Laney,   awe... drat.
<skaet> yup did.   Resending to be  readable.
<utlemming> Laney: okay, I think I marked them ready
<Laney> utlemming: Great, thank you.
<amjjawad> I have not noticed that before but I just had a look and every date on http://cdimage.ubuntu.com/ubuntu-gnome/releases/saucy/beta-1/ is 05-Sep-2013 except for the ISO files which is 03-Sep-2013 ... is that normal? as far as I remember, all the entries should be on the same day or maybe it is my rusty memory?
<skaet> cjwatson,  can you reject the message waiting moderator approval in ubuntu-devel-announce?
<amjjawad> did not yet had my coffee so :P
<Laney> amjjawad: Some of them are made when the image is published and some when it is first built
<amjjawad> so the MD5SUM which is dated 05-Sep-2013 will work for the image dated 03-Sep-2013 ??
<Laney> You can see the same on e.g. http://cdimage.ubuntu.com/ubuntu-gnome/releases/raring/release/
<Laney> right
<amjjawad> Laney: I see, thanks a lot :) just to double check :D
<skaet> cjwatson,  looks like I was able to cancel it directly.
<infinity> xnox: Hrm.  Why does boost-mpi-source1.53 suddenly want to be in main?
<xnox> infinity: there was a mistake in one of the upload, but all should be correct now, let me check.
<skaet> Laney,  my test email to self came through ok.   trying again....
<infinity> +Package: libboost1.53-all-dev
<infinity> xnox: ^-- Perhaps because the metapackage moved?
<xnox> infinity: that package was always in -mpi- package, no?
<infinity> xnox: Oh, no.  Because libboost-graph-parallel1.53.0 moved.
<infinity> xnox: And libboost-graph-parallel1.53.0 depends on libboost-mpi1.53.0
<xnox> infinity: moved from where to where?
<infinity> http://launchpadlibrarian.net/149409992/boost1.53_1.53.0-6%2Bexp2ubuntu2_1.53.0-6%2Bexp3ubuntu4.diff.gz
<infinity> xnox: From mpi to the base package.  Check the debian/control diff.
<skaet> Laney,  google mail is giving me woes...
<xnox> infinity: right, which is wrong.
<infinity> Err, wait.  Everything moved?  I'm so confused by this diff.
<xnox> infinity: boost1.53 does not build graph-parallel, see https://launchpad.net/ubuntu/+source/boost1.53/1.53.0-6+exp3ubuntu4/+build/4928604
 * skaet cancelled post to ubuntu-devel-announce again.
<xnox> infinity: it does not produce said binary package, what does component missmatches analyse?
<amjjawad> skaet: two emails? I guess they are the same, right?
<infinity> xnox: I think c-m is unhappy because your .dsc is wrong because your debian/control is wrong.
<infinity> xnox: https://launchpadlibrarian.net/149223980/boost1.53_1.53.0-6%2Bexp3ubuntu4.dsc
<infinity> xnox: Your source package CLAIMS to build all the stuff from -mpi- and that throws the extra-include rescuing operations off.
<xnox> infinity: yes my .dsc lists things it doesn't build.
<infinity> xnox: Again, see the confusing diff.
<infinity> xnox: Why did you change that?
<xnox> infinity: makes it a two-liner to convert from boost -> mpi source package, instead of spending time reapply the pathches and carefully checking that nothing got lost.
<xnox> infinity: plus it makes it suitable to be committed in debian, which I did.
<xnox> infinity: ok, so i have to clean up my .dsc.
<xnox> i guess such tricks are fine on gcc* packaging because well, it's all in main.
<infinity> xnox: If you want to retain the 2-liner semantic, you'll probably want to switch to a control.in
<xnox> yeap.
<xnox> infinity: can I lie in .dsc? =) e.g. sed it before uploading =))) muahahaha
<xnox> that would confuse everyone.
<infinity> xnox: No.
<Laney> skaet: bad
<Laney> skaet: can you turn off HTML mail?
<skaet> Laney,  yup,  no links then,  but... better than what we're seeing.
<skaet> I'll send the test one to you before trying to post again.
<Laney> it's fine how it was on the wiki
<skaet> Yeah,  that was what was cut/pasted in.   google mailer fun.  :-P
<infinity> That's some seriously unreadable email.
<ogra_> not in a modern MUA
<ogra_> :P
<Laney> hey, mutt was uploaded this year
<skaet> infinity,  yeah,  html mailers :-P   Looks fine in my inbox, but ....
<ogra_> looks fine in evolution too
<Laney> look at the list archive
<infinity> ogra_: It only looks fine in a "modern" MUA because you're reading the HTML part.  The text part is universally ugly, no matter what you read it in. :P
<infinity> On the other hand, I can't complain TOO much, because at least there IS a text part.
<infinity> So, it beats the HTML-only email I get from, say, my bank. :(
<skaet> Laney,  new test version on its way to you....   if that doesn't work,  I'll just give up on trying to have the links working.
<ogra_> heh
<Laney> I could send it ;-)
<infinity> skaet: Why do you care about having HTML links?  Any decent MUA will auto-linkify http:// links in a text-only email on the client side.
<skaet> Laney,  there are a couple of edits to what's on the WIKI page version needed.
<skaet> Laney,  how did it look
<Laney> sec
<skaet> infinity,  was standard process to add them.   Complaints in the other direction before.
<Laney> yes, looks fine now
<infinity> "Standard process"?  None of the rest of us send HTML email.
<skaet> Thanks Laney.  Ok,  keeping fingers crossed that 3rd time's a charm.
<amjjawad> balloons: you there?
<balloons> amjjawad, pong
<amjjawad> hi balloons
<balloons> hello
<amjjawad> just to let you know, I am planning to post Kate's email on Ubuntu QA Social Sites
<balloons> excellent, I wanted to share an easy link to all the images, but there's no master folder.. it's seperated by flavor
<amjjawad> the more testers, the better ;)
<balloons> :-)
<amjjawad> Leave it to me
<amjjawad> what happened to our master plan by the way? :P
<balloons> it's still out there.. beta1 and tests failing took precedence
<amjjawad> I did not forget it but I don't want to push hard, I know you are busy ;)
<balloons> UGJ is coming up, as usual I'd like to try and do something; a good time to test out ideas
<amjjawad> UGJ?
<bdmurray> skaet: It just occurred to me that DevelReleaseAnnouncement was not updated to reflect the change from ALPHA to BETA.  I see it is on https://wiki.ubuntu.com/BetaProcess, is that the right wiki page?
<skaet> infinity,  the HTML email was not intended and a result of using a new mail client.  Now know its an issue, and will check to avoid in future.   Adding the links to be hot links on the announce emails is something that's been done historically .  see: https://lists.ubuntu.com/archives/ubuntu-release/2012-September/001979.html
<skaet> bdmurray,  yes,  but that page needs a good hard scrub as several things no longer apply this cycle that are being called for on it.
<xnox> skaet: most email client auto-detect URLs and turn them into clickables, which includes all web email clients, desktop clients, mailing list archival websites and blogging engines.
<infinity> skaet: That list archive post is just an example of what I was saying, that a decent client (in this case, the list archive software) will automatically linkify strings starting with "http://"
<xnox> skaet: thus plain text emails are preferred (without multipart html portions )
<skaet> infinity,  xnox - went through explicitly adding the links before for that one I pointed you at.   But if everyone is agreed it shouldn't be done in future,  then lets just make it explicit.
<bdmurray> skaet: is somebody going to be doing that scrub of the BetaProcess page?
<skaet> bdmurray,  I'll do a scrub this weekend then mail out for comments.
 * skaet handling it as part of checklist
<slangasek> skaet: please don't drop anything from that page without discussion.  Stuff already fell through the cracks last cycle because of the process pages not being followed.
<skaet> slangasek, was thinking, I'd create a temp page,  let folks compare back and forth,  then merge.   ok?
<slangasek> there's nothing on that page that should be dropped, and if the optional beta-1 is no longer the point that it should happen, we need to make sure we have some other way to make sure it happens at the appropriate time
<slangasek> skaet: as long as things don't wind up dropped from the page before we've sorted out where they should go, fine
<skaet> slangasek,  approach I was contemplating was a table,  with tick boxes depending if applicable or not.  Columns being for optional vs everyone.
<skaet> hence,  scratch page to fuss on.   Agree very much don't want to accidently drop something.
 * apw notes this is the xen update (for raring for now) under a recent preliminary MRE approved by the techboard
<highvoltage> stgraber, skaet: thanks for taking care of those notes, I was out
<highvoltage> (been hanging with Richard Stallman, of all people :p)
<lool> Mighty release lords, please find a new FFE for gst-fluendo-mp3 https://bugs.launchpad.net/ubuntu/+source/gst-fluendo-mp3/+bug/1221434
<ubot2`> Launchpad bug 1221434 in gst-fluendo-mp3 (Ubuntu) "FFE New upstream release" [Undecided,New]
<infinity> lool: I'm offended by your test being in French.
<infinity> lool: Approved, though.  Please close the bug in your changelog.
<lool> thanks
<infinity> (Or if you're syncing from Debian, close by hand, whatever)
<lool> unfortunately, it will be in NEW in Debian for now
<lool> due to new binary package
<lool> infinity: ^ resulting binaries
<lool> hmm missing armhf but coming
<lool> there we go
<slangasek> bdmurray: interestingly, the oldest unverified SRU in precise right now seems to be for bug #1122596, which you sponsored the upload of... seems like that's a bug people might like fixed, any idea how we can get it verified?
<ubot2`> Launchpad bug 1122596 in libappindicator (Ubuntu Precise) "Race condition in app_indicator_init() causes application crash" [High,Fix committed] https://launchpad.net/bugs/1122596
<bdmurray> slangasek: the test case mentions "we have many crashdumps"... I wonder where those are
<bdmurray> if we had some crashes then we could look in errors for them
<slangasek> bdmurray: seems that edit was from John Vert, who I guess is with Valve
#ubuntu-release 2013-09-06
<tjaalton> lp1197363 has been verification-done for some time now
<tjaalton> it would also fix bug 1175533, not that it was mentioned on the changelog..
<ubot2`> Launchpad bug 1175533 in HWE Next "[HSW] intel VGA driver i915 doesn't support new haswell graphics [8086:0a2e] " [Undecided,New] https://launchpad.net/bugs/1175533
<tjaalton> also, the lts backport copy of mesa 9.1.4 is in precise-updates already, kinda weird that the "mother" package isn't in raring-updates yet :)
<infinity> tjaalton: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1197316 is slightly less v-done.
<ubot2`> Launchpad bug 1197316 in mesa (Ubuntu Raring) "GPU hang with Haswell GT3" [High,Fix committed]
<infinity> tjaalton: (ie: if you want people to promote things, give us green bugs)
<tjaalton> ahh, good poing
<tjaalton> assigned to me even :)
<tjaalton> well, the same commits are in 9.1.4, the bug was mainly for quantal tracking
<infinity> tjaalton: I'm not arguing the purpose of the bug, just that it shows up as non-verified on our reports, so without manual digging, we'll assume we should skip that update.
<tjaalton> I'll just mark it verified
<infinity> tjaalton: http://people.canonical.com/~ubuntu-archive/pending-sru.html is handy to check if you're wondering the state of something.
<tjaalton> saucy worked fine on gt3, had 9.1.4 there until 9.2 landed
<tjaalton> infinity: yeah, I'll leave it open..
<tjaalton> the page on a tab that is
<infinity> slangasek: Dude, who reviewed/accepted your sponsored apt upload where you completely failed to clean the tree and shipped debian/apt/EVERYTHING in the diff?
<infinity> slangasek: Please sir, may I have another?
<tjaalton> :)
 * infinity thinks we need a Code Review 101 if diff like that are getting through.
<infinity> s/diff/diffs/
<xnox> infinity: let's see if component-missmatches likes this next upload.
<xnox> *sigh* ftbfs.
<xnox> I wish syncpackage checked new queue, when syncing in new packages. Feel free to reject one of dianara syncs =)
<Laney> Someone please consider my GStreamer FFe: bug #1220588
<ubot2`> Launchpad bug 1220588 in gstreamer1.0 (Ubuntu) "[FFe] Update GStreamer stack to 1.1.4" [Undecided,New] https://launchpad.net/bugs/1220588
<Noskcaj> bug 1221626
<ubot2`> Launchpad bug 1221626 in clive (Ubuntu) "[FFe] Sync clive 2.3.3+cclive (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1221626
<tjaalton> infinity: huh, apparently I had the tag-editing thingy open on the mesa bug, without actually committing the change. thanks anyway
<xnox> infinity: boost cleared from component-mismatches.
<slangasek> infinity: oh, that was a self-accept because I was sponsoring it so it wasn't really "Mine"; unfortunately I hit the wrong button and tried to ^C it and the archive beat me to it
<slangasek> infinity: if you'd like to remove it I can reupload
<slangasek> infinity: and oh, the apt package has an incredibly buggy 'clean' target, instead of cleaning anything after build, it just calls 'configure' and then leaves a mess behind. :P
<highvoltage> "hi, i am Rogel, im new in linux OS. i just wanna ask if it is ok if I install edubuntu alongside with windows 7..
<highvoltage> if it is ok, how? because the last time i install KUBUNTU and my data were deleted."
<highvoltage> bad kubuntu!
<ScottK> It's the same friggin' installer.
<ScottK> Pick the wrong option and that will happen.
<infinity> slangasek: Yeah, well aware of apt's hilarious clean target, I usually start from a clean source tree and build with -nc for SRUs.
<slangasek> this makes me sad
<infinity> slangasek: If you want to upload a less broken one, feel free.  No point in removing the old one, you need to supersede the version anyway.
<slangasek> infinity: I'll only upload it if you make me feel guilty enough
<infinity> slangasek: You should feel guilty by default for including binaries and pregenerated DEBIAN/* in an upload.
<infinity> slangasek: That shouldn't need my help, surely.
<slangasek> well played
#ubuntu-release 2013-09-07
<slangasek> ScottK: so there's a python-cinderclient upload in raring-proposed which, according to bug #1191848, seems to have been intended for -backports?
<ubot2`> Launchpad bug 1191848 in raring-backports "please backport cinderclient 1.0.4 to raring" [Wishlist,Confirmed] https://launchpad.net/bugs/1191848
<adam_g> hmmph
<darkxst> would it be ok to upload https://launchpad.net/bugs/1219188? do I need to do a Ffe for that?
<ubot2`> Launchpad bug 1219188 in gnome-shell (Ubuntu) "Add support for separate background on lock screen" [Undecided,In progress]
<ScottK> slangasek: I'm away from an appropriate computer, would you please reject and reupload to backports?
<slangasek> ScottK: done
<ScottK> Thanks.  Just now got to my computer to look in on it.
<slangasek> ScottK: well, it seems my upload didn't take anyway, because it's older than the version in the archive.  Is the upload target for backports still the same?
<slangasek> I mean, the same as the rest of Ubuntu uploads
<ScottK> Yes, just foo-backports for release.
<slangasek> hmm, that's what I had
<slangasek> oh
<slangasek> ok, that upload was *really* broken
<slangasek> it was an upload of 1.0.3, in response to a request for backporting 1.0.4.  And saucy now has 1.0.5.
 * slangasek washes his hands of this mess
<ScottK> I'll take a look at it.  Thanks.
<ScottK> That was not fun.
<ScottK> Ended up uploading both a fix to 1.0.5 in saucy and having to fish 1.0.4 out of LP (and fix it as well).
<ScottK> One more time, with the epoch ...
<thotz> is it possible to upload blender in saucy or am I too late? I have made a bug report: https://bugs.launchpad.net/ubuntu/+source/blender/+bug/1220384
<ubot2`> Launchpad bug 1220384 in blender (Ubuntu) "FFe: Blender to version 2.86a" [Undecided,New]
<smartboyhw> thotz, fix https://launchpad.net/ubuntu/+source/blender/2.68a-3 's build failure:P
<thotz> smartboyhw: that's my problem. I can't do such things.
<smartboyhw> thotz, why?
<thotz> not enough knowledge. maybe wrong channel here, last time I asked to get gimp 2.8.6 in saucy that was in ubuntu-devel.
<thotz> but i read about ffes
<smartboyhw> thotz, now that it's in -proposed, it doesn't need an FFe. You just need to make it build.
<thotz> smartboyhw: ok i understand. I removed ffe from the bug.
<thotz> smartboyhw: but the build thing, but I think blender 2.68a should be in Saucy. I'm a simple bug triager and I like to test new things. I simply have no time for more. but thank you!
<darkxst> would it be ok to upload https://launchpad.net/bugs/1219188? do I need to do a Ffe for that?
<ubot2`> Launchpad bug 1219188 in gnome-shell (Ubuntu) "Add support for separate background on lock screen" [Undecided,In progress]
<darkxst> ^ Laney, stgraber ?
<stgraber> darkxst: you'd need a FFe
<darkxst> stgraber, ok, updated bug
<lool> hey
<lool> there seems to be something wrong with this package build: https://launchpad.net/ubuntu/+source/android/20130905-0ubuntu4/+build/4943178 it's been running for 2 hours and stopped making progress; previous builds on the same buildd took 45mn
<lool> I'm tempted to try this Cancel build button
<stgraber> lool: I'll wait till :45 see if it's just some horribly slow I/Os on that final dpkg-deb call, if not, I'll cancel, disable that buildd and have it restarted somewhere else
<stgraber> infinity: ^ (stuck on lamiak)
<elmo> it finished
<elmo> 2013-09-07 19:41:59+0000 [-] Returning build status: OK
<elmo> I've no idea why launchpad's claiming it's still building
<stgraber> special
<stgraber> so unless we've got some of the LP guys around (wgrant?) I guess our best bet is to cancel the build and have it rebuilt (and waste 45min of buildd time...)
<lool> (or cjwatson perhaps)
<lool> would be nice to preserve the broken build somehow, to allow investigation
<lool> not sure whether upload an ubuntu5 would be any better than cancelling the build on that respect?
<stgraber> well, between what elmo said above, the build log (that I believe is now always kept) and the fact that it's clearly currently in state BUILDING in LP, I don't think we'd loose any debugging data by cancel+rebuild
<stgraber> (and that'd save myself an android re-upload)
<lool> ok, lets do it then
<stgraber> canceling (well, trying to anyway), not sure what'll happen since there's nothing to cancel on the builder side
<lool> seems to stick in the Cancelling state; can't possibly be long since there's nothing to do?
<stgraber> yeah... I'll upload another no change rebuild then
<lool> thanks, sorry for your waster time and bandwidth
<lool> *wasted
<stgraber> uploaded
<stgraber> elmo: hey, if you're still around, could you check the status of:
<stgraber> https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa/+build/4943255
<stgraber> https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa/+build/4943251
<stgraber> https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa/+build/4943247
<stgraber> those are chromium builds all pretty much at the end of the build process and using the 3 other i386 buildds
<stgraber> so I'm wondering if we don't have some kind of bigger issues with all our buildds being somehow stuck
<stgraber> the chromium builds on the amd64 buildds also appear to be done but still running according to LP...
<infinity> Does buildd-manager need a restart perhaps?
<infinity> elmo: Can you give buildd-manager a restart on alpaca?
<infinity> stgraber: You didn't need a no-change rebuild for that, it's quite clearly (I think) buildd-manager being stuck, not the buildd.
<stgraber> infinity: yeah, it wasn't clear at the time (I hadn't spotted that all the other builds were in the same state)
<infinity> That's the failure mode for buildd-manager being stuck.  Build finishes, but never gets reaped.
<cjwatson> Yeah.  Sorry I didn't get here in time, could have saved you a reupload.
<cjwatson> lool: FWIW this failure mode cannot ever have anything to do with the archive
<infinity> Shame I was eating dinner at the time people were cancelling and reuploading.
<infinity> Oh well.
<cjwatson> The cancel will probably not actually happen (even though it claims it's happening)
<infinity> Now we wait patiently for someone to restart buildd-mangler, or call the emergency number.
<infinity> cjwatson: It should happen when buildd-manager is restarted and picks up its new state, I'd guess?
<stgraber> well, I should have checked /builders before re-uploading, not after. How well, we'll just waste 45min of one i386 builder, it's not the end of the world.
<infinity> Or maybe it'll reap the SUCCESS build instead.
<cjwatson> infinity: No, neither
<cjwatson> infinity: It isn't actually cancelling because it succeeded - the cancel actually gets ignored
<infinity> cjwatson: What do you figure will happen?  Fail the builder and cry for help?
<cjwatson> infinity: (But it might be superseded by the time it succeeds)
<infinity> cjwatson: Want to ring up elmo before it's too late in the UK for that to be a polite thing to do, and we'll get it all unstuck?
<cjwatson> infinity: Could somebody else?  The children are asleep after something of a battle to get them that way and I'm trying to avoid making noise.
<infinity> I'm just trying to avoid the double-whammy of long distance and roaming charges. :P
<lool> I can call
<infinity> Danke.
<lool> is it the emergency number, or literally elmo's number that I should call?
<infinity> Well, given that elmo was here ~30m ago, calling him would probably be sane.
<infinity> The emergency number, if you'd prefer not to bug elmo.
<infinity> (Though he might be the on-call guy anyway)
<lool> I'll try the emergency one, seems more appropriate
<cjwatson> I would use the emergency number.
<cjwatson> Assuming this is actually something that can't wait.
<infinity> It can't wait until Monday, we seem to have thoroughly buggered all the x86 buildds.
<cjwatson> (buildd-manager isn't actually totally dead, it's just having its usual problems with certain builds)
<infinity> Yeah, but it's "dead enough".
<cjwatson> Yeah
<infinity> Did someone remove the 80% rule for PPAs for me?
<infinity> cjwatson: Was that you?
<cjwatson> Just in case people were under the impression that it was actually entirely crashed
<cjwatson> infinity: Yes, I did
<infinity> cjwatson: Just for non-virt, or for all PPAs?
<cjwatson> Across the board
<infinity> Shiny.
<cjwatson> Given decent cancellation it provides no real benefit
 * infinity nods.
<cjwatson> Might as well build things as fast as possible and then occasionally need to cancel when something needs to jump the queue NOW
<infinity> Yeahp, that was my argument too.
<infinity> The most efficient use of resources is to be always building.
<cjwatson> (Also it was a pain to fit that code into wgrant's refactoring, because it meant that dispatch logic depended on things that happened earlier in the same scan
<cjwatson> )
<slangasek> stgraber: finally figured out the sbsigntool bug, so sbsigntool + shim-signed 1.3 are now uploaded
<stgraber> slangasek: nice! thanks
<slangasek> which gives us actual secureboot netboot, as soon as we get a pregenerated tftp-capable grub
<infinity> slangasek: Say, where's my non-crufty apt? :)
<cjwatson> slangasek: (er, yeah, not ignoring you on that, just didn't have bandwidth to think about it at the weekend)
<slangasek> cjwatson: no problem :)
<infinity> slangasek: Regarding sbsigntool, is this something we want backported/SRUed?
 * cjwatson -> away
 * infinity notes that ftpmaster is still running 0.4-0ubuntu2~0.IS.10.04.1, which could explain some curious things I see in publisher logs.
<slangasek> infinity: apt> I'll do that later this evening, I really needed to be done with this shim nonsense and now I need to not be at a keyboard for a while :)
<stgraber> infinity: yeah, I think we want gnu-efi, sbsigntool, shim and shim-signed SRUed to 12.04 for 12.04.4 (as we clearly missed 12.04.3)
<infinity> stgraber: Check, and current sbsigntool also tossed in lucid-cat, perhaps?
<slangasek> infinity: backported/SRUed> yeah
<infinity> (since that's what actually signs the bits in the archive)
<slangasek> infinity: can't we make lucid-cat obsolete instead? ;)
<infinity> slangasek: 95% of -cat goes away when we upgrade pepo to precise which is happening Very Soon.
<slangasek> infinity: right, so I would Not Worry About Itâ¢
<infinity> slangasek: I've been trying to make sure Soyuz reqs are getting SRUed to precise, so we don't need to rely on cat.
<infinity> Which reminds me, time for a dpkg SRU for ppc64el.
<infinity> (And a saucy upload)
<slangasek> we want sbsigntool updated in precise as a precondition for SRUing shim itself; the distro's demands on sbsigntool are much more onerous than the archive's
<slangasek> is ppc64el landed in dpkg upstream?
<slangasek> anyway, afk now
<infinity> slangasek: It is, yeah.  jbailey filed the bug a month or two ago, and I think guillem landed it in 1.17
<slangasek> fun
<infinity> Which I was going to merge if it ever got to testing, but it's not done so yet. :P
<infinity> Anyhow, adding a new arch is a 1 or 2 line patch, not worth the full merge just for that.
<infinity> slangasek: Regarding the "need it SRUed to SRU shim", pretty sure that means you need it updated on pepo too.  Since the signed binary in shim-signed is coming from pepo, not from your machine.
<infinity> Or is shim special?
<infinity> Oh, shim is special because it's signed by MS, not us.  Derp.
<infinity> I keep trying to foget that fact and, apparently, succeeding.
<stgraber> yeah, the sbsigntool issue was when taking a signed binary, detaching the signature and re-attaching the signature to another binary as is done during shim-signed's build to validate MS signed our binary and not something else.
<stgraber> current sbsigntool would give us a resulting binary that'd be slightly different (extra padding) and would fail the check.
<infinity> Right, go be AFK better.
<infinity> fo0bar: Does this mean you're at the other end of the emergency number?
<fo0bar> infinity: it's whoever's on call for the weekend.  so yes, for this weekend
<infinity> fo0bar: Shiny.  We need buildd-mangler restarted on alpaca.
<infinity> fo0bar: That would be buildd-manager on alphecca, if you don't speak fluent infinity. :P
<fo0bar> infinity: ... we have so many naming schemes, I took at face value that "alpaca" was a valid hostname
<fo0bar> and was updating sshebang to try to find it
<infinity> fo0bar: Hahaha.  Sorry about that. :)
<fo0bar> infinity: buildd-manager was hard hung.  killed, starting now
<fo0bar> I haven't handled it in a long time, but it appears to be going through the right motions.  it's doing ppa-resets now
<infinity> It seems to be doing some Stuff and Things, yes.
<infinity> Hard to say how happy it is until it's reaped a bunch of these builds.
<fo0bar> infinity: cool.  I'll be around; lool was just unfortunate enough to call while I was in the shower.  ping me if it doesn't look good
<lool> fo0bar: thanks for restarting
<lool> fo0bar: hope you still managed to finish the shower  :-)
<stgraber> i386 and amd64 look good now
<infinity> Yeah, it's all clearing up.
<lool> I see android build was somehow recancelled and is running from start again, that's fine
<infinity> lool: That's a new version.
<stgraber> my initial android build got marked superseded, the second one is building now
<lool> infinity: oh right, it hadn't even started building
#ubuntu-release 2014-09-01
<shadeslayer_> is there a way for me to download older ISO's?
<shadeslayer_> older as in, a older version of a daily live ISO
<ogra_> shadeslayer_, look at cdimage.ubuntu.com ... thats all we have
<shadeslayer_> roger
<ogra_> they get cleared up after a few days though
<ogra_> so you wont be able to go back very far
<shadeslayer_> yeah
<shadeslayer_> I wanted a ISO from the 27th
<shadeslayer_> maybe Riddell has it on his PC
 * shadeslayer_ wanted to figure out why ubiquity-dm does not login with SDDM
<shadeslayer_> hm, maybe I can just upload a package to the PPA and spin a ISO
<mlankhorst> can I get a ack for https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1364003 ?
<ubot2`> Ubuntu bug 1364003 in mesa "[FFE] mesa 10.3" [Undecided,New]
<ubot93> Launchpad bug 1364003 in mesa (Ubuntu) "[FFE] mesa 10.3" [Undecided,New]
<pfsmorigo> infinity: is there a url with 14.10 isos? beta etc
<infinity> psivaa: http://cdimage.ubuntu.com/releases/14.10/
<mlankhorst> 3;1~
<ScottK> I am inclined, based on https://release.debian.org/transitions/html/auto-libav.html , to think we ought to go ahead with libav11.  Thoughts?
<infinity> ScottK: At first glance, I'd agree, but I also haven't slept since yesterday, so I could also be very silly right now.
<ScottK> We should decide soon.
<mlankhorst> infinity: what do I need to do to get the ffe for xorg-server and mesa accepted?
<infinity> mlankhorst: Ask someone other than me, or ask me tomorrow.
<pfsmorigo> infinity: the link was for me? :) If so, there is no iso with the installer, right?
<infinity> pfsmorigo: Err, yeah, sorry, tab complete fail.
<infinity> pfsmorigo: Oh, and there are no betas for ubuntu, hence why that link is a bit empty.  Derp.
<infinity> pfsmorigo: If you're looking for other flavours, they live at cdimage/$flavour/releases/14.10
<infinity> pfsmorigo: For ubuntu, you want the daily builds, until we do final beta.
<infinity> pfsmorigo: http://cdimage.ubuntu.com/daily-live/current/
<infinity> (I'd argue you want the daily builds for other flavours too, but YMMV)
<pfsmorigo> infinity: yes, so no ppc64el daily?
<mlankhorst> ScottK: what do I need to do to get the ffe for xorg-server and mesa accepted?
<infinity> pfsmorigo: Those are server, not desktop.
<infinity> pfsmorigo: http://cdimage.ubuntu.com/ubuntu-server/daily/current/
<pfsmorigo> infinity: good, tks!
<infinity> pfsmorigo: Note that ppc64el dailies might currently install a kernel that won't boot from sapphire/opal, of you're doing bare metal testing.
<infinity> pfsmorigo: That's in the process of being fixed. :P
<pfsmorigo> infinity: ok np :)
<infinity> s/of/if/
<infinity> pfsmorigo: Should work fine in VMs, though.
<infinity> Or PowerVM/OF.
<shadeslayer_> does anyone know who I should talk to to get get the default IO scheduler changed in Ubuntu?
<shadeslayer_> like, foundation folks?
#ubuntu-release 2014-09-02
<apw> shadeslayer, changed in what, to what, and why?
<apw> shadeslayer, the default there is set by the kerenl, but changable globally via the kernel command line, and individually per spindle at runtime
<apw> shadeslayer, anyhow, you might want to stop by #ubuntu-kernel as a first step
<mlankhorst> who should I bug for xorg-server and mesa ffe's  ? https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1364003  https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1359769
<ubot2`> Ubuntu bug 1364003 in mesa "[FFE] mesa 10.3" [Undecided,New]
<ubot2`> Ubuntu bug 1359769 in xorg-server "[FFE] xorg-server 1.16" [Undecided,New]
<ubot93> Launchpad bug 1364003 in mesa (Ubuntu) "[FFE] mesa 10.3" [Undecided,New]
<ubot93> Launchpad bug 1359769 in xorg-server (Ubuntu) "[FFE] xorg-server 1.16" [Undecided,New]
<shadeslayer> apw: to CFQ, because that's whats default in linux upstream I think
<apw> shadeslayer, we did extensive testing in the last weeks, and that showed that cfq is still all over the place
<apw> shadeslayer, triggering visible latency issues on desktop for instance
<shadeslayer> apw: I can haz data?
<apw> shadeslayer, come over to #ubuntu-kernel and i'll get you with the tester
<mlankhorst> infinity: ping? mesa 10.3?
<ScottK> cjwatson_: Based on the libav11 progress in Debian ( https://release.debian.org/transitions/html/auto-libav.html ) - I think it might be reasonable to go ahead (better to be on the same release that Jessie will release with sooner than later for supportability reasons).  Since you had expressed concerns about libav, I thought I'd see what you thought?
<balloons> cjwatson_, stgraber or ?.. can someone provide a copy of the daily iso from last thursday? Any day last week works too, so long as it's not friday..
<cjwatson_> ScottK: right, I mostly had to decouple other transitions first.  was planning to go ahead with it this coming week
<cjwatson_> balloons: if it's not on cdimage.u.c, I don't have it.  No point asking me.
<ScottK> cjwatson_: OK.  I'll leave it to you then.
<balloons> cjwatson_, noted. I thought you had access to someplace it might be archived
<cjwatson> balloons: they're deleted, not archived
<cjwatson> I'm afraid the space requirements for archival are prohibitive
<balloons> indeed, it would be tough. It's just interesting because since we no longer have milestones (for ubuntu) we have no images besides today's
<cjwatson> we keep more than just a single day
<cjwatson> though only two at present for ubuntu daily-live
#ubuntu-release 2014-09-03
<bluesabre> Noskcaj ^ (also verified that rebuild fixes the issue)
<mlankhorst> infinity: ping?
<zul> Can I get an archive admin to look at python-osprofiler and python-lxc please?
<infinity> mlankhorst: Hey.
<mlankhorst> hey
<mlankhorst> can you take a look at the ffe's?
<infinity> mlankhorst: Bug number(s)?
<infinity> mlankhorst: And do they contain assurances that I'll see upstream point releases before release?
<mlankhorst> 1.16 is already released
<infinity> mlankhorst: Oh, that was in reference to Mesa.  If there's also an X FFe, give me bugs numbers, please.
<mlankhorst> bug 1364003 bug 1359769
<ubot2`> Launchpad bug 1364003 in mesa "[FFE] mesa 10.3" [Undecided,New] https://launchpad.net/bugs/1364003
<ubot2`> Launchpad bug 1359769 in xorg-server "[FFE] xorg-server 1.16" [Undecided,New] https://launchpad.net/bugs/1359769
<ubot93> bug 1364003 in mesa (Ubuntu) "[FFE] mesa 10.3" [Undecided,New] https://launchpad.net/bugs/1364003
<ubot93> bug 1359769 in xorg-server (Ubuntu) "[FFE] xorg-server 1.16" [Undecided,New] https://launchpad.net/bugs/1359769
<mlankhorst> http://lists.freedesktop.org/archives/mesa-dev/2014-August/066953.html mentions sept 12th
<infinity> Why do we have two bots?
<mlankhorst> no idea..
<apw> two bots of different versions too
<infinity> mlankhorst: Right, final release in Sept, will we see a 10.3.1 before utopic ships, though?
<infinity> mlankhorst: xorg, I think I'm fine with, iff you're doing a full transition of drivers/etc and if you've made sure the non-free drivers are up to speed.
<mlankhorst> yeah
<mlankhorst> just fglrx remaining, some free drivers will be dropped due to lack of maintenance, similar to debian
<infinity> mlankhorst: Which free drivers?  Anything people might/should care about?
<mlankhorst> no, old stuff like s3
<infinity> mlankhorst: (Trivial porting that we're being too lazy to fix, or fundamental breakage?)
<mlankhorst> really ancient pre-historic stuff
<infinity> Sometimes "unmaintained" just means "it works fine, and just needs minor API porting changes".
<infinity> I've never sorted out why "unmaintained" is such a dirty word for stable software.
<mlankhorst> in this case it means 'nobody uses it any more' ;-)
<mlankhorst> and porting it requires more than a recompile
<infinity> mlankhorst: Well, nobody uses it in the sense that there's a replacement (kms + modesetting?), or in that you believe no one should own those cards anymore, so screw 'em if they do?
<mlankhorst> in the sense that 'if debian dropped support for it, why should we keep it?'
<mlankhorst> we share the stack with them
<mlankhorst> and it's very likely those drivers have been broken
<mlankhorst> I'm not sure anyone tested since xorg 1.13 (which removed XAA, breaking a lot of them)
<infinity> Fair enough.  If Debian gets enough bugs to fix and reintroduce them, are you prepared to follow suit?
<mlankhorst> sure
<mlankhorst> I'd just syncpackage from debian then
<infinity> But yeah, if they're old enough that it seems unlikely people would pair those cards with the CPUs we support (ie: PAE-only i686 and above), we're probably safer than Debian in this regard.
<mlankhorst> I've thrown my s3 card out long ago, probably with my cyrix :P
<infinity> I assume this is just older S3 cards, not whatever silicon VIA is still pumping out from the same IP?
<infinity> Or whoever owns them now.
<infinity> Oh, they seem to have spun off independently again.
<infinity> They just don't seem to want to die.
<mlankhorst> yeah the really old ones
<mlankhorst> newer one has -sis or something
<infinity> mlankhorst: Alright.  +1 on the xorg thing, then, once the drivers are already and you've tested a fake transition in a PPA.
<stgraber> I know some servers were still shipping with some of those crazy old chips, though you don't really care about running X on those anyway ;)
<stgraber> we laos had a bunch of older s3 and via on thin clients, but those were VIA CPUs that don't do PAE so they can't boot our current kernel anyway (and are stuck on 12.04)
<mlankhorst> not sure why you would run a non-lts kernel on them anyway
<infinity> mlankhorst: Also, what does "Build fixes to support a gallium megablob" mean for us?
<infinity> mlankhorst: Was that something we were hackishly doing as a shared library before, and has that now become easier or harder?
<mlankhorst> infinity: we use upstream's attempt
<mlankhorst> they have their own megablob now for gallium
<mlankhorst> which is smaller than mine
<infinity> mlankhorst: Alright, that sounds reasonable then.
<infinity> mlankhorst: So, really, just give me a non-fabricated assurance that 10.3.1 is happening before utopic release, cause I don't trust mesa .0 releases (this may change, but not this week...) and you've got your FFe.
<infinity> mlankhorst: Or a commitment to watch commits and backport .1-targetted patches to .0 with some fervor.  Obviously better if the work load isn't entirely on you, though.
<mlankhorst> ok
<mlankhorst> yeah I had a small build regression with -rc2, but it was easy to find and revert :-)
<mlankhorst> failed on parallel -j8 build/install
<mlankhorst> infinity: if .0 is broken I'll make sure it gets fixed before final release, but I think we should get it sooner rather than later this cycle.
<mlankhorst> since I was asked to refresh to mir too, and flip to llvm 3.5 which broke on 10.2 before (although that release doesn't officially support 3.5)
<infinity> mlankhorst: Oh, I don't disagree that you should upload ASAP if we plan to use 10.3, my point is that I want to know we won't be shipping 10.3.0 in the final release.
<infinity> mlankhorst: Unless this is the first mesa release in history that isn't fundamentally broken on some subset of machines, which I frankly don't believe will be true without widespread testing, which I doubt upstream has ever done, hence the situation. :P
<infinity> mlankhorst: So, I'm fine us being guinea pigs, IF 10.3.1 will be out by release, or you backport like a madman from the will-become-10.3.1 branch.
<mlankhorst> yeah
<mlankhorst> I'll poke the release manager
 * ScottK predicts we break kwin again too, since the main upstream developer doesn't test against pre-releases.
<mlankhorst> I should really upgrade to trusty sometime soon. :P
<infinity> ScottK: Was that a casual FFe veto in passing, or just a note of something we'll need to watch for and potentially fix?
<ScottK> It's not a veto.
<ScottK> It's a "we should test this before we jump in"
<infinity> Kay.  I think the one big argument (ditching llvm 3.4) and medium-sized argument (probably better new hardware support) likely trumps anything else.
<infinity> But all for testing. :P
<infinity> mlankhorst: Do you have a PPA with 10.3-pre packages that one could, say, build and run KDE against?
<ScottK> Socially, it's much better for us to go to kwin upstream and give test results/report bugs before we jump and ask for feedback rather than have him find out with the KDE bugzilla exploads.
<infinity> ScottK: Indeed.  Though, I'd also argue it's better for upstreams who rely heavily on other projects to test against their trunks instead of panicking on release day too. ;)
<ScottK> Well sure, but the version of KDE we're releasing with is already post-release, so it's a bit late for that.
<infinity> Fair point.
<ScottK> If we updated mesa in process, rather than late, via FFe, we'd be fine.
<mlankhorst> infinity: not sure if I have one right now, building is general fine though
<mlankhorst> lets see if I uploaded it to x-staging yet
<mlankhorst> Nope, forgot to push the git trees. I'll upload it to x-staging tomorrow.
<lool> excuses for ubuntu-system-settings say it's held up waiting for the ubuntu-system-settings-online-accounts to run, but for some reason they aren't running https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-ubuntu-system-settings-online-accounts/lastBuild/?
<lool> I see other recent autopkgtests runs: https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-unity-scope-click/lastBuild/?
#ubuntu-release 2014-09-04
<mlankhorst> ScottK: I've uploaded mesa 10.2~rc1 to x-staging
<Mirv> we'd need qml-module-qt-labs-settings from qtdeclarative-opensource-src promoted to main to get https://launchpad.net/ubuntu/utopic/+source/ubuntu-ui-toolkit/1.1.1227+14.10.20140904-0ubuntu1 building
<Mirv> sil2100: ^
<Mirv> apparently ppc64el doesn't have that check or something
<sil2100> Now this is interesting how this got here
<mlankhorst> ScottK: erm I mean 10.3~rc1 :-)
<LocutusOfBorg1> sil2100, lucene has been accepted :)
<LocutusOfBorg1> please remove it from mentors!
<sil2100> LocutusOfBorg1: yessir! Doing it now ;p
 * sil2100 was delaying it and delaying
<sil2100> LocutusOfBorg1: done!
<sil2100> LocutusOfBorg1: sorry it took so long ;/
<LocutusOfBorg1> thanks :D
<LocutusOfBorg1> btw where do you plan to maintain it?
<LocutusOfBorg1> "You cannot upload to this branch. Members of Ubuntu Unity PS integration team can upload to this branch.
<LocutusOfBorg1> I cant push on bzr
<ScottK> mlankhorst: can you take the kde-workspace package and upload a rebuild of it to the same PPA?  If so, I'll call for testers once it's built.
<mlankhorst> you don't need to rebuild kde-workspace, abi is unchanged
<mlankhorst> ScottK: I've copied mesa to https://launchpad.net/~ubuntu-x-swat/+archive/ubuntu/x-staging/+packages
<mlankhorst> should be easier to use it without having to upgrade xorg-server
<ScottK> Thanks.
<mlankhorst> why do you want kde-workspace there btw?
<ScottK> I thought it had to be rebuilt against the new mesa, so nevermind.
<mlankhorst> ok
<jamespage> any archive admins around who could review zul's upload of python-osprofiler - this is required for cinder and glance b3 milestones which are due out in the next 24 hr
<sil2100> Is there anyone here that could promote an universe package to main? We would need qml-module-qt-labs-settings in main (it's in universe) - should be good as its source is anyway in main
<sil2100> It's required by ubuntu-ui-toolkit
<sil2100> And basically blocking the release of that
<cjwatson> sil2100: done
<sil2100> cjwatson: \o/ thanks :)
<cyphermox_> could someone please reject gnome-bluetooth  3.8.2.1-0ubuntu4.1  from trusty proposed; it's failed verification and I'd like to upload another SRU (and fix this one)
<zul> can someone reject openstack-granite please
<ScottK> cyphermox_: You can just go ahead and upload.
<cyphermox_> ScottK: alright
<ScottK> You need to use a new revision anyway.
<cyphermox_> hmm, true
<infinity> zul: Reject from where?
<zul> infinity,  source new
<infinity> zul: Done.
<zul> infinity: thanks
<infinity> zul: Are these two osprofiler uploads identical, or did you actually change it 2 minutes apart? :P
<zul> infinity: the newer one has the FFE bug number in the changelog
<infinity> Ahh, so it does.
<tedg> Hello, I have an FFe request that I'd like to get someone to comment on. bug 1363255
<ubot2`> Launchpad bug 1363255 in ubuntu "[FFe] Rotation lock indicator" [Undecided,New] https://launchpad.net/bugs/1363255
<ubot93> bug 1363255 in Ubuntu "[FFe] Rotation lock indicator" [Undecided,New] https://launchpad.net/bugs/1363255
<tedg> Hmm, fighting ubots!
<tedg> ubot93, help ubot2`
<bdmurray> slangasek: could you review https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/email-from-changes-file/+merge/233424?
<slangasek> bdmurray: merged
<bdmurray> slangasek: thanks
<cjwatson> [5~/wg 24
<cjwatson> sigh
<cjwatson> one of these days I will get into the habit of inserting esc 1 into that sequence as lag defence
#ubuntu-release 2014-09-05
<tedg> slangasek, by chance around to look at bug 1363255
<ubot2`> Launchpad bug 1363255 in ubuntu "[FFe] Rotation lock indicator" [Undecided,New] https://launchpad.net/bugs/1363255
<ubot93> bug 1363255 in Ubuntu "[FFe] Rotation lock indicator" [Undecided,New] https://launchpad.net/bugs/1363255
<slangasek> tedg: followed up
<zul> Can I get an ok for python-tooz and python-pymemcache (#1366000) and (#1365998)? They are sync requests from debian and needed for openstack
<cjwatson> zul: done.  accepted python-pymemcache, please close the bug once it's in
<zul> cjwatson: thanks
<cjwatson> zul: and you can go ahead and sync python-tooz too - it'll just dep-wait
<zul> cjwatson: ack
<tedg> slangasek, sweet, thanks!
<zul> cjwatson: can you accept python-tooz as well?
<cjwatson> done
<zul> thanks
<arges> cjwatson: hey i need some help. i accidentally copied 'linux-*lts-utopic' into trusty
<arges> linux-lts-utopic / linux-meta-lts-utopic / linux-signed-lts-utopic
<arges> infinity: ^^^
<cjwatson> where was it meant to go?
<arges> cjwatson: it wasn't meant to be copied to proposed at all
<cjwatson> well, just remove it again, remove-package -s trusty-proposed
<cjwatson> just note that you won't be able to copy in the same version later, since it has builds
<arges> cjwatson: so do I have to wait until it hits trusty-proposed? rmadison doesn't seem to see it (I think its technically a new package)
<arges> cjwatson: that should be OK, since by the time Utopic releases we'll have a much newer version anyway
<cjwatson> you shouldn't have to wait, no
<cjwatson> rmadison doesn't see it because the publication records are still Pending
<cjwatson> i.e. the publisher hasn't run yet
<arges> cjwatson: ok looks like remove-package is removing it : )
<cjwatson> not because it's new - in that case it would be in the queue
<cjwatson> ok, cool
<arges> cjwatson: thanks for the help. next time I'll wait until after morning coffee to run that command
<cjwatson> heh
 * ogra_ wonders why his android-tools takes so eternally long to migrate to the archive
<cjwatson> ogra_: it's dep-wait
<cjwatson>  Missing build dependencies: libxcrypt-dev
<ogra_> cjwatson, yeah, i see that ...
<ogra_> i wonder where the x comes from there
<cjwatson> it was in the previous upload too
<ogra_> yeah
<ogra_> why did it pass then
<cjwatson> because there is a libxcrypt-dev, it's just in universe
 * ogra_ just notices -lcrypt definitely doesnt need an extra build dep
<ogra_> what was i thinking there
<cjwatson> right, it's in libc6-dev
 * ogra_ drops and re-uploads
<cjwatson> and there's no libcrypt-dev package anyway
<cjwatson> so the previous one built because silos ignore the ogre model
<ogra_> i think was was just to tired and did apt-cache search crypt and a dumb copy/paste ...
<ogra_> ah
<ogra_> k
#ubuntu-release 2014-09-06
<siretart> cjwatson: thanks a lot for the swift libav11 transition!
<cjwatson> thanks for preparing it
<cjwatson> yeah, seems to have gone pretty smoothly with the exception of jitsi being independently busted
#ubuntu-release 2014-09-07
 * cjwatson does a mass give-back on ppc64el to see how much will now build after that autoconf change
<cjwatson> (current stats from qa/ftbfs/, for the record: 275 failed, 322 dep-wait)
#ubuntu-release 2015-08-31
<Logan> doko: eek
<coreycb> hello, can someone on the release team please take a look at the following FFEs:  bug 1488094 and bug 1489096?  this will help unblock most of the openstack packages.
<ubot93> bug 1488094 in glance (Ubuntu) "[FFE] glance liberty-2 release" [Undecided,New] https://launchpad.net/bugs/1488094
<ubot93> bug 1489096 in python-troveclient (Ubuntu) "[FFE] Please sync python-troveclient (1:1.2.0-4) from Debian (experimental)" [Undecided,New] https://launchpad.net/bugs/1489096
<teward> can an archive admin take a look at and handle this removal request? https://bugs.launchpad.net/ubuntu/+source/electrum/+bug/1481033
<ubot93> Launchpad bug 1481033 in electrum (Ubuntu) "Please remove electrum from the archive" [Undecided,New]
<teward> been almost a month since filed
<infinity> teward: Looking.
<teward> infinity: thank you
<infinity> Oh look, yet another bitcoin thing.
<teward> infinity: yeppers.
<teward> i hate having to say things should be removed, but...
<teward> (it should be treated as an independent entity from bitcoin source package though)
<infinity> teward: Removing it from wily won't do much for <= vivid, do we care?
<infinity> And should we care?
<teward> infinity: i've had it on my radar to "null" the package
<teward> should we care?  I think so.
 * infinity nods.
<teward> is it on my radar to propose an SRU package? yes.
<teward> i'm a little overloaded with other things on my to do list of higher priority
<teward> (for private development projects, or nginx ppas)
<infinity> Alright, cool.  There should be prior art there in the form of other packages we've replaced with null packages with NEWS.Debian and debconf notes.
<infinity> Other bitcoinish stuff, I suspect. :/
<teward> i'm going to look at the nulled bitcoin source and look there
<teward> and perhaps use that as a base.
<teward> infinity: in the interim can we get it removed in wily?
<infinity> teward: Yup.  On it.
<teward> i know Debian's bitcoin people were poking @ the latest code but no new package updates're there
<teward> so... :P
<infinity> teward: I'll get it done after this call.  Multitasking is hard.
<teward> OK thanks
<Logan> infinity: I feel like there should be an archive queue, a la sponsoring queue
<Logan> there's a lot of stuff that hasn't been handled
<teward> infinity: FYI: I updated the bug with the details that older versions should probably be nulled out like bitcoin was but i haven't prepped an SRU debdiff for that yet
<teward> but that it's on my radar.
<teward> no rush :)
<infinity> Logan: There's a queue, it's called stuff we're subscribed to, but we don't check it nearly as religiously as we should.
<infinity> Logan: I'm working on getting a couple more people on the team, then we might get to go back to have "AA days" where we each eat 2h/wk on just doing AA stuff.
<Logan> I'd love to be on the team, but I'm guessing I'd have to apply to core dev first
<infinity> teward: Cool, thanks.
<infinity> Logan: Yes, I'm also going to put a proposal to the TB that AA, release, and SRU have official policies around core-devness, thanks for the reminder. :P
<Logan> ha, no problem
<infinity> Logan: (Well, the technical wording would be that no one should be given queue permissions for a series/set they don't have upload permissions to, but for AA/SRU/release, that would be core-dev)
<infinity> Since queue is a backdoor to upload.
<Logan> but you could trust people not to use the backdoor maliciously ;P
<infinity> Logan: Up to now, yes, we've trusted, but trust is a poor replacement for security.
<Logan> fair enough
<infinity> (See the US cheque clearing system)
<Logan> so there are archive admins who are not core devs?
<infinity> Logan: No.  There's one member of -release that isn't, but she's stepping down, allowing me to make this proposal without it looking like I'm firing anyone.
<Logan> oh I see
<ScottK> infinity: Does that mean you'll fix the back door through the CI train too?
<infinity> ScottK: Is that still not enforced by the train properly?  I thought sil2100 and robru were meant to sort that. :/
<infinity> ScottK: If it's still an issue, it really shouldn't be, so yes, we need to fix that.
<robru> infinity: which backdoor?
<ScottK> Last I heard (and I haven't since I exited the DMB) it was still an on your honor check with a dev if there are packaging changes thing.
<robru> ScottK: devs don't publish silos though, only core devs & me.
<ScottK> robru: Do they have the technical capability to?
<robru> ScottK: no, the publish job has an ACL saying only core devs, plus "trainguards" (me & sil)
<infinity> robru: The part where you publish silos without having upload permissions is still a problem, mind you.  Unless the people uploading to the silos had upload permissions for the bits.
<robru> infinity: yes, that's on the list of things to fix. there's a lot to do
<infinity> robru: We need to figure out a way to make sure the system is enforcing "someone with upload rights was involved in this".
<robru> infinity: yes I'll be getting to that soon.
<infinity> robru: Kay, cool.
<robru> infinity: slangasek already even wrote some example code, I just need to get to it.
<robru> ScottK: so to clarify, publishing is on *my* honor, not "any random dev's honor"
<infinity> Logan: Anyhow, get yourself core-devy, you're a good candidate.  Then if you don't manage to burn yourself out over the next 6-12 months, talk to me about teams with elevated permissions. :)
<ScottK> robru: OK.  That's at least better, but unless you're an Ubuntu dev with upload rights for the affected packages, it still breaks the archive trust model (don't take that personally).
<Laney> Is it https://launchpad.net/~ci-train-ppa-service/+members#active this team?
<robru> ScottK: I understand, it is on the list of things to fix. just swamepd.
<robru> Laney: no it's the poorly named ubuntu-unity team which has nothing to do with unity development. it's exclusively used by the train
<Logan> infinity: cheers
<infinity> robru: For the record, while I'm fine with you working toward core-dev yourself, the solution to the train problem shouldn't be "make robru core-dev so he has permissions to upload any junk", since every package you upload from the train is sponsored by you, and you're taking responsibility for.
<infinity> robru: The solution needs to be that we can identify someone else with upload permissions has signed off on the upload and is taking responsibility for it.
<robru> infinity: right, was that not clear? we have a bug and some example code for how to make the train respect who has correct upload rights. it's just a matter of doing it.
<infinity> robru: Bonus points if that person then becomes the "uploader" in .changes and the changelog sig, so we can stop the madness of attributing thousands of uploads to a bot I can't yell at. :P
<infinity> robru: Okay, cool.  Wasn't sure (so, I guess not clear), but glad we're on the same page.
<infinity> robru: This is as much about responsibility as it is about permissions, it's been amazingly frustrating to try to track down people who "own" these uploads and can be held accountable.
<robru> infinity: even though the changelog entry ends with " -- CI Train Bot", the names in square brackets above that should correspond to the people to yell at.
<slangasek> robru: the names in square brackets are the people who prepared the merge, not the people who signed off on it
<robru> hm
<infinity> ^
<slangasek> making people the uploader would require some (probably otherwise useful) changes to the process, since it means signoff would need to happen before build
<slangasek> that could be good, or it could be a problematic bottleneck
<infinity> In a VCS sense, view this as the difference between 20 commits and a signed tag.
<robru> slangasek: that sounds like a bottleneck to me. people build & rebuild constantly, you can't get a sponsor for every single build.
<infinity> I care about the committers, but the tagged version is the responsibility of the person who signed off on the whole thing.
<slangasek> robru: it would at most be needed for each build that changes the packaging and thus requires sign-off
<infinity> And, indeed, if we get to "build from git", that's exactly how it would look.  A bunch of committers in the changelog, but the "uploader" is the one who signed the packaging tag.
<robru> slangasek: but that's chicken and egg then. the train can't know whether there are packaging changes until after it makes the build and sees the diff.
<slangasek> and there could be an optional bypass of the sign-off if you know you're only doing a test build
<infinity> For what it's worth, I oppose completely the premise that only packaging changes need a sponsor.
<infinity> Upload permissions are for the package, not the debian directory.
<robru> that makes sense
<slangasek> robru: I don't see how that's chicken and egg.  It tries to build the source package; it sees that there are packaging changes; it kicks it into "needs signoff" state; someone signs off and then it does it again and actually submits it for building
<infinity> If an upload of upstream-only changes breaks the world, I still need accountability.
<slangasek> infinity: this was the compromise that was approved by the DMB when the train went live
<robru> slangasek: the logic for diffing and finding packaging changes happens after the build is uploaded & completed in the PPA.
<infinity> slangasek: I'm inclined to say the DMB was wrong.  Just sayin'.  Rules aren't set in stone. :P
<robru> infinity: I'm pretty sure debian rules are set in stone ;-)
<slangasek> robru: sure.  that could be changed though if we thought it was better to do it the other way
<infinity> Is it so onerous to ask people to get upload rights?
<slangasek> no, debian/rules are set in make
<infinity> robru: Debian has a living constitution and a living policy, so no.
<slangasek> infinity: how many people has the DMB approved upload rights for this year?
<infinity> slangasek: Not sure, but that's more interesting compared to people who have applied.
<slangasek> and what should the uploader approval process look like for an upstream dev who is a domain expert and doesn't want to take responsibility for the packaging anyway?
<infinity> But, really, if upstream changes aren't part of the package, could I have punted that glibc bug that caused endless debate back and said "talk to upstream about it, it wasn't my debian directory that broke it"?
<infinity> Accountability is important.
<doko> could somebody hint gdal mia vtk6 gtkglextmm ipe grass cgal qscintilla2 bullet graphicsmagick  (or tell me what is still missing)?
<slangasek> doko: seen the autohinter output?  there are a bunch of other packages that gdal wants to go in at the same time as, including octave
<robru> infinity: rest assured that within a couple weeks the train will be honoring proper upload permissions. I'm just finishing up some other stuff before I start on that.
<infinity> robru: Sure, but we seem unclear again on what that means. :P
<infinity> robru: If it's only honoring them for packaging changes, I still think it's hilariously broken, DMB discussion notwithstanding.
<slangasek> robru: "honoring proper upload permissions" hopefully means "recording in bileto who signed off on packaging" :)
<robru> infinity: what part isn't clear? the train will only allow uploads from proper uploaders.
<robru> slangasek: that's within the realm of possibility.
<infinity> robru: Err, but the conversation we just had implied that's not what you're doing.  So, I'm confused.
<slangasek> robru: infinity is trying to argue that the agreed rules should be overturned.  but this isn't really the proper forum for that, and not something you should worry about as implementor of the existing rules
<infinity> slangasek: Honestly, I'm trying to clear up what he MEANS by "honoring upload permissions".
<slangasek> infinity: ah
<infinity> Because if there's a mechanical check on publishing that the upload was approved by someone with upload rights, that's correct (IMO), but not what the current rules state (only for packaging diffs).
<infinity> So...
<doko> slangasek, yes, and qscintilla2 too
<infinity> Which is it? :P
<robru> infinity: https://bugs.launchpad.net/cupstream2distro/+bug/1459186 if you're interested
<ubot93> Launchpad bug 1459186 in CI Train [cu2d] "Implementing proper permission checks during silo publish" [High,In progress]
<slangasek> infinity: packages that are Canonical upstream, exist in the archive, and have no packaging changes don't need an ubuntu-dev to sign off.  Packages that don't have Canonical upstream, or that have packaging changes, must be signed off by an ubuntu-dev with upload rights for the package in question
<robru> infinity: feel free to comment on that bug with a detailed explanation of The Right Way to do things so i won't forget it when I get around to it (actually it looks like sil started on that already, hmmm)
<infinity> slangasek: So, there's a whitelist somewhere for these Canonical upstream packages?
<infinity> Or is that all honor system too?
<infinity> Cause they should probably just be in a packageset that trainguards have upload rights to, to codify the DMB position.
<infinity> And then this can all be proper archive permissions checks.
<robru> infinity: there isn't an explicit whitelist, but the train only supports MPs for canonical upstream packages, so the difference would be "if there's an MP, we're upstream, if it's a manual source in the PPA, we're not"
<slangasek> infinity: in practice it's possible the whitelist is of the form "anything that has branches in the form that the train is capable of figuring out an MP for"
<robru> yeah, that
 * infinity -> lunch.
<robru> mmmhm, yes
<infinity> robru: I'll try to summarize my views later.  No, I'm not implying one grumpy old man can overturn the current state of affairs, and the current state is probably "fine" if enforced in a more mechanically sane and verifiable way.
<infinity> (Though, I'd prefer the exception not exist at all, but whatever)
<robru> infinity: yes, I agree, the current system is suboptimal and needs improvements. it's on the list of things I'll fix soon
<Logan> ruby-rspec needs ruby-threadorder to be MIRed
<Logan> the new version of ruby-rspec will fix a bunch of Ruby FTBFSes
<Logan> ruby-thread-order*
<cjwatson> robru: oh FWIW putting a real person in the changelog trailer line rather than "CI Train Bot" has been on my list to push for for a while - IMO that should be the silo owner or something like that, because doing that would mean that LP can notify a real person of failures
<cjwatson> robru: and hence fix the "cjwatson has to grep logs" problem
<cjwatson> (hope I'm not barging in on an existing agreement that implies something contrary, but if so, I wouldn't mind checking over it to ensure that it implies the correct thing for LP mail notifications)
<robru> cjwatson: oh yeah, silo owner would be a more reasonable thing to put there. Silo sponsor would be weird and cause problems implementing. Can you file a bug against lp:cupstream2distro for that?
<cjwatson> robru: sure
<robru> Thanks
<cjwatson> "silo sponsor" certainly wouldn't need to be in a changelog - that would be more analogous to syncpackage -s
<cjwatson> but IIRC you already pass a sponsor to the copy request
<cjwatson> maybe, sometimes
<cjwatson> robru: I discussed this with Didier something like a year and a half ago and then forgot to file it anywhere, apparently - https://bugs.launchpad.net/cupstream2distro/+bug/1490729
<ubot93> Launchpad bug 1490729 in CI Train [cu2d] "changelog trailer should name the silo owner rather than "CI Train Bot"" [Undecided,New]
<robru> cjwatson: yeah it makes sense. just never occurred to me.
<cjwatson> infinity: fwiw this doesn't conflict with what you were saying - the changelog trailer line clearly doesn't have to be somebody with upload permissions, because Debian
<cjwatson> (or anything else we might copy from)
<robru> cjwatson: when launchpad is notifying about upload failures, does it go by the changelog entry? or by the signer? because it'll still be signed by the train key even if I change the name in the changelog.
<cjwatson> robru: both
<cjwatson> it should be signed by the train key, that's correct
<robru> cjwatson: ah ok
<infinity> cjwatson: No, the changelog line doesn't have to correspond, it's just also pointless if it's a bot.
<cjwatson> robru: in fact, the rules are a bit complicated, but this proposed change isn't going to make it harder to find somebody to notify, at least - and if it's more conceptually correct, it's easier for us to find a consistent way to improve things if it is still broken
<robru> cjwatson: yeah good point.
<robru> cjwatson: infinity: I can probably get to both of those this week once I finish up some stuff I have going right now
<cjwatson> (I believe we may not additionally notify the changed-by person about failures when the target archive is a PPA, but we do when the target is the primary archive, whether it's an upload or a copy)
<cjwatson> but failures in copies to the primary archive are the main case that's currently opaque
<cjwatson> oh, we only add changed-by if it's a person with component upload permissions, hm
<cjwatson> anyway, as I say, we could at least *conceptually* improve it given that change :)  more information good
<infinity> cjwatson: Yeah, the mail rules are intentionally restrictive to avoid backscatter to DDs (and others) who aren't also ubuntu-dev.
<cjwatson> right, and also to avoid "person copies my Ubuntu package to a PPA, I shouldn't get spammed about it"
<infinity> cjwatson: But I want the information purely for better tracking/blame, what we do with it at the infrastructure level is a whole different story.
<cjwatson> the fact that we only mail component uploaders is curious - I wonder if I'm the first person to notice that
<infinity> (And I also contend that "this package is owned by a bot" is completely useless information to anyone)
<ScottK> infinity: It does always seem a little odd to me to get LP mail about stuff that's autosynced from Debian.
<infinity> The only place the bot should be evident is the signing key for the sponsored upload.
<cjwatson> ScottK: I think this is because the changed-by in that case is attached to your LP account and you have component upload privileges to Ubuntu
<cjwatson> so it's evident to people who work in both distributions, but at least not to Debian developers in general
<ScottK> That's good.  If it were general, then I'm sure there'd be lots of complaining.
<cjwatson> hm, I just rewrote a chunk of this code, I wonder if that means I'm now on the hook for all its deficiencies :-)
<infinity> cjwatson: I believe that's how it works, yes.
<infinity> cjwatson: I'm not sure at what percentage of rewrite you get to stop cursing cprov and blame yourself entirely, mind you.
<cjwatson> infinity: for once, Celso is just about the only Soyuz hacker *not* implicated in this code
<cjwatson> ah, but I think that's because of a rearrangement by Steve in 2011 - anyway, ancient history
<infinity> cjwatson: Blaming him is fun regardless. ;)
<teward> infinity: care to do a very-brief glance-over on the SRU for Trusty to 'nullify' the electrum package?
<infinity> teward: I'm a bit busy at the moment, but perhaps if you give me a nudge tomorrow.  Or ask someone else. ;)
<infinity> teward: Hrm.  Does the part where Debian has 2.4 in unstable change this conversation at all?
<infinity> teward: I expected that if it was universally considered a Bad Idea to distribute it, they would have removed it.
<teward> infinity: mmm
<teward> 2.4.4 is updated but iirc they didn't close the ticket yet.  At the time of the bug here for removal, the issue was they were giving pushback
<teward> they also need to make sure there's no MITM vector, which is why sbeattie is subbed to the removal bug (I poked -hardened first for general ida of whether there's a security risk with the older versions)
<teward> I'd be OK with a sync into Wily, and the removal/blacklist bug going away
<teward> on the provision that the older versions go away for being insecure and not reverse compatible or even usable with the latest forks in the chains
<infinity> teward: Didn't close which "ticket"?
<infinity> teward: The Debian bug was closed with the upload.
<teward> infinity: i meant the Debian bug
<teward> infinity: it didn't ping me and i'm subbed
<teward> oversight by email probably
<teward> infinity: as i said, i'm OK with it getting into something after Wily, because FF is currently in place, unless someone wants to override that.
<teward> but the current version in Wily, and older, are all 'bad' and actually will cause problems when being used
<teward> (because of the issues detailed in the bug on LP)
<infinity> teward: Anyhow, if this is going to be the same as other bitcoin stuff, where distributing it in stable releases is just wrong because people *need* the latest version, we should remove.
<infinity> teward: But I don't know enough about this software to say that.
<teward> infinity: ack, i'll have to poke at it more, but I *do* know that  items detailed in point 3 on LP are still valid:
<infinity> teward: IOW, don't evaluate wily on "is 2.4 good enough today" but "will 2.4 be good enough in 9 months (or 5 years, if that's what's in 16.04).
<teward> 1: bitcoin soft-fork on July 4, 2015, and only newer software versions don't know about it.
<teward> 2: wallet recovery seeds don't work on the older versions (when existing on newer)
<teward> infinity: i think it's a similar concern
<teward> infinity: because those 'forks' in the blockchain affect everything
<teward> but we may want to sit on it a week while i poke the electrum people
<infinity> teward: If this sort of thing is standard operating procedure and breaking old versions of clients is expected, I think remove/blacklist is probably still the right answer.
<infinity> teward: "The bitcoin network keeps becoming incompatible with old clients" is effectively why we removed all the rest.
<infinity> teward: So, yeah, if this is tightly coupled to the same issues, let's remove.
<teward> infinity: i'm double checking that understanding, but if it's a similar issue, then i still say removal is better.  I know in #electrum i've seen reqs for help with old versions and people say "Use the newer one because it works" (but with more technical reasons)
<teward> infinity: at best guess, that applies, the "Bitcoin network and Electrum software continue to change, making older versions incompatible." argument is still valid especially with points already in place on the bug I filed
<teward> I still support removal...
<infinity> teward: Yeah.  Let's just remove, then.  I was just curious, since your bug specifically mentioned "updating to 2.x is hard", but 2.x is indeed in Debian.
<teward> infinity: their argument at the time was 'hard'
<infinity> teward: If the real answer is "updating doesn't help because the updated one will also break in a year", then what version we carry today doesn't matter, and we should just remove.
<teward> I agree with the second one there more
<teward> brb power needed
<teward> and back
<teward> infinity: saw the remove, thanks.  I'll poke the debdiff up shortly for review, no rush.  Wily+ was my current concern
#ubuntu-release 2015-09-01
<jamespage> apologies - I'd not realized that the sync I just did to resolve some FTBFS in openstack packages also included a new python3 binary package
<jamespage> if that could be accepted much appreciated
<cjwatson> already done
<jamespage> cjwatson, ta
#ubuntu-release 2015-09-02
<michi> robru: ping
<robru> michi: pong
<michi> With the new requests page, how to I abandon (completely remove) a silo?
<robru> michi: is the silo assigned?
<michi> Yes, silo 10
<robru> michi: click 'Merge & Clean' and then check ONLY_FREE_SILO
<michi> OK, cool, thanks. Might be good to update the doc page. It still talks about the âAbandonâ link
<robru> michi: where? I went through and updated the docs recently
<michi> Under âAbandon a landingâ on the LandingProcess page
<robru> michi: lol, the answer to your question was right there
<michi> âThe CI Train REquests page has alink on each landing request called âAbandonâ"
<michi> I donât think that link still exists?
<michi> Or am I blind?
<robru> michi: reload the page or something? you must be seeing something cached since last week
<michi> Ah
<michi> Yes, thatâs whatâs happened.
<michi> Sorry for the noise.
<robru> michi: no worries
<michi__> robru: Not sure what to do with this one: https://ci-train.ubuntu.com/job/prepare-silo/6018/console
<robru> michi__: your request contains a branch, you need a merge.
<michi__> Aargh, wrong URL.
<michi__> Any chance of getting a more informative error message there?
<robru> michi__: also please file a bug against lp:cupstream2distro asking to make that error more understandable and assign it to me
<michi__> :)
<robru> michi__: can do, just have other priorities.
<michi__> About to create the bug, NP!
<robru> infinity: cjwatson: anybody around? I need help testing some train changes you'll like
<robru> "CI Airline will be ready ~July 2014"
<robru> kek
<infinity> robru: Not really, no.  Heading to bed.
<infinity> robru: Also, that was hours ago, so I assume you're not around either. :P
<robru> infinity: just watching tv. I sent an email with details
<Mirv> infinity: still around? there'd be new binary packages at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-024/+sourcepub/5314531/+listing-archive-extra - indicator-transfer-download-manager, libindicator-transfer-dev, libindicator-transfer0
<Mirv> probably not as heading to bed 40mins ago. any other archive admin around?
<Mirv> hmm, maybe RAOF or pitti could be awake?
<RAOF>  I could be.
<RAOF> But new binary packages aren't my thing; no AA hat here.
<Mirv> RAOF: oh, would there be a better list to use than https://launchpad.net/~ubuntu-archive/+members ?
<pitti> what about these?
<Mirv> pitti: train bypasses binary NEW queue, so we need preNEW review
<RAOF> Mirv: Sadly, no. I'm there because I need a subset of those powers for SRU work.
<Mirv> RAOF: ah, ok, that explains it
<pitti> it could really do with a symbols file
<pitti> Mirv: looks okay otherwise, but please add .symbols for tracking API
<Mirv> I'll file bugs about all comments and if they're a blocker, set it as critical priority
<Mirv> pitti: ok. a blocker or not blocker?
<pitti> not a blocker
<Mirv> ok.
<Mirv> thank you, I filed a bug about it for the next release.
<pitti> cheers
<doko> currently not accepting new binary library packages ...
<cjwatson> doko: Why not?  I would normally wave through mosquitto and sdformat
<doko> cjwatson, ok, only one binNMU needed
<slangasek> arges: will fix lsvpd and reupload today, thanks.  fwiw procedurally, I recommend that when an SRU is rejected for cosmetic/mechanical issues that the SRU team member fix/reupload/accept
<infinity> I certainly do that sometimes, depends on if I'm using the queue as a teaching tool, as well.
<infinity> And, clearly, slangasek needs tutoring on packaging.
<arges> slangasek: good point, I wasn't sure there needed to still be separation between uploading and accepting, but in the future for minor stuff like this I'll fix it
<infinity> arges: IMO, if the issue you find is minor and, in your mind, 100% unlikely to be contested by the uploader, just fix and reupload.
<infinity> arges: Things like version numbers or bug ref typos fit that, for instance.
<infinity> arges: If it's a question of "I don't like how you fixed this bug", then a round-trip is saner.
<arges> infinity: Makes sense. and obviously the teaching bit is moot for steve
<cyphermox> arges: ^ if you feel like reviewing more SRUs. :)
<arges> cyphermox: i'll catch that later... gotta head out for a bit
<cyphermox> sure
<cyphermox> I'm about to head out to get lunch, too
<slangasek> infinity, arges: 'sright, I'm a manager and therefore unteachable ;P
<infinity> slangasek: See, I was avoiding making that joke.
<robru> cjwatson: do you know if there's been any changes to launchpad/the archive lately that would affect the way the train publishes NEW packages? I had thought there was some long standing issue that the train somehow bypassed the NEW queue but there's been a couple silos I've seen recently that went into NEW and I have no idea why. I sure haven't changed
<robru> anything train-side regarding publishing NEW packages.
<coreycb> arges, could I get you or another sru team member to review some openstack-related uploads when you get a chance?
<arges> coreycb: i can handle it
<coreycb> arges, great, thanks.  for trusty: software-properties, cinder, python-keystoneclient.  and for vivid: python-keystoneclient
<bregma> is there a formal process for getting my NEW package (currently in the queue) accepted or is it now a matter a matter of patiently waiting for someone with the right rights to get around to it?
<infinity> bregma: The latter.  Which package?
<infinity> bregma: Ahh, libertine?
<bregma> infinity, yes, sorry, I'm a slow typer
<bregma> we're really targeting the vivid overlay for the phone, but want to avoid breaking anything on upgrades later
<infinity> bregma: I'm unconvinced that backdooring the NEW process with the overlay is a sane workflow, but...
<bregma> it's not in the overlay until it's in WIly first, and we'll be doing dual landings
<bregma> that's why I want it in Wily
<infinity> Okay, if it's not allowed in the overlay until it's in wily, then I retract my backdoor comment.
<infinity> bregma: I'm grabbing it to see if it looks like an easy review.  If it is, I'll knock it out, if it's not it might wait a bit, as I'm pretty busy right now.
<bregma> sure, thanks
<infinity> bregma: You missed a chance for silly naming here.  I'm disappointed.
<infinity> Assuming you're upstream, I'm still downloading. :P
<bregma> believe me, we discussed silly names
<infinity> Heh.
<bregma> there was a ted involved
<infinity> See, you could either be -lertine, thus libertine.so, or go the iberty route with -libertine and ibertine.so
<infinity> liblibertine is so boring. ;)
<bregma> hmmm, -latrine ....  I need a new project
<infinity> bregma: PasswordHelper{.h,.cpp} are missing copyright headers, FWIW.
<infinity> (Not a blocker, since the project as a whole has an obvious license, but you might want to fix upstream)
<infinity> bregma: Also not a blocker, but line-wrapping in Description fields doesn't work the way you think it does.
<infinity> bregma: The first line (up to the first \n) is the short description, the rest is the long description, so where you've wrapped a too-long short, you've dumped the end of it into the beginning of the long.
 * bregma kicks wrap-and-sort to see if it's still working
<infinity> bregma: Even weirder, liblibertine1 starts the long description with a blank line. :)
<infinity> Ditto for a few of them, actually.
<infinity> That might get filtered out, but it's still silly regardless.
<infinity> bregma: The only one that makes sense is libertine.  Short on 1 line, no blank '.' starting the long.
<bregma> yeah, that's a bad habit I picked up years ago, adding the blank line
<infinity> bregma: You probably want to fix the rest.  The wrapping issue in tools could be sorted by just s/command-line //
<infinity> bregma: My only other complaint would be that /usr/bin/dbus-session-bridge is a super generic and namespace-pollutey name for a binary not shipped by dbus.
<infinity> bregma: I might ask you to fix that one (or argue why it's a good idea) before you go writing other things that depend on that path.
<bregma> well, it's a replacement for the D-Bus stuff inside our little container so the actual name doesn't matter (just the socket passed at runtime)
<infinity> bregma: Right, so libertine-session-bridge or something might be more appropriate.
<bregma> we can certainly change it, but wit the next upload if possible
<infinity> bregma: I'd prefer to see it changed before I accept (or at least see a commit upstream), since I know how well everyone (me included) delivers on IOUs once the ACCEPT happens. :P
<bregma> heh
<infinity> bregma: Fix the descriptions in VCS and, more importantly, that generic binary path, and I'm happy.
<infinity> bregma: Point me at both, or just shove a new upload in the silo, and we're good to go.
<infinity> (The new upload would be nicer)
<bregma> we'll want to go the new upload route
<bregma> OK, thanks for the review
<arges> coreycb: software-properties, the .5 upload you have, does that fix the issues with the current .4 version in proposed?
<arges> coreycb: bug 1381050 is verification failed
<ubot93> bug 1381050 in software-properties (Ubuntu) ""Import Key File" fails when the path of the file has special characters" [Medium,In progress] https://launchpad.net/bugs/1381050
<coreycb> arges, ah, yes I think I based off of that
<infinity> bregma: Other than the nitpicks, though, nice clean packaging, so yay for that.
<infinity> bregma: And kudos on the insanely simple public interface for the library.  I was questioning the -dev having a single .h until I read it.
<arges> coreycb: perhaps we can pick up that change too since it looks like there was a MP with a fix for that
<coreycb> arges, ok do I just need to include the bug # for that in the most recent changelog?
<infinity> bregma: I'll reject that so no one else is tempted to re-review.  As soon as a fresh upload hits the silo, ping me directly, and I'll check the diff and give you a thumbs-up.
<bregma> infinity, thanks
<coreycb> arges, ah... verification-failed on that one..
<coreycb> bdmurray, I have a trusty sru for software-properties that I based off the version in -proposed.  do you know what the state of the -proposed version is?
<bdmurray> coreycb: http://people.canonical.com/~ubuntu-archive/pending-sru.html one of the bugs failed to verify
<coreycb> bdmurray, how would you recommend I go about my sru?
<bdmurray> slangasek: coreycb wants to SRU software-properties for Trusty and the previous SRU has a v-done and v-failed bug. I'd suggest just dropping the v-failed change and adding his fix. Does that seem reasonable?
<infinity> bdmurray: Either fix the v-failed bug, or back it out, yeah.
<bdmurray> infinity: okay, thanks
<bdmurray> coreycb: are you in a hurry? I'm looking at the v-failed bug but not making much progress
<coreycb> bdmurray, yeah I think we should probably get it in.  it enables the cloud archive shortcut for add-apt-repository for liberty.
<coreycb> we need to start cranking on testing, and the charms need it
<bdmurray> coreycb: okay the parts to remove are the changelog entry for fix importing keys and readd the lines removed from "def add_key(" https://launchpadlibrarian.net/210981282/software-properties_0.92.37.3_0.92.37.4.diff.gz
<coreycb> bdmurray, ok, so just to verify.  I assume I need to revert 0.92.37.4 changes as part of my 0.92.37.5 version.  sound right?
<coreycb> rather than just upload a new 0.92.37.4
<bdmurray> coreycb: yes, I'd be happy to review it (or sponsor it).
<coreycb> bdmurray, thanks
<coreycb> bdmurray, would you mind rejecting software-properties from the trusty review queue?
<coreycb> bdmurray, thanks.  I uploaded a new one if you could review when you get a chance.
<infinity> bregma: Diff in the PPA looks good to me.  Except for this (which I don't need another upload for, obviously):
<infinity> + and other software interacting wit hthe Libertine container, such as scopes
<infinity> bregma: ^-- Yay, typo. ;)
<bregma> I feel I should boycott the word "the" it is my greatest nemesis
<infinity> Hahaha.
<infinity> bregma: Add "with" to the list.  Really, I think it's the spacebar that hates you.
<bregma> grep -sr 'teh' *
<infinity> bregma: Anyhow, publish away when the train is done choo-chooing or whatever.
<infinity> bregma: I'll re-review in the queueue for sanity, but all looks good to me.
<bregma> infinity, yes, it needs a wizzard to ack it before it uploads to the queue
<infinity> Wow, how did my queue get an extra ue?
<infinity> I guess my fingers got excited.
<infinity> queueueueue!
<bregma> teh queueueue
<infinity> robru: bregma's silo is ready (27)
<robru> infinity: yeah I tried publishing it but apparently launchpadlib's checkUpload is horribly broken in python3, can you manually copy the package from the PPA for now? I'm working on a workaround
<infinity> Erm, yeah, can do.
<robru> infinity: thanks
<infinity> robru: Done (for ubuntu/wily, I'll leave the overlay bit to you to sort out after I let this through NEW)
<robru> infinity: oh right, thanks
<infinity> bregma: ^--- Accepted, thanks for indulging my nitpicking.
<bregma> pleased to receive constructive criticism
<cjwatson> robru: Copies bypass binary NEW due to an LP bug, but not source NEW.  This hasn't changed in quite some time.
<slangasek> bdmurray: yes, seems reasonable to me to back out the change to bug #1381050 for software-properties
<ubot93> bug 1381050 in software-properties (Ubuntu) ""Import Key File" fails when the path of the file has special characters" [Medium,In progress] https://launchpad.net/bugs/1381050
<robru> cjwatson: ah, I forgot binary NEW is different than source NEW
<cjwatson> This is https://bugs.launchpad.net/launchpad/+bug/993120, for which I once had half a fix but it's been overtaken by events and needs to be reworked
<ubot93> Launchpad bug 993120 in Launchpad itself "Copy from PPA with binaries evades NEW and puts new packages in their default component" [High,In progress]
<robru> cjwatson: you may enjoy: https://launchpad.net/~ci-train-staging-area/+archive/ubuntu/landing-000/+sourcepub/5366429/+listing-archive-extra
<robru> (scroll down a bit)
#ubuntu-release 2015-09-03
<cjwatson> robru: ah, excellent, thanks :)
<robru> cjwatson: you're welcome! I'm surprised this feature wasn't in there since the beginning...
<cjwatson> I see you're listed as "package_creator" on the API for that source_package_publishing_history now too
<cjwatson> Which is probably Soyuz-speak for "changed-by"
<cjwatson> We'll still have to work out how to cause that to send you at least some notifications, but it's a step
<bluesabre> release team, can somebody review https://bugs.launchpad.net/ubuntu/+source/blueman/+bug/1482626 and potentially ack? :)
<ubot93> Launchpad bug 1482626 in blueman (Ubuntu) "FFe: Please merge blueman 2.0-1 (universe) from Debian stretch (main)" [Wishlist,Confirmed]
<flexiondotorg> didrocks, I've been out and about this morning. Just saw your sponsoring. Many thanks!
<didrocks> flexiondotorg: yw! thanks for your work on Mate :)
<flexiondotorg> :-)
<flexiondotorg> bluesabre, I +1 your mention of https://bugs.launchpad.net/ubuntu/+source/blueman/+bug/1482626
<ubot93> Launchpad bug 1482626 in blueman (Ubuntu) "FFe: Please merge blueman 2.0-1 (universe) from Debian stretch (main)" [Wishlist,Confirmed]
<coreycb> bdmurray, Hi, we have some openstack SRUs in the queue for trusty and vivid.  any chance you could take a look?
<bdmurray> coreycb: yes, I'll have a look in a couple of hours
<coreycb> bdmurray, thanks
<stgraber> rbasak: wow, it's got to be the first time I do a NEW review of packages and lintian doesn't thing anything interesting to complain about, even when run in pedantic mode :)
<stgraber> so at least that part's good, now I need to look at what those packages actually are and see if they do anything wrong from a licensing point of view
<flexiondotorg> infinity, Could you update ubuntu-mate-meta for me please?
<flexiondotorg> infinity, I'm expecting librsvg-common and several fcitx packages to be added.
<bdmurray> coreycb: Do you know if bug 1368545 is fixed in wily?
<ubot93> bug 1368545 in python-keystoneclient (Ubuntu Vivid) "Value Type of http_connect_timeout is Wrong" [Undecided,In progress] https://launchpad.net/bugs/1368545
<coreycb> bdmurray, no, and they don't plan to because new development has moved to python-openstackclient
<bdmurray> coreycb: oh, comment 13 led me to believe it needed fixing in wily
<coreycb> bdmurray, sorry that wasn't a complete answer.  it is fixed in wily in debian which we're in sync with.  but not upstream.
<bdmurray> coreycb: "it is fixed in wily in debian"?
<coreycb> bdmurray, it's fixed in wily in ubuntu but not upstream
<bdmurray> coreycb: okay, got it
<bdmurray> coreycb: the branch I linked to in the bug shows it still being a BoolOpt though
<coreycb> bdmurray, ugh, we're behind it didn't get uploaded.  sorry about that.
<coreycb> bdmurray, it's in the branch but not uploaded.  maybe hold off on that then until we get it uploaded and sync'd?
<bdmurray> coreycb: okay, I'll let that sit
<coreycb> bdmurray, ok
<bdmurray> coreycb: what specific uploads did you want me to look at?
<coreycb> bdmurray, other than that one we have software-properties and cinder in trusty
<bdmurray> coreycb: okay
<bdmurray> utlemming: do you want to wait for the existing cloud-init SRU to complete?
<utlemming> bdmurray: no, we'd like to superceed it. The upload fixes a regression that affects performance on Azure. (i.e. users will start to get NTFS formated ephemeral devices)
<bdmurray> utlemming: got it
<stgraber> ^ that was a mistake, rejected
#ubuntu-release 2015-09-04
<stgraber> The new binary in question is lxd-utils which contains fuidshift. It's a tool we've had upstream forever but that lxd itself doesn't use (it just uses the same internal functions). I added it as it's useful on its own for users dealing with user namespaces and because our newly introduced autopkgtest tests it too.
<arges> Can I have release team review bug 1492271? Need FFE ack for new package in universe. Thanks
<ubot93> bug 1492271 in Ubuntu "[FFE] Sync new package numad 0.5+20150602-2 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/1492271
<arges> n/m need to fix some arch build issues first. Also I'm not entirely sure i need an FFE for this... tried reading the wiki a few times and wasn't completely sure.
<infinity> arges: It's a new package, doesn't need an FFe unless you intend to also get it installed by default.
<infinity> arges: What build issues, though?  Seems to build on Debian on all arches we care about.
<arges> infinity: I'm going to re-check for user error on this end, I think my armhf cross-schroot is messed up
<arges> infinity: but once it looks good, i"ll syncpackage then
<infinity> arges: Well, it might not cross, but that's hardly a blocker. :P
<infinity> arges: It seems to build natively fine in Debian.
<arges> Yea, most likely its a cross issue.
<cyphermox> so, I was looking at component-mismatches, noticed a large tree because of libtype-tiny-perl
<cyphermox> I can't seem to find what wants libtype-tiny-perl to be in main though, it doesn't appear to have reverse-(build-)depends in main, nor be in seeds.
<cyphermox> rmadison also shows it's not in main in other releases, so I'm not sure what to think of it :)
<cjwatson> It's listed for movement to universe in component-mismatches but not in component-mismatches-proposed, which may be a clue
<cyphermox> ah, I was only looking at -proposed
<cyphermox> d'oh.
<cyphermox> cjwatson: thanks.
<cjwatson> libpod-readme-perl is in main and has a newer version in -proposed which newly B-Ds on libtype-tiny-perl (and a pile of other stuff)
<cyphermox> cjwatson, shouldn't that be attached in the svg then?
<cjwatson> cyphermox: No, because libtype-tiny-perl has already been promoted
<cyphermox> oh, I see
<cjwatson> The svg only shows the graph of stuff that needs to be moved to main/restricted, plus the immediate parents of nodes in that graph that are already in main/restricted
<cjwatson> IYSWIM
<cyphermox> I couldn't find what wanted libtype-tiny-perl because I wasn't including -proposed when searching for things anyway.
#ubuntu-release 2015-09-06
<bluesabre> release team, care to take a look at https://bugs.launchpad.net/ubuntu/+source/blueman/+bug/1482626 ? If possible, xubuntu and ubuntu-mate are interested in shipping this release. If we get an ack, I can handle the upload :)
<ubot93> Launchpad bug 1482626 in blueman (Ubuntu) "FFe: Please merge blueman 2.0-1 (universe) from Debian stretch (main)" [Wishlist,Confirmed]
#ubuntu-release 2016-09-05
<ginggs> doko, i sync'd a new new eigen3 and now shogun has built (without changes). Should I  just untag LP: #1619629  now?
<ubot5> Launchpad bug 1619629 in shogun (Ubuntu) "shogun fails to build (with new eigen), demoting to proposed" [Undecided,New] https://launchpad.net/bugs/1619629
<LocutusOfBorg> doko, hi your opinion on pcl transition?
<LocutusOfBorg> the failures are fixed now
 * LocutusOfBorg won't do anything
<doko> ginggs: bug closed
<doko> LocutusOfBorg: no opinion
<ginggs> doko: danke
 * LocutusOfBorg tries a transition
 * LocutusOfBorg in his ppa
<LocutusOfBorg> oh, one single ros-rdep
<LocutusOfBorg> since ros- is in sync, I would sync it too
<LocutusOfBorg> the only rdep is the metapackage
<LocutusOfBorg> and no real rdeps, not even needing a rebuild
<LocutusOfBorg> why pbuilder is in main? /cc mapreri
<LocutusOfBorg> doko, syncpackage -f tango? opinion? the only change is   * (Build-)depend on libzmq5-dev. but it makes no sense to me
<doko> LocutusOfBorg: if it builds, fine
<LocutusOfBorg> it builds, libzmq-dev is provided by libzmq5-dev
<LocutusOfBorg> syncd
<Trevinho> infinity: hey
<Trevinho> infinity: do you have some time to review the SRU queued for unity7 in xenial?
<Trevinho> infinity: the silo is https://requests.ci-train.ubuntu.com/#/ticket/1843
<xnox> Laney, can src package in main build a binary package that is published in multiverse?
<xnox> (because said binary package is free, but useless without a multiverse depends)
<Laney> xnox: I don't see why not, but you should ask a real archive admin if you want an authoratative answer :-)
<xnox> right.
<Trevinho> infinity: oh sorry.. I didn't notice you where off....
<xnox> Laney, gnupg2 is a valid candidate, now it needs hints I'm guessing.... or all the other packages to be valid too.
<xnox> libmail-gnupg-perl/0.22-1ubuntu2 gnupg2/2.1.15-1ubuntu2 python-gnupg/0.3.8-3ubuntu2
<sergiusens> infinity hey, mind allowing snapcraft into xenial-proposed?
<ogra_> sergiusens, vacation ...
<sergiusens> ogra_ oh, slangasek then ^
<sergiusens> :-)
<ogra_> :)
<ogra_> i think he is out too ... til tomorrow
<ogra_> sergiusens, apw might be your last hope :)
<davmor2> sergiusens: US holiday they are all off ;)
<ogra_> davmor2, oh, did the US take over canada ?
 * ogra_ missed the news :P
<davmor2> ogra_: hahaha
<ogra_> :)
<Laney> xnox: I will activate ze hint-tester
<Laney> xnox: nein, some things are still broken
<Laney> xnox: https://paste.debian.net/810893/
<Laney> I think at least libgnupg-interface-perl has to become a candidate
<Laney> and also gnupg : Breaks: libgnupg-perl (<= 0.19-1) but 0.19-1 is to be installed <- libgnupg-perl just plain becomes uninstallable
<Laney> arriero's problem is gpgv : Breaks: python-debian (< 0.1.29) but 0.1.27ubuntu2 is to be installed
<Laney> which maybe is just that click wants hinting
<Laney> I think that is all
#ubuntu-release 2016-09-06
<xnox> Laney, thank you for analysis. I did sync python-debian over. not sure where that is stuck. I shall check libgnupg-perl too now.
<Laney> xnox: welcome
<xnox> Laney, libgnupg-perl_0.19-1ubuntu1 and parcimonie_0.10.2-1ubuntu1 uploaded should make things dandy....
<Laney> fingers crossed
<xnox> however parcimonie fails.... yet local build passes, and local adt tests pass too =(
<xnox> ok libgnupg-perl was stuck without entropy.... uploaded one with pre-generated key
<LocutusOfBorg> pitti, cjwatson I found some sort of bug in buildd
<LocutusOfBorg> " INFO: pkgstripfiles: waiting for lock (glusterfs-dbg) ..."
<LocutusOfBorg> this happens on all the architectures
<LocutusOfBorg> race condition? can I retry them=
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/glusterfs/3.8.3-1ubuntu1/+build/10714418
<cjwatson> doubtless a package bug of some kind; cancel it and you might see more
<doko_> cjwatson, LocutusOfBorg: that's the parallelized pkgstripfiles code. if you find there a bug ... please tell me. I see this from time to time too
<LocutusOfBorg> doko_, my wonder too
<LocutusOfBorg> some race condition in the lock?
<LocutusOfBorg> anyway, retrying
<LocutusOfBorg> but only ppc64el
<LocutusOfBorg> still failing doko_
<LocutusOfBorg> trying a local build now
<cjwatson> you'll need to ensure to have pkgbinarymangler installed and possibly to do some extra gubbins to enable it (I forget)
<LocutusOfBorg> but how can it be a package bug?
<cjwatson> dunno
<cjwatson> v unlikely to be a buildd bug though :)  could be a pkgbinarymangler bug
<LocutusOfBorg> sure, I call "buildd" whatever is not packaging :)
<LocutusOfBorg> confirming, the build works in pbuilder without pkgbinarymangler
<doko_>    dh_builddeb -a
<doko_> Found files in /usr/lib/python2.7/site-packages (must be in dist-packages for python2.7).
<doko_> debian/glusterfs-common/usr/lib/python2.7/site-packages
<doko_> debian/glusterfs-common/usr/lib/python2.7/site-packages/gluster
<doko_> debian/glusterfs-common/usr/lib/python2.7/site-packages/gluster/__init__.py
<doko_> debian/glusterfs-common/usr/lib/python2.7/site-packages/gluster/glupy
<doko_> debian/glusterfs-common/usr/lib/python2.7/site-packages/gluster/glupy/__init__.py
<doko_> dh_builddeb.pkgbinarymangler: dpkg-deb --build debian/glusterfs-common .. returned exit code 1
<doko_> LocutusOfBorg, cjwatson: ^^^  looks like dpkg-deb fails with an error, and then the pkgbinarymangle script doesn't cope with build errors and goes into an endless loop
<LocutusOfBorg> doko_, why debian is good?
<doko_> because debian doesn't have pkgbinarymangler?
<LocutusOfBorg> no doko_ that part is fail of dpkg-deb, right?
<doko_> I haven't checked
<LocutusOfBorg> anyway, thanks, I'll fix it
<cjwatson> LocutusOfBorg: No, that check is implemented in pkgsanitychecks which is part of pkgbinarymangler.  It's hooked into dpkg-deb there.
<LocutusOfBorg> doko_, can you explain this?
<LocutusOfBorg> python -c 'from distutils.sysconfig import get_python_lib; print(get_python_lib(prefix="${exec_prefix}"))'
<LocutusOfBorg> ${exec_prefix}/lib/python2.7/site-packages
<LocutusOfBorg> python -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())"
<LocutusOfBorg>  /usr/lib/python2.7/dist-packages
<LocutusOfBorg> shouldn't it return dist-packages in both cases?
<doko_> no, this is kind of a hack to force manually run setup.py's to override system packages. not perfect, but it keeps our python lib clean. why do you need to set an explicit prefix?
<LocutusOfBorg> this get_python_lib is used to understand where to installl the python binding
<LocutusOfBorg> and site-packages is returned instead of dist-packages
<doko_> use dh-python, and it moves things around
<LocutusOfBorg> now it calls dh_python2 lots of times
<LocutusOfBorg> should I just do a mv debian/foo-dev/usr/lib/python2.7/site-packages/* debian/foo-bar/usr/lib/python2.7/dist-packages/ or whatever?
<doko_> why do you call dh_python2 explicitly with site-packages?
<LocutusOfBorg> I don't even know what it does mean, I'm not the maintainer, just tried to fix the package in an Ubuntu merge :)
<LocutusOfBorg> what is the fix? remove the dh_python2=
<LocutusOfBorg> ?
<bdmurray> slangasek: I'd like to release update-manager & xorg-server-lts-xenial now.  Its a day early so I'm looking for an ack.
<slangasek> bdmurray: ack
<infinity> cyphermox: Is that binutils/grub hack upstream?
<infinity> cyphermox: Also, grub2-signed, please.
<infinity> cyphermox: Ahh, the binutils hack is *from* upstream.  That works.
<cyphermox> infinity: yes
<cyphermox> grub2-signed coming up (sorry about that)
#ubuntu-release 2016-09-07
<flocculant> stgraber: tracker doesn't appear to be remembering reported bugs at the 'Bugs to look for' list
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/nvidia-cuda-toolkit/7.5.18-3
<LocutusOfBorg> "diff from 7.5.18-2 to 7.5.18-3 (pending)"
<LocutusOfBorg> mmm crashed?
<sergiusens> arges hi there, mind letting snapcraft into xenial-updates?
<arges> sergiusens: sure i'll take a look
<sergiusens> thanks arges
<xnox> infinity, Laney, slangasek - could you please hint the gnupg2 transition over?
<xnox> i believe the following should land together: gnupg2 php-crypt-gpg libmail-gnupg-perl python-gnupg libgnupg-interface-perl
<xnox> and maybe britney will tell me what else i've missed, or everything will be fine.
<xnox> ahhh. it's not considered, one sec.
<slangasek> right, if it were considered, the autohinter should already tell you what you're missing
<xnox> libgnupg-interface-perl is not considered due to parcimonie, re-running that. it should pass as i did fix parcimonie to pass with both old & new.
<xnox> ok will refresh on http://autopkgtest.ubuntu.com/running#pkg-parcimonie later
<xnox> slangasek, it's not trying them together. and i don't see an autohint generated for these
<xnox> gnupg2 python-gnupg libgnupg-interface-perl php-crypt-gpg libmail-gnupg-perl
 * xnox stares at "info: broken arch run for mips64el"
<slangasek> heh
#ubuntu-release 2016-09-08
<slangasek> xnox: how does updating python-gnupg make ubuntu-touch uninstallable?
<mwhudson> can someone do the thing to run the runc autopkgtests with the docker from yakkety-proposed?
<slangasek> mwhudson: that's triggered automatically by the upload, so that seems to have happened and it looks like everything migrated happily
<mwhudson> slangasek: yeah, it seems to have migrated now
<xnox> slangasek, that mystery is unexplained to me either. as far as i could tell it doesn't / shouldn't.
<Laney> xnox: can you give me a sample hint?
<Laney> I'll poke it into the hint tester
<xnox> Laney, gnupg2 -> gnupg appears to have landed.
<xnox> looking at how to remove src:gnupg with pitti on #-devel now.
<Laney> ok
<Laney> what made it go in?
<pitti> oh, wasn't it expected to land yet?
<pitti> I did a few test retries against -proposed yesterday morning, but otherwise didn't touch it
<Laney> well I wasn't aware that it was ready
<pitti> xnox: http://paste.ubuntu.com/23149214/
<xnox> Laney, my commit mails for hints say that slangasek added hint to try things together, they migrated, and then removed the hint.
<Laney> ok...
<Laney> that's good I guess
<xnox> gnupg-curl shouldn't be installed anymore....
<pitti> xnox: it's not, it got removed along with the gnupg 1 source (no rdepends)
<xnox> yeah
<mwhudson> can someone reject juju-mongodb3.2 3.2.9-0ubuntu1~14.04 from trusty pls?
<apw> mwhudson, done
<LocutusOfBorg> anybody please accept ros-geometric-shapes? one single rdep, I would like to finish the ros-packages work
<cjwatson> LocutusOfBorg: .
<LocutusOfBorg> ta
<slangasek> xnox: yeah, I never saw if my hint had any effect, I didn't expect it to; but I saw that it made it in
<Laney> slangasek: do you know about the hint tester?
<jbicha> mwhudson: I did the docker.io autopkgtest retests for you earlier, I just had to add &trigger=docker.io/1.12.1-0ubuntu7 to the end of the URL the retry button gives
<slangasek> Laney: yes, but I've forgotten /where/ it is :)
<Laney> slangasek: code/b2/britney.py -c code/b2/britney.conf.ubuntu.yakkety.notest --series yakkety --hint-tester
<Laney> :)
<Laney> never leave hints-ubuntu without it
<LocutusOfBorg> britney, you slow?
<Laney> LocutusOfBorg: do you know about log/?
 * Laney the educator
<Laney> looks like it got broken
 * LocutusOfBorg goes to irclogs.ubuntu.com, has no always connected irc account
<Laney> LocutusOfBorg: I mean http://people.canonical.com/~ubuntu-archive/proposed-migration/log/
<LocutusOfBorg> nope
<Laney> TYL
 * Laney wonders what broke
<LocutusOfBorg> thanks
<LocutusOfBorg> I use update_output, but I forgot about log
<LocutusOfBorg> so.... nobody noticed that before me?
<slangasek> Laney: ah, that wasn't the hint tester I was thinking of, but thanks!
<Laney> you're welcome!
 * Laney has stopped britney for a minute to investigate
<Laney> LocutusOfBorg: first I heard
<Laney> bahaha
<LocutusOfBorg> I waited some hours, and then I decided to ask, because the update_output.txt was from hours ago
<Laney> next time you'll know how to consult the log :P
<LocutusOfBorg> yep :D
<pitti> just pushed the britney1-ubuntu fix for this: http://bazaar.launchpad.net/~ubuntu-release/britney/britney1-ubuntu/revision/296
<LocutusOfBorg> yep, I saw on -devel :P
<Laney> Not the first mid air collision
<LocutusOfBorg> why it broke only today is something I don't understand
<LocutusOfBorg> I thought this chan was the right one for reporting
<Laney> It is
<pitti> LocutusOfBorg: I changed the password this morning
<pitti> it's completely understood
<pitti> sorry for mid-air collision again, what a coincidence
<pitti> hah, http://people.canonical.com/~ubuntu-archive/component-mismatches.txt updaed now
<pitti> http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt too
<pitti> and britney running
<LocutusOfBorg> go britney go!
<LocutusOfBorg> I want my ~10 packages migrate :)
<LocutusOfBorg>   File "/home/ubuntu-archive/proposed-migration/code/b2/britney.py", line 3250, in <module>
<LocutusOfBorg> :/
<pitti> what -- now it failed on some socket.gaierror: [Errno -2] Name or service not known
<LocutusOfBorg> pitti, you sure that creds.password has the right value?
<pitti> ok, fixed harder, just dropped the / from the password -- easier to fix quoting issues everywhere (this also  affects the CI train)
<LocutusOfBorg> lol
<LocutusOfBorg> I smell sqli issues
<pitti> urllib.parse.urlsplit() indeed stumbles over this (thanks Laney)
<pitti> LocutusOfBorg: well, it's not like users can set the password from outside :)
<LocutusOfBorg> the library is in the archive, so even if you aren't affected by this, somebody else might be
<LocutusOfBorg> I mean, that urllib is widely used
 * LocutusOfBorg refresh the log
<Laney> it's not a bug in the library
<pitti> yeah, just failure to quote it
<Laney> I would have just joined the password and path bits :P
<LocutusOfBorg> go go go
<pitti> ok, now it's *really* running
<LocutusOfBorg> yes, and a bunch of stuff is already successful
<LocutusOfBorg> BTW I retried already insighttolkit4, but it goes ENOSPACE on ppc64el
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/insighttoolkit4/4.10.0-dfsg1-3ubuntu1/+build/10712957
<LocutusOfBorg> any thing I can do to ask an increase of the partition space?
<LocutusOfBorg> the -2 didn't fail, I suspect gcc increased some bits of size
<mwhudson> apw: thanks
<mwhudson> jbicha: thanks
<mwhudson> slangasek, infinity: is the special treatment for docker SRUs documented anywhere yet?
<slangasek> mwhudson: mmm, I assume not.  Could you start a wiki page analagous to https://wiki.ubuntu.com/SnapdUpdates with your understanding of the requirements, and infinity and I (and the rest of the SRU team) can iterate on it from there?
<mwhudson> slangasek: ok
<mwhudson> slangasek: can you subscribe ~snappy-dev to https://bugs.launchpad.net/ubuntu/+source/golang-github-coreos-pkg please?
<mwhudson> (for the MIR)
<slangasek> mwhudson: this is you bullying an admin into having them sign up, right? ;)
<mwhudson> slangasek: yes
<mwhudson> slangasek: i expect a grand total of 0 bug mails in the next 10 years
<slangasek> mwhudson: ok.  while I happen to be an admin of that team in LP, I don't think I should commit them to owning this package - that should be JamieBennett or mvo
<mwhudson> ok
<mwhudson> how did snapd get in main without this happening already, btw?
<mwhudson> oh probably because it doesn't use the bit of golang-github-coreos-go-systemd that imports this package
#ubuntu-release 2016-09-09
<Kamilion> Where's a good place for me to get information on why xen 4.7 isn't around in yakkity or xenial yet?
<Kamilion> does the cloud team have their own channel somewhere?
<wxl> Kamilion: have you tried server?
<nacc> Kamilion: fwiw, debian only has 4.6.0 still
<Kamilion> nacc: thanks; I hadn't checked debian either; I was kind of expecting something bubbling around july since it was released in june, but it's september now and I havn't heard a peep from anyone over 4.7
<Kamilion> I don't expect anything now that the freezes are looming either
<Kamilion> Alright, so I'll just figure on 4.8 showing up before 17.04 does and trickling down to LTS after april.
<Kamilion> My bet is the livepatching stuff is scaring distro support off till someone can wrap their head around it
<wxl> oooh
<wxl> livepatching?
<Kamilion> their release schedule changed as well; 4.8 is supposed to be due in december
<mwhudson> slangasek, infinity: https://wiki.ubuntu.com/DockerUpdates
<jbicha> archive admins, please accept the new libtotem-plparser-videosite binary into universe to close MIR bug 1547395
<ubot5> bug 1547395 in luasocket (Ubuntu) "MIR: new dependencies for libquvi-scripts / libquvi" [Undecided,Incomplete] https://launchpad.net/bugs/1547395
<dholbach> hiya
<dholbach> I'm patch piloting right now and noticed bug 1618904 - can somebody take a look?
<ubot5> bug 1618904 in underscore (Ubuntu) "[Ffe] Sync underscore 1.8.3~dfsg-1 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1618904
<dholbach> https://bugs.launchpad.net/ubuntu/+bug/1594603 and https://bugs.launchpad.net/ubuntu/+bug/1607546 too (new derivative - looks like they were in touch with the TB about this already)
<ubot5> Ubuntu bug 1594603 in Ubuntu "[needs packaging] budgie-desktop-environment" [Wishlist,In progress]
<ubot5> Ubuntu bug 1607546 in Ubuntu "[needs packaging] budgie-welcome" [Wishlist,In progress]
<dholbach> or flavour
<dholbach> bug 1480315 too
<ubot5> bug 1480315 in Ubuntu "[needs-packaging] CloudKitty" [Wishlist,Confirmed] https://launchpad.net/bugs/1480315
<LocutusOfBorg> doko_, your opinion about forcing sync of underscore?
<LocutusOfBorg> this will fix some bugs, and make backbone migrate
<LocutusOfBorg> I did some work https://bugs.launchpad.net/ubuntu/+source/underscore/+bug/1618904
<ubot5> Ubuntu bug 1618904 in underscore (Ubuntu) "[Ffe] Sync underscore 1.8.3~dfsg-1 (main) from Debian unstable (main)" [Wishlist,New]
<jibel> stgraber, Hey, how can I add xenial/arm64 to the tracker so I can trigger image builds? through the tracker or there is something else to update?
<LocutusOfBorg> infinity, would be nice to see fpc bootstrapped in Ubuntu again :)
 * ogra_ is always surprised to see it still has users 
 * LocutusOfBorg probably ogra_ never installed hedgewars
<LocutusOfBorg> :)
<ogra_> yeah ... thats written iin pascal  ?
<LocutusOfBorg> pascal, haskell, qt, c, c++ and something more
<ogra_> geez
<LocutusOfBorg> haskell the server parts, pascal the engine, and so on
<LocutusOfBorg> qt the graphical
<ogra_> is that game a programming exercise ?
<LocutusOfBorg> lol, it is a POC about how many different languages can be put together
<LocutusOfBorg> and maintaining it is a nightmare :)
<ogra_> hah, yeah, i can imagine
<LocutusOfBorg> I don't have many issues, except for haskell :)
<ginggs> cjwatson: what LocutusOfBorg said above - IIRC you've done this before, should be straightforward now that fpc powerpc is installable from Debian packages
<cjwatson> maybe, but bootstrapping work is strictly spare-time stuff for me nowadays
<cjwatson> and I'm out this weekend
<ginggs> cjwatson: oh, well have a good weekend!
<LocutusOfBorg> have fun :)
<marco-parillo> With yesterday's 64-bit daily ISO in a VM. I get a blank screen with a black breeze cursor, but nothing happens. I can <ctrl> <alt> <F1> to get a tty, and can login with kubuntu and an empty password and then sudo poweroff, so I guess the OS loads but not Plasma. However, again using yesterday's ISO, I tried starting it in a new VM just after a cold boot of my physical HW. I guess the disk load was heavier so I got the i
<marco-parillo> Whoops. Probably better for the kubuntu-devel channel.
<kenvandine> i'm updated the ubuntu-touch seeds in the stable overlay for xenial and vivid.  Is it ok to update the yakkety seed as well?  I want to make sure that's ok during the freeze
<kenvandine> s/updated/updating/
<stgraber> jibel: I thought we already had those products, if not, you'll need to add the product. If we have it and it's just not listed, you'll need to manually add a build through the admin UI.
<jibel> stgraber, I added the product Ubuntu Touch arm64 for xenial daily, but then how do I request a build like other archs? is there additional setup to link to rebuild action in the tracker to launchpad builders?
<stgraber> jibel: sorry, I'm off today so can't really look into this for you now. There is a mapping between tracker products and image building products on the image builder (nusakan) which may need updating.
<jibel> stgraber, no problem, it can wait
<jibel> stgraber, enjoy your time off
<jbicha> please demote libtotem-pl-parser-videosite (from totel-pl-parser) to universe
<slangasek> jbicha: well, there's a report for that :) http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed
<slangasek> (processing)
<cyphermox> slangasek: could you please review ubiquity in xenial-proposed queue
<cyphermox> ?
<slangasek> cyphermox: hmm, we're only now getting bug #1606393 landed? I thought that was already fixed
<ubot5> bug 1606393 in ubiquity (Ubuntu) "default should be to disable Secure Boot when installing third-party drivers" [High,Fix released] https://launchpad.net/bugs/1606393
<cyphermox> I fixed one extra usability issue
<jbicha> I believe libquvi and libquvi-scripts should be demoted to universe too
<slangasek> jbicha: bug #1547395?
<ubot5> bug 1547395 in luasocket (Ubuntu) "MIR: new dependencies for libquvi-scripts / libquvi" [Undecided,Invalid] https://launchpad.net/bugs/1547395
<jbicha> hmm, I guess it didn't show up on mismatches because libtotem-plparser-dev > libquvi-dev
<jbicha> and libtotem-dev and librhythmbox-dev depend on libtotem-plparser-dev
<jbicha> yes
<jbicha> it should be ok to move those 3 -dev packages to universe, right?
<jbicha> or maybe libtotem-pl-parser-dev doesn't actually need to depend on libquvi-dev; do you want me to try removing that depenendency instead?
<slangasek> jbicha: if you think these deps can be sanely dropped, that seems like less work for everyone
<jbicha> quvi is not listed in totem-plparser.pc so I'm making that change now
#ubuntu-release 2016-09-10
<LocutusOfBorg> is britney on VAC?
<LocutusOfBorg> pitti, ^^ :)
<LocutusOfBorg> I remember cjwatson mentioning VAC, but not britney :)
<LocutusOfBorg> maybe the reason is http://bazaar.launchpad.net/ unreachable?
<ogra_> LocutusOfBorg, yeah, she had a cold and her voice was slightly scratchy :P
<ogra_> yeah, you are right, lookss like http://bazaar.launchpad.net/ is dead ...
<ogra_> seems it is known and being worked on ...
<ogra_> matter of being patient i think ...
<LocutusOfBorg> if it is known it is perfectly fine by me :)
<ogra_> :)
<LocutusOfBorg> hey britney you alive!
<LocutusOfBorg> :D
<ogra_> there she sings again !
-queuebot:#ubuntu-release- Unapproved: libgweather (trusty-proposed/main) [3.10.2-0ubuntu2 => 3.10.2-0ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.16 => 2.17] (no packageset)
<sergiusens> slangasek if around, mind allowing that in ^? But yakkety you say? Well our tests fail on yakkety due to the old snapd which is stuck due to the transition in proposed but our adt works fine on xenial where snapd is ahead :-)
<sergiusens> quote from the snap-core team "having issues with the late transition in yakkety to default to GnuPG 2.x"
 * jbicha wonders why Lubuntu & GNOME daily yakkety images built but didn't publish to cdimage.ubuntu.com, maybe tomorrow
<tsimonq2> huh?
 * tsimonq2 checks that
<tsimonq2> that is weird...
#ubuntu-release 2016-09-11
<slangasek> who keeps demoting the dependencies of the new licensecheck in yakkety-proposed? :)
<LocutusOfBorg> pitti, hi, if possile please run ignition-transport testsuite against proposed protobuf, thanks
-queuebot:#ubuntu-release- New binary: mahimahi [ppc64el] (yakkety-proposed/universe) [0.93-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mahimahi [armhf] (yakkety-proposed/universe) [0.93-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mahimahi [i386] (yakkety-proposed/universe) [0.93-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mahimahi [amd64] (yakkety-proposed/universe) [0.93-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mahimahi [arm64] (yakkety-proposed/universe) [0.93-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mahimahi [s390x] (yakkety-proposed/universe) [0.93-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mahimahi [powerpc] (yakkety-proposed/universe) [0.93-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted mahimahi [amd64] (yakkety-proposed) [0.93-1]
-queuebot:#ubuntu-release- New: accepted mahimahi [armhf] (yakkety-proposed) [0.93-1]
-queuebot:#ubuntu-release- New: accepted mahimahi [powerpc] (yakkety-proposed) [0.93-1]
-queuebot:#ubuntu-release- New: accepted mahimahi [s390x] (yakkety-proposed) [0.93-1]
-queuebot:#ubuntu-release- New: accepted mahimahi [arm64] (yakkety-proposed) [0.93-1]
-queuebot:#ubuntu-release- New: accepted mahimahi [ppc64el] (yakkety-proposed) [0.93-1]
-queuebot:#ubuntu-release- New: accepted mahimahi [i386] (yakkety-proposed) [0.93-1]
<flocculant> jbicha: seems that nothing is published even though built "lockfile: Sorry, giving up on "/srv/cdimage.ubuntu.com/etc/.lock-archive-sync"
-queuebot:#ubuntu-release- New binary: android-platform-build [amd64] (yakkety-proposed/universe) [1:6.0.1+r55-2] (no packageset)
-queuebot:#ubuntu-release- New binary: android-platform-build [i386] (yakkety-proposed/universe) [1:6.0.1+r55-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mia [ppc64el] (yakkety-proposed/universe) [2.4.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mia [powerpc] (yakkety-proposed/universe) [2.4.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mia [i386] (yakkety-proposed/universe) [2.4.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mia [s390x] (yakkety-proposed/universe) [2.4.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mia [armhf] (yakkety-proposed/universe) [2.4.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mia [i386] (yakkety-proposed/universe) [2.4.3-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: mia [powerpc] (yakkety-proposed/universe) [2.4.3-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: mia [s390x] (yakkety-proposed/universe) [2.4.3-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: mia [ppc64el] (yakkety-proposed/universe) [2.4.3-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: mia [amd64] (yakkety-proposed/universe) [2.4.3-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: mia [armhf] (yakkety-proposed/universe) [2.4.3-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: mia [arm64] (yakkety-proposed/universe) [2.4.3-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gnome-calendar (xenial-proposed/main) [3.20.2-0ubuntu0.1 => 3.20.3-0ubuntu0.1] (desktop-extra, ubuntu-desktop)
<wxl> jbicha, tsimonq2: regarding lubuntu and gnome daily yakkety didn't publish is because of an error with the archive sync lock, e.g. http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-gnome/yakkety/daily-live-20160911.log and http://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/yakkety/daily-20160911.log
<jbicha> wxl: thanks, that's what flocculant said too
<wxl> the error on lubuntu desktop today is a little bit different, although my guess is that the 504 time out on iso.qa.ubuntu.com (just a few minutes ago was running slow) is obscuring the issue hiding behind it http://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/yakkety/daily-live-20160911.log
<wxl> jbicha: oh yeah i guess i didn't pay attention to the last line of the lastlog derp
<wxl> jbicha: and actually, it looks like it affects all images on further inspection
<jbicha> yes, I think UG was one of the first to hit it
<jbicha> things wait until the weekend to break!
<wxl> â¦except for ubuntu-base
#ubuntu-release 2017-09-04
<doko> LocutusOfBorg, slangasek: a sync is not possible, Ubuntu has jpeg8 compatibility, Debian has jpeg6 compatibility. and libturbojpeg-dev's so was not provided becauses it's a legacy API. At least it was when turbo entered Ubuntu
-queuebot:#ubuntu-release- New binary: golang-github-go-macaron-captcha [amd64] (artful-proposed/universe) [0.0~git20170330.0.cbfb9d9-1] (no packageset)
<doko> LocutusOfBorg: and not mentioning bug reports in this upload while you are aware of these and closing manually looks like you try to hide things. not amused
<doko> LocutusOfBorg, slangasek: the the README.md in the sources, "Using libjpeg-turbo". I don't see the value providing this, and fear desaster coming when more packages start depending on turbo-dev
<doko> but good night for now, 17.10 is not a LTS
-queuebot:#ubuntu-release- New: accepted golang-github-go-macaron-captcha [amd64] (artful-proposed) [0.0~git20170330.0.cbfb9d9-1]
-queuebot:#ubuntu-release- Unapproved: gnutls26 (trusty-proposed/main) [2.12.23-12ubuntu2.9 => 2.12.23-12ubuntu2.10] (core)
<LocutusOfBorg> doko, I saw them because jbicha pinged me *after* not before of course
<LocutusOfBorg> I woudl have closed bugs in changelog, of course! and it is not my fault that Debian started using it :( do you want to help me patching dcm2niix=
<LocutusOfBorg> I would  like to at least sync the packages with a minimal delta, same package names, ok for the jpeg6/jpeg8, but the current status quo is a mess, a double mess
<LocutusOfBorg> I put it in queue 12h before noticing the bugs
<LocutusOfBorg> btw you can't avoid people doing bad symlinks on their systems to use it anyway, not providing a -dev package is not helping, but rather making people do nasty hacks :(
<LocutusOfBorg> the package uses functions such as tjDecompressHeader2, provided only by that library
<LocutusOfBorg> not really sure how can we avoid that
-queuebot:#ubuntu-release- Unapproved: virt-manager (xenial-proposed/universe) [1:1.3.2-3ubuntu1.16.04.3 => 1:1.3.2-3ubuntu1.16.04.4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virt-manager (zesty-proposed/universe) [1:1.3.2-3ubuntu4 => 1:1.3.2-3ubuntu6] (no packageset)
<cpaelzer> could one please reject the shameful mistake of version number increase in zesty-unapproved being virt-manager 1:1.3.2-3ubuntu6?
<apw> cpaelzer, looking
-queuebot:#ubuntu-release- Unapproved: rejected virt-manager [source] (zesty-proposed) [1:1.3.2-3ubuntu6]
<LocutusOfBorg> hello, the following packages have been regressed in release casync/i386 pycurl/ppc64el r-cran-curl/ppc64el xandikos/amd64/i386 and are preventing curl migration
<LocutusOfBorg> also s390x might be sad, but it is not ran yet, maybe Laney knows an ETA for having it back online
<cpaelzer> thanks apw
<Laney> It's being investigated.
-queuebot:#ubuntu-release- Unapproved: virt-manager (zesty-proposed/universe) [1:1.3.2-3ubuntu4 => 1:1.3.2-3ubuntu4.1] (no packageset)
<LocutusOfBorg> please accept the new llvm "lld" package, it is the linker, and has its new package since the default llvm in yakkety/zesty/artful
<LocutusOfBorg> just we were missing the metapackage from llvm-defaults
<apw> LocutusOfBorg, where is that i don't see anything resembling that pending anywhere
<LocutusOfBorg> it is just building
<LocutusOfBorg> ok finished now
-queuebot:#ubuntu-release- New binary: llvm-defaults [amd64] (artful-proposed/universe) [0.37~exp3] (no packageset)
<LocutusOfBorg> hopefully having a new linker might help :)
-queuebot:#ubuntu-release- New binary: llvm-defaults [arm64] (artful-proposed/universe) [0.37~exp3] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-defaults [i386] (artful-proposed/universe) [0.37~exp3] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-defaults [armhf] (artful-proposed/universe) [0.37~exp3] (no packageset)
<LocutusOfBorg> sadly it still don't work on ppc64el and s390x... but meh, at least it is now in sync with debian experimental
<sil2100> apw: hey, I have a new walinuxagent to be released, the package is not seeded and cloud-up-to-date essential - I guess I can push it to artful without a FFE, right?
<sil2100> (by cloud-up-to-date essential I mean we always need to keep it up to date)
<apw> sil2100, that one has an SRU exception for that reason doesn't it, so it seems reasonable it would something we can update yes
<sil2100> apw: yeah, SRU exception it has, but I just wanted to make sure it also counts as a FF exception for the devel series
<apw> sil2100, it seems reasonable to count it to me for all the reasons it is reasonable in stable
<sil2100> Thanks!
<LocutusOfBorg> thanks Laney for having a look!
<Laney> LocutusOfBorg: Back up
<LocutusOfBorg> thanks for the work!
<cpaelzer> hi, does an FFE like https://bugs.launchpad.net/ubuntu/+source/slof/+bug/1706248 need any further pings/mails to be reviewed or is just a lot goging on atm delaying that?
<ubot5> Ubuntu bug 1706248 in slof (Ubuntu) "[FFE] SLOF dhcp request doesn't include client architecture code 93" [Medium,Confirmed]
<flocculant> cpaelzer: thanks for finding that virt-manager issue - I've been scratching my head for a couple of weeks :)
<cpaelzer> flocculant: which one actually :-)
<cpaelzer> flocculant: I happen to hack on a few the recent days
<flocculant> bug 1714638
<ubot5> bug 1711358 in ubiquity (Ubuntu) "duplicate for #1714638 20170817 - ISO hangs on boot on qemu with splash screen enabled and qxl graphics driver" [Undecided,Confirmed] https://launchpad.net/bugs/1711358
<cpaelzer> ah yeah, well I only came from another bug report
<cpaelzer> was verifying what it is about and finally linked to the already existing issue report
<flocculant> yup - but you did more than me - you found the dup :D
-queuebot:#ubuntu-release- Unapproved: walinuxagent (trusty-proposed/main) [2.2.14-0ubuntu1~14.04.1 => 2.2.16-0ubuntu1~14.04.1] (ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: walinuxagent (zesty-proposed/main) [2.2.14-0ubuntu1~17.04.1 => 2.2.16-0ubuntu1~17.04.1] (ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: walinuxagent (xenial-proposed/main) [2.2.14-0ubuntu1~16.04.1 => 2.2.16-0ubuntu1~16.04.1] (ubuntu-cloud, ubuntu-server)
<rbalint> Laney: could you please check if LP: #1714019 needs FFe and if it does tell what is missing? slangasek can't follow up on this soon
<ubot5> Launchpad bug 1714019 in unattended-upgrades (Ubuntu) "Please merge unattended-upgrades 0.96 (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/1714019
-queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (zesty-proposed) [2.2.16-0ubuntu1~17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (xenial-proposed) [2.2.16-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (trusty-proposed) [2.2.16-0ubuntu1~14.04.1]
<apw> rbalint, do you feel that unattended-upgrades has any new features ?
<apw> rbalint, the changelog looks like all fixes perhap with the exclusion of the new --download-only
<rbalint> apw: thanks for the review
<apw> rbalint, oh and we have that fix in our ubunut8 as a backport, so ignore that
<rbalint> apw: there are no features, but there are minimal changes which are not strictly bug fixes
<apw> rbalint, there does not appear to be anything there which would be concerning from a "changing behaviour" point of view, it looks to be mostly fixes, some cleanup of formatting but meh
<rbalint> apw: there is also default behavior change (longer timeout, minimal steps by default) but those are needed to fix real life issues IMO
<apw> if theey are being changed to fix bugs without the change, then that is a bug-fix none the less
<rbalint> apw: i'm perfectly fine with not needing FFe, i felt it was better to ask and have release team take a look at the changes
<apw> rbalint, i don't see anything in there warrenting it .. so i'd say you are good
<rbalint> apw: ok thanks!
<juliank> I uploaded gnutls28 on saturday, but it seems the autopkgtest for lxc on amd64, i386, ppc64el are borked _since some time_ and blocking the migration out of -proposed.
<juliank> would be great to ignore those failures and allow it in
<juliank> (BTW: there's also an SRU in the zesty unapproved queue with the same patches; bug 1707172 and bug 1714506 are being fixed)
<ubot5> bug 1707172 in gnutls28 (Ubuntu Zesty) "AES256-GCM emits all-zeros ciphertext on aarch64 with hardware acceleration" [High,In progress] https://launchpad.net/bugs/1707172
<ubot5> bug 1714506 in gnutls28 (Ubuntu Zesty) "libgnutls30 OCSP verification bug" [High,In progress] https://launchpad.net/bugs/1714506
-queuebot:#ubuntu-release- New: accepted llvm-defaults [amd64] (artful-proposed) [0.37~exp3]
-queuebot:#ubuntu-release- New: accepted llvm-defaults [armhf] (artful-proposed) [0.37~exp3]
-queuebot:#ubuntu-release- New: accepted llvm-defaults [arm64] (artful-proposed) [0.37~exp3]
-queuebot:#ubuntu-release- New: accepted llvm-defaults [i386] (artful-proposed) [0.37~exp3]
<apw> juliank, indeed those look unreleased to you for sure
<apw> juliank, ok hinted
<juliank> apw: thanks
<LocutusOfBorg> apw, the same happens on curl, all of them are regressed in release
<Laney> I hate this regressed in release thing
<Laney> It means people spend time finding out whether not to fix something rather than fixing it
<Laney> because we suck at catching failures at the right time
<apw> a very valid sentiment ...
<LocutusOfBorg> as said, such stuff shoudl run from time to time already against release
<LocutusOfBorg> specially when queues are emptu
<LocutusOfBorg> tests for some packages are run once a yer
<Laney> so we can find out whether to ignore breakage in an automated way?
<LocutusOfBorg> year, so when you regress you have the world that changed in the meanwhile
<jbicha> ci.debian.net runs more frequently
<LocutusOfBorg> I would prefer rather to know "which" package regressed it, not to find it with a complete different set of stuff
<apw> Laney, i assume this is happening because we have either 1) ignored some other failure and released (say systemd with regressions) or 2) we have a missing dependency here
<apw> Laney, perhap netplan given the networking nature
<Laney> could be - or something in the base system changed, or we only run for direct dependency changes so we miss anything transitive
<Laney> anyway, the main problem I have is accepting an ever worsening baseline
<LocutusOfBorg> "so we can find out whether to ignore breakage in an automated way?" <-- I still don't get if this was a joke or not :) I admit, in my brain I had this thought, but I never said it out there
<Laney> that's what the proposal is
<LocutusOfBorg> not from my side I hope :)
<LocutusOfBorg> it will make testsuite useless
<Laney> what is 'run against release' meant to achieve then?
<LocutusOfBorg> or at least useless when the breakage is something else
<LocutusOfBorg> it is meant to have more logs, more runs
<Laney> you want to run against nothing from proposed, find out if it is already broken there, and if it is then don't treat the failure as a regression
<LocutusOfBorg> and less changed packages between them
<Laney> that is what requests like the curl one is
<LocutusOfBorg> this is what I did for curl
<LocutusOfBorg> but ok, I found release is broken, now, with some more test, I can diff the testbeds, and find "what" regressed it
<Laney> In theory I wouldn't mind if someone were to schedule such tests if they were friendly to the infrastructure
<LocutusOfBorg> of course, with less priority
<Laney> using this to decide when to force-badtest, or changing the definition of REGRESSION, is where I start to have problems
<LocutusOfBorg> also, having somebody running tests (results ignored), with --all-proposed would be nice
<Laney> but if people on the release team want to do the former then I can't really stop them
<Laney> there's no way to ignore results like that
<LocutusOfBorg> I sometimes run against all-proposed, but I don't like to have the green button as result in case
<LocutusOfBorg> so, if it becomes green, I try to make migrate the fixex package from proposed too
<LocutusOfBorg> but again, choosing one architecture (e.g. arm64) to always run against proposed, will make us have a clear view of what regressed and where, and if a fix is already in place, just not migrated
<LocutusOfBorg> (e.g. with k* qt* haskell* perl* this is normal)
<Laney> I don't think it's normal with perl
<Laney> or with haskell? they have correct dependencies
<LocutusOfBorg> yes, perl testsuites should run against perl in proposed, if you rebuild
<LocutusOfBorg> nope Laney
<Laney> what?
<Laney> they sure do
<LocutusOfBorg> they are just uninstallable in release, because all the rebuilds are in proposed
<LocutusOfBorg> I think I remember haskell-hoogle having this issue
<Laney> you're not trying to migrate the release thing
<LocutusOfBorg> I don't know what to say, I remember with perl slangasek did the --all-proposed stuff, because of this issue
<LocutusOfBorg> (maybe it was somebody else, but the problem was there)
<Laney> with haskell, I don't know what the specific problem with perl was
<LocutusOfBorg> is that you rebuild 500 packages, and they are installable only with the correspective rebuilds
<LocutusOfBorg> there is no strict dependency I would assume, don't remember
<Laney> the haskell tooling makes you depend on the hash
<Laney> if you're saying that doesn't happen for Test-Depends, well, it should :)
<LocutusOfBorg> http://autopkgtest.ubuntu.com/packages/haskell-hgettext/artful/amd64
<LocutusOfBorg> look as example at the first failure
<apw> Laney, i wonder if we should upload a no-change rebuild of things which fail in this way so they get wedged in -proposed and emails sent to the owners
<LocutusOfBorg> indeed, or put the test in some "depwait" mode
<LocutusOfBorg> so we can aware that the regression is just because the archive is not yet fully in place
<Laney> the first failure is an all-proposed run
<Laney> and 2, 3, 4, and I get bored now and stop looking
<Laney> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/amd64/h/haskell-hgettext/20170715_153508_199d7@/log.gz these ones that weren't all-proposed worked
<LocutusOfBorg> this one? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/amd64/h/haskell-hgettext/20170622_040119_7b95b@/log.gz
<LocutusOfBorg> the first failure
<LocutusOfBorg> (the oldest)
<LocutusOfBorg> so, maybe rebuilds were not complete then?
<Laney> autopkgtest: WARNING: Test dependencies are unsatisfiable with using apt pinning. Retrying with using all packages from proposed
<Laney> and it still didn't work
<Laney> so I don't blame pinning
<LocutusOfBorg> but having a "testbed unsatisfiable status" would have helped at least
<LocutusOfBorg> I now agree with you
<LocutusOfBorg> (I was just not aware of that pinning feature)
<Laney> I wouldn't look forward to implementing that particularly :(
<Laney> apw: Maybe, but the proposal I've heard is to make such things *not* get stuck because they wouldn't be regressions in proposed
<Laney> also, things don't always have owners
<Laney> did anyone file a bug about the lxc regression so that its maintainers can look? :-)
<LocutusOfBorg> it would be somewhat fixed if britney in Debian would have start to looking at ci too :D
<Laney> https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1713726 â¥
<ubot5> Ubuntu bug 1713726 in lxc (Ubuntu) "lxc 2.0.8-0ubuntu6 ADT test failure with linux 4.13.0-7.8" [Undecided,New]
<acheronuk> LocutusOfBorg: those kcrash tests should be ignored, as they pass here against the archive in a lxc adt containers. so something has gone a bit funky in the official ubuntu ones
<LocutusOfBorg> s/should be ignored/ubuntu official adt containers should be fixed/ I would say :)
<LocutusOfBorg> at least diverging makes local testing less effective
<apw> Laney, yeah we tend to file bugs for everything we see in failure even if we ignore them, so they are not forgotten
<LocutusOfBorg> filing bugs for stuff in universe is... strange
<apw> LocutusOfBorg, why so?  just becasue we don't want to support things doesn't mean they arn't broken
<LocutusOfBorg> apw, yes, but not many looks at universe bugs, unfortunately
<LocutusOfBorg> (I do, but I feel alone)
<LocutusOfBorg> sorry, please remove lld/arm64, it was built but not available from llvm-toolchain-4.0
<LocutusOfBorg> old binaries left on arm64: lld (from 0.37~exp3) (NBS-proposed remove it)
<flexiondotorg> doko: I see caja-admin and caja-rename are in the Artful NEW.
<flexiondotorg> They took longer than expected to clear the Debian NEW queue, but we are hotly anticpating them for Ubuntu MATE.
<flexiondotorg> Could you allow them through please.
<Laney> jbicha: http://autopkgtest.ubuntu.com/packages/e/evolution-data-server/artful/i386 http://autopkgtest.ubuntu.com/packages/e/evolution-data-server/artful/s390x were all of these you?
<jbicha> Laney: yes, the probably is that e-d-s is now running the installed-tests, I expected them to be flaky so I'll probably disable them in my next upload
<jbicha> *the problem
<Laney> 4 retries (5 attempts) is probably a bit much
<jbicha> I now have data to show to upstream at least
<jbicha> Laney: are you interested in ignoring the tests for this version to let e-d-s migrate?
<slangasek> nacc: your sphinx-celery upload was binary rejected, but the source is still in -proposed; should we be expecting another upload, or should I just remove the corresponding source? https://launchpad.net/ubuntu/+source/sphinx-celery/1.3.1-1ubuntu1
<tsimonq2> Could an archive admin please look at ubuntu-mate-guide in NEW when they can?
<flexiondotorg> Could an archive admin please look at caja-admin and caja-rename in NEW when they can?
#ubuntu-release 2017-09-05
-queuebot:#ubuntu-release- New: accepted caja-admin [sync] (artful-proposed) [0.0.1-1]
-queuebot:#ubuntu-release- New: accepted caja-rename [sync] (artful-proposed) [17.3.28~bzr14+repack1-2]
-queuebot:#ubuntu-release- New binary: caja-admin [amd64] (artful-proposed/none) [0.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: caja-rename [amd64] (artful-proposed/none) [17.3.28~bzr14+repack1-2] (no packageset)
<LocutusOfBorg> AA ping wrt llvm-defaults NBS lld in arm64 (proposed)
<apw> LocutusOfBorg, why are we removing that on arm64 ?
-queuebot:#ubuntu-release- New: accepted caja-admin [amd64] (artful-proposed) [0.0.1-1]
-queuebot:#ubuntu-release- New: accepted caja-rename [amd64] (artful-proposed) [17.3.28~bzr14+repack1-2]
<LocutusOfBorg> because llvm-toolchain-4.0 doesn't build it
<LocutusOfBorg> also 5.0 and so on I would presume
<LocutusOfBorg> it has never been built
<LocutusOfBorg> (we will upload a fixed package in debian experimental too)
<LocutusOfBorg> not sure how much effort is needed to build lld on arm64, but the safe bet is to stick to what is in -release already, and enable it in debian eventually
<LocutusOfBorg> (specially due to gcc-7 llvm doesn't rebuild anymore)
<apw> LocutusOfBorg, ok removed
<LocutusOfBorg> ta
<apw> tsimonq2, hey this ubuntu-mate-guide, if it is viewable with things other than yelp does yelp have to be a Depends: could it be a Recommends:
-queuebot:#ubuntu-release- Unapproved: postgresql-9.3 (trusty-proposed/main) [9.3.18-0ubuntu0.14.04.1 => 9.3.19-0ubuntu0.14.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: postgresql-9.5 (xenial-proposed/main) [9.5.8-0ubuntu0.16.04.1 => 9.5.9-0ubuntu0.16.04] (core)
-queuebot:#ubuntu-release- Unapproved: postgresql-9.6 (zesty-proposed/main) [9.6.4-0ubuntu0.17.04.1 => 9.6.5-0ubuntu0.17.04] (core)
<doko> LocutusOfBorg: please could you be more specific about "specially due to gcc-7 llvm doesn't rebuild anymore"?
<LocutusOfBorg> doko, I honestly don't know, somewhere I get ld segfaulting
<LocutusOfBorg> look at llvm on amd64 as example
<LocutusOfBorg> I didn't find the time to do some debugging yet
<LocutusOfBorg> I was wondering about the gdwarf flag, but seems not the cause
<doko> well, but you do find the time syncing more stuff :-/
<LocutusOfBorg> Fixes I need :)
<LocutusOfBorg> for llvm I wait the debian uploads, to see how and where gcc regressed
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/llvm-toolchain-5.0/1:5.0~+rc5-1/+build/13325957
<LocutusOfBorg> this is an example
<doko> which doesn't fail in Debian, and I'm unsure that gcc regressed here. it appears that your comment is just a wild guess, nothing else
<LocutusOfBorg> I did the comparison, to check if "ubuntu1" was the culprit in the gcc detection
<LocutusOfBorg> and dpkg-compare showed the same result
<LocutusOfBorg> let me grab some food and I'll do the a new round of testing
<LocutusOfBorg> dwarf is the culprit probably
<Laney> rcj: philroche: Hi, looks like cloud image publishing/building got wedged again
<LocutusOfBorg> doko, amd64 llvm should be fixed but arm64 and ppc64el smells regressions in toolchain to me https://launchpad.net/ubuntu/+source/llvm-toolchain-5.0/1:5.0~+rc5-1
<LocutusOfBorg> forcing gcc-6 worked https://launchpad.net/ubuntu/+source/llvm-toolchain-5.0/1:5.0~+rc2-1
-queuebot:#ubuntu-release- Unapproved: cryptsetup (xenial-proposed/main) [2:1.6.6-5ubuntu2 => 2:1.6.6-5ubuntu2.1] (core)
<philroche> Laney: Yes. Apologies, working through a few issues with build now
<nacc> slangasek: oh sorry, you can remove the corresponding source
<apw> nacc, slangasek, removed
<nacc> apw: thanks
-queuebot:#ubuntu-release- New binary: llvm-toolchain-snapshot [amd64] (artful-proposed/universe) [1:6.0~svn311834-2ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-neutronclient (xenial-proposed/main) [1:4.1.1-2 => 1:4.1.1-2ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-neutronclient (zesty-proposed/main) [1:6.1.0-0ubuntu2 => 1:6.1.0-0ubuntu3] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: xfsprogs (zesty-proposed/main) [4.3.0+nmu1ubuntu4 => 4.3.0+nmu1ubuntu5] (core)
-queuebot:#ubuntu-release- Unapproved: xfsprogs (xenial-proposed/main) [4.3.0+nmu1ubuntu1 => 4.3.0+nmu1ubuntu1.1] (core)
-queuebot:#ubuntu-release- Unapproved: xfsprogs (zesty-proposed/main) [4.3.0+nmu1ubuntu4 => 4.3.0+nmu1ubuntu4.1] (core)
-queuebot:#ubuntu-release- Unapproved: rejected xfsprogs [source] (zesty-proposed) [4.3.0+nmu1ubuntu5]
-queuebot:#ubuntu-release- Unapproved: ppc64-diag (trusty-proposed/universe) [2.6.9-0ubuntu1~14.04 => 2.7.4-1~14.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ppc64-diag (xenial-proposed/universe) [2.7.0-0ubuntu4 => 2.7.4-1~16.04] (no packageset)
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-snapshot [amd64] (artful-proposed) [1:6.0~svn311834-2ubuntu3]
-queuebot:#ubuntu-release- New: accepted ubuntu-mate-guide [source] (artful-proposed) [17.10.1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: ubuntu-mate-guide [amd64] (artful-proposed/universe) [17.10.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ubuntu-mate-guide [amd64] (artful-proposed) [17.10.1-0ubuntu1]
<tsimonq2> apw: No, yelp has to be Depends because the desktop file uses it
<tsimonq2> And we have to have a desktop file
<tsimonq2> (context: ubuntu-mate-guide)
<tsimonq2> Oh, I see it was accepted, thanks!
-queuebot:#ubuntu-release- Unapproved: kdeplasma-addons (zesty-proposed/universe) [4:5.9.5-0ubuntu0.1 => 4:5.9.5-0ubuntu0.2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: systemd (xenial-proposed/main) [229-4ubuntu19 => 229-4ubuntu20] (core)
<xnox> cyphermox, ^
#ubuntu-release 2017-09-06
<RAOF> Huh. Maas doesn't have a documented micro-release-exception?
-queuebot:#ubuntu-release- Unapproved: rejected maas [source] (xenial-proposed) [2.2.3-6106-g314b2b2-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected python3.5 [source] (xenial-proposed) [3.5.2-2ubuntu0~16.04.2]
<infinity> RAOF: https://wiki.ubuntu.com/MAASUpdates
<infinity> RAOF: I believe it's still in the "needs review and possibly tweaks before being approved and linked from the SRU pages", but there it is.
<RAOF> Aha!
<RAOF> I thought I'd read a maas one, but there wasn't anything linked to the SRU page.
<RAOF> Oh, well. The upload still needed a tracking bug.
<tsimonq2> Oh hey infinity, nice to see you around again :)
<didrocks> good morning
<doko> bdmurray: see LP: #1682934, I'm not caring anymore about that and will fix it as won't fix. if RAOF thinks it is fine to reject, then fine ...
<ubot5`> Launchpad bug 1682934 in python2.7 (Ubuntu) "python3 in /usr/local/bin can cause python3 packages to fail to install" [Undecided,Confirmed] https://launchpad.net/bugs/1682934
<doko> SpamapS: ^^^
<RAOF> doko: I'd be happy to *accept* an upload to fix that bug.
<doko> please find somebody else to waste that time
<LocutusOfBorg> hello, question, what about syncing a library that changed soname, but has no reverse-dependencies  in the archive? https://packages.qa.debian.org/p/pupnp-1.8.html
<LocutusOfBorg> vlc is starting to depend on it soon, so I presume it would be better to have sonames in sync
<LocutusOfBorg> also, htseq is unbuildable on i386 in debian and Ubuntu, but only debian removed it so far
<juliank> Just a reminder about the gnutls28 is in zesty unapproved: It fixes an in-place encryption data loss on arm64 (ciphertext becomes all zeroes) and a connectivity issue (well, OSCP verification failing where it should not). Would be great to have that in -proposed soon.
<LocutusOfBorg> also gnutls26 in trusty unapproved :)
<juliank> right
<juliank> The zesty SRU should be easy to review, and as a bonus point, I just copied the patches from Debian stable and refreshed them (so chances are they are fine, given they passed Debian's release team...)
 * apw looks
<apw> juliank, there is already a gnutls28 in zesty-proposed which has adt failures ... do you want to be merged witht hat ?
<juliank> apw: It's based on that, I did not actually noticed that was still in -proposed. From a quick look, the failures in -proposed seem to be unrelated (aria2 fails in an http connection failure - no https, and systemd has been failing for a long time) - after all, the proposed change only affects the openssl compat library. So I guess you could either replace it, or push the existing to proposed first.
 * apw dies a little inside ...
<apw> ok i thikn it make sense to let this previous one out
<juliank> apw: It's certainly verified, I just think the uploader did not watch the autopkgtests and bug around so nobody looked at it further :)
-queuebot:#ubuntu-release- Unapproved: accepted gnutls28 [source] (zesty-proposed) [3.5.6-4ubuntu4.3]
<juliank> apw: thanks
<apw> LocutusOfBorg, that gnutls26 is based on the previos upload in -proposed which has failed verification
<apw> LocutusOfBorg, these are all by the same person and as far as i can see they have based their second fix on their own bad version of the fix
<apw> LocutusOfBorg, it looks like you have been sponsoring for them, if so could you circle with them and work out whats what with these two fixes
<juliank> apw: The broken one is by Simon Deziel <simon.deziel@gmail.com>, the one LocutusOfBorg is interested in is by Samuel D. Leslie <sdl@nexiom.net>, but based on the broken one
<juliank> There's a fixed patch in https://bugs.launchpad.net/debian/+source/gnutls28/+bug/1709193
<ubot5`> Ubuntu bug 1709193 in gnutls28 (Ubuntu Xenial) "Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer" [Undecided,Fix committed]
<apw> juliank, my bad i read those names as the saem, which is just wrong
<juliank> So the realistic option is to rebase Samuel's patch on top of the updated patch for that bug
<apw> yep, i'll reject what is here with that position
-queuebot:#ubuntu-release- Unapproved: rejected gnutls26 [source] (trusty-proposed) [2.12.23-12ubuntu2.10]
-queuebot:#ubuntu-release- Unapproved: accepted cryptsetup [source] (xenial-proposed) [2:1.6.6-5ubuntu2.1]
<LocutusOfBorg> apw, I might just add this one?https://launchpadlibrarian.net/334087516/lp1709193-14.04-version2.debdiff
<juliank> It's odd because I'm not sure if VERIFY_ALLOW_SIGN_RSA_MD5 would not allow MD5 signatures anywhere in the chain. I don't know if that's really something you'd want.
<juliank> That is; '%VERIFY_ALLOW_SIGN_RSA_MD5' will allow RSA-MD5 signatures in certificate chains.
<juliank> It's "OK" for self-signatures I guess, but I fear it might allow MD5 in general?
<apw> juliank, indeed that sounds like something we would want input from tyhicks on
<apw> as it is likely something they have turned off deliberatly
-queuebot:#ubuntu-release- Unapproved: gnutls26 (trusty-proposed/main) [2.12.23-12ubuntu2.9 => 2.12.23-12ubuntu2.10] (core)
<juliank> I think there is a bug that if the root cert is self-signed with MD5 that it is falsely rejected in gnutls26
<juliank> (because the self-signature is irrelevant for a root cert)
 * juliank is looking at gnutls git
<juliank> This sound like it: https://gitlab.com/gnutls/gnutls/commit/b93ae1abf1b84fdc094f2474f1b2e4848081810e
<juliank> But there might be other commits needed
<apw> juliank, well it seems to remove a lot of code ... otehr than that i am not sure
<apw> anyhow, we should wait on the security team feedback for that MD5 thing before we accept that SRU
<juliank> Maybe just do LocutusOfBorg's one first without the other?
<juliank> Should probably ask upstream about the whole thing, they might have a solution, although they're probably not that happy about questions about such old software :D
<apw> juliank, i have added security to the bug, and pinged for an oppinion
<juliank> Funny thing is that 2.12.23 was released 4 years ago (obviously ,it's in 14.04 after all), and 2.12.24 10 months ago, collecting patches for like 3 years
<apw> juliank, security people are very much like that
<apw> anyhow lets see what they say
<juliank> Right now I'm figuring out how to best upload apt 1.4.7 (which is in stretch) to zesty-proposed. In theory, it could be synced but then there's no diff for review. I could also do a fake sync by rewriting the changes file; or I could just upload it with a changed changelog. It would sort of be nice to share the tarball and history with stretch.
<juliank> * for next week, really
<juliank> I guess optimally I'd just patch launchpad to create diffs for synced packages...
<juliank> I have the fake sync in the apt PPA already since Jul 18, so that would be ready to go :)
<juliank> Though I do have to do a 1.4.8 anyway, so it might not be 1.4.7 entering
<cjwatson> "just"
<cjwatson> https://bugs.launchpad.net/launchpad/+bug/851562
<ubot5`> Ubuntu bug 851562 in Launchpad itself "Diffs not available for syncs on +queue page like for regular uploads" [High,Triaged]
<juliank> cjwatson: :D
<juliank> cjwatson: syncpackage --no-lp actually does a reasonable job, except that it also resigns the .dsc; so it's probably easiest for me to just change that
<Laney> We used to call the the "categorical just" in CS. <30 minute presentation>. "Isn't that just an instance of <insane category theoretic structure>?"
<juliank> grr, gpg: signing failed: Card reset required
<juliank> But, yay, with that line patched out, syncpackage --no-lp does a reasonable job of syncing apt 1.4.7 from stretch to zesty, probably with launchpad generating a diff then
<juliank> (not tested, but since uploading changes...)
<cpaelzer> anybody on the release team time to check FFE on bug 1706248?
<ubot5`> bug 1706248 in slof (Ubuntu) "[FFE] SLOF dhcp request doesn't include client architecture code 93" [Medium,Confirmed] https://launchpad.net/bugs/1706248
-queuebot:#ubuntu-release- Unapproved: ubuntu-fan (zesty-proposed/main) [0.12.2.1 => 0.12.4~17.04.1] (no packageset)
-queuebot:#ubuntu-release- New sync: fontawesomefx (artful-proposed/primary) [8.9-1]
-queuebot:#ubuntu-release- New sync: libimglib2-java (artful-proposed/primary) [4.3.0-1]
-queuebot:#ubuntu-release- New sync: libparsington-java (artful-proposed/primary) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted fontawesomefx [sync] (artful-proposed) [8.9-1]
-queuebot:#ubuntu-release- New: accepted libparsington-java [sync] (artful-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted libimglib2-java [sync] (artful-proposed) [4.3.0-1]
-queuebot:#ubuntu-release- New binary: fontawesomefx [amd64] (artful-proposed/none) [8.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libparsington-java [amd64] (artful-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libimglib2-java [amd64] (artful-proposed/none) [4.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted fontawesomefx [amd64] (artful-proposed) [8.9-1]
-queuebot:#ubuntu-release- New: accepted libparsington-java [amd64] (artful-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted libimglib2-java [amd64] (artful-proposed) [4.3.0-1]
<xnox> Rebuilding perl, by syncing from debian, to get the right config.h defines for the new glibc.
 * Laney cries
-queuebot:#ubuntu-release- Unapproved: rejected google-cloud-sdk [source] (zesty-proposed) [166.0.0-0ubuntu1~17.04.0]
-queuebot:#ubuntu-release- Unapproved: rejected google-cloud-sdk [source] (xenial-proposed) [166.0.0-0ubuntu1~16.04.0]
<xnox> Laney, otherwise things fail to detect perl.h and FTBFS =/
<xnox> as it includes header that glibc no longer ships
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (zesty-proposed/partner) [163.0.0-0ubuntu1~17.04.0 => 169.0.0-0ubuntu1~17.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (xenial-proposed/partner) [163.0.0-0ubuntu1~16.04.0 => 169.0.0-0ubuntu1~16.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (trusty-proposed/partner) [163.0.0-0ubuntu1~14.04.0 => 169.0.0-0ubuntu1~14.04.0] (no packageset)
<doko> update_excuses not update for three hours?
<LocutusOfBorg> yep, looks like britney having a sad day
<LocutusOfBorg> http://people.canonical.com/~ubuntu-archive/proposed-migration/log/artful/2017-09-06/
<LocutusOfBorg> seems running now
<LocutusOfBorg> but something is down, autopkgtests and something more :(
-queuebot:#ubuntu-release- Unapproved: ibm-java80 (xenial-proposed/partner) [8.0.4.1-0ubuntu1 => 8.0.4.11-0ubuntu1] (no packageset)
<SpamapS> RAOF: do we still have to do SRU's to zesty even though it is EOL?
<SpamapS> Like, who cares if somebody upgrades to it and regresses, they're not supported anyway.
<RAOF> SpamapS: Zesty isn't EOL yet, is it?!
<SpamapS> RAOF: 4/13/17
<SpamapS> oh haha
<SpamapS> That's RELEASE date
<SpamapS> derpaderp
<SpamapS> I's smahrt
<SpamapS> RAOF: carry on. ;)
<SpamapS> I'll prep a zesty upload
<RAOF> I would be rather surprised if we EOL'd Zesty *before* we released Artful :)
<juliank> I'm wondering about ndiswrapper SRUs for HWE kernels; whether it really makes sense to do the intermediate SRU there as well (given that the intermediate release has no HWE kernel). But I guess it does not hurt and I just re-upload the devel version anyway with ~16.04.1 or something appended
<juliank> so not really wondering
#ubuntu-release 2017-09-07
-queuebot:#ubuntu-release- Unapproved: libvirt (trusty-proposed/main) [1.2.2-0ubuntu13.1.21 => 1.2.2-0ubuntu13.1.22] (kubuntu, ubuntu-desktop, ubuntu-server, virt)
<cpaelzer> hi, currently qemu 2.10 migration in artful is blocked by bug 1715128
<ubot5`> bug 1715128 in cloud-init (Ubuntu) "Crashes in convert_ec2_metadata_network_config on ScalingStack bos01 (ppc64el)" [Critical,Confirmed] https://launchpad.net/bugs/1715128
<cpaelzer> I wanted to ask if one could force the migration (all else is good) since no one knows how long resolution will take
<apw> cpaelzer, is it safe to let it migrate if it is going to make scalingstack sad, given that is where we build things ?
<wgrant> apw: It's cloud-init that's broken
<wgrant> qemu is only affected because the cloud-init in the images doesn't work any more
<cpaelzer> as wgrant says
<apw> oh i see, not reading very well ... perhaps i should not be typing :)
<cpaelzer> I'd expect any ppc64el test needin network through proxies to fail over the next days
<cpaelzer> until that is resolved
<apw> that does not seem unreasonable ... hinted
<apw> cpaelzer, if this is going to take days to fix, can we not revert the whole of the cloud-init update somehow
<apw> cpaelzer, given it is cratering testing
<cpaelzer> apw: absolutely
<cpaelzer> apw: I planned to jump into the cloud-init standup today to dsicuss options
<cpaelzer> apw: a CURVER+reallyOLDVER might be a temporary fix in this case
<cpaelzer> but since this is around data source identification in scaling stack we have to understand what really is going on)
<wgrant> Well we know now
<cpaelzer> my current theory is that scaling stack tries to mimic ec2, but doesn't do perfectly (a common case btw)
<wgrant> https://bugs.launchpad.net/cloud-init/+bug/1715241
<ubot5`> Ubuntu bug 1715241 in cloud-init "ds-identify openstack returns not found on non-intel" [Medium,Confirmed]
<wgrant> ds-identify simply doesn't work outside x86.
<wgrant> Since it relies on DMI
<cpaelzer> IM-veryH-o I'm not 100% convinced that is the issue affecting the current case
<apw> they use dmi ... openstack "for the win"
<cpaelzer> hmm, yeah you might be right ont hat bug actually
<cpaelzer> yet I wonder why this should now be different than before
<cpaelzer> anyway smoser and rharper will ahve all the current context later today
<wgrant> Becaise cloud-init used to poll all datasources
<cpaelzer> Maybe it comes together with fail-detect EC2 + new ipv6 code that can fault if no EC2 data is actually provided
<wgrant> there was work this cycle to speed up cloud-init by using ds-identify to skip irrelevant sourcea
<cpaelzer> The polling -> detect change happened a while ago, that is why I wonder the recent update breaking it in this case
<cpaelzer> I'm rather up to date on the ds-identify move
<cpaelzer> just thought that would have been in artful for a while now, which is why I expect it to be partially bad for a while but e.g. the ipv6 code added now making this a hard fail
<wgrant> it is either that it has just swktched to EC2, or EC2 used to work but doesn't any more
<wgrant> but it *should* be using OpenStack on that cloud, so fixing ds-identify would probably work
<cpaelzer> ack
<cpaelzer> I think copying that discussion context to the current bug is worth to
 * cpaelzer is copying
 * Laney is looking into why /running is timing out
<Laney> don't all go hit it to confirm that that's the case please :/
<apw> Laney, :)
<Laney> https://paste.ubuntu.com/25483043/
<Laney> some extremely duplicated requests
<apw> queue gone mad ... hrm
<Laney> https://paste.ubuntu.com/25483059/
<Laney> BRITNEYYYYYYYYYYYY
<cpaelzer> oops she did it again (lamest pun ever I guess)
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.27.5~14.04 => 2.27.6~14.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.27.5 => 2.27.6] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (zesty-proposed/main) [2.27.5+17.04 => 2.27.6+17.04] (desktop-core, ubuntu-server)
<apw> Laney, crashing out before she writes her state back perhaps ?
<apw> Laney, is there ever a case where a duplicated run is valid in the pending queue (with the same actual parameters)
 * apw will review those snapds ^
<Laney> it was crashing
 * Laney dies
<Laney> guess I get to write a script to filter these out, and then fix britney
<apw> Laney, sounds like a fun day for you ... i wonder if we should be writing what we have submitted to disk at the time we submit it ... and then it is always recorded
<Laney> yeh
<Laney> going to make runs a bit slower but that's probably less bad than this
-queuebot:#ubuntu-release- Unapproved: ntp (xenial-proposed/main) [1:4.2.8p4+dfsg-3ubuntu5.6 => 1:4.2.8p4+dfsg-3ubuntu5.7] (ubuntu-server)
<Laney> https://paste.ubuntu.com/25483111/
<Laney> https://www.youtube.com/watch?v=ZKFDK-Z1QUE
<Laney> back in business
-queuebot:#ubuntu-release- Unapproved: xorg-server (xenial-proposed/main) [2:1.18.4-0ubuntu0.4 => 2:1.18.4-0ubuntu0.5] (desktop-core, xorg)
<apw> Laney, i don't see "moving triggered by apw to the top of the list" in there anywhere :)
<Laney> heh oh god
<Laney> reordering would be a lot more weird
<Laney> you'd have to ack everything out and then put it back in a different order
<Laney> /o\
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (zesty-proposed) [2.27.6+17.04]
<Laney> poor apw is going to have to queue up with the plebs :)
<apw> i assume you are picking all the requests and acking the bad ones and then exiting to do this ?
<Laney> yeh
<Laney> like filter-amqp
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.27.6]
<acheronuk> bug #1703368 breaks build and tests of some k* packages, as libxslt requires headers which were removed
<ubot5`> bug 1703368 in glibc (Ubuntu) "[FFe] [17.10 FEAT] upgrade to newest version of glibc >=2.26" [Undecided,Triaged] https://launchpad.net/bugs/1703368
<acheronuk> bug #1715599
<ubot5`> bug 1715599 in glibc (Ubuntu) "2.26-0ubuntu1 breaks compliation of several KDE sources" [Undecided,New] https://launchpad.net/bugs/1715599
<acheronuk> libxslt is not an optional build dep, so no easily working around that
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.27.6~14.04]
<xnox> acheronuk, that header is dropped and no longer required, one should include locale.h alone.
<xnox> acheronuk, hence this is a bug in libxslt, let me look into that.
<acheronuk> xnox: I was coming to that conclusion after filing the bug
<xnox> acheronuk, e.g. in src:perl it does "proper" configure time checks and generates defines to conditionally include locale.h, xlocale.h, or both.
<xnox> acheronuk, in this case I will just drop the xlocale.h include.
<xnox> and upload.
<acheronuk> xnox: thanks :)
<xnox> apw, awwww... /o\ what cloud-init regression?
<xnox> is there a bug number? do you add bug number when pushing hints?
<xnox> cpaelzer, we are currently undergoing investigations in scaling stack failing to talk to the metadata sources. and cloud-init was mistakenly identifying and (using/abusing) ec2 data-source on scalingstack on non-intel architectures since introduction of ds-identify it seems, and we are inflight fixing that.
<xnox> and separately, I'm currently seeing regression of not being able to talk to the openstack native datasource, on intel, in scalingstack =/
<wgrant> xnox: Hm, really? Do you have an example instance?
<wgrant> Which network is it on?
<wgrant> And which cloud?
<xnox> wgrant, yes i have all that. One sec.
<xnox> &> some other channel
<apw> xnox I should and did not
 * Laney wonders what this secret discussion revealed
<cpaelzer> Laney: you checked which other channel they meant as well :-)
<Laney> I just know it's no channel that I'm in :(
<slashd> Good day sil2100 ;), Do you have some cycle to approve the upload of "python-neutronclient" for Xenial and Zesty ? (LP: #1692334)
<ubot5`> Launchpad bug 1692334 in python-neutronclient (Ubuntu Zesty) "neutron bash completion helper is not installed" [Medium,In progress] https://launchpad.net/bugs/1692334
<tjaalton> pymol tests on ppc64el are breaking since a glibc update a week ago, and is blocking mesa..
<doko> tjaalton: are you sure it's glibc? I think I've seen these earlier, not just triggered by mesa
<tjaalton> doko: just trying to parse http://autopkgtest.ubuntu.com/packages/p/pymol/artful/ppc64el
<acheronuk> can a member of SRU team please release the missing packages for bug #1687444 ?
<ubot5`> bug 1687444 in polkit-kde-agent-1 (Ubuntu Zesty) "Zesty SRU tracking bug for KDE's Plasma 5.9.5" [Undecided,Fix committed] https://launchpad.net/bugs/1687444
<acheronuk> ksshaskpass & polkit-kde-agent-1
<sil2100> slashd: hey! On it in some minutes ;)
<slashd> sil2100, thanks
<acheronuk> oh, those are some 0-diff packages. so doesn't really matter. they can stay at 5.9.4 if releasing is deemed more a regression risk than not
<sil2100> acheronuk: I asked Brian about why he kept some of them unreleased
<sil2100> acheronuk: I could understand the polkit one since it had some autopkgtest regressions that first need someone to confirm if unrelated
<sil2100> But besides that, no idea why he didn't release those
<acheronuk> sil2100: well, as I said, the only upstream changes were internal version bumps, so even a nominal and likely unrelated regression would be a good reason to not release
<sil2100> acheronuk: yeah, it still requires someone to look and confirm ;) I guess I can pick it up
<acheronuk> I thought those were some with some fixes, but I was mistaken.
<acheronuk> The final paragraph of the SRU says to leave those unreleased if there is even a small risk
<acheronuk> all the crucial packages seem to have gone through
<acheronuk> I should have remembered all that, as I wrote the bug!
<xnox> tjaalton, triggering pymol test with pymol as the only trigger, to test it alone in artful-release pocket, without anything from proposed.
-queuebot:#ubuntu-release- Unapproved: accepted python-neutronclient [source] (zesty-proposed) [1:6.1.0-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted python-neutronclient [source] (xenial-proposed) [1:4.1.1-2ubuntu1]
<slashd> freyes, ^^^
<slashd> thanks sil2100
-queuebot:#ubuntu-release- Unapproved: accepted virt-manager [source] (zesty-proposed) [1:1.3.2-3ubuntu4.1]
-queuebot:#ubuntu-release- Unapproved: accepted virt-manager [source] (xenial-proposed) [1:1.3.2-3ubuntu1.16.04.4]
<sil2100> bdmurray: ^ there are 3 KDE packages left in -proposed that weren't pushed to -updates, any reason for that? IIRC you were the one publishing that batch
<freyes> slashd, thanks for the heads up
<sil2100> For zesty
<bdmurray> sil2100: No, copying all the package names was hard.
<sil2100> heh, yeah, crazy amount
<sil2100> bdmurray: ok, so I'll just check them quick and publish - or maybe you want to do that?
<bdmurray> sil2100: I can do it
<doko> what is the current way to re-run tests against all-proposed?
<nacc> doko: i have had to right-click the url, c&p, and append "&all-proposed=1"
<doko> ahh, maybe we should generate that button by default ...
<Laney> no
<nacc> doko: i thin it would get abused :/
<nacc> Laney: would it be difficult for the retry button to not just be a POST but instead be a web form where you can append more arguments? (in the case where, say, two packages need to be tested together). I find the biggest hassle is just c&p the same URL 5 times for each arch
<nacc> Laney: not asking you to do it, just curious
<Laney> Probably in most cases that is an insufficiently tight dependency
<Laney> but I'd probably implement that in retry-autopkgtest-regressions
<nacc> Laney: you might be right on the reason
<Laney> like [1] let you select the failing package instead of always dumping everything, [2] allow you to supply an extra trigger
<nacc> Laney: yeah, that would satisfy my need
<Laney> :3
<Laney> nacc: don't think you can file bugs on lp:ubuntu-archive-tools sadly
<nacc> ooh https://bugs.launchpad.net/ubuntu-archive-tools
<nacc> Laney: there?
<Laney> well blow me down
<Laney> now it'll turn out I've filed one there before
-queuebot:#ubuntu-release- Unapproved: python3.5 (xenial-proposed/main) [3.5.2-2ubuntu0~16.04.1 => 3.5.2-2ubuntu0~16.04.2] (core)
-queuebot:#ubuntu-release- Unapproved: python3.5 (zesty-proposed/main) [3.5.3-1 => 3.5.3-1ubuntu0~17.04.0] (core)
<nacc> Laney: heh
<nacc> Laney: I did a quick saerch and didn't see it, but filed LP: #1715698
<ubot5`> Launchpad bug 1715698 in ubuntu-archive-tools "retry-autopkgtest-regressions could take a srcpkg and extra triggers" [Undecided,New] https://launchpad.net/bugs/1715698
<Laney> nacc: merci
<Laney> if you (or anyone) work on it, feel free to subscribe me to the MP for a review
-queuebot:#ubuntu-release- Unapproved: tor (xenial-proposed/universe) [0.2.7.6-1ubuntu1 => 0.2.9.11-1ubuntu1~16.04.1] (no packageset)
<nacc> Laney: ack, will do!
<SpamapS> RAOF: FYI, I uploaded bug 1711724 to both xenial and zesty (as you can see above). Would very much appreciate a queue-jump as that has been waiting a long time since doko sniped it out of the queue for the other bug originally.
<ubot5`> bug 1711724 in python3.5 (Ubuntu Zesty) "Segfaults with dict" [High,In progress] https://launchpad.net/bugs/1711724
<SpamapS> aw man.. just noticed zesty has python 3.6.1 .. durn it
<SpamapS> one more upload
<stgraber> any chance someone on the release team can review https://bugs.launchpad.net/bugs/1715278
<ubot5`> Ubuntu bug 1715278 in lxc (Ubuntu) "[FFe] LXC 2.1" [Undecided,New]
<stgraber> ?
<stgraber> I'll be offline most of next week, so would be neat if we could get this uploaded and any issues sorted out before travel
-queuebot:#ubuntu-release- Unapproved: python3.6 (zesty-proposed/universe) [3.6.1-1 => 3.6.1-1ubuntu0~17.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected maas [source] (zesty-proposed) [2.2.3-6106-g314b2b2-0ubuntu1~17.04.1]
<SpamapS> RAOF: ^^ also python3.6 in zesty
-queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (zesty-proposed) [1.13.1-0ubuntu1~17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted runc [source] (zesty-proposed) [1.0.0~rc2+docker1.13.1-0ubuntu1~17.04.1]
<xnox> Laney, so i take it autopkgtest will be running all weekend. given glibc and perl. sigh
-queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (xenial-proposed) [1.13.1-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted runc [source] (xenial-proposed) [1.0.0~rc2+docker1.13.1-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted tor [source] (xenial-proposed) [0.2.9.11-1ubuntu1~16.04.1]
<bdmurray> xnox: is bug 1713536 fixed in artful?
<ubot5`> bug 1713536 in systemd (Ubuntu Zesty) "udev: boot script does not trigger subsystem coldplug" [Undecided,In progress] https://launchpad.net/bugs/1713536
<bdmurray> oh, nope systemd is in -proposed
<Laney> xnox: seems like it :-)
<Laney> at least non- huge stuff should get processed quickly
<bdmurray> SpamapS: I'll have a look today
<SpamapS> bdmurray: ty!
<xnox> bdmurray, in proposed, yes.
<xnox> bdmurray, but it will take a while to migrate due to backlogs =/
<bdmurray> xnox: is the SRU important enough to not wait for the fix in -proposed?
<xnox> bdmurray, accepting into -proposed yes; releasing to -updates can wait until it migrates in artful too.
<bdmurray> xnox: okay
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (zesty-proposed) [232-21ubuntu6]
-queuebot:#ubuntu-release- Unapproved: accepted fuse-umfuse-ext2 [source] (zesty-proposed) [0.4-1.1ubuntu0.17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted fuse-umfuse-ext2 [source] (xenial-proposed) [0.4-1.1ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted fuse-umfuse-ext2 [source] (trusty-proposed) [0.4-1.1ubuntu0.14.04.1]
-queuebot:#ubuntu-release- New source: uvp-monitor (artful-proposed/primary) [2.2.0.315-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kdeplasma-addons [source] (zesty-proposed) [4:5.9.5-0ubuntu0.2]
<slangasek> FFe request: LP: #1715720
<ubot5`> Launchpad bug 1715720 in tortoisehg (Ubuntu) "FFe: sync tortoisehg 4.3.1-1 from unstable, unblocks new mercurial" [Undecided,New] https://launchpad.net/bugs/1715720
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-131.180] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-131.180]
<bdmurray> SpamapS: What happened here?  27 -  libreadline-dev, libncursesw5-dev (>= 5.3), gcc (>= 4:6.3),
<bdmurray>  28 +  libreadline-dev, libncursesw5-dev (>= 5.3),
-queuebot:#ubuntu-release- Unapproved: accepted python3.6 [source] (zesty-proposed) [3.6.1-1ubuntu0~17.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted python3.5 [source] (xenial-proposed) [3.5.2-2ubuntu0~16.04.2]
<slangasek> thanks to whoever triggered the re-test to confirm pymol/ppc64el is broken in release
-queuebot:#ubuntu-release- Unapproved: accepted postgresql-9.6 [source] (zesty-proposed) [9.6.5-0ubuntu0.17.04]
-queuebot:#ubuntu-release- Unapproved: accepted postgresql-9.5 [source] (xenial-proposed) [9.5.9-0ubuntu0.16.04]
-queuebot:#ubuntu-release- Unapproved: accepted postgresql-9.3 [source] (trusty-proposed) [9.3.19-0ubuntu0.14.04]
-queuebot:#ubuntu-release- Unapproved: accepted stunnel4 [source] (xenial-proposed) [3:5.30-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (xenial-proposed) [2:8.4.0-0ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted ntp [source] (xenial-proposed) [1:4.2.8p4+dfsg-3ubuntu5.7]
<SpamapS> bdmurray: huh?
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (xenial-proposed) [2:13.1.4-0ubuntu4]
<bdmurray> SpamapS: https://launchpadlibrarian.net/336180848/python3.5_3.5.3-1_3.5.3-1ubuntu0~17.04.0.diff.gz see the changed Build-Depends
<SpamapS> bdmurray: I wonder if that happened because I did debuild -S on xenial?
<SpamapS> I definitely didn't _try_ to add that line.
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (trusty-proposed) [1.2.2-0ubuntu13.1.22]
<bdmurray> SpamapS: will you reupload?
<SpamapS> bdmurray: happy to, it will be a little while though.
<bdmurray> SpamapS: sure, I'll reject this one and feel free to ping me
-queuebot:#ubuntu-release- Unapproved: rejected python3.5 [source] (zesty-proposed) [3.5.3-1ubuntu0~17.04.0]
-queuebot:#ubuntu-release- New sync: node-md5.js (artful-proposed/primary) [1.3.4-1]
-queuebot:#ubuntu-release- New source: ibm-java71 (xenial-proposed/partner) [7.1.4.10-0ubuntu1]
#ubuntu-release 2017-09-08
<cpaelzer> apw; the hint you added yesterday to make the pp6e4l vagrant-mutate test pass (testbed error) can be removed
<cpaelzer> apw: the bug is (supposed to) be fixed
<slangasek> cpaelzer: it was a skiptest hint so it can be removed anyway - thanks, I'll nuke that one and a number of others I had added (and rerun the tests)
<cpaelzer> slangasek: ok
<cpaelzer> slangasek: just wanted to make sure we don't skip too much forever
<apw> cpaelzer, na i just skiptest'd that one package to let it go, it had done all its other tests ok so that was safe
-queuebot:#ubuntu-release- New: accepted node-md5.js [sync] (artful-proposed) [1.3.4-1]
-queuebot:#ubuntu-release- New binary: node-md5.js [amd64] (artful-proposed/none) [1.3.4-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted node-md5.js [amd64] (artful-proposed) [1.3.4-1]
<slangasek> jbicha: you synced a gnome-boxes which has unsatisfiable build-deps?
<doko> slangasek: please could you override the failing snapcraft test triggered by lxml? it's unrelated, see https://forum.snapcraft.io/t/snapcraft-autopkgtest-failure/2007
 * LocutusOfBorg goes fixing gnome-boxes --> slangasek, jbicha 
 * LocutusOfBorg goes fixing gnome-dictionary and hopefully gnome-documents
<LocutusOfBorg> is publisher having a sad day?
<cjwatson> not particularly
<LocutusOfBorg> maybe just slow... I waited almost one hour, and some node stuff is still "accepted"
<cjwatson> couple of long runs but I think that's because it ended up publishing several stable pockets
<cjwatson> ah, daily Contents updates, that would explain it
<LocutusOfBorg> seems good now, thanks
<LocutusOfBorg> doko, sync python3.6?
<doko> LocutusOfBorg: no! please stop syncing for a while unnecessary stuff so that the autopkg testers can catch up
<LocutusOfBorg> doko, I'm *asking* not *syncing* :)
<doko> well, I see your answers on artful-changes ... :-/
<LocutusOfBorg> gnome-* is fixed now, and should not trigger tests
<LocutusOfBorg> netcdf was broken, I had to fix it
<LocutusOfBorg> boinc was broken by glibc
<LocutusOfBorg> I'm trying only to sync stuff without testsuite or to fix broken tests (e.g. mechanicalsoup I'm working right now)
<LocutusOfBorg> did you really fix llvm? <3
<jbicha> LocutusOfBorg: gnome-dictionary probably could have used a FFe
<jbicha> syncing gtranslator to matchâ¦
<LocutusOfBorg> I don't see new features in the diff
<jbicha> the problem is the removed libgdict library not added features
<jbicha> LP: #1715612
<ubot5`> Launchpad bug 1715612 in gnome-dictionary (Ubuntu) "FFe: Sync gnome-dictionary 3.25.90-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1715612
<Laney> I just mass-retried all the ppc64el/artful regressions
<Laney> now the the images should be fixed wrt cloud-init
<Laney> hopefully will get one or two more passes
<ahasenack> hi, I don't understand why my bind9 upload is stuck in artful-proposed ( 1:9.10.3.dfsg.P4-12.6ubuntu1). All tests that pass have passed, but there is this line of text: "Invalidated by dependency". What does that mean?
<ahasenack> I see that present in other entries
<Laney> you need to wait for the listed package to become a candidate
<ahasenack> glibc, so nothing else will get through until glibc becomes a candidate?
<ahasenack> I see a few "regressions" in the glibc entry
<ahasenack> that's the whole archive almost?
<acheronuk> nothing that version depends on it
<acheronuk> e.g. bind9 has multiple: Depends: libc6-udeb (>= 2.26)
<xnox> ahasenack, it is weird that .deb got >=2.15 dependency but udebs got 2.26. Is the udeb build somehow build differently with much higher symbols?
<xnox> or shlibdeps not calculated right?
<ahasenack> nothing like that was touched in this upload
<xnox> sure, but the build is done against a new glibc.
<ahasenack> let me download the binaries
<ahasenack> xnox: built against libc from a-proposed, right?
<xnox> ahasenack, yes... everything is build against proposed.
<xnox> always.
<xnox> ahasenack, note previous build is similarly broken. e.g. libisccfg-export140_9.10.3.dfsg.P4-12.5ubuntu1_amd64.deb depends on libc6 (>= 2.4) yet libisccfg-export140-udeb depends on libc6-udeb (>= 2.24)
<apw> that may be intentional of course
<xnox> imho, if the binaries are not built any different between .deb and .udeb cases, the dep may be bogus - or cunning.
<xnox> apw, right, if it is intentional, it is annoying =)
<xnox> hmmmm....
<xnox> apw, libc6-udeb does not ship symbols file i wonder if shlibs based udeb dependencies is even a thing?!
<apw> if it has no symbols that probably explains the link to the latest major version
<LocutusOfBorg> slangasek, I see you did some maven related work, do you have any clue for the failures?
<LocutusOfBorg> I'm trying to debug it, and seems Debian is indeed fine, rebuilds work there
<LocutusOfBorg> some version mismatch, but I didn't find it (yet)
<LocutusOfBorg> I see latest maven-* uploads in Debian changed and fixed some build/runtime dependencies, so maybe this is the clue
<doko> maybe ask before you upload?
<LocutusOfBorg> I still think I can solve it
<LocutusOfBorg> but I don't want to do the same job twice
<xnox> LocutusOfBorg, do you do local test builds before syncing?
<xnox> you should, we are post-feature freeze and post debian import freeze thus we have stopped importing things from debian en-masse.
<xnox> only specific targetted fixes should be synced, not in general anything that got uploaded.
<xnox> LocutusOfBorg, why do we need exec-maven-plugin 1.6.0-4?
<xnox> the changelog is irrelevant for ubuntu, at this point in the cycle no?
<xnox> LocutusOfBorg, why are you syncing so many minor updates? can they wait until 18.04 is open?
<xnox> e.g. https://launchpad.net/ubuntu/+source/gant/1.9.11-7 is minor update, not fixing any bugs.
-queuebot:#ubuntu-release- Unapproved: flashcache (xenial-proposed/universe) [3.1.3+git20150701-2ubuntu2 => 3.1.3+git20150701-2ubuntu3] (no packageset)
<slangasek> LocutusOfBorg, doko: no, I uploaded what I did to try to un-break the builds that were already stuck in -proposed; the packages I uploaded, if I installed the sid binaries, were enough to unbreak the build for me, but those themselves fail to build.  maven is some sort of bootstrap nightmare
<doko> slangasek, LocutusOfBorg: yes, I was trying to resolve that for 17.10. CCed you on the last email. I hope tdaitx picks this up
<slangasek> ok
<LocutusOfBorg> slangasek, I did try the bootstrap and it didn't work
<LocutusOfBorg> I mean, copy the debian package from debian, no change rebuild it, install and no change rebuild again
<LocutusOfBorg> it failed
<LocutusOfBorg> I'll have a deeper look after work
<tdaitx> doko, slangasek: just went through the log, yeah, I was looking into maven last night, had a late start today so I'm still picking up from yesterday
<LocutusOfBorg> thanks
<SpamapS> bdmurray: weird, so somehow doing 'debuild' on a xenial box is removing that gcc build-depends from the zesty python3.6 package. No idea why
 * SpamapS is building a zesty chroot to try it in now
-queuebot:#ubuntu-release- Unapproved: accepted xfsprogs [source] (zesty-proposed) [4.3.0+nmu1ubuntu4.1]
-queuebot:#ubuntu-release- Unapproved: accepted xfsprogs [source] (xenial-proposed) [4.3.0+nmu1ubuntu1.1]
<SpamapS> bdmurray: Hey, I figured out the build-dep thing. The rules file added that to the synced package from Debian, but when one builds the source package in Ubuntu, that gcc build-dep is not added. It's also not needed, it's for backports.
<SpamapS> bdmurray: so, if you haven't rejected the other one yet...
<SpamapS> oh I see it was rejected
 * SpamapS re-uploads
-queuebot:#ubuntu-release- Unapproved: python3.5 (zesty-proposed/main) [3.5.3-1 => 3.5.3-1ubuntu0~17.04.0] (core)
-queuebot:#ubuntu-release- Unapproved: accepted python3.5 [source] (zesty-proposed) [3.5.3-1ubuntu0~17.04.0]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-95.118] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-95.118]
#ubuntu-release 2017-09-09
<tdaitx> slangasek, I have a maven-compiler-plugin that works, it requires 2 builds to get a sane package out (or we can keep it down to a single build if we want to keep a override_dh_auto_configure in debian/rules)
<tsimonq2> slangasek: Mind checking if this is PEBKAC? :P bug 1716079
<ubot5`> bug 1716079 in debootstrap (Ubuntu) "debootstrap silently fails when bootstrapping to a directory name with spaces" [Medium,New] https://launchpad.net/bugs/1716079
<tsimonq2> (or anyone, for that matter...)
<jackpot51> I get the same behavior
<tsimonq2> jackpot51: Thanks :)
<jackpot51> tsimonq2, you may be interested in testing `cdebootstrap` for the same behavior
<tsimonq2> jackpot51: Nice catch, that's also affected
 * tsimonq2 added some more details
<jackpot51> That is good information
<slangasek> tdaitx: I'm fine with two builds for maven-compiler-plugin; just tell me what we should upload/sync and in what order
<slangasek> infinity: is xlocale.h meant to be gone with glibc 2.26?
<doko> slangasek: yes, that's what we concluded
<tdaitx> slangasek, gah, I was looking a bit deeper into it to write a good bug report, then I realized that either my fix is not enough or I haven't found the right order to build stuff... I can build maven-compiler-plugin with itself, but so far trying to build anything else is failing with a circular dependency error
<tdaitx> The POM for org.apache.maven.plugins:maven-compiler-plugin:jar:3.6.2 is invalid, transitive dependencies (if any) will not be available: Artifact relocations form a cycle: [org.apache.maven.plugins:maven-compiler-plugin:3.6.1, org.apache.maven.plugins:maven-compiler-plugin:3.6.2]
<slangasek> doko: ok
<tdaitx> doko, ^
<slangasek> tdaitx: heh, nice
<tdaitx> let me know if you already know the right order to rebuild stuff
<slangasek> what if you build it a third time? ;)
<tdaitx> assumming that it is what I am missing now
<tdaitx> slangasek, I did, with itself, it works =)
<tdaitx> slangasek, doko fixed the circular dependency, dumb mistake on the relocations
<tdaitx> slangasek, doko see LP: #1716095
<ubot5`> Launchpad bug 1716095 in maven-compiler-plugin (Ubuntu) "[FTBFS] maven-compiler-plugins fails to build due to hardcoded compiler version" [Undecided,New] https://launchpad.net/bugs/1716095
<doko> tdaitx: do you need that sponsored?
<tdaitx> yes
<doko> ok, doing
<tdaitx> after those are up, then a no change rebuild of maven-shade-plugin and than maven should unblock some stuff
<tdaitx> slangasek, doko ^
<doko> tdaitx: hmm, where is the -ubuntu1 package?
<doko> ahh, I see now
<tdaitx> doko, be mindful to upload just the first patch (ubuntu1), after it is build you can upload the second (ubuntu2)
<tdaitx> the first one should be enough to retry maven-shade-plugin, after it is done then retry maven
<tdaitx> it is pretty late now,  tomorrow I will look into what else we can retry to fix any other failing packages...
 * tdaitx -> EOD
-queuebot:#ubuntu-release- New binary: kitchensink-clojure [amd64] (artful-proposed/universe) [2.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-kubeclient [amd64] (artful-proposed/universe) [2.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted kitchensink-clojure [amd64] (artful-proposed) [2.3.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-kubeclient [amd64] (artful-proposed) [2.3.0-2]
-queuebot:#ubuntu-release- New binary: puppetlabs-i18n-clojure [amd64] (artful-proposed/universe) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: trapperkeeper-clojure [amd64] (artful-proposed/universe) [1.5.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted puppetlabs-i18n-clojure [amd64] (artful-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted trapperkeeper-clojure [amd64] (artful-proposed) [1.5.2-1]
-queuebot:#ubuntu-release- New binary: potemkin-clojure [amd64] (artful-proposed/universe) [0.4.3-1build1] (no packageset)
-queuebot:#ubuntu-release- New: accepted potemkin-clojure [amd64] (artful-proposed) [0.4.3-1build1]
-queuebot:#ubuntu-release- New binary: ssl-utils-clojure [amd64] (artful-proposed/universe) [0.8.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: stockpile-clojure [amd64] (artful-proposed/universe) [0.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ssl-utils-clojure [amd64] (artful-proposed) [0.8.3-1]
-queuebot:#ubuntu-release- New: accepted stockpile-clojure [amd64] (artful-proposed) [0.0.4-1]
-queuebot:#ubuntu-release- Unapproved: network-manager (zesty-proposed/main) [1.4.4-1ubuntu3.1 => 1.4.4-1ubuntu3.2] (kubuntu, ubuntu-desktop)
<LocutusOfBorg> doko, FYI I'm fixing libsejda-io-java, libsambox-java, libsejda-java
<LocutusOfBorg> they need some bootstrapping and the bad versioning for the runtime dependency
<doko> LocutusOfBorg: are you aware of the Debian bug report?
-queuebot:#ubuntu-release- New binary: clj-http-clojure [amd64] (artful-proposed/universe) [2.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: puppetlabs-http-client-clojure [amd64] (artful-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted clj-http-clojure [amd64] (artful-proposed) [2.3.0-1]
-queuebot:#ubuntu-release- New: accepted puppetlabs-http-client-clojure [amd64] (artful-proposed) [0.9.0-1]
<LocutusOfBorg> https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=libsejda-io-java I don't see it
<LocutusOfBorg> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874494
<ubot5`> Debian bug 874494 in src:libsambox-java "rebuilding libsambox-java generates unmet dependency on libsejda-io-java (>= 1.1.3.RELEASE)" [Serious,Open]
<LocutusOfBorg> seems that I followed the "remove suffix from pom"
<LocutusOfBorg> the problem is really in libsejda-io-java I would say
<LocutusOfBorg>  Depends: libcommons-io-java, libfontbox2-java (>= 2.0.7), libsejda-io-java (>= 1.1.3), libslf4j-java (>= 1.7.25)
<LocutusOfBorg> it works
-queuebot:#ubuntu-release- New binary: libsejda-java [amd64] (artful-proposed/universe) [2.10.4-2build1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libsejda-java [amd64] (artful-proposed) [2.10.4-2build1]
<LocutusOfBorg> yeah!
-queuebot:#ubuntu-release- New binary: ring-clojure [amd64] (artful-proposed/universe) [1.6.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dujour-version-check-clojure [amd64] (artful-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted dujour-version-check-clojure [amd64] (artful-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted ring-clojure [amd64] (artful-proposed) [1.6.2-1]
-queuebot:#ubuntu-release- New binary: bidi-clojure [amd64] (artful-proposed/universe) [2.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: compojure-clojure [amd64] (artful-proposed/universe) [1.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ring-headers-clojure [amd64] (artful-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: trapperkeeper-webserver-jetty9-clojure [amd64] (artful-proposed/universe) [1.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted bidi-clojure [amd64] (artful-proposed) [2.1.2-1]
-queuebot:#ubuntu-release- New: accepted ring-headers-clojure [amd64] (artful-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted compojure-clojure [amd64] (artful-proposed) [1.6.0-1]
-queuebot:#ubuntu-release- New: accepted trapperkeeper-webserver-jetty9-clojure [amd64] (artful-proposed) [1.7.0-1]
-queuebot:#ubuntu-release- New binary: comidi-clojure [amd64] (artful-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: puppetlabs-ring-middleware-clojure [amd64] (artful-proposed/universe) [1.0.0-1] (no packageset)
#ubuntu-release 2017-09-10
-queuebot:#ubuntu-release- New: accepted comidi-clojure [amd64] (artful-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted puppetlabs-ring-middleware-clojure [amd64] (artful-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New sync: trapperkeeper-scheduler-clojure (artful-proposed/primary) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted trapperkeeper-scheduler-clojure [sync] (artful-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New binary: trapperkeeper-scheduler-clojure [amd64] (artful-proposed/none) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted trapperkeeper-scheduler-clojure [amd64] (artful-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New binary: metrics-clojure [amd64] (artful-proposed/universe) [2.9.0-1build1] (no packageset)
-queuebot:#ubuntu-release- New: accepted metrics-clojure [amd64] (artful-proposed) [2.9.0-1build1]
-queuebot:#ubuntu-release- New sync: restorecond (artful-proposed/primary) [2.7-1]
-queuebot:#ubuntu-release- New sync: selinux-dbus (artful-proposed/primary) [2.7-2]
-queuebot:#ubuntu-release- New sync: semodule-utils (artful-proposed/primary) [2.7-1]
-queuebot:#ubuntu-release- New: accepted restorecond [sync] (artful-proposed) [2.7-1]
-queuebot:#ubuntu-release- New: accepted semodule-utils [sync] (artful-proposed) [2.7-1]
-queuebot:#ubuntu-release- New: accepted selinux-dbus [sync] (artful-proposed) [2.7-2]
-queuebot:#ubuntu-release- New binary: selinux-dbus [amd64] (artful-proposed/none) [2.7-2] (no packageset)
-queuebot:#ubuntu-release- New binary: semodule-utils [i386] (artful-proposed/none) [2.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: semodule-utils [s390x] (artful-proposed/none) [2.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: semodule-utils [amd64] (artful-proposed/none) [2.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: semodule-utils [ppc64el] (artful-proposed/none) [2.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: semodule-utils [arm64] (artful-proposed/none) [2.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: semodule-utils [armhf] (artful-proposed/none) [2.7-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted selinux-dbus [amd64] (artful-proposed) [2.7-2]
-queuebot:#ubuntu-release- New: accepted semodule-utils [arm64] (artful-proposed) [2.7-1]
-queuebot:#ubuntu-release- New: accepted semodule-utils [i386] (artful-proposed) [2.7-1]
-queuebot:#ubuntu-release- New: accepted semodule-utils [s390x] (artful-proposed) [2.7-1]
-queuebot:#ubuntu-release- New: accepted semodule-utils [amd64] (artful-proposed) [2.7-1]
-queuebot:#ubuntu-release- New: accepted semodule-utils [ppc64el] (artful-proposed) [2.7-1]
-queuebot:#ubuntu-release- New: accepted semodule-utils [armhf] (artful-proposed) [2.7-1]
-queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.33 => 2.34] (no packageset)
-queuebot:#ubuntu-release- New sync: mcstrans (artful-proposed/primary) [2.7-1]
-queuebot:#ubuntu-release- New sync: selinux-python (artful-proposed/primary) [2.7-2]
-queuebot:#ubuntu-release- New: accepted mcstrans [sync] (artful-proposed) [2.7-1]
-queuebot:#ubuntu-release- New: accepted selinux-python [sync] (artful-proposed) [2.7-2]
<sergiusens> can someone please reject snapcraft 2.34 pushed to xenial-proposed?
#ubuntu-release 2018-09-03
<LocutusOfBorg> please remove ldc and its reverse-deps from ppc64el, upstream doesn't want to support that architecture, and Debian asked to remove them too https://github.com/ldc-developers/ldc/issues/2824
<gitbot> ldc-developers issue 2824 in ldc "Fails to build from source on ppc64el" [Open]
<acheronuk> anyone looking at the r-cran-rgenoud test regression with glibc? not sure what the issue is there. it's been too many years now since I did r type things, and I never used r even then
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (bionic-proposed) [1.93.5]
 * acheronuk shudders at the memory of finite element in fortran!
<ginggs> acheronuk: I did have a quick look, they seem to do the same calculation with and without a seed. https://salsa.debian.org/r-pkg-team/r-cran-rgenoud/blob/master/tests/testthat/test-genoud_fixed_seed.R#L92 https://salsa.debian.org/r-pkg-team/r-cran-rgenoud/blob/master/tests/testthat/test-genoud_no_given_seed.R#L84
<ginggs> with the new glibc, the results without a given seed are now closer to the old results with a seed
<ginggs> acheronuk: so adjusting the tolerance there might be safe, but it concerns me that the result only changed on amd64 and armhf
<ginggs> infinity: do you have any thoughts ^ ?  Is this expected?
<acheronuk> indeed
<LocutusOfBorg> btw with the new ldc we finally gained full arm64 support, while reverse-deps never really worked / compiled on ppc64el
-queuebot:#ubuntu-release- New binary: llvm-toolchain-snapshot [ppc64el] (cosmic-proposed/universe) [1:8~svn340819-1] (no packageset)
<mwhudson> acheronuk, ginggs: i've spent far to long poking at r-cran-rgenoud and have nfi what's going on
<mwhudson> it doesn't even call that many libc functions in its core loop
<ginggs> mwhudson, acheronuk: did either of you find a repo or bug tracker for r-cran-rgenoud?
<mwhudson> ginggs: no
<acheronuk> ginggs: seems like a one man thing to me
<mwhudson> it also has no rdeps so i hope some AA deletes it before i waste too much more time on it
<LocutusOfBorg> folks, please ignore symfony tests on armhf and s390x, they always failed, I did ignore test results because of deprecation warnings, and they started passing because of this reason... when I discovered that it was too late
<acheronuk> looks like the unseeded run is wrongly finding the max from the seeded one? fun
<acheronuk> ginggs: authors github? https://github.com/JasjeetSekhon/rgenoud
<acheronuk> 2 commits and out of date!
<ginggs> acheronuk: thanks, i couldn't find anything.  i'll drop them an email
<ginggs> the unseeded version just seems to pick a random number between 1 and 2^31 to use as a seed https://salsa.debian.org/r-pkg-team/r-cran-rgenoud/blob/master/R/rgenoud.R#L20 but all the failed tests fail with the same result
<acheronuk> fun that running unseeded in R locally with old glib mostly gives the same answer, but occasionally it does a swerve and finds one of the other maxima!
<acheronuk> so not sure I believe this is a hugely reliable test to start with
<acheronuk> https://paste.ubuntu.com/p/f3vtTNcw5t/ vs https://paste.ubuntu.com/p/mNqrRK2YXs/
<acheronuk> ^^ 2 following runs
-queuebot:#ubuntu-release- Unapproved: rax-nova-agent (xenial-proposed/universe) [2.1.15-0ubuntu1~16.04.0 => 2.1.15-0ubuntu1~16.04.1] (no packageset)
<LocutusOfBorg> cjwatson, hello, can you please ack/nack libapache-session-perl sync/merge? (I mean, is this add-recommended-packages change still needed now that Debian has autopkgtests? they even dropped debian/test/control in the last upload... )
<LocutusOfBorg> you did some of that perl changes, I'm merging them but I don't really know how to check if the bug is fixed or not... (and we have no ongoing perl transition fortunately)
<cjwatson> I'd rather it be merged, but the worst case if you sync it is that somebody will have to reinvent the same thing for the next perl transition
<cjwatson> so I don't care very deeply
-queuebot:#ubuntu-release- New binary: llvm-toolchain-snapshot [i386] (cosmic-proposed/universe) [1:8~svn340819-1] (no packageset)
<LocutusOfBorg> so cjwatson reintroduce that file and that's all?
<cjwatson> Sorry, I don't remember and am in the middle of two other things right now
<cjwatson> If it's a difficult merge due to the underlying file not existing any more, then just sync instead and we can sort it out later
<cjwatson> (if necessary)
<LocutusOfBorg> -Depends: @, pkg-perl-autopkgtest, libdbi-perl
<LocutusOfBorg> +Depends: @, pkg-perl-autopkgtest, libcgi-pm-perl, libdbi-perl
<LocutusOfBorg> this is the patch, in debian/test/control, but that file is now removed
<cjwatson> Just drop it and sync then
<LocutusOfBorg> it is recommended in the libapache-session-perl package, so maybe we can teach autopkgtest for perl to install recommends by default?
<cjwatson> It was a subtle problem and it's possible it's been fixed; if it hasn't then we'll likely need to fix it somewhere else anyway
<LocutusOfBorg> maybe debian did that...
<LocutusOfBorg>   [ gregor herrmann ]
<LocutusOfBorg>   * Remove debian/tests/control; add libdbi-perl to Recommends.
<LocutusOfBorg> the reason for adding libdbi-perl to recommends is similar, so maybe this is really already fixed
<LocutusOfBorg> in case we break on next perl transition, we will have a lot of "ubuntu1" previous packages in release, and we can quickly notice of the dropped delta, lets sync
<cjwatson> ack
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.34.2 => 2.35.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (bionic-proposed/main) [2.34.2+18.04 => 2.35.1+18.04] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.34.2~14.04 => 2.35.1~14.04] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-toolchain-snapshot [amd64] (cosmic-proposed/universe) [1:8~svn340819-1] (no packageset)
<LocutusOfBorg> slangasek, do you like the new diaspora-installer autopkgtest?
<LocutusOfBorg> I can't in pbuilder environment install the package, not sure why
<LocutusOfBorg> http://autopkgtest.ubuntu.com/packages/d/diaspora-installer/cosmic/amd64
<LocutusOfBorg> but it seems good, I'm tempted to remove the block
<mwhudson> hmm
<tsimonq2> hmm
<acheronuk> hmm
<mwhudson> looking at twisted/foolscap/txtorcon
<mwhudson> current situation is that there's a txtorcon in proposed that does not build a python 2 package
<mwhudson> but a previous upload built a totally broken one
<mwhudson> i _guess_ the thing to do is remove the broken one and upload a txtorcon-for-python-2 source package that is the old txtorcon source
<mwhudson> but all this requires an AA to sort out
<mwhudson> well unless txtorcon-for-python-2 gets a ridiculous dishonest version i guess but well
#ubuntu-release 2018-09-04
-queuebot:#ubuntu-release- Unapproved: widelands (bionic-proposed/universe) [1:19+repack-4build4 => 1:19+repack-4ubuntu0.18.04.1] (no packageset)
 * tsimonq2 really thinks glibc needs to be kicked through...
<tsimonq2> hmm
-queuebot:#ubuntu-release- Unapproved: gnome-games-app (bionic-proposed/universe) [3.28.0-1 => 3.28.0-1ubuntu1] (no packageset)
<mwhudson> tsimonq2: yeah i think so too
<mwhudson> about to write a mail about the two test failures in fact
<tsimonq2> Yeah.
<mwhudson> this has involved learning more about the x87 than i ever wanted to know :)
<mwhudson> tsimonq2: https://lists.ubuntu.com/archives/ubuntu-devel/2018-September/040480.html
<tsimonq2> mwhudson: Yup, I saw :)
<tsimonq2> Wonderful.
<mwhudson> all hail the x87
<tsimonq2> hahaha
<mwhudson> oh god what is happening with python-cffi on ppc64el now
<tsimonq2> mwhudson: It's FTBFS in -proposed.
<tsimonq2> Might be the same as Debian's FTBFS, might not be.
<tsimonq2> Â¯\_(ã)_/Â¯
-queuebot:#ubuntu-release- Unapproved: gnome-software (xenial-proposed/main) [3.20.5-0ubuntu0.16.04.11 => 3.20.5-0ubuntu0.16.04.12] (ubuntu-desktop)
<mwhudson> well yes it ftbfs and it involves floats
<mwhudson> and yes looks the same as debian
<mwhudson> ppc64el isn't as gratuitously strange about floats as i386 though
<mwhudson> i hope this isn't a compiler bug :(
<mwhudson> well it doesn't happen with gcc-7 or with gcc-8 at -O0 but it happens at -O1 or higher
<mwhudson> i think it's a compiler bug :(
<slangasek> LocutusOfBorg: sure; why is this '~build1' though?
<LocutusOfBorg> slangasek, because I'll upload a "final version" as soon as I'm happy :)
<LocutusOfBorg> and meh, I don't want a same version coming from debian and different content
<LocutusOfBorg> so, in case I'll try to push in Debian too
<LocutusOfBorg> apw, can you please clean up this NBS-proposed foo? old binaries left on amd64: libc++-7-helpers (from 1:7~+rc2-1~exp2ubuntu1)
<LocutusOfBorg> it is not even part of release
<apw> LocutusOfBorg, done
<LocutusOfBorg> thanks apw !
<LocutusOfBorg> can I please ask you an hint?
<LocutusOfBorg> [12:48:22] <LocutusOfBorg> folks, please ignore symfony tests on armhf and s390x, they always failed, I did ignore test results because of deprecation warnings, and they started passing because of this reason... when I discovered that it was too late
<LocutusOfBorg> it passed on armhf and s390x because I ignored test results, so not a regression at all
<LocutusOfBorg> (and if you hint, I promise I'll try to sort also the failing architectures, but this seems to be really non trivial)
-queuebot:#ubuntu-release- New source: smc-tools (cosmic-proposed/primary) [1.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-snapshot [amd64] (cosmic-proposed) [1:8~svn340819-1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-snapshot [i386] (cosmic-proposed) [1:8~svn340819-1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-snapshot [arm64] (cosmic-proposed) [1:8~svn340819-1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-snapshot [ppc64el] (cosmic-proposed) [1:8~svn340819-1]
-queuebot:#ubuntu-release- New: accepted neutron-taas [amd64] (cosmic-proposed) [4.0.0~a1~git2018083141.84846d5-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted vmware-nsx [amd64] (cosmic-proposed) [13.0.0-0ubuntu1]
<ahasenack> hi guys, I'm adding dep8 tests to the sssd package, it has none currently
<ahasenack> but I'm being hit by the glibc migration. My bileto dep8 tests use the release pocket, not proposed, and dependencies are uninstallable
<ahasenack> and I can't retrigger the sssd tests because, since there were never any, the state is "always failed"
<ahasenack> so I can't mangle the url to include proposed
<ahasenack> any ideas? Just wait for the glibc migration to complete? Or upload anyway and hope for the best?
<ahasenack> https://bileto.ubuntu.com/excuses/3399/cosmic.html ticket in question
<LocutusOfBorg> ahasenack, I retried against proposed
<LocutusOfBorg> https://autopkgtest.ubuntu.com/request.cgi?release=cosmic&arch=s390x&package=freeipa&trigger=sssd%2F1.16.3-1ubuntu1~ppa2&ppa=ci-train-ppa-service%2Fstable-phone-overlay&ppa=ci-train-ppa-service%2F3399&all-proposed=1
<LocutusOfBorg> this seems to have worked
<ahasenack> oh, cool,
<ahasenack> will https://bileto.ubuntu.com/excuses/3399/cosmic.html refresh eventually, or is that retry invisible to bileto?
<LocutusOfBorg> oh, I retried freeipa :/
<ahasenack> well, that one would need a retry too, but it had tests already
<Laney> retry-autopkgtest-regressions --ticket NNNN --series cosmic --state ALWAYSFAIL
<Laney> FYI
<Laney> --bileto not --ticket
<ahasenack> Laney: where is that script?
<Laney> ubuntu-archive-tools
<Laney> lp:
<Laney> bzr
-queuebot:#ubuntu-release- Unapproved: sshuttle (xenial-proposed/universe) [0.76-1 => 0.76-1ubuntu1] (no packageset)
 * Laney writes easy to understand lines
<ahasenack> yoda master :)
-queuebot:#ubuntu-release- Unapproved: sshuttle (bionic-proposed/universe) [0.78.3-1 => 0.78.3-1ubuntu1] (no packageset)
<LocutusOfBorg> ahasenack, I would have uploaded a version with exit 0 in testsuite just to have a previous success :)
<ahasenack> LocutusOfBorg: interesting idea. Would that have worked with the bileto ticket as well?
<LocutusOfBorg> I guess so :)
<ahasenack> LocutusOfBorg: but in this case, the dependencies won't install
<ahasenack> it doesn't even start the test
<LocutusOfBorg> Laney, it can't work
<LocutusOfBorg> because it creates a invalid trigger
<LocutusOfBorg> You submitted an invalid request: Package sssd does not have any test results
<LocutusOfBorg> ./retry-autopkgtest-regressions --bileto 3399 --series cosmic --state ALWAYSFAIL
<LocutusOfBorg> https://autopkgtest.ubuntu.com/request.cgi?release=cosmic&arch=amd64&package=sssd&trigger=sssd%2F1.16.3-1ubuntu1%7Eppa2&ppa=ci-train-ppa-service%2Fstable-phone-overlay&ppa=ci-train-ppa-service%2F3399
<Laney> weird, it clearly does
<Laney> feel free to debug that
<ahasenack> hi release team, I got an email about my samba sru kicking in the phasing stop trigger, https://errors.ubuntu.com/?release=Ubuntu%2014.04&package=samba&period=day&version=2%3A4.3.11%2Bdfsg-0ubuntu0.14.04.17
<ahasenack> if my reading of that is correct, there were just two new crashes? I see "2 U" in https://errors.ubuntu.com/bucket/?id=/usr/sbin/winbindd%3A6%3Adump_core%3Asmb_panic_s3%3Asmb_panic%3Awinbind_messaging_context%3Amain
<ahasenack> the crashes seem to be about something very basic, like /var/lib/samba not existing, or an apparmor profile denying access to that dir, so I would need logs to debug
<ahasenack> given there are just two, I think we should let the phasing continue
<ahasenack> bdmurray: hi, when you have a moment, about the samba trusty sru phasing alert that I wrote above
<bdmurray> ahasenack: looking
<bdmurray> ahasenack: Okay, I'll get the phasing to continue.
<ahasenack> bdmurray: it looks good on xenial, and it's the same version of samba with the same fix. But different build environment, of course
-queuebot:#ubuntu-release- New binary: intel-processor-trace [i386] (cosmic-proposed/main) [2.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: intel-processor-trace [amd64] (cosmic-proposed/main) [2.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syn [amd64] (cosmic-proposed/universe) [0.14.6-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted intel-processor-trace [amd64] (cosmic-proposed) [2.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted rust-syn [amd64] (cosmic-proposed) [0.14.6-1]
-queuebot:#ubuntu-release- New binary: rust-syn [s390x] (cosmic-proposed/universe) [0.14.6-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted intel-processor-trace [i386] (cosmic-proposed) [2.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: rust-syn [ppc64el] (cosmic-proposed/universe) [0.14.6-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-syn [ppc64el] (cosmic-proposed) [0.14.6-1]
-queuebot:#ubuntu-release- New: accepted rust-syn [s390x] (cosmic-proposed) [0.14.6-1]
-queuebot:#ubuntu-release- Unapproved: accepted brltty [source] (bionic-proposed) [5.5-4ubuntu2.0.1]
-queuebot:#ubuntu-release- New binary: rust-serde-derive [ppc64el] (cosmic-proposed/universe) [1.0.70-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-serde-derive [s390x] (cosmic-proposed/universe) [1.0.70-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-serde-derive [amd64] (cosmic-proposed/universe) [1.0.70-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-serde-derive [armhf] (cosmic-proposed/universe) [1.0.70-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-serde-derive [i386] (cosmic-proposed/universe) [1.0.70-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-serde-derive [arm64] (cosmic-proposed/universe) [1.0.70-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-serde-derive [amd64] (cosmic-proposed) [1.0.70-1]
-queuebot:#ubuntu-release- New: accepted rust-serde-derive [armhf] (cosmic-proposed) [1.0.70-1]
-queuebot:#ubuntu-release- New: accepted rust-serde-derive [ppc64el] (cosmic-proposed) [1.0.70-1]
-queuebot:#ubuntu-release- New: accepted rust-serde-derive [arm64] (cosmic-proposed) [1.0.70-1]
-queuebot:#ubuntu-release- New: accepted rust-serde-derive [s390x] (cosmic-proposed) [1.0.70-1]
-queuebot:#ubuntu-release- New: accepted rust-serde-derive [i386] (cosmic-proposed) [1.0.70-1]
<jbicha> slangasek: does bug 1766575 still feel appropriate to you for someone to SRU to bionic?
<ubot5> bug 1766575 in gnome-control-center (Ubuntu Bionic) "Drop libnss-myhostname recommends" [Low,Triaged] https://launchpad.net/bugs/1766575
<slangasek> jbicha: I'm not sure I can justify it now
<jbicha> ok, I'll wontfix it there, but at least it's fixed in cosmic
-queuebot:#ubuntu-release- New binary: s390-tools [s390x] (cosmic-proposed/main) [2.6.0-0ubuntu4] (core)
-queuebot:#ubuntu-release- New binary: tboot [amd64] (cosmic-proposed/universe) [1.9.7-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted s390-tools [s390x] (cosmic-proposed) [2.6.0-0ubuntu4]
-queuebot:#ubuntu-release- New: accepted tboot [amd64] (cosmic-proposed) [1.9.7-0ubuntu1]
<ahasenack> hi, the general advice for packages stuck in migration due to "Invalidated by dependency" because of glibc, is to wait for glibc to migrate?
<slangasek> ahasenack: or if you prefer, fix the r-cran-rgenoud autopkgtest regression ;)
<ahasenack> let me check
<slangasek> ahasenack: I mean, see the thread on ubuntu-devel first, mwhudson already took a swing at it
<ahasenack> isn't that what mwhudson emailed ubuntu-devel
<ahasenack> yeah
<ahasenack> the python one seems to have been fixed upstream
<ahasenack> after mwhudson's poke
<ahasenack> there is a gpg2 failure too, but that seems to just need -proposed enabled for its run
<slangasek> infinity: based on mwhudson's analysis, I think it's correct for us to badtest python-cffi 1.11.5-1build1 (we've confirmed it's a bad test, fixing it is only blocked on the ppc64el build failure).  What do you think of r-cran-rgenoud?
<slangasek> ahasenack: there's no gpg2 failure blocking glibc
<slangasek> hmm
<slangasek> or there WASN'T
<ahasenack> autopkgtest for gnupg2/2.2.8-3ubuntu1: amd64: Regression â» , i386: Pass
<ahasenack> one of the reds
<slangasek> this was a never-passed-before test that has now failed
<slangasek> so I will bypass that as necessary
<ahasenack> oh, and it is using proposed
<slangasek> yeah the problem specifically is that once p-m sees a passing result for a test, it considers all other failures to be "regressions", even if the pass happens at a later point in time and with a later package version
<slangasek> and the gnupg2 autopkgtest fails because it's trying to install i386 multiarch packages, what the hell
<slangasek> so r-cran-arglebargle is the only blocker from my POV
<doko> $ reverse-depends src:r-cran-arglebargle
<doko> reverse-depends: Error: <p>Unknown package</p>
<doko> -rgenoud? no rdeps, could be removed
<slangasek> yes, rgenoud but it's pronounced 'arglebargle'
<slangasek> yes it could be removed
<slangasek> "it could be removed" != "we're confident this isn't a bug in glibc"
<infinity> slangasek: I'm going to upload a python-cffi that passes its testsuite, my opinion on r-cran-genoud is that it's a crap test, based on reading scrollback from various people trying to understand it better. :P
<infinity> I think I'm okay just badtesting it (or demoting it if the testsuite also runs in the build and this makes it FTBFS now)
<ginggs> slangasek, infinity: r-cran-rgenoud doesn't run its testsuite during the build and doesn't FTBFS now.  I emailed upstream yesterday, but no response yet.
<slangasek> ok
<slangasek> infinity: ^^ based on all the above, I'm going to badtest the existing failures to unblock glibc, and python-cffi fix can land when it lands
<infinity> slangasek: WFM, py-cffi is uploading now, but it would be another coupe of hours for all the test turnaround.
<infinity> That's right, a two door car filled with hours.
-queuebot:#ubuntu-release- Unapproved: python-cffi (bionic-proposed/main) [1.11.5-1 => 1.11.5-2ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server)
<infinity> Erm.
<infinity> I live in the past.
-queuebot:#ubuntu-release- Unapproved: rejected python-cffi [source] (bionic-proposed) [1.11.5-2ubuntu1]
<infinity> slangasek: All in all, I can't tell for sure if it's because our tests are slowly getting less crap or glibc just didn't break many people this time around by becoming more standards-compliant, but this felt rather smooth.
<slangasek> infinity: indeed
<infinity> Oh, FFS upstream, really?
-queuebot:#ubuntu-release- Unapproved: gnu-efi (bionic-proposed/main) [3.0.4-2 => 3.0.8-0ubuntu1~18.04.1] (core)
<slangasek> LocutusOfBorg: I'm surprised by the NMU of a-c-c, my patch was not particularly good.  What was it impacting in Debian to warrant such a speedy NMU?
-queuebot:#ubuntu-release- Unapproved: gnu-efi (xenial-proposed/main) [3.0.2-1ubuntu1 => 3.0.8-0ubuntu1~16.04.1] (core)
<tsimonq2> Thanks for glibc!
-queuebot:#ubuntu-release- Unapproved: gnu-efi (trusty-proposed/main) [3.0u+debian-1ubuntu2 => 3.0.8-0ubuntu1~14.04.1] (core)
<LocutusOfBorg> slangasek, the fact that I don't want to have a delta for such package, I also forwarded all the patches upstream (with your authorship), so they can merge/improve and then sync back
<slangasek> ...
<LocutusOfBorg> I don't see the reason for such a delta, we have the toolchain in sync
<LocutusOfBorg> I had to do lots of ubuntu uploads in the past, they have been pita
<LocutusOfBorg> 4 of 5 patches were upstreamable as-is
<slangasek> well, I think that's a questionable rationale for an NMU but that's between you and the maintainer then
<LocutusOfBorg> lowNMU threshold, the maintainer *never* answered to me in *years*
<LocutusOfBorg> I did 4-5 NMUs for it
<LocutusOfBorg> with the delay, and now I stopped caring, I'm basically maintaining it with NMUs in Debian :)
<slangasek> ok
<LocutusOfBorg> slangasek, question: I see ganeti has a test failure on ppc64el, but this "autopkgtest [16:48:37]: test unittests: preparing testbed" is somewhere a new test...
<LocutusOfBorg> oh indeed, maybe we can just skip it, it has been probably failing since the begin
 * LocutusOfBorg will double check tomorrow
 * LocutusOfBorg g'night!
<slangasek> anyway, my patch was a quick-n-dirty implementation that was good enough to unblock autopkgtests but not something I would suggest committing upstream as-is, so hopefully we get some feedback
<slangasek> new test... yeah that's a bug in how p-m interprets "regression"
<LocutusOfBorg> ack, seems legit
<LocutusOfBorg> infinity, I'm really worried about glibc and libidn2...
<LocutusOfBorg> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905448
<ubot5> Debian bug 905448 in src:libidn "libidn: Please package libidn2 2.0.5" [Wishlist,Open]
<LocutusOfBorg> glibc 2.28 has replaced its own internal forked idn implementation by
<LocutusOfBorg> libidn2. However it requires at least version 2.0.5, while the version
<LocutusOfBorg> in Debian testing/unstable is 2.0.4.
<LocutusOfBorg> should we sync libidn2?
<infinity> LocutusOfBorg: Yes, yes we should.  I was waiting for that upload, but didn't notice it happening.
<infinity> LocutusOfBorg: "Really worried" is a bit far, mind you. :)
<infinity> LocutusOfBorg: But yes, we should sync to a version that doesn't suck.
 * infinity does so.
<infinity> LocutusOfBorg: Done.
 * infinity goes to grab food.
-queuebot:#ubuntu-release- Unapproved: shim (bionic-proposed/main) [13-0ubuntu2 => 15+1533136590.3beb971-0ubuntu1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: shim (xenial-proposed/main) [13-0ubuntu2 => 15+1533136590.3beb971-0ubuntu1] (core) (sync)
<mwhudson> infinity: so now that python-cffi built, glibc should migrate in the next few hours?
<mwhudson> or will there be stuff that needs rebuilding still
<slangasek> mwhudson: already migrated
<slangasek> I badtested old python-cffi
<mwhudson> oh
<mwhudson> awesomesauce
<slangasek> since we established it was a bad test
<slangasek> and I'm a literalist
<mwhudson> heh
<mwhudson> oh that makes sense
<mwhudson> the one in proposed was busted
<mwhudson> but the one in release was just a bogus test
-queuebot:#ubuntu-release- Unapproved: shim-signed (bionic-proposed/main) [1.34.9.2 => 1.37~18.04.1] (core)
<tsimonq2> Woo, below 500 packages in -proposed! \o/
<tsimonq2> 470 as of a few mins ago...
<tsimonq2> gnupg2 should probably migrate once the freeipa/4.7.0~pre1+git20180411-2ubuntu2/i386 test passes; it was depwait because of some python-cffi fun Adam and Steve already dealt with.
<tsimonq2> Bad snapd tests are bad, no wonder why they fail:
<tsimonq2> # cd .; git clone https://github.com/snapcore/spread /tmp/go/src/github.com/snapcore/spread
<tsimonq2> Cloning into '/tmp/go/src/github.com/snapcore/spread'...
<tsimonq2> fatal: unable to access 'https://github.com/snapcore/spread/': Operation timed out after 300027 milliseconds with 0 out of 0 bytes received
<tsimonq2> The real question is why this hasn't failed before...
<tsimonq2> But that should get systemd to migrate...
<xnox> slangasek, could you please skiptest systemd? it is all green, but snapd.
<xnox> slangasek, the snapd in cosmic-release tests regressed due to changes in core/base snaps.
<xnox> slangasek, the snapd in proposed appears to be regressed for other reasons at the moment.
<tsimonq2> Ah :)
<tsimonq2> xnox: Jinx? :)
<xnox> tsimonq2, i do not read your messages, no. =)
<tsimonq2> xnox: hehe
<xnox> i simply noticed emails re:glibc being pushed through.
<tsimonq2> Right.
<tsimonq2> xnox: Plus my hacky graph showed it :) https://pmstats.lubuntu.me/
<slangasek> xnox: done
<mwhudson> what's stopping twisted migrating now?
<mwhudson> oh maybe it just went
<mwhudson> yep
<mwhudson> rbalint: well done :)
-queuebot:#ubuntu-release- Unapproved: vlc (bionic-proposed/universe) [3.0.3-1-1ubuntu1 => 3.0.4-1ubuntu0.1] (kubuntu, mozilla)
#ubuntu-release 2018-09-05
<wxl> hey where would i go to to point out that lxd images don't seem to be available as of the 1st?
<wxl> (for cosmic)
<Ukikie> They've removed it from repos, they want you to use the 'snap'..
<wxl> i'm not talking about the lxd packages
<wxl> i'm talking about the actual images
<wxl> i.e. `lxc image list ubuntu-daily: | grep cosmic | grep 20180903` returns nothing
<wxl> oddly they are at images.linuxcontainers.org
 * wxl scratches his head
<wxl> oops s/cosmic/18\.10/
<Ukikie> Ah.
<slangasek> wxl: 'ubuntu-daily' does not necessarily mean that they're produced daily; as http://cloud-images.ubuntu.com/cosmic/ shows, there were no new images between the 1st and the 4th, and the ones from today may not have made their way through the importing process yet
<slangasek> (indeed, these images are generally expected to be trigger-based in responses to changes in the image contents, and there may have been no changes in the past few days on account of glibc)
<wxl> slangasek: ok, that makes sense.
<wxl> slangasek: fwiw i've been trying to monitor a weird situation i've run into where the last few images have not had a network connection, at least with lxd 3.0.1-0ubuntu1~18.04.1
<slangasek> hmm
<wxl> the one from the 26th works fine
<slangasek> only with the cosmic images?
<wxl> i tried bionic and had no such issues
<wxl> although i wonder if i didn't install a release version rather than a daily
<wxl> let me try to remember to command to figure that out
<wxl> yep i tried 20180831 bionic and all was well
<wxl> interestingly, i had a working container that i made the mistake of enabling proposed on and then doing an upgrade. i managed to do some pinning and used apt-offline to get it back to release state, but it didn't fix the issue. i think whatever broke managed to migrate to release
-queuebot:#ubuntu-release- Unapproved: accepted gnu-efi [source] (bionic-proposed) [3.0.8-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnu-efi [source] (xenial-proposed) [3.0.8-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnu-efi [source] (trusty-proposed) [3.0.8-0ubuntu1~14.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected shim [sync] (trusty-proposed) [13-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted shim-signed [sync] (trusty-proposed) [1.33.1~14.04.1]
<acheronuk> 07:04:10 /usr/bin/ruby: relocation error: /lib/x86_64-linux-gnu/libnss_files.so.2: symbol __libc_readline_unlocked version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference
-queuebot:#ubuntu-release- Unapproved: shim (trusty-proposed/main) [0.9+1474479173.6c180c6-1ubuntu1 => 13-0ubuntu2] (core) (sync)
<acheronuk> does ruby 2.5 need a rebuild?
<slangasek> that looks like you have a running process that needs restarted when glibc is upgraded due to loading of NSS modules at runtime
-queuebot:#ubuntu-release- Unapproved: accepted shim [sync] (trusty-proposed) [13-0ubuntu2]
<acheronuk> it's in a docker image build, so not sure how that would work
<slangasek> well, /lib/x86_64-linux-gnu/libnss_files.so.2 comes from the libc6 package and should never be out of sync on the filesystem
<acheronuk> seems to be upgrading libc ok https://kci.pangea.pub/view/bionic%20FIX/job/mgmt_docker/label=master/2455/console
<LocutusOfBorg> infinity, everything I don't understand worries me :) thanks for caring!
<doko> apw: please have a look at the linux autopkg test failure triggered by gcc-7?
<doko> slangasek: I have seen such messages as well, but not yet on the buildd. Involving libpthread
<LocutusOfBorg> [09:00:19] <BTS> Opened #908013 (serious) in src:libindicator 0.5.0-3 by Adrian Bunk (bunk) Â«libindicator FTBFS with glib 2.58Â». https://bugs.debian.org/908013
<LocutusOfBorg> [09:00:26] <BTS> Opened #908014 (serious) in src:libldm 0.2.4-1 by Adrian Bunk (bunk) Â«libldm FTBFS with glib 2.58Â». https://bugs.debian.org/908014
<ubot5> Debian bug 908013 in src:libindicator "libindicator FTBFS with glib 2.58" [Serious,Open]
<ubot5> Debian bug 908014 in src:libldm "libldm FTBFS with glib 2.58" [Serious,Open]
<LocutusOfBorg> src:libqmi  src:network-manager-iodine and so on...
<LocutusOfBorg> are we sure syncing glib was a good idea?
<seb128> LocutusOfBorg, you would have preferred to stay on an unstable version than do the update to the stable release?
<Laney> don't make deprecations into build errors
<LocutusOfBorg> seb128, I trust you as usual, just I'm worried about all the packages that now needs fixes... for sure moving from snapshot to stable is good, maybe adding a patch to avoid reverse-deps FTBFS was worth the effort?
<seb128> there is probably not that many packages that error out on deprecation warnings and those are easy enough to fix
<Laney> we're not going to un-deprecate a function in a distro patch
<juliank> hmm
<juliank> cosmic:
<juliank>  sbuild-build-depends-packagekit-dummy : Depends: libgtk-3-dev (>= 3.2) but it is not going to be installed
<juliank> for https://launchpad.net/ubuntu/+source/packagekit/1.1.10-1ubuntu5
<juliank> what broke?
<Laney> it's probably skew with the recently uploaded gtk+3.0
<juliank> yeah
<juliank> amd64 builds and does not have the gtk published yet
<juliank> probably that's the reason - libgtk-3-common missing
<juliank> so should work again once it's published
<Laney> indeedies
-queuebot:#ubuntu-release- Unapproved: xorg-server (bionic-proposed/main) [2:1.19.6-1ubuntu4 => 2:1.19.6-1ubuntu4.1] (desktop-core, xorg)
-queuebot:#ubuntu-release- Unapproved: xorg-server-hwe-16.04 (xenial-proposed/main) [2:1.19.6-1ubuntu4~16.04.1 => 2:1.19.6-1ubuntu4.1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected xorg-server-hwe-16.04 [source] (xenial-proposed) [2:1.19.6-1ubuntu4.1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: xorg-server-hwe-16.04 (xenial-proposed/main) [2:1.19.6-1ubuntu4~16.04.1 => 2:1.19.6-1ubuntu4.1~16.04.1] (no packageset)
<ahasenack> hi, does anybody know if the dep8 test runners mount filesystems with noexec perhaps? I'm debugging this error:
<ahasenack> + debian/tests/login.exp testuser1 testuser1kerberos testuser1@EXAMPLE.COM
<ahasenack>  /tmp/autopkgtest.cRVUhE/build.cWY/src/debian/tests/ldap-user-group-krb5-auth: 57: /tmp/autopkgtest.cRVUhE/build.cWY/src/debian/tests/ldap-user-group-krb5-auth: debian/tests/login.exp: Permission denied
<ahasenack> that script is +x, and it worked in lxd and kvm locally
<apw> ahasenack, we have executable tests in the kernel package, and they run ok, so i don't think that file can be on a noexec filesystem
<ahasenack> it's odd
<ahasenack> I'm calling it with the interpreter in the command line now, will see
<apw> ahasenack, the form of that error seems odd to me, the repeat of the krb5-auth in particular
<ahasenack> yeah
-queuebot:#ubuntu-release- Unapproved: openvpn (bionic-proposed/main) [2.4.4-2ubuntu1 => 2.4.4-2ubuntu1.1] (ubuntu-server)
-queuebot:#ubuntu-release- New: accepted smc-tools [source] (cosmic-proposed) [1.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: smc-tools [ppc64el] (cosmic-proposed/none) [1.1.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: smc-tools [s390x] (cosmic-proposed/none) [1.1.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: smc-tools [i386] (cosmic-proposed/none) [1.1.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: smc-tools [amd64] (cosmic-proposed/none) [1.1.0-0ubuntu1] (no packageset)
<doko> LocutusOfBorg: I saw your diffoscope and cmake-extras uploads. do you follow-up on these?
-queuebot:#ubuntu-release- New binary: smc-tools [arm64] (cosmic-proposed/universe) [1.1.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: smc-tools [armhf] (cosmic-proposed/universe) [1.1.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted smc-tools [amd64] (cosmic-proposed) [1.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted smc-tools [armhf] (cosmic-proposed) [1.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted smc-tools [ppc64el] (cosmic-proposed) [1.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted smc-tools [arm64] (cosmic-proposed) [1.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted smc-tools [s390x] (cosmic-proposed) [1.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted smc-tools [i386] (cosmic-proposed) [1.1.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libvirt (bionic-proposed/main) [4.0.0-1ubuntu8.4 => 4.0.0-1ubuntu8.5] (ubuntu-server, virt)
<LocutusOfBorg> doko, diffoscope is sad, I asked mapreri to help me
<LocutusOfBorg> I don't know why, so if you want to help it is appreciated, because I think I'll stop there
<LocutusOfBorg> (it is quick and easy to fix the test, but the problem is that I don't understand why it changed, and it might be an llvm issue)
<doko> and cmake-extras?
<LocutusOfBorg> (the new diffoscope fom debian FTBFS even before)
<LocutusOfBorg> cmake-extras just needed a no change rebuild and is good already
<doko> but the autopkg tests still fail?
<LocutusOfBorg> damn it is not
<LocutusOfBorg> indeed
<LocutusOfBorg> let me check
<doko> ta
<LocutusOfBorg> ok fixed.
<LocutusOfBorg> doko, btw, FYI https://salsa.debian.org/debian-ayatana-team/cmake-extras/commit/0a0439c6a565c5c20143a236d6c6b9c799d418be
<LocutusOfBorg> this is the reason for me introducing the new python-clang metapackage
<LocutusOfBorg> but I only fixed git, never uploaded
<ahasenack> apw: I switched that call to this, and tests are green now: + /usr/bin/expect -f debian/tests/login.exp testuser1 testuser1kerberos testuser1@EXAMPLE.COM
<doko> xnox: libu2f: that seeding helped
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (bionic-proposed/main) [1:18.04.25 => 1:18.04.26] (core)
 * slangasek tries to figure out what's going on with llvm versions in cosmic main :P
<ahasenack> infinity: hi, do you think squid4 for cosmic is still doable? We are 2w into feature freeze
<ahasenack> https://launchpad.net/ubuntu/cosmic/+queue?queue_state=0&queue_text=squid
<teward> can a release team member review an FFe request for NGINX 1.15.3, and either ACK (so I can upload) or NACK it?  Primary "feature change" is minor, the primary drive to get this in is the bugfixes to the WebDAV module from upstream.
<teward> (LP #1790149)
<ubot5> Launchpad bug 1790149 in nginx (Ubuntu) "[FFe needed] Update NGINX in Cosmic to 1.15.3 for bugfixes" [Wishlist,New] https://launchpad.net/bugs/1790149
-queuebot:#ubuntu-release- Unapproved: nautilus (bionic-proposed/main) [1:3.26.3-0ubuntu4 => 1:3.26.4-0~ubuntu18.04.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New sync: pipewire (cosmic-proposed/primary) [0.2.2-1]
-queuebot:#ubuntu-release- New sync: fontpens (cosmic-proposed/primary) [0.1.0-1]
-queuebot:#ubuntu-release- New sync: ufonormalizer (cosmic-proposed/primary) [0.3.5-1]
-queuebot:#ubuntu-release- New sync: python-osc-placement (cosmic-proposed/primary) [1.3.0-1]
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.18 => 2.02~beta2-36ubuntu3.19] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (trusty-proposed/main) [2.02~beta2-9ubuntu1.15 => 2.02~beta2-9ubuntu1.16] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.4 => 2.02-2ubuntu8.5] (core)
<LocutusOfBorg> slangasek, seems doko trying to get llvm7 in main and llvm6 in universe
<doko> yes, as in every release cycle
<LocutusOfBorg> but llvm 6 will go out once mesa is fixed
<LocutusOfBorg> and also doxygen, and defaults...
<doko> doxygen is fixed
<doko> mesa is on the way
<LocutusOfBorg> oh nice!
<LocutusOfBorg> so we need diffoscope and we are goo
<LocutusOfBorg> *good
<LocutusOfBorg> and also an llvm-7 stable maybe... it should be released today, but they are usually one month late...
<doko> that's ok. we don't have many dependencies
<LocutusOfBorg> you should also care about end user installing a snapshot rc compiler as default
<LocutusOfBorg> please any AA kill anbox from cosmic https://bugs.launchpad.net/ubuntu/+source/anbox/+bug/1780655
<ubot5> Ubuntu bug 1780655 in anbox (Ubuntu) "RoM: please remove this from ubuntu, doesn't work" [Undecided,New]
-queuebot:#ubuntu-release- Unapproved: grub2 (cosmic-proposed/main) [2.02+dfsg1-5ubuntu2 => 2.02+dfsg1-5ubuntu2] (core)
<slangasek> LocutusOfBorg: done
<slangasek> doko: did you also promote python-django-babel?  Did this not need an MIR?
-queuebot:#ubuntu-release- Unapproved: grub2 (cosmic-proposed/main) [2.02+dfsg1-5ubuntu2 => 2.02+dfsg1-5ubuntu2] (core)
<slangasek> LocutusOfBorg: symfony testsuite still failing on armhf and s390x (and should this not have had an FFe?)
-queuebot:#ubuntu-release- New: accepted kubernetes [source] (cosmic-proposed) [1.0]
-queuebot:#ubuntu-release- New binary: kubernetes [amd64] (cosmic-proposed/none) [1.0] (no packageset)
<slangasek> coreycb: panko still blocked in -proposed due to armhf autopkgtest failure, which seems very reproducible.  any idea what's what here?
<coreycb> slangasek: i'm working on it here: https://bileto.ubuntu.com/#/ticket/3405. i believe curl is not installed for arm.
<slangasek> coreycb: ah, yes if you use curl in your tests you should depend on it :-)
-queuebot:#ubuntu-release- New: accepted kubernetes [amd64] (cosmic-proposed) [1.0]
<coreycb> slangasek: well, yes :) but it doesn't need explicit install for other non-arm for some reason.
<slangasek> coreycb: armhf is the only architecture which uses containers instead of VMs; the lxd images should still be derived from the standard cloud image the same as the nova images are, I'm not sure why there would be different results
<coreycb> slangasek: ok
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (cosmic-proposed) [2.02+dfsg1-5ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (cosmic-proposed) [2.02+dfsg1-5ubuntu2]
-queuebot:#ubuntu-release- Unapproved: snapcraft (bionic-proposed/universe) [2.43+18.04 => 2.43.1+18.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.43 => 2.43.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: shim-signed (trusty-proposed/main) [1.33.1~14.04.1 => 1.33.1~14.04.2] (core)
-queuebot:#ubuntu-release- Unapproved: shim-signed (xenial-proposed/main) [1.33.1~16.04.1 => 1.33.1~16.04.2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (trusty-proposed) [1.33.1~14.04.2]
<cyphermox> SRU team: could you please check / release https://launchpad.net/ubuntu/+source/grub2/2.02-2ubuntu8.4  to bionic-proposed?
<cyphermox> I mean bionic-updates.
<slangasek> cyphermox: doing
<slangasek> cyphermox: done
<cyphermox> ta
<cyphermox> slangasek: could you please also reject grub2 from bionic-proposed queue? I'll upload a new one with an extra fix
-queuebot:#ubuntu-release- Unapproved: rejected grub2 [source] (bionic-proposed) [2.02-2ubuntu8.5]
<cyphermox> ta
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.4 => 2.02-2ubuntu8.5] (core)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (bionic-proposed/main) [1.93.5 => 1.93.6] (core)
<slangasek> juliank, Laney: so http://autopkgtest.ubuntu.com/running shows a python3.7 autopkgtest that's been hung with no output for 148h.  I've traced down the corresponding systemd unit (autopkgtest@bos02-arm64-5.service) which is not failed so hasn't been restarted.  Do you think there's any more investigation warranted here before I reset it?
-queuebot:#ubuntu-release- Unapproved: rejected grub2 [source] (bionic-proposed) [2.02-2ubuntu8.5]
-queuebot:#ubuntu-release- Unapproved: rejected grub2-signed [source] (bionic-proposed) [1.93.6]
<LocutusOfBorg> slangasek, nope, symfony is the really same release :)
<slangasek> LocutusOfBorg: 3.4.14->3.4.15?
<LocutusOfBorg> oh, I see changes are mostly fixes, 30k diff
<LocutusOfBorg> did you see new features?
<LocutusOfBorg> 12 bug fixed, no new features AFAICS
<slangasek> I didn't look deeply
<LocutusOfBorg> btw the test always failed on those architectures
<slangasek> proposed-migration thinks it's a regression
<LocutusOfBorg> it was good when I made the testsuite return 0 because of the phpunit deprecation warnings, so now it is seen as regression
<LocutusOfBorg> I missed that it was failing on two archs, and when I discovered the error testsuite had already run
<LocutusOfBorg> so now I'm trying to ignore testsuite there, and I fail
<slangasek> well, the last upload has the autopkgtest failing on all archs
<LocutusOfBorg> yep, I know, not sure why it works locally :(
<LocutusOfBorg> I'll have a look tomorrow
<LocutusOfBorg> some damn bash bug
<LocutusOfBorg> oh... missing dpkg-architecture dependency...
<LocutusOfBorg> so dpkg-dev is not installed during testsuite?
<slangasek> juliank, Laney: actually, there are 7 of these borked units; I'll go ahead and clear 6 of them and leave one of the ppc64el ones around for investigation if wanted (autopkgtest@bos02-ppc64el-20.service)
<jbicha> could sysprof/s390x/cosmic please be removed? it only built there because we ignored build test failures in the previous upload
#ubuntu-release 2018-09-06
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-390 [source] (bionic-proposed) [390.77-0ubuntu0.18.04.1]
<mwhudson> has anyone (jbicha?) looked at the ruby-gnome regression with pango1.0?
<mwhudson> it's just a rounding thing but i wonder why it's broken now...
<doko> why isn't that a desktop package? ;p
<slangasek> doko: because plymouth depends on it
<slangasek> (so it's shared desktop/foundations)
<doko> ouch
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-prime [source] (bionic-proposed) [0.8.8.1]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (bionic-proposed) [2.35+18.04]
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-settings [source] (bionic-proposed) [390.77-0ubuntu0.18.04.1]
<mwhudson> doko, slangasek: i think the test has regressed because pango is now compiled with -std=c99 :(
<xnox> c99?! this is so last century.
<xnox> i think i rip that out, when i see it.
<mwhudson> heh
<xnox> given the default is >>c99, the default should be used.
<mwhudson> k&r forever
<mwhudson> oh
<mwhudson> maybe that's not why it changed then
<xnox> the only acceptable places to use c99 is when one compiles tests to check api things work with both default and acient compilers.
<mwhudson> xnox: what is the default now? -std=c11 or something?
<mwhudson> oh ho ho this is std=c18 vs std=gnu18
<mwhudson> it's also a 1ulp difference on i386 so really i should stop caring
<juliank> mwhudson: xnox: the autopkgtest for ruby-gnome has a patch in debian/patches, but it's not applied
<juliank> You can see the test log says assert_equal() fails
<juliank> but I unpacked the source package
<juliank> it uses assert_arrays_nearly_equal
<juliank> Ah, I see what's going on
<mwhudson> juliank: um
<mwhudson> you are talking about the patch I just added?
<juliank> mwhudson: I just noticed you just uploaded that
<mwhudson> haha
<juliank> I was wondering: Why is this patch not applied?
<mwhudson> because sadly building, publication and running autopkgtests are not instantaneous
<juliank> It was not listed on the launchpad page when I ran pull-lp-source
<juliank> So odd timing
<apw> on the move to release perhaps
<juliank> it was just uploaded and moving to proposed
<apw> ahh
-queuebot:#ubuntu-release- Unapproved: grub2-signed (trusty-proposed/main) [1.34.17 => 1.34.18] (core)
-queuebot:#ubuntu-release- Unapproved: rejected grub2-signed [source] (trusty-proposed) [1.34.18]
-queuebot:#ubuntu-release- Unapproved: grub2-signed (xenial-proposed/main) [1.66.18 => 1.66.19] (core)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (trusty-proposed/main) [1.34.17 => 1.34.18] (core)
-queuebot:#ubuntu-release- Unapproved: accepted libglvnd [source] (bionic-proposed) [1.0.0-2ubuntu2.2]
-queuebot:#ubuntu-release- New binary: libglvnd [ppc64el] (bionic-proposed/main) [1.0.0-2ubuntu2.2] (core)
-queuebot:#ubuntu-release- New binary: libglvnd [s390x] (bionic-proposed/main) [1.0.0-2ubuntu2.2] (core)
-queuebot:#ubuntu-release- New binary: libglvnd [i386] (bionic-proposed/main) [1.0.0-2ubuntu2.2] (core)
-queuebot:#ubuntu-release- New binary: libglvnd [amd64] (bionic-proposed/main) [1.0.0-2ubuntu2.2] (core)
-queuebot:#ubuntu-release- New binary: libglvnd [arm64] (bionic-proposed/main) [1.0.0-2ubuntu2.2] (core)
-queuebot:#ubuntu-release- New binary: libglvnd [armhf] (bionic-proposed/main) [1.0.0-2ubuntu2.2] (core)
<ginggs> would someone please 'force-badtest dijitso/2018.1.0-4/armhf' ? dijitso/2017.2.0.0-2 in release only has a simple import test, see https://salsa.debian.org/science-team/fenics/dijitso/commit/594408adf17616034303cb8c1c581e2da82c67c8
<jbicha> mwhudson: see https://gitlab.gnome.org/GNOME/pango/issues/287
<gitbot> GNOME issue 287 in pango "ruby-gnome2 i386 test failure with pango built with meson" [Bugzilla, Opened]
-queuebot:#ubuntu-release- Unapproved: rejected qpdf [sync] (bionic-proposed) [8.1.0-1]
<sergiusens> sil2100: "time appropriate greetings", can I bug you with snapcraft 2.43.1 (+18.04) waiting for approval for xenial- and bionic-proposed?
<sil2100> sergiusens: sure! On it in a moment
-queuebot:#ubuntu-release- Unapproved: accepted snapd-glib [source] (bionic-proposed) [1.43-0ubuntu0.18.04.1]
<jbicha> mwhudson: thanks for the hint, see https://gitlab.gnome.org/GNOME/pango/merge_requests/19
<gitbot> GNOME issue (Merge request) 19 in pango "build: Don't force C99 for meson build" [Opened]
<sergiusens> thanks sil2100
<sil2100> eh, LP timeouts
<mitya57> Can someone please reject gnome-flashback upload in bionic SRU queue? I want to add one more fix to it.
<mfo> sil2100, Hi.  Could the debian-installer package pending SRU for trusty get a rebuild on amd64, please?  It should pass on trusty-proposed now.
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (xenial-proposed) [2.43.1]
<sil2100> mfo: hey! Ah, so grub2-signed migrated? Let me take a look
<mfo> sil2100, the shim-signed and grub2-common problems that it hit before are now resolved, i gave it a try yesterday on a PPA with trusty-proposed enabled. :)
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (bionic-proposed) [2.43.1+18.04]
<doko> apw: ping linux autopkg test failure on s390x
<coreycb> for some reason horizon is failing without a log (it builds ok locally): https://launchpad.net/ubuntu/+source/horizon/3:14.0.0-0ubuntu2/+build/15315380
<coreycb> any thoughts?
<apw> doko, ack
<xnox> doko, apw - well, when ADT_TRIGGER is gcc, i guess the most interesting part is the rebuild test which is PASS, rather than all of the ubuntu-regression-suite
<apw> xnox, yeah those test are all a mess
<xnox> doko, apw - and previously we had the ubuntu-regression-suite ingored in britney hints, because for some reason $ git clone https://git.launchpad.net would clone empty repository
<xnox> doko, apw - i've tried to debug that, but it appears to be specific to /large/ scalingstack instances as configured for the autopkgtest tenant.
<apw> xnox, lovely
<mfo> sil2100, I see d-i is currently building.  Thanks. o/
<xnox> doko, apw - i have failed to trace why git clone is done via https:// instead of git:// protocol
<apw> xnox, iirc because you can (and we do) provide proxies for https: and git: is blocked
<xnox> apw, if you can trace and maybe force try to make the autopkgtest use git:// protocol with launchapd? maybe we would get better git-protocolish error messages
<xnox> apw, ok, in that case, can you inject more envrionment variables such that the s390x runs give us debug info?
<xnox> let me find the things that w grant asked for
<xnox> apw, could you export "GIT_CURL_VERBOSE=1 GIT_TRACE=1" when doing git clone? and possibly redirect stderr into stdout, if stderr is not allowed by the test.
<doko> Laney: gcc-7 and gcc-8 now have autopkg tests. why arent't these run?
<apw> xnox, i'll point sforshee at this ^
<xnox> apw, and i wonder if proxy really is needed for git.launchpad.net over https. I kind of wish git.launchpad.net would be in no_proxy
<xnox> apw, thank you. This is from https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1789774
<ubot5> Ubuntu bug 1789774 in linux (Ubuntu) "linux s390x cosmic autopkgtests fail to clone from git.launchpad.net?!" [Undecided,Incomplete]
<xnox> apw, i've tried to trigger this with bileto / silo; but i got trumped, and bileto poops itself when there is a kernel in proposed, because it can't handle abi package names.
<Laney> doko: britney's logs might say something
<sforshee> apw, xnox: will have a look
<Laney> doko:         if src.startswith('gcc-'):
<Laney>             if re.match('gcc-\d$', src):
<Laney>                 for test in ['binutils', 'fglrx-installer', 'libreoffice', 'linux']:
<Laney> so the normal logic is overridden for gcc, guess we could add their own tests there
<cjwatson> xnox: Ew.  https is better than the git protocol
<xnox> cjwatson, hm, ok. just need to figure out what is broken with bos02 on s390x with large tenants in the autopkgtest tenant then
<cjwatson> (better in terms of both security and performance - git:// is the old dumb protocol IIRC)
<xnox> cjwatson, but the error condition that "stderr: you appear to have cloned an empty repository" is not a nice one, with error code 0
<xnox> i wish there was a flag to clone "--fail-on-empty" or something
<xnox> when clearly the repository to be cloned is not empty.
<cjwatson> I guess you could do a test after the clone
 * xnox is out of date with "protocols" "index revisions" "responses changes" in git stuff.... there have been changes, but i'm not at all aware which one is fastest/best/latest.
<xnox> but i wondered if cloning over git:// would expose or tell something different, from that broken environment.
<cjwatson> mm, trying those trace environment variables first is probably more useful
<xnox> ack
<apw> sforshee, ^
<sforshee> apw: actually some of the tests we're running do clone stuff over git://
<sforshee> stress-ng for instance
<xnox> that was that i noticed too.
<apw> sforshee, we are so consistent ... sigh
<xnox> i mean maybe for the https:// ones you sometimes parameterize it to use a private branch; then you do need https:// with authentication.... or ssh....
<apw> i am supprised git: would not be the 'best' all the time, given it seemed to have feature flags both ways
<xnox> sforshee, apw - when i tried to trace the repos where this all lives i did see things (still) on kernel.ubuntu.com and on launchpad, and like things that are declared as git:// in a yaml/metafile but then during s390x run it was autoconverted into https:// urls somehow.
 * xnox somehow thought that git: is the fastest one too for large packs....
<xnox> sforshee, but the s390x failures are both stem from the fact that there are two repos that fail to clone from https: from launchpad.
<xnox> sforshee, the current git tree itself (ie. /cosmic) and qa-regression-testing repo
<sforshee> xnox: I pushed changes to use those exports when cloning those two repos. Let me know when you've got what you need so I can revert those changes.
<Laney> doko: pushed a commit to proposed-migration to run those tests, will try to make it request those in a second
<Laney> doko: looks like you got your tests now
<didrocks> sil2100: hey! I saw that apport phase update has just been stopped. The pointed regression isn't a real one: https://errors.ubuntu.com/problem/d89b8d57a5c75209facd4b434677423793c317a9 (cannot allocate memory), and seeing the number of issues (4 in 4 days), it shouldn't be related, but only system with low memory (as this can happen with apport when collecting memory), mind releasing the update phasing
<didrocks> process?
<sil2100> didrocks: hey! hm, I might be a bit too busy right now, I'd have to look at it tomorrow - bdmurray maybe you could take a look as part of your SRU shift? ^
<didrocks> sounds good :)
<bdmurray> I've made a note.
<cjwatson> xnox: I sort of wonder if https://twistedmatrix.com/trac/ticket/9526 might be related to these git woes, but maybe only because I happened to hear about both problems on the same day
<xnox> cjwatson, it's a bit twisted for my brain =)
<cjwatson> though if it is that, it's been broken on git.l.n for ~4 months so it would be weird for me to hear about problem and solution on the same day
<cjwatson> and in any case I just tried cloning a big repo over slow ADSL and it's been going for longer than 75 seconds with no sign of stopping
<cjwatson> so as you were
<xnox> there is latency between lp and bos02 maybe
<xnox> but i would not expect it to be s390x specific....
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (bionic-proposed) [4.0.0-1ubuntu8.5]
-queuebot:#ubuntu-release- New: accepted python-osc-placement [sync] (cosmic-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New binary: python-osc-placement [amd64] (cosmic-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New sync: darkmint-gtk-theme (cosmic-proposed/primary) [2.0.0-1]
-queuebot:#ubuntu-release- New sync: numix-icon-theme-circle (cosmic-proposed/primary) [18-04-04-1]
<ginggs> would someone please 'force-badtest dijitso/2018.1.0-4/armhf' ? dijitso/2017.2.0.0-2 in release only has a simple import test, see https://salsa.debian.org/science-team/fenics/dijitso/commit/594408adf17616034303cb8c1c581e2da82c67c8
<slangasek> Laney: welcome back!  did you happen to see my question about the state of autopkgtest@bos02-arm64-5.service and whether further debugging is warranted?
<tumbleweed> ginggs: why does it only fail on armhf? filed a bug?
<ginggs> tumbleweed: openmpi is currently a bit broken on i386 and armhf, there are 3 RC bugs against openmpi
<slangasek> ginggs: have you also verified that running the new dijitso tests against the old dijito package on armhf fails the same way?
<ginggs> slangasek: no, i have not
<slangasek> k, that's what I'd be looking for here as a standard of evidence
<tumbleweed> it looks like britney's doing its job in this case
<ginggs> slangasek: ack
<tumbleweed> I don't see much evidence of spurious faliures in the past
<slangasek> well, ginggs rightly points out that it's a new test; but that doesn't tell us definitively whether it's a new bu
<slangasek> g
<ginggs> tumbleweed: that's because it was only an import test
<tumbleweed> ah, right there were different autopkgtests before
<slangasek> yeah
<slangasek> I mean, in my ideal scenario p-m would not consider this a regression since it's a new test
<slangasek> but since we're doing it all manually anyway I'm being pickier
-queuebot:#ubuntu-release- New binary: julia [ppc64el] (cosmic-proposed/universe) [1.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: julia [arm64] (cosmic-proposed/universe) [1.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted shim [sync] (bionic-proposed) [15+1533136590.3beb971-0ubuntu1]
<ginggs> slangasek: http://autopkgtest.ubuntu.com/running#pkg-dijitso <- old version of dijitso with new tests enabled, hangs in the same place
<ginggs> the OpenFabrics (openib) warning is not relevant here
-queuebot:#ubuntu-release- Unapproved: nginx (bionic-proposed/main) [1.14.0-0ubuntu1 => 1.14.0-0ubuntu1.1] (ubuntu-server)
<bdmurray> cpaelzer: There certainly are a lot of these open-vm-tools crashes about the package in bionic-updates.
-queuebot:#ubuntu-release- Unapproved: accepted gnome-flashback [source] (bionic-proposed) [3.28.0-1ubuntu1.1]
<mwhudson> jbicha: ah nice
<mwhudson> jbicha: i hacked the ruby-gnome2 testsuite in the meantime
-queuebot:#ubuntu-release- Unapproved: accepted widelands [source] (bionic-proposed) [1:19+repack-4ubuntu0.18.04.1]
<slangasek> ginggs: thanks, hinting
<jbicha> mwhudson: do you want to hack it back? I'm syncing pango1.0 1.42.4-3 from Debian in a few hours
-queuebot:#ubuntu-release- Unapproved: rejected shim-signed [source] (bionic-proposed) [1.37~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-games-app [source] (bionic-proposed) [3.28.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: shim-signed (bionic-proposed/main) [1.34.9.2 => 1.37~18.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted sshuttle [source] (bionic-proposed) [0.78.3-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted sshuttle [source] (xenial-proposed) [0.76-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected unattended-upgrades [source] (bionic-proposed) [1.1ubuntu1.18.04.6]
-queuebot:#ubuntu-release- Unapproved: accepted openvpn [source] (bionic-proposed) [2.4.4-2ubuntu1.1]
<jbicha> mwhudson: oh, now I'm concerned that my test was faulty since my autopkgtest was against your hacked version :|
<jbicha> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic-jbicha-arch/cosmic/i386/r/ruby-gnome2/20180906_123646_35121@/log.gz
<jbicha> if you have time, could you check the unhacked version against 1.42.4-3?
<mwhudson> jbicha: where is 1.42.4-3?
<mwhudson> but yes, it's easy enough for me to test that
<mwhudson> jbicha: i did enough testing yesterday to convince myself that if you remove -std=c99 from the command line the test will pass
<mwhudson> oh it's in unstable
<mwhudson> jbicha: so i build pango1.0 1.42.4-3, installed it and ran the old ruby-gnome2 autopkgtests and they passed
<mwhudson> jbicha: so you/i/someone could sync pango1.0 and remove my patch i guess
<mwhudson> *remove my patch from ruby-gnome2
<jbicha> mwhudson: yes, I'll sync. Why don't you go ahead and remove the patch now please?
<jbicha> (so that the automated tests will run against the right ruby-gnome2 for us :) )
-queuebot:#ubuntu-release- Unapproved: accepted vlc [source] (bionic-proposed) [3.0.4-1ubuntu0.1]
<Trevinho> bdmurray: thanks for the heads, up I'v updated https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1713581
<ubot5> Ubuntu bug 1713581 in nautilus (Ubuntu Bionic) "nautilus crashed with SIGSEGV in g_type_check_instance_is_fundamentally_a()" [High,Triaged]
<bdmurray> Trevinho: using the crash in the Error Tracker is a fine way to do the verification too
<Trevinho> bdmurray: ok, thanks that's what I've been using when hard to do a proper verification
<Trevinho> like to define a correct test-case
<Trevinho> like the only way I know how to reproduce this is hack nautilus not to load files quickly :-D
<mwhudson> jbicha: um does the order really matter?
<jbicha> ideally, we wouldn't let pango-built-with-meson in to cosmic until it passes its autopkgtests :)
<mwhudson> well it's in cosmic release now
<mwhudson> if i upload ruby-gnome2 it will fail its tests until the new pango is synced
<mwhudson> i feel like this is a lot of talk for a 1ULP difference on an architecture we should stop building for :)
<jbicha> oh I see
-queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (bionic-proposed) [1.37~18.04.1]
-queuebot:#ubuntu-release- New binary: nova-lxd [amd64] (cosmic-proposed/main) [18.0.0~rc2-0ubuntu2] (ubuntu-server)
-queuebot:#ubuntu-release- New: accepted python-osc-placement [amd64] (cosmic-proposed) [1.3.0-1]
#ubuntu-release 2018-09-07
<xnox> slangasek, https://code.launchpad.net/~xnox/britney/hints-ubuntu/+merge/354198
<xnox> should kexec tools continue to be blogged because of a broken kernel in proposed? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1790513
<ubot5> Ubuntu bug 1790513 in linux (Ubuntu Cosmic) "kdump-config status - not ready to kdump with v4.18 kernel" [Medium,Triaged]
<xnox> it is not possible to run tests on a non-proposed kernel.
<slangasek> xnox: your bug asks a question, but above you seem to assume an answer about whose bug it is; which package needs changed in order to fix this?  Since as things stand, this bug will not block linux 4.18 from reaching cosmic
<xnox> slangasek, i was not sure if i should be bold enough to block linux v4.18
<xnox> imho cannot kdump is severe
<xnox> but what do i know.....
<slangasek> xnox: well, all three of linux, kexec-tools, and makedumpfile are the responsibility of the kernel team, so perhaps make it their problem :)
<xnox> ha
<slangasek> xnox: kdump not working is certainly a serious problem, but whether they want that to block the new kernel reaching cosmic is something I would leave to them to decide
<cpaelzer> bdmurray: new ones on top of the two that I analyzed
<cpaelzer> bdmurray: taking a look
<cpaelzer> bdmurray: oh yeah, I'll update the upstream bug
<cpaelzer> bdmurray: feel free to stop the phasing for now
<cpaelzer> unfortunately without more data than the partial stack traces in the reports it is hard to go on atm
<cpaelzer> grml
<cpaelzer> thanks for the ping
<cpaelzer> at the time I sent the mail this was quite different to what it looks now
<cpaelzer> got to your mail now - ack
<cpaelzer> I hope I find something with this scarce info we have :-/
<cpaelzer> bdmurray: FYI spawned bug 1791220 for this
<ubot5> bug 1791220 in open-vm-tools (Ubuntu) "increased crash rate since 10.3 upgrade is available" [Undecided,New] https://launchpad.net/bugs/1791220
<cpaelzer> I'll need to finalize a few other things on my plate for today and then will take a look at a disassembly
<cpaelzer> it all is at the same spot, so maybe I can find disasm -> source -> review to find the bug
<Laney> slangasek: I missed that, sorry - what's the problem? Seems to be running here.
<slangasek> Laney: http://autopkgtest.ubuntu.com/running#pkg-r-cran-fastmatch
<Laney> slangasek: That looks to be autopkgtest@bos02-ppc64el-20
<slangasek> yes
<Laney> OK, just checking, since you said autopkgtest@bos02-arm64-5.service earlier
<slangasek> Laney: ah yes, I copy-pasted the wrong unit from history
<Laney> :P
<Laney> does Aug 25 07:44:36 correspond to some maintenance?
<slangasek> not afaik; and there were a total of 7 units across multiple clouds in this state, with varying times
<slangasek> cough, apologies for secureboot-db 1.2, it works fine if you install it on an actual secureboot system, notsomuch otherwise.  1.3 should fix this
<Laney> right, I don't feel like I'll be able to be very lucky finding out what event caused the test to not finish
<Laney> still at the very least sounds like a bug that autopkgtest hasn't timed out
<slangasek> Laney: yeah, it was the latter I was more interested in
<Laney> slangasek: I don't have any bright ideas for what I could do with this running process, do you?
<slangasek> Laney: I tried everything I could with the running process and got nowhere
<slangasek> so I left it in a state that you could inspect if you knew something I didn't
<Laney> Guess we get to file a not so useful bug :(
<slangasek> strace shows that one of the subprocesses is waiting on stdin
 * Laney kills it
<doko> Laney: thanks for enabling the gcc autopkg tests. Now that we check for an empty libgcc1 package, please can you remove the artificial libreoffice autopkg test trigger?
<doko> apw: gcc-8 migrated, gcc-7 not yet
-queuebot:#ubuntu-release- New binary: julia [ppc64el] (cosmic-proposed/universe) [1.0.0-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: julia [arm64] (cosmic-proposed/universe) [1.0.0-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New: accepted julia [arm64] (cosmic-proposed) [1.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted julia [arm64] (cosmic-proposed) [1.0.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted nova-lxd [amd64] (cosmic-proposed) [18.0.0~rc2-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted julia [ppc64el] (cosmic-proposed) [1.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted julia [ppc64el] (cosmic-proposed) [1.0.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted darkmint-gtk-theme [sync] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted numix-icon-theme-circle [sync] (cosmic-proposed) [18-04-04-1]
-queuebot:#ubuntu-release- New: accepted ufonormalizer [sync] (cosmic-proposed) [0.3.5-1]
-queuebot:#ubuntu-release- New: accepted fontpens [sync] (cosmic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted pipewire [sync] (cosmic-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New binary: pipewire [s390x] (cosmic-proposed/none) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pipewire [ppc64el] (cosmic-proposed/none) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fontpens [amd64] (cosmic-proposed/none) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: darkmint-gtk-theme [amd64] (cosmic-proposed/none) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ufonormalizer [amd64] (cosmic-proposed/none) [0.3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: numix-icon-theme-circle [amd64] (cosmic-proposed/none) [18-04-04-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pipewire [arm64] (cosmic-proposed/none) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pipewire [armhf] (cosmic-proposed/none) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pipewire [i386] (cosmic-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pipewire [amd64] (cosmic-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted pipewire [amd64] (cosmic-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted pipewire [armhf] (cosmic-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted pipewire [ppc64el] (cosmic-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted pipewire [arm64] (cosmic-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted pipewire [s390x] (cosmic-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted pipewire [i386] (cosmic-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted darkmint-gtk-theme [amd64] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted numix-icon-theme-circle [amd64] (cosmic-proposed) [18-04-04-1]
-queuebot:#ubuntu-release- New: accepted fontpens [amd64] (cosmic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted ufonormalizer [amd64] (cosmic-proposed) [0.3.5-1]
<xnox> sforshee, apw - all the git clones, over https, were successful in the last couple of linux runs. le sigh. i mean great, linux/s390x passed.
<xnox> but i fear the cloning thing might come back
-queuebot:#ubuntu-release- New binary: mshr [s390x] (cosmic-proposed/universe) [2018.1.0+dfsg1-5] (no packageset)
-queuebot:#ubuntu-release- New binary: mshr [ppc64el] (cosmic-proposed/universe) [2018.1.0+dfsg1-5] (no packageset)
-queuebot:#ubuntu-release- New binary: mshr [i386] (cosmic-proposed/universe) [2018.1.0+dfsg1-5] (no packageset)
-queuebot:#ubuntu-release- New binary: mshr [amd64] (cosmic-proposed/universe) [2018.1.0+dfsg1-5] (no packageset)
-queuebot:#ubuntu-release- New binary: mshr [armhf] (cosmic-proposed/universe) [2018.1.0+dfsg1-5] (no packageset)
<jbicha> please remove sysprof/s390x/cosmic : it only built because we ignored build test failures in the previous release
-queuebot:#ubuntu-release- Unapproved: accepted openssh [source] (xenial-proposed) [1:7.2p2-4ubuntu2.5]
-queuebot:#ubuntu-release- New: accepted mshr [amd64] (cosmic-proposed) [2018.1.0+dfsg1-5]
-queuebot:#ubuntu-release- New: accepted mshr [i386] (cosmic-proposed) [2018.1.0+dfsg1-5]
-queuebot:#ubuntu-release- New: accepted mshr [s390x] (cosmic-proposed) [2018.1.0+dfsg1-5]
-queuebot:#ubuntu-release- New: accepted mshr [armhf] (cosmic-proposed) [2018.1.0+dfsg1-5]
-queuebot:#ubuntu-release- New: accepted mshr [ppc64el] (cosmic-proposed) [2018.1.0+dfsg1-5]
<didrocks> sil2100: is "building from a ppa" a new requirement for FFe?
<didrocks> I have built it locally and tested it on cosmic (no build-dep changes btw)
<didrocks> the "provide build logs" sound a little bit of lack of trust to the packager btw :p
<didrocks> so, I can build it in a ppa and redo the whole manual testing from it, but this sounds like a waste of time to redo all this and ensuring it's stable as well
<xnox> i wonder if the buildlogs req is there from before ppas...
<sil2100> didrocks: I didn't invent that: https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze_for_new_upstream_versions
<sil2100> didrocks: it's been there since ages
<sil2100> didrocks: when was the last time you checked it? You can provide any build logs, PPA seemed just convenient
<didrocks> sil2100: right, but it's the first time that I was actually asked for a ppa and the build logs, sounds like other members and yourself in the past were more trusting us
<didrocks> I mean, I can understand for a one time drive-by contributor, but it seems we are making things more and more full of paperwork, anywayâ¦
<sil2100> didrocks: ok, I guess if you say it builds then that's good enough-ish, I generally started following the procedures a bit more since I don't want to have double-standards, I guess it's better to be more strict than less
<sil2100> didrocks: a PPA build is convenient because it tests more than one arch
<didrocks> true, I'm not annoyed by pushing to a ppa, the second round of testing can be annoying though
<sil2100> didrocks: we wouldn't want things to FTBFS suddenly on some untested arch and then delay things ;)
<didrocks> won't be for today anymore though, we'll see on Monday now
<sil2100> didrocks: anyway! Let's do it like this: just leave a comment stating that you have performed a successful local test build
<didrocks> sil2100: if you prefer the ppa, I can do itâ¦ Just find it weird ;)
<didrocks> the second round of testing will take more time as it's all manual and more "running and see it being stable", but oh my, that's for another week anyway
<sil2100> didrocks: I guess it's fine this time, since it's early and I don't want you to feel untrusted!
<sil2100> Like, by early I mean 'not that super late in the cycle'
<didrocks> sil2100: ok, let me add the comment then! Thanks :)
<didrocks> yep
<sil2100> Just saying that I'm not inventing any new rules here, just going by the book here!
<didrocks> oh, I didn't say that wasn't written on the wiki page, but this is the first time I saw it asked for a long time contributor
<didrocks> we'll get used to it I guess :p
<didrocks> sil2100: commented (but anyway, I'll only upload on Monday, don't want to break things during the week-end, just in case :p)
<sil2100> didrocks: you know I trust you!
<sil2100> didrocks: it's just you know, paperwork and such... ;p
<sil2100> (and certainty that nothing's busted, but as said, there's still time to get things building in the worst case anyway)
<didrocks> sil2100: no worry ;)
<didrocks> and thanks!
-queuebot:#ubuntu-release- New binary: gpaste [s390x] (cosmic-proposed/universe) [3.28.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gpaste [ppc64el] (cosmic-proposed/universe) [3.28.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gpaste [arm64] (cosmic-proposed/universe) [3.28.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gpaste [armhf] (cosmic-proposed/universe) [3.28.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gpaste [amd64] (cosmic-proposed/universe) [3.28.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gpaste [i386] (cosmic-proposed/universe) [3.28.2-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: open-iscsi (bionic-proposed/main) [2.0.874-5ubuntu2.1 => 2.0.874-5ubuntu2.2] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: syslinux (bionic-proposed/main) [3:6.03+dfsg1-2 => 3:6.03+dfsg1-2ubuntu0.18.04.1] (core)
<slangasek> I start processing the libreoffice SRU, and launchpad throws an oops trying to show me https://launchpad.net/ubuntu/+source/libreoffice
<slangasek> it's an omen
<xnox> slangasek, ok so i did $ sudo cat /proc/keys
<xnox> slangasek, and I did not like this:
<xnox> 30814288 I------     1 perm 1f030000     0     0 asymmetri sforshee: 00b28ddf47aef9cea7: X509.rsa []
<slangasek> :D
<slangasek> xnox: he's the upstream owner of the regdb key
<slangasek> I've had this reaction before when watching him scroll by in dmesg
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (bionic-proposed) [2.35.1+18.04]
-queuebot:#ubuntu-release- New sync: mozjs60 (cosmic-proposed/primary) [60.1.0-1]
<jbicha> feel free to kill mozjs38 now, it never was in Debian LP: #1728184
<ubot5> Launchpad bug 1728184 in mozjs38 (Ubuntu) "Please remove mozjs38 from Ubuntu" [High,Triaged] https://launchpad.net/bugs/1728184
<jbicha> we know that mozjs60 has a build problem on i386 and we will file a FFe if we do switch to mozjs60 for 18.10
#ubuntu-release 2018-09-08
-queuebot:#ubuntu-release- New binary: fife [s390x] (cosmic-proposed/universe) [0.4.1+git20180904-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bbswitch [ppc64el] (cosmic-proposed/universe) [0.8-5] (no packageset)
-queuebot:#ubuntu-release- New binary: bbswitch [s390x] (cosmic-proposed/universe) [0.8-5] (no packageset)
-queuebot:#ubuntu-release- New binary: bbswitch [amd64] (cosmic-proposed/universe) [0.8-5] (no packageset)
-queuebot:#ubuntu-release- New binary: bbswitch [i386] (cosmic-proposed/universe) [0.8-5] (no packageset)
-queuebot:#ubuntu-release- New binary: bbswitch [arm64] (cosmic-proposed/universe) [0.8-5] (no packageset)
-queuebot:#ubuntu-release- New binary: fife [amd64] (cosmic-proposed/universe) [0.4.1+git20180904-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bbswitch [armhf] (cosmic-proposed/universe) [0.8-5] (no packageset)
-queuebot:#ubuntu-release- New binary: fife [ppc64el] (cosmic-proposed/universe) [0.4.1+git20180904-2] (no packageset)
-queuebot:#ubuntu-release- New binary: fife [armhf] (cosmic-proposed/universe) [0.4.1+git20180904-2] (no packageset)
-queuebot:#ubuntu-release- New binary: fife [arm64] (cosmic-proposed/universe) [0.4.1+git20180904-2] (no packageset)
-queuebot:#ubuntu-release- New binary: fife [i386] (cosmic-proposed/universe) [0.4.1+git20180904-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted libglvnd [amd64] (bionic-proposed) [1.0.0-2ubuntu2.2]
-queuebot:#ubuntu-release- New: accepted libglvnd [armhf] (bionic-proposed) [1.0.0-2ubuntu2.2]
-queuebot:#ubuntu-release- New: accepted libglvnd [ppc64el] (bionic-proposed) [1.0.0-2ubuntu2.2]
-queuebot:#ubuntu-release- New: accepted libglvnd [arm64] (bionic-proposed) [1.0.0-2ubuntu2.2]
-queuebot:#ubuntu-release- New: accepted libglvnd [s390x] (bionic-proposed) [1.0.0-2ubuntu2.2]
-queuebot:#ubuntu-release- New: accepted libglvnd [i386] (bionic-proposed) [1.0.0-2ubuntu2.2]
-queuebot:#ubuntu-release- New sync: rust-spin (cosmic-proposed/primary) [0.4.9-1]
-queuebot:#ubuntu-release- New sync: rust-simd (cosmic-proposed/primary) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-simd [sync] (cosmic-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-spin [sync] (cosmic-proposed) [0.4.9-1]
-queuebot:#ubuntu-release- New: accepted bbswitch [amd64] (cosmic-proposed) [0.8-5]
-queuebot:#ubuntu-release- New: accepted bbswitch [armhf] (cosmic-proposed) [0.8-5]
-queuebot:#ubuntu-release- New: accepted bbswitch [ppc64el] (cosmic-proposed) [0.8-5]
-queuebot:#ubuntu-release- New: accepted fife [amd64] (cosmic-proposed) [0.4.1+git20180904-2]
-queuebot:#ubuntu-release- New: accepted fife [armhf] (cosmic-proposed) [0.4.1+git20180904-2]
-queuebot:#ubuntu-release- New: accepted fife [ppc64el] (cosmic-proposed) [0.4.1+git20180904-2]
-queuebot:#ubuntu-release- New: accepted gpaste [amd64] (cosmic-proposed) [3.28.2-1]
-queuebot:#ubuntu-release- New: accepted gpaste [armhf] (cosmic-proposed) [3.28.2-1]
-queuebot:#ubuntu-release- New: accepted gpaste [ppc64el] (cosmic-proposed) [3.28.2-1]
-queuebot:#ubuntu-release- New: accepted bbswitch [arm64] (cosmic-proposed) [0.8-5]
-queuebot:#ubuntu-release- New: accepted bbswitch [s390x] (cosmic-proposed) [0.8-5]
-queuebot:#ubuntu-release- New: accepted fife [i386] (cosmic-proposed) [0.4.1+git20180904-2]
-queuebot:#ubuntu-release- New: accepted gpaste [arm64] (cosmic-proposed) [3.28.2-1]
-queuebot:#ubuntu-release- New: accepted gpaste [s390x] (cosmic-proposed) [3.28.2-1]
-queuebot:#ubuntu-release- New: accepted bbswitch [i386] (cosmic-proposed) [0.8-5]
-queuebot:#ubuntu-release- New: accepted fife [s390x] (cosmic-proposed) [0.4.1+git20180904-2]
-queuebot:#ubuntu-release- New: accepted fife [arm64] (cosmic-proposed) [0.4.1+git20180904-2]
-queuebot:#ubuntu-release- New: accepted gpaste [i386] (cosmic-proposed) [3.28.2-1]
-queuebot:#ubuntu-release- New binary: rust-spin [i386] (cosmic-proposed/none) [0.4.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-spin [s390x] (cosmic-proposed/none) [0.4.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-spin [ppc64el] (cosmic-proposed/none) [0.4.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-simd [amd64] (cosmic-proposed/none) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-spin [arm64] (cosmic-proposed/none) [0.4.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-simd [arm64] (cosmic-proposed/none) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-spin [armhf] (cosmic-proposed/none) [0.4.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-simd [i386] (cosmic-proposed/none) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-spin [amd64] (cosmic-proposed/none) [0.4.9-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-simd [arm64] (cosmic-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-spin [amd64] (cosmic-proposed) [0.4.9-1]
-queuebot:#ubuntu-release- New: accepted rust-spin [armhf] (cosmic-proposed) [0.4.9-1]
-queuebot:#ubuntu-release- New: accepted rust-simd [i386] (cosmic-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-spin [arm64] (cosmic-proposed) [0.4.9-1]
-queuebot:#ubuntu-release- New: accepted mozjs60 [sync] (cosmic-proposed) [60.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-spin [i386] (cosmic-proposed) [0.4.9-1]
-queuebot:#ubuntu-release- New: accepted rust-spin [s390x] (cosmic-proposed) [0.4.9-1]
-queuebot:#ubuntu-release- New: accepted rust-simd [amd64] (cosmic-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-spin [ppc64el] (cosmic-proposed) [0.4.9-1]
-queuebot:#ubuntu-release- New binary: rust-structopt-derive [ppc64el] (cosmic-proposed/universe) [0.2.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-structopt-derive [s390x] (cosmic-proposed/universe) [0.2.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-structopt-derive [arm64] (cosmic-proposed/universe) [0.2.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-structopt-derive [armhf] (cosmic-proposed/universe) [0.2.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-structopt-derive [amd64] (cosmic-proposed/universe) [0.2.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-termcolor [ppc64el] (cosmic-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-structopt-derive [i386] (cosmic-proposed/universe) [0.2.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-termcolor [s390x] (cosmic-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-structopt-derive [amd64] (cosmic-proposed) [0.2.10-1]
-queuebot:#ubuntu-release- New: accepted rust-structopt-derive [armhf] (cosmic-proposed) [0.2.10-1]
-queuebot:#ubuntu-release- New: accepted rust-structopt-derive [ppc64el] (cosmic-proposed) [0.2.10-1]
-queuebot:#ubuntu-release- New: accepted rust-termcolor [ppc64el] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New binary: rust-termcolor [amd64] (cosmic-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-termcolor [armhf] (cosmic-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-structopt-derive [arm64] (cosmic-proposed) [0.2.10-1]
-queuebot:#ubuntu-release- New: accepted rust-structopt-derive [s390x] (cosmic-proposed) [0.2.10-1]
-queuebot:#ubuntu-release- New binary: rust-termcolor [arm64] (cosmic-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-structopt-derive [i386] (cosmic-proposed) [0.2.10-1]
-queuebot:#ubuntu-release- New binary: rust-termcolor [i386] (cosmic-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-termcolor [s390x] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New binary: rust-nix [ppc64el] (cosmic-proposed/universe) [0.11.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-nix [s390x] (cosmic-proposed/universe) [0.11.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-nix [ppc64el] (cosmic-proposed) [0.11.0-1]
-queuebot:#ubuntu-release- New: accepted rust-termcolor [amd64] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-termcolor [armhf] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-nix [s390x] (cosmic-proposed) [0.11.0-1]
-queuebot:#ubuntu-release- New: accepted rust-termcolor [i386] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-termcolor [arm64] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New binary: rust-nix [arm64] (cosmic-proposed/universe) [0.11.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-synstructure [ppc64el] (cosmic-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-nix [armhf] (cosmic-proposed/universe) [0.11.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-synstructure [s390x] (cosmic-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-nix [i386] (cosmic-proposed/universe) [0.11.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-synstructure [armhf] (cosmic-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-openssl [s390x] (cosmic-proposed/universe) [0.10.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-synstructure [i386] (cosmic-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mozjs60 [ppc64el] (cosmic-proposed/universe) [60.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-openssl [armhf] (cosmic-proposed/universe) [0.10.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-synstructure [amd64] (cosmic-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-openssl [arm64] (cosmic-proposed/universe) [0.10.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-synstructure [arm64] (cosmic-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-openssl [ppc64el] (cosmic-proposed/universe) [0.10.10-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted mozjs60 [ppc64el] (cosmic-proposed) [60.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-nix [armhf] (cosmic-proposed) [0.11.0-1]
-queuebot:#ubuntu-release- New: accepted rust-openssl [arm64] (cosmic-proposed) [0.10.10-1]
-queuebot:#ubuntu-release- New: accepted rust-openssl [ppc64el] (cosmic-proposed) [0.10.10-1]
-queuebot:#ubuntu-release- New: accepted rust-synstructure [amd64] (cosmic-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted rust-synstructure [armhf] (cosmic-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted rust-synstructure [ppc64el] (cosmic-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New binary: rust-commoncrypto [amd64] (cosmic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-commoncrypto [s390x] (cosmic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-nix [arm64] (cosmic-proposed) [0.11.0-1]
-queuebot:#ubuntu-release- New: accepted rust-openssl [armhf] (cosmic-proposed) [0.10.10-1]
-queuebot:#ubuntu-release- New: accepted rust-synstructure [arm64] (cosmic-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted rust-synstructure [s390x] (cosmic-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New binary: rust-openssl [i386] (cosmic-proposed/universe) [0.10.10-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-nix [i386] (cosmic-proposed) [0.11.0-1]
-queuebot:#ubuntu-release- New: accepted rust-synstructure [i386] (cosmic-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted rust-openssl [s390x] (cosmic-proposed) [0.10.10-1]
-queuebot:#ubuntu-release- New binary: rust-commoncrypto [ppc64el] (cosmic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-commoncrypto [arm64] (cosmic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-commoncrypto [i386] (cosmic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-openssl [amd64] (cosmic-proposed/universe) [0.10.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-commoncrypto [armhf] (cosmic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-core-foundation [amd64] (cosmic-proposed/universe) [0.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-core-foundation [i386] (cosmic-proposed/universe) [0.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-commoncrypto [amd64] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-commoncrypto [armhf] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-commoncrypto [ppc64el] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-core-foundation [amd64] (cosmic-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted rust-openssl [amd64] (cosmic-proposed) [0.10.10-1]
-queuebot:#ubuntu-release- New binary: rust-structopt [armhf] (cosmic-proposed/universe) [0.2.10-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-commoncrypto [arm64] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-commoncrypto [s390x] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-openssl [i386] (cosmic-proposed) [0.10.10-1]
-queuebot:#ubuntu-release- New: accepted rust-commoncrypto [i386] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-core-foundation [i386] (cosmic-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New binary: rust-data-url [ppc64el] (cosmic-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-env-logger [armhf] (cosmic-proposed/universe) [0.5.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-miow [armhf] (cosmic-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-data-url [s390x] (cosmic-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-env-logger [i386] (cosmic-proposed/universe) [0.5.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-data-url [arm64] (cosmic-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-data-url [i386] (cosmic-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-structopt [amd64] (cosmic-proposed/universe) [0.2.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-data-url [armhf] (cosmic-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-structopt [i386] (cosmic-proposed/universe) [0.2.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-miow [amd64] (cosmic-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-data-url [amd64] (cosmic-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-miow [i386] (cosmic-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-env-logger [amd64] (cosmic-proposed/universe) [0.5.11-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-data-url [amd64] (cosmic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-miow [i386] (cosmic-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted rust-data-url [arm64] (cosmic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-data-url [i386] (cosmic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-data-url [s390x] (cosmic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-env-logger [armhf] (cosmic-proposed) [0.5.11-1]
-queuebot:#ubuntu-release- New: accepted rust-miow [amd64] (cosmic-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted rust-structopt [amd64] (cosmic-proposed) [0.2.10-1]
-queuebot:#ubuntu-release- New: accepted rust-structopt [i386] (cosmic-proposed) [0.2.10-1]
-queuebot:#ubuntu-release- New binary: rust-os-pipe [ppc64el] (cosmic-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-data-url [armhf] (cosmic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-env-logger [amd64] (cosmic-proposed) [0.5.11-1]
-queuebot:#ubuntu-release- New: accepted rust-miow [armhf] (cosmic-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New binary: rust-failure-derive [s390x] (cosmic-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-data-url [ppc64el] (cosmic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-structopt [armhf] (cosmic-proposed) [0.2.10-1]
-queuebot:#ubuntu-release- New: accepted rust-env-logger [i386] (cosmic-proposed) [0.5.11-1]
-queuebot:#ubuntu-release- New binary: rust-os-pipe [s390x] (cosmic-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-failure-derive [s390x] (cosmic-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted rust-os-pipe [s390x] (cosmic-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New binary: rust-failure-derive [ppc64el] (cosmic-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-os-pipe [i386] (cosmic-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-os-pipe [ppc64el] (cosmic-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New binary: rust-os-pipe [arm64] (cosmic-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-failure-derive [amd64] (cosmic-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-failure-derive [arm64] (cosmic-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-os-pipe [armhf] (cosmic-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-failure-derive [armhf] (cosmic-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ctrlc [ppc64el] (cosmic-proposed/universe) [3.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-os-pipe [amd64] (cosmic-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ctrlc [s390x] (cosmic-proposed/universe) [3.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ripgrep [armhf] (cosmic-proposed/universe) [0.9.0-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-ctrlc [s390x] (cosmic-proposed) [3.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-ripgrep [armhf] (cosmic-proposed) [0.9.0-3]
-queuebot:#ubuntu-release- New: accepted rust-os-pipe [amd64] (cosmic-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-ctrlc [ppc64el] (cosmic-proposed) [3.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-failure-derive [arm64] (cosmic-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted rust-failure-derive [ppc64el] (cosmic-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted rust-os-pipe [armhf] (cosmic-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New binary: rust-ctrlc [arm64] (cosmic-proposed/universe) [3.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-failure-derive [i386] (cosmic-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-failure-derive [amd64] (cosmic-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted rust-os-pipe [arm64] (cosmic-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New binary: rust-ctrlc [armhf] (cosmic-proposed/universe) [3.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-failure-derive [armhf] (cosmic-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New binary: rust-ripgrep [amd64] (cosmic-proposed/universe) [0.9.0-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-os-pipe [i386] (cosmic-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-ctrlc [arm64] (cosmic-proposed) [3.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-failure-derive [i386] (cosmic-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted rust-ctrlc [armhf] (cosmic-proposed) [3.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-ripgrep [amd64] (cosmic-proposed) [0.9.0-3]
-queuebot:#ubuntu-release- New binary: rust-crypto-hash [ppc64el] (cosmic-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-crypto-hash [s390x] (cosmic-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-crypto-hash [ppc64el] (cosmic-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted rust-crypto-hash [s390x] (cosmic-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New binary: rust-crypto-hash [amd64] (cosmic-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-crypto-hash [arm64] (cosmic-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-crypto-hash [armhf] (cosmic-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-crypto-hash [amd64] (cosmic-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted rust-crypto-hash [armhf] (cosmic-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted rust-crypto-hash [arm64] (cosmic-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New sync: eclipse-platform-text (cosmic-proposed/primary) [4.7.3-2]
-queuebot:#ubuntu-release- New binary: kicad [amd64] (cosmic-proposed/universe) [5.0.0+dfsg1-2] (no packageset)
#ubuntu-release 2018-09-09
-queuebot:#ubuntu-release- New: accepted eclipse-platform-text [sync] (cosmic-proposed) [4.7.3-2]
-queuebot:#ubuntu-release- New: accepted kicad [amd64] (cosmic-proposed) [5.0.0+dfsg1-2]
#ubuntu-release 2019-09-02
-queuebot:#ubuntu-release- New: accepted ejabberd-contrib [amd64] (eoan-proposed) [0.2019.08.19~dfsg0-3]
-queuebot:#ubuntu-release- New: accepted ejabberd-contrib [armhf] (eoan-proposed) [0.2019.08.19~dfsg0-3]
-queuebot:#ubuntu-release- New: accepted ejabberd-contrib [ppc64el] (eoan-proposed) [0.2019.08.19~dfsg0-3]
-queuebot:#ubuntu-release- New: accepted ejabberd-contrib [arm64] (eoan-proposed) [0.2019.08.19~dfsg0-3]
-queuebot:#ubuntu-release- New: accepted ejabberd-contrib [s390x] (eoan-proposed) [0.2019.08.19~dfsg0-3]
-queuebot:#ubuntu-release- New: accepted ejabberd-contrib [i386] (eoan-proposed) [0.2019.08.19~dfsg0-3]
<vorlon> mwhudson: was the output going to also mention RC bugs filed in Debian that are keeping the package out of testing?
<mwhudson> vorlon: yes
<mwhudson> vorlon: in fact i have new output now
<vorlon> k :)
<mwhudson> vorlon: https://paste.ubuntu.com/p/XJQvjqSKJd/
<mwhudson> vorlon: does the environment that this script will run in have access to a directory containing the Packages files for the devel series?
<mwhudson> it must, right?
<vorlon> mwhudson: knot-resolver has versions in both release and -proposed so would need two separate removal lines (-s eoan-proposed), maybe we should care about that nuance.  Also, knot-resolver has hddemux as a reverse build-dep ugh
<mwhudson> vorlon: i guess i should invoke reverse-depends huh?
<vorlon> mwhudson: yes, in ~/mirror/ubuntu/dists
<vorlon> mwhudson: at least if it's going to recommend removal commands for cut'n'paste, yes
<mwhudson> vorlon: those are compressed in there though?
<mwhudson> or do they get uncompressed somewhere
<mwhudson> vorlon: the reason for asking about Packages is that i need to map binary package to source package name
<mwhudson> vorlon: is there an easier way to do that than grep-dctrl -SwnsPackage
<mwhudson> er other way around
<mwhudson> source to binaries
<vorlon> mwhudson: compressed and uh if you're in python I guess you want to use the python apt module instead of grep-dctrl
<mwhudson> vorlon: do i really
<vorlon> hypothetically
<mwhudson> i guess if they can read compressed indices i actually do...
<mwhudson> vorlon: https://paste.ubuntu.com/p/vKZHbbCCgr/
<mwhudson> vorlon: or even https://paste.ubuntu.com/p/6NC4VPMJTw/
 * RAOF grumbles about gvfs autopkgtest being flaky.
<FourDollars> RAOF: xkb-data 2.23.1-1ubuntu1.18.04.1 is not released https://bugs.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/1740894.
<ubot5> Launchpad bug 1740894 in OEM Priority Project bionic "KEY_RFKILL is not passed to userspace" [Critical,Fix committed]
<RAOF> Is that a problem? It was not clear to me on the bug (or in your email) that the systemd release needed too wait for xkb-data.
<FourDollars> RAOF: I thought  xkb-data 2.23.1-1ubuntu1.18.04.1 will be released to bionic-updates with systemd for https://bugs.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/1740894.
<ubot5> Launchpad bug 1740894 in OEM Priority Project bionic "KEY_RFKILL is not passed to userspace" [Critical,Fix committed]
<FourDollars> RAOF: Because xkb-data 2.23.1-1ubuntu1.18.04.1 caused some regression so I included the patch for systemd.
<FourDollars> RAOF: https://bugs.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/1740894/comments/49 comments about it.
<ubot5> Launchpad bug 1740894 in OEM Priority Project bionic "KEY_RFKILL is not passed to userspace" [Critical,Fix committed]
<FourDollars> RAOF: If you only released the systemd, it will make most of Dell latops' Wifi hotkey broken.
<RAOF> Urgh.
<RAOF> It would have been nice to have that documented in the bug somewhere!
<FourDollars> OK.
<RAOF> Because I have released the systemd SRU (which you said was urgent?)
<FourDollars> RAOF: Yes, it is urgent.
<FourDollars> RAOF: Is it possible to release xkb-data 2.23.1-1ubuntu1.18.04.1 right now?
<RAOF> FourDollars: The xkeyboard-config SRU appears to be a valid release candidate, but we haven't released it because you asked us not to (in https://bugs.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/1740894/comments/48)
<ubot5> Launchpad bug 1740894 in OEM Priority Project bionic "KEY_RFKILL is not passed to userspace" [Critical,Fix committed]
<RAOF> If that's no longer the case, then I can release xkeyboard-config, yes.
<FourDollars> RAOF: So I commented https://bugs.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/1740894/comments/49 and made the patch for system.
<ubot5> Launchpad bug 1740894 in OEM Priority Project bionic "KEY_RFKILL is not passed to userspace" [Critical,Fix committed]
<FourDollars> s/system/systemd/
<RAOF> So, I shall release xkeyboard-config  	2.23.1-1ubuntu1.18.04.1 into bionic-updates?
<FourDollars> RAOF: Yes, please.
<FourDollars> RAOF++ Thx a lot.
-queuebot:#ubuntu-release- New sync: libgeotiff (eoan-proposed/primary) [1.5.1-1]
-queuebot:#ubuntu-release- New binary: mpi4py [amd64] (eoan-proposed/universe) [3.0.2-13] (kubuntu)
-queuebot:#ubuntu-release- New binary: mpi4py [i386] (eoan-proposed/universe) [3.0.2-13] (kubuntu)
-queuebot:#ubuntu-release- New binary: mpi4py [ppc64el] (eoan-proposed/universe) [3.0.2-13] (kubuntu)
-queuebot:#ubuntu-release- New binary: mpi4py [arm64] (eoan-proposed/universe) [3.0.2-13] (kubuntu)
-queuebot:#ubuntu-release- New binary: mpi4py [armhf] (eoan-proposed/universe) [3.0.2-13] (kubuntu)
<Laney> vorlon: kernel bug> I assume you've appropriately reported it and cleaned up?
-queuebot:#ubuntu-release- New binary: mpi4py [s390x] (eoan-proposed/universe) [3.0.2-13] (kubuntu)
-queuebot:#ubuntu-release- New binary: golang-1.13 [amd64] (eoan-proposed/universe) [1.13~rc2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-1.13 [s390x] (eoan-proposed/universe) [1.13~rc2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-1.13 [ppc64el] (eoan-proposed/universe) [1.13~rc2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-1.13 [i386] (eoan-proposed/universe) [1.13~rc2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-1.13 [armhf] (eoan-proposed/universe) [1.13~rc2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (disco-proposed/main) [5.0.0-1002.3] (core)
-queuebot:#ubuntu-release- New source: python-infoblox-client (eoan-proposed/primary) [0.4.22-0ubuntu1]
-queuebot:#ubuntu-release- New binary: golang-1.13 [arm64] (eoan-proposed/universe) [1.13~rc2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (disco-proposed) [5.0.0-1002.3]
<sil2100> RikMills: hey! Do you know what's up with the kdeconnect autopkgtests for bionic?
<sil2100> RikMills: I see those are all red since recently, and  this is blocking qtbase-opensource-src from getting released
<RikMills> sil2100: discussed with juliank here https://irclogs.ubuntu.com/2019/08/06/%23ubuntu-devel.html#t10:36
<RikMills> long story short, an already flaky/racy test went completely bad with openssl 1.1.1. disable or skip I think
<sil2100> RikMills: could you please fill in a bug for this so that we don't forget what it's all about? I'll then hint it (with a bug reference for 'future reference') and release qtbase-opensource-src
<RikMills> sil2100: ok, will do so in a bit
<sil2100> RikMills: thank you!
<RikMills> sil2100: LP: #1842302
<ubot5> Launchpad bug 1842302 in kdeconnect (Ubuntu) "autopkgtests: testsslsocketlinereader fails in bionic since openssl 1.1.1" [Undecided,New] https://launchpad.net/bugs/1842302
<tarzeau> could i ask for ubuntu 19.10 gets rtl-433 from sid, since the official release version only differs very little from the git check out version. and comes with a proper manual page as well?
<ginggs> tarzeau: 'requestsync rtl-433'
<tarzeau> requestsync rtl-433
<ginggs> tarzeau: in a terminal :)
<ginggs> https://wiki.ubuntu.com/SyncRequestProcess
<tarzeau> ginggs: gpg error was invalid ipc response
<ginggs> tarzeau: you can also file the sync request bug in launchpad manually, but requestsync is easier
<tarzeau> i try to get rid of kwalletd(kde-runtime)/kinit5(kinit) and retry
<tarzeau> damn it keeps wanting to use that wallet crap i don't want
<tarzeau> i'm giving it with -k the key to use, why does it try stuff i don't want it to? broken
<tarzeau> where in launchpad?
<ginggs> against the rtl-433 source package https://launchpad.net/ubuntu/+source/rtl-433
<tarzeau> mighty complicated, i'll skip that i guess
-queuebot:#ubuntu-release- New binary: probert [amd64] (eoan-proposed/main) [0.0.17] (no packageset)
-queuebot:#ubuntu-release- New binary: probert [ppc64el] (eoan-proposed/main) [0.0.17] (no packageset)
-queuebot:#ubuntu-release- New binary: probert [i386] (eoan-proposed/main) [0.0.17] (no packageset)
-queuebot:#ubuntu-release- New binary: probert [s390x] (eoan-proposed/main) [0.0.17] (no packageset)
-queuebot:#ubuntu-release- New binary: probert [armhf] (eoan-proposed/main) [0.0.17] (no packageset)
-queuebot:#ubuntu-release- New binary: probert [arm64] (eoan-proposed/main) [0.0.17] (no packageset)
-queuebot:#ubuntu-release- New: accepted mpi4py [amd64] (eoan-proposed) [3.0.2-13]
-queuebot:#ubuntu-release- New: accepted mpi4py [armhf] (eoan-proposed) [3.0.2-13]
-queuebot:#ubuntu-release- New: accepted mpi4py [ppc64el] (eoan-proposed) [3.0.2-13]
-queuebot:#ubuntu-release- New: accepted mpi4py [arm64] (eoan-proposed) [3.0.2-13]
-queuebot:#ubuntu-release- New: accepted mpi4py [s390x] (eoan-proposed) [3.0.2-13]
-queuebot:#ubuntu-release- New: accepted mpi4py [i386] (eoan-proposed) [3.0.2-13]
-queuebot:#ubuntu-release- New: accepted probert [amd64] (eoan-proposed) [0.0.17]
-queuebot:#ubuntu-release- New: accepted probert [armhf] (eoan-proposed) [0.0.17]
-queuebot:#ubuntu-release- New: accepted probert [ppc64el] (eoan-proposed) [0.0.17]
-queuebot:#ubuntu-release- New: accepted probert [arm64] (eoan-proposed) [0.0.17]
-queuebot:#ubuntu-release- New: accepted probert [s390x] (eoan-proposed) [0.0.17]
-queuebot:#ubuntu-release- New: accepted probert [i386] (eoan-proposed) [0.0.17]
-queuebot:#ubuntu-release- Unapproved: dkms (bionic-proposed/main) [2.3-3ubuntu9.5 => 2.3-3ubuntu9.6] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: dkms (disco-proposed/main) [2.6.1-4ubuntu2.2 => 2.6.1-4ubuntu2.3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rejected apt [source] (disco-updates) [1.8.3]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-utils [source] (disco-proposed) [0.31-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: apt (disco-proposed/main) [1.8.1 => 1.8.3] (core)
<sil2100> coreycb: hey! The cinder that's currently in disco-proposed is blocking another cinder upload that's in the queue
<sil2100> Could you verify the -proposed one so we can release it?
<sil2100> coreycb: it's been in -proposed for 33 days already
-queuebot:#ubuntu-release- Unapproved: accepted smc-tools [source] (disco-proposed) [1.2.0-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: rejected gnome-initial-setup [source] (bionic-proposed) [3.28.0-2ubuntu6.16.04.5]
<ahasenack> hi guys, on august 23rd, someone promoted all php7.3 packages from universe to main (https://launchpad.net/ubuntu/+source/php7.3/+publishinghistory), but not all of the 7.2 binary ones were in main before
<ahasenack> this has caused php7.3 to get stuck in eoan proposed: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#php7.3
<ahasenack> due to some dependencies being in universe only
<ahasenack> for example, php7.2-imap was in eoan universe
<ahasenack> but php7.3-imap 7.3.6 is in eoan/universe, whereas php7.3-imap 7.3.8 is in eoan-proposed/main
<rbasak> ^ to resolve, I think an AA needs to demote a bunch of src:php7.3 binaries back to universe. The ones that match the src:php7.2 binaries, at least.
-queuebot:#ubuntu-release- Unapproved: accepted gnome-initial-setup [source] (bionic-proposed) [3.28.0-2ubuntu6.16.04.6]
<rbasak> (also I suspect the standing PHP MIR doesn't permit those packages in main anyway)
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (disco-proposed) [1.8.3]
<apw> rbasak, hmmm, nasty
<vorlon> Laney: I cleaned up but haven't reported the bug yet, haven't had time to isolate the trigger
<Laney> nod
<apw> vorlon, the kernel version reported was a few back-rev, no idea of that is releveant
<vorlon> that too
<vorlon> since they've all now been rebooted, was going to wait and see if it happened again
<apw> rbasak, ok overrides in progress
<rbasak> Thanks!
<ahasenack> apw: thanks
<ahasenack> apw: php7.3 seems sorted, but I'm now seeing dep8 test results from august 8th showing up all of a sudden. It looks like the tests were run before the deps were sorted, is that expected?
<ahasenack> that means they ran (and are green) with mysql 5.7, not mysql 8 which is what is in the archive now
<ahasenack> in fact, the only red so far, armhf, is because that one picked up mysql 8
<ahasenack> (in mediawiki)
-queuebot:#ubuntu-release- New binary: llvm-toolchain-9 [armhf] (eoan-proposed/main) [1:9~+rc3-1~exp1] (no packageset)
#ubuntu-release 2019-09-03
<LocutusOfBorg> hello, can we please have some haskell new processing?
-queuebot:#ubuntu-release- New binary: gr-fcdproplus [s390x] (eoan-proposed/universe) [3.8~20190817-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-fosphor [s390x] (eoan-proposed/universe) [3.8~1.278b66e-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-iqbal [amd64] (eoan-proposed/universe) [0.38-3] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-iio [s390x] (eoan-proposed/universe) [0.3-6] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-fcdproplus [amd64] (eoan-proposed/universe) [3.8~20190817-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-fcdproplus [ppc64el] (eoan-proposed/universe) [3.8~20190817-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-fosphor [ppc64el] (eoan-proposed/universe) [3.8~1.278b66e-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-iio [i386] (eoan-proposed/universe) [0.3-6] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-iqbal [s390x] (eoan-proposed/universe) [0.38-3] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-iio [amd64] (eoan-proposed/universe) [0.3-6] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-rds [s390x] (eoan-proposed/universe) [3.8.0.0.f1c584a-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-iqbal [ppc64el] (eoan-proposed/universe) [0.38-3] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-fosphor [i386] (eoan-proposed/universe) [3.8~1.278b66e-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-iqbal [i386] (eoan-proposed/universe) [0.38-3] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-iio [ppc64el] (eoan-proposed/universe) [0.3-6] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-rds [amd64] (eoan-proposed/universe) [3.8.0.0.f1c584a-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-rds [ppc64el] (eoan-proposed/universe) [3.8.0.0.f1c584a-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-fcdproplus [armhf] (eoan-proposed/universe) [3.8~20190817-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-iqbal [armhf] (eoan-proposed/universe) [0.38-3] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-iqbal [arm64] (eoan-proposed/universe) [0.38-3] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-rds [i386] (eoan-proposed/universe) [3.8.0.0.f1c584a-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-fcdproplus [arm64] (eoan-proposed/universe) [3.8~20190817-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-fosphor [arm64] (eoan-proposed/universe) [3.8~1.278b66e-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted gr-fcdproplus [amd64] (eoan-proposed) [3.8~20190817-2]
-queuebot:#ubuntu-release- New: accepted gr-fcdproplus [armhf] (eoan-proposed) [3.8~20190817-2]
-queuebot:#ubuntu-release- New: accepted gr-fcdproplus [s390x] (eoan-proposed) [3.8~20190817-2]
-queuebot:#ubuntu-release- New binary: gr-fosphor [armhf] (eoan-proposed/universe) [3.8~1.278b66e-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted gr-fcdproplus [arm64] (eoan-proposed) [3.8~20190817-2]
-queuebot:#ubuntu-release- New: accepted gr-fosphor [i386] (eoan-proposed) [3.8~1.278b66e-2]
-queuebot:#ubuntu-release- New: accepted gr-fcdproplus [ppc64el] (eoan-proposed) [3.8~20190817-2]
-queuebot:#ubuntu-release- New: accepted gr-fosphor [ppc64el] (eoan-proposed) [3.8~1.278b66e-2]
-queuebot:#ubuntu-release- New: accepted gr-iio [amd64] (eoan-proposed) [0.3-6]
-queuebot:#ubuntu-release- New: accepted gr-iio [ppc64el] (eoan-proposed) [0.3-6]
-queuebot:#ubuntu-release- New: accepted gr-iqbal [amd64] (eoan-proposed) [0.38-3]
-queuebot:#ubuntu-release- New: accepted gr-iqbal [armhf] (eoan-proposed) [0.38-3]
-queuebot:#ubuntu-release- New: accepted gr-iqbal [ppc64el] (eoan-proposed) [0.38-3]
-queuebot:#ubuntu-release- New: accepted gr-rds [amd64] (eoan-proposed) [3.8.0.0.f1c584a-2]
-queuebot:#ubuntu-release- New: accepted gr-rds [ppc64el] (eoan-proposed) [3.8.0.0.f1c584a-2]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-9 [armhf] (eoan-proposed) [1:9~+rc3-1~exp1]
-queuebot:#ubuntu-release- New: accepted gr-fosphor [s390x] (eoan-proposed) [3.8~1.278b66e-2]
-queuebot:#ubuntu-release- New: accepted gr-iio [s390x] (eoan-proposed) [0.3-6]
-queuebot:#ubuntu-release- New: accepted gr-iqbal [i386] (eoan-proposed) [0.38-3]
-queuebot:#ubuntu-release- New: accepted gr-rds [i386] (eoan-proposed) [3.8.0.0.f1c584a-2]
-queuebot:#ubuntu-release- New binary: gr-fcdproplus [i386] (eoan-proposed/universe) [3.8~20190817-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted gr-iio [i386] (eoan-proposed) [0.3-6]
-queuebot:#ubuntu-release- New: accepted gr-iqbal [s390x] (eoan-proposed) [0.38-3]
-queuebot:#ubuntu-release- New: accepted gr-iqbal [arm64] (eoan-proposed) [0.38-3]
-queuebot:#ubuntu-release- New: accepted gr-rds [s390x] (eoan-proposed) [3.8.0.0.f1c584a-2]
-queuebot:#ubuntu-release- New binary: gr-iio [arm64] (eoan-proposed/universe) [0.3-6] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-rds [arm64] (eoan-proposed/universe) [3.8.0.0.f1c584a-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-iio [armhf] (eoan-proposed/universe) [0.3-6] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-fosphor [amd64] (eoan-proposed/universe) [3.8~1.278b66e-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-rds [armhf] (eoan-proposed/universe) [3.8.0.0.f1c584a-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: haproxy (bionic-proposed/main) [1.8.8-1ubuntu0.4 => 1.8.8-1ubuntu0.5] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: apt (bionic-proposed/main) [1.6.11 => 1.6.12] (core)
<ahasenack> hi, hoping this is the right channel. I got an email about a samba sru for disco causing increased crashes. This link, however, shows just one crash: https://errors.ubuntu.com/?release=Ubuntu%2019.04&package=samba&period=week&version=2%3A4.10.0%2Bdfsg-0ubuntu2.3
<ahasenack> is it a case of 1 being infinitely bigger than 0 and that triggered the check?
-queuebot:#ubuntu-release- Unapproved: s390-tools (disco-proposed/main) [2.8.0-0ubuntu5 => 2.8.0-0ubuntu5.1] (core)
<xnox> ahasenack:  this happens from time to time, and buckets realize braindeadness and auto-correct themselves. I don't think any actions are required on your part, and it will auto-resume auto-phasing.
<ahasenack> the other report says: samba	2:4.10.0+dfsg-0ubuntu2.3	40% of users			0
<ahasenack> (https://people.canonical.com/~ubuntu-archive/phased-updates.html) so it is ongoing already?
<ahasenack> or stopped at 40%
<Laney> does it auto resume?
<xnox> Laney:  either that, or bdmurray fixes it =)
<Laney> I usually reply to the email and explain why I think it should be turned back on
<ahasenack> the email says it won't autoresume
<ahasenack> yeah, I checked tzs, bdmurray won't be online for a few hours still
<ahasenack> Laney: I'll reply to the email then, sounds good
<Laney> speaking of, we should sort gnome-shell out
<LocutusOfBorg> vorlon, any idea for the s390x testsuite hangs?
<LocutusOfBorg> e.g. https://launchpad.net/ubuntu/+source/haskell-lens-aeson/1.0.2-6build2/+build/17507670
<coreycb> sil2100: hi thanks for the nudge. we're working on cinder. we have a few regression failures that we're debugging.
<tumbleweed> ./45
<ahasenack> hi, how would I ask for a re-run of all tests (green included) of php7.3 in eoan-proposed?
<ahasenack> that package wasn't being considered before because it had universe deps, sometihng apw fixed yesterday, but then all those tests showed up, and they ran many weeks ago, not yesterday
<ahasenack> as a result, they didn't pick up mysql-8.0. Many of those greens used mysql 5.7, which is what was in proposed back then
<ahasenack> something like this perhaps?
<ahasenack> ./retry-autopkgtest-regressions -s eoan --state PASS --blocks php7.3
<teward> is it too late to sync a package from Unstable so that we don't have an Ubuntu delta?  I know it's past FF but this is just to remove the ubuntu delta since the package (xca in Universe) in Unstable has been updated so we no longer need the Ubuntu delta (functionally it doesn't introduce many changes, but under the hood the package is a lot more policy compliant now, and up to date from a packaging perspective).
<teward> (and fun fact, it's my bootprints on the package in Debian too xD)
<ahasenack> teward: all that matters is the diff between what is in eoan now, and what you are bringing in
<ahasenack> I'm contemplating something similar in a few, as soon as lp ingests the new debian package
<ginggs> teward: xca can't be synced - xca_2.1.2.orig.tar.gz tarballs differ
<teward> *raises an eyebrow*
<teward> that's... interesting
<teward> ginggs: i wonder if Debian using a gbp workflow is the problem
<teward> because it *looks* like the tarball uploaded to Ubuntu had a prebuilt configure rather than letting it run via dh
<teward> *headscratches*
<ginggs> i don't see xca_2.1.2.orig.tar.gz in pristine-tar
<teward> oh you know what
<teward> i think i see the issue
<teward> let me double check
<teward> ginggs: yeah that's a GBP issue it refuses to update pristine-tar
<teward> give me a minute
<teward> ahhhh I see why the tarballs differ
<teward> the watch file in Debian pulls from the actual GH source code generated tags rather than the prebuilt then attached xca-2.1.2.tar.gz
<ahasenack> I've seen that before with another package
<teward> the two key differences that I can see:
<teward> xca-2.1.2.tar.gz premade tarball has a configure
<ahasenack> there were actual different contents, it wasn't just a compression artifact
<teward> whereas RELEASE.2.1.2.tar.gz has configure.ac
<teward> and doesn't have the configure
<teward> hmmmmm
<ahasenack> and it was with github too
<teward> yeah the tricky part is when there's *two* versions of the code available
<teward> one created by the devs and then attached as part of building/releasing
<teward> and GH's automatic 'source code' tarball it tags
<teward> which explains the sync conflicts
<ahasenack> it was with virt-manager:
<ahasenack> https://github.com/virt-manager/virt-manager/archive/v2.2.0.tar.gz != https://releases.pagure.org/virt-manager/virt-manager-2.2.0.tar.gz
<teward> yeah I just confirmed the issue, the autotags on GH and the ones on their 'site' differ, though both are hosted on GH
 * teward headscratches
<teward> interesting
<teward> well guess that settles that
 * teward returns to the shadows
<ginggs> teward: you could fakesync, but not sure of the benefit
<teward> ginggs: meh, they're basically identical in functionality, but we're way behind on debian policy and compat on the package here in Ubuntu, which was my primary concern.  Should be fine though, we can sync next time there's an XCA upstream release and I've got it packaged in Debian
<teward> also figured out why GBP wasn't working for me *derps*
<teward> E:BrokenGitRepoLocally
<teward> >.>
<sil2100> vorlon, Laney, infinity: could one of you take a look at my quick FFe? https://bugs.launchpad.net/ubuntu/+source/u-boot/+bug/1838064
<ubot5> Launchpad bug 1838064 in u-boot (Ubuntu Bionic) "[FFe] Support Nitrogen6x board" [High,Confirmed]
<doko> sforshee, apw: please could you have a look at the linux autopkg test failures, and if they are not real, override the tests?
-queuebot:#ubuntu-release- New: accepted gr-fosphor [amd64] (eoan-proposed) [3.8~1.278b66e-2]
-queuebot:#ubuntu-release- New: accepted gr-rds [armhf] (eoan-proposed) [3.8.0.0.f1c584a-2]
-queuebot:#ubuntu-release- New: accepted gr-iio [arm64] (eoan-proposed) [0.3-6]
-queuebot:#ubuntu-release- New: accepted gr-fcdproplus [i386] (eoan-proposed) [3.8~20190817-2]
-queuebot:#ubuntu-release- New: accepted gr-fosphor [armhf] (eoan-proposed) [3.8~1.278b66e-2]
-queuebot:#ubuntu-release- New: accepted gr-rds [arm64] (eoan-proposed) [3.8.0.0.f1c584a-2]
-queuebot:#ubuntu-release- New: accepted gr-fosphor [arm64] (eoan-proposed) [3.8~1.278b66e-2]
-queuebot:#ubuntu-release- New: accepted gr-iio [armhf] (eoan-proposed) [0.3-6]
<vorlon> LocutusOfBorg: no idea on s390x testsuite hangs. was this reproduced in Debian?
<vorlon> ahasenack: retrying the php7.3 tests that did already pass won't change whether proposed-migration considers php7.3 migratable, why do you want those rerun?
<ahasenack> vorlon: because they were run with mysql 5.7, not mysql-8
<vorlon> ahasenack: ok but what does rerunning them get you?
<ahasenack> vorlon: up until yesterday php7.3 was in a state "not considered" because of universe depends. That was fixed yesterday, and all of a sudden these old test results popped up
<vorlon> a failing test, after the succeeding test, isn't going to cause britney to record it as a failure
<ahasenack> vorlon: in terms of the archive, if the few reds are solved now, this will migrate, with the current greens not having been run against what is in the archive now
<ahasenack> my fear is landing stuff that won't work with mysql-8 and php 7.3.98
<ahasenack> 7.3.8
<vorlon> yes, and rerunning tests won't give you a gate for that
<ahasenack> I don't understand why a failure now will not block migration
<vorlon> because that's not how it's implemented in britney
<vorlon> britney already has the successful test results, it does not re-poll swift
<vorlon> (which would not scale)
<ahasenack> doesn't it do that if a new dep is uploaded while the package is in proposed?
<ahasenack> re-run the test with the new dep?
<ahasenack> or only if it was a red before?
<vorlon> it reruns it with a different trigger
<vorlon> and records the result against the newly-uploaded package only
<ahasenack> so best way forward now is to resolve the few reds, let it migrate, and then if we have reason to believe it could fail with the untested combination, upload again?
<vorlon> yes
<ahasenack> php7.3-7.3.8, that is
<ahasenack> vorlon: and the tests are run even when there are universe deps blocking the consideration of the package? Just trying to understand how old test results suddenly popped up after the universe deps were sorted
<vorlon> ahasenack: anyway if you do want to rerun the tests so that you have the results available for comparison, you can self-serve with retry-autopkgtest-regressions in ubuntu-archive-tools (retry-autopkgtest-regressions --blocks php7.3 --state PASS) but the results won't be reported on update_excuses, you'd have to drill down
<ahasenack> yeah, I got the urls for that, but didn't know they wouldn't be reported in excuses, or considered for migration
<vorlon> sil2100: acked for FF
<sil2100> vorlon: thanks o/
<rbasak> ahasenack: yeah I wasn't expecting test reruns to gate, but they would flag any problems correctly that we could then examine and fix.
<ahasenack> we could just upload to bileto
<rbasak> Sure
<LocutusOfBorg> vorlon, yes
<LocutusOfBorg> this is why I'm patching them to disable testsuite, because eventually a fix will come
<LocutusOfBorg> we are discussing it right now
<vorlon> ok
<ginggs> would some please look at a FFe for blender? LP: #1842215
<ubot5> Launchpad bug 1842215 in blender (Ubuntu) "FFe: Sync blender 2.80+dfsg-3 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/1842215
<sforshee> doko, apw: this is perf failing to build because it implemented its own gettid call, and in glibc 2.30 unistd.h also has a gettid declaration
<sforshee> apw: so it's not a toolchain issue, you can hint that and we'll need to apply a fix to the kernel
-queuebot:#ubuntu-release- New binary: mkl-dnn [amd64] (eoan-proposed/universe) [1.0.2-1] (no packageset)
<LocutusOfBorg> vorlon, we can't progress on haskell without approving syncs in new queue...
<vorlon> LocutusOfBorg: ok, looking.  (you will have to prod AAs about such things, the NEW queue doesn't get watched much post-FF.)
-queuebot:#ubuntu-release- New: accepted haskell-bytestring-to-vector [sync] (eoan-proposed) [0.3.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-githash [sync] (eoan-proposed) [0.1.3.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-network-byte-order [sync] (eoan-proposed) [0.0.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-serialise [sync] (eoan-proposed) [0.2.1.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-simple-templates [sync] (eoan-proposed) [0.8.0.1-6]
-queuebot:#ubuntu-release- New: accepted haskell-splitmix [sync] (eoan-proposed) [0.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-bytestring-to-vector [sync] (eoan-proposed) [0.3.0.1-2]
-queuebot:#ubuntu-release- New: accepted haskell-network-byte-order [sync] (eoan-proposed) [0.0.0.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-simple [sync] (eoan-proposed) [0.11.2-4]
-queuebot:#ubuntu-release- New: accepted haskell-githash [sync] (eoan-proposed) [0.1.3.1-3]
-queuebot:#ubuntu-release- New: accepted haskell-splitmix [sync] (eoan-proposed) [0.0.2-2]
-queuebot:#ubuntu-release- New: accepted haskell-serialise [sync] (eoan-proposed) [0.2.1.0-3]
-queuebot:#ubuntu-release- New: accepted haskell-dec [sync] (eoan-proposed) [0.0.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-lens-family-core [sync] (eoan-proposed) [1.2.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-bytestring-conversion [amd64] (eoan-proposed) [0.3.1-6build1]
-queuebot:#ubuntu-release- New: accepted haskell-bytestring-conversion [armhf] (eoan-proposed) [0.3.1-6build1]
-queuebot:#ubuntu-release- New: accepted haskell-bytestring-conversion [ppc64el] (eoan-proposed) [0.3.1-6build1]
-queuebot:#ubuntu-release- New: accepted haskell-bytestring-conversion [amd64] (eoan-proposed) [0.3.1-6build2]
-queuebot:#ubuntu-release- New: accepted haskell-bytestring-conversion [s390x] (eoan-proposed) [0.3.1-6build2]
-queuebot:#ubuntu-release- New: accepted haskell-bytestring-conversion [arm64] (eoan-proposed) [0.3.1-6build1]
-queuebot:#ubuntu-release- New: accepted haskell-bytestring-conversion [s390x] (eoan-proposed) [0.3.1-6build1]
-queuebot:#ubuntu-release- New: accepted haskell-bytestring-conversion [i386] (eoan-proposed) [0.3.1-6build1]
-queuebot:#ubuntu-release- New: accepted haskell-bytestring-conversion [i386] (eoan-proposed) [0.3.1-6build2]
-queuebot:#ubuntu-release- New: accepted haskell-bytestring-conversion [arm64] (eoan-proposed) [0.3.1-6build2]
-queuebot:#ubuntu-release- New: accepted haskell-bytestring-conversion [ppc64el] (eoan-proposed) [0.3.1-6build2]
-queuebot:#ubuntu-release- New: accepted haskell-bytestring-conversion [armhf] (eoan-proposed) [0.3.1-6build2]
-queuebot:#ubuntu-release- New binary: haskell-githash [amd64] (eoan-proposed/none) [0.1.3.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-network-byte-order [i386] (eoan-proposed/none) [0.0.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-splitmix [amd64] (eoan-proposed/none) [0.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-githash [i386] (eoan-proposed/none) [0.1.3.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-splitmix [i386] (eoan-proposed/none) [0.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-splitmix [amd64] (eoan-proposed/none) [0.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-bytestring-to-vector [amd64] (eoan-proposed/none) [0.3.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-bytestring-to-vector [i386] (eoan-proposed/none) [0.3.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-lens-family-core [amd64] (eoan-proposed/none) [1.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-splitmix [i386] (eoan-proposed/none) [0.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-bytestring-to-vector [i386] (eoan-proposed/none) [0.3.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-network-byte-order [amd64] (eoan-proposed/none) [0.0.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-dec [i386] (eoan-proposed/none) [0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-network-byte-order [amd64] (eoan-proposed/none) [0.0.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-network-byte-order [arm64] (eoan-proposed/none) [0.0.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-splitmix [arm64] (eoan-proposed/none) [0.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-network-byte-order [i386] (eoan-proposed/none) [0.0.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-serialise [amd64] (eoan-proposed/none) [0.2.1.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-bytestring-to-vector [amd64] (eoan-proposed/none) [0.3.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-dec [amd64] (eoan-proposed/none) [0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-dec [armhf] (eoan-proposed/none) [0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-network-byte-order [arm64] (eoan-proposed/none) [0.0.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-splitmix [arm64] (eoan-proposed/none) [0.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-lens-family-core [i386] (eoan-proposed/none) [1.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-serialise [i386] (eoan-proposed/none) [0.2.1.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-bytestring-to-vector [armhf] (eoan-proposed/none) [0.3.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-githash [armhf] (eoan-proposed/none) [0.1.3.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-network-byte-order [armhf] (eoan-proposed/none) [0.0.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-splitmix [armhf] (eoan-proposed/none) [0.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-githash [arm64] (eoan-proposed/none) [0.1.3.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-network-byte-order [armhf] (eoan-proposed/none) [0.0.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-lens-family-core [arm64] (eoan-proposed/none) [1.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-splitmix [armhf] (eoan-proposed/none) [0.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-bytestring-to-vector [arm64] (eoan-proposed/none) [0.3.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-bytestring-to-vector [arm64] (eoan-proposed/none) [0.3.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-lens-family-core [armhf] (eoan-proposed/none) [1.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-bytestring-to-vector [armhf] (eoan-proposed/none) [0.3.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-dec [arm64] (eoan-proposed/none) [0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-serialise [arm64] (eoan-proposed/none) [0.2.1.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-bytestring-to-vector [s390x] (eoan-proposed/universe) [0.3.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-network-byte-order [s390x] (eoan-proposed/universe) [0.0.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-githash [s390x] (eoan-proposed/universe) [0.1.3.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-splitmix [s390x] (eoan-proposed/universe) [0.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-dec [s390x] (eoan-proposed/universe) [0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-lens-family-core [s390x] (eoan-proposed/universe) [1.2.3-1] (no packageset)
<ginggs> would an AA please review mkl-dnn in NEW, it's an upstream micro-release, compared to 1.0-2 already in proposed, and fixes FTBFS with GCC 9
-queuebot:#ubuntu-release- New binary: haskell-bytestring-to-vector [ppc64el] (eoan-proposed/universe) [0.3.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-network-byte-order [ppc64el] (eoan-proposed/universe) [0.0.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-githash [ppc64el] (eoan-proposed/universe) [0.1.3.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-serialise [ppc64el] (eoan-proposed/universe) [0.2.1.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-splitmix [ppc64el] (eoan-proposed/universe) [0.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-bytestring-to-vector [ppc64el] (eoan-proposed) [0.3.0.1-2]
-queuebot:#ubuntu-release- New: accepted haskell-network-byte-order [ppc64el] (eoan-proposed) [0.0.0.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-splitmix [ppc64el] (eoan-proposed) [0.0.2-2]
-queuebot:#ubuntu-release- New binary: haskell-lens-family-core [ppc64el] (eoan-proposed/universe) [1.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-githash [ppc64el] (eoan-proposed) [0.1.3.1-3]
-queuebot:#ubuntu-release- New binary: haskell-dec [ppc64el] (eoan-proposed/universe) [0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-serialise [ppc64el] (eoan-proposed) [0.2.1.0-3]
-queuebot:#ubuntu-release- New: accepted haskell-bytestring-to-vector [armhf] (eoan-proposed) [0.3.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-dec [arm64] (eoan-proposed) [0.0.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-githash [s390x] (eoan-proposed) [0.1.3.1-3]
-queuebot:#ubuntu-release- New: accepted haskell-network-byte-order [s390x] (eoan-proposed) [0.0.0.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-splitmix [s390x] (eoan-proposed) [0.0.2-2]
-queuebot:#ubuntu-release- New: accepted haskell-bytestring-to-vector [s390x] (eoan-proposed) [0.3.0.1-2]
-queuebot:#ubuntu-release- New: accepted haskell-lens-family-core [s390x] (eoan-proposed) [1.2.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-dec [s390x] (eoan-proposed) [0.0.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-serialise [arm64] (eoan-proposed) [0.2.1.0-3]
-queuebot:#ubuntu-release- New: accepted haskell-bytestring-to-vector [arm64] (eoan-proposed) [0.3.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-bytestring-to-vector [armhf] (eoan-proposed) [0.3.0.1-2]
-queuebot:#ubuntu-release- New: accepted haskell-githash [armhf] (eoan-proposed) [0.1.3.1-3]
-queuebot:#ubuntu-release- New: accepted haskell-splitmix [armhf] (eoan-proposed) [0.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-bytestring-to-vector [arm64] (eoan-proposed) [0.3.0.1-2]
-queuebot:#ubuntu-release- New: accepted haskell-lens-family-core [armhf] (eoan-proposed) [1.2.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-githash [arm64] (eoan-proposed) [0.1.3.1-3]
-queuebot:#ubuntu-release- New: accepted haskell-splitmix [armhf] (eoan-proposed) [0.0.2-2]
-queuebot:#ubuntu-release- New: accepted haskell-dec [amd64] (eoan-proposed) [0.0.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-lens-family-core [arm64] (eoan-proposed) [1.2.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-network-byte-order [arm64] (eoan-proposed) [0.0.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-network-byte-order [armhf] (eoan-proposed) [0.0.0.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-splitmix [arm64] (eoan-proposed) [0.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-dec [armhf] (eoan-proposed) [0.0.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-network-byte-order [armhf] (eoan-proposed) [0.0.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-lens-family-core [i386] (eoan-proposed) [1.2.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-serialise [i386] (eoan-proposed) [0.2.1.0-3]
-queuebot:#ubuntu-release- New: accepted haskell-bytestring-to-vector [amd64] (eoan-proposed) [0.3.0.1-2]
-queuebot:#ubuntu-release- New: accepted haskell-network-byte-order [amd64] (eoan-proposed) [0.0.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-network-byte-order [amd64] (eoan-proposed) [0.0.0.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-serialise [amd64] (eoan-proposed) [0.2.1.0-3]
-queuebot:#ubuntu-release- New: accepted haskell-splitmix [arm64] (eoan-proposed) [0.0.2-2]
-queuebot:#ubuntu-release- New: accepted haskell-lens-family-core [amd64] (eoan-proposed) [1.2.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-network-byte-order [arm64] (eoan-proposed) [0.0.0.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-network-byte-order [i386] (eoan-proposed) [0.0.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-splitmix [i386] (eoan-proposed) [0.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-bytestring-to-vector [amd64] (eoan-proposed) [0.3.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-bytestring-to-vector [i386] (eoan-proposed) [0.3.0.1-2]
-queuebot:#ubuntu-release- New: accepted haskell-githash [amd64] (eoan-proposed) [0.1.3.1-3]
-queuebot:#ubuntu-release- New: accepted haskell-splitmix [i386] (eoan-proposed) [0.0.2-2]
-queuebot:#ubuntu-release- New: accepted haskell-bytestring-to-vector [i386] (eoan-proposed) [0.3.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-network-byte-order [i386] (eoan-proposed) [0.0.0.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-dec [i386] (eoan-proposed) [0.0.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-githash [i386] (eoan-proposed) [0.1.3.1-3]
-queuebot:#ubuntu-release- New: accepted haskell-splitmix [amd64] (eoan-proposed) [0.0.2-2]
-queuebot:#ubuntu-release- New: accepted haskell-splitmix [amd64] (eoan-proposed) [0.0.2-1]
-queuebot:#ubuntu-release- New: accepted mkl-dnn [amd64] (eoan-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted gnome-getting-started-docs [amd64] (eoan-proposed) [3.33.90-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted marco [amd64] (eoan-proposed) [1.22.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted marco [armhf] (eoan-proposed) [1.22.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted marco [ppc64el] (eoan-proposed) [1.22.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted marco [arm64] (eoan-proposed) [1.22.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted marco [s390x] (eoan-proposed) [1.22.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted marco [i386] (eoan-proposed) [1.22.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted haskell-lens-family-core [ppc64el] (eoan-proposed) [1.2.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-dec [ppc64el] (eoan-proposed) [0.0.3-1]
-queuebot:#ubuntu-release- New sync: rust-pangocairo-sys (eoan-proposed/primary) [0.10.0-1]
#ubuntu-release 2019-09-04
<RAOF> Boy, those gvfs autopkgtests really suck, don't they â¹ï¸
-queuebot:#ubuntu-release- Unapproved: update-notifier (trusty-proposed/main) [0.154.1ubuntu6 => 0.154.1ubuntu7] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted rust-pangocairo-sys [sync] (eoan-proposed) [0.10.0-1]
<vorlon> ginggs: mkl-dnn is through NEW but I see it has failed its autopkgtest
-queuebot:#ubuntu-release- New: accepted golang-1.13 [amd64] (eoan-proposed) [1.13~rc2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-1.13 [armhf] (eoan-proposed) [1.13~rc2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-1.13 [ppc64el] (eoan-proposed) [1.13~rc2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-1.13 [arm64] (eoan-proposed) [1.13~rc2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-1.13 [s390x] (eoan-proposed) [1.13~rc2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-1.13 [i386] (eoan-proposed) [1.13~rc2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted libgeotiff [sync] (eoan-proposed) [1.5.1-1]
-queuebot:#ubuntu-release- New binary: haskell-http-link-header [amd64] (eoan-proposed/universe) [1.0.3.1-2build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-http-link-header [i386] (eoan-proposed/universe) [1.0.3.1-2build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-http-link-header [arm64] (eoan-proposed/universe) [1.0.3.1-2build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-http-link-header [ppc64el] (eoan-proposed/universe) [1.0.3.1-2build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-http-link-header [armhf] (eoan-proposed/universe) [1.0.3.1-2build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-http-link-header [s390x] (eoan-proposed/universe) [1.0.3.1-2build1] (no packageset)
<doko> update_excuses isn't updated since yesterday night
<vorlon> doko: not so, https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html has a timestamp of 2019.09.04 03:47:01 +0000
-queuebot:#ubuntu-release- New binary: httpdirfs-fuse [amd64] (eoan-proposed/universe) [1.0.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: httpdirfs-fuse [armhf] (eoan-proposed/universe) [1.0.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pangocairo-sys [amd64] (eoan-proposed/universe) [0.10.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: httpdirfs-fuse [arm64] (eoan-proposed/universe) [1.0.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pangocairo-sys [i386] (eoan-proposed/universe) [0.10.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: httpdirfs-fuse [i386] (eoan-proposed/universe) [1.0.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: httpdirfs-fuse [ppc64el] (eoan-proposed/universe) [1.0.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pangocairo-sys [arm64] (eoan-proposed/universe) [0.10.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pangocairo-sys [ppc64el] (eoan-proposed/universe) [0.10.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: httpdirfs-fuse [s390x] (eoan-proposed/universe) [1.0.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pangocairo-sys [s390x] (eoan-proposed/universe) [0.10.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pangocairo-sys [armhf] (eoan-proposed/universe) [0.10.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-pangocairo-sys [ppc64el] (eoan-proposed) [0.10.0-1]
-queuebot:#ubuntu-release- New: accepted rust-pangocairo-sys [s390x] (eoan-proposed) [0.10.0-1]
-queuebot:#ubuntu-release- New: accepted rust-pangocairo-sys [amd64] (eoan-proposed) [0.10.0-1]
-queuebot:#ubuntu-release- New: accepted rust-pangocairo-sys [armhf] (eoan-proposed) [0.10.0-1]
-queuebot:#ubuntu-release- New: accepted rust-pangocairo-sys [arm64] (eoan-proposed) [0.10.0-1]
-queuebot:#ubuntu-release- New: accepted rust-pangocairo-sys [i386] (eoan-proposed) [0.10.0-1]
<doko> Laney: could you or somebody look at the mhash ftbfs? didn't reach yet the 5-day limit, but blocking glibc (multiarch-support removal)
<tarzeau> https://launchpadlibrarian.net/439023089/buildlog_ubuntu-eoan-amd64.colmap_3.6+dev2-2_BUILDING.txt.gz
<tarzeau> can i do anything about that?
<tarzeau> i'm perfectly able to build it on my 19.10 eoan
<ginggs> tarzeau: isn't that the same as debian #925655 ?
<ubot5> Debian bug 925655 in src:colmap "colmap: ftbfs with GCC-9" [Serious,Open] http://bugs.debian.org/925655
<ginggs> tarzeau: fix it in debian then request a sync
<tarzeau> can't built it with gcc9 either :( indeed
<Laney> should probably use #ubuntu-motu for discussing that (and #ubuntu-devel for doko's question)
-queuebot:#ubuntu-release- New binary: haskell-simple-templates [amd64] (eoan-proposed/universe) [0.9.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-simple-templates [i386] (eoan-proposed/universe) [0.9.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-simple-templates [armhf] (eoan-proposed/universe) [0.9.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-simple-templates [arm64] (eoan-proposed/universe) [0.9.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-simple-templates [ppc64el] (eoan-proposed/universe) [0.9.0.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected update-notifier [source] (trusty-proposed) [0.154.1ubuntu7]
-queuebot:#ubuntu-release- Unapproved: update-notifier (trusty-proposed/main) [0.154.1ubuntu6 => 0.154.1ubuntu7] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: haskell-simple-templates [s390x] (eoan-proposed/universe) [0.9.0.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (trusty-proposed) [0.154.1ubuntu7]
-queuebot:#ubuntu-release- New source: nvidia-graphics-drivers-435 (eoan-proposed/primary) [435.21-0ubuntu1]
<tseliot> sil2100: hey, any chance you can reject nvidia-settings (435.21-0ubuntu1) in eoan?
-queuebot:#ubuntu-release- New: rejected nvidia-graphics-drivers-435 [source] (eoan-proposed) [435.21-0ubuntu1]
<apw> tseliot, ^
-queuebot:#ubuntu-release- New: accepted haskell-simple-templates [amd64] (eoan-proposed) [0.9.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-simple-templates [armhf] (eoan-proposed) [0.9.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-simple-templates [ppc64el] (eoan-proposed) [0.9.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-simple-templates [arm64] (eoan-proposed) [0.9.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-simple-templates [s390x] (eoan-proposed) [0.9.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-simple-templates [i386] (eoan-proposed) [0.9.0.0-1]
<tseliot> apw: err... why did that happen?
<tseliot> I only wanted nvidia-settings rejected, the driver was fine
<apw> tseliot, ahh ok i missed sorry
<apw> tseliot, shove it back in
<tseliot> I can re-upload
<apw> my fault
<apw> tseliot, odly the other is not there so that is confusing
<tseliot> apw: no problem. Apparently, nvidia-settings was accepted. Nothing major, but I messed up the changelog (too many git branches), so two releases were dropped from the changelog
<tseliot> apw: I fixed it on my end, thanks
-queuebot:#ubuntu-release- New source: nvidia-graphics-drivers-435 (eoan-proposed/primary) [435.21-0ubuntu1]
<doko> Trying easy from autohinter: apitrace/7.1+git20170623.d38a69d6+repack-3build5 bro/2.5.5-1build2 dante/1.4.2+dfsg-6build2 gcc-7/7.4.0-12ubuntu1 gcc-9/9.2.1-6ubuntu3 gcc-snapshot/1:20190903-0ubuntu1 glibc/2.30-0ubuntu1 isc-dhcp/4.4.1-2ubuntu5 libnss-db/2.2.3pre1-6build5 nvidia-cuda-toolkit/10.1.168-1build1 unscd/0.53-1build3
<doko>     * amd64: hidrd, indicator-sound-gtk2, libhidrd0, libhidrd0-dbg, libhidrd0-dev, libido-0.1-0, libido-0.1-dev, libkqoauth-dbg, libkqoauth-dev, libkqoauth0
<doko> ^^^ all these have removal bugs pending
<ginggs> vorlon: thanks. i think mkl-dnn needs moar rams for a couple of the new tests.
-queuebot:#ubuntu-release- New sync: sagemath (eoan-proposed/primary) [8.8-1]
-queuebot:#ubuntu-release- New sync: pplpy (eoan-proposed/primary) [0.8.4-2]
<LocutusOfBorg> please accept it ^^ it should fix sagemath sadness
<LocutusOfBorg> we kicked it out because of "transitions" :)
<tarzeau> ah was looking for sagemath today on eoan, thanks for re-adding it
<LocutusOfBorg> please accept also haskell-http-link-header
<tseliot> apw: hey, can you approve nvidia-graphics-drivers-435 in eoan, please?
<apw> tseliot, what is the official previous version
<tseliot> apw: the driver doesn't replace any other series. It's a short lived branch
<tseliot> and it's the first release in the archive
<apw> tseliot, right i want someething to compare it to; and they all have random numbers making them hard to guess
<tseliot> apw: oh, well, you can compare the packaging to the one of nvidia-graphics-drivers-430, also in eoan
<apw> great
<tseliot> apw: it's based off the same git branch. Actually, if you want, I can give you the links to both branches, so that you can see the changes
<apw> tseliot, sure send me those in PM as well
<tseliot> all right
<doko> apw: could you override the linux autopkg tests based on sforshee's comment?
-queuebot:#ubuntu-release- New: accepted pplpy [sync] (eoan-proposed) [0.8.4-2]
-queuebot:#ubuntu-release- New: accepted sagemath [sync] (eoan-proposed) [8.8-1]
-queuebot:#ubuntu-release- New binary: pplpy [amd64] (eoan-proposed/none) [0.8.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pplpy [s390x] (eoan-proposed/none) [0.8.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pplpy [ppc64el] (eoan-proposed/none) [0.8.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pplpy [i386] (eoan-proposed/none) [0.8.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pplpy [arm64] (eoan-proposed/universe) [0.8.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pplpy [armhf] (eoan-proposed/universe) [0.8.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-simple [i386] (eoan-proposed/universe) [0.11.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-simple [amd64] (eoan-proposed/universe) [0.11.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-simple [s390x] (eoan-proposed/universe) [0.11.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-simple [ppc64el] (eoan-proposed/universe) [0.11.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-http-link-header [amd64] (eoan-proposed) [1.0.3.1-2build1]
-queuebot:#ubuntu-release- New: accepted haskell-http-link-header [armhf] (eoan-proposed) [1.0.3.1-2build1]
-queuebot:#ubuntu-release- New: accepted haskell-http-link-header [ppc64el] (eoan-proposed) [1.0.3.1-2build1]
-queuebot:#ubuntu-release- New binary: haskell-simple [arm64] (eoan-proposed/universe) [0.11.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-http-link-header [arm64] (eoan-proposed) [1.0.3.1-2build1]
-queuebot:#ubuntu-release- New: accepted haskell-http-link-header [s390x] (eoan-proposed) [1.0.3.1-2build1]
-queuebot:#ubuntu-release- New: accepted haskell-http-link-header [i386] (eoan-proposed) [1.0.3.1-2build1]
-queuebot:#ubuntu-release- New binary: haskell-simple [armhf] (eoan-proposed/universe) [0.11.3-1] (no packageset)
<LocutusOfBorg> vorlon, ccls has been removed on armhf and i386 in Debian... can we do the same? https://launchpad.net/ubuntu/+source/ccls/0.20190823-3ubuntu3
<vorlon> LocutusOfBorg: ack
<LocutusOfBorg> fixing 32 bits for me is a waste of time :)
<LocutusOfBorg> thanks I tried to fix them btw, but I can't understand the error, and two days of attempts are way too much for a leaf package
<LocutusOfBorg> btw haskell is getting near an end
<vorlon> LocutusOfBorg: done
<LocutusOfBorg> lovely thanks
<Laney> you know leaf packages are the ones people actually use
<Laney> not passing judgement on this case, but 'leaf package â waste of time' is probably not a criterion you should be applying in general
<LocutusOfBorg> Laney, fixing 32 bits in Ubuntu when Debian stopped caring is a waste of time...
<LocutusOfBorg> I never give up on leaf packages unless I can't figure them out
<Laney> fine, but I'm responding to 'two days of attempts are way too much for a leaf package'
<vorlon> for me the straightforward rationale is that we should not be blocking migration of a package because of a build failure on an architecture for which Debian has already removed the binaries
<Laney> which is maybe more general than you mean
<LocutusOfBorg> sure, and in general you are right!
<LocutusOfBorg> I hoped to fix 32 bit and forward the patch to Debian...
<vorlon> Description: C/C++/ObjC language server
<vorlon> language... server
<LocutusOfBorg> and I'll probably try again while waiting for haskell
<LocutusOfBorg> also please accept haskell-simple
-queuebot:#ubuntu-release- New: accepted haskell-simple [amd64] (eoan-proposed) [0.11.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-simple [armhf] (eoan-proposed) [0.11.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-simple [ppc64el] (eoan-proposed) [0.11.3-1]
-queuebot:#ubuntu-release- New: accepted pplpy [amd64] (eoan-proposed) [0.8.4-2]
-queuebot:#ubuntu-release- New: accepted pplpy [armhf] (eoan-proposed) [0.8.4-2]
-queuebot:#ubuntu-release- New: accepted pplpy [ppc64el] (eoan-proposed) [0.8.4-2]
-queuebot:#ubuntu-release- New: accepted haskell-simple [arm64] (eoan-proposed) [0.11.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-simple [s390x] (eoan-proposed) [0.11.3-1]
-queuebot:#ubuntu-release- New: accepted pplpy [i386] (eoan-proposed) [0.8.4-2]
-queuebot:#ubuntu-release- New: accepted haskell-simple [i386] (eoan-proposed) [0.11.3-1]
-queuebot:#ubuntu-release- New: accepted pplpy [s390x] (eoan-proposed) [0.8.4-2]
-queuebot:#ubuntu-release- New: accepted pplpy [arm64] (eoan-proposed) [0.8.4-2]
-queuebot:#ubuntu-release- New: accepted httpdirfs-fuse [amd64] (eoan-proposed) [1.0.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted httpdirfs-fuse [armhf] (eoan-proposed) [1.0.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted httpdirfs-fuse [ppc64el] (eoan-proposed) [1.0.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted httpdirfs-fuse [arm64] (eoan-proposed) [1.0.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted httpdirfs-fuse [s390x] (eoan-proposed) [1.0.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted httpdirfs-fuse [i386] (eoan-proposed) [1.0.1-1ubuntu1]
<LocutusOfBorg> I syncd bladerf, I hope to see gnuradio going to an end...
<LocutusOfBorg> something needs a kick out from release, I'll have a deeper look once things settle down, and open RC bugs in Debian too
<vorlon> RikMills[m]: you uploaded language-pack-kde-wa, it's in NEW and it was previously removed because it depends on language-pack-wa which doesn't exist
<vorlon> RikMills[m]: so this looks to me like it should be rejected
-queuebot:#ubuntu-release- New binary: bladerf [ppc64el] (eoan-proposed/universe) [0.2019.07-4] (no packageset)
-queuebot:#ubuntu-release- New binary: bladerf [s390x] (eoan-proposed/universe) [0.2019.07-4] (no packageset)
-queuebot:#ubuntu-release- New binary: bladerf [amd64] (eoan-proposed/universe) [0.2019.07-4] (no packageset)
-queuebot:#ubuntu-release- New binary: bladerf [i386] (eoan-proposed/universe) [0.2019.07-4] (no packageset)
-queuebot:#ubuntu-release- New binary: bladerf [arm64] (eoan-proposed/universe) [0.2019.07-4] (no packageset)
<doko> vorlon: please could you process the multiarch-support related removal bugs?
<doko>  hidrd, indicator-sound-gtk2, libhidrd0, libhidrd0-dbg, libhidrd0-dev, libido-0.1-0, libido-0.1-dev, libkqoauth-dbg, libkqoauth-dev, libkqoauth0
<vorlon> doko: why does reverse-depends not show me that any removals are needed?
<doko> I don't undestand the question ...
<vorlon> doko: 'reverse-depends multiarch-support' -> no output
-queuebot:#ubuntu-release- New: accepted bladerf [amd64] (eoan-proposed) [0.2019.07-4]
-queuebot:#ubuntu-release- New: accepted bladerf [i386] (eoan-proposed) [0.2019.07-4]
-queuebot:#ubuntu-release- New: accepted bladerf [s390x] (eoan-proposed) [0.2019.07-4]
-queuebot:#ubuntu-release- New: accepted bladerf [arm64] (eoan-proposed) [0.2019.07-4]
-queuebot:#ubuntu-release- New: accepted bladerf [ppc64el] (eoan-proposed) [0.2019.07-4]
<doko> $ apt-cache rdepends multiarch-support
<doko> multiarch-support
<doko> Reverse Depends:
<doko>   libhidrd0
<doko>   libkqoauth0
<doko>   libido-0.1-0
<vorlon> doko: ah, the answer is that it's pre-depends and the reverse-depends command doesn't look at those
<xnox> vorlon:  because it's Pre-Depends?
<xnox> and my irc is stuck in bad scroll mode
<LocutusOfBorg> vorlon, btw, also sigil has been removed on ppc64el and s390x in Debian, because of missing qtwebengine support...
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/sigil/+bug/1839607
<ubot5> Launchpad bug 1839607 in sigil (Ubuntu) "rm sigil where libqtwebengine5-dev is not built" [Undecided,New]
<vorlon> LocutusOfBorg: done
<LocutusOfBorg> lovely!
<vorlon> doko: I'm going through all the ubuntu-archive bugs right now and I see LP: #1835803.  Does this also need blacklisted?
<ubot5> Launchpad bug 1835803 in openjdk-12 (Ubuntu) "remove openjdk-12 in eoan" [Undecided,New] https://launchpad.net/bugs/1835803
<vorlon> n/m I'm sure the answer is yes
<doko> I'm not uploading -12 again to debian, so it doesn't matter
<vorlon> but haven't asked for its removal from unstable?
<doko> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/c/cross-toolchain-base-mipsen/20190904_151459_18be5@/log.gz
<doko> can we run this on a big instance?
<doko> tracker is down, can't check
<ahasenack> doko: Reason: Cannot perform Post-Handshake Authentication.<-- that?
<ahasenack> funny, I have a bug open against the browsers for that
<ahasenack> saw it while testing some apache regressions due to openssl 1.1.1 in bionic
<doko> yes
<ahasenack> https://bugs.launchpad.net/bugs/1834671
<ubot5> Launchpad bug 1834671 in firefox (Ubuntu Eoan) "TLSv1.3 client certificate authentication with renegotiation unsupported in browsers" [Undecided,New]
<xnox> sounds like tracker had upgraded openssl to 1.1.1 and has a broken older apache still.
<ahasenack> cert auth is one way to trigger it
<doko> ahasenack: but I see that in bionic
<ahasenack> doko: if the negotiation settles on tls v1.3, and a post-handshake authentication is needed ("pha"), then most browsers don't have support for that, and the server will complain like that error page we see
<xnox> doko:  yeh... and? as a client you are providing authentication cert, and that bombs out on tracker end.
<ahasenack> "The connection to this site is encrypted and authenticated using TLS 1.3, X25519, and AES_256_GCM."
<ahasenack> it used tls3.1, as expected
<ahasenack> er, 1.3
<xnox> but we have had client tls 1.3 for a long time now; so it must be that tracker.d.o that was recently upgraded and shows miscompat.
<xnox> i guess they upgraded it to the new debian stable
<ahasenack> I don't think this is triggered by client cert
<ahasenack> it's triggered by a different set of ssl config options inside a <directory> or similar block
<ahasenack> so ssl to the vhost was established, and then a directory access triggers the renegotiation because of the changed ssl settings inside it
<ahasenack> doko: I see you added apache2 back to that bug, why? Is it not a client issue, as shown by the bug links I added to the description?
<ahasenack> unless you are thinking we should disable tls 1.3 in apache until all browsers have support for tls 1.3 PHA?
<ahasenack> this is the firefox commit, for example: https://hg.mozilla.org/integration/autoland/rev/1bb8ad865648
<doko> ahasenack: no, I just added a bionic task
<ahasenack> doko: ah, I see, the bionic line was added to all pckages
<ahasenack> I fixed the apache bit
<ahasenack> doko: if you use firefox, you can enable it. I just saw it's disabled by default
<ahasenack> doko: about:config, search for security.tls.enable_post_handshake_auth
<ahasenack> I just tried, and can open tracker.debian.org again
<doko> ta
<ahasenack> I'm also on bionic
<ahasenack> xnox: ^
<ahasenack> i added this to the bug
<doko> vorlon: there is https://bugs.debian.org/915650 for openjdk-12. will file the removal issue once the next security update is out (but not updated for 12)
<ubot5> Debian bug 915650 in src:openjdk-12 "openjdk-12 should not release with bullseye" [Important,Open]
<vorlon> xnox: I don't see mingw-ocaml being made uninstallable at a glance at https://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt; why did this come to your attention?
<vorlon> LocutusOfBorg: sagemath is dep-wait.
<vorlon> on a removed python2 package
<vorlon> removing sagemath again
<vorlon> why does a package named 'boxer-data' need autopkgtests, and how do its autopkgtests manage to regress with a new version of 'boxer'
<LocutusOfBorg> vorlon, I already opened a new RC in Debian about sagemath
<LocutusOfBorg> vorlon, hinting autopkgtest for ddcci-driver-linux/*/s390x will make me really happy
<LocutusOfBorg> it can't work there, the kernel doesn't support the driver on s390x
<LocutusOfBorg> (theoretically dkms should just return true in that case, but the code doesn't work on autopkgtests)
<LocutusOfBorg> http://launchpadlibrarian.net/434046705/dkms_2.7.1-1ubuntu1_2.7.1-1ubuntu2.diff.gz
<vorlon> LocutusOfBorg: why was the autopkgtest passing before?
<LocutusOfBorg> probably because it is apt erroring out
<LocutusOfBorg> vorlon, previous kernel had that module built
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1837073
<ubot5> Launchpad bug 1837073 in linux (Ubuntu) "linux 5.2.0-8.9 disabled backlight on s390x." [High,Confirmed]
<LocutusOfBorg> you can link that bug ^^
<vorlon> ok
<vorlon> because I remember that having been a problematic autopkgtest on s390x before and then it started passing
<LocutusOfBorg> actually the driver was building ok (so testsuite was green), but the resulting kernel driver was totally broken because backlight never worked correctly on s390x
<LocutusOfBorg> so kernel folks decided to stop shipping a broken support
<vorlon> ack; hinted
 * LocutusOfBorg tries to debug why that test still fails, hopefully he will find a solution
<LocutusOfBorg> thanks for the hint
<mwhudson> https://code.launchpad.net/~mwhudson/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/372302 <- thoughts
<vorlon> mwhudson: is basically what doko asked for above, so sure
<vorlon> mwhudson: is it only needed for amd64?
<mwhudson> vorlon: i386 too
<mwhudson> vorlon: but yeah probably best to not have it unnecessarily in big_packages on other arches
<mwhudson> (where the test basically does nothing)
<mwhudson> vorlon: which config file is for amd64? worker-bos01.conf? is that i386 too?
<vorlon> mwhudson: the one with no suffix is amd64+i386
<mwhudson> oh ok so the one i edited?
<mwhudson> neat
<mwhudson> vorlon: so my branch is ok? i can't merge it
<vorlon> mwhudson: y, merged && pushed && working on deployment
<vorlon> mwhudson: was delayed somewhat by the curiosity that git+ssh://git.launchpad.net/~mwhudson/autopkgtest-cloud did not work as a remote for your repo unlike all the others
<vorlon> mwhudson: pkill -HUPed and the x86 queue is empty according to http://autopkgtest.ubuntu.com/running so you should be able to retry the test now and get it on the right VMs
<vorlon> package naming schema consistency is so disappointing, haskell-esqueleto really could've been named has-queleto
<mwhudson> vorlon: thx
<mwhudson> vorlon: wow http://autopkgtest.ubuntu.com/packages/l/linux/eoan/amd64 looks great
<mwhudson> jvmti/jvmti_agent.c:48:21: error: static declaration of âgettidâ follows non-static declaration
<mwhudson> ok so that is caused by glibc 2.30 yay
<vorlon> fsvo "great"?
<mwhudson> vorlon: do you know if the kernel team has been poked about this already?
<vorlon> mwhudson: I do not know
<mwhudson> i think we want upstream commit 4541a8bb13a86e504416a13360c8dc64d2fd612a
<mwhudson> ah it's in ubuntu-eoan/master-next
-queuebot:#ubuntu-release- Unapproved: sosreport (xenial-proposed/main) [3.6-1ubuntu0.16.04.2 => 3.6-1ubuntu0.16.04.3] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: sosreport (bionic-proposed/main) [3.6-1ubuntu0.18.04.2 => 3.6-1ubuntu0.18.04.3] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: sosreport (disco-proposed/main) [3.6-1ubuntu2 => 3.6-1ubuntu2.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New sync: fwupdate (eoan-proposed/primary) [12-6]
#ubuntu-release 2019-09-05
<doko> mwhudson, vorlon: yes, already poked
<doko> <sforshee> doko, apw: this is perf failing to build because it implemented its own gettid call, and in glibc 2.30 unistd.h also has a gettid declaration
<doko> <sforshee> apw: so it's not a toolchain issue, you can hint that and we'll need to apply a fix to the kernel
<doko> but no action yet ...
<doko> zodb removal bugs: https://bugs.launchpad.net/ubuntu/+source/zope.error/+bug/1842807
<ubot5> Launchpad bug 1842807 in zope.session (Ubuntu) "RM: zodb and rdeps" [Undecided,New]
<doko> so the only one to investigate is the wcc autopkg test failure
<vorlon> rbalint: marking unattended-upgrades/amd64 badtest, it's running a test dependent on snapshot.debian.org and getting 503s
<LocutusOfBorg> vorlon, easy one please? https://bugs.launchpad.net/ubuntu/+source/qtwebkit-source/+bug/1840190
<ubot5> Launchpad bug 1840190 in qtwebkit-source (Ubuntu) "Remove from eoan archive" [Undecided,New]
<LocutusOfBorg> also, https://bugs.launchpad.net/ubuntu/+source/newsbeuter/+bug/1839465
<ubot5> Launchpad bug 1839465 in newsbeuter (Ubuntu) "newsbeutrer: remove from eoan (removed from unstable)" [Undecided,New]
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/nlohmann-json/+bug/1838701
<ubot5> Launchpad bug 1838701 in nlohmann-json (Ubuntu) "nlohmann-json: remove from eoan" [Undecided,New]
<LocutusOfBorg> actually only the first one is needed
<LocutusOfBorg> qtwebkit-source is now a source-only package FWICS...
<LocutusOfBorg> also this one, is it possible? https://bugs.launchpad.net/ubuntu/+source/mopidy-scrobbler/+bug/1838275
<ubot5> Launchpad bug 1838275 in mopidy-scrobbler (Ubuntu) "mopidy-scrobbler: kick out from release" [Undecided,New]
<LocutusOfBorg> so, just qtwebkit-source and mopidy-scrobbler seems still needed
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-435 [source] (eoan-proposed) [435.21-0ubuntu1]
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-435 [i386] (eoan-proposed/none) [435.21-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-435 [amd64] (eoan-proposed/none) [435.21-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1052.61] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1052.61]
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-435 [amd64] (eoan-proposed) [435.21-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-435 [i386] (eoan-proposed) [435.21-0ubuntu1]
<doko> sforshee, apw: ping again on the linux autopkg tests
<apw> doko, i already hinted gcc-7
<apw> doko, nothing else was only waiting on linux
<doko> apw: glibc and gcc-9, and why should linux be the only blocker?
<apw> doko, because i am not hinting our testing bad, i am hinting the testing to be ignored
<doko> well, then please hint glibc
<apw> it has another failure; which is not the kernle
<doko> with this attitude you are delaying migration once anthing else is fixed
<apw> doko, if i hinted my kernel package good it would not migrate
<doko> and no, for gcc-9 linux was the only thing
<doko> but anyway, now re-uploaded
<apw> autopkgtest for wcc/0.0.2+dfsg-3ubuntu1: amd64: Regression â»
<apw> autopkgtest for zodb/1:3.10.7-1build1: amd64: Ignored failure, arm64: Regression â» , armhf: Regression â» , i386: Ignored failure, ppc64el: Ignored failure, s390x: Ignored failure
<apw> both of those also are holding glibc, so hinting over those is not appropriate
<doko> this is glibc, not gcc-9
<apw> i think you had uploaded gcc-9 before i checked as i searched for all linux failures holding packages
<apw> and for packages which had no other failurs i hinted them out, gcc-7 was hte only one
<doko> not according to https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html
<apw> that page indeed says the kernel is blocking glibc
<apw> but i cannot hint all kernle testing as to be ignore in this context; that is too risky
<doko> I only uploaded 9.2.1-7ubuntu1 this morning, so your comment seems to be wrong
<apw> gcc is blocked by three thing
<apw> i only checked this morning and hinted the ones which can go; so it is not wrong
<apw> anyhow, glibc; i am happy to hint over the kenrel fialures; once the others are either good or hinted
<apw> but as there are three i think it was other failures, it is not appropraite to hint glibc out (for me)
<doko> well, then fix the linux package to pass the test instead
<apw> my attitude it to not hint out a glibc with known issues as it is ever so slightly critical
<tseliot> apw: hi, can you move nvidia-graphics-drivers-435 to restricted, please?
<xnox> doko:  we do not have ability to have a hint for "ignore linux when triggered by glibc"
<apw> and that will NOT make that package release
<xnox> doko:  we only have "ignore linux everywhere" or "skip all testing triggered by glibc"
<doko> apw: then FIX linux
<apw> and it wont help, seth is fixing the kernel; it takes a day to build etc etc
<apw> we have a lever, which is poor which i used on gcc-7
<apw> because it WAS appropriate
<apw> it is NOT appropriate to use that lever on glibc; it has _OTHER_ fialures that need fixing
<apw> gcc-9 was missed and that is on me, but it was gone by the time i got to it; you can slam on me for the delay leading to that
<apw> all you like
<xnox> doko:  tracker & bugs look operational to me now, so i think the tls stuff is now fixed. Does it work for you now?
<doko> yes
-queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu10.28 => 237-3ubuntu10.29] (core)
<rbalint> sil2100, could you please release  LP: #1840909 today, one day early?
<ubot5> Launchpad bug 1840909 in ec2-hibinit-agent (Ubuntu Disco) "ec2-hibinit-agent-ignore-powerkey.conf prevents EC2 Nitro instances from stopping normally" [Undecided,Fix committed] https://launchpad.net/bugs/1840909
<sil2100> rbalint: looking
<sil2100> rbalint: done o/
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (bionic-proposed) [1.6.12]
-queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (disco-proposed) [13.2.6-0ubuntu0.19.04.4]
-queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (bionic-proposed) [12.2.12-0ubuntu0.18.04.3]
<rbalint> sil2100, thanks!
<doko> apw: please override the linux autopkg test failure triggered by binutils (after verifying that it's unrelated to binutils)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-62.69] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-62.69] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-62.69]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-62.69]
<RikMills> vorlon: after all this time I am still unsure. can I sync a new source package (elisa music player) that has just been accepted by debian ftp masters without a FFE?
-queuebot:#ubuntu-release- New binary: haskell-github [amd64] (eoan-proposed/universe) [0.20-1build2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-github [i386] (eoan-proposed/universe) [0.20-1build2] (no packageset)
<vorlon> RikMills: you can but you need to convince an AA to process it
<RikMills> vorlon: ok. thanks. I think it is worth trying
<RikMills> I don't intend to seed it for this release
<ginggs> vorlon: I created a MR adding mkl-dnn to big_packages; tests pass for me locally
-queuebot:#ubuntu-release- New binary: haskell-github [ppc64el] (eoan-proposed/universe) [0.20-1build2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-github [s390x] (eoan-proposed/universe) [0.20-1build2] (no packageset)
<doko> sforshee, apw: is there a ppa with linux 5.3 which I could use for the test rebuild? really only interested in linux-libc-dev
<doko> vorlon: it looks like there is one link-grammar override missing, triggered by python3.7
<vorlon> apw: I have badtest'ed linux/5.2.0-15.16; if we have agreed that it's acceptable for the autopkgtest for this version of the package to be allowed to regress in the release pocket due to glibc header changes, then other packages should not be caught in the crossfire when they also trigger the test and it fails
<vorlon> doko: I had only overridden armhf and i386, those were where I saw it failing before.  have you confirmed that it now fails on all archs in release pocket?
<vorlon> doko: it actually looks like a retry of those tests should pass with link-grammar 5.6.2-1ubuntu1 now in release pocket, or else there is a separate regression that needs analyzed
<vorlon> ginggs: link to MR, please?
-queuebot:#ubuntu-release- New binary: haskell-github [arm64] (eoan-proposed/universe) [0.20-1build2] (no packageset)
<ginggs> vorlon: https://code.launchpad.net/~ginggs/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/372338
<doko> vorlon: gave back link-grammar tests
<vorlon> doko: so did I; but there's also a queue right now :/
-queuebot:#ubuntu-release- New binary: haskell-github [armhf] (eoan-proposed/universe) [0.20-1build2] (no packageset)
<doko> vorlon: can you skip the autopkg tests triggered by gcc-9, or do you want to wait?
<vorlon> I don't understand how all the packages triggering autopkgtests have all been uploaded just today when the queue was empty all week until now
<vorlon> doko: I'd like at least some test results in order to smoke test the gcc-9 upload
<doko> ok
<sforshee> doko: canonical-kernel-team/bootstrap has a 5.3 build
<doko> vorlon, Laney: which ben version are we running for the transition tracker?
<doko> sforshee: ta
<vorlon> doko: ENOCLUE
<infinity> doko: Looks like it's still the trusty version.
<infinity> There was work done to move to bionic, but seems it quit halfway.
<ginggs> i think our ben is at least older than 0.8.1, because it misses the fix for debian #900627
<ubot5> Debian bug 900627 in src:ben "ben: please show [build logs] link for arch:all packages as well" [Wishlist,Fixed] http://bugs.debian.org/900627
<infinity> ginggs: It's a lot older.  See above.
<doko> infinity: would be nice if we could priotize that
<ginggs> infinity: thanks
<infinity> We should probably run it from a VCS checkout instead of a package, if the tool is actively being worked on.
<infinity> (And if that work matters to us)
<doko> yes, it does, because the version we are using, doesn't match against Build-depends-indep
<infinity> Or if it's regularly updated in sid, we could pin the sid version, since it doesn't have any compiled code, IIRC.
<infinity> doko: Fair enough.  I'll see if Laney has anything to add to this, since it's been mostly his domain, and we'll figure out how to get something newer.
<doko> it's not urgent, but I see deficiencies with the py2-removal tracker.
<doko> we can discuss this at the sprint
<vorlon> infinity: "from a vcs checkout" means getting to build ocaml binaries from source, I think?
<vorlon> well, you say no compiled code; I didn't think that was true
<coreycb> vorlon: I'd like to see if we can remove python-django 2:2.2.4-1 from eoan-proposed. I just took a scan through the openstack horizon patches for 2.2.4 support and they look to be backward compatible. I don't think they're going to merge this cycle anyway but I checked in case they do.
<vorlon> infinity, cjwatson: I'm struggling to figure out why archive-reports is not regenerating the component-mismatches reports; could we revisit the fact that the script more or less suppresses all output, making it impossible to figure out what wrong in previous runs?
<vorlon> coreycb: and you've determined that's necessary, rather than just disabling build-time tests that require django?
<coreycb> vorlon: that's right we discussed that..  if we went that route would there be a chance of a horizon that doesn't support 2.2.4 + django 2.2.4 both landing in eoan-release?
<vorlon> coreycb: you should not disable testing of django in the autopkgtests; those will gate python-django 2.2.4 as long as they fail
<vorlon> coreycb: but also the python-django revdeps are a mess right now wrt compatibility, see https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#python-django
<vorlon> oh actually
<vorlon> the horizon autopkgtests *pass* with the new django
<vorlon> so that doesn't help you ;P
<vorlon> but I'm pretty confident in saying that's not landing for 19.10
<vorlon> we could add a block-proposed bug to be sure
<coreycb> vorlon: ok, that may be the way to go then. disable any tests that fail for 2.2.4 and open a block-proposed bug.
<vorlon> coreycb: LP: #1842969
<ubot5> Launchpad bug 1842969 in python-django (Ubuntu) "python-django 2.2.4 not for eoan" [Undecided,New] https://launchpad.net/bugs/1842969
<coreycb> vorlon: ah, thanks for opening that
-queuebot:#ubuntu-release- Unapproved: nplan (xenial-proposed/universe) [0.32~16.04.6 => 0.32~16.04.7] (no packageset)
<cjwatson> vorlon: I have no opinion on that
<infinity> The number one reason reports don't run is because the archive didn't actually change.  I've changed both release and proposed, let's see if it magically runs. :P
<cjwatson> vorlon: I thought it went to stderr and hence to snakefruit:/var/mail/ubuntu-archive though
<infinity> But we could certainly have some logging (other than stderr to cron to mailbox) to checkpoint some of the report actions, etc.
<cjwatson> There was some problem with ben in bionic.  I think I described it on IRC maybe?
<vorlon> infinity: the archive absolutely did change, per the synced germinate.output timestamp that's being checked
<infinity> Kay.
<cjwatson> https://irclogs.ubuntu.com/2019/02/20/%23ubuntu-release.html and https://irclogs.ubuntu.com/2019/02/21/%23ubuntu-release.html#t11:19
<cjwatson> AFAIK nobody ever followed up on that
<cjwatson> I suggest following up on that if you want it fixed
<infinity> cjwatson: Ah-ha.
<cjwatson> doko: ^-
<cjwatson> If whatever the problem is is fixed in sid, then we should identify the fix and SRU it into bionic
<cjwatson> It would be a lot less annoying than having to build the thing from source in a chroot on snakefruit
<LocutusOfBorg> anybody please accept haskell-github thanks
<infinity> I don't see any interesting output in the mail from component-mismatches, so if it's entirely silent, that's on that script.
<infinity> Assuming it's being run at all.
<vorlon> doko: binutils failing its autopkgtests against gcc-9
<vorlon> doko: I am not keen to ignore these failures
-queuebot:#ubuntu-release- New binary: linux-signed-gke-4.15 [amd64] (bionic-proposed/main) [4.15.0-1042.44] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1042.44] (kernel)
#ubuntu-release 2019-09-06
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1057.62] (kernel)
<vorlon> doko, infinity: well so I sorted out what was broken with archive-reports, somehow the 'run-britney' subprocess had a stale lockfile from /July/ that I had to remove in order to get everything to run to completion.  But I don't understand how that could've been the case given that reports have run successfully since then.
<vorlon> (the file in question was testing/.run-britney.lock)
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-4.15 [amd64] (bionic-proposed) [4.15.0-1042.44]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1057.62]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1042.44]
<apw> vorlon, could the runs since have been manual trying to debug it and finding it worked fine stylee
<vorlon> apw: I don't think so, c-m reports have updated far too consistently
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (xenial-proposed/main) [4.15.0-1023.26~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (bionic-proposed/main) [4.15.0-1023.26] (kernel)
-queuebot:#ubuntu-release- Unapproved: systemd (disco-proposed/main) [240-6ubuntu5.6 => 240-6ubuntu5.7] (core)
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1023.26]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (xenial-proposed) [4.15.0-1023.26~16.04.1]
<doko> vorlon: please ignore, not reproducible. http://autopkgtest.ubuntu.com/running#pkg-binutils amd64 and armhf are past the initial configure step, arm64 and s390x are waiting ... and https://launchpad.net/~doko/+archive/ubuntu/toolchain/+sourcepub/10464018/+listing-archive-extra looks good as well on amd64
<vorlon> doko: done
-queuebot:#ubuntu-release- New binary: haskell-github [amd64] (eoan-proposed/universe) [0.20-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-github [i386] (eoan-proposed/universe) [0.20-2] (no packageset)
<vorlon> Laney, juliank: s390x autopkgtests seem to be at half capacity, with only 1 worker in bos01 instead of 16; do you know why?
<ginggs> vorlon: thanks for the autopkgtest-cloud merge, do you know when changes will take effect?  i retried mkl-dnn now, but it seems to have still run on a small instance
-queuebot:#ubuntu-release- New sync: elisa-player (eoan-proposed/primary) [1.1+really0.4.0-1]
<vorlon> ginggs: ah, let me deploy that
-queuebot:#ubuntu-release- New binary: haskell-github [ppc64el] (eoan-proposed/universe) [0.20-2] (no packageset)
<vorlon> ginggs: ginggs: deployed, takes effect immediately
<ginggs> vorlon: ta!
-queuebot:#ubuntu-release- New binary: pywps [amd64] (eoan-proposed/universe) [4.2.1-1ubuntu1] (no packageset)
<marcustomlinson> vorlon: hey, could I ask you to sponsor another libreoffice upload for me? Had some component mismatches
<marcustomlinson> some _more_ component mismatches (facepalm)
<juliank> vorlon: that's not optimal. Haven't seen anything weird in email though, so a bit surprised
<marcustomlinson> hey doko could you sponsor my libreoffice upload to fix those component mismatches?
<doko> marcustomlinson: sure, where can I find it?
<marcustomlinson> doko: https://drive.google.com/drive/folders/1RujzWuAdacd9bdpTVGyk3-AJXKpCVgTq?usp=sharing
<doko> glibc migrated \o/
<marcustomlinson> vorlon: ignore me, timezone fail :)
<LocutusOfBorg> +    rm /dev/random
<LocutusOfBorg> +    ln -s /dev/urandom /dev/random
<LocutusOfBorg> why should anybody sane do this in a debian/test script?
-queuebot:#ubuntu-release- New binary: haskell-github [s390x] (eoan-proposed/universe) [0.20-2] (no packageset)
<LocutusOfBorg> shouldn't a test that does rm and ln -s of /dev devices declare "breaks testbed"?
<Laney> vorlon: nope, did you figure it out in the meantime?
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (disco-proposed/main) [5.0.0-28.30] (core, kernel)
<Laney> infinity: I think Colin did some work on moving to a more recent version but it didn't work and one of us needs to pick that back up
<Laney> vorlon: the units are disabled - why is that?
 * Laney is going to put them back up
<Laney> done
-queuebot:#ubuntu-release- New binary: haskell-github [armhf] (eoan-proposed/universe) [0.20-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-github [amd64] (eoan-proposed) [0.20-2]
-queuebot:#ubuntu-release- New: accepted haskell-github [i386] (eoan-proposed) [0.20-2]
-queuebot:#ubuntu-release- New: accepted haskell-github [s390x] (eoan-proposed) [0.20-2]
-queuebot:#ubuntu-release- New: accepted haskell-github [armhf] (eoan-proposed) [0.20-2]
-queuebot:#ubuntu-release- New: accepted haskell-github [ppc64el] (eoan-proposed) [0.20-2]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (disco-proposed/main) [5.0.0-28.30] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (disco-proposed/main) [5.0.0-28.30] (core, kernel)
<RikMills> apw or another AA, any chance you could look at the elisa-player sync in New? steve said no ffe required, and just need to persuade an AA to process it. ;)
<doko> LocutusOfBorg: any idea about the lintian autopkg test failure on armhf?
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (disco-proposed) [5.0.0-28.30]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (disco-proposed) [5.0.0-28.30]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (disco-proposed) [5.0.0-28.30]
<LocutusOfBorg> doko, I syncd 2.20 hoping to fix it :)
<LocutusOfBorg> I'll have a look
<ginggs> +binaries-general (binary): spelling-error-in-binary usr/bin/static iIF if
<ginggs> new binutils introduces a spelling error
<doko> really?
<ginggs> well, it looks like lintian think it is
<ginggs> I'm trying to skip that in my PPA...
-queuebot:#ubuntu-release- New binary: github-backup [amd64] (eoan-proposed/universe) [1.20170301-2build2] (no packageset)
-queuebot:#ubuntu-release- New binary: github-backup [i386] (eoan-proposed/universe) [1.20170301-2build2] (no packageset)
<ginggs> lintian autopkgtest running now, will know in ~1hr
-queuebot:#ubuntu-release- New binary: github-backup [ppc64el] (eoan-proposed/universe) [1.20170301-2build2] (no packageset)
-queuebot:#ubuntu-release- New binary: github-backup [s390x] (eoan-proposed/universe) [1.20170301-2build2] (no packageset)
-queuebot:#ubuntu-release- New binary: github-backup [armhf] (eoan-proposed/universe) [1.20170301-2build2] (no packageset)
-queuebot:#ubuntu-release- New binary: github-backup [arm64] (eoan-proposed/universe) [1.20170301-2build2] (no packageset)
<RikMills> iso are now startiing to bloat quite a lot due to including nvidia driver in ship-live :/
<slashd> sil2100 or any SRU vanguard available, I found a regression in the most recent net-snmp upload, I want to let you guys know in case you want to revert the current package found in -updates until we figure out what is causing it original bug: https://bugs.launchpad.net/bugs/1835818 | regression-update bug: https://bugs.launchpad.net/ubuntu/+source/net-snmp/+bug/1843036
<ubot5> Launchpad bug 1835818 in net-snmp (Debian) "snmpd causes autofs mount points to be mounted on service start/restart" [Unknown,New]
<ubot5> Launchpad bug 1843036 in net-snmp (Ubuntu) "[regression] SNMP missing disks in hrStorageTable" [High,New]
<slashd> ddstreet, ^
<slashd> sil2100, SRU vanguard, I think I found a fix, I'll keep you posted, if this still need to be reverted or not
<slashd> ddstreet, ^
<LocutusOfBorg> hello, do you think it is possible to kick xmds2 out because of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=938925 ?
<ubot5> Debian bug 938925 in src:xmds2 "xmds2: fails mpi hdf5 tests" [Serious,Open]
<LocutusOfBorg> I uploaded a no-change rebuild just to have track of it
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/xmds2/3.0.0+dfsg-2build1/+build/17530065
<LocutusOfBorg> vorlon, ^^
<LocutusOfBorg> (I don't see any recent upstream activity that would explain a fix in that test)
<sil2100> slashd: ok, we'll need to revert it anyway
<sil2100> slashd: is it a regression on all series?
<sil2100> slashd: reverting
<slashd> sil2100, we notice on Bionic, but won't be suprise it's the same behaviour everywhere
<slashd> sil2100, current impact we can see is monitoring via snmp (e.g. nagios)
<slashd> for disk
<slashd> such as unable to monitor disk space
-queuebot:#ubuntu-release- Unapproved: cloud-utils (disco-proposed/main) [0.31-0ubuntu1.1 => 0.31-0ubuntu1.2] (core, edubuntu)
<slashd> thanks sil2100
-queuebot:#ubuntu-release- Unapproved: net-snmp (bionic-updates/main) [5.7.3+dfsg-1.8ubuntu3.2 => 5.7.3+dfsg-1.8ubuntu3.1] (desktop-core, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: net-snmp (xenial-updates/main) [5.7.3+dfsg-1ubuntu4.3 => 5.7.3+dfsg-1ubuntu4.2] (desktop-core, ubuntu-server) (sync)
<sil2100> cjwatson: hey! Sorry to bother you, a quick AA question: if I remove (revert) a package from -updates, I usually have to copy the previous version on it's place - but what in the case of when -updates only had the faulty version that I removed? Should I still copy the release binaries to -updates anyway?
<doko> ginggs: did you find out why this recently changed?
<cjwatson> sil2100: seems unnecessary
<sil2100> cjwatson: ok, thanks o/
<vorlon> Laney: yeah, no idea at all why they were disabled, I didn't do it that's why I was asking the both of you
<vorlon> anyway, thanks for re-enabling
-queuebot:#ubuntu-release- Unapproved: accepted net-snmp [sync] (bionic-updates) [5.7.3+dfsg-1.8ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: accepted net-snmp [sync] (xenial-updates) [5.7.3+dfsg-1ubuntu4.2]
<sil2100> No worries, those are reverts for the net-snmp -updates regression ^
<Laney> sil2100: don't you need to bump the version so that people who upgraded get the old version back?
-queuebot:#ubuntu-release- New: accepted github-backup [amd64] (eoan-proposed) [1.20170301-2build2]
-queuebot:#ubuntu-release- New: accepted github-backup [armhf] (eoan-proposed) [1.20170301-2build2]
-queuebot:#ubuntu-release- New: accepted github-backup [ppc64el] (eoan-proposed) [1.20170301-2build2]
-queuebot:#ubuntu-release- New: accepted haskell-github [amd64] (eoan-proposed) [0.20-1build2]
-queuebot:#ubuntu-release- New: accepted haskell-github [armhf] (eoan-proposed) [0.20-1build2]
-queuebot:#ubuntu-release- New: accepted haskell-github [ppc64el] (eoan-proposed) [0.20-1build2]
-queuebot:#ubuntu-release- New: accepted pywps [amd64] (eoan-proposed) [4.2.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted github-backup [arm64] (eoan-proposed) [1.20170301-2build2]
-queuebot:#ubuntu-release- New: accepted github-backup [s390x] (eoan-proposed) [1.20170301-2build2]
-queuebot:#ubuntu-release- New: accepted haskell-github [i386] (eoan-proposed) [0.20-1build2]
-queuebot:#ubuntu-release- New: accepted github-backup [i386] (eoan-proposed) [1.20170301-2build2]
-queuebot:#ubuntu-release- New: accepted haskell-github [s390x] (eoan-proposed) [0.20-1build2]
-queuebot:#ubuntu-release- New: accepted haskell-github [arm64] (eoan-proposed) [0.20-1build2]
<sil2100> Laney: that's something we'll do later, for now I just reverted the version from -updates
<sil2100> Rebuilding is like a separate thing, since it needs a rebuild, this was a bin copy
<sil2100> So yes! Existing users will still be broken for now!
<sil2100> slashd: did you find a fix already?
<Laney> OK then
-queuebot:#ubuntu-release- Unapproved: dpkg (bionic-proposed/main) [1.19.0.5ubuntu2.2 => 1.19.0.5ubuntu2.3] (core)
-queuebot:#ubuntu-release- Unapproved: dpkg (disco-proposed/main) [1.19.6ubuntu1.1 => 1.19.6ubuntu1.2] (core)
-queuebot:#ubuntu-release- Unapproved: dpkg (xenial-proposed/main) [1.18.4ubuntu1.6 => 1.18.4ubuntu1.7] (core)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-62.69~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-62.69~16.04.1] (kernel)
<slashd> sil2100, maybe, but need to test with impacted users first
<slashd> sil2100, will know more most likely on Monday
<sil2100> slashd: ok, so if the fix is not obvious, I guess I'll fast track a revert-upload with the version number bumped
<sil2100> But after I'm back from practice
<vorlon> coreycb: monasca-statsd is python2-only hasn't been uploaded since artful; what should we do with this?
<vorlon> coreycb: LP: #1843078
<ubot5> Launchpad bug 1843078 in monasca-statsd (Ubuntu) "monasca-statsd: Ubuntu-specific, python2-only, no reverse-dependencies" [Undecided,New] https://launchpad.net/bugs/1843078
<coreycb> vorlon: i'll work on a new release with py3 only. it's clearly not a huge focus for us but not a dead project so might as well update it.
-queuebot:#ubuntu-release- New binary: gdmd [amd64] (eoan-proposed/none) [2.068.2+git190828-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gdmd [amd64] (eoan-proposed) [2.068.2+git190828-1]
<vorlon> coreycb: ok; but in the pile of things yet to be done for 19.10, is it important to update this, vs removing it now and letting it come back in later when someone cares?
<coreycb> vorlon: i almost came back and said let's just remove it but i already uploaded it. i agree though.
<vorlon> hah ok
<vorlon> coreycb: have you looked at python-cotyledon python2 removal at all?  I was working through python-os-testr NBS removal, and the obvious translations of debian/control and debian/rules fail because "PYTHON=python3.7 /usr/bin/testr-python3 run --parallel --subunit" calls "subunit2pyunit" which tries to run all the tests under python2 :P
<vorlon> does subunit need to move to python3?  the binary package depends on both python-subunit and python3-subunit, but the shebang is python2
<coreycb> vorlon: hmm, i haven't but happy to.
<coreycb> vorlon: can i take it from you?
<vorlon> coreycb: should I upload python-cotyledon as-is?  I think the bug is subunit
<vorlon> but I don't know if it's safe to flip subunit to python3 instead of python2
<coreycb> it should be fine to move subunit to python3 only
<coreycb> the build-depend, that is
<vorlon> ok, then I'll upload python-cotyledon now, and let you worry about making subunit DTRT
<coreycb> vorlon: ok
<vorlon> coreycb: if I hadn't already shown this to you, the burn-down list I'm working off of is https://people.canonical.com/~ubuntu-archive/nbs.html
<coreycb> vorlon: i've seen that but i have a hard time making sense of the web of connections
<coreycb> web of dependencies i should say
<coreycb> i guess the confusion is when i've looked at that report, i look at corresponding source packages and they're already py3 only
<vorlon> coreycb: but in some cases the py3-only versions might be stuck in -proposed (python-cliff, which doesn't migrate because it breaks python-os-testr and python-stestr, which are themselves NBS and should be removed, but have reverse-build-dependencies)
<coreycb> vorlon: exactly :)
<coreycb> vorlon: in that case does manually removing python-os-testr and python-stestr fix it?
<vorlon> interestingly, python-pyghmi also b-d on subunit, invokes it the same way, and doesn't hit any problems due to missing python2 modules
<vorlon> coreycb: yes but I'm also trying to unwind as much of this as possible rather than just create a pile of FTBFS packages that may or may not get looked at
<coreycb> ok
<vorlon> otoh some of these webs are getting knotty enough that I might start cutting through
<vorlon> python-bandit breaks python-cliff build which doesn't migrate because it breaks python-stestr which is NBS but can't be removed because it breaks python-debtcollector which doesn't migrate because it breaks python-keystoneclient which is NBS but can't be removed because it breaks python-swiftclient which is NBS but simplestreams build-depends on it
<vorlon> coreycb: novnc also looks like it needs switched to python3
<coreycb> vorlon: i'll take a look
<coreycb> vorlon: btw there's a bug for simplestreams - bug 1841277
<ubot5> bug 1841277 in simplestreams (Ubuntu) "please drop Py 2 OpenStack dependencies" [High,Triaged] https://launchpad.net/bugs/1841277
<vorlon> coreycb: yeah I know, I chatted briefly w/ powersj and rcj about it yesterday
<coreycb> ok
<coreycb> vorlon: novnc is uploaded and py2-only. i'll look at cotyledon monday.
<vorlon> \o/
<coreycb> great to see a couple packages trickling through out of eoan-proposed!
<cjwatson> vorlon: In case you run into it, I'm planning to revert the removal of python-httmock temporarily, since I missed its build-dep from python-gitlab
<vorlon> cjwatson: ok
 * vorlon scratches his head and wonders how he managed to remove pylint2 prematurely and make things uninstallalbe
<cjwatson> (httmock on its way into Debian NEW now)
-queuebot:#ubuntu-release- Unapproved: net-snmp (disco-proposed/main) [5.7.3+dfsg-5ubuntu1.1 => 5.7.3+dfsg-5ubuntu1.2] (desktop-core, ubuntu-server)
#ubuntu-release 2019-09-07
-queuebot:#ubuntu-release- Unapproved: net-snmp (bionic-proposed/main) [5.7.3+dfsg-1.8ubuntu3.2 => 5.7.3+dfsg-1.8ubuntu3.3] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: net-snmp (xenial-proposed/main) [5.7.3+dfsg-1ubuntu4.3 => 5.7.3+dfsg-1ubuntu4.4] (desktop-core, ubuntu-server)
<vorlon> coreycb: looks like python-oslo.{context,i18n} and python-pbr also need sorted
<doko> test rebuild just started, a hundred ftbfs in main ... https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20190906-eoan.html
<vorlon> doko: is that a complete count for main, or still in progress?
<doko> vorlon: in progress, but i386 and amd64 should be finished
<doko> for main
<vorlon> ok
<doko> and it's using linux-libc-dev 5.3 from ubuntu-toolchain-r/volatile, so that might explain some of the linux related ftbfs
<vorlon> doko: a lot of the build failures seem to be missing build logs
<vorlon> devscripts, dict-foldoc (which I just gave back), dictionaries-common,
<vorlon> ok maybe just those 3.  3 > 0, so it's a lot ;)
<doko> feel free, but I'll do that only when all archs finish building main
<vorlon> dkms also.  so perhaps it was a timing thing
<vorlon> (i.e. a short-lived infra blip that ate the logs for a chunk of the 'd's)
<doko> infinity: looks like we need more no-change rebuilds for glibc: https://launchpadlibrarian.net/440610784/buildlog_ubuntu-eoan-amd64.aide_0.16.1-1build1_BUILDING.txt.gz
-queuebot:#ubuntu-release- New binary: haskell-blogliterately [amd64] (eoan-proposed/universe) [0.8.6.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-blogliterately [i386] (eoan-proposed/universe) [0.8.6.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-blogliterately [s390x] (eoan-proposed/universe) [0.8.6.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-blogliterately [ppc64el] (eoan-proposed/universe) [0.8.6.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-blogliterately [armhf] (eoan-proposed/universe) [0.8.6.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-blogliterately [arm64] (eoan-proposed/universe) [0.8.6.3-1] (no packageset)
<ginggs> doko: no, i presume the new binutils caused the byte sequence 0x69 0x49 0x46  to appear in the armhf binaries, tripping up lintian's spelling-error-in-binary warning
<ginggs> the binaries-missing-lfs failures on i386 and armhf are new since lintian 2.20.0 and reproducible in debian
<ginggs> i am filing bugs for both
<doko> ginggs: that could be https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=1c1e0fe58b9389bd40f5f642d20dc2e1befd4541
<doko> hmm, but i386?
<ginggs> spelling error only on armhf
<infinity> doko: Looks like that was always the case, but the warnings telling us about it are new.  Also, ick to aide statically linking audit, cap, and acl.
<infinity> doko: Realistically, I think this might mean that any static libraries need a rebuild against the new libc, then any static binaries pulling those in also need a rebuild, but... Gross.
<infinity> Well, not *any*, but any that use NSS.
<infinity> So, yes, this has always been true, it just didn't used to complain at build time.
<infinity> doko: Although, the hard error there (the LTO version thing) is new...
<infinity> And I think that's things needing rebuilding with new GCC, not new glibc.
<infinity> Maybe.
<infinity> doko: Yeah, confirmed, the LTO version failure there is due to GCC version mismatches, not glibc.  The warnings before that are glibc, but not fatal.
<infinity> doko: So, libe2p.a needs a rebuild with the current GCC.
<LocutusOfBorg> anybody please accept haskell-blogliterately
<infinity> doko: Which is in libext2fs-dev
<LocutusOfBorg> (haskell is getti closer)
-queuebot:#ubuntu-release- New: accepted elisa-player [sync] (eoan-proposed) [1.1+really0.4.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-blogliterately [arm64] (eoan-proposed) [0.8.6.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-blogliterately [i386] (eoan-proposed) [0.8.6.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-blogliterately [s390x] (eoan-proposed) [0.8.6.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-blogliterately [amd64] (eoan-proposed) [0.8.6.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-blogliterately [ppc64el] (eoan-proposed) [0.8.6.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-blogliterately [armhf] (eoan-proposed) [0.8.6.3-1]
-queuebot:#ubuntu-release- New binary: elisa-player [s390x] (eoan-proposed/universe) [1.1+really0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: elisa-player [ppc64el] (eoan-proposed/universe) [1.1+really0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: elisa-player [amd64] (eoan-proposed/universe) [1.1+really0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: elisa-player [i386] (eoan-proposed/universe) [1.1+really0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: elisa-player [arm64] (eoan-proposed/universe) [1.1+really0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: elisa-player [armhf] (eoan-proposed/universe) [1.1+really0.4.0-1] (no packageset)
<LocutusOfBorg> vorlon, if you still care... I might found a fix for your python-cotyledon build failure https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+sourcepub/10528615/+listing-archive-extra
<LocutusOfBorg> but I would onestly just sync it
<LocutusOfBorg> I can't run tests anymore with the new release
-queuebot:#ubuntu-release- New: accepted elisa-player [amd64] (eoan-proposed) [1.1+really0.4.0-1]
-queuebot:#ubuntu-release- New: accepted elisa-player [armhf] (eoan-proposed) [1.1+really0.4.0-1]
-queuebot:#ubuntu-release- New: accepted elisa-player [ppc64el] (eoan-proposed) [1.1+really0.4.0-1]
-queuebot:#ubuntu-release- New: accepted elisa-player [arm64] (eoan-proposed) [1.1+really0.4.0-1]
-queuebot:#ubuntu-release- New: accepted elisa-player [s390x] (eoan-proposed) [1.1+really0.4.0-1]
-queuebot:#ubuntu-release- New: accepted elisa-player [i386] (eoan-proposed) [1.1+really0.4.0-1]
<doko> infinity: the correct solution is not to ship the lto information in the .a files in the archive.  dh_strip should strip these.  I don't think it's reliable to patch all upstreams not to build with -flto
<infinity> doko: Potentially also a reasonable position to take.  But it's clearly not happening here. :P
<doko> infinity: https://tracker.debian.org/news/1052440/accepted-e2fsprogs-1453-4-source-into-unstable/
<infinity> doko: In the case of e2fsprogs, though, upstream is also the Debian maintainer, so if there's a "correct" thing he should be doing with his static libraries, he might appreciate the prod.
<infinity> Oh, jinx. :)
<infinity> So just needs a merge.
<infinity> Or maybe a cherrypick of that one change, if we don't want to justify a new upstream.
<infinity> Looks like mostly bugfixes, though.
<infinity> doko: You're TIL on e2fsprogs, +1 with a release hat on for you to merge to current Debian if you feel the urge.
<infinity> If you want to get rid of it, I can do it after I've slept.
<infinity> Just /msg me as a reminder, if so.
<ginggs> doko: how urgent is lintian? can we revert to 2.19.0 + a patch?
<doko> ginggs: I didn't sync it, I don't care that much
<ginggs> oh ok, I saw it was blocking some things
<doko> infinity: please go ahead and merge
<doko> infinity: now filed https://bugs.debian.org/939656
<ubot5> Debian bug 939656 in debhelper,lintian "dh_strip should strip sections with LTO information from .a and .o files / lintian should warn about these" [Important,Open]
<RikMills> thank you to whoever accepted elisa-player :)
<mwhudson> ginggs: i've just been poking at lintian a bit and am quite confused
<mwhudson> i think it must be a debian bug though
<ginggs> mwhudson: the binaries-missing-lfs failures on i386 and armhf ?
<mwhudson> ginggs: yes
<ginggs> mwhudson: i did file debian bug #939639
<ubot5> Debian bug 939639 in src:lintian "lintian: autopkgtest failure on 32-bit architectures" [Normal,Open] http://bugs.debian.org/939639
<mwhudson> ginggs: do you know how to make the test suite print the lintian command line it's running?
<mwhudson> ah ok i'll subscribe to that bug and go to sleep
<ginggs> mwhudson: no idea. sleep well!
<mwhudson> the tag is emitted properly when i run lintian -E on the built test deb by hand ...
<ginggs> it seems there was a lot of refactoring from 2.19.0 to 2.20.0, and those tests only run on armhf and i386, so they could have been inadvertently broken
<LocutusOfBorg> I'm trying hard to debug lintian...
<ginggs> LocutusOfBorg: reverting to 2.19.0 + spelling error patch will work
<ginggs> LocutusOfBorg: here's the fix https://deb.li/SIjg
<LocutusOfBorg> too late I guess :D
<LocutusOfBorg> can I get an AA around to help haskell go in release?
<LocutusOfBorg> vorlon, ^^
<LocutusOfBorg> ppc64el removals: gtk2hs-buildtools haskell-cairo haskell-glib haskell-gio haskell-pango haskell-gtk haskell-gtk3 haskell-gtk-traymanager haskell-yi-frontend-pango haskell-chart-cairo yi haskell-diagrams-cairo haskell-diagrams-gtk haskell-gtk-sni-tray	
<LocutusOfBorg> with such removals on ppc64el the picture will be more clear...
<LocutusOfBorg> I tried really hard, and also fedora is trying to sort out that problem... nobody has a clue
<LocutusOfBorg> also debian folks...
<LocutusOfBorg> kick out to proposed pocket, no upstream fixes, FTBFS with ghc 8.6.5: haskell-werewolf haskell-yi-keymap-vim haskell-yi-mode-javascript haskell-yi-keymap-emacs haskell-hakyll taffybar nbsphinx (See Debian bug: #939492)
<ubot5> Debian bug 939492 in src:nbsphinx "nbsphinx: testsuite failures with new pandoc" [Serious,Open] http://bugs.debian.org/939492
<LocutusOfBorg> we need a dinstall or two, I'm fixing other 3 packages
<LocutusOfBorg> also, why hasn't been this package cleaned up? old binaries left on amd64: python-openvswitch (from 2.11.1-0ubuntu1)
<LocutusOfBorg> is this python2 decruft happening automatically?
<LocutusOfBorg> (please somebody blacklist ghc)
-queuebot:#ubuntu-release- Unapproved: net-snmp (disco-proposed/main) [5.7.3+dfsg-5ubuntu1.1 => 5.7.3+dfsg-5ubuntu1.2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: net-snmp (bionic-proposed/main) [5.7.3+dfsg-1.8ubuntu3.2 => 5.7.3+dfsg-1.8ubuntu3.3] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: net-snmp (xenial-proposed/main) [5.7.3+dfsg-1ubuntu4.3 => 5.7.3+dfsg-1ubuntu4.4] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New sync: libdata-methodproxy-perl (eoan-proposed/primary) [0.04-1]
<vorlon> LocutusOfBorg: your list of ppc64el removals doesn't seem to encompass the reverse-dependencies.  taffybar build-depends on haskell-gtk-sni-tray, e.g.  I assume we should also remove any of those I find along the way
<LocutusOfBorg> taffybar is on the second list
<LocutusOfBorg> the "kick out from release to whatever you want"
<LocutusOfBorg> the only reverse-dependency I found so far in ppc64el that is missing, is carettah
<LocutusOfBorg> and threadscope
<LocutusOfBorg> (I'm rebuilding also unrelated haskell packages, just to spot such issues)
<vorlon> ack
<vorlon> well the second list is being processed second, and processing the first list requires dealing with the revdeps, so
<vorlon> anyway, am making my way down the stack now
<vorlon> LocutusOfBorg: nbsphinx, haskell-yi-keymap-vim, haskell-yi-mode-javascript, haskell-yi-keymap-emacs all show as having reverse-build-deps; are these resolved in -proposed?
<vorlon> LocutusOfBorg: as for NBS decruft, that always requires an AA to ack https://people.canonical.com/~ubuntu-archive/nbs.html
<LocutusOfBorg> sorry its a huge deal haskell for me, I don't have clear answers for your questions...
<LocutusOfBorg> for sure I have to fix (tomorrow) uuagc, haskell-snap-templates, threadscope, arbtt, stylish-haskell, bustle, rss2irchaskell-stack
<LocutusOfBorg> and ganeti
<LocutusOfBorg> they shouldn't block transition, but I want them fixed
<LocutusOfBorg> I also would like to undestand why I can't rebuild git-annex
<LocutusOfBorg> Symbolic link for debian/copyright not allowed
<LocutusOfBorg> damn
#ubuntu-release 2019-09-08
<vorlon> LocutusOfBorg: heh, ghc now tied up with a gtk+3.0 shlibs bump
<vorlon> but certainly much closer overall
-queuebot:#ubuntu-release- New binary: e2fsprogs [i386] (eoan-proposed/main) [1.45.3-4ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: e2fsprogs [s390x] (eoan-proposed/main) [1.45.3-4ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: e2fsprogs [amd64] (eoan-proposed/main) [1.45.3-4ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: e2fsprogs [ppc64el] (eoan-proposed/main) [1.45.3-4ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: e2fsprogs [arm64] (eoan-proposed/main) [1.45.3-4ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: e2fsprogs [armhf] (eoan-proposed/main) [1.45.3-4ubuntu1] (core)
-queuebot:#ubuntu-release- New: accepted e2fsprogs [amd64] (eoan-proposed) [1.45.3-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted e2fsprogs [armhf] (eoan-proposed) [1.45.3-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted e2fsprogs [ppc64el] (eoan-proposed) [1.45.3-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted libdata-methodproxy-perl [sync] (eoan-proposed) [0.04-1]
-queuebot:#ubuntu-release- New: accepted e2fsprogs [arm64] (eoan-proposed) [1.45.3-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted e2fsprogs [s390x] (eoan-proposed) [1.45.3-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted e2fsprogs [i386] (eoan-proposed) [1.45.3-4ubuntu1]
-queuebot:#ubuntu-release- New binary: libdata-methodproxy-perl [amd64] (eoan-proposed/none) [0.04-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libdata-methodproxy-perl [amd64] (eoan-proposed) [0.04-1]
-queuebot:#ubuntu-release- Unapproved: dehydrated (bionic-proposed/universe) [0.6.1-2 => 0.6.2-2ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: dehydrated (disco-proposed/universe) [0.6.2-2 => 0.6.2-2ubuntu0.19.04.1] (no packageset)
<LocutusOfBorg> vorlon, firewalld can be hinted, regressed due to nftables
<LocutusOfBorg> (sigh, I already suggested to use firewalld as nftables testsuite, it catches *all* its regressions)
<LocutusOfBorg> I'll talk now with upstream to fix them
-queuebot:#ubuntu-release- New binary: freeipa [i386] (eoan-proposed/universe) [4.8.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: freeipa [s390x] (eoan-proposed/universe) [4.8.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: freeipa [ppc64el] (eoan-proposed/universe) [4.8.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: freeipa [arm64] (eoan-proposed/universe) [4.8.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: freeipa [armhf] (eoan-proposed/universe) [4.8.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: freeipa [amd64] (eoan-proposed/universe) [4.8.1-0ubuntu1] (no packageset)
#ubuntu-release 2020-08-31
<mwhudson> ah now i see where gi-harfbuzz comes n
<mwhudson> *in
-queuebot:#ubuntu-release- New: accepted haskell-gi-harfbuzz [source] (groovy-proposed) [0.0.3-1~build1]
-queuebot:#ubuntu-release- New binary: haskell-gi-harfbuzz [amd64] (groovy-proposed/none) [0.0.3-1~build1] (no packageset)
<mwhudson> vorlon, LocutusOfBorg: do either of you know what's going on with gjs?
<vorlon> no idea
<vorlon> LocutusOfBorg: fyi lintian complains about haskell-gi-harfbuzz because the Copyright: fields don't list a year
-queuebot:#ubuntu-release- New binary: haskell-gi-harfbuzz [s390x] (groovy-proposed/universe) [0.0.3-1~build1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-gi-harfbuzz [amd64] (groovy-proposed) [0.0.3-1~build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-harfbuzz [s390x] (groovy-proposed) [0.0.3-1~build1]
<vorlon> https://launchpad.net/ubuntu/+source/dpkg/1.20.5ubuntu2 will hopefully speed things up a bit going forward
<mwhudson> vorlon: is that build going to slowly run all the tests on riscv first? :)
-queuebot:#ubuntu-release- New binary: haskell-gi-harfbuzz [ppc64el] (groovy-proposed/universe) [0.0.3-1~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-harfbuzz [arm64] (groovy-proposed/universe) [0.0.3-1~build1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-gi-harfbuzz [arm64] (groovy-proposed) [0.0.3-1~build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-harfbuzz [ppc64el] (groovy-proposed) [0.0.3-1~build1]
<vorlon> mwhudson: of course ;) but it seems to have finished now
<mwhudson> vorlon: hooray
<mwhudson> https://launchpad.net/ubuntu/+source/haskell-gi-harfbuzz/0.0.3-1~build1/+build/19896035 still going though
<mwhudson> nearly done
<oSoMoN> good morning everyone
<oSoMoN> SRU team: could you please accept chromium-browser into focal-proposed?
<tjaalton> oSoMoN: looking
<oSoMoN> thanks!
-queuebot:#ubuntu-release- Unapproved: accepted chromium-browser [source] (focal-proposed) [1:85.0.4183.83-0ubuntu0.20.04.1]
<oSoMoN> thanks tjaalton
<LocutusOfBorg> mwhudson, for gjc, either ask the person who syncd from experimental, or ask to stick with a version from debian testing and sid?
<xnox> mwhudson:  you mean that we have mutter transition https://launchpad.net/ubuntu/+source/mutter/3.37.91-1ubuntu1 and mutter is stuck in NEW hence we can't build/rebuild things?
<xnox> oh the autopkgtest?
<xnox> Trevinho:  gjs is failing autopkgtests in ubuntu https://autopkgtest.ubuntu.com/packages/g/gjs/groovy/amd64
<xnox> 64 good, 65 bad
<mwhudson> xnox: yeah i bumped into the mutter thing too but i meant the autopkgtests
<mwhudson> argh "start in 4 hours" https://launchpad.net/ubuntu/+source/haskell-gi-gdk/3.0.23-1/+build/19872330
<mwhudson> anyone want to score that up? :)
<LocutusOfBorg> mwhudson, it failed
<mwhudson> ah so it did
<LocutusOfBorg> looks like haskell-gi-gdkpixbuf and haskell-gi-gio should finish first
<mwhudson> ah i see the deps are still building
<LocutusOfBorg> yep I kicked the build
<mwhudson> might even be time to kick haskell-gi-gtk builds by the time i wake up again
<mwhudson> maybe
<Trevinho> xnox: oh, weeeird. not sure what's wrong there, I'll check
<Trevinho> xnox: however now that mozjs78 is into NEW, I think we should just get that together with new gjs (as the one I pulled was the first revision good for new g-s but without new mozjs)
<Trevinho> debian's NEW, not ubuntu (yet)
<Trevinho> we've still to handle some destkop packages though (due to these NEW's delays), so not sure we should do a global FFe or not.
-queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (bionic-proposed) [1.37~18.04.8]
-queuebot:#ubuntu-release- Unapproved: rejected rpi-eeprom [source] (focal-proposed) [7.8-0ubuntu0.20.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted language-selector [source] (focal-proposed) [0.204.1]
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-13 [source] (focal-proposed) [13.0.4+8-1~20.04]
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-14 [source] (focal-proposed) [14.0.2+12-1~20.04]
-queuebot:#ubuntu-release- Unapproved: rejected backport-iwlwifi-dkms [source] (focal-proposed) [8613-0ubuntu1~20.04.1]
<vorlon> retried the ghc/armhf build, again
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (focal-proposed/main) [5.4.0-46.50] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: accepted s390-tools [s390x] (groovy-proposed) [2.14.0-1ubuntu1]
<teward> anyone on SRU team around?
<teward> got a questino fer ya
<teward> question*
<sigv> teward: I am not, but generally, don't ask to ask.
<teward> heh.  i'm trying to determine the feasbility of taking s3cmd from Groovy to Focal as an SRU, to fix some python issues in it and make sure it's up to date with S3 stuff.  but not sure if that's super feasible.  (The SRU justification would be it fixes multiple bugs and introduces compatibility and Python fixes.)
<sigv> teward: pretty much https://sol.gfxile.net/dontask.html
<teward> > "don't ask"
<teward> you already said that, please don't beat the dead horse
<vorlon> teward: seems unlikely that a new upstream release of this magnitude would pass muster for SRU
<teward> vorlon: hmm, well unfortunately guess what they didn't do
<teward> make the fix for 1874651 easy to nitpick
<teward> trying to see if i can find the commit though
<teward> ah here it is
<teward> wow that's a simple patch
<teward> vorlon: could we SRU a two-line patch to fix the python problem then?
<teward> since this is polluting an autoupdates function I have now
<teward> automated process*
<teward> E:NeedCoffee
<rbasak> What exactly is the problem that this patch fixes?
<rbasak> Oh you linked a bug, sorry
<rbasak> I think it's OK to SRU that
<rbasak> if response["status"] is 200 -> if response["status"] == 200 I mean
<rbasak> The former is technically buggy anyway
<rbasak> As well as the warning being annoying
<teward> rbasak: yep that's *literally* the fix
<teward> though there was some other S3 stuff I needed and i like bugfixes so I personally backported for myself in a PPA :P
<teward> because I'm Insane that way (but we know this)
-queuebot:#ubuntu-release- Unapproved: s3cmd (focal-proposed/universe) [2.0.2-1 => 2.0.2-1ubuntu1] (no packageset)
<teward> rbasak: i also uploaded it to proposed and SRU-templated the bug so... ^ SRU review ready :)
<rbasak> Thanks
<teward> (and it's a tiny tiny fix but it's annoying As Heck)
<rbasak> I'm on vacation today :)
<teward> yep
<teward> (one advantage of coredev is upload xD0
<teward> (one advantage of coredev is upload rights xD)
<rbasak> One advantage of teward being a coredev is that he fixes things for Ubuntu :-P
<teward> :P
<teward> in many different locations
<teward> some universe, some main, with sprinkles of my own brand of chaos everywhere xD
<teward> POSITIVE chaos though :)
<teward> and in case you're curious this literally *is* the change on upstream: https://github.com/s3tools/s3cmd/commit/92a9c79b5a505d66ff25b661ef9c5191d9985252
<teward> like tiny tiny two liner just to replace `is` with `==` :P
<teward> so that should be an easy one
<rbalint> sil2100, vorlon could you please merge https://code.launchpad.net/~rbalint/britney/hints-ubuntu/+merge/389987 for glibc and various other packages?
<vorlon> rbalint: I'm reviewing it; -1 for merging as-is, comments pending on the MP once I get through the list
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (focal-proposed/main) [5.4.0-46.50] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-190.220] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (focal-proposed/main) [5.4.0-46.50] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (focal-proposed/main) [5.4.0-46.50] (core, kernel)
<rbalint> vorlon, thanks, trimmed down the mp and fixed the rest, please take look at it again
<vorlon> rbalint: done
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (focal-proposed) [5.4.0-46.50]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (focal-proposed) [5.4.0-46.50]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (focal-proposed) [5.4.0-46.50]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (focal-proposed) [5.4.0-46.50]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-190.220]
<mwhudson> urgh ghc failed with no log on armhf
<vorlon> yeah; I've retried the build at least 3x now
<vorlon> am asking lp folks
<mwhudson> uggggh
<LocutusOfBorg> vorlon, I retried at least 6 more times
<vorlon> whee
<LocutusOfBorg> there is no armhf builder capable of being up for at least 4 days
<LocutusOfBorg> I already asked on #launchpad
<vorlon> so, IS has made some networking changes today; it's possible this may improve things
-queuebot:#ubuntu-release- Unapproved: nvme-cli (focal-proposed/universe) [1.9-1 => 1.9-1ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: nvme-cli (bionic-proposed/universe) [1.5-1ubuntu1 => 1.5-1ubuntu1.1] (no packageset)
<santa_> RikMills: last updates of the day: I have updated the lintian overrides for kcalcore (fw) and kdeplasma-addons,ksysguard,kwin,plasma-workspace (plasma)
<santa_> so we have this http://tritemio-groomlake.duckdns.org/build-status/buildstatus_ubuntu-exp2/ubuntu-exp2_status_frameworks.html
<santa_> and this http://tritemio-groomlake.duckdns.org/build-status/buildstatus_ubuntu-exp2/ubuntu-exp2_status_plasma.html
<santa_> as green as possibru
<santa_> I haven't touch applications yet
<santa_> good night everybody
 * santa_ signs off
#ubuntu-release 2020-09-01
-queuebot:#ubuntu-release- Packageset: Removed modernizr from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added pangox-compat to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added pangox-compat to i386-whitelist in groovy
<vorlon> xnox: our groovy daily ISOs are pulling in a grub signed with the old archive signing key.  Why is this?
<vorlon> xnox: hmm because gcdx64.efi.signed is copied into cd-boot-images-amd64 at build time instead of letting it be pulled directly from the archive mirror, and has not been updated since the CVE
<vorlon> xnox: LP: #1892754 - so who is responsible for tracking that Built-Using points to an out-of-date version?
<ubot5> Launchpad bug 1892754 in cd-boot-images-amd64 (Ubuntu) "Unable to boot in UEFI+secure boot mode" [High,Fix committed] https://launchpad.net/bugs/1892754
<guiverc> thanks vorlon :)
<RAOF> Hm. Is `pkg-config --static --libs wayland-client` failing with missing dependencies a bug we care about?
 * RAOF is not sure why the build system is adding the `--static` flag ð¤·ââï¸
<RAOF> Ooops, wrong channel.
<vorlon> guiverc: sure - sorry we missed this
<guiverc> caught before release, that's what matters :)
<RikMills> santa_: ack. plasma 5.19.5 should be out later today, so I will incorporate those changes
<Laney> wee no ghc/armhf build yet?
<santa_> RikMills: thanks, wrong chan by the way, sorry everyone else for the noise
<xnox> vorlon:  i heard rumours that launchpad would have started doing this soon together with new britney. i guess that was not the case. Should I add strict Depends on == of built-using packages?
<cjwatson> xnox: I'm still working on LP Built-Using support but it got pushed back somewhat due to discovering problems that required a rethink
<mwhudson> xnox: i guess strict depends would solve the problem for now
<Laney> The support is there in proposed-migration, but it doesn't make too much sense to enforce it there without the LP side
<Laney> We will enable it once that's good to go
<Laney> LocutusOfBorg: Yeah, I saw!
-queuebot:#ubuntu-release- New: accepted node-srs [sync] (groovy-proposed) [0.4.9-1]
-queuebot:#ubuntu-release- New: accepted mutter [amd64] (groovy-proposed) [3.37.91-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted mutter [armhf] (groovy-proposed) [3.37.91-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted mutter [riscv64] (groovy-proposed) [3.37.91-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted mutter [arm64] (groovy-proposed) [3.37.91-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted mutter [s390x] (groovy-proposed) [3.37.91-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted mutter [ppc64el] (groovy-proposed) [3.37.91-1ubuntu1]
-queuebot:#ubuntu-release- New binary: node-srs [amd64] (groovy-proposed/universe) [0.4.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-srs [ppc64el] (groovy-proposed/universe) [0.4.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-srs [s390x] (groovy-proposed/universe) [0.4.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-srs [arm64] (groovy-proposed/universe) [0.4.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-srs [armhf] (groovy-proposed/universe) [0.4.9-1] (no packageset)
<xnox> Laney:  what would proposed-migration thing do? prevent migrations?
<Laney> yep, enforce the built-using thing is present in the target
<xnox> Laney:  i kind of think it is useful to start enforcing that already, if there is code to do that. It would have blocked grub2-signed from migrating without cd-boot-images-amd64 rebuild.
<xnox> or does it only prevent i.e. cd-boot-images-amd64 from migrating, ahead of grub2-signed/shim-signed/etc?
<Laney> what has the Built-Using here?
<Laney> problem is that without archive support it can be falsified at any time
-queuebot:#ubuntu-release- New binary: linux-signed-kvm [amd64] (groovy-proposed/main) [5.8.0-1001.1] (core)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (groovy-proposed/main) [5.8.0-1001.1] (core, kernel)
-queuebot:#ubuntu-release- New: accepted node-srs [amd64] (groovy-proposed) [0.4.9-1]
-queuebot:#ubuntu-release- New: accepted node-srs [armhf] (groovy-proposed) [0.4.9-1]
-queuebot:#ubuntu-release- New: accepted node-srs [s390x] (groovy-proposed) [0.4.9-1]
-queuebot:#ubuntu-release- New: accepted node-srs [arm64] (groovy-proposed) [0.4.9-1]
-queuebot:#ubuntu-release- New source: mozjs78 (groovy-proposed/primary) [78.2.0-1~fakesync1]
-queuebot:#ubuntu-release- New: accepted node-srs [ppc64el] (groovy-proposed) [0.4.9-1]
-queuebot:#ubuntu-release- New: accepted mozjs78 [source] (groovy-proposed) [78.2.0-1~fakesync1]
<handsome_feng> Hi, Any idea about same code build successfully on Debian but fails on Ubuntu due to symbols file? see:  https://buildd.debian.org/status/fetch.php?pkg=peony&arch=ppc64el&ver=3.0.2-2&stamp=1597758554&raw=0 and https://launchpadlibrarian.net/495492230/buildlog_ubuntu-groovy-ppc64el.peony_3.0.2-2_BUILDING.txt.gz (Ignore the .qm warnings which I fixed in recent commits),  I tested 'export
<handsome_feng> DPKG_GENSYMBOLS_CHECK_LEVEL = 1', but still failed in my PPA.
-queuebot:#ubuntu-release- New binary: mozjs78 [s390x] (groovy-proposed/main) [78.2.0-1~fakesync1] (no packageset)
<LocutusOfBorg> handsome_feng, just mark some symbols as optional and add the new ones as optional?
<LocutusOfBorg> ubuntu uses -O3 optimization, this makes some symbols change
<LocutusOfBorg> (and I would say that symbols for c++ projects are a waste of time)
-queuebot:#ubuntu-release- New binary: mozjs78 [ppc64el] (groovy-proposed/main) [78.2.0-1~fakesync1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-kvm [amd64] (groovy-proposed) [5.8.0-1001.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (groovy-proposed) [5.8.0-1001.1]
<LocutusOfBorg> xnox, is nodejs patch for https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1858971 still useful?
<ubot5> Ubuntu bug 1858971 in ruby2.5 (Ubuntu) "SECLEVEL=2 & tls1.2-min by default are causing ftbfs / autopkgtest failures" [Undecided,Fix committed]
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-116.117] (core, kernel)
<LocutusOfBorg> I don't understand why this last piece of delta can't go in debian or go away
-queuebot:#ubuntu-release- New binary: mozjs78 [amd64] (groovy-proposed/main) [78.2.0-1~fakesync1] (no packageset)
<handsome_feng> LocutusOfBorg: Got it, Thanks!
<LocutusOfBorg> handsome_feng, if you need help, just ask :)
<handsome_feng> LocutusOfBorg: Thanks, :) ,  I'm thinking of  just delete the symbols file and then specify the exact dependent library, is it acceptable?
<handsome_feng> It's hard to deal with the symbols file even with the kde tools.
<coreycb> RAOF: hello, if you happen to have cycles in your SRU rota today we have a few openstack stable releases in the focal unapproved queue. the neutron one in particular has a number of needed OVN fixes. this is for bug 1892139.
<ubot5> bug 1892139 in Ubuntu Cloud Archive ussuri "[SRU] ussuri stable releases" [High,In progress] https://launchpad.net/bugs/1892139
<LocutusOfBorg> handsome_feng, I don't know the answer... :D
<LocutusOfBorg> it really depends on the project and context, and how fast it does change symbols
<handsome_feng> LocutusOfBorg: Okay, I'll do some research and find some examples. Thanks a lot! :)
-queuebot:#ubuntu-release- New binary: mozjs78 [arm64] (groovy-proposed/main) [78.2.0-1~fakesync1] (no packageset)
-queuebot:#ubuntu-release- New binary: mozjs78 [riscv64] (groovy-proposed/main) [78.2.0-1~fakesync1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-116.117] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (focal-proposed) [2.664.6]
-queuebot:#ubuntu-release- New binary: mozjs78 [armhf] (groovy-proposed/main) [78.2.0-1~fakesync1] (no packageset)
<bdmurray> sil2100: I'd like to get gnome-control-center for focal fully phased. The new issues are all false positives as 1:3.36.3-... didn't exist for very long.
<sil2100> bdmurray: ok, sure
<sil2100> I can override it, hopefully once it's phased 100 it will not get zeroed out on new false positives
<bdmurray> sil2100: It won't we've done this before.
<sil2100> Done!
<bdmurray> Thanks
<coreycb> bdmurray: if you happen to have some cycles in your SRU rota, we have a neutron upload in the focal unapproved queue with some important OVN fixes
<bdmurray> coreycb: ack
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (focal-proposed) [2:16.1.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted glance [source] (focal-proposed) [2:20.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-flashback [source] (focal-proposed) [3.36.4-0ubuntu1]
<vorlon> "started 6 hours ago" <table flip> https://launchpad.net/ubuntu/+source/haskell-gi-gtk/3.0.36-1/+build/19872368
<vorlon> did someone here restart those haskell-gi-gtk builds, and can explain why?
<vorlon> xnox, Laney: I am not in favor of britney enforcing Built-Using, it will make proposed-migration even more brittle than it already is.  (And I think for that matter we'd be better off without britney enforcing build-depends, in favor of the previous handling of doing an end-of-cycle cleanup of ftbfs)
-queuebot:#ubuntu-release- Unapproved: accepted valgrind [source] (focal-proposed) [1:3.15.0-1ubuntu9.1]
-queuebot:#ubuntu-release- Unapproved: accepted valgrind [source] (bionic-proposed) [1:3.13.0-2ubuntu2.3]
-queuebot:#ubuntu-release- Unapproved: rejected sbsigntool [source] (focal-proposed) [0.9.2-2ubuntu1.20.04.1]
-queuebot:#ubuntu-release- New: accepted shim-canonical [amd64] (groovy-proposed) [2]
-queuebot:#ubuntu-release- New: accepted shim-canonical [arm64] (groovy-proposed) [2]
-queuebot:#ubuntu-release- Unapproved: accepted s3cmd [source] (focal-proposed) [2.0.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected python-taskflow [source] (focal-proposed) [4.1.0-0ubuntu1.1]
<teward> bdmurray: thanks for accepting the s3cmd into proposed.  If nobody replies with it being tested by EOD Tomorrow I'll weigh in - 'cause this issue bites me too.  (I know it's preferred that the 'uploader' doesn't test the SRU alone but... :P)
<teward> (I also know it's still accepted if nobody else does the testing)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-116.117]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-116.117]
<vorlon> cpaelzer: hi, you said on https://code.launchpad.net/~paelzer/britney/hints-ubuntu-groovy-vagrant-libvirt/+merge/389888 that the change is "now correct", but I see no changes on your branch, and the version listed in your hint update is only in -proposed, NOT in the release pocket
<rbalint> vorlon, could you please merge this (hopefully) last round for glibc? https://code.launchpad.net/~rbalint/britney/hints-ubuntu/+merge/390116
-queuebot:#ubuntu-release- New source: libnsl (groovy-proposed/primary) [1.3.0-0ubuntu1]
-queuebot:#ubuntu-release- New source: rpcsvc-proto (groovy-proposed/primary) [1.4.2-0ubuntu1]
<rbalint> vorlon, also those are for the new glibc, please check them, too ^
-queuebot:#ubuntu-release- Unapproved: rejected freecad [source] (bionic-proposed) [0.16.6712+dfsg1-1ubuntu2.1]
<LocutusOfBorg> vorlon, missing build on i386: libdune-ocaml-dev, ocaml-dune (from 2.1.3-2)
<LocutusOfBorg> can you please do something?
<vorlon> LocutusOfBorg: removed; and if someone could get lintian to migrate, we'd be clean wrt packageset overrides and I could do a batch cleanup
<LocutusOfBorg> do we need 3 MIRs?
<vorlon> I think that's what's currently missing
<vorlon> there was some discussion of perl fast-track MIRs, but that's waiting on doko
<vorlon> (not sure if anyone actually talked to doko about it)
<LocutusOfBorg> there is also an armhf regression...
<LocutusOfBorg> but we might want to try to move armhf to big-packages, and test here
<LocutusOfBorg> vorlon, https://autopkgtest.ubuntu.com/packages/u/udisks2/groovy/amd64 looks like regressed in release? can we do something?
<vorlon> LocutusOfBorg: covered by rbalint's MP above
<LocutusOfBorg> oh rbalint ^^ yep sorry I just discovered bug 1893827
<ubot5> bug 1893827 in udisks2 (Ubuntu) "autopkgtest fails in groovy" [Undecided,New] https://launchpad.net/bugs/1893827
<vorlon> rbalint: merged; and I appreciate the due diligence wrt baseline retesting
<vorlon> rbalint: if glibc is dropping libnsl, doesn't it need a pre-dependency on the new package to ensure its availability for all existing packages that use it?  Because lbnsl1 is certainly listed in libc6.symbols/.shlibs as pointing to libc6
<vorlon> (rpcsvc seems less critical since it's only about headers + rpcgen, but do we know what the buildability impact will be there too?)
<vorlon> oh, I see, this is libnsl2, not libnsl1
<vorlon> rbalint: I: libnsl source: wildcard-matches-nothing-in-dep5-copyright src/nisplus/nis_hash.c (paragraph at line 38)
<vorlon> I: libnsl source: wildcard-matches-nothing-in-dep5-copyright test-driver (paragraph at line 119)
<vorlon> rbalint: similarly, some debian/copyright mismatches on rpcsvc-proto
-queuebot:#ubuntu-release- New: accepted libnsl [source] (groovy-proposed) [1.3.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: libnsl [amd64] (groovy-proposed/none) [1.3.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libnsl [s390x] (groovy-proposed/none) [1.3.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libnsl [ppc64el] (groovy-proposed/none) [1.3.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rpcsvc-proto [source] (groovy-proposed) [1.4.2-0ubuntu1]
<mwhudson> well ghc/armhf hasn't failed yet
-queuebot:#ubuntu-release- New binary: libnsl [arm64] (groovy-proposed/none) [1.3.0-0ubuntu1] (no packageset)
<mwhudson> argh wtf what happened to the haskell-gi-gtk builds :(
-queuebot:#ubuntu-release- New binary: libnsl [armhf] (groovy-proposed/none) [1.3.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rpcsvc-proto [ppc64el] (groovy-proposed/none) [1.4.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rpcsvc-proto [amd64] (groovy-proposed/none) [1.4.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rpcsvc-proto [s390x] (groovy-proposed/none) [1.4.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rpcsvc-proto [arm64] (groovy-proposed/universe) [1.4.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rpcsvc-proto [armhf] (groovy-proposed/universe) [1.4.2-0ubuntu1] (no packageset)
<vorlon> rbalint: and this should probably be a Breaks:? I: libnsl-dev: conflicts-with-version libc6-dev (<< 2.32)
-queuebot:#ubuntu-release- New: accepted libnsl [amd64] (groovy-proposed) [1.3.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libnsl [armhf] (groovy-proposed) [1.3.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libnsl [s390x] (groovy-proposed) [1.3.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libnsl [arm64] (groovy-proposed) [1.3.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libnsl [ppc64el] (groovy-proposed) [1.3.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: libnsl [riscv64] (groovy-proposed/universe) [1.3.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libnsl [riscv64] (groovy-proposed) [1.3.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: rpcsvc-proto [riscv64] (groovy-proposed/universe) [1.4.2-0ubuntu1] (no packageset)
<vorlon> rbalint: I think rpcsvc-proto is missing a Breaks/Replaces on libc6-dev-bin (<< 2.32), for /usr/bin/rpcgen
-queuebot:#ubuntu-release- New: accepted rpcsvc-proto [amd64] (groovy-proposed) [1.4.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted rpcsvc-proto [armhf] (groovy-proposed) [1.4.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted rpcsvc-proto [s390x] (groovy-proposed) [1.4.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted rpcsvc-proto [arm64] (groovy-proposed) [1.4.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted rpcsvc-proto [ppc64el] (groovy-proposed) [1.4.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted rpcsvc-proto [riscv64] (groovy-proposed) [1.4.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: grub2 (groovy-proposed/main) [2.04-1ubuntu29 => 2.04-1ubuntu29] (core)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (focal-proposed/main) [2.664.5 => 2.664.6] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: grub2 (groovy-proposed/main) [2.04-1ubuntu29 => 2.04-1ubuntu29] (core)
-queuebot:#ubuntu-release- Unapproved: rejected gnome-shell [source] (bionic-proposed) [3.28.4-0ubuntu18.04.4]
