#ubuntu-release 2010-10-04
<cjwatson> I'd appreciate review of choose-mirror
<cjwatson> a couple of people mentioned the missing proxy question during ISO testing
 * ScottK is totally unfamiliar with D-I, so not particularly comfortable being the reviewer.
<ara> good morning mvo
<mvo> hey ara, good morning
<mvo> hey, good morning jibel
<jibel> Good morning mvo!
<micahg> could someone please look at bug 650601 today
<ubot4> Launchpad bug 650601 in libfxscintilla (Ubuntu) "[FFe] Please update libfxscintilla to 2.11.0 (affects: 1) (heat: 8)" [Wishlist,New] https://launchpad.net/bugs/650601
<cjwatson> micahg: I can't see what practical difference this enigmail upload makes?  the merge mostly seems cosmetic
<cjwatson> micahg: is there something I missed?
<Riddell> I can't log in with today's Kubuntu CD
<Riddell> "authentication error" on linux console
<Riddell> yep, no "ubuntu" user on the ubuntu desktop ISO either
 * Riddell looks at NCommander, last uploader of casper
<cjwatson> meep
 * cjwatson rsyncs and will have a look if nobody else does
<cjwatson> ttx: likewise-open: is this Mac as in OS X, or Mac as in powerpc, or something else?
 * NCommander hides out of site from Riddell's gaze.
<cjwatson> (also I suspect that the autoconf error you're hitting might just be because the AC_CHECK_MEMBERS arguments were line-wrapped ...)
<NCommander> Riddell: can you get the casper log and such? the patch I cooked should only fire on UNE + ARM, if it broke Kubuntu, then I made a typo somewhere
<cjwatson> not seeing an obvious reason why recent changes would have affected ubuntu user creation in any way
<ttx> cjwatson: that would be Mac as in OSX. I tried without the linewrap... and it still failed, same error
<cjwatson> ok - would have approved but I see somebody already did ;-)
<ttx> cjwatson: ok, thanks
<ttx> cjwatson: I wonder if that's the "->" in the aggregate that it doesn't like.
<ttx> cjwatson: and.. it used to work.
<cjwatson> Riddell: user-setup bug actually
<cjwatson> ogra: do check whether your changes are actually valid shell :-(
<cjwatson> (I should have checked too when accepting it)
<cjwatson> Riddell: please review user-setup 1.28ubuntu10 when it lands
<Riddell> ok
<cjwatson> ttx: should bug 600174 be on the server-mrs list?
<ubot4> Launchpad bug 600174 in axis2c (Ubuntu Maverick) (and 1 other project) "axis2c fails to build from source in linaro (affects: 3) (dups: 1) (heat: 20)" [High,New] https://launchpad.net/bugs/600174
 * ttx looks
<ttx> cjwatson: hrm, looks a bit flaky. Yes, should be on our list, will add.
<cjwatson> thanks
<ogra_ac> cjwatson, whats wrong ?
 * ogra_ac checks the branch
<Riddell> missing bracket
<ogra_ac> argh
<ogra_ac> sorry sorry sorry
<ScottK> Is oneconf supposed to be in Universe?
<cjwatson> ScottK: nothing depends on it and it's not seeded ...
<ScottK> cjwatson: OK.  It seemed odd to see Ubuntu One stuff in Universe.
<seb128> it's not ubuntuone
<cjwatson> I guess it's experimental maybe?
<ScottK> seb128: Oh.  OK.
<seb128> it's didrocks' project
<seb128> it didn't get promoted this cycle because desktopcouch is not reliable enough
<seb128> we couldn't get it tested
<ScottK> I see.
<seb128> btw when do you think you will start rolling images for the release?
<didrocks> even if it's in universe and we can't get a lot of testing due to desktopcouch working for not enough people, I try to get it in shape :)
<seb128> we got a few packages that didn't get rebuild with recent rosetta exports
<seb128> ie xdg-user-dirs
<seb128> or shared-mime-info
<ScottK> In that case, accepted.
<seb128> dpm just pointed that today
<seb128> is there still a slot to get such updates?
<didrocks> ScottK: thanks
<ScottK> You're welcome.
<didrocks> ScottK: I'll certainly have a new Quickly bug-fix release later or tomorrow btw
<ScottK> OK.
<ScottK> Universe stuff tomorrow is fine.
<Laney> I want to sync a haskell library and do some rebuilds against it
<Laney> is there still time?
<ScottK> Laney: If it's important and doesn't touch anything that's seeded, yes.
<Laney> it's important enough, yes
 * Laney does
<ScottK> Haskell isn't seeded anywhere is it?
<Laney> no
<ScottK> Should be fine then.
<Laney> shall I wait for a normal sync or upload it myself?
<ScottK> How about file a sync bug.
<ScottK> Let me see what I can do with it.
<Laney> right, that was the question
<Laney> Need to wait for dinstall+mirror push then
<ScottK> Ping me when it's done.
<Laney> k
<ScottK> Oh, in that case, go ahead and upload it.
<cjwatson> if you give me an upload signed by a key in the Debian keyring, I can sync it
<Laney> cjwatson: It's on incoming
<ScottK> Ohhh.  Even better.
<cjwatson> or point to it on incoming.d.o
 * Laney fishes out the dsc
<Laney> (haskell-gtk)
<Laney> http://incoming.debian.org/haskell-gtk_0.11.0-5.dsc
<cjwatson> right, I can sync that, give me a minute to check sigs and such
<Laney> sure, thanks
<didrocks> ev: cjwatson: I guess today's iso showing a gdm prompt when clicking on "try ubuntu" either on ubiquity session or from syslinux is known? (seems like there is no ubuntu user in the system but I can get no tty)
<cjwatson> didrocks: yes, known and fixed
<didrocks> cjwatson: great, I'm tracking another bug, it seems the keymap (at least the French one: azerty keyboard) is not taken into account when you use syslinux to choose "try ubuntu" or "install ubuntu" instead of the ubiquity session
<didrocks> but as I can't test today's iso, it will have to wait for deeper testing I guess :)
<cjwatson> Laney: synced
<Laney> cjwatson: thanks muchly
<Laney> hopefully my graphs will go duly red and i won't have to think
<ScottK> cjwatson: Would you please throw http://paste.debian.net/93211/ and mass-sync.py?  That takes care of all the pending sync requests for ~ubuntu-archive.
<cjwatson> ScottK: doesn't the third line need to be -S experimental?
 * ScottK looks
<ScottK> cjwatson: Yes.  Sorry about that.
<cjwatson> ScottK: the last line seems problematic because experimental currently has rygel 0.8.0-1
<cjwatson> (BTW, sync-helper.py is useful for this kind of stuff, if you haven't seen it)
<ScottK> cjwatson: I know it's not exactly what was ack'ed, but it's also development snapshot to stable release, so I thought it best to go ahead.
<ScottK> I have not, I'll try it.
<cjwatson> ok.  similarly gupnp-vala is .12 rather than .11, is that ok?
<ScottK> cjwatson: Let's give that one a pass for now.  I'll look into it.
<cjwatson> ok, skipping that
<cjwatson> # Binaries are produced by TI, and the rpath cannot be rationally adjusted.
<cjwatson> rsalveti: ^- do you know about the chrpath package?
<cjwatson> rsalveti: I assume this is also related to why you have those awful libXau.so.0 and libXdmcp.so.0 symlinks?
<cjwatson> rsalveti: binaries on their way into the archive now ...
<rsalveti> cjwatson: yeah, ugly binaries and links
<rsalveti> missing soname, not that nice
<rsalveti> cjwatson: cool, thank you very much!
<cjwatson> ScottK: done
<ScottK> cjwatson: Thanks.
<didrocks> cjwatson: it seems that I found the bug about keyboard layout not beeing taken into account, but I would prefer you to have a look first: bug #651046
<ubot4> Launchpad bug 651046 in casper (Ubuntu) "[maverick] wrong keyboard layout in live or ubiquity session (affects: 2) (heat: 10)" [Critical,Triaged] https://launchpad.net/bugs/651046
<cjwatson> didrocks: dup of bug 594162 then
<ubot4> Launchpad bug 594162 in busybox (Ubuntu Maverick) (and 1 other project) "segmentation fault while downloading preseed file (affects: 1) (heat: 12)" [High,Triaged] https://launchpad.net/bugs/594162
<cjwatson> didrocks: please don't work around it
<cjwatson> cyphermox said he was going to test my busybox fix
<didrocks> cjwatson: oh good then. please disapprove it then
<didrocks> I'll dup it too
<cjwatson> disapprove?
<cjwatson> it's not nominated or anything
<cjwatson> oh, the branch
<cjwatson> didrocks: if you want to test busybox-initramfs from my PPA, that would be good too
<didrocks> cjwatson: ok, doing it then :)
<didrocks> cjwatson: seems to work for me :-) nice!
<cyphermox> sweet.
<chrisccoulson> what's the absolute cut-off date for fixes to seeded packages? (ie, should i be preparing them as a SRU now)?
<chrisccoulson> i want to get bug 646076 fixed really
<ubot4> Launchpad bug 646076 in gnome-control-center (Ubuntu) "gnome-display-properties: cannot save systemwide resolution (affects: 11) (dups: 1) (heat: 50)" [Low,Triaged] https://launchpad.net/bugs/646076
<seb128> it's a one liner to create a directory on disk
<seb128> one liner in the debian directory
<cjwatson> I think absolute cut-off is still a day or two away
<seb128> ok
<seb128> chrisccoulson, I guess upload now then ;-)
<chrisccoulson> excellent, thanks
<doko> cjwatson, ScottK: ok to go on with bug #654613 ?
<ubot4> Launchpad bug 654613 in multisync0.90 (Ubuntu) (and 10 other projects) "remove packages needing opensync (<< 0.30) in maverick (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/654613
 * ScottK looks at cjwatson.
<ScottK> There are quite a few removal bugs pending for ~ubuntu-archive.
<doko> I'm currently only working on NBS
<cjwatson> doko: did the Debian maintainer know how much of the opensync system this was going to take out?  how much of opensync is left?
<doko> cjwatson: well, it's basically removing all of it. the alternative, afaiu, would be to revert to opensync (<< 0.30)
<cjwatson> is there any way we can reserve the option of putting it back in in an SRU?  people do actually use opensync
<cjwatson> (was the conversation with the Debian maintainer somewhere public?)
<doko> no, azeem pinged me on Friday an a private channel
<cjwatson> I'm worried about the results but don't see what else we can do really
<cjwatson> I do think we should restore it in an SRU if at all possible
<cjwatson> the bug needs some better discussion of the problem and why this is the only option - people are going to find it while wondering what happened to opensync
<micahg> cjwatson: all the enigmail merge does is decrease the diff with Debian
<cjwatson> micahg: somebody seems to have accepted it, but from now to release, please save such things for natty
<Daviey> Regarding mythexport.... it's a universe package, which fixes the package (current one is unusable).. the thing that makes the diff look larger is removals of hunks of commented code.. which i guess he could/should have left that - but he has worked hard on that, and so I sponsored it to give him the best chance of getting it in.  I told him that you may reject it :)
<micahg> cjwatson: Sorry, I thought since it was unseeded, that was a safe merge
<Daviey> Would the release team be able to comment on bug #654657 please? :)
<ubot4> Launchpad bug 654657 in python-django-openid-auth (Ubuntu) (and 1 other project) "Duplicate package (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/654657
<Daviey> (not urgent)
<ScottK> Daviey: Commented
<Daviey> ScottK: thanks
<Daviey> ScottK: I've realised that i foolishly uploaded mythexport (currently in unapproved) with .bzr bundled... Would you mind nuking it, so i can reupload?
<ScottK> Sure thing.
<ScottK> Daviey: Rejected.
<Daviey> \o/, thanks
<NCommander> cjwatson Riddell: was the casper not properly creating a user bug filed/fixed already?
 * NCommander isn't seeing anything in th ebackscroll and got bit by this bug now :-/
<cjwatson> yes, fixed in user-setup 1.28ubuntu10
<cjwatson> do you need an updated build of something on cdimage?
<cjwatson> I've rebuilt a few things but not the full set
<NCommander> cjwatson: armel+dove needs a respin. probably also armel+omap*
<NCommander> er, actually, probably not, as omap doesn't use casper
<cjwatson> dove running
<cjwatson> does jasper use user-setup?  it wasn't a casper bug
<NCommander> cjwatson: TBH, I have no clue, and no hardware to test
<cjwatson> quick source grep suggests not
<NCommander> cjwatson: then just dove
<cjwatson> Daviey: this mythexport upload drops the change in 2.2.1-0ubuntu2, which was an installability fix
<Daviey> cjwatson: Hmm
 * Daviey looks
<cjwatson> actually, sending mail
<Daviey> cjwatson: Hmm.. dammit... i checked on a maverick box - and apt seemed to process it correctly.... just re-tried, and it didn't
<Daviey> cjwatson: Thanks for the mail... talking with John atm.
 * Daviey feels a plonker.
<cjwatson> no worries, that's what we're here for
<cjwatson> ... not for making you feel like a plonker. :-)
<Daviey> heh
<superm1> Riddell, http://launchpadlibrarian.net/56813600/casper_1.244_1.245.diff.gz causes an error on non-kde systems.  that 48kubuntu_disable_restart_notifications should be testing that it's really on a KDE image, or that the directory at least exists first
<Riddell> hmm, yes
<Riddell> let me ping the author
<Riddell> superm1: what's the affect of that error?
<fabrice_sp> Hi, I'm working with enna's upstream to try to get it fixed in Maverick. The only solution would be to sync 3 libs (one is already in Debian, 2 are waiting in mentor) plus the enna package. the only rdepends of the libs are enna. What is the probability of get a FFe acked?
<superm1> Riddell, i noticed it as an error in the casper log.  it's the last thing that casper runs, i'm unsure if it actually causes casper to exit prematurely though
<Riddell> fabrice_sp: do it quick :)
<superm1> it's hard to tell because user-setup was rather broken causing other interesting problems
<Riddell> superm1: we'll get it fixed
<fabrice_sp> Riddell, I'll try :-) Thanks
<superm1> Riddell, cool thanks.  perhaps it might make sense to move all things specific to certain flavors into packages only installed on those flavors for natty
<superm1> that's what I did for all the mythbuntu casper stuff
<ScottK> ttx: I'm inclined to approve Bug 636482 - I'd like your opinion from a server team perspective.
<ubot4> Launchpad bug 636482 in python-django (Debian) (and 1 other project) "Update python-django to 1.2.3 version to fix an XSS vulnerability (affects: 2) (dups: 1) (heat: 26)" [Unknown,Unknown] https://launchpad.net/bugs/636482
<micahg> cjwatson: Since you said I should avoid "cosmetic" merges, I wanted to ask you about mediatomb, when you granted the FFe, it was on teh condition that I merge it from Debian before release, does this still apply
<jdstrand> cjwatson: I just installed today .1 daily server in a VM and it won't reboot. I get 'Rebooting into new system... and then pop out to the installer menu. it looks like clock-setup returned '1'. is this something you are aware of?
<jdstrand> cjwatson: actually, that clock setup might be a cascading failure...
<jdstrand> I thought I remebered something about not being able to reboot, but couldn't find it...
<jdstrand> hmm.. yes, that wouldn't be the cause. it looks like the silesystems got unmounted but it just didn't reboot
 * Daviey screams.
<jdstrand> Daviey: are you screaming at me?
<Daviey> jdstrand: no, generally :)
<jdstrand> heh
<jdstrand> Daviey: was it in reaction to my comments, or unrelated?
<Daviey> jdstrand: Addition to :)... things were looking so lovely a few days ago :)
 * jdstrand tries to find the installer magic he knew 6 months ago to debug this
<cjwatson> micahg: that wasn't what I meant - I simply meant that I didn't want orig.tar files to get out of sync with Debian, and that the packaging should be vaguely congruent, etc.
<cjwatson> jdstrand: give me a few minutes and I can help.  toddler-wrangling just now
<jdstrand> oh, duh-- 'save debug logs'
<jdstrand> ok, there are some rtc not found messages
<jdstrand> but ultimately clock-setup claims to have been successful
<jdstrand> some umount errors about Device or resource busy, and can't open /proc/mounts
<jdstrand> but then: Oct  4 21:32:48 init: The system is going down NOW!
<cjwatson> can I see the full syslog?
<jdstrand> yes
<jdstrand> /home/jamie/syslog on chinstrap
<jdstrand> cjwatson: ^
<cjwatson> hmm.
<cjwatson> nothing to do with clock-setup.  it worked fine the first time.
<jdstrand> cjwatson: I have an appt in 20 minutes, but have put all the logs in /home/jamie/server-installer-wont-reboot-logs.tar.gz on chinstrap
<cjwatson> Oct  4 21:32:48 finish-install: umount: can't umount /dev/pts: Device or resource busy
<cjwatson> that's the first point things seem to go particularly badly wrong
<jdstrand> cjwatson: I'm here until then though
<cjwatson> though not 100% sure
<cjwatson> can I set up a reproduction case for this?  server install in kvm?  anything particular?
<cjwatson> the stuff most directly relevant here hasn't changed recently
<jdstrand> cjwatson: http://paste.ubuntu.com/506029/
<jdstrand> cjwatson: it isn't anything special, though I did use virt-install
<jdstrand> cjwatson: the paste has the ps auxww output for virt-install and the full kvm line
<cjwatson> I never use the libvirt stuff for installer testing, it's such a pain for testing the installer as opposed to deploying a target system
<jdstrand> being a libvirt maintainer in Ubuntu, I tend to use it :)
<jdstrand> but, the kvm line is there
<cjwatson> guess I'll just try virtio disks and hope that the rest doesn't matter much
<jdstrand> 768 ram, I do see '-rtc base=utc', ... raw disk image, ...
<cjwatson> rtc won't matter
<jdstrand> I would be surprised if the other stuff made a difference
<jdstrand> but yeah virtio
<cjwatson> what partitioning?
<jdstrand> cjwatson: default lvm
<cjwatson> ok
<jdstrand> cjwatson: all installation defaults-- hit Ok everywhere
<jdstrand> cjwatson: this did work the middle of last week
<jdstrand> (virt-install and all)
<cjwatson> it's bizarre, init thinks it's trying to shut down at least ...
<cjwatson> can you reproduce it on a second run?  there's probably not much interesting evidence left
<cjwatson> my test is running
<jdstrand> cjwatson: sure, but it will have to be later. I gotta go in 5
 * cjwatson nods
<jdstrand> k, heading out. I'll try to kick it off later tonight (probably ~5 hours). otherwise first thing in the morning
<cjwatson> this always turns out to be wrong when I say it, but it feels like cosmic rays
<micahg> cjwatson: oh, sorry, so I should then wait to merge until natty, I have a regression from Lucid that I wanted to fix as well (lacking javascript that ScottK said I could go ahead and do)
<jdstrand> cjwatson: well, I'll try it a few times and see if I can reproduce and get back to you. thanks for looking at it
 * jdstrand really leaves
<cjwatson> micahg: fixing regressions is fine, but please keep the diffs minimal
<micahg> cjwatson: ok, I'll save the merge for Natty then, thanks
<cjwatson> we're getting to the point of having quite limited buildd and reviewer time remaining
<micahg> could someone please look at bug 650601
<ubot4> Launchpad bug 650601 in libfxscintilla (Ubuntu) "[FFe] Please update libfxscintilla to 2.11.0 (affects: 1) (heat: 8)" [Wishlist,New] https://launchpad.net/bugs/650601
<cjwatson> jdstrand: would help if you'd said which tasks you were installing :-/
<cjwatson> it's possible that might matter
<cjwatson> might be possible to decipher it from the logs
<cjwatson> jdstrand: reboots fine here.  please let me know which tasks you're using and I'll try with that
#ubuntu-release 2010-10-05
<cjwatson> Daviey: accepted mythexport.  you may have to close a bunch of bugs manually as I just noticed John used the wrong format in the changelog.  I don't want to make him go around again just for that.
<nhandler> Didn't someone make a script that lets you pass it a list of bug numbers and it takes care of closing them?
<Daviey> cjwatson: Doh.. not having a good day here.  Thanks for that.
<cjwatson> nhandler: I did a one-off when the auto-closing system was broken
<cjwatson> http://paste.ubuntu.com/506066/ - but NOT SUITABLE for running as-is, it doesn't take bug numbers on the command line but fishes them out of the publication records
<cjwatson> it's probably not worth it for a handful of bugs
<Daviey> done
 * Daviey lets John know
<ScottK> ^^^ appears to be the one that robbiew already said no to in an FFe.
<ScottK> I don't see any new bugs, or approvals, so rejecting.
<jdstrand> cjwatson: oh, I forgot to mention the tasks. I installed all tasks. it's a server install, not a UEC install, with all tasks selected
<jdstrand> cjwatson: I'm going to try it now
<ScottK> Arrrgh!!!
<ScottK> I swear I clicked reject, but it's in.  https://launchpad.net/ubuntu/+source/ubuntu-font-family-sources/0.69+ufl-0ubuntu1
<ScottK> Unless someone else accepted it ....
<ScottK> Urgh.
 * ScottK goes to bed.
<jdstrand> cjwatson: well, it worked this time. I'll try a few more times in the morning. I think for now forget about it unless I can reproduce
<cjwatson> casper> commented on bug
<dpm> hi everyone, I realise it's getting late, but I prefer asking in any case:
<dpm> While testing the final maverick language packs, I've noticed that the gnome-language-selector translations are missing (bug 654548). Would it be possible to do a new upload of language-selector including an export of LP translations and bypassing pkgbinarymangler's translation-stripping part? It would be a workaround, but this way we'd have a translated language-selector without the need of new language packs.
<ubot4> Launchpad bug 654548 in ubuntu-translations "Language selector translation is missing from the final Maverick language packs (affects: 2) (heat: 12)" [High,Triaged] https://launchpad.net/bugs/654548
<doko> cjwatson: re-uploaded ffmpeg yesterday. did see that packages like libmesh do fail to build with the current ffmpeg version in maverick. so there is a chance that the packages which we did remove may come back in time for maverick
<doko> about opensync: there are already a few plugins built with the new opensync version, so not sure about the best way ...
<doko> for audacious, I'd like to remove the plugins which fail to build unless I hear back from bdrung
<cjwatson> doko: I was hoping to get a straight answer from siretart on whether it was OK, but he seems to still be labouring under the misapprehension that we're actually using powerpc
<cjwatson> so I've just accepted it
<doko> ok, thanks
<cjwatson> dpm: language-selector is already blacklisted in pkgbinarymangler, so it ought to include its own translations and this is not a workaround
<cjwatson> dpm: since language-selector is part of the toolchain that installs language packs ...
<cjwatson> it already seems to include quite a few translations
<mgunes> cjwatson: is the premature downloading of pre-published images before release a problem in the final release process the same way it is in milestones? If so, I'm inclined to post a notice on the forums until release telling people to check the release blog and/or ubuntu-announce for definitive news, since it seems to be a growing problem recently.
<dpm> cjwatson, ah, weird, I don't have any translations in /usr/share/locale for language-selector, either, but let me re-check...
<cjwatson> mgunes: yes
<cjwatson> mgunes: it inhibits our ability to get things out to mirrors
<Laney> can someone make sure the removals ~ubuntu-archive are subscribed to are done before the really final freeze?
<mgunes> cjwatson: thanks, will proceed
<dpm> cjwatson, it seems that the latest version of language-selector has translations in the source code, but it does not install them
<seb128> it does, I just did a local build
<dpm> seb128, so do you think the blacklisting perhaps is not working and they got stripped?
<seb128> $ dpkg -c language-selector-common_0.6.5_all.deb  | grep language-selector.mo  | wc -l
<seb128> 92
<seb128> on a local build
<seb128> let me check launchpad build logs
<dpm> thanks
<seb128> skaet, hey
<seb128> in London?
<skaet> hey seb,
<skaet> yup,  just arrived in the office.  :)
<seb128> is it your first time in the office?
<seb128> dpm, cjwatson: http://launchpadlibrarian.net/56391059/buildlog_ubuntu-maverick-i386.language-selector_0.6.5_FULLYBUILT.txt.gz
<skaet> seb128, yup, first time.
<seb128> "pkgstriptranslations: language-selector-common does not contain translations, skipping
<seb128> pkgstriptranslations: tarball already exists
<seb128> "
<cjwatson> looks suspiciously like it's stripping translations doesn't it
<cjwatson> wait, language-selector was unblacklisted?
<cjwatson> bug 570240
<ubot4> Launchpad bug 570240 in pkgbinarymangler (Ubuntu) "Wrong language-selector package blacklisted (affects: 1) (heat: 23)" [Low,Fix released] https://launchpad.net/bugs/570240
<cjwatson> I'm not sure I follow the reasoning for dropping it from the blacklist, TBH
<pitti> hello
<cjwatson> but, dpm, you were involved in that bug ...
<seb128> pitti, hey
<seb128> we are discussing language-selector
<seb128> should translations be stripped or not?
<seb128> right now they are stripped but not in langpacks
<cjwatson> original question:
<cjwatson> 10:18 <dpm> While testing the final maverick language packs, I've noticed that the gnome-language-selector translations are missing (bug 654548). Would it be possible to do a new upload of language-selector
<ubot4> Launchpad bug 654548 in ubuntu-translations "Language selector translation is missing from the final Maverick language packs (affects: 2) (heat: 12)" [High,Triaged] https://launchpad.net/bugs/654548
<cjwatson>             including an export of LP translations and bypassing pkgbinarymangler's translation-stripping part? It would be a workaround, but this way we'd have a translated language-selector without the need
<cjwatson>             of new language packs.
<cjwatson> I was surprised by language-selector having been dropped from the blacklist; I confess that bug 570240 doesn't make huge amounts of sense to me but maybe I need more coffee
<ubot4> Launchpad bug 570240 in pkgbinarymangler (Ubuntu) "Wrong language-selector package blacklisted (affects: 1) (heat: 23)" [Low,Fix released] https://launchpad.net/bugs/570240
<pitti> hm, why are they missing in the first place..
<seb128> that would be one of the questions for you
<seb128> I'm not sure how langpacks are built or where to check for logs
<pitti> but yes, I wouldn't mind a reupload of language-selector with translations included
<dpm> cjwatson, good catch, I didn't even remember that bug.
<pitti> seb128: I can do that
<seb128> pitti, thanks
<pitti> I need about 15 more minutes to finish my current g-s-d patch, then I can have a look at this
<cjwatson> changing language on the live CD I agree is a dodgy unlikely-to-work edge case; but including translations in l-s applies also to the installed system
<seb128> ok
<cjwatson> so I think the correct fix is to blacklist l-s, but this time do it properly
<dpm> pitti, I've requested an export, let me check if I've already got the link and I'll paste it here
<seb128>  Installed-Size: 2320
<cjwatson> what's Size?
<seb128> against
<seb128> Installed-Size: 456
<seb128> language-selector-common
<cjwatson> and which binary package is that?
<cjwatson> ok
<seb128> once translations are shipped
<seb128> the deb is 277k
<cjwatson> against Size: 58036
<cjwatson> 200K increase in compressed size doesn't seem too bad
<seb128> right
<seb128> so let's do an upload without stripping translations?
<cjwatson> shall I upload pkgbinarymangler then?
<cjwatson> or do we just want to override it in language-selector?
<seb128> I was going to just override in language-selector
<dpm> seb128, yeah, +1 on that. I don't quite understand what's happened here (why the latest langpacks don't contain the translations even if it's in fact not blacklisted), but we can try to figure out after release.
<cjwatson> they are there, they're just in the KDE language packs
<cjwatson> $ dpkg -c /home/lp_archive/ubuntu/pool/main/l/language-pack-kde-de-base/language-pack-kde-de-base_10.10+20100930_all.deb | grep language-selector
<cjwatson> -rw-r--r-- root/root     12969 2010-10-01 18:14 ./usr/share/locale-langpack/de/LC_MESSAGES/language-selector.mo
<seb128> urg
<cjwatson> bad heuristics somewhere I assume
<dpm> ah
<cjwatson> presumably because there's a language-selector-qt but the GTK version is just language-selector
<cjwatson> I suspect http://paste.ubuntu.com/506372/ would fix it, but if we're re-blacklisting anyway then who cares
<pitti> done with my previous patch, /me reads backlog
<pitti> dpm: so the rationale for unblacklisting language-selector from stripping seemed and seems reasonable to me; has this changed?
<pitti> Copying af/language-selector into package ../maverick/sources-base/language-pack-kde-af-base
<pitti> (from the log)
<pitti> cjwatson: right
<pitti> cjwatson: classificatio override committed, thanks
<pitti> I think we should only blacklist it once for this maverick upload
<pitti> but in general keep it stripped
<seb128> pitti, should we just "export NO_PKG_MANGLE=1" in the l-s rules?
<dpm> pitti, the rationale hasn't changed, as far as I'm aware, although I'm getting a bit lost with all the blacklisting
<pitti> the next langpack update will fix that then
<cjwatson> pitti: the rationale in the bug report for unblacklisting language-selector only considered the live CD case
<pitti> seb128: yes
<cjwatson> pitti: it didn't, as far as I can tell, consider the case of an installed system where the desired language just isn't installed yet
<ScottK> FYI, I'll be off IRC for the next 13 - 15 hours, so don't wait on me for anything ....
<pitti> cjwatson: I thought the rationale was that you'd at least see it in a language you can understand -- after all, it's your desktop language
<cjwatson> that's not the rationale given in bug 570240
<ubot4> Launchpad bug 570240 in pkgbinarymangler (Ubuntu) "Wrong language-selector package blacklisted (affects: 1) (heat: 23)" [Low,Fix released] https://launchpad.net/bugs/570240
<cjwatson> and there are several situations where the desktop language might be English for one reason or another - not on CD and no network access during installation, for instance
<cjwatson> in which case the OS installer would have been localised, but now you're dropped into a desktop you don't understand, so I think some guidance in language-selector would not be inappropriate
<cjwatson> I thought it was a simple rule - anything needed to install language packs should be blacklisted.  no?
<pitti> I don't think we ever spelt it out clearly, but it makes sense for the corner case above
<seb128> cjwatson, could you review the g-s-d upload pitti just did once it hit the queue?
<seb128> it's the fix for bug #640807
<ubot4> Launchpad bug 640807 in gnome-settings-daemon (Ubuntu Maverick) (and 2 other projects) "automatic xrandr module misconfigures monitors (affects: 13) (dups: 3) (heat: 54)" [High,Fix committed] https://launchpad.net/bugs/640807
<pitti> will still take some 15 minutes until the debdiff appears, though
<seb128> it's basically going back to the behaviour we had before GNOME 2.32
<pitti> the change was introduced very late (after FF), in 31.91
<cjwatson> seb128,pitti: looks reasonable to me.  the only concern I have is future migration.  will we make sure to migrate gconf configuration for this locally-introduced key, even if upstream uses a different name in future?
<seb128> cjwatson, we will switch to gsettings next cycle
<pitti> cjwatson: that's indeed a concern; however, fortunately they will migrate to gsettings soon anyway
<seb128> so upstream will not go for a gconf key
<pitti> cjwatson: so if they change the name, we'd only need to change the key name in the migration code
<seb128> and gconf -> to gsettings is dropping one line in a file
<dpm> cjwatson, pitti, seb128: thanks a lot for looking into the l-s translations issue
<seb128> so migration will be easy
<pitti> right
<cjwatson> hm, ok
<seb128> brb
<pitti> dpm: so, want me to wait on your export, so that I can update the translations in the package?
<dpm> pitti, whatever suits you best. I've just got the export link: http://launchpadlibrarian.net/57123174/launchpad-export.tar.gz If you could include those translations, that would be great. If those are too big a change at this point, just including the existing translations in the package would be a big improvement already
<pitti> dpm: I don't see why we shouldn't include them; the current po files in the package weren't tested any more (i. e. not at all) than the ones in the langpacsk
<pitti> i. e. the launchpad ones were at least tested in KDE
<pitti> or from folks with the KDE langpacks installed
<dpm> pitti, +1. They were also tested by ubuntu folks, as the transition to the kde langpack seemed to happen recently (I just noticed it when I reported the bug, before it was translated in Ubuntu)
<dpm> or at least that was my impression
<pitti> ok, works fine in German; I installed pkgbinarymangler, and -common has the po files now; both the menu entry and the app itself are in German now
<dpm> cool
<pitti> uploaded
<doko> cjwatson: we really need a list of sources which are not yet build in a distribution ...
<doko> built even
<doko> just found eigenbase-resgen and mondrian
<wgrant> doko: You mean things that haven't been rebuilt in maverick, or something else?
<ttx> ScottK: looking...
<cjwatson> doko: http://people.canonical.com/~ubuntu-archive/testing/maverick_outdate_all.txt
<cjwatson> oh, that's only out of date, not never built at all
<cjwatson> feel free to extend lp:ubuntu-archive-reporting :-)
<doko> heh
<cjwatson> actually it's lp:~maxb/+junk/ubuntu-archive-reporting isn't it ...
<maxb> heh
<maxb> shall we move that?
<cjwatson> as you like ...
<cjwatson> we have a minor branch deployed anyway
<cjwatson> (path, arch, suite changes)
<doko> maxb: do you volunteer to extend it?
<maxb> uh, possibly :-)  I might need to remind myself how feasible what you suggest is in the current code first
<ttx> ScottK: looks reasonable to me.
<ttx> ScottK: though we could (should) filter out the non-security changes, they seem quite harmless.
<Riddell> ttx: ScottK is away today
<ttx> Riddell: ok -- I was just answering a question he had about bug 636482
<ubot4> Launchpad bug 636482 in python-django (Debian) (and 1 other project) "Update python-django to 1.2.3 version to fix an XSS vulnerability (affects: 2) (dups: 1) (heat: 26)" [Unknown,Unknown] https://launchpad.net/bugs/636482
<bdrung> doko: sorry, i don't have time to work on these. a quick look showed that we are using old versions or the upstream changes don't improve the build failure
<cjwatson> could somebody please review lupin?
<doko> looking
<cjwatson> doko: thanks
<doko> bdrung: ok, then I'll remove audacious-dumb and audacious-dumb and disable the plugins for imms, upse and xmp
<doko> cjwatson: ^^^ ?
<cjwatson> seems like the best option at this point to get rid of the last NBS other than opensync
<doko> what do you think about opensync?
<cjwatson> I commented on that yesterday
<cjwatson> 16:55 <cjwatson> I'm worried about the results but don't see what else we can do really
<cjwatson> 16:55 <cjwatson> I do think we should restore it in an SRU if at all possible
<cjwatson> 16:57 <cjwatson> the bug needs some better discussion of the problem and why this is the only option - people are going to find it while wondering what happened to opensync
<cjwatson> for the audacious stuff - please only remove binaries
<cjwatson> no need to remove sources if there are no build-deps involved in NBS
<doko> yes
<doko> updated the opensync bug report today:
<doko> the alternative would be to downgrade to opensync to (< 0.30), and then rebuild/downgrade the following packages too:
<doko> osynctool
<doko> libopensync-plugin-syncml
<doko> libopensync-plugin-file
<doko> libopensync-plugin-evolution2
<doko> libopensync-plugin-xmlformat
<doko> libopensync-plugin-vformat
<Riddell> does anything use opensync?  it's dead upstream as far as I know
<cjwatson> I guess if that can be done without involving an epoch (and hence breaking merges forever), it would be preferable
<cjwatson> Riddell: "dead upstream" doesn't seem compatible with "new upstream versions uploaded quite recently to Debian experimental"?
<doko> azeem will join us here in 15min ...
<doko> please review upse and xmp
<mvo> about this apt upload, it does fix the test case in the changelog (postfix failing to instal if exim is already installed). I did exsessive tests on it and created lp:~mvo/+junk/apt-resolver-regression-tests  to ensure it does nothing bad (plus inspected the code of course), so it should be fine. if you prefer it as a SRU that is fine for me as well
<lamont> mvo: what was the issue?  (as in should postfix do something differently?)
<ttx> Riddell, cjwatson: do we have a tentative schedule for the final ISO generation yet ?
<ttx> (I mean, the first candidates for final)
<mvo> lamont: postfix is fine, apt is having a issue in maverick
<mvo> lamont: its just a convinient test-case
<lamont> ah, ok
 * lamont unstresses
<mvo> lamont: no worries (and yeah, release week is fun, isn't it?)
<lamont> heh
<lamont> you keep using that word....
<cjwatson> ttx: not before tomorrow
<ttx> cjwatson: ok, thanks !
<doko> hi azeem_
<doko> what do you suggest for the opensync mess?
<azeem_> gah, network is really slow here
<azeem_> doko: ok, so the file and evolution plugins are the ones which should get reverted I guess, and the syncml one dropped
<doko> azeem_: and opensync reverted too? which version number should be used?
<doko> epoch, or fake version
<cjwatson> please not an epoch
<cjwatson> unless Debian uses one too I suppose
<azeem_> my preference would be uploading 0.22-4squeeze1 to t-p-u after coordination with the Debian release team, and then merge a fake version to maverick from there
<azeem_> if that is possible
<cjwatson> we're not likely to have time to wait for t-p-u
<cjwatson> the absolute hard deadline for unseeded packages in universe/multiverse is tomorrow noon UTC
<cjwatson> actually no
<cjwatson> sorry, noon UTC on Oct 9
<cjwatson> so I suppose we can wait a day or two for t-p-u review
<azeem_> packages against testing are at http://people.debian.org/~mbanck/opensync-squeeze
<azeem_> I didn't have much time last night to test them as well though, will do now after checking what else is missing
<doko> wgrant: no, packages which are not built at all (and are not built because the build dependencies are missing). these show not up on ubuntuwire.com/ftbfs
<micahg> could a member of the release team please look at bug 650601?
<ubot4> Launchpad bug 650601 in libfxscintilla (Ubuntu) "[FFe] Please update libfxscintilla to 2.11.0 (affects: 1) (heat: 8)" [Wishlist,New] https://launchpad.net/bugs/650601
<cjwatson> doko: seems to be a lot of cruft in the debdiff of upse from what's in the archive - is it necessary?
<doko> looking ...
<azeem_> cjwatson, doko: ok, I asked for tester feedback on opensync-users and debian-user
<doko> cjwatson: re-uploaded with the same version number
<doko> azeem_: thanks
<jdstrand> cjwatson: I'm not keen on cosmic rays. I've tested 4 more installs without incident
<jdstrand> so I'm forgetting about it now too
<doko> rejected my first upse upload
<cjwatson> jdstrand: duly forgotten
<Daviey> jdstrand: I tried to reproduce it last night in KVM... and couldn't
<Daviey> Hi... been looking at Bug #600174 ... The axis2c code seems really buggy (valgrind), and now the FTBFS seems to have happened because of tool chain changes.  Disabling the test suite produces binary packages... Looking for advice from the RT with what to do.
<ubot4> Launchpad bug 600174 in axis2c (Ubuntu Maverick) (and 1 other project) "axis2c fails to build from source on maverick/i386 (affects: 3) (dups: 1) (heat: 22)" [High,Confirmed] https://launchpad.net/bugs/600174
<Daviey> there is an i386 package currently in maverick.... which is good...
<Daviey> .. but if a security update is needed... it's going to need work
<Daviey> (or disabling the test suite)
<Daviey> Should we just leave it in FTBFS for now?
<doko> Daviey: does it build with gcc-4.5? it's in main too, so could be an alternative. didn't check myself
<Daviey> doko: Ah.. good point
<doko> Daviey: also trying with -O0/-O1
<Daviey> doko: I will try that... but i really wanted to establish if it's worth my time working on it at the moment... rebuilding so close to release scares the crap out of me :)
<doko> Daviey: well, target it for maverick-updates and work later on it?
<Daviey> doko: Yeah... that takes the pressure off slightly :)
<cjwatson> hm, dmraid installations not so happy, grub installed to wrong place
<cjwatson> and there's only been a bug open about this for six months or so ...
<cjwatson> buggeration.
<\sh> ScottK: ping
<\sh> ScottK: for universe and bugfix releases (native package which results in a new version) do we need to file a FFe or just follow "Feature Freeze for bugfix only updates" ?
<doko> ScottK is offline for a some hours
<doko> cjwatson: please could you review the reuploaded upse?
<Laney> \sh: no special freeze ATM AFAIK
<doko> heh, he didn't like it
<\sh> Laney: k..thx
<azeem_> doko: I guess the google-calendar plugin needs to be dropped as well, as per LP#244877
<doko> azeem_: could you document this in bug #654613 ?
<ubot4> Launchpad bug 654613 in multisync0.90 (Ubuntu) (and 10 other projects) "remove packages needing opensync (<< 0.30) in maverick (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/654613
<mvo> the aptdaemon upload I just did is not a OMG-this-needs-to-be-in-NOW upload, we can also do it as a SRU on the first day. it collected a bunch of dupes, this is why I uploaded it
<mvo> (now)
<azeem_> doko: gah, it's still http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg503765.html
<azeem_> I've no idea (i) how I came up with that patch (ii) why I thought that patch/upload fixed it
<azeem_> but applying it to /usr/share/pyshared/Ft/Xml/XPath/ParsedAxisSpecifier.py fixes it
<cjwatson> doko: your binutils-avr upload also removed bug-lpm.c and bug-lpm.o.  was that intentional?
<doko> yes
<cjwatson> ok
<doko> maybe I should have left it there to keep the diff minimal
<cjwatson> *shrug* accepted anyway
<doko> cjwatson: enblend-enfuse is the last one for today. and I assume that there's enough buildd power to build gcc-snapshot
<cjwatson> I'm not entirely sure about that assumption
<cjwatson> is it vital we have a new snapshot?
<doko> no
<doko> fixes the build failure on powerpc
<cjwatson> oh, hm, didn't realise it was failing
<cjwatson> it takes over two days on armel
<cjwatson> I guess it has to be now or not at all ...
<cjwatson> could somebody review initramfs-tools?
<doko> done
<cjwatson> thanks!
<cjwatson> oh, urghurgh, queuebot fell over
<cjwatson> no longer running on my home machine, so should have a better chance of staying up
<doko> interesting, removed the auacious-dev b-d, now ftbfs with missing zlib header ...
<cjwatson> hm, spewing lots of stderr, but I guess I can ignore that for now
<doko> the enblend-enfuse upload fixes the ftbfs on armel, didn't mention it in the changelog
<doko> I don't why we need armel->avr and armel->z80 cross toolchains ...
<micahg> I still have 2 FFe bugs that need to be looked at for universe (bug 631221 and bug 650601)
<ubot4> Launchpad bug 631221 in calendarserver (Ubuntu Maverick) (and 1 other project) "FFe: Sync calendarserver 2.4.dfsg-2 (universe) from Debian unstable (main) (affects: 10) (dups: 2) (heat: 181)" [Wishlist,Fix released] https://launchpad.net/bugs/631221
<ubot4> Launchpad bug 650601 in libfxscintilla (Ubuntu) "[FFe] Please update libfxscintilla to 2.11.0 (affects: 1) (heat: 8)" [Wishlist,New] https://launchpad.net/bugs/650601
<micahg> oops
<micahg> sorry, that first one is wrong, should be bug 651514
<ubot4> Launchpad bug 651514 in tortoisehg (Ubuntu) "FFe: Sync tortoisehg 1.1.1-1 (universe) from Debian unstable (main) (affects: 5) (dups: 2) (heat: 34)" [Medium,New] https://launchpad.net/bugs/651514
<ogra> someone of the release team please let the x-loader-omap4 package through, it add the missing support for the final omap4 hardware revision, it was tested heavily by ubuntu and TI engineers on that HW
<ogra> skaet, i need an official ok for that package i guess
<ogra> (the one above my last line)
<cjwatson> ogra: done
<ogra> cjwatson, thanks a lot
<cjwatson> micahg: tortoisehg granted (and sync-helper running), will read through libfxscintilla later
<micahg> cjwatson: awesome thanks
<cjwatson> micahg: libfxscintilla approved
<cjwatson> I'd appreciate somebody looking over grub-installer and debian-installer, if anyone has a moment
<micahg> cjwatson: k, I'll finish the update tonight and find someone to upload, thanks
<cjwatson> Riddell: I don't hugely care since it's just a debug message, but this chunk http://paste.ubuntu.com/506842/ in the pulseaudio diff looks wrong - the else will bind to the inner if, not the outer one
<cjwatson> Riddell: at the very least it's wrongly indented.  might want to let Colin Guthrie know
<cjwatson> Riddell: is there a bug associated with this pulseaudio upload, or a mailing list reason or something?
<Riddell> mm, that's why I always use curly brackets with if statements
<Riddell> cjwatson: http://permalink.gmane.org/gmane.comp.audio.pulseaudio.scm/2725 is the main reference I was given
<Riddell> I was hoping crimsun would give me his opinion but he's been silent
<Riddell> I can file a bug and get Colin Guthrie to explain his reasoning if you want
<cjwatson> well, they all look reasonable enough from the patch descriptions, I'm just wondering about the tradeoff for putting it into maverick at this late point vs. an SRU
<cjwatson> I don't know enough about pulseaudio to evaluate how serious any of those things are
<cjwatson> happy to accept if they are serious
<Riddell> I don't think it matters much either way
<cjwatson> Riddell: well, if you can manage to track down crimsun by tomorrow morning, or otherwise find an explanation of seriousness, I'm happy to let it in
<cjwatson> pulseaudio just makes me nervous :)
<cjwatson> done with reviewing for tonight, early start tomorrow to get to London
#ubuntu-release 2010-10-06
<slangasek> huh, why are all the ubuntu seeds branches using branch format 6
<slangasek> this is perhaps not something I should change the week of release ;)
<micahg> slangasek: maybe so hardy people can work with them
<slangasek> micahg: that would be silly :)
<Riddell> cjwatson: upstream pulseaudio comments on the patches https://bugs.edge.launchpad.net/ubuntu/+source/pulseaudio/+bug/655409
<ubot4> Launchpad bug 655409 in pulseaudio (Ubuntu) "KDE related updates to pulseaudio (affects: 1) (heat: 6)" [Undecided,New]
<ScottK> I've been away, so I don't know where we are wrt respins and such, but if we can get bug 636482 without causing a server respin, I think we should.
<ubot4> Launchpad bug 636482 in python-django (Debian) (and 1 other project) "Update python-django to 1.2.3 version to fix an XSS vulnerability (affects: 2) (dups: 1) (heat: 26)" [Unknown,Unknown] https://launchpad.net/bugs/636482
<ScottK> slangasek: ^^^ - Thoughts?
<cjwatson> ScottK: no respins yet
<cjwatson> (as in uploads won't trigger them)
<ScottK> cjwatson: I'd say we should go ahead and sync python-django then.
<ScottK> It'll save a USN after release and it's been tested/reviewed.
<ScottK> BTW, I'll be ~offline again tomorrow (your today, I presume) as I was the previous one.
<cjwatson> ok
<cjwatson> ScottK: according to comment 10 it can't be synced yet though
 * ScottK looks
<cjwatson> may be better off with somebody sponsoring kklimonda's package
<cjwatson> (or rebasing it on 1.2.3-1)
<ScottK> I marked in the bug.
<micahg> cjwatson: are you around?
<doko_> cjwatson, azeem_: looks like Riddell didn't see the opensync discussion here, and did go forward to remove the unbuildable packages
<ara> morning all!
<slangasek> ScottK: python-django> doesn't appear to impact the server, so looks ok from here
<SpamapS> are we spinning isos yet? I just figured out bug 653362 .. simple fix .. hopefully ready for a sponsored upload before iso's start
<ubot4> Launchpad bug 653362 in dovecot (Ubuntu Maverick) (and 1 other project) "package mail-stack-delivery 1:1.2.12-1ubuntu7 failed to install/upgrade: subprocess new pre-installation script returned error exit status 1 (affects: 3) (dups: 2) (heat: 26)" [High,In progress] https://launchpad.net/bugs/653362
<SpamapS> FYI: hopefully this can get sponsored/uploaded before the isos spin: https://code.launchpad.net/~clint-fewbar/ubuntu/maverick/dovecot/karmic2lucid2maverick-upgrade-fix/+merge/37707
<micahg> slangasek: if I already have an FFe, does a universe package have to be uploaded before noon UTC, or am I good for after that?
<slangasek> micahg: the deadline is there to ensure that packages are successfully built on all architectures before the door is closed; so you should regard the deadline as a hard one
<micahg> slangasek: k, I guess I have to wait up for a sponsor then
<micahg> cjwatson: unping
<micahg> slangasek: got a sponsor so no worries
<ara> morning seb128, robbiew
<seb128> hey ara
<cjwatson> SpamapS: I still have to fix grub ...
<robbiew> ara: morning (sorry...had window closed)
<Riddell> doko_: uh oh, they weren't ment to be removed?
<doko_> Riddell: the latest plan was to revert the opensync upgrade, not sure I do want to touch this after the removals, at least NBS is empty
<ScottK> I'd appreciate it if someone would do the sync in bug 613926
<ubot4> Launchpad bug 613926 in josm (Ubuntu) "[FFe] Sync josm 0.0.svn3514-2 (universe) from Debian sid (main) (affects: 3) (heat: 22)" [Undecided,In progress] https://launchpad.net/bugs/613926
<pitti> is there still time to do an upload of upower (trivial patch: initialize a GError, see http://cgit.freedesktop.org/upower/commit/?id=a4e099c5bff9f9fdb9067a0a6bb206d4c34745ae)
<pitti> it's causing a lot of crashes (bug 648414)
<ubot4> Launchpad bug 648414 in upower (Ubuntu Maverick) (and 2 other projects) "upowerd assert failure: *** glibc detected *** /usr/lib/upower/upowerd: double free or corruption (out): 0x00d13ec0 *** (affects: 38) (dups: 41) (heat: 338)" [High,In progress] https://launchpad.net/bugs/648414
<pitti> or should this become an SRU at this point?
<pitti> I'll upload it (works fine here, see test case in bug); please reject if it's too late, then I'll prepare an SRU
<Riddell> skaet: who is spinning CDs and when?
<Riddell> pitti: well given that nobody is spinning CDs it should be ok to accept
<Riddell> let me look
<pitti> so, we'll pre-publish on Saturday, so I guess we should have the final images tomorrow, so that we can still test them all?
<Riddell> we should start testing today in the hope of having final images
<Riddell> but we were told that would happen from london and london isn't responding
<Riddell> so shrug
<pitti> I'll reinstall my main workstation with today's desktop images, for testing and kicks
<pitti> (over lunch presumably, so in about an hour)
<pitti> Riddell: ok, I'll review some other bits in the queue, like d-i, grub-installer, and this utouch-grail thing
<pitti> Riddell: i. e. "final call for the last passengers to the HMS Maverick"
<ara> :D
<pitti> ah, utouch-grail is an SRU already
<pitti> dovecot looks fine, and nasty "fail to install" bug, accepting
<Riddell> accepted upower
<cjwatson> I think I have a fix for Marjo's critical grub2 bug
<cjwatson> well, workaround, it's not really a proper fix
<cjwatson> ev: we'll need a ubiquity upload containing grub-installer 1.55ubuntu4
<ev> cjwatson: right-o
<mvo> can we please remove secvpn from the archive? because of bug #327482 it will not even work on most ubuntu systems (all that don't have inittab)
<ubot4> Launchpad bug 327482 in secvpn (Ubuntu) "access to non-existent /etc/inittab (affects: 48) (dups: 31) (heat: 70)" [High,Confirmed] https://launchpad.net/bugs/327482
<cjwatson> ev: (won't quite be in the archive yet)
<ev> indeed
<Riddell> mvo: I can do that
<mvo> hm, looks like I disconnected, did my message "can we please remove secvpn from the archive? because of bug #327482 it will not even work on most ubuntu systems (all that don't have inittab)" made it?
<ubot4> Launchpad bug 327482 in secvpn (Ubuntu) "access to non-existent /etc/inittab (affects: 48) (dups: 31) (heat: 70)" [High,Confirmed] https://launchpad.net/bugs/327482
<cjwatson> can you subscribe ubuntu-archive to that and we'll queue it?
<cjwatson> Riddell: the reason you weren't getting a response is that we were busy looking at the last critical bug
<cjwatson> so there's no point spinning anything yet anyway
<cjwatson> I did say that I was going to be doing this on Wednesday morning ...
<Riddell> fair enough
<mvo> sure, thans
<cjwatson> grub2 uploaded
<cjwatson> fixes Marjo's machine!  might fix others, it seems quite plausible
<cjwatson> PCI bus enumeration going wrong is a very believable candidate for breaking lots of machines
<cjwatson> ev: any progress on that ubiquity upload?
<ev> cjwatson: on it now
<cjwatson> ta
 * ara hugs cjwatson for fixing grub2
<cjwatson> hopefully I haven't broken anything in the process.  I don't *think* so
<cjwatson> pitti,Riddell: could one of you please review grub2?
<cjwatson> ara,fader_: I'd appreciate wide testing of grub2 on affected machines (and non-affected machines too for regression testing, but particularly affected machines) to find out what percentage of them that fixes
<cjwatson> I can't say for sure that all of the systems on which you've had problems are suffering from the same bug.  Obviously I hope they are
<ara> cjwatson, I don't have access to any affected machine, but count me in for regression testing ;-)
 * cjwatson nods
<cjwatson> who's reviewing and can they please review grub2? :)
<Riddell> cjwatson: I'll look
<pitti> back; my install attempts failed three times, but seems to have ben bad media (squashfs errors)
<pitti> with a different usb stick, today's ubuntun daily installs without a hitch
<Riddell> cjwatson: accepted
<pitti> cjwatson: seems Riddell beat me to it
<ogra_ac> cjwatson, TI discovered a silicon temperature prob for which we have an x-loader fix and a test which runs since last evening and still have to run for about 2hm, when does the freeze kick in?
<ogra_ac> s/hm/h
<Riddell> accepting brasero too
<pitti> Riddell: I'll update the xubuntu seeds to fix the oversize
<pitti> done
<pitti> cjwatson: ^ FYI (cd check mail just came in)
<Riddell> NCommander: should we care about these problems? http://people.canonical.com/~ubuntu-archive/testing/maverick_probs.html
<doko> please review llvm-2.8
<cjwatson> ogra_ac: please upload
<cjwatson> Riddell: thanks
<cjwatson> Riddell: I don't think those should be major, apart from maybe openjdk (which I thought doko had fixed?)
<cjwatson> we don't care about kvm virt usb-creator on armel AFAIK
<doko> no, openjdk is by intent. the old version on armel, the new version on the other archs
<doko> well, openjdk-6-source is a real problem, but openjdk-6-jdk only suggests it
<doko> as long as eclipse doesn't build on armel ...
<cjwatson> Evan reckons that we should try to fix bug 630529 too
<ubot4> Launchpad bug 630529 in ubiquity (Ubuntu) "Installing from USB drive writes boot sector to USB not HDD (affects: 2) (heat: 12)" [Critical,Incomplete] https://launchpad.net/bugs/630529
<cjwatson> we're working on this ...
<ara> cjwatson, any ETA for the ISOs?
<doko> Riddell: so the last binaries for libopensync-plugin-moto  should be removed too?
<cjwatson> ara: 13:31 <cjwatson> Evan reckons that we should try to fix bug 630529 too
<ubot4> Launchpad bug 630529 in ubiquity (Ubuntu) "Installing from USB drive writes boot sector to USB not HDD (affects: 2) (heat: 12)" [Critical,Incomplete] https://launchpad.net/bugs/630529
<cjwatson> 13:35 -!- cyphermox [~cyphermox@ubuntu/member/pdpc.supporter.active.cyphermox] has quit [Quit: Quitte]
<cjwatson> oops
<cjwatson> 13:31 <cjwatson> we're working on this ...
<ara> OK
<cjwatson> going as fast as possible
<cjwatson> I realise the lack of stuff to test is a problem
<pitti> I guess smoketesting today's dailies can't hurt, but we shouldn't add them to the tracker yet
<Riddell> doko: removed
<doko> ok, removing libopensync0-dev and libopensync0 too
<Riddell> doko: you mean you want me to remove them?
<doko> Riddell: no, I did
<doko> Riddell: but you could accept the llvm packages ;)
<doko> I don't understand what the scilab upload is supposed to fix ...
<doko> I can't see who did upload the package
<cjwatson> ubiquity 2.4.7 uploaded
<cjwatson> we're also waiting for a signed wubi.exe (IS is on it)
<cjwatson> doing a full test install with 2.4.7
<cjwatson> (from usb) - had already tested the active bit of the change but best be safe
<Riddell> accepting llvm
<doko> Riddell: sorry, clang belong to it as well
<cjwatson> can somebody review that ubiquity upload?  then we can run the publisher as soon as it's built and then start spinning CDs (subject to wubi signing which apparently is complicated)
<cjwatson> I realise it might take a little while to review as it isn't entirely trivial.  Evan and I pair-programmed it
<Riddell> cjwatson: looking
<fader_> cjwatson: I'm guessing your grub changes are not in an ISO yet but will be in the next spin?
<cjwatson> fader_: correct
<fader_> cjwatson: Cool.  All set up to re-test.
<Riddell> cjwatson: isn't this ment to also update grub-installer 1.55ubuntu4
<Riddell> ?
<Riddell> looks like it is already at 1.55ubuntu4
<Riddell> ah that happened a couple of hours ago
<cjwatson> that was 2.4.6, yes
<cjwatson> queuebot is a little confused due to the rmadison lag
<cjwatson> the one thing to note is that the bug fixed in 2.4.7 is still present in grub-installer, for d-i installations
<cjwatson> I think it's higher-priority in desktop installations so I'd rather defer that part to natty
<Riddell> cjwatson: ok accepting
<cjwatson> thank you
<Riddell> cjwatson: might be an idea to report bug 630529 on d-i as well then
<ubot4> Launchpad bug 630529 in ubiquity (Ubuntu Maverick) (and 1 other project) "Installing from USB drive writes boot sector to USB not HDD (affects: 2) (heat: 12)" [Critical,In progress] https://launchpad.net/bugs/630529
<cjwatson> mm, fair point
<cjwatson> done
<Riddell> doko: accepted clang
<azeem_> doko: hrm, so reverting is off the table?
<doko> azeem_: afai, not off the table, but now requires now some more work.
<doko> afaiu
<azeem_> ok
<cjwatson> ubiquity/amd64 is published, but not i386.  I'm going to run the publisher by hand shortly to catch up
<cjwatson> and try to make things go a bit faster
 * cjwatson taps fingers waiting for the publisher
<cjwatson> (it's running cron.germinate now)
<ttx> I like that calm before the storm...
<cjwatson> just walking skaet through manual CD builds
<cjwatson> server is done but there was a glitch in mirroring that meant that oem-config 2.4.7 wasn't there on i386 - skaet is respinning
<cjwatson> (get the respins done early!)
<cjwatson> ara: who can give skaet admin access to iso.qa?
<ara> cjwatson, I can
<cjwatson> aha
<ara> skaet, which is your id at the iso tracker?
<skaet> hi ara,   kate.stewart
<ara> skaet, done. can you refresh the page and see if you have access to the admin menu?
<cjwatson> she does
<cjwatson> just queueing up other builds now first
<smoser> skaet, ttx uec images build 20101006.1 started. will appear at http://uec-images.ubuntu.com/server/maverick/20101006.1 ~ 4 hours
<ttx> smoser: ack
<skaet> smoser, thanks.
<micahg> ok, so I thought I had a sponsor before noon UTC, but the sponsor didn't upload, so should I still try to find someone for bug 650601 to upload?
<ubot4> Launchpad bug 650601 in libfxscintilla (Ubuntu) "[FFe] Please update libfxscintilla to 2.11.0 (affects: 1) (heat: 8)" [Wishlist,Confirmed] https://launchpad.net/bugs/650601
<cjwatson> crap, forgot to set OFFICIAL="Release"
<cjwatson> so the images generated so far are labelled wrongly
<cjwatson> sorry about that folks
<ttx> smoser: does that affect your cloud images ^^ ?
<ttx> smoser: cjwatson says no
<fader_> cjwatson: FYI, it looks like bug 641259 is still hitting us on some servers :(
<ubot4> Launchpad bug 641259 in grub2 (Ubuntu Maverick) (and 2 other projects) "grub does not appear to load after maverick post-beta install (affects: 10) (heat: 74)" [Critical,Fix released] https://launchpad.net/bugs/641259
<ttx> so you're still on track :)
<smoser> well, libfxscintilla does not affect cloud images
<smoser> but grub2 does
<cjwatson> fader_: they'll have to stay broken now
<cjwatson> I have no more available options
<cjwatson> fader_: did we fix any of them?
<fader_> cjwatson: Ack, I expected as much but wanted to let you know
<fader_> cjwatson: I've tried two so far to no avail, but I'll keep trying the others
<cjwatson> fader_: also, there should be a new bug
<cjwatson> oh, wait, well
<cjwatson> that bug was about servers
<fader_> I want to do the 10.04-grub-workaround to make sure they installed properly first
<cjwatson> let's see how your testing goes
<ara> skaet, cjwatson: rebuilding already?
<skaet> yup,  there rebuilding now...
<cjwatson> ara: 17:41 <cjwatson> crap, forgot to set OFFICIAL="Release"
<cjwatson> 17:42 <cjwatson> so the images generated so far are labelled wrongly
<cjwatson> 17:43 <cjwatson> sorry about that folks
<ara> cjwatson, OK, thanks!
<cjwatson> smoser: the bit that doesn't affect cloud images is the OFFICIAL="Release" labelling that I forgot
<cjwatson> fader_: maybe one could be shipped to UDS or something?
<fader_> cjwatson: Good idea, I'll see what it would take to make that happen
<smoser> ok. good. yeah, i'm still on track for 20101006.1 to be testable when it arrives (maybe 3 hours from now -- 20:00 UTC)
<cjwatson> fader_: are any of the affected servers in the UK?
<cjwatson> fader_: if they are, elmo says I can get one brought to the office
<fader_> cjwatson: Yes, all of the affected ones are in the UK
<cjwatson> woo
<fader_> cjwatson: Let me finish up verification that 10.10 installed correctly on one of them and I'll give you the info on it
<cjwatson> ok, if you can give me a sample hostname that would be good
<fader_> cjwatson: The host I'm checking right now is "doubah"
<cjwatson> server, desktop reposted
<cjwatson> (ubuntu)
<cjwatson> ubuntu alternate rebuilding
<cjwatson> then skaet takes over again :)
<micahg> cjwatson: my sponsor fell through for libfxscintilla, should I still try to get it uploaded?
<cjwatson> micahg: might as well
<micahg> cjwatson: k, thanks
<cjwatson> not promising to accept it; but I can promise that we won't accept it if it isn't uploaded
<micahg> cjwatson: heh, ok, thanks
<cjwatson> generally, during hard-freeze periods (launchpad says "pre-release freeze") you can err on the side of uploading
<cjwatson> since we can always hold/reject if need be
<cjwatson> kubuntu desktop posted
<cjwatson> kubuntu alternate posted
<cjwatson> (pub)
<lfaraone> If I can approve FFes for a set of packages, can I A) approve a FFe requested by someone else and upload the same, B) request and ACK my own FFe for that same set of packages?
<smoser> cjwatson, slangasek, or anyone else with ability, could youplease populate tracker with 20101006.1 for uec images and ec2
<smoser> http://uec-images.ubuntu.com/server/maverick/20101006.1/published-ec2-daily.txt
<doko> cjwatson, Riddell: if there are image rebuilds, I'd like to fix http://sourceware.org/bugzilla/show_bug.cgi?id=12092
<ubot4> sourceware.org bug 12092 in libc "strstr broken for some inputs on pre-SSE4 machines" [Normal,Resolved: fixed]
<stgraber> any ETA on the first DVD builds (I'm mostly interested in Edubuntu) ?
<NCommander> Riddell: openjdk is a problem,but not one I think that's going to get solved. Linaro was working on it, but I'm not sure of the current status of their fix
<ogra_ac> NCommander, ??
<ogra_ac> whats the problem ?
 * ogra_ac is pretty sure that was fixed weeks ago by using a different version on arm
<ogra_ac> (and i think i tlaked about it in the meeting more than once)
<NCommander> ogra_ac: I know we have two different java versions for armel, but I thought that was a stopgap until the 1.9 branch could be properly fixed on ARM
<ogra_ac> NCommander, we dont
<ogra_ac> we only have one openjdk on arm
<ogra_ac> and another one on the other areches
<ogra_ac> and thats on purpose (as i said in the past)
<NCommander> ogra_ac: must have missed that
 * NCommander scures away
<ogra_ac> NCommander, it just shows up on ftbfs because neither doko nor cjwatson wanted to maintin a PAS hack for it
<ogra_ac> just ignore it
<NCommander> Ignore More: On
<ogra_ac> :)
<NCommander> ogra_ac: on the plus side, apport is pretty much fixed, I just need to upload a bunch of stuff to the porting box, and we're in business
<ogra_ac> awesome
<ogra_ac> how is portland ?
<ogra_ac> have you been adopted already ? :)
<NCommander> ogra_ac: great, I feel better that I have in a very long time.
<NCommander> (I assume you heard I was in Portland from GrueMaster)
<ogra_ac> yeah, i can imagine how portland can do that to you
<ogra_ac> yeah
<NCommander> ogra_ac: more that being home was just not the place I could be anymore
#ubuntu-release 2010-10-07
<ScottK> FYI cjwatson, slangasek, etc: I've reviewed ubuntu-sugar-remix-meta and it's fine to go in.  I'm leaving it in queue in case you need a build to stimulate a publisher run.
<ScottK> lfaraone: ^^^ - Don't panic.  We'll get it in before release.
<lfaraone> ScottK: no worries.
<micahg> ScottK: if there is a sync that looks like it should go in, is it still worth trying (potential data loss)
<micahg> or better to SRU
<ScottK> micahg: Seeded or unseeded?
<ScottK> micahg: What package?
<micahg> ScottK: zoneminder, unseeded, RC bug
<micahg> actually, needs a merge
<micahg> debian 497107
<ubot4> Debian bug 497107 in zoneminder "uninstallation deletes MySQL database with no warning" [Serious,Fixed] http://bugs.debian.org/497107
<ScottK> Sounds reasonable to try and fix.
<micahg> ScottK: should I try to get a merge done then?
<ScottK> micahg: Yes.
<micahg> ScottK: thanks
<wgrant> When is the release pocket expected to permafreeze?
<ScottK> wgrant: Depends on what you mean by that.
<ScottK> I think ~noon UTC Thursday was what we said though.
<ScottK> barring last minute respins ...
<wgrant> We need to do some stuff at the Soyuz end to completely rid the indices of sparc and ia64.
<ScottK> Actually I think a day after that.
<ScottK> We said noon UTC on 10/9 in the mail to u-d-a, but I think that was a mistake.
<micahg> Noon UTC Sat was in the original mail
<wgrant> Although given what happened last time, I guess we can't really make any assumptions that there won't be 11th hour respins.
<ScottK> Yeah.  I think that's wrong though.
<ScottK> Yep.
<ScottK> cjwatson: The "Final Freeze timeline for unseeded packages in Universe/Multiverse" said Noon UTC on 10/9, but I think we really wanted 10/8 for hard freeze in Universe.
<ScottK> Unfortunately I'll be away again tomorrow, so I'd appreciate it if someone else in the release team would look at that and re-announce as needed.
<ScottK> Noon UTC would be 36 hours to the end of 10/10 and IIRC we were aiming for 36 hours to the start of 10/10.
<slangasek> smoser: ec2 candidates posted to the tracker
<slangasek> NCommander: Portland, or Portland, ME? :)
<ScottK> micahg: Is it on purpose we don't ship the unversioned .so in  libfxscintilla-dev?
<micahg> ScottK: idk, I just tried to follow what was done before in teh package, did I miss something?
<ScottK> OK.  Let me look at the old one.
<micahg> ScottK: you'll have to go back to karmic
<ScottK> Nice.  That's an empty package.
<ScottK> So this one is at worst less useless.
<micahg> ScottK: zoneminder works locally, but fails in pbuilder, should I try pushing to PPA to see if it works?
<ScottK> What's the error?
<micahg> oh, right :)
<micahg> ScottK: idk, I can't see what the error is, I get a line of undefined references
<ScottK> What's the first one?
<micahg> zm_comms.cpp:(.text+0x1d89): undefined reference to `std::set<CommsBase*, std::less<CommsBase*>, std::allocator<CommsBase*> >::set()'
<ScottK> micahg: Why don't we take this to #ubuntu-motu?
<micahg> ScottK: k
<NCommander> slangasek: Portland, OR :-)
<slangasek> NCommander: ah, then, welcome!
<NCommander> slangasek: thanks :-). I don't move here full time htough until November.
<RAOF> Hm.  I think bug #656037 should be release-critical for the netbook images.  Can I get a second opinion on that?
<ubot4> Launchpad bug 656037 in ubiquity (Ubuntu) "Software sources not selected (affects: 2) (heat: 12)" [High,Confirmed] https://launchpad.net/bugs/656037
<slangasek> RAOF: confirmed; that's a rather significant bug to have at install time
<slangasek> RAOF: are you or someone else working on a fix?
<RAOF> I am not at this point; I'm not familiar with the ubiquity code.
<RAOF> And I've only just hit it.
<slangasek> cjwatson, ev, skaet: ^^ installing UNE gives only security enabled in sources.list; looks critical to me, no straightforward way to fix it post-release
<RAOF> Ah, ok.  I think I know what's wrong there.
<skaet> slangasek, RAOF, thanks for the head's up.
<RAOF> skaet: I've updated the bug with my findings so far; shall I leave that up to you, and go and try to break further iso images? :)
<skaet> ROAF, :),  just read the update.   Thanks.
<skaet> we'll discuss it here first thing this morning (when the rest wake up )... please go and try to break more iso images ;)
<micahg> can we still get a sync in for a CVE?
<micahg> oh, hmm..has lots of rdepends, maybe better not
<ara> morning all!
<didrocks> hey, FYI, this version fix an upgrade issue ^^
<ara> skaet, are you around?
<ara> morning ttx, robbiew
<robbiew> ara: morning
<ttx> ara: hey
<ttx> ara: skaet is not here yet
<ara> marjo, robbiew, cjwatson: the installation in English when French selected seems to be a side effect of bug https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/656037
<ubot4> Launchpad bug 656037 in ubiquity (Ubuntu Maverick) (and 1 other project) "Software sources not selected (affects: 2) (heat: 14)" [High,Confirmed]
<robbiew> ara: ack
<robbiew> ev: ^^^
<ev> indeed, I have a pile of these things I'm trying to sort through.  Looking at bug 655893 now.
<ubot4> Launchpad bug 655893 in ubiquity (Ubuntu Maverick) (and 1 other project) "Free Software option still enables restricted repos (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/655893
<robbiew> ev: ack
<cjwatson> stgraber: your DVD builds are up (actually last night, but I couldn't get net access to post them)
<cjwatson> ScottK: urgh, it seems late notice to potentially delete a day from developers' schedules is the thing
<cjwatson> ara: looking at that shortly, just finishing catching up
<ara> sure thing
<cjwatson> doko: can you upload it so that we have flexibility to accept it if possible?
 * ara is looking forward to the release so she can format her laptop and have a fresh installation
<cjwatson> currently have five bugs on the respin-candidate whiteboard list here
<cjwatson> (1) lsb-release not updated (2) grub broken on some servers (3) bug 656037 (4) bug 655893 (5) libc strstr broken on some SSE2/SSE3 machines on some inputs
<ubot4> Launchpad bug 656037 in choose-mirror (Ubuntu Maverick) (and 1 other project) "Software sources not selected (affects: 2) (heat: 14)" [High,Triaged] https://launchpad.net/bugs/656037
<ubot4> Launchpad bug 655893 in ubiquity (Ubuntu Maverick) (and 1 other project) "Free Software option still enables restricted repos (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/655893
<doko> cjwatson: uploaded
<SpamapS> cjwatson: is one of those to fix the release tag?
<cjwatson> SpamapS: (1)
<SpamapS> ah ok. :)
<cjwatson> doko: hm, robbie says it was broken on lucid too
<doko> yes, it is
<doko> sru is uploaded too
<cjwatson> just trying to weigh whether we should cram into maverick release given that, or push to updates
<cjwatson> mind you it's looking like we have to respin everything anyway
<doko> that's why I was asking, I'm fine with either decision. it's the build time on armel which maybe is a blocker
<doko> 5h
<ttx> base-files fix uploaded
 * ara is trying to find motivation to keep testing when she knows that the probability of respin tends to 100%
<cjwatson> the more things we catch in one go, the more chance there is that we can keep it to one respin
<cjwatson> doko: the question is fairly finely balanced, but I think the consensus here is that we should push this to -proposed
<cjwatson> basically as risk management
<Daviey> I just noticed that mythbuntu is oversized.
<cjwatson> Daviey: yes, amd64 only
<cjwatson> can you do anything aboutit?
<cjwatson> (that's really really safe)
<Daviey> cjwatson: happy to poke.
<doko> cjwatson: ok, rejected
<cjwatson> so for 656037, I think I would like to try to fix this on live filesystems rather than changing ubiquity for it
<cjwatson> by adding the appropriate /etc/default-release file
<cjwatson> still considering though
<robbiew> ara: take a break ;)
<cjwatson> basically because if I change choose-mirror then I have to rebuild d-i too
<cjwatson> and also because mirror/suite is a force-override, and /etc/default-release is what's generally supposed to be used as I read the code history
<cjwatson> OTOH, hmm, customisers will be caught out
<ara> robbiew, mmm, coffee... :)
<cjwatson> sigh, I'll change choose-mirror, it's the simplest fix
<robbiew> cjwatson: ack
<cjwatson> testing
<ara> nice thing 11-11-11 is a Friday
<cjwatson> oh don't even go there. :)
<cjwatson> so after base-files lands we can spin arm omap and none of the pending bugs seem to affect that
<cjwatson> well, 650703 might, not sure
<pitti> I take it it's too late for a tzdata sync into maverick?
<pitti> ah, nevermind; I just saw that there aren't urgent changes in 2010m
<cjwatson> which country's sky is falling and when?
<cjwatson> ok :)
<pitti> Vostok Station on the South Pole
<pitti> like anyone there would are about an hour off during a half-year night :)
<pitti> "care"
<pitti> urgh, quite a few packages still in the queue for maverick
<cjwatson> universe is still ok but please don't accept stuff on CDs without coordination
<pitti> no, I won't accept anything on my own at this point
<pitti> just took a look at it while I'm doing SRUs
<marjo> pitti: yes, thanks
<pitti> didrocks: I think ubuntu-netbook-default-settings can become an SRU (which is fine for upgrading from lucid)
<didrocks> pitti: sure, it's just it seems we will have to respin right? so, it was just in case :)
<didrocks> but as it's just affecting upgrades, a 0-day SRU will do it
<pitti> cjwatson: urgent SRUs can already be accepted tomorrow (or whenever we are reasonably sure that we won't respin), right?
<pitti> didrocks: you mean "in case we have to respin netbook", or "we already need to anyway"?
<didrocks> pitti: I was thinking looking at bug #656037 that a respin will be necessary
<ubot4> Launchpad bug 656037 in choose-mirror (Ubuntu Maverick) (and 1 other project) "Software sources not selected (affects: 2) (heat: 14)" [High,Triaged] https://launchpad.net/bugs/656037
<pitti> ah, yes
<didrocks> pitti: but your choice, if it's a 0-day SRU, I think it's fine as well
<pitti> cjwatson: ok to accept ubuntu-netbook-default-settings, since it seems we're going to respin that anyway?
<pitti> (trivial and obvious patch)
<cjwatson> yes
<didrocks> thanks cjwatson, pitti :)
<ara> just installed xubuntu i386 and the TERM env var is not set by default, is that known?
<ara> also, the plymouth splash shows Ubuntu 10.10
<cjwatson> splash> known bug, wontfix for maverick I think
<cjwatson> TERM> bug 621927?
<ubot4> Launchpad bug 621927 in xfce4-terminal (Ubuntu) (and 8 other projects) "Embedded Terminal Emulator isn't giving a TERM variable (affects: 72) (dups: 17) (heat: 386)" [Undecided,Confirmed] https://launchpad.net/bugs/621927
<ara> yes, it looks like it. Thanks cjwatson!
<cjwatson> a dup of it was originally filed on man-db or something like that, so it happened to be in my browser history
<ara> don't be so modest :)
<cjwatson> *cough* er, yes, of course, I've memorised the Launchpad bug database
<cjwatson> very handy during downtime
<pitti> me too; for example, I still know exactly what #1, #10000, and #100000 are about
<ara> cjwatson, you could go to a talent show where they'd pick a bug number and you'd tell them the description and tasks
<cjwatson> I used to be able to tell you the maintainer for a very sizeable number of Debian packages off the top of my head, but that was when I was RM and hassling people regularly :)
<mvo> term> I will sponsor the fix
<cjwatson> choose-mirror uploaded for 656037, will need d-i and ubiquity uploads to incorporate it though
<mvo> pitti: vte (bug #621927) - do you prefer maverick or maverick-proposed?
<ubot4> Launchpad bug 621927 in xfce4-terminal (Ubuntu Maverick) (and 14 other projects) "Embedded Terminal Emulator isn't giving a TERM variable (affects: 72) (dups: 17) (heat: 386)" [Undecided,Confirmed] https://launchpad.net/bugs/621927
<pitti> mvo: default answer is "proposed" now; please coordinate with cjwatson and skaet for maverick uploads, but just if we need to respin anyway
<pitti> it sounds very far away from an installation breaker
<mvo> yeah, proposed it is then
<pitti> right
<mvo> I guess I need to reupload some other ones to proposed as well, namely gconf and ubuntu-artwork
<pitti> *nod*
 * mvo will do that now
<skaet> mvo, sounds about right.   I've flagged it to release note issue though (feel free to come up with the wording ;) )
<pitti> mvo: gconf sounds like SRU, I'll reject the upload
<pitti> mvo: I think I can process SRUs tomorrow, so that they are ready for testing at release time
<mvo> skaet: heh :) you know that I'm founding member of https://edge.launchpad.net/~blatant-and-awkward
<pitti> mvo: same for jockey, I think?
<mvo> yeah
<pitti> lol
<skaet> mvo, LOL.   I maybe should join...
<ara> pitti, I am getting this when trying to shutdown xubuntu:
<ara> Method "Shutdown" with signature "" on interface "org.freedesktop.Hal.Device.SystemPowerManagement" doesn't exist
<pitti> mvo: rejecting jockey as well; in the bug you also said "proposed", I think it's too late (would require respinning everything)
<pitti> ara: right, our current XFCE still tries to talk to hal until it falls back to other shutdown methods
<mvo> pitti: sure, that is fine
<pitti> ara: it's just cosmetical (hal isn't supposed to be there)
<pitti> a bit of a wart, though
<pitti> ara: I think that's fixed in the xubuntu-dev PPA (i. e. newer upstream version); I came across it during an oem project
<ara> pitti, but I can't shutdown, it goes back to gdm
<pitti> oh
<ara> it didn't happen with the first xubuntu installation I did today
<pitti> ara: oh, hmm; I have a patch for this; is there a bug about it? we could SRU it
<ara> pitti, google didn't come up with any result in launchpad, I'll file one, which package?
<pitti> ara: I'm not allowed to publish the OEM bug, but I'm happy to attach the bug to a public one and nomiate for SRU
<pitti> ara: xfce4-session
<ara> pitti, sure thing, let me file the bug
 * cjwatson slooowly tries to construct a reproduction case for bug 650703
<ubot4> Launchpad bug 650703 in ubiquity (Ubuntu Maverick) (and 1 other project) "OEM config appears to work but user setup is not run after reboot (affects: 2) (heat: 10)" [High,Incomplete] https://launchpad.net/bugs/650703
<cjwatson> can somebody review choose-mirror?
<pitti> cjwatson: I was just about to ask whether you want me to accept
<pitti> I just reviewed it
<pitti> done
<ara> pitti, there was one bug already, bug 496423
<ubot4> Launchpad bug 496423 in xfce4-session (Ubuntu) (and 1 other project) "XFCE4-Session doesn't use the ConsoleKit interface to shutdown or reboot (affects: 3) (dups: 1) (heat: 22)" [Medium,Triaged] https://launchpad.net/bugs/496423
<pitti> splendid
<ara> pitti, I commented it and marked as affecting me
<pitti> ara: responded with patch
<pitti> uh, wow -- whatever the LP guys did with the buildd system, let's keep it that way
<pitti> it's as responsive and snappy as it used to be a long time ago
<wgrant> Yep.
<wgrant> jelmer fixed everything.
<wgrant> Did you see the blog post about it?
<wgrant> Latency should be down from ~20 minutes to <5 seconds.
<wgrant> http://blog.launchpad.net/cool-new-stuff/more-build-farm-improvements has a pretty graph.
<pitti> wgrant: right; and chroot upgrading seems to be faster, too
<wgrant> That hasn't changed. But the log updating has.
<wgrant> It's now updated a few times a minute.
<wgrant> So it just looks like it's going faster.
<cjwatson> 650703 unreproducible here
<cjwatson> will try again on real hw with amd64
<pitti> erk, seems I misread the oversize number of xubuntu yesterday
<pitti> seeds fixed harder now
<hggdh> I cannot see 'reinstall grub' as an option under the Rescue on the server ISO. Is this correct or a bug?
<cjwatson> it would be a bug, I haven't had a chance to look it up yet
<cjwatson> (not rc though)
<hggdh> cjwatson: I will open one then
<cjwatson> do you have a separate /boot?
<hggdh> not on the test machines, no
<cjwatson> and grub is definitely installed on the partition you selected to rescue?
<cjwatson> the test is fairly simple - [ -f /target/boot/grub/menu.lst ] || [ -f /target/boot/grub/grub.cfg ]
<hggdh> er, actually, I found that on a KVM test, single disk, standard partitioning
<hggdh> an yes, grub is installed
<cjwatson> ok, I can try to reproduce that here
<cjwatson> hggdh: lvm or not?
<hggdh> LVM
<cjwatson> ok
<cjwatson> IIRC that creates a separate /boot.
<cjwatson> I'm pretty sure that will be why.  rescue-mode doesn't currently mount any other partitions other than the one you select.
<cjwatson> hggdh: bug 320183
<ubot4> Launchpad bug 320183 in rescue (Ubuntu) "When using "Recover a broken system" from the Server CD boot menu, /boot is not mounted (heat: 5)" [Low,Triaged] https://launchpad.net/bugs/320183
<hggdh> then this is a bind, is it not? All rescue asks is where is the root
<hggdh> ah there, OK
<cjwatson> not really, you just have to use the shell instead
<cjwatson> it's a lack of provision of shiny neatness, rather than making it impossible to rescue
<hggdh> indeed :-)
<hggdh> cjwatson: thank you
<ara> ev, one question, before the new ubiquity architecture, where it starts installing in the background while the user keeps answering questions, was the installation process cancelable (?) without losing any data once you had selected the partition schema?
<ara> ooh
<ara> no, ev
<ara> OK, I'll wait :)
<cjwatson> ara: you could cancel at any point before pressing "Install" on the summary screen
<ara> cjwatson, thanks, then there's a problem now, as soon as you click next after partman, you cannot cancel it anymore, which is OK, but not if we don't tell the user :(
<ara> the user does not receive any warning (when selecting full disk)
<ara> only when resizing
<cjwatson> you'lll need ev for that
<cjwatson> -l
<ara> OK, I'll tell him when he's back
 * ara -> lunch
<cjwatson> fader: I'm very confused about doubah.  it appears to be running Xen, which should mean that nothing should go anywhere near grub2.  are you actually doing the cert installs within Xen, or is that a red herring?
<fader> cjwatson: No, it does shared duty as a PPA build system, so when we're not testing it it gets wiped and reinstalled
<fader> I'm not aware of what's used after that but Xen would be a likely candidate
<fader> cjwatson: For reference, we do a PXE boot and then a straight install off of the daily server image.  I can send you the preseed we use if that's of use as well.
<cjwatson> fader: aha.  so can I consider the Xen installation that's currently there to be wipable?
<cjwatson> fader: and am I likely to be able to do a USB install and achieve similar results?
<fader> cjwatson: Absolutely... feel free to blow it away.
<cjwatson> ok
<fader> cjwatson: I certainly hope the USB install shows the same results, otherwise this bug is even weirder :/
<ev> ara: that's by design
<ev> thus why the button is labelled 'Install Now' - it will immediately write to your disk
 * cjwatson wheels this maverick-desktop-i386.iso USB stick over there then
<ev> And if we are forced in a later release to be more explicit, lets do it in the button label, not in a warning dialog.
<ev> it warning you when resizing is actually a bug.  I forgot to suppress that message.
<stgraber> cjwatson: cool, highvoltage will start testing them
<ara> ev, OK, thanks
<Riddell> while I support not having an extra dialogue I do wonder how many people won't read the button text and won't expect the formatting to start at that stage
<ara> Riddell, I agree, I think the next, next, next, next, makes you think that the labeling of that one is "Next" without reading
<cjwatson> fader: hmm.  so I did a desktop install on doubah (as that was quickest), and it booted fine
<fader> cjwatson: I have only reproduced the issue with server installs
<cjwatson> oh, you tried a desktop install?
<fader> I will give a desktop install a shot on one of the other affected systems and see what's up
<fader> cjwatson: Not yet :)
<cjwatson> I can try a server install ... don't see why that would differ particularly though
<fader> Sorry, ambiguous phrasing
<fader> It's possible that it's environmental somehow, but I don't know why it would be consistently reproduceable with maverick only on these systems but never hitting others.  Curiouser and curiouser.
<cjwatson> I'll try amd64 as well rather than i386
<cjwatson> which arch were you using?
<fader> I was using amd64
<cjwatson> ok, suppose that's a possible source of trouble
<cjwatson> usb-creatoring server-amd64 now
<cjwatson> (usb-creating?)
<fader> Yeah, lacks the simplicity of 'burning' :)
<ara> cjwatson, do we have an ETA for the respin?
<cjwatson> ara: will discuss with skaet when she gets back (should be shortly)
<ara> OK
<cjwatson> would like to know more about fader's grub bug though
<fader> I've got an i386 desktop install going right now
<cjwatson> fader: what partitioning do you use?
<fader> cjwatson: Default full disk
<cjwatson> LVM?
<cjwatson> (which is default on servers)
<fader> Yes, 90% sure, let me check the preseed though
 * ogra_ac would appreciate an armel respin to test the omap4 changes
<fader> cjwatson: Yep
<cjwatson> ogra_ac: does the omap image contain ubiquity?
<ogra_ac> cjwatson, well, as oem-config, yes
<cjwatson> in that case I think it would be best to wait until this ubiquity lands so we don't have to respin again straight afterwards?
<cjwatson> unless that's a serious problem
<charlie-tca> pitti: mr_pouit said you downsized my 64bit desktop image. It still shows oversized by way too much for a cd. Is this going to be downsized and rebuilt?
<ogra_ac> not really, all bits were tested separately already
<cjwatson> but I'll hand back to skaet now and go back to debugging this server box
<ogra_ac> just not in an image yet
<fader> cjwatson: http://pastebin.ubuntu.com/507997/   -- the preseed I'm using (for reference)
<pitti> charlie-tca: I already fixed the seeds, so the next respin (when ubiquity is finished) should be okay
<charlie-tca> So we will need a respin for testing
<lfaraone> There's a package in Universe that is new in Maverick, that is currently broken to an external API change. The version in Ubuntu is a git snapshot pre-release version. I've tested the new version for a few days and have found no problems with it.
<cjwatson> fader: just to double-confirm, your preseed in fact says regular, not lvm
<lfaraone> I'm the maintainer of it in Debian. Could it be possible to get the new version in Ubuntu, since there's zero regression potential, and it doesn't work at all at current.
<cjwatson> fader: you have 'd-i partman-lvm/confirm boolean true' and such, but the operative bit is 'd-i partman-auto/method string regular' - is that definitely right?
<fader> cjwatson: Hmm, sorry -- the preseed is right; I thought that the 'auto' bit implied default.  The preseed should be believed over me wherever we differ
<fader> As that's what is actually being run
<cjwatson> fader: hm, and you're using GRUB_TERMINAL=serial - is there definitely something listening to serial?
<cjwatson> (that would be an obvious difference between this and a non-preseeded lucid install!)
<fader> cjwatson: Definitely; there's a serial console connected to the system
<cjwatson> ok - well, I can try it without that and see what happens, and then bring my laptop over and serial it up
<fader> Though that's the case on all of the server systems, and only some of them exhibit this behavior
<cjwatson> just seemed like an obvious source of skew
<fader> My i386 desktop install is complete and appears to have the same symptoms as the amd64 server installs
<cjwatson> similar preseeding?
<cjwatson> is it possible that some of the serial consoles are set to different speeds?
<fader> Similar preseeding, yes; I can pastebin the preseed for that if it's of use to you
<cjwatson> sure, might be
<fader> All the serial consoles should be set to the same speed... all the preseeds are generated from a single template and the systems are all connected to a serial console multiplexer of some description
<cjwatson> I'm not sure what grub's defaults for serial config are
<fader> Argh, sorry -- I goofed the desktop install and ended up with a server install after all; redoing this
<cjwatson> doubah boots fine with grub on the console
<cjwatson> default serial config is 9600 baud, no parity, 8 data, 1 stop
<cjwatson> I'll check with IS
<fader> cjwatson: Same -- 9600 8,n,1
<fader> What we're using, I mean
<cjwatson> fader: this is working fine over serial here
<cjwatson> plugged my laptop in and used picocom
<cjwatson> remind me of how I can look at another machine that's currently in the cert lab?  maybe I can compare and contrast somehow
<cjwatson> (a failing machine)
<ara> ttx, any reason why UEC tests are not in the tracker?
<ttx> ara: no, they should be
<ttx> smosrer asked for them to be added at the same time as the EC2 ones
<ttx> smoser, even
<ara> smoser, I can add them for you, can you tell me the build number?
<ttx> hggdh: what version did you test with ?
<ttx> better use that one :)
<hggdh> ttx: I tested 20101006.1
<ttx> ara: ^ that's the one that should be there
<ara> on it
<hggdh> if we are respinning, shouldn't we close the QA tracker meanwhile?
<ara> on it
<ara> sorry, done
<ara> :D
<hggdh> holy ara...
<ara> (the UEC posting, not the closing)
<hggdh> still :-)
<hggdh> ttx: UEC instance tests marked executed
<fader> cjwatson: I /msg'd you some connection info
<ttx> hggdh: we are *not* respinning yet.
<victorp> fader - ping
<fader> victorp: pong
<victorp> fader - just talking to marjo and colin about the server bug
<victorp> fader - can I ask some questions?
<victorp> fader - the servers that are failing , are they related? i.e. same rack, make, ... something?
 * cjwatson is also asking fader some of these questions in /msg :-)
<fader> :)
<cjwatson> confirmed that a 10.04 cert-preseeded install succeeds
<fader> victorp: They seem to be HP systems
<fader> But not every HP system is affected
<victorp> fader - are they passing for 10.4 on exactly the same test set-up
<fader> victorp: Yes, they work just fine in 10.04
 * victorp is having it in the open :)
<victorp> fader: ok...
<victorp> cjwatson - seems like a real issue then and not a lab issue
<cjwatson> it does, but if only it were reproducible here ...
<cjwatson> I realise the differentials point to a 10.10 bug
<victorp> cjwatson - we will need to send you there then :)
<cjwatson> not necessarily ... let's see
<victorp> fader - is there another way to try to install 10.10 on the failing servers on the lab that is more manual
<cjwatson> yes, fader and I are working on that
<victorp> ok - let me know how it goes
<cjwatson> (I'm sshed into the serial multiplexor)
<cjwatson> smoser: do you have any examples of this grub problem affecting UEC?
<cjwatson> smoser: if not, then currently, I don't think you should wait for it
<smoser> i've never seen it affect uec. and hggdh has run probably on the order of thousands of instances.  as far as I know, we've never seen a grub related failure.
<smoser> (and ec2 doesn't load with grub-pc, it loads with pv-grub provided by amazon)
<smoser> so, i'll start the build
<skaet> smoser,  you'll need to rebuild though it appears to pick up the lsb-release change, we think?
<smoser> yes. i definitely do not have the lsb-release change.
<hggdh> difficult to say -- if we have a grub failure in the tests, I can only find it if something is written to the console (we dump the console log on failed tests)
<skaet> heh.   I type too slow. ;)
<ttx> I'd respin the cloud images only if we respin the server ISOs, for consistency
<hggdh> I never saw any grub failures there, though
<marjo> hggdh: good to know
<ttx> skaet: how sure are we that we'll respin the server ISOs ?
<skaet> we're respinning the server ISOs as soon as ubiquity drops.
<ttx> smoser: ok, then you can
<skaet> or at least that's the belief.
<Riddell> what does ubiquity have to do with the server CDs?
<marjo> victorp, fader, cjwatson: different vendors, different racks and different serial console servers
<marjo> skaet: ^^^ re: failing servers
<skaet> Riddell, cjwatson's double checking, but the working hypothesis right now is we need it.
<smoser> alright . maverick server build started. it will appear as http://uec-images.ubuntu.com/server/maverick/20101007.1 probably about 18:30 UTC
<smoser> If we need to get hggdh or someone early access to that, the .tar.gz files are available probably inside a half hour.
<skaet> Riddell,  we need to get the servers rebuilt to pick up some other changes at this point.   (lsb_release)
<cjwatson> Riddell: oem-config
<cjwatson> it has a debconf frontend
<cjwatson> fader: I'm not sure I'm getting the mirror config right here - getting the same "failed to download a file from the mirror" message.  how did you do this by hand?
<fader> cjwatson: Should be the mirror and path info that you have.  10.189.90.1 and the path /enablement/cdimage.ubuntu.com/ubuntu-server/daily/current/maverick-server-amd64
<JamesPage> skaet: I picked up bug 656173 this morning; its a change in functionality between lucid->maverick (by design) but may catch some libvirt users out; does it need to be added to release notes for maverick?
<ubot4> Launchpad bug 656173 in libvirt (Ubuntu) "virt-aa-helper generates incomplete apparmor profiles with chained backing files (affects: 1) (heat: 8)" [Undecided,Won't fix] https://launchpad.net/bugs/656173
<fader> cjwatson: Let me walk through it on another machine
<skaet> JamesPage, go ahead and add a note please.   I'd rather make sure its clear, than deal with alot of bugs that will get answered "working as designed"... :(
<jdstrand> skaet: it is an uncommon configuration I think
<fader> cjwatson: Wait, I see the issue... can I reboot that system on you?
<jdstrand> skaet: chained backing stores are not by any means the default
<skaet> jdstrand,  JamesPage,  will go discuss with robbiew, and get his experience on this then.  ;)
<cjwatson> fader: sure, what was the problem?
<cjwatson> I had resorted to set -x'ing my way through net-retriever ...
<jdstrand> skaet: fyi-- soon there will be a USN to discuss all of it as well, for a lucid security update
<fader> cjwatson: I munged the TFTP setup when manually editing it to remove the preseed, so you were in a weird inconsistent state -- booting from the 10.04 image and then trying to install 10.10 :[
<cjwatson> aha!
<cjwatson> that would have done it
<robbiew> jdstrand: skaet: documenting is fine...it's not much of an added effort ;)
<jdstrand> no it isn't, and I'm not opposed to it. I just wanted to put it in perspective
<ttx> robbiew: cheap way to show that we care about a consistent user experience
<jdstrand> euca uses raw (and no backing stores), virtinst/virt-manager use storage pools, and you should specify the disk format appropriately
<jdstrand> s/and you/and they/
<cjwatson> fader: so assuming that I can reproduce it, will I be able to do things like install a parallel 10.04 install, chroot into 10.10, fiddle with its grub, experimentally reboot to that, then switch back to 10.04 if it fails, rinse and repeat?
<fader> cjwatson: Yes, you should be able to.  I can set up the install for 10.04 if/when you need it
<cjwatson> if I can do that, I may have some hope
<cjwatson> ok
<cjwatson> fader: does it matter which disk I use?  is sda OK?
<fader> cjwatson: sda is what I've been using
<fader> I did try sdb on another system with multiple disks but it didn't have any noticeable effect
<cjwatson> "Logical volume(s) to be removed: thorium-disk, thorium-diskcow, thorium-swap, thorium-swapcow"; "Volume group(s) to be removed: PPA"; "Physical volume(s) to be removed: /dev/sda6"
<cjwatson> is that ok?
<fader> Makes sense as it had been doing PPA duty
<fader> Yes, our SOP is to blow everything away
<fader> They are totally wiped when set up for testing and then again when put into the PPA pool
<cjwatson> right
<cjwatson> fader: ok, can I have a reboot to the 10.04 install?
<cjwatson> (manual for preference?
<fader> cjwatson: Sure, one moment
<fader> cjwatson: mirror is /enablement/releases.ubuntu.com/lucid/ubuntu-10.04-server-amd64
<fader> You should be rebooting
<cjwatson> yep
<cjwatson> how can I deal with the reboots back and forward after this is done?  it would be ideal not to have to bother you every time
<cjwatson> presumably I'd need to use some kind of rescue system to reinstall the 10.04 grub
<fader> cjwatson: I will whip up a quick script for you if you can give me ~10m (I'm in a meeting atm)
<cjwatson> it'll take that long to do the 10.04 install
<fader> Yep :)
<slangasek> skaet: so bug #649917 would be easy enough to address in SRU to make the warning message go away, but this wouldn't actually make the system behave any more smoothly; anyone seeing the message is experiencing some other bug with plymouth, because if plymouth is working right you're never supposed to be in text mode to /see/ this message
<ubot4> Launchpad bug 649917 in plymouth (Ubuntu Maverick) (and 2 other projects) "GLIb-WARNING **: getpwid_r(): failed due to unknown user id (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/649917
<slangasek> skaet: it may be worth fixing the bug about the spurious warning message just to eliminate the bug report noise about it, but I'm not sure it actually gets us closer to how we want plymouth to work - what do you think?
<cjwatson> fader: so where does pxelinux come from in this setup?
<cjwatson> for example how is the version determined?
 * ara needs to step out for some errands. She will be back in about 1 hour
<fader> cjwatson: It's generated by a set of scripts that cr3 wrote, based on a templating system... he has templates for e.g. "maverick server" or "lucid alternate desktop" and drops in the necessary bits like IP addresses
<cjwatson> fader: I guess what I mean is, under what circumstances will we use lucid's pxelinux vs. maverick's pxelinux?
<fader> cjwatson: Under normal conditions it's based on which image was updated... if a new maverick ISO shows up on cdimage, it sets up and uses the maverick pxelinux.  In this case, I'm invoking that by hand, so it's using lucid's pxelinux when doing a lucid install and maverick for a maverick install
<cjwatson> so after you did the side-by-side install of lucid, it would have switched to using a lucid pxelinux?
<fader> Yes, definitely
<fader> For the install -- it boots from the local disk after install and does not PXE
<fader> s/does/should/
<robbiew> slangasek: fyi - skaet is in "HR training"
<slangasek> I wonder what that's a euphemism for
<slangasek> :)
<robbiew> well...you know how in-depth our HR training is :P
 * cjwatson starts off (Ubuntu netbook omap) and (Ubuntu alternate; Ubuntu desktop) in parallel
<cjwatson> since ubiquity's in place
<robbiew> \o/
<cjwatson> fader: observationally, it goes through pxelinux before booting from the local disk
<cjwatson> according to the messages on the serial console
<fader> cjwatson: Hmm, it should attempt to PXE but fail and boot from the disk, if that's what you mean
<cjwatson> in my book that's going through pxelinux :-)
<cjwatson> pxelinux has an opportunity to change state ...
<cjwatson> it definitely hits pxelinux, not just the pxe bios
<fader> I had thought that was in firmware on the system though rather than being affected by whatever was installed on the disk
<fader> Ah
<cjwatson> at least I think that's what it said, I no longer have the scrollback
<fader> Ah, I see what you mean
<fader> So we can remove the PXE path from the dhcpd conf if that is worth trying
<cjwatson> later yes, though let's pursue the current path first
<fader> Roger
<cjwatson> if that gets us a way to complete certification, it may well be a win
<cjwatson> fader: http://syslinux.zytor.com/archives/2010-August/015076.html and thread is also suggestive, and I wonder if 'chain.c32 hd0' would help
<cjwatson> might well be better than trusting the PXE stack to do it
<cjwatson> (prefixed with COM32, I think)
<fader> cjwatson: Indeed, reading that thread now
<fader> cjwatson: And I'll take your word for that, as I'm over my head at this point :)
<highvoltage> images being rebuilt?
<highvoltage> I get "You can't post or edit your result on an archived build or a build being currently rebuilt." on the iso tracker
<cjwatson> yes
<highvoltage> ok
<highvoltage> I guess this means I can go out and get lunch at least :)
<cjwatson> Ubuntu alternate reposted
 * skaet started off ubuntu-server now
<ttx> skaet: yay !
<skaet> slangasek,  good points.  fixing the spurious warnings seems like the right thing.  Do you think it will improve the signal to noise ratio on the bugs being reported against plymouth (ie seeing out what the real problems are)?
<slangasek> skaet: well, some users for whom plymouth is not currently working as intended will no longer see it so because they won't care about a black screen between the splash and gdm but they do care about an error message; but we don't currently have anyone working on these issues anyway
<ogasawara> skaet, cjwatson, robbiew: for the day 0 kernel upload, would you prefer I upload it ahead of time (ie tomorrow or sat) so that it's ready and in the queue?
<cjwatson> I think so, yes
<cjwatson> ubuntu-netbook omap build failed
 * skaet published ubuntu-server;  kubuntu started...
<ScottK> cjwatson: Re the unseeded final freeze deadline, I'm OK with not moving it as long as everyone is aware on this end that we've accepted a narrower margin than we'd originally intended.
<cjwatson> skaet: arm omap4 failed because ubiquity was out of date - should have known
<GrueMaster> skaet: Ping me when you get omap* built.  I am onsite at TI, and we are waiting with bated breath.  :P
<GrueMaster> The ubuntu-preinstalled-netbook images.
<cjwatson> have to wait for ubiquity_2.4.8_armel.deb to show up on http://ports.ubuntu.com/ubuntu-ports/pool/main/u/ubiquity/
<cjwatson> it hopefully shouldn't be *too* much longer since it's on cocoplum
<ara> my alternate installation failed, due to some uninstallable packages
<ara> no panic, wrong image
<hggdh> fader: interesting. One of the machines did not boot. Grub issues?
<fader> hggdh: One of the machines you are testing?
<hggdh> fader: yes, (the UEC test rig)
<fader> hggdh: The bug I was seeing turned out to be a bug in pxelinux rather than grub... how are you booting that system?
<hggdh> fader: install is via PXE
<hggdh> then then it boots from local drive
<fader> hggdh: Where is it failing?  And does it load pxelinux before booting from the local drive?
<fader> (Which is where cjwatson determined my bug was coming in)
<hggdh> fader: this one failed when it was set to boot from the local drive (PXE boot returned "no action")
<hggdh> ok, disregard -- I power-cycled it, and it booted normally
<fader> Hmm, gremlins
<hggdh> aye
<ttx> ara: could you make the 20101007.1 uec-images the candidates for cloud images ?
<skaet> GrueMaster, ack.  just reshuffled the builds around a bit.  omap building now.
<ara> ttx, sure, on it
<ttx> "Ubuntu Server UEC {i386,amd64}"
<ara> ttx, done
<ttx> thx
<cjwatson> hggdh: for the record, the workaround was to use 'com32 chain.c32 hd0' rather than 'localboot 0' (with chain.c32 copied from /usr/lib/syslinux/chain.c32 in maverick's syslinux-common, into the tftp directory
<hggdh> cjwatson: thank you
<GrueMaster> skaet: thanks.
<smoser> cjwatson, slangasek, or anyone else with ability, could you please populate tracker with 20101007.1 for uec images and ec2 . http://uec-images.ubuntu.com/server/maverick/20101007.1/published-ec2-daily.txt
<slangasek> grabbing
<slangasek> smoser: posted
<smoser> gracias
<GrueMaster> is omap4 image still generating?
<GrueMaster> skaet: ^^^
<slangasek> GrueMaster: yes
<slangasek> looks like it's in the last stage, actually
<GrueMaster> Ok.
<skaet> GrueMaster, as soon as its finished,  will post a note here  ;)
<GrueMaster> Thanks much.
<GrueMaster> Although we *may* have to respin omap4.  (note - I am not the athorative figure in this decision).
<slangasek> GrueMaster: what are the variables underlying that "may"?
<GrueMaster> We're onsite at TI.  Possible graphics issue *may* be xloader related, and also an issue in jasper on blaze.
<ara> bug 656165 is still happening to me in the latest builds
<GrueMaster> Jasp[er is an easy fix.
<ubot4> Launchpad bug 656165 in ubiquity (Ubuntu) "Language support incomplete after installation (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/656165
<skaet> GrueMaster, ack.    Let us know what you find out,  be good to have the images tested out though, as much as possible in case other bugs lurking....
<GrueMaster> For the most part, it already has been.  I have been testing the images with updates every day.
<GrueMaster> This should just incorporate all the latest updates i have been testing.
<skaet> ara, if cjwatson gets back on line tonight,  please let him know.
<GrueMaster> Problem has been hardware accessability.  We just got our blaze working today.
 * GrueMaster head hurts
<skaet> GrueMaster, Glad you've got your board now.   Only able to use it onsite at TI?
<GrueMaster> Yes.  Hotel doesn't have HDMI monitor.
<slangasek> GrueMaster, skaet: omap is built
<GrueMaster> Thanks.  Pulling now.
<skaet> slangasek,  still in the build queue is mythbuntu, edubuntu, ubuntu-dvd, kubuntu-dvd, ubuntu-server-ports, ubuntu(powerpc), kubuntu(powerpc), kubuntu(armel+omap), kubuntu-mobile(armel+omap); xubuntu(powerpc)
<skaet> can you please upload them to the tracker, etc. as they emerge?
<GrueMaster> Also, need to add testcases on iso.qa for ubuntu-preinstalled-netbook images.  The tasks are there, just no testcases.
 * skaet leaving the building now...  heading back to hotel... and zzzz.
<slangasek> skaet: yep, will do
<GrueMaster> slangasek: Can you update iso.qa with the omap testcases please?
<slangasek> GrueMaster: erm - why are these test cases not already there?  Do you mean to tell me that there are new test requirements showing up post-RC?
<slangasek> or do you mean that the builds haven't been posted?
<GrueMaster> Please look at http://iso.qa.ubuntu.com.  They just haven't been added properly for this release.
<marjo> GrueMaster, slangasek: Is it really critical to add these to iso.qa.ubuntu.com so close to release day?
<slangasek> how does this question only arise *now*?  How did these images pass RC validation without test cases?
<GrueMaster> We had testcases for RC.
<slangasek> found the problem
<slangasek> Ubuntu ARM preinstalled, not Ubuntu Netbook
<slangasek> GrueMaster: there, fixed
<GrueMaster> Thanks
<ScottK> slangasek (since you appear to have the baton for the release team at the moment), I have a couple of packages I'm accepting now, but I'm leaving you ubuntu-sugar-remix-meta in case you need to stimulate a publisher run later tonight.  I've reviewed it and it's fine.
<slangasek> ScottK: ack, thanks
<jcastro> is there a guideline to determine if a bug is release note worthy or do we just use best judgement, assign it as affecting the team and hope for the best?
<jcastro> I'm looking at bug #636311
<ubot4> Launchpad bug 636311 in xserver-xorg-input-evdev (Ubuntu) "Keyboard special keys interfere with mouse (affects: 11) (dups: 1) (heat: 64)" [Undecided,Confirmed] https://launchpad.net/bugs/636311
<highvoltage> jcastro: I updated the theme on http://www.youtube.com/user/ubuntudevelopers , let me know if it's ok or if there's something you'd like changed
<highvoltage> (oops, I thought I was on another channel)
<slangasek> jcastro: best judgement, open a task on the ubuntu-release-notes project
<jcastro> ugh, launchpad, it just opened another task on -evdev
<micahg> slangasek: is it worth finding merges/syncs/one-off unseeded RC bug fixes tonight still?
<slangasek> micahg: up to the deadline, sure
<micahg> slangasek: cool, thanks
<slangasek> edubuntu, mythbuntu posted
#ubuntu-release 2010-10-08
<charlie-tca__> hmm, Xubuntu desktop 64 is still oversize. It is now 712MB, which won't a cd.
<charlie-tca__> (after the respin, too)
<charlie-tca__> pitti: ^ ^  ^ still need to trim more
<slangasek> charlie-tca__: what should be trimmed?  That's a decision for the xubuntu devs rather than the release team, isn't it?
<charlie-tca__> mr_pouit told me pitti was trimming it. I will go back to him and see what he can do.
<slangasek> well, I can trim things, but the decisions about what should go are really for the xubuntu team to make
<slangasek> I guess language packs are the first choice :)
<charlie-tca__> okay. I will try to get mr_pouit on it. pitti was going to do something agreed by him and lionel already.
<charlie-tca__> I asked pitti before the respin, since there was no reason to respin if it wasn't gonna fit yet, and he said he trimmed it already
<slangasek> it's 1am in Germany, so I think pitti is safely away
<charlie-tca__> Oh, yeah. France too, I guess.
<charlie-tca__> I guess it will have to wait for one of them
<stgraber> same timezone, so they should be back in 7-8 hours
<slangasek> charlie-tca__: nah, if they're both out, no need to lose the time; if they don't like the changes I make they can revert and no harm done
<charlie-tca__> Works for me. If you need me say okay as team lead, go for it
<slangasek> in fact, from what I see the changes didn't take because we haven't done a task regeneration run in the archive since the seeds were changed
<slangasek> so I may just need to kick the archive harder and respin
<charlie-tca__> Well, let's do that then. We need those changes to happen
<slangasek> ScottK: accepting ubuntu-sugar-remix-meta
<GrueMaster> slangasek: Respin?  What for?
<slangasek> GrueMaster: xubuntu oversize, nothing to worry about
<GrueMaster> Ok.  I haveenough to panic about here.
<slangasek> kubuntu arm seems to be done some time ago; posting to the tracker
<charlie-tca__> Thank you, slangasek
<slangasek> oh, well, good thing we have another package that was just accepted, because apparently we were a full two publisher cycles behind having the xubuntu tasks in sync - sigh
<slangasek> hmm, or did that get accepted at just the wrong moment
<slangasek> yah, it did
<charlie-tca__> heh, I been complaining about the oversize for two spins now
<slangasek> well, the current respin is smaller than the preceding
<slangasek> but there were no publisher runs after the seed change, to make them effective
<slangasek> no non-empty publisher runs, that is
<slangasek> right, found the runes for forcing the publisher
<slangasek> running now; and I'm running out the door, so will have to respin xubuntu a bit later
<ScottK> slangasek: I thought I saw a note from you that syncing python-django wouldn't affect the server ISO.  If that's true, I recommend we do it.
<ScottK> See Bug 636482
<ubot4> Launchpad bug 636482 in python-django (Debian) (and 1 other project) "Update python-django to 1.2.3 version to fix an XSS vulnerability (affects: 2) (dups: 1) (heat: 26)" [Unknown,Unknown] https://launchpad.net/bugs/636482
<ScottK> Actually now that i read the bug again, I remember why we can't sync it yet.
<ScottK> Nevermine.
<ScottK> e/d
<FireCrotch> Hi. I have a question pertaining to getting a bug-fix included in Maverick before release, not quite sure about how to go about the process
<FireCrotch> The fix is for this bug: https://bugs.launchpad.net/ubuntu/+source/libdrm/+bug/619663  and the fixed packages are contained in a ppa linked to in the comments
<ubot4> Launchpad bug 619663 in libdrm (Ubuntu) (and 2 other projects) "[maverick] Non-mirrored dual-screen gives narrow display on secondary monitor (affects: 22) (dups: 6) (heat: 134)" [High,Fix committed]
<ScottK> FireCrotch: Unless it's worth delaying the whole release for, it's too late.
<FireCrotch> ScottK: Well, I guess that depends on what is considered worth delaying the whole release for. :) Maybe it's a bug that we can at least get mentioned in the release notes and upload a fixed package for updates, for those who do need the functionality?
<ScottK> That would be a better approach.
<FireCrotch> Is there someone specific that I can contact to coordinate that?
<RAOF> FireCrotch: Sarvatt is already on it.
<FireCrotch> RAOF: Oh, thank you
<ScottK> slangasek, cjwatson, etc: I'm leaving ninvaders in the queue if you need to stimulate a publisher run.  It should be good to accept if you need it.
<slangasek> ScottK: yes, python-django isn't on the server - I figured that one had been done already, grabbing it now
<slangasek> ok, the xubuntu-live task is starting to make me angry
<slangasek> ScottK: ah, read the rest of scrollback before committing the change; good :)
<ScottK> I'll leave you both gjs and ninvaders then for more publisher runs.
<slangasek> thanks
<slangasek> I need to figure out why the preceding publisher runs didn't already do the job, first :/
<wgrant> I'm confused. Are the publisher's careful flags not enough? Why do you need uploads?
<slangasek> wgrant: the what flags?
<wgrant> You can tell the publisher to publish indices for a suite, and only that suite.
<wgrant> Regardless of if there are uploads to be dealt with.
<slangasek> wgrant: you know that our interface to this is "look at the crontab; hunt down the publisher cron job; find the magic line; edit until it does what we want"? :)
<wgrant> Heh.
<slangasek> anyway, what's going wrong now is germinate, somehow
<ara> good morning all
<pitti> Good morning
<pitti> charlie-tca, slangasek: yes, indeed I trimmed some langpacks (since I added some a week ago)
<slangasek> hey there
<slangasek> so I'm rerunning germinate by hand, but I don't have high hopes; it's not picking up the latest xubuntu seed changes you made
<slangasek> I don't know why yet
<pitti> ah, seems that was sorted out now, *phew*; I was already afraid I couldn't count until 12 any more..
<pitti> uh, darn
<slangasek> http://people.canonical.com/~ubuntu-archive/seeds/xubuntu.maverick/live is out-of-date
<slangasek> trying to run the cronjob manually now
<slangasek> well, ok, how did platform.maverick wind up getting its bzr branch upgraded to a format incompatible with what was being used on people.c.c... within two days of me commenting that now is perhaps not the time in the release cycle to make such a change
<slangasek> sorted now
<pitti> wasn't me, promised (bzr upgrade)
<pitti> thanks
<slangasek> pitti: sure, more likely me than you, I've hit a few 'upgrade' buttons on the website in the past few days... I just can't imagine why I would've done that
<slangasek> ok, publisher running
<doko> do we still run fdupes during live CD builds?
<mvo> doko: I think we do (last I looked at the builder script)
<doko> mvo, don't see it in http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/
<cjwatson> wgrant: two things in response to that: (1) the fundamental problem is that cron.germinate doesn't mark suites dirty when its output changes (or possibly that cron.germinate isn't more internal to the publisher, but that's harder); (2) using publish-distro.py's -A flag means that you have to unpick cron.publish-ftpmaster, which is really quite tedious
<cjwatson> slangasek: apologies, that was my fault while trying to make bzr not crash for skaet checking out the seeds - I forgot that it would require work on people.c.c too
<wgrant> cjwatson: You can't dirty a pocket from outside the publisher (it's in-process state). But we want to fix that for other reasons.
<ara> skaet, good morning
<ara> skaet, any reason why the upgrades are not yet in the tracker?
<cjwatson> wgrant: maybe I should put it differently: when publish-distro.py starts up it considers whether there are any uploads in queues but not whether cron.germinate has changed
<cjwatson> (that's not entirely in-process)
<wgrant> cjwatson: Right.
<wgrant> It purely calculates the dirtyness from the state of the DB, which cron.germinate is not in.
<skaet> ara, looking into it...
<cjwatson> slangasek: of course, this means that I'm now having trouble running 'bzr up' because the repository is in the wrong format *sigh*
<cjwatson> I may just have to go round and upgrade everything, but I guess I should wait for a little while
 * cjwatson does 'bzr reconfigure --standalone' in the meantime
<skaet> ara,  they're there now.
<ara> skaet, ok, thanks
<didrocks> ara: was it really slow for you for bug #656713? I wasn't paying really attention, but when I looked again, the installation was finished on my box without internet connexion and one selected French.
<ubot4> Launchpad bug 656713 in ubiquity (Ubuntu) "Ubiquity tries to get lang packs from Internet, even though there is no connection (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/656713
<ara> didrocks, well, it tried to download about 60-something packages, and it fails one by one, so, yes, it makes it slower
<ara> I guess it can be solved in a SRU, as it does not fail, but as it should know that there is no internet connection, my guess is that it should skip that part
<didrocks> ara: ok, I probably didn't pay attention to that, it was an acceptable time when not looking at it. Thanks :-)
<didrocks> ara: I just tried to trick it and try "install mp3 support and updates". Was pretty slow when clicking on next, not sure it's related, I will try without that
<didrocks> (like a min here to go to next screen)
<didrocks> and with dummy partition table (just 2 tables, no lvm, no raid, nothing fancy)
<ara> so how's the conversation going in the release sprint?
<cjwatson> quiet
<ara> :)
<ttx> ara: as in "completely silent" quiet
<cjwatson> ttx: as in "god I need coffee" quiet.  speaking of which ...
<cjwatson> ara: 656165> hm, can you check your /etc/apt/sources.list after installation?  does it have (es.)archive.ubuntu.com entries?
<cjwatson> 'cos the logs suggest it might not and that would be bad
<ara> cjwatson, mmm, I don't have access to it anymore. I will try again as soon as I finish the installation IÂ¡m doing now, and will let you know
<cjwatson> as in respin bad
 * cjwatson burns a test image
<ara> cjwatson, but I think it did have it, because I remember checking that (to see if the bug with the source list was solved)
 * ara listens to Bowie's Space Oddity as perfect OST for release testing
<nigelb> heh
<ara> Riddell, rekonq keeps crashing for me under KVM, have you tried that?
<ara> bug 650934
<ubot4> Launchpad bug 650934 in rekonq (Ubuntu) "Rekonq crashes in a KVM with 800MB ram (affects: 1) (heat: 487)" [Undecided,New] https://launchpad.net/bugs/650934
<Riddell> ara: i've never used kvm
<ara> I love the retro use of the stereo on that song :)
<ara> cjwatson, I am testing again bug 656165
<ubot4> Launchpad bug 656165 in ubiquity (Ubuntu) "Language support incomplete after installation (affects: 2) (heat: 12)" [Undecided,New] https://launchpad.net/bugs/656165
<cjwatson> as am I
<cjwatson> and ev apparently ...
<ev> it's a party bug :)
<ara> cjwatson, I cannot reproduce it now, so it seems that it was a transitional network problem, or something like that
<cjwatson> ara: I think it is very probable that it depends on latency to the archive mirror.  that said there does seem to be something odd
<ev> didrocks: was your removal of the note about not being able to use Startup Disk creator to create 10.04 images from Ubuntu 10.10 intentional?
<ev> in: https://wiki.ubuntu.com/MaverickMeerkat/TechnicalOverview?action=diff&rev1=96&rev2=95
<didrocks> ev: hum, no I read probably the other way around (creating 10.10 disk from lucid). Fixing it then, sorry
<ev> no worries
<ev> I just wanted to be sure you didn't know something that I was unaware of :)
<didrocks> ev: that would we weird on usb creator :-)
<didrocks> I'm updating the unity part as well
<ev> heh
<ev> cool, thanks
<ara> cjwatson, how is the investigation on the OEM issue (respin-wise)?
<cjwatson> ara: could you be more specific, please?
<ara> cjwatson, bug 650703
<ubot4> Launchpad bug 650703 in ubiquity (Ubuntu Maverick) (and 1 other project) "oem-config-prepare works, but oem-config fails to start after reboot (affects: 2) (heat: 10)" [High,Incomplete] https://launchpad.net/bugs/650703
<ev> ara: we need someone who can reproduce it to provide us with upstart debugging information
<ev> so --debug on the kernel command line
<cjwatson> ara: and since we can't reproduce, it's hard to consider it a respin candidate at the moment
<cjwatson> ara: also, as Rick pointed out, the primary audience of oem-config is OEMs, who aren't constrained to using just the release image, so this can be fixed post-release if need be
<ara> cjwatson, sure thing, thanks for the update
<cjwatson> but indeed, what ev said
<ara> cjwatson, ev, Riddell: Kubuntu amd64 OEM (DVD) just crashed for me
<ara> bug 656819
<ubot4> Launchpad bug 656819 in ubiquity (Ubuntu) "Ubiquity crashed while installing Kubuntu DVD amd64 OEM mode (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/656819
 * Riddell still downloading amd64 dvd
<Riddell> hum, that doesn't look too good
<cjwatson> Oct  8 10:28:19 ubuntu in-target: Failed to fetch http://extras.ubuntu.com/ubuntu/dists/maverick/main/source/Sources.bz2  Hash Sum mismatch
<cjwatson> the consequence is obviously bad
<cjwatson> but I think that's why it's happening
<cjwatson> (this is essentially web cache skew - you have a "transparent" proxy between you and the internet, probably)
<cjwatson> wonder why it's causing sources.list to be completely missing though; that's bizarre
 * pitti yays at the empty "Daily CD health checks" email
<cjwatson> in fact, that failure ought to be entirely ignored
<robbiew> cjwatson: working through issues documented in Lucid's release notes for any carry over....was bug 345126 fixed for Maverick?
<ubot4> Launchpad bug 345126 in partman-auto (Ubuntu Lucid) (and 3 other projects) "Installer creates too small swap partition (hibernation fails) (affects: 6) (heat: 19)" [High,Won't fix] https://launchpad.net/bugs/345126
<robbiew> ev: ^ ?
<ev> robbiew: doesn't appear to have been.
<robbiew> ack...release noting
<ev> robbiew: best to check with cjwatson though.  Perhaps I'm looking in the wrong place for the change.
<robbiew> ev: fair'nuf
<cjwatson> shouldn't think so, given the won't fix
<cjwatson> oh, that was for lucid.  but no, it wasn't
<robbiew> skaet: ^^^ fyi,  another reason why we need to be able to have 2 distros open for development in launchpad :/
<wgrant> We can technically create natty now, but we can't have it accepting uploads.
<robbiew> wgrant: ah..so we could target bugs?
<ScottL> was anyone wondering about a ubuntu studio respin for ia32-libs?
<wgrant> robbiew: Right. The publisher will no longer combust if it sees an uninitialised series.
<wgrant> But it's probably a bit late to be considering that now.
<wgrant> (this has only been possible for a month or two)
<robbiew> wgrant: ah...cool...and yes, no need to rock the boat ;)
<wgrant> But for next time we should probably test and do that.
<ScottK> ScottL: Do you want to respin for ia32-libs?
<cjwatson> wgrant: what would the status of the new distroseries be?
<wgrant> cjwatson: Probably Experimental.
<wgrant> Since it can't be Development.
<ScottL> ScottK, i believe YokoZar would like the respin and i do not object and can support it
<cjwatson> indeed, can only have one of those
<ScottK> cjwatson: Do you have any objections to an Ubuntu Studio respin?
<ScottL> ScottK, i'm about to leave to take kids to school and go to work, i will be back on as scott-work in about 1.5 hours
<ScottK> ScottL: OK.  I'll accept it if cjwatson thinks it's OK.
<doko> hmm, I think I should reject the just uploaded libapache2-mod-python, because it's on the server cd
<ScottK> doko: I was just about to suggest that.
<cjwatson> ScottK: no objections
<ScottK> OK.  Thanks.
<ScottK> cjwatson: ia-32libs is built, so would you please respin Ubuntu Studio amd64 in an hour?
<ScottK> ScottL: ^^^
 * ara goes for a late lunch
<cjwatson> ScottK: ack
<scott-work> ScottK:  i read the logs, thank you (and cjwatson ) for your assistance
<robbiew> skaet: I pruned the resolved Lucid issues from https://wiki.ubuntu.com/MaverickMeerkat/ReleaseNotes
<skaet> robbiew:  thanks!
<cjwatson> scott-work: respin running
<cjwatson> ScottK,GrueMaster: do either of you know what the story is with Kubuntu arm preinstalled-desktop (not mobile) images?  They were published for RC, but there's only one entry in the ISO tracker, which is "Kubuntu Desktop Arm (omap)" (presumably omap3?) with a wrong link in its info
 * ScottK looks at GrueMaster
 * ScottK recalls he tested something ....
<cjwatson> ScottK,GrueMaster: so I don't know how the omap4 one got tested, and it's going to make it difficult to automatically emit publication commands for omap4
<cjwatson> scott-work: ubuntustudio reposted
<Riddell> cjwatson: for RC the Kubuntu arm preinstalled-desktop images were on the ISO tracker as Kubuntu Netbook Arm (omap)
<GrueMaster> cjwatson: I have not tested the final release for kubuntu, and am not in a position to test them this week.
<scott-work> cjwatson: thank you
<cjwatson> Riddell: *blink* ok, that's even more confusing, but is no help anyway as that's still only one image not omap(3) + omap4?
<cjwatson> there's only Kubuntu Desktop Arm (omap) there now rather than Kubuntu Netbook Arm (omap), which I think is probably an improvement in terms of accuracy, but ...
<didrocks> ev: does my proposal to bug #656777 make sense? (well, too late for maverick in any case, but it can help for natty)
<ubot4> Launchpad bug 656777 in ubiquity (Ubuntu) "Wrong keyboard selection with starting directly ubiquity (affects: 1) (heat: 6)" [High,Confirmed] https://launchpad.net/bugs/656777
 * ev ponders
<Riddell> cjwatson: unfortunately I don't know how the iso testing site works enough to fix it
<ev> didrocks: an inidicator that opens a dialog of options is, I think, going to be the best solution in Natty.  I talked to cjwatson about it, and trying to guess the keyboard on language alone has been attempted before and had to be quickly reverted.
<didrocks> ev: sure, but setting it as default can also be interesting. My point is that you already select "fr oss" in the keyboard layout selection dialog when you choose "French" in the first dialog. So, you are already making an assumption. Making the same assumption from the start will make more sense, isn't it?
<cjwatson> Riddell: it's more a question of what we should be doing.  if we should be publishing both omap and omap4, I can work around it
<cjwatson> didrocks: it's quite subtle for different languages
<cjwatson> and in gfxboot, there's a menu so you get to change the assumption if it's wrong
<cjwatson> anyway, I just discussed this with ev in person
<didrocks> cjwatson: if I understand correctly, you are afraid of false positive and think it's better to only set a default on a screen when you can change the layout if it doesn't fit, right?
<cjwatson> I'm not afraid of false positives, I *know* we will get it wrong a significant percentage of the time :)
<cjwatson> we could fiddle with default assumptions, certainly, but we have to have an indicator anyway so that you can override
<Riddell> cjwatson: we should publish both
<didrocks> cjwatson: fair enough then :)
<didrocks> and that will enable changing for setting a passphrase with the correct layout too, so fine with me
<cjwatson> us
<cjwatson> uh
<cjwatson> didrocks: the keyboard layout is asked properly before passphrase
<cjwatson> so that really isn't an issue already, as far as I know
<cjwatson> unless you mean network passphrase
<didrocks> cjwatson: sorry, do you mean, in network manager for wifi key?
<didrocks> yeah
<cjwatson> best be specific about these things :)
<didrocks> cjwatson: sorry, I should have been, right :-)
<cjwatson> https://lists.ubuntu.com/archives/ubuntu-users/2004-September/001405.html  https://lists.ubuntu.com/archives/ubuntu-users/2004-September/002211.html
<cjwatson> ^- from last time we tried to infer keyboard layout from language and not provide a way to override :)
<GrueMaster> Ok,I am starting on the Ubuntu Dove netbook image.  Live is booting fine, no glaring issues.  Starting installer then off to a meeting.  Will update tracker info when I get back.
<Riddell> talking about meetings, do we have a release team meeting today?
<didrocks> cjwatson: again, I understand the rational and it's better to play it safe, right :-) In any case, the french loco team have its own respin, so it was more a "for natty" thing
<didrocks> cjwatson: I just know now that the rationale is "propose a default on a screen you can override the option"
<cjwatson> Riddell: not afaik ...
<doko> ScottK, cjwatson: universe still open?
<doko> about bug #656926
<ubot4> Launchpad bug 656926 in openocd (Ubuntu) "ftbfs - on maverick fails on armel - sync openocd from debian unstable to universe (affects: 1) (heat: 8)" [Medium,Triaged] https://launchpad.net/bugs/656926
<cjwatson> just about
<cjwatson> for a bit over 18 more hours
<cjwatson> please don't do anything that will take past end of Saturday to build, though
 * doko disables the testsuite in gcc-snapshot ...
<doko> ;)
<doko> hmm, there are now cairo-dock-plugins *and* cairo-dock-plug-ins in maverick ...
<slangasek> cjwatson: oh good, it wasn't me then :-)
<ScottK> doko: cairo-doc-plugins as no binaries so the duplication doesn't hurt anything.
<doko> ScottK: why not remove it and blacklist?
<doko> ScottK: didrocks will ask/clearify with upstream
<ScottK> OK
<ScottK> doko: cairo-dock-plug-ins was never in Debian.  Now that cairo-dock-plugins is in Debian we should probably follow Debian.
<doko> cjwatson: I just see that libgpiv3 still depends on libhdf5-serial-1.6.6-0 | libhdf5-1.6.6-0 on armel, but it's not shown in NBS
<cjwatson> which one of those packages should be in NBS?
<doko> libhdf5-serial-1.6.6-0, there's only libhdf5-serial-1.8.4
<doko> or maybe I did remove it?
<cjwatson> it's already removed
<cjwatson> so that would just be libgpiv3 being uninstallable on armel, presumably?
<cjwatson> there's no uninstallability report for universe because it takes too long to run :(
<doko> yes, currently preparing a no change upload
<didrocks> doko: I think the upstream package doesn't agree with the debian maintainer or something like that, I'll try to clarify the situation with them
<doko> fun ...
<doko> cjwatson: would it be possible to run it manually once a few weeks before release?
<cjwatson> doko: I'm not sure.  The last time I tried to run it I got bored after six hours, so I don't actually know how long it would take
<ScottK> doko: Will leaving libgpiv in queue for a while block any further work of yours?
<doko> ScottK: if you can give back pygpiv later, no
<doko> I'll be away soon
<ScottK> I'll go ahead and accept it then.
<jdstrand> skaet: is there anything more I need to do with bug #656173 in terms of making sure it gets a release note?
<ubot4> Launchpad bug 656173 in libvirt (Ubuntu) (and 1 other project) "libvirt no longer probes chained backing stores (affects: 1) (heat: 8)" [Undecided,Won't fix] https://launchpad.net/bugs/656173
<jdstrand> (I just updated the bug)
<ScottK> (that way I'm not required to remember one more thing for later)
<jdstrand> skaet: hi btw :)
<cjwatson> hm, kubuntu oem breaks
<cjwatson> I think we'll need to fix that in an SRU
<cjwatson> (this is different from ara's report, which I couldn't reproduce)
<cjwatson> oh, wait - I bet this is only if you have no net access
<cjwatson> ... no
<ScottK> Doesn't oem need to work on the ISO?
<cjwatson> no, because it's typically used by OEMs who are free to apply updates
<cjwatson> it's obviously very nice if it does but it's not entirely critical
<ScottK> Right.  OK.
<cjwatson> http://paste.ubuntu.com/508934/ <- patch
<ScottK> Oops.
<kees> I'd like to upload a fix for bug 632206. it seems only ubuntustudio ships anything from the wine1.2 package. is this okay to upload?
<ubot4> Launchpad bug 632206 in wine1.2 (Ubuntu) "Wine (& Crossover) cannot activate Securom modules after upgrading to Maverick (heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/632206
<ScottK> kees: I think we're in zero day SRU territory for Ubuntu Studio.
<kees> ScottK: as in, it's okay to upload wine1.2 now, or that I should wait?
<ScottK> kees: You can upload it to -proposed now.
<kees> okay, I will rebuild for -proposed. thanks!
<kees> ScottK: okay, it's in proposed. what's the 0-day SRU procedure? (obviously no 7-day delay...)
<kees> ScottK: oh, and it seems that Yokozar may have another upload for a full micro release bump. ah, well, either will fix the issue.
<slangasek> ^^ apologies for xdeb, this is very late in the coming but it's a needed bugfix to make one of the core features of xdeb introduced this cycle usable for non-trivial cases.  So if someone could review (and hopefully approve) that last minute universe package, I would be grateful
<slangasek> ScottK: ^^ you may be the only one around at this hour?
<pitti> slangasek: looking
<slangasek> pitti: thanks!
 * pitti boggles at the debdiff
<pitti> slangasek: do you build these sources on linaro, somewhere that doesn't add X-Launchpad-Bugs-Fixed:?
<slangasek> pitti: Linaro would add it; I built on Ubuntu; I think the missing X-Launchpad-Bugs-Fixed: is because of the lack of whitespace after the "LP:"
<pitti> ok, so launchpad's debdiff isn't lying, the changelog really is that strange
<pitti> ah
<slangasek> I wasn't sure if that was going to be an issue and didn't check the .changes before upload
<pitti> slangasek: just asking because recently I found several uploads in SRUs which didn't have it
<pitti> slangasek: we can just close it manually, no big deal; I just wondered if that was due to a different lsb_release or so
<slangasek> not in this case
<slangasek> I have from time to time been known to accidentally build my source packages in Debian instead of Ubuntu, but not this time :)
<pitti> slangasek: in the aptutils.py there might be a missing "if options.debug:", FYI
<slangasek> pitti: I know that message is being printed out in non-debug mode, and didn't consider it a problem
<slangasek> (it's not my code, or I'd be a bit more decisive with my answer)
<pitti> 'k, accepted
<slangasek> thanks!
<pitti> ah, my wife returs home, which means -> good night!
<slangasek> 'night :)
<pitti> will get online tomorrow morning, in case we need more help
 * slangasek goes back to evil hacks to allow cross-bootstrapping under qemu-arm-static
<slangasek> incidentally, there are two uploads in the queue, dkms and edubuntu-artwork, that obviously imply respins... anyone know if those are meant to be accepted/rejected?
<ara> night pitti!
<ScottK> slangasek or cjwatson: I've been leaving two Universe packages in the queue in case you need to stimulate a publisher run.  I've been ~offline most of the day, so don't have any state about where we are WRT potential respins.  Please let me know when you think we're past that so I can go ahead and accept them.
<slangasek> ScottK: I think you should go ahead and accept them; there shouldn't be any more seed/task changes now
<ScottK> slangasek: Thanks.  Will do.
<ScottK> Done.
<ScottK> slangasek: I think we should also get rid of the release pocket version of edubuntu-artwork in queue and assume it's the -proposed one that will get used.
<ScottK> Queue is all -proposed now.
#ubuntu-release 2010-10-09
<slangasek> ScottK: I was going to check with highvoltage / stgraber on that one since I think it's really their call whether they wanted a respin for it
<ScottK> slangasek: It was there before the last respin, so I'm assuming not.
<ScottK> It's trivial to reupload in any case if needed.
<ScottK> Ah.  Shoot.
<ScottK> The last respin I was thinking about was Studio, not Edubuntu.
<slangasek> highvoltage, stgraber: ping ^^
<ScottK> At least rejecting when I shouldn't is more reversible than accepting when I shouldn't.
<slangasek> ScottK: indeed :)
<ScottK> It seems a bit odd that http://cdimages.ubuntu.com/kubuntu/releases/10.10/rc/ just has dvd images.  I'd expect either a full set or nothing there?
<slangasek> CDs go to releases.ubuntu.com/releases/10.10; cdimages.ubuntu.com/kubuntu/releases/10.10 is for overage
<slangasek> and cdimages.u.c doesn't have room to carry releases.u.c as well as what it already carries
<wgrant> Is extras.u.c broken?
<wgrant> I'm not behind a proxy, and I'm getting hash mismatches on Sources.bz2.
<ScottK> wgrant: By design, but that's probably not what you're talking about.
<wgrant> Heh, indeed.
<wgrant> The PPA itself is fine, so the sync is broken.
<ScottK> slangasek: Thanks.
<elmo> wgrant: example sources.list line?
<wgrant> elmo: It was a fresh install.
<wgrant> deb http://extras.ubuntu.com/ubuntu maverick main
<wgrant> deb-src http://extras.ubuntu.com/ubuntu maverick main
<wgrant> I suppose I should check the indices manually.
<elmo> wgrant: is it reproducable?
<wgrant> elmo: Yes.
<elmo> hmm
<elmo> it's not for me, and the timestamp for everything but the Releases.gpg dates back to October
<elmo> actually even that does
<elmo> hmm
<elmo> so, I see why all the timestamps are so old
<elmo> but if you can reproduce it, I'd love to get more detail
<elmo> manually checking the Sources.bz2 and it seems to match
<wgrant> elmo: Packages.bz2 for i386 and amd64 is 64a543afbb5f4bf728636bdcbbe7a2ed0804adc2
<wgrant> (checkexd from a few hosts)
<wgrant> Oh, right, that matches.
<wgrant> Fail.
<wgrant> Was looking at the wrong line.
<wgrant> Then why is it whinging, I wonder.
<wgrant> Er.
 * elmo doesn't like the sound of that
<wgrant> So.
<wgrant> I can see that the installer (alternate CD) encountered the same error, so there was probably no proxy involved.
<wgrant> The index in /var/lib/apt/lists was pretty clearly for the primary archive, which explains the hash mismatch.
<wgrant> Moving it out the way makes the error mysteriously vanish.
<elmo> sorry, which index?
<elmo> I'm wondering if it's because the Sources.bz2 is empty
<wgrant> extras.ubuntu.com_ubuntu_dists_maverick_Release
<elmo> and that messes with the installer's head
<wgrant> Somehow the installer grabbed the archive.ubuntu.com file instead.
<elmo> wgrant: oh, err, near
<elmo> s/near/neat
<wgrant> Erm.
<wgrant> The first mention of extras.ubuntu.com in the installer log:
<wgrant> Oct  8 23:57:58 in-target: Hit http://extras.ubuntu.com maverick Release.gpg
<wgrant> I wouldn't expect a cache hit on the first update, really.
<wgrant> I guess I'll run the installer in a VM and see what happens.
<elmo> wgrant: oh, parting shot - ISTR cjwatson said ara had reported a similar bug
<elmo> wgrant: might want to see if he already debugged it there
<wgrant> elmo: Aha, I see something in backscroll. Thanks.
<wgrant> It was dismissed as proxy skew.
<wgrant> But this is a little suspicious.
 * wgrant will install in a VM and watch closely.
<wgrant> Hm.
<wgrant> Reproduced.
<wgrant> Just after the user details are entered and it goes off and does its apt config thing, /var/lib/apt/lists grows a extras.ubuntu.com Release file which looks suspiciously like a primary archive Release from the 21st of May.
<GrueMaster> I saw the same thing on the dove (armel) image, which is worse as there are no package lists (blank or otherwise) on that location.
<wgrant> Well, that's a bit more odd.
<wgrant> Since I can see where it's getting this file.
<wgrant> But that doesn't explain your case.
<GrueMaster> Dove uses thelive image setup same as x86.  I do not see it on the preinstalled images.
<wgrant> It's in the apt-mirror-setup udeb.
<wgrant> So you probably do have it.
<GrueMaster> Wheee.  Lucky me.  :p
<GrueMaster> I wasn't sure what to file it under, and I have been onsite at TI all week, making normal testing challenging at best.
<wgrant> Yeah, apt-setup is buggy.
<wgrant> Easiest fix is probably to touch Release on extras.ubuntu.com.
<wgrant> elmo: ^^ not so bad after all.
<elmo> wgrant: sorry - how would touching the file help?
<wgrant> elmo: The mtime of the bad index is a couple of days ago, but the one on extras.ubuntu.com is from September. So it won't grab a fresh copy.
<wgrant> If the one on the server is newer, it should all work fine, I suspect.
<elmo> wgrant: right, but I'm curious as to where on earth this bad index comes from
<wgrant> elmo: The apt-setup udeb has an old signed copy of Release and Release.gpg.
<wgrant> Once it sets up the mirrors, it prepopulates apt's list cache with those.
<elmo> ah, ok, I see
<elmo> that's err, broken
<elmo> but OK
<wgrant> It is broken, yes.
<wgrant> But probably better to work around than reroll...
<elmo> oh, god yes
<wgrant> It calls this:
<wgrant> apt-setup-signed-release archive.ubuntu.com "$file"
<wgrant> apt-setup-signed-release then greps out lines that it should populate.
<wgrant> Except that the regex is now "^'.*'"
<wgrant> Maybe to handle mirrors, I guess.
<elmo> hmm
<wgrant> Hm?
<wgrant> I see Release.gpg is new, but not Release itself.
<elmo> yeah
<elmo> because that's what it is on the PPA
<elmo> and it keeps getting overriden by rsync
<wgrant> Ah. Fun.
<elmo> I guess I'll disable the rsync until we have something in the PPA
<elmo> (it was broken anyway ;-)
<elmo> wgrant: is it easy for you to spin up a re-test?
<wgrant> elmo: Sure.
<wgrant> It only takes a few minutes to get to that stage.
<wgrant> elmo: That's fixed my real installation. But the installer apparently fails to retrieve it ("Err http://extras.ubuntu.com maverick Release" shows up in syslog, which isn't awfully helpful). But it's otherwise working, and an apt-get update after it finishes looks like it should work.
<elmo> huh
<wgrant> Yes.
<elmo> wgrant: anything useful in the installer syslog?
<wgrant> Anyway, looks like it's fixed unless you look at the logs.
<wgrant> Get:8 http://extras.ubuntu.com maverick Release [57.3kB]
<wgrant> Err http://extras.ubuntu.com maverick Release
<wgrant> Thankyou, apt, for your wonderful errors.
<wgrant> I'll let it finish installing and confirm that an update afterwards works OK.
<wgrant> elmo: apt-get update works fine on the installed system.
<wgrant> So unless you look at the installer syslog it looks like it works perfectly.
<wgrant> Thanks.
<elmo> cool - do you want to/are you going to follow up to the bug or should I?
<wgrant> I filed bug #657176 about the general apt-setup issue.
<ubot4> Launchpad bug 657176 in apt-setup (Ubuntu) "apt-setup-signed-release doesn't restrict its actions to the given archive (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/657176
<elmo> ok
<stgraber> slangasek,ScottK: I'm not exactly sure what that change is.
<stgraber> mvo sent us an e-mail about an upgrade fix for edubuntu-artwork
<stgraber> if that's this upload, then we won't need to respin as it only affects upgrades and you can't upgrade using the DVD
 * stgraber is trying to find a diff
 * stgraber found it
<slangasek> ok - needs to be reuploaded to -proposed, then
<stgraber> right, I'll ask mvo to do that
<stgraber> hmm, actually I guess I can just do it, just need to get the .dsc from LP (as it seems I can still get it even from reject uploads)
<wgrant> Right, we keep all primary archive uploads forever.
<stgraber> ok, re-uploaded to -proposed
<stgraber> slangasek: can we get that to -updates by the time 10.10 is out ? so users who upgrade on release day will get the fix ?
<pitti> good morning
<pitti> anything I should help out with?
<robbiew> pitti: well...Kubuntu manual partitioning test is still outstanding...but I don't think we need you to run that :P
<robbiew> stgraber: any plans on running the upgrade tests for Edubuntu?  I noticed they are still marked untested
<marjo> robbiew: will you take care of working with kubuntu release team re: ARM?
<robbiew> marjo: yeah...I'll "take care" of it ;)
<marjo> robbiew: thank you sir1
<marjo> sir!
<AlanBell> window 74
<AlanBell> gah, sorry
<marjo> skaet: any idea what happened to the kubuntu mobile images? i can no longer access them from iso.qa.ubuntu.com
<skaet> marjo: ???
<robbiew> is this the armel stuff?
<marjo> robbiew: yes
<marjo> i was going to submit bugs on behalf of mpoirier who did the testing
<marjo> so i can mark those tests failed
<robbiew> I have no idea...were they there yesterday?
<cjwatson> wgrant: thanks for diagnosing that.  looks like we've dodged the bullet for maverick?
<marjo> robbiew: those are the images that mpoirier tested
<cjwatson> which images (URLs)?
<marjo> robbiew: i'm submitting bug reports anyway, since i can't mark those tests failed without a bug number
<robbiew> marjo: ok
<robbiew> FTR, I'm not holding up the release for Kubuntu Mobile on OMAP3/4 bugs anyway ;)
<wgrant> cjwatson: Yep.
<marjo> cjwatson: http://iso.qa.ubuntu.com/qatracker/test/4741
<cjwatson> kubuntu-mobile should be http://cdimage.ubuntu.com/kubuntu-mobile/ports/daily-preinstalled/current/ or thereabouts
<cjwatson> iso.qa's download links seem busted
<marjo> cjwatson: ack
<cjwatson> but I don't think that's something we can fix without db access?
<wgrant> cjwatson: The apt error during installation is a bit odd, though.
<marjo> robbiew: ack
<marjo> ogra_ac: hi
<ogra_ac> hi
 * ogra_ac tries to think clear, i just stepped off the train, totally jetlagged
<marjo> ogra_ac: ok, thx for the warning
<marjo> ogra_ac: any chance you can help test kubuntu on ARM? http://iso.qa.ubuntu.com/qatracker/test/4739
<ogra_ac> hmm
<ogra_ac> not today anymore, i can give it a try tomorrow though
<marjo> ogra_ac: ack
<ogra_ac> thats only omap3, right ?
<ogra_ac> oops
<cjwatson> both omap3 and omap4 are built, despite the fact that the tracker only lists one
<cjwatson> (I already talked with marjo about this; we'll rationalise arm image handling on the tracker later)
<cjwatson> (not for 10.10)
<ogra_ac> hmm, k
<ogra_ac> i dont know who enabled omap4
<marjo> ogra_ac: mpoirier already tested omap3 and omap4 but i don't think he did kubuntu desktop on ARM
<marjo> http://iso.qa.ubuntu.com/qatracker/test/4739
<cjwatson> did anyone enable it specifically?  we probably just shoved it in
<ogra_ac> we dont support live images on omap
<cjwatson> kubuntu isn't a live image
<ogra_ac> only preinstalled
<ogra_ac> the testcase says live
<cjwatson> the image type is 'preinstalled-desktop'
<cjwatson> the testcase lies
<marjo> ogra_ac: that's what mpoirier confirmed
<ogra_ac> ok
<cjwatson> (or possibly 'preinstalled-mobile', depending on whether this is kubuntu or kubuntu-mobile)
<marjo> ogra_ac: check out: https://bugs.launchpad.net/ubuntu/+bug/657281
<ubot4> Launchpad bug 657281 in ubuntu "Kubuntu Maverick on Omap3 & Omap4: screen goes black and never comes back (affects: 1) (heat: 6)" [Undecided,New]
<ogra_ac> marjo, to be honest i dont really care much about kubuntu on arm, the kubuntu community confirmed they had testers, thats the only reason why i enabled kubuntu on omap3 around beta
<ogra_ac> i'm fine to do a last minute test tomorrow, but i wonder where the mentioned testers are
<ttx> skaet, Daviey: checkin in from stpancras: everything alright ?
<marjo> ogra_ac: thx
<skaet> ttx,  hi.   so good so far.
<Daviey> ttx: Did you manage to get the earlier train ?
<ttx> I could have get it.. but I chose to have lunch instead
<ttx> skaet: I won't be around this afternoon, arriving home ~10pm
<ttx> so I guess I'll check in sunday morning to check everything is alright :)
<Daviey> ttx:  heh, surely the food french side is better?
<ttx> sure, but it's late :)
<skaet> ttx,  safe travels, thanks for letting me know.
<cjwatson> I'm off again.  text me if you need me
<Daviey> ttx: What time will you have phone coverage?
<Daviey> (just incase)
<ttx> I'll have phone coverage over most of the travel, except while under the sea
<Daviey> groovy.
<ttx> just leave me a text message if anything springs up
<ttx> Daviey: how is cloud10 doing ?
<Daviey> ttx: Just finishing the merge from the design team, then will chase IS about access.  Ng said he was working today, so if nobody else - i will poke him.
<Ng> there are several of us available today, although the UKers will be lunching shortly
<robbiew> Ng: what's for lunch?
<ttx> microsize sandwiches, right
<Ng> robbiew: we're considering going to pizza express
<ttx> robbiew: enjoy the Coriander tonight
<robbiew> Ng: sounds good...ol'faithful
<ttx> I shouldn't tell where robbiew is having dinner tonight on a public channel. His fanclub might turn up.
<marjo> ttx: thx for introducing me to Coriander
<robbiew> fanclub?....yeah right?
<ttx> marjo: thank those who introduced me to it :)
<Daviey> Ng: OK, great - who is vanguard?
<robbiew> marjo: ttx: your welcome ;)
<robbiew> you're
<Daviey> if Daviey wasn't quite so lazy, he would walk the 30 steps to speak to you in person.
<nigelb> heh
<Ng> Daviey: by this point things should have tickets, and almost nobody is working today, so nobody is focussed on typical vanguard duties
<Daviey> Ng: Ok, i will walk over
<Daviey> :)
<nigelb> Daviey: Nothing like sitting next to each other and IRC-ing :p
<nigelb> robbiew: btw, might want to +m #ubuntu-release-announce, 10.10.10 is hitting in the east slowly :)
<robbiew> nigelb: heh...so you assume we are releasing on 00:00:00 UTC on 10.10.10
<wgrant> No, but everyone else does.
<nigelb> exactly
<robbiew> good for them :D
<nigelb> robbiew: we know you get a kick out of respin 10 mins before release :)
<robbiew> heh
<robbiew> creates dramam
<robbiew> drama
<ttx> you mean it's not out yet ? Damn, I need to go back to the office.
<nigelb> lol
<robbiew> we have to keep OMG!Ubuntu from pre-announcing
<robbiew> ;)
<Daviey> nigelb: :)
<nigelb> robbiew: true that.
<wgrant> robbiew: Oh, they haven't already?
<ttx> wgrant: they don't work on weekends.
<ttx> emphasis on *they*
<robbiew> well...after my respin last release...it wouldn't be wise
<wgrant> Heh.
 * ttx can almost feel skeat's bad eye on robbiew.
<nigelb> Haha
<wgrant> !!
<marjo> robbiew: don't even think of it
<ttx> we should have a specific deliverable that nobody uses and without any tests attached, just so that robbiew can respin it at the last minute. I don't know... Kubuntu on ARM in ap-southeast AMI
<nigelb> robieubuntu - resput at the last minute of ubuntu releases.
<nigelb> *spun
<ttx> ok, will be back in a few, yay StPancras free wifi
<ScottK> Is the omap4 kernel that's sitting in unapproved for -release really meant to be there?
<ogra_ac> ScottK, whats the changelog entry ?
<ogra_ac> there should be an SRU
<ogra_ac> nothing that needs approval before release
<ScottK> http://launchpadlibrarian.net/57298257/linux-ti-omap4_2.6.35-903.15_source.changes
<ogra_ac> looks right
<ScottK> ogra_ac: Then I guess it was uploaded to the release pocket by mistake.
<ogra_ac> thats the planned SRU
<ScottK> Except not uploaded to -proposed.
<ogra_ac> oh, might be, asl tgardner
<ogra_ac> *ask
<ogra_ac> i dont mind if it goes into the release indeed :) but it was initially planned as SRU
<robbiew> cjwatson: should bug 653134 be marked FixReleased for the lupin task?  And do we still need to releasenote it per comment 30?
<ubot4> Launchpad bug 653134 in lupin (Ubuntu Maverick) (and 3 other projects) "Can't boot Ubuntu after an upgrade from 10.04.1 to 10.10 (affects: 3) (heat: 20)" [High,Triaged] https://launchpad.net/bugs/653134
<ScottK> Unless you're up for retesting all the omap4 images, I suspect you do mind if it goes in ...
<ScottK> robbiew: We're at the final freeze for Universe now.  There's one package in queue that I'm going to reject since it's a very minor change and then we're done.
<ogra_ac> ScottK, there is only one omap4 image to test and that change wont affect it at all, it only affects a specific board which isnt publically available anyway
<robbiew> ScottK: \o/ thanks!
<ScottK> You still have to requalify the image.
<ogra_ac> indeed
<ScottK> ogra_ac: I'm going to reject that as I'm certain a release pocket upload isn't what we want.
<ogra_ac> k
<ScottK> If it turns out that's wrong, they can reupload.
<ogra_ac> its not wrong
 * robbiew heads out for lunch
<ogra_ac> doesnt matter where in the archive it lives as long as we get it in at some point
<ogra_ac> (from our side ... )
<ScottK> Right.  Done.
<ScottK> robbiew: The -release queue is clear now.
<robbiew> ScottK: thank you
<ScottK> You're welcome.
<ScottK> stgraber: edubuntu-artwork is now in the queue for -proposed twice.  Please let us know which one we should keep (based on debian/changelog they are dupes, but please let us know)
<marjo> skaet: persia is testing kubuntu desktop on arm, so i think we're covered
<skaet> thanks persia, marjo. :D
<persia> Mind you, I don't have graphics acceleration or enough RAM to meet minimum requirements, so I'm not expecting more than "Yeah, it boots and the base environment (slowly) comes up if one waits an hour or so".
<marjo> persia: understood & that would be sufficient
<ev> robbiew: http://njpatel.blogspot.com/2010/07/gwibber-concept-part-1.html
<skaet> Riddell,  ScottK,  is there an updated page for: https://wiki.kubuntu.org/MaverickMeerkat/RC/Kubuntu
<skaet> or more specifically - what will be the path that https://wiki.kubuntu.org/MaverickMeerkat/FinalDraft/Kubuntu
<skaet> will be using.   Final or FinalDraft?
<ScottK> Riddell will need to answer that.  I was mostly offline for $WORK stuff this week and have no idea.
<ScottK> I've asked on #kubuntu-devel to see if anyone else knows.
<wgrant> robbiew: Now now, you'll give OMG probable cause to announce the release if you keep doing that :P
<robbiew> wgrant: we wouldn't want that....would we?
<persia> Tends to make mirrors annoyed when it takes *hours* to process the last pulse of .pool because of overexcited folk
<marjo> robbiew: you really know how to make release days exciting
<ScottK> persia: Hopefully they've got it already since we haven't made any changes in the archive in over 12 hours.
<ScottK> Anyone else on the release team is welcome to join in working on the list at https://bugs.launchpad.net/~ubuntu-release and give people the sad news that $YOURPETBUG won't get fixed this cycle.
<persia> ScottK, Most release mirrors only sync once daily, and not everyone gets pulsed.  That said, any sane release mirror is likely to be paying special attention today
<persia> (plus there needs to be a pulse once the symlinks are created)
<ScottK> Oh, right.
<ScottK> Forgot about that bit.
<robbiew> ogra_ac: do you all need to release note bug 626749?
<ubot4> Launchpad bug 626749 in flash-kernel (Ubuntu Maverick) (and 1 other project) "flash-kernel tries to use MTD devices on OMAP4 when no flash-kernel.conf exists (affects: 1) (heat: 10)" [Medium,Confirmed] https://launchpad.net/bugs/626749
<ogra_ac> robbiew, not for the images, no
<ogra_ac> its on a special case device in a cornercase situation, NCommander is supposed to fix it though since his change to the subarch detection created the issue
<ogra_ac> (thats why i assigned it to him)
<robbiew> ogra_ac: ack..thnx
<robbiew> ogra_ac: so....should we add bug 657281 to the ARM page?
<ubot4> Launchpad bug 657281 in ubuntu "Kubuntu Maverick on Omap3 & Omap4: screen goes black and never comes back (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/657281
<robbiew> or does Kubuntu have their own ARM release notes page?
<ogra_ac> robbiew, well, we dont support kubuntu
<ogra_ac> its a community thing to test it which apparently didnt happen yet
<robbiew> ogra_ac: probably should be added to Kubuntu's page
<robbiew> Riddell: ScottK: ^^
<ogra_ac> i will do a test as per marjo's request tomorrow but it dosnt really fit on our page
<marjo> ogra_ac: thx
 * ogra_ac is really a bit upset that he was forced into building these images at all with the promise that there would be testers
<robbiew> ogra_ac: but how would the testers get the hardware?
<ogra_ac> robbiew, beagleboards are available for $129 at digikey
<ogra_ac> since 1.5 years
<robbiew> ogra_ac: what about the omap4 stuff?
<ogra_ac> i dont know who enabled them, that they are built is a mistake
<ogra_ac> i explicitly didnt
<Spads> cjwatson: There appear to be tilde files in the releases tree, namely .htaccess~ and HEADER.html~
<Spads> cjwatson: a few more in include/ and kubuntu/
<ogra_ac> robbiew, we need that properly sorted in natty and i'd like to have a UDS session with kubuntu, release team and arm team about that
<robbiew> ogra_ac: ack
<ogra_ac> robbiew, i didnt enable kubuntu at all in maverick and was shouted at so i made the compromise to enable omap3 *if there would be testers*
<robbiew> ogra_ac: ah...then the omap4 was built perhaps due to miscommunication between us and you all....any way...not going to hold up the release for this stuff anyway ;)
<ogra_ac> robbiew, ack
<ScottK> We've had testers up until now.
<ScottK> Speaking of which, I"m doing the Kubuntu manual partitioning test that's missing now.
<ogra_ac> from the community ?
<ScottK> From people who weren't doing it on paid Canonical time, so yes.
<ScottK> We also got kubuntu-mobile testing on arm from non-Canonical people
<ogra_ac> ScottK, well, paid time or not gets very blurry, imho we should see that TI provides some HW to the community and thats something i'd like to solve in the above mentioned UDS session
<ogra_ac> (TI will be there to participate in the discussion)
<charlie-tca> xubuntu release notes for the final are going to be https://wiki.ubuntu.com/Xubuntu/MaverickMeerkat/Final if anyone cares.
<ev> lamont, anyone else: have you had any success in building a i386 chroot on an amd64 system without root? (While fakeroot fakechroot debootstrap... works fine for amd64->amd64, it fails on amd64->i386)
<lamont> ev: never tried
<ev> I was afraid you might say that
<ScottK> Testing done.
<ScottK> ogra_ac: I'm in favor of that.
<NCommander> ogra_ac: *cough*, oops. That feel off my TODO list
<NCommander> argh
<persia> ev, there's at least some chance that one won't have permission to set the personality without root (although I'll admit to not understanding the details of linux personalities)
<ev> persia: that much seems to work, though it could be failing silently for all I know
<persia> No idea then (and I've never tried).  I thought personality was the only thing different between amd64->amd64 and amd64->i386
<persia> You might be able to do it using qemu-debootstrap if you change the pass-through filters to not reject that usecase (as you'd have root in the emulated environment, which you can do as a regular user)
<ev> hmm, I'll add that to my list of things to try
<ev> thanks!
<persia> Just be warned that the qemu-debootstrap authors assumed nobody would do this, so you may have to tweak the script a fair bit :)
<ogra_ac> NCommander, yeah, you somehow misunderstood when i said you should unassign yourself from all bugs you dont actively work on :)
<didrocks> robbiew: can you release note bug #657371 for netbook? It's really a bug finally :)
<ubot4> Launchpad bug 657371 in netbook-meta (Ubuntu) "Ubuntu Netbook Edition maverick doesn't have a guest session (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/657371
<robbiew> didrocks: ack
<didrocks> thanks :)
<didrocks> we can fix it in a SRU changing the seeds and people getting it by the new recommend
<robbiew> didrocks: is there any workaround that I should document?
<didrocks> robbiew: I'm investigating on seeing why it's broken right now, I'll ping you
<robbiew> ok
<Riddell> bug 656876 is a problem for Kubuntu upgrades
<ubot4> Launchpad bug 656876 in ubuntu "distupgrade crashed during conf file change review (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/656876
<Riddell> I'll probably have to upload update-manager
<Riddell> we're thinking uploading to maverick-updates directly
<ScottK> Riddell: I'd still upload to proposed and test it, but yes, ~directly.
<Riddell> robbiew: ok with that?
<ScottK> We'll also need an associated release note.
<robbiew> +1 with ScottK's suggestion
<robbiew> upload, test, then move over
<robbiew> Riddell: ^^
<Riddell> ok
<cjwatson> robbiew: I think that lupin bug will need some kind of vague release note ("may break"), yes
<cjwatson> Spads: skaet is in control of antimony today and tomorrow, so I guess those will be from her
<Spads> cjwatson: copy.
<robbiew> cjwatson: ack
<skaet> Spads:  all good now?
<Spads> skaet: let me see
<Spads> skaet: Looks much better, thanks!
<skaet> Spads: you're welcome.  thanks for the explanation.
<NCommander> ogra_ac: *cough*
<doko_> robbiew: do mention in the release notes that we did drop support for i586?
<stgraber> ScottK: argh, I only uploaded it once ;) guess mvo uploaded it too. Let me quickly check
<robbiew> doko_: ok
<stgraber> robbiew: I'll coordinate with highvoltage so we have the upgrade tested today
<robbiew> k
<stgraber> ScottK: keep the edubuntu-artwork of the 2010-10-07 and drop the one I made yesterday
<ScottK> OK
<ScottK> stgraber: Done.
<stgraber> thanks
<doko_> robbiew: and maybe add i686 without cmov support
<robbiew> doko_: ack...will do, thx
<newz2000> Hi, can you confirm that this will be a valid URL for an ISO: Can you confirm, does this look like a valid URL for the ISO? http://mirror.clarkson.edu/ubuntu-releases//maverick/ubuntu-10.10-desktop-i386.iso
<Riddell> newz2000: looks fine
<newz2000> Riddell: great
<Riddell> preferably without the double slash
 * newz2000 will look into that
<newz2000> Riddell: do you have a page with Kubuntu release notes that you'd like people to see for kubuntu instead of the ubuntu release notes?
<Riddell> the release notes are the same
<Riddell> there's a separate release announce page
<newz2000> no, I'm just thinking release notes
<Riddell> which will be http://www.kubuntu.org/10.10-release
<Riddell> where are the draft release notes?
<newz2000> Riddell: https://wiki.ubuntu.com/MaverickMeerkat/ReleaseNotes
<Riddell> skaet: https://wiki.kubuntu.org/MaverickMeerkat/FinalDraft/Kubuntu will be http://www.kubuntu.org/10.10-release
<Riddell> newz2000: do you know what magic is needed at release time to clear web caches and whatnot?
<newz2000> Riddell: when we push we also ping IS to flush the cache
<Riddell> newz2000: ok, make sure you give me warning when that's going to happen
<newz2000> Riddell: well, this time B will be doing the push unless there's a problem, but I'll tell her to give you a ping
<newz2000> Her IRC nic is literraly "B" on canonical's irc
<Riddell> that's either very silly or very elite, I'm unsure which :)
<newz2000> That's what they call her in real life too
<Riddell> that's elite
<Riddell> robbiew, skaet: do we have an ETA for release?
<highvoltage> http://edubuntu.org/news/10.10-release will be Edubuntu's release notes (I'll work on that after finishing testing upgrades)
<newz2000> Riddell: how much advance notice would you like before the cache's are cleared?
<Riddell> newz2000: 15 mins say?
<newz2000> Riddell: ok.
<newz2000> It's not an exact science fyi. Cache's have a mind of their own.
<Riddell> although an expected time would be nice too
<Riddell> ScottK or anyone: update-manager in maverick-proposed unapproved queue
<ScottK> Looking
<ScottK> Waiting for the diff
<ScottK> Riddell: Accepted.
<Riddell> ta
<Riddell> I think I'm in for a long evening of testing
<Riddell> and release announce writing
<ScottK> maverick-backports project created.
<Riddell> newz2000: does kubuntu have an equivalent of http://www.ubuntu.com/testing/download  ?
<shadeslayer> Riddell: uh.. that page also lists kubuntu downloads
<shadeslayer> Releases of Kubuntu and Edubuntu are also available here.
<Riddell> it would be nice to have one that went directly to the kubuntu page though
<shadeslayer> yeah :)
<ScottK> Who's working on release notes?
<ScottK> robbiew or skaet: Are you still in progress on these?
<Riddell> I've a suspicion Millbank folks have all gone to the pub
<ScottK> Probably.
<ScottK> Riddell: There are a couple of Kubuntu specific release notes which still need to get in.
<ScottK> https://bugs.launchpad.net/ubuntu-release-notes/+bugs?field.searchtext=&orderby=-date_last_updated&search=Search&field.status:list=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
<Riddell> ScottK: thanks, "review release notes" is definately on my TODO for tonight
<ScottK> OK.  Cool.
<ScottK> I'm aware of those two because I wrote them.  No idea what else there may be.
<didrocks> robbiew: FYI, netbook guest session package fix uploaded to -proposed
<Riddell> robbiew, skaet: who is doing the pre-publishing and when?
<Riddell> ah, it's already done, good good
<Riddell> ev: does Wubi work from Windows 7?
<skaet> ScottK, Riddell back from dinner.
<Riddell> so I was almost right when I said pub :)
<Riddell> skaet: correction, it'll be at http://www.kubuntu.org/news/10.10-release
<skaet> Riddell,  yup.
<Riddell> skaet: I'm not going to get to reviewing the kubuntu bits on the release notes for a wee while, when do you need that done by?
<skaet> Riddell,  we're getting an edit in.   Please hold off any changes until you're passed the baton.
<newz2000> Riddell: no, there is no equiv for the download/testing link
<Riddell> newz2000: add that to my wishlist :)
<newz2000> noted. ;-)
<skaet> Riddell,  please refresh now.  baton just passed to robbiew.  ;)
<skaet> Riddell,  after a bit of discussion,  would it be possible to just mail robbiew and me your edits directly at this point?
<Riddell> skaet: can do, as I say I'm busy on other things just now, when do you need them by?
<stgraber> skaet: we have one edubuntu upgrade bug to release note, should we update the wiki directly ?
<skaet> Riddell,  stgraber - please send any updates to us by email in next 15 minutes.   we need to get them ready to handoff to newz2000.
<newz2000> skaet: you don't need to hand off to me. Make sure that wiki page is right and everything will happen OK tomorrow.
<skaet> newz2000,  good to know.
<stgraber> skaet: ok, highvoltage is preparing an e-mail just now (we need to refresh the Edubuntu 10.10 features and add one release note entry)
<skaet> stgraber,  thanks!    Will incorporate as soon as arrives.
<jdstrand> robbiew: fyi for bug #656173, there is updated suggested release note text in comment #10. The one you added had a small typo and wasn't as clear as it could be
<ubot4> Launchpad bug 656173 in libvirt (Ubuntu) (and 1 other project) "libvirt no longer probes chained backing stores (affects: 2) (heat: 14)" [Undecided,Won't fix] https://launchpad.net/bugs/656173
<jdstrand> robbiew: I'd change it, but you have the lock
<robbiew> jdstrand: ack
<skaet> jdstrand,  thanks.  robbie's got it.
<Spads> skaet: if you doubted that mirror admins would notice ~ files, take a look at this when you have time: https://pastebin.canonical.com/38465/
<Spads> skaet: basically we should probably add DirectoryIndex index.html to our .htaccess for releases so that our mirrors won't spill the beans
<Spads> skaet: short version is that http://se.releases.ubuntu.com/.pool/ doesn't show http://se.releases.ubuntu.com/.pool/index.html the way it ought.
<ScottK> skaet: The release notes inputs I had are in fix committed bugs against ubuntu-release-notes
<Riddell> skaet: where is the draft of the e-mail announcement for ubuntu-announce?
<skaet> ScottK,  cool.  Can you please let us know the bug numbers.
<skaet> Riddell,  robbiew's working on it.
<ScottK> skaet: Bug 628930 and Bug 651294
<ubot4> Launchpad bug 628930 in mesa (Ubuntu Maverick) (and 4 other projects) "[i945GME] KDE Desktop effects not active by default (affects: 8) (dups: 1) (heat: 50)" [High,Fix released] https://launchpad.net/bugs/628930
<ubot4> Launchpad bug 651294 in xserver-xorg-video-intel (Ubuntu) (and 1 other project) "X crash on KDM logout (still - yes, really) (affects: 4) (heat: 20)" [High,Confirmed] https://launchpad.net/bugs/651294
 * ScottK has promised to loan hardware affected by 628930 to the kwin developer that's coming to UDS, so we may have something for SRU by the end of the month.
<skaet> thanks ScottK!
<Riddell> Bug 628930 is already in there
<ubot4> Launchpad bug 628930 in mesa (Ubuntu Maverick) (and 4 other projects) "[i945GME] KDE Desktop effects not active by default (affects: 8) (dups: 1) (heat: 50)" [High,Fix released] https://launchpad.net/bugs/628930
 * robbiew takes a break
<ScottK> OK.  Would you please mark the ubuntu-release-notes task fixed released then.
<Riddell> skaet: do you have a list of Kubuntu images to be published on cdimage tomorrow?
<highvoltage> skaet / robbiew: did you get my email?
<skaet> highvoltage,  yup.   Changes added.
<highvoltage> great! thanks
<skaet> need to change locations now... will finish up after I can connect again.
<Riddell> robbiew: is mvo going to be around tomorrow?
<stgraber> Is there any vague estimate as to when we'll release ? both highvoltage and I are on the EDT, so it'd be nice to know how early to wakeup to make the anouncement available on the website + blog posts ;)
<Riddell> added to release notes Bug: 634664 Bug: 651086 Bug: 656195
<skaet> ogra_ac, thanks for the input.  I think I've cleaned up that bad copy/paste now.   could you please take a look at the bugs and make sure you're comfortable with them.
<skaet> ??
<ogra_ac> skaet, is tomorrow morning (my time) ok ?
<ogra_ac> or is it urgent ?
<skaet> Riddell, ScottK;  have made all the changes I've received.   Do you want any further changes to the Kubuntu overview or bugs part?
 * ogra_ac fixes one issue
<Riddell> skaet: for the ReleaseNotes?
<skaet> ogra_ac, newz2000 says he's got the manual part removed,  so pressure came off a bit.
<skaet> Riddell, yup
<Riddell> hmm "Kubuntu 10.10 comes with the latest KDE Software." is actually a lie, but never mind
<Riddell> skaet: just the link needs changed in "For more information see the Kubuntu release page"
<Riddell> to http://www.kubuntu.org/news/10.10-release
<ScottK> Riddell: Shouldn't that be something plasmaish anyway?
<ogra_ac> skaet, well, the separate arm notes are moot if we add the "no sound devices on omap" bug as well ...
<Riddell> ScottK: we ship with a lot more KDE Software than just Plasma
<skaet> ogra_ac,  the separate arm notes are a better break down, and clearer than the release notes.
<ogra_ac> oh, ok
<skaet> ogra_ac,  can you remove the "update for Maverick Meerkat" at the top of the ARM notes though?
<ScottK> Riddell: True, but KDE software is not particularly true to the rebranding stuff.
<Riddell> ScottK: yes it is, it's the approved term for software made by KDE
<ogra_ac> skaet, why is bug 539027 under arm ?
<ubot4> Launchpad bug 539027 in casper (Ubuntu) (and 1 other project) "end_request: I/O error rebooting at end of install (affects: 18) (dups: 1) (heat: 102)" [Medium,Confirmed] https://launchpad.net/bugs/539027
<ScottK> Riddell: OK.
<ogra_ac> there is nothing arm realted in the comments
<Riddell> skaet: is mvo going to be around tomorrow?
 * skaet looking...
<ogra_ac> and if its casper it can only be dove (omap images dont use casper)
<ogra_ac> ah, i see
<ScottK> skaet: Where do I read the draft?
<skaet> Riddell,  mvo said he'd come in.
<ogra_ac> GrueMaster apparently commented for dove
<Riddell> skaet: ok, remind me to make sure he sets the date correctly in meta-release (it currently isn't valid) and to use the maverick-updates version
<ogra_ac> skaet, so if 539027 stays for arm, it should be pointed out that its dove only
<skaet> ogra_ac,  while you're in there now, go ahead and make that change
<ogra_ac> skaet, hmm, bug 563034 is clearlsy a lucid bug and has no notes about maverick
<ubot4> Launchpad bug 563034 in gnome-media (Ubuntu) "recording .ogg produces no sound (affects: 2) (heat: 20)" [Undecided,New] https://launchpad.net/bugs/563034
<skaet> ogra_ac,  if its not valid, remove it.
<ogra_ac> ok
<skaet> Riddell,  please send a note with the detail.
<skaet> ogra_ac.  Thank you.  :)
<ogra_ac> skaet, done, please check for typos etc
#ubuntu-release 2010-10-10
<skaet> ogra_ac,  ack.  :)
 * ogra_ac hasnt slept since 30h now and doesnt give any guarantee for any grammar :)
 * skaet understands ogra_ac's state only too well, and is very appreciative of the pass that mpt made on the document earlier to clean up the grammar.  ;)
<ogra_ac> heh, well, i edited after mpt so better check twice :)
<skaet> ogra_ac: will do another pass after i wake up and am a bit more alert.  ;)
<ogra_ac> heh, good
 * ogra_ac is off to bed 
<skaet> Riddell, ScottK, and other community maintainers, if you spot something that is wrong/inaccurate, go ahead and edit the wiki.   Please be careful not to collide with others.  I had to fix a few of those up tonight.   Will see who's around in the morning.  ;)
 * skaet thinks ogra_ac has a good idea.
<Riddell> guid nicht skaet
<cjwatson> Riddell: I tested wubi on Windows 7 and it worked fine.  There are bugs indicating factors we don't understand, so I can't swear it will work for all Windows 7 users, but it certainly isn't fundamentally incompatible or anything.
<cjwatson> good luck for release!
<Riddell> groovy
<Riddell> thanks cjwatson
<Riddell> have a nice non-release Sunday
<marjo> cjwatson: jibel reported migration assistant failed (no option to import for Windows 7); just FYI
<ScottK> I've successfully tested Riddell's work around for bug 656876 and it avoids the issue.  My recommendation is we go ahead and put it in -updates sooner rather than later as more and more people will be upgrading as we get closer to release.
<ubot4> Launchpad bug 656876 in update-manager (Ubuntu) "distupgrade crashed during conf file change review (affects: 1) (heat: 10)" [Critical,Fix released] https://launchpad.net/bugs/656876
<Riddell> copied to maverick-updates
<Riddell> still need to make sure mvo updates the meta-release file correctly
<stgraber> is edubuntu-artwork also in -updates now ?
<Riddell> dunno, try looking at launchpad
<stgraber> will try (I'm on my cell)
<ScottK> It's still pending.
<ScottK> (in unapproved)
<stgraber> who do I need to nag to have it moved to -updates (ideally before releas) ?
<Riddell> stgraber: me or scott can accept it into -proposed then someone needs to test it then we can move it to updates, but it needs a good reason why it should be moved to updates without the normal week's waiting period
<stgraber> will cause gconf update issue for users upgrading from 10.04
<stgraber> we just didn't want it on the DVD as we'd have needed to retest for something that only fixes upgrades
<roxdragon> weee
<roxdragon> when relase maverick?
<stgraber> but we really want that in for users upgrading from 10.04
<ScottK> stgraber: What we just did for Kubuntu upgrades is pretty unusual.  It's just because it could cause upgrade failures.  What's the impact of the Edubuntu issue.
<ScottK> roxdragon: I think you want to be in #ubuntu-release-party.
<stgraber> ScottK: it might cause gconf update failure for users upgrading from 10.04
<ScottK> stgraber: And then what?  Keep in mind I don't use Gnome, so I've no idea what the impact of that is?
<stgraber> ScottK: as update-gconf will very likely fail for these users until edubuntu-artwork is updated
<ScottK> And what happens if it fails?
<ScottK> Does the system upgrade fail?
<stgraber> ScottK: well, for example installing another software using gconf would probably fail (as in, no setting or schema update)
<Riddell> stgraber: "we just didn't want it on the DVD" but the bad version is on the DVD surely?
<ScottK> Riddell: Right, but it just affects upgrades.
<stgraber> no, the upgrade won't fail but installing any software after the upgrade might fail
<stgraber> (mvo found the bug and made the upload, I only reviewed+tested the change)
<ScottK> Personally I'm reluctant to abuse -updates pre-release for things that don't cause a failed upgrade.
 * ScottK looks at Riddell.
 * highvoltage looks at ScottK 
<Riddell> I'll review it for -proposed for now
<Riddell> it'll need to build and get tested anyway
<stgraber> I don't really mind, the only potential issue is that we'll get a few bug reports on random packages failing to install for non-obvious reason
<persia> stgraber, Which sort of gconf failure?  One of the ones that makes folk do `dpkg --configure -a` afterwards, or just a transient issue?
<Riddell> stgraber: does this also need the gconf update?
<stgraber> persia: I'd need to recheck the but mvo fixed (once I'm no longer on my
<stgraber> cell)
<Riddell> persia: bug 633370
<ubot4> Launchpad bug 633370 in gconf (Ubuntu Maverick) (and 3 other projects) "package gconf2 2.31.91-0ubuntu3 failed to install/upgrade: No such file or directory: '/usr/share/gconf/defaults/20-edubuntu' (affects: 6) (dups: 7) (heat: 62)" [Medium,Fix committed] https://launchpad.net/bugs/633370
<stgraber> Riddell: nope
<Riddell> persia: good morning :)
<persia> Good morning :)  I hope you're well east or west of your typical haunts :)
<persia> That bug *will* cause random packages to not be configured until the update is available.
<persia> Depending on the postinsts, this may or may not impact things.
<ScottK> OK.  That makes it sound a little more interesting.
<stgraber> if that was only breaking edubuntu packages I wouldn't mind waiting a few days, but the fact that it'll broke random packages when installing on an upgraded edubuntu is a bit more of an issue
<persia> Note that, as stgraber says, it may have no impact: it depends entirely on the ordering of the upgrade, which is in the hands of apt, and very hard to determine in advance.
<ScottK> For a large value of very.
<Riddell> stgraber: Accepted edubuntu-artwork into maverick-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!
<Riddell> where here means bug 633370
<ubot4> Launchpad bug 633370 in gconf (Ubuntu Maverick) (and 3 other projects) "package gconf2 2.31.91-0ubuntu3 failed to install/upgrade: No such file or directory: '/usr/share/gconf/defaults/20-edubuntu' (affects: 6) (dups: 7) (heat: 66)" [Medium,Fix committed] https://launchpad.net/bugs/633370
<Riddell> stgraber: also that bug needs a TEST CASE comment
<stgraber> Riddell: ok, highvoltage as a VM we can use for that. Thanks
<highvoltage> not with me though
<stgraber> highvoltage: should have taken your laptop, told you :)
<highvoltage> I tested for 633370 and I couldn't reproduce
<highvoltage> just talked to stgraber IRL, I didn't test it properly
<stgraber> sorry, talking was just a lot faster than typing on the n900 :)
<ScottK> It will need a test case/test result before it can go in -updates.
<stgraber> sure
<stgraber> highvoltage: can you write it quickly ?
<highvoltage> stgraber: not sure if it's good, but it's there
<Riddell> release note added for Bug: 656876
<Riddell> bug 656876
<ubot4> Launchpad bug 656876 in update-manager (Ubuntu) "distupgrade crashed during conf file change review (affects: 1) (heat: 10)" [Critical,Fix released] https://launchpad.net/bugs/656876
<highvoltage> (signing off from IRC for now, battery low and I have a policy of getting drunk while on irc)
<highvoltage> (uhm, I mean not)
<stgraber> highvoltage: thanks, will test it once we are back home (package should be built by then)
<GrueMaster> Riddell: (and anyone else that is interested).  I am home now, and firing up the kubuntu-desktop image on omap and omap4.  I don't plan on Doing a very thorough test of everything, but I want to see if I see the same results reported by mporier & marjo.  Will let you know soon.
<ScottK> GrueMaster: Thank you.  I think that will be sufficient.
<ScottK> Very helpful
<GrueMaster> Sorry I couldn't get to it earlier while at TI, but we were having internet issues.
<GrueMaster> Hard to download a full image over 3G, and my backups made zsync useless.
<ScottK> Understood.
<ScottK> We certainly appreciate your help with this.  It's not like you didn't already spend a little bit of time on ISO testing recently.
 * stgraber is back home and on laptop
<stgraber> Riddell: I still see edubuntu-artwork in the queue as unapproved, is that normal ?
<ScottK> It is if he didn't actually accept it.
<ScottK> (which seems to be the case)
<ScottK> Let me have a look
<persia> GrueMaster, I'd be very interested in your kubuntu-desktop/omap3 experience: I seem to have run into the OOM killer, and so was unable to determine if there were also underlying software crashes.
<GrueMaster> I plan on hitting it with beqagleXM.
<GrueMaster> I know it will fail on beagle.
<GrueMaster> omap4 image looks good.
<Riddell> hmm, the sru-accept script should have done that
<Riddell> stgraber: accepted now
<Riddell> ScottK: ^^
<ScottK> OK.
 * ScottK stops
<stgraber> Riddell, ScottK, persia: highvoltage and I just looked closely at that bug and it's only affecting users on Lucid who don't follow the upgrade instructions
<stgraber> if they do an upgrade prior to dist-upgrading, they won't have the bug
<stgraber> because that symlink issue got fixed as an SRU in lucid
<stgraber> also, mvo's fix isn't the right one, we don't want to fix the symlink, we actually want it removed completely
<persia> Oh, cool.  Fixing it in a lucid upgrade is even better.
<ScottK> So should Riddell remove it?
<stgraber> as fixing the symlink would make it point to another file in /usr/share/edubuntu-artwork which is a symlink to the actual correct file in /usr/share/gconf/defaults
<stgraber> ScottK: yes
<ScottK> Riddell: ^^^
<ScottK> I can't do that one.
<stgraber> ScottK: I'm going to upload new package in -proposed which fixes the rm of that symlink completely but that can go post-release
<ScottK> OK.
<stgraber> ScottK, Riddell: Should I bump the version to 10.10.10.2 for that upload or can I re-use 10.10.10.1 ?
<ScottK> You need to bump it.
<ScottK> 10.10.10.1 is used now.
<Riddell> removed from maverick-proposed
<stgraber> Riddell: thanks
<pinnerup> Anyone has any idea when tomorrow the release will be publicly available?
<Riddell> exactly one hour after the last person asks when it will be available
<persia> pinnerup, #ubuntu-release-party is the channel to speculate.
<pinnerup> Ah, thanks.
<Riddell> we really should have got cjwatson to do the +v only thing
<ScottK> Only 209 users there.  Hardly getting started.
<ikonia> getting messy though
<wgrant> Hm, access here is rather limited :(
<ikonia> thankfull jono appears to have controlled himself this release
<wgrant> ikonia: Oh, we'll see about that :)
<roved2101> hey fanbois is it out yet?
<ScottK> roved2101: You want #ubuntu-release-party.
<ScottK> Riddell: You're right.
<wgrant> At this time you'll need Hobbsee or the IRCC to do it.
<ikonia> don't think any IRCC members are active
<wgrant> Yeah :(
 * micahg could give it a shot as long as the permissions aren't locked
<ikonia> they are
<ikonia> only a few named people and the ircc
<stgraber> according to the access list: cjwatson, Mithrandir, pitti, Hobbsee, slangasek and UbuntuIrcCouncil
<stgraber> have access
<wgrant> Right. As I said, all except Hobbsee and possibly the IRCC should be asleep.
<ikonia> only cjwatson and hobbsee has full control
<wgrant> Hmm?
<ikonia> I don't think it will get bad in here any way
<micahg> maybe a notice on login that the party channel is for are we there yet stuff?
<ikonia> no-one reads it
<persia> +m +v on ubuntu/member is usually better.
<GrueMaster> Ok, preliminary testing of kubuntu-desktop on beagleXM is good.  Slow, but usable.
<ScottK> \o/
<stgraber> I believe last time cjwatson +m the channel and manually +v everyone who's supposed to talk in that channel, then +v people as they joined and had reason to talk
<wgrant> That happened last time just after the 11th hour reroll was declared.
<wgrant> It was fairly noisy. It's not close to that level yet.
<GrueMaster> Ok, the kubuntu-preinstalled-mobile-omap* images are corrupted.  I have updated bug 657281 accordingly.
<ubot4> Launchpad bug 657281 in ubuntu "Kubuntu Maverick on Omap3 & Omap4: screen goes black and never comes back (affects: 1) (heat: 8)" [Undecided,Incomplete] https://launchpad.net/bugs/657281
<GrueMaster> And I'm out for the night.
<highvoltage> goodnight GrueMaster
<stgraber> ok, I'm out for a while, will be back in around 5 hours.
<nhandler> Did you guys need an IRCC member?
<wgrant> nhandler: It was desired to +m the channel and +v most people. But things seem to have quietened down now.
<nhandler> wgrant: So do you not want the +m/+v now? I'm about to head to bed (and I doubt anyone else with access will be around for a few hours, but most confused users will also probably be gone)
<wgrant> I'm not -release. But it seems quiet enough now that I wouldn't bother.
<nhandler> Well, not really a release team decision for this, more of a 'what will make the channel function the best' decision. But if you think things are quiet enough now, I'll head to bed.
<wgrant> Morning robbiew.
<robbiew> morning
<pitti> Good morning
<pitti> ikonia: what's up?
<pitti> (I'm not IRC council, FTR)
<wgrant> You're not IRCC, but you have access here.
 * pitti starts SRU processing
<pitti> cjwatson, slangasek, ScottK: FYI, switched queuediff to default to maverick
<ttx> skaet, robbiew: o/
<Daviey> ttx: o/
<ttx> Daviey: still around ?
<Daviey> ttx: Seems you made it back safely :)
<Daviey> ttx: Yeah
<skaet> tty, o/
<ttx> ttz waves back
<pitti> hey skaet, good morning
<pitti> hey ttx
<skaet> hey pitti, good morning
 * ttx keeps a window open into a 10.10.10 world
<pitti> ok, SRU queue cleared, except for two which I need further info for, and udev which I uploaded myself
<slangasek> speaking of the SRU queue, I still need to announce this plan about the SRU freeze later this month.  Do you think that belongs on u-d-a or u-d?
<pitti> slangasek: uda would be better IMHO
<pitti> we used to send out SRU process changes there
<wgrant> robbiew: You know that only ops can see what normal people are saying in #u-r-a, right?
<pitti> and right after release everyone is trying to get in SRUs
<slangasek> pitti: ack
<robbiew> wgrant: yep
<wgrant> Heh. It just looks a bit odd to see you shushing nonexistent people.
<persia> What is the plan for the "SRU Freeze"?  Is there a draft?
<tgardner> pitti, I'll have the 0 day kernel release uploaded in a few minutes, once I'm sure its exactly what Leann uploaded.
<pitti> tgardner: ah, great
<marjo> skaet: ISO Testing Results: 100% test image coverage; 100% mandatory test cases done; 99.9% optional test cases
<tgardner> pitti, re-uploaded linux_2.6.35-22.34. holler if it ain't right
<pitti> tgardner: to -security?
<Riddell> morning
<pitti> I don't have control over that, I think we need jdstrand, kees, or mdeslaur
<pitti> hey Riddell, good morning
<tgardner> pitti, yep, to -security
<tgardner> pitti, you're right. I can't upload to -security. can you just promote Leann's upload to -security? or do I _really_ need one of the security team geeks to do this?
<pitti> I don't know their current procedure
<pitti> we could in theory build it in -proposed, and then copy over to -security
<pitti> but I don't know what that'd break
<pitti> tgardner: was that ever done before?
<tgardner> pitti, APW AND SMB TELL ME THATS THE WAY IT WAS DONE LAST TIME
<tgardner> oops, sorry
 * apw covers his ears
<persia> It won't break anything as long as none of the packages that end up installed *during the build* differ between -updates and -security.  If any differ, breaks semantic validity of -security, and is very, very, very bad.
<wgrant> Soyuz-wise it will work fine.
<wgrant> Is it not embargoed, though?
<pitti> no, and USN release should be done at the time of -proposed -> -security
<tgardner> all of the CVEs have been released
<pitti> tgardner: ok, accepted; should build now
<pitti> I'll sort out the bug mangling after breakfast
<tgardner> pitti, cool, thanks
<Riddell> mvo: how come meta-release uses maverick-propoed and not maverick-updates ?
<mvo> Riddell: yes, I already updates that
<mvo> Riddell: for the kubuntu fix you did
<Riddell> thanks for that
<Riddell> but it doesn't answer my question :)
<mvo> Riddell: I was wondering if we shouldn't set the diff to "expanded" by default (and hide the button). but I don't know if that will cause issues :/
<Riddell> mvo: well expanding it is the problem, that's what loads the troublesome plugin
<mvo> Riddell: aha, ok. could we load and expand it when the upgrade starts?
<mvo> Riddell: so that it does not load it on demand?
<mvo> Riddell: about -proposed, let me check
<Riddell> I did try a version with show/hide at the start, but it didn't help for some reason and I ran out of time
<mvo> Riddell: aha, thanks!
<mvo> Riddell: about -updates> there is no release-upgrader in -updates :/ that is a soyuz bug
<mvo> Riddell: I work around it usually by using the explict version from -updates in the meta-release file
<Riddell> silly soyuz
<mvo> Riddell: but currently current and 0.142.20 are the same, so I did not use the explicit vresion
<wgrant> Silly custom uploads, more likely :P
<mvo> *pff* ;)
<wgrant> Well, actually silly Soyuz design decisions from 5.5 years ago that are really awkward to change :(
<pitti> hm, do we block torrents until the red button?
<pitti> "Requested download is not authorized for use with this tracker"
<persia> Ought do, really.
<pitti> of coruse it's possible that my ISP recently blocked that
<slangasek> never heard of torrent blocking before
<pitti> I don't usually use torrents, but it's step 7 in "release - 3h"
<pitti> some guys in #u-r-p also say that torrents don't work for them
<stgraber> pitti: mine are still downloading. The tracker seemed to be dead initialiy, took 10min or so for them to start
<pitti> stgraber: ok, thanks for confirming
 * pitti blames Telekom then
<Riddell> are we nearly there yet?
<persia> Riddell, at least another hour :p
<pitti> 10:10 UTC *cough*
<wgrant> 10:10:12 :(
<wgrant> Congrats everyone.
<pitti> web site wise we haven't released yet, though :)
 * Riddell publishes http://www.kubuntu.org/news/10.10-release
<wgrant> pitti: Looks good to me.
<pitti> even though #u-r-p claims otherwise
<pitti> ah, now!
<gaspa>  o/
<pitti> \o/
<nigelb> "06:10 <@robbiew> Ubuntu 10.10 is released"
<pitti> meerkat dance!
 * persia encourages anyone doing things a bit late to consider the -d argument to touch(1)
<wgrant> Heh.
<pitti> robbiew: "Sun, 10 Oct 2010 11:10:10 +0100" -> well fudged^Wdone!!
<stgraber> yeah !
<nigelb> \o/
 * stgraber does the Edubuntu release magic and goes back to bed, it's a bit early here ;)
<nigelb> tbh, less crazier release this time :)
<persia> Trick to being uncrazy is doing it Sunday rather than Thursday.
<pitti> congrats everyone!
<Squirm> yaya
<Squirm> :D
<marjo> congrats everyone! skaet: nice first release
<nigelb> persia: heh, good point
<pitti> who wants to have the honor of updating #devel topic?
<slangasek> skaet, robbiew et al: congrats!
<wgrant> Heh, OMG! was 5 minutes late.
 * pitti votes for skaet
<marjo> pitti: ditto
<pitti> wgrant: went to the loo at the wrong time?
<nigelb> pitti: hahaha
<Squirm> lol
<robbiew> slangasek: thank you my friend
 * nigelb bows to robbiew 
<nigelb> Beautiful release mail
<mvo> congrats skaet and robbiew from me as well!
<marjo> robbiew: congrats for another fine release
<robbiew> nigelb: I aim to please
<robbiew> nigelb: and notice the time the email was sent ;)
<nigelb> robbiew: DANG! YOU ROCK!
<nigelb> how in the world did you get the timing right :D
<persia> robbiew, So, how many times did you need to reset your clock to ensure that time?
<pitti> robbiew: mutt's "edit all headers" feature, presumably? :-)
<robbiew> persia: pitti: well.....;)
<persia> (and if you try for that sort of time again, consider setting your timezone to Reykjavik for the extra +0000 goodness)
<robbiew> persia: NEVER AGAIN!!!
<persia> Awwww
<persia> Note that there was a certain inevitability about it, making the anticipation today less exciting than usual.
<wgrant> Well, it could have gone the way of Lucid.
<pitti> persia: not quite; remember what happened to earth just 5 minutes before the program ended
<Riddell> http://torrent.ubuntu.com/kubuntu/simple/maverick/desktop/ not updated?
<Riddell> (or http://torrent.ubuntu.com/simple/maverick/desktop/ )
<persia> pitti, See, that's the unfortunate aspect of the misnomer of "trilogy": it was all reset so that nobody really noticed.
<Squirm> the website link is quick too
<Squirm> got it in 5min
<pitti> newz2000, robbiew: web site alert: http://www.ubuntu.com/news/ubuntu-10.10-desktop-edition is 404
<pitti> it's the prominent link from teh announcement
<Squirm> I downloaded it from
<Squirm> http://www.ubuntu.com/desktop/get-ubuntu/download
<wgrant> Hm. Some of the screenshots on the front page are a bit bad.
<robbiew> pitti: fixing now
<robbiew> pitti: ...well, elmo is getting it fixed ;)_
<Ng> pitti: where did you get that link from?
<pitti> Ng: robbie's email announcement
<pitti> same problem with http://www.ubuntu.com/news/ubuntu-10.10-server-edition
<pitti> Ng: https://lists.ubuntu.com/archives/ubuntu-announce/2010-October/000139.html
<Ng> thanks
<pitti> Ng: I'm afraid this is the one email we can't possibly send a followup to, date wise
<nigelb> All I can ay is mod_rewrite ftw to fix that :/
 * ttx congrats everyone
<ttx> robbiew, Daviey, skaet: no release at http://uec-images.ubuntu.com/releases/10.10/ ?
<Ng> pitti: robbiew: fixed
 * ttx compares with http://uec-images.ubuntu.com/releases/10.04/release/
<pitti> Ng: cool, thanks!
<Daviey> ttx: skaet is working on it now
<robbiew> ttx: who does that?
<Daviey> (i think)
<ttx> robbiew: I think it's some nectarine magic
<robbiew> ttx: ack
<persia> If it's magic, it's probably a target for automation: we've done enough releases, we ought know how to do it.
<robbiew> ttx: see #distro
<slangasek> it's in the checklist, in fact; is it missing a command to push the changes to the mirrors maybe?
<pitti> have a nice Sunday everyone!
<marjo> pitti: congrats & thx!
<sabdfl> well done all
<ttx> Daviey, skaet: also the aws pages still point to RC, but I guess this needs to be done after the publication script.
<Daviey> ttx: yeah
<Daviey> ttx: Do you happen to know how long the upload normally takes?
<ttx> 5 min
<ttx> according to smoser
<ttx> "the only thing needed is a < 5 minute operation "Make the build public"."
<ttx> Daviey, skaet: you're trying to run "promote-daily --make-public", right
<skaet> ttx, yup.  ;)
<smoser> skaet, Daviey ttx i'm here.
<smoser> got your call, and see that
<smoser> :-(
<ogra_ac> hmm, somehow the manifest files for omap and omap4 didnt get copied to http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/maverick/release/
<robbiew> ogra_ac: perhaps pitti can help...skaet is resolving some ec2 images related stuff
<ogra_ac> robbiew, no hurry, if someone complains i can send them to the daily image page it has the right file
<robbiew> ogra_ac: ack
<ogra_ac> (and worst case i could copy them over manually, but i think the release script misses a bit, cjwatson fixed the daily scripts for us but we seemingly both forgot about the actual release script)
<skaet> ogra_ac, if you can,  just copy them over, and we'll add it to the post-mortem list for the scripts.
<ogra_ac> k
<skaet> thanks!
<ogra_ac> hmm, i cpoied them to the right dir on antimony but dont see them on cdimage
<pitti> ogra_ac: what's up?
<pitti> (sorry, was out for a hike)
<ogra_ac> pitti, manifest files are missing for omap and omap4
<ogra_ac> pitti, i copied them manually in the right dir on antimony, but apparently they dont get mirrored to http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/maverick/release/
<pitti> ogra_ac: you ran sync-mirrors?
<ogra_ac> ah, no, i didnt
 * ogra_ac has never touched the publishing stuff
<pitti> you need to run that after each change
<ogra_ac> ok
<pitti> ogra_ac: I'll check it and run it now
<ogra_ac> ok, thanks
<pitti> weird, why is cdimage so slow today?
<ogra_ac> lol
<elmo> :-(
<pitti> (SCNR)
 * ogra_ac guesses somone downloads something from it 
<elmo> you're up to 5 damn servers - I'm going to go to 7 next time
<ogra_ac> (just a guess though)
<pitti> the day when we do a release and cdimage is fast is a good day to look for another job
<ogra_ac> yeah
<pitti> it's actually surprisingly fast, j/k
<pitti> ogra_ac: http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/maverick/release/ubuntu-netbook-10.10-netbook-armel+dove.manifest works, though; do you mean another one?
<ogra_ac> last release i needed several tries to get to it
<ogra_ac> pitti, omap and omap4
<pitti> ogra_ac: ah, I see
<ogra_ac> i dont care about dove, nobody has that HW out in the wild
<persia> Nobody has omap4 either :p
<ogra_ac> persia, well, but omap4 is on pre-sales
<persia> True.
<pitti> ogra_ac: rsync running, will take a bit
<ogra_ac> pitti, thanks a lot
 * pitti off again, cu tomorrow
<ttx> elmo: how is the download rate going ? Does releasing on a sunday make a difference ?
<ttx> for the record, the cloud images are OK now :)
<ttx> thanks to smoser that we woke up on that fine Sunday morning
 * skaet thanks smoser for getting up so early!  thanks too to ttx and daviey for helping to sort it all out.   
<Daviey> :D
<skaet> pitti,  ogra_ac - are things sorted out with the manifests noe?
<skaet> s/noe/now/
<ogra_ac> skaet, yep
<ogra_ac> everything fine now
<skaet> *\o/*
<ogra_ac> :)
<skaet> thanks ogra_ac, pitti!
<smoser> ttx, thanks for catching the ami pages.
<smoser> i'm checking them now
<ttx> smoser: cool
<smoser> i'm not sure how the alpha1 ami ids got into the x86_64 header
<smoser> that ws the only errors you saw, right?
<ttx> and the 32 bit header contained the 64bit header
<ttx> I think
<ttx> the bodies were ok
<ttx> yep, maverick-i386.txt contained data from the 64-bit AMIs
<ttx> was pretty confusing, I ended up with two 64-bit pages :)
<jdstrand> pitti: fyi, ogasawara had an ack from kees regarding the 0-day kernel on maverick to build in -proposed and copy to -security since there is nothing in -updates now (and therefore builds in -proposed and -security would be identical)
<jdstrand> pitti: that of course won't last forever :) for today it is fine though
<persia> jdstrand, http://archive.ubuntu.com/ubuntu/dists/maverick-updates/main/source/ doesn't appear empty to me.  And it also doesn't appear identical to http://archive.ubuntu.com/ubuntu/dists/maverick-security/main/source/ (even ignoring the other components, which ogre-model protects the kernel from anyway)
<persia> kees, ogasawara ^^
<lamont> persia: see also https://edge.launchpad.net/ubuntu/+source/update-manager
<persia> lamont, Yes.  The main point being that while it happens to be true that the set of packages installed on a kernel build is identical, the rationale given for the free pass of the 0-day kernel SRU doesn't happen to be valid, so ought be adjusted.
<persia> (free pass for -updates -> -security, which is typically bad)
<lamont> ah
<lamont> I'm also missing about 15 minutes of context
<persia> More like ~8 hours, if I recall correctly.  Might even be 10.
<persia> (at least I was responding to a last comment ~2 hours ago in a (slow) discussion on the topic since about that long back)
<persia> Anyway, have a good weekend.  I should probably finish waking up before adding more.
<lifeless> persia: you're out of your normal TZ?
<persia> lifeless, No.  Just up a bit earlier than usual.
<jdstrand> persia: granted, update-manager slipped in since the free pass was given, but as stated and you know as well, it won't affect the build
<jdstrand> -proposed will also pull in -updates and -security, so building the kernel in -proposed is still ok
<jdstrand> persia: also, this is a one time free pass-- we are very careful about *not* copying from -updates -> -security. but I think you know that as well. so I think in all we have maximum clarity now
<persia> Right.  I just wanted to make sure the official justification was because nothing in -updates would be pulled by the build, rather than that nothing was in -updates, given timestamps, etc.  best to set precedents carefully, even when one hopes to never repeat.
<rlameiro> popey: hi, persia told me that you manage some kind of video distribution of ubuntu related stuff, is there something for ubuntu studio?
<persia> heh.  I certainly didn't expect that to appear in this channel :)
<jcastro> rlameiro: #ubuntu-community-team for those kind of questions please!
<rlameiro> well, its the only channel i found Popey:D sorry jcastro
<jcastro> no worries
<rlameiro> jcastro: why are some ubuntu channels hidden on the whois?
<persia> It's not that, it's some people don't expose all their channels in /whois
<rlameiro> ok
<nhandler> rlameiro: The +i usermode is now enabled by default. This means that when you /whois a user, you will only see channels that you share with them (unless the user manually removed the +i usermode)
<rlameiro> oh, ok
<rlameiro> nhandler: thanks for the info, i didnt knew that
#ubuntu-release 2011-10-03
<ScottK> infinity: No.  I was not around....
<jbicha> what does final freeze mean for unseeded universe?
<micahg> jbicha: it comes much later
<micahg> well, not much, about a week and a half
<jbicha> specifically would a feature freeze exception to add sushi, the GNOME 3.2 previewer for Nautilus, be considered?
<ScottK> jbicha: It would, but please don't use a binary name that another source is already using.  It confuses things (like apt-get source will match the binary one).
<ScottK> You'll need to find an archive admin with time to review it.
<jbicha> right, using the same binary name as another is bad but that's not exactly what's happening here
<jbicha> or are you saying that we need to use the same binary name as our source package?
<ScottK> No.  I'm saying don't use as your binary the name of some other source pacakge (which is what I thought was what the bug said)
<ScottK> IIRC it's sushi/sushi-irc and you want to be sushi-nautilus/sushi.
<ScottK> Please don't.
<infinity> Or we could just fix apt-get source to behave sanely. :P
<jbicha> there were lots of ideas for names: gnome-sushi, nautilus-sushi...or sushi-previewer similar to epiphany-browser
<jbicha> ScottK: ok, I'll get someone from the Debian GNOME team to help us pick a better name, thanks
<ubuntu-baltix> hi all
<ubuntu-baltix> please update ubiquity-slideshow-ubuntu, because at 28th september Lithuanian translation was half complete (about 50%), but at 29th - fully translated (100%) :)
<ubuntu-baltix> translation freeze was on 29th of September and pitti told me, that It's OK to finish translation ubiquity-slideshow-ubuntu on 29th of September  :)
<ubuntu-baltix> Evan Dandrea stick an upload in the queue and told me, that" the release team will decide if they want to accept it."
<ubuntu-baltix> So, I'm asking here :)
<infinity> ubuntu-baltix: If the upload is nothing more than updated translations, I'm fine with it.
<cjwatson> it's not in the queue now though
<cjwatson> unless he only *just* uploaded it?
<infinity> Their conversation was half an hour ago..
<infinity> So, I dunno.
<infinity> Maybe he got sidetracked. :P
<cjwatson> right, maybe hasn't finished it yet, I haven't seen any commits
<cjwatson> it does take a while because you have to ask Launchpad for an export and then wait for the mail
<cjwatson> anyway, we'll be notified here when it's uploaded
<ubuntu-baltix> cjwatson: should ev or I do something more?
<cjwatson> ubuntu-baltix: ev needs to do the update.  you don't need to do anything
<ev> just reviewing the delta now
<ubuntu-baltix> ev: thanks
 * infinity raises his brow at https://bugs.launchpad.net/bugs/865150
<ubot4> Launchpad bug 865150 in unity (Ubuntu) (and 2 other projects) "UIFe: Desktop should be titled "Ubuntu Desktop" (affects: 1) (heat: 12)" [Undecided,New]
<infinity> Does anyone really expect us to let that in the week of RC?
<seb128> infinity, there was a pushback from pitti and some documentation people who asked for the logo addition to be reverted because it's just confusing
<seb128> it's similar to the bfb logo for natty which was opening the dash so user tend to click on it and nothing happen, it also makes 2 logos close from each other
<infinity> Oh, I understand the bug.  But UIF was way back there... *points*
<seb128> infinity, I'm not arguing that you should accept it, I'm just pointing that there was not push for it to be dropped from r-t and documentation team people
<seb128> infinity, well the logo was added some days ago...
<infinity> Oh, fair enough on the logo point. :P
<infinity> But the bug addresses several items.
<infinity> String change, nautilus menu hover, etc.
<Laney> Can't we just have the logo removed for now?
<seb128> that's the fallback option "just use Ubuntu"
<Laney> it seems to be a cock up that it somehow got through UIF
<infinity> Yeah, I'd be fine with the bug if it just said "remove the logo we added two days ago".
<infinity> The rest of it is a bit abitious. :P
<infinity> ambitious*
<seb128> I would be fine with that as well
<seb128> what I care about is having that second logo dropped ;-)
<Laney> I also care about reviewing how these kind of changes get made so late
<Laney> but that is a separate topic :-)
 * Laney comments.
<Laney> oh, infinity beat me
<seb128> Laney, "how" is easy, sabdfl and design seem to think that's the change of tweaks that should be allowed late since they are not really ui changes but rather tweaks in feedback to user testing
<Laney> Good job we've got an LTS coming up so can tighten up the ship (and then keep on being tight thereafter).
 * AlanBell hopes the LTS will be useable much earlier than this cycle
<infinity> seb128: There's been discussion of redefining what UI freeze means, and letting it slide to around the same time as string freeze.  That would (probably) work if we can make a very clear division between "UI features" and "UI appearance" (the latter being minor positioning, icons, wallpaper, colours, etc)
<infinity> seb128: But that's going to be a long and potentially contentious discussion. :P
<infinity> seb128: And lots of stuff the design folks wanted in late this cycle was very much featurey, and that just won't fly, IMO.
<seb128> infinity, they don't agree with you on "feature" ;-)
<infinity> seb128: I've noticed. ;)
<seb128> infinity, like their "new features" are "fixes for usability issues that raised in testing"
<seb128> like adding the system settings launcher
<seb128> or the default menu in the panel
<infinity> Great, I find it a usability issue that my software is out of date, or that daemon X doesn't support new protocol Y, or, or...
<seb128> I somewhat agree with them that we should try to fix known usability issues after uif and not wait a cycle
<seb128> but anyway not something we will solve there today
<infinity> Or, they could be planning their stuff now, land it all at the beginning of the cycle, get testing in, respond to feedback, and have it "right" by UIF.
<seb128> but a discussion for UDS for sure
<seb128> right, that would be ideal ;-)
<infinity> But yes, when they don't even land most of it until UIF, it's not a shock that they then find it doesn't test well with users post-UIF.
<infinity> And yes, time for lively debates in Orlando.
<infinity> Need something to distract me from noticing that I'm in Florida.
<infinity> ev: Accepted, thanks.
<ev> thanks infinity
<ev> ^ ubuntu-baltix
<infinity> I'd like to say I read all the new Danish, Hungarian, and Lithuanian translations to make sure they were correct, but that would be a blatant lie. :P
<Laney> A blatant dereliction of release team duty.
<ubuntu-baltix> infinity, ev, thanks
<hrw> hi
<hrw> can armel-cross-toolchain-base 1.75 (universe) be accepted? it fixes bug 864591
<ubot4> Launchpad bug 864591 in armel-cross-toolchain-base (Ubuntu) "gcc-4.6-arm-linux-gnueabi is uninstallable on Oneiric (affects: 1) (heat: 8)" [Medium,Triaged] https://launchpad.net/bugs/864591
<jamespage> hello - please can nova 2011.3-0ubuntu5 be accepted - nova 2011.3-0ubuntu4 is not currently installable on fresh installs
<jamespage> ta
<ScottK> infinity: re apt-get source being sane, that'd be great, but that's certainly not the only issue.
<Laney> sladen: has the font bug been sabdfled or do you expect it to be?
<hrw> can armhf-cross-toolchain-base be accepted? should fix issue with ubuntu armel cross compiler
<hrw> and sorry for generated noise around it
<sladen> Laney: given Mark's desire for it over the last 12 months, I would guess that there's a 50% chance.  I would rather just facilite the process if it does happen
<sladen> Laney: I think if we'd got the stuff from Dalton Maag ~2 weeks earlier, but own views might have been different
<skaet> who just accepted the armhf-cross-toolchain-base?
 * skaet was looking at it and had some questions
<Laney> that is a common question
<cjwatson> not I; although it went with armel-cross-toolchain-base that had already been accepted, didn't it?
<cjwatson> the patch looks OK to me
<Laney> skaet: have we decided on a date for UUFF yet? Are you going to send the announce?
<skaet> I was trying to figure out if the changes around the Multi-arch build code made sense.
<hrw> skaet: it ftfbs without this change
<skaet> Laney,  thread input seems quiescent, so yup,  will go to 1.5 days and make the announce today.   Working on a page for it.
<Laney> I thought 1.5 days was the hard deadline and Final Freeze was some time before that
<Laney> like the normal final freeze
<skaet> hrw,  thanks.   would have liked someone with more multi-arch background to cross check it.
<skaet> but water under bridge.
<hrw> skaet: it is cross compiler - it does not do multiarch at all
<hrw> skaet: one day we will get multiarch cross build dependencies and those packages will vanish
<ScottK> skaet: I accepted it.
<Laney> sladen: The font stuff seems to live on its own schedule, which is weird for something which impacts the user experience so
<hrw> have a nice rest of day
<skaet> hrw,  thanks.
<skaet> ScottK,  ack.
<sladen> Laney: outside contractors
<Laney> quite :-)
<cjwatson> skaet: they make sense.  they're rebasing a patch against code in another package that changed.
<cjwatson> skaet: if you look at the structure of the patch, the first character of the changed lines is ' ', indicating that it's a change in the context against which the patch is being applied, not a change in what the patch does
<skaet> cjwatson,  thanks for confirming.
<skaet> and explaining.
<cjwatson> or rather - the '-Multi-Arch: ...' lines were already in the patch
<cjwatson> (diffs of diffs are a bit confusing.)
<cjwatson> the change this is making is adding lines like 'Pre-Depends: dpkg (>= 1.15.6)' to the context
<cjwatson> it makes sense, just hard to explain :)
<skaet> :)  The Pre-Depends part made sense, but the ' ' line syntax of patch on patch was the part had me scratching head.
<cjwatson> you have to unpack it layer by layer
 * skaet nods
<cjwatson> and if necessary extract both old and new and compare by eye
<skaet> ev,  any more changes expect for WUBI at this point?  (if not, would like to get the signed copy prepared and ready for the images later this week)
<stgraber> skaet: ping
<infinity> stgraber: Accepted.
<stgraber> I'm going to release a minor bugfix release of arkose (2 lines diff), I'd love to have that in the release rather than as SRU. The bug is the CWD in the container being /usr/bin instead of whatever directory you were in when you started the container.
<stgraber> this can have nasty side effects when running "arkose -c 'blah'" as "blah" will be running in /usr/bin (and depending on the arguments, as root)
<slangasek> stgraber: seems a straightforward proposition to me
<cjwatson> I've tried to clear out the ~ubuntu-archive sync queue a little; there are some things that required an FFE in there, but I checked that they had one
<cjwatson> there are a few other things in the queue I didn't sync because I wanted to think about them a bit harder, but this should not stop anyone else from doing them
<cjwatson> looks like the syncs have gone straight through to accepted; the list was htop_0.9-4_source.changes libsynthesis_3.4.0.16.1-1_source.changes logcheck_1.3.14_source.changes phpmyadmin_3.4.5-1_source.changes pyzmq_2.1.9-1_source.changes zeromq_2.1.9-1_source.changes
#ubuntu-release 2011-10-04
<infinity> Stupid queue timeouts.  Didn't notice that my ubiquity accept failed.
<stgraber> ubiquity ftbfs on arm, reason is "gcc not found", interesting...
<stgraber> any known issue on the armel builders? :)
<infinity> Hrm?
 * infinity looks.
<stgraber> https://launchpadlibrarian.net/81861398/buildlog_ubuntu-oneiric-armel.ubiquity_2.8.2_FAILEDTOBUILD.txt.gz
<infinity> I see nothing about GCC not found...
<infinity> The following packages have unmet dependencies: gnome-icon-theme : Depends: libgtk-3-bin but it is not going to be installed
<infinity> E: Unable to correct problems, you have held broken packages.
<infinity> ^--- Archive skew.
<infinity> Read the bottom of logs, not the top? :)
<infinity> "sh: gcc: not found" is dpkg-architecture running in the base system, where there shouldn't be gcc.
<stgraber> yeah, I guess I'm too used to skip the bottom because of the 10 pages of package removal :)
<infinity> Every build log shows that.  We should just shut it up. :P
<infinity> When GTK+3.0 finally finished building, I'll retry ubiquity.
<infinity> finishes*
<slangasek> infinity: shut it up> yes please :)
<pitti> Good morning
<pitti> slangasek: 854622> I thought mvo reproduced it with a natty install and oneiric upgrade
<pitti> slangasek: anyway, seems you found the reason at last? I saw mvo's upload
<slangasek> pitti: we never pinned down the exact source of the bug, but that's immaterial; we still need the oneiric package to fix up the wrong symlink, whenever it is that it broke
<pitti> infinity: I just released a new media-player-info with lots of new devices; this has a standing SRU exception as well, and is rather harmless
<pitti> infinity: do you mind if I upload it for oneiric now?
<pitti> or do you prefer an SRU at this point?
<pitti> infinity: it contains textual info about mp3 usb sticks to tell music players about their name, format, directory for music, etc.
<ScottK> pitti: I'd say upload it.
<pitti> done
<infinity> pitti: Yeah, just upload it.
<pitti> the bash-completion upload got a debian-changes-1:1.3-1ubuntu5 which reverts one of the patches
<pitti> I'll reject and tell bryce
<infinity> Yep.
<infinity> I was just about to. :P
 * pitti looks at libvirt, finds that it's way over his head, and leaves review to Daviey
<infinity> Hahaha.
<infinity> Why do you think it's still in the queue? :)
<infinity> I was too tired to do it justice.
<infinity> pitti: Oh, want to stage an apport upload to go with that kerneloops one?
<infinity> pitti: Or planning to just do it on RC day?
<pitti> infinity: it's in the release process documentation for final; I was planning to upload it on Friday right after RC
<pitti> together with the final langpacks, etc.
<infinity> Mmkay.
<infinity> Maybe we should add kerneloops to that same documentation.
<pitti> it is
<infinity> Heh.
<infinity> So someone just got excited? :)
<pitti> or do you prefer an SRU at this point?https://wiki.ubuntu.com/ReleaseProcess , minus 7 days
<pitti> infinity: apparently so :)
<infinity> "Top up the CDs with language packs" <--- I like how that assumes we even have room anymore.
<pitti> infinity: we can still fit another Xhosa
<pitti> infinity: oh, there totally is space for Klingon!
<infinity> *smirk*
<pitti> Ubuntu for Human^Wwarrior beings
<pitti> erk, put a "Linux" there
<ScottK> No media-player-info diff yet and I'm off to bed, so I'll look at it in the morning if infinity didn't mash the "I believe" button already.
<ScottK> Good night.
<pitti> infinity: apt looks ok, but please reupload with a reference to bug 865828 in the changelog
<ubot4> Launchpad bug 865828 in apt (Ubuntu Lucid) (and 1 other project) "Backport apt-ftparchive Packages/Translations split code to lucid (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/865828
<infinity> pitti: Err, doesn't it have one?
<pitti> nope
<infinity> Oh, bah.  I uploaded the wrong copy after I updated the changelog.
<infinity> Reject away.
<pitti> http://launchpadlibrarian.net/81876688/apt_0.7.25.3ubuntu9.8_source.changes
<infinity> pitti: Reuploaded.
<pitti> cheers
<infinity> pitti: If you kept the old one, you can verify that this only changes the changelog (and the PO timestamps...)
<infinity> Silly build system.
<pitti> yeah, merging po files on clean is kinda evil, and rather pointless
<infinity> It also rebuilds configure.
<infinity> But at least that doesn't introduce changes if your autotools don't change.
<infinity> (But you can tell if someone uploaded apt from another release)
<infinity> pitti: And in the queue again.
<pitti> thanks, will get to it as soon as the diff arrives
 * pitti pokes some other SRUs in the meantime
<pitti> infinity: accepted, thanks!
<infinity> pitti: Danke.
 * tumbleweed has been using ubuntu mono in gnome-terminal for a day, and it's not growing on me yet. bug 866058 is the most annoying problem
<ubot4> Launchpad bug 866058 in ubuntu-font-family-sources (Ubuntu) "Mono: 'm' too wide at 11pt (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/866058
<Laney> does "Ubuntu Mono 13" mean 13pt?
<tumbleweed> probably ppem (pixels per em), but I'm not a font person :)
<Laney> dunno, and anyway it's been sabdfled so no matter :-)
<Daviey> Hmm, Are we having a RC this time?  I thought we were not, but it seems to be on the schedule.
<pitti> Daviey: it's for testing/QA, but we won't put it on releases.u.c./announce it
<Daviey> ok, thanks
<cjwatson> anyone have opinions on bug 862920, especially bug 861206?
<ubot4> Launchpad bug 862920 in ubuntu "[FFe] Multiple input method related updates (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/862920
<ubot4> Launchpad bug 861206 in fcitx (Ubuntu) "Please sync fcitx (1:4.1.1) from Sid to universe (affects: 1) (heat: 12)" [Undecided,Incomplete] https://launchpad.net/bugs/861206
<cjwatson> I've found a problem with bug 861204 that needs to be fixed, but am wondering about the rest of it
<ubot4> Launchpad bug 861204 in sunpinyin (Ubuntu) "Please sync sunpinyin (2.0.3-4) from Sid to universe (affects: 1) (heat: 12)" [Undecided,Incomplete] https://launchpad.net/bugs/861204
<cjwatson> I'm inclined to say that it's OK as long as the new input methods aren't used by default in Oneiric
<pitti> the sunpinyin syncs seem appropriate to me (impact wise, modulo the debian/rules bug you uncovered); I'm less enthusiastic about the others, though
<pitti> googlepinyin sounds interesting for the future, as it's a lot smaller
<cjwatson> it seems like a moderate amount of work to cram in at this point ...
<cjwatson> I really can't say e.g. whether Chinese users are better served by having this but potentially having it be buggy, or having just the older methods
<pitti> seems we don't pull in fcitx for any language right now
<pitti> so it's low-risk; but just like you I have zero ideas whether it's an improvement/stable :(
<cjwatson> the new packages aren't especially risky if not used by default
<cjwatson> well, I'll wait a while to see if anyone else has thoughts
<pitti> right, we don't; I'm just not sure how much they actually got tested under oneiric (as opposed to under sid)
<cjwatson> yeah
<jamespage> please could nova  2011.3-0ubuntu5 be accepted - closes bug 865169 and completes bug 832507 (incorrect patch uploaded with -0ubuntu4)
<ubot4> Launchpad bug 865169 in nova (Ubuntu) "nova-common postinst fails to complete for new installations (affects: 2) (heat: 12)" [Critical,In progress] https://launchpad.net/bugs/865169
<ubot4> Launchpad bug 832507 in nova (Ubuntu) (and 2 other projects) "console.log grows indefinitely (affects: 3) (heat: 262)" [High,Fix released] https://launchpad.net/bugs/832507
<cjwatson> Laney: new comments on bug 831402, and it came up on -devel-discuss as well
<ubot4> Launchpad bug 831402 in dlr-languages (Ubuntu Oneiric) (and 1 other project) "dlr-languages version 20090805+git.e6b28d27+dfsg-3 failed to build in oneiric (affects: 2) (heat: 16)" [High,Won't fix] https://launchpad.net/bugs/831402
<pitti> eek, langpack spam from cronjob
<pitti> we'll get fresh ones on Friday, but dpm asked for another set of update packages for translators
 * pitti accepts
<pitti> Daviey: can you please have a look at the libvirt upload in unapproved?
<Daviey> pitti: wilco
<Daviey> pitti: I need to speak with hallyn when he is online, i knew something was coming; but it's much larger than i hoped.  Will comment later.
<Laney> cjwatson: yeah, we know that git head works, the problem is DFSGing it suitably
<cjwatson> Laney: patches aren't extractable?
<Laney> I'm sure they are, given enough effort, but I'd be inclined to package a snapshot (maybe not for O though)
<Laney> but I personally don't know too much about iron*; cmn was the guy in the team who worked on this package most recently but has ran out of time/motivation sadly
<Laney> (our current snapshot is pretty old)
<doko> Laney, is this dlr-languages? the get-orig-source target does have the dfsg cleaning stuff
<Laney> yes, but it's not entirely up-to-date
<Laney> I am confident that it's possible to get a new snapshot packaged, the problem is that nobody has volunteered to do it.
<Laney> commented
<doko> so much for my plan to have an upload-free week ...
<doko> please review openjdk-6 (ARM/JamVM specific fix)
<pitti> doko: will do, just waiting for the debdiff to appear
 * pitti removes eclipse-plugin-cvs to clean up NBS, eclipse-jdt just suggests it
<cjwatson> openssl could use a second pair of eyes
<pitti> cjwatson: looks fine, accepting
<cjwatson> thanks
<doko> Daviey, cobbler-enlist needs seeding
 * sladen grumps at the steam-rollers
<mdeslaur> ^ openssl upload there is to correct a slight issue with previous upload, as discussed with cjwatson
<ScottK> Laney: Technically I don't think ubuntu-mono was SABDFL'ed.  He said please and pitti said OK.
<ogra_> real SABDFL'ing means to be unpolite ?
<ogra_> :)
<ScottK> No, it means to direct.
<pitti> well, I said the patch was ok under the conditions
<pitti> if we need to swallow this thing, then let's at least not break all derivatives
<cjwatson> bug 848916 - er, doesn't this require an FFE?
<ubot4> Launchpad bug 848916 in webkitkde (Ubuntu) "Sync webkitkde 1.1.0git80efcf77-1 (universe) from Debian experimental (main) (affects: 1) (heat: 8)" [Wishlist,Confirmed] https://launchpad.net/bugs/848916
<utlemming> skaet: could you add http://uec-images.ubuntu.com/oneiric/20111004/ to the tracker for the Ubuntu Cloud Images?
<cjwatson> bit early for iso tracker stuff isn't it?
<utlemming> cjwatson: isn't the RC on Thursday?
<cjwatson> no images are being released on Thursday; that's when we prepare a candidate for the release next Thursday
<skaet> utlemming, we'll be doing a release candidate like we did on Natty, rather than the full production.
<utlemming> okay, thanks for the clarification. This is my first time through a release cycle. :)
<skaet> utlemming,  np.  Glad you have them ready.   We'll start posting on Thurs/Friday depending when the langpacks land.
<highvoltage> Yay, my french lesson for friday got cancelled so I can actually make a release meeting.
<ogra_> highvoltage, i bet we'll skip this week then :P
<highvoltage> hmm, that's what happened the last time I had a Friday open :-/
<skaet> highvoltage, ogra_ - release meeting is still planned for this friday.  ;)
 * skaet figures it will be the last until after UDS.  :)
<skaet> ev,  https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/740903,  I'm seeing it milestoned for 11.10, but also marked as Won't Fix for oneiric - what's the plan with this one?
<ubot4> Launchpad bug 740903 in ubiquity (Ubuntu Oneiric) (and 2 other projects) "return_to_partitioning fails when the replace option fails (affects: 6) (heat: 28)" [High,Won't fix]
<cjwatson> looks like unhelpful LP semantics
<skaet> very unhelpful semantics. :P
<ev> skaet: it's quite the edge case
<ev> if you even saw that bug in the first place, you'd have another bug :)
<cjwatson> what I mean is that when you mark a release task won't fix it doesn't clear the milestone when reinstating the default-series task
<Laney> ScottK: maybe technically not, but it seemed to be effectively so.
<ev> skaet: I've kept it open to keep an eye on return_to_partitioning which has sometimes not worked exactly as designed
<Laney> but never mind.
<ev> skaet: it's a problem solved by test coverage, really.
<skaet> ev,  ok, if I target it to "P" so it keeps open, and remove the milestone so it stops showing up on the release critical bug list?
<ev> absolutely
<skaet> ev, done.
<ev> fanx!
<cjwatson> I've removed the 11.04 milestone too, which is obviously nonsensical at this point
<skaet> ScottK,  are you still trying to get bug 793679 fixed this week?  or is it going to be release noted?
<ubot4> Launchpad bug 793679 in kdeadmin (Ubuntu Oneiric) (and 1 other project) "systemsettings crashed with ImportError in /usr/share/kde4/apps/system-config-printer-kde/options.py: No module named ppdippstr (affects: 7) (dups: 6) (heat: 53)" [High,Confirmed] https://launchpad.net/bugs/793679
 * ScottK looks.
 * doko rejects python2.7, patching a generated file
<bdmurray> Is kerneloops still held in the queue?
<skaet> bdmurray,  yes
<bdmurray> okay could it be approved / let through?
<ScottK> skaet: I think I can fix it.
<skaet> ScottK, goodness.
<skaet> bdmurray, there was some discussion on the timing of it applying, but I'll need to look up details, unless someone else remembers?
<skaet> cjwatson, infinity, ScottK, ^
<ScottK> I thought it wasn't until we started doing RC images (i.e. Friday or later)
<ScottK> I may misremember though
<cjwatson> I suspect it's probably OK around nowish
 * ScottK doesn't have a real opinion on it.
<cjwatson> I think we'll be starting with RC images around Thursday?
<skaet> yes,  as soon as the langpacks land.
<Daviey> doko: Yeah, i really only cared for the -udeb to be in main.. but we are supporting it anyway, so i'll add it.
<doko> Daviey, thanks
<doko> skaet, is there a reason to open a task for the p-series in bug 853688?
<ubot4> Launchpad bug 853688 in eglibc (Ubuntu P-series) (and 5 other projects) "Natty to Oneiric - failed to calculate the upgrade with gcj-4.4-jre installed (affects: 19) (dups: 8) (heat: 104)" [Undecided,New] https://launchpad.net/bugs/853688
<skaet> doko,  did it since command-not-found isn't likely to get fixed until updates.   eglibc part should have been marked with same status as Oneiric.
<doko> skaet, ok, did set it to invalid
<skaet> thanks doko.
<slangasek> cjwatson, bdmurray: do we need an apport upload that matches the kerneloops one?
<slangasek> or is it still early for that?
<Daviey> Please can libvirt be accepted, it resolves an LXC race.  Whilst the patch could have been smaller, we favoured upstream cherrypicking over distro patches.  It's received testing, and passed the platform qa regression testsuite.  It really only impacts LXC, and seems good.  Thanks.
<doko> seb128, pitti: do you intend to address the libgnomeprintui ftbfs? please either fix it directly, or find another gnome/gtk lib which did move libs to private libs after the FF
<jdstrand> re libvirt> fyi, the qrt tests don't have lxc tests in it, but the build tests do. if it passes qrt, then it should not break non-lxc badly
<Daviey> jdstrand: thanks
<micahg> Daviey: libvirt affects a lot more than lxc, but I would go with whatever jdstrand says about it :)
<jdstrand> note, I did not test the LXC bits. I am just vouching for qrt and the in-build tests being thorough
<ScottK> skaet: Uploaded.
<Laney> singularity can be accepted
<skaet> thanks Laney,  doing
<seb128> doko, pitti: I've not special interest to fix GNOME lib deprecated for years in Universe, that comes after issues in the default installation my list, but I can have a look if I run out of other things to do
<seb128> re. libgnomeprintui
<skaet> seb128,  could I ask you to review the latest unity upload?   I think that pitti's off for the night, and would like to get it into the builds.
<skaet> http://launchpadlibrarian.net/81934511/unity_4.20.0-0ubuntu2_4.22.0-0ubuntu1.diff.gz
<seb128> skaet, ok, I can do that ;-)
<seb128> looking
<skaet> thanks! :)
<seb128> ups
<seb128> sorry flacky wifi
<seb128> skaet, seems fine to me, we got a pre-version in the ubuntu-desktop ppa yesterday which got testing by a few people
<skaet> thanks seb128,  accepting it then.
<seb128> that's a small update over what we tested with small fixed and I know didrocks tested before uploading
<seb128> skaet, thanks
<seb128> skaet, if you could ack the few GNOME updates as well that would be welcome
<seb128> they should be easier to review than unity ;-)
<skaet> seb128,  will take a pass, and ack the ones I feel I understand. ;)
<seb128> skaet, thanks
 * skaet seems to be getting timeout errors from launchpad :P
<skaet> hmmph,   seems to be an issue accepting unity.
<skaet> slangasek, could you see if launchpad will cooperate for you with accepting unity?
<slangasek> skaet: it's reviewed and just needs an accept?
<skaet> slangasek,  seb128 ok'd it,  and launchpad just keeps timing out on me.
 * slangasek goes behind the web interface's back
<ScottK> pitti: Could you review kdeadmin.  I uploaded it, so I can't ...
<skaet> seb128, am a bit concerned about the gnome-control-center one,  since it seems to be impacting user interface a bit - bug 862027,  would rather pitti ok it.
<ubot4> Launchpad bug 862027 in ubuntu-mono (Ubuntu Oneiric) (and 1 other project) "System Settings Keyboard icon indistinct with Ambiance (affects: 2) (heat: 22)" [Medium,Fix committed] https://launchpad.net/bugs/862027
<skaet> s/ok/comment on/
<doko> please review eglibc, just makes all the packages depending on libgcj10 and libgnat installable again
<doko> please review python2.7, linking the _curses extension against libncursesw
<seb128> skaet, ok, works for me, that one doesn't need lot of testing and isn't that important, let's see what pitti says about it
<jdstrand> skaet: I would like to do an apparmor upload that only fixes a test suite problem. this will help with SRUs, etc in the future. ok to upload?
<ScottK> jdstrand: Sounds good.
<jdstrand> cool
<jdstrand> it'll be a bit, but I'll get it in soon
<skaet> jdstrand, +1 from me as well.
<seb128> the ubuntuone-client-gnome update fixes the broken version that landed yesterday and makes nautilus segfault for a lot of users
<seb128> review would be appreciated for it ;-)
<jdstrand> skaet: cool, thanks
<seb128> thanks
 * skaet --> lunch
<infinity> doko: I'm thinking that stray patch in eglibc was unintentional.
<infinity> doko: http://launchpadlibrarian.net/81935897/eglibc_2.13-20ubuntu4_2.13-20ubuntu5.diff.gz
<infinity> doko: Everything past debian/control is suspect, really. :P
<ScottK> infinity: Would you please look at kdeadmin?
<doko> infinity, ahh, the diff of the previous upload that I committed. will remove. the other changes are ok
<doko> at least, intended
<doko> rejected and re-uploaded
<infinity> ScottK: As a minor nitpick, you might want to remove that stray trailing newline from kdeadmin-4.7.1/debian/system-config-printer-kde.links in your VCS. ;)
<infinity> ScottK: (Obviously not a bug, accepting)
<ScottK> OK.
<jdstrand> skaet, ScottK: apparmor uploaded
<jdstrand> thanks again
<ScottK> infinity: Done.  Thanks.
<infinity> seb128: Regarding bug#865957, what's the point in recommending a universe package?  It won't get pulled in on a fresh install.
<ScottK> apparmor accepted.
<infinity> Well, except on the images that build with universe on by default. :P
<jdstrand> \o/
<ScottK> Recommending Universe from Main isn't allowed though.
<infinity> ScottK: Actually flat-out not allowed?  When was that decree passed?
<infinity> (Just to avoid the above confusion in behaviour, I assume?)
<ScottK> Same time we started installing recommends by default.
<ScottK> Main has to be transitively closed.  With installing recommends by default that means Main can't Recommend Universe.
<infinity> Well, missing recommends are still ignored with install-by-default, surely.
<infinity> But I agree that from a consistency standpoint it's bad to recommend across components like that.
<ScottK> Yes.  It will work.
<ScottK> So there won't be an earth shattering kaboom, but it's not in line with how it's supposed to work.
<ScottK> It'll show up in component mismatches and doko will come get you.
<infinity> Policy or not, it's wrong to me anyway.
<seb128> infinity, it's a binary of a source in main so I guess it will be promoted once it's on component-mismatch? ;-)
<infinity> seb128: See #distro.
<seb128> infinity, it's a a few kb binary and pitti acked to get it on the CD today
<infinity> seb128: Oh, someone could have mentioned this conversation. :P
<infinity> seb128: (Which I don't see...)
<seb128> infinity, it was on #ubuntu-desktop this afternoon
<seb128> infinity,
<seb128> [13:47] <seb128> or any reason to not install it?
<seb128> [13:47] <pitti> seb128: nothing depends on it
<seb128> [13:47] <seb128> pitti, would it be fine to make g-c-c recommends it?
<seb128> [13:47] <pitti> no other particular reason from what I can see
<seb128> [13:47] <pitti> it's 30 kB
<seb128> [13:47] <pitti> seb128: sure
<seb128> infinity, basically
<stgraber> ScottK: can you accept librecad? apparently queuebot didn't see it (probably because it's a sync?)
 * ScottK looks
<slangasek> see, this is why #ubuntu-desktop should just be #ubuntu-devel :)
<seb128> slangasek, you wouldn't like #ubuntu-desktop to be on #ubuntu-devel
<ScottK> stgraber: Done.
<stgraber> ScottK: thanks
<kenvandine> queuebot would have missed intltool too then
<ScottK> It did.
<seb128> slangasek, I think #ubuntu-desktop is quite chatty and noisy
<slangasek> seb128: yes I would :)
<seb128> slangasek, well maybe you would but others probably wouldn't ;-)
<infinity> I wouldn't mind.
<slangasek> oh well, who cares about them ;)
<seb128> lol
<stgraber> quite a lot of us are in both anyway, might as well merge them :)
<seb128> well, sometime #ubuntu-desktop is too chatty for desktopers, i.e the number of cross conversations are hard to follow
<infinity> desktop bugs affect most developers, being able to jump in on those discussions without being in Yet Another Channel wouldn't hurt my feelings. :P
<seb128> not sure we could have one channel and still keep it usable
 * infinity joins desktop anyway.
<kenvandine> desktop is fun!
<kenvandine> :)
<infinity> siretart's going to hate me.
<infinity> Two rejects in a row for the same package.
<slangasek> honestly, my concern is that the development discussions are off in a separate channel which just ends up with duplicated / uncoordinated effort (like above)
<doko> one more person, does it make a difference ;-)
<doko> yes, same for -server
<slangasek> yep
<seb128> slangasek, realistically there is too much happening in Ubuntu to channel it on one channel and keep it usable
<slangasek> I am unconvinced :)
<infinity> Maybe.  But desktop stuff is so core to what everyone does.
<seb128> there is also a part of those teams which have interest in the specific part the channel is about and probably wouldn't join discussion on #ubuntu-devel
<infinity> It's not quite like -installer, where 99% of the developers don't understand or care.
<seb128> like we are quite friendly chatty there
<doko> realistically, I don't want to first chase down the channel, and the person
<seb128> not sure I would feel right having those random jokes and chats on #ubuntu-devel
<doko> just address it one one channel
<infinity> seb128: We joke randomly on -devel too.  You should visit sometime. :)
<seb128> lol
<seb128> doko, nobody ask you to chase desktop people down ;-)
<slangasek> yes, you should set traps and wait for them to come to you
<slangasek> just, say, delete libnss - you'll catch them easily
<infinity> I like the way you think.
<doko> slangasek, that did prove to work ;-P
<slangasek> :-)
<infinity> doko: After doing such thing, though, you need to go hide in #ubuntu-undiscoverable, chat with yourself, and wait for them to show up.
<infinity> s/thing/things/
<doko> infinity, that's called #ubuntu-toolchain
<infinity> Oh, fair point.  I don't think I rejoined that after coming back.
<infinity> Nor #ubuntu-server.
<seb128> see, it's not only -desktop :p
<infinity> I haven't really missed either.
<doko> there is no #ubuntu-foundations
<infinity> seb128: I don't know his it is today, maybe people actually use it, but back in The Day, #ubuntu-toolchain saw about one discussion a month.  :P
<seb128> doko, right, that's #ubuntu-devel ;-)
<slangasek> heh
 * infinity registers a consolidating-irc-channels spec.
<doko> seb128, no, it's not that funny if there is not one channel that anybody in distro joins
<seb128> doko, distro people who are on #ubuntu-desktop are usually on #ubuntu-devel
<infinity> But I have a much better idea than just forcing some people to move to -devel, and others to do whatever.  I think we need to have two channels, #ubuntu-a-m and #ubuntu-n-z, and whatever letter your line starts with, that's the channel you send it to.
<seb128> infinity, you can't put g and k in the same channel....
<infinity> You can learn to get along.
<seb128> I will start to cry :p
<kenvandine> lol
<doko> g catches up with k
<seb128> well nowadays we are on u, but still ;-)
<slangasek> pff, it's the same point of articulation, merely a difference of voicing
<slangasek> (we were talking about linguistics, weren't we?)
<kenvandine> seb128, now it is g and q
<ScottK> re consolidating ubuntu-desktop and -devel: Are you going to conslidate ubuntu-server, kubuntu-devel, etc in there too?
<ScottK> There are lots of developers that really don't care about Ubuntu the desktop.
<slangasek> ScottK: if I had my druthers
<ScottK> How about #ubuntu-motu?
<ScottK> I guess if it's all of them, I think it's OK.
<slangasek> sure
<slangasek> (not that I can ever keep straight the current rationale for #ubuntu-motu being a separate channel, either)
 * micahg sees it as an opportunity for training w/out bothering in progress discussions
<ScottK> One could argue that could be done in #ubuntu-packaging.
<jbicha> let's create a new IRC channel to discuss this issue!
<ScottK> In the current paradigm there's no particularly special role for MOTU in training new devs
<slangasek> which is why I'm not sure why it's a distinct channel :)
<ScottK> I think the channel and the ML can go away.
<ScottK> Both are not very active anymore anyway.
<micahg> the channel seems pretty active to me and the ML has been seeing more activity lately as well, but folding it in would be fine with me
<micahg> it would stop the main/universe where do I go questions
<Laney> I quite like having a community around universe.
 * micahg likes that too
<ScottK> It's far less active than it used to be before $DECISION_MAKER decided try and kill of MOTU.
<Laney> indeed it is, and we have a disturbing lack of new people coming through, but I hope we can repair the damage over time
<highvoltage> Could it perhaps also be that there is greater awareness now that new packages and bug fixes should rather be done in debian first?
<ScottK> I think it's a feeling that there's less room for development contribution if you're !Canonical.
<ScottK> Also I think the user base has shifted over time.
<ScottK> We get a lot fewer breathless "Oh, must have latest $CRACK" FFes than we used to.
<highvoltage> ScottK: well, for some ubuntu-specific stuff that is true. but I don't think it applies at all to universe.
<ScottK> highvoltage: How well do people understand that from the outside?
 * micahg has tempered his "latest $CRACK" filings over time
<highvoltage> ScottK: good question.
<highvoltage> ScottK: I guess blogging about it would help to some degree. I'd be happy to do that if you could proof-read it to make sure it's all sane.
<highvoltage> I also wish there were more information/communication about the archive re-org.
<slangasek> I've switched from crack to ecstasy, personally
<infinity> slangasek: But "I want the latest $X" can be a confusing statement.
<slangasek> heh
<infinity> I wonder if the mythbuntu folks would get angry about me co-opting their brand to make an always-broken flavour called methbuntu.
<infinity> Basically, it would just be an installer that shows you things that make you really, really happy for 30 minutes, and then convinces you to plug in all your removable media, so it can randomly delete stuff you like.
<stgraber> infinity: also make sure to daily sync from experimental and add the DX/desktop daily build PPA in there, that should be all you need for it
<Laney> are AAs still doing the sync queue?
<ScottK> Yes.
<ScottK> cjwatson did it as recently as today or yesterday.
<Laney> sounds good. Didn't know whether to ping or not; I'll leave it then.
<ScottK> I'm going to push one more round of kdepim related changes.  It's mostly turning our git snapshots into 4.7.2 and one good bugfix.
<cjwatson> I did most of it, not quite all
<cjwatson> I think there were two I needed to check on - anyone want to comment on webkitkde?
<cjwatson> seemed rather FFE-worthy to me
<cjwatson> highvoltage: quite honestly, I wish I'd never started with archive reorg and would rather forget about it than blog about it
<cjwatson> it seemed to make sense, and then turned into a couple of intertwined ghastly messes
<cjwatson> the whole "MOTU is being killed off" meme was never my intention and I think has been a clear net negative
<cjwatson> whatever the technical pluses of consolidating the components might have been
 * micahg hugs cjwatson
<Daviey> micahg: I'm fully aware that libvirt affects more than lxc, but thanks for the pointer.
<micahg> Daviey: I figured you were, which is why I was puzzled by your comment
<Daviey> micahg: The patchset in the upload resolves an lxc race.
<micahg> ah
<jdstrand> skaet: security review added to bug #834442
<ubot4> Launchpad bug 834442 in translate-toolkit (Ubuntu Oneiric) (and 1 other project) "[MIR] translate-toolkit (affects: 3) (heat: 20)" [High,Confirmed] https://launchpad.net/bugs/834442
<skaet> jdstrand,  ack.  thanks.
<jdstrand> skaet: I'd like another member of the mir team to make the final decision
<jdstrand> skaet: perhaps mterry since he did the initial packaging review and is familiar with it
<skaet> jdstrand,  based on what you're seeing,  and the lateness,  it doesn't look good.   Yes, getting mterry's opinion on doing the split out would be good.
<jdstrand> skaet: well, while I prefer the split, it wouldn't be the worst thing to get it in. I am new to the mir team and getting my feet wet wrt acceptance criteria
<slangasek> stgraber: review requested for https://code.launchpad.net/~vorlon/ubiquity/lp.813065/+merge/78179, which fixes the bug for me
<skaet> slangasek: can you have a look at bug 834442?
<ubot4> Launchpad bug 834442 in translate-toolkit (Ubuntu Oneiric) (and 1 other project) "[MIR] translate-toolkit (affects: 3) (heat: 20)" [High,Confirmed] https://launchpad.net/bugs/834442
<jdstrand> skaet: I'm ending up wearing 2 hats-- the security hat, and then the mir hat. making sure I am wearing the right one is what I am trying to work out ;)
<slangasek> ok
<skaet> thanks.  :)
<slangasek> skaet, jdstrand: wasn't this meant to become an MIR *only* if the recommends on python-aeidon needed to be kept?  translate-toolkit itself has been in main forever
<slangasek> not that I object to you reviewing the security of the package, but it doesn't seem to be required by the MIR process :)
 * jdstrand scratches head
<jdstrand> oh, I see, libreoffice doesn't need translate-toolkit any more
<jdstrand> so if we wanted to keep it on its own, we needed the mir
<slangasek> "the b-d should be removed, or the [python-aeidon] component mismatch (including further dependencies) should be addressed, and this report converted to a MIR.
<slangasek> "
<slangasek> meaning an MIR *for python-aeidon*, not for translate-toolkit
<slangasek> and per https://bugs.launchpad.net/ubuntu/+source/translate-toolkit/+bug/834442/comments/1, it is still needed for LibO
<ubot4> Launchpad bug 834442 in translate-toolkit (Ubuntu Oneiric) (and 1 other project) "[MIR] translate-toolkit (affects: 3) (heat: 20)" [High,Confirmed]
<jdstrand> well, I guess this can be closed as the rdepends of translate-toolkit don't include python-aeidon
<jdstrand> that was an unfortunate title for the bug :\
<skaet> indeed.   thanks jdstrand, slangasek.   glad that's sorted.
<slangasek> jdstrand: well, Sweetshark evidently misunderstood what doko was asking, perhaps someone should clarify with him
<jdstrand> and by 'rdepends', I of course meant 'depends' :P
<slangasek> ('MIR' wasn't in the original bug title)
<jdstrand> no matter, it is all resolved now
<jdstrand> I guess I can comment in the bug
<jdstrand> slangasek: thanks for looking at it
<slangasek> sure thing :)
<highvoltage> cjwatson: how about putting archive reorg to rest softly and officially?
<highvoltage> cjwatson: also, *hug*
<micahg> highvoltage: personally, I'd rather see it driven to completion while trying to help MOTU recover
<highvoltage> micahg: hmm, interesting
<ScottK> Is the bot dead?
<ScottK> slangasek, infinity, etc: Would one of you review akdonadi/kdepim/runtime/libs?  Should be minimal diffs.
<infinity> ScottK: I will in a sec.
<ScottK> Thanks.
<infinity> ScottK: Accepted.
#ubuntu-release 2011-10-05
<Daviey> * Please can someone accept libvirt, thanks *
<highvoltage>  /win 32
<infinity>  /linux
<infinity> Daviey: You've gone over it with combs of various fine-toothiness?
<Daviey> infinity: yes, it was discussed earlier. :)
<Daviey> There is a Ubuntu grown patch which is smaller to resolve the same issue, but the consensus was upstream cherry pick.
<Daviey> (and is passes the qa-regression-testsuite)
<Daviey> and oddly, seems to work :)
<infinity> Weird.
<Daviey> infinity: thanks
<ScottK> infinity: Thanks.
<ScottK> That one ^^^ should fix pulse/skype integration.
<infinity> ScottK: Wait, is that why Skype keeps freezing up on my system?
<ScottK> Not sure.  I mostly know it fixes phonon not finding pulse.
<ScottK> Thanks.
<infinity> The patch feels incorrect to me, but it does what it says on the tin.
<infinity> (It would make more sense, surely, to try to detect if there's only a two-part version, and only then spoof the 0?  Unless Pulse upstream has decided to move to two-part versions indefinitely, I guess)
 * micahg doesn't understand why software make versions dependent on mutiple parts of a version
<infinity> micahg: When that version defines an API, it gets interesting.
<infinity> micahg: Which is the case with Skype.
<infinity> Or, rather, how Skype was using pulseaudio.
<infinity> From what I can tell.
<infinity> And others, I'd assume.
<micahg> still, shouldn't the function that checks the version do a sane check regardless of how many points in the version?  i.e. 1.0 > 0.9 or whatever
<infinity> Probably.
<infinity> But if you're used to checking for major.minor.patchlevel, you might do it wrong. :P
<infinity> And fixing everything that does that is harder than just keeping a consistent scheme.
<micahg> yes, if you're checking for an exact match, that's probably wrong, we've seen this before (kernel)
<infinity> Oh, I know.
<infinity> I just want dpkg --compare-versions in the standard libc. :P
<SpamapS> Has anyone tried a debootstrap of oneiric in the last 3 hours?
<SpamapS> We're getting a corrupt Packages.gz problem
 * ScottK debstraps a chroot from inside a chroot to see what happens.
<ScottK> deb/deboot
<SpamapS> might have cleared up
<ScottK> deboostrap inside a chroot is apparently like crossing the streams.
<ScottK> boo/boot.
<infinity> SpamapS: What was the actual error message?
 * infinity sees no issues on an hour-old mirror.
<pitti> infinity: mesa-utils> sorry, didn't see that it was from a universe source; in my obsolete world model it was built by mesa
<pitti> so let's not worry about this for oneiric then
<micahg> hi pitti, I will hopefully have a chromium upload for oneiric shortly , do I need buy in again from lubuntu and mythbuntu?
<pitti> micahg: as for potentially breaking their daily build, or what for?
<micahg> pitti: for potentially breaking their RC?
<pitti> I missed how that worked previously; but I guess can't hurt to ping them
<pitti> micahg: does it build an arch:all package with strict dependencies?
<micahg> I was supposed to update for beta 2, but it never happened
<pitti> so that a late amd64 build would break installability?
<micahg> yes
 * micahg will run a test i386 build after amd64 finishes
<pitti> infinity: ^ this is a looong story; are you interested in hearing it, or just want me to review?
<pitti> (4 people, 2 hours of discussion, an etherpad, and two merge proposals)
<pitti> but now we at least all have a shared understanding what lightdm did wrong, and what needs to happen
<pitti> infinity: accepting, I'll take the bullets
<micahg> pitti: will it make much of a difference if I upload chromium now or in ~8 hrs?
<pitti> micahg: how long does it build? but in general, the earlier the better
<micahg> pitti: i386 3hrs, amd64 1hr, armel 24
<pitti> micahg: oh, then please "now"
<micahg> pitti: ok
<micahg> pitti: can you review chromium as soon as it gets in, I'd like to go to sleep soon :)
<pitti> micahg: thanks, accepting
<pitti> Laney: why do we need the dbus-sharp sync? it doesn't seem to change anything compared to our version in oneiric?
<micahg> pitti: thanks, I'll check for any issues in the morning my time, have a good day
<pitti> micahg: sleep well, thansk!
<Laney> pitti: indeed, it was just to get the pkg back in sync. The world looked rather empty so I jumped in there.
 * cjwatson will be out for a bit - taking K to physio
<pitti> ^ that's from me, review appreciated
<pitti> seb128: would you mind peer-reviewing http://launchpadlibrarian.net/82012196/gnome-menus_3.2.0-0ubuntu1_3.2.0-0ubuntu2.diff.gz ?
<seb128> pitti, can do
<seb128> pitti, do you think bug #864174 should be rc?
<ubot4> Launchpad bug 864174 in lightdm (Ubuntu Oneiric) (and 1 other project) "boot hangs waiting for lightdm after purging gdm (wrong default-display-manager) (affects: 3) (heat: 16)" [High,Confirmed] https://launchpad.net/bugs/864174
<seb128> not sure how often it happens, or how
<pitti> seb128: I think this can be SRUed, as it's pretty much an upgrade matter
<pitti> seb128: but if we can get a fix nowish, fine for me to get it in
<pitti> I think I switched between gdm and lightdm quite a bit, but /e/X/d-d-m seems alright for mne
<pitti> this doesn't look very straightforward to me, or is there a known case where "lightdm" gets written there?
<seb128> pitti, gnome-menus> ack from me
<pitti> seb128: thanks, accepting
<seb128> pitti, no fix that I know about, I'm just concerned it might be a real issue, dobey hit it this week and his box was hanging on an empty screen (from an user perspective)
<pitti> seb128: yes, no doubt about the importance
<seb128> ie. bug #856810 is similar
<ubot4> Launchpad bug 856810 in netcfg (Ubuntu) (and 1 other project) "Boot hangs at "Booting system without full network configuration..." (affects: 14) (heat: 76)" [Undecided,Confirmed] https://launchpad.net/bugs/856810
<pitti> seb128: I just think that fixing it in an SRU will be fine, as it doesn't affect a clean install
<seb128> ok
<pitti> that doesn't mean that we are not allowed to fix it for release :)
<pitti> just that it's not a blocker
<seb128> pitti, right, well I mentioned it there just in case r-t wants to "track" it
<mvo> fwiw the update-notifier one is not critical, that is equally fine for -update IMO too
<mvo> the software-center one would be nice because at least the "empty whats new" field will be a bad first run experience
<pitti> mvo: u-n> oh, uh -- wouldn't it be easier to just ignore the auto-open key?
<pitti> that seems quite a large and rather untested change to me at this point (also for SRU)
<pitti> jibel, cjwatson, skaet: FYI, current amd64 live oversizedness (just a tad) is due to the new langpack deltas from yesterday, and will be fixed on Friday when we get fresh ones
<mvo> pitti: fair enough, could you please write that in the bug? I'm not sure what the unity-2 status is actually, but if the whitelist/blacklist is all sorted it may wait for P
<tumbleweed> ScottK: the pyside fix I uploaded is actually a bug in cmake-data (expecting all qt4 modules to live under QT_LIBRARY_DIR). I'm suprised it hasn't affected other Qt4 + cmake programs (or maybe it has, and we haven't noticed)
<tumbleweed> or if that's a reasonable expectation, then it's a bug in phonon not being multiarched
<stgraber> good morning
<stgraber> can I get a respin of Edubuntu to pick up the new ubiquity please?
<Laney> argh, our new overlord!
<stgraber> ;)
<nigelb> Congrats stgraber :)
<stgraber> thanks nigelb
<ScottK> tumbleweed: I have a vague recollection about this and I think the phonon developers said pyside was making unreasonable assumptions.
<ScottK> I thought it was fixed though.
<tumbleweed> ScottK: the fix was broken (sorry barry), see the bug the upload closes
<tumbleweed> and it's not pyside making that assumption, but cmake-data
<ScottK> I see.
<stgraber> cjwatson, infinity, pitti, skaet: Can one of you trigger a respin of Edubuntu?
<pitti> sure
<stgraber> thanks
<pitti> stgraber: running
<pitti> cjwatson, infinity: I'm uploading apport for disabling for final release; should be accepted together with kerneloops on Friday, I just wanted to get the upload out of the way (to be able to stash P fixes into bzr)
<skaet> pitti,  ack.
<ScottK> Sigh.  Alternates grew 8MB overnight.
<cjwatson> pitti: I just NEWed some language packs and realised they seem inconsistent again
<cjwatson> pitti: language-pack-kde-ky but no language-pack-kde-ky-base; language-pack-kde-my but no language-pack-kde-my-base; language-pack-mhr-base but no language-pack-mhr; language-pack-gnome-mhr-base but no language-pack-gnome-mhr
<GrueMaster> skaet: Are we not doing an RC release this week?  Or is this just another daily test week?
<skaet> GrueMaster,  we'll be spinning up a full set of ISO images tomorrow and populating the ISO tracker for everyone to do the testing,  but won't be posting on the web site.
<GrueMaster> Ah, ok.
<ogra_> skaet, do you have an ETA ? we still have that banshee issue and i would like to have as much time as possible before we decide if we switch to RB or not (seed change + meta upload)
 * GrueMaster goes back to the arm pit.
<skaet> ogra_, as soon as the langpacks land was the plan with pitti.
<ogra_> skaet, oh, and we need to talk about an EOL message for lucid armel :)
<ogra_> (happy to do that after release though)
<GrueMaster> Yes.  Kill it please.  I'll even bring a Titanium Spork to UDS if necessary.
<kenvandine> doko, i just uploaded the ido ftbfs on armel fix
<kenvandine> i didn't get to do an armel build on it, but it works on amd64 and should build on armel too
<skaet> ogra_, after release +1.
<doko> kenvandine, thanks, however it still ftbfs, see https://launchpadlibrarian.net/82046752/buildlog_ubuntu-oneiric-armel.ido_0.3.0-0ubuntu3_FAILEDTOBUILD.txt.gz
<doko> please test build on kakadu
<kenvandine> doko, ok... i'll look
<kenvandine> ok, never tried that before :)
<infinity> kenvandine: Or test build on scheat, it's much faster. :P
<kenvandine> infinity, wow kakadu is slow... i figured ido is quick to build so who cares if it is an extra couple minutes
<kenvandine> doko, uploaded again, fixed the last failure
<doko> kenvandine, looks fine, but I can't approve. infinity: ^^^
<kenvandine> great
<ScottK> So I guess we can update devscripts, ubuntu-dev-tools, etc now: http://www.markshuttleworth.com/archives/784
<slangasek> at last :)
<tumbleweed> ScottK: thankfully we've been trying to use distro-info for all of that. /me pokes bdrung
<ScottK> I think debootstrap doesn't use that.
<tumbleweed> yeah, devscripts needs a patch too
<micahg> ooh, maybe deboostrap should be patched to use distro-info at build time :)
<ScottK> Normally we get debootstrap unmodified from Debian.
<ScottK> (they have Ubuntu releases in theirs)
<ScottK> I don't think we should mess with that.
<micahg> debian could probably benefit as well as they have distro-info
<micahg> or at least be willing to take a patch
<ScottK> I guess you know what to do with that idea ....
<infinity> slangasek: Care to give that a quick once-over for me? --^
<slangasek> lookin
<slangasek> infinity: --swap-file-size argument is relative to the root?
<slangasek> (tested?)
<infinity> slangasek: Yeahp.  Ends up using chroot/$LB_SWAP_FILE_PATH
 * slangasek nods
<slangasek> accepted
<infinity> And I assume you mean s/size/path/ ;)
<slangasek> yes :)
<infinity> slangasek: I don't want to touch xdiagnose with a 20-foot pole, I suspect it's more up your alley.
<slangasek> oh, is it?
<infinity> Well, it does sketchy upstart things, which you've become intimate with lately. :P
<infinity> (And that's totally my excuse for not reviewing the rest of the diff)
 * slangasek chuckles
<skaet> block post has been made,  we have a name for P now.  :)
<skaet> http://www.markshuttleworth.com/archives/784
<skaet> s/block/blog/
<charlie-tca> pronouncable and spellable, too!
<slangasek> infinity: actually, I may have written that patch to the upstart job ;) you sure you don't want to review it after all? :)
<slangasek> yes, p-a-n-g-o-l-i-n, pronounged "panguin"
<charlie-tca> huh?
<skaet> http://www.merriam-webster.com/cgi-bin/audio.pl?pangol02.wav=pangolin
<skaet> slangasek, ^ I think the "l" is pronounced. ;)
<slangasek> skaet: depends on the accent!  I'm pretty sure I heard "penguin" ;)
<skaet> slangasek,  lol,  :)
 * charlie-tca was thinking this was finally an easy name :)
<tumbleweed> yeah, the l should be pronounced
<charlie-tca> obviously, locale specific ;)
 * ScottK will look at python3-defaults.
<ScottK> Daviey: ^^^ updating memcached looks like pure fixing goodness.  There's a lot of noise in the diff, but once you get to the meat of the changes it's all good.  http://code.google.com/p/memcached/wiki/ReleaseNotes146 and http://code.google.com/p/memcached/wiki/ReleaseNotes147 are the upstream changelogs.
<cjwatson> I've uploaded debootstrap to unstable with the 'precise' symlink; I guess I should do a fast-track sync of that rather than waiting for LP to pick it up?
<Daviey> ScottK: looking, sorry for the delay - on really bad ()[Dbut free[C wifi
<ScottK> Daviey: Thanks.
<infinity> Daviey: Seems "sane" to me, for some value of "sane" that includes "upstream has some very, very, very bad programmers".
<infinity> Daviey: But their ugly code appears to do what it says it should. :P
<infinity> Daviey: But since you seem to still be looking at it and not noticing I've reviewed it, I'll wait until you're done. :)
 * cjwatson fast-syncs debootstrap, since nobody's complained
<cjwatson> I'll miss being able to do this ;-)
<infinity> cjwatson: "this" being fake syncing, or syncing from cocoplum?
<Daviey> infi	gah! :)
<tumbleweed> if we could get lp to harvest packages from incoming.debian.org, native syncing could be fast too...
<ScottK> We can't even get LP to keep up with what's in the actual Debian archive.
<tumbleweed> yeah, that could be faster
<cjwatson> infinity: scp blahblah cocoplum:, then copy to ~lp_archive/syncs/ on cocoplum and dpkg-scansources . /dev/null >Debian_incoming_main_Sources; sync-source.py -b cjwatson -S incoming debootstrap
<infinity> cjwatson: I'm sure that we can get incoming scanning as a feature at some point.  Maybe.
<infinity> cjwatson: (It might be another one to put on the list of "stuff that should be done before you take away our shells")
<cjwatson> I could've fakesynced as an alternative, so not critical.
<infinity> cjwatson: Though, doing it properly means having the full Debian keyring handy, since incoming offers no signed Sources.gz.
<cjwatson> Indeed, and keeping that in sync, and and and
<kirkland> umm, i just just accidently uploaded byobu to oneiric
<kirkland> i meant to just upload to PPA, but I neglected to give the do-not-release-to-oneiric flag in my release script
<kirkland> it's relatively harmless (affects the experiment, non-main byobu-tmux bits) -- but it should probably be rejected at this point in the release
<kirkland> sorry
<kirkland> lots and lots of apologies
<NCommander> cjwatson: infinity: I've gotten a request to add impitool for armel. Any chance we can slip an upload in for it? (it only needs a change to the Architecture line to build, and possibly a P-a-s change)
<infinity> NCommander: Do we know why it was excluded?
<infinity> kirkland: Rejected, and removed byobu from oneiric entirely for good measure.
<kirkland> infinity: :-D
<NCommander> infinity: not sure. it requires a kernel module which I'm unsure is available for armel, but IMPI hardware is in the pipeline
<slangasek> kirkland: fwiw, AAs do have access to the unapproved queue for rejects
<slangasek> (just not permission to accept stuff from it unless they're also wearing a release team hat :)
<infinity> ipmitool: i386 amd64 ia64 powerpc                                     # i386 specific
 * infinity likes how that comment fails to match the arch line.
<NCommander> infinity: yeah, I saw that :-/, no comment.
<infinity> NCommander: So, there's a claim that we'll be seeing IPMI BMCs on ARM, and this might actually work?
<infinity> NCommander: If so, sure.  Upload, but not until I've fixed P-a-s.
<NCommander> infinity: yeah.
<kirkland> slangasek: thanks -- i realized that after i asked
<infinity> (And make sure you've done a local test build)
<NCommander> infinity: already did the test build. Poke me when P-a-s is fixed (might as well add both armel and armhf so we don't need to smack this again in P-cycle)
<infinity> I already added both, yes. :P
<infinity> Though we have a massive armhf patch landing later anyway.
<NCommander> infinity: thatwas fast :-)
<infinity> Not sure which machine creates build records these days.
<infinity> If it's cocoplum, you're good to go.  If not, wait 15 minutes for cron to update P-a-s elsewhere. :P
<infinity> (You can upload now, I just won't accept for "a while".
<infinity> )
<NCommander> infinity: upload away
<NCommander> infinity: thanks for your help
<cjwatson> infinity: I think it's cesium
<ScottK> Daviey: Conclusions on memcached?
<infinity> cjwatson: cesium dispatches builds, it's unclear to me what creates them.  I *think* it's done by cocoplum on accept.
<Daviey> ScottK: I dropped off it as infinity had it in hand.
<infinity> Daviey: ahh, all I saw was garble from you. :)
<infinity> But yes, I've reviewed it.
<infinity> I'll poke it through.
<Daviey> Sorry, laggy connection is hurting.
<infinity> Daviey: S'all good.
<utlemming> skaet: are you around
 * infinity looks at the 9MB ubuntu-docs diff and sighs.
<skaet> utlemming, yup.  what's up?
<utlemming> skaet: for our RC tomorrow, do we want to spin up some RC Cloud Images or just rely on the regular daily?
<cjwatson> for the other images I was just going to let the daily builds take care of it
 * cjwatson doesn't see a need for unnecessary work :-)
<utlemming> sounds good to me
<skaet> utlemming,   what cjwatson says.
<skaet> :)
<cjwatson> I'd appreciate review of localechooser; part of my last work item for the Qin images
<cjwatson> (still testing the other part)
<bdrung> tumbleweed, ScottK: distro-info updated (will be synced tomorrow)
<tumbleweed> bdrung: I updated devscripts git, but the ubuntu upload needs a core-dev. I assume some of these also need SRUs
<bdrung> yes
<bdrung> tumbleweed: i could sponsor you ;)
<bdrung> tumbleweed: can we get a list of packages that needs a modification?
<tumbleweed> I suppose I could whip up a patch. We mentioned debootstrap, devscripts, distro-info, and older ubuntu-dev-tools, can't think of anything else right now
<bdrung> tumbleweed: i hope that i will have time to modify devscripts to use distro-info
<cjwatson> I've done debootstrap (for precise, not for distro-info)
<bdrung> cjwatson: "ubuntu-distro-info -a | grep -v gutsy" should do the trick for you
<cjwatson> not now
<cjwatson> there's a list of other ones in https://wiki.ubuntu.com/NewReleaseCycleProcess
<cjwatson> anyway, debootstrap can't depend on distro-info
<cjwatson> it'll have to continue being bumped by hand
<tumbleweed> bdrung: yeah, I left that for you. devscripts: http://paste.ubuntu.com/703067/
<slangasek> cjwatson: maybe it could use it at build time, though?
<cjwatson> I suppose that would be possible
<bdrung> tumbleweed: dch is the last item on the list to make that work on debian and ubuntu better
 * slangasek blames LVM for bug #818177 \o/
<ubot4> Launchpad bug 818177 in udev (Ubuntu Oneiric) (and 3 other projects) "boot failures caused by udev race (affects: 7) (heat: 54)" [High,Confirmed] https://launchpad.net/bugs/818177
<cjwatson> ooh, progress
<slangasek> and that is an Ubuntu-specific udev rule in lvm2
<cjwatson> the watershed one?
<slangasek> /lib/udev/rules.d/85-lvm2.rules in toto is Ubuntu-specific, yes
<cjwatson> that dates from UDS-Seville; I recall that there was a very detailed blueprint, if that helps
<slangasek> I'm not saying it's wrong that we have it... just that we're on our own for fixing it ;)
<cjwatson> yeah
<cjwatson> https://blueprints.launchpad.net/ubuntu/+spec/udev-lvm
<infinity> Mountain View is in Seville now? :)
#ubuntu-release 2011-10-06
<cjwatson> huh, you're right, I have a very very distinct memory of discussions about that in Seville though
<cjwatson> maybe it was something related but subtly different
<cjwatson> oh, perhaps udev-lvm-mdadm-evms-gutsy
<cjwatson> heh, yes, https://blueprints.launchpad.net/ubuntu/+spec/udev-lvm-mdadm-evms-gutsy is definitely worth looking at in conjunction
<slangasek> # In Ubuntu uploads should go to precise
<slangasek> yes, they should all go to precise
 * slangasek stabs the language center of his brain harder
<infinity> slangasek: Yeah, I don't think I'll ever get used to it.
<infinity> Maybe we can get a perky == precise hack into launchpad, and upload to the correct suite. :)
<cjwatson> it took me three months to stop typing interpid.
<infinity> I remember a lot of rejected "gusty" uploads.
<cjwatson> oh, yeah, that too
<slangasek> heh
<slangasek> dch -r, dudes :P
<cjwatson> I wasn't always in the habit of editing /usr/bin/dch locally before I got round to upgrading to the next release
<cjwatson> (I am now)
<slangasek> ah :)
<cjwatson> skaet: is this a true candidate tomorrow - should we ensuring that base-files and the CD volume labels are final?
<cjwatson> or just a smoke test?
<cjwatson> *should we be
<cjwatson> ReleaseProcess doesn't indicate that we should be doing so until Monday
<cjwatson> so I guess I'll just go to bed, somebody else can deal with that if it's needed :)
<cjwatson> debian-installer and ubiquity uploaded, hopefully at least conceivably final
<stgraber> cjwatson: good night!
<ScottK> infinity and Daviey: Thanks for looking into memcached.
 * infinity puzzles over both the weird version on that postfix upload and the really quick accept...
<infinity> Who accepted that?
 * infinity wonders if lamont accepted his own upload...
<lamont> infinity: I did not
<lamont> OTOH, I haven't exactly finished updating the debian chroot to build the upload for debian
<infinity> lamont: It would seem that no one else is speaking up either. :P
<micahg> lamont isn't an AA AFAIK
<lamont> and that's a perfectly valid "yeah, just import over me" version number
<lamont> micahg: I have a duck
<infinity> micahg: lamont is a duckie, he has full LP access.
<lamont> OTOH, AA stuff scares me enough to just avoid it entirely
<micahg> lamont: I know, but I don't see you as the type to abuse it :)
<infinity> lamont: While you're in a package maintaining mood, RT#48330? :)
<stgraber> skaet: just so you know, I just found what looks like a python-gevent bug breaking weblive for Oneiric systems (possibly limited to these with IPv6 connectivity). Only Edubuntu ships with python-x2go/python-gevent by default but we'll likely want that working in the release (as it's advertised in the install slideshow).
<infinity> micahg: Yes, lamont's never abused access to anything in his life. ;)
<lamont> infinity: give it some relationship to 48181?  I'd be inclined to shrug if you went in and said 48181 depended on 48330
<lamont> that argument holds at least some water
<infinity> 48181?
 * infinity looks.
<lamont> I have one other zomfg ticket ahead of 48181, and I'm planning to have a weekend this week
<infinity> I'm not sure I can argue that. :P
<infinity> But it's a 2-line patch.
<lamont> infinity: oh.  orthogonal activities?
<infinity> lamont: Yeah.  48181 is an OEM one-off project, not proper armhf in Soyuz.
<lamont> ok
<infinity> lamont: 48330 is Soyuz.
<infinity> (And needs doing between now and P, but I'd prefer to have all our ducks i na row well ahead of P, so I'm not panicking on opening day)
<lamont> infinity: I've got pre-O craziness that wins over it.
<ScottK> infinity: I accepted it.
<lamont> OTOH, if you happened to have a source package that was based on -cat, that becomes much more of a slamdunk
<infinity> ScottK: Mmkay.  Just seemed a bit quick.
<infinity> lamont: I can do that.
<lamont> infinity: it got built and tested in a ppa
<lamont> postfix that is
<ScottK> It was because I'd reviewed it before it was uploaded.
<infinity> lamont: I realised the current -cat one was Colin's, not yours. :P
<lamont> with ScottK poking me about it starting a couple days ago
 * infinity wonders if he can still upload to archive.admin ...
<lamont> pretty sure we removed that key
<infinity> Oh, no, it was an scp queue, wasn't it?
<lamont> yeah
<infinity> Foiled.
<infinity> lamont: I'll toss a fixed package on chinstrap.
<lamont> cool.  ref it in the ticket, and etc, etc
<lamont> fortunately, dpkg on the buildds is run inside the chroot, so we don't need a hardy version
<lamont> and with that, way past my bedtime
<infinity> lamont: Yeah, I know, I fixed that misfeature. ;)
<infinity> lamont: Just need this for soyuz.
<lamont> your homedir on osageorange is another option for where to drop it
<infinity> What host is that?
<infinity> New amd64 porter, I'm guessing?
<lamont> porter box, should have a lucid-cat chroot on it
<lamont> it's the new ronne
<infinity> Yeah, I don't keep up.  Never use porter boxes.
<infinity> I always have to look them up when I tell others to. :P
<lamont> heh
<micahg> there are aliases for them now
<infinity> Oh?
<micahg> infinity: porter-<arch>
 * infinity just tried amd64.canonical.com amd64-porter.canonical.com and amd64.porter and gives up hope that it's intuitive. :)
<lamont> MachineOverview
<infinity> Oh, sure.
<infinity> lamont: Looks like porter-armhf might need some DNS love (scheat)
<infinity> Sure, it has no armhf chroots yet, but whatever. :P
<lamont> bah
<lamont> throw that at RT, it seems trivial to me
<lamont> as in it'll just go through the vg queue and be done in a couple days
 * infinity nods.
<lamont> logging in would be work
<lamont> and my day ended quite a while ago
<infinity> So did mine. :P
<lamont> heh
<infinity> lamont: Uploaded to osageorange, changes is signed (on the off chance that the archive accepts my key?), and threre's a debdiff sitting there too.
<stgraber> skaet: actually just spent a bit of time debugging that python-gevent thing now. It's a weird bug but actually very far from being critical (socket.getaddrinfo hanging for > 30s when one of your DNS servers doesn't answer)
<ScottK> Sounds easy enough to fix though.
<stgraber> pretty weird bug though. I have 3 DNS servers, two of them work fine, including the first one. getaddrinfo always returns within a second, except from python-x2go which uses python-gevent
<infinity> lamont: And ticket updated to reflect that.
<stgraber> trying to reproduce with just socket or gevent.socket won't get me the bug. Doing it from x2go, gets me the bug every time I try it
<ScottK> What does it use for DNS?
<stgraber> ScottK: http://paste.ubuntu.com/703175/
<ScottK> Congratulations, BTW.
<stgraber> weblive-appserv02.nx.stgraber.org, 6622, socket.AF_UNSPEC, socket.SOCK_STREAM are the parameters to socket.getaddrinfo() (added some debug in paramiko)
<stgraber> thanks :)
<pitti> Good morning
<pitti> cjwatson: langpacks> I'll just remove the broken ones for now; need to investigate why the heck they are built without a corresponding -base
<infinity> pitti: Mornin'.
<pitti> skaet: langpacks will be uploaded tomorrow; they weren't meant to be on the RC (but current images have Tuesday's langpacks, so are reasonably current for testing)
<infinity> pitti: I'm waiting on a final apt upload from mvo for RCish images anyway.
<infinity> pitti: Well, for ARM, that is.  You can spin others before, if you like. ;)
<pitti> seems we still have the daily cron jobs even
<pitti> https://wiki.ubuntu.com/OneiricOcelot/ReleaseTaskSignup doesn't have someone responsible for RC2, but as we don't release it, I guess the only thing that we need doing is spinning images and posting them to the tracker for QA?
<infinity> Yeah, we're not releasing.  So, whatever.
<infinity> Also heard rumours that we won't start calling things RC until after the weekend.
<ScottK> stgraber: For a test you might switch the failing call in dns.py to use python-dns or python-dnspython.  That would at least give you an idea if if the issue was in the code below that call.
<pitti> oh, so we could still accept fixes today?
<infinity> Yeah.
<ScottK> I would.
<ScottK> In fact I did a few minutes ago.
<pitti> e. g. I have https://code.launchpad.net/~jbicha/ubuntu/oneiric/jockey/update-help-link/+merge/77782, which is a trivial and obvious fix for broken help button
<infinity> Well, we can accept fixes until release day, but we pretty obviously don't want to unless they're critical. :P
<infinity> pitti: Do it.
<pitti> (due to the ubuntu-docs reorg)
<pitti> well, not exactly critical, but very low-risk (arch: all package, and all that)
<ScottK> Sounds like the kind of final polish we should have.
<infinity> pitti: I don't think the team as a whole is committed to being in RC mode until the sprint, which starts Monday morning.
<pitti> ScottK: yeah, I agree
<pitti> but RC on Monday sounds fine to me; we'd still want some urgent fixes in, if we can get them
<infinity> pitti: So, I think it's sane to get base-files and such in over the weekend, turn off dailies Monday morning, and go from there.
<pitti> sounds fine
<pitti> so a REAL release candidate for the first time? :-)
 * infinity crosses his fingers.
<pitti> we should still get the current dailies some testing, though, to spot some OMG installer problems
<infinity> I've kind of come to the conclusion that I just have to live with any ARM bugs we find from here on.
<infinity> THough I'm really, really tempted to hack up oem-config to stop/start (ana)cron before/after the install.
<infinity> The regression potential for messing that up isn't worth it, though.
<ScottK> pitti: If you have a free moment today, I think KDE 4.6.5 is sufficiently aged to move to natty-updates.
<pitti> ScottK: yep, will do
<ScottK> Thanks.
<pitti> I'll have a look today why evolution-exchange is uninstallable
<pitti> slangasek, infinity, ogra_: do you know about all the linaro kernels on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt ?
<pitti> they are also shown as being uninstallable on http://people.canonical.com/~ubuntu-archive/testing/oneiric_probs.html (some of them)
<pitti> should they be in main and are missing some seeding/metapackages, or demoted?
<infinity> pitti: vexpress and omap4 are used by d-i.. That may need some seeding, if things aren't smart enough to sort that out.
<infinity> pitti: linaro-mx51 can go to universe, as can st1-5, unless we have a support commitment there I'm not aware of (we certainly don't use them for images)
<infinity> pitti: linaro-omap as well.
<infinity> pitti: Might need Colin's input on vexpress.  I can chase down the rest.
<pitti> hm, indicator-datetime went to oneiric-proposed
<pitti> could just as well have gone to final, I guess?
<infinity> Oh, I didn't even notice the pocket on that one...
<pitti> http://launchpadlibrarian.net/82049869/indicator-datetime_0.3.0-0ubuntu1_0.3.0-0ubuntu2.diff.gz looks safe enough to me, anyway, and it affects the live system
<pitti> infinity: I can remove the proposed package and reupload to oneiric?
<infinity> pitti: yeah, please do, I didn't notice the suite when I accepted it.
<pitti> roger
<micahg> pitti: you'd have to bump the version
<pitti> micahg: yeah, I won't retrofit the changelog
<infinity> pitti: don't accept that u-boot to proposed either, I'm going to grill jcrigby about why he didn't want that in release.
<pitti> infinity: *nod*
<infinity> pitti: Actually, better idea, maybe I'll reject it from -proposed, so I can talk to him about it without someone else accepting it. :P
<infinity> pitti: Oh, I suppose u-boot-linaro-mx53loco can go to universe, we're building mx53 from universe anyway.
<infinity> (Though it comes from main sources, so I could just as easily seed it)
<infinity> I've always found the source-in-main-binary-in-universe thing kinda messed up. :/
 * infinity fixes some kernel seeds.
<pitti> ok, let's see what's left after your seed changes
<infinity> pitti: Updated, if you want to manually trigger a mismatches check.
<pitti> infinity: I'll just wait for cron, before I break anything
<infinity> pitti: Wuss. ;)
<pitti> infinity: so you seeded mx53 only? mx51, st1-5, and omap should still go to universe?
<infinity> pitti: mx53 is in universe, and should stay there (the u-boot can go).
<infinity> pitti: I fixed up seeds for omap, vexpress, and omap4 for main, and mx51 and st1-5 can go.
<pitti> ah, good
<pitti> still wondering why their sources are in main
<infinity> Who knows.
<stgraber> ScottK: http://paste.ubuntu.com/703195/
<pitti> demoting, of course I just missed the publisher
<infinity> I'm wondering why linaro-omap is in main when the images use -omap, but I need to talk to Colin about that, since he builds d-i for both.
<stgraber> ScottK: at least I'm pretty sure it's a gevent weirdness now :)
<ScottK> Yeah.
<infinity> pitti: You can remove libreoffice-gcj too, it's NBS.
<pitti> weird, why it isn't on http://people.canonical.com/~ubuntu-archive/nbs.html ..
<infinity> Probably because it's still in the .dsc and NBS isn't smart.
<infinity> It's conditionally built.
<pitti> aah
<infinity> And not on any of our architectures.
<pitti> presumably for backports
<infinity> No, for arches that use gcj instead of openjdk.
<infinity> We just don't ship any of those. :P
<pitti> cheers, doing
 * infinity finds http://people.canonical.com/~ubuntu-archive/testing/oneiric_outdate.txt helpful for stuff like that.
<micahg> Ubuntu freebsd coming any time soon? :D
<infinity> When one package from a source is out-of-date, you know something's up. ;)
<nigelb> micahg: Tomorrow's headlines - "Ubuntu developer membership board member wonders when Ubuntu freebsd is coming out"
<micahg> nigelb: context FTW :)
<infinity> pitti: ibmasm-utils and msr-tools can be removed on armel and powerpc (should have been done in natty, no one noticed)
<nigelb> micahg: Heh. :)
<infinity> pitti: All those pings combined, and two buildds catching up, and armel will be completely up-to-date again.  Yay.
<pitti> *flush*
<infinity> ScottK: Aww, crap.  Weren't we meant to do something about that kdesdk/ppc build failure?
<infinity> ScottK: I reproduced it but didn't have the time to debug. :/
<ScottK> Yes.  You were going to fix it ...
<infinity> I was going to fix it?
<infinity> Really?
<ScottK> Yes.
<infinity> Lies and subterfuge.
<ScottK> I'm sure you volunteered.
<micahg> infinity: I'm in the same boat as you :)
<ScottK> I know it's way too complicated for me.
<infinity> Ugh.
<infinity> Can it please not be CMake?
<micahg> infinity: a generated file doesn't seem to work on powerpc
<infinity> micahg: And by 'work' you mean 'exist'.
<micahg> right
<infinity> And yeah, I got that far before I got busy.
 * infinity updates his oneiric chroot to have another poke with a sharper stick.
<ScottK> The python-defaults upload that is about to appear only has minor changes from what we have now, but it lines us up with what's supposed to push the python2.7 transition into Debian Testing today, so I think it'd be good so have that for release.
<ScottK> That one.
<infinity> I'll look at it when it gets diffy.
<ScottK> Thanks.
<ScottK> Kubuntu alternates all fit again.
<infinity> pitti can fix that.
<ScottK> Somehow they grew 10MB yesterday to I had to strip some lang packs off.
<pitti> ScottK: most likely https://launchpad.net/ubuntu/+source/kubuntu-docs/11.10ubuntu2 ?
<ScottK> Yes.  That would do it.
<ScottK> But notice what pocket that's in.
<ScottK> It wasn't supposed to be accepted yet.
<micahg> xubuntu alternates are 10MB larger as well
<infinity> Did we get a kernel image suddenly bloating or something?
<ScottK> And kubuntu-doc is on both live and alternate, so it wouldn't have affected both.
<infinity> ScottK: It was only your alternates that grew?
<ScottK> Yes.
<pitti> ScottK: eww, missed that; straight to -updates?
<infinity> So, something d-i-ish, or something in your ship seed.
<infinity> And something in common with xubuntu.
<infinity> This is a fun game.
<ScottK> Yep.
<pitti> ScottK: we also got new delta langpacks on Tuesday, which will shrink again tomorrow when we do a -base refresh
<micahg> usually the langpacks do this when stuff moves between base and non-base
<ScottK> Fortunately the alternates have language packs to remove.
<ScottK> Maybe that was it.
<pitti> ScottK: so if you add up the size of all language-pack-XX on the images, that's what will go away on Saturday's images
<ScottK> Easy enough to put them back if we get more room.
<pitti> ScottK: so, about the kubuntu-docs blunder, sorry about that; should we reupload the previous version, and the current one to -proposed?
<ScottK> The biggest reason to wait was fear that the added translations would make it too big.
<ScottK> Since we aren't over on the live CD, I think we can leave it.
<ScottK> I was suprised Riddell uploaded it so soon if it was for updates.
<infinity> ScottK: Your CDs shouldn't be building against updates anyway.
<infinity> ScottK: Check your manifests, that package shouldn't be there.
<ScottK> It's there.
<infinity> Really?
<ScottK> Yep.
<infinity> That's a bug in our code, then. :P
<infinity> Well maybe a misfeature.
<infinity> Since we build against updates for point releases.
<ScottK> I don't think so.  I think we normally build against updates, it's just usually empty.
<infinity> And I guess maybe we're expecting (incorrectly) that updates is empty on release. ;)
<ScottK> We used it last cycle to fix a dvd seed problem by uploading kubuntu-meta to -updates and then just respinning the dvd.
<ScottK> That way the CDs weren't out of date at release ...
<ScottK> Nice trick, eh?
<ScottK> I think pitti thought of it.
<pitti> I still remember that one
<pitti> I'm not surprised that -updates lands on images, it's just strange to have it
<pitti> in all but that one case we have used zero-day SRUs for fixing major upgrade bugs
<pitti> which don't affect images
<cjwatson> Yeah, we've used that trick a couple of times
<pitti> hey cjwatson  -- early for you :)
<infinity> Up to and including making sure openssl-blacklist DIDN'T land on CDs because it was too effin' huge.
<infinity> That was entertaining.
<infinity> cjwatson: Want to check the lightdm in the queue, since it relates to your pet bug?
<cjwatson> pitti: Thursdays are odd for me, toddler sign class
<cjwatson> (and believe me I'm not happy to be awake)
<infinity> Beer.
<infinity> Some may argue it's too early to drink, but in your world, it's probably more late than early.
<cjwatson> lightdm> still doesn't look like an entirely proper fix to me (overrides PAM), but it looks OK
<cjwatson> and somebody else seems to have beaten me to it
<cjwatson> I hadn't tested the previous one yet ;-)
<ScottK> I think it's officially late here.  Good night.
<infinity> Night.
<slangasek> pitti: I know nothing about current linaro kernel packages, sorry
<infinity> slangasek: I sorted it.
<infinity> Ish.
<infinity> Someone verify that I can spell "oneiric" correctly and accept jasper?
<pitti> one-eye-rick looks fine; accepted
<infinity> That sounds vaguely dirty.
<infinity> Right, I remember the kdesdk failure.  structviewpreferences.h doesn't exist, and ISN'T REFERENCED FROM THE BUILD SYSTEM AT ALL.
<infinity> (I'm not bitter)
<infinity> Friggin CMake.
<micahg> infinity: it's supposed to be generated by a .kcfg file IIRC
<infinity> Yeah, I have no clue how any of that works. :P
<micahg> me neither :P
<doko> do we already accept uploads for -proposed?
<infinity> pitti: Oh, the other issue with those mismatches is linux-meta-linaro being crufty.  I need to talk to jcrigby about that, since not all the linaro sources are in sync. :/
<infinity> cjwatson: And on the topic of ARM kernels, is there a reason for the linaro-omap d-i build alongside the -omap one?
<infinity> cjwatson: (That you know of?)
<cjwatson> infinity: I just do what I'm told.  But both of them are in d-i right now, so let's keep them both for oneiric ...
<infinity> Yeah, I wasn't planning to change it, was just curious if you had a rationale.
<cjwatson> doko: -proposed can always be uploaded to from the moment a series opens
<cjwatson> doko: whether anyone will process it ... :-)
<cjwatson>   * Add linaro-omap netboot target to armel images, copied from versatile;
<cjwatson>     this is useful for all OMAP2+ boards supported in this kernel.
<cjwatson> was for linaro-omap - that was lool
<cjwatson> I don't really want to know, I just let y'all shuffle kernels around
<infinity> cjwatson: Heh.
<jbicha> will there be an actual milestone RC like the Betas or is RC just test builds for final?
<infinity> jbicha: The latter.
<jbicha> infinity: thanks, that's how I read the schedule but just wanted to verify
<cjwatson> slangasek: do we want to ditch stderr from 'modprobe -q vesafb' in your recent initramfs-tools change?  I've noticed that my live CD boots in kvm have started showing "FATAL: Error inserting vesafb (/lib/modules/3.0.0-12-generic/initrd/vesafb.ko): No such device" on the console, which seems untidy and may alarm people
<slangasek> cjwatson: mmm yes - sorry for not catching that
<lool> infinity: we can chat about OMAP flavors if you like
<lool> infinity: There was also a linaro-vexpress build which got disabled due to some missing kernel configs a while ago (that actually just got fixed); both of the linaro-* builds are suitable for running with qemu-linaro or on real hardware
<lool> the linaro-omap one targets OMAP3 and OMAP4
<lool> I think we could do without the OMAP build entirely, but that's not really Linaro's decision to make
<infinity> lool: We'll chat about flavours after release. :)
<infinity> lool: Not inclined to do anything about it right now, we'll go with what we have.
<pitti> so seems some linaro kernels are still missing something: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<infinity> pitti: meta issues.  Scroll up and check nick hilights.
<infinity> pitti: I'll sort it with jcrigby tomorrow.
<pitti> ok, thanks
<pitti> libgdata is FTBFS (probably link ordering), looking
<infinity> slangasek: \o/
<pitti> ^ trivial FTBFS fix, review appeciated
<jbicha> pitti: I noticed the FTBFS because I was going to make libgdata-dev depend on its gir
<infinity> jbicha: Would you still like to make that change?
<infinity> jbicha: You can grab pitti's source from the queue and then I can reject it. ;)
<pitti> I can reject the current upload
<pitti> infinity: all in bzr
<pitti> jbicha: ^
<infinity> pitti: Crazy talk.  You kids and your fancy bizedares.
<pitti> ^ simple installability fix, review appreciated
<pitti> jbicha: libgdata upload rejected, and uncommitted the release tag in bzr to pretend it never happened :)
 * infinity decides to try to get some sleep tonight.
<infinity> Toodles, everyone.
<pitti> sleep well!
<pitti> jbicha: doing the dependency change now
<pitti> ... and reuploaded
<jbicha> pitti: thank you
 * ogra_ wonders why omap4 images suddenly try to install oem-config-kde
<ogra_> (and fail badly)
<ogra_> was there any seed change ? we never had that package installed
<ogra_> hrm, i should probably learn to read before talking, ignore me
<ogra_> pitti, can we hold back on arm images until after the arm meeting today, i have no info about the banshee breakage from NCommander yet and dont know iff we need a seed change (to rhythmbox) or not
<ogra_> (which indeed in turn will require a meta upload)
<infinity> ogra_: We're not spinning RC until the end of the weekend.
<infinity> ogra_: It's just dailies as usual for now.
<ogra_> oh ?
<ogra_> why is that ?
<infinity> Just seemed to be the general concensus around here.
<infinity> And the release sprint starts Monday morning, so that seems like a sane time to turn off the cronjobs and roll up our sleeves.
<ogra_> k, well, kate told me she wanted images during the day ... that was my last update
<pitti> well, we still get dailies
<infinity> ogra_: omap4 images installing oem-config-kde?  where?
<pitti> jibel: is the auto-tester for dailies running?
<ogra_> infinity, in the kubuntu build that failed
<pitti> i. e. do we get notified if something really breaks?
<infinity> ogra_: Oh, well that sort of makes sense in kubuntu.
<ogra_> infinity, i hadnt finished my first coffee ...
<infinity> ogra_: But yeah, the failure is just the usual ubiquity-out-of-sync issue.
<ogra_> and evo crashes badly if i scroll down to the bottom of the log so i didnt really regard the subject line while trying to scroll as slow as possible to actually see the end of the log
<ogra_> one day i need to switch to TB or file a bug for evo about that :P
<pitti> ugh, http://people.canonical.com/~ubuntu-archive/component-mismatches.txt just exploded
<pitti> did we just get a new nova? (didn't see one), or was there some seed change?
<pitti> Daviey: ^
<jibel> pitti, yes it is running. is your intention to really break something today ?
<pitti> jibel: not just today!
 * pitti promotes cobbler-enlist
<Daviey> pitti: Hmm.. that will be my fault.
 * Daviey fix0rs
<pitti> Daviey: cheers
<Daviey> pitti: When it refreshes, it should just be tgt and it's children, which fell out of main this cycle - but should be there.
<Daviey> bug 594372 is the old MIR, can you promote it when it's clear what needs nbumping?
<ubot4> Launchpad bug 594372 in tgt (Ubuntu Maverick) (and 7 other projects) "MIR: tgt (affects: 1)" [Medium,Fix released] https://launchpad.net/bugs/594372
<pitti> Daviey: can do
<Daviey> thanks.
<Daviey> i thought c-m's used to generate every 15mins or so, seems to be hourly now :(
<pitti> Daviey: has always been hourly, as it needs to wait for publisher
<nigelb> 45
<pitti> nigelb: off by three
<nigelb> pitti: heh, ironically, I was indeed looking for /window 42 :)
<pitti> cjwatson, Daviey: could either of you please review my libgdata and evolution-exchange uploads?
<pitti> Daviey: I just did the necessary promotions/demotions for nova
<pitti> c-m should look better in ~ 1.5 hours
<pitti> ScottK: any idea what to do with kdesdk's kdesvn dependency? should that get a very late MIR, or dependency dropped? (I remember that we had the same problem in ealier releases)
<cjwatson> pitti: accepted libgdata and evolution-exchange
<pitti> cjwatson: cheers
<doko> pitti, ScottK: that should be gone. kdesdk did build now. somebody insisted to have to debug it on powerpc only
<tumbleweed> bdrung: distro-info was picked up by lp, and I requested a sync. (someone please ack it)
<Daviey> pitti: thanks
<ScottK> doko: Thanks.
<Laney> phppgadmin distro-info look ok to me
<pitti> Laney: accepted
<Laney> cheers
<orava> Hi, when 11.10 RC will be available?
<stgraber> good morning
<ev> hiya
<Daviey> 14:36 < stgraber> good morning <-- fail. it's the afternoon.
<hggdh> Daviey: good morning ;-)
<skaet> hiya
<Laney> hey
<kenvandine> hey skaet
<skaet> pitti, have all the langpacks landed now?
<skaet> ogra_, wat;s the background on the glade-3 armel translations sitting in the new queue?
 * skaet scratching her head over them.
 * ogra_ has no clue, first time i hear about it 
 * skaet figures to see if pitti knows where they've come from then....
<cjwatson> the translations are not the things that are new.
<cjwatson> I will review that
<skaet> thanks cjwatson. :)
<ogra_> package name changes ?
<ogra_> 8or is that source-new we are talking about)
<cjwatson> I will deal with it
<ogra_> k
<cjwatson> nor is it armel-specific btw
<Laney> binary new; they added gtk2 variants
<ogra_> aha
<doko> who did accept libx86 and xen? just want to know how it was accepted (web UI or command line tol)
<skaet> Daviey, nova fix in the queue from Robie,  are you reviewing and accepting it for the candidates?
<cjwatson> pitti: your glade-3 3.8.0-0ubuntu2 upload said that glade-gnome is built by the glade source package now, but I don't see that.  Did you have a glade upload that you aborted when didrocks decided to reintroduce glade-gnome to glade-3?
<stgraber> are we planning for a mass rebuild later today? otherwise I'd like to have a respin of Edubuntu to pick up the new ubiquity for testing.
<skaet> stgraber, will go kick it off.
<stgraber> thanks
<skaet> its started now.
<pitti> skaet: no, langpack export is starting tonight, will build them tomorrow morning
<pitti> cjwatson: didrocks needed the gtk2 variant back for quickly
<pitti> cjwatson: it's actually not called "glade-gnome" any more, just glade
<cjwatson> pitti: so the mentioned glade change never happened?
<cjwatson> pitti: didrocks' upload reintroduces a 'glade-gnome' binary package, that's why I'm asking
<cjwatson> I wanted to make sure that wouldn't collide with a change to the glade source package
<skaet> pitti, was wanting to get the candidates created with the langpacks today, so jibel could test them out tomorrow,  any options?
<pitti> skaet: the export takes about 24 hours..; but when we discussed that a week or two ago it was fine?
<didrocks> cjwatson: the paths are different, it's basically the same than libgladeui-common's one, with a different (glade3) path
<skaet> pitti, I appear to have misunderstood.  I thought they'd be ready by today, not starting to export today.
<cjwatson> sorry, I seem to be being unclear, I don't care about any of this stuff :)
<cjwatson> pitti's previous upload implied that glade-gnome was being added as a binary to the glade source package
<cjwatson> I want to make sure that didn't happen so that this glade-3 upload in NEW won't collide
<cjwatson> I can read the rest of the rationale and such for myself
<pitti> glade-gnome is not really meant to exist any more
<pitti> in a GNOME 3 world
<cjwatson> *sigh* is anyone actually going to answer my question? )
<didrocks> cjwatson: there is no overwrite, if that's the question, it's gnome-common for the gtk2 glade flavor and libgladeui-common for the gtk3 glade
<pitti> as all the widgets etc. are in GTK now
<cjwatson> :)
<cjwatson>   * debian/control: Drop glade and glade-gnome, they are built by the "glade"
<pitti> cjwatson: so, glade-gnome is not meant to be built by the glade source
<cjwatson>     source package now.
<cjwatson> did this happen or did it not?
<cjwatson> this should be yes or no
<pitti> "yes" for the  glade binary, "no" for glade-gnome
<pitti> and glade-gnome isn't meant to be built by glade
<cjwatson> OK
<pitti> so everything should be fine
<cjwatson> thanks, that's all I wanted to know
<pitti> but I don't know why didrocks introduced glade-gnome as well
<pitti> didrocks: ^ are these the extra gnomeish widgets on top of glade-gtk2?
<didrocks> pitti: right, it seems that some widgets in glade only show if we get this extra ones
<didrocks> (in glade, like, in glade gtk2)
<pitti> didrocks: yes, those are from the old "extra" gnome libs, all of which are obsolete in 3
<pitti> cjwatson: so, as long as there are no file collisions, it shoudl be fine; want me to check?
<didrocks> (there is not normally, I ensured that using the old glade3/ path instead of glade/)
<cjwatson> pitti: it looks fine, but I'm sure a second pair of eyes wouldn't hurt.  The files are in cocoplum:/tmp/cjwatson/
<doko> pitti, cjwatson: the kdesvn component mismatch isn't a real one. kdesdk depends on kdesdk-kio-plugins (>= 4:4.7.1-0ubuntu2) | kdesvn-kio-plugins. the former is in main
<pitti> cjwatson: install well alongside glade binaries, debs look ok to me, and both the old and the new glade work
<cjwatson> ok, and it can go in universe, can't it?
<pitti> yes, as quickly is universe, too
<cjwatson> ok, accepted then, thanks
<pitti> thanks
<mvo> if someone like cjwatson could review the apt upload, that would be great, it got some good review from mdeslaur and infinity already, but the more eyes the better
<pitti> I'm afraid I'm mostly useless right now, my head is exploding (got a cold); I'll try to take a nap, back on TB meeting
<pitti> please don't hesitate to call my mobile if something bad happens
<skaet> ok pitti.   hope you feel better soon.
<ev> RT 48349 is for a signed wubi
 * skaet thanks whoever just reviewed glib2.0,  which appears to have the fix for bug 804946
<ubot4> Launchpad bug 804946 in glib2.0 (Ubuntu Oneiric) (and 2 other projects) "gnome-settings-daemon crashed with SIGSEGV in g_variant_unref() (affects: 227) (dups: 83) (heat: 1020)" [Critical,Fix released] https://launchpad.net/bugs/804946
<infinity> That was me.
<skaet> :)
 * Laney wonders if 12.10 wouldn't have been a better choice for the LTS given that Debian will be frozen from June
<cjwatson> http://article.gmane.org/gmane.comp.time.tz/4133 erk
<micahg> skaet: we're going to need a firefox upload to fix upgrades from natty to oneiric with the same firefox version, I assume we want this fixed on the live media as well?
<micahg> skaet: problem we're fixing is missing search engines again
<skaet> micahg, ok,  what's the ETA?
 * skaet wondering if we need this in today's images, or if its going to need to go into Monday's final, or an SRU.
<micahg> skaet: well, I can do this one of 2 ways, I can fix the current issue, but it'll come back to bite us again when we upgrade to 8, or I can try to fix it right so we hopefully aren't bitten by it again
<micahg> the first, I can upload a fix in a few minutes, the other will be several hours
<skaet> micahg,  please fix the current issue,  and upload that.   That will give us the backup, and get the builds started.   If you have a better fix,  we can decide tomorrow to get it ready and included for Monday's builds.
<micahg> skaet: ok
 * skaet figures micahg will do a better proper long term fix without her asking for the next few hours... is it ready yet?;)
<skaet> cjwatson, urk indeed.
<micahg> skaet: so, Chris Coulson committed a fix to bzr, it should be a permanent fix
<micahg> I'll upload it
<skaet> micahg, thanks.
<micahg> skaet: do you want me to do a test build first or just upload? (only change was in the postinst)
<skaet> micahg,  test build first please,  just in case.    We have time,  waiting for WUBI upload.
<micahg> skaet: ok, should be about a half hour then
<skaet> micahg, thanks. :0
<skaet> :)
<micahg> skaet: so, apparently, the upgrade issue with Firefox was discussed with pitti yesterday and they decided to SRU, I'm not sure if the issue of people upgrading off of live media was brought up
<skaet> micahg, yeah, so it appears.
<jdstrand> micahg: can you briefly summarize the issue?
<jdstrand> (for me-- sorry that I am not up on backscroll, etc)
<micahg> jdstrand: upgraders from natty w/the same version will lose their search engines Bug #869311
<ubot4> Launchpad bug 869311 in firefox (Ubuntu Oneiric) (and 1 other project) "searchplugins installation damaged after natty->oneiric upgrade (affects: 1) (heat: 6)" [High,In progress] https://launchpad.net/bugs/869311
<jdstrand> so, I go from 0ubuntu0.11.04.1 to 0ubuntu1 and lose my search engine?
<micahg> jdstrand: right
<jdstrand> micahg: 7.0.1+build1+nobinonly-0ubuntu2 will fix this?
<jdstrand> (whether it is SRU or not)
<micahg> jdstrand: yes
<jdstrand> micahg: what is on the iso right now?
<micahg> 7.0.1+build1+nobinonly-0ubuntu1 should be
<jdstrand> micahg: ok, so this should not affect new installs, correct?
<micahg> jdstrand: right, only upgrades (which I thought the live media supports as well)
<jdstrand> micahg: so your concern is natty users using the CD to upgrade
<micahg> but I guess if people are upgrading off live media, they'll either be out of date on natty, or will just run upgrades on oneiric afterwards
<micahg> so I guess it can go to SRU
<micahg> jdstrand: yes
<jdstrand> well, we can't say the former is true, we can say that latter is
<jdstrand> micahg: can this simply be a 0-day SRU?
<micahg> jdstrand: yep
<jdstrand> IMHO, that is the best course of action because they will immediately get the updates most of the time. it seems that people upgrading off of oneiric install media would also be getting network upgrades as well
<micahg> jdstrand: right and if they don't they probably didn't have the previous upgrades either (so won't experience the issue)
<jdstrand> cool
<ev> about to step out for dinner
<ev> still waiting for a signed wubi from IS
<ev> will check back when I get home tonight
<jdstrand> skaet: I think that perhaps this should be a release note in the Technical Overview: "Ubuntu 11.04 users who are upgrading via Ubuntu 11.10 install media may lose access to Firefox search engines until performing a standard upgrade (LP: #869311)."
<jdstrand> (or similar)
<skaet> ev, ok,  WUBI's on the critical path for building the images.
<infinity> Is there a sane way to determine why I can see private bugs?
<infinity> https://bugs.launchpad.net/ubuntu/+source/geoclue <-- I see 20+ private bugs there, and I'm curious if people who actually need to see them can.
<micahg> infinity: go to a bug and click on edit bug mail, it should tell you why you can see it
<skaet> jdstrand, ack.   will add it then.
<micahg> skaet: do you want a release notes task on the bug?
<skaet> micahg, yes please.
<micahg> skaet: and should I just leave the upload for chris next week then?
<ev> skaet: indeed, text me if I need to run back to the office
<ev> skaet: my mobile is in the directory
<Laney> infinity: by being in a team which is subscribed to the bug (usually crash bug triagers)
<Laney> don't know if that is sane
<infinity> Laney: Ahh, so basically, any ubuntu dev can see those.  Check.
<jdstrand> micahg: thanks for looking into this and bringing it up :)
<infinity> Laney: It may or may not be sane, but in this case, I'd like people to actually be trying to fix that bug. :P
<infinity> Laney: 20+ dupes of the same bug sounds less than ideal.
<jdstrand> micahg: is the ubuntu2 upload something that chris can handle next week?
<micahg> infinity: bug control is allowed to see retraced bugs, and ubuntu-dev is a member
<micahg> jdstrand: yes
<micahg> jdstrand: as long as the 7 day SRU period is waved
<skaet> ev,  thanks will do.
<jdstrand> micahg: cool. feel free to commit any work you've done and just ask him to review/upload
<jdstrand> micahg: yeah-- that'll need to be coordinated with pitti (which is convenient since he is on both the SRU and release teams :)
<skaet> stgraber, edubuntu 20111006.1 is available
<skaet> crontab has been disabled
<stgraber> skaet: rsyncing
<skaet> heya,  who let the ubuntu-meta package through,  and what was it fixing?
<cjwatson> you can answer the latter question using https://launchpad.net/ubuntu/+source/ubuntu-meta/+changelog
<cjwatson> I wasn't the one who accepted it but I would have done if I'd seen it
<skaet> thanks cjwatson
<cjwatson> the seed commit message is "remove banshee from armel and replace it with rhythmbox, banshee is unusable on arm"
<skaet> yup,  am looking at it now.
<pitti> micahg, skaet: as chris is on holiday, and the firefox issue is upgrade-only, a 0-day SRU should do, I think
<pitti> chris has a fix, but needs testing, etc.
<ogra_> skaet, banshee is unfixable in time, the meta upload switches armel back to rhythmbox
<ogra_> sorry, i should have announced it here, but was in a hurry to get catfood before the shop closes
<skaet> ogra_,  ack.  infinity, ^^
 * skaet stepping out to lunch, biab
<ev> skaet: Got your message. We've just sat down to eat. I'll check and move the wubi binary into the right place once we're done.
<ogasawara> pitti: I uploaded a new linux-meta to resolve the missing lbm-headers and -extra meta packages, could you accept it in the queue?
<skaet> ev:  thanks!
<pitti> ogasawara: splendid, thanks!
<stgraber> skaet: I'll be uploading a new edubuntu-meta shortly, just a refresh to follow the changes to ubuntu's and apparently one of our meta wasn't up to date on ARM (which we don't ship anyway)
<stgraber> skaet: I've been discussing a NetworkManager/libnl bug in private with cyphermox. It prevents anyone on an ipv6 only network to connect to the internet when they use a static configuration.
<stgraber> it's a pretty rare setup, thought the annoying part is that if we push the fix as an SRU, they won't be able to install it unless they manually fix the route from a shell (as they won't get connectivity until the fix is downloaded)
<stgraber> is that something you'd consider for release or should we instead document and get that as SRU (hoping it's indeed a very very rare setup)?
<Daviey> stgraber: Is it a regression from Natty?
<stgraber> cyphermox: do you know? ^
<stgraber> Daviey: I would think it's but I don't have a lucid system around me here to easily check
<cyphermox> Daviey: I'd venture a "yes", but tbh I didn't spend much time playing with ipv6 on natty
<cyphermox> otoh, this part of the NM code didn't really changed that I know of, so perhaps it was the same in natty
<Daviey> It's a setup i want to create at home, but i'd expect some tweaking.  I imagine others in the same situation would expect the same, am i wrong?
<cyphermox> there's two issues: one with libnl not playing nice, and one with missing bits in NM
<cyphermox> Daviey: what do you mean by tweaking?
<stgraber> Daviey: well, when filling the IPv6 manual configuration in NM, I'd kind of expect it to actually set that configuration :) and not everything but the default gateway
<Daviey> cyphermox: potential to add my own patches.
<cyphermox> ah, no, don't think you'd need to add that much
<cyphermox> even if you just set one static ipv6 with a gateway, the default gateway for the interface is never set
<cyphermox> partly due to libnl, partly because there are small bugs in NM for that; plus then it wouldn't be removed, for the same reason
<cyphermox> and I fail at copy paste.
<cyphermox> stgraber: Daviey: the changes in NM are relatively simple and self-explanatory: http://paste.ubuntu.com/703472/
<stgraber> cyphermox: wow, that's like the shortest NM patch I've seen in month!
<cyphermox> the change in libnl3 would warrant a quick review, but basically "reverts" to libnl1 behavior: http://paste.ubuntu.com/703546/
<cyphermox> stgraber: isn't it two patches?
<stgraber> cyphermox: right ;)
<ScottK> stgraber: Accepted edubuntu-meta
<infinity> cyphermox: Those both look fine to me.
<infinity> skaet: You willing to hold off your respins for a couple hours for this NM fix?  Your call.
<infinity> skaet: Actually, we're still updating metas and stuff...
<infinity> cyphermox: Just do it. :P
<cyphermox> infinity: zug zug
<infinity> cyphermox: Your Blizzard fanboy is showing.
<skaet> infinity,  yeah, and waiting for ev to upload WUBI.
<stgraber> cyphermox: I plan on running a full ipv6 test on alternate + desktop tomorrow, just to be sure. So having that in now would be good.
<skaet> WUBI upload is my trigger to kick off the builds.     If anyone has a good reason for waiting for something else,  please post now.
<cyphermox> yup, it's a matter of minutes, the packages are pretty much ready and I've been running with them since yesterday
<cyphermox> stgraber: I'm going to need sponsoring for the libnl3 changes.
<infinity> cyphermox: I can sponsor.
<infinity> cyphermox: Throw me a debdiff somewhere or something.
<cyphermox> infinity: merge proposal good enough? https://code.launchpad.net/~mathieu-tl/ubuntu/oneiric/libnl3/lp856209/+merge/78485
<infinity> Ick.
<infinity> Yes.
<infinity> (debdiff is so much faster than me checking out a branch I don't normally work with)
<infinity> I can, however, diff from your MP and live with that. ;)
<infinity> cyphermox: Is NM on its way to the queue?
<infinity> cyphermox: libnl3 uploaded.
<cyphermox> yes, uploading now
<cyphermox> doen
<cyphermox> heh, I could have sent you a debdiff just the same, since I did make one
<infinity> No matter, LP diffs for me.
<infinity> Just easier to apt-get source when I have a local mirror than to checkout a branch I never use.
<infinity> Especiall since I have to apt-get source anyway for paranoia.
<infinity> (I always diff before I upload to make sure there's no cruft in the VCS I'm using)
<cyphermox> right. I was paranoiing, hence the slow response
<cyphermox> retested the different eth0 wlan0 with ipv6 or without, and mbm and vpns for good measure
<infinity> I'll accept as soon as I verify these are the same two diffs I reviewed before. :)
 * infinity waits for the queueu to get diffy with it.
<cyphermox> infinity: it's not quite the same
<cyphermox> infinity: for NM I added a small thing, just dropping some messages I had forgotten from warn to debug
<cyphermox> that way I don't end up spamming everyone's syslog with 10 extra lines per connection
<infinity> That sounds pleasant.
<infinity> I'll re-review for the hell of it.  It was small. :)
<cyphermox> sure
<slangasek> cjwatson: did the vesafb error suppresion fix go ahead already?
<ScottK> pitti: Thanks for taking care of moving kde 4.6.5 to -updates.
<infinity> slangasek: Changelog says no.
<infinity> slangasek: We're still waiting on wubi, I believe, so go go go? :)
<stgraber> ScottK: thanks (for edubuntu-meta)
<ScottK> No problem.
<slangasek> infinity: ok, initramfs-tools uploaded; I have not tested it
<infinity> slangasek: You rebel.
<slangasek> I'm not rebelling, just informing :)
 * skaet shifting location,  biab
<bdrung> tumbleweed: where? i synced it.
<bdmurray> I'm gonna rename p-series to Precise okay?
<bdmurray> In launchpad that its
<slangasek> bdmurray: thanks :)
<stgraber> are there any script currently looking for p-series that'll need updating?
<bdmurray> Well, I was just writing one and didn't want it needing updating ;-)
<bdmurray> using the version is more reliable
<skaet> bdmurray, thanks :)
<bdmurray> hrm, actually it results in an error with out an e-mail address for changes to go to
<slangasek> ah, so we need precise-changes to get set up
<bdmurray> or to use the api
<bdmurray> I don't have permission to change the displayname though
 * infinity thinks we're almost ready for a base-files upload.
<Daviey> Isn't that usually done on release week?
<infinity> Or, apparently we're not doing that until -3
<infinity> Yeah, getting ahead of the new and improved schedule, apparently. ;)
<skaet> :P
<Daviey> infinity: release later, release okayish.
 * Daviey looks at cloud-init
<slangasek> cjwatson: any traction on bug #745960?
<ubot4> Launchpad bug 745960 in grub2 (Ubuntu Oneiric) (and 3 other projects) "Cannot boot grub after installing to LVM (affects: 19) (heat: 108)" [High,Incomplete] https://launchpad.net/bugs/745960
<Daviey> slangasek: Did you see that udev without dbus installed is apparently causing non-deterministic boot fails?
<infinity> cjwatson: Shouldn't syslinux-themes-* be "Arch: amd64 i386" in light the whole dependency on memtest86+?
<slangasek> Daviey: um, no
<skaet> Daviey, is fix for bug 850880 going to land in time for release?
<ubot4> Launchpad bug 850880 in cobbler (Ubuntu Oneiric) (and 1 other project) "cobbler-ubuntu-import does not pull from -updates (affects: 1) (heat: 6)" [High,In progress] https://launchpad.net/bugs/850880
<Daviey> skaet: yep
<slangasek> Daviey: do you have a bug number for this?
<slangasek> udev itself doesn't use dbus
<Daviey> slangasek: I'm not sure, hggdh mentioned that jibel was still trying to work out enough information to raise a bug.  I suggested he talk with jhunt tomorrow
<slangasek> Daviey: ok, well I'm pretty skeptical of this bug description to be honest
<slangasek> we have three other known udev issues related to initramfs races
<Daviey> slangasek: Apparently installing dbus was enough to get reliable booting.. Perhaps it's slowing down the boot.
<Daviey> *shrug*
<slangasek> I think it's more likely that they're seeing one of these
<Daviey> That is all i know.
<slangasek> and that dbus is a red herring
<slangasek> ev: how was dinner? :)
<Daviey> smoser: cloud-init, why did you bump the timeout by 1?
<Daviey> smoser: So this catches the failure, and re-tries X times.. doesn't just catch and error out, right?
<slangasek> Daviey: a udev bug report tomorrow is almost certainly too late for us to get any kind of fix in for release.  But then, the same is probably true of a bug report today, so.
<Daviey> slangasek: I agree that it's probable to be the same issue.. Does that mean the already declared bug is unlikely to be resolved for release?
<slangasek> Daviey: yes, all of these udev bugs are going to be zero-day SRU material
<Daviey> geez.
<Daviey> I would have thought that it was bit of a release blocker.
<slangasek> that would imply an unhealthy amount of rushing
<Daviey> Some hardware having 100% boot failure.. Doesn't help them it being in -updates.
<slangasek> what hardware has 100% boot failure?
<ev> slangasek: We're just trying to flag the waitress for the bill
<slangasek> that's absolutely not the message communicated in these bugs
<Daviey> slangasek: Much of the Canonical IS hardware AIUI :)
<slangasek> then perhaps you should clarify what you mean by "the already declared bug"
<slangasek> because none of the things we're tracking bear the slightest resemblance to that
<slangasek> (not that Canonical IS is going to run O on their hardware, but still)
<Daviey> slangasek: bug 818177 was reported by CorpServices hardware.  bug 862823, was by IS.  Are you certain they don't have the same root cause?
<ubot4> Launchpad bug 818177 in udev (Ubuntu Oneiric) (and 3 other projects) "boot failures because 'udevadm exit' does not kill udevd worker threads (affects: 8) (heat: 62)" [High,Triaged] https://launchpad.net/bugs/818177
<ubot4> Launchpad bug 862823 in udev (Ubuntu) "udev causes a kernel panic on oneiric network install (affects: 1) (heat: 39)" [High,Confirmed] https://launchpad.net/bugs/862823
<Daviey> The failure jibel is seeing is in kvm..  However, i don't have enough data about that to comment.
<slangasek> Daviey: 818177 as it's currently being worked is nothing at all like a 100% boot failure.  If that was the original symptom, I'm afraid that's been drowned out by Adam's and Serge's debugging of unrelated configurations
<Daviey> the 'hardware' is kvm, i mean
<slangasek> 862823 *could* be the same as bug #818177 but there's really not much evidence yet to support this
<ubot4> Launchpad bug 818177 in udev (Ubuntu Oneiric) (and 3 other projects) "boot failures because 'udevadm exit' does not kill udevd worker threads (affects: 8) (heat: 62)" [High,Triaged] https://launchpad.net/bugs/818177
<Daviey> slangasek: ah, comment 1 is 1:10 success
<slangasek> i.e., 862823 has insufficient information to actually implement a fix
<Daviey> Gah, Trellis said he was going to update the bug earlier
<Daviey> 09:30 < Daviey> TREllis: hey, can you comment if you were using LVM to produce bug 818177,
<ubot4> Launchpad bug 818177 in udev (Ubuntu Oneiric) (and 3 other projects) "boot failures because 'udevadm exit' does not kill udevd worker threads (affects: 8) (heat: 62)" [High,Triaged] https://launchpad.net/bugs/818177
<Daviey> 09:37 < TREllis> Daviey: howdy, originally yes but it's visible without LVM according to the support guys in montreal who were installing oneiric yesterday on the same systems
<slangasek> right - the LVM issue has been triaged off to a different bug
<slangasek> (that's the one that adam_g is seeing, principally)
<slangasek> 818177 is now about udev reaping its children, which is a race condition that should happen *rarely*
<slangasek> if there is hardware that's failing 100%, then we definitely need to escalate
<ev> On my way to a computer now. Will sort wubi straight away
<slangasek> ev: whoo :)
<Daviey> slangasek: I'll see if i can grab some more details tomorrow morning.
 * ev underground
<Daviey> slangasek: Ah, Trellis did say that on some hardware they were blocked from testing it because of a binary firmware rename which hasn't been handled.
<Daviey> http://pb.daviey.com/GPWt/
 * infinity loves how initramfs-tools uploads make ~1200 packages uninstallable.
<slangasek> infinity: buy a bigger hamster
<infinity> slangasek: amd64 too!
<Daviey> (which smb and apw where notifed of today, don't know that there is a bug.)
<slangasek> amd64 is a bigger hamster!
<infinity> http://people.canonical.com/~ubuntu-archive/testing/oneiric_probs.html <-- See?!
<infinity> Our hamsters are just fine!
<slangasek> Daviey: right, I saw that error in the original bug data, though I don't understand how it relates to the hang-on-boot symptom
 * infinity goes to pet some dev boards.
<Daviey> infinity: lets just ship i386, only breaks 5 packages
<infinity> Daviey: Seems reasonable.
<slangasek> Daviey: is that hang completely reproducible?
<hggdh> slangasek: I think this maybe just a race condition; it happens frequently on our Jenkins rig for i386 minimal-virtual server install, and infrequently elsewhere
<Daviey> slangasek: I only learned of it at 8:30 UTC today, and if you have the scrollback, you know as much as i do.
<Daviey> infinity: Is that initramfs-tools induced issue transient?
<infinity> Daviey: Of course.
<Daviey> A happy ending.
<infinity> Daviey: Just a great example of the "archive skew" issue that we keep whining about. :)
<slangasek> hggdh: what happens, exactly?
<slangasek> hggdh: I have at least three different udev bugs in the air at the moment, I need a precise description
<slangasek> (a precise description for oneiric, of course ;P)
<hggdh> slangasek: as far as I can determine: system boots, everything seems OK; / remains RO, and udev gets completely lost
<hggdh> after some minutes you get a login prompt, but / is still RO
<Daviey> http://pb.daviey.com/ohJw/
<hggdh> reboots may, or may not, reproduce
<slangasek> hggdh: right.  Bug #818177 to a T then
<ubot4> Launchpad bug 818177 in udev (Ubuntu Oneiric) (and 3 other projects) "boot failures because 'udevadm exit' does not kill udevd worker threads (affects: 8) (heat: 62)" [High,Triaged] https://launchpad.net/bugs/818177
<hggdh> yes, really sounds like it
<infinity> pitti: All ARM-related component mismatches should be taken care of now.
<hggdh> interesting is that we pretty much *only* see it on a i386 install
<slangasek> and dbus is a red herring for that
<hggdh> I also think so, I was able to reproduce & reboot correctly without it
<infinity> pitti: Not sure what the story is on then linux-* stuff that wants to fall into universe.  Not sure if that's a failure to seed, or incorrect overrides when NEWing.
<infinity> pitti: (For x86, that is, I got the ARM linux-* stuff happy, as I said)
<slangasek> Daviey: ^^ ok, hggdh and I are aligned now :)
<Daviey> super
<ev> I see no wubi signed binary. The ticket hasnt been updated
<ev> Am I missing something?
<skaet> ev,  there's was a direct link pasted to #is window.
<skaet> just a sec, and I'll grab it again.
<skaet> ev, pasted in pm.
<ev> Right. Sorted
<ev> Wubi is ready for the CDs
<skaet> :)
<hggdh> slangasek: if it will help any, we are now saving the boot log (actually, the console log) on Jenkins, so next time it fails we will have it
<slangasek> hggdh: I think that particular bug is well-understood now, and the console log doesn't give too much relevant debugging detail by default; I might have some test packages later that would give more interesting output though
<skaet> ev, where should I be looking for Wubi to land before triggering builds?
<slangasek> skaet: it's published directly via people.canonical.com and pulled from there onto antimony by the build scripts; so if ev says "ready", you should be able to trigger anytime
<skaet> slangasek,  thanks!!
<slangasek> skaet: hold
<skaet> holding
<slangasek> http://people.canonical.com/~evand/wubi/oneiric/ doesn't show anything updated after 17:40pm
<ev> No, thats correct
<skaet> slangasek, wubi-r241-signed.exe is there
<ev> It's the stable symlink
<slangasek> ok
<ev> Which points to 241-signed
<skaet> 17:41 is when it was created by IS
<slangasek> it's just backdated?
<slangasek> ah, ok
<slangasek> skaet: good to go then :)
<skaet> slangasek, ev,  thanks \o/
<ev> Sure thing
<skaet> WUBI, CDs, DVDs building...
<skaet> Daviey,  any last updates I should be checking for being built, before kicking off server?
<smoser> Daviey, I did bump the timeout.  previously it was not catching that error and thus exiting without retrying.  i bumped the timeout to increase the chance of getting a response before giving up.
<smoser> the fact is, that on nova, the MD service is painfully slow, and 2 seconds might not return . so all we're doing is killing it by repeatedly asking it for something.
<smoser> i dont want to disable the timeout *and* retry, because then ew'd potentially do X retries with OS default timeout (which is quite long).
<infinity> skaet: I see a cloud-init upload still being debated for server.
<infinity> smoser: Accepted.  Even if it's the wrong solution, I fail to see how it's much worse.
<skaet> infinity, ok.  will wait for it to build, and then trigger the alternates
#ubuntu-release 2011-10-07
 * slangasek afks for a bit
 * skaet takes dog for walk, back in about 30 min....
<skaet> ubuntu desktop, alternate 20111007 posted
<skaet> kubuntu alternate 20111007 posted
<skaet> ScottK, ^ (desktop should be available soon)
<ScottK> OK.
<skaet> xubuntu alternate 20111007 posted
<skaet> wubi posted
<infinity> skaet: eglibc on ARM is publishing right now, should be able to spin preinstalled images in 30-45mins.
<skaet> infinity,  good to hear.   :)   looks like we should have most of them available for europe then, when they wake up.  :)
<infinity> Here's hoping.
 * skaet crosses fingers
 * infinity is tempted to make another livecd-rootfs change before building ARM images..
<infinity> skaet: Would you be grumpy if I delayed ARM by another publisher cycle? :P
<infinity> skaet: Just need one livecd-rootfs upload to get some unwanted cruft off our packages.
<skaet> infinity,  I'll defer to you for the ARM ones.  You'll be the one staying up late for them ;)
<infinity> I'm okay with that. :P
<infinity> Upload in the queue in ~2 minutes, then.
<infinity> If someone can get it reviewed/accepted before :40 or :45, should be good to go. :)
<infinity> (3 line diff)
<slangasek> infinity: mind the contents generation
<slangasek> (next hour is Dead Time for the publisher, unless you stab cron)
<infinity> slangasek: Hrm?
<infinity> Oh, feh.  Is it that time of day?
<slangasek> and the hour after that, since contents generation traditionally takes 2h :P
<infinity> Actually.  I'm going to reject.
<infinity> On the basis of wanting to fix a typo in the changelog to look less stupid.
<slangasek> wait, no, apparently I'm timeshifted
<slangasek> or can't read big-endian cron syntax
<slangasek> so you actually have 2 hours :)
<infinity> \o/
<infinity> Perfect.
<infinity> slangasek: Review for me at :40 when it lands (again)
<infinity> (please)
 * infinity wonders how this diff generation business can take this long.
 * skaet notes its like a watching a pot of water boil,  always takes longer when you're watching ;)
<infinity> skaet: That depends on how warm your face is.
<skaet> lol
<infinity> I think the queue diffy thingee has given up the will to live.
<infinity> http://paste.ubuntu.com/703708/  <-- The diff.
<infinity> Hahaha.
<infinity> And it lands in the queue right after I paste it.
<infinity> Whatever.
<infinity> slangasek: Review teh queue for me, silver plates.
<skaet> ScottK, kubuntu desktop 20111007 landed
<infinity> skaet, ScottK: Or you? :)
 * ScottK looks again.
<ScottK> infinity: Accepted.
<infinity> Danke.
 * infinity puts the publisher on manual, since he's going to miss it by 2 or 3 minutes.
<skaet> lubuntu 20111007 posted
<skaet> ubuntu-studio 20111007 posted
<infinity> Or maybe I won't.
<slangasek> infinity: sorry, was @dinner
<infinity> slangasek: S'all good.
<skaet> mythbuntu 20111007
<skaet> posted. ;)
<skaet> xubuntu desktop 20111007 posted
<infinity> skaet: Alright.  preinstalled should be good to go.  You want to add it to your queue, or have me do them?
<skaet> infinity,  please add it to your queue,  I'll be calling it a night in about an hour.
<infinity> Mmkay.
<infinity> I will be too. :P
<infinity> I'll just leave the builds running in a screen session, though.
<skaet> post the order on the pad,  and ask jibel or pitti to post when they get up.
<infinity> I'll just use pitti's loop of doom.
<infinity> Or, will, if the pad responds.
<skaet> kubuntu mobile won't be needed,  double check for that.
<skaet> http://pad.ubuntu.com/ubuntu-release
<skaet> ubuntu-uk pad goes wonky for me about this time of night,  so I moved it.
<infinity> Yeah, I saw the forward.
<infinity> And loop started.
<skaet> its in the release channel title now too.   But I was using old links myself earlier.
<infinity> With no kubuntu-mobile.
<skaet> :)
<infinity> I could go for a case of Penfold's Grange right now.
<infinity> Maybe we should dig up a bottle or three for next Thursday.
<skaet> +1
<skaet> mmmm.... Grange.
<skaet> infinity,  looks like ubuntu-server nova 2011.3-0ubuntu6 produced an uninstallable binary for i386, amd64.  worth posting?
<skaet> or not.
<infinity> Hrm?
<skaet> report.html for it.
<infinity> nova-compute-xen
<skaet> yup
<infinity> Well done, server team.
<infinity> That's not on the CD though.
<infinity> Or is it?
<infinity> Ugh, it is now.
<infinity> Yeah, they've screwed up and need promotions.
<skaet> is the image worth testing for other issues, or does that need to get sorted first/
<skaet> ?
<infinity> Nah, it's still worth publishing to test.
<infinity> Just means that one metapackage is worthless.
<infinity> E: Package 'xen-linux-system' has no installation candidate
<infinity> Go team!
<infinity> Daviey:  nova-compute-xen : Depends: xen-linux-system but it is not installable
<infinity> Daviey: You might want to look into that. :P
<skaet> thanks.   just about to do the same.  ;)
<slangasek> skaet: what's the timeline from here to images that are candidates for release?
<infinity> slangasek: We'll find no bugs and the only difference between these and release will be base-file, apport, and kerneloops.
<infinity> base-files*
<slangasek> skaet: wondering about landing a udev workaround for bug #818177 to make the server team happy, and maybe a libpciaccess fix for bug #864123 to make the desktop team happy
<ubot4> Launchpad bug 818177 in udev (Ubuntu Precise) (and 6 other projects) "boot failures because 'udevadm exit' does not kill udevd worker threads (affects: 9) (heat: 68)" [High,Triaged] https://launchpad.net/bugs/818177
<ubot4> Launchpad bug 864123 in libpciaccess (Ubuntu) "libpciaccess0:386 is uninstallable on amd64 (affects: 4) (heat: 20)" [Undecided,Confirmed] https://launchpad.net/bugs/864123
<skaet> slangasek,  testing tomorrow,  pitti kicks off the candidates on sunday night.   we should have the candidate images on monday.
<slangasek> (this is the udev bug that was discussed with Daviey earlier today; I'm ok with being told no)
<infinity> slangasek: What are the odds of the workaround causing more problems than it fixes?
<skaet> slangasek,  pondering....
<infinity> slangasek: Cause, post-Monday, we pretty much have to live with anything that isn't a showstopper...
<ScottK> Sigh.  I missed a small problem with the postfix package I accepted two days ago.
<ScottK> Missing debian/copyright.
<slangasek> infinity: the workaround is "kill it harder in the initramfs"
<ScottK> I think we'll need to fix that.
<infinity> ScottK: ...
<infinity> ScottK: Yes.
<slangasek> infinity: so, ah, approximately no risk of making it worse
<skaet> ScottK, ack.
<infinity> slangasek: And it was already being killed?  Just a larger knife and a gun now?
<infinity> slangasek: That seems reasonable to me.
<slangasek> yes
<slangasek> udevadm control --exit ; pkill udevd
<slangasek> so using both the new and the old methods to make sure it dies
<slangasek> both are racy
<infinity> But differently racy!
<slangasek> yes
<infinity> Which is what you're counting on? :)
<slangasek> so by combining the two, we've turned the race into a gauntlet
<slangasek> yes, exactly
<infinity> Seems fair to me.
<infinity> And very low risk.
<infinity> We have to rebuild once or twice anyway, and this doesn't change the viability of current images.
<infinity> (ie: we don't need to respin RIGHT NOW if you upload it)
<infinity> So, +1 from me.
<skaet> slangasek,  what are the chances of side effects?
<infinity> skaet: The only real side effect of this is it working slightly better.  Or just as badly as always.
<skaet> infinity for the udev one I assume you're talking about.  or both?
<infinity> skaet: The udev one.
<infinity> slangasek: libpciaccess is multiarching it? :/
<infinity> slangasek: (Though for a good cause, it would seem)
<slangasek> infinity: correct; it's multiarched in Debian already and I'm prodding people about testing the revdeps if they want to have a shot at it
<infinity> Yeah.  That one's a bit shakier (though I like the proposed outcome)
<infinity> But I'm all for the udev thing.
<infinity> skaet: Your call, there's my two bits.
<slangasek> skaet: side effects from the udev change in question are really zero... the only possibility of adding the 'pkill' call are that the processes don't die in time, in which case we still see the bug, or they do, in which case the bug is gone
<skaet> infinity, slangasek,  ok,  +1 on the udev one.
<slangasek> ok
<skaet> slangasek,  on the libpciaccess one,  if they satisfy you on the revdeps am thinking it would be good to have.   What's the impact of 0 day SRU vs. including it?
<slangasek> good question
<slangasek> I was mostly thinking that if we're going to make the change at all it should be pre-release because it doesn't fit the SRU criteria
<infinity> Inclusion should only matter if anything on the CD tries to install libgl1-mesa-dri:i386...
<slangasek> but by that logic it doesn't fit the final freeze criteria either
<slangasek> right, and that won't happen
<slangasek> so the net effect for users is the same whether we do SRU or late freeze exception
<infinity> (Arguably a bug that flash won't attempt to)
<slangasek> infinity: flash is also happily not on the CD :)
<slangasek> and yes, it is a bug that flash doesn't pull it in
<infinity> slangasek: There's a checkbox to install it... Which of course then comes from the archive... Which means a 0day SRU is fine.
<slangasek> yep
<infinity> Thinking these things through in print is embarassing.
<slangasek> (hmm, a checkbox to install it?  Really?)
 * infinity shrugs.
<infinity> Isn't the extras thing a question?  I dunno.  haven't installed an x86 desktop in a long time.
<infinity> It can't possibly be silently done.
<infinity> Net access + some other condision = restricted-extras
<infinity> condition.
<slangasek> ah, ok
<infinity> I should quit with the fingers.
<ScottK> It is a check that's not checked by default.
<infinity> ^
<slangasek> right
<slangasek> one I've never personally clicked ;)
<infinity> Heh.
<ScottK> (The not checked by default thing went to the TB)
<infinity> Anyhow.  I'm with you on the spirit of the thing that somehow breaking freeze is less distasteful than pretending a feature change is a sane SRU.
<infinity> If we can get it well-testing before Sunday.
<infinity> ScottK: And was unanimously voted on, I hear.
<ScottK> Yes.
<infinity> ScottK: So maybe we're not hopeless.
<ScottK> Almost no discussion needed.
<ScottK> Nope.
<skaet> slangasek, if they can satisfy you its sane and low risk, and everything is ready to go in tomorrow,  I'll go along.  I don't want it bumping up against Sunday though.
<slangasek> skaet, infinity: build tests for libpciaccess will certainly be done tonight (see #ubuntu-devel); risk of runtime regression is negligible since everything that uses it does so via ELF dependencies and the ld.so multiarch support is by this point well tested; and I can get the code review done tonight or tomorrow morning.  No risk of running into Sunday.
<skaet> slangasek, ok then.
<infinity> slangasek: Sounds reasonable.  Definitely nothing that tries to cleverly dlopen it or such madness?
<slangasek> infinity: not unless it also fails to declare its dependency on it at the same time
<infinity> slangasek: Check.
<slangasek> it's linked by things that are themselves dlopened, but that's not a problem either
<infinity> That's a bug I'm willing to expose. :)
<infinity> (the dependency one, should it exist somewhere)
<slangasek> anyway, libpciaccess is rather specialized :)
<slangasek> Description: Generic PCI access library *for X*
<infinity> Like that would stop anyone from being evil.
<infinity> But yeah, it sounds low-risk if some rudimentary testing can be done.
<infinity> Make sure file lists are sane, blah blah.
<skaet> ubuntu server 20111007 posted ( with known 'xen-linux-system' has no installation candidate)
<skaet> ubuntu dvd, kubuntu dvd,  lubuntu desktop 20111007 posted
<ScottK> skaet: Server will need the fixed postfix too.
<skaet> ScottK,  noted in the pad for rebuilds.
<ScottK> Need to release quickly before Canonical gets a cease and desist on distributing tzdata ...
 * skaet afraid to ask...
<infinity> ScottK: Seriously.
<ScottK> http://yro.slashdot.org/story/11/10/06/1743226/civil-suit-filed-involving-the-time-zone-database
<infinity> skaet: http://blog.joda.org/2011/10/today-time-zone-database-was-closed.html
<infinity> D'oh.
<infinity> I paste too slowly.
<infinity> But I don't paste slashdot, so point to me.
<ScottK> postfix taken care of.
<skaet> edubuntu dvd 20111007 posted
<skaet> stgraber ^
<skaet> ScottK, infinity, urk.  Thanks for the links though.
<skaet> chinese ubuntu finished too.   ok,  that's it for me,  pumpkin time.
<skaet> pad is updated,  good night all.
<slangasek> the suit in question is total crap under US case law; I don't know why the plaintiffs haven't already been thrown out on their ears
<ScottK> So was SCO.  That only took 8 years.
<ScottK> pitti: postfix SRU uploaded for you to have a look at.
<slangasek> ScottK: the SCO case a) had deep pockets, b) had much less clear facts to work with
<ScottK> True.
<slangasek> a lot harder to navigate the question of "did you mean to transfer the IP rights" than "are there any protected IP rights here" :)
<nigelb> slangasek: That's comforting :)
<nigelb> It is worrying to see tzdata disappear :(
<slangasek> it's inconvenient; I don't find it worrying
<pitti> Good morning
<infinity> Morning Martin.
<infinity> pitti: I have preinstalled images spinning according to the order in the pad, if you want to post them as they pop.
<infinity> pitti: core and server should be done/finishing, ubuntu's building.
<pitti> infinity: sure; will do
<slangasek> infinity, skaet: libpciaccess passes muster; synced (which I believe will bypass the queue)
<pitti> infinity: do we already want to build/post desktop/alternates, or wait with that until Monday?
<infinity> slangasek: If you synced it the ftpmaster way, it will, yes.
<infinity> pitti: skaet's been building and posting.
<pitti> infinity: as for the x86 linuxy stuff, ogasawara said she uploaded a new linux-meta
<infinity> pitti: This should get us a nice round of testing over the weekend, then we can spin RCish images Sunday/Monday.
<pitti> but seems the new meta didn't help much
<infinity> pitti: Well, the meta matches up with everything.
<infinity> pitti: It's just a question of components right now.  What belongs where?
<infinity> pitti: If everything up for demotion is demoted, it should all Just Work.
<infinity> pitti: I believe.
<pitti> infinity: anything else than "all binaries of linux are in main" are a real PITA
<infinity> pitti: (Or, some stuff needs seeding and promoted)
<pitti> as we get ten kernels a week in SRUs, and they bypass NEW
<pitti> so I think I'll just seed the extra -meta binaries instead
<infinity> pitti: Yeah, I dunno.  I still think that any time a binary is promoted to main, the source and all other binaries should be too, but I lost that argument long ago.
<infinity> I think it's bizarre to claim we support the source but not the binaries.
<pitti> infinity: well, sometimes a binary pulls in something into main which we don't want; these cases are justified IMHO
<infinity> pitti: That's rare, though.
<slangasek> not rare enough
<infinity> pitti: But I concede that point, I suppose.
<infinity> Well, it has to be doing it via a dependency that isn't also a build-dependency.
<infinity> Which is vaguely rare.
<infinity> But yes, perhaps not rare enough.
<infinity> pitti: All the armel uninstallables from britney are arch:all packages that depend on !arm packages.  Not much we can do about that, so I declare britney for arm good.
<infinity> (Well, we could fix it by making those arch:all packages be arch-specific, but a bit late)
<infinity> pitti: The only other suspect thing is openoffice.org-gcj depending on non-existant libreoffice-gcj on all arches, might actually be worth an openoffice.org upload just to remove that metapackage and have apt be slightly less confused.
<ScottK> infinity: You know how long that takes to build on arm, right?
<infinity> ScottK: About 20 seconds?
<infinity> ScottK: It's an empty package.
<infinity> ScottK: openoffice.org is just a bunch of metapackages depending on libreoffice stuff.
<ScottK> Oh.
<ScottK> Right.
<ScottK> Nevermind me.
<pitti> infinity: yeah, agreed
<pitti> bug 869459 looks reasonable to me, I'd go ahead with this; infinity, ScottK, any opinion on this (not sure if it was discussed already), or should I just go ahead and take the blame?
<ubot4> Launchpad bug 869459 in clutter-gst (Ubuntu) "FFe: Sync clutter-gst 1.4.2-1 (main) from Debian unstable (main) (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/869459
<ScottK> I'll share the blame if you'll also accept my postfix sru ...
<ScottK> (I'd say go ahead.)
<pitti> at least it promises to finally work on arm
<infinity> Promises aren't everything.
<slangasek> ^^ ignore, taken care of
 * pitti starts building new langpacks, export finished
<ScottK> I'm glad I didn't wait much longer on the backports I just accepted.
<pitti> ScottK: oh, full backports for postfix, not just upstream updates?
<ScottK> I think it's actually lower risk and easier maintenance.
<ScottK> The only significant change is the multi-instance support and since upstream has supported that since 2.6 it's really a long standing packaging bug we didn't support it.
<ScottK> Most of the packaging diff is the addition of a copyright file for the source (all the binaries already had it).
<pitti> I commented on bug 869411
<ubot4> Launchpad bug 869411 in postfix (Ubuntu Natty) (and 1 other project) "SRU tracking bug for postfix 2.8.2 -> 2.8.5 for natty (affects: 1) (heat: 8)" [Wishlist,In progress] https://launchpad.net/bugs/869411
<pitti> ScottK: sorry, it seems we had a misunderstanding in the meeting then
<pitti> I just assumed this is a mere upstream microrelease update, not a full backport including the packaging
<pitti> as the former is the usual (and only) case for approved MREs
<ScottK> OK.  Then I've been doing the clamav updates wrong for a long time ...
<ScottK> I can reduce this to just the upstream changes.
<pitti> ok, thanks; I'll reject the current upload then
<pitti> ScottK: especially bumping debhelper compat etc. will become more and more difficult the further back you go
<pitti> if we would update hardy now, it wouldn't even work
<ScottK> Right, but this will only go to natty as an SRU.
<ScottK> It would work in backports.
<ScottK> I don't anticipate asking for a major version exception like I did for clamav, so postfix 2.8 will never have to go back further than natty in -proposed/updates.
<ScottK> I've already been backporting it to lucid.
<ScottK> pitti: Reuploaded.
<ScottK> BTW, for clamav there are cases where you have no choice to change the packaging or it won't work, so it is a bit different.
<pitti> ScottK: right, understood
<pitti> thanks, will review when the diff arrives
<ScottK> I think I'm going to sleep then.
<ScottK> Good night.
<pitti> sleep well!
<pitti> gnargh, LP timing out for LP builds
<didrocks> pitti: just upoaded the one line for 3 bugs crash fix. I ran it out for an hour
<pitti> didrocks: awesome, thanks
<pitti> didrocks: so the others have more intrusive fixes where we can't be 100% sure?
<didrocks> pitti: yeah, that's why I didn't include them, the gain/risk doesn't worth it
<didrocks> can be a SRU, they aren't crashes (or crash with only one people experience, and the service then restarted)
<didrocks> of course, it will work once I target oneiric and not preciseâ¦
<pitti> lol
<pitti> it's a bit of a nuisance, isn't it?
<pitti> breaks people's habits
<didrocks> indeed :-)
<infinity> It broke me so badly that I started typing my passphrase in the suite field because I got a bit muddled.
<infinity> (I only slept 3 hours last night, shut up)
<didrocks> infinity: you never know, that can maybe works one day
<didrocks> with verylongandnotstandinguprelease :-)
<didrocks> pitti: the relevant commit is there: http://bazaar.launchpad.net/~ubuntu-desktop/unity/ubuntu/revision/591
<infinity> Speaking of uploads.
<pitti> didrocks: ah, thanks; easier than trying to relate two debian-changes* monsters :)
<didrocks> yeah, with the previous cherry-pick in particularâ¦ :)
<infinity> pitti: I'm heading to bed, new openoffice.org in the queue in 50 seconds.
<pitti> infinity: yay, will review
<pitti> infinity: I bent LP timeouts to my will, new langpacks are being built
<pitti> will upload once that's done and I gave them some good beating
<pitti> infinity: sleep well
<infinity> pitti: Not much to review.  But if you notice a GPG passphrase anywhere in the diff, let me know. :P
<pitti> *chuckle*
<infinity> pitti: Once this builds, you should be able to remove oo.org-gcj.
<infinity> pitti: And then the rest of the uninstallables are linux component issues, armel things we can't fix and one "hahaha, server team, lol wut?!" that I pinged Daviey about.
<mvo> I just upload a new update-manger, the diff looks big, but its mostly just automatic importint of the oneiric base-installer to ensure that the kernel is correctly picked, that auto updating was disabled recently by accident
<ev> for what it's worth, I can confirm the new wubi is in fact signed
<ev> so what is the game plan for the RC images? Are those intended to land today or over the weekend?
<pitti> ev: right now the plan is to trigger them on Sunday, so that on Monday morning we all have fresh images to test which are real RC
<ev> pitti: cool, thanks
<pitti> preparing/uploading langpacks right now, will accept apport/kerneloops on Sunday
<infinity> (But don't let that stop you from vigorously testing the current builds over the weekend)
<infinity> We expect RC to be very nearly identical.
<pitti> yes, absolutely
<ev> hm, I think I  missed wiring up the wubi images to the simple tree on cdimage
<ev> indeed
<pitti> http://iso.qa.ubuntu.com/qatracker/ is there for everyone's testing pleasure
<pitti> ok, langpacks are as good as they are going to be
<pitti> cjwatson: can we temporarily disable the queuebot, to avoid getting 812 "new package" and 812 "removed" lines?
<pitti> infinity: you don't happen to know where the queuebot runs at?
<pitti> can't see it on people.c.c
<pitti> */2 * * * *publish-queue -s oneiric -Q unapproved
<pitti> oh, that might be it?
<pitti> I guess it is; disabling for nor
<pitti> now
<cjwatson> slangasek: nothing on 745960 yet, probably going to have another crack at it today
<cjwatson> infinity: syslinux-themes-*> maybe?  if you want to change it, be my guest :)
<cjwatson> pitti: the queuebot runs on chiark, you don't have access ;-)
<cjwatson> pitti: I can stop the actual bot if you'd prefer
<pitti> cjwatson: I just temporarily disabled publish-queue
<pitti> it's back on now, all langpacks are in
<cjwatson> ok
<pitti> and seb just discovered that lightdm unfixed bug 849027
<ubot4> Launchpad bug 849027 in lightdm (Ubuntu Oneiric) (and 2 other projects) "lightdm does not provide an equivalent to the gdm guest session AppArmor profile (affects: 3) (dups: 1) (heat: 274)" [Critical,Fix committed] https://launchpad.net/bugs/849027
<pitti> the merge to 1.0 upstream branch forgot half of the patch
<pitti> I uploaded a new package which adds it back
<pitti> tested it, works again
<pitti> (it's in the queue now)
<pitti> it restores the code to what we had last Friday, I didn't actually have to change the commit
<pitti> (except for slightly unfuzzing a later patch)
<cjwatson> pitti: bah, sorry I missed the TB meeting, I remembered about it earlier in the day and then completely forgot about it ... it would be nice to reevaluate the meeting time with the current board, it really doesn't work well for me
<pitti> cjwatson: yeah, neither for me really, it's very late
<pitti> cjwatson: added to the agenda for next time
<cjwatson> thanks
<pitti> cjwatson: do you have a minute to review lightdm? (unfortunately still no diff yet, LP is slow on Fridays apparently)
<pitti> I'm available for interrogation on the patch
<cjwatson> pitti: yep, moment
<cjwatson> pitti: that's fine (compared with previous patch), accepted
<pitti> cjwatson: thanks
<pitti> meh, that was quite an unsuspected surprise
<pitti> just after you think you've got everything in
<sladen> skaet/robbiew: do we have enough information to populate  https://wiki.ubuntu.com/PreciseReleaseSchedule  yet?
<pitti> sladen: there is https://wiki.ubuntu.com/PScheduleInterlock already
<seb128> pitti, ^
<pitti> yep, waiting for the diff to appear, to double check
<seb128> speaking about next, cycle: https://live.gnome.org/ThreePointThree#Schedule
<seb128> GNOME 3.4.1 tarballs should be on april 16
<seb128> it would be nice if we have a schedule that allow to get .1 in Oneiric
<pitti> seb128: last week I added the main 3.4 dates to the interlock page
<pitti> seb128: ITYM precise?
<seb128> yes
<seb128> sorry my finger are not used to the next cycle yet :p
 * cjwatson is currently trying to get a last-minute LP fix in for bug 572128
<ubot4> Launchpad bug 572128 in debmirror (Ubuntu) (and 1 other project) "Ubuntu Archive translations are missing Index metadata file (affects: 3) (heat: 18)" [Undecided,Confirmed] https://launchpad.net/bugs/572128
<cjwatson> (FYI)
<ogasawara> pitti: bug 869270, I've got a fix for it.  I can upload, but would like approval from the release team first.
<ubot4> Launchpad bug 869270 in linux (Ubuntu Oneiric) (and 1 other project) "linux-image-extra's install claims unmet dependencies (affects: 1) (heat: 6)" [Medium,Fix committed] https://launchpad.net/bugs/869270
<ogasawara> pitti: the -extra's package is an elective install though, similar to lbm, so it is not release critical
<pitti> ogasawara: that's the wrong (== 3.0.0) dependency?
<ogasawara> pitti: correct, the dependency line was wrong
<pitti> ogasawara: hm, but that's the "linux" source, I suppose
<pitti> that would take quite a while to build
<ogasawara> pitti: yep, arm takes the longest to build, around 12hrs
<ogra_> did someone talk to IS about the kernel and the panda builders ?
<ogra_> we have faster buildds that can be used with some manual fiddling
<ogra_> (by IS)
<pitti> ogra_: so, it would barely fit, but leave us no margin at all for error (weekend and all that)
<pitti> erm, ogasawara ^
<pitti> ogasawara: can we upload it to -proposed perhaps, and copy to final when it all built?
<pitti> cjwatson: ^ how would that work for you?
<ogasawara> pitti: I can do that if that's the consensus here
<ogra_> lamont, are you around ? could we fast-path that kernel upload manually into a panda so it builds a bit faster ?
<pitti> with the detour via -proposed, 12 hours should even be enough
<lamont> ogra_: you'll notice that all of the non-pandas are on manual
<ogra_> well, the panda should cut the time in half
<ogra_> lamont, oh, ok
<lamont> would you like a little extra boost for the langpack builds, at the cost of idle amd64 builders?
<pitti> lamont: it says ETA 33 minutes, so no extra hurry from my side
<lamont> wfm
<pitti> lamont: but nice to know that this is possible
<pitti> lamont: OOI, how much effort it is to change their badge to be "I shall build i386 packages"?
<lamont> 1) set to manual and get the buildd idle, because I don't trust the transition edge (wgrant would probably tell me he thoroughly tested this and it's fine, but I don't remember, so I play safe)
<lamont> 2) builders/allspice/+edit <-- change architecture, uncheck manual, commit
<lamont> N.B.: architectures with no builders do not get build records.  that's why there's an lpia builder still... so don't ever take all of them
<lamont> s/no/no ok/
<lamont> 3) remember what you hijacked so you can put it back later
<lamont> 4) profit
<lamont> sorry for the long path to profit, fiww
<pitti> lamont: oh, nice; that doesn't even require superpowers, I could do that as well
<lamont> it requires buildd-admin powers
<pitti> lamont: perhaps I can try on one, for the exercise?
<pitti> is that safe?
<lamont> sure
<pitti> lamont: yes, got them
<lamont> allspice is love
<pitti> oh, they are both on manual already
<pitti> are you working on them right now?
<lamont> fruits beat penguins any day
<lamont> oh.
<lamont> I started to, then didn't, but left them on manual. oops
<pitti> ok, so taking allspice as guinea pig
<lamont> so I cheated you out of the pleasure of doing step 1
<pitti> switched
<pitti> https://launchpad.net/builders -> sweet
<lamont> I'll throw crested back on auto then
<pitti> lamont: not that I dare to try, but what would have happened if I set it to sparc? would the DC burst into flames?
<pitti> or would it backfire and set _me_ on fire?
<lamont> nah, but the builds would have failed in not-quite-spectacular ways
<pitti> there, allspice building i386
<pitti> nice
<lamont> since the sparc tarball isn't really compatible with chrooting into it on an x86 box
<pitti> there have been occasions where this would have come in handy
<pitti> lamont: thanks
<pitti> yep, build finished
<pitti> ok, just for the fun I'll leave that running for a while and switch back
<lamont> though just for my sanity, if you bluetab me here or #is when you shuffle things, I'll have a clue when someone else asks me wtf is going on
<pitti> yep, will do
<pitti> I don't expect to actually use this very often
<pitti> lamont: but I updated the description for that ("An amd64 builder (pitti temporarily hijacked to build i386)"), to at least leave some footmark
<lamont> even better
<lamont> I've been changing them to say what the builder is capable of in some cases
<cjwatson> pitti: I'm not overjoyed about uninstallable packages in the release pocket, but I guess a zero-day is OK
<pitti> cjwatson: I mean, we coudl copy -proposed into release, not -updates
<pitti> cjwatson: the main thing that would look odd then is the changelog
<pitti> lamont: that'd be my next question
<pitti> lamont: we actually had cases when the three amd64 builders were busy building java, gcc, or whatnot, and we desperately needed an ubiquity
<pitti> lamont: are some of the i386 buildds able to build amd64?
<lamont> roseapple is likely
 * lamont checks
<lamont> pitti: so yeah, roseapple.  the others have 32-bit kernels
<pitti> lamont: mind if I update the description to point out that?
<lamont> feel fre
<lamont> e
<pitti> done
<cjwatson> pitti: oh, sure, I'm fine with that too
<pitti> ogasawara: so, let's go ahead with this
<ogasawara> pitti: ack
<pitti> gives us a nice exit hatch
<sladen> pitti: bargin.  I was mainly just after some milestone to put stuff against
<lamont> pitti: allspice is ready to return to normalcy
<skaet> slanden, schedule is up at https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule,  have put a redirect from PreciseReleaseSchedule to there as well,  as I suspect you won't be the last to ask ;)
<ogasawara> pitti: ok, kernel uploaded, just needs approval.
<skaet> pitti,  ogasawara,  just checking I've read the backscroll correctly - this is for 0-day SRU,  not the release image?
<ogasawara> skaet: if it finishes building in time to make the release, it'll be copied to the release pocket.  Otherwise it'll go out as a 0-day.
<skaet> ogasawara, can you summarize what its fixing for me?
 * skaet needs to get more coffee it appears. :P
<ogasawara> skaet: yep, linux-image-extra fails to install because it claims it has an unmet dependency.  The Depends: line in the control stub was wrong, so this patch fixes it.
<skaet> ogasawara, depends line fix is the only change?
<ogasawara> skaet: yep, it's the only change.
<skaet> ogasawara, thanks,  that makes me feel better about it.
<ogasawara> skaet: indeed, no actual kernel code change.  and the fact that it fails to install at the moment means we can't really break it any more than it is.
 * skaet is trying to figure out if that last statement is meant as reassurance or warning... ;)
<pitti> skaet: goo dmorning
<pitti> lamont: hm, wasn't here, but I just switched it back
<pitti> skaet: it's to fix the remaining uninstallable packages
<skaet> pitti, yup,  less worried after the explanation, but it was a bit of a jolt to wake up to a kernel rebuild going on.
<pitti> skaet: yeah, while the diff should be small, I'm not a fan of directly building it in release, so we figured out this trick
<pitti> ugh, 3.3 MB diff
<skaet> pitti,  it seems worth remembering. ;)  removes the risk.    what 3.3MB diff??   BTW has there been any input from Daviey on whether they'll be wanting a rebuild of server.
<pitti> skaet: just the usual noise of cleaned up abi files
<pitti> skaet: I didn't notice a request from Daviey; Daviey, do you need one?
<pitti> ogasawara: looks fine, thanks! accepted
<skaet> pitti,   http://pad.ubuntu.com/ubuntu-release
<skaet> xen-linux-system issue with the last build, and picking up the udev change.
<skaet> am wondering after we here from jibel if we should respin the desktop to make sure no weird interactions from desktop fixes that went in.
<cjwatson> hm, so where is this udev workaround?  I thought Steve had uploaded that
<pitti> I think it went to a PPA
<cjwatson> I don't see it in LP though
<cjwatson> ah
<pitti> the bug asks for testing it
<cjwatson> right, https://launchpad.net/~vorlon/+archive/ppa/+packages
<pitti> skaet, cjwatson, doko: I proposed merging debhelper and cdbs to https://wiki.ubuntu.com/P-SeriesOpening; how does that move from "proposed" to "set"? collecting votes from other release team members?
<cjwatson> well I agree at least
<doko> pitti, looks like violent agreement ...
<skaet> pitti,  let me ask some questions after the meeting.   :)
<Laney> sounds reasonable indeed
<pitti> we already had some packages which needed a newer debhelper
<pitti> and it's not really known to cause many regressions (at most FTBFS due to becoming stricter, but that's fine I think)
<pitti> skaet: ^ FYI
<pitti> skaet: yes, fine to discuss post-meeting
<pitti> skaet: reading http://packages.debian.org/changelogs/pool/main/c/cdbs/current/changelog, we really want that for precise IMHO
<cjwatson> yep, we've always done packaging toolchain early and it makes good software engineering sense to do so
<cjwatson> (i.e. before autosyncing the bulk of packages)
<pitti> I can commit to do the merges on Monday and have them ready
<pitti> ooh, seems we have a trivial fix for bug 795475
<ubot4> Launchpad bug 795475 in libimobiledevice (Ubuntu Precise) (and 3 other projects) "[iOS5 devices do not work] Unhandled lockdown error (-4) (affects: 4) (heat: 28)" [Medium,Confirmed] https://launchpad.net/bugs/795475
<pitti> how much do we love apple (for oneiric)?
<pitti> http://cgit.sukimashita.com/libimobiledevice.git/commit/?id=f0487376671ffd6ac3fc121657f1fbd0acea3cb0
<doko> pitti: which "toolchain regression"?
<pitti> doko: context?
<pitti> doko: you mean for debhelper?
<doko> <pitti> (if for nothing else than to test for toolchain regressions and the like)
<pitti> there have been some cases, and there was some talk for e. g. disallowing brace expansion in .install files
<pitti> doko: ah - well, the ones we don't know about :)
<doko> well, ok. now I know that I can ignore this when you report this
<pitti> doko: this just said "we should test the new kernel once it's built"
<pitti> there is a nonzero chance that something breaks, even if it was just a dependeny fix
<pitti> we had the weirdest things in SRUs already
<cjwatson> I've fixed up the display name and such for https://launchpad.net/ubuntu/precise, and created milestones based on the current published release schedule
<slangasek> cjwatson, pitti: the workaround probably isn't
<slangasek> I've since had a closer look at udev code, and can't see any reason it would help us at all
<skaet> cjwatson,  thanks.
 * skaet takes that off the list for london.
<pitti> skaet: I have a livecd-rootfs update for fixing the Chinese image overflow (pinged cjwatson to review the commit)
<skaet> pitti,  ack.   mark it on the pad for respin,  and I'll trigger it later then.
<pitti> skaet: I learned that it needs an RT first
<skaet> pitti,  RT?   not parsing that one.
 * skaet must need more coffee
<pitti> skaet: request tracker ticket for IS, to install that new livecd-rootfs version once it's through unapproved ^ and in the archive
<pitti> cjwatson: do you have a sec to review it?
<pitti> (it's just that bzr change plus dch -r)
<skaet> pitti,  D'oh!   of course.
 * skaet must go get coffee
<pitti> lamont: once above livecd-rootfs is accepted, we need to roll it out to the builders; I prepared an RT to be sent once it's accepted, but we would need it today still (or tomorrow, but meh weekend); do you have the powers to fast-track this?
<skaet> cjwatson,  netboot images - Oct 6th ones good to post on the ISO tracker?
<cjwatson> pitti: yes, link/number?
<cjwatson> skaet: yes, although we ought to rebuild them if this kernel upload makes it in time
<pitti> cjwatson: I was holding it back until it actually gets accepted
<cjwatson> pitti: oh right, one moment
<cjwatson> pitti: fine, accepted
<skaet> cjwatson,  ok  will post,  but mark for rebuiding based on when the kernel lands.
<pitti> cjwatson: https://rt.admin.canonical.com/Ticket/Display.html?id=48375
<pitti> also added to pad now
<pitti> skaet: ^ FYI, pad now has the links to the livecd-rootfs build page and RT
<pitti> skaet, cjwatson: for coordination, I can test the new linux kernel on amd64 and i386 tomorrow morning, and copy it to oneiric if it's alright; ok?
<skaet> pitti,  that sounds fine by me.
<skaet> pitti,  I'll go ahead and rebuild the desktop this afternoon then,  and post the images, so we can check that last nights fixes haven't caused any surprises.
<slangasek> Daviey: we still don't have a useful workaround for udev; this is going to have to go to -updates
<Daviey> slangasek: yeah, i wondered if the sleep 'fix' that seemed to hide the race for most scenarios might be a good release 'fix'?  Then SRU a proper resolution?
<skaet> pitti,  if the linux image are good,  does it make sense to do one more desktop build before Sunday with it in?
<slangasek> Daviey: I don't know what sleep fix would hide any races, we're apparently already hitting the 60s timeout waiting for worker threads to die
<pitti> skaet: I don't think it's worth the trouble really; they are identical except for the broken dependency, modulo tool chain issues (but the toolchain didn't change in some time)
<Daviey> slangasek: Hmm, adam_g had a sleep patch (on the bug) would gave udev settle time, hiding the race.
<Daviey> Isn't that doing the same thing that those debugging found, that exposing debug messages also slowed it down enough to hide the race?
<skaet> pitti, ok then.   Have all the fixes for the desktop images landed?   If so,  I'll start it now.
<pitti> skaet: yes
<slangasek> Daviey: adam_g has been debugging a different issue than hallyn and TREllis
<slangasek> Daviey: Adam's bug is vgchange deadlock when udev dies; yes, a sleep would help that settle, but we haven't even been looking at that bug right now because I understood 818177 to be the higher priority
<Daviey> slangasek: hallyn was reducing the impact with debug messages slowing it down aswell, right?
<slangasek> Daviey: yes, but that could be a result of timing changes *internal* to udev
<slangasek> to where a sleep in the main script isn't going to make a difference
<Daviey> Is it awful to suggest adding the debug messages for release, and removing them as an SRU when we have a decent fix?
<slangasek> if someone shows that a sleep helps, we can consider it, but even so we're too close to the cutoff to be uploading things that help some people if we don't understand why
<slangasek> because it might regress other systems
<Daviey> udev seems as solid as a wet paper bag :)
<pitti> good night everyone!
<Daviey> nn pitti
<slangasek> night, pitti
<cjwatson> Do we have consensus on syncing from testing for precise?  I should get an LP branch landed for that if sos
<cjwatson> *so
<jbicha> https://wiki.ubuntu.com/LTS says we sync from testing :)
<cjwatson> jbicha: yes, but we normally re-discuss that each time
<cjwatson> I think it's a good idea, I just want to check
<slangasek> cjwatson: I interpreted the mails as a consensus
<cjwatson> I've clearly lost the mail trail - what was the subject?
<cjwatson> (just want to have a reference for the LP bug)
<slangasek> oh man, now I have to extract an actual reference
<slangasek> skaet: do you remember where this was discussed?
<jbicha> https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2011-September/012945.html
<cjwatson> oh, ue-leads maybe?  Subject: 'P' series prep - planning for LTS
<cjwatson> ah, public thread, much better
<cjwatson> and I even replied
<slangasek> :)
<stgraber> skaet: just so you know, we seem to have a pretty serious upgrade problem with Edubuntu. Poked mvo about it (update-manager deciding not to upgrade edubuntu-desktop)
<stgraber> it seems to be a package dependency resolution problem when both switch from gnome 2.x to gnome 3.x and also depending on gnome-session-fallback, I'm sure mvo is a lot better at parsing apt.log than I'm so hopefully we'll have a fix soon
<skaet> stgraber, thanks for the head's up.   slangasek ^^ FYI.
<slangasek> stgraber: are we expecting to need to get the fix onto the CD?
<stgraber> slangasek: not sure yet, I'd think it should be fixable through a 0-day SRU for edubuntu-meta, though then I'd probably prefer to have it on the DVD anyway. That'd only affect Edubuntu DVDs though.
<slangasek> stgraber: right
<slangasek> mostly wondering if you expected to need it fixed in update-manager
<stgraber> well, if we need it fixed in update-manager, that's going to be in Natty's, not Oneiric's or in the .tar.gz it downloads when starting the upgrade
<stgraber> so I don't expect this to need to respin anything other than potentially Edubuntu
<slangasek> right, ok
<lamont> pitti: livecd-rootfs gets caught at the start of BuildLiveCD when it does a dist-upgrade.
<lamont> or are you talking about a new BuildLiveCD?
<Daviey> cjwatson: bug 870212, no chance for release - right?
<ubot4> Launchpad bug 870212 in debian-installer (Ubuntu) "no network d-i install does not continue after failing network setup (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/870212
<Daviey> pondering adding a Release Notes target, once you confirm.
<ScottK> skaet: Sorry I missed the meeting.  Kubuntu is in pretty good shape except for the ongoing kdepim pain.  Upstream sent out a strong recommendation to apply a fix for a data corruption issue, so I think it's important to get on the ISO.
<ScottK> Given that, I'm going to look at post 4.7.2 fixes to see what it makes sense to cherrypick.
<skaet> ScottK,  ack.
<ScottK> I'll have it in the can well before the final spin on Monday.
<skaet> inifinity,  what's the status with the arm images?   not seeing any on the iso tracker.
<skaet> hmm....  seem to be built from the dailies.  Adding.
<stgraber> skaet, slangasek: mvo tracked down the problem to gnome-panel, he should have a potential fix tested a bit later today. So we'll need to have a new gnome-panel uploaded in Oneiric. Package seems to only be shipped by Edubuntu (source has been demoted to universe)
<infinity> lamont: http://launchpadlibrarian.net/82233919/livecd-rootfs_2.42_2.43.diff.gz is a BuildLiveCD fix, so I assume that's what he meant, yes.
<lamont> infinity: yeah - RT with the script attached is the ideal answer for that
<infinity> I thought he filed an RT?
<infinity> Ahh, he did, but wasn't specific.
<slangasek> stgraber: aha - sounds doable, thanks
<infinity> https://rt.admin.canonical.com/Ticket/Display.html?id=48375
<infinity> lamont: ^-- He just failed to mention BuildLiveCD anywhere in the ticket. :P
<infinity> lamont: RT#48375 updated.
<skaet> stgraber,  limited scope at this point is good.   glad mvo figured it out.
 * mvo is on it
<infinity> skaet: Yeah, they all built.  pitti was meant to add them as they popped, I guess he got sidetracked. :)
<skaet> ubuntu desktop 20111007 omap, omap4, mx5, ac100 posted.
<skaet> GrueMaster, ogra_  ^^
 * infinity rsyncs for some testing.
<skaet> kubuntu desktop 20111007 omap, omap4 posted
<skaet> ScottK, ^
<GrueMaster> skaet: Are these somehow different from what was already posted for 20111007 daily?
<skaet> GrueMaster, nope they're the same
<skaet> just posting them to the iso tracker.
<GrueMaster> ok.  I l already have them then.
<GrueMaster> Ah.
<skaet> goodness
<ScottK> OK.
<infinity> Daviey: Is something being done about nova-compute-xen's uninstallability?
<infinity> Daviey: (Or maybe it's intentional, but I don't see what provides "xen-linux-system"...)
 * infinity likes a world where the armel build of linux finishes first.
<Daviey> infinity: i assumed it was showing because it's deps were in universe.
<Daviey> It should be gone now... but you raise a good point.
<infinity> Daviey: xen-linux-system doesn't exist at all...
<infinity> Daviey: I suspect it's something Debian-specific that we don't provide?
<infinity> (And maybe we should?)
<Daviey> it wouldn't be that, it was added by a Ubuntu developer
<Daviey> and not in debina either
<Daviey> debian*
<infinity> Daviey: Well, a quick google for it shows that such a package exists in Debian.
<infinity> http://packages.debian.org/sid/xen-linux-system-3.0.0-1-686-pae for instance.
<cjwatson> Daviey: that's distinctly not ideal and I suspect a regression in the IPv6 branch.  I'll see what I can do
<Daviey> *awesome* https://answers.launchpad.net/nova/+question/172828
<cjwatson> (but my daughter needs attention just now)
<Daviey> cjwatson: thanks, as there is a workaround - and those installing with no network are a small set, i'm not going to cry about it.
<cjwatson> it's the sort of thing I tend to regret not fixing before release
<Daviey> sure
<cjwatson> preseeders get really unhappy with me
<infinity> Daviey: I'm not sure if dropping the dep (as in the whiteboard) is the right answer, or if we should be providing the metapackages like Debian, but dropping the dep sure it easier. :P
<infinity> s/it/is/
<Daviey> well yes
<Daviey> infinity: I think the theory being that you need to do some manual foo.
<infinity> Daviey: ?
<Daviey> infinity: I'm not sure just installing xen is enough, even in linux 3.0.
<Daviey> i'm digging
<infinity> Daviey: Eh?  Installing a dom0-capable kernel and the hypervisor (minus a bug where the grub entry was wrong, but that's supposedly fixed now) was all it took back in hardy.  Surely, we haven't made things worse?
<infinity> Well, and a reboot.
<infinity> And, sure, having a package installed doesn't guarantee you've rebooted.  We had that same problem in hardy with some xen-foo deps.
<infinity> But it's still a good hint.
<Daviey> xen hasn't been presetn since then. :)
<infinity> Daviey: Yes, I know.  I'm just hoping it's as-good-or-better than the hardy support was. :P
<infinity> Daviey: Either way.  Dropping the dep is fine too.  Depending on kernels has always been a lose-lose game for any package.
<infinity> Daviey: Because, as stated, you can't actually guarantee it's booted just because it's installed.
<infinity> Daviey: Packages that REALLY care (like libc) do preinst checks, but that seems stupidly heavy-handed for nova-compute-*, which could just fail to run when installed.
<infinity> (Though it would be nice if you can verify that it fails to run in a sensible and informative way for P, if it doesn't already in O)
<Daviey> infinity: I really don't care for O TBH.
<Daviey> If that is the only bug the xen package has, i am a happy bunny
<Daviey> (HINT, it's not been tested)
<infinity> And it won't be tested if it can't be installed. :P
<infinity> So at least dropping the dep is sane.
<Daviey> I don't yet have enough info to rush something.
<slangasek> doh, at least one regression reported as a result of adding vesafb fallback support to the initramfs (bug #869119)
<ubot4> Launchpad bug 869119 in initramfs-tools (Ubuntu Oneiric) (and 1 other project) "screen goes blank before showing password prompt (inteldrmfb, cryptsetup) (affects: 1) (heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/869119
<Daviey> might want, xen-hypervisor-4.1-amd64 | xen-hypervisor-4.1-i386
<slangasek> not a blocker, but doh
<infinity> Daviey: Possibly, but as pointed out, depending on kernels is a lose-lose battle (and hypervisors are kernels in this context, as you can't guarantee you've booted to it just because it's installed)
<infinity> Daviey: So, (for P), having no dep but having it fail verbosely with "this isn't a Xen dom0, doofus" might be appropriate.
<Daviey> no, this is a firefight fix - for P we should set the reboot-required flag at least
<infinity> Daviey: Even a reboot-reuquired guarantees nothing, if they boot to a different GRUB entry.
<skaet> ubuntu alternate 20111007.1 posted.
<Daviey> infinity: yeah, i agree.. i've given this more consideration that i care to for O :)
<infinity> Daviey: Like I said, for O, I think just making it installable (ie: by dropping the dep) is probably enough to get it tested.
<infinity> Daviey: Rethinking for P is totally out of scope for this week, unless you find yourself bored. :P
<Daviey> infinity: Well xen-hypervisor-4.1-{amd64|i386} seems like a good middleground, no?
<infinity> Daviey: If that's the dep on amd64, and cleverly reverse on i386, it's probably vaguely sane.
<infinity> reversed*
<Daviey> anyone deploying a virtualhost on i386 needs their head looking at :)
<infinity> Not inclined to disagree.
<Daviey> still cannot be installed on armel, unless you want to fix - https://launchpad.net/ubuntu/+source/xen/4.1.1-2ubuntu4/+build/2826607 :)
<infinity> Yeah, I've heard rumours of upstream work for xen on PPC and ARM.  I don't much care this week. ;)
<jdstrand> skaet: sorry for not being around for the release meeting. I saw micahg responded, and he is correct, nothing really left for us for oneiric besides security updates after its released :)
<skaet> jdstrand,  no worries.  micahg handled it.  :)
 * skaet removed worry about last minute security update from her list. ;)
<infinity> Well, they can be uploading to security right now anyway. :)
<infinity> And images are always insecure a week after release. :P
<skaet> :)
<jdstrand> heh
<jdstrand> true, we can just start going to oneiric-security and not worry anyone :)
<jdstrand> though, tbh, I think the image builders would pull from there
<jdstrand> anyhoo, we aren't doing that for the moment
<skaet> Daviey,  did you just approve ssh-import-id?
<Daviey> skaet: I can't trigger an approve on anything
<Daviey> not ~ubuntu-archive
<Daviey> <--
<skaet> Daviey,  understood.   ok, wondering who approved it then?
<Daviey> skaet: might be a good idea to push for better auditing next cycle. :)
<infinity> skaet: I did.
<skaet> Daviey:  +1 on that.
<infinity> skaet: It seemed straightforward enough.
<infinity> And no possibility for negative impact.
<Daviey> I Confirmed the bug which was raised regarding it.
<skaet> infinity just a bit surprised to see it go through.
<Daviey> It broke at least one app, not having it
<skaet> if no negative impact, and unbreaks something yeah understood.
<jibel> bug 870281
<ubot4> Launchpad bug 870281 in ubiquity (Ubuntu Oneiric) (and 1 other project) "installer crash when user choose to install additional software: http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_10.3.183.10.orig.tar.gz doesn't exist (affects: 4) (dups: 3) (heat: 30)" [High,Confirmed] https://launchpad.net/bugs/870281
<skaet> slangasek, ^
<skaet> known?
<infinity> mdeslaur: ^
<infinity> As far as I know, mdeslaur was planning a new upload of flashplugin-nonfree.
<infinity> Maybe.
<slangasek> skaet: yes, flashplugin-nonfree needs updated every time there's a new upstream version; mdeslaur indicated he would handle it
<slangasek> assigned to him
<skaet> slangasek,  thanks!
<Daviey> flashplugin-nonfree really needs a better mechanism IMO.
<stgraber> 21:16 <mvo> hm, this needs a little bit more work but its getting late, I will have to poke at it tomorrow morning
<stgraber> 21:17 <mvo> I think the solution will be to add a explict breaks against the version of the rdepends of libpanel-applet-3-0
<stgraber> 21:17 <mvo> but I need to go to sleep
<stgraber> 21:17  * mvo waves until tomorrow
<stgraber> skaet: ^ so you know
<skaet> Thanks stgraber.   slangasek,  please keep a lookout for it while I'm traveling.
 * Daviey thought next week would be mostly sitting by a pool drinking sangria.. starting to look like we'll have to work.
<stgraber> I'll poke mvo tomorrow morning about it just before I leave to Montreal for the gnome summit (and then catch my flight to London in the afternoon)
<stgraber> if the fix gets uploaded tomorrow morning, I should have some time to test the upgrades from the airport
<skaet> thanks stgraber!
<skaet> 20111007.1 WUBI posted
<slangasek> Daviey: the "better mechanism" is to distribute the content in packages instead of having to download the content from elsewhere at package install time; but we can't do this in the Ubuntu archive because we can't redistribute the code on the mirrors. <shrug>
<slangasek> so the only thing for it is to keep close tabs on the upstream versions and update the package each time there's a new release
<Daviey> slangasek: Yeah, previously it was broken for a month IIRC.
<slangasek> well, if no one's tending it the alternative to "broken for a month" is "installable but known-insecure for a month" anyway :)
<Daviey> or pulling it out, and relying on -partner archive... not sure how that would sit with some people though
<slangasek> now that we have a 64-bit version, it's worth thinking about
<slangasek> but not during release week :)
<Daviey> no, P-Series. sure.
<skaet> indeed.
 * skaet --> errand, biab
 * infinity runs off to eat turkeys.
<ScottK> infinity: Please accept my kdepim* uploads (or anyone else who's around).
<wgrant> lamont, pitti: No need to go manual.
<wgrant> You can just flip the arch while it's building, as it only affects the next dispatch selection query.
<slangasek> are we still waiting before accepting apport/kerneloops?
<infinity> slangasek: Not going to accept them until we spin "real RC" images.
<infinity> slangasek: Which, by all accounts, is Sunday night, ish.
<infinity> slangasek: (The same time we do base-files)
<slangasek> infinity: you mean until *it's time to* spin them?
<slangasek> ah
<slangasek> ok
<infinity> Well, yes, when it's time, not after. :P
<slangasek> :)
<infinity> slangasek: Can you review ScottK... You seem to be on it. :)
<slangasek> :)
<infinity> slangasek: Also, that kernel built everywhere.  You might want to confirm with skaet, but I think the plan was to ignore the fact that the changelog says -proposed and copy it into the release pocket before the next round of rebuilds. :P
<infinity> (scrollback was a bit muddled on what the actual concensus was)
<slangasek> skaet: ^^ can you confirm that you want these linux kernels copied to the release pocket?
<ScottK> slangasek: Thanks.
<slangasek> sure
<cjwatson> netcfg fixes the problem Daviey reported earlier; that's a recent regression, I think the bug means that systems may not get a proper hostname set, and I really don't want to deal with the consequences of that
<cjwatson> it's a quick build, and if we're having a new kernel then we need a new d-i anyway, so we have an easy window for this
<cjwatson> base-files uploaded too for when we want to go RC
 * slangasek takes a look at netcfg
#ubuntu-release 2011-10-08
<slangasek> netcfg accepted
<cjwatson> thanks!
<cjwatson> Daviey: ^-
<Daviey> cjwatson: oh lovely.
<Daviey> thanks
<mdeslaur> infinity: uhm, any ideas why the old flash version disappeared from the partner archive?
<mdeslaur> I guess I'll upload a i386 only flash 11 flashplugin-nonfree for now
<lamont> wgrant: that's good to know.  I expected it was the case, but whenever I don't remember, I get all paranoid.
<slangasek> mdeslaur: because when the new one is uploaded the previous version eventually gets garbage collected
<mdeslaur> slangasek: we had that stopped a while ago, specifically for this reason..
<slangasek> oh?  who stopped it where/how?
<slangasek> and was that related to why cocoplum has been failing to garbage collect at all for a while, causing the mirroring script to overrun and blow up? :)
<mdeslaur> slangasek: I think it was infinity last time, but I'm not sure
<mdeslaur> slangasek: could be related, I'm not sure how it was stopped
<cjwatson> [5~/wg 97
<cjwatson> bah
<mdeslaur> doesn't make sense that we break the _installer_ for two days every two weeks when we publish a new flash
<wgrant> In LP's defense, it also doesn't make sense to pull stuff from partner directly like that.
<mdeslaur> wgrant: it's a terrible terrible hack, flashplugin-nonfree need to die.die.die
<wgrant> slangasek: cocoplum's process-death-row was broken because of ancient DB breakage from when we tried to delete dapper. It should have been working for ~2 weeks now, though.
<slangasek> yep
<slangasek> mdeslaur: doesn't the installer know how to fall back to the Adobe website if it can't find it on partner, in which case making sure we always update the installer package *first* would help?
<mdeslaur> slangasek: no, it doesn't know, and the reason we moved it to the partner archive was that adobe removed the old version before we could even get it into the partner archive
<slangasek> yes - but having it try partner, with adobe as a fallback, means that the installer will always be able to pull from one of the two sites
<slangasek> but if infinity has some other special way to prevent garbage-collection of old versions, that's fine too
<mdeslaur> that would be an improvement, but that wouldn't solve the problem we have, which is once the new version comes out, the old one gets nuked everywhere
<slangasek> how does it not solve the problem?
<mdeslaur> when it's gone in partner, it's also gone from the adobe site
<slangasek> it ensures that the current version of the installer package always works
<slangasek> no, the point is to make sure it's *not* gone from partner until the installer package is updated
<mdeslaur> right
<slangasek> new adobe release - everything pulls from archive.c.c in preference
<slangasek> new installer package - can't find it on archive.c.c, pulls from adobe
<slangasek> new package pushed to partner - installer pulls from archive.c.c again
<skaet> slangasek, infinity,  yes, that is my understanding of what pitti and ogasawara worked out.
<skaet> ogasawara	Yesterday we uploaded a new linux-meta-3.0.0-12.14 to resolve some missing meta-packages.  This morning we also uploaded a new linux-3.0.0-12.20 kernel to resolve unmet install dependency issues for linux-image-extra.  We uploaded to -proposed as a safety precaution in case it takes too long to build.  It will be copied to the release pocket should it finish building in time, else it'll be promoted to -up
<skaet> dates as a day 0.
<mdeslaur> slangasek: new package is always pushed to partner before we update the multiverse package
<mdeslaur> also, adobe tarball is _very_ different from what we ship
<mdeslaur> so we'll need to understand both formats / both hash sums
<skaet> slangasek, infinity:  quote above was from release team meeting today,  also there,  pitti indicated getting the linux into the images to test for toolchain regressions and the like was desirable.
<slangasek> skaet: ... what toolchain regressions?
<slangasek> that is, toolchain regressions from what?
<slangasek> anyway - yes, will copy to the release pocket then
<skaet> slangasek,  toolchain parts changed since last kernel was built.
<skaet> not expecting to see anything be an issue,  but early testing rather than later seemed appropriate.
<skaet> or at least that was how I understood pitti's comments.
<slangasek> if there is a toolchain-induced regression, we have no time to fix the toolchain anyway
<slangasek> so if that's really a concern, it's better to NOT push to release
<slangasek> so that the testing can be done in a manner that doesn't compromise the release
<skaet> http://irclogs.ubuntu.com/2011/10/07/%23ubuntu-meeting.html#t15:42
<mdeslaur> infinity, slangasek, skaet: I just uploaded a minimal change flashplugin-nonfree to fix the issue
<skaet> thanks mdeslaur
<slangasek> mdeslaur: thanks.  are you also planning to fix the flashplugin-downloader return code before release?
<mdeslaur> slangasek: I included that in the upload also
<slangasek> mdeslaur: yay :)
<wgrant> mdeslaur: I wonder if the old workaround was to rsync partner without deleting.
<mdeslaur> slangasek: :)
<wgrant> There was nothing to keep them on cocoplum, AFAIK.
<mdeslaur> wgrant: let me try and find the previous discussion in my irc logs, one sec
<Daviey> Surely when adobe release a new one, flashplugin-nonfree stops functioning as the wget (or md5sum) fails?
<mdeslaur> Daviey: yes, that was the original problem, that way someone moved the wget to the partner archive at some point in the past
<mdeslaur> adobe doesn't archive past releases
<skaet> slagasek, http://irclogs.ubuntu.com/2011/10/07/%23ubuntu-release.html,  around 15:00-15:40.
<slangasek> skaet: sorry, what am I looking at?  The only thing I see in that time range is about archive opening for P?
<skaet> slangasek,  no worries,  was an iterspersed conversation.   15:49:  doko/pitti comments.
<mdeslaur> wgrant: sorry, I can't find the discussion in my logs
<slangasek> skaet: ah, I see
<cjwatson> I don't think a toolchain regression should be a concern; for that to be plausible, the toolchain would have to have changed
<skaet> slangasek,  14:08,  me realizing that there was a kernel spin going on.
<cjwatson> there've been libc changes, but they have negligible effect on the kernel
<cjwatson> gcc-4.6 and binutils have not been uploaded since the last kernel upload
<skaet> cjwatson,  there was a binutils change I thought in the window between kernels.
<skaet> hmm... if you think not,  I'll double check.
<cjwatson> no, there wasn't; the last binutils change was completely published before the last kernel upload.
<slangasek> skaet: so basically, I have no problem with copying the kernel from proposed to the release pocket because I'm confident that there's no risk of regression from the toolchain.  I just think "check for toolchain regressions" is a bogus justification for doing the copying, because this is the one place we don't want to find out about them.
<skaet> slangasek,  cjwatson,  kernel published on 9/23 ABI bump.   binutils on 9/20.   yes,  toolchain should be fine.
<cjwatson> 9/22 but who's counting :)
<cjwatson> (changelog date != upload date)
<skaet> chuckle, yeah you're right.
<skaet> :)
<cjwatson> [5~/wg 97
<cjwatson> *sigh*
<skaet> huh??
<cjwatson> laggy system running my IRC client
<cjwatson> occasionally misinterprets control characters
<skaet> thanks,  was a confusing set.
<skaet> slangasek, please do the copy.   I think we're all convinced at this point,  and may as well pick it up in next set of builds.
<slangasek> skaet: copy done
<slangasek> afk for dinner
 * skaet hopes that she doesn't live to regret those words...  crossing fingers.
<skaet> thanks slangasek,  enjoy dinner.
<Daviey> it will go horrible wrong.. just to keep life interesting.
<cjwatson> I'll do a d-i upload tomorrow or so to pick that up
<skaet> ^ mdeslaur ,  thanks.  looked good.
<skaet> infinity, slangasek - just downloaded the latest software-center update,  and am not able to install packages - keep getting installArchives() failed: Selecting previously deselected package <insert name of package>  tried it with 3 separate packages,  can you confirm?
<skaet> yet it does seem to show up as installed.
<infinity> skaet: That's disconcerting.
<skaet> infinity,  indeed.  Can you try it.
<infinity> Yeah, I'm looking for something to install without a ton of deps. :P
<skaet> It actually does seem to work to install/uninstall - but keep getting the message saying its failed as it does the task - disconcerting.
 * infinity installs Filezilla.
<infinity> skaet: Worked and gave me the Installed checkbox...
<skaet> fresh update with the software center and linux fix just accepted this evening?
<infinity> skaet: Can you run SC from a command line and see if it spews any terminal messages?
<skaet> sure
<infinity> Ahh, yes, my SC is out of date.
<infinity> Let's try again.
 * infinity finds all that "Possible missing firmware" spam on mkinitrd disconcerting.
<infinity> skaet: Latest version still works as advertised for me. :/
<infinity> I hate having mechanic's syndrome sometimes.
<slangasek> skaet: trying to confirm here.  If you downgrade to the previous version, does the problem persist for you?
<skaet> infinity, slangasek bug 870446 has my screenshots.
<ubot4> Launchpad bug 870446 in software-center (Ubuntu) "installing or removing packages - seeing message saying it has failed, but it seems to succeed (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/870446
<skaet> slangasek,  will try.
<infinity> Hrm.
<infinity> Thought it might somehow relate to your testing with gnumeric, but can't reproduce with that either.
 * infinity tries a fresh install on his Panda instead of his crazy desktop.
<slangasek> skaet: I don't see it here either
<skaet> slangasek,  I'm seeing it in on prior version of software center as well.
<skaet> machine is a pure victim machine,  no customizations.   defaults all the way.
<slangasek> hmm
<slangasek> well, the error message in the screenshot is about preconfiguring packages
<slangasek> which is about debconf
<slangasek> what image was used for installing?
<skaet> I used the beta2,  and then updated every day since then.
<slangasek> which beta2 image?
<skaet> amd64 desktop
 * slangasek nods
<skaet> its release notable, since the right action does seem to happen, but something is wrong for it to appear in the first place.
<skaet> s/it/the message saying it failed/
<slangasek> well, I think it's probably somehow specific to your machine if no one else has reported it or is seeing it now.  The error message definitely points to a problem specific to debconf, which makes me wonder if it's not software-center at all having the problem
<slangasek> but rather something to do with debconf on the backend
<infinity> Corrupt debconf DB?
<slangasek> could be any number of things
<infinity> skaet: If you purge gnumeric and reinstall it with apt-get, do you get anything fancy?
<slangasek> skaet: could you check if 'apt-get install $pkg' gives normal... what infinity said
<slangasek> btw, I think I understand the udev issue well enough now to push a workaround after all
<skaet> slangasek, infinity - trying
<infinity> slangasek: That sound... Promising?
<slangasek> I still don't know why we're losing a worker thread, but I do know why we were winding up with /dev screwed up post-initramfs - and that's because the init-bottom script was set -e and udevadm control --exit exits non-zero if it hits a timeout waiting for udevd to die
<slangasek> so if we just raise udevadm control's timeout a little on the commandline to ensure udevd *does* die first, we should get clean (if slow) boots in all these cases
<slangasek> and then it's just a matter of figuring out why the heck udev is losing its mind
<infinity> What happened to the pkill option?
<slangasek> infinity: it turned out to be irrelevant
<slangasek> udevadm control --exit is doing all the right things
<infinity> Kay.
<slangasek> except for the bit where udevd and udevadm control each having a 60s timeout means udevadm usually hits its timeout first, returning non-zero
<infinity> But that timeout would have to be insanely high to catch every possibe problem, I assume.
<slangasek> no, it just needs to be about 61s long
<infinity> Ahh.
<slangasek> :)
<infinity> Just longer than udevd.  I didn't catch that.
<slangasek> which, granted, *is* insanely high, and that we're hitting it at all means something's badly messed up
<infinity> Well, if udevd is hung...
<infinity> Or, rather, in a patient loop waiting for something else to timeout.
<slangasek> it's successfully reaped all of its children, but for some reason it still has references open to the now-dead worker thread
<slangasek> so udevd appears to be waiting around for no reason at all
<slangasek> big bug - but for the initramfs script itself, all we care about is that we're not hitting the timeout in the caller unnecessarily
<infinity> It's not still dealing with events or something?
<slangasek> *that* is what's causing /dev to fail to be mounted, and is a clear bug in the script
<infinity> Does exit trigger the same codepath as stop-exec-queue before it shuts down?
<slangasek> stop-exec-queue?
<infinity>        --stop-exec-queue
<infinity>            Signal udevd to stop executing new events. Incoming events will be queued.
<slangasek> I don't think so... will check in a bit
<infinity> How reproducible is this hitting the 60s wall business?
<slangasek> with the right VM, I seem to be getting it about 50% of the time (with small sample size)
<slangasek> on real hardware, I've not seen it at all
<slangasek> but TREllis and lynxman have
<slangasek> (and in that case, it's somehow related to a bnx2 firmware load failure)
<infinity> Oh, also, rewinding a bit, you mentioned set -e terminating the script early and then life carrying on.
<infinity> Didn't run-scripts used to panic when a child exited non-0?
<infinity> This seems like a regression to me. :P
<slangasek> I don't know
<infinity> (I had the same issue debugging jasper seemingly "skipping a bunch of code" because something was broken earlier up)
<infinity> I was almost sure that initramfs scrip bugs used to panic().  They sure should.
<infinity> Well, I think they should.
<slangasek> care to track it down in the history?
<infinity> Maybe it was deemed unfriendly somehow.
<infinity> Yeah, going to look and see.
<skaet> slangasek, infinity - updating to the lastest flashplugin-downloader got rid of the message.    I'll be closing the bug.
<infinity> Oh!
<infinity> It was a postinst failing over and over or something?
<infinity> Wait, but fp-downloader doesn't fail.
<infinity> (which is also a bug)
<mdeslaur> infinity: the new one now fails properly, fyi
<infinity> mdeslaur: \o/
<skaet> infinity,  I'll paste you the terminal messages before and after in a PM.
<infinity> slangasek: I might be misremembering the panic-on-non-zero-exit thing.  Can't find a change that would have removed it.  Or the changelog sucks and I need to root through history. :/
<infinity> slangasek: That still feels wrong to me, though.  Skipping half a script and still booting can be pretty damaging (not to mention confusing).
<infinity> mdeslaur: Hahahah.  According to skaet's apt output, in some cases, it would fail anyway, thought entirely by accident.
<mdeslaur> infinity: oh, can I see it?
<infinity> nspluginwrapper: /usr/lib/flashplugin-installer/libflashplayer.so is not a valid NPAPI plugin
<infinity> mdeslaur: (That was her previous version, upgrading made it happy)
<infinity> But she was in a broken postinst loop with that.
<mdeslaur> infinity: ooooh, there's a bug about people hitting that. That happens when it's missing.
<infinity> Well, upgrading fixed her up.
<mdeslaur> skaet, infinity: can I see the log output?
<infinity> That was the only thing relevant in her recent logs.
<infinity> I assume it broke earlier on an upgrade attempt, probably hidden by a GUI.
<infinity> Or something. :/
<mdeslaur> we definitely need to create a few deliberately broken packages to test all the gui tools failures before LTS
<infinity> Yeah, I'm not really happy with how the GUI tools deal with failure.
<infinity> Failure happens.  Especially in third-party repos and PPAs (but even in our own).
<infinity> And we deal with it fairly poorly.
<infinity> apport will pick it up from update-manager.
<infinity> No idea about SC.
<infinity> I think we need a friendly GUI "rollback" option, though.
<skaet> +1 on that
<infinity> Cause for a non-technical-non-bugfiling-non-googling-for-answers user, it's sort of the end of the world to just have your packaging system broken "forever" by a broken package.
 * skaet is visualizing her mom, about now.
<infinity> And I'm not even talking some fancy LVM snapshotting thing (a la Windows rollback), I just mean some clever heuristics to try to purge a system of an obviously unconfigurable package.
<infinity> "Installing foo failed, would you like to try purging it with fire, or would you prefer to never install another piece of software again without confusing errors?"
<slangasek> infinity: no, fp-downloader doesn't fail, but fp-installer which depends on it *does*
<infinity> slangasek: Oh, quite right, I didn't look at the package name, just the failure.
<infinity> It's all the same to me.  flash.*
<slangasek> yet another reason the failure should be made fatal at the source
<slangasek> hmm, this is the exact same conversation as the initramfs one
<infinity> Sort of, yes.
<infinity> Now my head hurts.
<slangasek> infinity: as far as stop-exec-queue is concerned, --exit also causes incoming events to no longer be queued
<slangasek> (but otherwise has the same effect, that events in the queue are no longer processed)
<infinity> Mmkay.
 * slangasek works on figuring out what the event stuck in udev's gullet is
 * skaet wishes slangasek luck,  and figures she better call it a night.  
<slangasek> skaet: 'night - have a good flight!
<skaet> thanks!
 * infinity might call it a day too.
<infinity> skaet: 'Night.
 * slangasek waves to infinity 
<skaet> infinity, have a good flight, see you in london!
<skaet> slangasek,  decision baton passes to you now.  Have fun.  :)
 * slangasek twirls it on his ear
<skaet> lol
<slangasek> pitti, cjwatson, infinity: udev uploaded to the oneiric queue; I've tested this build 20x now on the VM where I previously got the timeout 50% of the time, boots cleanly each time (no delays, no initramfs panics, no read-only rootfs).  I've also installed it on a pair of test laptops and done a couple reboots each, no problems seen there either.  So I think this is good to go in today.
<pitti> slangasek: yay
<pitti> infinity: ah, did you accpet the libimobiledevice SRU?
 * pitti sends the call for testing to the bug
<pitti> infinity: (no harm done, I just thought we'd wait with proposed stuff until Monday)
<slangasek> pitti: what's the right place to upstream this udev patch?
<pitti> slangasek: mailing linux-hotplug@vger.kernel.org (you don't need to be subscribed, I think)
<slangasek> pitti: ok, thanks
<pitti> will review from queue once it's diffified
<pitti> i386 kernel working fine, testing amd64 now
 * slangasek tries to remember how to get git to send a patch by email instead of sending embarrassment
<pitti> slangasek: git format-patch origin
<slangasek> that's the easy part
<pitti> this will produce a 0001-blabla.patch, which you just attach to a mail
<slangasek> well, ok, if that's the local convention, that's easy enough :)
<pitti> slangasek: I've never tried sending it directly from git
<pitti> that seems to work everywhere (attach .patch to bugzilla or to mail)
<pitti> amd64 kernel also works; copying oneiric-proposed to oneiric
<pitti> ogasawara: ^ FYI
<slangasek> pitti: oh, they're already copied to oneiric
<pitti> oh, ok
<slangasek> I haven't deleted from -proposed yet though
<pitti> yesterday I earned the job to test them and copy them, but so much the better
<pitti> anyway, I can start the weekend without worrying about these kernels now :)
<pitti> http://people.canonical.com/~ubuntu-archive/testing/oneiric_probs.html looks as good as we can get it, I htink
<pitti> and http://people.canonical.com/~ubuntu-archive/testing/oneiric_outdate.html clean as well -- SHIP IT!
<pitti> http://china-images.ubuntu.com/oneiric/daily-live/20111008/ -- yippie! not oversized any more
 * pitti loves when things all come together
<pitti> I'll accept firefox into -proposed, the earlier, the better
<pitti> slangasek: oneiric-proposed kernel cleaned up
<pitti> slangasek: great work on udev! that must have kept you up all night!
<slangasek> pitti: well, I'm still trying to get to bed before dawn ;)
<cjwatson> Oh botheration.
<cjwatson> Around beta 1, I went to the effort to get an account on a system to test a fix for bug 774089, and I completely forgot to upload it
<ubot4> Launchpad bug 774089 in parted (Ubuntu) (and 6 other projects) "Booting fails 3 times, works every fourth time after new install of Natty Narwhal amd64 on Macbook Pro (affects: 22) (heat: 135)" [Critical,Triaged] https://launchpad.net/bugs/774089
<cjwatson> However the last few comments on that bug suggest that things are now working due to kernel changes
<cjwatson> So maybe I should leave it alone ...
<infinity> pitti: Wasn't I, I wasn't home.
<pitti> lamont: temporarily made allspice and crested help out with the lucid/natty langpack builds (i386)
<cjwatson> ^- hopefully final d-i of the cycle to pick up new linux and netcfg
<pitti> have a nice weekend everyone!
<pitti> I'll accept base-files/apport/kerneloops tomorrow morning, and kick off a full set of images tomorrow evening
<infinity> pitti: I thought we were doing that Sunday?
<infinity> pitti: Oh, I guess "tomorrow" is Sunday for you.
<infinity> pitti: Don't mind me, it's still "Friday" for me, despite it being 6am. :P
<cjwatson> infinity: don't worry, we'll have you on the one true timezone next week
<infinity> cjwatson: I'm always happier in that timezone anyway.
<infinity> I should probably just accept that it's where I belong and move.
<cjwatson> joiiiiiiiin uuussssss
<Daviey> Hmm, can i protest this?
<infinity> Nope.
<lamont> infinity: if you move to europe, you'll just wind up running on an apac TZ instead.
<infinity> lamont: Pessimist.
<nigelb> I thought infinity was immune to time-zones.
<lamont> dude.  I remember australia
<infinity> lamont: I never slept at all in Australia.
<mdeslaur> since we no longer have a timezone database, I think the point will be moot soon anyway
<infinity> (which seems to be happening this week too...)
<lamont> mdeslaur: where did we put the database>?
<lamont> remember.  sleep is important.  always remember where you put it.
<Daviey> probably fallen behind the fridge.
<infinity> lamont: http://blog.joda.org/2011/10/today-time-zone-database-was-closed.html
 * lamont afk
<ogra_> hmm, there is an issue with the qatracker, for ac100 it points to an img.gz file, we dont build img.gz for ac100, only tar.gz and .bootimg
<stgraber> ogra_: can you give me the path of a valid one and the invalid path? I'll go update the tracker
<infinity> stgraber: Valid path is two files, can the tracker do that?
<infinity> stgraber: http://cdimage.ubuntu.com/daily-preinstalled/20111007/oneiric-preinstalled-desktop-armel+ac100.tar.gz
<infinity> stgraber: http://cdimage.ubuntu.com/daily-preinstalled/20111007/oneiric-preinstalled-desktop-armel+ac100.bootimg
<infinity> stgraber: Those two files.
<stgraber> ok, I'll have a look soonish
<infinity> stgraber: If it can only deal with one, make it the tar.gz
<stgraber> ok, it can only have one, so I'll make it point to the .tar.gz
<infinity> Kay.
<stgraber> infinity, ogra_: did that do the trick?
<infinity> stgraber: Looks better.  Why do only some images have hashes?
<infinity> (I'm using http://iso.qa.ubuntu.com/qatracker/dllist)
<infinity> doko_: Maybe I'm missing something here, but how does editing a manpage fix symbol alignment issues?
<infinity> doko_: http://launchpadlibrarian.net/82305059/binutils_2.21.53.20110810-0ubuntu3_2.21.53.20110810-0ubuntu4.diff.gz
<stgraber> infinity: because of some weird and buggy magic that's hardcoded in the php code ;)
<stgraber> infinity: I'm working on rewritting all that
<ogra_> stgraber, thanks looks good
<ScottK> Looks like it'd be good to update python-defaults.  There's a dh_python2 bug that will cause some packages to misbuild.  It doesn't affect anything currently in the archive, but it'd be great to avoid trouble with backports.
<ScottK> Uploaded.
<ScottK> Most of the diff is tests.
<dylan-m> Hi there! So, I have one change for the Ubuntu install slideshow (a new picture + updated translations), and I'm wondering if there's any way to get that in the final ISO without causing trouble. Just a little thing, so no problem if there isn't a way. (Though it _would_ be awesome!)
 * dylan-m hides away sheepishly
<infinity> dylan-m: Upload it and I'll look at the diff.  If it looks obviously safe, sure.
<dylan-m> infinity: Great, thanks! Searching my memory, (since this is a package that's only there for the installer) I guess it'll happen in the odd chance the image is rebuilt, and otherwise not. Is that correct?
<infinity> Correct, but the images are being rebuilt.
<ScottK> Thanks.
<ScottK> (for whoever accepted python-defaults)
<infinity> ScottK: Was me.
<infinity> ScottK: That probably could have been an SRU, but whatever.
<ScottK> Could have, but it seems better not to have to mess with stuff like that after release.
 * lamont has stabbed rossm and thrown it back into the pool
 * infinity is amused by update-manager-0.152.23/AutoUpgradeTester/profile/eduubuntu/DistUpgrade.cfg (note the typo) and wonders if that's referenced that way elsewhere in the code, or if it doesn't actually work.
<infinity> And, of course, mvo isn't online to ask him about it. :P
<jibel> infinity, it actually doesn't work http://people.canonical.com/~mvo/automatic-upgrade-testing/current/
<jibel> IOError: Can't find profile '/home/mvo/update-manager/main/AutoUpgradeTester/profile/edubuntu/DistUpgrade.cfg' (/home/mvo/update-manager/main/AutoUpgradeTester)
<infinity> jibel: Special.  Rejecting, then.
<infinity> Maybe that'll make him show up on IRC to talk. ;)
<slangasek> mdeslaur: pff, that merely means we no longer have an *upstream* for the timezone database :)
<mdeslaur> slangasek: but, I've already convinced my wife to switch all our clocks to UTC!
<slangasek> haha
<slangasek> pitti: hmm, my mail to linux-hotplug@vger.kernel.org doesn't seem to have reached the mail archive yet
 * slangasek chuckles at his outbound mail logs.  Well, it was accepted... 250 2.7.1 Looks like Linux source DIFF email.
<GrueMaster> ScottK: Just an FYI - kubuntu on omap4, no visible issues on install or login.  I don't have time to go through and do a full app sweep, but it looks a lot better than releases past.
<ScottK> GrueMaster: Great news.  Thanks.
<GrueMaster> Two more platforms and arm is done.
<slangasek> ScottK: can you comment on how the kubuntu ISO's boot sequence is put together? I have bug #870832 reported on kubuntu specifically; wonder if there's a difference here in the display manager handling that causes a race not seen elsewhere
<ubot4> Launchpad bug 870832 in plymouth (Ubuntu) "Plymouth not shown during live disk shutdown. (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/870832
<slangasek> OTOH, broder was commenting on something like this earlier...
 * ScottK looks
<ScottK> slangasek: I have seen that happen a few times.
<stgraber> slangasek: Got an e-mail from mvo. The fix for edubuntu upgrade will be a new update-manager upload to Oneiric (so that it gets into the .tar.gz for natty).
<stgraber> slangasek: the fix is just a one line change in the code adding edubuntu-desktop to the list of package to ensure are always upgraded
<stgraber> oh, just read backog ;)
<stgraber> apparently it already went through
<ScottK> I never saw it consistently, but I don't know of anything Kubuntu specific that would cause it.  The kdm upstart job is as close a copy to what's in gdm as I could manage.
<ScottK> I've NFK what causes it as it wasn't consistent.
<stgraber> infinity: did you see anything else wrong in mvo's upload?
<stgraber> infinity: if not, I'll just re-upload with that fixed
<slangasek> ScottK: understood.  I'll boot up a VM here and see what I can figure out; I don't expect we'll try to fix it for oneiric, but at least we can have it triaged
<slangasek> stgraber: ah, already in then, good :)
<stgraber> slangasek: well, got rejected by infinity ;)
<slangasek> ah right
<infinity> stgraber: Nothing else obviously wrong.
<stgraber> infinity: ok, expect it in the queue soonish then :)
<stgraber> trying to figure out how to build the source package of update-manager... having some problem getting the pre-build stuff to pass...
<infinity> Lacking build-deps, I assume?
<stgraber> I'm running in a clean LXC container with all the build-deps installed ;)
<slangasek> it's not the build-deps
<slangasek> it's the how-to-generate-the-source deps
<slangasek> for which we have no good way to provide a manifest, unfortunately
<slangasek> (and no, I don't know what's in that list in the update-manager case... I just know this problem affects everything mvo maintains :)
<stgraber> I have an extra 30 minutes I can spend on that before going to the airport, if I can't get it to work, I'll text mvo asking for him to grab the branch and upload ;)
<stgraber> oh, I think I got it
<ScottK> slangasek: Sounds almost manoj like.
<slangasek> heh
<stgraber> it seems to be a case where "bzr bd -S" doesn't do the same thing as "debuild -S -sa" with the former working ;)
<slangasek> oh, well, yes, that's the generate-the-source-package hook part... debuild -S assumes you already have a full source package tree, which you don't
<slangasek> generated bits :)
<Daviey> bug 865701 , might want added to the release notes?
<ubot4> Launchpad bug 865701 in unity (Ubuntu) "Maximized windows can be accidentally closed from wrong monitor. (affects: 3) (heat: 18)" [Undecided,Confirmed] https://launchpad.net/bugs/865701
<stgraber> ok, I "think" I got it to work ;) debdiff between mvo's upload and mine looks good at least. Should be in the queue soonish
<slangasek> Daviey: please open a task on the ubuntu-release-notes project for this
<slangasek> I'm not sure that's release-notable though because it's difficult to explain in a way that will make sense to users... I think it's more important to get the DX team to fix it ASAP in SRU
<Daviey> slangasek: yeah, i wasn't certain.
<slangasek> Daviey: well, it's easy enough to open a task on u-r-n, and we can always close 'invalid' afterwards :)
<Daviey> ack
<infinity> stgraber: Accepted.
<stgraber> infinity: thanks!
<slangasek> ScottK: when you've seen bug #870832, do you know if it's always been after choosing the *install* option (i.e., never after "Try $OS")?
<ubot4> Launchpad bug 870832 in plymouth (Ubuntu) "Plymouth not shown during live disk shutdown. (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/870832
<charlie-tca> smoketested Xubuntu images; they do install and they did not crash on my hardware
<stgraber> that's usually a good start
<slangasek> heh, aren't those the alpha milestone criteria? :-P
<slangasek> hopefully it does more than that ;)
<ScottK> slangasek: I don't.
<slangasek> ScottK: ok.  my current hypothesis is that this relates to the fact that kdm (or lightdm) is never fully running when you choose "install", so the confusing sequence of shutdown events somehow causes plymouth to be started while an X server is still running; but this is so far only a hypothesis
<slangasek> if that's what's happening, it's probably a bug in ubiquity
<ScottK> OK.  So if it happens from a full live session then that blows your theory, right?
<charlie-tca> new images spinning tomorrow, you want all the tests done in detail today and tomorrow?
<ScottK> (even if an install was done from that session)
<slangasek> ScottK: yes
<ScottK> OK.  I'll keep an eye out for it if I get time for ISO testing this week (bad week for a release $WORK wise for me).
<slangasek> charlie-tca: I'm not asking for any extra testing of the current images per se, just being drily amused on a Saturday afternoon :)
<cjwatson> slangasek: hm, doesn't plymouth start on stopped ubiquity-dm or some such as well on shutdown?
<cjwatson> (if not there may be a reason mind ...)
<infinity> cjwatson: It starts on desktop-shutdown
<infinity> cjwatson: Does ubiquity-dm emit that?
<cjwatson> it may not; that's new IIRC
<infinity> It is.
<cjwatson> can't check right now
<infinity> You can blame vorlon for missing one DM. :P
<cjwatson> it would have to be careful about it, as there are situations where you can transition from ubiquity-dm to a real dm
<ScottK> Can't blame vorlon for any Ubuntu problems.
<infinity> cjwatson: Indeed.
<infinity> cjwatson: And no, it doesn't emit any such thing.  But yeah, it would have to be careful about that case.
 * cjwatson would look if he weren't supervising a madly bouncing toddler
 * infinity goes to get ready to catch his flight to the land of promised timezone parity.
<infinity> cjwatson: Velcro walls, velcro clothes, done.
<cjwatson> It might be worth a shot.
<cjwatson> Safe travels
<infinity> cjwatson: Is there a runlevel switch when ubiquit-dm transitions to lightdm?
<cjwatson> No
<infinity> Then this, stolen from the lightdm init should work:
<infinity> post-stop script
<infinity>  if [ "$UPSTART_STOP_EVENTS" = runlevel ]; then
<infinity>   initctl emit desktop-shutdown
<infinity>  fi
<infinity> end script
<cjwatson> hm, ok, that makes sense
<slangasek> infinity, cjwatson: I didn't miss it, I only converted the DMs that were already listed as causing plymouth to start to use the new event
<slangasek> cjwatson: but if it were just "ubiquity-dm doesn't emit it", then plymouth wouldn't start *at all* on shutdown; whereas the observed behavior is that plymouth starts up and something takes the console into text mode underneath it
<charlie-tca> slangasek: yeah, I stepped out to bang my head on the wall a couple of times. humor is back now
<slangasek> charlie-tca: :)
<slangasek> and since ubiquity-dm is also 'stop on ... stopping kdm', ubiquity-dm with its X session should be stopped *first*, before kdm's post-stop script triggers the event
<cjwatson> it's start on starting kdm too; maybe kdm is starting up afterwards, briefly?
<cjwatson> not to the point of starting the dm, but it might hit the job ...
<cjwatson> hm, no, this is incoherent
<slangasek> well, I also haven't ruled out there being an upstart bug involved
<slangasek> anyway, this is all weekend tinkering, not something I think we should try to fix for release
<ScottK> python-pypm in queue will fix package installability.  It's a quick build, so not a bad one to keep in queue for stimulating the publisher.
 * ScottK larts tumbleweed for not syncing it after he fixed it in Debian.
<tumbleweed> oops
<tumbleweed> btw, I see people complaining about my devscripts change. Was that not how we normally handled things (I thnaven't checked yet) bug 870618
<ubot4> Launchpad bug 870618 in devscripts (Ubuntu) "debchange: "precise" is the default distribution in oneiric (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/870618
<ScottK> Usually the default distro is changed after release, but I think it's fine.
<ScottK> Saves me having to change it myself.
<Laney> indeed, I'd wontfix that report. It's not as if we'll be seeing many uploads from now to release.
<tumbleweed> I get the feeling the reporter is expecting dhc on oneiric to default to oneiric
<tumbleweed> I only run development Ubuntu's so I'm not used to knowing if that's the usual behavior
<stgraber> I guess one could argue that most of our users are more likely to upload to a PPA than to the archive, having the current release set by dch would then make more sense
<slangasek> tumbleweed: historically we have not changed the dch target before release, no
<slangasek> it doesn't really matter either way; 'oneiric' will be a wrong target within 5 days, and 'precise' will be wrong for over half the support lifetime of oneiric
<slangasek> ... though I guess this has a negative impact on ppa usage
<slangasek> tumbleweed: ^^ on that basis, I think it actually would be better to revert this... and for precise perhaps we should plan to come up with a way to pull a default target from the user environment instead of from the commandline?
<tumbleweed> slangasek: yeah, the PPA usage arguement is sound
<slangasek> devscripts seems to be on kubuntu DVD and on server
<slangasek> tumbleweed: if you intend to upload to revert this, please do so today to get it on the ISOs, or else send it to -proposed
<tumbleweed> I'll need a sponsored upload (not a core dev, but happy to prepare that now)
<stgraber> tumbleweed: I'm happy to sponsor if you have it ready in the next 20 minutes
<stgraber> (waiting for my flight)
<tumbleweed> stgraber: thanks: http://paste.debian.net/135105/
<tumbleweed> eep, forgot to close thebug, anyway...
<stgraber> tumbleweed: I'll update the changelog
<stgraber> tumbleweed: uploaded
<tumbleweed> stgraber: ta
 * ScottK considers "makes PPA uploads to the current release harder" a feature, not a bug, but whatever.
<slangasek> whyso?
<ScottK> I think people who don't know what they are doing slamming crap into PPAs is a source of trouble.
<ScottK> I'm personally sick and tired of hunting down bugs that turn out to be due to bad PPA uploads.
<ScottK> Not that it happens a lot, but it's frequent enough on just the few packages I really triage on that I think it's a large problem.
<stgraber> well, if they upload to the dev release, they'll then most likely re-upload once they understand what they did wrong
 * tumbleweed hears a lot of flak from good developers who find ppas hard to use
<stgraber> and so will use twice the builder time
<ScottK> That and I think that PPAs have been generally harmful for developer recruitment (it's in a PPA, so why should I bother <-- heard that more than once)
<ScottK> Reviewing the diff anyway.
<tumbleweed> but yes, I also see lots of people braeking their installs (esp at upgrades) by using hundreds of dodgy PPAs
<ScottK> Accepted.
<ScottK> So while I find PPAs to be a very valuable development tool, I think that there is a lot of negatives that go with it.
<ScottK> On balance, I'm not convinced we're better off.
<stgraber> I heard quite a few people saying that having some kind of "official" PPAs for some specific projects or team and showing a big scary warning when adding any other PPA could help with that
<stgraber> though it doesn't help solve the "it's in a PPA, so why should I bother" part
<ScottK> "Official" PPAs are a slippery slope that IMO we shouldn't start down.
<stgraber> I can see why a project (as in upstream project) would like that though. I certainly agree that we don't want to have "official" Ubuntu PPAs as we already have way enough different ways of getting something to our users
<mdeslaur> ScottK: I probably shouldn't say this, but I keep stuff I wrote in a PPA, because I only see disadvantages in getting it into the archive
<ScottK> mdeslaur: I believe you.
<mdeslaur> and I do agree that people pulling random stuff out of PPAs is annoying also, especially when it conflicts with stuff that _is_ in the archive
<slangasek> yeah, I've recently seen an awful lot of non-Ubuntu "lib32fooN" packages on people's systems conflicting with ia32-libs... I suspect ppas are to blame
<slangasek> apport should probably be made smarter and refuse to file bugs in those cases
 * slangasek turns that "should" into a bug report
<tumbleweed> otoh, if people want to break their systems, I'd rather they did it with a ppa than building the world from source
<mdeslaur> tumbleweed: true
<slangasek> bug #871030 filed
<ubot4> Launchpad bug 871030 in apport (Ubuntu) "apport should disallow filing bugs for package install failures when they conflict with non-Ubuntu packages (affects: 1) (heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/871030
<mdeslaur> I wish there was a bigger difference between patform and applications
<mdeslaur> but that's a whole other discussion :)
<ScottK> Having been stuck doing work on an OS recently where that's the case (BSD, forget which one), that has it's own set of problems.  I'm convinced now it's different, not better.
<mdeslaur> ScottK: this is a UDS-beer discussion :)
<ScottK> Sure thing.
<ScottK> Sorry I won't be able to make it this time.
<mdeslaur> ScottK: what? you won't be at UDS? Seriously?
<ScottK> Seriously.
<mdeslaur> ScottK: if you're not there, we should cancel it.
<mdeslaur> ok, enough off-topic rambling from me in here
#ubuntu-release 2011-10-09
<stgraber> yeah, got a hotel room and even reasonably fast and stable wireless (at least for the last 10 minutes)!
<Laney> you are enlondoned?
<stgraber> yep
<tumbleweed> keepass2 sync diff on bug 871265
<ubot4> Launchpad bug 871265 in keepass2 (Ubuntu) "Sync keepass2 2.16+dfsg-2 (universe) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,Fix released] https://launchpad.net/bugs/871265
<charlie-tca> Are we spinning new images today?
<infinity> pitti: How goes?
<stgraber> hey infinity! had a good trip?
<infinity> stgraber: Wasn't too bad.
<infinity> stgraber: You?
<stgraber> everything was on time and it was a direct flight, so pretty good too
<pitti> slangasek: yes, and patch already went upstream
<pitti> hey infinity, how are you?
<infinity> pitti: Tired. ;)
<infinity> pitti: Just checking in to see if anything's on fire.
<pitti> we got green light on the firefox testing
<pitti> I'm pondering moving it to oneiric instead of oneiric-updates
<pitti> so that the alternates will DTRT when you use them for upgrading
<pitti> and once that's published, kick off the images
<pitti> apport/kerneloops/base-files went in this morning
<stgraber> I'm testing the update-manager upload from yesterday (for Edubuntu), should have the result in an hour or so (hotel internet...)
<pitti> firefox done
<chrisccoulson> hi pitti
<chrisccoulson> how are you?
<pitti> hey chrisccoulson
<pitti> pretty well, thanks!
<chrisccoulson> good :)
<pitti> chrisccoulson: many thanks for the firefox upload, so we got this into final
<chrisccoulson> pitti, sure, no problem. i'm glad that's fixed now
<chrisccoulson> that's been a nightmare. perhaps next time i shouldn't book a vacation in the last 2 weeks of the cycle ;)
<pitti> heh, perhaps better not
<pitti> chrisccoulson: I hope you still had at least some time to enjoy it
<chrisccoulson> pitti - yeah, it was good thanks
<chrisccoulson> i can't believe how hard i found it to wind down though
<cjwatson> occupational hazard, I think ...
<chrisccoulson> heh
<cjwatson> I'm sure it was easier to wind down before we had smartphones
<Daviey> cjwatson: lack of smartphones just means you end up on a family holiday, parked outside mcdonalds - leaching wifi.
<chrisccoulson> heh
<chrisccoulson> actually, my smartphone wasn't much use, as the 3G coverage was terrible where we stayed
<chrisccoulson> but i made the mistake of taking my laptop, and our cottage had free wifi
<chrisccoulson> which was unexpected ;)
<Daviey> bug 870121, is concerning me - there seems to be inconsistent values on all flavours (not just cloud) .. requires more investigation.
<ubot4> Launchpad bug 870121 in ubuntu "APT::Periodic::Update-Package-Lists not set in cloud images (affects: 1) (heat: 6)" [High,Confirmed] https://launchpad.net/bugs/870121
<pitti> slangasek, cjwatson, infinity: I'd set off the images now, unless you have another blocker?
<infinity> I've got nothing, but I've been out of touch while traveling.
<pitti> kernel is in, firefox is in, NBS/component-mismatches/oneiric_outdate all clean, oneiric_probs as good as it's going to be
<infinity> Yeah, I'm at a "probably just have to live with my bugs" point.
<infinity> Until we find something dire tomorrow. ;)
<pitti> the world is rebuilding
<pitti> will post the lot tomorrow morning
<pitti> so long, enjoy your beer in London!
 * pitti food/evening/night &
<infinity> Did you just background yourself?
<tumbleweed> is it still possible to request removals from universe?
<cjwatson> tumbleweed: yeah, we still have a little leeway
<cjwatson> pitti: there's auto-ISO-posting code in cdimage now, though you have to set some environment variable or other
<tumbleweed> cjwatson: ah, I was thinking of bug 815922, (libavg was removed in Debian) but I see it has an ubuntu-only redpend
<ubot4> Launchpad bug 815922 in libavg (Ubuntu) "libavg segfaults on startup (affects: 2) (heat: 14)" [Undecided,Confirmed] https://launchpad.net/bugs/815922
<SpamapS> I know you guys are in the home stretch. It would be quite helpful if someone can take a look at bug 871375 and approve the upload ASAP. Thanks!
<ubot4> Launchpad bug 871375 in juju (Ubuntu) "[FFe] update juju to upstream revision 398 (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/871375
<slangasek> pitti: yay, my first patch in udev :)
<slangasek> pitti: no blockers here, +1 for kicking off the builds
<SpamapS> slangasek: is this by any chance the weird race some people have been seeing in udev?
<slangasek> SpamapS: one of them.
<slangasek> SpamapS: there's still an LVM-specific issue, and the netbooting issue hasn't been triaged to the point yet that I can say whether it's the same (waiting for feedback on the bug).
<SpamapS> slangasek: we experienced udev issues with and without LVM this past week.. I think adam_g was involved in some of the triage. I'm glad at least some progress has been made.
<slangasek> yes, adam_g's bug was the LVM one... that bug still exists, although with the latest comments on the bug it seems that it now manifests in a friendlier way (60s delay at boot, instead of failed boot)
<stgraber> wow, my Edubuntu dist upgrade finally completed, took a while but at least everything seems to have upgraded fine!
<slangasek> infinity, pitti: do you have any idea what's happening in bug #871083?  The manpages are being compressed with the correct options to be idempotent (-9nf), the uncompressed content is identical, and the compressed files are the same size; yet the .gz files don't match between amd64 and i386
<ubot4> Launchpad bug 871083 in pam (Ubuntu) "package libpam-modules 1.1.3-2ubuntu1 failed to install/upgrade: ErrorMessage: './usr/share/man/man8/pam_shells.8.gz' is different from the same file on the system (affects: 2) (dups: 1) (heat: 14)" [Medium,Triaged] https://launchpad.net/bugs/871083
 * slangasek pushes a no-change rebuild to -proposed for this
<cjwatson> Bug 572128 has passed QA, and hopefully will be deployed to cocoplum tomorrow morning
<ubot4> Launchpad bug 572128 in debmirror (Ubuntu) (and 1 other project) "Ubuntu Archive translations are missing Index metadata file (affects: 3) (heat: 18)" [Undecided,Confirmed] https://launchpad.net/bugs/572128
<cjwatson> squeaking in just in time for oneiric
 * cjwatson -> bed
<slangasek> cjwatson: 'night!
<skaet> slangasek,  doko__;   I've rejected the binutils patch for now, since it seems it could have a pretty broad impact, and hence regression potential exists.   Since we've been living with this since the start of the year, it isn't too urgent.   Would rather this be deployed in precise,  and then discuss at UDS whether it makes sense to add it to updates for oneiric,  after its had some exposure and wider testing.
<slangasek> skaet: which binutils patch was this?  I wasn't aware that any patches were still under consideration for binutils in oneiric
<skaet> https://bugs.launchpad.net/ubuntu/+source/openmpi/+bug/697229
<ubot4> Launchpad bug 697229 in openmpi (Debian) (and 7 other projects) "openmpi link failure with ld --as-needed (affects: 2) (dups: 1) (heat: 18)" [Unknown,New]
<skaet> spotted it in the oneiric queue for proposed this evening when I just checked on things.
<skaet> wanted it was enabling several more architectures,  and may well be safe and fine,  but seemed to have a potential for regressions as well.
<skaet> hmm... that last sentence didn't quite emerge as planned. ;p
<slangasek> skaet: ok, well according to pitti the uploaded package seemed to not do the intended anyway
<slangasek> but I think it's clear there was no intention to include this in the release, only as an SRU
<skaet> slangasek,  yup, saw that, but want to make sure its effects are well understood, discussed and worth the risk before we add it in.
<Daviey> Isn't that an SRU team issue?
<skaet> Daviey,  I'm on the SRU team as well.
<Daviey> aye, but i mean - is it something that needs UDS consideration, rather than just handling at team level?
<Daviey> *shrug*
<hggdh> slangasek: please see bug 871528 -- just noticed it on a netbook, sounds related to the udev bugs (but the delay here is ~ 100 seconds?)
<ubot4> Launchpad bug 871528 in udev (Ubuntu) "slow boot, udev-related? (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/871528
<slangasek> hggdh: why do you attribute this to udev?
<slangasek> there's no 100s delay anywhere in udev
<Daviey> another slow boot, bug 870214
<ubot4> Launchpad bug 870214 in ubuntu "iSCSI root installation creates manual eth0 configuration + long boot (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/870214
#ubuntu-release 2012-10-01
<ScottK> Riddell: ^^^^ stgraber's question.
<ScottK> I don't know.
<cjwatson> I could use somebody else paying some attention to the upload queue.  I think a majority of the stuff there is mine now.
<Laney> looking
<Laney> rejecting django-dajax, asking for FFe
<cjwatson> Laney: excellent, thanks
<Laney> left the ones that give me Fear
<smartboyhw> The fear of the LORD is the beginning from wisdom (Proverbs 6:9)----fits Laney:P
<stgraber> ScottK, Riddell, cjwatson: I got a reply from dpm telling me that the Kubuntu folks have no real control on what's getting in those langpacks and what's generating them. David poked pitti about it, so hopefully the few I've discovered to be broken will soon be fixed.
<Riddell> stgraber: hmm, I think it might be my fault but it hasn't reached the top of my todo list yet
<knome> hey skaet!
<knome> skaet, we were wondering what does "What was done engineering wise?" really refer to?
 * smartboyhw too
<knome> skaet, new packages? new releases? changed default settings? any uploads done?
<stgraber> knome: any change affecting your product that you think is relevant
<knome> relevant to who/what?
<stgraber> knome: can be new version of a package, artwork change, settings change, ...
<knome> if we change our appearance, i know that's relevant to the docs team, but is that something to report to the release team?
<knome> or is the main idea of this section to gather the release notes?
<knome> if that is it, can we rethink wording, because i think that's the sloppiest question ever :)
 * smartboyhw thinks this is not the same thing as release notes
<knome> i think skaet used to use something (this?) for creating release notes at some point
<stgraber> that section is meant to keep all the other teams up to date on what you've been doing. We don't use that for the techoverview/release notes as otherwise they'd be horribly long :)
<knome> and no, of course it's not === release notes
<stgraber> IIRC this cycle Kate is parsing the blueprint to extract the tech overview entries
<knome> stgraber, isn't that kind of duplicate of the "summary of bugs worked on by team"?
<smartboyhw> Hmm..blueprints:P
<knome> stgraber, saying kind of, because not everything is actually a bug...
<stgraber> knome: yeah, if all you've been doing is bugfixing, it'd be quite redundant, then just put a single like "Been working on bugs, see below" :)
<knome> stgraber, right.
<knome> stgraber, i don't think creating a new wallpaper is "engineering"
<knome> stgraber, so the title is still kind of... lousy
 * smartboyhw thinks "List what have you added/deleted" is better:P
<knome> well, no, not that either
<knome> "Changes to images done by team" or sth
<cjwatson> *shrug*
<cjwatson> s/engineering/development/ only with better wording
<tumbleweed> cjwatson: when you have a minute: https://code.launchpad.net/~stefanor/ubuntu-archive-tools/edit-packagesets/+merge/124639
<tumbleweed> (it's landed in LP production)
<knome> cjwatson, yep, but it's still a bad title.. ;) good to have sorted out what you are after with it though
<stgraber> tumbleweed: yay!
<cjwatson> tumbleweed: merged, thanks
<cjwatson> knome: it's not necessarily meant to be constrained to just changes to images, so yours is wrong too :)
<cjwatson> for example foundations often lists significant infrastructure work there
<smartboyhw> cjwatson, a question from me
<smartboyhw> === What's about to land that might impact the other teams and release as a whole? ===
<smartboyhw> Er what does this mean?
<stgraber> "What did your team do this past week" might be generic enough ;)
<smartboyhw> stgraber, +1
<cjwatson> smartboyhw: Replace "impact" with "affect" and it might be more understandable
<cjwatson> ("impact" for "affect" is ghastly managementese)
<knome> cjwatson, yeah, that's true. stgraber, yes, that might be good, but then it could have the bugs listed under it too.
 * smartboyhw still doesn't understand sorry
<cjwatson> smartboyhw: It's unlikely it will be relevant to you
<cjwatson> Since changes to Ubuntu Studio are not likely to affect any other team
<smartboyhw> cjwatson, OK thanks
<knome> smartboyhw, if xubuntu uploads a new version of xfce, it's probably going to mean ubuntu studio needs to think about that too
<smartboyhw> knome OK.
<knome> smartboyhw, or, to say with the words in the mail, it might affect US too
<skaet> knome,  stgraber, smartboyhw - problem with my plan is that folks don't update their blueprints :P   so that the automated extraction will work.
<knome> skaet, hey! don't point at us :)
 * smartboyhw is a new guy on this so don't point at him:P
<skaet> knome,  no fingers,  its a pervasive problem from the walking through of them I did after beta 11
<smartboyhw> I mean on the release mail thing:P
<knome> skaet, we were just thinking that the "bugs worked on by the team" looks really similar to "open work items" :)
<skaet> beta 1 rather.
<knome> skaet, well, i'd say our blueprints are in a rather good shape :) or not in good - but current
<skaet> and yes,  I use the data from the weeklies to generate the first pass of the release notes,  and then rely on the team leads to find things that aren't explained overlooked.  :)
<smartboyhw> skaet, knome: Ours isn't in good shape (mainly all scott-work's items:P)
<skaet> yup knome,  Xubuntu rocks at keeping their status up to date.  :)
<skaet> smartboyhw,  if its clear that scott-work won't be able to get to things now for this cycle,  feel free to go in and mark them postponed.
<smartboyhw> OK
<skaet> that will get the status tracked more accurately,  and make it explicit rather than everyone guessing.  :)
<smartboyhw> :P
<knome> skaet, heh, thanks. i think we really benefit from being up-to-date too
 * skaet makes a note to change the template for the weekly meeting to say "affect" rather than "impact"  ;)
<smartboyhw> lol
<xnox> skaet: effect & affect are confusing =) next week you might get *drumroll* in that section ;-)
<cjwatson> effect => noun, affect => verb - except in rare cases where they're not :-)
<cjwatson> (you might effect a change, or say that somebody with a particular psychological problem has a lack of affect - but those are rare uses)
<stgraber> z3c.formui <- new upstream release, only listed change was marked by upstream as a feature, didn't have a FFe
<xnox> cjwatson: memorized the regular way long time ago, never knew there was a flip side to these terms. Thanks.
 * skaet makes  a note to defer to cjwatson on all future grammar issues... ;-)
<smartboyhw> more lol:P
 * smartboyhw wonders can someone help to refresh the status.ubuntu.com page for Ubuntu Studio for a bit......
<smartboyhw> skaet, can I PM?
<Laney> anyone want to look at the microcode FFes?
<smartboyhw> better version: skaet can I PM (private message) you?
<stgraber> ok, I think that's enough queue reviews for me, let's try to actually fix some stuff now
<skaet> smartboyhw,  yes.   just juggling some things right now, so please be patient if my response time isn't as immediate as I'd like.
<smartboyhw> OK
<cjwatson> ^- first batch of mass rebuild to attempt to get armel/main into sync with the default compiler flags
<stgraber> cjwatson: I'll take a look before going for lunch, those should be quick to review anyway ;)
<cjwatson> If I don't manage to finish the rebuild before final freeze, not the end of the world
<skaet> ack
<smartboyhw> ?
<stgraber> cjwatson: accepted them all
<stgraber> or rather, tried to :) let's use the command line instead...
<cjwatson> Yeah, the web UI may have trouble accepting lots in a single request
<cjwatson> It still has to check permissions even if bugs are closed asynchronously now
<Laney> debfx: I'm going to reject that qt4-x11 until we see if the give-backs work
<Laney> I've a solution that doesn't require disabling QtWebkit on arm.
<cjwatson> Laney: abiword/armhf still killed its builder today
<Laney> yeah, saw
<cjwatson> So I think it may need more work
<Laney> feel free to just copy it out of canonical-arm-dev/ppa if you don't think it'll work
<stgraber> alright, I uploaded a new ubiquity-slideshow-ubuntu. It'd be good to get that one in the archive ASAP to give as much time as possible to the translators to update for the new copy.
<stgraber> the diff will likely be a bit scary, but ignoring po/ in the review should bring it down to something much more reasonable (basically bug 1056456 and bug 1054346)
<ubot2> Launchpad bug 1056456 in ubiquity-slideshow-ubuntu "[UIFe] New copy for Ubuntu installer slideshow" [Undecided,Triaged] https://launchpad.net/bugs/1056456
<ubot2> Launchpad bug 1054346 in ubiquity-slideshow-ubuntu "welcome.jpg shows a pangolin" [High,Triaged] https://launchpad.net/bugs/1054346
<debfx> Laney: what has changed that you think it'll build this time?
<Laney> either a launchpad fix to the timeouts (which we suspect doesn't work ATM) or building with -gstabs instead of -g
<Laney> stgraber: I don't see any change to the xubuntu slideshow in that diff, and the change in Slideshow.py doesn't appear documented
<cjwatson> yeah, I think that either the production-configs fix hasn't been deployed yet or the LP change to use it doesn't work
<cjwatson> will find out more when wgrant gets up, I guess
<cjwatson> looks like unity perhaps ought to have gone to quantal-proposed?
<cjwatson> it's dep-wait in quantal, and unity is uninstallable in quantal-proposed which suggests that copying compiz might be a bad idea ...
<debfx> or disable debugging symbols completely since we throw away the binary anyway
<cjwatson> seb128: ^- didrocks has left but perhaps you can help?
<stgraber> Laney: hmm, I thought it was the xubuntu one I had to fix but it was the lubuntu slideshow actually
<stgraber> Laney: ubiquity-slideshow-ubuntu-64/slideshows/lubuntu/slides/03_office.html was missing a closing </p>
<stgraber> Laney: for Slideshow.py, I have no idea what the change does other than that the script still works fine and isn't actually shipped in the binary packages so I usually ignore it
<stgraber> Laney: commit message says "Slideshow.py: Fixed _find_available_locale looking in wrong place for extra slides (LP: #1046511)."
<stgraber> though that was on 5th of September, so should have made it in the previous upload... not sure what happened there
<stgraber> Laney: looking at the bug, that change was already manually copied over to ubiquity (where that file is actually shipped)
<xnox> didn't I merge that ?! =/
<xnox> maybe I didn't use the right branches?!
<Laney> stgraber: huh, OK, thanks
<Laney> I see the fix in lubuntu
<stgraber> xnox: the ubiquity side is good, it's just the ubiquity-slideshow-ubuntu that seems to have some out of order commits, not sure how that happened ;)
<stgraber> timestamp: Tue 2012-09-25 10:06:19 -0400
<stgraber> timestamp: Wed 2012-09-05 13:16:23 -0700
<stgraber> timestamp: Thu 2012-09-20 13:29:23 -0400
<xnox> stgraber: let's do the timewarp again!
<stgraber> see how it went back in time ;)
<xnox> anywho another release tracking bug bites to dust =)
 * skaet likes release tracking bug squashing going on.... thanks xnox.  :)
 * xnox did nothing... it's all stgraber's fault... eh... praise that is
<stgraber> :)
<skaet> :)  thanks stgraber then.  ;)
<stgraber> I'm down to just one bug assigned to me on rls-q, will have to pick some more to keep me busy this week :)
<xnox> what is the correct way to "postpone" rls-q-tracking bug? (a) in such a way that if it's fixed in r-series, it should be SRU'ed (b) in a such a way that if it's fixed later, SRU is not expected.
<skaet> I don't think we'll run out this week though,  and you'll get bored somehow  ;)
<skaet> xnox,  add an r-series task to it
<Laney> milestone quantal-updates
<Laney> or rls-q-notfixing
<Laney> wontfix?
 * Laney can't remember
<skaet> target it to quantal-updates in the milestone
<skaet> if the bug is intended to be fixed,  rls-q-notfixing, isn't really appropriate
<Laney> cjwatson: I/someone can just no-change upload unity to -proposed if you want
<Laney> why?
<Laney> what's rls-q-notfixing for then?
<skaet> if the team is not going to fix it.    Sounds like its going to be fixed,  just not in time.
<skaet> use milestones,   to indicate timescale
<Laney> hmm
<xnox> I see.
<xnox> and for (b) case, where team will fix later, but not backport to quantal?
<skaet> then mark the quantal task as WON"T FIX,  but have the R-series task open
<xnox> ok.
<skaet> rls-q-notfixing is appropriate as well
<skaet> but redundant in this case
<xnox> but add rls-r-incoming?
<skaet> if its targetted to the series,  than rls-r-incoming adds no additional information.
<skaet> so not needed
<skaet> s/series/ r-series/
<xnox> ok.
<seb128> cjwatson, sorry I was out, yes, compiz had an abi change so unity needs rebuild with it, I can reupload to quantal-proposed if you want
<cjwatson> seb128: Please
<seb128> thanks to whoever accepted unity ;-)
<cjwatson> np
<iulian> Laney: Re: microcode, I've had those on my radar. Apparently, the reporter doesn't want to supply any information at all. There are loads of new features and thus I wouldn't approve them unless I see some testing done. I suggest we nack them for quantal, even though no other package is affected by them. If somebody is willing to test the packages, then we could easily backport them.
<iulian> I'd prefer to have the packages in a working state.
<Laney> iulian: do what you think is best; I don't really know anything about it
<skaet> iulian +1
<stgraber> jdstrand: nice apparmor profile cleanup you did there with the new abstraction :)
<jdstrand> thanks!
<stgraber> skaet: I'm a bit concerned by unity-firefox-extension in the queue, it's quite clearly doing string changes without a matching UIFe
<stgraber> skaet: accepting it would very likely mean extra work for translators
<jdstrand> it was getting ridiculous-- there was gonna by 3 with identical and one with almost identical contents without it :)
<stgraber> I agree that those are grammar mistakes but we're now in the weird position where fixing them will break translations and require extra work
<stgraber> jdstrand: hehe, yeah, copy/paste is bad when you have support for includes :)
<Laney> reject, ask them to ask the translators what they think
<stgraber> Laney: done
<stgraber> kenvandine: ^
<infinity> stgraber: If they're just grammar fixed, one could manually unfuzzy the strings?  (since the translations are likely to already be correct).
<infinity> s/fixed/fixes/
<infinity> At least, I'd hope the translations didn't literally translate poor grammar. :P
<kenvandine> ok
<stgraber> infinity: yeah, but someone needs to commit to going through LP and update them all as the translations aren't bundled in the source
<infinity> stgraber: True dat.
<kenvandine> that fix was requested by the translation team
<kenvandine> i'll revert it and upload again
<stgraber> infinity: and IIRC you need some special rights to be able to do that without going through all the individual translation teams
<stgraber> kenvandine: was that dpm? I think dpm has the required rights do unfuzzy all the strings, so if he's on it, then I'll accept it
<kenvandine> it wasn't
<kenvandine> i'll revert it
<stgraber> ok
<stgraber> I'll leave a comment in the bug
<kenvandine> thx
<cjwatson> Sigh, I really must fix the bug where any private recipe build causes /builders to become private
<skaet> stgraber,   reject it
<cjwatson> SO ANNOYING
<stgraber> cjwatson: +1
<kenvandine> stgraber, ugh... one of these is a terrible spelling error
<kenvandine> promt
<skaet> stgraber,  it will be in the hold queue and we can revisit.   but there should be a UIFE for it at a minimum, and the translators should be knowing about it.   :(
<stgraber> kenvandine: yeah, I agree that those were pretty bad mistakes, so I'd strongly recommmend coordinating with dpm to see if it can be landed and fixed without requiring work from the individual translators (assuming they didn't "translate" the mistakes ;))
<kenvandine> yeah
<kenvandine> to get the other bug fixed i'll revert with a patch for now and ask them to do that
<stgraber> kenvandine: ok, sounds good
<kenvandine> stgraber, uploaded, thx
<skaet> cjwatson, slangasek - t-series (14.04) and u-series(14.10) have been created in launchpad now.
 * cjwatson does not expect to use them for a year or so :)
<stgraber> oh, looks like a few more easy reviews :)
<iulian> Thanks to cjwatson. :)
<cjwatson> I'm just sorry we didn't get round to this rebuild before freeze
<stgraber> can someone review madwimax? it's the only one in the queue I can't review (I'm the uploader)
<cjwatson> Because it's a bit of a waste of review effort really
<stgraber> cjwatson: no worries, it really only takes 2s per package to check that the version number makes sense :)
<iulian> stgraber: Looking.
<cjwatson> If it doesn't, dch -R is buggy. :-)
<cjwatson> slangasek did raise an issue of potential hardening regressions
<cjwatson> But I think what I'm going to do for that is write a script to gather build logs and feed them to blhc
<cjwatson> And compare precise/quantal
<cjwatson> That's going to be a lot easier than building them all in advance to check, or auditing in some other (presumably manual) way
<iulian> stgraber: I'll better leave that to someone else to review.
<stgraber> iulian: ok
<cjwatson> stgraber: accepted
<stgraber> cjwatson: thanks
<stgraber> kenvandine: wow, that new upload almost gave me an headache having to remember what's in the revert patch to check that it matches the translations fixes listed in the diff ;)
<stgraber> kenvandine: anyway, looks good, accepted :)
<kenvandine> stgraber, thx :)
<Laney> bah, yeah, qt4-x11 died again
<skaet> I've been doing pass through the blueprints,  finding "r" ones in the New pile.
<skaet> There is some seriously old cruft in "New" set,  ie 2007,2008, etc.  that doesn't look touched at all.
<skaet> Am thinking of marking anything older than 2 years as obsolete,  so it stops showing up on the New searches and wasting time in future.   Esp if the bluerpint only looks half baked (ie. couple of statements, abandoned).   Anyone have issues with that?
<xnox> skaet: well relevant people should get an email when you change those old blueprints..... and can reactively patch things up =)
 * xnox likes when skaet approves my draft blueprints and sets herself as "participation essential"
<skaet> xnox, true.  :)   or ignore them... but at least I don't have to look at them again this way.
<skaet> xnox, approved to be considered for r-series so it would show up on the searches at least.   ;-)   You'll still need to get slangasek approving it to be worked on... ;)
<skaet> ^ btw,  some easy accepts for rebuilding are out of the queue now.
<phillw> skaet: not sure about things, but I do get a notification each time the lubuntu tracker of stuff is done?
<skaet> phillw,  you need to subscribe to the blueprint in order to get notifications.
<phillw> skaet: Â [Blueprint lubuntu-q-work-items] Lubuntu work items for Q
<phillw> I get that one everytime it is updated>
<skaet> phillw,  name on that one changed to https://blueprints.launchpad.net/ubuntu/+spec/community-r-lubuntu-work-items
<phillw> Should i be somewhere else?
<skaet> nah,  its release planning, so general sorts of questions are fine here.
<phillw> skaet: stop giving me a heart attack, we're not even finished with 'Q', yet!! I know I will be allocated to 'R' :)
<skaet> oops.  missed the "q" reference,  there was a place holder for "r" series,  I had to rename today,  so that's what I thought you were talkinga bout.
 * skaet goes to look at the lubuntu-q-workitems
<phillw> skaet: https://blueprints.launchpad.net/ubuntu/+spec/community-q-lubuntu-work-items does not work (I am talking Quatal)
<skaet> no,  I left that alone - since its in use.   just wanted to make sure that the R-series one followed the right pattern to get scheduled.
<skaet> anyhow,  just looked at the q one,  and you're on the to be notified list.  (all people subscribed, get notified, every time something changes)
<xnox> stgraber: ogra_ : and the other authors opinion is "bin it" =)))) love it!
<phillw> skaet: may I please say a YAY!! for a guy who has got your graph on track? first time that I have looked at his.... http://status.ubuntu.com/ubuntu-quantal/u/gilir.html
<phillw> skaet: he was always my 'boss', but he's done it :D
<stgraber> xnox: ;)
<skaet> :)
 * skaet --> EOD
<phillw> skaet: may I ask what  http://status.ubuntu.com/ubuntu-quantal/group/topic-quantal-release-management.html
<phillw> is before you run away?
<xnox> phillw: it's meta blueprint that collects all some of the other blueprints as far as I know..... or something.
<phillw> skaet: I thought i was doing that with -testing.....
<skaet> they were blueprints that were of interest and would have helped manage the release.   Lots not done, and linkely not to, so will be working with individual mangers to get things marked postponed, as appropriate there.
<phillw> skaet: is balloons aware of that area>
#ubuntu-release 2012-10-02
 * xnox keeping the queue full of easy syncs ;-)
<Laney> doko: (anyone else): I'm copying qt4-x11 now
<Laney> how do I make copy-package copy to proposed?
<Laney> I don't see that options.destination.pocket gets set anywhere
<cjwatson> It's done in setup_location
<cjwatson> Does --to-suite=quantal-proposed not work?
<Laney> dunno
<Laney> I was reading the source to make sure I don't get it wrong
<cjwatson> It should do.  Try it and the confirmation message should tell you
<cjwatson> Oh, maybe it only tells you the archive
<Laney> the suite doesn't get used directly in the copyPackage call
<cjwatson> Yeah, but setup_location unpacks it.
<Laney> right
<cjwatson> --to-suite=quantal-proposed is certainly the intended interface.
<Laney> excellent
<infinity> Wait.
<infinity> Where did that copy come from?
<Laney> canonical-arm-dev/ppa
<Laney> I realised that this was the package you were talking about with missing -g change for CXXFLAGS
<Laney> I thought webit at first and got confused
<Laney> k
<infinity> Yeah, I'm going to have to reject that...
<infinity> For two reasons.
<infinity> (a) canonical-arm-dev isn't a clean PPA, it could have built against random non-archive bits.
<infinity> And (b) it's a pure virt PPA, so it's building on qemu-user-static systems that are known-broken.
<Laney> (a) I checked that it did not, but (b) fair enough
<infinity> Well, (a) seems to be a non-issue from the log.
<infinity> Yeah.
<cjwatson> Known-broken how?
<infinity> But (b) is kinda a no-go.
<Laney> I don't know that it is known broken
<Laney> I mean, yeah it sometimes fails when real builds would not but I'm not aware of the vice-versa case
<infinity> cjwatson: qemu-user-static randomly segfaults, and since it's at the binfmt_misc jiggery-pokey level, it won't actually bubble up and kill sbuild.
<infinity> cjwatson: Which can lead to curious results.
<cjwatson> Oh joy.
<cjwatson> That doesn't result in exit code 139?
<infinity> There are reasons I won't let people use this solution for distro buildds...
<cjwatson> Why oh why ...
<cjwatson> (I mean surely if, say, a shell segfaulted the shell script would exit non-zero)
<infinity> cjwatson: Yeah, I'm not sure why it doesn't seem to make its way back up the stack.  Could be a kernel misfeature?  Or something horribly perverse that qemu is doing.
<cjwatson> Brought to you by the same geniuses that brought you https://lkml.org/lkml/2001/3/20/31
<cjwatson> Anyone recognise https://launchpadlibrarian.net/118045056/buildlog_ubuntu-quantal-armhf.dmake_1%3A4.12-2build1_FAILEDTOBUILD.txt.gz, or should I just give it back and hope?  scheat doesn't reproduce it and it passed in the test rebuild
<Laney> infinity: if you reject then I might as well do a sourceful upload to set CXXFLAGS too, and include the patch in rejected
 * infinity looks.
<Laney> so, do it.
<infinity> Laney: That would be lovely.
<Laney> of course it will then fail again :P
<infinity> Probably.  Possibly.
<infinity> But we need to effin' fix the buildds this week anyway, or I'm going to swan dive from a tall building.
<infinity> cjwatson: Oh, that pesky misc-4 and it's failures!
<infinity> cjwatson: (IOW, I have no idea what's up with that, I'm happy to blame cosmic rays if it works on a retry)
<infinity> I was sort of expecting a log that might have something I could interpret. :P
<cjwatson> It's ordering, I assume
<cjwatson> The build on scheat says
<cjwatson> making testfile2
<cjwatson> making testfile1
<cjwatson> making testfile3
<cjwatson> as opposed to 2/3/1
<infinity> Oh, curious.
<infinity> I'm not so good with small integers, but I'd expect 1/2/3...
<cjwatson> infinity: Mathematician.
<infinity> cjwatson: Guilty as charged.
<Laney> infinity: ^
<Laney> perhaps you want to take that one
<cjwatson> Laney: I think he's gone to sleep.  I've accepted it.
<cjwatson> We'll see how that goes, I guess.
<Laney> fair enough. Cheers.
<Laney> make and webkit incoming.
<infinity> New webkit!
<infinity> Yay!
<debfx> Laney: is it really necessary to use -gstabs for all Qt components instead of just webkit?
<Laney> debfx: Dunno. I didn't test. With each build taking a day or more it's not the most pleasing of experiences.
<Laney> By all means feel free to do so and submit a revised version
<debfx> afaik we have such a patch in qtwebkit-source
<debfx> build time is one area where disabling the qt4-x11 webkit would help a lot ;)
<cjwatson> damnit, it's 2012 and we're *still* cleaning up after the horrendous mistake of mass-importing source packages from non-Debian sources in dapper
 * xnox 8)
<Laney> mass-remove them? ;-)
<cjwatson> it's tempting, but maybe I will let others care
<cjwatson> as ever I'm mostly annoyed by technical decisions taken for political reasons
<doko> maas-remove? =)
<Laney> reviewing queue
<Laney> huh, someone is beating me :P
<infinity> Laney: I do my best code reviews in my sleep.
<infinity> unixy_shell is the best variable name ever.
<infinity> Laney: The bit about defining PAGE_SIZE if it isn't... Are you sure that's not a bug elsewhere?
<Laney> No, but I found similar changes applied to other packages
<Laney> Infact I got the change from some other Debian package (don't ask me which)
<infinity> Mmkay.
<Laney> I'm not sure where it comes from on the working arches
<infinity> x86_64-linux-gnu/sys/user.h:#define PAGE_SIZE		(sysconf(_SC_PAGESIZE))
<Laney> or why it's different on arm
<infinity> Definitely missing from user.h on ARM.  I'd file a bug, if I were you.
<infinity> Cause it also misses out on PAGE_MASK, and some other bits and bobs because of that.
<infinity> Anyhow, doesn't hurt to have the hack in make for now.
<kenvandine> stgraber, can you look at bug 1055803, is that response from dpm sufficient?
<ubot2> Launchpad bug 1055803 in unity-firefox-extension "Typos in strings to translate in template "Unity-Firefox-extension"" [High,Confirmed] https://launchpad.net/bugs/1055803
<kenvandine> i'll add dh-translations too
<stgraber> kenvandine: good enough for me, if it's not translated, there's no harm in changing the strings
<kenvandine> yeah
<kenvandine> stgraber, thx
<ScottK> Someone (not me) ought to look at the webkit new upstream release that's in the queue.
<infinity> ScottK: If no one beats me to it, it's on my list, cause I'm pretty danged sure we want it (and the security team would agree).
 * ScottK too.
<infinity> ScottK: But I could also use a nap.  Or caffeine.
 * infinity is undecided on that.
 * ScottK just looked at the size of the diff and decided to wrap a somebody else's problem field around it.
 * ScottK is tired enough that he may need both of those.
<infinity> ScottK: Yeah, I suspect my review of it will be somewhat akin to speed-reading.
<infinity> ScottK: I'll understand the basic plot, but don't ask me what the characters had for lunch.
<ScottK> Right.
<ScottK> My review probably would have been more like "close eyes, hold nose", so better you anyway.
 * ScottK pours coffee.
<Laney> Oops, I accidently dropped some archive changes in webkit
<Laney> Started from a PPA package that was out of date
<psivaa> i get https://pastebin.canonical.com/75723/ after an p2q upgrade, could some one help me figure out how to resolve this, (i  had to use grub-repair after the upgrade too )
<ScottK> Laney: Should I reject it then?
<Laney> ScottK: I suppose.
<Laney> I'm piloting now but I'll reupload it soon. It's just some Recommends changed to Suggests.
<ScottK> Getting it out of unapproved reduces the chance of an oops in the mean time.
<Laney> sure
<skaet> Daviey,   has the maas upload that was producing uninstallable binaries been sorted in the last couple of hours?   Was looking at the Daily CD heal checks email,  and it seems to have been there for a couple of days.
<cjwatson> It's blocked on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<cjwatson> Specifically ipmitool
<cjwatson> Although I think Daviey said that was due to be dropped ...
<infinity> Laney: No "just" about those dependency changes. :P
<doko> no, replaced by freeipmi. just pinged Daviey about this. apparently work in progress
<skaet> thanks doko, cjwatson
<Daviey> Yeah, the MIR had a couple of requirements, which is in-progress
<Daviey> nothing alarming, just some changes
<skaet> Daviey,  will it land by tomorrow?
<Daviey> sure!
<doko> cjwatson, slangasek: where should libpam-xdg-support be seeded?
 * cjwatson disavows knowledge
<infinity> doko: My bet's on desktop-common or similar, but slangasek will know for sure.
<xnox> doko: when I was discussion bug 1058211 slangasek said: "Sep 28 22:44:30 <slangasek>	xnox: well, preferably not; this should be seeded as part of ubuntu-desktop"
<ubot2> Launchpad bug 1058211 in weston "weston does not fallback gracefully if $XDG_RUNTIME_DIR is not set" [Undecided,Confirmed] https://launchpad.net/bugs/1058211
<xnox> doko: that was about libpam-xdg-support on #ubuntu-devel.
<slangasek> doko: I was going to seed it in ubuntu-desktop; could be done in desktop-common if there's consensus that this is correct
<doko> and I thought I could finish the test rebuild today ...
<doko> slangasek, who is needed for this consensus? kubuntu, lubuntu?
<infinity> slangasek: Well, the whole point of all things xdg is to be, well, cross-desktop.  So, if it's correct, it's correct for everyone, right? :)
<slangasek> infinity: funny :P
<doko> Riddell, any proposal to only accept these packages in an order that the builds do succeed?
<Riddell> doko: you'll be pleased to know I took your advice and stopped using debian's method of build-depends to just depend on the libraries directly
<doko> \o/
<Riddell> so they sort themselves out for building in the PPA
<doko> a beer if can teach this to our gnome packagers ...
<doko> if you, even
<Laney> what?
<ScottK> doko: I'm accepting them anyway.
<ScottK> Riddell: So I can accept them without worrying about order?
<ogra_> doko, "a" beer wont do to convince them i fear :)
<doko> ScottK, well, it will cost 10min x the packages on all archs ...
<doko> ScottK, so how does this make sense, even before kdelibs is built?
<ScottK> Right, I meant after kde4libs is done.
<ScottK> It's building now.
<Riddell> ScottK: yes I think so
<ScottK> Cool.  We'll see.
<stgraber> Uploaded casper and would much appreciate if someone could review soonish, I'm planning on respinning desktop once it's built to do some more debugging. Diff is at http://paste.ubuntu.com/1256180/ (as LP's probably busy diffing kde...)
<stgraber> oh, that explains why queuebot didn't mention it ;)
<cjwatson> I rejected and reuploaded lockfile-progs from that with a cleaner diff.
<didrocks1> skaet: hey
<skaet> hiya didrocks,  how are we looking for DesktopInfrastructureFreeze?  any snags?
<didrocks> skaet: unity is still under quite a lot of changes, but I hope it will get there
<skaet> didrocks,  if not,  we may need to go with what's in the archive now then.
<didrocks> skaet: so it seems that PS think the release team ack for removing the preview on https://bugs.launchpad.net/unity-lens-shopping/+bug/1055684/comments/11 doesn't ask for any UIFe
<ubot2> Launchpad bug 1055684 in unity-lens-shopping "[FFE] Use music lens details page for music store results" [High,In progress]
<didrocks> skaet: I still think that the doc team has a say on it, as it impacts their work
 * skaet looking
<didrocks> wdyt?
<stgraber> rejected casper, back from lunch break, so back to hacking on it, I'll bundle some more changes and re-upload at the end of the day
<didrocks> (so there is a branch to remove the previews waiting)
<SpamapS> Hi, can I get a +1 for bug #1060319 (FFE for juju)
<ubot2> Launchpad bug 1060319 in juju "FFE - Juju and charm-tools" [Undecided,New] https://launchpad.net/bugs/1060319
<didrocks> skaet: ?
<SpamapS> ignore charm-tools there
<skaet> didrocks,  reviewing the comments in the bug and checking some things
<SpamapS> (juju is unseeded)
<Laney> SpamapS: is it really urgent? " Reported by Clint Byrum 1 minute ago "
<Laney> also, subscribe the release team please
<SpamapS> heh, I was just about to do that, just noticed I forgot to :)
<SpamapS> No its not.
 * SpamapS crawls back into hole
<popey> skaet, screenshots finally uploaded to bug 1055684
<ubot2> Launchpad bug 1055684 in unity-lens-shopping "[FFE] Use music lens details page for music store results" [High,In progress] https://launchpad.net/bugs/1055684
<skaet> popey,  how much testing was done off network for this featue?
<popey> i tested both on and off network
<skaet> Can you please add the details of what scenarios were tested,  in the bug to help us?
<popey> i left a comment with what I did
<skaet> thanks, popey
<popey> np
<Daviey> Can anyone comment why openvswitch is showing in both kubuntu and desktop sets?
<cjwatson> ends up in supported for some reason, probably the -dbg packages
<cjwatson> shouldn't be a big deal
<infinity> That software-properties is fixing a "it just plain don't work" regression for PPAs.
<doko> slangasek, infinity, cjwatson: xdg seeded in desktop-common
<slangasek> doko: did you get input from the flavors about this, then?
<doko> slangasek, no, based on infinity's comment to provide a common infrastructure
<slangasek> doko: infinity is being less than rigorous in his rationale
<slangasek> doko: this was pushed as a FFe for the Ubuntu desktop; if we're going to put it in desktop-common, kubuntu/lubuntu folks should be consulted
<doko> so, we do want this at least for ubuntu and kubuntu, right? lubuntu/xubuntu are the others?
<slangasek> doko: "we" don't want things for kubuntu, the kubuntu team need to be asked if they want it :)
<infinity> doko: Yeah, I think it *should* be wanted everywhere (at some point), that doesn't mean it is. :/
<infinity> doko: You may have missed the sarcasm in my comment to vorlon. :)
<doko> ehh, just didn't realize that this was explicit sarcasm, and not the usual implicit one ...
<infinity> Hahahaha.
<doko> asking kubuntu now
<ogra_> tell them they wanti ti :)
<ogra_> *it
<doko> Riddell confirms that libpam-xdg-support is fine for the kubuntu desktop
 * skaet --> lunch,  biab
<popey> ogra_, what arm devices do we have which will happily run Unity on 12.10?
<ogra_> popey, panda
<ogra_> FSVO happily :)
<popey> :)
<ogra_> even though we have a new nvidia driver it still doesnt work with unity ... so panda is the only one atm
<popey> pgraner, hey, got someone with a pandaboard and 12.10 who can test a feature for me?
<popey> unless you want to ogra_ ? (assuming you're beyond EOD)
<pgraner> popey, all of my team have panda's, I would suggest hggdh, or plars since they are in the US tz
<ogra_> well, i could test it tomorrow morning ... yeah, i'm not in my office atm
<pgraner> popey, and if they fell like showing you some love
<popey> np thanks ogra_
<popey> hggdh / plars hello!
<plars> popey: heya
<popey> plars, bug 1055684 needs testing.
<ubot2> Launchpad bug 1055684 in unity-lens-shopping "[FFE] Use music lens details page for music store results" [High,In progress] https://launchpad.net/bugs/1055684
<popey> i have done so on x86/64 but can't on 12.10 due to my arm device not being able to run unity currently
<plars> popey: is this arm only? From my understanding they just want to make sure the fix doesn't do something silly on arm right?
<popey> plars, I am going by the requirements from skaet
<plars> popey: is the fixed version in -proposed?
<popey> no, it should be in ppa:unity-team/release
<plars> popey: I'll need to reinstall my arm, so it will take me some time, there's another branch linked there that's uncommited, is it needed for this fix also?
<popey> not for testing the music lens feature, no, shouldn't be
<cjwatson> javatools 0.43ubuntu2 in unapproved is the first stage (of three) in fixing a build failure that almost consumed my sanity today.  Could somebody review it?
<cjwatson> (Well, the third stage will be a build retry, not an upload.)
<cjwatson> Also, there's a bunch of rebuilds in the queue if somebody wants to make a decent dent in it for very little review effort.
<Daviey> crikey
<ScottK> OK.  KDE 4.9.2 is all accepted, so the queue list ought to be more readable now.
<stgraber> cjwatson: accepted javatools
<stgraber> rejected a bunch of ubuntu-release-upgrader and kept just the newest entry
<cjwatson> stgraber: thanks
<cjwatson> I suspect that may mean intermediate bugs don't get closed automatically
<cjwatson> Unless the most recent used -v
<cjwatson> I usually review and accept/reject the whole lot when I see that
<SpamapS> I'd like to sync python-txzookeeper in from Debian experimental (patch release bump) .. its unseeded and just a support lib for juju.. should I file a FFE bug or is it cool to just go forward w/ it?
<stgraber> hmm, indeed... the latest one wasn't uploaded with -v
<SpamapS> (unseeded universe, btw)
<ScottK> SpamapS: If it's bug fix only, no FFe needed.
<stgraber> and the queue is back to something reasonable
<SpamapS> ScottK: thats what I thought... I get lost in what freezes are active at any one time :p
<seb128> ^ rejected that one because I had a small error, reuploaded it with that sorted out
<phillw> does any one know the (UTC) times when ogra_ is about?
<ogra_> now ?
<ogra_> :)
<ogra_> phillw, gilir already pinged me about the slideshow stuff
<ogra_> in case its about that :)
<phillw> ogra_: yeah, can I drop that from my "TODO" list for nagging purposes? :)
<ogra_> :)
<ogra_> i'll take care of it
<xnox> ogra_: phillw what slideshow nagging stuff?
<ogra_> seems ot be an issue on my side
<phillw> thanks, I do like to follow up when I say I will action something :)
<xnox> didn't we like just/recently had slideshow upload?!
<ogra_> xnox, the ac100 images have the ubuntu slideshow in the lubuntu installer
<ogra_> we are using oem-config there which behaves minimally different from ubiquity i suspect there is just something like an env var missing
<phillw> damn those seed files :P
<ogra_> i doubt its a seed issue
<ogra_> they shouldnt differ between arm and x86 anymore
<ogra_> (apart from hw related bits indeed)
<phillw> hmm, most peculiar that they're not being picked up, then.
<xnox> ogra_: make sure you seed/install lubuntu-slideshow before installting frontend-gtk or ubiquity, by default it pulls in ubuntu-slideshow. and if that dependency (slideshow) is satisfied a second one is not installed.
<cjwatson> It'll be a livecd-rootfs bug.
<cjwatson> Search for slideshow in live-build/auto/config there and you'll see attempts to do as xnox suggests - but lubuntu isn't handled
<ogra_> yeah i thought either at build time or a runtime oem-config thing
<cjwatson> Add another condition to that case statement for lubuntu and that should fix it
<ogra_> great
<phillw> cjwatson: as always, thanks!
 * ogra_ sees touch config/oem-config-preinstalled in that code 
<ogra_> when did we add that ?!?
<ogra_> awesome
<cjwatson> Adam did that towards the end of precise, I believe
 * NCommander waves
 * NCommander works on the FFE queue
<ogra_> uploaded ...
<ogra_> i fixed xubuntu alongside so we dont run into it in case someone ever does preinstalleds for it
 * NCommander really wishes the bot said who approved something through a queue
<ScottK> Those were me.
<bkerensa> mm
<NCommander> ScottK, ah
<xnox> NCommander: no audit trail in lp, so nobody knows. unless somebody claims =)
 * NCommander grumbles
 * NCommander did just finishing confirming genshi's patch does indeed fix the FTBFS before someone else approves
<stgraber> NCommander: that was me, sorry :)
<stgraber> I also accepted ubuntu-mono after giving it a +1 for the release team (as jbicha gave his +1 and the change seems minimal for our default install but useful for the alternate theme)
<stgraber> oh, or rather, someone else beat me to it :)
<ogra_> accept it twice and we have stereo
<stgraber> NCommander: hehe, we managed to comment at roughly the same time in the bug (but I was first by a few seconds) then you beat me to the accepting in the queue :)
<ogra_> (sorry, someone has to make a stereo joke if someone else mentions ubuntu-mono ... )
<NCommander> stgraber, ahahaha :-)
<NCommander> stgraber, I just kicked casper through, looked through the changes and the bugs and everything looks sane
<NCommander> Unapproved queue is empty! :-)
<NCommander> (for about five seconds)
<stgraber> NCommander: thanks for reviewing casper
<NCommander> stgraber, NP
<NCommander> I wasa little late to the party realizing ~ubuntu-release got queue access so I'm digging into working through it
 * ogra_ notices that NCommander waited with re-apperaing omn IRC right after the kde flood was through 
<ogra_> :)
<NCommander> My spidy senses were tingling that it was a good time to go get beer and pizza
#ubuntu-release 2012-10-03
<ScottK> It would be lovely if someone could review/accept the taglib update.   That's needed to fix one of the KDE build failures we had.
<stgraber> ScottK: looking
<ScottK> Thanks.
<stgraber> well, once LP gives me a diff :)
<ScottK> http://paste.ubuntu.com/1257087/
<stgraber> I guess that wasn't a case where you could get away with a generic usr/include/taglib/*.h?
<stgraber> anyway, accepted
<jbicha> ^ I guess that needs at least a verbal FFe since it adds a new (renamed) package but there aren't any rdepends
<jbicha> it won't build anyway until webkit makes it to quantal
<balloons> can anyone tell me if I'm doing something wrong -- I'm trying to launch ubiquity from my quantal box, but it only wants to run the kubuntu installer
<ScottK> stgraber: Thanks.
<balloons> ubiquity gtk_ui crashes, with no frontend available
<balloons> ahh.. I solved it, but it's odd you get the kde version by default
<balloons> why isn't ubiquity-frontend-gtk installed by default?
<micahg> debfx: Laney: qtwebkit isn't supposed to be built from the qt4-x11 source since maverick, but from qtwebkit-source
<ScottK> would someone please rescore taglib.  There's stuff in proposed that needs it to build.
<stgraber> ScottK: rescored
<ScottK> stgraber: Thanks.
<NCommander> jbicha, ping
<NCommander> I don't see a bug/reason for the telepathy-farstream sync.
<jbicha> NCommander: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686564
<ubot2> Debian bug 686564 in libtelepathy-farstream2 "Breaks theora video calling" [Grave,Fixed]
<NCommander> jbicha, thanks,accepted
<NCommander> (Its an annoying PITA to look at sync changelogs since Launchpad doesn't give me a handy link like it does with uploads)
<cjwatson> balloons: it'll be random.  I see no need to explicitly prefer any particular frontend since we always select a particular one during live fs building
<cjwatson> balloons: and really, REALLY don't run ubiquity on your regular system.  it is not even slightly a good idea ...
<cjwatson> (it will at the very least feel free to make configuration changes to the running system and is not at all guaranteed to put things back the way they were later)
<cjwatson> Laney: ignore the mail about my mistaken copy of make-dfsg to quantal-updates rather than quantal - I deleted that again
<debfx> micahg: it's a bit more complicated than that
<Laney> cjwatson: righto. You got in before I saw it
<cjwatson> Riddell: ^- no Replaces: field?
<Riddell> cjwatson: is that needed in -proposed?
<Riddell> surely -proposed is for people who do testing?
<cjwatson> There's no harm in adding Replaces, and it may help
<cjwatson> So why not?
<Riddell> ok dokay
<cjwatson> If it gets rid of even a handful of confused bug reports it's worth it
<cjwatson> Could somebody review ubiquity in unapproved, please?
<cjwatson> In fact if somebody other than me could do any queue review that would be pretty nice. :-)
<smartboyhw> :P
<Laney> I'll do some in a bit.
<Laney> post lunch
<cjwatson> Thanks
<Laney> 283 results :(
<Laney> oh, langpacks
<cjwatson> Huh
<cjwatson> I can deal with those ...
<cjwatson> Flushed.
<Laney> how do you deal with those? do you just accept them?
<cjwatson> Yeah
<cjwatson> Well I spot-checked one that it looked vaguely reasonable
<cjwatson> But I'm not going to review them all :-)
 * xnox ponders why is it source package per lang, instead of singe source package with binary package per lang.
<cjwatson> They don't *always* get uploaded in a giant block
<xnox> ok then
<cjwatson> Just often
<cjwatson> I expect I have some status quo bias; I think I'm happier with fewer ginormous source packages though
<xnox> some of them are very small like 9kB src & 3kB binary....
<xnox> gnome and kde-base are big.
 * xnox meh...
<cjwatson> the non-base ones alternate between tiny and huge
<tumbleweed> meep, I should also do a queue pass. I haven't been doing much recently
 * smartboyhw wonders why everyone suddenly caught up with queue passing today:P
<tumbleweed> urgh, I need to catch up on FFe bugs first
<Daviey> I don't think they are overwhelming tumbleweed
<tumbleweed> no, but tehy're in a busy inbox
<Daviey> tumbleweed: yeah, inbox traffic has indeed been high
<seb128> Daviey, thanks for geary!
<Daviey> seb128: np
<hallyn> hi - IIRC when I asked beofre, for bug 1056381, it was said an FFE for spice isn't needed since it's needed for a qxl bugfix?
<ubot2> Launchpad bug 1056381 in xserver-xorg-video-qxl "[FFe: spice] error on x startup" [High,Confirmed] https://launchpad.net/bugs/1056381
<hallyn> but, better safe than sorry :)
<stgraber> hallyn: can we get a changelog for all those packages? that'd make it easier to figure out whether there are any feature changes that'd indeed require an FFe
<hallyn> stgraber: quoted into the bug you mean?
<stgraber> hallyn: yes, please
<hallyn> ok
<stgraber> rejected wakeup as it's a feature change without a FFe or even a bug (re-adding evolution plugin)
<hallyn> stgraber: (posted to the bug)
<stgraber> hallyn: yep and I added the upstream changelogs for each now
<balloons> cjwatson, ahh, so no running of ubiquity to install to another target eh? Guess I can close my own bug found then :-)
<xnox> balloons: already won't fixed it. =) ubiquity more-or-less copies the whole system it's booted of (the live-cd) + does cleanup. And since installed systems != livecd special built the results are unexpected =)
<cjwatson> balloons: Yeah, that's explicitly unsupported
<plars> popey: so should I use ppa:unity-team/ppa then? I looked at unity-team/release and it doesn't appear to be set to build for arm at all
<popey> yes plars
<plars> popey: ok, I had the wrong one yesterday it seems, it looks like arm still isn't build though so I'll check back later today
<popey> thanks plars
 * iulian wonders why spice is sitting in the queue if its FFe hasn't been approved yet.
<iulian> stgraber: Are you looking at spice?
<stgraber> iulian: I can review it later today but I wouldn't mind another review of the FFe by someone who knows a bit more about spice. I'm just the original reporter of the bug as I tried using spice a couple of weeks ago and noticed that X wouldn't start in my VM.
<iulian> stgraber: I have no experience with spice at all and thus I shall leave it to someone else.
<infinity> stgraber: It sounds like you have as much experience as anyone, given that you've, I dunno, used it. :P
<stgraber> hmm, then I'll give it another look and if I don't spot anything that looks scary I'll accept the FFe. Current state is that X doesn't start, so can't get much worse than that I guess
<plars> popey: hey, it finally built, and seems to work here :)
<popey> woooooot
<popey> plars, so can you open music with a right click and then play preview from the store?
 * popey crosses fingers
<plars> popey: right click, yes - from the main results this time too (not just music)
<popey> excellent, thanks plars, much appreciated, could you please leave a comment on bug 1055684 ?
<ubot2> Launchpad bug 1055684 in unity-lens-shopping "[FFE] Use music lens details page for music store results" [High,In progress] https://launchpad.net/bugs/1055684
<plars> popey: I think I'm missing the bits I need to playback the preview... let me install that
<Laney> https://launchpad.net/ubuntu/+source/qt4-x11/4:4.8.3+dfsg-0ubuntu3/+build/3871112
<infinity> I'm rejecting eglibc, since I plan to do an upload today, and it'll be a waste of buildd time to build both, I'll make sure the one in the queue is included in mine.
<mdeslaur> infinity: cool, thanks
<infinity> mdeslaur: NP, happy to reject more security uploads!
<mdeslaur> lol :)
<mdeslaur> stupid security updates wasting all the CPU time :)
<infinity> mdeslaur: I'm still bitter about the security update to precise that wiped out two weeks of testing on my eglibc SRU. :/
<infinity> mdeslaur: (Reeeeeally would have been nice if someone had at least tried to contact me and coordinate that)
 * NCommander sits down and deals with the unapproved queue
<micahg> infinity: I thought about mentioning it but figured you would see it in backscroll, will highlight next time
<mdeslaur> infinity: yeah, it sucks when that happens. sorry about that....I believe it got started a while ago
<infinity> micahg: Erm, hilighting me after it's uploaded would have been a bit too late anyway.
<infinity> mdeslaur: The annoyance is that I could have finished off the SRU testing pretty quickly, and we could have pushed the security update on top.
<micahg> infinity: they discussed it a bit first :)
<infinity> micahg: But not with me, nor with regard to the SRU, that's the bit that's annoying me.
<infinity> micahg: And it's pretty non-obvious to people who aren't paying really close attention when their SRU just disappears.
<micahg> infinity: oh, I thought you meant the devel upload, yeah, I wasn't around for the security update in stable
<infinity> micahg: Oh, no, the devel upload is fine.  I just rejected it to avoid wasting resources.
<infinity> micahg: This is entirely about the precise upload.
<infinity> micahg: Which, along with resetting my SRU timer, also broke a whole class of users who had been happily using the one in -proposed. :/
<mdeslaur> infinity: we'll make it up to you with some security team beer at uds ;P
<infinity> mdeslaur: But.  But.  You guys aren't half as fun as the kernel team.
<infinity> mdeslaur: You can always stop by their table and buy us a round. :)
<mdeslaur> infinity: oh, we go to the Kernel Team Variety Show too!
<NCommander> seb128, ping, I see an entire set of indicator-* packages in the queue with no attached bug.
<NCommander> What changes are they making?
<ScottK> NCommander: There's no requirement for a bug.  Read the diff.
<NCommander> (I see new upstream version released)
<NCommander> ScottK, I did, the diff just says new upstrema version with no reason
<ScottK> As long as the new version is bugfix only, that's sufficient.
<seb128> NCommander, #ps is just rolling stable tarballs for release, translation updates, minor cleanups
<NCommander> seb128, thanks
<NCommander> ScottK, I'm aware of that, but I do like to verify $WORLD :-). Call it insanity/pendaticness
<NCommander> seb128, I'll release the entire set now
<seb128> NCommander, thanks
<ogasawara> infinity: could I get those linux and linux-meta uploads approved?  It should be our last before kernel freeze tomorrow.  it's an ABI bumper too.
<infinity> ogasawara: Yeahp, can do.
<ogasawara> infinity: thanks, you're the best
<infinity> ogasawara: Aww, I'm blushing.
<plars> popey: ok, I can confirm that preview works too, sorry for the delay
<popey> plars, no need to apologise, I really appreciate you taking the time to test it, thanks!
<Daviey> infinity: are you handling d-i uploads?
<infinity> Daviey: I will in ~8h, yeah.
<Daviey> rocking banana !
<infinity> (When the kernel builds are all done and such)
<stgraber> if someone wonders, I've tested most of the changes in that casper upload. I couldn't really test the RAID stuff, but my guess is that it can't be much worse than what they have now (failure to boot)
<stgraber> the various persistence changes have been tested and so has the username/userfullname/hostname override
<stgraber> The network changes have been tested from busybox (to check that the syntax is fine) but I don't have a netboot environment here to test that it actually works at runtime (but the code is so similar that it really should)
<infinity> stgraber: Tested "most" is really giving me confidence. ;)
<stgraber> infinity: it's casper we're talking about ;) testing all the possible paths in that thing would take years...
<ScottK> kde-baseapps is me trying to salvage some binaries.
<infinity> ScottK: Was there a double-override-loss-of-binaries oops?
<infinity> apw: Danke.
<apw> infinity, np
<wgrant> infinity: No, there was a copy-from-proposed-before-armhf-built oops
<infinity> wgrant: Ahh.  Oops indeed.
<wgrant> infinity: ScottK and I are poking to copy them across
<infinity> wgrant: Thanks for helping.
<wgrant> Using the same binary recovery method that's never been used on the primary archive before
<wgrant> And running into some issues
<wgrant> But I think we'll have it sorted out once he's back to rerun the copy
<wgrant> And then we'll know this works and can use it properly in future
<wgrant> The latest trick is that copyPackage doesn't let you specify a custom source pocket, instead just picking the latest publication with that (archive, name, version)
<wgrant> So asking it to copy that version picks the release publication, not the proposed one, so it doesn't grab the missing binaries
<wgrant> But if we copy it back to proposed, then from proposed back to release, it will grab the missing binaries, and all will be good in the world.
<infinity> Yeah, I've used THAT copy trick before.
<infinity> updates -> proposed -> updates
<wgrant> Right
<infinity> It's from a pocket to itself that's the curiously bizarre use-case.
<wgrant> And the non-deterministic override selection issue is a bit problematic, but relatively easily fixable.
#ubuntu-release 2012-10-04
<infinity> ^--- The eglibc upload I promised, superseding the earlier security upload with a couple more fixes, the SRU version of the same will follow later today.
<Daviey> infinity: can you follow up with bug 997978 please?
<ubot2> Launchpad bug 997978 in qemu-kvm "KVM images lose connectivity with bridged network" [High,In progress] https://launchpad.net/bugs/997978
<Daviey> (people seem confusededed)
<infinity> Daviey: Done.  I may just do the re-base on Soren's behalf and upload; it's trivial.
<infinity> Daviey: Want to give a quick review of eglibc ubuntu19->ubuntu20 (You can fish 19 out of rejected to do the diff), I already reviewed ubuntu19 and was happy with it, so just need someone to okay my changes in 20.
<Daviey> ok
<infinity> ^--- Verified that's the same diff as soren's 14.1->14.2, which I already reviewd and (almost) accepted, so accepting this one.
<Daviey> infinity: eglibc, I really hate the fact that one of the new patches doesn't have any clear traceability, such as citing it's origin.  But that isn't anything new with that package, by the seems of it.
<infinity> Daviey: Oh, none of the cvs patches tend to do that.  I should probably get both us and Debian using a more DEP-friendly patch style.
<Daviey> infinity: the thing is, it seems to be a mixture of patches?
<Daviey> debfiff, http://pb.daviey.com/5wwT/ .. http://sourceware.org/ml/libc-alpha/2012-06/msg00578.html ?
<infinity> Daviey: It's 4 commits in one of those patches, and one in another.
<Daviey> yeah, the other is well defined with the header
<infinity> Daviey: Yeah, maybe I should adjust the headers for verbosity.
<Daviey> But it's really hard to review something that is a clump of code, with the comment - "Backport another FMA support patch from glibc master branch"
<infinity> Daviey: The FMA one is the one you think it well-defined. :)
<Daviey> (normally i wouldn't be looking so closely, but eglibc is something that well, i wouldn't just to wave past.)
<infinity> Daviey: I can reupload with a bit of a header on the wordsize one.
<infinity> (Just including, but not applying, the bits that would have gone in /ChangeLog)
<infinity> Daviey: http://paste.ubuntu.com/1259152/ <-- Would this make you happier?
<Daviey> infinity: maybe i am just too tired, but the bug points to commit c5bfe3d5ba29d36563f1e4bd4f8d7336093ee6fc , is is totally different to the patch?
<Daviey> Oh, i do indeed suck - http://sourceware.org/ml/libc-alpha/2012-06/msg00120.html .. bad foo
<infinity> Let me just reupload the above patch with the header, since that's likely what I'll want for the SRU too.
<Daviey> infinity: sorry if it's seemingly pedantic
<infinity> Nope, you're right.  Debian and Ubuntu both need better patch headers in glibc. :P
<infinity> Reject away, a new one will be up shortly.
<infinity> Daviey: Reuploaded.
<infinity> Daviey: All better?
<Daviey> infinity: well, i've just validate against upstream VCS, and the touched files haven't been touched since.. So no reversions,  There seemed to be one more commit that added a test?
<Daviey> * math/libm-test.inc (cosh_test): Add more tests / http://sourceware.org/ml/libc-alpha/2012-06/msg00578.html
<infinity> Daviey: We skipped the test in the backport to 2.15 (assuming you're talking about the dbl/ldbl stuff)
<infinity> Daviey: http://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/release/2.15/master
<Daviey> Ok, thanks for being patient.
<infinity> Daviey: Spiffy, thanks.  I'd ask you to do the same review on precise for me so I can accept that, but you might hit me. ;)
<infinity> Daviey: (precise is the combinatin of the previously-accepted 10.1, the security 10.2, and then the changes you just reviewed are 10.3, so all you'd need to do is verify that 10.3 is indeed that... I guess)
<Daviey> infinity: If only you could see my hand right now :)
<infinity> The trick is that the security 10.2 didn't include 10.1.
<infinity> Daviey: Does it have a reduced finger count?
<Daviey> it's counting in binary
<infinity> I prefer to look at it from the side and see it as a musical note.
<Daviey> heh
<Daviey> ogasawara / infinity: I assume you saw linux armhf ftbfs?
<infinity> Daviey: Ugh, rly?
<infinity> Oh, lovely.  It's ACTUALLY FTBFS, instead of some BS packaging error.
<infinity> I guess that gets me out of d-i uploads tonight. :P
<slangasek> ^^ there's the uefi shim, with Canonical UEFI CA key embedded
<slangasek> cjwatson: ^^
<slangasek> hmm, the uploaded changelog is inaccurate though; let me fix that
<slangasek> removed && reuploaded
<tseliot> hi, can anybody reject nvidia-settings-updates and nvidia-settings in quantal, please?
<Laney> tseliot: done
<tseliot> Laney: thanks a lot
<Daviey> cjwatson: did you just copy eglibc to quantal-release?
<Daviey> (it's fine if you did, i just wanted to confirm)
<cjwatson> Yes
<cjwatson> This is somebody's nag to do some queue review please.  I've got quite a bit stacked up there now which could be using buildd time.
<cjwatson> I'm reviewing the nvidia* stuff as best I can at the moment.
<Laney> I am already doing it
<cjwatson> nvidia?
<Laney> no, working from the bottom of queue
<cjwatson> OK, great, thanks
 * Laney yays at having three ppc buildds again
<cjwatson> Yeah, makes a big difference
<cjwatson> tjaalton: So, talk to me about this mesa upload - is the rationale that if we're shipping a pre-release snapshot, it might as well be as close to release as possible?
<tjaalton> cjwatson: yes, 9.0 will be released next wednesday, but we'll probably sru it
<tjaalton> since it's past final freeze?
<cjwatson> mm
<cjwatson> There are a couple of renamed identifiers in glext.h along with the API additions
<tjaalton> checking
<cjwatson> GL_TYPE_RGBA_FLOAT_ATI -> GL_RGBA_FLOAT_MODE_ATI and GL_MAX_TRANSFORM_FEEDBACK_INTERLEAVED_ATTRIBS_NV -> GL_MAX_TRANSFORM_FEEDBACK_INTERLEAVED_COMPONENTS_NV
<cjwatson> Do you think those are safe?
<cjwatson> I'd hate to have to do another test rebuild at this point
<cjwatson> Also a few adjustments to some of the function declarations
<cjwatson> I think it's mostly OK, just looking for a risk assessment
<tjaalton> riht
<tjaalton> +g
<tjaalton> "upgrade glext.h to version 85", and applied to the stable branches
<tjaalton> don't know the history yet
<tjaalton> nope, only master and 9.0
<cjwatson> Of course it comes pretty much straight off opengl.org, doesn't it
<tjaalton> yeah
<tjaalton> and don't see anything using it directly, besides mesa
<cjwatson> So it's probably pointless to worry about it too much
<tjaalton> think so, yes
<cjwatson> All right, accepted
<tjaalton> cool, thanks
 * Laney wonders if popt is going to get a diff
<cjwatson> unconvinced by gcc-defaults-armel-cross and gcc-defaults-armhf-cross; asking hrw for clarification on #ubuntu-devel
<mdeslaur> ^ libxslt is only security fixes
<cjwatson> sure, accepted
<mdeslaur> cjwatson: thanks
<cjwatson> Right.  So I believe all 28 items in the release pocket queue are currently ones I uploaded.
<cjwatson> And I think I need somebody with more desktop clue than me to review the Unity stack in -proposed.
<cyphermox> ^^ network-manager-applet includes two extra strings which are marked translatable ("HSPA+", "LTE"), but normally are never translated (and I checked the other similar strings for a few languages, GSM/HSUPA, etc.). Confirmed with dpm too
<Laney> gah
<seb128> cjwatson, do you have questions or any comment,explanation that could help for the unity stack?
<Laney> https://bugs.launchpad.net/ayatana-design/+bug/1052513 â no UIFe
<ubot2> Launchpad bug 1052513 in unity-lens-applications "Dash - 'More suggestions' icons are too large" [Undecided,Confirmed]
<seb128> cjwatson, or are you looking for somebody who validated the code diff?
<cjwatson> err ... I want somebody else to review it :)
<seb128> popey, ^
<Laney> i'm looking
<cjwatson> seb128: popey isn't in ubuntu-release
<Laney> I assume there are screenshots that include those icons though
<seb128> cjwatson, no, but he's the one leading the team who is in charge of making sure unity commits don't land if there are not an approved exception bug
<seb128> cjwatson, or said differently, he should be handling that UIFe
<cjwatson> I think you think I'm asking for something that I'm not asking for
<cjwatson> All I'm saying is that I'm disregarding that bit of the queue, as an ubuntu-release member, because I'd rather somebody with a bit more relevant knowledge tackled it
<seb128> cjwatson, oh, my "^popey" was pointing to Laney's UIFe exception
<cjwatson> ah
<seb128> sorry ;-)
 * cjwatson goes back to glaring at nvidia-texture-toolkit
<cjwatson> I wish people would stop typedeffing standard-looking names
<cjwatson> if you want a 64-bit integer type, put it in your own damned namespace
<mdeslaur> release team: bug 1061734
<ubot2> Launchpad bug 1061734 in webapps-applications "webapps-applications removes package installation prompt" [Undecided,New] https://launchpad.net/bugs/1061734
<JohnLea_> Laney; hyia, popey just pinged me about bug #1052513  This one should land under the 12.10 Dash exception that was agreed with Online Services.  Also as the request is only to "make all app icons the same size", fixing this bug will not cause any translation or documentation issues.  A user looking at the screen after this bug is fixed, and at the same time looking at the documentation will not be in any confusion.
<ubot2> Launchpad bug 1052513 in unity-lens-applications "Dash - 'More suggestions' icons are too large" [Undecided,Confirmed] https://launchpad.net/bugs/1052513
<Laney> kenvandine: ^
<Laney> JohnLea_: mhr3 tells me that it's not fixed anyway
<JohnLea_> Laney;  we need it to be, it's a bad visual regression.  thx, I'll ping mhr3
<Laney> well then you'll need to get an exception
<Laney> mdeslaur: speak to kenvandine and mvo, but in general feel free to upload a revert
<Laney> didrocks: is this everything in proposed?
<Laney> oh, there's another one ;-)
<didrocks> Laney: miss unity, coming soon
<Laney> yeah, that's the one I was looking for
<didrocks> once I've fixed the PS integration team packagingâ¦
<Laney> did you version the build deps?
<didrocks> yeah, I versionned all build-deps
<didrocks> so you can accept in the order you want :)
<Laney> great
<Laney> I'll do that then, but I'll be going out very soon so someone else will likely have to do unity itself
<Laney> didrocks: unity-lens-help contains debian patches despite being native
<didrocks> Laney: yeah, it's a native app versionning but upstream isn't ready to roll a tarball
<Laney> I mean you shouldn't have debian/patches
<didrocks> Laney: so, not sure what I had to do as we need to feature politcally-wise
<Laney> or you should change the source ofrmat
<didrocks> Laney: should I just inline patch?
<Laney> yes
<didrocks> ok, doing
<didrocks> Laney: reuploaded
<Laney> thanks a lot
<xnox> not sure why pulseaudio got uploaded into proposed....
<xnox> the fix is needed to unbreak ubiquity a11y
<didrocks> Laney: sorry, I was thinking that it needed to be handled differently :)
<didrocks> Laney: ah, what about unity-lens-radios?
<Laney> just because there was two in the queue
<didrocks> Laney: one doesn't have the build-dep on gir-unity
<Laney> yeah I checked
<Laney> I rejected the bad one
<didrocks> Laney: I thought I rejected the other one myself, but maybe launchpad timeouted
<didrocks> thanks :)
<seb128> xnox, does it make a difference? it can be pocket copied once it's built
<didrocks> Laney: ok, uploading unity now
<cjwatson> xnox: Indeed, it *will* be copied once its built
<cjwatson> It was uploaded to -proposed to avoid multiarch skew
<xnox> I see. Ok. thanks.
<xnox> it's needed to bring sound back to ubiquity / desktop-cds
<cjwatson> xnox: Feel free to see if David needs any help on figuring out the armhf build failure, then, since that's a blocker for that
<cjwatson> (Or maybe that's cosmic rays; here's hoping ...)
<xnox> *sigh*
<Laney> Lot of those rays around these days ...
<Laney> kenvandine: erm
<Laney> -         gir1.2-unity-5.0,
<Laney> +         gir1.2-unity-5.0 >= 6.8,
<Laney> that's not the right control file syntax ...
<didrocks> Laney: FYI, I uploaded unity-lens-video to quantal itself because it's doesn't depend on the rest of the stack (I have an additional cherry-pick fix)
<Laney> didrocks: I don't even see that in the queue
<Laney> unless you did it right now
<didrocks> well, 5 minutes ago
<Laney> ok, probably somewhere in the tubes
<didrocks> yeah ;)
 * Laney hits the BFB
<Laney> and by that I mean "Enter"
<didrocks> Laney: it's in now :)
<Laney> what is going on?
<Laney> oh, queue is doing prefix matching
 * Laney -e -e -e
<doko> please could somebody comment on https://bugs.launchpad.net/ubuntu/+source/libgnomecanvas/+bug/1013211 ? the last upload was rejected
<ubot2> Launchpad bug 1013211 in libgnomecanvas "[FFe] Please transition libgnomecanvas to multi-arch" [High,In progress]
<kenvandine> Laney, crap... i'll fix
<slangasek> cjwatson: new shim uploaded
<kenvandine> Laney, re-uploaded :)
<Laney> kenvandine: going out right now I'm afraid
<Laney> someone else can review for you
<infinity> doko: Done.
<infinity> doko: If it's sitting in rejected, I can just review it from there.
<kenvandine> Laney, no worries, thanks
<infinity> doko: Do we know who rejected libgnomecanvas last time?
<infinity> cjwatson: Rejected your libgnomecanvas and accepting the previously-rejected upload from stokachu instead.
<cjwatson> infinity: Mine was just a no-change rebuild, wasn't it?  Any upload will do.
<infinity> cjwatson: Indeed, which is why I went that route.
<infinity> cjwatson: Was just poking you so you wouldn't wonder about the REJECT, s'all.
<cjwatson> Laney: I'm increasingly tempted to make -e the default.  That was the fault of some Launchpad developer way back when
<cjwatson> And it irritated me at the time :-)
<hallyn> want to upload an lxc fix for bug 1060404 .  ought i to ask for permission here first ?  (i.e. is this currently a full freeze?)
<ubot2> Launchpad bug 1060404 in lxc "update-grub runs and fails in containers" [High,Confirmed] https://launchpad.net/bugs/1060404
<infinity> hallyn: If it's just a bugfix, no need to ask permission, fire away and we'll review.
<hallyn> infinity: thx, firing
<skaet> hallyn,  final freeze is next Tuesday.   Important bug fixes welcome until then.   (Kernel and Desktop interface freeze is today at 2100 though.)
<hallyn> yikes, that's badd for the netdev refcount bug :)
<hallyn> skaet: thanks
 * cjwatson hopes apw gets his signed kernels patch in before then :-P
<cjwatson> (critical path for secure boot)
<skaet> thanks for flagging cjwatson.
<apw> cjwatson, i am uploading it as soon as the armhf build which is near completion has published
<infinity> cjwatson: It'll be close enough.
<infinity> apw: And by "has published", you mean "has been copied to -release and published", I assume?
<infinity> apw: If you're pretty sure it'll all work right and dep-wait correctly, you can just upload now.
<apw> infinity, if i upload a new source it'll stop the binaries publishing won't it ?
<cjwatson> We might need some care if he uploads before the last one's published ...
<infinity> apw: Oh, it's a new linux source?  Nevermind.
<cjwatson> Yeah
<infinity> Fun.
<cjwatson> That and then a linux-signed or similar on top
<apw> infinity, i really mean, i'll tell you when its done, you'll fix it, and tell me when its safe to upload again :)
<cjwatson> (I've reviewed the packaging diff to linux already)
<infinity> apw: Upload everything and I'll reject it. ;)
<infinity> apw: And rescue from rejected later.
<infinity> apw: So you don't have to wait around past your EOD.
<apw> infinity, i need the abi files from that binary build to make the next package anyhow
<infinity> apw: Oh, there's that.  Fiiiine.  Wait.  See if I care!
<apw> i am packing anyhow, for a trip this weekend, so its not the end of the world
 * infinity taps his foot.
 * cjwatson sees amd64 failures drop below 100 in the test rebuild
<cjwatson> We might get to some approximation of vaguely there yet
<cjwatson> skaet: desktop infrastructure rather than interface, I thought?
 * cjwatson checks
<slangasek> cjwatson, jdstrand: btw, can one of you sanity check this shim package for me, just to make absolutely certain I've embedded the right key?
<cjwatson> Heh, I wanted to check that but didn't actually have the original to hand
<slangasek> heh
<slangasek> I *think* I used the right key, and the key I used certainly has a trust chain to the archive-signed grub and efilinux ;)
<slangasek> but I'd really like a double check before I submit it to MS
<slangasek> jdstrand: ^^
<jdstrand> slangasek: where is it?
<slangasek> jdstrand: shim source package in quantal
<jdstrand> so it is in unapproved?
<slangasek> debian/canonical-uefi-ca.der
<slangasek> no, it's in the archive
<jdstrand> ok, I'll look at it-- it will be a bit though
<slangasek> not yet submitted to MS, so if I got the key wrong we just need to replace & reupload
<slangasek> ok, thanks
<cjwatson> slangasek: Do you know what the MS turnaround time's likely to be?
<slangasek> cjwatson: extrapolating from a sample size of one, I'd say "less than 2 business days"
<slangasek> once we submit it, which requires IS to go down into the vault and find the machine running IE
<cjwatson> OK
<slangasek> cjwatson: are there test signed kernel images available anywhere right now?
<slangasek> that's the part I didn't get a chance to test before upload
<cjwatson> There may be some in ~apw/signing
<skaet> cjwatson,  yeah my bad - Desktop Infrastructure Freeze is today.   https://wiki.ubuntu.com/DesktopInfrastructureFreeze
<xnox> cjwatson: I claim that cosmic rays are not iluminating my flat, as pulseaudio has build successfully for armhf in sbuild locally. Shall I push the retry button on pulseaudio, hoping that the cosmic rays have moved together with the rain god.
<infinity> xnox: Yeah, give it a whirl.
<infinity> xnox: The worst that happens is it fails again.
 * xnox "you spin me right round baby right round" http://www.youtube.com/watch?v=J5Bw-QufBPk
<infinity> Like a build record, baby?
<slangasek> xnox: er, it's disturbing on so many levels that this is the video you came up with for this song
<infinity> Oh dear, I didn't click the link.
<xnox> "see I don't understand how build number 1 failed, it was just a thing before, I only build twice..." http://www.youtube.com/watch?v=Tc7W8Q-g9Lg
<xnox> =))))))
<apw> infinity, ok ... yell when you are happy
<infinity> apw: I accepted.  Happiness will occur soonish, after publisher+copy.
<slangasek> xnox: http://www.youtube.com/watch?v=M660rjNCH0A
<xnox> slangasek: gosh, you've changed a lot since UDS. How did you grow a bear that long that quick?!
<xnox> slangasek: wait, since debconf =)
<slangasek> xnox: people mistakenly believe that you have to cultivate a greybeard for a long time, but the secret truth is the rate of facial hair growth increases linearly with age
<slangasek> so the older you are, the more trivial it becomes
 * skaet made the mistake of clicking on the links....
 * xnox actually read a peer reviewed academic paper on relationship between shaving and speed of beard growth. There is none, only the optical illusion created by larger cross-section created by razors vs natural pointy hair.
<infinity> xnox: Tell me the research was government-funded.  Restore my faith in my tax dollars going to useful things.
<skaet> lol
<xnox> infinity: well in UK most of universities are funded by Malaysian and Chinese foreign exchange students. As they get their government's grants to study in the UK. E.g. my university would not have Engineering department at all, if not exchange students paying triple the price.
<xnox> infinity: www.movember.com grow a moustache for a month for charity =)
<infinity> Dearest publisher, you picked a lousy time to run over your 30m window, no love, Me.
<infinity> apw: So, the publisher screwed you.  We're delayed by 30m.
<apw> infinity, missed it by seconds did we
<cjwatson> Giant translation tarballs again or something?
<infinity> apw: If by seconds, you mean five minutes, yes.
<infinity> cjwatson: Dunno, haven't poked the log, but a 5 minute delay sounds like translations would be a fair thing to blame.
<infinity> That so needs to be async.
<cjwatson> Yeah, I've been meaning to move that to a script server.
 * skaet notes that Freeze is 2100 UTC,  not london time... 
<infinity> Actually, that log doesn't show any translation foo.  Could have just been I/O contention.
<xnox> skaet: or in other words Freezes have their own Daylight Saving Time pattern ;-)
<skaet> :)
<seb128> bah
<seb128> https://bugs.launchpad.net/unity/+bug/1057000 ?
<seb128> <ubottu> Launchpad bug 1057000 in unity (Ubuntu) "[Ubuntu 12.04.1/12.10] nVidia drivers 304.51 prevent autohidden Unity launcher from revealing" [High,Confirmed]
<seb128> tseliot, ^
<xnox> pulseaudio has backed please copy quantal-proposed -> quantal
<xnox> Laney: ^ ;-)
<infinity> cjwatson: Want to wave that d-i through?  The binaries are on disk on ftpmaster.
<Laney> xnox: I never know when I'm allowed to, so I tend to avoid copying stuff. Ask Mr. Conrad.
<infinity> Mr Conrad needs a new nick hilight.
<xnox> Mr. Conrad please send pulseaudio through infinity to quantal from -proposed? =)
<infinity> (Also, he already copied pulseaudio)
<xnox> you are awesome =)
<infinity> Laney: Feel free to accept d-i for me, though.
<skaet> infinity,  done
<skaet> (d-i, accepted)
<infinity> Danke.
<skaet> infinity, Laney - anything left pending for the desktop infrastructure or kernel freeze side of things?
<infinity> skaet: There's a kernel incoming from Andy in a few minutes.
<skaet> k
<Laney> not that I know of. seb128 ?
<seb128> skaet, Laney: do you count webapp as infrastructure?
<seb128> otherwise we are good I think
<skaet> seb128, yeah I count them as infrastructure - since other things have to interact with them.
<skaet> seb128,  rest has landed?
<seb128> yes
<skaet> infinity, looks like that linux upload you were waiting for has arrived.   Can you do the sanity check and get it in?
<infinity> skaet: Yeah, that'll be happening shortly.  There's still one more piece to the signed kernel puzzle that will be ~8h late because it needs the kernel built for it to work.
<phillw> who's on queue duty for FFe today? :)
<infinity> phillw: Several people, just ask.
<phillw> infinity: it is the pcmanfm FFe exception that Julien has asked for. Whilst this area is totlally out of my remit, i do know that he does stuff correctly. As we are in FF, it is a mix of bug fix & more ability.
<gilir> since phillw bring it up, it's bug 1059845
<ubot2> Launchpad bug 1059845 in pcmanfm "[FFe] New upstream release 1.0.1" [Undecided,New] https://launchpad.net/bugs/1059845
<gilir> It's mostly a bugfix release, but with some small features inside with require FFe
<infinity> gilir: Have you built and tested it locally?
<phillw> hi gilir (boss), even as mere mortal I can understand your reasoning and request. You are always very good to explain what is being done for those of us who are not coders.
<gilir> infinity, yes, available in a PPA, tested at least on 2 systems
<infinity> gilir: Oh, the bug claims you have.
<phillw> infinity: the L-QA people will go test :D
<infinity> gilir: The only new feature concern I have there is the "basic multimonitor support"... If that doesn't appear to have caused any crazy new behaviours or regressions, I'm fine with the FFe.
<gilir> infinity, not on my system, which is multi-monitor
<infinity> gilir: Unplug a monitor and make sure it's fine with one too? :)
<gilir> infinity, the only regression I saw was reverted, I didn't see problem since I using the new version (1 week)
<gilir> that's an idea :-)
<infinity> gilir: I'll follow up to the bug, pending you testing with one monitor.
<gilir> infinity, ok thanks, I'll update it later
<infinity> gilir: Bug updated.
 * phillw awaits for being told off :) 
<slangasek> jdstrand: any luck on that shim CA confirmation?  I'd like to get this on its way today in the hopes of getting it turned around by the weekend
<jdstrand> slangasek: sorry, not yet-- was training someone and trying to get an update out and then got the normal pulls every which way
<jdstrand> it is next on my list, but may not get to it tonight since I have a hard stop in a few. will definitely do it first thing in the morning
<jdstrand> (if not sooner)
 * infinity takes a late lunch after the linux review.
<infinity> jdstrand: I totally read that as "if not sober".
<jdstrand> haha
<slangasek> jdstrand: ok; I'm considering pulling the trigger anyway in the meantime then
<infinity> Dyslexia is a beautiful gift.
<jdstrand> slangasek: sorry, I will review it regardless
<slangasek> jdstrand: ack :)
<jdstrand> slangasek: I'm assuming it is more than just looking at the file itself, is is that all you want?
<jdstrand> s/is is/or is/
<slangasek> jdstrand: just looking at the file to make sure I've included the right one :)
<jdstrand> slangasek: I can do that. give me a minute
<slangasek> I'm not worrying about a security audit of the code at this point; might be useful, but we're in the same boat with RH if there are any issues :P
<jdstrand> slangasek: I confirm that is our master public certificate
<slangasek> jdstrand: ok, thank you :)
<jdstrand> slangasek: sorry for the delay-- that was considerably easier than I thought :)
<cjwatson> unity stack looks built in -proposed; copying to release
<SpamapS> RAOF: tsk tsk, your colord upload has a misformatted LP: bug number
<SpamapS> RAOF: (LP: 844286)
<RAOF> GAH!
<SpamapS> rejecting now, re-upload in the next 10 minutes and I'll accept, otherwise it looks good
<SpamapS> we are seriously far behind on SRU's
<RAOF> SpamapS: Done; thanks.
 * xnox yeah precise SRUs =)
<cjwatson> migods we have idle armel builders
<SpamapS> quick, somebody.. UPLOAD SOMETHING
<SpamapS> we can't let those chips cool down ;)
<cjwatson> You may have noticed I just uploaded 20 no-change rebuilds :P
 * SpamapS breathes a sigh of relief
<SpamapS> :)
<xnox> SpamapS: added SRU template to  bug 488696 . Sorry for the delay =)))
<ubot2> Launchpad bug 488696 in autofs "syntax error in nsswitch config near [ syntax error ]" [Undecided,Fix released] https://launchpad.net/bugs/488696
#ubuntu-release 2012-10-05
 * infinity feeds the poor, lonely buildds.
<infinity> cjwatson: Argh.
<infinity> cjwatson: Did you overzealously remove linux from -proposed?
<infinity> cjwatson: Yup, you sure did. :/
<infinity> wgrant: So, silly copying tricks.  Is there a clever way to get https://launchpad.net/ubuntu/+source/linux/3.5.0-17.27/+publishinghistory undeleted?
<infinity> wgrant: With bonus points for having it back before the builds complete? ;)
<wgrant> infinity: If the source is deleted, then yeah
<infinity> wgrant: It is.
<wgrant> Use copy-package's version argument
<wgrant> The API doesn't require the package to not be deleted
<wgrant> It's possible that your copy-package script does, but you can just hack that check out if it whinges
<wgrant> copy-package -b -e 3.5.0-17.27 --to-suite=quantal-proposed linux
<wgrant> I think
<infinity> I had a -s quantal-proposed in mine too..
 * infinity knocks that out.
<wgrant> That's probably just used to find the origin version
<wgrant> So it should be irrelevant when -e is specified
<wgrant> But checking
 * infinity comments some bits out.
<wgrant> Ah, so find_latest_published_source requires -s and that the package be currently published
<infinity> Oh, hrm.  Yeah.
<wgrant> I'd just eliminate that and use options.version directly in copy_packages
<wgrant> Remove the find_latest_published_source call
<infinity> And more to the point, I can't just comment those bits out, cause it's used for versions too.
<wgrant>                     source_name=package, version=source.source_package_version,
<wgrant> version=options.version
<wgrant> done
<infinity> Yeah, just did that. :P
<infinity> Alright, that may or may not have just done... Something.
<wgrant> infinity, ScottK: BTW, the copier diff bug that broke both your binary revival attempts was fixed yesterday, will be on production next week
<wgrant> infinity: You copied it twice
<wgrant> infinity: It's in Unapproved now
<infinity> Twice?  Go me.
<infinity> wgrant: The billion dollar question is what this will do to the builds.
<wgrant> infinity: If you copied with -b, nothing
<wgrant> They should continue and then be accepted fine
<wgrant> No new ones will be created
<infinity> wgrant: Sure, and the two that already failed due to being for superseded source?
<infinity> wgrant: Need SQL intervention to kick them back to needs-build? :/
<wgrant> 2012-10-05 00:45:18 INFO    Job:
<wgrant> <PlainPackageCopyJob to copy package linux from ubuntu/primary to ubuntu/primary, PROPOSED pocket, in ubuntu quantal, including binaries>
<wgrant> raised CannotCopy:
<wgrant> linux 3.5.0-17.27 in quantal (source has no binaries to be copied)
<wgrant> It was copied before there were any binaries at all?
<infinity> Just builds, no binaries.
<infinity> It was deleted before any builds completed.
<infinity> https://launchpad.net/ubuntu/+source/linux/3.5.0-17.27
<wgrant> Ah, OK
<wgrant> Trying to load, LP not being forgiving
<wgrant> But copy without -b
<wgrant> Since there are no binaries in either suite, a source-only copy will work fine
<wgrant> But you are correct that the amd64/i386 builds will need manual recovery
<infinity> Bugger.
<wgrant> For added fun, we have no ops
<infinity> We have GSAs.
<wgrant> We do
<infinity> If you know the magic required.
<wgrant> And I guess we have bigjools to approve
<wgrant> But we have no webops or lifeless
<wgrant> So, copy without -b
<wgrant> To get the soruce back and salvage the other three builds
<infinity> I haven't surgerised that table in years.
<wgrant> It's a really easy query. I'll just set them to failed, then retry.
<infinity> Check.
<infinity> New copy accepted.
<wgrant> No need to mess with the buildqueue etc.
<wgrant> linux 3.5.0-17.27 in quantal (same version already building in the destination archive for Quantal)
<wgrant> blaaargh
<wgrant> Yeah, this isn't going to work :/
<wgrant> If there was a single binary in the initial copy it would have been fine.
<infinity> Oh, bah.
<wgrant> But since it was copied with nothing, we're stuck
<infinity> Hrm.  What if I just copy it to release?  Will that suffer the same issue?
<infinity> It's not an ABI change, there's no real reason it needs to be in proposed.
<wgrant> Copy what to release?
<infinity> The source.
<wgrant> Oh, it's not already there?
<infinity> Or will it still have a sad about it being currently building?
<infinity> No, it's in proposed.
<infinity> Well, it WAS in proposed, and that's where I was copying it to.
<wgrant> I assumed it was deleted from proposed because it was copied to release
<wgrant> But I see now it's entirely gone.
<wgrant> The release copy will fail the same way
<infinity> No, it was deleted from proposed because the previous version was moved to release, and Colin wasn't paying attention. :P
<wgrant> Heh
<infinity> So, if all the builds were to spontaenously fail, would that help us any?
<infinity> Or is "building in destination" not actually what it says?
<wgrant> A source-only copy will work if the builds are all failed
<infinity> That, I can do.
<wgrant> So if you want to kill those three, you can copy it back into proposed source-only, retry the builds, and then we can fix the x86 stuff
<wgrant> They need to actually be failed, though, not just not building.
<infinity> wgrant: They'll be failed shortly.  If DarrenS loves me.
<wgrant> Although it's not directly relevant here, builds will complete and upload successfully as long as the source is published somewhere in the archive. The suite doesn't necessarily need to match
<wgrant> And you can then use the binary revival trick (once the bugfix is deployed) to copy them into the right pocket.
<infinity> wgrant: And that would be more interesting if I could have rescued the source in the first place. ;)
<wgrant> Yeah
<infinity> wgrant: Oh, and it's going to have to be SQL surgery on i386, amd64, and powerpc.  The latter finished while we were talking.
<wgrant> Yeah, so I saw
<infinity> And armel and armhf now dead.
<infinity> Well, armhf is in the death throes...
<wgrant> armhf still seems alive
 * infinity waits.
<wgrant> Yeah
<wgrant> Once it's failed properly, retry the source-only copy
 * wgrant prepares SQL
<infinity> There.
<wgrant> BuildStatus.SUPERSEDED should possibly be retriable nowadays, since it is possible to unsupersede things
<wgrant> But it's historically been our go-to status for making builds unretriable.
 * infinity accepts and crosses his fingers.
<wgrant> 2012-10-05 01:03:17 INFO    Ran 1 PlainPackageCopyJob jobs.
<wgrant> It worked.
<infinity> It did indeed.  And beat the publisher by a matter of seconds.
 * infinity fires up the ARM builds again.
<infinity> wgrant: Right, all looks snazzy.  Whenever you can make the SQL mojo go, that'd be nice.  You have a couple of hours of slack time, thanks to those builds being wildly faster than armhf. :P
<wgrant> Heh
<infinity> ^-- lolwut?
<infinity> Oh, that's the amd64 build, queuebot's confused.
<ScottK> wgrant: Thanks.  Both for the quick turn around and the update.
<micahg> Bug #1057518 has UI changes, could someone tell me if a UIFe is needed?
<ubot2> Launchpad bug 1057518 in onboard "debian.tar.gz supplied: New upstream release 0.98.1 available" [Undecided,New] https://launchpad.net/bugs/1057518
<micahg> is 'Added NVIDIA driver detection' to checkbox called a feature?
 * micahg rings the bell on the counter to see if anyone is around :)
<RAOF> That sounds like a feature to me, but I'm not exactly on the release team.
<micahg> right, which is why I'm asking :)
<ScottK> micahg: Yes and yes.
<micahg> ScottK: thanks for the confirmation :)
<infinity> It's a feature for sure, but depending on the size of the code, and how obviously unbroken it seems, it may be FFeable.
<micahg> looks FFeable, just wasn't sure if that qualified as a feature for checkbox
<infinity> Pretty much any new code that isn't directly fixing a bug that could only be fixed by refactoring a bit is a "feature", to be fair.
<infinity> That was a convoluted sentence.
<micahg> fair enough :)
<ScottK> infinity: I'm working on some no change rebuilds so we can get the binaries that got missed when Riddell prematurely copied from proposed (you can see the first one ^^^).  I'd appreciate if you could push them through.
<infinity> ScottK: I'm working on wandering away from my computer and killing brain cells with gin, but I'll poke at things randomly when I come back.
<ScottK> Thanks, but you know what gin is made from, right?
<infinity> ScottK: Love.
<ScottK> Juniper berries.
<infinity> ScottK: And love.
<ScottK> And do you know what juniper berries are?
<ScottK> They are poisonous.
<ScottK> Just saying.
<infinity> So are tomatoes, in large enough quantity, doesn't stop people from eating 'em.
<ScottK> Shortly after one of my brothers graduated from high school he got sick enough from gin that for years afterwards all you had to do way say the word and he would turn pale.
<ScottK> ;-)
<micahg> scottk: did you want to review kaffeine in precise-proposed? (when you're done with your no change rebuilds)?
<ScottK> Depends on if I run out of steam or not.
<micahg> hrm, i'm guessing I need a UIFe to upload Bug #621204  as well
<ubot2> Launchpad bug 621204 in im-switch "Typo in error string" [Undecided,In progress] https://launchpad.net/bugs/621204
<ScottK> micahg: Done.
<ScottK> BTW, that's it for the KDE rebuilds for missing binaries.  Maybe if the gin gets infinity, Riddell will tend to them once he wakes up.
<micahg> scottk: thanks
<cjwatson> infinity: argh sorry
<cjwatson> infinity: we really should make pending-sru's recommendation be to remove by version
<apw> cjwatson, infinity, linux-signed above is the packaging half of the signing changes; if you would review w
<apw> (so much for waiting till it appeared)
<infinity> cjwatson: Did you want to review the linux/amd64 in unapproved, since you have a vague idea of WTF should be in the tarball? ;)
<cjwatson> I suppose I'd better
<cjwatson> " Archive admins should review the corresponding source upload for correctness prior to approving these uploads"
<cjwatson> BRB in a week
<infinity> I reviewed the source and it seemed vaguely sane...
<infinity> But, I'm not as well-versed in how this is all meant to work.
 * apw notes there is at least the correct extra binary in the upload
<apw> (in the linux/amd64 binary)
<Laney> cjwatson: -e default> yes please. I don't think I've wanted the prefix/substring/whatever behaviour yet.
<infinity> I use it for langpacks.
<infinity> But that's a perfectly reasonable sort of use-case for pattern-matching being an argument, not the inverse.
<Laney> Yep.
<cjwatson> linux/amd64 accepted now.  Distracted by an argument, sorry.
<cjwatson> Wait, why didn't that work
<cjwatson> Sigh.  Accepted by id, can't be bothered to debug why by name didn't work
<Riddell> ScottK: I'm confused, https://launchpad.net/ubuntu/+source/kde-baseapps/4:4.9.2-0ubuntu4 exists but is not on https://launchpad.net/ubuntu/+source/kde-baseapps
<Riddell> oh wait, it just appeared
<Riddell> good I guess that's sorted, thanks much for doing that
<cjwatson> What happened with those KDE builds?  Were they copied in advance of pending-sru saying that all the builds were done?
<cjwatson> (And could somebody have a look through my 30 no-change rebuilds in the queue?)
<Riddell> cjwatson: yes I copied them early which apparantly confuses launchpad
<Laney> doing
<Laney> I added a --names-only to queue locally so that I can loop over queuediff
<cjwatson> Riddell: Yeah, please don't do that, that's why we have pending-sru list the build states
<Riddell> cjwatson: where is pending-sru?
<cjwatson> http://people.canonical.com/~ubuntu-archive/pending-sru.html
<cjwatson> section near the bottom for quantal
<Laney> does queuediff cache the fact that there's no diff available?
<cjwatson> I think it tends to run into proxy trouble a good bit
<ScottK> Found one more KDE package needs rebuilding.
<ScottK> Riddell: kdepim-runtime should appear forthwith.
<ScottK> Found another one.
<ScottK> smokekde should be along in a moment.
<Laney> What's the barrier for desktop interface freeze?
<Laney> https://wiki.ubuntu.com/DesktopInfrastructureFreeze "no further fixes"
<cjwatson> s/interface/infrastructure/
<Laney> yeah
<cjwatson> IMO anything that doesn't affect the users of that infrastructure shouldn't count: e.g. FTBFS fixes
<cjwatson> I mean I would see that as an obvious case for an exception
<Laney> so I have a fix for a crash in a library which occurs on non-default setups
<Laney> can I upload that, for example?
<ScottK> Where did that come from?
<Laney> the fix?
<ScottK> The freeze
<Laney> oh, I'm not really sure about it
<cjwatson> I lose track.
<ScottK> That doesn't even make sense.
<cjwatson> Laney: I would upload it for review if I were you.
<Laney> I feel like I should understand it so that I can review stuff too
<ScottK> I've no idea what the bounds of desktop infrastructure are either.
<ScottK> Laney: Don't worry, you're not the only one.
<cjwatson> It feels like "hey can we not have lots of unity churn after here"
<cjwatson> But it's not well-phrased.
<ScottK> We already have a freeze that's supposed to cover that.
<ScottK> Feature freeze.
<phillw> cjwatson: have you had any feed back from kernel / X-org team re: PPC?
<cjwatson> phillw: No; you'll need to chase them if you want an answer, as I absolutely don't have time
<phillw> cjwatson: Thanks, I'll go in to full nagging mode :) If that fails, would you allow the change? (It would be, as you state, a 'bodge job' instead of a fix)
<cjwatson> phillw: No, I want an ack from one of those teams one way or the other telling me what to do
<cjwatson> I'm not going to take responsibility for changing those boot parameters without that, given that I don't really understand them
<cjwatson> So I want at least *one* of our relevant developers to look it over and tell me what they think, even if they don't fix the underlying bug(s)
<cjwatson> Without that I'm afraid I'm going to leave it as it is, on the basis that currently I'm hearing from people who are broken by the current setting, but for all I know some different group of people might be broken by the change
<phillw> cjwatson: and we both know that one will blame the other...
<cjwatson> (And obviously I wouldn't hear from the latter until after changing things)
<phillw> cjwatson: shame they were not on the 24 hour marathon. Would have been a really good time to bash heads together.
<cjwatson> What, when people are low on sleep?  Doesn't seem like a good time to me ...
<phillw> cjwatson: I got in early :)
<cjwatson> I don't want a coerced or thoughtless answer; I want an actual one
<phillw> cjwatson: so do I... So, why do -kernel and -xorg keep kicking the critical bugs into the 'long grass'?
<phillw> cjwatson:
<phillw> cjwatson: A3 worked, these bugs are 100% regression issues.
<cjwatson> I expect they're upstream regressions that have not been reported coherently to the right people
<cjwatson> Please stop asking me - I don't know
<cjwatson> Talk to them
<phillw> cjwatson: I do apologise, I do get frustrated at times. May I repeat that you are "one of the good guys" for trying to keep a PPC release going. I do not say 'thank-you' often enough. You really are a star.
 * smartboyhw nods in agreement:P
<cjwatson> I'm not fishing for compliments or anything - it's just that the best way I can help is to encourage you to talk to the people who actually have useful knowledge
 * ogra_ shudders seeing Laney approved bug 999771
<ubot2> Launchpad bug 999771 in myunity "myunity depends upon DISTRIB_RELEASE being the second entry in /etc/lsb-release" [Undecided,Won't fix] https://launchpad.net/bugs/999771
<Laney> k
<ogra_> they should have used lsb_release -r
<micahg> that would require a runtime dependency on lsb-release
<Laney> indeed
<ogra_> sure
<Laney> the fix in there is miles better than it was
<cjwatson> Hmm, this tickles a memory somewhere
<Laney> cjwatson: your name is indeed invoked in the bug :-)
<micahg> (which is in minimal, so shouldn't matter too much), but running the command is usually slower though
<cjwatson> I have a distinct feeling I remember a bug related to assuming /etc/lsb-release was shell
<ogra_> but its a tool to manage unity ... which surely pulls in some python already
<cjwatson> Laney: an older memory :)
<Laney> heh
<ogra_> so adding lsb-release as a dep shouldnt add much
<micahg> chromium used it for a while (don't remember if it still does or not)
<micahg> ogra_: the problem is lsb_release is slow
<ogra_> oh, come on ...
<cjwatson> I'm going to have to grep my upload mailboxes :-/
<smartboyhw> skaet, er release meeting today?
<ogra_> its a one time check in a gui tool
<Laney> it's hardly a terrible fix
<Laney> people coming out of the woodwork immediately after the upload rather than the weeks when the patches were available ...
<micahg> ogra_: it should really be generated at build time IMHO
<cjwatson> Laney: the one worry I have is that my memory is that this may be crashy on some flavours
<ogra_> micahg, ++
<cjwatson> I'm trying to find the history to see if it's this I'm thinking of or something else
<doko> Laney, use /etc/os-release ... the format is defined
<ogra_> doko, but only available in quantal
<cjwatson> bug 214861
<ubot2> Launchpad bug 214861 in localechooser "expects to be able to source /etc/lsb-release" [High,Fix released] https://launchpad.net/bugs/214861
<cjwatson> Laney: ^-
<doko> well, I'll see to backport this then to precise
<Laney> aha
<cjwatson> Laney: localechooser has some battle-tested shell code for this
<cjwatson> which matches the python implementation afaik
<Laney> perhaps you want to inform marga
<cjwatson> yeah
<cjwatson> Laney: Done.  Sorry for being late, but associative memory over four years takes a while to respond sometimes
<Laney> cjwatson: Ta. It's an interesting data structure that has such a fast membership operation, but much slower lookup performance
<cjwatson> Laney: That's a hash :-)
<cjwatson> In the crypto sense - you can check whether you have the ciphertext, but getting back from that to the plaintext is hard ...
<Laney> Also here the membership test is probablistic, and the hashes get harder to crack over time :P
<skaet> smartboyhw - yes there is a release meeting today
<smartboyhw> skaet, thanks
<doko> skaet, for a gcc-4.7 update, which should go to -updates ... can I upload to -proposed? or just prepare and build in the ubuntu-toolchain-r ppa?
<cjwatson> If you upload to -proposed at the moment, there's a decent chance somebody running on autopilot will copy it to release
<skaet> doko,  please do it in the ppa,
<doko> ok
<tumbleweed> not that I tend to be particularly active at release meetings, but advance notice: I almost certainly can't make it
<skaet> hmm....   do we want to reject the nvidia-graphics-drivers-tegra3 in unapproved queue,  until the source version in the new queue is processed?
<ogra_> skaet, ?
<ogra_> one is tegra, the other is tegra3
<ogra_> tegra3 is completely new
<ogra_> -tegra is just a package update for the tegra2 drivers
<skaet> ogra_  Thanks!   ok,  missed that "3", and thought somethin weird was going on since the versions looked the same.
<ogra_> yeah, i was pondering to name them -cardhu and -ventana (teh work names for the tegras) ... but then tegra2 would have had so much extra paperwork (new source etc)
<skaet> ogra_ what's the bug associated the tegra3 ones?   would like to read the backstory.
<ogra_> i wanted to save us from that ... though i agree the naming isnt great :)
<ogra_> skaet, identical code, same bug
<ogra_> i would have filesd a tegra3 task, but thats only possible once a source package is in the archive
<ogra_> *filed
<skaet> fair enough.   Thanks for the background
<ogra_> skaet, the libas have now a SONAME field (never had that before) but that doesnt have the correct contant
<ogra_> sigh, my typing degrades every day
 * skaet just sees that a flood of langpacks has hit the unapproved queue.... :P
<ogra_> skaet, if you run ldconfig on them, the broken info lands in ld.so.cache
<ogra_> if an app looks for libEGL.so.1 ld only knows about libEGL.so
<ogra_> so the app cant run
<skaet> Laney,  would you mind taking a look at the libunity that seems to be in the unapproved queue?
 * skaet takes her turn letting through some rebuilds 
<roadmr> micahg: sorry to pester you, we FFed bug 1060211 if you want to have a look,  depending on what happens with that I'll resubmit the merge for checkbox 0.14.8
<ubot2> Launchpad bug 1060211 in checkbox "[FFe] graphics_driver script does not report proprietary driver version" [Low,Fix committed] https://launchpad.net/bugs/1060211
<ogra_> thanks !
<apw> infinity, cjwatson, i have updated linux-signed to add the postinst/postrm and linux-image binary dependancies
<micahg> roadmr: IANA release team member
 * micahg can sponsor once approved
<roadmr> micahg: oh ok! thanks anyway!
 * skaet starts wading through RIddell's langpack changes...
 * iulian is reviewing the other ones.
<iulian> Well, not all of them. :)
<smoser> hi. can i get an approval on a cloud-init upload ?
<cjwatson> Upload it first then we'll review it
<smoser> https://launchpad.net/ubuntu/quantal/+source/cloud-init/0.7.0-0ubuntu2
<cjwatson> Or is it that one in the queue?
<smoser> should be in queue
<smoser> yes.
<cjwatson> smoser: accepted
<skaet> cjwatson, can you take the linux signed one too?
<cjwatson> Yep, looking
<skaet> ta
<skaet> hmm... is queuebot acting up again?
 * skaet accepted a couple and not seeing them.
<infinity> Ugh.
<cjwatson> Which?
<infinity> ScottK: There seems to be an explosion of KDE-related things that want to come back to main.
<cjwatson> infinity: Ugh, what.  language packs maybe?
<cjwatson> No ...
<micahg> langpacks in main are part of it
<cjwatson> Well, maybe
<cjwatson> What the heck is the root cause of all that
<micahg> according to http://people.canonical.com/~ubuntu-archive/component-mismatches.svg :)
<infinity> langpacks and kde4libs->kate.
<skaet> they were labeled universe
<cjwatson> This is the tool that does the labelling
<infinity> So, the langpack bit is simple to fix.  Let's go see what changed to make the other bit happen.
<skaet> ok,  will leave them for infinity to sort.
<smoser> thank you.
<cjwatson> Hm, yes, language-pack-kde-zh-* might be the cause of the lot
<cjwatson> ubuntu.quantal/usb-live: * /^language-pack-[^-]+-zh-han/
<cjwatson> That plus (presumably) a new dependency?
<infinity> You'd think...
 * skaet shakes her head at the kate package name, and see the potential for confusion.
<cjwatson> Yeah, that would account for it
<cjwatson> Fix that seed and I think everything else should follow
<skaet> ok
<infinity> Yeah, I'm not seeing the kde4libs->kate thing.
<infinity> The fancy svg might be lying.
<cjwatson> The rest is all the effect of Extra-Includes, I believe
<cjwatson> Pull in enough stuff and the auto-"include -dbg" stuff kicks in and drags in half the world
<cjwatson> Also, stuff.
<infinity> Have you already mangled the seed, or shall I?
<cjwatson> No, go ahead.  I'm too woozy for regexps.
<infinity> I've so far failed to wake up this morning.
<infinity> I'm out of bed only to prove I'm not dead. ;)
<infinity> But, let's regex away.
 * infinity wonders why that regex is there at all...
<cjwatson> Probably made sense once.
<infinity> I suspect that replacing the zh-han regex with /^language-pack-gnome-zh-han/ will fix it all up nicely.
 * infinity will do a quick before-and-after germinate for both Ubuntu and Kubuntu and check.
<cjwatson> Agreed.
<iulian> gilir: Have you uploaded pcmanfm as well? I can only see libfm in the queue.
<iulian> gilir: Nevermind, saw it.
<bdmurray> could somebody have a look at approving my update-manager uploads to p and o proposed?
<infinity> bdmurray: Sure, I'll trade you those for my eglibc upload to precise.
<infinity> bdmurray: (Which is a combination of the 10.1 that was previously accepted and then superseded by the security update, the 10.2 security update, and then two small patches from the recent quantal)
<kenvandine> the latest upload for aptdaemon ftbfs because of failing tests, i tried building the latest built version and it now ftbfs as well
<kenvandine> anyone have suggestions for someone that might be around that has messed with aptdaemon in the past?
<bdmurray> infinity: the changelog entry for update-manager is longer than the change - I'm not sure this a good deal
<kenvandine> or... if we can turn off those tests until mvo can look at it on monday, so we get some better testing of webapps over the weekend?
<kenvandine> the tests fail for the current published version of aptdaemon anyway, so that isn't a regression
<kenvandine> but i would really like to be able to get more testing for webapps
<infinity> bdmurray: It's probably a bum rap for you, but someone needs to accept that eglibc, and I'm pretty sure it's not allowed to be me (even if I've verified a few times that the diff is sane). :P
<kenvandine> skaet, ^^
<cjwatson> kenvandine: I'll have a look either tonight or tomorrow if nobody else does
<cjwatson> Please don't disable tests
<kenvandine> ok
<kenvandine> i didn't want to... just couldn't find anyone to look at it that knew their way around
<kenvandine> cjwatson, thanks!
<kenvandine> the more testing we can get for webapps, the better :)
<infinity> bdmurray: Uhm, your precise-proposed update imported quantal sources.
<infinity> bdmurray: I'm thinking that was unintentional, given the changelog.
<bdmurray> infinity: yes, I'm not sure how that happened
<infinity> bdmurray: oneiric looks good, though.
<infinity> bdmurray: Given the tininess of the diff, I'd probably not mess with pre-upload magic at all, and just apply it directly to the source package, but whatever workflow helps you sleep better...
<bdmurray> It looks like something in utils/demotions.py - I'll try and sort it out
<skaet> thanks kenvandine, cjwatson
<slangasek> cjwatson: ^^ new shim with changed path for second stage, as requested
<bdmurray> infinity: ^
<slangasek> self-accepting shim (time-sensitive, can't break anything yet because we're still putting it in place)
<Daviey> shimmy it in!
<kenvandine> Daviey, :-D
<skaet> slangasek, well, I'd trust your review over mine on the subject, at any rate. :P
<slangasek> infinity, bdmurray: does eglibc still need looking at?
<infinity> slangasek: Looks like bdmurray got to it for me.
<infinity> slangasek: You're free. :)
<slangasek> ah ok
<infinity> (Free to keep hating secure boot...)
<slangasek> sorry, was a bit tied up this morning :P
 * skaet --> dr. appt.  back on later. 
<slangasek> Daviey: mm, why does http://people.canonical.com/~ubuntu-archive/component-mismatches.txt show maas having a dependency on a package not in main?
<slangasek> (ipmitool)
<Daviey> slangasek: because that is the intention of the report, it shows packages that depend or recommend on universe packages.. And candidates for demotion.. but i know you know that?
<slangasek> Daviey: I'm trying to figure out why we're two weeks before release and there's a package in main with a dependency on a package that's never been in main, and I find no MIR for it
<Laney> slangasek: https://bugs.launchpad.net/ubuntu/+source/ipmitool/+bug/1040682
<ubot2> Launchpad bug 1040682 in ipmitool "[MIR] ipmitool" [High,Invalid]
<slangasek> ah, I didn't check 'invalid'
<Daviey> slangasek: it's being replaced with freeipmi on next upload, covered by MIR 1052056
<Daviey> bug 1052056
<ubot2> Launchpad bug 1052056 in freeipmi "[FFe] [MIR] freeipmi" [Undecided,In progress] https://launchpad.net/bugs/1052056
<slangasek> ok
<Daviey> slangasek: The debdiff for jdstrand's requirements is here, http://paste.ubuntu.com/1262079/ pending one more addition.. which is in progress
<Daviey> (this was discussed in the release meeting, just a few hours ago)
<slangasek> alright
<ScottK> No more KDE stuff on http://people.canonical.com/~ubuntu-archive/testing/quantal_outdate_all.txt
<ScottK> Riddell: I think the copying misfire is all cleaned up now.
<Riddell> oh great, many many thanks
<cjwatson> I already reviewed the minitube diff when granting its FFe, so accepted.
<jdstrand> skaet: hmmm, final freeze is next tuesday? that is rough on the US...
#ubuntu-release 2012-10-06
<infinity> wgrant: Hrm, no can accept libreoffice.  Irksome.
<slangasek> was there any specific reason to leave the language-pack-kde uploads in the queue, or should I flush them?
<wgrant> infinity: A timeout?
<infinity> wgrant: Sadly, yeah.
<wgrant> I believe it's illegal in most jurisdictions to mention a timeout with its OOPS ID
<wgrant> s/with/without/
<wgrant> We may be able to bump the timeout enough
<infinity> https://oops.canonical.com/oops/?oopsid=OOPS-bc3d500f772ea9e03cb98de14e919500
<ubot2> https://lp-oops.canonical.com/oops.py/?oopsid=bc3d500f772ea9e03cb98de14e919500
<wgrant> Thanks
<infinity> ubot2: That was pretty wildly unhelpful.
<ubot2> infinity: Error: I am only a bot, please don't think I'm intelligent :)
<wgrant> Does libreoffice still have hundreds of langpack packages?
<infinity> wgrant: It does, yeah.  Does/should that matter for a source accept?
<wgrant> Oh, source, no
<wgrant> Hm
<wgrant> Did you retry that?
<wgrant> The timeout doesn't make very much sense
<wgrant> There's this rather suspicious 8.5s gap in the SQL log
<wgrant> Which looks like a one-off
<infinity> I tried once from the web UI, twice from the CLI.
<wgrant> Another OOPS ID would be helpful
<infinity> Sure, I'll do it again!
<wgrant> Heh
<infinity> ...
<infinity> And now it works.
<infinity> Mechanic's syndrome.
<wgrant> As long as you're unblocked :)
<wgrant> We'll see the OOPSes in tomorrows reports
<wgrant> I wonder if that 9s delay is consistent
<infinity> To prove I'm not full of it, another OOPS for the same timeout was:
<infinity> https://oops.canonical.com/oops/?oopsid=OOPS-bc3d500f772ea9e03cb98de14e919500
<ubot2> https://lp-oops.canonical.com/oops.py/?oopsid=bc3d500f772ea9e03cb98de14e919500
<wgrant> It's really really odd
<wgrant> Aha, thanks
<infinity> Wait, that's the same one.
<infinity> Wut?
<wgrant> Yes, yes it is
<infinity> On two different runs of the API tool, though.
<infinity> My scrollback doesn't lie...
<wgrant> Nope
<wgrant> It does lie
<wgrant> https://oops.canonical.com/oops/?oopsid=OOPS-eddb1503e8421232ad7713cdada76c44 is another one
<ubot2> https://lp-oops.canonical.com/oops.py/?oopsid=eddb1503e8421232ad7713cdada76c44
<wgrant> Hmmm
<infinity> Unless I'm blind...
<infinity> http://paste.ubuntu.com/1263001/
<wgrant> A 6s hole between those two queries this time
<wgrant> wat
<infinity> I swear that has the same OOPS twice.
<infinity> Are async jobs re-entrant? :P
<infinity> Okay, no, I'm blind.
<wgrant> Search for x-lazr-oopsid
<wgrant> There are two
<infinity> THere's the other OOPS.
<infinity> Evidently, scrolling through raw XML makes me go cross-eyed.
<wgrant> Yeah
<wgrant> So, all three OOPSes show the same thing, and none of them make much sense at all
<wgrant> Oh
<wgrant> Hmm
<wgrant> That's about the time it would parse P-a-s
<wgrant> But last I heard the appservers didn't have P-a-s.
<wgrant> But I wonder if it's retrieving the source's binary history
<wgrant> Which is quite a few binaries, IIRC
<infinity> It's a lot of everything.
<infinity> I think it's one of those source pages that times out, too.
<wgrant> It's also the only source package that regularly ENOSPCs our builders
<infinity> Only the PPAs, but yes.
<wgrant> Hm
<wgrant> The hole is right where it shells out to dpkg-architecture
<infinity> That makes no sense.
<infinity> Cause that call wouldn't be package-dependant.
<wgrant> No, and it could be something that's just nearby
<wgrant> Exactly
<wgrant> But there's indeed no P-a-s specified
<wgrant> And surely the scheduler doesn't hate us that much
<wgrant> infinity: I think Launchpad just really really doesn't like you
<infinity> wgrant: I'm not inclined to disagree with your analysis.
<wgrant> It probably saw your blueprint change this morning
<wgrant> infinity: Bug #1062638
<ubot2> Launchpad bug 1062638 in launchpad "Queue accepts occasionally time out due to huge non-SQL time in createMissingBuilds" [Critical,Triaged] https://launchpad.net/bugs/1062638
<tjaalton> anyone available to ack the precise-proposed upload for bug 966744?
<ubot2> Launchpad bug 966744 in xserver-xorg-video-intel "[i965] Resume from suspend leaves me with black screen or a screen of the desktop before it suspended. Compiz hung in intel_update_renderbuffers() from intel_prepare_render() from brw_draw_prims()" [Critical,In progress] https://launchpad.net/bugs/966744
<infinity> tjaalton: I can look at it.
<tjaalton> infinity: thanks
<tjaalton> updating the sru header atm
<infinity> tjaalton: You seem to be lacking bugs for the other patches?
<tjaalton> infinity: that's the info I added there :)
<infinity> Added... Where?
<tjaalton> to the bug above
<infinity> Oh, are you implying that all three patches address the same bug?
<tjaalton> [regression potential]
<tjaalton> yes
<tjaalton> well, the first one was a by-product
<tjaalton> when trying to reproduce it
<tjaalton> hmm or maybe not
<tjaalton> sigh, can't confirm it either way, since I added it to the branch late-august
<infinity> tjaalton: Yeah.  I mean, they all sound like valid and useful bugfixes, but the compiz/resume thing doesn't seem to relate to the output-attach/resume issue?
<infinity> tjaalton: There's no bug for the 106 patch?
<tjaalton> upstream bugs yes
<tjaalton> I'll check lp
<tjaalton> pretty hard to match them..
<infinity> tjaalton: Well, if there's no bug, there's no way to have a testcase to make sure it's fixing the bug, etc.  Sounds like the sort of thing we'd like to make sure is verified.
<tjaalton> woohoo, bug 992391 should match fdo 50078
<ubot2> Launchpad bug 992391 in xserver-xorg-video-intel "[i915] xserver freeze on switching VGA1/LVDS1" [Undecided,Confirmed] https://launchpad.net/bugs/992391
<infinity> Ahh, so it doesn't need to be on suspend, it can be triggered manually with display switching?
<infinity> Much easier to verify.
<infinity> And also a much worse bug. :P
<infinity> Can you give me a fresh upload with a bug closure in the changelog?
<tjaalton> yes
<tjaalton> seems like this was filed upstream too and then marked as closed, will check again if it really is the other bug..
<infinity> Sure.  You may have a third bug on your hands.  Worth checking before uploading.
<infinity> Cause these all sound like vaguely nasty behaviours.
<tjaalton> heh
<tjaalton> and actually, fdo 50100 references the commit in 50078 so I'll just add the bug closure there and ping the bug so they'll test it once it hits proposed
<tjaalton> infinity: uploaded, but I wonder if it works with the same version number?
<infinity> tjaalton: It does.
<infinity> tjaalton: The queue doesn't care, only the archive.  I'll just reject one.
<tjaalton> ah, cool
<infinity> tjaalton: Okay, that changelog looks better.  I'll double-check the diff when it comes through and you should be good to go if you didn't just introduce weird cruft or replace an X driver with a copy of frozen-bubble.
<tjaalton> heh, no the branch looks clean
<infinity> Yes, but it's my job to not believe you. :)
<tjaalton> of course :)
<infinity> Oops, no precise task for that second bug.
 * infinity fixes that.
<tjaalton> i can do that
<infinity> tjaalton: I don't care if there's all the SRU headers on that one, but do me a favour and make sure there's a clear test case somewhere.
<infinity> tjaalton: I already set up the task. :P
<tjaalton> heh, thanks
<tjaalton> ok I'll see if the test case works here
<infinity> Yeah.  The bug description itself IS a pretty good test-case, assuming it actually reproducibly crashes the server.
<tjaalton> right, _should_ be easy to hit
<Laney> ScottK: popey: anyone else: https://ubuntuone.com/1oBE6gcsZopYjcldngBqkr
<Laney> I had to do one additional fix, but it looks good to me now.
<Laney> I'm going to upload it to the queue.
<popey> what was the fix?
<Laney> same fix as Mirv did to Ubuntu-M but for Ubuntu-MI
<Laney> otherwise Ubuntu Light Italic comes out as Ubuntu Medium Italic
<popey> tested that fudged font on other platforms? (i.e. LO and other apps on Windows?
<Laney> no
<Laney> but I'm not going to upload it to windows :P
<popey> sure, but we don't want different binary versions of the font for different platforms really do we?
<Laney> if Windows is broken but Ubuntu is not then I wouldn't be too unhappy with a fork
<Laney> it's this or rustle up DM to do the fix with their real tools
<Laney> Qt is working as far as I can see too :-)
<popey> forking our own font because our own apps don't work with it seems sub-optimal to me.
<cjwatson> We're willing to patch our own non-font packages if need be
<Riddell> Laney: got packages to test?
<Laney> Riddell: queuebot will update you in 3...
<Laney> 2...
<Laney> 1 ...
<Laney> :(
<Laney> anyway, it is in the queue. Build that and try it out.
<Laney> I'll leave it up to others to decide whether to accept now or reject/accept on Monday
<Laney> out for a little while, bye
<popey> thanks Laney
<Riddell> Laney: fonts working good in Kubuntu for me
<Riddell> ScottK: ^^
<skaet> ^ Based on the fonts working ok for Riddell,  have accepted it.
<ScottK> Riddell: Thanks.
<cjwatson> so I know in outline what's wrong with aptdaemon, I think, but I have to get ready to go out for dinner
<cjwatson> I'll finish fixing it when I get back
<cjwatson> (just to save anyone else duplicating work on it)
#ubuntu-release 2012-10-07
<micahg> please don't copy libreoffice to the release pocket, see bug #1062757
<ubot2> Launchpad bug 1062757 in libreoffice "No menu bar under GNOME Shell & gnome-classic" [High,Confirmed] https://launchpad.net/bugs/1062757
<infinity> micahg: Ugh, again?
<micahg> yeah, it failed on arm* too, segfault
<infinity> Then it ain't getting copied anyway.
<micahg> right, I just noticed that afterwards though
<infinity> But it sounds quite buggy in general for an rc->rc bump. :/
<micahg> well, it says in the earlier changelog included 3.6.2.2, so I think the upstream versioning is wrong
<micahg> infinity: did you see tyhicks's comment in the openssl bug?
<infinity> Oh, no, haven't been back today.
<infinity> micahg: Thanks for the nudge.
<micahg> infinity: sure, when I saw the rejection e-mail I started panicking :)
<infinity> micahg: I'm still pretty sure that that upload is wrong, but I'm willing to buy the "works like precise" argument while people investigate further.
<infinity> It's at least conservatively consistent wrongness.
<micahg> yeah
<cjwatson> ^- test fixes only fixing FTBFS; webapps folks would probably appreciate a quick review
<skaet> cjwatson,  yup,  made sense when I was looking at it,  have accepted.
<skaet> cjwatson,   the grub2 one on the other hand....   who other than slangasek and yourself is best to review?
<cjwatson> skaet: I asked slangasek to review it when he woke up; he did have a one-line contribution to it after some testing, but I don't think it's anything that should recuse him from review
<cjwatson> aptdaemon> thanks
<skaet> thanks cjwatson.   :)   ok,  saw him in there as an author, so wasn't sure about the level.   Thats fine then.
<cjwatson> I tend to credit if in any doubt at all :)
<skaet> :)
<cjwatson> in this case he spotted a missing grub_errno cancellation
<cjwatson> and of course the general design of what we're doing was following his high-level instructions
<skaet> yes,  he's definitely the best choice for a second set of eyes then ;)
<smartboyhw> :)
<cjwatson> I think the remaining pieces following that upload are maintainer script code in grub-efi-amd64-signed to copy the loader image into the ESP, a shim-signed package once we get the MS signature, and a bit of fiddling in cdimage to use the signed loader
<cjwatson> so the end is hopefully in sight, as it'd bloody well better be by this stage
<cjwatson> oh, a corresponding grub-installer tweak too
<cjwatson> ah, good, aptdaemon built
 * skaet hoping the end is indeed in sight...  
 * smartboyhw hope for it too
<Laney> nah, the end is boring
<smartboyhw> Laney, oh is it
<skaet> Laney,  I like boring. boring is good.  ;)
<Laney> :P
<slangasek> grub2 LGTM
<slangasek> (accepted)
<Daviey> lets shake things up with a mass accidental sync from experimental.
<Daviey> WEEEEEEEEEEEEEEEEEEEEEEEEee
<slangasek> um
<slangasek> cjwatson: so based on upstream's comments, I think we should be ok to drop the -partition_offset 16 option?
<slangasek> cjwatson: or do you think we should pull 1.2.5?
<phillw> cjwatson: do you have time for a PM?
<cjwatson> slangasek: I'll read through the comments in detail tomorrow - haven't quite absorbed them yet
<cjwatson> phillw: feel free to leave a message
<infinity> slangasek / cjwatson: Based on my reading of the bug log, I suspect we'd be better off actually pulling the bugfix (either cherry-picking the commit he pointed to, or 1.2.5) than running with different options.
<phillw> cjwatson: the fate of PPC is pretty much, once again in you guys at -release, -kernel -xorg. We are running out of time for PPC. Could be carrying over a 'hatchet job' for 12.10 be done, with the issues being looked after (with hopefully a little urgency) to 13.04?
<infinity> slangasek / cjwatson: It is, after all, a 1-char fix.
<infinity> phillw: What do you mean a "hatchet job"?
<phillw> infinity: it would be a boot option, which I think debian are currently using?
<infinity> phillw: Note that PPC *does* work fine on some hardware, it's some specific X drivers that seem broken.  "It doesn't work on all hardware" probably isn't an excuse to release, but absoltely, getting those drivers fixed on that hardware would be shiny.
<infinity> phillw: Or, rather, some combinations of KMS and X drivers.
<infinity> phillw: Do you have exact boot options that people assume should work?  I'll test on my non-Apple hardware here and see if they generically apply in any meaningful way. :P
<phillw> infinity: I'm not a kernel person :) I did ask & get a patch from red-hat for kernel. but I am way out of my knowledge area here.
<infinity> phillw: Where's this patch?
<phillw> infinity: I can email you the full list from adam of all the bugs that are reported.
<infinity> Uhm, sure.  Does one of them have the patch referenced in it?
<infinity> Cause I do so enjoy treasure hunts.
<phillw> as A3 hit, 12.10 went from testing on VM to breaking both nvid and geof vid chip sets. as we have only few testers with the actual kit, this did rather muck up testing...
<phillw> infinity: email address to be sent to?
<infinity> adconrad@ubuntu
<phillw> infinity: email address not recognised?
<infinity> (.com)
<phillw> lol
<slangasek> infinity: what do you see in the bug log that indicates partition_offset 16 is needed?  The image I built without that option tests out fine under both UEFI and BIOS in a VM
<phillw> you should have incomming. that is all that has been discussed since i got the nVid bug fix into the kernel, which does not help PPC.
<cjwatson> phillw: I'm not taking responsibility for it.  Get a kernel/X person to say it should be done and I'll be happy to do that.
<cjwatson> The fact that all the mails about this are 3000 lines long with references to dozens of different long bugs is probably not helping!  People really need to learn the virtue of being concise.
<infinity> slangasek: My reading and understanding of the feature leads me to believe that it ends up being part of the whole "conservative in what you produce, liberal in what you accept" mantra.  I suspect most systems should boot perfectly fine without it, but "making it look like a conventional HDD MBR layout" is almost certainly going to fix booting on some broken/unforgiving firmware.
<cjwatson> (Frankly half the time I lose track of what's even being asked for.)
<infinity> slangasek: And, indeed, upstream points to that sometimes being the case.
<phillw> cjwatson: I know you cannot, and I'm also really grateful for telling PPC to "Go away"... but, PPC is now stuck between a rock & a hard place.
<phillw> *for you NOT telling*
<infinity> slangasek: Of course, he also points to partition_offset *causing* one failure he knows about WRT Mac booting, but I do wonder if that might have been a manifestation of the bug he just fixed. :P
<phillw> ~ 2 weeks left...
<cjwatson> No, it's stuck between nobody cornering a kernel/X person and GETTING A STRAIGHT ANSWER.
<infinity> slangasek: Either way, the bugfix is 1-character, seems not unreasonable that we should cherry-pick and test if it fixes your issue.
<cjwatson> It should take five minutes.  Please stop making it my problem!
<cjwatson> I'm sorry but I can't deal any more with reading through thousands of lines of stuff about this.  It shouldn't be this hard.
<phillw> cjwatson: well, as I don't have a private number to sabdfl, can you suggest someone who has the authority to bash their heads together?
<cjwatson> No.  Don't escalate to sabdfl.
<cjwatson> That's silly.
<cjwatson> I've pointed you to IRC channels - did you try?
<infinity> phillw: Have you tried finding the references to the EXACT bugs (not lists of them), perhaps patches people have tested even, and then taking those clear, concise references to the Kernel or X people?
<cjwatson> Did anyone try?
<cjwatson> Or did people just send thousand-line e-mails with all the bugs they'd ever heard of vaguely to do with powerpc?
<cjwatson> I'm sorry but I'm very frustrated by the nonproductive approaches.
<infinity> phillw: Either way, doomsday prophecies about the death of PPC aren't helpful either.  A broken video driver is a broken video driver.
<cjwatson> You have to be concise, and ask people who can do something about it.
<phillw> infinity: cjwatson there is one thing I have learned.... Adam has taken time to herd up the bugs. for L-QA I am pretty strict. but you must also know that a 'fail to actually get LiveCD', 'fail to install' made it hard.
<cjwatson> Because all those people are busy - which doesn't mean that you shouldn't ask them, but it means that you should be respectful of their time and not make them read through dozens of bug reports.
<infinity> phillw: You claimed there was a patch that fixes things.  You haven't yet actually referenced that patch.  It's this sort of thing we're talking about.
<cjwatson> Adam's mails are too long for me to be able to absorb.
<phillw> we lost B1 and B2 beacuse of what are actually video chip issues? Please do cut us some slack here?... please?
<infinity> phillw: Could be a lot less wailing and gnashing of teeth and a bit more "here's the patch we found".
<cjwatson> I've been trying to give gentle advice on this for weeks now ...
<cjwatson> But all I've got is extraordinarily lengthy mails and requests to just do hacky things anyway
<cjwatson> When I've said that the reason I'm not doing that is that I have no idea whether it would break something else
<cjwatson> And I am not qualified to decide
<cjwatson> If somebody who is qualified to decide looks at it and says sure, then I'm quite happy to do it
<cjwatson> If I'm actually told in clear and concise terms what to do
<phillw> infinity: well, let's try the other issue... working fine at A3, totally broken just after... had that been something like AMD64, it would have been screamed at as a regression? Pleae, for god's sake think I'm being agreesive... But, it did work and then got totally broken. I know PPC is low on the list, but... we did have it working?
<cjwatson> You asked some time after if we could regress the entire distribution to alpha-3 just for lubuntu powerpc.
<cjwatson> We would not have done that for amd64 either, because we can't.
<cjwatson> It's not possible.
<cjwatson> I would expect that if this had happened for amd64 then somebody would have taken the time to work out how to describe the problem in concise terms
<cjwatson> And work out what was architecture-specific, what was bootloader-specific, and what was video-card-specific
<phillw> infinity: as it got broken at a basic level, my suggestion to cjwatson was look at what we had then, that worked. I do not know enough of kernel stuff to understand if the ppc kernel <> AMD64 etc. It was just a reference point.
<cjwatson> And wouldn't have been conflating them all into amd64 being broken, because that's just unhelpful
<cjwatson> phillw: it doesn't work that way, for any architecture
<cjwatson> I redirected you away from that approach as a way to try to save you time from an unproductive approach
<cjwatson> There are millions of lines of code involved.  You have to investigate considerably more before you get down to the point where it's worth "looking at what worked back then", or reverting, or whatever.
<cjwatson> Targeted reverts are a tool in the armoury, but you don't reach for "revert the whole kernel across a month of development" as the first step.
<cjwatson> Yes, it is useful to know when something last worked, but there's much more to a sensible debugging process than that.
<phillw> cjwatson: which has been done, but the pointer forward is a fix from kernel / x-org team... Have we had any back from Adam's suggestions? The only one that got in was the redHat one, that infinity exlained better to me to ask to be included. I'm sure it has solved the i686 bugs etc, but it did not fix PCC.
<phillw> It solved some bugs, but not all of them. For that alone it was incorporating into 12.10
<cjwatson> AFAIK the nvidia fix you previously pointed to was already included.
<cjwatson> But obviously that's not relevant to radeon.
<phillw> and it also does not fix the nVid issue in PPC
<cjwatson> That's been buried in massively long mails.
<cjwatson> They were so long I hadn't even noticed.
<phillw> it is either a kernel fix (required) or a boot parameter.
<cjwatson> Then get a kernel guy to sign off.
<cjwatson> That's all I want.
<phillw> cjwatson: I'm really, really sorry to be pecking your head. You are clearly a guy who wants PPC to happen.
<phillw> cjwatson: is not infinity a kernel guy?
<cjwatson> If infinity decides that the boot parameter's the right thing to do, then I trust his judgement; but he's a foundations developer on my team, not full-time kernel.
<cjwatson> So I would respect his right to abstain.
<phillw> cjwatson: so, if no one will make a decision, is PPC dead?
<cjwatson> No, because that's been an exaggeration right from the start.
<cjwatson> Lubuntu powerpc might have trouble with this release.
<phillw> cjwatson: it can not pass the iso tests, so it will be dead.
<cjwatson> But there's more to powerpc than Lubuntu (e.g. see Ben Collins' recent posts on planet), and there's more than this release.
<cjwatson> Dead implies not getting back up.
<phillw> cjwatson: so there is a ubuntu / kubuntu / xubuntu version?
<cjwatson> Ben's been doing server work.
<cjwatson> The architecture is clearly not just about video card bugs ...
<phillw> cjwatson: I assure you, I'm much rather that L-PPC goes out with out with a release note than nothing at all. I'm also going to be tests for PPC-Server so we keep kate happy, that is not reliant on desktop video chips :)
<cjwatson> Not always generalising bugs encountered on powerpc to all of powerpc would really help.
<cjwatson> As I think infinity said above.
<phillw> Jonathan, one of the Lubuntu devs also will test PPC server on 'real kit'. All I want, honest.... please... just an insatallable system for 12.10 PPC? The stuff dropped late, took some finding out.. but...... can we get something working for 12.10?
<phillw> cjwatson: was Adam always as PITA as me? :D7
<cjwatson> Assuming you mean "o jordan" rather than infinity, I've not dealt with him much before.
<cjwatson> Begging really isn't helpful.
<Daviey> If anyone wants to review freeipmi, please feel free to reject if you feel the -Wunused-result is too intrusive... I actually don't think ti's worth it.... but MIR suggetsed it.
<Daviey> (my patch, so i won't sob)
<cjwatson> Daviey: I don't think it's too intrusive, but it's buggy.  You've declared _err_exit's second parameter as int, but are passing strerror() to it.
<Daviey> cjwatson: Ah.
<Daviey> I suck.
<cjwatson> And you seem to be using it from different translation units without a header declaration, which is confusing
<cjwatson> It kind of looks like you meant this to be varargs or something, but that's probably OTT in context.  You could just pass errno (being careful to call it something else in the formal parameter) and append : %s directly in _err_exit, then exit 1 or something
<cjwatson> The rest of it looks fine, but check over the compiler warnings since this looks as though it should have triggered some ...
<Daviey> Yes, looking now, i can see warning: passing argument 2 of '_err_exit' makes integer from pointer without a cast
<cjwatson> Daviey: so rejecting for now, but happy to review a corrected version tomorrow if nobody's done it before I fall back out of bed
<Daviey> I won't touch it before i awake. Thanks for looking.
<Daviey> A maas package is just about to hit the queue which is quite intrusive, please do not accept it.  I want to review in the morning.
<Laney> you should reject it then :-)
<infinity> Daviey: Yeah, just reject it and review and accept it from REJECTED in the morning.
<infinity> Daviey: Much saner than trusting everyone to read backscroll. ;)
<Daviey> Good thinking
#ubuntu-release 2013-09-30
<stgraber> that one is mine, diff should be fairly straightforward. I mostly noticed the crash on Ubuntu Touch, though I've had reports (by e-mail, no bug report) of it also happening on standard machines that have weird network devices.
<stgraber> (and yes, I fixed the patch name in the previous changelog entry because it was bugging me)
<infinity> stgraber: Accepted.
<stgraber> thanks
<didrocks> Laney: I guess the qtsystems-opensource-src is easy (and pinned by the lubuntu discussion we had, I didn't check, but that's what Mirv told in term of rdepends)
<Laney> +Forwarded: no
<Laney> Mirv: know why that's the case?
<didrocks> Laney: when I read the diff, I guess it was because it's an hack
<Laney> The kernel part got wontfixed
<Mirv> Laney: it got wontfixed, but I'm not sure if it's something that wouldn't be fixed later on since it's clear the driver has stubbed functions.
<Laney> Mirv: I think that means we'll end up carrying the patch indefinitely until someone else gets around to fixing it
<Laney> I'm worried that we change the specification of the function for everyone unilaterally without seeking upstream's input
<Laney> ScottK: thoughts?
<Laney> Some kind of whitelist of known-broken devices might be ok
<ScottK> Laney: I agree with you.
<ScottK> Upstream review should be sought before something like this is done.
<ScottK> I'll be offline mostly today, so I can't provide much help.
<Mirv> Laney: ok, I'll file an upstream bug about it. there's not much people looking at qtsystems though, so there may not be a quick answer. but we essentially took over qtpim development already, so if we need qtsystems a lot we can start pushing that too.
<Laney> Mirv: took over upstream?
<Mirv> Laney: wrong wording, but I mean renato from our side has become the only upstream contributor pushing changes at the moment.
<Laney> ah
<Laney> well, having upstream commit is great and the way things should work
<Laney> Mainly I think changing behaviour in Ubuntu-specific ways indefinitely is a bad idea
<Laney> Mirv: Could you check if it's feasible to do the whitelist?
<Laney> QtSystems has API to get the device at least
<Laney> (Not sure if it works in this case though)
<Mirv> Laney: I now proposed the rsalveti's patch as is to upstream and added the links to the packaging branch. rsalveti may comment on the feasibility of the whitelisting.
<Mirv> so both filed a bug https://bugreports.qt-project.org/browse/QTBUG-33748 and a branch fixing it
<Laney> Mirv: thanks
<Mirv> those ido + indicators miscellaneous small fixes ^ tested by me on desktop (autopilot unity7 + manual tinkering with the indicators) and psivaa on touch
<stgraber> oh looks like the queue grew quite a bit overnight, I'll finish to deal with something then go through all of those (in 20min-ish)
<rsalveti> Mirv: you probably know more about qtsystems internals than me :-) All I gave at that bug was a workaround to disconnect signal from actually knowing if the device is valid
<rsalveti> Mirv: we might just ask help from renato then, as he seems the only one changing it lately
<rsalveti> whitelist sounds a better idea, but need to check what api to use, and -enotime this week
<Laney> what is the point of that libfriends upload?
 * Laney asks in The Other Place
<diwic> uhm, are we frozen? We usually unfreeze between "Final Beta" and "Final Freeze"
 * diwic just uploaded a PulseAudio to fix a few crashes
<smartboyhw> diwic, see https://lists.ubuntu.com/archives/ubuntu-release/2013-September/002605.html
<apw> diwic, actually we normally are in this half way not frozen but everything gets looked at phase in between
<stgraber> diwic: so the dbus part of the upload seems like a feature change to me (removal of dbus support). Can you confirm that nothing in any of our supported images (all flavours) use that module?
<cjwatson> diwic: We haven't unfrozen in this phase since at least the quantal release cycle.
<cjwatson> Compare e.g. https://lists.ubuntu.com/archives/ubuntu-devel-announce/2013-April/001030.html
<diwic> stgraber, it was not used in 13.04, experimentally enabled in 13.10 because I thought upstream has fixed things, but it still causes crashes.
<stgraber> diwic: Based on the changelog it looks like you neabled the module around a month ago, is that right?
<diwic> stgraber, so no, I can't give you a guarantee, just that I would be surprised of something in our official flavours actually used it.
<cjwatson> diwic: IIRC pulseaudio is in touch images; doesn't this need landing approval from the touch people?
<diwic> cjwatson, I asked didrocks on friday if it was okay to upload a PulseAudio with stuff that only touches things that we don't make use of on the phone and he said ok
<diwic> stgraber, something like that. If you ask me to verify, I would look into the same changelog to do that :-)
<didrocks> yeah, it was okay (and it's still)
<cjwatson> diwic: OK, cool
 * cjwatson lets stgraber carry on reviewing ...
<stgraber> ok, so based on the limited time in the archive (so unlikely that anyone actually noticed and made use of it) and the fact that it's causing a segfault in some cases, I'm granting an FFe on that and will let it through
<diwic> stgraber, ok, do I need to do any paperwork for the FFe?
<stgraber> diwic: nope, paperwork is the past 10 lines of IRC log
<diwic> stgraber, ok, thanks :-)
<stgraber> ^ what happened there? :)
<Riddell> stgraber: my scripts got ahead of themselves, it's not released upstream yet
<stgraber> Riddell: ok :)
<Laney> stgraber: btw I queried the libfriends upload, maybe leave that one for now
<stgraber> Laney: ok, will do
<Laney> (appears to do nothing)
<stgraber> seb128: is the Uploaders change intentional in that gtk upload?
<diwic> the "Unpacking replacement friends ..." line in my log was slightly amusing. :-)
<Laney> stgraber: that is automatic
<stgraber> Laney: ah? does it somehow sync that with Debian when generating the source package?
<seb128> stgraber, that's control.in->control from the pkg-gnome tools
<cjwatson> It's an intersection of a list in pkg-gnome-tools with the last N entries in the changelog, IIRC
<seb128> stgraber, it builds the upload list from the changelog most recent entries
<Laney> It takes the last x uploaders and intersec
<Laney> yeah
<stgraber> ah, interesting, ok.
<Laney> Mirv: looks like QtSystems can't give you the model on N4
<stgraber> hmm, weird that click didn't get auto-accepted, let me quickly check why
<stgraber> ok, that's because it's in ubuntu: supported (and as a result in the packageset), alright, waiving through
<Laney> there's 10-ish outstanding FFes too
<seb128> Laney, it reads the model from /sys/devices/virtual/dmi/id/product_name ... is that available on the n4?
<Laney> seb128: nope
<seb128> Laney, then it should fallback to libhybris
<cjwatson> stgraber: thanks
<seb128> Laney, getprop ro.product.model
<Laney> seb128: in qtsystems itself?
<seb128> Laney, no, u-s-s
<Laney> not talking about that
<seb128> oh, ok
<seb128> sorry, ignore me then
<Laney> :P
<seb128> qtsystems only knows to read /sys/devices/virtual/dmi/id/product_name
<seb128> Laney, that's https://bugs.launchpad.net/ubuntu/+source/qtsystems-opensource-src/+bug/1197542
<seb128> Laney, see comment #10 there
<stgraber> looking at all those indicator related uploads now
 * Laney nods
<Laney> so I don't know if this whitelist idea can be implemented in qtsystems
<seb128> Laney, I didn't follow the discussion, what's the whitelist for?
<Laney> seb128: https://bugs.launchpad.net/ubuntu/+source/qtsystems-opensource-src/+bug/1231196
<Laney> it got accepted anyway (should have rejected if I wanted to block it)
<seb128> ok
<stgraber> and back to an empty queue!
<Laney> nice
<Laney> Riddell: bug #1222128 might interest you
<Laney> (the bot has been irritatingly broken for ages)
<Riddell> 15:50 < ubottu> bug 1222128 in Ubuntu "[FFe] [needs-packaging] kqoauth" [Wishlist,New] https://launchpad.net/bugs/1222128
<czajkowski> slangasek: ello :)
<slangasek> czajkowski: hey there
<Laney> I imagine someone other than me would be more qualified to look at http://pad.lv/1218530
<slangasek> Laney: ok, done
<Laney> ta
<czajkowski> slangasek: re the workspace not working and it was last week and now no longer isn't the regression tag a useful tag ?
<slangasek> czajkowski: that tag is for regressions in stable updates
<czajkowski> ahh
<czajkowski> ok
<czajkowski> thanks for clearing it up
<slangasek> not that your bug shouldn't be fixed, but the SRU team doesn't want to receive bug mail about it ;)
<czajkowski> slangasek: good to know :)
<stgraber> seb128: what happened to that poor evolution-data-server changelog?
<stgraber> (if that's even you who uploaded that one, the diff is pretty confusing ;))
<stgraber> Riddell: hmm, that user-manager upload looks like it has new features...
<stgraber> Riddell: (if you say it doesn't, I'll read much closer but added dependencies and a bunch of new files isn't usually a very good sign)
<infinity> stgraber: That eds looks like an almost-sync-but-not-quite.
<infinity> Diff looks fine but, yeah, losing all the Ubuntu history/context in the changelog is a bit irksome.
<stgraber> infinity: yeah, looked like a sync at first but not quite, I guess I should pull the resulting changelog to see what's the end result :)
<stgraber> it also does say "sync with Debian" and then "remaining changes" which to me sounds wrong, that's a merge and a merge should keep the changelog history (merge-changelog is usually pretty good at that so why not use it...)
<infinity> Wait, there's a tool for that?  I always do it by hand when MoM can't do it for me.
<stgraber> merge-changelog 1 2 > 3 :)
<infinity> Does someone still have a hardy chroot kicking around?
<infinity> Oh, nevermind.  I was going to ask if tar's compression autodetection works in hardy, but that was apparently added in 2004...
<pleia2> infinity: heads up, http://www.ubuntu.com/community/participate included in release announcements is a 404, I submitted a bug to have them redirect to community.ubuntu.com (it's private, I can sub you if you'd like)
<stgraber> pleia2: why is it private?
<stgraber> (I don't really care about the bug, just wondeirng why a bug about an existing problem on a public website is private)
<infinity> pleia2: Oh, fun.  It should perhaps redirect to http://community.ubuntu.com/contribute/
<infinity> Maybe.
<pleia2> stgraber: all website content bugs are by default
<infinity> Or maybe just to the root.
<infinity> I don't remember what was on the old page.
<infinity> Yeah, probably best to send it to /contribute/
<stgraber> pleia2: that seems wrong, but ok...
<balloons> does anyone have an insight on who is doing signoff for the server images?
<infinity> balloons: I did for the beta, but we probably want someone from the server team to do it for final.
<infinity> rbasak: ^
<balloons> infinity, I figured it was you :-) I was hitting a dead end on trying to track someone from the server team down who knew enough to handle this.
<infinity> balloons: Well, we could escalate all the way to robbiew if we can't find anyone to take responsibility, but let's see if rbasak responds first. :P
<seb128> stgraber, what's wrong with it?
<infinity> seb128: It dropped all the Ubuntu changelog entries.
<seb128> yeah, we never keep old changelog entries when merging desktop packages
<seb128> it's annoying to merge back, it wastes space and it's not useful
<seb128> we have launchpad for a record of uploads
<seb128> think about it as a direct sync and then, oh, we have a diff again there ;-)
<seb128> infinity, stgraber: jbicha has a "sync on debian" stacked in the vcs so I included that rather than having to play revert (the actual diff out of the changelog is quite small)
<infinity> It loses history if one wants to know when something was changed.  Digging through all revisions on LP is a pain.
<apw> did we say there was a handy tool for the merge
<infinity> apw: merge-changelog, apparently.
<apw> oh yeah thats the baby, seems to be pretty simple
<seb128> infinity, so what do you do when a package can be synced and then has ubuntu diff again?
<seb128> infinity, do you go add back all the previous ubuntu diff history to the changelog?
<infinity> seb128: That's different.  If it can be synced, one assumes that the Ubuntu bits have ended up in Debian, thus are represented in the Debian changelog.
<seb128> well, they are represented in the merge summary the same way they would be in a debian changelog entry
<infinity> (including some sort of attribution, perhaps, which one loses if you remove history)
<seb128> well, anyway, we have been dropping changelog history consistently for desktop stuff for over 9 years
<stgraber> seb128: I don't think your merge summary contains the name of who added the individual bits and when those were introduced, and it turns out it's pretty useful information when debugging stuff
<seb128> ^
<seb128> that's what we do accross desktop for ever
<seb128> you liking it or not doesn't seem a release team topic
<seb128> if you want us to change that go to the TB
<stgraber> doesn't necessairly make it right ;)
<seb128> (sorry, not wanting to be harsh, just trying to not start an endless argument on who prefers what)
<seb128> sure
<seb128> but let's agree to disagree
<seb128> if you care enough, take it to the TB
<rbasak> infinity, balloons: I'll raise it in the server team irc meeting tomorrow. Thanks for asking - it'll be nice to have someone lined up and scheduled to do it rather than a last minute scramble to find someone.
<stgraber> and have the TB say what? please respect the existing procedures on merges? because I'm pretty sure what infinity and I are saying is what's been documented for ages as the procedure to make merges
<stgraber> we've even wrote tools to do just that ;)
<rbasak> I wonder how we could make sure that someone is nominated each release for this without you having to chase.
<balloons> rbasak, if you can, please let me know who you pick
<rbasak> balloons: will do.
<infinity> rbasak: Well, it would have been fine if the person who "owned" the product hadn't quit. :P
<seb128> stgraber, recommended != required
<stgraber> rbasak: so we have a sign-off contact entered next to the product name on the tracker. If you let me know ahead of time I can update the field to reflect reality
<rbasak> OK - thanks!
<balloons> rbasak, infinity yes, basically we need someone to take over the reins from Daviey on this one :-)
<seb128> stgraber, that's a pretty stupid rule imho, because as said, sync loose changelog history anyway and we have full history in launchpad in any case
<infinity> seb128: It's not worth arguing about.  My biggest concern is actually just attribution, nothing else.  A sync should retain attribution because the Debian maintainer should mention the patch contributor when he takes the patch.
<infinity> seb128: A merge without history makes it look like the last uploader "owns" all the modifications.
<infinity> (Proper DEP-3 headers in patches fixes that, but not everyone uses quilt, and not everyone uses proper headers when they do use quilt)
<seb128> infinity, would you be happy if we put the author in the merge summary?
<infinity> seb128: Or in the patches, if you're doing quilty things (and maybe you already do that religiously).  In which case, meh.  Lost history is annoying, but not world-ending.
<infinity> Either way, this isn't worth having a debate about on a Monday.
<infinity> Cause, well.  Monday.
<infinity> Screw Monday.
<seb128> infinity, we tend to do tag patches yes, and as said, launchpad has the history
<seb128> -changes lists as well
<infinity> LP's history isn't meaningful for someone who downloads a source package.  But properly tagged patches works for me for the blame/attribution game.
<seb128> infinity, we have vcses for history as well
<seb128> or bzr blame
<rsalveti> can someone approve libhybris? adding another functional call needed by gstreamer to fix an issue with playbin/platform-api in touch
<stgraber> I'll take a look
<rsalveti> thanks
<stgraber> done
<rsalveti> thanks
<cjwatson> infinity: fakeroot/critcl> well spotted
<cjwatson> oho, lilypond/i386 stuck to the wall this time
<cjwatson> I'm working on a Debian QA upload for kinput2
 * infinity is fixing openmpi1.6
<infinity> Man, I'd give good money for the new apt-cacher-ng to stop randomly stalling...
<infinity> Or maybe I'll just give up on clever caches and run squid on my laptop.
 * cjwatson shaves yaks.  Need to QA-upload wnn6-sdk first
<infinity> That mpfr4 testsuite hang on armhf isn't making me the happiest of campers.
<infinity> 20-to-1 odds say that switching to gcc-4.7 "fixes" it.  And then doko hits me.
#ubuntu-release 2013-10-01
<Mirv> rsalveti: I really just package it, I haven't looked at the code (qtsystems). Renato was working on qtpim, not qtsystems, so I think there isn't anyone truly familiar with it.
<rsalveti> Mirv: right, no worries, I can take a better look once this multimedia stack lands
<ScottK> ^^^ security fix.
<slangasek> ScottK: do you need someone to review it, then?
<ScottK> Yes.  Review/accept since it's my uplaod.
<ScottK> It's closely based on what the security team did for precise where the package is in Main.
 * ScottK sleeps (since the alarm goes off in < 3 hours).
<slangasek> accepted
<infinity> slangasek: Gold star for the insighttoolkit
<infinity> ... upload
<slangasek> infinity: I'm sure I don't know what you're talking about; it's the middle of the night and I'm asleep
<infinity> slangasek: Are you claiming the NSA backdoored your PGP key?
<infinity> slangasek: (... and used that backdoor to fix bugs in... Ubuntu?)
<slangasek> no, merely suggesting that you're asleep
<slangasek> and dreaming
<infinity> I'm neither elated, confused, or terrified, I can't be dreaming.
<slangasek> and while the dream me is flattered to be included, this is probably not healthy
<slangasek> ok, off to bed. 'night. :)
<infinity> slangasek: Toodles.
<sgran> is this the right place to ask questions about the cloud-archive?
<sgran> I expect not, but I can't find a link to an IRC channel
<smartboyhw> Ubuntu Release Team: I'm not understanding something. After UIF and DocStringFreeze we are supposed to send emails to ubuntu-doc and ubuntu-translators right? I didn't see any of these e-mails sent to these mailing lists, and I don't believe there has been uploads without UI changes in the past few days
<smartboyhw> s/has been uploads without UI changes/all uploads are without UI changes/
<Laney> if you have an example, please raise it
<xnox> smartboyhw: do note, e.g. packages on ubuntu touch images have a standing exception, so those do still change.
<smartboyhw> xnox, I know
<smartboyhw> Laney, I don't know if I'm correct, but I saw gnomeradio having icons removed (does that deserve a UIF?)
<Laney> it's not installed by default, so no
<smartboyhw> Um, - Added option to disable audio loopback mode in Preferences settings. looks like a much better one
<smartboyhw> Laney, ^
<Laney> which package?
<smartboyhw> Laney, gnomeradio
<Laney> not installed by default: not covered by UIF
<Laney> https://wiki.ubuntu.com/UserInterfaceFreeze
<smartboyhw> Hmm
<xnox> smartboyhw: typically UIFe are for things which have screenshots in documentation from default installs (ubuntu, edubuntu, xubuntu, lubuntu, kubuntu, etc) which blindly rewrite complete UI and thus confusing help / documentation readers. But minor tweaks and bugfixes are ok, "e.g. remove broken button" and etc.
 * smartboyhw needs to check something then
<smartboyhw> Hmm, I might not need a UIFe then
<smartboyhw> xnox, any good tools to check if one package is in the seeds/metas?
<smartboyhw> (all of them)
<cjwatson> seeded-in-ubuntu
<smartboyhw> Default install != supported (I believe). Yeah, no need UIFe:P
<smartboyhw> (supported seeds)
<cjwatson> sgran: #ubuntu-server would probably know more - the cloud archive is a kind of bolt-on thing and the release team proper doesn't run it
<sgran> cjwatson: thanks, I'll ask there
<ScottK> slangasek: Thanks.
<doko> infinity, the mpfr issue is a wrong-code issue. in th works ...
<Riddell> kde 4.11.2 going up, here comes the flood
<Laney> queue mute #ubuntu-release
<Laney> worth a go
<Laney> queue mute unapproved #ubuntu-release
 * Laney goes away
<cjwatson> Hm, better rebalance i386/amd64 builders then
<cjwatson> (done)
<Riddell> cjwatson: why the need for a rebalance and what elite powers enable you to do that?
<infinity> doko: Awesome, thanks.
<infinity> Riddell: We had all but one builder on i386 to finish the test rebuild.
<cjwatson> Riddell: we had 7 i386 / 1 amd64 in order to try to finish the test rebuild faster
<cjwatson> Riddell: powers> ~launchpad-buildd-admins
<cjwatson> Riddell: this is all a workaround for not having cross-architecture builder pooling in LP, though
 * Riddell learns new things
<infinity> I think I'll work on fixing that around release week, or the week after.
<cjwatson> The main thing I can't quite work out is how to calculate/represent queue lengths with pooled builders
<cjwatson> Since the queues would no longer be per-architecture, and would sort of overlap in complicated ways
<infinity> cjwatson: Queue lengths shouldn't be hard to estimate, it's just the general potential uglification of /builders I haven't quite figured out how to deal with.
<cjwatson> I think the processor column has to just become a list of architectures per builder, but I have no idea how to adjust the "build status" sections
<cjwatson> The actual dispatch bit is easy enough ...
<infinity> cjwatson: The queue status, you mean?  That should still be per-arch.  I don't see it changing much, except that the number of builders per arch will go up, as it'll account for every builder that can build that arch.
<infinity> cjwatson: The math to sort out the actual queue time isn't rocket surgery and shouldn't lead to results that are any more of a lie than the current lies.
<cjwatson> infinity: But if we have 8 builders that can do either i386 or amd64, saying "amd64 8; i386 8" is grossly misleading
<cjwatson> infinity: Even worse for the PPA case where (IIRC) some of the builders can do i386 amd64 and some can do i386 amd64 armhf
<infinity> cjwatson: Nah, it's true.  There are 8 builders capable of building that arch.
<infinity> cjwatson: Also, all the PPA machines are x86_64 now.
<infinity> cjwatson: Pretty sure I checked that last time this came up.
<cjwatson> Yeah, but I think only the multi-guest ones can do armhf
<cjwatson> It may be true, but I think it needs some refinement to be intelligible
<infinity> cjwatson: Nope, everything can do armhf.  It's built into lp-buildd (well, if the qemu-user-static bits are installed)
<infinity> That doesn't mean we want to allow all of them to do it, mind you.
<cjwatson> And are they installed everywhere?  I thought I understood from wgrant that that wasn't true.
<cjwatson> Right, so whether it's policy or capability, the effect is the same
<infinity> cjwatson: Not sure if everything has qemu-user-static installed, but that's easy to fix if that's the result we want.
<infinity> cjwatson: Anyhow, I'm okay with the reporting of "builders that are allowed to build this arch", even if it has overlap.  And calculating potential queue depth from there is not particularly hard, with a bit of fudging.  And that algorithm is all about fudging already.
<cjwatson> I think I'd prefer a refactored build status table, separating "number of builders" from "queue length"
<cjwatson> Perhaps
<cjwatson> Or perhaps with some indication of how many builders are shared
<cjwatson> Something like that ...
<infinity> Well, we can redesign the page whenever.  That's less interesting than doing the pooling and making the queue not be completely inaccurate.
<infinity> The dispatch bit is ridiculously easy, since build records already come out in the order we want them.
<cjwatson> I wonder if that's actually true
<infinity> cjwatson: It is in all cases except a missing build created post-upload.
<cjwatson> Are we sure that, given long i386 and amd64 queues, it wouldn't do all of one architecture first and then the other?
<cjwatson> There's nothing today that would prove that one way or another
<infinity> cjwatson: But on a fresh upload, when 5 builds are created, the records are sequential (or close enough) and have the same score.
<infinity> cjwatson: So, if you use the score and the ID, you can get them out in the order that's sane.  Score alone isn't enough.
<cjwatson> If it's score then id, or similar, then fine
<cjwatson>         order_clause = " ORDER BY buildqueue.lastscore DESC, buildqueue.id"
<cjwatson> Yeah, that looks OK
<infinity> cjwatson: It actually has the curious side-effect, if dispatched correctly, to fix arch skew issues that you have on mismatches builder pools.
<infinity> cjwatson: Cause all arches should always dispatch for the same source at almost the same time on pooled arches.
<cjwatson> Well, in that case the work is something like (a) add many-to-many builder/processor DB table (b) add model/browser code to represent that and let us edit it in the API/UI (c) populate production data (d) change dispatch code and /builders to look at many-to-many table rather than single-processor mapping (e) clean up old DB bits at leisure
<cjwatson> infinity: Yeah
<cjwatson> I guess I'm spending today retrying KDE dep-waits in the right order
<infinity> Someone should have muted queuebot.
<cjwatson> At least the ones that aren't automatically determined
<Laney> I tried and floundered
<Laney> there's still time if you know the syntax
<cjwatson> mute queue saucy-proposed
<queuebot> Added mute entry: ['#ubuntu-release', 'queue', 'saucy-proposed']
<infinity> Hah, Google just got me there.  2 seconds late.
<infinity> doko: How long did the full rebuild test take on armhf?
<infinity> (Not counting esys-particle)
<infinity> I need to patch that to build a -data/-common/whatever package and put all those images in it.  Crazy build times.
<cjwatson> Or NO_PNG_PKG_MANGLE=1 if it doesn't make much size difference
<infinity> Oh, or that, even if it does. :P
<cjwatson> Well, if it does, optimise things statically first
<infinity> But duplicating all that data in every arch:any package is Wrong(tm) anyway.
<cjwatson> Not that I care that much since it isn't on images
<infinity> A proper patch submitted to Debian seems saner.
<cjwatson> Yeah
<infinity> esys-particle_2.2.u1-2_armhf.deb (200.4 MiB)
<infinity> It ain't tiny.
<cjwatson> Hah
<infinity> Curious how much the png optimisation saves.
 * infinity grabs the source and tries a no-mangly build.
<cjwatson> Riddell: What are the deepest bits of the build-dep chain here, and I'll accept them first?
<infinity> kdelibs, usually.
<cjwatson> It'd save a lot of time not to have to go round retrying things later because Kubuntu people never do :-P
<cjwatson> infinity: IME there are several, though
<infinity> cjwatson: kdelibs, kdepimlibs, kde-runtime are the ones I recall.
<cjwatson> all the kdepim stuff, kde-workspace - I just don't know the ordering
<infinity> And I don't actually see a kdelibs upload...
<infinity> Well, kde4libs.
<infinity> Ahh, cause it was done 18h ago.
<infinity> Yay for that.
<cjwatson> So kdepimlibs is probably pretty much at the bottom
<cjwatson> Oh, there's akonadi, soprano, nepomuk in those build-deps
 * cjwatson goes for nepomuk-core first
<Riddell> cjwatson: I already accepted them
<Riddell> https://wiki.kubuntu.org/Kubuntu/Ninjas/DependencyGraph for the gory details
<Riddell> a widescreen monitor helps with that one
<cjwatson> Ah
<cjwatson> Well, let me know if there's anything you particularly don't want accepted early
<cjwatson> w/g 23
<cjwatson> oops
<cjwatson> infinity: I tried a full britney analysis run on universe, which has now been running for 14 hours (and there's no way to tell how far it's got).  I'm going to kill it and try a different approach
<cjwatson> I assume it was stuck in NP-complete hell
<infinity> cjwatson: Eek.
<infinity> cjwatson: I'm guessing that's probably a sign of things being excessively broken?  It really shouldn't take that long to run, I'd think?
<doko> infinity, didn't look that close. below one week
<infinity> cjwatson: Did you try on just a single arch first?
<cjwatson> No
<cjwatson> Not sure I believe time's output
<cjwatson> real    849m23.490s
<cjwatson> user    0m1.236s
<cjwatson> sys     0m0.200s
<cjwatson> It was sitting at 100% CPU for most of that time
<infinity> doko: Hrm.  Kay.  I might still try to get a glibc 2.18 done this week, then, and we could do an armhf-only rebuild to see if there are any obvious regressions.
<cjwatson> infinity: I probably need to rebase that britney instance on top of the one in proposed-migration, which has Debian's performance work
<infinity> doko: Sadly, there are glibc testsuite regressions on 2.18 on armhf that I'd like to try to sort.  Not sure if they'll bubble through to packages, though.
<cjwatson> infinity: But, easier approach: just get proposed-migration to dump out a list of uninstallables as well as the count
<cjwatson> It already has that information to hand
<infinity> cjwatson: Oh sure, that wouldn't be a bad start.  If we clean that up, maybe your full run won't take 17 days. :P
<cjwatson> Hm, in fact it seems to have an option for that already
<infinity> cjwatson: So, if you're curious, a non-mangled esys-particle is about 60MB larger.  And builds in 26 minutes instead of 8 hours on x86.
<infinity> Probably worth doing the split and submitting to Debian.
<cjwatson> Mm, yeah, and probably worth optimising the PNGs statically then
<infinity> Eating one x86 buildd for 8 hours is alright.  Eating one on every arch hurts.
<infinity> (Or pre-optimising in the source, sure)
<cjwatson> So, most of the uninstallables are because britney doesn't understand udebs
<infinity> cjwatson: She doesn't?  In what sense?
<cjwatson> Claims they're uninstallable
<cjwatson> I don't know exactly why but this tallies with mutterings I've heard from the Debian release team :)
<cjwatson> The uninstallables report takes an extra 30 seconds to generate, but I think that's acceptable :)
<infinity> The udeb thing shouldn't be that hard to solve, one would think?
<cjwatson> (And it doesn't block promotion)
<cjwatson> infinity: Probably not
<infinity> It is because there are some base deps provided by the d-i initrd that britney just doesn't know about?
<infinity> I mean, ultimately, they're just debs.
<infinity> Just really sketchy ones.
<cjwatson> It probably needs the same algorithms germinate has to follow dependencies in the right world
<infinity> I like how they're almost the inverse of click packages, in the sense that many udebs are nothing BUT maintainer scripts with complex dependencies.
<cjwatson> infinity: http://people.canonical.com/~ubuntu-archive/proposed-migration/saucy_uninst.txt
<cjwatson> I'll see if I can work out the udeb thing - it might just be a matter of inserting faux packages
<infinity> And the very top of the list is something that should be arch-restricted.
<cjwatson> It's Architecture: all
<infinity> Yes, I know.  I'm arguing it probably shouldn't be.
<cjwatson> There'll probably be several of those showing up on i386
<cjwatson> Yeah, perhaps
<infinity> Sadly, the crossbuild stuff fails due to britney not groking multiarch.
<infinity> And wine is in that camp too, IIRC.
<infinity> Overall, though, this isn't as bad as I thought it would look.
<cjwatson> The udeb things might actually come down to incorrect kernel Provides
<infinity> I thought we'd mostly fixed the kernel provides issues?
<cjwatson> Ahaha no not for udebs
<infinity> Cause when they go wrong, component-mismatches has a hissy fit and tries promoting random universe kernels.
<cjwatson> kernel-image-BLAH is meant to provide FOO-modules for the various things that would be in *-modules-BLAH but are actually built in
<cjwatson> But the Ubuntu kernel team has never got this right
<infinity> apw: ^
<infinity> I know someone who'd be happy to get it less wrong. :P
<cjwatson> I wonder if I can figure out the proper list
<cjwatson> (Please wait a week while I update my saucy kernel remote :P)
<infinity> Anyhow, a good chunk of this goes away when we clean up the last of NBS.
<cjwatson> Yep
<infinity> And the udebs things are mentally filterable.
<infinity> All in all, it's way less ugly than I thought it would be.
<apw> infinity, i am listening
<cjwatson> I can certainly work on cleaning some of this up
<infinity> apw: The two lines above where I paged you. :)
<apw> and yes if there is something linux-image-foo.udeb should be providing to make your life easier we can do that
<cjwatson> kernel-image-foo.udeb but yeah
<cjwatson> I'll hopefully be able to come up with a patch shortly ...
<apw> so i assume that is any udeb which becomes empty, we should provide ... ish
<apw> cjwatson, well i am in testing mode for various things, so now is a very good time
<cjwatson> Anything that's depended on by other udebs and that is built in
<cjwatson> In practice, mostly filesystems
<cjwatson> That's very probably what all the partman-* output there is for, along with all the other stuff that's in stages of d-i after partitioning
<cjwatson> Since they tend to depend on (virtual package meaning that partman is done)
<apw> we have typically not understood the udebs relationship to d-i well enough, and made a hash of it as a result
<cjwatson> I'm at 11% of "git remote update saucy" :)
<apw> this is a good time to repair that and once done to get some knowledge transfer into the team to keep it fixed
<cjwatson> So, here's my logic
<apw> in the good-old-days (tm) i would have suggested a bar session at UDS for this
<cjwatson> view http://archive.ubuntu.com/ubuntu/dists/saucy/main/debian-installer/binary-i386/Packages.gz
<cjwatson> After a bit of "what's the underlying problem" you get to (say) partman-basicfilesystems
<cjwatson> Depends: cdebconf-udeb, dosfstools-udeb, e2fsprogs-udeb, ext2-modules, fat-modules, partconf-mkfstab (>= 1.09)
<infinity> And nothing provides ext2-modules, fat-modules, and the world explodes?
<cjwatson> cdebconf-udeb, dosfstools-udeb, e2fsprogs-udeb, partconf-mkfstab are real packages not listed as uninstallable
<cjwatson> fat-modules-3.11.0-9-generic-di Provides: fat-modules
<cjwatson> But nothing Provides: ext2-modules
<infinity> Oh, fat's not built in?
<cjwatson> Not on i386 anyway
<cjwatson> Maybe on other architectures - the kernel-wedge framework has plenty of provision for this being arch-specific
<apw> infinity, on arm probabally but here not so much
<cjwatson> ext2 is probably built into the kernel, and the way you tell d-i this is by having kernel-image Provides: ext2-modules
<cjwatson> Similar to the way that fs-core-modules Provides: *-modules for the filesystems it builds
<cjwatson> d-i has probably actually been warning about this for ages but it hasn't mattered so much
<infinity> Hah, no.  fat-modules-udeb exists solely to ship msdos.ko, I think.
 * apw wonders if the d-i logs have the info one needs to fix and validate soame
<cjwatson> But if we can get it consistent then we can make proposed-migration have better behaviour - it could enforce that we don't accidentally make udebs uninstallable
<infinity> The rest (fat, vfat, etc) are built in.
<cjwatson> infinity: Mm, well, I think that can stay as it is
<cjwatson> apw: http://people.canonical.com/~ubuntu-archive/proposed-migration/saucy_uninst.txt should be enough
<cjwatson> That's where I'm starting here
<infinity> cjwatson: I think that's just a happy accident of poor configs. :)
<apw> infinity, doesn't that mean there is someting other than fat in that udeb so that it actually still exists
<cjwatson> apw: Right, msdos.ko
<infinity> apw: Yeah, like I said, msdos... What he said.
<cjwatson> There are probably a few other similar cases; I see efi-modules in a similar situation
<apw> so you would make britney check udebs as well, and then we would be unable to break it again
<cjwatson> Just trawling
<cjwatson> apw: It actually does right now - I think I was mistaken in saying it didn't
<infinity> It's just that it's allowing things to be "as broken as before" (which is what it always does), so if it's always been broken...
<cjwatson> Right
<cjwatson> This has been broken since before proposed-migration existed, and so was grandfathered
<apw> heh ok perfect
<infinity> But if we reach the goal of making the whole archive installable, and then hit people with large sticks when they try to force things in, britney can do its job much better.
<apw> works for me, i don't like being an outlier, which is why we now have the lists of udebs udebs and the like
<apw> i am all for sanity
<cjwatson> I plan to spend a bunch of the rest of the cycle analysing and zeroing all this
<apw> cjwatson, so are you doing these udebs for me, or do you awnt me to
<cjwatson> I'll come up with something
<apw> ack
<cjwatson> Since I'll need to do the analysis anyway, I guess :)
<cjwatson> It's kind of a pain to expect anyone else to do
<infinity> There should probably be some automated way of doing it.
<apw> i was wondering the same
<infinity> If we know all the udebs we could produce, and know all the udebs we did produce.
<apw> presumable i can look at the Depends in this package-list
<cjwatson> Meh, analyse once and it'll be way easier from then on
<cjwatson> Won't take that long
<apw> and for those which arn't in the list, and arn't packages in saucy, fail
<infinity> Though, that assumes that all the ones we didn't produce are built-in, rather than a victim of anemic configs that lack features.
<cjwatson> I'll check for that
<apw> well when cjwatson sends me over a patch for the missing one, i can check, or ... he can do everything and i can get a coffee
<cjwatson> I used to help maintain the kernel udeb handling in Debian, it's no harder :)
<infinity> apw: Get me one too.  I think I've given up on sleep tonight being a thing.
<apw> heh, i bet we make it harder
<cjwatson> Other problems not mentioned above: btrfs-modules, crypto-dm-modules, ext3-modules, ext4-modules, ufs-modules
<cjwatson> I think that's the lot
<cjwatson> Not all of KDE is through, but the bulk is, so unmuting
<cjwatson> unmute queue saucy-proposed
<queuebot> Removed mute entry: ['#ubuntu-release', 'queue', 'saucy-proposed']
<Riddell> thanks cjwatson
<cjwatson> apw: I think http://paste.ubuntu.com/6179577/ would be a fine start
<cjwatson> apw: I expect the ARM and PowerPC variants would need something similar
<apw> cjwatson, ok are you sending a patch or shall i suck that in from the pastebin
<cjwatson> kernel-team@ is it still?
<apw> cjwatson, yep thats the one
<cjwatson> apw: https://lists.ubuntu.com/archives/kernel-team/2013-October/033011.html
<cjwatson> apw: Er, sending a followup
<cjwatson> apw: Should be correct with the typo fix in https://lists.ubuntu.com/archives/kernel-team/2013-October/033012.html
<cjwatson> (I can send a new patch if you need it)
<apw> cjwatson, na i can wangle it out
<cjwatson> ta
<cjwatson> Urgh, proposed-migration is crashing.  Looking into it.
<cjwatson> Should be happier once kcron builds, so I've just scored that up ...
<cjwatson> kcron/i386 that is
<cjwatson> Though maybe I can fix it otherwise ...
<didrocks> can we get someone looking at mir? we would need it for image build #75? (it's in the unapproved queue)
<didrocks> tested on desktop and touch
 * didrocks wonders why unity-mir is blocked though in update_output.txt, no trace of success
<stgraber> didrocks: I'll do queue reviews once I'm 1) done with the current issue 2) actually awake ;)
<didrocks> (there is no new dependency, unity-mir should be enough on its own)
<didrocks> stgraber: thanks!
<cjwatson> didrocks: It seems quite clear why it's blocked
<cjwatson>     * i386: indicators-client, libunity-mir-dev, libunity-mir1, unity8, unity8-autopilot
<cjwatson>  libunity-mir1 : Depends: libmirserver4 (>= 0.0.12+13.10.20131001) but 0.0.12+13.10.20130926.1-0ubuntu1 is to be installed
<cjwatson> Which is presumably because it needs the new mir
 * infinity looks at the new mir.
<didrocks> cjwatson: this is in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt?
<cjwatson> Yes
 * cjwatson fixes the proposed-migration crash
 * didrocks doesn't see libunity-mir1 : Depends: libmirserver4 (>= 0.0.12+13.10.20131001)â¦
<cjwatson> didrocks: The first line is in update_output.txt
<infinity> didrocks: That's from him trying to install it.
<cjwatson> didrocks: The second line was from "chdist apt-get saucy-proposed-i386 install libunity-mir1" as ubuntu-archive@snakefruit
<didrocks> cjwatson: ah, so it's not clear from update_output.txt, you need to try to chdist it, ok :)
<didrocks> Mirv told me there was no ABI break thoughâ¦
<cjwatson> It tells you that that package is uninstallable, just not exactly why
<infinity> +  [ Michael Terry ]
<infinity> +  * merge latest dev branch.
<infinity> +
<infinity> +  [ Kevin DuBois ]
<infinity> +  * merge latest dev branch.
<infinity> +
<cjwatson> For that matter sometimes apt takes some persuasion to tell you exactly why
<infinity> +  [ Daniel d'Andrada ]
<infinity> +  * merge latest dev branch.
<didrocks> cjwatson: hum libmirserver4 is in suacy
<infinity> Most.  Informative.  Changelog.  Ever.
<infinity> didrocks: Not in a high enough version.
<didrocks> infinity: I knowâ¦ already told upstream they need to change their commit message in the future
<cjwatson> libmirserver4 | 0.0.12+13.10.20130926.1-0ubuntu1 |         saucy | amd64, armhf, i386
<cjwatson> 0.0.12+13.10.20130926.1-0ubuntu1 < 0.0.12+13.10.20131001
<didrocks> oh right, I'm so used they don't have any kind of compatibility
<didrocks> cjwatson: ok, so, I'll try chdist next time I don't see it installing
<didrocks> thanks
<cjwatson> Riddell: Um, what is this kate upload
<cjwatson> +       $(overridden_command) -- -DKDE4_BUILD_TESTS=false -DPYTHON_LIBRARY=/usr/lib/x86_64-linux-gnu/libpython2.7.so.1
<cjwatson> Riddell: That really isn't a sensible thing to put in debian/rules for all architectures :-)  Rejecting
<cjwatson> shadeslayer: ^-
<shadeslayer> ack
<shadeslayer> Riddell: I didn't realize 4.11.2 was out?
<Riddell> cjwatson: good point
<Riddell> shadeslayer: ftp is open
<shadeslayer> okay
<cjwatson> I'm guessing you want $(DEB_HOST_MULTIARCH) there, with "DEB_HOST_MULTIARCH := $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)" at the top if tat isn't done already
<shadeslayer> I didn't see a release announcement
<didrocks> (thanks)
<xnox> cjwatson: /me prefers "include /usr/share/dpkg/architecture.mk" to get all the DEB_{BUILD|HOST}_* vars with caching and for free =)
<cjwatson> xnox: whatever :-)
<Riddell> shadeslayer: no they open ftp the night or the morning before the announcement
<cjwatson> xnox: (note my version isn't lacking caching)
<shadeslayer> okay :)
<xnox> cjwatson: it's always executed though, even when not needed. architecutre.mk only execs on demand & then caches.
<xnox> (not that it matters, it's not that expensive to call)
<shadeslayer>  /join #kde-devel
<smartboyhw> shadeslayer, the whole channel? ;)
<shadeslayer> yep
<smartboyhw> shadeslayer, er, you do realize where you are talking right? ....
<shadeslayer> yep
<smartboyhw> ;O
<shadeslayer> wait
<shadeslayer> eh
<shadeslayer> no no no
<smartboyhw> LOL
<shadeslayer> smartboyhw: I read that as "The wrong channel"
<shadeslayer> and then went "yep"
<smartboyhw> shadeslayer, sure;)
<smartboyhw> Well, we welcome everybody anyway
<xnox> cjwatson: \o/ thanks for removals.
<cjwatson> np
<shadeslayer> xnox: cjwatson -DPYTHON_LIBRARY=/usr/lib/$(DEB_HOST_MULTIARCH)/libpython1.7.so.1
<shadeslayer> look better?
<xnox> shadeslayer: actually you want `python-config --ldflags` & -lpython2.7
<xnox> shadeslayer: cause there list libpython2.7.so in the proper /usr/lib/python2.7/config-$triplet/ directory, and will enable you to e.g. do python2.7 debug build.
<xnox> shadeslayer: which is then e.g. under /usr/lib/python2.7/config-x86_64-linux-gnu_d/, vs /usr/lib/python2.7/config-x86_64-linux-gnu/ (_abi suffix)
<shadeslayer> xnox: I don't quite follow, but the problem is that kate can't find the python lib causing python plugins in kate to not work
<xnox> shadeslayer: ah, if you need the runtime library, you are correct.
<shadeslayer> correct
<cjwatson> mir/unity-mir passed proposed-migration now, I see
<shadeslayer> btw did the swith to xmir happen already? because I don't think I saw it running on the Beta 2
<cjwatson> no
<shadeslayer> okay
<stgraber> Riddell: can you confirm that the "a" in the version number for kate is intentional (not seeing it in the others, so wondering)
<Riddell> stgraber: yes it is, upstream rerolled the tar
<stgraber> ok
<stgraber> Riddell: hmm, kdeartwork contains what looks like a feature change (disabling a bunch of slideshow transitions)
<Riddell> stgraber: are you really reviewing every package? I'm quite impressed
<stgraber> Riddell: I sure am ;)
<stgraber> most of those take just a few seconds though as they're just re-versioning and updates to debian/control
<Riddell> stgraber: kdeartwork change is for bug http://bugs.kde.org/182104
<ubot2`> KDE bug 182104 in general "Specific transition effect of the slideshow screensaver is extremely slow" [Normal,Resolved: fixed]
<Riddell> Bug 182104 - Specific transition effect of the slideshow screensaver is extremely slow
<Riddell> it's removing a feature not adding it
<stgraber> Riddell: feature freeze also covers feature removal ;)
 * stgraber looks at the bug report
<Laney> introducing a negative feature
<stgraber> fine, I'll consider that fixing a nasty performance bug and let it through ;)
<jamespage> infinity, balloons: rbasak just raised that someone from the server team needs to signoff on server images
<jamespage> I'll pickup that honour for this cycle :-)
<balloons> jamespage, :-) wonderful. I've already got a task for you then
<jamespage> nice
<jamespage> balloons, what do I need todo?
<balloons> jamespage, Can you review the current tests and make sure they are all still valid and needed? In particular we have a few questions about the jeos tests
<balloons> jamespage, http://iso.qa.ubuntu.com/qatracker/milestones/270/builds/54674/testcases
<balloons> plars, if you around, let's sort this out with jamespage now for the final images ^^
<jamespage> I see we are oversized as well
<jamespage> I guess that needs looking at
<balloons> jamespage, umm, is server still trying to fit on a cd? the other images are not longer constrained to that size
<jamespage> whilst I'm here - we have a bit of a problem with python-lesscpy  (bug 1233749)
<ubot2> Launchpad bug 1233749 in python-lesscpy (Ubuntu Saucy) "lesscpy command fails" [High,Triaged] https://launchpad.net/bugs/1233749
<jamespage> there are fixes stuck in the Debian NEW queue for this; is there precedent/process for pushing a package from the debian git repositories directly into Ubuntu?
<jamespage> balloons, the honest answer is I don't know
<jamespage> but I can find out
<cjwatson> I've been meaning to review the sizes and clear the warnings
<jamespage> if its OK then we should probably drop " Warning: This image is oversized (which is a bug) and will not fit onto a standard 703MiB CD. However, you may still test it using a DVD, a USB drive, or a virtual machine."
<balloons> jamespage, sure thing.. if you and team can review the tests and prune anything not needed it would greatly help. Checking on the oversize issue is a good idea also. Thanks!
<plars> balloons: there are automated tests for a fair chunk of those. I don't have esx server so I'm not able to do the optional one, and maas usually gives me problems, but jamespage and smoser were really helpful in testing that during previous cycles.
<cjwatson> I don't think it's something the server team needs to spend much time on, though obviously if there's stuff you can rip out for free then do it
<jamespage> cjwatson, I'll not put it at the top of the list then
<jamespage> I think roaksoax is about to add a couple more things anyway for maas
<balloons> yes, I know maas is important. I wonder about the rest
<balloons> it seems like we're always spending the last days spinning around on maas
<rbasak> Would it be sufficient to automatically test most of the tasks with preseeds?
<balloons> imho, yes
<rbasak> And then focus on a basic install and maas?
<balloons> that's the direction I would like to see it go
 * infinity decides it's finally time to nap.
<balloons> so rbasak plars jamespage can we confirm what we have automated tests for? I can then remove them from mandatory manual testing on the tracker. We can mark them as optional or remove them altogether
 * rbasak isn't sure
<plars> balloons: it's most of the install scenarios there, but I usually give them a look by hand as I'm doing other installs too, so just leave them
<plars> balloons: ideally, I'd love to see manual and automated results all grouped together in a single view for the image, but we don't have that yet
<balloons> plars, of course.. But I'd like to at least mark them as optional
<plars> balloons: having them on the list though, ensures that someone either tries it by hand, or actually looks at the results and confirms they look ok
<balloons> there's 18 mandatory tests for server, which adds up
<doko> infinity, gcc-4.8 uploaded
<jamespage> balloons, I'll review tomorrow AM
<balloons> jamespage, plars rbasak thank you :-)
<ogra_> stgraber, did systemd just go through without any queuebot message ?
 * ogra_ sees it built and all, i tought the binary would show up here 
<stgraber> ogra_: why would the binary show up there?
<stgraber> ogra_: AFAICT the source go blocked in Unapproved and accepted 1h50 ago
<ogra_> dunno, i see others show up in the backlog
<ogra_> ah, k
<stgraber> the only ones that show up in New are those that introduce new binaries
<ogra_> oh, ok, i thought durign freeze all held binaries would show up too
<ogra_> anyway, then i should be good to build an image
<stgraber> nope, only source packages get caught in unapproved
 * ogra_ fires off a build 
<stgraber> jamespage: hey, looking at the horizon upload, should there be any kind of migration code in postinst to move the key between locations?
<rsalveti> can anyone review the gstreamer related packages ^? this is a new upstream bugfix release, and final for the 1.2 series
<stgraber> yep, will take care of that in a few minutes, slowly going through the queue
<rsalveti> awesome, thanks
<stgraber> infinity: around? (if you're, I'll leave the kernel upload to you, if not, I'll process it in a couple minutes)
<stgraber> Laney: do you have a FFe for gst-plugins-good? looking at the upstream changelog, it doesn't really look like bugfix only to me...
<stgraber> (I don't think we need a FFe for bad => good, those are fine, but I noticed a few new codecs and other random features in the upstream changelog bundled in the source)
<rsalveti> let me check good
<rsalveti> stgraber: which new codecs did you noticed in good?
<rsalveti> looking here at the git log and seems it only got fixes
<rsalveti> but there are indeed some new features inside a few plugins
<stgraber> rsalveti: +2013-06-18 13:27:20 +0100  Alex Ashley <bugzilla@ashley-family.net>
<stgraber> may be changes to an existing codec (AVC) though if that's the case, that's rather massive changes
<rsalveti> hm, 06-18 is before 1.1.4, let me find the commit for that
<stgraber> I didn't look at the code change itself, only the diff of the upstream changelog in the source
<rsalveti> http://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/?id=a965185dee339da89f833b10cc2e5ac1108381b2
<rsalveti> right, that's post 1.1.4 indeed
<stgraber> how interdependent are those gstreamer packages?
<stgraber> because we already have half of them through, so wondering what happens if -good is stuck for a while
<rsalveti> seems only bad depends on -good
<rsalveti> gstreamer <- base <- ugly / good
<rsalveti> abd bad depends on good, base and gst
<rsalveti> *and
<stgraber> based also contains feature changes...
<stgraber> *base
<rsalveti> I can put a FFe bug in place
<stgraber> would be good. I don't think it's a problem, but may be worth a generic, update everything to 1.2.0 tracking bug with all affected packages
<rsalveti> yeah
<rsalveti> let me do that
<stgraber> because I realistically won't go through the whole code diff as even the changelog looks scary ;)
<rsalveti> yeah, even if mainly fixes, that's a lot of fixed all around, hard to track them down
<rsalveti> *fixes
<rsalveti> stgraber: bug 1233832
<ubot2> Launchpad bug 1233832 in gstreamer1.0 (Ubuntu) "[FFe] Updating gstreamer 1.0 stack to the final 1.2 release" [Undecided,New] https://launchpad.net/bugs/1233832
<rsalveti> stgraber: let me know if you need any other info in there
<stgraber> rsalveti: granted and I've let the two remaining packages in now
<rsalveti> stgraber: great, thanks
<jamespage> stgraber, I suppose for the sake of not leaving clutter in the filesystem that makes sense
<jamespage> stgraber, if you want to reject I'll prepare a revised upload tomorrow
<stgraber> jamespage: ok, will do that. thanks!
#ubuntu-release 2013-10-02
<infinity> rsalveti: Hah.  Damnit, I literally just did that identical merge and it got rejected two minutes after yours was accepted. :)
<rsalveti> infinity: :-)
<infinity> rsalveti: (Though, I missed the extra-comma fix in build-deps, so yours was better anyway)
<rsalveti> thanks for fixing it anyway
<infinity> So, I guess not identical.  One char off. :P
<cjwatson> apw: http://people.canonical.com/~ubuntu-archive/proposed-migration/saucy_uninst.txt much prettier :-)
<cjwatson> (though still need to sort out linux-ppc)
<apw> cjwatson, ^5 indeed, that is much better
<apw> cjwatson, if you have a patch for linux-ppc we can get that in with luck before he rebases
<cjwatson> apw: Do you happen to have a git remote URL to hand for it?
<apw> cjwatson, https://github.com/benmcollins/ubuntu-saucy-powerpc.git and i should be able to commit it
<cjwatson> Righto
<infinity> cjwatson: So, curiously, those kernel fixes highlighted exactly why we need to be at 0 uninstallables.
<infinity> cjwatson: Britney quite happily traded fixing 6 broken udebs for breaking 1 d-i, and slid it right in. :P
<apw> i wonder if d-i should be a special, as too expensive to break
<infinity> Nah.
<infinity> It'll be fine now.
<infinity> This was a one-time event.
<infinity> Though, I think britney might actually have a config option for "never let these packages break".
<infinity> I vaguely recall seeing something like that in passing.
<cjwatson> Heh
<cjwatson> infinity: You fixing d-i?
<apw> given we make CDs out of the results, and those are 'today' it might make some sense
<infinity> cjwatson: Already done hours ago after I noticed the oops.
<cjwatson> apw: like infinity, I'm not too bothered as this ceases to be a problem once we abolish things it can trade
<infinity> apw: When I remove ti-omap4 (I should do that tomorrow), I can finish up the seed changes I left half done, and can spread the d-i love around to the kernel team too (well, you and Tim).
<apw> cjwatson, yeah i can see that makes a lot of sense
<apw> and i am all for making it so
<jamespage> stgraber, ^^ revised horizon that does tidyup as well
 * jamespage goes to look at test cases for balloons
<cjwatson> I'm not aware of a "never let this package break" option FWIW
<cjwatson> (presumably this will happen once more as we fix linux-ppc)
<infinity> cjwatson: Yeah, I think I was confusing it with b1's noremove.d stuff.
<infinity> I'm not fussed about PPC breaking for a day if I don't notice it right away.
<infinity> It not automatically tested by people who whine 20 minutes after a broken ISO happens.
<infinity> s/It/It's/
<cjwatson> orig: 396+0: i-69:a-33:a-29:p-36:a-229
<cjwatson> easy: 341+0: i-35:a-22:a-19:p-36:a-229
<cjwatson> is a nice thing to see though
<infinity> Shame about that last a.
<jamespage> balloons, plars: so the only tests cases we don't have covered with automated tests are: maas-*, Install (Default + crypted LVM), iscsi-*, rescue-mode, Install (No Network Connection), Install (JeOS on ESX)
<cjwatson> Manual rescue testing did actually show up a fairly important bug in the final beta cycle
<jamespage> cjwatson, good
<jamespage> cjwatson, I actually still think there is merit in getting a person to run the tests at least once a cycle
<infinity> Manual testing definitely has a place.  We've even managed to convince people who make decisions that this is true.
<infinity> So, yay.
<jamespage> cjwatson, picks up stuff that automated testing does not because its not exactly the same
<infinity> (But the more automated tests you can ALSO have, the better)
<jamespage> infinity, agreed - generally less nasty surprises when you do some manual testing!Â¬
<cjwatson> As I said to balloons, the right answer is for routine stuff to be covered automatically so that manual testing can be creative and find things we missed
<cjwatson> I think that's all the KDE changes through to the release pocket now
<cjwatson> (once again I had to chase up some build failures due to poor ordering)
<infinity> Hrm.  openclipart's build log seems to be full of a lot of "path/to/foo.png is already optimized." ... That might be a prime candidate for a NO_WHATEVER_MANGLE.
<cjwatson> infinity: Not at all by coincidence I'm test-building such a thing right now
<infinity> Hah.  Same trigger/annoyance for you?  "Say, why is that buildd still on O, when the others are on P?"
<infinity> OH LOOK, CLIPART.
<cjwatson> Just taking a while since it's hyoooooooooooooge
<cjwatson> Right
<cjwatson> Also it's taken twice as long as the last primary-archive build of the same version did, for some reason
<cjwatson> Dunno if optipng has got even slower or what
<infinity> I wouldn't be surprised.
<infinity> I'd also love to see if we can figure out a safe way to parallelize the PNG opt part of pkgbinarymangler.
<infinity> Given that all our buildds are multi-core.
<infinity> And some excessively so.
<apw> infinity, png things, surley that is the definition of paralelisable
<infinity> Well, the easiest way it just to call it N times for N cores, but the way pkgbinarymangler is written doesn't allow for that all that pleasantly.
<cjwatson> Could just use parallel(1)?
<infinity> cjwatson: Could do.  Could probably do it in pure shell with wait without too much trouble, actually.
<xnox> (gnu parallel from universe can preserve ordering and buffer stdout/stderr if that's important, it's in universe though.)
<infinity> xnox: That's what Colin suggested, yes.
<infinity> I'm slightly less concerned about confusing output.  Sort of par for the course for -j builds already anyway.
<xnox> infinity: well there is moreutils & gnu variants of parallel(1)
<infinity> xnox: Both of which are in universe, so meh. ;)
<infinity> (But I'd rather not be pulling even more packages into the default chroots for something that can easily be done in shell)
<xnox> oh, i see. I somehow thought moreutils is in main.
<apw> yeah we just need a loop with a wait in it
<cjwatson> Using either of moreutils or parallel is a bit problematic here, unfortunately
<cjwatson> What if a package build-depends on the other ...
<infinity> I think my concern last time was about double-parallelisation, so we'd get 24x24 optipngs going on sagari, but pkgbinarymangler already disables --parallel for dh_builddeb to avoid races in the symlink code.
<cjwatson> There are some pure-shell gizmos in snakefruit:/home/ubuntu-archive/bin/archive-reports for running N commands at a time that you could use
<cjwatson> Perha
<infinity> cjwatson: Yeah, I have a simple gizmo in the livefs build log mirror too.
<cjwatson> ps
<cjwatson> Not remotely as clever as GNU parallel of course
<infinity> cjwatson: (Which I think I cargo-culted from build-livefs...)
<cjwatson> http://paste.ubuntu.com/6183271/
<cjwatson> That's amenable to being used in a for loop of the type found in pkgstripfiles
<cjwatson> infinity: That one just runs them all at once, rather than having control over how many it runs
<infinity> Well, controlling how many isn't rocket surgery.
<infinity> You can either chunk your input, or use counters.
<cjwatson> Sure
<infinity> Waaait.
<infinity> xargs can do this?
<cjwatson> I may well have to cancel the openclipart2 build in order that launchpad-buildd can be upgraded, which is my other motivation
<infinity> Combining -n and -P
<cjwatson> Oh, yeah, forgot about -P
<cjwatson> I searched for "parallel" in xargs(1) and came up with nothing :-P
<infinity> -n 1 -P $(nproc), done.
<infinity> xargs is too clever.
<cjwatson> Still, it might be easier to do the wait thing because that would let you use shell functions and avoid having to create a separate script
<cjwatson> Since we're doing both optipng and advpng in here (and some other bits) and probably want to parallelise the lot
<cjwatson> Some care needed with the md5sums mangling too
<cjwatson> That obviously can't be parallelised, at least not without doing it completely differently
<infinity> Having another script doesn't hurt my feelings.  And locking md5sums isn't hard.
<cjwatson> I'd batch that up and do the whole thing at the end, rather than locking.
<cjwatson> Write out all the new md5sums to a separate file and have a perl script to merge them back at the end
<infinity> pkgpngmangle should be its own script anyway, stripfiles isn't where it belongs.
<cjwatson> (Come to think of it, with a huge package, that might be quite slow in itself right now)
<infinity> A quick sed on even a huge MD5SUMS file shouldn't be too bad.  But batching it all up and doing it in one quick perl script would probably be faster.
<infinity> Even accounting for the split second it takes to start perl.
<cjwatson> md5sums for openclipart2-png is 13194 lines, 1.3MB or so.  Writing out 1.3MB 13194 times is not completely ideal to have to do, even if it doesn't dominate
<cjwatson> Sure, it's a quick sed, but multiplied by the number of PNGs
 * infinity nods.
<pstolowski> stgraber: ping
<infinity> Of course, if I rewrote it in perl and called it from dpkg-deb, I'd have threading and output buffering available to me too.  And could just buffer the md5s and write them all out at the end, without futzing with multiple processed and temp files.
<infinity> This escalated quickly from a 2-line hack to a rewrite.
<infinity> Maybe I should do it in Go!
 * apw withdraws infinity's coffee supply
<infinity> apw: I think my suggestion was so offensive that it actually knocked Colin off the Internet.
<infinity> Oh, actually, as much as my "hey, I can rewrite this in perl!!" thing sounds fun, there's zero reason the md5sum part needs to be in the loop.
<apw> infinity, hehe ... very likely
<infinity> I could just take the file list, xargs optipng, then md5 the lot and do one big sed/perl/whatever.
<apw> ^^ that is from smb, this is a resync with debian to reduce our delta ... testing looks good and we have rebuilt all of its rdepends as well; infinity aware
<infinity> ^-- I'm reviewing that Xen, nobody else needs to worry about it, I have context with apw and smb already.
<cjwatson> infinity: I don't know quite what the hell's wrong with my connection at the moment, even beyond the usual
<cjwatson> It didn't even drop properly, it just didn't catch up enough for irssi to acknowledge
<infinity> cjwatson: Some day, you'll get real internets.
<cjwatson> Some day my prince will come
<apw> not a chance he is in the wrong country, in a bit which has no technology companies, no reason to ... oh wait
<rbasak> ^ uvtool was me. Minor bugfix I fixed in "upstream" trunk first.
<rbasak> Oooh, thanks!
<cjwatson> apw: I showed you http://cjwatson.dreamwidth.org/2827.html, right?
<cjwatson> rbasak: Was probably automatic.  https://lists.ubuntu.com/archives/ubuntu-release/2013-September/002605.html
<rbasak> Ah. I see, thanks. I should read ubuntu-release.
 * rbasak subscrubes
<infinity> Subscrube sounds dirty, for some reason.
<cjwatson> Ear of the beholder.
<apw> cjwatson, perhaps the reason you don't have it is because even bt cannot find it
<infinity> cjwatson: Background/rationale for that ltsp change?
<infinity> Oh, possibly because we don't have kbd-chooser at all.
<cjwatson> Exactly
<cjwatson> It was in saucy_uninst as a result
<apw> cjwatson, were you doing a patch for linux-ppc, or can i assume it is basically the same as that for master
<cjwatson> apw: Just preparing it now as a matter of fast
<cjwatson> *fact
<apw> cjwatson, cool i am about to abuse the a machine for a test build and it can do both at once
<cjwatson> apw: https://lists.ubuntu.com/archives/kernel-team/2013-October/033068.html
<apw> cjwatson, thanks, will sort
<cjwatson> block-modules Provides: nbd-modules had been done in master a while back, but not ppc
<cjwatson> (2735470d39cade45bf2d2c1f80fea55cb94733b3)
<infinity> apw: "the a machine"? :)
<infinity> apw: Have you handed off saucy/lowlatency to zequence yet, or is there one or two rebases still in your court?
<apw> infinity, you know how my grasp of english is... tenuious at best ... spelling less so
<apw> infinity, in theory i am in the process, but he is off sick anyhow, and so htis one i am doing
<apw> (in the process of handing it off)
<infinity> Kay.
<infinity> We probably need to have a talk sometime about doing -signed for lowlatency.
<apw> i need to make sure the tools bits are right anyhow, so it is helpful if i do it, and indeed it is done and building now
<apw> yep, that isn't hard to do, the core bits are the same in the package so it should be a matter of turning it on
<apw> and making a -signed for it of course
<zequence-work> infinity: Yes, for the LTS, we probably want that
<zequence-work> apw: Ah, nice. I have yet to investigate what that all is about
<infinity> I'd still like to see lowlatency magically build out of master, but I'm not holding my breath.
<infinity> I had hoped tickless would save us all, but it appears not quite ready for prime time.
<sil2100> Hi release team! Can I get some eyeballs from the SRU team to check https://bugs.launchpad.net/unity/+bug/1043627 ?
<ubot2> Launchpad bug 1043627 in nux (Ubuntu Raring) "[SRU] Add XIM Support to Nux" [Undecided,Confirmed]
<sil2100> It's already waiting over few months now ;)
<infinity> cjwatson: Thanks for making remove-package take multiple '-a'
<cjwatson> YW
<infinity> (Just used it when whacking old ac100-tarball-installer binaries)
<cjwatson> Been annoying me for a while
<cjwatson> Ah, thanks, that was on my todo
<infinity> seb128: Have you noticed or looked at the EDS autopkgtest failure that's preventing it from migrating?
<seb128> infinity, yes, I was just looking at that, I know what it is, going to upload a fix in the next half an hour
<infinity> seb128: Awesome, thanks.
<seb128> infinity, yw
<infinity> seb128: Just wanted to make sure it wasn't going unnoticed.  Some people don't tend to pay attention to migration issues.
<infinity> (And then there's the part where one in a billion people can decipher Jenkins output...)
<seb128> infinity, I got a nice email from jenkins telling me ;-)
<seb128> well, jenkins is not easy to browse, but I could confirm the issue here
<doko> another gcc-4.8 upload coming ... please let this build first before accepting things like lo
<cjwatson> Is it needed specifically for libreoffice?
<doko> no, just a fix for a wrong-code regression in 4.8 on armhf
<cjwatson> doko: I mean, is it just that you want to make sure libreoffice isn't occupying all builders?  (Which it wouldn't be anyway)
<cjwatson> Or do you want to make sure that libreoffice is built with the new compiler?
<doko> yes, the latter, although I'm still trying to understand the impact of this issue (what kind of things could be misbuilt)
<seb128> infinity, e-d-s ^
<infinity> seb128: Danke.
<infinity> doko: When can I expect that gcc-4.8?
<infinity> doko: (Should I reserve sagari for you, or is it a few hours away?)
<pstolowski> stgraber: ping
<doko> infinity, 30min, waiting for a test build
<infinity> doko: Kay, I'll keep sagari for you, then.
<pstolowski> Riddell: ping
<Riddell> hi pstolowski
<pstolowski> Riddell: hi! can I bring this bug https://bugs.launchpad.net/unity-lens-applications/+bug/1231556 to your / release team attention? just got doc+translators ack
<ubot2> Launchpad bug 1231556 in Unity Home Scope "[UIFFe] Inconsistency between Dash plugins category name and filters" [High,In progress]
 * stgraber does some queue review now
<stgraber> pstolowski: pong
<pstolowski> stgraber: hey! just talking to Riddell about ^
<rsalveti> stgraber: mind checking hybris ^? bugfix to unblock the autopilot mediaplayer related test cases
<Riddell> pstolowski: find with me if translations and docs people are fine
<pstolowski> Riddell: can you +1 it?
<Riddell> pstolowski: commented on bug
<pstolowski> Riddell: ta!
<pitti> any opinion about "upgrade" vs "backport 4 patches" for bug 1234219?
<ubot2> Launchpad bug 1234219 in ofono-phonesim (Ubuntu) "Does not accept calls to 05123xx -- FFE: update to 1.19" [Undecided,New] https://launchpad.net/bugs/1234219
<stgraber> jamespage: sorry for the delay, horizon accepted, thanks for the fix!
<jamespage> stgraber, ta
<stgraber> diff from 319.49-0ubuntu2 to 319.60-0ubuntu1 (105.3 MiB) <- I wonder if we had much large diffs than that ;)
<rsalveti> thanks!
<infinity> stgraber: What was that diff for?
<infinity> Doesn't seem excessive at all...
<stgraber> nvidia binary driver
<stgraber> basically replacing 50MB worth of binary blobs by another 50MB :)
<stgraber> I really love it when upstreams have very detailed and easy to read changelogs! /me accepts libx11 (as long as the diff is, it actually seems to be bugfix only and gets rid of a bunch of patches)
<doko> infinity, gcc-4.8 uploaded and set ross to manual
<infinity> doko: Will look as soon as I get a diff from the queue.  Thanks.
<infinity> smoser: Bah, I thought you said maas was going to depend on ubuntu-cloudimage-keyring ... It started depending on ubuntu-cloud-keyring, but not the other.
<smoser> infinity, CRAP
<smoser> roaksoax, ^
<smoser> suck.
<infinity> roaksoax: While we're at it, you need to file a few more MIRs for new maas dependencies.
<infinity> roaksoax: Oh, I guess just curtin.
<smoser> infinity, bug 1220434 is there.
<ubot2> Launchpad bug 1220434 in curtin (Ubuntu) "[MIR] curtin" [Undecided,New] https://launchpad.net/bugs/1220434
<infinity> smoser: Weird, c-m isn't picking that up.
<infinity> Oh, you didn't sub ubuntu-mir.
<roaksoax> smoser: so what is it? ubuntu-cloudimage-keyring or ubuntu-cloud-keyring?
<smoser> ubuntu-cloudimage-keyring
<roaksoax> smoser: ok, i'll make a new upload. Could you also propose the packaging fix for the upstart job so It can land now?
<smoser> roaksoax, i'm looking at it.
<roaksoax> smoser: k!
<infinity> smoser: Out of curiosity, what is ubuntu-cloud-keyring, and why isn't that also in main?
<stgraber> infinity: isn't that the cloud archive keyring?
<infinity> stgraber: One would assume, yes.
<infinity> (Why that and the cloudimage keyring aren't just one keyring, I'm not sure...)
<infinity> Like we have our FTP and CD keys both in ubuntu-keyring.
<stgraber> because the cloud archive isn't enabled by default and some people may not want to trust it by default?
<infinity> Oh, I guess cloud images don't actually use the cloud archive, unlike cdimage/ftpmaster being paired.
<infinity> Fair enough.
<stgraber> ftp and cd keys make sense because our official medias contain a pool that's signed by the CD key, so an installed system needs to trust both keys to work properly
<stgraber> not the case with the cloud stuff
 * infinity nods.
<smoser> infinity, the cloud images keyring doesn't actually sign packages.
<smoser> at all
<smoser> just data
<smoser> the cloud archive keyring (ubuntu-cloud-keyring) signs packages
<infinity> smoser: Check.
<apw> these linux-ppc and linux-lowlatency uploads are derivative rebases to latest master source version to bring all to the same underlying version
<cjwatson> infinity: ^- pretty please stop britney from doing bad things for too long by accepting that d-i
<infinity> cjwatson: I'll accept it when it can be built. :P
<cjwatson> Oh, is the publisher taking a while?
<infinity> cjwatson: The kernels aren't built...
<cjwatson> Oh, I can't read
<cjwatson> Read that as binaries
<infinity> cjwatson: That linux-ppc should be done in ~20m, I'm guessing.  I'll stay up long enough to see it publish, push d-i, and bump seeds.
<infinity> cjwatson: (ie: feel free to piss off, since it's all late and stuff over there)
<cjwatson> Yeah, might do in a bit
#ubuntu-release 2013-10-03
 * infinity runs out of reasons to still be awake and goes to remedy the situation.
<TheDrums> henrix: Howdy, still alive?
<tjaalton> drop xorg-server, I'll do a proper merge this time..
<tjaalton> including the latest upload
<tjaalton> fixed version uploaded
<lool> hey there
<lool> I'm pushing a block hint on system-image to stage a build in -proposed
<lool> uploaded system-image now, let's see if I got that right
<cjwatson> looks syntactically fine
<lool> I think I might keep it and tell barry to stage upcoming system-image bits there since there is no change of blocking other stuff from migration
<lool> didrocks: ^
<lool> *chance
 * cjwatson cancels libreoffice on sulfur and gives it to sagari instead
<zul> can a archive admin approve, glance, keystone and ceilometer please
<lool> zul: s/approve/review/  :-P
<zul> lool:  yes please :)
 * lool is not an archive admin though; sorry
<lool> (it's release team really)
<xnox> there is now two upstart uploads in saucy-proposed/main.
<xnox> can you please reject either of them, both are equivalent, pick whichever you prefer best.
<lool> also hinted block lxc-android-config; only seeded in touch
<didrocks> lool: sounds good, did you get a chance to test it?
<didrocks> lool: so not for next image for system-image?
<lool> hinted system-image and lxc-android-config in
<lool> after they go in, I will keep the system-image block but lift the lxc-android-config one
<smartboyhw> Can somebody have a look at Bug 1234669?
<ubot2> Launchpad bug 1234669 in Ubuntu "FFe: Sync ardour3 3.4~dfsg-2 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1234669
<seb128> Laney, do you know if anyone is looking at the intel driver update FFe?
<Laney> no I don't
<seb128> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1234027 if somebody wants to look at it
<ubot2> Launchpad bug 1234027 in xserver-xorg-video-intel (Ubuntu) "FFe: new upstream release 2.99.903" [Wishlist,Confirmed]
<seb128> it fixes several issues, including the "screenshots are blank" one
<seb128> would be nice to get in saucy (or at least get the fixes backported if we don't get the ffe for the update)
 * Laney resets it to New so that it gets on the list
<Laney> that auto-confirm feature is the worst (at least for process bugs)
<seb128> Laney, thanks
<tjaalton> I've just subscribed u-r so probably why it wasn't on the radar..
<Laney> that'll do it
<tjaalton> now that seb128 will test it on gen5 the testing should be complete
<tjaalton> :)
<seb128> ;-)
<brainwash> seb128: can you have a look at bug 1231978 please? a fix has been committed upstream
<ubot2> Launchpad bug 1231978 in gvfs (Ubuntu) "Thunar 1.6.3 locks when browsing Trash with Xubuntu 13.10 Beta 2 and following dailies" [Critical,Confirmed] https://launchpad.net/bugs/1231978
<seb128> brainwash, yes, alex (upstream) already pinged about it, it's on my list for today
<brainwash> seb128: thanks :)
<seb128> brainwash, yw
<cjwatson> Could somebody have a look at my apt SRUs?  We need to get them done before Launchpad can safely be upgraded to precise, so I'd like to get the clock ticking as early as possible
<lool> unblocked lxc-android-config/0.106
<rsalveti> libhybris: bugfix for video seek, if anyway can approve :-)
<Laney> ScottK: Riddell: One of you two might want to review kubuntu-settings
<Laney> I don't want to go through all of those maintainer script changes
<Laney> are they all necessary to do now?
<slangasek> cjwatson: apt> done, but could you add an explicit test case to the bugs?
<Laney> hmm, a nova stack
<cjwatson> slangasek: OK, I'll come up with something after the meeting.  Thanks
<Laney> Reminds me that I was going to ask if we should now add another server person to the RT
<lool> dbus above seems a critical bug fix for flavors using dbus in user sessions; IIUC, we are starting jobs using dbus before dbus is really ready and that breaks them
<infinity> lool: Accepted.
<lool> thanks
<zul> can we get a release team member to review the openstack please (nova, glance, keystone, ceilometer, etc)
<infinity> zul: Are there FFes for all these massive diffs?
<zul> infinity:  its my understanding  that they dont need one since their all point releases for bugs fixes etc
<zul> jamespage:  ^^^
<infinity> They're not point releases...
<infinity> beta -> rc is development releases, and there are certainly some massive changes in here.
<infinity> (Not that I'm arguing against us pushing toward the final upstream releases, but it would be nice to know someone's gone through and tested some of this, cause I can't review a 3MB diff)
<jamespage> infinity, we can raise a FFe if required; the target for saucy has always been 2013.2
<infinity> jamespage: Verbal confirmation that this has seen some sort of testing and sanity checking would be alright.  I don't need a formal process, just reassurance. :P
<zul> infinity: it has been tested and sanity checked
<jamespage> infinity, sure - bearing in mind the insane upstream gating of commits and the fact we also build/test against trunk in our CI lab I'm pretty comfortable with this :-)
<jamespage> infinity, I also have a full openstack environment just waiting to test these again once they land in distro - all running b3 right now
<xnox> cjwatson: Laney: do you have your codesearch instance URL handy?
<cjwatson> xnox: http://162.213.35.4/
<xnox> cjwatson: thanks.
<infinity> stgraber: Is the reboot-required postinst thing really necessary, given that it's a one-time thing and people who run devel releases either (a) reboot constantly anyway or (b) ignore reboot-required?
<stgraber> infinity: slangasek asked for it, I added it :)
<infinity> (To be fair, I'm not even sure how I'm supposed to know reboots are required anymore... The gear doesn't turn red anymore, and I see no visual indicator that I need a reboot, despite clearly having upgraded rebooty packages in the last 11 days)
<slangasek> reboots are always one-time things
<slangasek> infinity: you're failing to use update-manager :P
<infinity> slangasek: I meant the postinst is a one-time thing.
<infinity> slangasek: True, I don't use update-manager.  If it's the only thing that usefully displays reboot notifications at the GUI level, that seems like a regression to me.
 * infinity shrugs.
<infinity> The system menu used to be fairly obvious about it, which seemed useful.
<infinity> Since you might ignore u-m's initial recommendation (cause you're running some long-running process or whatever) and want a constant nag.
<slangasek> I don't remember if that's a deliberate behavior change, or if the gear not changing color is a regression
<slangasek> bdmurray: ^^ do you know?
<slangasek> infinity: currently, the "constant nag" is that you can't dismiss u-m's notification, you can only click 'reboot'
<slangasek> but I don't know if that's intentional
<infinity> slangasek: It used to change the color *and* have a "reboot required" string in the menu itself, near the logout/suspend entries.  Both are gone.  I assumed it was a deliberate design decision.
<infinity> slangasek: You can't close u-m with the X? :P
<slangasek> having update-manager keeping a memory-hogging window open as a reminder somewhere on your desktop is annoying
<slangasek> infinity: there's no X
<infinity> Oh.
<infinity> Shows how long it's been since I ran u-m.
<infinity> Hah.  Damnit.
<infinity> And running u-m kicked me immediately to the reboot dialog.
<infinity> At least it's not modal...
<xnox> infinity: slangasek: gear not changing red is intentional change.
<xnox> infinity: there is also MOTD that reboot is required on console logins.
<xnox> infinity: these days update manager insist on reboot required, it says that at the end of installing updates and only has shutdown-now button and no other way to close it. (one can minimise it)
<infinity> xnox: Sure, but that doesn't address the GUI nag issue.  I almost never log in to a console on my laptop, except when debugging why the GUI broke. :P
<xnox> for me update-manager shakes and goes to foreground with "reboot now" button ....
<infinity> Oh well.  I pretty much never win arguments with design people, so I don't think I'll bother trying.
 * xnox actually uses update-manager. it became useful after mpt's grouping of packages and now i catch deadly updates more often with my eyes then apt-get's output.
<slangasek> xnox: MOTD is only shown if you have a console login; it doesn't constitute a persistent reminder that the reboot is required, so if you ignore the initial "reboot required" from u-m (or are refusing to dogfood, like infinity), you get no ongoing reminder
<slangasek> stgraber: and android-tools made it into saucy with no problems
<stgraber> slangasek: good
<infinity> slangasek: I'm not even sure it's an intentional refusal to dogfood, update-manager just no longer pops up for me.  I assume that's something I did that changed that, but it seemed a pleasant enough change for someone who prefers to run apt-get anyway. :P
<balloons> so for the final rc images, builds planning to start on the 10th? what to make sure everything is lined up properly
<infinity> balloons: Final Freeze is the 10th, so that would be the beginning of the RC week, yeah.  Unless we're working magic, I wouldn't expect those to be the final images, mind you.  But we'll want heavy testing regardless.
<balloons> infinity, :-) Just wanted to make sure before I pushed on everyone to be ready on the 10th
<slangasek> infinity: hmmm, I wonder what changed to make update-manager not pop up for you; there was a flag for a while that you could use to say "I want this in the indicators, not as a pop-up", but then that stopped working, so I believe we now ignore the flag
<slangasek> infinity: in any event, update-manager is how we expect people to use our "constantly-usable" devel series, and there are u-m-specific issues with conflicts/replaces that require certain gardening; it would be good to have more people dogfooding u-m generally
<infinity> slangasek: Yeah, I'm not sure either.  I haven't seen it pop in ages, and assumed it was something I did locally, as others would have complained if it was a global thing.
<slangasek> infinity: does running 'update-manager --no-update' work from the commandline?
<infinity> Hah, no.  That crashes.
<slangasek> well, there ya go then
<infinity> Works without the --no-update switch.
<infinity> http://paste.ubuntu.com/6189674/
<infinity> apport claims it's bug #1219414
<ubot2> Launchpad bug 1219414 in update-manager (Ubuntu) "update-manager crashed with AttributeError in start(): 'NoneType' object has no attribute 'set_functions'" [Medium,Confirmed] https://launchpad.net/bugs/1219414
<stgraber> https://errors.ubuntu.com/problem/10857477ccaa1e6f187c2f983099ea169dfa10af and https://errors.ubuntu.com/problem/9bfd367a2cf6a93d63e1a12e877d629ef90ead0f
<infinity> So, started happening in 0.190, if errors is to be believed.
<infinity> 189 seems more likely.  Maybe that didn't live long enough to get installed anywhere.
<slangasek> infinity: ironically, that backtrace points to a bug in showing the 'needs restart' dialog
<infinity> slangasek: Which works if I call it without --no-update.
<infinity> Could also explain why more people don't see it.  Cause you'd have to get into a restart-needed state without update-manager before it tries to run.
 * slangasek nods
<slangasek> so, it's caused by xnox's refactor? :)
<infinity> And I suspect not everyone haphazardly mixes apt-get and update-manager like I do.
<infinity> Though, this doesn't explain why I haven't seen the dialog in months.
<infinity> I can't possibly always be in a restart-needed state.
<infinity> Well, maybe I am almost all the time. :P
<infinity> Hard to say for sure.
<slangasek> infinity: want to try a one-line change, to add self.window_main.realize() before the self.window_main.get_window() ?
<infinity> I've closed the backtrace.  Which file and line was that?
<infinity> Oh, wait, it's up there.
<slangasek> /usr/lib/python3/dist-packages/UpdateManager/Dialogs.py:285
<infinity> slangasek: That did it.
<slangasek> infinity: bug reproduced here, fix confirmed; I'll go ahead and upload
<infinity> I have mixed feelings about this being fixed.
<infinity> Now I'll see u-m again. :P
<infinity> But, happy that my anecdote led to a bug fix.
<infinity> slangasek: Hrm, my testing methodology might be faulty, though.
<infinity> slangasek: Removing that line, it still works.
<slangasek> infinity: mine wasn't :)
<infinity> slangasek: Maybe running u-m succesfully changed its state somehow.
<slangasek> sudo /usr/share/update-notifier/notify-reboot-required; update-manager --no-update --> confirm failure; edit; update-manager --no-update --> confirm success
<infinity> slangasek: Yeah, see, I removed the line here now, and "sudo /usr/share/update-notifier/notify-reboot-required; update-manager --no-update" doesn't crash anymore.
<infinity> slangasek: So, WTF is up with that? :P
<slangasek> infinity: oh.  you ran 'update-manager' in between without the '--no-update' option?
<infinity> slangasek: I did at some point, yes.
<slangasek> and it showed you a list of available updates to apply?
<infinity> slangasek: But now I just redid notify-reboot-required and update-manager --no-update with no update-manager in between, and still works (without the fix).
<slangasek> so it's not trying to show you the 'reboot required' dialog now because you have a list of available updates to apply ;)
<infinity> slangasek: Oh, right.  Drawing a different window first.  Check.
<infinity> If I dist-upgrade, that should go away.
<infinity> Let's see.
<slangasek> yep
<slangasek> or if, y'know, you *use update-manager*
<infinity> If apt-listchanges and update-manager still got along, maybe I'd use it more.
<infinity> Or did that ever get fixed?
<slangasek> wasn't aware that they didn't get along
<slangasek> regardless
<slangasek> u-m in queue, please review
<infinity> Okay, reproduced and verified fixed after an upgrade.
#ubuntu-release 2013-10-04
<slangasek> ^^ that's the fix for the sbverify problem that popped up on IRC earlier today; I guess we'd like that in so that QA has a working sbverify they can use for testing
<stgraber> I'll review
<stgraber> well, as soon as I get a diff...
<infinity> slangasek: Why does that sbsigntool upload have a changelog entry from a precise SRU/backport?
<infinity> slangasek: (And do you care?)
<tjaalton> anyone know why https://launchpad.net/ubuntu/+source/wayland/1.1.0-2ubuntu2/+build/4969824 is still in limbo?
<infinity> tjaalton: Because it's arm64, which is pretty much entirely in limbo.
<tjaalton> but the package is still in proposed because of that?
<infinity> No.
<infinity> It's been in the release pocket since August 21...
<tjaalton> oh gah
<tjaalton> I was looking at a wrong pkg..
<tjaalton> still have libwayland0 installed, and the new one doesn't have that anymore
<infinity> slangasek: I decided to just re-upload for you without the goofy changelog entry, otherwise looked good, so accepting.
<rbasak> Can I chase someone for an FFe ack for bug 1209493 please? I have an upload ready; I just need an FFe approved and for the delayed NMU to land in Debian so that I can check we aren't diverging.
<ubot2> Launchpad bug 1209493 in subversion (Ubuntu) "[FFe] libapache2-svn missing in saucy" [Undecided,Confirmed] https://launchpad.net/bugs/1209493
<rbasak> (also, a sponsor)
<smartboyhw> Laney, un-NEW and unblock the ardour3 sync please:)
<Laney> cannot
<smartboyhw> Laney, uh oh, well, then just a wide release team asking then
<Laney> You mean archive admin
<smartboyhw> Laney, yep....
<smartboyhw> Laney, you aren't one of the AAs?
<Laney> afraid not
<smartboyhw> :O
<smartboyhw> News for me
<Laney> https://launchpad.net/~ubuntu-archive/+members
<Laney> Maybe one day :-)
<smartboyhw> Laney, I hope you can be one:)
<Laney> Anyway, I'm sure someone will get to it soon
<Laney> syncs are easy
<cjwatson> done
<smartboyhw> cjwatson, thank you
<lool> someone mind if I block hint upstart into proposed to do a boot test before it reaches saucy?
<lool> this is for https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1234898
<ubot2> Launchpad bug 1234898 in upstart (Ubuntu) "upstart-local-bridge not handling all events sent to it" [Undecided,In progress]
<lool> sergiusens: ^
<cjwatson> feel free
<lool> pushed
<lool> jodh: please upload upstart bug fix for https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1234898 ASAP and heads up here to get a review to get out of unapproved, then someone to boot test it  :-)
<ubot2> Launchpad bug 1234898 in upstart (Ubuntu) "upstart-local-bridge not handling all events sent to it" [Undecided,In progress]
<jodh> lool: I'd really like someone else to test it first.
<ogra_> sergiusens, ^^^
<sergiusens> ogra_, I think he means someone else than me
<lool> sergiusens: did you test it?
<lool> jodh: we can test it in -proposed?
<lool> jodh: it wont move to saucy
<lool> jodh: but yeah, testing before upload is also important
<jodh> sergiusens: I was actually meaning you, or someone on your team :)
<sergiusens> lool, yeah, I have a loop that cosntantly running with the fix
<sergiusens> jodh, oh, I commented on the bug :-)
<lool> jodh: I'd like the final binaries from saucy-proposed to be tested too before they get green light, so let's upload with sergiusens' testing in mind, and test the .deb before it goes in saucy
<jodh> sergiusens: are you sure? the last comment is mine asking for testing.
<sergiusens> jodh, I can make a wider scale test than what I did in the bug, but I am certain that I'm consistently getting the event I'm after now
<sergiusens> jodh, :-/ didn't hit send in the reply :-/
<sergiusens> sorry about that
<sergiusens> anyways, I was wasn't expecting so much excitement from lool and ogra when I asked for it to be in the plan just so it's there
<jodh> sergiusens: please can you add a comment ?
<jodh> sergiusens: got it.
<sergiusens> jodh, it's there; although I'm on 20+ now
<lool> sergiusens: trying to get isolated fixed in quickly
<jodh> xnox: can you review the MP I've raised and merge upstream? https://code.launchpad.net/~jamesodhunt/upstart/bug-1234898/+merge/189296
<lool> this one sounded safe and important
<smoser> hey all.
<smoser> i'm looking for some release team member to judge acceptability of bug 1233486 fix.
<ubot2> Launchpad bug 1233486 in software-properties (Ubuntu) "add support for 'cloud-archive:' like 'ppa:' but for cloud archive" [Undecided,New] https://launchpad.net/bugs/1233486
<smoser> my branch linked there works for 'apt-add-repository' and for this stuff there isn't much other known path through that code, and I believe I've retained backwards compatibility from the library interface path.
<xnox> jodh: right. After lunch =/ ?! maybe you can merge the slangasek's reviewed proposal from me as well? https://code.launchpad.net/~xnox/upstart/fix-1234841/+merge/189292
<jodh> xnox: ok, thanks. I've merged your branch now. Can you ping me to avoid dual uploads again? :)
<lool> jodh, xnox: Where's this upstart upload?
<lool> would love getting this in the next image
<jodh> lool: waiting for xnox to review atm.
<xnox> lool: jodh: ^
<xnox> jodh: do you receive your pings?! =) ^
<jodh> xnox: no - as I've mentioned to you before, emacs has stopped doing this for me recently. I'll raise a bug...
<jodh> xnox: maybe time for irssi? :)
<jodh> xnox: thanks for upload.
<Laney> https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1220701
<ubot2> Launchpad bug 1220701 in nova (Ubuntu) "FFE: 13.10 Native nova lxc driver" [Undecided,Incomplete]
<Laney> why bother filing an exception request if you're just going to upload before it's approved?
<Laney> zul:
<zul> Laney:  sorry about that it shouldnt have happened
<smoser> jodh, can i start on mounted mountpoint=/run and not block ?
<smoser> sorry. badk channdle
<jodh> smoser: 'mounted' is a blocking event (upstart-events(7)), but you could always have a job that specifies that 'start on' and then calls 'start --no-wait other-job' if you have a long-running op you don't want to hold up the boot?
<smoser> jodh, its for debugging. and i just have a task, and i just made the task detach itself.
<smoser> ie:
<smoser> script
<smoser> (
<smoser> stuff
<smoser> here
<smoser> ) &
<smoser> end scdript
<smoser> seems to work.
<xnox> smoser: but that double forks a shell for no reason.
<xnox> smoser: please don't do that.
<smoser> it doesnt do it for no reason.
<xnox> smoser: wouldn't that ignore set -e ?
<smoser> it does it for good reason
<smoser> i want it detached!
<xnox> and then without ( ) &, it will start failing.
<smoser> a.) its debug. b.) 'set -e' is complete BS. i much prefer actually catching errors.
<smoser> but this is the wrong channel anyway
<xnox> smoser: upstart exec's all script stanzas with set -e, pre-set.
<smoser> yes, and sometimes i 'set +e' :)
<xnox> =)))))
<xnox> smoser: if you want to not block, have empty exec and use post-start =)
<smoser> that doesn't seem to work in practice, xnox
<smoser> at least now 'start myjob' doesn't even return until the post-start is finished
<xnox> smoser: start --no-wait myjob
<xnox> smoser: using post-start means that events are emitted, use --no-wait if you want to instantly detach.
<xnox> smoser: cause e.g. start $foo, will block until everything else that "starts on starting $foo" completes.
<xnox> (with or without your ()& hack)
<lool> ogra tested new upstart on touch; releasing it out of its -proposed jail
<sil2100> Anyone from the SRU team with some free cycles? ;)
<cjwatson> xnox: Thanks for boost1.54.  You're doing 1.53 too?  (Just checking, not nagging :) )
<xnox> cjwatson: yes, boost takes a whilte to pack, debdiff, build and upload. ditto 1.53-mpi-source
 * cjwatson nods
<xnox> cjwatson: i was going to ping you after all three are done.
<slangasek> infinity: goofy changelog> because I was reusing a working tree, thanks for fixing :)
<xnox> cjwatson: boost1.53 is ready ^ but i guess it will need touch unblock as well.
<jamespage> pls could my horizon and swift uploads be accepted into saucy
<jamespage> I'd quite like todo another test run today with everything at rc1 for openstack + associated fixes
<zul> could the nova upload be accepted please it fixes some autopkgtests issues
<cjwatson> zul: ooh
<zul> cjwatson:  thanks
<lool> Hi there
<lool> I'll be upload three reverted packages which broke ubuntu-touch images
<lool> none of them seeded in Ubuntu AFAICT
<lool> indicator-network, unity8, unity-notifications
<seb128> lool, goind back on the agent that should allow settings to enter a password then I guess?
<lool> seb128: what source is this?
<seb128> lool, the agent was moved out of unity8 to the indicator
<ogra_> oh, that app with the NSA name ...
<lool> seb128: I'm reverting indicator-network and unity8 to their previous versions, would that be correct?
<seb128> lool, https://code.launchpad.net/~indicator-applet-developers/indicator-network/secret-agent/+merge/182898
<ogra_> secret-agent
<lool> seb128: I think that's good
<seb128> lool, no idea, I just know that the settings couldn't accept a password because of the agent was in unity, the update was supposed to fix that
<lool> seb128: we're going to get that bug again, yes
<seb128> lool, so I guess rolling back is going to regress it
<ogra_> lool, did you test removing your wlan and reconnecting ? thats what triggeres the WPA dialog
<lool> seb128: yes
<seb128> :-(
<lool> stgraber: ah it seems indicator-network is still in the desktop packageset
<lool> albeit it should not be seeded anymore?
<lool> stgraber: would you mind approving this one?
<lool> stgraber: it's a revert to the earlier version
<lool> thanks
<infinity> ^-- Ignore that noise, I removed the version in saucy before uploading the new one.
<cjwatson> If ^- that confuses anyone, it's resurrecting a binary from an accidental removal earlier in the cycle
<infinity> cjwatson: Althgouh, why did you copy it to proposed instead of directly back into release?
<infinity> Hopefully britney will cope with the weirdness of that situation.
<cjwatson> I like having the extra verification
<infinity> cjwatson: Will britney deal okay with the "source with no binaries in release, and source with some binaries in proposed" situation?
<infinity> I guess I'll see soon enough.
<cjwatson> Should do
<cjwatson> Its response is generally to copy the source and let Soyuz fill in the extra binaries
<cjwatson> (Which is technically slightly incorrect because not all the binaries might be installable, but ...)
<infinity> There's something oddly satisfying about this archive health video game.
<cjwatson> infinity: Hmm, no, doesn't look like that worked properly.  Will copy by hand
<cjwatson> (libzmq-constants-perl
<cjwatson> )
#ubuntu-release 2013-10-05
<slangasek> smoser, utlemming: how do the changes in cloud-init to cloudinit/sources/DataSourceSmartOS.py relate to the bugs in the changelog?
<smoser> adjusting for the changes required for azure
<slangasek> smoser: what does 'availability-zone' have to do with azure?
<slangasek> smoser: also, isn't there a mismatch between 'availability-zone' and 'availability_zone'?
<smoser> slangasek, crap. that isn't even necessary (as its taken care of elsehwere)
<smoser> :-(
<smoser> well, the availability-zone -> availabilty_zone. something else handles either or on that.
<slangasek> smoser: so does this warrant a reupload?
<smoser> well, i assume utlemming put that in for some reason.
<smoser> he didn't need to put the 'availability_zone' portion in. the getter.
<smoser> but he did add it to SMARTOS_ATTRIB_MAP . and i'm assuming that that solved a problem for him. which unfortunately is not documented.
<smoser> if you want me to re-upload i'll bug utlemming and do that on monday.
<smoser> or you can let this in and we'll get a bug for it anyway.
<slangasek> well, since there's nothing about it in the changelog I'd rather not let it in as-is
<smoser> i'll re-upload quikcly then with a changelog message.
<smoser> please NAK that one
<smoser> and i'll add changelog entry
<slangasek> ok
<slangasek> smoser: but, what will the changelog message say if you don't know what this change was needed for...?
<smoser> i know what the insertion into the map will do
<smoser> and why he'd do that.
<smoser> but the other portion was not necessary
<slangasek> ok. are you backing that bit out then?
<slangasek> or do we just trust that it's a no-op?
<smoser> it is a noop
<smoser> but i'm backing out
<smoser> and will upload
<smoser> quickly
<slangasek> okie
<smoser> just pushed
<slangasek> infinity: erm
<slangasek> infinity: the change in -0ubuntu5 is not SRU-worthy and should not hold up the SRU of the rest of the critical fixes
<infinity> slangasek: Oh.  Seemed to me you'd want sbsigntool to also be able to verify sanely, but sure.  I can re-review and accept ubuntu4 from rejected.
<bkerensa> slangasek: Ubuntu Docs is ready for a upload if you would like to sponsor :)
<ginggs> Hi all.  I've noticed some SRU bugs didn't get the usual message that they are in -proposed and needed verification e.g. LP: #1076414, LP: #1006988
<ubot2> Launchpad bug 1076414 in nvidia-settings-updates (Ubuntu) "Transitioning between nvidia drivers (updates, 304, 310) results in install failure due to conflicting nvidia-settings" [High,Invalid] https://launchpad.net/bugs/1076414
<ubot2> Launchpad bug 1006988 in inventor (Ubuntu Precise) "ivview application does not start" [Undecided,In progress] https://launchpad.net/bugs/1006988
<lool> I've blocked unity8, unity-notifications, indicator-network to upload them together to saucy
<lool> cjwatson: Not quite sure why the packageset is ubuntu-desktop here ^
<lool> so we're reuploading unity-notifications + indicator-network + unity8, reverting the reverts for the first two and with proper fix for 3rd one
<cjwatson> lool: dunno, not going to investigate now :)
<lool> cjwatson: fair enough, do you have a sec to review it from unapproved though?
<cjwatson> was just doing so
<lool> awesome
<cjwatson> lool: oh, it's in ubuntu-desktop because there's a manual exception, apparently
 * cjwatson pokes at history
<cjwatson> lool: http://bazaar.launchpad.net/~cjwatson/+junk/packageset/revision/66
<cjwatson> lool: So that's fairly old and if kenvandine no longer thinks that's necessary I can undo the indicator-network part of it
<cjwatson> Maybe it was in desktop installs at the time
<cjwatson> Or maybe they just needed upload privileges to it
<lool> cjwatson: I'll write him a mail asking about it
<cjwatson> Ken joined core-dev since then which might make a difference :)
<cjwatson> remember that it's an extremely recent thing to have being in a packageset have a negative effect (i.e. no auto-accept)
<cjwatson> before that it was generally an unrestricting kind of thing
<lool> cjwatson: yup; I don't particularly mind, it just seems inconsistent with reality
<lool> thanks for looking into it
<cjwatson> it does seem inconsistent - normally I only add that kind of manual exception when it widens permissions, e.g. when the package would otherwise be in core
<cjwatson> but that isn't the case now for indicator-network, so the situation probably changed
<cjwatson> for moving from unseeded to in a package set I would normally ask for a seed entry instead
<smartboyhw> Please ACK Bug 1235651 for us
<ubot2> Launchpad bug 1235651 in ubuntustudio-meta (Ubuntu) "[FFe] Include ardour3 in ubuntustudio-meta" [Undecided,New] https://launchpad.net/bugs/1235651
<slangasek> infinity: we don't rely on sbverify anywhere in the archive, it's only used by some QA tests, and the SRU isn't going to happen quickly enough to be a reasonable solution for those currently-failing tests.  So, thanks for the un-reject. :)
<lool> it looks like britney didn't run for a couple of hours?
<lool> cjwatson: FYI ^
<slangasek> lool: I fear that's probably related to the mail Larry just sent out about jenkins private IP changing and firewall rules getting in the way of jobs from snakefruit + nusakan
<slangasek> if britney can't talk to jenkins, it can't get ADT results
<slangasek> so, RT #65040
<slangasek> retoaded: is there a committment from IS to work on this ticket over the weekend?  saucy development is dead in the water until that firewall rule is fixed
<slangasek> retoaded: so if the firewall isn't getting fixed until Monday, I think we need britney to be able to continue to reach jenkins on the old IP until then
<lool> Dropping him an email too to max chances of this being seen
<lool> slangasek: it's a bit surprizing in terms of timing that it blocks now though
<slangasek> I suspect this dependency was overlooked in the migration plan for magners, otherwise the RT would've been filed sooner than 9pm London time on a Friday
<lool> I don't quite understand how when moving to a new IP we're not copying over all rules from the old IP
<lool> perhaps because we're resplitting multiple services across different machines
<lool> but seems like we should be tracking dependencies between services better
<lool> anyway
<lool> win 33
<lool> ups
<slangasek> hmm, but now I'm doubting that the firewall is the issue
<slangasek> at least, direct connection to both old and new IPs fails, as does connecting via the proxy
<lool> slangasek: it happened in the past that britney got stuck
<slangasek> I don't see evidence of that
<lool> but I think it's now running on a host that I'm not sure I have access to
<slangasek> snakefruit
<lool> yeah, my public key isn't accepted there
<lool> if you can check whether there's a stale britney process running for a long time there
<slangasek> there is not
<slangasek> I think this *is* related to the jenkins move
<slangasek> I just am not sure it's a firewall issue
<slangasek> lool: so, running britney by hand appears to have succeeded
<slangasek> but only the third time I ran it
<slangasek> and that doesn't explain the lack of attempts over the past 3h
<slangasek> it's possible that britney didn't run because there were no new packages accepted into -proposed?  the britney run is guarded by:
<slangasek> if release_changed "$DEVEL" || release_changed "$DEVEL-proposed"; then
<slangasek>         background pids run-proposed-migration
<slangasek> fi
<slangasek> anyway, evidently my manual test of jenkins availability from snakefruit was flawed somehow
<slangasek> retoaded: ^^ seems we're not as blocked as I was afraid we were
<lool> slangasek: ah cool, I thought of this at first because it seemed to run less frequently over the week-end, but then I discarded the idea because it seemed a poor choice considering a) people might upload hints at any time and b) transitions might be held by autopkgtests
<infinity> Yeah, the 'if changed' logic stopped making sense when autopkgtesting was added to the mix.
<infinity> We could change the trigger from "release_changed" to "germinate_changed", but then britney will run later in the publisher cycle and miss the window to promote before the next run.
<infinity> The proper answer is to trigger it *from* ftpmaster, which we intend to do.
<infinity> I guess we could run it on release_changed || germinate_changed.
<infinity> There.  Done.
<infinity> Wait, no.
 * infinity undoes.
<infinity> Having it promote twice in the same publisher cycle might be less than ideal.
<infinity> I think we probably just want to fix this properly, with an SSH trigger.
<stgraber> infinity: I think what we discussed at the sprint was triggering from ftpmaster + every 5 or 10 minutes (if no ftpmaster trigger in between)
<stgraber> that was to workaround the case of a frozen archive with very little changes but required britney run to monitor autopkgtest and get things copied over
<infinity> stgraber: A frozen archive still runs the publisher.
<infinity> stgraber: So, it really just needs to trigger unconditionally, post-publish-attempt, even if no dirty pockets published.
<stgraber> infinity: wouldn't that mean running britney basically continuously given how often we run the publisher nowadays?
<infinity> stgraber: Ish, but not quite.  britney still runs much faster than the publisher.
<slangasek> right, but the cron trigger is set up to run every minute... which may be excessive frequency
<retoaded> slangasek, ack
#ubuntu-release 2013-10-06
<smartboyhw> People: Does bugs requesting a UIFe but NOT a FFe need to subscribe ~ubuntu-release?
#ubuntu-release 2014-09-29
<ScottK> ^^^ is just rejected so it doesn't get inadvertently accepted before I get my testing questions answered.
<ScottK> And an FFe reviewed.
<Laney> blerg, need to remember to pass --source to queue
<apw> ^ bug fix only update to ensure thermald runs correctly in the face of sysfs bits being late to the party
<rbasak> cjwatson: reuploaded bcache-tools. Thanks for the review.
<cjwatson> rbasak: ta
<cjwatson> zul: Um I just noticed that python-nova.flex contains no useful files.  Please can you run packages through sbuild before uploading them?
<apw> ^ fix for vbox VMs failing to reach lightdm
<knome> \o/
<mlankhorst> oh for the love of god..
<mlankhorst> https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1374131 seems that it needs libgl1-mesa-dri installed
<ubot2> Launchpad bug 1374131 in mesa (Ubuntu) "qtcreator-plugin autopkgtest fails on AMD64 mesa mesa_10.3.0" [Critical,Confirmed]
<ogra_> can someone approve phablet-tools and ubuntu-touch-meta ?
<ogra_> (i thought there is a bot that does it)
<ogra_> Laney, i assume you justified with the right people that it is ok to add another font to the seed (while we are just trying to only drop bits to make space)
<cjwatson> 10:57 -queuebot:#ubuntu-release- Unapproved: accepted phablet-tools [sync] (utopic-proposed) [1.1+14.10.20140929-0ubuntu1]
<ogra_> oh
<Laney> ogra_: are you telling me off?
<ogra_> missed that
<cjwatson> And I'm not sure how ubuntu-touch-meta can possibly be accepted given that 1.187 is already in the archive.
<cjwatson> rejecting
<ogra_> Laney, no, i was wondering if you talked to pmcgowan and slangasek ... who work on shrinking the image :)
<ogra_> hmm
<ogra_> why didnt i see it on -cahnges then
<cjwatson> Please use "pull-lp-source ubuntu-touch-meta" as your starting point for uploads
<Laney> I didn't justify with anybody, go ahead and revert if you want. Seems like a valid enough request to me.
<cjwatson> ogra_: anyway, https://lists.ubuntu.com/archives/utopic-changes/2014-September/010878.html
<ogra_> Laney, right, to me too ... we can still remove it if someone complains ... that was simply the reason why i didnt merge it yet
<ogra_> cjwatson, yeah, i see it now
<Laney> Nobody even responded to the request at all
<cjwatson> ... but it makes ubuntu-touch/i386 uninstallable apparently
<ogra_> hmm
<cjwatson>  libqt5gui5-gles : Conflicts: libqt5gui5 but 5.3.0+dfsg-2ubuntu6 is to be installed
<cjwatson>  libqt5quick5-gles : Conflicts: libqt5quick5 but 5.3.0-3ubuntu12 is to be installed
<cjwatson> because signon-apparmor-extension needs to be built against -gles on !armhf, I think?
<ogra_> oh, fun
<cjwatson> possibly
<ogra_> yeah
<cjwatson> oh, no, it's the sdk-libs changes
<ogra_> so that needs arch specific differentiation i guess
<cjwatson> yup, will sort it out
<ogra_> thanks
<cjwatson> ogra_: does http://paste.ubuntu.com/8454630/ look right in terms of the package organisation?
<ogra_> cjwatson, it does, are these two enough ?
<cjwatson> the others there don't have -gles variants
<ogra_> k
<cjwatson> Laney: it would be nice if you could have merged your branch into trunk when you noticed the divergence, rather than merging trunk into your branch and then pushing that over the top of trunk
<cjwatson> produces confusing bzr log :-/
<Laney> mmm, apols, can overwrite if you like?
<cjwatson> if you could then now might be a good time, yeah
<Laney> cjwatson: try that
<cjwatson> Laney: thanks
<cjwatson> ogra_: committed, if you want to redo a 1.188 upload with a fresh seed update
<mlankhorst> cjwatson: hey I've fixed the dependency issue of mesa, shall I re-upload?
<cjwatson> mlankhorst: I know nothing about this beyond people having asked me about it the other day and me redirecting them
<cjwatson> Do what seems appropriate :)
<mlankhorst> I've found the root cause at least
<mlankhorst> it being that it was working by pure chance before. :P
<mlankhorst>  DISPLAY=:0 glxinfo
<mlankhorst> name of display: :0
<mlankhorst> Error: couldn't find RGB GLX visual or fbconfig
<mlankhorst> oops
<mlankhorst> didn't mean to copy paste
<Laney> It'd be nice if someone could review gnome-desktop3 - it's a small transition that we want to do quickly
<cjwatson> infinity,slangasek: openssl and grub2 reviews from unapproved would be lovely when you're around.
<ogra_> that package name could need a few more "s" in it :P
<jamespage> ^^ that keystone upload does a variety of good things and should unblock all of the pending oslo.* packages stuck in proposed on failing autopkgtests
<mlankhorst> same for mesa, i promise it won't break qtbase-opensource-src this time. :D
<cjwatson> reviewing
<Laney> is it possible to get the signer of a queue item?
<Laney> Don't see anything on package_upload
<ScottK> For mesa it's not the known stuff I worry about.
<jamespage> thanks cjwatson
<Riddell> anyone know what's wrong with okular? it seems the main blocker to KDE SC 4.14.1 bits getting in the archive but I can't see a failure in jenkins http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<rbasak> Riddell: https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-okular/lastBuild/? shows as failed to me.
<Laney> https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-okular/lastBuild/ARCH=amd64,label=adt/artifact/results/testsuite-stdout
<Laney> That's faily
<Riddell> ah hah, I was looking at the "log" file
<Riddell> thanks Laney
<Laney> it's in there, you just have to look harder
<Laney> 'testsuite' has its output before 'acc'
<Riddell> ah yes, still getting my head around this autopkgtest stuff
<zul> ^^^ the nova-compute-flex makes it installable and fixes races with cgmanager
<infinity> cjwatson: I assume you're using the word "review" very loosely in the openssl case.
<infinity> cjwatson: "Yes, your rainbow tables all look correct, I re-calculated them on a napkin."
<cjwatson> infinity: right :)  that took me roughly a day of resolving merges on two monitors
<cjwatson> infinity: I ended up importing the current package state into git temporarily so that I could cherry-pick the requested series from upstream and then compare that against the rolled-up patch I'd been given to make sure I'd resolved conflicts correctly ...
<infinity> cjwatson: Well, not matching theirs doesn't imply you're the one that did it wrong. :P
<infinity> cjwatson: But if both ended up the same, that has some implication that you're both equally smart or equally unlucky.
<infinity> cjwatson: So, yeah, more of a verbal review, then.  Did yours, indeed, match theirs in the end?
<infinity> cjwatson: And this is building with full testsuite goodness and no obvious regressions?
<cjwatson> close enough.  there were a few bits where they'd pulled unnecessary bits of other patches, and I went with my own resolution.  I'd made one or two mistakes which I found that way and corrected.
<infinity> cjwatson: And, how can we test the POWER8 stuff (can I build it on a P7 host, and run a testsuite on P8 and watch for bogons?)
<cjwatson> I built on amd64/powerpc/ppc64el and the test suites passed
<cjwatson> I trust that the last is true but don't have one to test on :)
<infinity> Sure, but building on ppc64el probably means POWER7, which would skip any P8-optimised bits.
<infinity> So, how can we test on P8?  I think we should, since that's the whole point of the upload.
<cjwatson> Fair question.  I think: build source package on p7, rsync built tree to p8, run 'make test'
<cjwatson> Do I have access to one I've forgotten about?
<infinity> cjwatson: Kay.  That sounds reasonable.  Want to spin up a test tree on kelsey, and I'll do the second bit when I find a host to slap a chroot on?
<infinity> cjwatson: You might have access to a few, though what state any of them are in is the more interesting question.
<cjwatson> infinity: OK, (re-)building on kelsey01
<cjwatson> infinity: kelsey01:~cjwatson/openssl-1.0.1f/
<infinity> cjwatson: Ta.
<dobey> uploads to seeded packages are ok now as long as they don't break feature/ui/string freeze, right?
<cjwatson> Yes, they're just held for manual review
<dobey> ok
<cjwatson> infinity: I take it it passed?
<infinity> cjwatson: Nah, I was on a call with our fearless leader.
<cjwatson> infinity: Oh.  Somebody accepted it.
<infinity> Oh.  Indeed somebody did.
<infinity> I wonder how they "reviewed" it.
<infinity> Anyone want to confess to accepting that openssl upload? :P
<infinity> cjwatson: I guess no one's fessing up.  I'll test it anyway in a bit.
<infinity> (I wish someone had finished that queue auditing feature...)
<cjwatson> Thanks
<bdmurray> cjwatson: slangasek ran change-override for aptdaemon but there is no information about that here - https://launchpad.net/ubuntu/trusty/amd64/aptdaemon. Any ideas?
<cjwatson> bdmurray: That's where it would've appeared
<cjwatson> So need to know what he did
<cjwatson> (Assuming he did a binary override in the correct suite including that architecture ...)
<infinity> bdmurray: Ran change-override to what end?
<bdmurray> infinity: to fully phased the update
<bdmurray> 18:09 <slangasek> $ change-override -z 100 -s  trusty-updates aptdaemon
<infinity> Looks fully phased to me.
<cjwatson> Then that worked fine
<cjwatson> phase 100 shows empty in that column
<infinity> Empty... What Colin said.
<infinity> Small UI bug that could be filed, perhaps.
<infinity> Er, of course, that should have been -S aptdaemon, to phase all the binaries from the source.
<infinity> Oh, I say that, but python3-aptdaemon also looks phased.
<infinity> So maybe slangasek did them individually.
<infinity> slangasek: ^?
<bdmurray> I understand that empty means 100%, the timing is particularly confusing
<bdmurray> 17:08:15 ... 0% of users
<bdmurray> 17:08:14 ... empty
<slangasek> infinity: I mistakenly did it without -S the first time around, then went back and used -S on a second pass when bdmurray called my attention back to it
<infinity> bdmurray: That's the date it was deleted/superseded, not the date it was set to 0%
<infinity> slangasek: Ahh, kay.
<infinity> bdmurray: The history output is a bit confusing in that regard, I agree.
<slangasek> cjwatson, infinity: I accepted the openssl upload, as cjwatson highlighted both of us and infinity did not tell me he was claiming it :)
<infinity> slangasek: Oh.  Backscroll had me waffling about unreviewability and that it should be tested first.
<slangasek> infinity: yep; didn't see that until now
<slangasek> so, well, feel free to continue testing
<infinity> slangasek: But I assume you pored over all the assembly and recalculated the rainbow tables by hand, so we're good. ;)
<slangasek> I'll say that's what I did, sure
<infinity> :)
<infinity> bdmurray: Hrm.  Is it an lpapi bug or sru-review bug that it seems to pick up the wrong diff for a package that's been uploaded, rejected, and reuploaded with the same version?
<bdmurray> infinity: which package?
<infinity> bdmurray: flash-kernel, it's picking the debdiff from rejected.
<bdmurray> infinity: it uses the debdiff in launchpad so - https://launchpadlibrarian.net/186070966/flash-kernel_3.0~rc.4ubuntu49.3_3.0~rc.4ubuntu49.4.diff.gz
<infinity> bdmurray: But that's not the diff I'm getting.
<infinity> bdmurray: Does it cache locally?
<bdmurray> infinity: nope, I'll take a look
<infinity> bdmurray: ... And now I do get that diff.  WTF?
<infinity> bdmurray: Does it fall back to other queues if unapproved doesn't have a diff yet, maybe?
<bdmurray> infinity: no, but there is a --queue option
<infinity> bdmurray: Which I wasn't uding, since it defaults to unapproved.
<infinity> s/uding/using/
<hallyn> hi, bugs 1374622, 1374617 and 1374612 fix the inability to migrate VMs from p->t.  The latter two require FFE for u.  The second is a new package with only 4 pxe roms.
<ubot2> bug 1374622 in libvirt (Ubuntu Trusty) "Support migration from 12.04" [High,New] https://launchpad.net/bugs/1374622
<ubot2> bug 1374617 in Ubuntu Trusty "[FFE] New package: ipxe-precise" [High,New] https://launchpad.net/bugs/1374617
<ubot2> bug 1374612 in qemu (Ubuntu Trusty) "[FFE] add pc-1.0-precise machine type" [High,New] https://launchpad.net/bugs/1374612
<infinity> hallyn: How is this meant to work to the user without excessive documentation?
<infinity> hallyn: If their old machines were pc-1.0, starting them on trusty won't magically use pc-1.0-precise, I assume.  Will it fail to boot gracefully with an error telling them what to do?
<infinity> hallyn: And once it's migrated, does it become "pc-1.0" again and use the new ipxe ROMs, or are they stuck as pc-1.0-precise forever?
<infinity> I'm a bit fuzzy on how this works.
<hallyn> infinity: once they've migrated to trusty, it'll be called pc-1.0-precise
<hallyn> then they can edit the machine type to be something newer if they like
<infinity> Can't that be handled transparently, then?
<hallyn> but yes, the switch to pc-1.0-precise wont' be automatic.  they have to set a libvirt flag
<hallyn> which part
<infinity> Well, with any luck, all of it.
<infinity> So, AIUI, we need to go from precise/1.0 to trusty/1.0-precise to trusty/1.0, cause you stop in the middle, you're still using ipxe-precise, which we don't want to keep forever, yes?
<hallyn> no.  because pc-1.0 means two different things.  so we are introducing pc-1.0-precise to refer to one of them, and using the libvirt flag to tell libvirt which to use
<infinity> s/cause you/cause if you/
<hallyn> it's ok to use pc-1.0-precise at least as long as precise is supported
<hallyn> and realistically we'll probably never get rid of it.
<infinity> So, I guess I have two questions.  1) if we can move from trusty/1.0-precise to trusty/1.0, why can't we move from precise/1.0 to trusty/1.0, and 2) can we make either step more automatic?
<hallyn> just as the default machine type in trusty is now caled 'pc-i440fx-trusty
<hallyn> 1) is false.  ou'd move to something newer ,not to 1.0
<hallyn> 2) we can't make it more automatic bc there is no way to tell which pc-1.0 they are sending us.
<infinity> Err, whatever, ignore my terminology.
<infinity> But you can move from trusty/1.0-precise to trusty/pc-i440fx-trusty then, right?
<hallyn> while it is shut down, yes
<infinity> What happens when I try to migrate precise to trusty today?
<hallyn> one of the proposed packages is to make pc-1.0-precise the default in precise to cut down on the amount by which this happens now
<hallyn> it simply fails
<infinity> Is it a detectable failure?
<infinity> Or completely nonsensical?
<hallyn> not complete nonsensical.  it's detectable if yo uknow what to look for
<infinity> Okay, so if it's detectable, it's automatable.
<hallyn> it'll complain about memory segments not being the same or somesuch
<hallyn> at what level though.  some ppl are doing qemu migration by hand.  there yo ubasically get no feedback at the source site, other than that the vm kept running instead of stopping
<hallyn> some are using libvirt.  we coudl indeed try to fix it automatically there, but it would not be simple.  the destination would have to detect it, then tell the source to restart
<hallyn> the ipxe-precise package would be needed regardless,
<hallyn> for qemu users really it can't be automaticed more tha nit is - you specify the target machine type with 'qemu -M pc-1.0-precise', jsuts as you would otherwise do 'qemu -M pc-1.0'.  you have to specify it regardless.
<infinity> hallyn: Right, not disputing the need for the new package, just thinking that we can do better than "oh, yeah, that failed because you need to read obscure doc X".
<infinity> hallyn: For qemu, it could still be trapped, I'd think.  If -M pc-1.0 runs into the memory segment consistency issue, can we not do some checksums, compare to our other ipxe on disk, go "oh, no, we need that one", and reboot with that machine type?
<hallyn> we have discussed making the fallback to the pc-1.0-precise the default;  that would throw users who were using 'pc-1.0' in trusty (which some would say would be their own fault, but i think that's not quite true)
<infinity> hallyn: Thus eliminating the need for people or tools to specify -precise at all, we just twiddle it.
<hallyn> rharper: ^ got a job for you :)
<rharper> hallyn: sup
<hallyn> infinity: it may be possible
<hallyn> i'm not sure we can restart at that level
<hallyn> sure we can always re-exec ourselves :)
<infinity> It's all just a userspace program, you can restart at any level.
<infinity> You just need some cleverness.
<hallyn> do we want cleverness in an sru?
<infinity> I'd rather cleverness than something that technically fixes the issue but is hard to discover.
<hallyn> so yeah, it should be possible.  detect an old vga size paired with pc-1.0, then re-exec ourselves with "-M pc-1.0-precise"
<infinity> At worst, I'd like it to be able to detect the issue and print "you probably want -M pc-1.0-precise", but once we've gone that far trapping it, a bit more clever to JDTRT might be the best option.
<rharper> hallyn: if I'm reading backscroll right, neither qemu nor libvirt are the right place to "detect" which type to be used
<hallyn> then what is?
<infinity> qemu seems like the ideal lowest common denominator.
<infinity> It's the only one that knows something's broken.
<hallyn> if we *could* have qemu just re-exec itself, then libvirt wouldn't need to do anything
<rharper> at the end of the day, folks without a higher level management tool which makes migration and machine type decisions (versus taking hte defaults which is what both do) it's going to be trouble getting it "right"
<hallyn> infinity: so to be clear the machine type as such is not passed from source to destination
<rharper> not sure I follow the re-exec -- when migration fails you retain the original qemu -- and IIUC folks don't want to actually have to reboot/restart their qemu VM
<hallyn> rharper: re-exec the destination
<rharper> who?
<hallyn> and somehow signal the source to restart :)
<hallyn> itself
<rharper> no one is reexecting in the qemu case
<rharper> libvirt *could* but that's just a guess
<rharper> and what if migration fails for some other reason
<hallyn> qemu could do it itself.
<rharper> no way to know that it should do that
<infinity> What if it fails for "some other reason'?
<infinity> I don't care about some other reason.
<infinity> I'm specifically curious about "pc-1.0" failing due to this specific issue.
<hallyn> detect that vgasize is that of pc-1.0-precise while m-t is pc-1.0.  D oit only in that case
<rharper> how long do you want and how many times do we want qemu to keep rexecing itself ?
<hallyn> infinity: but i still don't know how we could tell the source qemu to re-start migration
<infinity> Which should be entirely solvable by detecting the situation and swithcing to pc-1.0-precise.
<rharper> this all seems crazy hacky
<hallyn> rharper: agreed, but the goal of something easier ofr the user to discover is laudible
<rharper> scan some part of the incoming migration data, some how track these parts in some state (or write it out) so it can recall what happened the last N times we re-exec'ed ourselves ?
<hallyn> rharper: yup, write out what we've read so far, re-exec ourselves with -m pc-1.0-precise;  if we're already exec'd with that we just fail
<infinity> hallyn: So, the problem here is that qemu itself is also doing the migration?  This isn't fed to it by some higher level tool?  (I'm mostly ignorant to how this works).
<rharper> that sounds like a really bad idea w.r.t keep state, how to handle if the file is still around, or if it contains bogus data, or ...
<hallyn> infinity: right, the two qemu processes do it with a'migrate' API
<hallyn> rharper: it works for upstart :)
<infinity> And who triggers the migration?  Source or destination?
<rharper> qemu can't migrate itself -- it always requires a third party to initiate migration
<hallyn> both :)
<rharper> neither
<rharper> mgmt
<hallyn> destination is started with "-incoming tcp:0.0.0.0:5555"
<hallyn> source is told "migrate tcp:a.b.c.d:5555"
<rharper> management application ( most likely libvirt ) is issued a migration command to the source (with the destination URL);
<rharper> and mgmt app does as hallyn describes under the covers;
<infinity> Okay, but once it's started, the destination knows the source, as it has an open TCP connection to it.
<hallyn> and qemu does the migration :P
<hallyn> yup
<infinity> So, no need to save temp files or other ugliness.
<rharper> we can't modify the migration protocol
<infinity> You detect the bad memory segment, and restart the source migration.
<rharper> source doesn't retain any state w.r.t migration succeeding or failing, the mgmt application can/could
<hallyn> infinity: if we make that kind of change, supporting/backporting future CVEs until 2019 is gonna hurt
<infinity> Bleh.  Maybe.
<infinity> I just see limited value in non-discoverable ways to work around bugs.
<hallyn> well lemme put it another way - i don't believe any 'ordinary user' is going to migrate vms from P->T
<infinity> And "we documented it somewhere, really" isn't discoverable.
<hallyn> we saw limited value in supporting this at all, but ablight needed it enough that he wrote the patches himself to fix it.  his own site is done entirely with thie rown mgmt toold
<rharper> honestly, the easiest fix I'd say for 99% of folks is to shutdown your Precise VM, modify the machine type to pc-1.0-precise
<rharper> and then we're all good
<rharper> or offline migration to trusty
<hallyn> agreed.  this is mainly for ppl who have tons of customers not willing to shut down
<infinity> rharper: sure, but those people need to be told to do that.
<hallyn> but we can't predict how they're using this.  if they're using netcat to a qemu monitor socket they won't see any info we try to hand them
<infinity> Anyhow, I'm not saying magic is a blocker for this, I'm just examining if there are better ways.
<rharper> indeed;  I don't think there is an easy package-specific place to do this...
<hallyn> so right now what happens is - they try to migrate, it fails.  the question is, is there any better way - other than release notes and/or a lp bug - to let them know that hey they can re-try it like this
<infinity> I'm more concerned about if this will come up again between 14.04 and 16.04, etc.
<hallyn> that shouldn't, that's why we have the pc-i440fx-trusty machine type
<hallyn> so we can do magic
<infinity> hallyn: Release Notes are useless to communicate to users on release day, they're even worse after.
<hallyn> we could do magic if we didn't care about 14.04 pc-1.0 users
<infinity> hallyn: So, a special trusty machine type is a start, but I assume this still implies we might need 14.04 ROMs in 16.04?
<infinity> hallyn: So, better magic for the users, same mess for us? :)
<rharper> documenting on wiki and socializing the document
<rharper> that's not the best, but better than nothing
<hallyn> infinity: we will need old roms, yes.  fixing that is not up to us, but up to the qemu folks.  they believe it's up to distros to work that out.
<infinity> I wonder if/how this affects non-BIOS arches.
<infinity> OVMF, SLOF, etc.
<hallyn> egads, for that matter, we never got qemu-slof ot compile for utopic
<hallyn> ("that reminds me")
<infinity> hallyn: Err, never got it to compile?
<infinity> hallyn: Is it currently sad?
<hallyn> correct.
<infinity> binutils segv.  Exciting.
<infinity> I can look at that in a bit.
<hallyn> infinity: now the roms have to change their size to the next o(log n) or something before it matters that they changed, which odesn 'thappen much.  otherwise new roms are fine during migration.
<hallyn> but when thta does happen, then we need to package the old roms and direct qemu to them.
<hallyn> on the bright side, we can do that automatically
<hallyn> (for the user, not for us)
<infinity> This all sounds a whole like some serious design flaws. ;)
<rharper> fwiw I do believe this is something that QEMU should address upstream, but it's not an easy thing to do
<infinity> Alright, so I'm not happy about, but can accept "manual migration, icky forward-ported ROMs, and socializing docs", but I'd really like better answers.
<infinity> The docs part goes away for 14.04->16.04, so that's a plus, but the rest still looks sketchy.
<rharper> the idea of a OS or VM being bound to a machine, is very much like real hardware ... and part of real hardware (and virtual) is the BIOS/Firmware/Blob -- that ought to be something we can encapsulate (if users desire)
<rharper> and possibly included in the payload of the VM.
<infinity> rharper: Effectively, save the firmware blobs that the VM was started with as an nvram blob that gets reused and passed around?
<infinity> That has the disadvantage that it's then hard to upgrade the firmware.
<infinity> But I guess this is a case where having and eating cake might just be really hard.
<infinity> Or impossible.
<rharper> infinity: I think it can be worked out -- the nvram stuff already has a "writable" drive that needs to be kept with the the VM
<rharper> no reason that we couldn't keep/load/write roms for BIOS as well -- but we need to think carefully about how to handle the permissions needed to host these VMs that can care and update their own BIOS
<rharper> with something like qcow2 (or other metadata drive files) one could even mark out hidden partitions to hold this... but it's seriously like a qemu 3.0 sort of feature as it will cut across all of QEMU
<hallyn> rharper: did you mention recently that you were talking about just that with qemu upstream?  What sort of venue was that, i.e. email/irc, and is there a log?
<infinity> rharper: Yeah, that sounds rather complex and whacky.
<rharper> hallyn: not upstream, with alex
<rharper> hallyn: I probably have the log
<hallyn> rharper: oh, ok, i thought you had told alex you'd been talking with upstream about something like that.  nm then
<hallyn> infinity: so really, the libvirt patch could be tweaked so that if /etc/libivrt/qemu.conf does not have 'assume_incoming_qemukvm = 1' and machine type is pc-1.0, it spits a warning out "if migration fails, try setting that"
<ari-tczew> do we still use subscribing to ~ubuntu-release for FFe reviews?
<infinity> ari-tczew: Yeah.  It does hurt to poke people on IRC too, though.
<infinity> cjwatson: Want to lob a grub2-signed at the queue too, or should I do that?
<cjwatson> infinity: I was going to do that, yeah.
<cjwatson> infinity: ^-
<infinity> cjwatson: Ta.
<xnox> infinity: Laney: poke re:FFe Bug #1372367
<ubot2> bug 1372367 in btrfs-tools (Ubuntu Utopic) "FFe Upgrade btrfs-tools to 3.16" [Undecided,New] https://launchpad.net/bugs/1372367
#ubuntu-release 2014-09-30
<Laney> xnox: at least the NEWS would be nice, preferably some info on how you've tested it too
<Laney> can we have a v-series set up in LP?
<infinity> wgrant: ^
<infinity> wgrant: Time for v/w/x to get ahead of the curve?
<wgrant> infinity: TB should be able to do that, I think.
<wgrant> I can't do it myself.
<infinity> wgrant: Oh, sure, I can do it.  I thought for some odd reason you'd been involved in the last round of "make a ton in advance".
<wgrant> infinity: It's of course very possible that I fixed that permission as part of the RTM work.
<infinity> wgrant: Heh.
<elfy> apw: still no go here with vbox and today's daily re bug 1371651
<ubot2> bug 1371651 in plymouth (Ubuntu) "Daily does not boot into graphical interface after installation" [Critical,Fix released] https://launchpad.net/bugs/1371651
<apw> elfy, i'll resync my images and see what it does for me
<apw> elfy, what version of plymouth do you have
<elfy> apw: 0.9.0-0ubuntu6
<apw> elfy, and your symptom is the "no lightdm starting, but if you start it manually it works"
<elfy> yea
<elfy> lightdm status is stop/waiting
<elfy> apw: new symptom now - previous to the plymouth change - it WOULD boot to login if I booted with systemd - now it doesn't do that
<elfy> bbl
<apw> elfy, that makes little to no sense ... hmmm
<elfy> yea - I'm just telling what I see ;)
<elfy> back to work now
<pitti> hello
<pitti> cleaning up -proposed a bit; for a case like mercurial where the new version in -proposed Breaks: an existing version in utopic (like mercurial-git)
<pitti> should we sync hg-git from unstable as well to get the matching version, or remove the new mercurial from -proposed?
<cjwatson> pitti: well, judgement call, but unless the new hg-git seems crazy, for a leaf-ish package like that I'd probably sync it
<pitti> cjwatson: yeah, my gut feeling, too; I'll review the changelog
<Mirv> could qtbase-opensource-src's autopkgtest regression (u-s-s-online-accounts i386) be ignored so that qtbase could proceed to release pocket? it's a mesa/llvm regression, not qtbase.
<Laney> most of that desktop stuff from the last hour is no-change rebuilds, apart from u-s-d
<Laney> I'd appreciate review so that we can progress the gnome-desktop3 transition
<Laney> (sorry for using API copies)
<apw> elfy, seems to work on my vbox setup, come find me on #ubuntu-kernel to discuss
<jamespage> ^^ the retrying bump is needed for the openstack glance rc1 I'm working on atm
<Mirv> FYI oxide-qt's debdiff other than chromium bug fixes: http://pastebin.ubuntu.com/8466001/
<pfsmorigo> infinity, cjwatson: the ppc64el daily is still broken.
<rtg> pfsmorigo, I've just uploaded a kernel a few minutes ago that should fix powernv bare metal installations.
<pfsmorigo> rtg: we had an issue that was cause by the chrp note at the bootloader. do you have a lauchpad id for your fix?
<rtg> pfsmorigo, the 2 bugs that directly impact ppc64el are #1374438 and #1374440
<pfsmorigo> rtg: nice
<cjwatson> infinity: ^- here we go again
<cjwatson> self-accepting d-i as an obvious no-change rebuild
<cjwatson> oh maybe somebody already handled that
<Laney> Cool, I'll accept my own no-change rebuilds then
<cjwatson> I think that's fine
<cjwatson> (obviously)
<Laney> huzzah
<ogra_> yum, cheese
<Laney> It does always look rather tasty when I run it
<dobey> anyone can approve FFe for https://bugs.launchpad.net/ubuntu/+source/unity-scope-click/+bug/1368252 please? about to land in ubuntu-rtm and would like to get it synced back into utopic as well, asap.
<ubot2> Launchpad bug 1368252 in unity-scope-click (Ubuntu RTM) "[FFe] Repetitious language during uninstallation of Apps" [High,In progress]
<slangasek> infinity: did you run the openssl test suite yesterday for POWER8?
<infinity> slangasek: Didn't get to it yet, and I'm about to nap after being up all night, but leave me a poke in /msg as a reminder and I'll do it later (or if you have a victim machine with a chroot and a few minutes, go nuts)
<Laney> thanks reviewer
<cjwatson> np
<apw> ^ second fix for another group of "no display-manager" issues on utopic
#ubuntu-release 2014-10-01
<mlankhorst> arges: I've re-uploaded mesa unmodified, see bug report. :-)
<jamespage> please could the oslo.vmware in the review queue be looked at - I need the version bump for glance and nova rc1's
<Laney> mlankhorst: what is that mesa?
<mlankhorst> Laney: oh mesa in trusty for https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1365490
<ubot2> Launchpad bug 1365490 in mesa (Ubuntu Trusty) "ubuntu 12.04.5 broken on VMware" [High,Incomplete]
<Laney> in the utopic queue
<mlankhorst> er oops?
<Laney> kind of surprised it didn't get rejected outright
<mlankhorst> that one's already in main
<mlankhorst> weird that it didn't get rejected..
<Laney> release
<Laney> and if you want it in trusty then you need to fix the version number and upload with -v, etc
 * Laney kills it
<mlankhorst> but mesa trusty is accidentally messed up slightly, it won't generate a debdiff against 10.1.3-0ubuntu0.1 which is in the archive. instead against a snapshot that was uploaded by accident and already deleted.
<jamespage> ^^ that's basically a no-change rebuild (a2 -> 1.0.0) to deal with internal version checking for entry points via pbr in glance
<arges> mlankhorst: ah thanks, i should have done a manual diff. that looks much more sane.
<mlankhorst> yeah :)
<jamespage> ^^ those last two oslo* uploads are final releases to resolve internal version checking issues in glance
<jamespage> I really hope they are the last two...
<apw> ^ fixes brown-paper-bag failure to install in the previous upload, sigh
<jamespage> ^^ an another minor fix for pbr version mismatches
 * jamespage sighs 
<jamespage> that really should be it now
 * ScottK wonders how reasonable pbr really is.
<jamespage> ScottK, its doing what it says on the tin, but I don't want to put 25k diff version bumps into eventlent and boto
<zul> not reasonable
<jamespage> even if most of that is py3 work
<pfsmorigo> apw, infinity: is there some progress in the recent kernel bug? (#1375452)
<apw> pfsmorigo, the latest kernel upload should have the fix for that applied
<pfsmorigo> apw: good! and how can we have this new kernel in the daily image?
<infinity> pfsmorigo: It needs to work its way through the sausage factory and get built on all arches, etc, but I'll hand-spin a new daily when it's done, probably in ~9h or so?
<infinity> Actual times may vary, but "by tonight (north american time)" is a reasonable estimate.
<pfsmorigo> infinity: hehe
<pfsmorigo> infinity: ok nice
<infinity> cjwatson: Did you reject all the -19 binary NEW linux stuff, or NBS clean it from -proposed already, or am I just blind and can't find it?
<infinity> I'm just blind.
<infinity> Must have been looking at an old version of the queue.
<infinity> apw: ^-- That should make our lives easier, no NBS mess.
<infinity> cjwatson: If "make test" passes on here, is that good enough, or should I be looking to make sure it ran specific things, etc?
<cjwatson> I think "make test" is probably fine
<infinity> cjwatson: Alright, then it passed on a POWER8 system.
<cjwatson> Also, 9h is about when the daily would build all by itself anyway
<cjwatson> Woo
<infinity> cjwatson: Yeah, we might be racing cron with armhf build times + d-i + britney, but if I miss the daily, I'll just spin another.
<cjwatson> Yep
<jdstrand> is the publisher off or something wrong? I did two uploads but don't see them mentioned here or in https://launchpad.net/ubuntu/utopic/+queue?queue_state=1&queue_text=
<jdstrand> ah, ok, there we go
<stgraber> just filed a FFe for the latest LXC milestone, would be nice if a release team member could look at bug 1376437
<ubot2> bug 1376437 in lxc (Ubuntu) "[FFe] LXC 1.1~alpha2" [Undecided,New] https://launchpad.net/bugs/1376437
<stgraber> I know it's kinda late for this, but it took us a long time to get the init scripts/systemd mess in a reasonable shape before we could tag that milestone...
<stgraber> if we don't get the FFe (which I'd understand), then I'd like to know ASAP because I'd then have to cherry-pick about 10-20 commits from alpha2 into our already patched alpha1 so that LXC works at least reasonably in utopic
<ScottK> stgraber: what fraction of the update are those 10 - 20 commits?
<infinity> stgraber: Is the end goal to ship 1.1final in utopic, or will things not align for that?
<stgraber> infinity: not, alpha2 would be what we release utopic with
<infinity> Shame.
<infinity> stgraber: So, I guess you're going to commit to support alpha2 for 9mo so the security team doesn't hate you? :)
<infinity>  - lxc-start now defaults to backgrounded mode (I will revert that change prior to upload to avoid potential last minute breakages)
<stgraber> ScottK: we need at least the few changes to unbreak things on the current kernel, I'd still push for the openvswitch changes to unbreak nova-compute-flex, we need the apparmor bits and the initscript/systemd bits to unbreak LXC on systemd.
<infinity> ^-- You mean you *will* revert it, period, or you intend to revert it if we argue?
<stgraber> ScottK: there are a bunch more that'd be worth taking if only as nice to have but those bits are the ones I've been nagged about the most
<stgraber> infinity: yeah, I'll deal with any security issue that may show up during the support period.
<stgraber> infinity: I'll revert it in the initial alpha2 upload to the archive because I don't want to break ubuntu touch (which is the main case I can think of). I'll un-revert it in utopic+1 though.
<apw> stgraber, i think the question there is if the bits you need are 10-20 commits, how many are in ~alpha2
<stgraber> and then just fix lxc-android-config to pass -F instead of assuming lxc-start keeps the container attached to the foreground
<infinity> stgraber: The lxc-start thing is interesting to me.  I'm all for not breaking things, but also would find it confusing if my 1.1~alpha on utopic and my 1.1final on v-series behaved differently, despite being "the same version".
<stgraber> apw: I tagged alpha2 about an hour ago, so all the bits we need are in there (nothing's been committed upstream since).
 * ScottK tosses http://www.bartleby.com/100/420.47.html at infinity.
<infinity> stgraber: He (and Scott) were asking for ratios.
<infinity> stgraber: You need 20 commits, but how may commits are there between alpha1 and alpha2
<apw> stgraber, assumed that, it that 1000 commits or 25 commits more than we have
<infinity> stgraber: Is that 20/30 or 20/100 or...
<stgraber> infinity: 143
<infinity> ScottK: I'm not sure if I should laugh or be insulted. :)
<ScottK> I was going for laugh.
<infinity> stgraber: And the followup question, how likely is a backport of those 20 "necessary" commits to be broken?
<infinity> stgraber: As in, will you have to iterate a few times (realistically here, not pie-in-the-sky hope) before you make sure you isolate all the right bits?
<stgraber> infinity: doing some stats now
<infinity> stgraber: This decision would be easier if you told me this was a final release, with some upstream stability statements attached to that.
<infinity> Cause I'm allergic to shipping alphas.
<infinity> But alpha2 is probably better than alpha1. :P
<ScottK> Version number is higher.  Has to be better.
<doko> please accept the gcc-4.9 in -proposed. it has the gccgo fixes for arm64 to make relocations work for cgo, and again a bunch of powerpc updates/fixes
<infinity> ScottK: In the case of an upstream alpha/beta versus a final release, I'm okay with backing that statement (well, depending on the upstream).
<stgraber> infinity: so basically alpha1 was aligned with 1.0.5 bugfix wise, 1.0.6 is now in trusty so if we don't want to regress we should get all those fixes into our alpha1. That's 85 commits according to git. On top of those (which should be mostly straight cherry-picks), openvswitch is 3 commits and systemd is one giant commit which will blow up in my face (that thing would fail to rebase pretty much daily while I was working on it...).
<ScottK> Yeah.  Depending.
<infinity> stgraber: Right, I'm leaning to a "yes" right now, for both the bugfix parity with trusty and the needed features to not suck in utopic.
<stgraber> infinity: I also agree it'd have be nice to get 1.1 in utopic and indeed that was my plan at the beginning of the cycle, then I ran into internal politics and we had fun with that thing called systemd so the whole thing got delayed a bit...
<infinity> stgraber: Right.  So, no 1.1 final (unless we argue to SRU it later), but that does leave the open question of behavioural differences between 1.1alpha and 1.1final, which is vaguely unintuitive.
<infinity> stgraber: What in the distro will break with that lxc-start change?  Just touch container setup?
<stgraber> alpha2 (really a bad name but I didn't feel like calling it an rc yet) is basically feature complete for 1.1 because what we wanted for 1.1 was checkpoint/restart, now the only missing bits are some template tricks to make systemd based distros suck less (and that doesn't apply to Ubuntu yet).
<stgraber> infinity: last archive grep I did, it's just touch, everyone else passes -d because they don't like LXC messing up with their terminal
<infinity> stgraber: Okay, so can we either upload an RTM-specific build for them, or just fix the bit that would break?
<stgraber> I'm happy to upload lxc-android-config adding the one char fix and bumping the versioned depend on LXC
<infinity> stgraber: I think that would actually be better than the safe-but-confusing revert.
<stgraber> I'm fine with that
<infinity> stgraber: Since docs will likely say "if you use 1.0, do X, if you use 1.1, do Y", but no one will think to mention "hey, if you're on Ubuntu utopic, which is a unique snowflake with 1.1alpha2, pretend it's 1.0, except when not".
<stgraber> I really hope docs instruct you to either do -d or -F and reserve the default behavior for a regular user who's not trying to script his way around lxc-start, but yeah, I get your point :)
<infinity> stgraber: So, yeah, copy and paste to bugs as necessary, but this is me saying if you can fix things that depend on the old lxc-start behaviour, please don't revert it, and you're okay for the alpha2 upload.
<stgraber> infinity: thanks
<infinity> stgraber: And if we find you were wrong, you can follow up with an upload that reverts the behaviour, making my inner pedant a bit sad. ;)
 * ScottK thought it was your inner hobgoblin
<darkxst> anyone able to take a quick look at bug 1376184, I'm about to do a gnome-shell upload to fix things with g-s-d 3.12 and would be good to include that
<ubot2> bug 1376184 in gnome-shell (Ubuntu) "[UIFe] Re-enable brightness widget" [Undecided,New] https://launchpad.net/bugs/1376184
<bdmurray> arges: if you are still about could you have a look at apport in the trusty SRU queue?
<arges> bdmurray: i can, can you reject kexec-tools in the utopic queue for me? I may need to add additional patches
<arges> bdmurray: ok done
<bdmurray> arges: I'm not an AA so can't help with that.
<arges> infinity: ^^ can you reject kexec-tools in the utopic unapproved queue. I'll be updating that tomorrow with additional patches. Thanks
<arges> bdmurray: ah sorry: ) thanks anyway
<infinity> arges: Done.
<arges> thanks
<bdmurray> infinity: sru-report is failing to run - https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/fix-401-traceback/+merge/236794 fixes that
<infinity> bdmurray: Erm, wat?
<infinity> bdmurray: How do we have things in proposed where the build records aren't public?
<infinity> I assume this was linux-keystone.
<bdmurray> Copied from ubuntu trusty in Private PPA for Canonical ARM Developers by Chris J Arges
<bdmurray> right
<infinity> bdmurray: I submit that the code is doing something wrong here.
<infinity> bdmurray: And skipping the 401 isn't the right answer.
<arges> infinity: what did i screw up?
<infinity> bdmurray: Cause the archive copy of that is clearly public: https://launchpad.net/ubuntu/+source/linux-keystone/3.13.0-14.24
<infinity> arges: Nothing. :)
<infinity> wgrant: Is this an lpapi bug?
<infinity> wgrant: It seems that when bdmurray is asking for getBuilds() on a package that was copied from a private PPA, it's going back to the PPA to get that info, which it then can't.  Despite the info being entirely public, if you look it up via the distro (say, in the web UI).
<wgrant> infinity: It's not an LP API bug so much as a moronic model which I haven't fixed yet.
<wgrant> It's trying to generate a link to the build, which crashes because it's in a private PPA that bdmurray can't see.
<infinity> wgrant: A data model bug, kay.
<wgrant> Yes.
<wgrant> Fix is partially done.
<infinity> wgrant: So the "correct" solution for now is, indeed, to just trap and skip the 401? :/
<apw> bjf, ^^ i think this discussion is the same issue shanky was having with the linux-keystone copy
<wgrant> infinity: I think so. The current model is broken in a way that can't easily be worked around.
<infinity> wgrant: Fun.  Kay.  Merged Brian's fix, then.
<infinity> apw: If shanky was vomiting on trying to determine if builds were complete, then yes.
<infinity> apw: I hadn't been expecting Ike to build in a private PPA and copy it to yours. :/
<infinity> But oh well.
<infinity> That also shouldn't break as amazingly as it does.
<wgrant> (the solution that I need to finish off is to partially copy builds when their binaries are copied, so the references are always intra-archive, preventing crossing of privacy domains)
<infinity> stgraber: Ooo, more apparmor changes AGAIN too.  Right after jdstrand uploaded a bunch of things with apparmor changes that said "match lxc apparmor" ;
<infinity> stgraber: Can you check and see if, for instance, the latest docker.io upload matches lxc alpha1 or alpha2, and if it needs changing again? :)
<doko> rejecting the binutils, gdb and gcc-4.9 uploads. building these in a ppa, and then copying the binaries, so that test results are available
<infinity> doko: "So that test results are available"?
<infinity> doko: Or do you mean so you can test before you're satisfied with copying?
<infinity> (Which makes sense)
<stgraber> infinity: I think it's all fine. We had a chat with jdstrand a few days back, as a result of that he uploaded some profile changes to LXC which I then pushed upstream, so what's upstream in alpha-2 matches what he pushed as patches a few days earlier to the archive.
<infinity> stgraber: That's not what the diff in the queue says.
<stgraber> infinity: and he re-used those same patches for docker.io now, so I believe we've got the same thing everywhere (the same also applied to libvirt).
<stgraber> infinity: ah?
<infinity> stgraber: I don't speak fluent apparmor, so maybe it's functionally the same, but it's definitely not identical.
<infinity> The signal and ptrace stuff changed a bit, and you deny an extra mount option.
<infinity> stgraber: First three files in http://launchpadlibrarian.net/186338094/lxc_1.1.0~alpha1-0ubuntu5_1.1.0~alpha2-0ubuntu1.diff.gz
<doko> infinity, well, I tested locally, but having the test results available without regressions is the testing I need for all archs
<doko> fuck
<infinity> doko: Sure, I just was curious what you meant by "available", since an archive or PPA build is identical in its ability to produce test results.
<doko> sorry, I accepted :-/
<infinity> doko: If you meant you want test results before you copy to the archive, so you can opt not to, that's entirely sane.
<infinity> Of course, you'd have to be able to actually use the queue correctly. :P
<stgraber> infinity: indeed, what he pushed for docker.io looks like the kind of profile LXC had a while back. I have however no idea exactly what docker does nowadays so it may very well be right.
<doko> pff, shouldn't accept something with a non-empty reject field
 * infinity cancels the powerpc build before it kills the VM.
<infinity> stgraber: Perhaps you and he should sync on that to be sure. :)
<stgraber> infinity: the docker.io profile isn't wrong though and should be safe too, what jdstrand pushed to LXC those past few days are extra restrictions that are there for the unlikely case where the kernel doesn't do its job.
<stgraber> jdstrand: here is one more ping for you :)
<infinity> stgraber: Right, what I was driving at was that your lxc upload wasn't identical to his.
<stgraber> infinity: so I'm pretty sure LXC's version of those profiles is right since we talked about them at length with jdstrand and I included them as-is, it could be that docker.io and libvirt-bin should also be using that new version, or not, I don't know.
<infinity> stgraber: So, wondering if things got weirdly out of sync again, or if yours is more correct, or if they're functionally the same despite being syntactically different.
<infinity> stgraber: Discounting docker and libvirt entirely here, just the lxc bits are different.
<doko> cancelled the other gcc-4.9 builds for now
<infinity> stgraber: Oh.
<infinity> stgraber: Derp, I'm missing that in the previous uploads those were patched in debian/patches.
<stgraber> infinity: right, was about to point that out :)
<stgraber> infinity: old LXC + debian/patches == new LXC
<stgraber> if not, then cp is broken and decided to corrupt the profile in a valid way when I copied them upstream two days ago :)
<stgraber> so sounds like we all agree then. Got to run, have a good evening!
<infinity> stgraber: In that case, only the "+  mount options=(rw, slave) -> /," addition to start-container looks new.
<infinity> stgraber: Unless that's from a previous patchset. :P
#ubuntu-release 2014-10-02
<robru> stgraber: what's going on with queuebot?
<stgraber> robru: my server appears to be kernel panicing every 10 minutes, not sure why
<robru> stgraber: oh good
<robru> good luck
<stgraber> trying to restart just the bare minimum for now, hoping things will stay stable enough for me to investigate tomorrow
<stgraber> in any case, it should make for an interesting bug report as the only things running on that box are unprivileged containers, so if it's one of those causing the panic, then it's a regular user causing a kernel panic...
<infinity> pfsmorigo: Looks like the migration of the kernel and d-i was pretty much perfectly timed for the daily that's going to happen automatically in about an hour.  So, in 1.5h or so, you should have a ppc64el daily that boots again.
<jamespage> cjwatson, any reason why this upload disappeared between proposed and release pockets:
<jamespage> https://launchpad.net/ubuntu/utopic/+source/python-oslo.vmware/0.6.0-1ubuntu2
<jamespage> ?
<jdstrand> infinity: apparmor can't be identical between docker, lxc and libvirt-lxc. also, libvirt-lxc uses individual profiles instead of the sam eprofile for all, lxc confines lxc start, libvirt-lxc runs libvirtd and a profile and docker.io is unconfined
<jdstrand> infinity: but by far most of the profiles can be the same, so I reorganized them all so they are easier to compare
<jdstrand> (well, I didn't reorganize lxc, I reorganized libvirt-lxc and docker)
<jdstrand> I can verify the changes in the new uploads
<pfsmorigo> infinity: tks man. I'm testing daily right now. let's see
<pfsmorigo> infinity: what timezone are you?
<pfsmorigo> infinity: it worked. daily image installed fine here. tks
<pfsmorigo> apw: ^
<apw> pfsmorigo, he is of indeterminate timezone at best :), glad that fixed it, thanks for letting us know
<pfsmorigo> apw: hehe
<apw> jamespage, i think you just caught it in the copy phase from one pocket to the other, as the removal happens immediatly and the arrival happens when the next publisher completes (approximatly)
<apw> jamespage, no ignore me, i read the numbers wrong
<jamespage> apw, yeah - I had to double take - I've not seen that before
<jamespage> maybe infinity or wgrant might have an idea as to where https://launchpad.net/ubuntu/utopic/+source/python-oslo.vmware/0.6.0-1ubuntu2 went ?
<wgrant> jamespage: The copy was probably eaten by one of the swift outages this morning. An archive admin should be able to revive it for you.
<jamespage> ah-ha!
<jamespage> any archive admins around who can sort out my oslo.vmware upload that's got lost?
<jamespage> stgraber, pitti? ^^
<stgraber> jamespage: hmm, that's interesting
<jamespage> stgraber, indeed
<stgraber> ok, doing the usual copy on top of itself, hopefully that'll do the trick
<stgraber> jamespage: ok, in theory I just copied it on top of itself, so in a publisher cycle it should show up in -proposed again, then britney should be able to get it to migrate
<jamespage> stgraber, awesome thanks
<bdmurray> any SRU team member I'd like to have a 2nd opinion on releasing the fix for bug 1354571 early.
<ubot2> bug 1354571 in apport (Ubuntu Trusty) "apport-retrace ignores warnings from gdb" [Medium,Fix committed] https://launchpad.net/bugs/1354571
<infinity> bdmurray: Perfectly reasonable.  My only question is if that's missing a powerpc64le-linux-gnu target, or if that gets covered by powerpc64.
<infinity> Or, rather ppc64/ppc64le
<infinity> Which looks wrong anyway, as that's not the GNU triplet. :P
<bdmurray> infinity: hmm?
<infinity> bdmurray: Looking at the diff, it enables "ppc64-linux-gnu", but the GNU triplet for ppc64 is powerpc64-linux-gnu (and the triplet for ppc64el is powerpc64le-linux-gnu).  But this could be a gdb weirdness, not a packaging bug.
<bdmurray> infinity: are we talking about apport and bug 1354571?
<ubot2> bug 1354571 in apport (Ubuntu Trusty) "apport-retrace ignores warnings from gdb" [Medium,Fix committed] https://launchpad.net/bugs/1354571
<infinity> bdmurray: I'm talking about switching gdb back from "all" to a static target list.
<infinity> bdmurray: The thing you asked about 20 minutes ago. :P
<infinity> Unfortunately, neither "ppc64-linux-gnu" or "powerpc64-linux-gnu" show up anywhere in the source except for debian/rules, so this is a bit hard to hunt.
<infinity> bdmurray: Do we use binutils-multiarch for ppc64el retracing yet?  Would we notice if it was broken?
<bdmurray> infinity: I'm really lost re what you are referring to. I'd didn't ask about gdb recently.
<infinity> bdmurray: Err, you're right.  I saw "gdb" in the bug title, and then went looking at the GDB source package.  I need to wake up.
<infinity> And, indeed, the GDB upload has a note that it regresses arm64 and ppc64el.
<infinity> bdmurray: Looking at apport instead. :P
<bdmurray> infinity: Okay. Yes, the gdb in trusty-proposed does need a reupload and that's in bug 1233185. The retracers are using 7.7.1-0ubuntu4 so I haven't been too concerned about that SRU.
<ubot2> bug 1233185 in gdb (Ubuntu Trusty) "gdb-multiarch cannot read ARM cores: "wrong size gregset struct in core file"" [High,Triaged] https://launchpad.net/bugs/1233185
<infinity> bdmurray: apport looks fine.
<bdmurray> infinity: thanks
<barry> any ~ubuntu-release have a few moments to review LP: #1376736?
<ubot2> Launchpad bug 1376736 in pycurl (Ubuntu) "[FFe] update to pycurl 7.19.5" [High,New] https://launchpad.net/bugs/1376736
<wxl> i have a query on behalf of our wiki team. is lubuntu responsible for  https://wiki.ubuntu.com/Lubuntu/Announcement/XX.YY or is that something the general release team takes care of?
<knome> wxl, you're responsible for your own announcements yourself, the release team only does the general ones
<wxl> cool thanks knome
<knome> np
<jamespage> stgraber, hmm - oslo.vmware -1ubuntu2 does not appear to have re-appeared in proposed - is it easier for me to just upload a 1uubntu3 with the same content?
<infinity> jamespage: Reappear?
<jamespage> infinity, 1ubuntu2 disappeared between building in proposed and migrating to release pockts
<infinity> jamespage: What source package is this?
<jamespage> infinity, python-oslo.vmware
<jamespage> infinity, https://launchpad.net/ubuntu/+source/python-oslo.vmware/0.6.0-1ubuntu2
<infinity> Looks like the copy fell to the librarian outage.  I'll just recopy it.  Sec.
<infinity> jamespage: https://launchpad.net/ubuntu/+source/python-oslo.vmware/0.6.0-1ubuntu2/+publishinghistory
<infinity> jamespage: There, it has a pending publishing record now.
<infinity> jamespage: Will fix itself shortly.
<jamespage> infinity, thankyou - wgrant indicated it was probably due to that outage
<jdstrand> infinity: fyi, there is one mount rule added to lxc alpha2 over what I uploaded
<jdstrand> so, the libvirt-lxc and docker.io profiles could get that I suppose
<jdstrand> I'll follow up with hallyn and stgraber tomorrow and see why it was added
<hallyn> which rule is that i wonder
#ubuntu-release 2014-10-03
<cjwatson> stgraber,jamespage,infinity: the reason stgraber's copy of python-oslo.vmware wasn't effective was that it was stuck in unapproved :)  rejecting the dup now
<cjwatson> curious that queuebot didn't notice though
<Laney> People are getting confused because there's no mail for copies
<cjwatson> is that related to my comment?
<Laney> Sounds like it, but I didn't read the context
<cjwatson> no I think this was quite different
<cjwatson> a copy got eaten by librarian swift outage and then there was some confusion yesterday attempting to resurrect it
<Laney> As in stgraber would have known to accept it if he had a Waiting for Approval email
<cjwatson> ah perhaps
<Laney> Would someone promote liblcms2-utils please?
<Laney> foo2zjs is depwait
<cjwatson> Laney: done
<Laney> ta
<Laney> rsalveti: are these pa patches forwarded?
<infinity> cjwatson: Oh, derp, didn't even think to check, my copy used --auto-approve, of course.
<cjwatson> ah yes
 * infinity sees that his meta changes last night made libreoffice-presentation-minimizer go green and removes it.
<infinity> And NBS back down to 0 for now.
 * cjwatson zaps nbs-rtm too
<rsalveti> Laney: yes
<Laney> ta
<rsalveti> Laney: just 2 minor bug fixes
<Laney> Would prefer a link if you could in future
<Laney> accepting
<barry> hello release team!  could i get some love for LP: #1376736 ?
<ubot2> Launchpad bug 1376736 in pycurl (Ubuntu) "[FFe] update to pycurl 7.19.5" [High,New] https://launchpad.net/bugs/1376736
<rsalveti> Laney: yeah, decided to push first and then spend time testing and upstreaming, but will add a note for that next time
<rsalveti> testing because upstream is way ahead
<barry> Laney: do you have a moment to look at LP: #1376736 ?
<ubot2> Launchpad bug 1376736 in pycurl (Ubuntu) "[FFe] update to pycurl 7.19.5" [High,New] https://launchpad.net/bugs/1376736
#ubuntu-release 2015-09-28
<jamespage> lots of openstack clients and oslo libraries being synced from experimental today - re-alignment for rc1
<jamespage> ^^ that last sync is needed for barbican, which is its only reverse depends in the ubuntu archive
<Riddell> someone accepting things in double quick time or no packagset packages don't get blocked?
<Laney> second one
<ogra_> Riddell, there is a bot
<ogra_> iirc
<ogra_> for the non-packageset ones
<coreycb> bdmurray, can you promote software-properties to trusty-updates?  for bug 1472586
<ubot93> bug 1472586 in software-properties (Ubuntu Trusty) "[SRU] Add support for liberty cloud-archive" [Undecided,Fix committed] https://launchpad.net/bugs/1472586
<bdmurray> coreycb: I'll have a look this morning
<coreycb> bdmurray, thanks
<wxl> could we turn the daily images cronjobs back on? pretty please?
<infinity> wxl: I did so a day or two ago....
<wxl> oh yeah i guess i was a little early today, but for the past couple days, nope
<wxl> oh well, i'll assume all is well
<Laney> That ubuntu-docs reminded me to run the old UDD query I had hanging around
<Laney> https://udd.debian.org/~laney/less.txt
<Laney> There's a few other packages where vivid{,-updates,-proposed} < wily{,-proposed}
<Laney> just mentioning in case someone is more aroudn than I am and wants to look at it
<Laney> Otherwise I can maybe look tomorrow
 * Laney fades away
<Ukikie> Seen ca-certificates get in there too.
<robru> stgraber: https://code.launchpad.net/~robru/queuebot/ping-everybody can you merge this please?
<infinity> cyphermox: Yo.
<infinity> cyphermox: modemmanager.  Isn't that something the phone uses?
<cyphermox> no
<cyphermox> it's desktop
<infinity> cyphermox: The phone is, AFAIK, still upstart, at least until they converge with snappy.
<infinity> cyphermox: Oh.  No phone interest at all?
<cyphermox> yes
<cyphermox> no, no ubuntu phone interest at all, they use ofono instead
<ogra_> infinity, ofono doesnt really like fighting with modemmanager over devices ;)
<infinity> cyphermox: Kay.
<infinity> cyphermox: The other bit I'm confused by is removal of the service link.  Do the sysv and systemd jobs still have matching names after that change?
<infinity> (And does that mean they didn't before?)
<cyphermox> the right name for ModemManager is ModemManager, the systemd service should be fine
<infinity> cyphermox: But the systemd service must match the init script.
<infinity> cyphermox: Or life goes topsy-turvy.
<cyphermox> infinity: I'm just removing special-casing we had just for us, the package as it is in Debian should work 100%
<cyphermox> (just for us -- just for upstart)
<ogra_> well, it goes interesting at lleast, since the sysvinit generator of systemd would start generating another unit from the sysv script
<infinity> ogra_: Right.
<ogra_> are actually both installed in the binary ?
<cyphermox> lemme get back some state about it, it's been on my hd for a little bit now
<infinity> Erm, that's not actually a delta at all, that's in the Debian source.
<cyphermox> right, so the service name needs to match, but we don't ship a sysv init script
<stgraber> robru: done
<robru> stgraber: thanks
<cyphermox> infinity: I know, I had convinced mbiebl to keep things in debian source.
<infinity> So the Debian package is buggy and doesn't ship a sysv init script? :P
<cyphermox> it ships systemd magic only
<cyphermox> the sysv script may well have been dropped, MM is typically dbus-activated by NM when needed, not just started
<infinity> Anyhow.  Fair enough.  Please jam this in Debian too, it's rather odd to have an Ubuntu delta to remove an Ubuntu delta. ;)
<ogra_> inception !
<cyphermox> infinity: yep :)
 * ogra_ doesnt like where that might go ... in the end it removes Ubuntu altogether 
<infinity> ogra_: I think it would be lovely if all Ubuntu deltas were in Debian, and all it took was changing base-files and dpkg/vendor and rebuilding Debian to get Ubuntu out of the other end.
<infinity> ogra_: I'm pretty sure some Canonical management would disagree with me. :P
<ogra_> hah
<flexiondotorg> My Pebble Time has just altered me that I need to say a quick thankyou to cyphermox :-)
<cyphermox> your pebble time alters you?
<cyphermox> ;)
<flexiondotorg> Well, that was a typo. But I suppose it does in a way ;-)
<flexiondotorg> cyphermox, Can you take a peek at this merge proposal please? https://code.launchpad.net/~ubuntu-mate-dev/debian-cd/ubuntu-mate-logo/+merge/272432
#ubuntu-release 2015-09-29
 * infinity raises an eyebrow at ubuntu-mate-welcome-repository-installer.
<infinity> flexiondotorg: Tell me that PPA-adding business only happens at user request, and with hearty warnings?
<infinity> flexiondotorg: Cause we're pretty firm about flavours not installing/shipping stuff from outside the archive without user intervention.
<infinity> flexiondotorg: Also, stuff like this is completely and utterly insecure:
<infinity> add_apt_key_from_url('http://repo.steampowered.com/steam/signature.gpg')
<infinity> flexiondotorg: If there's no secure trusty path to that key, the only vaguely sane way to do that is to ship the key in the package in /usr/share/<package>/apt-keys and add it on demand from the local filesystem, so the trust path is our archive.
<infinity> s/trusty/trust/ ... I'll never be able to type that word again.  Thanks Mark.
<Ukikie> (Also confuses some people when you use the word 'precise' or 'precisely' >_> )
<mterry> Is there a freeze on besides feature freeze?
<Laney> Uploads are going to the unapproved queue
<Laney> Unseeded stuff is accepted automatically
<Laney> See ubuntu-devel-announce
* Laney changed the topic of #ubuntu-release to: Released: Trusty 14.04.3, Vivid 15.04, Wily Beta 2 | Archive: feature freeze, user interface freeze, final beta freeze | Wily 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
<mterry> Laney, ah makes sense.  Didn't grok that part of the freeze email
<mterry> thanks!
<flocculant> infinity: re flavours stopping and starting their build. Is this likely to actually happen? I know you said it was a TODO, seems like rather a sensible place to try and end up. Though I'd guess it was tied to something sensible like a flavour release team.
<flocculant> There's certainly been times when I or bluesabre would have liked to have done so easily :)
<flocculant> Laney: is -desktop the best place to talk about this bug that's turned up (see it for Xubuntu and at least Ubuntu) bug 1497170
<ubot93> bug 1497170 in xdg-utils (Ubuntu) "New file creation - not opening with file editor" [High,Confirmed] https://launchpad.net/bugs/1497170
<Laney> Sure, if you like
<flocculant> Laney: heh - was more a question if that was the best place :)
<Laney> go for it
<flocculant> not sure that's something that anyone would want wily to release with - small but a pita :)
<flexiondotorg> infinity, cyphermox Can I kindly request that someone merge this code please?
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1499078
<ubot93> Launchpad bug 1499078 in ubuntu-release-upgrader (Ubuntu Wily) "ubuntu-release-upgrader has no support for Ubuntu MATE" [High,Triaged]
<cyphermox> flexiondotorg, I will review it in a bit
<smoser> hi. can i get someone to take a look at my openhpi upload ?
<flexiondotorg> cyphermox, Thank you! I'd like to test it before RC :-)
<cyphermox> yep
<cyphermox> flexiondotorg: reviewed, I merged your changes in ubuntu-release-upgrader, and I'm waiting after bzr bd -S
<cyphermox> (tests)
<flexiondotorg> cyphermox, Thanks. I test it tomorrow :-)
<cyphermox> oops, there are failures
<cyphermox> but no worries, I'll fix things to make it work
<flexiondotorg> cyphermox, Failures?
<cyphermox> yeah
<flexiondotorg> My fault?
<cyphermox> I see, it's because French.
 * cyphermox twiddles bits
<ogra_> just remove the french ... rm -fr
<cyphermox> I wish I could, but the Klingon translations aren't good enough yet for an alternative.
<ogra_> ask pitti ;)
<flexiondotorg> Mon dour
<ogra_> he is fluid in klingon
<cyphermox> is he?
<ogra_> yeah
<cyphermox> :)
<flexiondotorg> Has to dash....
<bdmurray> cyphermox: thanks for looking at that
<cyphermox> np
<bdmurray> infinity, slangasek: I'd like to release the fix for bug 1148116 early as it causes the Error Tracker to ask for core files and try to retrace things that end up just failing.
<ubot93> bug 1148116 in apport (Ubuntu Precise) "not all packages from PPAs have '[origin: ' in Package section" [High,Fix committed] https://launchpad.net/bugs/1148116
<cyphermox> brb
<slangasek> bdmurray: +1 on early release for 1148116
<bdmurray> slangasek: okay, thanks
<infinity> flocculant: It's not on any immediate roadmap, per se, but it falls out easily from other changes we want to make that would remove the static crontab entries in favour of one big "build it all" job, where "all" could then be defined by an external trigger DB like the ISO tracker.
<infinity> Please no one touch the linux* packages in the queue, I'm not accepting them until after the current one migrates to release.
<doko> infinity, nodejs ping
<infinity> doko: Oh, right.  I need to hunt down that one arm64 FTBFS I noticed and check in a PPA that it didn't regress all arches.  Lemme find that now.
<infinity> Hrm, in fact, there were a lot of them.  I hope that's just the arm64 port sucking, and not 4.0.0 requiring the world to be ported.
 * infinity picks a handfull and copies them into a PPA.
<doko> infinity, SRU issues: python3-defaults should be ok for trusty from my point of view. gccgo-4.9 too (asked slangasek for that too)
<infinity> doko: Alright, a mess of node-* building in ppa:adconrad/ppa, we'll see how that looks.
<doko> ta
<superm1> hey all, I was really hoping to see fwupd land in 15.10's archive.  it's been sitting in Debian's NEW queue for the past 2 weeks though with no activity, so I don't think it will likely sync in time.  is it too late to upload to ubuntu with a -0ubuntu1 package and process through NEW to make into 15.10?
<superm1> (https://ftp-master.debian.org/new/fwupd_0.1.5-1.html)
<ogra_> cyphermox, ^^^
<ogra_> superm1, no worries, it is planned to land
<superm1> okay, thanks.  if there is anything else I can do related to helping it along, shout
<ogra_> superm1, well, i think cyphermox is working on it
<cyphermox> superm1: yes, I am going to upload it tonight
#ubuntu-release 2015-09-30
<superm1> cyphermox: okay cool
<superm1> cyphermox: if you want to push what you end up uploading to github, i can pull it into an 'ubuntu' branch to track at the debian packaging branch just so we have it in VCS until they can converge again after a debian FTP master lets it in to debian
<RAOF> That is the most awesome bug âgrub can't be installed on systems with more than 26 discsâ :)
<cyphermox> superm1: all I did was add an entry on top of your current git for "upload to wily". I'd really rather we have no delta at all, and I think there is no reason to have any
<cyphermox> I made sure we'd still be at a lower version than what will land when it's through new.
<cyphermox> i think I still had trouble building the packages because of the state of patches, maybe
<cyphermox> superm1: have you tried starting from a clean tree and trying the rebuild the package?
<ogra_> uhm, what ?
<ogra_> why was ubuntu-core-config rejected ?
<Laney> check your mail?
<ogra_> didnt get one yet, but now snappy will be broken, half of the changeset was in livecd-rootfs
<apw> ogra_, should those two not dep on each other in some way to prevent them migrating separatly if that is the case ?
<ogra_> well, i wouldnt like to make livecd-rootfs depend on anything not used for building
<apw> ogra_, no more thinking some kind of breaks or something
<ogra_> ubuntu-core-config defines what paths on the resulting image are writable ...
<ogra_> livecd-rootfs only manageds to build the image, but bits on it wont work now until u-c-c lands
<ogra_> -d
<apw> yep, i was hoping there was some way to represent this to prevent you getting broken in the future -- does not solve your current situation
<ogra_> well, there are also seed changes involved ... its a triple place change :)
<ogra_> not so easy to reflect that in packaging
<ogra_> i just have to get u-c-c in before the next auto-build ...
<ogra_> now if my mail server wouldnt be so broken i could see why it was rejected :P
<infinity> ogra_: If you never got your mail, it was rejected for the bogus version number.
<ogra_> nipickars !
<ogra_> :P
<ogra_> and no, i'm still waiting for my IMAP server to drop the load under 25 :P
<ogra_> somehow that 200MHz/128MB/4200rpm PATA system starts showing its age
<ogra_> :)
 * ogra_ has a snappy replacement in the works, but not ready yet
<ogra_> there you go :)
<ogra_> (and now the mail got through as well)
<apw> could someone reject linux-signed for me, i messed up the -v
<infinity> apw: Er, no.
<infinity> apw: Cause I accepted before you asked.
<apw> infinity, never mind, i'll close the bug by hand ... no biggie
<infinity> apw: Oh, just for the closure?  Yeah, no big deal.
<Laney> that was a quick valgrind review
<cyphermox> has anyone heard of a werewolf image yet for the slideshow? it would be nice to get that before the last few days before release :)
<doko> chrisccoulson, are the aarch64 changes upstream for thunderbird?
<doko> these seem to get dropped in the pending upload
<cyphermox> davmor2: would you happen to have time to run your install again on your XPS13 so I know for sure that bcmwl is good now?
<davmor2> cyphermox: sure is it in the latest daily or do I need to install something?
<cyphermox> daily should be fine, let me check
<cyphermox> yup
<Laney> cyphermox: for a werewolf I guess you want design (and willcooke might be able to help you find someone)
<cyphermox> Laney: ah?
<Laney> mostly guessing - i've not been involved in this in the past (IIRC)
<cyphermox> Laney: I just know we always tend to do this wayy late in the release ;)
 * willcooke speaks to design
<Laney> cyphermox: quick, put it on your calendar for 5 months from now
<Laney> I almost said "put it on the beta checklist" :)
<cyphermox> no, we need that earlier. perhaps there is already something somewhere too, I just have no idea and I figure it was better to point it out now than one week from release
<Laney> so put a reminder to yourself to get it sorted early next time?
<cyphermox> *earlier*
<cyphermox> last time was later than now ;)
<Laney> thanks willcooke ;-)
<Laney> could you maybe add it to that reminder of yours to get a refreshed slideshow too (at least the welcome page)?
<davmor2> cyphermox: step one passes it shows up in additional drivers in live cd, Now I'll reboot and run an install and ensure it is install automagically \o/
<cyphermox> davmor2: yay
<cyphermox> I did one more upgrade test earlier to make sure modemmanager was good, and it seems to be
<davmor2> cyphermox: pfff
<cyphermox> if you disagree by all means tell me I did the test wrong ;)
<davmor2> cyphermox: you did the test wrong ;) I'll give it go after and confirm for you :)
<cyphermox> ahha
<Laney> doko: â
<davmor2> cyphermox: I can haz wifi on the installed system \o/
<cyphermox> davmor2: great.
<davmor2> cyphermox: can you try something for me on a fresh wily, open firefox, close it, open libreoffice and close it, and then open the dash.  It should be FF on the right and then libreoffice right?   Now open nautilus and close that, it doesn't show up but now FF is on the left of LO right?
<cyphermox> ok, just a second
<cyphermox> what do you mean by fresh, does it need to be recently-installed?
<davmor2> cyphermox: it will likey happen regardless
<davmor2> cyphermox: mine was a fresh install so I always go by what I had done :)
<cyphermox> davmor2: I can confirm your assessment makes sense, it should be in reverse chronological order; when I do that I initially have just firefox, no libreoffice, and then when I open nautilus I get libreoffice listed in the dash, but not nautilus or firefox anymore
<cyphermox> ah, firefox is at the very end of the list behind "6 additional results"
<davmor2> cyphermox: weird thought right nautilus shouldn't move another apps position right?
<cyphermox> yeah, it should be in the dash, as the very first item
<cyphermox> (ie. the latest opened app
<cyphermox> I'm not sure where you get that this must be in reverse chronological order though, maybe it's not the case
<cyphermox> I don't know what order is would be otherwise though
<cyphermox> it certainly isn't alphabetical
<davmor2> cyphermox: no no, I opened FF first, so it showed in the dash, I then opened LO, that appeared to the left of FF.  This I expect.  I then opened nautilus, Nautilus didn't show up in the dash but FF was now to the left of the LO not the right as expected
<cyphermox> right
<cyphermox> well, I get a different order of things and nautilus never gets in the list
<cyphermox> but it doesn't make any more sense.
<davmor2> cyphermox: that's my point, if you open the dash look at the order, close the dash and open the dash the order doesn't change at least for me it doesn't, it's only after hitting nautilus that it changes
<davmor2> cyphermox: it's like opening nautilus randomises your app list
<willcooke> cyphermox, Laney - I have a werewolf for you
<cyphermox> yay
<willcooke> It's in a zip file, so email ok?
<cyphermox> of course.
<willcooke> cyphermox, on its way
<Laney> AWOOOOOOOOOOOOOOOOOOOO
<willcooke> :)
<Laney> that werewolf is scary
<davmor2> cyphermox, jibel: so that is good news, xps upgrade worked well not stalls for modemmanger \o/ and also no issues with wifi in the live system or the installed one \o/
<cyphermox> awesome
<cyphermox> now to keep fixing everything else ;)
 * davmor2 goes off to break some more stuff as cyphermox seems far to pleased with himself
<cyphermox> davmor2: did you ever run into that timezone crash?
<davmor2> cyphermox: nope but aren't most of the issue for that being reported from russia?
<cyphermox> not all
<davmor2> cyphermox: fix it!!! I still see the monkey in the help window should be a werewolf by now ;)
<cyphermox> heh
<cyphermox> zug zug!
<davmor2> cyphermox: do we have any ideas when the final artwork is landing I thought it had landed by now?
<cyphermox> I don't know
<davmor2> infinity, jibel: any ideas on the final artwork? ^
<cyphermox> is there an artwork freeze? :)
<ogra> just paint it over ...
<cyphermox> davmor2: as I understand, we already have the right wallpaper
<davmor2> cyphermox: indeed but if you open the help app, from the settings indicator it is the monkey not werewolf icon
<cyphermox> right, this will need to be changed, but one thing at a time
<cyphermox> also, wow, does that logo look menacing ;)
<jibel> davmor2, is it just to update the vervet to a werewolf?
<cyphermox> davmor2: so, what settings indicator so we can file a bug about it?
<jibel> davmor2, last time infinity used his gimp skills to do the update
<cyphermox> jibel: looks like we have a vectorized werewolf now
<cyphermox> jibel: want to review my changes?
<cyphermox> https://code.launchpad.net/~mathieu-tl/ubiquity-slideshow-ubuntu/werewolf/+merge/272961
<davmor2> jibel, cyphermox: yeah it's the yelp app I believe just the front page of ubuntu help from the system/settings/session indicator whatever it's called nowadays
<cyphermox> yelp?
<cyphermox> you mean "about this computer?
<cyphermox> nevermind
<cyphermox> the help, I see
<davmor2> cyphermox: no the one under that that says Ubuntu Help ;)
<cyphermox> yep, I see
<cyphermox> I have no idea what ships that :)
<davmor2> cyphermox: the app itself I believe is yelp
<cyphermox> yeah, it rings a bell
<davmor2> and it is as I start it from the terminal
<davmor2> cyphermox: no idea where it gets the artwork from though
 * cyphermox greps
<cyphermox> davmor2: the mouse-over image changes are scary
<jibel> cyphermox, this is beautiful ;)
<cyphermox> weee
<cyphermox> scary though :)
<cyphermox> we should move the release date a few days forward to hit halloween.
<davmor2> cyphermox: This must be lost in translation does Scary mean Awesome in Canada?  You know like bad is good?
<cyphermox> davmor2: so, looks like it's ubuntu-docs and already updated to have the right mascot
<cyphermox> davmor2: Yes?
<davmor2> cyphermox: hmmmm then why it is not displaying the right mascot I wonder
<cyphermox> not uploaded yet
<davmor2> cyphermox: ah okay
<cyphermox> it's unreleased, in the bzr branch
<davmor2> cyphermox: ah okay
<cyphermox> at least it's ready
<davmor2> as long as it isn't forgotten
<superm1> cyphermox: i didn't have any issues building in a clean tree back to back
<superm1> cyphermox: i agree it would be best to avoid no delta, but if it ends up being a necessary evil, just want to make sure it's tracked
<cyphermox> superm1: yep, no problem
<cyphermox> so far, no delta, but I'll keep you aware if we need any changes -- hopefully there won't be anything that wouldn't also apply to Debian
<superm1> Okay.  Yeah, presumably can just put whatever else is needed in the UNRELEASED entry for Debian for now to do on the next upload once it clears NEW
<coreycb> release team,1:5.0.0~rc1-0ubuntu2 re-introduces some binary packages ( ceilometer-agent-{central,compute,ipmi} ) that were dropped in 1:5.0.0~rc1-0ubuntu1
<dannf> ^ can someone reject that first libguestfs trusty upload? I forgot to update-maintainer :( 2nd upload fixes.
<doko> dannf, done
<dannf> doko: thx!
#ubuntu-release 2015-10-01
<jamespage> please could an archive-admin accept the NEW binaries for ceilometer; 0ubuntu1 dropped some that it should have not upon review (the NEW's are restoration of the dropped binaires with appropriate tweaks)
<jamespage> ignore me I just saw New: accepted ceilometer [amd64] (wily-proposed) [1:5.0.0~rc1-0ubuntu2]
<jamespage> doh
<jamespage> pls could neutron 2:7.0.0~rc1-0ubuntu2 be accepted - it resolves a problem on 32bit systems (which is causing issues with the auto-backport to 14.04)
<smoser> quick question ..
<smoser> if i fix https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1501834 for wily, will someone ask me to file a FFE ? and if so would that be granted ?
<ubot93> Launchpad bug 1501834 in initramfs-tools (Ubuntu) "add squashfs support by default" [Medium,Confirmed]
<rtg> smoser, that doesn't really seem like a feature, more of a bug fix (and a seemingly trivial one at that)
<stgraber> I granted that FFe
<cyphermox> smoser: it certainly makes sense to me as a bugfix.
<cyphermox> arges: re-uploaded ipmitool ^
<cyphermox> (so you'll want to take the last one only)
<smoser> thanks all. uploaded.
<arges> cyphermox: ok
<cyphermox> slangasek: could you review/approve tzsetup? ^ after that I still need to update ubiquity for the bug to be fixed.
<slangasek> cyphermox: looking
<cyphermox> thanks
<cyphermox> fwiw, also a reminder about fwupd :)
<hjd> Hi all. Could someone take a quick look at bug 1500112 and see whether this needs (and possibly qualifies for) an FFE, or whether it only needs a sync request? :)
<ubot93> bug 1500112 in haskell-stack (Ubuntu) "missing dependency on libyaml-0-2" [Medium,Confirmed] https://launchpad.net/bugs/1500112
<teward> cyphermox: hello!  Mind a PM briefly?
<slangasek> cyphermox: tzsetup accepted, but OOI why would there be a detected value of "None" that we need to special case, instead of the detected value just being empty (the already handled case)?
<cyphermox> slangasek: it seems like the "we found your IP in the database but no timezone to go with it" has always been <TimeZone>None</TimeZone>
<cyphermox> whereas the "we can't find your IP at all" leads to <TimeZone> not being present in the response, so detected=
<cyphermox> it was very much a case where I screwed up the merge while trying to reduce delta, and didn't catch that failure when testing because I always got my IP either detected or not in the database.
<cyphermox> I suppose we could fix whatever software runs behind geoip.ubuntu.com to not return "None" and instead use an empty string, but I have no idea what software that would be. do you?
<slangasek> cyphermox: lp:ubuntu-geonames; and the installer team owns it
<cyphermox> oh cool
<slangasek> I do think this is a bug on the server to return two different values for two different flavors of "not found"
<rsalveti> infinity: when you get some time, mind reviewing rtl8812au (new package)? my first dkms package, built and tested locally with 2 different devices (and seems a quite common chipset)
<rsalveti> ffe for it is already approved, so just normal package review/approval needed
<cyphermox> slangasek: not the same server, apparently.
<infinity> rsalveti: I dunno man, you abandoned me.
<infinity> rsalveti: Like, maaaaaybe I could review your package, or maaaaaybe I don't love you anymore!
<infinity> rsalveti: (reviewing in a bit :P)
<cyphermox> rsalveti: yeah, thanks for rtl8812au :)
 * rsalveti hugs infinity
<rsalveti> cyphermox: np, having a package is better than tons of instructions pointing out to many different github repos
<cyphermox> indeed.
<rsalveti> upstreaming for realtek seems to be a bit of a pita still
<cyphermox> teward: no, I don't mind a pm, why?
<cyphermox> rsalveti: on the bright side, the USB and many PCI 802.11ac chips will now work, so yay
<rsalveti> yeah
<cyphermox> rsalveti: did you add modaliases, in case?
<rsalveti> yup
<cyphermox> awesome :)
<slangasek> cyphermox: sorry, what do you mean not the same server?
<cyphermox> slangasek: I looked at the code, and it seems to be what responds on geoname-lookup.ubuntu.com, but not on geoip.ubuntu.com/lookup
<slangasek> wut
<slangasek> oh
<cyphermox> yeah :/
<cyphermox> so geoip is asked first to try to guess what timezone to default to
<slangasek> is the one I pointed you at lookups for location names?
<slangasek> sorry
<cyphermox> then you get in the timezone page and geoname-lookup gets you the timezone for a location
<cyphermox> yeah
<cyphermox> well, I didn't realize that's what happened until just now :)
<cyphermox> actually
<cyphermox> I think geonames probably is only on the desktop, as I haven't seen it be called at all in ubiquity
<cyphermox> nevermind
<cyphermox> that's exactly what happens
<slangasek> cyphermox: I wonder if these shouldn't be merged into a single service with two api endpoints so we don't have this confusion
<slangasek> but then we would need to figure out where geoip.ubuntu.com lives :P
<cyphermox> once that's done I'll consider it
<barry> release team, please don't approve python-apt 1.0.0ubuntu1.  juliank is going to upload 1.0.1 to unstable right now, and that will have the fix for the deprecation warnings and a couple of other minor bugs
<barry> when lp picks up python-apt 1.0.1 we can drop the ubuntu delta and do a straight up syncpackage
<barry> see LP: #1501805 for details
<ubot93> Launchpad bug 1501805 in python-apt (Ubuntu) "Sync python-apt 1.0.1 (main) from Debian unstable (main)" [High,In progress] https://launchpad.net/bugs/1501805
<barry> oh well
<infinity> ^-- Self-reviewing both of those, they're just kernel ABI bumps.
<doko> barry, sorry read that too late
<barry> doko: no worries.  i'll just syncpackage 1.0.1 as soon as lp picks it up
<barry> doko: and thanks!
<infinity> doko: You probably shouldn't be accepting things anyway. :P
<doko> infinity, I agree, but pestering you doesn't help ;-P
<infinity> doko: I'm not the only member of the release team doing reviews (though I've done the vast majority this week, I think).
<xnox> hehe
#ubuntu-release 2015-10-02
<flexiondotorg> infinity, cyphermox Any chance this merge proposal could be reviewed please?
<flexiondotorg> https://code.launchpad.net/~ubuntu-mate-dev/debian-cd/ubuntu-mate-logo/+merge/272432
<cyphermox> flexiondotorg: I'm happy to look but I can't merge it myself, lacking permissions
<flexiondotorg> cyphermox, Ah, OK.
<flexiondotorg> Thanks for offering to review.
<cyphermox> bzr: ERROR: There was an error parsing the changelog: Could not parse changelog: Invalid key-value pair after ';': UNRELEASED
<flexiondotorg> OK, I'll check bzr.
<cyphermox> maybe this is me
<flexiondotorg> cyphermox, Not my fault :-)
<flexiondotorg> No, not you.
<flexiondotorg> The branch I branched from has this issue.
<flexiondotorg> I can fix in my merge proposal?
<cyphermox> no, please just keep your own changes
<flexiondotorg> OK, so me merge proposal is just my changes.
<flexiondotorg> But the changelog is broken. I promise it wasn't me :-)
<flexiondotorg> I didn't touch the changelog.
<cyphermox> oh, I know
<flexiondotorg> cyphermox, Nice one on ubi-timezone, b43 and modemmanager BTW.
<cyphermox> it' s been that way for a long while
<cyphermox> yeah, now to tackle usb-modeswitch
<flexiondotorg> Right, I need to get my daughter from school.
<flexiondotorg> ttfn
<cyphermox> and I'm getting sick of forgetting all about it for the whole release and having to scramble to get it fixed; it's a complicated merge, so i want to see if we can't drop all of the delta to keep just the embedded tcl weirdness, even if yuck tcl
<cyphermox> bah, the tcl to c porting is trivial this time, might as well not spend hours playing with it
<bdmurray> slangasek: Can you remove libreoffice from vivid -proposed see bug 1443667.
<ubot93> bug 1443667 in libreoffice (Ubuntu) "Installer crashes installing libreoffice" [High,Fix released] https://launchpad.net/bugs/1443667
<slangasek> bdmurray: done
<apw> would someone be able to binary-new the wily-proposed kernel, then the testing can run over the weekend
<cjwatson> apw: doing
<cjwatson> apw: (done, if you didn't notice)
#ubuntu-release 2015-10-03
<jamespage> please can ^^ horizon upload be rejected - it misses part of the required update
<jamespage> (sat am is not good for my brain apparently)
#ubuntu-release 2016-10-03
-queuebot:#ubuntu-release- Unapproved: gnome-software (yakkety-proposed/main) [3.20.1+git20160923.2.7374bdc-0ubuntu1 => 3.20.1+git20161003.0.7ac7d1b-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gvfs (yakkety-proposed/main) [1.28.2-1ubuntu2 => 1.30.0-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: appstream-glib (xenial-proposed/main) [0.5.13-1ubuntu3 => 0.5.13-1ubuntu4] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: kde4libs (yakkety-proposed/universe) [4:4.14.22-0ubuntu1 => 4:4.14.22-0ubuntu2] (kubuntu)
<tsimonq2> hmmmmmmm ^
-queuebot:#ubuntu-release- Unapproved: accepted kde4libs [source] (yakkety-proposed) [4:4.14.22-0ubuntu2]
<tsimonq2> slangasek: thanks :)
<Mirv> the virtualbox autopkgtest failure happens probably because of 4.8 kernel, and definitely not due to Qt. http://autopkgtest.ubuntu.com/packages/v/virtualbox/yakkety/amd64 - could it be ignored?
-queuebot:#ubuntu-release- Unapproved: lxd (yakkety-proposed/main) [2.3-0ubuntu5 => 2.3-0ubuntu6] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (yakkety-proposed) [2.3-0ubuntu6]
-queuebot:#ubuntu-release- Unapproved: pcl (yakkety-proposed/universe) [1.8.0+dfsg1-4ubuntu1 => 1.8.0+dfsg1-4ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: sqlmap (yakkety-proposed/universe) [1.0.9-1 => 1.0.10-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pcl [source] (yakkety-proposed) [1.8.0+dfsg1-4ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted sqlmap [sync] (yakkety-proposed) [1.0.10-1]
-queuebot:#ubuntu-release- Unapproved: libint2 (yakkety-proposed/universe) [2.1.0-1.1 => 2.1.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libint2 [sync] (yakkety-proposed) [2.1.0-2]
-queuebot:#ubuntu-release- Unapproved: kover (yakkety-proposed/universe) [1:4-9 => 1:4-11] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted kover [sync] (yakkety-proposed) [1:4-11]
<mardy> Laney: hi! Could you please remove the yakkety s390x packages created by online-accounts-api? https://launchpad.net/ubuntu/yakkety/+source/online-accounts-api
<Laney> mardy: nope, can't do that, sorry - you need a member of ubuntu-archive
<Laney> mardy: You should fix the package to stop building those though, if you haven't already
<mardy> Laney: yep, I've the change silo'd
<mardy> cjwatson: hi! could you help with this? ^
<acheronuk> [10:27] <jbicha> could kdegraphics-mobipocket be accepted from the yakkety rejected queue? I see that okular depends on the new version
<acheronuk> indeed it does ^^^
<apw> acheronuk, do we know why it was rejected in teh first place ?
<cjwatson> mardy: not this week, slammed
<cjwatson> mardy: pick another AA victim :)
<mardy> cjwatson: ok, thanks anyway
<mardy> didrocks: hi! Want to be a victim? ^
<didrocks> mardy: I don't have any official time anymore to do AA work :/
<mardy> didrocks: no, thanks anyways :-)
<apw> mardy, why do they need removing ?
<mardy> apw: because they prevent bileto siloes from building, they get stuck in "dependency wait" state
<apw> is this more of your upstart disaster ?
<mardy> apw: mine? :-) but yes, I think it's related to upstart
<apw> mardy, and i don't th
<apw> mardy, and i don't think that those existing is stopping your builds, the depwait there is presumably because you have a dirty build-dep on upstart in s390x
<mardy> apw: I've tried with and without build-dep on upstart, and it gets stuck anyway
<apw> iirc the build-dep: was recommended to make the binaries not build as they are uninstallable as they have a runtime-dep on upstart, right ?
<mardy> apw: yes, that's my understanding too
<cjwatson> yeah, from what I remember of your situation, the dep-wait is intentional
<cjwatson> but perhaps your binaries need to be pulled out so that this doesn't block
<apw> yeah that sounds like what i am expecting, that this is the last time they need removing
<mardy> apw: do you have time to help?
-queuebot:#ubuntu-release- Unapproved: witty (yakkety-proposed/universe) [3.3.5+dfsg-1ubuntu2 => 3.3.5+dfsg-1.1ubuntu1] (no packageset)
<apw> mardy, looking at the ramifications now
-queuebot:#ubuntu-release- Unapproved: accepted witty [source] (yakkety-proposed) [3.3.5+dfsg-1.1ubuntu1]
<shadeslayer> acheronuk: hm, forwarding all those emails is going to be tricky
<shadeslayer> I'll see what I can do
<apw> mardy, can i assume storage-framework is one of yours, and you won't care if it no longer works on s390x ?
<mardy> apw: yes, no one will care
<acheronuk> apw: due to no real changes in the source for this release I think. kde bump their release versions to have a full versioned set for each release for these. reason for no changes in many is that Qt/kde4 dev on those stopped as a Qt5/kf5 port was being done but not ready
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (yakkety-proposed) [3.20.1+git20161003.0.7ac7d1b-0ubuntu1]
<apw> mardy, ok removed ... let the publisher run (~1hr) and see if that unblocks your silo
<acheronuk> shadeslayer: no worries. whatever you can *reasonably* do
<mardy> apw: thanks a lot!
<acheronuk> apw: [09:58] <slangasek> acheronuk: if the kubuntu team wants the new version numbers, they can upload later; final freeze is just not a good time for that kind of upload
<acheronuk> apw: unfortunately as you can see, some of them block builds if not accepted
-queuebot:#ubuntu-release- Packageset: Added im-config to personal-gunnarhj in yakkety
<bluesabre> Hello release team, Xubuntu has some late-landing changes for our Yakkety wallpaper, can we please get an ack for the following?
<bluesabre> https://bugs.launchpad.net/ubuntu/+source/xubuntu-artwork/+bug/1629650
<ubot5> Ubuntu bug 1629650 in xubuntu-artwork (Ubuntu) "[UIFe] New wallpaper for 16.10" [Undecided,New]
<bluesabre> https://bugs.launchpad.net/ubuntu/+source/ubiquity-slideshow-ubuntu/+bug/1629648
<ubot5> Ubuntu bug 1629648 in ubiquity-slideshow-ubuntu (Ubuntu) "[UIFe] Yak art for the Xubuntu slideshow" [Undecided,New]
<xnox> pitti, could you please hint over http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#libgnupg-interface-perl test suite results. it appears those tests fail in the container runners only.
<apw> xnox, why did they work before ?
<xnox> apw, never with gnupg2 =)
<apw> that really, really does not deserve a happy emogi !
<xnox> they do work on bare-metal and kvm.
<xnox> (and pass)
<xnox> (on s390x at least)
<ginggs> would an archive admin remove NBS binaries wine and wine1.4-dev from yakkety, please?
<xnox> gpg: can't connect to the agent: File name too long
<xnox> gpg: error reading key: No secret key
<xnox> not ok 1
<xnox> *sigh*
<xnox> apw, so first they think it's a good idea to use $GNUPGHOME for sockets, then they complain that filename is too long.
<apw> xnox, don't we point HOME somewhere like /DIESCREAMING
<xnox> apw, not anywhere in production, just on poor people's default sbuild
<apw> ahh
<xnox> 'HOME' => '/build/'  & $resolve_alternatives = 1; in my ~/.sbuildrc
<xnox> to match launchpad
<apw> ginggs, if i am reading this right there is a number of things depping on those that need a rebuild
<ginggs> apw: nothing should need a rebuild
<ginggs> apw: wine-stable and wine-development both Provides: wine
<apw> so that might be NBS being too dumb i guess, hrm
-queuebot:#ubuntu-release- Unapproved: mame (yakkety-proposed/multiverse) [0.176-3 => 0.177-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mame [sync] (yakkety-proposed) [0.177-1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-ui-toolkit-gles (yakkety-proposed/universe) [1.3.2104+16.10.20160919.3 => 1.3.2104+16.10.20160929] (ubuntu-qt-packages) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-ui-toolkit (yakkety-proposed/main) [1.3.2104+16.10.20160919.3 => 1.3.2104+16.10.20160929] (ubuntu-desktop, ubuntu-qt-packages) (sync)
<mardy> apw: it worked, thanks a lot!
-queuebot:#ubuntu-release- Unapproved: prelude-manager (yakkety-proposed/universe) [1.0.1-5.1ubuntu3 => 1.0.1-5.2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted prelude-manager [sync] (yakkety-proposed) [1.0.1-5.2]
<apw> ginggs, so yes the NBS report is too dumb, and in theory all those are removable... however I am not convinced that a provides: will trigger package replacement for old installs
-queuebot:#ubuntu-release- Unapproved: bugwarrior (yakkety-proposed/universe) [1.4.0+git2016070901-1 => 1.4.0+git2016090101-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: flask-script (yakkety-proposed/universe) [2.0.5-1 => 2.0.5-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted bugwarrior [sync] (yakkety-proposed) [1.4.0+git2016090101-1]
-queuebot:#ubuntu-release- Unapproved: gnustep-gui (yakkety-proposed/universe) [0.25.0-3 => 0.25.0-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted flask-script [sync] (yakkety-proposed) [2.0.5-2]
-queuebot:#ubuntu-release- Unapproved: ipython-genutils (yakkety-proposed/universe) [0.1.0-1 => 0.1.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnustep-gui [sync] (yakkety-proposed) [0.25.0-4]
-queuebot:#ubuntu-release- Unapproved: kitchen (yakkety-proposed/universe) [1.2.4-1 => 1.2.4-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ipython-genutils [sync] (yakkety-proposed) [0.1.0-2]
-queuebot:#ubuntu-release- Unapproved: libjs-jquery-selectize.js (yakkety-proposed/universe) [0.12.2+dfsg-1 => 0.12.3+dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: minetest-mod-mesecons (yakkety-proposed/universe) [2016.07.09-1 => 2016.09.13-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted kitchen [sync] (yakkety-proposed) [1.2.4-2]
-queuebot:#ubuntu-release- Unapproved: accepted minetest-mod-mesecons [sync] (yakkety-proposed) [2016.09.13-1]
-queuebot:#ubuntu-release- Unapproved: node-text-encoding (yakkety-proposed/universe) [0.6.0-1 => 0.6.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libjs-jquery-selectize.js [sync] (yakkety-proposed) [0.12.3+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: node-simple-fmt (yakkety-proposed/universe) [0.1.0+20130419-1 => 0.1.0+20130419-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: pygccxml (yakkety-proposed/universe) [1.7.4-3 => 1.8.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-simple-fmt [sync] (yakkety-proposed) [0.1.0+20130419-2]
-queuebot:#ubuntu-release- Unapproved: accepted pygccxml [sync] (yakkety-proposed) [1.8.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted node-text-encoding [sync] (yakkety-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- Unapproved: pynac (yakkety-proposed/universe) [0.6.8-1 => 0.6.9-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: relational (yakkety-proposed/universe) [2.4-1 => 2.5-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pynac [sync] (yakkety-proposed) [0.6.9-1]
-queuebot:#ubuntu-release- Unapproved: rc (yakkety-proposed/universe) [1.7.2-2build1 => 1.7.4-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted relational [sync] (yakkety-proposed) [2.5-1]
-queuebot:#ubuntu-release- Unapproved: svnmailer (yakkety-proposed/universe) [1.0.9-2 => 1.0.9-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: timew (yakkety-proposed/universe) [1.0.0~beta1+ds-1 => 1.0.0+ds.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted rc [sync] (yakkety-proposed) [1.7.4-1]
-queuebot:#ubuntu-release- Unapproved: accepted timew [sync] (yakkety-proposed) [1.0.0+ds.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted svnmailer [sync] (yakkety-proposed) [1.0.9-3]
-queuebot:#ubuntu-release- Unapproved: traitlets (yakkety-proposed/universe) [4.2.2-2 => 4.3.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted traitlets [sync] (yakkety-proposed) [4.3.1-1]
<ginggs> apw: old installs of wine get removed due to wine-stable and wine-development having Conflicts: wine (>= 1.1)
<apw> ginggs, yes, but how to _new_ installs of wine-stable get triggered if you have wine installed already
<ginggs> apw: through wine1.6
-queuebot:#ubuntu-release- Unapproved: acmetool (yakkety-proposed/universe) [0.0.56-1 => 0.0.56-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted acmetool [sync] (yakkety-proposed) [0.0.56-2]
-queuebot:#ubuntu-release- Unapproved: wsjtx (yakkety-proposed/universe) [1.1.r3496-3 => 1.1.r3496-3.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: wdq2wav (yakkety-proposed/multiverse) [1.0.0-1 => 1.0.0-1.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: xpaint (yakkety-proposed/universe) [2.9.1.4-3.1build1 => 2.9.1.4-3.2] (no packageset) (sync)
<ginggs> apw: ubuntu's old wine package was a metapackage that Depends: wine1.6
-queuebot:#ubuntu-release- Unapproved: accepted wdq2wav [sync] (yakkety-proposed) [1.0.0-1.1]
-queuebot:#ubuntu-release- Unapproved: accepted xpaint [sync] (yakkety-proposed) [2.9.1.4-3.2]
-queuebot:#ubuntu-release- Unapproved: djmount (yakkety-proposed/universe) [0.71-7 => 0.71-7.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: polyorb (yakkety-proposed/universe) [2.11~20140418-3 => 2.11~20140418-3.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted wsjtx [sync] (yakkety-proposed) [1.1.r3496-3.1]
-queuebot:#ubuntu-release- Unapproved: nast (yakkety-proposed/universe) [0.2.0-6build1 => 0.2.0-6.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: diffpdf (yakkety-proposed/universe) [2.1.3-1 => 2.1.3-1.1] (no packageset) (sync)
<santa_> slangasek: good morning, I would like to work with you on the issues we got with kde packages
-queuebot:#ubuntu-release- Unapproved: accepted diffpdf [sync] (yakkety-proposed) [2.1.3-1.1]
-queuebot:#ubuntu-release- Unapproved: accepted nast [sync] (yakkety-proposed) [0.2.0-6.1]
-queuebot:#ubuntu-release- Unapproved: fractalnow (yakkety-proposed/universe) [0.8.1-1build1 => 0.8.1-1.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted djmount [sync] (yakkety-proposed) [0.71-7.1]
-queuebot:#ubuntu-release- Unapproved: accepted polyorb [sync] (yakkety-proposed) [2.11~20140418-3.1]
-queuebot:#ubuntu-release- Unapproved: tachyon (yakkety-proposed/universe) [0.99~b6+dsx-5 => 0.99~b6+dsx-6] (no packageset) (sync)
<santa_> first of all I would like to say that we would upload libkexiv2 (we missed that in the massive uploading)
<santa_> and we would also need to get drumstick in (it's needed by minuet)
-queuebot:#ubuntu-release- Unapproved: accepted fractalnow [sync] (yakkety-proposed) [0.8.1-1.1]
-queuebot:#ubuntu-release- Unapproved: accepted tachyon [sync] (yakkety-proposed) [0.99~b6+dsx-6]
-queuebot:#ubuntu-release- Unapproved: siege (yakkety-proposed/main) [4.0.2-1ubuntu1 => 4.0.2-1.1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: wsjtx (yakkety-proposed/universe) [1.1.r3496-3.1 => 1.1.r3496-3.1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted wsjtx [source] (yakkety-proposed) [1.1.r3496-3.1build1]
-queuebot:#ubuntu-release- Unapproved: aodh (yakkety-proposed/main) [3.0.0~rc1-0ubuntu2 => 3.0.0~rc1-0ubuntu3] (openstack)
-queuebot:#ubuntu-release- Unapproved: python-pymysql (xenial-proposed/main) [0.7.2-1 => 0.7.2-1ubuntu1] (ubuntu-server)
<Mirv> ^ (some screens up) ubuntu-ui-toolkit and ubuntu-ui-toolkit-gles no code changes, just arm64 test enablement
<apw> Mirv, that seems like a strange reason to upload them ?
<Mirv> apw: well QA was insisting they want to have them immediately, but then if they should skip yakkety thats ok and up to you. the bileto is still releasing everything to yakkety and not the PPA.
<Mirv> which this week starts to be wrong
<Mirv> sil2100: maybe redirecting bileto silos to overlay this week now?
-queuebot:#ubuntu-release- Unapproved: ubuntu-system-settings-online-accounts (yakkety-proposed/universe) [0.7+16.10.20160830.2-0ubuntu1 => 0.7+16.10.20160929-0ubuntu1] (no packageset) (sync)
<sil2100> Mirv: I guess that's a valid proposal right now
<sil2100> Mirv: let me discuss that quickly tomorrow on the RTM status
<Mirv> could you ignore virtualbox autopkgtest failures for qtbase-opensource-src and qtbase-opensource-src-gles ? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src
<apw> Mirv, yeah that is a kernel interaction, we have the same version in the kernel
<Mirv> it seems that has constantly been failing since linux 4.8 for introduced
<Mirv> apw: right.
<apw> Mirv, it is actually about whether the kernel and it are in sync, and if they are it breaks
<apw> (which ironically is a good thing)
<apw> Mirv, and done
<Mirv> apw: thank you!
-queuebot:#ubuntu-release- Unapproved: ceilometer (yakkety-proposed/main) [1:7.0.0~rc2-0ubuntu1 => 1:7.0.0~rc3-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: miral (yakkety-proposed/universe) [0.1.0+16.10.20160919-0ubuntu1 => 0.2.0+16.10.20160930.1-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted miral [sync] (yakkety-proposed) [0.2.0+16.10.20160930.1-0ubuntu1]
-queuebot:#ubuntu-release- New source: ubuntu-kylin-wizard (yakkety-proposed/primary) [16.10.0]
-queuebot:#ubuntu-release- Unapproved: libkf5kexiv2 (yakkety-proposed/universe) [15.12.3-0ubuntu1 => 16.04.3-0ubuntu1] (kubuntu)
<santa_> hi again
<santa_> it would be nice if wee could get this one approved â (libkf5kexiv2) because it's blocking other builds of kde applications
<santa_> (we missed it because of a small glich in out automation tools)
<santa_> s/wee/we/
<santa_> s/out/our/
-queuebot:#ubuntu-release- Unapproved: hardinfo (yakkety-proposed/universe) [0.5.1-1.4ubuntu1 => 0.5.1-1.4ubuntu2] (lubuntu)
-queuebot:#ubuntu-release- Unapproved: kio (yakkety-proposed/universe) [5.26.0-0ubuntu1 => 5.26.0-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plasma-discover (yakkety-proposed/universe) [5.7.5-0ubuntu1 => 5.7.5-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plasma-sdk (yakkety-proposed/universe) [4:5.7.5-0ubuntu1 => 4:5.7.5-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plasma-desktop (yakkety-proposed/universe) [4:5.7.5-0ubuntu1 => 4:5.7.5-0ubuntu2] (kubuntu)
<slashd> Hi SRU vanguard, could you please nominate LP:  #1628279 affecting Xenial ?
<ubot5> Launchpad bug 1628279 in zfs-linux (Ubuntu) "python utilities script suffix (.py) should be removed as per Policy 10.4" [Low,Fix released] https://launchpad.net/bugs/1628279
<apw> slashd, done
<slashd> apw, tks
<rbasak> slashd: won't that regress Xenial users by definition?
<apw> yep, looks like it will ... perhaps we should be offering them under both names in this
<rbasak> Yeah, adding symlinks makes sense. Then users can rely on the new names, but users relying on the old names won't break before a release upgrade.
<apw> rbasak, perhaps copy that into the bug, i do not believe they have done the work on teh sru yet
<rbasak> Will do
<slashd> apw, rbasak, the debdiff for Xenial is not done yet, only yakkety to addressed the situation the sooner, but yes I was actually thinking of a symlink approach too, I'm glad you have a +1 on this
<apw> slashd, it sounds like there are two pending srus here (following through the bugs) can we get those two together
<slashd> apw, merging "1628279" with "1607920" in one single debdiff ?
<apw> slashd, as i understnad things they both are blockers for seeding right?
<slashd> apw, "1628279" as definitely more impact, caribou is working on the upload, it is fixing a bug, where the renaming is more/less cosmetic but still I think we need to do it.
-queuebot:#ubuntu-release- Unapproved: gnome-calculator (xenial-proposed/main) [1:3.18.3-0ubuntu1 => 1:3.18.3-0ubuntu1.16.04.1] (ubuntu-desktop)
<slashd> cking, apw and I would like to combine both LPs in one single SRU : your python2->python3 + the utilities python script renaming (1628279), I'll redo the SRU accordingly
<sakrecoer> hi everyone, sorry for nagging about this, but now we have all the missing pieces for our FFe/UIFe ... https://bugs.launchpad.net/ubuntustudio/+bug/1624690 we would be very thankfull if this could land on our ISO before RC...
<ubot5> Ubuntu bug 1624690 in ubuntustudio-lightdm-theme (Ubuntu) "[UIFe/FFe] Please upload ubuntustudio-default-settings" [Undecided,New]
 * sakrecoer crosses fingers and proceeds to nagg a little in #u-dev too :3
<slashd> cking, apw disregard my last comment
-queuebot:#ubuntu-release- Unapproved: nautilus-image-converter (xenial-proposed/universe) [0.3.1~git20110416-1ubuntu1 => 0.3.1~git20110416-1ubuntu1.16.04.1] (no packageset)
<slashd> caribou, as per my discussion with apw,  I will re-submit a new debdiff for bug (1607920) which will include fix for another bug I worked on as well (1628279) for Xenial.
<caribou> slashd: ok
-queuebot:#ubuntu-release- Unapproved: xml-core (yakkety-proposed/main) [0.13+nmu2ubuntu1 => 0.15] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: ptouch-driver (yakkety-proposed/main) [1.4.2-1 => 1.4.2-2] (desktop-core) (sync)
-queuebot:#ubuntu-release- Unapproved: playonlinux (yakkety-proposed/multiverse) [4.2.10-2 => 4.2.10-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted playonlinux [source] (yakkety-proposed) [4.2.10-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: cyphesis-cpp (yakkety-proposed/universe) [0.6.0-6build1 => 0.6.2-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted cyphesis-cpp [sync] (yakkety-proposed) [0.6.2-2]
-queuebot:#ubuntu-release- Unapproved: polyorb (yakkety-proposed/universe) [2.11~20140418-3.1 => 2.11~20140418-3.1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted polyorb [source] (yakkety-proposed) [2.11~20140418-3.1build1]
<slangasek> acheronuk, apw: kdegraphics-mobipocket accepted (though an equally valid fix would have been to have okular un-version its build-dep)
<slangasek> ginggs: http://people.canonical.com/~ubuntu-archive/nbs.html says wine, wine1.4-dev aren't ready to be removed
<slangasek> ah, apw already addressed this
<slangasek> santa_: hi, so I'm several timezones west of you, best to not block on me for things you need; but I'm looking at libkf5kexiv2 now
-queuebot:#ubuntu-release- Unapproved: accepted libkf5kexiv2 [source] (yakkety-proposed) [16.04.3-0ubuntu1]
<slangasek> acheronuk, santa_: is anyone looking at the kde-runtime autopkgtest failure?  Strangely the tests are not run at build time...
-queuebot:#ubuntu-release- Unapproved: ubuntustudio-default-settings (yakkety-proposed/universe) [0.62 => 0.63] (no packageset)
<ginggs> slangasek: i think dssi-vst should be removed, it was removed from debian in 2013. will wine1.4-dev then get removed automatically?
-queuebot:#ubuntu-release- Unapproved: ubuntustudio-lightdm-theme (yakkety-proposed/universe) [0.9 => 0.10] (no packageset)
<slangasek> ginggs: done (and yes, that should make wine1.4-dev a candidate for NBS removal)
-queuebot:#ubuntu-release- Unapproved: libpfm4 (yakkety-proposed/main) [4.7.0+git11-gbfb9baf-1 => 4.7.0+git30-gd422ba2-1] (no packageset) (sync)
<ginggs> slangasek: thanks! ok, is anything else needed wrt to the wine binary NBS?
<slangasek> ginggs: don't know; apw?
<apw> so the confusion was whether there was a clean path for existing people with "wine" installed to the new world order
<apw> yes if they install wine they will get the new via a provides, but is there a migration for actual old wine metapackages installed
<apw> as that currently includes a path through the package we are trying to remove
<ginggs> apw: if they had the old wine metapackage, they would have wine1.6 installed
<slangasek> this does not ensure that apt chooses to upgrade wine1.6 and remove wine; have you tested?
<ginggs> slangasek: yes, we did much testing
<ginggs> various upgrade logs in LP: #1558480
<ubot5> Launchpad bug 1558480 in wine1.6 (Ubuntu) "[FFe] Transition from src:wine1.6 to src:wine from Debian" [High,Fix released] https://launchpad.net/bugs/1558480
<apw> ginggs, and wine/1:1.6.2-0ubuntu14 from xenial is already in this form
<ginggs> apw: sorry, not understanding
<apw> ginggs, i mean we're testing using the xenial base on upgrade to yakkety
<ginggs> wine/1:162-0ubuntu14 and -0ubuntu15 are still in the old form
<apw> but they are in the form with wine causeing wine1.6 to be installed ?
<acheronuk> slangasek: thank you :) downgrading the okular build-deps was a fallback option
<ginggs> yes, it is the old form where they are metapackages that Depends: wine1.6
<sakrecoer> \o\ Laney /o/ thank you!!!! <3
-queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.18.1 => 2.19] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cinder (yakkety-proposed/main) [2:9.0.0~rc1-0ubuntu1 => 2:9.0.0~rc2-0ubuntu1] (openstack, ubuntu-server)
<sergiusens> infinity or others in the sru team, mind letting snapcraft ^ in?
 * apw has a look ...
-queuebot:#ubuntu-release- Unapproved: gnocchi (yakkety-proposed/universe) [2.0.2-7 => 3.0.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: magnum (yakkety-proposed/universe) [2.0.0-6 => 3.0.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnocchi [sync] (yakkety-proposed) [3.0.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted magnum [sync] (yakkety-proposed) [3.0.0-1]
-queuebot:#ubuntu-release- Unapproved: sahara (yakkety-proposed/universe) [1:5.0.0~b2-1 => 1:5.0.0~rc1-1] (openstack) (sync)
-queuebot:#ubuntu-release- Unapproved: unity8 (yakkety-proposed/universe) [8.14+16.10.20160922-0ubuntu1 => 8.14+16.10.20160922-0ubuntu2] (ubuntu-qt-packages)
-queuebot:#ubuntu-release- Unapproved: designate (yakkety-proposed/main) [1:3.0.0~rc1-0ubuntu1 => 1:3.0.0~rc2-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (xenial-proposed) [2.19]
-queuebot:#ubuntu-release- Unapproved: glance (yakkety-proposed/main) [2:13.0.0~rc1-0ubuntu1 => 2:13.0.0~rc2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: horizon (yakkety-proposed/main) [3:10.0.0~rc2-0ubuntu1 => 3:10.0.0~rc3-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: nova (yakkety-proposed/main) [2:14.0.0~rc1-0ubuntu2 => 2:14.0.0~rc2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted hardinfo [source] (yakkety-proposed) [0.5.1-1.4ubuntu2]
<slangasek> pitti: for some reason the autopkgtest requests for a couple of bileto ppas went missing - and I retried them and they still didn't fire.  how do we debug these going missing?  is it possible that triggering for multiple releases in parallel is a problem on the amqp side?
<slangasek> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-1988-excuses/2016-10-01_06:35:00/1988_vivid_excuses.html https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-1988-excuses/2016-10-01_06:35:00/1988_xenial_excuses.html
<slangasek> actually
<slangasek> pitti: nevermind, apparently those URLs are stale (?) and there are different excuses for that ppa that show things completed
<slangasek> robru: ^^ why would the excuses url for a ticket change over time?  that's inconvenient
-queuebot:#ubuntu-release- Unapproved: accepted unity8 [source] (yakkety-proposed) [8.14+16.10.20160922-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: juju-core (yakkety-proposed/main) [2.0~beta17-0ubuntu1.16.10.1 => 2.0~rc2-0ubuntu1.16.10.1] (ubuntu-server)
<handsome_feng> Laney, hi, are you there? It is has been a while since I updated the ubuntu-kylin-wizard package, Couble you please upload that when you are free, Thank you !
<Laney> handsome_feng: did you see https://bugs.launchpad.net/ubuntukylin/+bug/1609207/comments/5 ?
<ubot5> Ubuntu bug 1609207 in Ubuntu Kylin "[needs-packaging] ubuntu-kylin-wizard" [High,Fix committed]
<jbicha> handsome_feng: could you make sure Kylin is aware of bug 1618138 ?
<ubot5> bug 1618138 in ubuntukylin-theme (Ubuntu) "Adapt to flatpak style icon names" [Undecided,New] https://launchpad.net/bugs/1618138
<handsome_feng> Oh, I just notise that , Thank you , laney.
<handsome_feng> jbicha: er, I'm not sure about that, I will ask the people
<jbicha> thanks
<apw> Laney, that "initial version" bug number looks to be an unrelated hardinfo bug ?  (for ubuntu-kylin-wizard)
<Laney> AAAAAAAAAAAAA
<Laney> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
<Laney> it should be the one I just linked
<apw> Laney, it appears to be one i recognise so from a qeueu entry today
<Laney> lemme fix that
<Laney> I probably copied from the wrong tab
<robru> slangasek: it's the nature of swift that you can't overwrite an object once it's been written (at least not reliably), so each new file gets a new time-stamped name
<slangasek> robru: well that's unseemly
-queuebot:#ubuntu-release- New source: ubuntu-kylin-wizard (yakkety-proposed/primary) [16.10.0]
-queuebot:#ubuntu-release- Unapproved: indicator-network (yakkety-proposed/universe) [0.8.0+16.10.20160915-0ubuntu1 => 0.8.0+16.10.20160930.5-0ubuntu1] (no packageset) (sync)
<Laney> apw: try that one
-queuebot:#ubuntu-release- Unapproved: accepted indicator-network [sync] (yakkety-proposed) [0.8.0+16.10.20160930.5-0ubuntu1]
<robru> slangasek: when i was first adding swift support for diffs, i tried overwriting same names, but the old version would get served most of the time because it's a caching distributed file store thing. It was pitti who suggested putting a timestamp in the name so each upload would have a unique name
<cjwatson> you could have a frontend server proxy the current file from swift
<slangasek> yes
<cjwatson> that's the usual approach
<robru> Yeah? The current URL is listed on the ticket
<slangasek> robru: the end user experience should not require me to go back to the ticket page to find a new URL
-queuebot:#ubuntu-release- New: rejected ubuntu-kylin-wizard [source] (yakkety-proposed) [16.10.0]
<slangasek> hitting 'refresh' in my browser should Just Work
<slangasek> thus, 'frontend'
<robru> Hmm
<flocculant> slangasek: we're seeing a crash on update manager - I think there's probably a private bug for it, but I reported bug 1629900 which has a branch linked with a fix
<ubot5> bug 1629900 in update-manager (Ubuntu) "update-manager crashed with ValueError in require_version(): Namespace Unity not available" [Medium,Confirmed] https://launchpad.net/bugs/1629900
<flocculant> or rather I know there is a bug which I can't see bug 1623296
<ubot5> Error: Launchpad bug 1623296 could not be found
<tsimonq2> thanks Laney
-queuebot:#ubuntu-release- New: rejected ubuntu-kylin-wizard [source] (yakkety-proposed) [16.10.0]
-queuebot:#ubuntu-release- New source: ubuntu-kylin-wizard (yakkety-proposed/primary) [16.10.0]
-queuebot:#ubuntu-release- New: accepted ubuntu-kylin-wizard [source] (yakkety-proposed) [16.10.0]
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.3 => 2.02~beta2-36ubuntu3.4] (core)
-queuebot:#ubuntu-release- New binary: ubuntu-kylin-wizard [amd64] (yakkety-proposed/none) [16.10.0] (no packageset)
-queuebot:#ubuntu-release- New binary: ubuntu-kylin-wizard [ppc64el] (yakkety-proposed/none) [16.10.0] (no packageset)
-queuebot:#ubuntu-release- New binary: ubuntu-kylin-wizard [arm64] (yakkety-proposed/none) [16.10.0] (no packageset)
-queuebot:#ubuntu-release- New binary: ubuntu-kylin-wizard [i386] (yakkety-proposed/none) [16.10.0] (no packageset)
-queuebot:#ubuntu-release- New binary: ubuntu-kylin-wizard [armhf] (yakkety-proposed/none) [16.10.0] (no packageset)
-queuebot:#ubuntu-release- New binary: ubuntu-kylin-wizard [s390x] (yakkety-proposed/none) [16.10.0] (no packageset)
-queuebot:#ubuntu-release- New binary: ubuntu-kylin-wizard [powerpc] (yakkety-proposed/none) [16.10.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gnome-session (yakkety-proposed/main) [3.20.2-1ubuntu5 => 3.20.2-1ubuntu6] (ubuntu-desktop)
<slangasek> bdmurray: could you lookt at flocculant's update-manager crash+branch? (https://launchpad.net/bugs/1629900)
<ubot5> Ubuntu bug 1629900 in update-manager (Ubuntu Yakkety) "update-manager crashed with ValueError in require_version(): Namespace Unity not available" [Medium,Triaged]
-queuebot:#ubuntu-release- Unapproved: ubuntu-terminal-app (yakkety-proposed/universe) [0.7.218 => 0.7.218ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-terminal-app [source] (yakkety-proposed) [0.7.218ubuntu1]
<bdmurray> slangasek: I've been looking at it already. ;-)
<slangasek> bdmurray: \o/
<flocculant> thanks guys :)
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [0.7.8-1-g3705bb5-0ubuntu1~16.04.2 => 0.7.8-1-g3705bb5-0ubuntu1~16.04.3] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lxd (trusty-backports/universe) [2.0.3-0ubuntu2~ubuntu14.04.1 => 2.0.4-0ubuntu1~ubuntu14.04.1] (no packageset)
<lamont> dear archive-admins... please take smosers upload of cloud-init as a replacement for thge one I have sitting in xenial-proposed.
<lamont> kthx
-queuebot:#ubuntu-release- Unapproved: lxc (trusty-backports/main) [2.0.3-0ubuntu1~ubuntu14.04.1 => 2.0.4-0ubuntu1~ubuntu14.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: designate-dashboard (yakkety-proposed/universe) [2.0.0-2 => 3.0.0~rc1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted designate-dashboard [sync] (yakkety-proposed) [3.0.0~rc1-1]
-queuebot:#ubuntu-release- Unapproved: lxcfs (trusty-backports/universe) [2.0.2-0ubuntu1~ubuntu14.04.1 => 2.0.3-0ubuntu1~ubuntu14.04.1] (no packageset)
<slangasek> cjwatson: why does trying to grab ubuntu-ui-toolkit from the yakkety unapproved queue with 'queue fetch' give me an openid login page instead of a .dsc?
<slangasek> (instead of any of the files, indeed)
<slangasek> ah
<slangasek> the source ppa is deleted
<slangasek> robru: why is the ppa for https://bileto.ubuntu.com/#/ticket/2019 deleted before the package has landed in yakkety?
<slangasek> Mirv: looks like this is your doing.  Did you knowingly override a warning in bileto about the packages not yet having landed in yakkety?
-queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (trusty-backports) [2.0.4-0ubuntu1~ubuntu14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (trusty-backports) [2.0.4-0ubuntu1~ubuntu14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted lxcfs [source] (trusty-backports) [2.0.3-0ubuntu1~ubuntu14.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-ui-toolkit-gles [sync] (yakkety-proposed) [1.3.2104+16.10.20160929]
-queuebot:#ubuntu-release- Unapproved: grub2-signed (xenial-proposed/main) [1.66.3 => 1.66.4] (core)
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-ui-toolkit [sync] (yakkety-proposed) [1.3.2104+16.10.20160929]
-queuebot:#ubuntu-release- Unapproved: rejected gvfs [source] (yakkety-proposed) [1.30.0-1ubuntu1]
<robru> slangasek: yep, Mirv force merged. he should be aware that force merging while things are unapproved nukes them (this was true also before ephemeral ppas)
<slangasek> robru: why do we still have that button? :-)
<robru> slangasek: there are cases where it's warranted, eg if it's in proposed and we're rushing to get an ota out the door or something.
<robru> slangasek: I suppose I could make a big red warning for when merging when things are still unapproved
<slangasek> force-merging, even if it's just in -proposed, still breaks the archive CI
<slangasek> robru: or disallow entirely for that case, since it nukes the packages and leaves the archive admins with a mess?
<robru> slangasek: I thought archive admins were aware that queued uploads where the source has been deleted should just be rejected with extreme prejudice?
<slangasek> robru: I /have/ rejected it with extreme prejudice.  Figuring out that this was what was supposed to happen took far more time than it should have
<robru> slangasek: let's say hypothetically bileto prevented force-merging tickets with unapproved queue packages, what would you prefer to happen? presumably mirv needed that merged so he could rebuild some other silo and include the changes, so you'd want mirv to come here and ask to have the upload rejected, then he can merge? I don't see a lot of point in that,
<robru> if un-doing the upload is really what you want to do
<robru> "really what HE wanted to do"
<robru> slangasek: it sounds to me more like your upload queue software should be smarter/faster about noticing when the source has vanished
<slangasek> robru: force-merge does not mean "undo the upload"
<robru> slangasek: well, it does for queued uploads, and mirv knows that
<slangasek> robru: no, it was a triple-landing, so two of them are landed and the third one is broken off at the hip
<slangasek> if you want to abandon a ticket, you abandon a ticket, you don't *merge* it
<slangasek> "your upload queue software" - which is Launchpad, which is the existing software that bileto needs to integrate with
<slangasek> if you want to provide a patch to Launchpad to auto-reject things from the queue when the source disappears, ok ;)
<slangasek> but this still absolutely should not have been force-merged
<robru> slangasek: but he didn't want to abandon it, he wanted the changes merged to trunk.
<slangasek> robru: then that is the opposite of undoing the upload!
<robru> slangasek: I know it's bad practise, but I don't think it's outrageously terrible to want to merge something to trunk without caring if it actually got to the archive. I would assume he just had another ticket he wanted to publish quickly and just wanted to merge one, rebuild the other, then publish, essentially batching up two uploads into one. I don't know
<robru> if that's what really happened but it seems like a reasonable scenario.
<slangasek> if there is not a committment to follow the process, then these packages should not be using triple landings
-queuebot:#ubuntu-release- Unapproved: python-taskflow (yakkety-proposed/main) [2.3.0-1 => 2.3.0-1ubuntu1] (ubuntu-server)
<slangasek> and other teams should not be left doing forensics to figure out the mess left behind
<tsimonq2> slangasek: what emails are sent out to flavors for anything administrative? also, what about email notifications for package uploads like the Debian archive?
<slangasek> tsimonq2: "sent out to flavors" - if you mean the mails you asked to be signed up for, it's image build failures and image oversized
<slangasek> and there's not really a way to sign up for notifications of package uploads
<tsimonq2> slangasek: well I mean the Debian tracker notifies on that sort of thing, I get those emails all the time!
<robru> slangasek: bileto doesn't have permission to remove packages from the upload queue, for the same reason it doesn't have permission to add things to the upload queue, so noticing sources of uploads have been deleted is on LP's end
<slangasek> robru: yes, so take out the force-merge option.
<tsimonq2> slangasek: is it something in the tooling? the way things are set up? what if I really wanted to receieve those sort of notifications for the lubuntu packageset?
<slangasek> landers should not be half-landing and then backing out of yakkety.  If they're not going to use dual/triple landings right, they need to be maintaining separate per-release branches.
<robru> slangasek: you want it taken out entirely, or taken out in the case of queued uploads, or can we just limit it's use to a smaller group of trusted people?
<robru> slangasek: mirv is technically a train guard
<slangasek> robru: IMHO it should be taken out entirely; I would accept a compromise of removing the option for queued uploads; and no it shouldn't be limited to "trusted people", because nobody should be trusted with this ;)
<slangasek> tsimonq2: Debian upload management is completely different software to Ubuntu's
-queuebot:#ubuntu-release- Unapproved: nova-lxd (yakkety-proposed/main) [14.0.0~b3-0ubuntu1 => 14.0.0~rc1-0ubuntu1] (ubuntu-server)
<robru> slangasek: removing it entirely is a scary prospect for me because there are times when proposed is broken but tickets still need to land
<slangasek> right
<robru> Impedance mismatch between touch and archive
<tsimonq2> slangasek: I see, ok, I thought you guys shared a lot more tools
-queuebot:#ubuntu-release- Unapproved: helm (yakkety-proposed/universe) [2.1.0-1 => 2.2.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: link-grammar (yakkety-proposed/universe) [5.3.10-1 => 5.3.11-1] (no packageset) (sync)
<tsimonq2> slangasek: is it set up different on the servers or is there somewhere I can make a PR against?
<slangasek> tsimonq2: er, we use Launchpad? :)
-queuebot:#ubuntu-release- Unapproved: accepted siege [sync] (yakkety-proposed) [4.0.2-1.1]
<slangasek> tsimonq2: so you can propose a merge against launchpad :)
 * tsimonq2 greps for $release-changes@lists.ubuntu.com
<robru> slangasek: also, abandoning has the same problem, the source is deleted without removing the queued upload, should i block that too?
<tsimonq2> thanks slangasek :)
-queuebot:#ubuntu-release- Unapproved: accepted helm [sync] (yakkety-proposed) [2.2.0-1]
<slangasek> robru: no, because in that case it's consistent - the package will not land in the archive, and the branch is not merged to trunk
-queuebot:#ubuntu-release- Unapproved: accepted link-grammar [sync] (yakkety-proposed) [5.3.11-1]
<robru> slangasek: but still you have a queued upload that takes you too long to notice doesn't exist
<slangasek> in a dual/triple landing, of course, it will be landed in the overlay ppa still... unless you want bileto to back those out also on 'abandon'
<robru> Ugh
<robru> slangasek: some time ago i proposed not copying to overlay until after it migrated through proposed but that was shot down
<slangasek> robru: yes, the interaction with the queue will still be annoying, but in this case I think it happened only because force-merge was pushed when the right answer was to wait for the review
<slangasek> heh
<robru> slangasek: ok I'll block merges when uploads are queued
<slangasek> robru: thanks :)
-queuebot:#ubuntu-release- Unapproved: accepted aodh [source] (yakkety-proposed) [3.0.0~rc1-0ubuntu3]
<slangasek> robru: fwiw it seems you're right, there is a new ticket for those packages now https://bileto.ubuntu.com/#/ticket/2035
<robru> slangasek: yeah, that makes sense
<gQuigs> should I do a separate removal request for src:wine (wine 1.6) which is obsolote due to https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1558480
<ubot5> Ubuntu bug 1558480 in wine1.6 (Ubuntu) "[FFe] Transition from src:wine1.6 to src:wine from Debian" [High,Fix released]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-system-settings-online-accounts [sync] (yakkety-proposed) [0.7+16.10.20160929-0ubuntu1]
<gQuigs> the package "wine" is now a virtual package provided by wine-stable
<slangasek> gQuigs: no, this has been discussed in this channel this morning
<gQuigs> oh - oops - will check the logs
-queuebot:#ubuntu-release- Unapproved: accepted ceilometer [source] (yakkety-proposed) [1:7.0.0~rc3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kio [source] (yakkety-proposed) [5.26.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-discover [source] (yakkety-proposed) [5.7.5-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-sdk [source] (yakkety-proposed) [4:5.7.5-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-desktop [source] (yakkety-proposed) [4:5.7.5-0ubuntu2]
<slangasek> Laney: I see you requested a sync for xml-core; I talked about this with nacc on Friday and I think he concluded we should not sync; why is this wanted now?
-queuebot:#ubuntu-release- New binary: libkf5kipi [i386] (yakkety-proposed/universe) [16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkf5kipi [ppc64el] (yakkety-proposed/universe) [16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkf5kipi [amd64] (yakkety-proposed/universe) [16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkf5kipi [arm64] (yakkety-proposed/universe) [16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkf5kipi [armhf] (yakkety-proposed/universe) [16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkf5kipi [s390x] (yakkety-proposed/universe) [16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkf5kipi [powerpc] (yakkety-proposed/universe) [16.04.3-0ubuntu1] (kubuntu)
<jderose> cyphermox: so re reverting shim in yakkety... anything i can help with? :)
<cyphermox> jderose: not really, I'm just pressing buttons now
<jderose> cyphermox: please let me know when you have something to test
-queuebot:#ubuntu-release- Unapproved: accepted ptouch-driver [sync] (yakkety-proposed) [1.4.2-2]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntustudio-default-settings [source] (yakkety-proposed) [0.63]
<smoser> hi. can i get an archive admin to please replace cloud-init in xenial-proposed (0.7.8-1-g3705bb5-0ubuntu1~16.04.2 ) with the version i uploaded to (0.7.8-1-g3705bb5-0ubuntu1~16.04.3)
<smoser> i guess maybe that takes sru team member
<slangasek> smoser: maybe bdmurray wants to take this one, as he's doing SRU team training today (IIRC)
<smoser> that'd be nice. it should be a good example of straight forward
<cyphermox> there's also more grub2 / grub2-signed in xenial queue
<smoser> shoot. other than i forgot to -v for genchanges correctly
<smoser> shall i re-upload for that slangasek ?
-queuebot:#ubuntu-release- Unapproved: accepted ubuntustudio-lightdm-theme [source] (yakkety-proposed) [0.10]
<slangasek> smoser: yes please
<smoser> NACK the one there then ?
<slangasek> smoser: done
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (xenial-proposed) [0.7.8-1-g3705bb5-0ubuntu1~16.04.3]
<bdmurray> slangasek: The training is tomorrow so if smoser is in hurry I can review it now.
<santa_> slangasek: thank you very much for libkexiv, I'm not looking @ kde-runtime so far, right now my priority are some library rejections which I think they are going to block other builds
<slangasek> bdmurray: ok, it is a hurry - if you can get it now spiff, otherwise I can
<smoser> bdmurray, well, roaksoax will tell you he's in a hurry.
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [0.7.8-1-g3705bb5-0ubuntu1~16.04.2 => 0.7.8-1-g3705bb5-0ubuntu1~16.04.3] (edubuntu, ubuntu-cloud, ubuntu-server)
<slangasek> santa_: kde-runtime also blocks loads fwiw; I've managed to reproduce the failure, and frustratingly it doesn't reproduce when I run the test case directly, only when I run it under the test harness
<cyphermox> jderose: if only shim was to cooperate better with building under gcc 5/6 that would be nice, but I really doubt you can do anything about that ;)
<slangasek> cyphermox: building?
<cyphermox> slangasek: don't we still want to have the old shim source too?
<slangasek> cyphermox: yes, but you can't rebuild it, you'll get a different binary
<slangasek> cyphermox: this is copy-package -e territory
<cyphermox> oh, right, because shim-signed also goes to check things after
<jderose> cyphermox: yeah, i different build would need to be resigned, right?
<santa_> slangasek: reagrding the tests, back in the days we were actively disabling them in debian, however that autopkgtests thing arrived and the current maintainer in debian worked on that, and I have the impression he spends the 100% of the time fixing the test themselves or the environment of the tests than fixing any actual bug in the code tested
<slangasek> cyphermox: yes, this requires literally downgrading shim in the archive on a provisional basis until the new signed one comes in
<cyphermox> yeah
<slangasek> santa_: growing pains, resulting from not having testing part of the plan from the beginning
<slangasek> cyphermox: so, you do need a new shim-signed source, but the shim source should be a copy-package -b -e [...] of the old one
<santa_> slangasek: I know, that's something out of the radar in kubuntu development so far
<cyphermox> yeah yeah, I got that now
<santa_> I guess we could prepare something to work on that porperly for the next release
<slangasek> ginggs: what is the libpfm4 sync fixing?
<santa_> * properly
<slangasek> santa_: you should not plan on the release team making exceptions to let packages in to 16.10 that fail their tests
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [0.7.8-1-g3705bb5-0ubuntu1~16.04.3]
<santa_> slangasek: to be honest I didn't plan so much, I got git/ppa permissions very recently and I'm doing the best I can with what we have right now
<santa_> there are so much things to improve
-queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (yakkety-proposed) [2:9.0.0~rc2-0ubuntu1]
<slangasek> santa_: right; my point is, if these packages don't clear proposed-migration on their own merits, chances are they will not make it for release
-queuebot:#ubuntu-release- Unapproved: shim (yakkety-proposed/main) [0.9+1465500757.14a5905-0ubuntu1 => 0.8-0ubuntu2] (core) (sync)
<cyphermox> slangasek: ^ still looks wrong for the version number to be going down?
<cyphermox> -e lets me pick the version, not rename, unless i'm not using the right copy-package
<slangasek> cyphermox: oh, you're doing this directly on the archive?  I figured you would still stage it in a ppa so shim-signed could be built and the upgrade tested a bit before landing
<cyphermox> oh, sure, we can do that too
<infinity> Yeah, with shim-signed depending on shim, we can't really force a downgrade...
<cyphermox> my idea really had been to make it so we had 0.9somethingsomething.is.0.8 and not worry about upgrading/downgrading
<infinity> I don't suppose shim builds reproducibly? :P
<slangasek> infinity: we can "force" a downgrade of shim together with an upgrade of shim-signed; it won't work right for anyone who's been tracking yakkety pre-release but is better than nothing at this point
-queuebot:#ubuntu-release- Unapproved: accepted sahara [sync] (yakkety-proposed) [1:5.0.0~rc1-1]
<slangasek> infinity: reproducibly> nope sorry
<cyphermox> infinity: nope
<slangasek> it's close but not quite IIRC
<slangasek> and the toolchain has certainly changed since the last build
<cyphermox> well, especially now if I need to patch to make it build with gcc 5 or 6
<jderose> slangasek: i'm all for better than nothing :)
<infinity> slangasek: Yeah, toolchain's changed, but we could fudge that by building it in a PPA that matches.
<cyphermox> slangasek: want to reject that shim upload so i can do things better?
<slangasek> infinity: well, the whole thing is a hedge against MS not getting the signed binary back to us in time; diminishing returns on how perfect we make this
<slangasek> cyphermox: how are you going to make it better?
<cyphermox> testing the downgrade in a ppa?
<cyphermox> well, I suppose we don't care about shim, only shim-signed
<slangasek> cyphermox: it can sit in the queue until then :)
<slangasek> still the same binary when you're done ;)
<cyphermox> yep
<ginggs> slangasek: the libpfm4 update is for enabling support for the latest intel CPUs, there's a papi update i want to sync as well - it was a request from the debian maintainer
<Mirv> slangasek: robru: right, forgot about the removal. then again we discussed with apw that the upload is not very needed in yakkety anyway, as it was test related change only to please QA, and that yakkety should be already redirected towards overlay this week. there is new UITK already built and being tested now, wanting to get to that was the goal. it may or may not make sense to get into yakkety as
<Mirv> it has Qt 5.6 related changes, depend on how testing looks and time flies.
<slangasek> ginggs: well, this is a server-seeded package, dependency of s390-tools; looks to me like it needs a freeze exception and possibly sign-off from server team or xnox, no free pass for Debian maintainers :)
<ginggs> slangasek: np, i'll file an FFe
-queuebot:#ubuntu-release- Unapproved: accepted designate [source] (yakkety-proposed) [1:3.0.0~rc2-0ubuntu1]
<Mirv> slangasek: robru: but I agree it'd make sense to not allow UNAPPROVED status silos to be cleaned, since it removes the package which is probably never really wanted. should ve rejected first.
-queuebot:#ubuntu-release- Unapproved: accepted glance [source] (yakkety-proposed) [2:13.0.0~rc2-0ubuntu1]
<slangasek> Mirv: ok, then we're on the same page :) and you can always ping a release team member for expedited accept, this is preferable to queue breakage and I'm sure the release team will make time for you
<jderose> infinity: slangasek: cyphermox: does the package necessarily need to be rebuilt? i know with the differences in the metadata, the deb itself needs to be signed by the canonical archive key ultimately... but can that be done while retaining the exact same signed shim.efi binary used in xenial?
<infinity> jderose: The signed binary indeed can't (and won't) change.
<infinity> It's the unsigned package that's a bit trickier.
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (yakkety-proposed) [3:10.0.0~rc3-0ubuntu1]
<jderose> infinity: right
<slangasek> infinity, cyphermox: if it came down to it, technically we could reupload shim 0.8-0ubuntu2 source under 0.9+vomit~really.0.8, let it build a different binary, and bodge shim-signed to ignore the binary mismatch just this once
<slangasek> we would be no less source-compliant than usual
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (yakkety-proposed) [2:14.0.0~rc2-0ubuntu1]
<infinity> slangasek: Given the proper binary will continue to exist in xenial (which will outlive yakkety) and we can point to it in a one-liner in copyright or something, that would be fine by me.
<infinity> slangasek: I'd prefer not to break all yakkety->yakkety upgrades if we can work around it with minimal futzing.
<cyphermox> I don't mind either way, the Breaks/Replaces isn't very complicated either given there was only ever one version released with that bad shim.
<infinity> cyphermox: How would Breaks/Replaces help?
<infinity> cyphermox: apt won't let you downgrade without scary force options.
<infinity> And update-manager definitely won't.
<cyphermox> oh, nevermind, I was thinking of shim-signed itself
<cyphermox> but that doesn't need any downgrading.
<infinity> Right.
<infinity> So, I think Steve's suggestion is the best here, perhaps mixed with mine.
<infinity> Bump shim version, ignore the la la la binary mismatch in shim-signed, and add a small note that the shim-signed binary in that specific version is actually the one from xenial.
<infinity> (And build in a wily PPA if you're having toolchain issues, that's where the last shim built)
<cyphermox> well I already have things patched sufficiently to build in yakkety
<infinity> Mmkay.  Though if you didn't patch things and built in wily, it might be almost the same as what we had, ish. :P
-queuebot:#ubuntu-release- Unapproved: winff (yakkety-proposed/universe) [1.5.3-7ubuntu1 => 1.5.5-1] (no packageset) (sync)
<cyphermox> heh
<infinity> Patching things to build a binary we don't intent to use is just extra confusion.
<infinity> s/intent/intend/
<infinity> If the revert can be nothing but a changelog entry, I'd be happier.
-queuebot:#ubuntu-release- Unapproved: accepted winff [sync] (yakkety-proposed) [1.5.5-1]
<infinity> (which implies building in a wily PPA and copying, probably)
<slangasek> yeah, I'd rather see it built in wily and binary copied to yakkety, than source-patched or built with a different toolchain
<slangasek> this is all temporary regardless
<jderose> true
<infinity> Indeed.  Hopefully it's just a couple of hours of wasted time and we get a newer, shinier, less crap shim before release.
<infinity> Hopefully.
<slangasek> cyphermox: so, I think infinity wins this one, I'll drop the 0.8-0ubuntu2 from the queue and wait for your 0.9+vomit-really-0.8
<cyphermox> so, to reiterate; rebuild 0.8-0ubuntu2 named 0.9+1465500757.14a5905.is.0.8-0ubuntu1 in a wily PPA (with an extra changelog entry "revert to 0.8" on top of the changelog from 0.9) and copy?
<slangasek> yes
<cyphermox> wfm.
<slangasek> in a wily, devirt ppa
<infinity> s/0ubuntu1/0ubuntu2/ and yes.
<cyphermox> well
<infinity> We have a shim-prep PPA for this.
<infinity> canonical-foundations/shim
<cyphermox> that -0ubuntu1 there is the version of the upload, not the version of the previous shim.
<infinity> cyphermox: The ".is" confuses it a bit for me, but I won't be picky and reject if you think I'm wrong. :P
<cyphermox> infinity: yep, already use that, and the newer shim is there too.
<cyphermox> fair enough; s/is/really/
<cyphermox> or really.for.realz.
<infinity> cyphermox: No, no.  I don't mind "is", I meant that the is (or really) then implies the next string is the original version you're reverting to. :P
<infinity> And ubuntu1 and ubuntu2 weren't the same.
<infinity> So...
<cyphermox> well then it would have to be -0ubuntu2-0ubuntu1
<cyphermox> ;)
<infinity> Nah.
<infinity> Cause we'll never rev that version.
<infinity> If we do, something went extra wrong.
<cyphermox> yeah, given that I don't care what it is
<infinity> Anyhow.  Pointless bikeshedding.
<infinity> Go with the spirit of the plan, I won't block on the letter of my pednatic law. :P
<cyphermox>  0.9+1465500757.14a5905.really.is.0.8dash0ubuntu2.for.infinity-0ubuntu99 it is then.
<cyphermox> and I again reclaim my very-long-version-numbers title
<slangasek> I want my bikeshed to have points all over
<slangasek> like a flail
<jderose> haha. yeah, that's the keeper cyphermox :)
<ginggs> slangasek: libpfm4 + papi FFe filed LP: #1629989
<ubot5> Launchpad bug 1629989 in libpfm4 (Ubuntu) "FFe: Sync libpfm4 4.7.0+git30-gd422ba2-1 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1629989
<slangasek> I feel like balloons is trying to troll the release team into fixing bug #1629412 for him
<ubot5> bug 1629412 in golang-go.crypto (Ubuntu) "Please merge debian version of golang-golang-x-crypto-dev" [Undecided,New] https://launchpad.net/bugs/1629412
<slangasek> really, all he had to do was ask
-queuebot:#ubuntu-release- Unapproved: rejected shim [sync] (yakkety-proposed) [0.8-0ubuntu2]
<cyphermox> I can see this shim stuff just being totally useless and we'll have the signed new one tomorrow or something
<infinity> cyphermox: Better than the inverse scenario.
<cyphermox> have the new shim totally useless and do this tomorrow?
<infinity> :P
<cyphermox> > https://launchpad.net/~canonical-foundations/+archive/ubuntu/shim/+sourcepub/6978941/+listing-archive-extra
<infinity> Oh, hrm.  s/wily/vivid/ ?
<apw> cyphermox, ftbfs
 * cyphermox sighs
<lamont> hi
-queuebot:#ubuntu-release- Unapproved: ifupdown (yakkety-proposed/main) [0.8.13ubuntu2 => 0.8.13ubuntu3] (core)
<infinity> cyphermox: Copied it to vivid instead. :P
<lamont> ifupdown is me... can someone review and do the whacky-thump into -proposed?
<infinity> cyphermox: Lets see how that goes.
<cyphermox> infinity: I was about to do that, reaching for copy-package.
<infinity> cyphermox: You're too slow. :)
<lamont> sometimes, you two scare me
<cyphermox> so I've been told.
-queuebot:#ubuntu-release- Unapproved: ifupdown (xenial-proposed/main) [0.8.10ubuntu1.1 => 0.8.10ubuntu1.2] (core)
<infinity> lamont: Does that actually work...?
<lamont> infinity: verfiied on both xenial and yakkety
<lamont> and prior art
<infinity> lamont: /lib/lsb/init-functions contains some voodoo wherein running /etc/init.d/service if there's a matching systemd unit will run the unit instead, which leads me to believe you've created an infinite loop...
<infinity> But okay...
<infinity> Maybe it protects against that. :P
<lamont>  /lib/systemd/system/apparmor.service:ExecStop=/etc/init.d/apparmor stop
<santa_> slangasek: ok, I have looked @ kmbox abi break. I can justify why we can/should ignore that
<lamont> infinity: I don't know how the magic works, but it seems to
<jderose> cyphermox: is it possible to take the extact data.tar.xz file from the xenial build, just generate a new control.tar.gz and freshly sign thing whole thing up in .deb goodness?
<santa_> 1. it's true its an ABI break
<infinity> jderose: Not so much.
<santa_> 2. it's reverse dependencies are, if I'm not mistaken, just kdepim-runtime and kf5-messagelib
<infinity> cyphermox: Looks like the build in vivid worked, so hand-wavey la la la, we're on our way.
<cyphermox> yep, making shim-signed now
<jderose> infinity: wonder if it produced the exact same bits though
<infinity> jderose: I guarantee it doesn't.
<infinity> jderose: But we're not using that binary for anything, so refer back to "hand-wavey la la la".
<santa_> 3. kdepim-runtime and kf5-messagelib are a part of kde apps 16.04.3 and as such they are handled by our automation tools
<jderose> infinity: okay, gotcha. so is the plan just to place the xenial shim.efi properly on the ISO?
<santa_> 4. so kdepim-runtime and kf5-messagelib have a versioned build dependency on libkf5mbox-dev (>= 16.04.3~)
<infinity> jderose: More or less.
<cyphermox> jderose: not just on the iso, once we're done people will update and get the shim from xenial back.
<santa_> 5. therefore even if the abi was broken the reverse dependencies will get rebuilt against the latest version of the library and never the old one
<lamont> infinity: I'm seeing magic for upstart, but not for systemd
<jderose> cyphermox: which raises a question: in what scenarios (which package upgrades, etc) does the shim.efi file from the actual package get copied onto the ESP?
<santa_> slangasek: does it sound as a sane excuse to ignore that abi break? keep in mind that we could bump the abi version using our debian abi manager but that would force us to keep a delta with debian
<cyphermox> when you upgrade, grub-install gets triggered and will copy it.
<infinity> santa_: None of that is a sane reason to ignore an ABI break, and there also shouldn't be a delta with Debian.  If the ABI broke, it should be fixed everywhere, not just in Ubuntu.
<infinity> santa_: ABI tracking is about runtime dependencies, not build-time.
<infinity> santa_: If libfoo.so.1 no longer provides all the same symbols that libfoo.so.1 used to, it's not libfoo.so.1 anymore.
<infinity> lamont: There's magic somewhere...
<lamont> ok
<infinity> lamont: eg: http://paste.ubuntu.com/23271705/
<infinity> But maybe that magic only trips for automagic sysv-imported units.
<infinity> Though not sure how it would tell.
<lamont> what does /etc/init.d/exim4 look like?
<lamont> most of the upstart jobs had their guts replaced
<apw> infinity, it is in the init.d libraries at the top
<infinity> lamont: A normal init script, with /lib/lsb/init-functions included.
<infinity> apw: Yes, I know, lamont claimed there was no magic in /lib/lsb/init-functions though. :P
-queuebot:#ubuntu-release- Unapproved: lxd (yakkety-proposed/main) [2.3-0ubuntu6 => 2.3-0ubuntu7] (edubuntu, ubuntu-server)
<apw> oh heh, there cirtainly is :)
 * lamont didn't say there wasn't just that hecouldn't find it
<lamont> apw: how do apparmor and ebtables avoid the magic?
<infinity> Ahh.
<infinity> lamont: /lib/lsb/init-functions.d/40-systemd
<apw> that
 * lamont tears down networking on his desktop, just for testing.. back in a few
<lamont> infinity: that was ... interesting.  Please reject both uploads, and I'll get back to you
-queuebot:#ubuntu-release- Unapproved: golang-go.crypto (yakkety-proposed/main) [1:0.0~git20160607.0.77f4136-1ubuntu2 => 1:0.0~git20160824.0.351dc6a-1ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rejected ifupdown [source] (xenial-proposed) [0.8.10ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: rejected ifupdown [source] (yakkety-proposed) [0.8.13ubuntu3]
<slangasek> santa_: a versioned build-dependency does not solve the problem that, if the old kdepim-runtime or old libkf5messageviewer5 use the symbols that have been removed, an upgrade of libkf5mbox5 first will break these packages even though the dpkg database says everything's ok.  The library package name is a contract not to break the revdeps, which you can't retroactively revoke
<santa_> infinity, slangasek: ok, we are going to bump the soname using the abi manager then. we will get a libfoo5abi1 package for each abi break and a new symbols file
-queuebot:#ubuntu-release- Unapproved: accepted juju-core [source] (yakkety-proposed) [2.0~rc2-0ubuntu1.16.10.1]
<slangasek> santa_: that would satisfy the requirements nicely and get cleanly through the queue, thanks
<santa_> slangasek: ack
<infinity> (And this should happen in Debian too, it shouldn't be a delta)
<infinity> Err, unless the ABI break was due to Ubuntu-specific toolchain things.
<lamont> infinity: for giggles /etc/init.d/apparmor restart
<slangasek> santa_, infinity: so, drilling down into kmbox myself, the only symbol that's been dropped is actually a template instantiation: _ZN5KMBox4MBox13appendMessageERK14QSharedPointerIN5KMime7MessageEE@Base -> "KMBox::MBox::appendMessage(QSharedPointer<KMime::Message> const&)@Base"
<lamont> -tigernut(root) 312 : /etc/init.d/ebtables stop
<lamont> [ ok ] Stopping ebtables (via systemctl): ebtables.service.
<lamont> huh
<slangasek> santa_, infinity: in this case, it should *not* be an ABI break, and I should be able to rescue the version from the rejected queue (sorry for not noticing this before)
<infinity> slangasek: Oh, heh.  Yay C++?
<slangasek> infinity: a bit
<santa_> sgclark: hmm, I didn't check the symbols diff, but there was a file rename that suggested an ABI change not properly handled by upstream
<santa_> slangasek: â
<sgclark> oh whew
<santa_> sgclark: spurious ping, nvm
<santa_> sorry
<sgclark> hah np
<lamont> infinity: it looks like it just needs to have all of the Execs go there for happiness
<lamont> yay more testing
<infinity> lamont: That might well completely change what that service does...
<infinity> lamont: You might want to get some peer review from pitti regarding his systemd/networking house of cards before reuploading.
<slangasek> santa_: so, sorry to waste your time on this one.  Yes, I'm confident that this is not actually ABI-breaking.  Though also, the two reverse-deps of this library in the archive?  I can't find any evidence that they use the library...
<slangasek> santa_: ah oops, ignore the last, I was using wrong case
<santa_> slangasek: ftr, I just checked using a vm with our staging ppas and doing grep-aptavail -FDepends | grep ^Package: | sort -u
<santa_> slangasek: btw how you checked symbols differences, debdiff? something else?
<santa_> * how did you check
<slangasek> santa_: I looked at the debdiff for debian/lib*.symbols
<lamont> infinity: agreed
<lamont> though he's EU time, yes/
-queuebot:#ubuntu-release- Unapproved: accepted gnome-session [source] (yakkety-proposed) [3.20.2-1ubuntu6]
<santa_> k
<infinity> lamont: Generally, yes.
<lamont> yeah
-queuebot:#ubuntu-release- Unapproved: accepted python-taskflow [source] (yakkety-proposed) [2.3.0-1ubuntu1]
<slangasek> jbicha: gnome-online-accounts being in main doesn't seem to be a new thing, and yet there are a bunch of component-mismatches for its recommends that I don't remember being there before this week.  Since you TIL, do you want to look at whether realmd and dleyna-server should be demoted to Suggests?
<jbicha> slangasek: the binary g-o-a is in universe so I don't think that's necessary
<Laney> slangasek: I was fulfilling a sponsorship request and didn't at the time see a reason not to do so. If you have more knowledge, then you can reject and comment on the bug saying such: https://bugs.launchpad.net/ubuntu/+source/xml-core/+bug/1629832
<ubot5> Ubuntu bug 1629832 in xml-core (Ubuntu) "Sync xml-core 0.15 (main) from Debian unstable (main)" [Wishlist,New]
<jbicha> component-mismatches seems odd
<slangasek> jbicha: interesting, ok
<santa_> slangasek: I'm now inspecting kpimtextedit symbol changes from our git, this one looks like a real abi break
<xnox> slangasek, a good reason to split out /usr/sbin/cpacfstatsd into separate subpackage to push that dependency out.
<jbicha> like gnome-bluetooth recommends unity-control-center | gnome-control-center so I don't think g-c-c should show up there
 * xnox opens a bug report for z
<santa_> first symbol changed, for example
<nacc> Laney: slangasek: that sync is the discussion slangasek and I had last week -- it'd be fine to sync if someone has reviewed the upstream chagnes relative to the freeze. But I believe we've also fixed xml-core in yakkety sufficiently for now
<slangasek> jbicha: ah, g-c-c has added a Recommends: on g-o-a so you're probably right that this is a bug
<santa_> _ZN12KPIMTextEdit14RichTextEditor14handleShortcutEPK9QKeyEvent
<santa_> KPIMTextEdit::RichTextEditor::handleShortcut(QKeyEvent const*)
<santa_> â old one
<santa_> _ZN12KPIMTextEdit14RichTextEditor14handleShortcutEP9QKeyEvent
<santa_> KPIMTextEdit::RichTextEditor::handleShortcut(QKeyEvent*)
<santa_> â new one
<slangasek> Laney, nacc: thanks, rejecting for now and have followed up to the bug
<santa_> slangasek: so proceed to bump the abi with our abi manager for this one?
<slangasek> santa_: yes, that's clearly an ABI break (wouldn't be in C, but is in C++ because the symbol lookup would fail)
<jbicha> similar for lightdm > kylin-greeter
<santa_> allright
<slangasek> jbicha: yeah, I will take a stab at tricking germinate later to ignore these
<jbicha> lightdm recommends unity-greeter | lightdm-greeter
<jbicha> and kylin-greeter provides the virtual package lightdm-greeter
<jbicha> but unity-greeter provides that virtual package too
-queuebot:#ubuntu-release- Unapproved: rejected xml-core [sync] (yakkety-proposed) [0.15]
<santa_> slangasek: libkeduvocdocument seems an ABI break too looking at the diff from our git, proceed with our ABI manager (y/n)?
<nacc> slangasek: Laney: i think we can do that immediately with 17.04 though, and was planning on following up with that regardless
<slangasek> santa_: yes, libkeduvocdocument is a big ABI break
-queuebot:#ubuntu-release- Unapproved: accepted nova-lxd [source] (yakkety-proposed) [14.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: open-iscsi (yakkety-proposed/main) [2.0.873+git0.3b4b4500-14ubuntu4 => 2.0.873+git0.3b4b4500-14ubuntu5] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (yakkety-proposed) [2.3-0ubuntu7]
-queuebot:#ubuntu-release- New: accepted libkf5kipi [amd64] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5kipi [armhf] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5kipi [powerpc] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5kipi [s390x] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ubuntu-kylin-wizard [arm64] (yakkety-proposed) [16.10.0]
-queuebot:#ubuntu-release- New: accepted ubuntu-kylin-wizard [i386] (yakkety-proposed) [16.10.0]
-queuebot:#ubuntu-release- New: accepted ubuntu-kylin-wizard [ppc64el] (yakkety-proposed) [16.10.0]
-queuebot:#ubuntu-release- New: accepted libkf5kipi [arm64] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5kipi [ppc64el] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ubuntu-kylin-wizard [armhf] (yakkety-proposed) [16.10.0]
-queuebot:#ubuntu-release- New: accepted ubuntu-kylin-wizard [s390x] (yakkety-proposed) [16.10.0]
-queuebot:#ubuntu-release- New: accepted libkf5kipi [i386] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ubuntu-kylin-wizard [powerpc] (yakkety-proposed) [16.10.0]
-queuebot:#ubuntu-release- New: accepted ubuntu-kylin-wizard [amd64] (yakkety-proposed) [16.10.0]
<santa_> slangasek: same with kidentitymanagement, seems a clear abi break so we would manage it with the abi manager to get a new soname
<santa_> slangasek: about libkdeedu, it seems, indeed it's obsolete so I think we could skip that package and let the rejection win
<stgraber> slangasek: using sru-review for yakkety uploads now? :)
<stgraber> slangasek: got confused by the LP e-mail for a sec when I got it
<slangasek> stgraber: yeah, sorry, I have been using it because it's convenient for the reviews, then I usually 'n' out and manually accept - forgot to this time :)
<stgraber> ok :)
<infinity> slangasek: We could rename it queue-review and have it skip the SRU-specific bits if series == devel.
<slangasek> infinity: qiew-review plz
-queuebot:#ubuntu-release- Unapproved: rejected libpfm4 [sync] (yakkety-proposed) [4.7.0+git30-gd422ba2-1]
-queuebot:#ubuntu-release- New source: gce-compute-image-packages (yakkety-proposed/primary) [20160930-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted open-iscsi [source] (yakkety-proposed) [2.0.873+git0.3b4b4500-14ubuntu5]
-queuebot:#ubuntu-release- Unapproved: update-manager (yakkety-proposed/main) [1:16.10.5 => 1:16.10.6] (core)
-queuebot:#ubuntu-release- New: rejected gce-compute-image-packages [source] (yakkety-proposed) [20160826-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected gce-compute-image-packages [source] (yakkety-proposed) [20160930-0ubuntu1]
<infinity> Odd_Bloke: You around, re ^?
<infinity> Odd_Bloke: If not, slangasek should be forwarding you my rejection message. :P
<infinity> Odd_Bloke: Basically, you missed noting that the two bits in disk_expand/third_party/* are GPL, not Apache, and your attempt to force off old packages with "Conflicts" should be "Conflicts/Replaces" to hint the upgrade/removal.
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (yakkety-proposed) [1:16.10.6]
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (yakkety-proposed/main) [1:16.10.3 => 1:16.10.4] (core)
<slangasek> jbicha: gnome-online-accounts binary is pulled into main because of s390x only, where we have no unity-control-center package
<slangasek> killing off the desktop seed on s390x would fix this
<slangasek> but for the moment, worked around by dropping gnome-bluetooth from the seed on s390x
-queuebot:#ubuntu-release- Unapproved: casper (xenial-proposed/main) [1.376 => 1.376.1] (desktop-core, ubuntu-server)
<jbicha> slangasek: ok, that looks light lightdm's problem too (pulling in kylin-greeter) because unity-greeter isn't built on s390x
<jbicha> s/light/like
-queuebot:#ubuntu-release- Unapproved: gnome-chemistry-utils (yakkety-proposed/universe) [0.14.10-2 => 0.14.14-1] (mozilla) (sync)
#ubuntu-release 2016-10-04
<slangasek> jbicha: confirmed, working around that one too, thanks
<santa_> slangasek: about kde-runtime rik pointed in #kubuntu-devel that debian dropped the testsuite https://anonscm.debian.org/cgit/pkg-kde/applications/kde-runtime.git/commit/?id=bac71802bceec4c301df4695ccffab4bfc45db3a
<tsimonq2> santa_: now that Clive is a Kubuntu Dev let's see if he can upload ;)
<slangasek> santa_: oh, well, who needs tested code after all :/  Since Debian has dropped it, I would accept an upload here that did the same
<slangasek> santa_: or, for that matter, I can force-badtest this version and then you don't have to worry about reuploading for 16.10
<santa_> slangasek: thank you very much, I will try to fix tomorrow more stuff
<cyphermox> slangasek: do you want the reverted shim now? I tested it locally (though not tested for booting an image, but since it's a revert...) and I could "downgrade" fine.
<cyphermox> shim and shim-signed built in vivid from the PPA; and could use a quick review just in case I missed something
-queuebot:#ubuntu-release- Unapproved: im-config (yakkety-proposed/main) [0.29-1ubuntu14 => 0.29-1ubuntu15] (input-methods, kubuntu, personal-gunnarhj, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: language-selector (yakkety-proposed/main) [0.171 => 0.172] (core, personal-gunnarhj)
-queuebot:#ubuntu-release- New binary: libkf5libkdepim [i386] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5libkdepim [ppc64el] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5libkdepim [amd64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5libkdepim [armhf] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5libkdepim [arm64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5libkdepim [s390x] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5libkdepim [powerpc] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
<slangasek> cyphermox: yes please for reverted shim
-queuebot:#ubuntu-release- New: accepted libkf5libkdepim [amd64] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5libkdepim [armhf] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5libkdepim [powerpc] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5libkdepim [s390x] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5libkdepim [arm64] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5libkdepim [ppc64el] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5libkdepim [i386] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<slangasek> santa_, acheronuk: fwiw once kidentitymanagement and kpimtextedit packaging fixes are available in git, I'm happy to sponsor these through - and those two appear to be at the base of the current dep-wait tree
<slangasek> cyphermox: I see open-iscsi still fails its autopkgtest, it seems to be using a strange fixed path to the .deb that certainly doesn't exist
<slangasek> xnox: ubuntu-release-upgrader autopkgtest looks like it's probably regressed due to apt gpg changes; could you have a look please?
-queuebot:#ubuntu-release- Unapproved: snap-confine (xenial-proposed/main) [1.0.38-0ubuntu0.16.04.10 => 1.0.42-0ubuntu3~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5mailimporter [ppc64el] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5mailimporter [amd64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5mailimporter [i386] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5mailimporter [arm64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5mailimporter [armhf] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5mailimporter [s390x] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5mailimporter [powerpc] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
<slangasek> xnox: hur, ok nevermind, you already fixed this bug and it's in the queue - thanks ;)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (yakkety-proposed) [1:16.10.4]
-queuebot:#ubuntu-release- Unapproved: accepted im-config [source] (yakkety-proposed) [0.29-1ubuntu15]
-queuebot:#ubuntu-release- New: accepted libkf5mailimporter [amd64] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5mailimporter [armhf] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5mailimporter [powerpc] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5mailimporter [s390x] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5mailimporter [arm64] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5mailimporter [ppc64el] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5mailimporter [i386] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: audiocd-kio (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: rejected audiocd-kio [source] (yakkety-proposed) [4:16.04.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: audiocd-kio (yakkety-proposed/universe) [4:16.04.3-0ubuntu1 => 4:16.04.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted audiocd-kio [source] (yakkety-proposed) [4:16.04.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: qbittorrent (yakkety-proposed/universe) [3.3.6-1 => 3.3.6-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted qbittorrent [source] (yakkety-proposed) [3.3.6-1build1]
-queuebot:#ubuntu-release- Unapproved: ecasound (yakkety-proposed/universe) [2.9.1-7build3 => 2.9.1-7ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ecasound [source] (yakkety-proposed) [2.9.1-7ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted language-selector [source] (yakkety-proposed) [0.172]
-queuebot:#ubuntu-release- Unapproved: polyorb (yakkety-proposed/universe) [2.11~20140418-3.1build1 => 2.11~20140418-3.2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: wsjtx (yakkety-proposed/universe) [1.1.r3496-3.1build1 => 1.1.r3496-3.2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted polyorb [sync] (yakkety-proposed) [2.11~20140418-3.2]
-queuebot:#ubuntu-release- Unapproved: accepted wsjtx [sync] (yakkety-proposed) [1.1.r3496-3.2]
-queuebot:#ubuntu-release- Unapproved: morse2ascii (yakkety-proposed/universe) [0.2+dfsg-1ubuntu1 => 0.2+dfsg-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: cutecom (yakkety-proposed/universe) [0.22.0-2 => 0.30.3-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted cutecom [sync] (yakkety-proposed) [0.30.3-1]
-queuebot:#ubuntu-release- Unapproved: ecasound (yakkety-proposed/universe) [2.9.1-7ubuntu1 => 2.9.1-7ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xloadimage (yakkety-proposed/universe) [4.1-23build1 => 4.1-24] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted morse2ascii [sync] (yakkety-proposed) [0.2+dfsg-2]
-queuebot:#ubuntu-release- Unapproved: moka-icon-theme (yakkety-proposed/universe) [5.3.2-2 => 5.3.5-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ecasound [source] (yakkety-proposed) [2.9.1-7ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted xloadimage [sync] (yakkety-proposed) [4.1-24]
-queuebot:#ubuntu-release- Unapproved: accepted moka-icon-theme [sync] (yakkety-proposed) [5.3.5-1]
-queuebot:#ubuntu-release- New source: gce-compute-image-packages (yakkety-proposed/primary) [20160930-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: btfs (yakkety-proposed/universe) [2.4-1build2 => 2.4-1build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted btfs [source] (yakkety-proposed) [2.4-1build3]
<pitti> slangasek: there is some irritating bug in xenial's rabbitmq (I didn't see it under trusty) that there are queue items which are neither running nor introspectable any more, i. e. they are somehow attached to a worker already without already being accepted
<pitti> slangasek: i. e. the next few queue items which are going to be processed next aren't visible; I coudln't reproduce this locally yet to investigate
<pitti> (i. e. locally it works fine, but I tested it at a smaller scale)
-queuebot:#ubuntu-release- Unapproved: nfstrace (yakkety-proposed/universe) [0.4.2-2 => 0.4.2-2ubuntu1] (no packageset)
 * slangasek nods
-queuebot:#ubuntu-release- Unapproved: accepted nfstrace [source] (yakkety-proposed) [0.4.2-2ubuntu1]
<acheronuk> slangasek: thank you. that is appreciated with those ABI probs :)
-queuebot:#ubuntu-release- Unapproved: nvidia-prime (yakkety-proposed/main) [0.8.4 => 0.8.5] (ubuntu-desktop)
<slangasek> ^^ possible component-mismatch fix
-queuebot:#ubuntu-release- Unapproved: c2esp (yakkety-proposed/main) [27-2 => 27-3] (desktop-core) (sync)
-queuebot:#ubuntu-release- Unapproved: nfstrace (yakkety-proposed/universe) [0.4.2-2ubuntu1 => 0.4.2-2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted nfstrace [source] (yakkety-proposed) [0.4.2-2ubuntu2]
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [source] (yakkety-proposed) [20160930-0ubuntu2]
<Odd_Bloke> infinity: Ack on gce-compute-image-packages; thanks.
<infinity> Odd_Bloke: Looks like slangasek fixed you up.
<infinity> slangasek: I've read your nvidia-prime changelog about 7 times and it's still failing to make sense.
<infinity> slangasek: And which c-m node is this meant to be fixing?
<Odd_Bloke> infinity: So he did.
<Odd_Bloke> slangasek: Thanks!
-queuebot:#ubuntu-release- New binary: gce-compute-image-packages [amd64] (yakkety-proposed/none) [20160930-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: slingshot (yakkety-proposed/universe) [0.9-1 => 0.9-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted slingshot [source] (yakkety-proposed) [0.9-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: dpdk (yakkety-proposed/main) [16.07-0ubuntu4 => 16.07-0ubuntu5] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: mimedefang (yakkety-proposed/universe) [2.78-1ubuntu1 => 2.78-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted mimedefang [source] (yakkety-proposed) [2.78-1ubuntu2]
<bluesabre> Hello release team! Can we (Xubuntu) get an ack for these two bugs? We have some late landing artwork updates for Y, https://bugs.launchpad.net/ubuntu/+source/xubuntu-artwork/+bug/1629650, https://bugs.launchpad.net/ubuntu/+source/ubiquity-slideshow-ubuntu/+bug/1629648
<ubot5> Ubuntu bug 1629650 in xubuntu-artwork (Ubuntu) "[UIFe] New wallpaper for 16.10" [Undecided,New]
<ubot5> Ubuntu bug 1629648 in ubiquity-slideshow-ubuntu (Ubuntu) "[UIFe] Yak art for the Xubuntu slideshow" [Undecided,New]
-queuebot:#ubuntu-release- Unapproved: gnome-builder (yakkety-proposed/universe) [3.20.4-2 => 3.20.4-2ubuntu1] (desktop-extra)
<zyga> hello
<zyga> RAOF: hey
<zyga> RAOF: can you please upload snap-confine to proposed (it is in the queue)
<apw> zyga, you may have missed him, its pretty late over there
<zyga> arges: hey, maybe you can do it? :)
<apw> zyga, may just make sense to say you have a snap-confine which is urgent in (i assume) the xenial-proposed queue
<zyga> well, it is important so if we can get it into proposed and work on verification that would help a lot
<apw> zyga, ok i'll have a look
<zyga> thank you! :)
-queuebot:#ubuntu-release- Unapproved: gnome-shell (yakkety-proposed/universe) [3.20.3-1ubuntu2 => 3.20.4-0ubuntu1] (desktop-extra, edubuntu, mozilla, ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: accepted snap-confine [source] (xenial-proposed) [1.0.42-0ubuntu3~16.04.1]
<Odd_Bloke> infinity: Could you ack the gce-compute-image-packages binaries out of NEW?
-queuebot:#ubuntu-release- Unapproved: ubuntu-push (yakkety-proposed/main) [0.68+16.10.20160825.4-0ubuntu1 => 0.68+16.10.20161003-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: retext (yakkety-proposed/universe) [6.0.1-2 => 6.0.2-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted retext [sync] (yakkety-proposed) [6.0.2-2]
-queuebot:#ubuntu-release- Unapproved: gnome-control-center (yakkety-proposed/universe) [1:3.20.1-2ubuntu1 => 1:3.20.1-2ubuntu2] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: qtubuntu-gles (yakkety-proposed/universe) [0.63+16.10.20160831-0ubuntu1 => 0.63+16.10.20160928.1-0ubuntu1] (ubuntu-qt-packages) (sync)
-queuebot:#ubuntu-release- Unapproved: webbrowser-app (yakkety-proposed/main) [0.23+16.10.20160825-0ubuntu1 => 0.23+16.10.20160928-0ubuntu1] (ubuntu-desktop, ubuntu-qt-packages) (sync)
-queuebot:#ubuntu-release- Unapproved: qtubuntu (yakkety-proposed/main) [0.63+16.10.20160831-0ubuntu1 => 0.63+16.10.20160928.1-0ubuntu1] (ubuntu-qt-packages) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted qtubuntu-gles [sync] (yakkety-proposed) [0.63+16.10.20160928.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-push [sync] (yakkety-proposed) [0.68+16.10.20161003-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtubuntu [sync] (yakkety-proposed) [0.63+16.10.20160928.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted webbrowser-app [sync] (yakkety-proposed) [0.23+16.10.20160928-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (yakkety-proposed) [1:3.20.1-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [source] (yakkety-proposed) [3.20.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-builder [source] (yakkety-proposed) [3.20.4-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted dpdk [source] (yakkety-proposed) [16.07-0ubuntu5]
-queuebot:#ubuntu-release- Unapproved: gnome-session (yakkety-proposed/main) [3.20.2-1ubuntu6 => 3.20.2-1ubuntu7] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted c2esp [sync] (yakkety-proposed) [27-3]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-chemistry-utils [sync] (yakkety-proposed) [0.14.14-1]
<pitti> slangasek: your nvidia-prime change is curious indeed (not really obvious, but I trust that the reasoning is correct)
<pitti> slangasek: although I don't actually see gdm3 in component-mismatches{,-proposed}?
-queuebot:#ubuntu-release- Unapproved: freeorion (yakkety-proposed/universe) [0.4.6~RC1-1ubuntu1 => 0.4.6-1ubuntu1] (no packageset)
<bluesabre> hi pitti
<bluesabre> would you be willing to ack https://bugs.launchpad.net/ubuntu/+source/xubuntu-artwork/+bug/1629650 and https://bugs.launchpad.net/ubuntu/+source/ubiquity-slideshow-ubuntu/+bug/1629648 :)
<ubot5> Ubuntu bug 1629650 in xubuntu-artwork (Ubuntu) "[UIFe] New wallpaper for 16.10" [Undecided,New]
<ubot5> Ubuntu bug 1629648 in ubiquity-slideshow-ubuntu (Ubuntu) "[UIFe] Yak art for the Xubuntu slideshow" [Undecided,New]
-queuebot:#ubuntu-release- Unapproved: accepted freeorion [source] (yakkety-proposed) [0.4.6-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: im-config (yakkety-proposed/main) [0.29-1ubuntu15 => 0.29-1ubuntu16] (input-methods, kubuntu, personal-gunnarhj, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-session [source] (yakkety-proposed) [3.20.2-1ubuntu7]
<pitti> bluesabre: done
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [amd64] (yakkety-proposed) [20160930-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted im-config [source] (yakkety-proposed) [0.29-1ubuntu16]
<Laney> pitti / apw: could you remove indicator-bluetooth/s390x please? New builds are depwait due to url-dispatcher
<Laney> bileto won't let me publish - assuming it checks the archive (and this will be a problem at britney-time anyway)
-queuebot:#ubuntu-release- Unapproved: debian-installer (yakkety-proposed/main) [20101020ubuntu478 => 20101020ubuntu479.1] (core)
<apw> Laney, rigth same rules as for y-proposed
-queuebot:#ubuntu-release- Unapproved: php7.0 (yakkety-proposed/main) [7.0.8-3ubuntu2 => 7.0.8-3ubuntu3] (kubuntu, ubuntu-desktop, ubuntu-server)
<pitti> Laney: sure, can remove it
<Laney> merci
 * Laney will check bileto has noticed in a bit
 * Laney -> lunch
<pitti> done
-queuebot:#ubuntu-release- Unapproved: metacity (yakkety-proposed/main) [1:3.20.3-1ubuntu1 => 1:3.20.3-1ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accountsservice (yakkety-proposed/main) [0.6.40-2ubuntu15 => 0.6.42-0ubuntu1] (personal-gunnarhj, ubuntu-desktop)
<cyphermox> slangasek: open-iscsi> indeed, but that's not new, I was trying to fix it, and it didn't work out.
<cyphermox> that whole test is broken in fun ways
-queuebot:#ubuntu-release- Unapproved: python-testtools (yakkety-proposed/main) [1.8.1-0ubuntu1 => 1.8.1-0ubuntu2] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: shim-signed (yakkety-proposed/main) [1.20 => 1.21.2] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: shim (yakkety-proposed/main) [0.9+1465500757.14a5905-0ubuntu1 => 0.9+1465500757.14a5905.is.0.8-0ubuntu2] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: zfs-linux (xenial-proposed/main) [0.6.5.6-0ubuntu13 => 0.6.5.6-0ubuntu14] (no packageset)
 * apw will look at that zfs-linux ...
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (yakkety-proposed) [20101020ubuntu479.1]
<apw> does anyone object if i release the zfs-linux fix that is sitting in xe
<apw> xenial-proposed, it is teensy and not in core-functionality and has 5 days soak
-queuebot:#ubuntu-release- Unapproved: walinuxagent (yakkety-proposed/main) [2.1.5-0ubuntu3 => 2.1.5-0ubuntu4] (ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: unity-scope-click (yakkety-proposed/universe) [0.1.1+16.10.20160926.1-0ubuntu1 => 0.1.1+16.10.20161003-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted unity-scope-click [sync] (yakkety-proposed) [0.1.1+16.10.20161003-0ubuntu1]
<Odd_Bloke> That walinuxagent is a tiny fix requested by Microsoft for functionality that we don't enable by default; ACK appreciated.
-queuebot:#ubuntu-release- Unapproved: cupt (yakkety-proposed/universe) [2.9.5build1 => 2.9.8] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted cupt [sync] (yakkety-proposed) [2.9.8]
-queuebot:#ubuntu-release- Unapproved: lxc-android-config (yakkety-proposed/universe) [0.230+16.10.20160728-0ubuntu1 => 0.230+16.10.20161004-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted lxc-android-config [sync] (yakkety-proposed) [0.230+16.10.20161004-0ubuntu1]
<flocculant> pitti: thanks - did you notice there were 2 there from b.luesabre?
-queuebot:#ubuntu-release- Unapproved: kylin-greeter (yakkety-proposed/universe) [16.10.0 => 16.10.1] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: indicator-bluetooth (yakkety-proposed/main) [0.0.6+16.10.20160526-0ubuntu1 => 0.0.6+16.10.20161003-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: unity-settings-daemon (yakkety-proposed/main) [15.04.1+16.10.20160819-0ubuntu2 => 15.04.1+16.10.20161003-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: unity-control-center (yakkety-proposed/main) [15.04.0+16.10.20160705.1-0ubuntu3 => 15.04.0+16.10.20161003.1-0ubuntu1] (ubuntu-desktop) (sync)
<pitti> flocculant: no, I don't think so; I just saw the theme update one
<clivejo> hi, is there anyone on the release team free to do a bit of hand holding?
<slangasek> infinity, pitti: preferring gdm3 over lightdm is meant to try to get gnome-panel out of c-m because of the supported-hardware-desktop seed; but I realize now that maybe I didn't think through the pulling of gdm3 itself into the seed, hmm.  It seemed like a good idea at the time
<slangasek> infinity, pitti: I guess the other thing I could do, which feels wrong but could be more reliable, would be to seed lightdm in supported-desktop-hardware
<slangasek> infinity, pitti: not lightdm, but unity-greeter
<pitti> slangasek: I thought gnome-panel was due to indicator-applet, which is a recommends of indicator-datetime
<infinity> Isn't that the group we've been ignoring for years?
<infinity> As an obvious germinate bug.
<pitti> yes
<slangasek> pitti: it's because indicator-applet is an *alternative* recommends of indicator-datetime; I did some seed fiddling last night, and the only place it's left in germinate is the supported hardware desktop seed
-queuebot:#ubuntu-release- Unapproved: rejected nvidia-prime [source] (yakkety-proposed) [0.8.5]
<infinity> slangasek: Does supported-hardware-desktop perhaps just need a better dependency chain in STRUCTURE?
<slangasek> infinity: yeah, you've been ignoring it, but it has a tendency to balloon out from time to time and make the reports unreadable and I did some work beginning of the cycle to try to tame it; it's no longer showing up in the desktop seed and we should also be able to get it out of the supported-hardware-desktop seed
<slangasek> infinity: do you want supported-hardware-desktop to depend on desktop?
<slangasek> if so, then yes, that should fix
<slangasek> oh
<slangasek> but supported-hardware-desktop is in platform, and desktop is not there
<infinity> Yeah.
<infinity> And therein lies the problem.
 * pitti doesn't see any desktop-ish stuff in supported-hardware-desktop
<infinity> It is, indeed, a layering violation at work here if s-h-d is pulling in actual desktop things.
<pitti> oh, nvidia-settings?
<slangasek> pitti: nvidia-{361,340} are seeded by regexp, depend: nvidia-prime, depends: lightdm | gdm3
<pitti> ah
<pitti> dropping the recommends in indicator-datetime would be too evil?
<pitti> (to suggests:)
<slangasek> yes
<infinity> It would just pop up in another indicator.
<cjwatson> actual desktop things> right, that's why it isn't actually an obvious germinate bug despite looking like that at first
<infinity> They all have the same recommends.
<slangasek> because a) it's not just indicator-datetime, there's a passel of packages affected; b) it's an alternative recommends, and the problem is the picking of an indicator-renderer Provider other than the one we want
<pitti> so we preferrably recommend indicator-applet which we've stopped supporting many years ago..
<infinity> We could just move nvidia* from platform/supported to ubuntu/supported?
<cjwatson> Swathes of supported-hardware-desktop should possibly just move to ubuntu/supported-desktop-extra
<cjwatson> Which I think might be the right place
<pitti> i. e. nvidia-settings*?
<pitti> (the rest is drivers and CLI stuff)
<infinity> All the restricted bits, at least.
<pitti> wacom-tools doesn't even exist any more
<infinity> Basically, that whole last section.
<pitti> or i855-crt
<cjwatson> (ubuntu/supported-desktop-extra gets counted as a "desktop" seed for support duration purposes, ubuntu/supported doesn't; the distinction doesn't matter at the moment because they're both 5y for LTS, but might matter again in future)
<pitti> infinity: I think the drivers themselves should probably stay
<infinity> pitti: I'm not convinced it actually makes a high level difference where they live.
<infinity> It'll just fix the layering issues.
<infinity> And I'd rather all of it be in the same place, wherever that place is.
<infinity> So hunting for nvidia/fglrx isn't painful.
<pitti> ok, I buy that
<infinity> I'll make the change now, if someone else isn't already.
<infinity> And we can see what happens.
<pitti> cheers
<pitti> and we should probably reject the nvidia-prime upload?
-queuebot:#ubuntu-release- Unapproved: ubuntu-kylin-docs (yakkety-proposed/universe) [16.04.1 => 16.10.1] (ubuntukylin)
<pitti> ah, someone already did
 * pitti â dinner and then hot bath and bed, caught a conference flu last week :(
<infinity> And committed.
-queuebot:#ubuntu-release- Unapproved: nova (yakkety-proposed/main) [2:14.0.0~rc2-0ubuntu1 => 2:14.0.0~rc2-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: marble (yakkety-proposed/universe) [4:16.04.3-0ubuntu1 => 4:16.04.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: cloud-utils (yakkety-proposed/main) [0.29-0ubuntu4 => 0.29-0ubuntu5] (edubuntu, ubuntu-server)
<Odd_Bloke> Is there any way to tell exactly when something was archived to old-releases.u.c?  (I'm specifically interested in the utopic archives.)
<jbicha> Odd_Bloke: https://wiki.ubuntu.com/Releases ?
<Odd_Bloke> jbicha: vivid and wily are still on archive.u.c, so that's not a great guide. :)
<smoser> Odd_Bloke, its not a hard rule
<smoser> i think the guarantee is that it is after EOL
<xnox> Odd_Bloke, it's arbitrary. talk to infinity.
<slangasek> 2016-04-22 13:22:59.773811425 +0000
<slangasek> Odd_Bloke: ^^
<Odd_Bloke> slangasek: Thanks!
<slangasek> Odd_Bloke: that corresponds to when we were prepping the 16.04 release and needed to get them the hell out of the main directory so there was space on the mirror set
<slangasek> Odd_Bloke: sorry, it's been suggested that you may have been asking about the archive part of this rather than the images part of this, which gets a different answer
<slangasek> (which maybe I can also find)
<slangasek> Odd_Bloke: timestamp of 'dists' under http://old-releases.ubuntu.com/ubuntu/ is 28-Sep-2015, which would be the last time something was written to that directory, and the last thing written there should have been utopic I think?
-queuebot:#ubuntu-release- Unapproved: okteta (yakkety-proposed/universe) [4:15.12.3-0ubuntu4 => 4:16.04.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: python-cffi (yakkety-proposed/main) [1.7.0-1 => 1.7.0-1ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted php7.0 [source] (yakkety-proposed) [7.0.8-3ubuntu3]
-queuebot:#ubuntu-release- Unapproved: extra-cmake-modules (yakkety-proposed/universe) [5.26.0-0ubuntu1 => 5.26.0-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted metacity [source] (yakkety-proposed) [1:3.20.3-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: cloud-initramfs-tools (xenial-proposed/main) [0.27ubuntu1.1 => 0.27ubuntu1.2] (edubuntu, ubuntu-server)
<lamont> who is my favorite AA today?
<lamont> cloud-initramfs-tools for xenial and yakkety (inbound) proposed, pls?
-queuebot:#ubuntu-release- Unapproved: cloud-initramfs-tools (yakkety-proposed/main) [0.29ubuntu2 => 0.29ubuntu3] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted accountsservice [source] (yakkety-proposed) [0.6.42-0ubuntu1]
<slangasek> lamont: will look as soon as lp gives me a debdiff
<lamont> ta
<lamont> the yakkety uplaod is a forwardport of the xenial diff
<lamont> and definitely "less broken" :/
<lamont> actually, reject both?
 * lamont just realized why the diff was so big
<slangasek> lamont: done
<lamont> ta
-queuebot:#ubuntu-release- Unapproved: rejected cloud-initramfs-tools [source] (xenial-proposed) [0.27ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: rejected cloud-initramfs-tools [source] (yakkety-proposed) [0.29ubuntu3]
-queuebot:#ubuntu-release- Unapproved: sphinx (yakkety-proposed/main) [1.4.6-1 => 1.4.8-1] (edubuntu, ubuntu-server) (sync)
<dobey> hmm, if my package is in -proposed for > 4 hrs, why would it not be showing up on update_excuses page, and nothing related on autopkgtests page?
<dobey> i woner if the main component update caused something to go out of sync perhaps?
<slangasek> dobey: in proposed, or in the unapproved queue?
<slangasek> also, I noticed component-mismatches reports did not regenerate for 4 hours so possibly snakefruit is angry
<dobey> slangasek: proposed
<dobey> slangasek: a unity-scope-click silo was published this morning, and then you did the main component update for it ~1 hr ago, and lp says "latest upload" is the older version now, but shows the newer version still in proposed
<smoser> can i get someone to approve https://launchpad.net/ubuntu/yakkety/+queue?queue_state=1&queue_text=cloud-utils
<dobey> hmm, i guess snakefruit could be angry if that has anything to do with the update_excuses
<slangasek> dobey: you can see from http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html header that the last regen was at 13:35
<slangasek> so that's quite old
<dobey> indeed
<dobey> hmm
<slangasek> poking now
<slangasek> I see a britney process currently running and nothing else putting the machine under load
<slangasek> eh, rather, I see germinate running
<slangasek> ok, now I see both ;)
<slangasek> and these both started running in the past 5 minutes
<slangasek> so, britney is going to be slow right now because of (at least) the kde cloggage.  But not /this/ slow
<dobey> hmm
<dobey> http://autopkgtest.ubuntu.com/running shows empty queues
<dobey> so i guess maybe something is breaking things?
<slangasek> the queues are filled by britney
<slangasek> so if britney is only running once every 4 hours, autopkgtest has probably just drained them
<clivejo> who deals with the sync'ing of packages with Debian?
<slangasek> clivejo: the Ubuntu Developers
<slangasek> PROPOSED_MIGRATION_SERIES="precise trusty vivid wily xenial yakkety"
<slangasek> PROPOSED_MIGRATION_SERIES_RTM="14.09 14.09-factory"
<slangasek> infinity: ^^ we should probably prune wily from this at least, yes?  and drop the RTM ones
<slangasek> (and maybe also prune vivid?)
<infinity> slangasek: wily for sure.  We still use proposed for vivid for the kernel SRUs until told otherwise.
<slangasek> hmm we have a bug in p-m handling, we check if the release has changed before running proposed-migration, but that means if the autopkgtest results have changed but the archive has not, we don't re-run
-queuebot:#ubuntu-release- Unapproved: ark (yakkety-proposed/universe) [4:16.04.3a-0ubuntu1 => 4:16.04.3a-0ubuntu2] (kubuntu)
<apw> slangasek, i thought we had a "Test in progress" grep on the previous results to override that
<slangasek> apw: oh, you're quite right
<slangasek> I find archive-reports a very hard to read script :)
<infinity> It makes perfect sense if you mash Colin's brain together with Martin's, and then sprinkle some of mine on top.
<infinity> Also a lovely spring meal.
<dobey> hmm
<slangasek> brain sprinkles always get stuck in my teeth
<dobey> if britney is taking 4 hours to run, and last started ~35 min ago, shouldn't update_excuses.html show an update time of ~40 min ago or so?
-queuebot:#ubuntu-release- Unapproved: accepted shim-signed [sync] (yakkety-proposed) [1.21.2]
-queuebot:#ubuntu-release- Unapproved: accepted shim [sync] (yakkety-proposed) [0.9+1465500757.14a5905.is.0.8-0ubuntu2]
<slangasek> dobey: I don't yet /know/ that it was taking 4h to run; I only know that the last results were 4h+ ago, and that a new run started at 16:40 UTC
<dobey> ok. i'm just trying to understand what's keeping my package in proposed. am a little worried about the impending freeze, and have another fix i need to try to get in before freeze
<slangasek> yeah, this looks like p-m is just dying
<dobey> :-/
<slangasek> hah, infinity's seed change did it
<slangasek> http://paste.ubuntu.com/23276418/
<infinity> I broke the world?
<dobey> so it appears
<slangasek> infinity: just britney's world
<infinity> slangasek: You sure that's me, and not the unity8 promotions?
<clivejo> slangasek: would you have time to help with something?
<slangasek> infinity: not certain, but indicator-renderer points that way
-queuebot:#ubuntu-release- Unapproved: accepted cloud-utils [source] (yakkety-proposed) [0.29-0ubuntu5]
-queuebot:#ubuntu-release- Unapproved: bind9 (yakkety-proposed/main) [1:9.10.3.dfsg.P4-10.1 => 1:9.10.3.dfsg.P4-10.1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (yakkety-proposed/main) [1.370 => 1.371] (core)
<slangasek> infinity: ok, no it's not related to the seed change, britney is just getting very angry about the unity8 binary in yakkety-proposed (?)
<slangasek> E: [Tue Oct  4 18:05:10 2016] - Mismatch found unity8 8.14+16.10.20160922-0ubuntu2 arm64 differs
<slangasek> I: [Tue Oct  4 18:05:10 2016] -  ... ARCHITECTURE arm64 != all
-queuebot:#ubuntu-release- Unapproved: systemd (xenial-proposed/main) [229-4ubuntu10 => 229-4ubuntu11] (core)
-queuebot:#ubuntu-release- Unapproved: lxd (yakkety-proposed/main) [2.3-0ubuntu7 => 2.4-0ubuntu1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: licenseutils (yakkety-proposed/universe) [0.0.7-7 => 0.0.7-8] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted licenseutils [sync] (yakkety-proposed) [0.0.7-8]
<slangasek> Section: faux
<slangasek> Version: 8.14+16.10.20160922-0ubuntu2
<slangasek> Architecture: all
<slangasek> Package: unity8
<slangasek> wut
<slangasek> dobey: ^^ ok, took a bit, but I should have this sorted now for the next run, sorry it took so long
<dobey> slangasek: ok, thanks!
<slangasek> (No idea why, when the fauxpage input lists architectures, the output is Architecture: all; but fixed now anyway by dropping arm64 from the list of archs it generates for)
-queuebot:#ubuntu-release- Unapproved: accepted python-testtools [source] (yakkety-proposed) [1.8.1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: cloud-init (yakkety-proposed/main) [0.7.8-11-g02f6c4b-0ubuntu1 => 0.7.8-14-g94fd35e-0ubuntu1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (yakkety-proposed) [2.1.5-0ubuntu4]
<slangasek> cyphermox: well, shim went through rather quickly, I guess we have no autopkgtests there :)
-queuebot:#ubuntu-release- Unapproved: accepted kylin-greeter [source] (yakkety-proposed) [16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted indicator-bluetooth [sync] (yakkety-proposed) [0.0.6+16.10.20161003-0ubuntu1]
<lamont> slangasek: is there an open-iscsi - 2.0.873+git0.3b4b4500-14ubuntu4  in the unaccepted queue?
-queuebot:#ubuntu-release- Unapproved: cloud-initramfs-tools (xenial-proposed/main) [0.27ubuntu1.1 => 0.27ubuntu1.2] (edubuntu, ubuntu-server)
 * lamont is doing one last test before he asks for c-i-t
-queuebot:#ubuntu-release- Unapproved: libkeduvocdocument (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu2] (kubuntu)
<slangasek> infinity, cjwatson, pitti, jbicha: hey lookie, no more gnome-panel on c-m
-queuebot:#ubuntu-release- Unapproved: accepted unity-control-center [sync] (yakkety-proposed) [15.04.0+16.10.20161003.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: maas (yakkety-proposed/main) [2.0.0+bzr5189-0ubuntu1 => 2.1.0~beta1+bzr5433-0ubuntu1] (ubuntu-server)
<cyphermox> slangasek: I will read that as "please make autopkgtests for shim" and add it to my todo list :)
<cyphermox> fwiw, it was planned, and I have code that might work to do boot tests with shim, that might allow us to catch (too late, since it's gated on signage, but whatever) other issues in booting CDs and whatnot
<cyphermox> lamont: open-iscsi is a pita
<tsimonq2> slangasek: hello. one of the packages we recently uploaded, minuet, is in the NEW queue but is part of the 16.04.3 release of KDE Applications. could that be approved, please?
 * tsimonq2 has Kubuntu hat on
-queuebot:#ubuntu-release- Unapproved: libwebp (yakkety-proposed/main) [0.5.1-2 => 0.5.1-2ubuntu1] (desktop-core, ubuntu-server)
<slangasek> tsimonq2: NEW queue is a bit down the priority list at the moment, but I have my eye on it
<tsimonq2> slangasek: thank you :)
-queuebot:#ubuntu-release- Unapproved: accepted unity-settings-daemon [sync] (yakkety-proposed) [15.04.1+16.10.20161003-0ubuntu1]
<lamont> is there a cloud-init in the unapproved queue?
<lamont> and can I have cloud-initramfs-tools 0.27ubuntu1.2 for xenial-proposed pls?
<lamont> cyphermox: that it is
<tsimonq2> slangasek: oof, ok, I think I'm going to retract that. bug 1584310 needs to be fixed before it'll build and the fix for that is in Experimental. so unless you absolutely feel confident syncing from Experimental (which sounds crazy, I know) then it can't be done.
<ubot5> bug 1584310 in libdrumstick (Ubuntu) "New upstream release available" [Undecided,New] https://launchpad.net/bugs/1584310
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-kylin-docs [source] (yakkety-proposed) [16.10.1]
-queuebot:#ubuntu-release- Unapproved: loganalyzer (yakkety-proposed/universe) [3.6.6+dfsg-3 => 3.6.6+dfsg-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted loganalyzer [source] (yakkety-proposed) [3.6.6+dfsg-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: xubuntu-artwork (yakkety-proposed/universe) [16.10.0 => 16.10.1] (xubuntu)
<flexiondotorg> infinity, I'm just gearing up to sync all of MATE 1.16 from Debian unstable to Yakkety.
<flexiondotorg> This replaces the MATE 1.15.x development snapshots with stable releases.
<flexiondotorg> It is a bunch of package that will need accepting, any preference how to communicate that?
<wxl> flexiondotorg: yeah. with a stack of unmarked bills.
<flexiondotorg> lulz :-)
<wxl> XD
<tsimonq2> flexiondotorg: Kubuntu tried that last week. there's still things in the queue...
<flexiondotorg> Sqeeky bum time.
<acheronuk> tsimonq2: how many packages in mate?
<flexiondotorg> acheronuk, Sec...
<flexiondotorg> 38
<acheronuk> kubuntu = 300+
<flexiondotorg> OK, not such a big deal then :-)
<wxl> yeah tsimonq2 neener neener neener
<acheronuk> not that size is always a reliable indication......
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (yakkety-proposed) [2:14.0.0~rc2-0ubuntu2]
<flexiondotorg> slangasek, I just attempted a sync from Debian unstable to Yakkety and got this:
<flexiondotorg> syncpackage: D: Source package mate-common is temporarily blacklisted (blacklisted_current).
<flexiondotorg> This is the mate-common versions in the sync:
<flexiondotorg> mate-common -> yakkety/Release: current version 1.15.1-0ubuntu1, new version 1.16.0-1
<flexiondotorg> Is that blacklisting message because I want to sync over a version with 0ubuntu1 suffix?
<flexiondotorg> slangasek, Disregard above. All sorted.
-queuebot:#ubuntu-release- Unapproved: accepted marble [source] (yakkety-proposed) [4:16.04.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: mate-common (yakkety-proposed/universe) [1.15.1-0ubuntu1 => 1.16.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-desktop (yakkety-proposed/universe) [1.15.1-0ubuntu1 => 1.16.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-user-guide (yakkety-proposed/universe) [1.15.0-0ubuntu1 => 1.16.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: libmatekbd (yakkety-proposed/universe) [1.15.0-0ubuntu1 => 1.16.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: libmatemixer (yakkety-proposed/universe) [1.15.0-0ubuntu1 => 1.16.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: libmateweather (yakkety-proposed/universe) [1.15.1-0ubuntu1 => 1.16.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-icon-theme (yakkety-proposed/universe) [1.15.0-0ubuntu1 => 1.16.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: caja (yakkety-proposed/universe) [1.15.4-0ubuntu1 => 1.16.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-polkit (yakkety-proposed/universe) [1.15.0-0ubuntu1 => 1.16.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: marco (yakkety-proposed/universe) [1.15.0-0ubuntu1 => 1.16.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-settings-daemon (yakkety-proposed/universe) [1.15.1-0ubuntu1 => 1.16.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-menus (yakkety-proposed/universe) [1.15.0-0ubuntu1 => 1.16.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-session-manager (yakkety-proposed/universe) [1.15.0-0ubuntu1 => 1.16.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-backgrounds (yakkety-proposed/universe) [1.15.0-0ubuntu1 => 1.16.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-panel (yakkety-proposed/universe) [1.15.1-0ubuntu1 => 1.16.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-notification-daemon (yakkety-proposed/universe) [1.15.1-0ubuntu1 => 1.16.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-control-center (yakkety-proposed/universe) [1.15.2-0ubuntu1 => 1.16.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-screensaver (yakkety-proposed/universe) [1.15.0-0ubuntu1 => 1.16.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-media (yakkety-proposed/universe) [1.15.0-0ubuntu1 => 1.16.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-power-manager (yakkety-proposed/universe) [1.15.1-0ubuntu1 => 1.16.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-system-monitor (yakkety-proposed/universe) [1.15.0-0ubuntu1 => 1.16.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: atril (yakkety-proposed/universe) [1.15.3-0ubuntu1 => 1.16.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: caja-dropbox (yakkety-proposed/multiverse) [1.15.0-0ubuntu1 => 1.16.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: engrampa (yakkety-proposed/universe) [1.15.1-0ubuntu1 => 1.16.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: caja-extensions (yakkety-proposed/universe) [1.15.0-0ubuntu1 => 1.16.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: eom (yakkety-proposed/universe) [1.15.1-0ubuntu1 => 1.16.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-icon-theme-faenza (yakkety-proposed/universe) [1.15.1+dfsg1-0ubuntu1 => 1.16.0+dfsg1-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-applets (yakkety-proposed/universe) [1.15.2-0ubuntu1 => 1.16.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-indicator-applet (yakkety-proposed/universe) [1.15.1-0ubuntu1 => 1.16.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-netbook (yakkety-proposed/universe) [1.15.2-0ubuntu1 => 1.16.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-terminal (yakkety-proposed/universe) [1.15.1-0ubuntu1 => 1.16.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-sensors-applet (yakkety-proposed/universe) [1.15.0-0ubuntu1 => 1.16.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-user-share (yakkety-proposed/universe) [1.15.1-0ubuntu1 => 1.16.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-utils (yakkety-proposed/universe) [1.15.1-0ubuntu1 => 1.16.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: mozo (yakkety-proposed/universe) [1.15.1-0ubuntu1 => 1.16.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: pluma (yakkety-proposed/universe) [1.15.2-0ubuntu1 => 1.16.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: python-caja (yakkety-proposed/universe) [1.15.0-0ubuntu1 => 1.16.0-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-desktop-environment (yakkety-proposed/universe) [1.15.0+0ubuntu1 => 1.16.0+1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted okteta [source] (yakkety-proposed) [4:16.04.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted python-cffi [source] (yakkety-proposed) [1.7.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (xenial-proposed) [229-4ubuntu11]
-queuebot:#ubuntu-release- Unapproved: accepted extra-cmake-modules [source] (yakkety-proposed) [5.26.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted xdg-utils [source] (xenial-proposed) [1.1.1-1ubuntu1.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted appstream-glib [source] (xenial-proposed) [0.5.13-1ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted ark [source] (yakkety-proposed) [4:16.04.3a-0ubuntu2]
#ubuntu-release 2016-10-05
-queuebot:#ubuntu-release- Unapproved: accepted bind9 [source] (yakkety-proposed) [1:9.10.3.dfsg.P4-10.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libkeduvocdocument [source] (yakkety-proposed) [4:16.04.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (yakkety-proposed) [1.371]
-queuebot:#ubuntu-release- New binary: libkeduvocdocument [amd64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkeduvocdocument [ppc64el] (yakkety-proposed/universe) [4:16.04.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkeduvocdocument [i386] (yakkety-proposed/universe) [4:16.04.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (yakkety-proposed) [2.4-0ubuntu1]
-queuebot:#ubuntu-release- New binary: libkeduvocdocument [powerpc] (yakkety-proposed/universe) [4:16.04.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkeduvocdocument [s390x] (yakkety-proposed/universe) [4:16.04.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkeduvocdocument [arm64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkeduvocdocument [armhf] (yakkety-proposed/universe) [4:16.04.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: loganalyzer (xenial-proposed/universe) [3.6.6+dfsg-2ubuntu1 => 3.6.6+dfsg-2ubuntu1.1] (no packageset)
<slangasek> smoser: cloud-init> I see there are build-time tests; what other validation does this get, to be sure we're not breaking things a week before release?
-queuebot:#ubuntu-release- Unapproved: python-pbr (yakkety-proposed/main) [1.10.0-0ubuntu2 => 1.10.0-0ubuntu3] (ubuntu-desktop, ubuntu-server)
<smoser> slangasek, there isnt much :-(.
<smoser> we are working on getting more in plae.
-queuebot:#ubuntu-release- Unapproved: curtin (xenial-proposed/main) [0.1.0~bzr399-0ubuntu1~16.04.1 => 0.1.0~bzr425-0ubuntu1~16.04.1] (ubuntu-server)
<smoser> place.
<smoser> the two non-bug changes shoudl be safe enough.
<smoser> my primary argument for cloud-init upload at this point revolves around "pitti suggested".
<smoser> i'll talk to pitti some tomorrow and get some testing done on it manually.
-queuebot:#ubuntu-release- Unapproved: firebird2.5 (yakkety-proposed/universe) [2.5.6.27020.ds4-1ubuntu1 => 2.5.6.27020.ds4-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted firebird2.5 [sync] (yakkety-proposed) [2.5.6.27020.ds4-2]
-queuebot:#ubuntu-release- Unapproved: fldiff (yakkety-proposed/universe) [1.1+0-3 => 1.1+0-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted fldiff [sync] (yakkety-proposed) [1.1+0-4]
-queuebot:#ubuntu-release- Unapproved: libjna-java (yakkety-proposed/universe) [4.2.2-1 => 4.2.2-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libjna-java [sync] (yakkety-proposed) [4.2.2-2]
-queuebot:#ubuntu-release- Unapproved: libuser (yakkety-proposed/universe) [1:0.62~dfsg-0.1ubuntu1 => 1:0.62~dfsg-0.1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted libuser [source] (yakkety-proposed) [1:0.62~dfsg-0.1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: fwts (yakkety-proposed/universe) [16.09.00-0ubuntu1 => 16.09.00-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: openafs (yakkety-proposed/universe) [1.6.18.3-1 => 1.6.18.3-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted fwts [source] (yakkety-proposed) [16.09.00-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted openafs [sync] (yakkety-proposed) [1.6.18.3-2]
-queuebot:#ubuntu-release- Unapproved: python-utmp (yakkety-proposed/universe) [0.8.2 => 0.8.3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-utmp [sync] (yakkety-proposed) [0.8.3]
-queuebot:#ubuntu-release- Unapproved: tkgate (yakkety-proposed/universe) [2.0~b10-4ubuntu2 => 2.0~b10-5ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted tkgate [source] (yakkety-proposed) [2.0~b10-5ubuntu1]
-queuebot:#ubuntu-release- Unapproved: runit (yakkety-proposed/universe) [2.1.2-8ubuntu1 => 2.1.2-8ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted runit [source] (yakkety-proposed) [2.1.2-8ubuntu2]
-queuebot:#ubuntu-release- Unapproved: pidgin (yakkety-proposed/universe) [1:2.10.12-0ubuntu7 => 1:2.10.12-0ubuntu8] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ubuntu-push-qml (yakkety-proposed/universe) [0.1+15.10.20150826.1-0ubuntu1 => 0.1+15.10.20150826.1-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-push-qml [source] (yakkety-proposed) [0.1+15.10.20150826.1-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted libkeduvocdocument [amd64] (yakkety-proposed) [4:16.04.3-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted libkeduvocdocument [armhf] (yakkety-proposed) [4:16.04.3-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted libkeduvocdocument [powerpc] (yakkety-proposed) [4:16.04.3-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted libkeduvocdocument [s390x] (yakkety-proposed) [4:16.04.3-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted libkeduvocdocument [arm64] (yakkety-proposed) [4:16.04.3-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted libkeduvocdocument [ppc64el] (yakkety-proposed) [4:16.04.3-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted libkeduvocdocument [i386] (yakkety-proposed) [4:16.04.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted pidgin [source] (yakkety-proposed) [1:2.10.12-0ubuntu8]
-queuebot:#ubuntu-release- Unapproved: gnome-backgrounds (yakkety-proposed/universe) [3.22.0-2 => 3.22.1-1] (desktop-extra, ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: rygel (yakkety-proposed/universe) [0.32.0-1 => 0.32.0-2] (desktop-extra) (sync)
-queuebot:#ubuntu-release- Unapproved: open-iscsi (yakkety-proposed/main) [2.0.873+git0.3b4b4500-14ubuntu3 => 2.0.873+git0.3b4b4500-14ubuntu6] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: mpfr4 (yakkety-proposed/main) [3.1.4-2 => 3.1.5-1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: xml-core (yakkety-proposed/main) [0.13+nmu2ubuntu1 => 0.15] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-backgrounds [sync] (yakkety-proposed) [3.22.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted open-iscsi [source] (yakkety-proposed) [2.0.873+git0.3b4b4500-14ubuntu6]
-queuebot:#ubuntu-release- Unapproved: accepted rygel [sync] (yakkety-proposed) [0.32.0-2]
-queuebot:#ubuntu-release- Unapproved: accepted mpfr4 [sync] (yakkety-proposed) [3.1.5-1]
-queuebot:#ubuntu-release- Unapproved: accepted xml-core [sync] (yakkety-proposed) [0.15]
-queuebot:#ubuntu-release- Unapproved: accepted python-pbr [source] (yakkety-proposed) [1.10.0-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted libwebp [source] (yakkety-proposed) [0.5.1-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted xubuntu-artwork [source] (yakkety-proposed) [16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted sphinx [sync] (yakkety-proposed) [1.4.8-1]
<pitti> slangasek: awesome!
<pitti> fun, now we only have recommends there
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (yakkety-proposed) [0.7.8-14-g94fd35e-0ubuntu1]
<pitti> smoser, slangasek: ah, the cloud-init diff is almost exclusively documentation changes, plus one test fix and the before=, so LGTM
-queuebot:#ubuntu-release- Unapproved: rejected maas [source] (yakkety-proposed) [2.1.0~beta1+bzr5433-0ubuntu1]
<pitti> flexiondotorg: the whole mate stack is obviously not something which we can diff-review sanely, we can pretty much just take your word (and britney's) for it; how much has this been tested?
<pitti> ^ MaaS rejection: replacing stable 2.0 with beta 2.1 a week before release, no FFE bug ref, pinged roaksoax in #u-devel
-queuebot:#ubuntu-release- Unapproved: accepted golang-go.crypto [source] (yakkety-proposed) [1:0.0~git20160824.0.351dc6a-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: lintian (yakkety-proposed/main) [2.5.45ubuntu1 => 2.5.48] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: sucrack (yakkety-proposed/universe) [1.2.3-2ubuntu1 => 1.2.3-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted sucrack [sync] (yakkety-proposed) [1.2.3-3]
-queuebot:#ubuntu-release- Unapproved: opencv (yakkety-proposed/universe) [2.4.9.1+dfsg-2 => 2.4.9.1+dfsg-2.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted lintian [sync] (yakkety-proposed) [2.5.48]
-queuebot:#ubuntu-release- Unapproved: accepted atril [sync] (yakkety-proposed) [1.16.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted caja-extensions [sync] (yakkety-proposed) [1.16.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted eom [sync] (yakkety-proposed) [1.16.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-applets [sync] (yakkety-proposed) [1.16.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-control-center [sync] (yakkety-proposed) [1.16.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-icon-theme-faenza [sync] (yakkety-proposed) [1.16.0+dfsg1-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-media [sync] (yakkety-proposed) [1.16.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-netbook [sync] (yakkety-proposed) [1.16.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-panel [sync] (yakkety-proposed) [1.16.0-1]
<flocculant> pitti: bug 1629648 was the other we were looking for :)
<ubot5> bug 1629648 in ubiquity-slideshow-ubuntu (Ubuntu) "[UIFe] Yak art for the Xubuntu slideshow" [Undecided,New] https://launchpad.net/bugs/1629648
-queuebot:#ubuntu-release- Unapproved: accepted mate-screensaver [sync] (yakkety-proposed) [1.16.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted caja-dropbox [sync] (yakkety-proposed) [1.16.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted marco [sync] (yakkety-proposed) [1.16.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-desktop-environment [sync] (yakkety-proposed) [1.16.0+1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-menus [sync] (yakkety-proposed) [1.16.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-power-manager [sync] (yakkety-proposed) [1.16.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-session-manager [sync] (yakkety-proposed) [1.16.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-system-monitor [sync] (yakkety-proposed) [1.16.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-user-share [sync] (yakkety-proposed) [1.16.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted mozo [sync] (yakkety-proposed) [1.16.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted pluma [sync] (yakkety-proposed) [1.16.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted engrampa [sync] (yakkety-proposed) [1.16.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-indicator-applet [sync] (yakkety-proposed) [1.16.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-sensors-applet [sync] (yakkety-proposed) [1.16.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-terminal [sync] (yakkety-proposed) [1.16.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted opencv [sync] (yakkety-proposed) [2.4.9.1+dfsg-2.1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-backgrounds [sync] (yakkety-proposed) [1.16.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-settings-daemon [sync] (yakkety-proposed) [1.16.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted python-caja [sync] (yakkety-proposed) [1.16.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-notification-daemon [sync] (yakkety-proposed) [1.16.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-utils [sync] (yakkety-proposed) [1.16.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted caja [sync] (yakkety-proposed) [1.16.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted libmatemixer [sync] (yakkety-proposed) [1.16.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-common [sync] (yakkety-proposed) [1.16.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-icon-theme [sync] (yakkety-proposed) [1.16.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-user-guide [sync] (yakkety-proposed) [1.16.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted libmatekbd [sync] (yakkety-proposed) [1.16.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-desktop [sync] (yakkety-proposed) [1.16.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted libmateweather [sync] (yakkety-proposed) [1.16.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-polkit [sync] (yakkety-proposed) [1.16.0-1]
<pitti> flocculant: trivial ack, bug updated
<flocculant> pitti: you're a champ - thanks :)
<pitti> Laney: there, enough fodder for the armhf queues for smoketesting :)
-queuebot:#ubuntu-release- Unapproved: oslo-sphinx (yakkety-proposed/universe) [4.7.0-1 => 4.7.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted oslo-sphinx [sync] (yakkety-proposed) [4.7.0-2]
-queuebot:#ubuntu-release- Unapproved: criu (yakkety-proposed/universe) [2.6-1 => 2.6-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted criu [source] (yakkety-proposed) [2.6-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gcc-6 (yakkety-proposed/main) [6.2.0-5ubuntu11 => 6.2.0-5ubuntu12] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-6 [source] (yakkety-proposed) [6.2.0-5ubuntu12]
-queuebot:#ubuntu-release- Unapproved: audiocd-kio (yakkety-proposed/universe) [4:16.04.3-0ubuntu2 => 4:16.04.3-0ubuntu3] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: btfs (yakkety-proposed/universe) [2.4-1build3 => 2.11-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libdbusmenu [sync] (xenial-proposed) [16.04.1+16.04.20160927-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted btfs [sync] (yakkety-proposed) [2.11-1]
-queuebot:#ubuntu-release- Unapproved: rejected qtbase-opensource-src [sync] (xenial-proposed) [5.5.1+dfsg-16ubuntu7.2]
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (xenial-proposed) [20101020ubuntu451.6]
-queuebot:#ubuntu-release- Unapproved: accepted smbldap-tools [source] (xenial-proposed) [0.9.9-1ubuntu1.16.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted audiocd-kio [source] (yakkety-proposed) [4:16.04.3-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: rejected fcitx [source] (xenial-proposed) [1:4.2.9.1-1ubuntu1.16.04.1]
-queuebot:#ubuntu-release- Unapproved: mate-dock-applet (yakkety-proposed/universe) [0.74-1 => 0.75-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted comix [source] (xenial-proposed) [4.0.4-1ubuntu1]
<flexiondotorg> pitti, Ubuntu MATE testing team have been running it for 10 days or so from a PPA.
<pitti> flexiondotorg: ack, thanks
<flexiondotorg> pitti, Changes a small.
<flexiondotorg> MATE 1.15.x is in Yakkety and they are the last development snapshots.
<flexiondotorg> pitti, If it helps. This is everything MATE that was requested for sync.
<flexiondotorg> http://paste.ubuntu.com/23278609/
-queuebot:#ubuntu-release- Unapproved: accepted vino [source] (xenial-proposed) [3.8.1-0ubuntu9.2]
<pitti> flexiondotorg: someone else already accepted it, so it's all good
<flexiondotorg> pitti, Great.
<flexiondotorg> Except for mate-dock-applet, which wasn't available for a sync last night.
<flexiondotorg> I just made the request.
<flexiondotorg> pitti, Thanks for helping.
-queuebot:#ubuntu-release- Unapproved: accepted python-pymysql [source] (xenial-proposed) [0.7.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: unity8-desktop-session (yakkety-proposed/main) [1.0.13+16.10.20160921-0ubuntu1 => 1.0.13+16.10.20160928-0ubuntu1] (no packageset) (sync)
<pitti> flexiondotorg: accepted
<flexiondotorg> pitti, Many thanks!
-queuebot:#ubuntu-release- Unapproved: accepted mate-dock-applet [sync] (yakkety-proposed) [0.75-1]
-queuebot:#ubuntu-release- Unapproved: accepted unity8-desktop-session [sync] (yakkety-proposed) [1.0.13+16.10.20160928-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-calculator [source] (xenial-proposed) [1:3.18.3-0ubuntu1.16.04.1]
-queuebot:#ubuntu-release- Unapproved: cross-toolchain-base (yakkety-proposed/main) [11ubuntu4 => 12ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted cross-toolchain-base [source] (yakkety-proposed) [12ubuntu1]
-queuebot:#ubuntu-release- Unapproved: mame (yakkety-proposed/multiverse) [0.177-1 => 0.178-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mame [sync] (yakkety-proposed) [0.178-1]
-queuebot:#ubuntu-release- Unapproved: mate-themes (yakkety-proposed/universe) [3.20.11-0ubuntu1 => 3.20.12-0ubuntu1] (ubuntu-mate)
<flexiondotorg> If someone could accept mate-themes that would be very helpful, thanks :-)
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (yakkety-proposed/partner) [111.0.0-0ubuntu1 => 128.0.0-0ubuntu1] (no packageset)
<Odd_Bloke> ^ is required for GCE yakkety images to work properly, so an ACK in to -proposed would be appreciated.
-queuebot:#ubuntu-release- Unapproved: accepted mate-themes [source] (yakkety-proposed) [3.20.12-0ubuntu1]
<flexiondotorg> ^^^ Thanks!
-queuebot:#ubuntu-release- Unapproved: libetonyek (yakkety-proposed/main) [0.1.6-3 => 0.1.6-5] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libetonyek [sync] (yakkety-proposed) [0.1.6-5]
-queuebot:#ubuntu-release- Unapproved: aspectj (yakkety-proposed/universe) [1.8.9-1 => 1.8.9-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted aspectj [sync] (yakkety-proposed) [1.8.9-2]
-queuebot:#ubuntu-release- Unapproved: assertj-core (yakkety-proposed/universe) [2.3.0-2 => 2.3.0-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: bridge-method-injector (yakkety-proposed/universe) [1.13-1 => 1.14-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted assertj-core [sync] (yakkety-proposed) [2.3.0-3]
-queuebot:#ubuntu-release- Unapproved: accepted bridge-method-injector [sync] (yakkety-proposed) [1.14-1]
-queuebot:#ubuntu-release- Unapproved: activemq (yakkety-proposed/universe) [5.13.4+dfsg-2 => 5.14.0+dfsg-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted activemq [sync] (yakkety-proposed) [5.14.0+dfsg-2]
-queuebot:#ubuntu-release- Unapproved: access-modifier-checker (yakkety-proposed/universe) [1.4-2 => 1.7-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted access-modifier-checker [sync] (yakkety-proposed) [1.7-1]
-queuebot:#ubuntu-release- Unapproved: carrotsearch-randomizedtesting (yakkety-proposed/universe) [2.1.6+dfsg-1 => 2.1.17-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted carrotsearch-randomizedtesting [sync] (yakkety-proposed) [2.1.17-1]
-queuebot:#ubuntu-release- Unapproved: clojure1.6 (yakkety-proposed/universe) [1.6.0+dfsg-1 => 1.6.0+dfsg-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: cofoja (yakkety-proposed/universe) [1.1-r150-2 => 1.3-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted clojure1.6 [sync] (yakkety-proposed) [1.6.0+dfsg-2]
-queuebot:#ubuntu-release- Unapproved: csvjdbc (yakkety-proposed/universe) [1.0.29-1 => 1.0.31-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted cofoja [sync] (yakkety-proposed) [1.3-1]
-queuebot:#ubuntu-release- Unapproved: ecj (yakkety-proposed/main) [3.11.0-6 => 3.11.0-7] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted csvjdbc [sync] (yakkety-proposed) [1.0.31-1]
-queuebot:#ubuntu-release- Unapproved: felix-framework (yakkety-proposed/universe) [4.6.1-1 => 4.6.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: fop (yakkety-proposed/universe) [1:2.1-3 => 1:2.1-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted felix-framework [sync] (yakkety-proposed) [4.6.1-2]
-queuebot:#ubuntu-release- Unapproved: glassfish (yakkety-proposed/universe) [1:2.1.1-b31g+dfsg1-3 => 1:2.1.1-b31g+dfsg1-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted fop [sync] (yakkety-proposed) [1:2.1-4]
-queuebot:#ubuntu-release- Unapproved: groovy (yakkety-proposed/universe) [2.4.7-1 => 2.4.7-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted glassfish [sync] (yakkety-proposed) [1:2.1.1-b31g+dfsg1-4]
-queuebot:#ubuntu-release- Unapproved: hawtdispatch (yakkety-proposed/universe) [1.20-1 => 1.22-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted groovy [sync] (yakkety-proposed) [2.4.7-2]
-queuebot:#ubuntu-release- Unapproved: jabref (yakkety-proposed/universe) [2.10+ds-5 => 2.10+ds-6] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: jackrabbit (yakkety-proposed/universe) [2.12.2-1 => 2.12.4-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted hawtdispatch [sync] (yakkety-proposed) [1.22-1]
-queuebot:#ubuntu-release- Unapproved: accepted jackrabbit [sync] (yakkety-proposed) [2.12.4-1]
-queuebot:#ubuntu-release- Unapproved: accepted jabref [sync] (yakkety-proposed) [2.10+ds-6]
-queuebot:#ubuntu-release- Unapproved: jardiff (yakkety-proposed/universe) [0.2-4 => 0.2-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: jarjar-maven-plugin (yakkety-proposed/universe) [1.9-4 => 1.9-5] (no packageset) (sync)
-queuebot:#ubuntu-release- New sync: java-string-similarity (yakkety-proposed/primary) [0.18-1]
-queuebot:#ubuntu-release- Unapproved: accepted jardiff [sync] (yakkety-proposed) [0.2-5]
-queuebot:#ubuntu-release- Unapproved: jdeb (yakkety-proposed/universe) [1.5-2 => 1.5-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted jarjar-maven-plugin [sync] (yakkety-proposed) [1.9-5]
-queuebot:#ubuntu-release- Unapproved: jdependency (yakkety-proposed/universe) [1.1-1 => 1.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted jdeb [sync] (yakkety-proposed) [1.5-3]
-queuebot:#ubuntu-release- Unapproved: jmock2 (yakkety-proposed/universe) [2.7~snapshot+201309170925-gitd7fe69b5+dfsg-2 => 2.8.2-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted jdependency [sync] (yakkety-proposed) [1.1-2]
-queuebot:#ubuntu-release- Unapproved: jnr-ffi (yakkety-proposed/universe) [1.0.10-4 => 1.0.10-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted jmock2 [sync] (yakkety-proposed) [2.8.2-2]
-queuebot:#ubuntu-release- Unapproved: jnr-netdb (yakkety-proposed/universe) [1.1.4-2 => 1.1.6-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted jnr-ffi [sync] (yakkety-proposed) [1.0.10-5]
-queuebot:#ubuntu-release- Unapproved: knopflerfish-osgi (yakkety-proposed/universe) [5.1.0+dfsg1-3 => 5.2.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted jnr-netdb [sync] (yakkety-proposed) [1.1.6-1]
-queuebot:#ubuntu-release- Unapproved: libjackson-json-java (yakkety-proposed/universe) [1.9.2-7 => 1.9.2-8] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted knopflerfish-osgi [sync] (yakkety-proposed) [5.2.0-1]
-queuebot:#ubuntu-release- Unapproved: libjide-oss-java (yakkety-proposed/universe) [3.6.15+dfsg-1 => 3.6.16+dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libjide-oss-java [sync] (yakkety-proposed) [3.6.16+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: libparanamer-java (yakkety-proposed/universe) [2.8-2 => 2.8-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libquartz-java (yakkety-proposed/universe) [1:1.8.6-1 => 1:1.8.6-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libjackson-json-java [sync] (yakkety-proposed) [1.9.2-8]
-queuebot:#ubuntu-release- Unapproved: accepted libquartz-java [sync] (yakkety-proposed) [1:1.8.6-2]
-queuebot:#ubuntu-release- Unapproved: accepted libparanamer-java [sync] (yakkety-proposed) [2.8-3]
-queuebot:#ubuntu-release- Unapproved: libreflectasm-java (yakkety-proposed/universe) [1.05-3 => 1.05-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libspring-java (yakkety-proposed/universe) [4.3.2-1 => 4.3.3-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libreflectasm-java [sync] (yakkety-proposed) [1.05-4]
-queuebot:#ubuntu-release- Unapproved: maven-shade-plugin (yakkety-proposed/universe) [2.4.3-1 => 2.4.3-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libspring-java [sync] (yakkety-proposed) [4.3.3-1]
-queuebot:#ubuntu-release- Unapproved: mina2 (yakkety-proposed/universe) [2.0.13-1 => 2.0.13-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: openvswitch (yakkety-proposed/main) [2.6.0-0ubuntu1 => 2.6.0-0ubuntu2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted maven-shade-plugin [sync] (yakkety-proposed) [2.4.3-2]
-queuebot:#ubuntu-release- Unapproved: mustache-java (yakkety-proposed/universe) [0.8.17-5 => 0.8.18-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mina2 [sync] (yakkety-proposed) [2.0.13-2]
-queuebot:#ubuntu-release- Unapproved: mvel (yakkety-proposed/universe) [2.2.7-1 => 2.3.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mustache-java [sync] (yakkety-proposed) [0.8.18-1]
-queuebot:#ubuntu-release- Unapproved: parboiled (yakkety-proposed/universe) [1.1.7-1 => 1.1.7-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mvel [sync] (yakkety-proposed) [2.3.1-1]
-queuebot:#ubuntu-release- Unapproved: plexus-containers1.5 (yakkety-proposed/universe) [1.6-2 => 1.6-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted parboiled [sync] (yakkety-proposed) [1.1.7-2]
-queuebot:#ubuntu-release- Unapproved: resteasy (yakkety-proposed/universe) [3.0.18-1 => 3.0.19-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted plexus-containers1.5 [sync] (yakkety-proposed) [1.6-3]
-queuebot:#ubuntu-release- Unapproved: accepted resteasy [sync] (yakkety-proposed) [3.0.19-2]
-queuebot:#ubuntu-release- Unapproved: tika (yakkety-proposed/universe) [1.5-4 => 1.5-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: stax-ex (yakkety-proposed/universe) [1.7.1-1 => 1.7.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: tiles (yakkety-proposed/universe) [3.0.5-1 => 3.0.7-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted stax-ex [sync] (yakkety-proposed) [1.7.1-2]
-queuebot:#ubuntu-release- Unapproved: accepted tiles [sync] (yakkety-proposed) [3.0.7-1]
-queuebot:#ubuntu-release- Unapproved: accepted tika [sync] (yakkety-proposed) [1.5-5]
-queuebot:#ubuntu-release- Unapproved: tomcat7 (yakkety-proposed/universe) [7.0.70-3 => 7.0.72-1] (ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: undertow (yakkety-proposed/universe) [1.4.0-1 => 1.4.3-1] (no packageset) (sync)
-queuebot:#ubuntu-release- New binary: mame [amd64] (yakkety-proposed/multiverse) [0.178-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted undertow [sync] (yakkety-proposed) [1.4.3-1]
-queuebot:#ubuntu-release- Unapproved: wagon2 (yakkety-proposed/universe) [2.10-4 => 2.10-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: zookeeper (yakkety-proposed/universe) [3.4.8-2 => 3.4.9-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted wagon2 [sync] (yakkety-proposed) [2.10-5]
-queuebot:#ubuntu-release- Unapproved: accepted zookeeper [sync] (yakkety-proposed) [3.4.9-1]
-queuebot:#ubuntu-release- Unapproved: bouncycastle (yakkety-proposed/universe) [1.55-1 => 1.55-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted bouncycastle [source] (yakkety-proposed) [1.55-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ecj [sync] (yakkety-proposed) [3.11.0-7]
-queuebot:#ubuntu-release- Unapproved: accepted tomcat7 [sync] (yakkety-proposed) [7.0.72-1]
-queuebot:#ubuntu-release- Unapproved: jarjar (yakkety-proposed/universe) [1.4+svn142-4ubuntu1 => 1.4+svn142-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted jarjar [sync] (yakkety-proposed) [1.4+svn142-5]
-queuebot:#ubuntu-release- Unapproved: tomcat8 (yakkety-proposed/main) [8.0.36-2ubuntu1 => 8.0.37-1] (kubuntu, ubuntu-desktop, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: apt (yakkety-proposed/main) [1.3 => 1.3.1] (core) (sync)
<LocutusOfBorg> flexiondotorg, I'm doing some retry for mate, can I?
-queuebot:#ubuntu-release- New: accepted mame [amd64] (yakkety-proposed) [0.178-1]
-queuebot:#ubuntu-release- New: accepted java-string-similarity [sync] (yakkety-proposed) [0.18-1]
-queuebot:#ubuntu-release- Unapproved: accepted apt [sync] (yakkety-proposed) [1.3.1]
-queuebot:#ubuntu-release- Unapproved: accepted tomcat8 [sync] (yakkety-proposed) [8.0.37-1]
-queuebot:#ubuntu-release- Unapproved: geronimo-jacc-1.1-spec (yakkety-proposed/universe) [1.0.1-1.1fakesync1ubuntu1 => 1.0.1-2fakesync1ubuntu1] (no packageset)
<flexiondotorg> LocutusOfBorg, I don't understand the question.
-queuebot:#ubuntu-release- Unapproved: accepted geronimo-jacc-1.1-spec [source] (yakkety-proposed) [1.0.1-2fakesync1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: unity-control-center (yakkety-proposed/main) [15.04.0+16.10.20161003.1-0ubuntu1 => 15.04.0+16.10.20161003.1-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: java-string-similarity [amd64] (yakkety-proposed/none) [0.18-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted java-string-similarity [amd64] (yakkety-proposed) [0.18-1]
-queuebot:#ubuntu-release- Unapproved: libvirt (xenial-proposed/main) [1.3.1-1ubuntu10.3 => 1.3.1-1ubuntu10.4] (ubuntu-server, virt)
<bluesabre> pitti, would you mind taking a look at lp 1630401 as well? The thene is non-default and is a bugfix release over what we already have in yakkety so it should be a trivial ack :)
<ubot5> Launchpad bug 1630401 in numix-gtk-theme (Ubuntu) "[UIFe] numix-gtk-theme 2.6.4" [Undecided,New] https://launchpad.net/bugs/1630401
<bluesabre> pitti, (sorry for the recent abundance or spam)
<pitti> there's no need to ask for exceptions for bug fixes; bug updated
<Laney> If it's a UIF exception then that's only for the default envrionment - and the policy for flavours should be up to them
<Laney> It's so documentation is current, mainly - what that means (if anything) is going to vary between the flavours too
<Laney> bluesabre: ^-
<bluesabre> Gotcha, thanks guys
<apw> that said filling in the bug seems like a good idea just in the sense it makes people think about whether it is an issue for their documentation
<apw> they can then approve their own bug :)  and it is linked to the upload when it hits our queue
-queuebot:#ubuntu-release- Unapproved: vlan (yakkety-proposed/main) [1.9-3.2ubuntu1 => 1.9-3.2ubuntu2] (core)
<flexiondotorg> LocutusOfBorg, I see what you asking now. Yes, you can :-)
-queuebot:#ubuntu-release- Unapproved: fwts (yakkety-proposed/universe) [16.09.00-0ubuntu2 => 16.09.00-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted fwts [source] (yakkety-proposed) [16.09.00-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: numix-gtk-theme (yakkety-proposed/universe) [2.6.1-1 => 2.6.4-1] (no packageset) (sync)
<LocutusOfBorg> :)
<LocutusOfBorg> flexiondotorg, I'm issuing rebuilds for ~20 packages
<flexiondotorg> LocutusOfBorg, Thanks :-)
<flexiondotorg> Most will be requiring mate-desktop
-queuebot:#ubuntu-release- Unapproved: android-tools (yakkety-proposed/main) [5.1.1r36+git20160322-0ubuntu4 => 5.1.1r36+git20160322-0ubuntu5] (desktop-core)
<clivejo> is there someone available to help me with kdeconnect?  the current source is named kdeconnect-plasma but I would like to rename it back to kdeconnect in line with debian
-queuebot:#ubuntu-release- Unapproved: libertine (yakkety-proposed/main) [1.4.1+16.10.20160914-0ubuntu1 => 1.4.2+16.10.20161003-0ubuntu1] (no packageset) (sync)
<clivejo> The old source - https://launchpad.net/ubuntu/+source/kdeconnect , new https://launchpad.net/ubuntu/+source/kdeconnect-plasma and I want to update it to released version 1.0.1 available here - http://download.kde.org/stable/kdeconnect/1.0.1/src/
<jbicha> hi, could I get an ack for bug 1630557 ? thanks
<ubot5> bug 1630557 in ubuntu-gnome-meta (Ubuntu) "FFE: Include Spice integration by default in Ubuntu GNOME" [Wishlist,New] https://launchpad.net/bugs/1630557
<acheronuk> slangasek et al: +1 on clivejo's request if it is something you can help with. I don't use it, but the current archive version needs an update anyway, which I think would have to become a SRU if not done, as the old version is not compatible with the companion app much now
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (xenial-proposed) [0.6.5.6-0ubuntu14]
-queuebot:#ubuntu-release- Unapproved: lxc (yakkety-proposed/main) [2.0.4-0ubuntu5 => 2.0.5-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: portaudio19 (yakkety-proposed/main) [19+svn20140130-1build2 => 19+svn20140130-1.1] (kubuntu, ubuntu-desktop) (sync)
<LocutusOfBorg> fix for an RC bug that prevents blind people from using it ^^^ please accept
<LocutusOfBorg> flexiondotorg, winff is failing the testsuite
<LocutusOfBorg> pitti, please ignore winff failure on armhf? seems a bus error not related to mate
-queuebot:#ubuntu-release- Unapproved: online-accounts-api (yakkety-proposed/main) [0.1+16.10.20160722.4-0ubuntu1 => 0.1+16.10.20161003.1-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-system-settings-online-accounts (yakkety-proposed/main) [0.7+16.10.20160929-0ubuntu1 => 0.7+16.10.20161004-0ubuntu1] (no packageset) (sync)
<pitti> LocutusOfBorg: done
<LocutusOfBorg> thanks
<clivejo> pitti: you helped me with kdeconnect before?
<pitti> clivejo: I know nothing about it, what kind of help?
<clivejo> the source was renamed to kdecoonect-plasma for the new kf5 port, we expected upstream to follow but they didnt
-queuebot:#ubuntu-release- Unapproved: ubuntu-terminal-app (yakkety-proposed/universe) [0.7.218ubuntu1 => 0.7.218ubuntu2] (no packageset)
<clivejo> Debian have re-used the original kdeconnect packaging and I want to follow that and update to latest source 1.0.1
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-terminal-app [source] (yakkety-proposed) [0.7.218ubuntu2]
<flexiondotorg> LocutusOfBorg, winff?
<flexiondotorg> That is not something from MATE.
<clivejo> Previous and one I want to update is https://launchpad.net/ubuntu/+source/kdeconnect the current https://launchpad.net/ubuntu/+source/kdeconnect-plasma
<LocutusOfBorg> but triggered by mate
<LocutusOfBorg> anyhow, I'll trigger the last 7 builds at the end of this britney run I think
<xnox> slangasek, pitti - how to make bileto ignore missing builds? e.g. upstart/s390x ? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-2048-excuses/2016-10-05_13:20:01/2048_xenial_excuses.html
<pitti> xnox: hm, I don't know -- it shouldn't complain about that in the first place
<xnox> pitti, well upstart/s390x does exist in xenial/release.
<xnox> missing in xenial-updates
<pitti> xnox: oh, xenial
<pitti> so why did it suddenly start to FTBFS in x?
<pitti> xnox: no idea, I'm afraid -- I suppose it might be enough to make tests non-fatal on s390x?
<xnox> pitti, looking at http://ddebs.ubuntu.com/dists/yakkety/main/binary-s390x/Packages it appears to be stale
<pitti> xnox: it's removed in yakkety, but not in xenial
<xnox> yet it was just recently generated.
 * xnox will wait a bit, kernel moved an hour ago, so maybe ddebs will move in a bit too
<xnox> pitti, so it did start to ftbfs on xenial too, and last xenial-proposed got released into xenial-updates with failing s390x build.
<xnox> not sure where/how that hint was applied
 * xnox ignores that for a moment.
-queuebot:#ubuntu-release- Unapproved: open-iscsi (yakkety-proposed/main) [2.0.873+git0.3b4b4500-14ubuntu6 => 2.0.873+git0.3b4b4500-14ubuntu7] (ubuntu-desktop, ubuntu-server)
<cyphermox> lamont: "finally" ^
<lamont> cyphermox: oh wow
<lamont> pitti: (or whoever) can you kick cloud-initramfs-tools from unaccepted into xenial-proposed?
<jderose> cyphermox: hmm, todays daily ISO still seemingly has the broken shim package?
<jderose> infinity: is there something special about how shim, shim-signed get onto the iso? i ask because today's daily doesn't seem to have the fix, plus i don't see shim listed in the manifest
<cyphermox> jderose: ok, looking
-queuebot:#ubuntu-release- Unapproved: ubiquity-slideshow-ubuntu (yakkety-proposed/main) [115 => 116] (kubuntu, ubuntu-desktop)
<cyphermox> cd log says the right shim "should" be there.
<cyphermox> as I recall though it's never on the manifest because it's installed separately only if needed
<cyphermox> it is, however, in http://cdimage.ubuntu.com/daily-live/current/yakkety-desktop-amd64.list
 * cyphermox waits for zsync to complete
<cyphermox> pitti: could you please review open-iscsi, cloud--initramfs-tools and ubiquity-slideshow?
<pitti> I will, once my interruptions stop getting interrupted by other interruptions :)
<cyphermox> ;)
<pitti> cyphermox: open-iscsi> this is still not right -- please don't make any assumptions about /tmp, just use apt
<cyphermox> you misunderstand
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity-slideshow-ubuntu [source] (yakkety-proposed) [116]
<pitti> cyphermox: oh, that's the inner VM?
<cyphermox> pitti: this *uses* apt to download the open-iscsi deb, which is then copied into the inner vm
<pitti> I thought the "outer" VM tried to fish them out of ../../binaries/ or so
<cyphermox> I need to put the deb somewhere ;)
<cyphermox> it doesn't use the internal paths from autopkgtest at all
<pitti> ok, I  thought becuase I saw those in the diff
<pitti> anyway, thanks!
<cyphermox> everything just happens to be in /tmp, because need somewhere to put them ;)
<pitti> cyphermox: I don't see cloud-initramfs-tools, did the other two
<cyphermox> thanks
-queuebot:#ubuntu-release- Unapproved: accepted open-iscsi [source] (yakkety-proposed) [2.0.873+git0.3b4b4500-14ubuntu7]
<cyphermox> cloud-initramfs-tools is lamont's, no idea where it would be ;)
<pitti> ah, ok; he asked about xenial
<lamont> pitti: perhaps I should upload it again, then.  Yay me.
<lamont> it's likely that I didn't ever actually re-upload it
<lamont> will do that in a bit
<pitti> lamont: no, all good
<pitti> lamont: cyphermox asked for it amongst two yakkety-propoised packages, so I assumed he meant a y upload
<lamont> nope. x-proposed.  part of the whole cluster
<lamont> smoser will (I hope) uplaod 0.30ubuntu1 to yakkety today (hint hint...) to remove my shamefully bad code (that's not used)
<lamont> pitti: you found 1.2 in xenial?
 * lamont afk quick errand
<pitti> lamont: https://launchpad.net/ubuntu/xenial/+queue?queue_state=1 â there
<lamont> pitti: I feel like I've been taught to fish with dynamite!..  Ta
<jderose> cyphermox: /usr/lib/shim/shim.efi.signed from the `shim-signed` package and /EFI/BOOT/BOOTx64.EFI on the ISO should be the same, correct? FYI, they aren't the same on the latest daily
<lamont> the first 140 lines or so of that diff are deleting a file that shouldn't have been in 1.1 :/
<lamont> because the actual file is (end of diff) in a subdirectory
<lamont> and if  you want changelog to preserve the ubuntu1.1 version, reject and tell me so and I'll fix it in a few.
<lamont> afk about 20 min
<smoser> there is no real need to upload that code to yakeety
<smoser> that should not block the upload to xenial
<smoser> as the code path is not used in yakkety
<cyphermox> jderose: well, I see that they're not the same but I don't know right now why
<apw> smoser, well other than the SRU policy wanting it released in devel first
<smoser> apw, i plan on pulling it into upstream, but you really shouldnt bother gating on that. any bug in that path is basically "invalid" on yakkety. but i can upload if that makes you happiest.
<smoser> and i would like to have yakkety with it, but only to make the two code bases the same.
<apw> same is good
<smoser> can someone please take a look at curtin xenial sru that rharper prepared
 * apw casts an eye
-queuebot:#ubuntu-release- Unapproved: maas (yakkety-proposed/main) [2.0.0+bzr5189-0ubuntu1 => 2.1.0~beta1+bzr5433-0ubuntu1] (ubuntu-server)
<lamont> o/
-queuebot:#ubuntu-release- Unapproved: lxcfs (yakkety-proposed/main) [2.0.3-0ubuntu2 => 2.0.4-0ubuntu1] (edubuntu, ubuntu-server)
<jderose> cyphermox: btw, same problem in the latest daily server iso too
-queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (xenial-proposed) [10.2.3-0ubuntu0.16.04.1]
<cyphermox> yeah, we figured it out I think
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (yakkety-proposed/partner) [111.0.0-0ubuntu1 => 128.0.0-0ubuntu1] (no packageset)
<Odd_Bloke> Could someone approve that google-cloud-sdk and reject the upload from ~6 hours ago?
<Odd_Bloke> slangasek: ^ maybe?
<slangasek> Odd_Bloke: I've done the reject part; putting the review of the new one on my backlog for after coffee
-queuebot:#ubuntu-release- Unapproved: rejected google-cloud-sdk [source] (yakkety-proposed) [128.0.0-0ubuntu1]
<Odd_Bloke> slangasek: Thanks. :)
-queuebot:#ubuntu-release- Unapproved: accepted openvswitch [source] (yakkety-proposed) [2.6.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted vlan [source] (yakkety-proposed) [1.9-3.2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted unity-control-center [source] (yakkety-proposed) [15.04.0+16.10.20161003.1-0ubuntu2]
<cyphermox> slangasek: I can do the d-i respin for shim
<cyphermox> jderose: ^ a part of the puzzle I didn't expect; we'll do that and then an iso respin will get the right shims.
<jderose> cyphermox: awesome, thanks!
<jderose> cyphermox: so the d-i build gets the shim bits copied into it then? and it wasn't rebuilt since shim was updated?
-queuebot:#ubuntu-release- Unapproved: accepted android-tools [source] (yakkety-proposed) [5.1.1r36+git20160322-0ubuntu5]
<cyphermox> well, d-i builds its own images for netbooting, which includes shim, and we reuse that to build the fuller images for the isos
<jderose> cyphermox: okay, gotcha, makes sense
-queuebot:#ubuntu-release- Unapproved: accepted nautilus-image-converter [source] (xenial-proposed) [0.3.1~git20110416-1ubuntu1.16.04.1]
<stgraber> would be great if someone could take a look at the lxc and lxcfs bugfix releases in the yakkety queue
<slangasek> xnox: in theory that should be a 'force' hint, I'm not sure if bileto is set up to read the existing hints files from the SRU/release team?  robru if I put hints in lp:~ubuntu-sru/britney/hints-ubuntu-xenial/ will bileto read those?
<slangasek> xnox: fwiw we aren't using proposed-migration to manage publication of SRUs, so p-m output is strictly advisory on the SRU side - we didn't have to deal with this issue when publishing the previous SRU
<slangasek> but if bileto leads us to cleaning up our hints, so much the better
-queuebot:#ubuntu-release- Unapproved: debian-installer (yakkety-proposed/main) [20101020ubuntu479.1 => 20101020ubuntu480] (core)
<pitti> stgraber: will look
<stgraber> thanks pitti
-queuebot:#ubuntu-release- Unapproved: accepted numix-gtk-theme [sync] (yakkety-proposed) [2.6.4-1]
-queuebot:#ubuntu-release- Unapproved: accepted libertine [sync] (yakkety-proposed) [1.4.2+16.10.20161003-0ubuntu1]
<pitti> stgraber: ah, this shoudl automatically build against the new go.crypto bits
-queuebot:#ubuntu-release- Unapproved: accepted portaudio19 [sync] (yakkety-proposed) [19+svn20140130-1.1]
<stgraber> pitti: well, no since that's only lxc and lxcfs, lxd 2.0.4 will be xenial-only, but we released lxd 2.4 yesterday and it's already in the archive
<stgraber> pitti: when was the new go.crypto uploaded?
<pitti> stgraber: oh right, lxc, not lxd, sorry
<pitti> stgraber: this morning
<stgraber> not that it should matter, lxd is using go shared libraries now
<pitti> this hash-based tracking of go libraries appears fairly broken to me :(
-queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (yakkety-proposed) [2.0.5-0ubuntu1]
<stgraber> well, the fact that nobody versions their API properly in the Go world is the problem :)
<pitti> right
<slangasek> pitti: there's prior art in ocaml and haskell; mwhudson and I worked through the requirements in detail; if there are implementation bugs in the hash-based ABI tracking for go please escalate to mwhudson, if it's broken in the sense of "augh every upload requires rebuilding the world", well, sorry that's an upstream limitation :)
<pitti> slangasek: right, I meant the latter
-queuebot:#ubuntu-release- Unapproved: accepted lxcfs [source] (yakkety-proposed) [2.0.4-0ubuntu1]
<xnox> slangasek, it's just that britney doesn't run any adt tests, unless packages are considered / otherwise valid
<pitti> providingn libraries without stable APIs is not *really* providing a library..
<cjwatson> it kind of is if you get to share memory segments
<slangasek> xnox: yes, and I've added a 'force' hint now so that it will be considered a candidate
<pitti> (indeed nothign we can do downstream about it, but it's still questionable whether we shoudl actually use that so widely)
 * pitti STFU and continues reviewing
<cjwatson> which is possibly useful given umpty-megabyte binaries
<stgraber> pitti: ok, so I guess we want a no change rebuild of LXD then to fix this?
<pitti> stgraber: yes, I think so (hopefully it's no-change :) ) -- slangasek said he was going to look at the transition, so please coordinate wiht him
<stgraber> ok, I believe it's no change since I didn't have any problem building lxd on my laptop where I'm using the upstream build system (and so always pull latest)
<stgraber> upstream jenkins looks happy too and builds from current snapshots of everything every time
<stgraber> slangasek: want a no change rebuild of LXD?
<slangasek> stgraber: yeah, I'm going to throw things at a ppa this morning when I get a chance to verify buildability, if you have things that specifically need rebuilt now please go ahead and upload them to the archive, and if necessary I will pull golango-go.crypto back out of -proposed and revert the rebuilds
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (yakkety-proposed) [20101020ubuntu480]
-queuebot:#ubuntu-release- Unapproved: accepted online-accounts-api [sync] (yakkety-proposed) [0.1+16.10.20161003.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-system-settings-online-accounts [sync] (yakkety-proposed) [0.7+16.10.20161004-0ubuntu1]
<slangasek> stgraber: I was puzzling over the lxd autopkgtest failures however, since it didn't look like there was a runtime dep on the shared lib that would cause this
<pitti> Depends: libgolang-golang-x-crypto1-aee66c7c01790941129f5499917bbb4d5763ffe4
<pitti> isn't that the runtime dep?
<slangasek> looks like it
<slangasek> reverse-depends doesn't show it
<slangasek> tsk :)
<pitti> and it fails due to uninstallability
<slangasek> maybe we overflowed reverse-depends' package name field length
<pitti> $ reverse-depends libgolang-golang-x-crypto1-aee66c7c01790941129f5499917bbb4d5763ffe4
<pitti> reverse-depends: Error: <p>Package not published in specified release</p>
<pitti> hah
<slangasek> pitti: yes, but I was doing 'reverse-depends src:golang-go.crypto' which should traverse provides
<pitti> oh, it's virtual
<pitti> slangasek: it only shows rdepends for -dev indeed; I suppose it can't deal with these virtual package provides
<pitti> and the real libgolang-golang-x-crypto1 package actually doesn't have real rdepends
<pitti> (as intended)
-queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (xenial-proposed) [0.1.0~bzr425-0ubuntu1~16.04.1]
<stgraber> oh, fun, I do have to release a LXD 2.4.1 now anyway since I screwed up the 2.4 release tarball (says 2.3 in there)
<stgraber> so will upload that which will also act as the rebuild for the new go crypto
<pitti> Version: 2.4-0ubuntu1
<pitti> $ lxd --version
<pitti> 2.3
<pitti> heh
<stgraber> yeah, still trying to figure out how that happened :)
<stgraber> the tag in git shows the right version string
<stgraber> I somehow managed to screw up the tarball
-queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (yakkety-proposed) [128.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: cloud-initramfs-tools (yakkety-proposed/main) [0.29ubuntu2 => 0.30ubuntu1] (edubuntu, ubuntu-server)
<Odd_Bloke> slangasek: Thanks!
-queuebot:#ubuntu-release- Unapproved: nova (xenial-proposed/main) [2:13.1.1-0ubuntu1 => 2:13.1.1-0ubuntu1.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted loganalyzer [source] (xenial-proposed) [3.6.6+dfsg-2ubuntu1.1]
<pitti> cyphermox: still no joy :( http://autopkgtest.ubuntu.com/packages/open-iscsi/yakkety/i386 -- UnboundLocalError: local variable 'resolvconf_contents' referenced before assignment
<bdmurray> pitti: Are you reviewing SRUs now? Or who accepted curtin?
<pitti> bdmurray: I'm not; I reviewed yakkety and just finished putting an end into linux' eternal tmpfail-loop-of-daeth
<slangasek> bdmurray: apw was asking me about curtin, maybe him
<nacc> rbasak was just reviewing one of mine, I think
<apw> bdmurray, that was me
<apw> bdmurray, problem ?
<bdmurray> apw: I'm working on training rbasak now and we are reviewing the queue.
<apw> bdmurray, oh that was a one off direct request for review, i am not reviewing anything else
<bdmurray> apw: Okay, cool.
<apw> bdmurray, you didn't want to look at that one, trust me
-queuebot:#ubuntu-release- Unapproved: cups-filters (yakkety-proposed/main) [1.11.4-0ubuntu1 => 1.11.4-0ubuntu2] (desktop-core, ubuntu-server)
<slangasek> pay no attention to the man behind the curtin
<pitti> bdmurray: ack, will leave it alone; lamont asked about cloud-initramfs-tools; if you don't get to it during your training, I'll have a look at it tonight
 * pitti aligns the tin foil
<pitti> ... hat
 * apw puts on a double layer
<lamont> yay for hats
-queuebot:#ubuntu-release- Unapproved: lxd (yakkety-proposed/main) [2.4-0ubuntu1 => 2.4.1-0ubuntu1] (edubuntu, ubuntu-server)
<stgraber> pitti: ^
<pitti> stgraber: thanks; will wait until it becomes diffy, preping dinner by then
<stgraber> still no idea wth happened... Just re-checked all the other things I tagged lately using the same script and they all seem nice
<pitti> well, "heat up", we already prepped it yesterday :)
<stgraber> yeah, heading out for dinner too now (at LinuxCon in Berlin)
<pitti> stgraber: ooh
<apw> stgraber, you will figure it out two years from now
<pitti> stgraber: I had been in Berlin until Sunday, for a week
<cyphermox> pitti: indeed, but "Could not access KVM kernel module: No such file or directory"
<stgraber> pitti: arrived here yesterday afternoon, flying back home on Friday
<robru> slangasek: xnox: bileto reads hints exclusively from  lp:~ubuntu-release/britney/hints-ubuntu
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (xenial-proposed) [1.3.1-1ubuntu10.4]
-queuebot:#ubuntu-release- Unapproved: stress-ng (yakkety-proposed/universe) [0.06.17-1ubuntu0 => 0.06.17-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted stress-ng [source] (yakkety-proposed) [0.06.17-1ubuntu1]
<slangasek> robru: ok, that's different from the setup for the archive instances; is this a deliberate difference, or just something not imported in the setup?
<robru> slangasek: i guess you could call it a communications error. Nobody ever told me there were hints anywhere else, and even those hints i didn't implement until somebody complained that bileto wasn't observing their hints
<slangasek> robru: ok, this is all part of the britney1 code
<robru> slangasek: yeah i don't have britney1 at all, i just pull in britney2 and the hints and point them at each other
-queuebot:#ubuntu-release- Unapproved: nova (xenial-proposed/main) [2:13.1.1-0ubuntu1 => 2:13.1.1-0ubuntu1.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ubuntu-wallpapers (yakkety-proposed/main) [16.10.0-0ubuntu1 => 16.10.1-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted smbldap-tools [source] (trusty-proposed) [0.9.9-1ubuntu1.14.04.2]
-queuebot:#ubuntu-release- Unapproved: fslint (yakkety-proposed/universe) [2.44-2 => 2.44-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted fslint [source] (yakkety-proposed) [2.44-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: appstream-glib (yakkety-proposed/main) [0.6.2-1 => 0.6.3-1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (trusty-proposed) [1:0.196.22]
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (yakkety-proposed) [2.4.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted cups-filters [source] (yakkety-proposed) [1.11.4-0ubuntu2]
<pitti> stgraber: accepted
<Laney> ^- I uploaded that appstream-glib directly to not have to wait for it to grind through Debian and Launchpad. And it calls some things New Features, but they're opt-in for clients so should be harmless (but I can file an FFe if $you want)
<sergiusens> arges or anyone in the release team, mind accepting snapcraft into xenial-updates?
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (precise-proposed) [1:0.156.14.20]
-queuebot:#ubuntu-release- Unapproved: rejected nova [source] (xenial-proposed) [2:13.1.1-0ubuntu1.1]
<apw> sergiusens, i don't see one in the queue
<sergiusens> apw it is here though http://people.canonical.com/~ubuntu-archive/pending-sru.html
<apw> sergiusens, oh i completely missread that as -proposed, derp
-queuebot:#ubuntu-release- Unapproved: thefuck (yakkety-proposed/universe) [3.11-1 => 3.11-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted thefuck [sync] (yakkety-proposed) [3.11-2]
 * Laney blinks
<ogra_> "thefuck" ? doesnt that violate the code of conduct ?
<ogra_> :O
<Laney> haha
-queuebot:#ubuntu-release- Unapproved: barbican (yakkety-proposed/main) [1:3.0.0~rc1-0ubuntu1 => 1:3.0.0~rc1-0ubuntu2] (openstack)
<slangasek> ogra_: sorry, it's a sync from Debian ;P
<slangasek> (though its maintainer has signed the Ubuntu CoC ;)
<ogra_> evil debianers :)
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (yakkety-proposed/main) [1:16.10.4 => 1:16.10.5] (core)
<bdmurray> slangasek: Could you reject that u-r-u upload?
<apw> bdmurray, done
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-release-upgrader [source] (yakkety-proposed) [1:16.10.5]
-queuebot:#ubuntu-release- Unapproved: open-iscsi (yakkety-proposed/main) [2.0.873+git0.3b4b4500-14ubuntu7 => 2.0.873+git0.3b4b4500-14ubuntu8] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: linux (yakkety-proposed/main) [4.8.0-19.21 => 4.8.0-21.23] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta (yakkety-proposed/main) [4.8.0.19.28 => 4.8.0.21.30] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed (yakkety-proposed/main) [4.8.0-19.21 => 4.8.0-21.23] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (yakkety-proposed/main) [1:16.10.4 => 1:16.10.5] (core)
<infinity> ^-- I'm on those linux uploads.
-queuebot:#ubuntu-release- Unapproved: gnome-control-center (yakkety-proposed/universe) [1:3.20.1-2ubuntu2 => 1:3.20.1-2ubuntu3] (ubuntugnome)
<slangasek> d-i 480 migrated to yakkety, so lining up respins (initially, just ubuntu server & desktop) for when it hits
<dobey> ogra_: "i don't think it ought to be blasphemy, just saying jehovah"
<jderose> slangasek: awesome, thanks! i'll test on hardware and under qemu as soon as there's shiny new ISOs
-queuebot:#ubuntu-release- Unapproved: dietlibc (yakkety-proposed/universe) [0.34~cvs20160606-2 => 0.34~cvs20160606-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted dietlibc [source] (yakkety-proposed) [0.34~cvs20160606-2ubuntu1]
<bdmurray> apw: The new ubuntu-release-upgrader is good if you are still about.
-queuebot:#ubuntu-release- Unapproved: ubiquity (yakkety-proposed/main) [16.10.11 => 16.10.12] (core)
-queuebot:#ubuntu-release- Unapproved: accepted barbican [source] (yakkety-proposed) [1:3.0.0~rc1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted open-iscsi [source] (yakkety-proposed) [2.0.873+git0.3b4b4500-14ubuntu8]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (yakkety-proposed) [1:3.20.1-2ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (yakkety-proposed) [1:16.10.5]
-queuebot:#ubuntu-release- Unapproved: ubuntu-themes (yakkety-proposed/main) [16.10+16.10.20160926-0ubuntu1 => 16.10+16.10.20161005-0ubuntu1] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: kpimtextedit (yakkety-proposed/universe) [15.12.3-0ubuntu1 => 16.04.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: preseed (yakkety-proposed/main) [1.71ubuntu2 => 1.71ubuntu3] (core)
<cyphermox> please hold on on approving preseed; I just realized that if it lands first it would likely make ubiquity unnecessarily fail to build until I update the manifest... or please review ubiquity first ;)
-queuebot:#ubuntu-release- Unapproved: memcached (yakkety-proposed/main) [1.4.25-2ubuntu1 => 1.4.25-2ubuntu2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: frogr (yakkety-proposed/universe) [1.0-1 => 1.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted frogr [sync] (yakkety-proposed) [1.1-1]
<mwhudson> morning
<stgraber> slangasek: lxd autopkgtest looks good with the rebuild
<stgraber> in that, I've uploaded a new LXD (to fix that version string issue) and it built fine and passed adt, autopkgtest is still showing a fail for the lxd test for go-crypto, but maybe a retry would fix that now
<slangasek> stgraber: ack; I'll hold off on the autopkgtest retry until I finish the analysis of my rebuild test (https://launchpad.net/~vorlon/+archive/ubuntu/multiarch/+packages)
-queuebot:#ubuntu-release- Unapproved: unity-scope-click (yakkety-proposed/main) [0.1.1+16.10.20161003-0ubuntu1 => 0.1.1+16.10.20161005-0ubuntu1] (no packageset) (sync)
<santa_> slangasek: hi, we uploaded kpimtextedit; I think I need it in -proposed to proceed with kidentitymanagement
<slangasek> santa_: happy to expedite, but why is it needed in -proposed to move to the next step?
<slangasek> (accepted)
<bdmurray> powersj: Is bug 1626197 still an issue?
<ubot5> bug 1626197 in Ubuntu "Yakkety Server ISO (2016-09-21) fails install due to libpython3.5" [Critical,New] https://launchpad.net/bugs/1626197
<powersj> bdmurray, no we can mark that fixed
-queuebot:#ubuntu-release- Unapproved: accepted kpimtextedit [source] (yakkety-proposed) [16.04.3-0ubuntu2]
<santa_> slangasek: right now I can't run the autopkgtest of my wip kidentitymanagement (it needs an soname bump, as we discussed) it complains about dependencies because (I think) we don't have kpimtextedit in -proposed yet
<dobey> any chance to get that unity-scope-click accepted? ^^
<bdmurray> powersj: we as in me or we as in you?
<powersj> :) I can
<santa_> slangasek: ftr kidentitimanagement is not buildable in yakkety until kpimtextedit gets built, thank you for accepting it
<slangasek> santa_: right, but they could still be uploaded to the queue in parallel, using either a versioned build-dep (which might already be there) or give-backs of the builds
<santa_> slangasek: yeah, there's already a versioned b-d but I wanted to run the autopkgtest because I think it's going to fail
<santa_> so I wanted to fix the autopkgtest before uploading kidentitymanagement
<santa_> in order to not get it tackled by britney
<slangasek> oh, well, we can fix autopkgtest runs manually also to use the right combination of packages
-queuebot:#ubuntu-release- New binary: kpimtextedit [ppc64el] (yakkety-proposed/universe) [16.04.3-0ubuntu2] (kubuntu)
<pitti> stgraber, slangasek: lxd built fine against new go.crypto, and I retried the tests so that both are now valid candidates (still needs the transition, though0
<santa_> aren't they ok just with the versioned b-d?
 * lamont idly wonders when cloud-initramfs-tools will hit {y,x}-proposed
<santa_> I mean autopkgtests inherit the build depends from debian/control, right?
-queuebot:#ubuntu-release- New binary: kpimtextedit [amd64] (yakkety-proposed/universe) [16.04.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- New binary: kpimtextedit [i386] (yakkety-proposed/universe) [16.04.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- New binary: kpimtextedit [s390x] (yakkety-proposed/universe) [16.04.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- New binary: kpimtextedit [arm64] (yakkety-proposed/universe) [16.04.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- New binary: kpimtextedit [powerpc] (yakkety-proposed/universe) [16.04.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: etcd (yakkety-proposed/universe) [2.3.7+dfsg-4 => 2.3.7+dfsg-5] (no packageset) (sync)
-queuebot:#ubuntu-release- New binary: kpimtextedit [armhf] (yakkety-proposed/universe) [16.04.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted etcd [sync] (yakkety-proposed) [2.3.7+dfsg-5]
<bdmurray> slangasek: could you reopen the release notes task for bug 1447038?
<ubot5> bug 1447038 in casper (Ubuntu) "Shutdown/Restart of live session guest does not work in Virtualbox, and VMWare" [High,Triaged] https://launchpad.net/bugs/1447038
<slangasek> dobey: accepted
<slangasek> santa_: autopkgtests normally don't involve installing the build-deps at all unless 'build-required' is specified; so the answer to your question is "it depends"
-queuebot:#ubuntu-release- Unapproved: accepted unity-scope-click [sync] (yakkety-proposed) [0.1.1+16.10.20161005-0ubuntu1]
<slangasek> pitti: transition> I'm finishing up my analysis of the revdeps in ppa, so far looking good and I'll trigger that transition soon
<slangasek> lamont: cloud-initramfs-tools/yakkety, reviewing now
<lamont> woot!
<slangasek> bdmurray: reopened
<slangasek> lamont: what's the extra comment noise in dyn-netconf/scripts/init-bottom/cloud-initramfs-dyn-netconf ?
<lamont> at the top of the file, or?
<lamont> it needs to support both input-file formats, so it shows examples of both
<slangasek> lamont: at the top of the file. ok
<slangasek> accepted for yakkety
<lamont> xenial should look startlingly familiar
-queuebot:#ubuntu-release- Unapproved: accepted cloud-initramfs-tools [source] (yakkety-proposed) [0.30ubuntu1]
<dobey> slangasek: thanks
<slangasek> lamont: mostly; but why did cloud-initramfs-dyn-netconf  disappear in the xenial SRU?
<slangasek> was that file in the wrong location?
<slangasek> and this diff suggests that some of these changes you just landed in yakkety had already landed in the previous xenial sru hmmmm
<slangasek> ok accepted
<lamont> slangasek: because it should never have appeared in 1.1?
-queuebot:#ubuntu-release- Unapproved: accepted cloud-initramfs-tools [source] (xenial-proposed) [0.27ubuntu1.2]
<lamont> 27ubuntu1.1 was reflected in 0.29ubuntu1.2, whch may or may not have made it out of unaccepted.
<lamont> 27ubuntu1.2 is reflected in 0.30ubuntu1
-queuebot:#ubuntu-release- Unapproved: golang-github-coreos-pkg (yakkety-proposed/main) [3~ds1-0ubuntu1 => 3~ds1-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted golang-github-coreos-pkg [source] (yakkety-proposed) [3~ds1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: libecap (yakkety-proposed/main) [1.0.1-3ubuntu4 => 1.0.1-3.2] (ubuntu-server) (sync)
<jderose> cyphermox: slangasek: i did a quick sanity check under qemu+ovmf on the 20161005.1 desktop and server ISOs... everything seems shiny re shim. i'll test on hardware shortly, will report back with my results
<slangasek> jderose: hurrah
<jderose> slangasek: indeed :D
<cyphermox> great!
<cyphermox> I'll do this here on hardware too
<cyphermox> slangasek: could you please review ubiquity? and *later* preseed?
<jderose> cyphermox: in your opinion, were there any particular risks in reverting shim, any particular test scenarios i should give extra attention to?
<cyphermox> jderose: well, I know some BIOS may be broken now, there was at least one commit in the new shim that was required to fix some weirdness in the way the boot entry was passed to shim
<slangasek> cyphermox: looking
<cyphermox> but it's very limited impact
<cyphermox> jderose: if we can boot the iso images and boot an installed system, I think we're fine.
<jderose> cyphermox: ah, i didn't realize BIOS installs even interacted with shim. i'll test on some BIOS systems then too
<slangasek> s/BIOS/firmware/
<slangasek> ;)
<cyphermox> yeah, I use "BIOS" loosely
<jderose> ah, okay, that makes more sense :)
<cyphermox> let's call it "EFI implementations"
 * cyphermox -> dinner, back in a few hours
<slangasek> cyphermox: I am facepalm that this bug has been open so long and no one has gotten pkexec working properly on those desktop envs
<cyphermox> I looked hard, couldn't make sense of it. seems like pkexec has acted up in the past before
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (yakkety-proposed) [16.10.12]
<ahoneybun> anyone around to help with this: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1615799 ?
<ubot5> Ubuntu bug 1615799 in ubiquity (Ubuntu) "Kubuntu slideshow is broken" [Critical,Confirmed]
<slangasek> cyphermox: it certainly has, but is meant to be the right interface here <shrug>
<wxl> that's critical?!
<cyphermox> slangasek: I know :/
<ahoneybun> as new users are installing Kubuntu and not seeing help about there new system
<cyphermox> ahoneybun: ah, it's still broken? I will look this evening
<ahoneybun> yep we've been trying to fix it
<ahoneybun> but no one knows PyQt well enough
<ahoneybun> wxl: I believe it is
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-wallpapers [source] (yakkety-proposed) [16.10.1-0ubuntu1]
<ahoneybun> clivejo has had to disable the whole slideshow for the installer to even work
<ahoneybun> so pretty critical I think
<slangasek> infinity: you still on those linux uploads?
-queuebot:#ubuntu-release- Unapproved: accepted appstream-glib [source] (yakkety-proposed) [0.6.3-1]
<wxl> ahoneybun: it just seems strange to me that the installer would fail just due to a problem with the slideshow
<ahoneybun> it's coded into like that
<ahoneybun> good old python2
<wxl> wait the bug says it installs fine?
<ahoneybun> since the slideshow has been part has been disabled
<ahoneybun> other wise the installer will not start
<wxl> a broken slideshow can be resolved with release notes
<wxl> a broken installer can't
<wxl> that being said, i'd advise NOT making the installer depend upon the success of the slideshow
<wxl> but that's my 2Â¢ :)
<cyphermox> How was it disabled, so i know how to get started fixing this? ;-)
<ahoneybun> I'm not sure since I did not do it
<wxl> i hear you, but certainly something to investigate furhter one
<wxl> s/furhter one/further on/
<ahoneybun> I think it is pretty important for a first time user of Linux
<ahoneybun> Ubuntu in this case
<wxl> i don't disagree. just saying there's critical and then there's critical :)
<infinity> slangasek: I am, yes.
<slangasek> infinity: ok, happily ignoring
<infinity> wxl: It's a critical bug in the slideshow, whether it's release critical is a different story.
<infinity> Well, likely in ubiquity, not the slideshow, but whatever.
<cyphermox> wxl: in this case things aren't that simple
<cyphermox> Right
<ahoneybun> well ubiquity not the slideshow
<infinity> wxl: Arguing criticality of a bug that effectively reads as "it doesn't work at all" isn't worth the time.
<infinity> That's sort of the definition of critical.
<wxl> fair enough
<acheronuk> cyphermox: disabled by removing ubiquity-slideshow-kubuntu from the cd/seeds I think?
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-themes [sync] (yakkety-proposed) [16.10+16.10.20161005-0ubuntu1]
<acheronuk> cyphermox: http://bazaar.launchpad.net/~kubuntu-dev/ubuntu-seeds/kubuntu.yakkety/revision/1341
<wxl> acheronuk: does that mean it has the default ubuntu slideshow?
<acheronuk> wxl: no, just a blank space and progress bar
<wxl> acheronuk: well that's good at least!
<acheronuk> wxl: it works, but doesn't look great to have that missing :(
<slangasek> doko_: ok, figured out that taglibs-standard is a straight swap rename of jakarta-taglibs-standard; will sort out for archive
-queuebot:#ubuntu-release- Unapproved: accepted memcached [source] (yakkety-proposed) [1.4.25-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: audiocd-kio (yakkety-proposed/universe) [4:16.04.3-0ubuntu3 => 4:16.04.3-0ubuntu4] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted audiocd-kio [source] (yakkety-proposed) [4:16.04.3-0ubuntu4]
<ahoneybun> thanks for the fill in of info acheronuk
<slangasek> santa_: libkf5pimtextedit-dev contains a binary ./usr/lib/x86_64-linux-gnu/qt5/plugins/designer/kpimtexteditwidgets.so which looks like it should be in the runtime package?
<slangasek> santa_: I'm not accepting this from the binary NEW queue, since if that file is in the wrong package it'll require more packaging fix-ups to move it than if we just pretend this package version never happened
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-welcome (yakkety-proposed/universe) [16.10.9 => 16.10.10] (ubuntu-mate)
<slangasek> bdmurray: u-r-u autopkgtest regression on armhf? I've seen errors before about libGL trying to load swrast, but don't remember what the proper fix was (other than in the general sense of "don't let your test deps assume GL hardware availability in autopkgtests")
<bdmurray> slangasek: the libGL messages existed on the passing test too - https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/armhf/u/ubuntu-release-upgrader/20161004_054525@/log.gz
<slangasek> ok
<santa_> slangasek: if I'm not mistaken, that's a qt designer plugin, that's meant to be used by developers and it's not needed @ runtime by packages linking against the library
<santa_> slangasek: that file would be used by qt designer so you could design a window having the ui widget in question
<flexiondotorg> If anyone wants to accept ubuntu-mate-welcome into Yakkety that would be just dandy :-)
-queuebot:#ubuntu-release- Unapproved: gdb (yakkety-proposed/main) [7.11.90.20160927-0ubuntu1 => 7.11.90.20161005-0ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: click-apparmor (yakkety-proposed/main) [0.3.16 => 0.3.17] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted click-apparmor [source] (yakkety-proposed) [0.3.17]
<slangasek> santa_: ok, so the lintian error it's giving is that there are missing library dependencies; probably needs ${shlibs:Depends} for the dev package if this is where you mean for it to be shipped?
<santa_> slangasek: oh, probably, let me check/fix...
<slangasek> santa_: ok. if it's staying in this package, then I don't need to hold it up in NEW anymore
<santa_> slangasek: yeah, go ahead, I guess I will prepare an update adding ${shlibs:Depends}
-queuebot:#ubuntu-release- New: accepted kpimtextedit [amd64] (yakkety-proposed) [16.04.3-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted kpimtextedit [armhf] (yakkety-proposed) [16.04.3-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted kpimtextedit [powerpc] (yakkety-proposed) [16.04.3-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted kpimtextedit [s390x] (yakkety-proposed) [16.04.3-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted kpimtextedit [arm64] (yakkety-proposed) [16.04.3-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted kpimtextedit [ppc64el] (yakkety-proposed) [16.04.3-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted kpimtextedit [i386] (yakkety-proposed) [16.04.3-0ubuntu2]
<jderose> cyphermox: slangasek: finished sanity checking desktop ISO on a slew of UEFI hardware... so far so good. next i'll test the server ISO, although seems I shouldn't expect anything different
<lamont> slangasek: I'm wondering how much more time I have to shake the trees on my package collection and stil get in before freeze-freeze...
 * lamont is confident in them, but wants to give others more warm fuzzies by having more hands verify them
<slangasek> lamont: what package collection is this?
<lamont> {cloud-initramfs-tools,initramfs-tools,open-iscsi,cloud-init}
<lamont> open-iscsi is actually a cyphermox package, but the others are sitting in -proposed waiting on verification-done on the SRU bugs
<lamont> 1621615, 1621507
<lamont> bug 1621507 bug 1621615
<ubot5> bug 1621507 in MAAS "initramfs-tools configure_networking() fails to dhcp ipv6 addresses" [Critical,Triaged] https://launchpad.net/bugs/1621507
<ubot5> bug 1621615 in MAAS "network not configured when ipv6 netbooted into cloud-init" [Undecided,New] https://launchpad.net/bugs/1621615
<slangasek> lamont: initramfs-tools itself still?  let's get that one first, plese
<slangasek> the others only impact the server image, but strangely, all our images care about initramfs-tools
 * lamont stares at the diff, if any
<lamont> how is that possible? :D
<slangasek> as for a general deadline, well, if we have it by the end of the week I think we'll manage
<lamont> ack.
-queuebot:#ubuntu-release- Unapproved: gcc-6-cross (yakkety-proposed/main) [12ubuntu1 => 12ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-6-cross [source] (yakkety-proposed) [12ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted preseed [source] (yakkety-proposed) [1.71ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted libecap [sync] (yakkety-proposed) [1.0.1-3.2]
-queuebot:#ubuntu-release- Unapproved: gcc-6-cross (yakkety-proposed/main) [12ubuntu1 => 12ubuntu3] (no packageset)
<lamont> slangasek: mpontillo will update 1621507 and hilight you after his testing
-queuebot:#ubuntu-release- Unapproved: accepted gcc-6-cross [source] (yakkety-proposed) [12ubuntu3]
 * lamont bbl
#ubuntu-release 2016-10-06
<mpontillo> slangasek: I've finished regression testing the fixes LaMont put together (via custom built MAAS images) -- from what I can tell, everything looks okay. I've done a dozen or so deployments with MAAS, using X and Y.
<mpontillo> updated the bug to verification-done.
-queuebot:#ubuntu-release- Unapproved: accepted gdb [source] (yakkety-proposed) [7.11.90.20161005-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-welcome [source] (yakkety-proposed) [16.10.10]
 * cyphermox back
<tsimonq2> cyphermox: could you please keep me in the loop on the Kubuntu slideshow?
<cyphermox> infinity: if this retry of the autopkgtests for open-iscsi fail, I think we'll have reached the point where we might as well override the tests -- I know open-iscsi works, even in those MAAS ephermeral tests, I ran them multiple times locally and we (lamont and I) did run MAAS deployments with these pacakges
-queuebot:#ubuntu-release- New binary: libkf5libkleo [ppc64el] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5libkleo [amd64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5libkleo [i386] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5pimcommon [ppc64el] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
<cyphermox> tsimonq2: ok, starting to look into that now
-queuebot:#ubuntu-release- New binary: libkf5libkleo [powerpc] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5pimcommon [i386] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5pimcommon [amd64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
<dobey> can someone please hit https://autopkgtest.ubuntu.com/request.cgi?release=yakkety&arch=i386&package=unity8&trigger=unity-scope-click%2F0.1.1%2B16.10.20161005-0ubuntu1 to retry the test? only failed on i386 and in someething that unity-scope-click would have had no effect on
<tsimonq2> thanks a bunch cyphermox :)
-queuebot:#ubuntu-release- New binary: libkf5libkleo [s390x] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
<cyphermox> tsimonq2: however, I have little idea what I'm doing there, so we'll see ;)
<tsimonq2> cyphermox: you familiar with Qt and/or Python? :)
<cyphermox> python and ubiquity yes, Qt, much less, but I can manage
<tsimonq2> well then it won't be TOO hard for you :)
-queuebot:#ubuntu-release- New binary: libkf5libkleo [armhf] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5pimcommon [powerpc] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5pimcommon [s390x] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5libkleo [arm64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5pimcommon [armhf] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5pimcommon [arm64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libkf5libkleo [amd64] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5libkleo [armhf] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5libkleo [powerpc] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5libkleo [s390x] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5pimcommon [arm64] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5pimcommon [i386] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5pimcommon [ppc64el] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5libkleo [arm64] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5libkleo [ppc64el] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5pimcommon [armhf] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5pimcommon [s390x] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5libkleo [i386] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5pimcommon [powerpc] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5pimcommon [amd64] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<tsimonq2> ooh, more Kubuntu stuff accepted ;)
<cyphermox> tsimonq2: what of blaze's port to pyqt5?
<tsimonq2> cyphermox: huh?
<cyphermox> someone called 'blaze' on LP did some porting to pyqt5
<cyphermox> I'm looking through it right now, looks legit and pretty complete
<tsimonq2> I just didn't understand your question
<tsimonq2> well apparently it's not complete
<cyphermox> ok
<tsimonq2> I couldn't get it set up on my machine
<cyphermox> well then it's going to get me some ways to the end
<tsimonq2> segfault
<tsimonq2> cyphermox: so I think what you might need to do to figure it out is fix the goshdarn segfault :P
<cyphermox> it looks like it's not that simple. if there's no webkit for pyqt4 as it seems to be the case now, there isn't much I'll be able to do
<cyphermox> ah, zsync done
-queuebot:#ubuntu-release- Unapproved: spu-tools (yakkety-proposed/universe) [2.3.0.136-2 => 2.3.0.136-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted spu-tools [source] (yakkety-proposed) [2.3.0.136-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: maas (yakkety-proposed/main) [2.0.0+bzr5189-0ubuntu1 => 2.1.0~beta2+bzr5454-0ubuntu1] (ubuntu-server)
<lamont> slangasek: it occured to me over dinner... initramfs-tools is already in yakkety, it's the xenial SRU that's sitting in -proposed.
<lamont> bug 1621615 also marked verification-done
<ubot5> bug 1621615 in MAAS "network not configured when ipv6 netbooted into cloud-init" [Undecided,New] https://launchpad.net/bugs/1621615
<lamont> slangasek: given that all of the packages in question are Fix-Released in yakkety, I expect that the SRUs of same could wait until people are awake after final freeze and the RC is out.
-queuebot:#ubuntu-release- New binary: libkf5gravatar [i386] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5gravatar [ppc64el] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kf5-kdepim-apps-libs [ppc64el] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5gravatar [amd64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kf5-kdepim-apps-libs [i386] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
<jbicha> could a Release Team member take a look at bug 1630557 ? thanks
<ubot5> bug 1630557 in ubuntu-gnome-meta (Ubuntu) "FFE: Include Spice integration by default in Ubuntu GNOME" [Wishlist,New] https://launchpad.net/bugs/1630557
-queuebot:#ubuntu-release- New binary: kf5-kdepim-apps-libs [amd64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5gravatar [s390x] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5gravatar [armhf] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kf5-kdepim-apps-libs [arm64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5gravatar [arm64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kf5-kdepim-apps-libs [s390x] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5gravatar [powerpc] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kf5-kdepim-apps-libs [armhf] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kf5-kdepim-apps-libs [powerpc] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
<ahoneybun> cyphermox: webkit has support in PyQt5
<ahoneybun> blaze changed the names of the functions from PyQt4 to 5
<cyphermox> ahoneybun: yeah, I noticed
<cyphermox> I'm working on that, got it a bit of way to working
<cyphermox> so far I can almost reach the timezone panel
<slangasek> dobey: unity8 i386 retried; I feel like I've seen that failure before, maybe you could log a bug about them fixing the test?
<cyphermox> there! working slideshow for kubuntu.
-queuebot:#ubuntu-release- Unapproved: nfstrace (yakkety-proposed/universe) [0.4.2-2ubuntu2 => 0.4.2-2ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted nfstrace [source] (yakkety-proposed) [0.4.2-2ubuntu3]
-queuebot:#ubuntu-release- New: accepted libkf5gravatar [amd64] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5gravatar [ppc64el] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5gravatar [i386] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5gravatar [arm64] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5gravatar [powerpc] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5gravatar [armhf] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5gravatar [s390x] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<slangasek> santa_: this sticks out among the other KDE lib packages: I: libkf5kaddressbookgrantlee5: no-symbols-control-file usr/lib/x86_64-linux-gnu/libKF5KaddressbookGrantlee.so.5.2.3
-queuebot:#ubuntu-release- New: accepted kf5-kdepim-apps-libs [amd64] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kf5-kdepim-apps-libs [armhf] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kf5-kdepim-apps-libs [powerpc] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kf5-kdepim-apps-libs [s390x] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kf5-kdepim-apps-libs [arm64] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kf5-kdepim-apps-libs [ppc64el] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kf5-kdepim-apps-libs [i386] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<cyphermox> slangasek: wondering if we could override the open-iscsi test results. the MAAS ephemeral image test still fails in autopkgtest, but they do work locally and I and lamont have run MAAS deployments that show the package is working
<lamont> cyphermox: slangasek I fully support this plan
<lamont> cyphermox: I'd actually be inclined to leave that particular test there, but not run by default, with the README saying how to run it, and a hope that people run it manually to make sure it still passes
<slangasek> cyphermox, lamont: last successful autopkgtest for open-iscsi on amd64 and i386 was before xenial was released; yes to overriding, and +1 from me for disabling a test that isn't passing
<cyphermox> lamont: well, true that I could have it skip myself.
<slangasek> (that's an SRU-worthy change for both xenial and yakkety)
-queuebot:#ubuntu-release- Unapproved: arc-theme (yakkety-proposed/universe) [20160923-1 => 20161005-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: clearlooks-phenix-theme (yakkety-proposed/universe) [6.0.3-1 => 6.0.3+git20161006-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted arc-theme [sync] (yakkety-proposed) [20161005-1]
-queuebot:#ubuntu-release- Unapproved: accepted clearlooks-phenix-theme [sync] (yakkety-proposed) [6.0.3+git20161006-1]
<cyphermox> I'll do an upload tomorrow that skips the test, it's easy to unskip it for one-off local autopkgtest runs.
<cyphermox> lamont: ^
<cyphermox> and now, I'm off
<lamont> cyphermox: g'night
<pitti> good morning
<cyphermox> g'night
 * lamont stil has a few more tests to run before his hardware gets repossessed by IS in the morning
<pitti> cyphermox: open-iscsi? I'll hint if it still fails
<slangasek> pitti: I've just hinted open-iscsi :)
<pitti> ack
<cyphermox> it's indeed what we were discussing
<lamont> pitti: good morning, sir
<pitti> hey lamont, how are you?
<lamont> lets not go there. :D
<lamont> actually doing well
<lamont> questions from earlier in /query
<lamont> mostly of the "halp how make work" variety, that become useful tomorrow when I cause my local hardware to qemu boot ipv6 guests
-queuebot:#ubuntu-release- Unapproved: accepted casper [source] (xenial-proposed) [1.376.1]
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (xenial-proposed) [2:13.1.1-0ubuntu1.1]
<slangasek> pitti: I'm puzzled by the autopkgtest failure here; there's an error about an undefined symbol that is only available in the proposed version of kiconthemes, which has correct .symbols files, so how did the test environment ever end up with anything referencing that symbol? http://autopkgtest.ubuntu.com/packages/p/plasma-framework/yakkety/amd64
-queuebot:#ubuntu-release- Unapproved: rejected maas [source] (yakkety-proposed) [2.1.0~beta1+bzr5433-0ubuntu1]
<slangasek> (I'm also retrying it with kio+kiconthemes fwiw)
<pitti> slangasek: I did a mass-retry for KDE against all of -proposed on Monday, as the 5.26 packages commonly need to be tested together
<pitti> I suppose that exposed it?
<slangasek> pitti: if it had been tested with the version of kiconthemes in -proposed, it shouldn't have been a missing symbol
<pitti> Get:184 http://ftpmaster.internal/ubuntu yakkety-proposed/universe amd64 libkf5iconthemes5 amd64 5.26.0-0ubuntu1 [83.3 kB]
<pitti> slangasek: ^ it was
-queuebot:#ubuntu-release- Unapproved: rejected linux-signed [sync] (yakkety-proposed) [4.8.0-21.23]
<pitti> slangasek: actually, that log was not a run with --all-proposed
<slangasek> pitti: ah.  so I see packages being downloaded multiple times as part of that test.  Is it building against -proposed, and then testing the binaries against release?
<pitti> --apt-pocket=proposed=src:kio
-queuebot:#ubuntu-release- Unapproved: linux-signed (yakkety-proposed/main) [4.8.0-19.21 => 4.8.0-21.23] (core, kernel) (sync)
<pitti> i. e. that was just a standard "minimize proposed" run
<pitti> slangasek: no, the apt pinning is the same for build and binaries, but it did run into the fallback: WARNING: Test dependencies are unsatisfiable with using apt pinning. Retrying with using all packages from proposed
<slangasek> pitti: ah
<pitti> slangasek: so, it did build against everything in -proposed, as just instlaling kio from -proposed was uninstallable
<pitti> and if deps aren't versioned correctly and pinning just the trigger from -proposed causes uninstallability, running everything from -proposed is the fallback
<pitti> that happened during build, but not during the test
<pitti> so indeed this is a case where --all-proposed (or more selectively using kiconthemes from -proposed) should help
<slangasek> pitti: got it.  a bit confusing, especially when grepping the log instead of reading it linearly
<slangasek> santa_, acheronuk: libkdegames looks like it still has a broken autopkgtest (acc, broken since mid-august)
<pitti> slangasek: want me to do a mass-retry against all-proposed to mop up these cases?
<slangasek> santa_, acheronuk: (overriding the bad test for libkdegames, to avoid blocking)
<slangasek> pitti: I'm never thrilled with --all-proposed because I don't feel that it gives us proper bisection, but it's up to you
<cpaelzer> good morning, today openvswitch shows up in update-excuses for a failed dependent neutron test
<cpaelzer> coreycb yesterday analyzed just such an issue and debugged it to a timing issue on s390
<cpaelzer> therefore I was re-triggering the test for now
<cpaelzer> is there anything I should check/notify if I do so (I beg a pardon, but this is the first time I restart such a test)
<slangasek> cpaelzer: nope, just don't stand on the button
<cpaelzer> one click, one SSO login and thats it
<cpaelzer> ok, will take a look later then if that unblocked it
<cpaelzer> thanks slangasek
<cpaelzer> at least I found it on the running queue, so the triggering worked
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta [sync] (yakkety-proposed) [4.8.0.21.30]
-queuebot:#ubuntu-release- Unapproved: accepted linux [sync] (yakkety-proposed) [4.8.0-21.23]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed [sync] (yakkety-proposed) [4.8.0-21.23]
-queuebot:#ubuntu-release- Unapproved: golang-github-appc-spec (yakkety-proposed/universe) [0.8.5+dfsg-1 => 0.8.6+dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted golang-github-appc-spec [sync] (yakkety-proposed) [0.8.6+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: golang-google-grpc (yakkety-proposed/universe) [0.0~git20160517.0.a22b6611-2 => 1.0.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted golang-google-grpc [sync] (yakkety-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- Unapproved: gcc-snapshot (yakkety-proposed/universe) [20161001-1ubuntu1 => 20161006-1ubuntu1] (no packageset)
<santa_> good morning
-queuebot:#ubuntu-release- Unapproved: accepted gcc-snapshot [source] (yakkety-proposed) [20161006-1ubuntu1]
<santa_> slangasek: regarding libkdegames I think you were right when you said it was obsolete, apparently nothing is using it anymore but libkeduvocdocument
-queuebot:#ubuntu-release- Unapproved: kdesdk-thumbnailers (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:15.12.3-0ubuntu2] (kubuntu)
<santa_> I don't know why it's still released upstream maybe they didn't removed it yet from the tarball release scripts
<slangasek> ah
<santa_> regarding the libkf5kaddressbookgrantlee5 I take note
<santa_> slangasek: right now I have finished kidentitymanagement, that should unblock the remaining kde builds, would you like to sponsor it? I can prepare a dsc
<slangasek> santa_: I've also retried akonadi's autopkgtest with a hint to make things installable, and it fails with a different error now: http://autopkgtest.ubuntu.com/packages/a/akonadi/yakkety/amd64
<slangasek> santa_: maybe pitti can sponsor it, I'm past EOD
<pitti> santa_: sure, please send me a debdiff or pointer to .dsc
<santa_> ok
-queuebot:#ubuntu-release- Unapproved: accepted kdesdk-thumbnailers [source] (yakkety-proposed) [4:15.12.3-0ubuntu2]
<santa_> pitti: http://gpul.grupos.udc.es/sponsor/kidentitymanagement_16.04.3-0ubuntu2.dsc
-queuebot:#ubuntu-release- Unapproved: gcc-6-cross-ports (yakkety-proposed/universe) [9ubuntu1 => 9ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-6-cross-ports [source] (yakkety-proposed) [9ubuntu2]
-queuebot:#ubuntu-release- Unapproved: gcc-5-cross (yakkety-proposed/universe) [24ubuntu1 => 24ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gcc-5-cross-ports (yakkety-proposed/universe) [10ubuntu1 => 10ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-5-cross-ports [source] (yakkety-proposed) [10ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-5-cross [source] (yakkety-proposed) [24ubuntu2]
-queuebot:#ubuntu-release- Unapproved: kidentitymanagement (yakkety-proposed/universe) [15.12.3-0ubuntu1 => 16.04.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted kidentitymanagement [source] (yakkety-proposed) [16.04.3-0ubuntu2]
<pitti> santa_: ^ (will have a look at binNEW again after it built)
<santa_> pitti: thank you very much
-queuebot:#ubuntu-release- New binary: kidentitymanagement [ppc64el] (yakkety-proposed/universe) [16.04.3-0ubuntu2] (kubuntu)
<pitti> santa_: that'll require a dozen no-change rebuilds; want/need me to upload those?
-queuebot:#ubuntu-release- New binary: kidentitymanagement [amd64] (yakkety-proposed/universe) [16.04.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- New binary: kidentitymanagement [i386] (yakkety-proposed/universe) [16.04.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- New binary: kidentitymanagement [arm64] (yakkety-proposed/universe) [16.04.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- New binary: kidentitymanagement [s390x] (yakkety-proposed/universe) [16.04.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- New binary: kidentitymanagement [armhf] (yakkety-proposed/universe) [16.04.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- New binary: kidentitymanagement [powerpc] (yakkety-proposed/universe) [16.04.3-0ubuntu2] (kubuntu)
<pitti> slangasek: http://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/revision/1982 â just the newer version is enough, britney now does a â¤ check on the version for matching
-queuebot:#ubuntu-release- Unapproved: account-plugins (yakkety-proposed/main) [0.13+16.10.20160831-0ubuntu1 => 0.13+16.10.20160929.1-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- New: accepted kidentitymanagement [amd64] (yakkety-proposed) [16.04.3-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted kidentitymanagement [armhf] (yakkety-proposed) [16.04.3-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted kidentitymanagement [powerpc] (yakkety-proposed) [16.04.3-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted kidentitymanagement [s390x] (yakkety-proposed) [16.04.3-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted kidentitymanagement [arm64] (yakkety-proposed) [16.04.3-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted kidentitymanagement [ppc64el] (yakkety-proposed) [16.04.3-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted kidentitymanagement [i386] (yakkety-proposed) [16.04.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: upstart (xenial-proposed/main) [1.13.2-0ubuntu21.1 => 1.13.2-0ubuntu21.2] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: upstart (yakkety-proposed/main) [1.13.2-0ubuntu32 => 1.13.2-0ubuntu33] (core) (sync)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (yakkety-proposed/main) [4.8.0-21.23] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (yakkety-proposed) [4.8.0-21.23]
-queuebot:#ubuntu-release- Unapproved: glibc (yakkety-proposed/main) [2.24-0ubuntu1 => 2.24-3ubuntu1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-wallpapers (yakkety-proposed/main) [16.10.1-0ubuntu1 => 16.10.2-0ubuntu1] (ubuntu-desktop)
<santa_> pitti: I have a fix for plasma-framework autotests, are you willing to sponsor the upload? that would unblock some britney migrations I think
<davmor2> cyphermox, jibel: Yay working uefi on secureboot again \o/
-queuebot:#ubuntu-release- Unapproved: accepted upstart [sync] (yakkety-proposed) [1.13.2-0ubuntu33]
<pitti> santa_: sure
<santa_> ok. let me prepare the dsc
-queuebot:#ubuntu-release- Unapproved: accepted glibc [sync] (yakkety-proposed) [2.24-3ubuntu1]
<santa_> I plan to try to fix more tests today, so we can get more things migrated
<infinity> pitti: apw's all over that glibc, BTW.
<pitti> infinity:  oh, oops
<infinity> And I have a d-i prepped to pick up new glibc and kernel once it publishes.
<apw> pitti, s'ok, i was litterally about to do the exact same
<pitti> apw: sorry for mid-air collision then
<pitti> let the autopkgtest queue fun begin :)
<apw> pitti, it is good we both reviewed it, and both were happy to hit the button on it
<apw> infinity, d-i> nice
<santa_> pitti: http://gpul.grupos.udc.es/sponsor/plasma-framework_5.26.0-0ubuntu2.dsc
<pitti> santa_: did you see my questions about the rebuilds for kidentitymanagement?
<santa_> pitti: about the no-change rebuilds?
<pitti> santa_: yes
-queuebot:#ubuntu-release- Unapproved: plasma-framework (yakkety-proposed/universe) [5.26.0-0ubuntu1 => 5.26.0-0ubuntu2] (kubuntu)
<pitti> santa_: i. e. don't bother with sponsoring; I have a script for mass-rebuilds, I was just wondering if/which of those you need done
<santa_> pitti: so let me see if I get you: we bumped the abi so the reverse depends must be rebuilt to depend on the abi1 package, right?
<pitti> santa_: correct
<pitti> santa_: some might need actual source chagnes if the API changed too (but I was assuming it's just some C++ ABI change)
<santa_> pitti: if we get everything we have in -proposed migrated that wouldn't be needed
<pitti> santa_: how do you mean?
<pitti> santa_: you either finish the transiton or that kidentitymanagemnt upload will not land in yakkety (britney enforces this)
<pitti> santa_: libkf5identitymanagement5 is NBS now, we can't release with that
<santa_> pitti: because we have an script which bumps the version of the build depends, so everything build depending on kidentitymanagement is going to be built against >= 16.04.3 getting the right dependency on build time
<santa_> so everything in -proposed would be fine
<pitti> santa_: right; but I meant the packages which are already in yakkety (reverse-depends libkf5identitymanagement5)
<pitti> even in -proposed
<pitti> everything which has built before that kidentitymanagement upload
<pitti> needs to be rebuilt
<santa_> hmm
<santa_> probably many would fail to build because iirc the API changed
<pitti> 5 â 5abi1 just sounded like one of the usual C++ madness ABI changes, not a real API change?
<pitti> if the API changed, why isn't this just 6?
<santa_> because that could clash with a real upstream soname bump
<pitti> the changelog also said "bug fix releaes", and the few removed functions like setUrl() just looked internal
<pitti> well, if that actually changed API and upstream 5.26 isn't ready for that and the transition isn't being handled, then perhaps we shuold remove that version from y-proposed again
-queuebot:#ubuntu-release- Unapproved: accepted plasma-framework [source] (yakkety-proposed) [5.26.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: mesa (yakkety-proposed/main) [12.0.3-1ubuntu1 => 12.0.3-1ubuntu2] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-wallpapers [source] (yakkety-proposed) [16.10.2-0ubuntu1]
<santa_> it's 16.04.3, it's a package from KDE Applications, not from KDE Frameworks
-queuebot:#ubuntu-release- Unapproved: accepted account-plugins [sync] (yakkety-proposed) [0.13+16.10.20160929.1-0ubuntu1]
<santa_> pitti: can't be kidentitymanagement blocked from migrating to yakkety until all reverse depends are ready to migrate?
<pitti> santa_: it's the other way around -- it won't migrate until all of them are
<pitti> santa_: look at "trying: kidentitymanagement" in http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_output_notest.txt
<pitti> santa_: anyway, if you did not really intend to land this in yakkety, let's remove it now
<pitti> santa_: otherwise the next KDE uplaod will build against it and get stuck
<santa_> pitti: the idea was getting the complete set of kde apps 16.04.3 landing in yakkety, I don't see why it's a bad thing in the next uploads are built against kidentititymanagement 5abi1, because it's the way it's suposed to be
<pitti> santa_: ok; then please upload them ASAP
<santa_> pitti: they are already there, the only thing blocking us right now are the autotests
<pitti> santa_: how do you mean "already there"?
<pitti> in some PPA?
 * pitti is really confused
<santa_> pitti: nope, in -proposed
<pitti> santa_: so the ones in -proposed need no-change rebuilds?
<pitti> as everything which was not uploaded in the last hour or so was obviously not built against 5abi1
<santa_> pitti: what was not uploaded in the last hour wasn't built yet, it was in dep-wait because we have versioned build depends
<pitti> santa_: aah! ok, that makes more sense
<santa_> pitti: so now, this last upload of kidentitymanagement would unblock that dep-wait packages which will be built against the correct version
<jbicha> can I upload the update requrested in bug 1630557 ?
<ubot5> bug 1630557 in ubuntu-gnome-meta (Ubuntu) "FFE: Include Spice integration by default in Ubuntu GNOME" [Wishlist,New] https://launchpad.net/bugs/1630557
-queuebot:#ubuntu-release- New binary: libkf5ksieve [ppc64el] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5ksieve [amd64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5ksieve [i386] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kf5-messagelib [ppc64el] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5ksieve [powerpc] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5ksieve [s390x] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kf5-messagelib [i386] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5ksieve [armhf] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted kf5-messagelib [i386] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5ksieve [amd64] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5ksieve [i386] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5ksieve [ppc64el] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kf5-messagelib [ppc64el] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5ksieve [powerpc] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5ksieve [armhf] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5ksieve [s390x] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: libkf5ksieve [arm64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kf5-messagelib [amd64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kf5-messagelib [s390x] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kf5-messagelib [powerpc] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kf5-messagelib [armhf] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kf5-messagelib [arm64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted kf5-messagelib [amd64] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kf5-messagelib [armhf] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kf5-messagelib [s390x] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kf5-messagelib [arm64] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5ksieve [arm64] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kf5-messagelib [powerpc] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: makedumpfile (yakkety-proposed/main) [1:1.6.0-2 => 1:1.6.0-2ubuntu1] (core)
<davmor2> cyphermox: meh hit a snag on hardware, Mokutil just says verfication failed(15) Access denied
-queuebot:#ubuntu-release- Unapproved: accepted makedumpfile [source] (yakkety-proposed) [1:1.6.0-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (yakkety-proposed) [12.0.3-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: debian-installer (yakkety-proposed/main) [20101020ubuntu480 => 20101020ubuntu481] (core)
<apw> pitti, have debian-installer ^
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (yakkety-proposed) [20101020ubuntu481]
<pitti> aah, glibc test madness incoming
<Laney> moar workers!
<pitti> apw: can't see it, but now I just see someone accepted it
<apw> pitti, that was me :)
<infinity> pitti: Consider a late glibc upload a way to get a good baseline on tests before we flip over to SRUs. :P
<pitti> :)
<pitti> infinity: and it's getting too cold outside, so some heating can't hurt!
-queuebot:#ubuntu-release- Unapproved: upstart (yakkety-proposed/main) [1.13.2-0ubuntu33 => 1.13.2-0ubuntu34] (core)
<pitti> Laney: ^ more obnoxious script changes to fix that race
<pitti> Laney: (no changes since you tested it from people.u.c.)
<pitti> infinity: I suppose we don't actually want to wait until *all* glibc tests finished? (if we do, we won't land anything in the next two days at least)
<pitti> i. e. I'd let a few hundred of them run, and once we see enough green and only justifiable red I'll kill the remaining tests and we wave it through?
<Laney> pitti: ack
<infinity> pitti: Yeah, seems reasonable.  The number of code changes is actually quite small.
<smb> apw, are autopkgtests which failed automatically restarted or does that need some manual steps. Just was looking at xenial libvirt for otehr reasons and the sru page says armhf failed. Though the log looks suspiciously like container problem. Did not see a button for retry myself.
<apw> smb, will have a llok
<apw> smb, concur, and i have clickd the button on it
-queuebot:#ubuntu-release- Unapproved: accepted upstart [source] (yakkety-proposed) [1.13.2-0ubuntu34]
<smb> apw, ah thanks. Is that button appearing for you from something the sru page points to or am I just blind? Well ok I am mostly blind anyhow... :-P
<apw> smb, they are on the britney progress pages for the release, i've dropped you a link in PM
<smb> apw, got it. thanks
 * smb was trying to click his way through from the pending-sru page
<apw> smb, yeah not so much
<pitti> apw, smb: excuses.html are not dynamic/per user/login, retry buttons appear for everyone (they just don't work for everyone)
<apw> pitti, yeah there is no connection from pending-sru.html to those buttons, i think that was the confusion
<pitti> aah
-queuebot:#ubuntu-release- New binary: libkf5mailcommon [ppc64el] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5mailcommon [amd64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5mailcommon [i386] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5mailcommon [s390x] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5mailcommon [armhf] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5mailcommon [powerpc] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5mailcommon [arm64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: foomatic-db (yakkety-proposed/main) [20160817-0ubuntu1 => 20161005-1] (desktop-core, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-gnome-meta (yakkety-proposed/universe) [0.69 => 0.70] (ubuntugnome)
<LocutusOfBorg> cjwatson, your opinion on a ghc sync -f? https://anonscm.debian.org/cgit/pkg-haskell/DHG_packages.git/commit/?id=6c85e8fa057c35e85231ab95d955b954160e6520 and https://anonscm.debian.org/cgit/pkg-haskell/DHG_packages.git/commit/p/ghc/debian?id=3354959ffaddb30572e3609841f20a26859323ff
<LocutusOfBorg> the powerpc fixes might be useful
<LocutusOfBorg> as well as the fPIE additions, that should be better than the existing hacks
<LocutusOfBorg> I also propose myself in doing the rebuilds if you want to do a sync and a little transition
<cjwatson> LocutusOfBorg: I'd recommend not at this point in the cycle; too difficult to get everything rebuilt in time if it turns out to break ABI
<cjwatson> save it for z
<cjwatson> unless it's actively getting in something's way (more than "might be useful")
<LocutusOfBorg> I can do all the rebuilds in two days, but I agree
<LocutusOfBorg> cjwatson, AFAIR we had some powerpc broken builds, and we kicked them out to let it transition
<LocutusOfBorg> this patch should fix the failures
<cjwatson> right, and leaving them kicked out is fine
<LocutusOfBorg> but I agree
<cjwatson> IME two days is very ambitious, and relies on builders being otherwise fairly idle, which they won't be
<LocutusOfBorg> the point was to make you aware of the fixes, so expect a transition for yakkety+1 archive opening :)
<cjwatson> it also means basically swamping the build farm to the exclusion of other things
<LocutusOfBorg> sure, I have some scripts that do rmadison and uploads as soon as it is fine
-queuebot:#ubuntu-release- Unapproved: llvm-toolchain-3.6 (yakkety-proposed/main) [1:3.6.2-3ubuntu2 => 1:3.6.2-3ubuntu3] (kubuntu, ubuntu-desktop, ubuntu-server)
<LocutusOfBorg> but I agree, there is no need right now, I was just wondering about making you aware of that fixes.
<LocutusOfBorg> please accept that llvm fix ^^ :) I gave the patch to nacc, it is the usual regex fix to new gcc version
-queuebot:#ubuntu-release- Unapproved: clamav (yakkety-proposed/main) [0.99.2+dfsg-2ubuntu1 => 0.99.2+dfsg-2ubuntu2] (ubuntu-server)
<caribou> FYI, the clamav will rely on llvm-toolchain-3.6 to be available
<LocutusOfBorg> caribou, how? http://launchpadlibrarian.net/288556750/clamav_0.99.2+dfsg-2ubuntu1_0.99.2+dfsg-2ubuntu2.diff.gz
<LocutusOfBorg> -               llvm-3.6-dev,
<LocutusOfBorg> +               llvm-dev [i386 amd64 kfreebsd-amd64 kfreebsd-i386],
<LocutusOfBorg> I see this change
<LocutusOfBorg> this brings 3.8 as default llvm
<caribou> LocutusOfBorg: my fault,
<LocutusOfBorg> ok :) because I tested a no-change rebuild for clamav
<caribou> After preparing the upload, I ran another test & forgot to roll it back
<caribou> (mostly sleepless nights are no good for uploads)
<caribou> :( even my prompt tells me I'm not on the right branch : |default_llvm*|caribou@avogadro:clamav
<caribou> I always forget : can this clamav upload be kicked out so I can re-upload with the same version or do I need to increment it again ?
<santa_> pitti: â would be great if we could the libkf5mailcommon binaries in, so that would unblock more builds
<caribou> "Dear Release Team, could you please disregard the latest upload of clamav which will definitively fail to build"
<pitti> caribou: as long as it's in unapproved it can be rejected and you can reupload with same version number
<pitti> caribou: once it's accepted, the version number is burned
<caribou> pitti: yeah, thought so but wanted to be sue
<caribou> sure
<pitti> caribou: rejected
<caribou> (Man! time to turn on the coffee machine again)
<caribou> pitti: thanks!
-queuebot:#ubuntu-release- Unapproved: rejected clamav [source] (yakkety-proposed) [0.99.2+dfsg-2ubuntu2]
<pitti> santa_: done
-queuebot:#ubuntu-release- New: accepted libkf5mailcommon [amd64] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5mailcommon [armhf] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5mailcommon [powerpc] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5mailcommon [s390x] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5mailcommon [arm64] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5mailcommon [ppc64el] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5mailcommon [i386] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: clamav (yakkety-proposed/main) [0.99.2+dfsg-2ubuntu1 => 0.99.2+dfsg-2ubuntu2] (ubuntu-server)
<LocutusOfBorg> I like this one more :)
<davmor2> cyphermox: give me a ping when you're online dude we need to have a chat about mokutil
-queuebot:#ubuntu-release- Unapproved: zfcpdump-kernel (yakkety-proposed/universe) [4.8-0ubuntu1 => 4.8-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted zfcpdump-kernel [source] (yakkety-proposed) [4.8-0ubuntu2]
<cyphermox> I am online
<santa_> pitti: thanks, I have checked libkscreen autpkgtest and works fine here: http://gpul.grupos.udc.es/things/libkscreen_5.7.5-0ubuntu1_adt.log not sure why it fails on the official server
<cyphermox> davmor2: what's going on?
<davmor2> cyphermox: hey dude, so if I select 3rd party drivers you add a password for mokutils.  On reboot after install you then get a message that says verfication failed(15) Access denied on both hardware and vm
<davmor2> cyphermox: and that is in the blue mokutil screen rather than the black uefi screens
<cyphermox> ok
<cyphermox> oh
<cyphermox> yuck
<cyphermox> slangasek: ^ yay us
<davmor2> cyphermox: you're welcome
<davmor2> cyphermox: want a bug for that?
<cyphermox> yes please
<apw> cyphermox, not the signed binary then ?
<cyphermox> not really sure how we'll fix it though :/
<cyphermox> apw: what do you mean?
<apw> cyphermox, best to ignore me :)
<cyphermox> shim is fine, but we're installing a different shim than the one built, yet installing the MokManager from the shim built from source -- what that means is that shim expects a particular one-time signature for MokManager, and doesn't get it, because we don't have the right stuffs
<cyphermox> I suppose there will be more fudging to do :(
<apw> oh that is harsh
<davmor2> cyphermox: https://bugs.launchpad.net/ubuntu/+source/mokutil/+bug/1631013
<ubot5> Ubuntu bug 1631013 in mokutil (Ubuntu) "When triggering 3rd party driver during an install on reboot you get an error from mokutil" [Undecided,New]
<cyphermox> apw: could you review grub2/grub2-signed from xenial queue?
<davmor2> cyphermox: on a plus side the image boots now :)
-queuebot:#ubuntu-release- Unapproved: cinder (yakkety-proposed/main) [2:9.0.0~rc2-0ubuntu1 => 2:9.0.0-0ubuntu1] (openstack, ubuntu-server)
<cyphermox> heh
<cyphermox> I really would like for MS to just damn well sign our binary now so we could be done with this
<davmor2> cyphermox: yeah but that would be easy and everything
-queuebot:#ubuntu-release- Unapproved: barbican (yakkety-proposed/main) [1:3.0.0~rc1-0ubuntu2 => 1:3.0.0-0ubuntu1] (openstack)
<jderose> pitti: are you working on lp:1626651 already? i'm gonna take a stab at it today, starting with the u-s-d side, but i want to coordinate with you if you're already in progress on it
<jderose> https://bugs.launchpad.net/ubuntu/+source/unity-settings-daemon/+bug/1626651
<ubot5> Ubuntu bug 1626651 in unity-settings-daemon (Ubuntu) "brightness keys are handled slower in Yakkety than Xenial" [High,Triaged]
<pitti> jderose: not yet, too much other things, sorry
<jderose> pitti: nah, don't be sorry :)
<pitti> jderose: the actual fix is trivial (just flipping the pam.d config), the hard part is to ensure it doesn't break anything
<jderose> pitti: yeah, that approach sounded scary to me and i don't have the needed experience there. but i figure i'll dig into the u-s-d side to first better understand what's going on, and hopefully come up with a low-risk solution that at least offers moderate improvement
<pitti> jderose: halving it is easy, by not wrapping the "get" part into pkexec (that doesn't need any privs)
-queuebot:#ubuntu-release- Unapproved: telephony-service (yakkety-proposed/main) [0.1+16.10.20160909.1-0ubuntu1 => 0.1+16.10.20160927-0ubuntu1] (no packageset) (sync)
<pitti> jderose: I actually wonder why this is still being used in the first place -- I had expected most platforms to support XBACKLIGHT
<pitti> and that doesn't need any crazy pkexec helpers in the first place
<jderose> pitti: looking at cking's original report plus the usd code, to me it looks like pkexec is only being used with --set-brightness, not with --get-brigtness or --get-max-brightness. but the later two still do this through calling usd-backlight-helper, so they still spawn a process (just not as heavy as spawning through pkexec)
<pitti> jderose: I thought get would go through pkexec too
<jderose> pitti: i know in some circles, /sys/class/backlight is now the preferred approach. i know gnome-settings-daemon (since usd was forked) as dropped use of xbacklight altogether. but this is problematic because the nvidia proprietary driver only supports xbacklight, no longer supports /sys/class/backlight
<pitti> jderose: oh, I thought XBACKLIGHT was the modern one which can be done through xrandr and thus unprivileged (ICBW)
-queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-3.6 [source] (yakkety-proposed) [1:3.6.2-3ubuntu3]
-queuebot:#ubuntu-release- Unapproved: aodh (yakkety-proposed/main) [3.0.0~rc1-0ubuntu3 => 3.0.0-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- New binary: libkf5calendarsupport [amd64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5calendarsupport [ppc64el] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
<jderose> pitti: as far as i can tell, just the set actions are using pkexec. if you compare backlight_helper_get_value() to backlight_helper_set_value() - http://bazaar.launchpad.net/~unity-settings-daemon-team/unity-settings-daemon/trunk/view/head:/plugins/power/gpm-common.c#L1257
<pitti> jderose: ah, good
<jderose> only the later is wrapping the call with pkexec (seems the comment at the tom of backlight_helper_get_value() is out of date)
-queuebot:#ubuntu-release- New binary: libkf5calendarsupport [i386] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5calendarsupport [arm64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
<jderose> pitti: one thing that stands out to me from cking's forkstat... doesn't it look like usd is doing everything 4 times? 4 for --get-max-brightness, 4 for --get-brightness, 4 for --set-brightness. like maybe instead of getting 1 event, it's getting 4?
-queuebot:#ubuntu-release- New binary: libkf5calendarsupport [armhf] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
<cking> jderose, it did seem like that when I ran it
<jderose> cking: looking at what changed in usd since xenial, nothing stands out as something that could have introduced this. where do the events come from that usd is using? udev?
<cking> no idea where they come from
<cking> i think I tried and older 4.4 kernel and the same thing happened
<cking> *an older
<apw> jderose, the added cost of running pkexec is new i beleive, triggering systemd to do literrally 100s of things
-queuebot:#ubuntu-release- New binary: libkf5calendarsupport [powerpc] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
<jderose> cking: yeah, saw that in your bug report. so thanks for ruling out the kernel :)
<cking> at that point I kinda thought it's something weird in the plumbing layer and I lost hope of fixing it easily
<jderose> cking: something weird somewhere for sure :)
-queuebot:#ubuntu-release- Unapproved: glance (yakkety-proposed/main) [2:13.0.0~rc2-0ubuntu1 => 2:13.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New binary: libkf5calendarsupport [s390x] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
<jderose> cking: did you only notice this around the time you filed the bug, or were you experiencing this for a while before you filed the bug?
<jderose> (just trying to narrow down the timeframe for when this was introduced)
<cking> jderose, about a day or so before it was drawn to my notice by somebody else with a Lenovo X230 so I tried it on my spare lenovo
<cking> so who knows when it started
<jderose> apw: if the root problem pkexec being more expensive, is that something that can be addressed, or are these new expectations too deeply tied in already?
<jderose> cking: okay, thanks
<apw> jderose, i don't think i know, i was just observing when it was being diagnosed, i thought pitti wrote up the issue pretty well
-queuebot:#ubuntu-release- Unapproved: snap-confine (yakkety-proposed/main) [1.0.42-0ubuntu3 => 1.0.43-0ubuntu1] (no packageset)
<jderose> yeah, lots of great information in the bug.
<pitti> jderose: yeah, hence my suspicion that pkexec was being used for get too
<jderose> pitti: yeah, that would have been a nice, easy way to improve things
 * apw is looking at snap-confine
-queuebot:#ubuntu-release- Unapproved: designate (yakkety-proposed/main) [1:3.0.0~rc2-0ubuntu1 => 1:3.0.0-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: python-tooz (yakkety-proposed/main) [1.40.0-1ubuntu1 => 1.43.0-0ubuntu1] (ubuntu-server)
<flocculant> cyphermox: while I was trying things out on xubuntu with different themes (we've got an issue with theme and resize partition window there) I thought I would try Ubuntu using hi-contrast theme - ubiquity crashes - bug 1614848
<ubot5> bug 1614848 in Ubuntu GNOME "ubiquity crashed with GLib.GError in configure_icons(): gtk-icon-theme-error-quark: Icon 'gtk-missing-image' not present in theme Adwaita (0)" [Critical,New] https://launchpad.net/bugs/1614848
<flocculant> our issue is bug 1617711
<ubot5> bug 1617711 in ubiquity (Ubuntu) "Resize screen hard to read" [Undecided,New] https://launchpad.net/bugs/1617711
<cyphermox> ack
-queuebot:#ubuntu-release- Unapproved: accepted snap-confine [source] (yakkety-proposed) [1.0.43-0ubuntu1]
<flocculant> about the only theme you can sensibly see *our* resize window is numix, default is readable if you squint :p
<cyphermox> ah, so it's straight theme fail?
<flocculant> apparently not according to ochosi
<cyphermox> afaik there were some theme changes for gtk
<flocculant> ochosi> flocculant: if hi-contrast doesn't work it's a ubiquity bug, not a theme bug. plain and simple as that.
-queuebot:#ubuntu-release- Unapproved: horizon (yakkety-proposed/main) [3:10.0.0~rc3-0ubuntu1 => 3:10.0.0-0ubuntu1] (openstack, ubuntu-server)
<jbicha> flocculant: how did you catch the gtk-missing-icon crash? does your icon theme not provide that icon?
<cyphermox> flocculant: do you have a screenshot with adwaita? if not, no big deal, I'll pull today's images and look
<flocculant> cyphermox: I can get you whatever you need here pretty quick
<flocculant> as long as it takes to boot a vm
<flocculant> cyphermox: xubuntu using adwaita > http://i.imgur.com/GY1Lyja.png
<cyphermox> thanks
<cyphermox> so clearly not a theme fail, but a ubiquity bug because Gtk
<jderose> pitti: on yaakety, is u-s-d no longer started by upstart? `status unity-settings-daemon` gives me "stop/waiting" on yakkety, but gives me "start/running" on xenial
<flocculant> cyphermox: and with high contrast > just so you've seen it :) http://i.imgur.com/nxSMm0u.png
<cyphermox> such high contrast
<pitti> jderose: no, moved: systemctl --user status unity-settings-daemon.service
<flocculant> jbicha: not a clue - I just ran ubuntu installer with high contrast, it crashed and then pointed me at ^^ bug
<flocculant> though there appear to be icons missing from ubuntu with that theme - like main icons system settings etc in the top menu bar
<jderose> pitti: gotcha, thanks. well i guess that's one key difference between X and Y. can you think of any weirdness that might be introduced by running it under the systemd user session vs upstart?
<pitti> jderose: not really from upstart â systemd; but it could certainly be influenced by the move to dbus-user-session
<pitti> jderose: you can boot with the upstart session by disabling the /usr/share/upstart/systemd-session bit in /etc/X11/Xsession.d/00upstart
<pitti> jderose: i. e. change the condition to "if false && [ "${1#*.target}" != "$1" ]" or comment out that block
<jderose> pitti: okay, i'll give that a quick try for kicks. also, tell me more about this "dbus-user-session" of which you speak, please :D
<pitti> jderose: this moves the dbus instance and user services like gvfs or pulseaudio from being per-session to per-user, i. e. the grpahical session and all VT/ssh logins share the same instance
<jderose> pitti: if i start usd with upstart, will dbus-user-session still be used (sorry, i don't know anything about dbus-user-session)
<pitti> jderose: yes, it will
<pitti> jderose: you can also try to purge dbus-user-session (--force-depeds perhaps)
<pitti> jderose: also, â #u-devel
<jderose> okay, thanks. well, i'll hack around on this for a while, see if i can come up with anything
<jderose> oops, yeah, would be better for #ubuntu-devel i guess :)
-queuebot:#ubuntu-release- Unapproved: heat (yakkety-proposed/main) [1:7.0.0~rc2-0ubuntu1 => 1:7.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: keystone (yakkety-proposed/main) [2:10.0.0~rc2-0ubuntu2 => 2:10.0.0-0ubuntu1] (openstack, ubuntu-server)
<jbicha> flocculant: /usr/share/icons/HighContrast/index.theme
<jbicha> but you ship gnome-icon-theme so that should work
<flocculant> jbicha: what's that for? if you're about ubiquity crashing with high contrast - that was in Ubuntu not Xubuntu
-queuebot:#ubuntu-release- Unapproved: networking-ovn (yakkety-proposed/universe) [1.0.0~rc2-0ubuntu1 => 1.0.0-0ubuntu1] (no packageset)
<jbicha> ok, well humanity-icon-theme ships that icon then
<flocculant> no idea - I was just telling cyphermox what I saw in ubuntu and what we are seeing in xubuntu
-queuebot:#ubuntu-release- Unapproved: accepted networking-ovn [source] (yakkety-proposed) [1.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: snap-confine (xenial-proposed/main) [1.0.42-0ubuntu3~16.04.1 => 1.0.43-0ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: akonadi (yakkety-proposed/universe) [4:16.04.3-0ubuntu1 => 4:16.04.3-0ubuntu2] (kubuntu)
<santa_> pitti: â fix for akonadi autopkgtests uploaded
<pitti> santa_: cheers
<jbicha> flocculant: ubiquity with yakkety unity works here with high contrast
<cyphermox> jbicha: it's all good I've got this covered
<flocculant> cyphermox: thanks
<jbicha> :)
<flocculant> jbicha: ok - I just used the latest daily *shrug*, only did that to check what we're seeing over where I do qa :)
-queuebot:#ubuntu-release- Unapproved: manila (yakkety-proposed/universe) [1:3.0.0~rc1-0ubuntu1 => 1:3.0.0-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: openstack-trove (yakkety-proposed/universe) [1:6.0.0~rc2-0ubuntu1 => 1:6.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted openstack-trove [source] (yakkety-proposed) [1:6.0.0-0ubuntu1]
 * pitti cuts short the glibc tests, 'nuff green
<pitti> will do some manual testing and the hinting when I'm back in ~ 3 h
<apw> pitti, ack
<slangasek> pitti: â¤ check on the version for matching - ugh, you pragmatist :)
<slangasek> pitti: glibc, I see a non-zero number of tests as red, have those all been confirmed to be not glibc's fault?
<apw> slangasek, i have spot checked a few and nothing jumped out, nothing systematic though
<apw> (and we should do something systematic)
 * apw also notes that we are down to just wine causing NBS right now
-queuebot:#ubuntu-release- New: accepted libkf5calendarsupport [amd64] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5calendarsupport [armhf] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5calendarsupport [powerpc] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5calendarsupport [s390x] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5calendarsupport [arm64] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5calendarsupport [ppc64el] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5calendarsupport [i386] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: cpustat (yakkety-proposed/universe) [0.01.27-1 => 0.01.27-1ubuntu0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cpustat [source] (yakkety-proposed) [0.01.27-1ubuntu0]
-queuebot:#ubuntu-release- Unapproved: accepted snap-confine [source] (xenial-proposed) [1.0.43-0ubuntu1~16.04.1]
<bzoltan> hello folks,is here anybody who could ack the rules changes for the UITK release? https://bileto.ubuntu.com/#/ticket/2035
<lamont> anyone reviewing grub2/xenial? (it's the last piece to be able to say is at least in -proposed...)
<bzoltan> pitti: slangasek: maybe ^^
<apw> lamont, there is previous grub2 in the -proposed pocket -- does your base on that or not ?
<lamont> apw: the request is to accept the one that's been sitting in unaccepted all this time
<lamont> apw: specificly cyphermox'  2.02~beta2-36ubuntu3.4 from 3 days ago
<lamont> oh, how about if I actually answer the question... gimme a mo
<cyphermox> apw: 3.4 includes the stuff
<lamont> or let him do that. :D
<apw> lamont, right but does it include the one which is already there, as that is currently marked verfication-fail
<lamont> ta
<cyphermox> yeah, verification-fail because you need the extra patches from 3.4
<lamont> apw: the new one is because I marked the old one failed
<cyphermox> slangasek: you mentioned you had promoted taglibs-standard, no?
<cyphermox> doko was asking me to review the MIR yesterday (and I just did now, anyway)
<slangasek> cyphermox: yes
<lamont> apw: so onece 3.4 lands in porposed, I'll retest and mark the failed as done
<slangasek> cyphermox: it's a straight-swap for jakarta-taglibs-standard (source package rename), I've already demoted that one in exchange
<cyphermox> slangasek: what about the packages that will need to transition to the new binary names eventually?
<apw> cyphermox, perfect thanks
<cyphermox> slangasek: yeah, I know
<slangasek> cyphermox: didn't ever notice there was an MIR, I guess ~ubuntu-mir wasn't subscribed to it so it's not on the report
<cyphermox> seems subscribed to me now *shrugs*
<slangasek> k
<cyphermox> slangasek: I was more asking about did you talk to the server team about the reverse-depends that will eventually need to be updated?
<slangasek> cyphermox: no, because they're not server team packages
<cyphermox> oh
<slangasek> this was the only revdep in main
<cyphermox> ack
<slangasek> bzoltan: hmm, it looks like this is new build system code, and unlike for cmake, bileto doesn't have qmake awareness to include those build system diffs in the 'packaging' diff (robru?) but yes, I'll review them all and ack them
<bzoltan> slangasek:  thank you
<slangasek> bzoltan: so before this change, were these packages not being built with -fstack-protector, etc?
<slangasek> bzoltan: the bad thing about this implementation is that it's hard-coding flags that are supposed to come dynamically from the current toolchain policy.  If the previous behavior was that these flags were not applied /at all/, then it's an improvement and better than nothing.  But if the flags were previously picked up, then nack...
<robru> slangasek: some long time ago train attempted to include build systems in the packaging diff but then at some point it was decided to only care about debian/
<slangasek> robru: it wasn't that long ago; was I part of the discussion to stop including the build systems diff? I might've been and don't remember
<robru> slangasek: i don't remember. It was over a year ago I'm sure. Probably i pushed for the change for simplicity sake and nobody objected
<slangasek> robru: ehm; "nobody objected" is not a valid policy change procedure
<slangasek> since this is a question of what kinds of changes require or don't require sign-off by core-devs before being uploaded to the archive, you should be expecting affirmative assent :)
<bzoltan> slangasek: this was introduced as new flags with this change set - http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/staging/revision/2120
<cyphermox> robru: as I recall the build system diff was there so that we could see whether there really ought to be packaging changes for say, a new build dependency
<robru> slangasek: right, i don't recall all the details, it was quite some time ago. Probably only shortly after Didier left the project.
<robru> cyphermox: yeah that sounds right.
<slangasek> bzoltan: that doesn't answer my question of whether the build previously inherited the correct flags from the environment or not
<slangasek> robru: so my dim recollection is that we dropped this because *if* you're only changing the upstream build system and not changing the debian directory, it doesn't need review; and if you're changing both, there's a packaging diff (which triggers the check), and you have the full diff available for inspection separately if you want it
<robru> slangasek: seems reasonable
<robru> slangasek: yes the full diff is guaranteed to always be available as the packaging diff is created from that
-queuebot:#ubuntu-release- Unapproved: neutron (yakkety-proposed/main) [2:9.0.0~rc3-0ubuntu1 => 2:9.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ironic (yakkety-proposed/universe) [1:6.2.0-0ubuntu2 => 1:6.2.1-0ubuntu1] (openstack)
<bzoltan> slangasek: the dpkg-build flags were correctly applied at package build before and after this change, at packaging build it's actually exactly the same flags before and after, loicm made this change because the dpkg-build flags are stored in qmake mkspecs files (that comes from the qtbase pacakging) and, before this change, were always applied when building the toolkit for development (!debuild) causing a bunch of issues: incompatibility
<bzoltan> with compilers other than GCC, -g forced even in release builds, etc
<bzoltan> slangasek:  so yes, the right flags were applied before, and are still applied now
<slangasek> bzoltan: right, but the difference is now you're *hard coding* the flags in your package, which means that when they change, your package will not follow
<slangasek> bzoltan: and indeed, the hardcoded flags are already different than what we're applying in yakkety today
<slangasek> because we use -fstack-protector-strong in yakkety, but this is not supported by older toolchains
-queuebot:#ubuntu-release- Unapproved: cdist (yakkety-proposed/universe) [4.3.1-2 => 4.3.1-2build1] (no packageset)
<bzoltan> slangasek: yes we are hard-coding the flags, but these hard-coded flags are used only when debian_build is not defined and if you look at debian/rules debian_build is passed to qmake, that allows us to have almost the same flags applied when building the toolkit for development purpose and when it's built on CI, and to spot issues early. The only difference is that these hard-coded flags are applied in a more qmake friendly way. Just when GCC is used,
<bzoltan>  not with -g in release builds, etc
-queuebot:#ubuntu-release- Unapproved: accepted cdist [source] (yakkety-proposed) [4.3.1-2build1]
<clivejo> anyone from the security team here?
<tyhicks> clivejo: hi - someone from the security team will ping you shortly
<sarnold> hi clivejo,tsimonq2
<slangasek> bzoltan: oh - so the flags are only applied when debian_build is /not/ defined, sorry, I missed that nuance.  let me have another look here
<bzoltan> slangasek: yes, precisely ... We were working on making the UITK portable and upstreamable.
<slangasek> bzoltan: thanks, I've confirmed that the yakkety build log shows all the correct flags, so ack on this.  Did you want it published now?
<bzoltan> slangasek:  I would like to, yes please
-queuebot:#ubuntu-release- Unapproved: linux-meta-raspi2 (yakkety-proposed/universe) [4.4.0.1019.19 => 4.8.0.1012.14] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-raspi2 (yakkety-proposed/universe) [4.4.0-1019.25 => 4.8.0-1012.14] (kernel) (sync)
<apw> ^ those are syncing the linux-raspi2 kernel with the main kernel version
<slangasek> bzoltan: button pushed
<bzoltan> slangasek: thank you
-queuebot:#ubuntu-release- Unapproved: ubuntu-ui-toolkit-gles (yakkety-proposed/universe) [1.3.2104+16.10.20160919.3 => 1.3.2135+16.10.20161003.1] (ubuntu-qt-packages) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-ui-toolkit (yakkety-proposed/main) [1.3.2104+16.10.20160919.3 => 1.3.2135+16.10.20161003.1] (ubuntu-desktop, ubuntu-qt-packages) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-snapdragon (yakkety-proposed/universe) [4.4.0-1022.25 => 4.4.0-1029.32] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-snapdragon (yakkety-proposed/universe) [4.4.0.1022.14 => 4.4.0.1029.21] (kernel) (sync)
<apw> ^ those are syncing the linux-snapdragon kernel with the latest in xenial
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-ui-toolkit-gles [sync] (yakkety-proposed) [1.3.2135+16.10.20161003.1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-ui-toolkit [sync] (yakkety-proposed) [1.3.2135+16.10.20161003.1]
<pitti> slangasek: glibc> I went through some of them; doing the rest now
<slangasek> pitti: cheers
<pitti> slangasek: I saw some more fallout from gnupg2, some more flakiness etc., nothign worrisome (from glibc's POV) yet, so looking good so far
-queuebot:#ubuntu-release- Unapproved: cpustat (xenial-proposed/universe) [0.01.25-1 => 0.01.25-1ubuntu0] (no packageset)
 * apw concurs that gnupg2 was fingered in several failures
-queuebot:#ubuntu-release- New binary: libkf5eventviews [ppc64el] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
<pitti> apparently the lxc â lxd move on armhf also caused some fallout
-queuebot:#ubuntu-release- New binary: libkf5eventviews [i386] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5eventviews [arm64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5eventviews [armhf] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5eventviews [amd64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5eventviews [s390x] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5eventviews [powerpc] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
<pitti> slangasek, infinity: added devscripts to https://bugs.launchpad.net/ubuntu/+bugs?field.tag=gnupg2, some unrelated KDE regressions, and just two candidates where I can't exclude glibc right away: ipset and kguiaddons; I retried both; ipset could also be fallout from linux 4.8 (more likely)
<pitti> argh, forgot to request a full langpack export; done now, but I think it's already running
<pitti> wgrant: ^ can you please do a manual run for yakkety?
<pitti> wgrant: actually, given the timestamp I figure today's export failed?
<robru> can somebody reject telephony-service from https://bileto.ubuntu.com/#/ticket/2009 ? I'm redirecting it to overlay ppa instead
-queuebot:#ubuntu-release- Unapproved: conjure-up (yakkety-proposed/universe) [0.2.1 => 2.0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted conjure-up [source] (yakkety-proposed) [2.0.1]
-queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.16+16.10 => 2.16+16.10ubuntu1] (desktop-core, ubuntu-server)
<pitti> slangasek, infinity: hah, ipset and kguiaddons worked on a retry, so no inexplicable regressions -- /me hints in
<slangasek> robru: done
<robru> slangasek: thanks
<slangasek> pitti: \o/
-queuebot:#ubuntu-release- Unapproved: rejected telephony-service [sync] (yakkety-proposed) [0.1+16.10.20160927-0ubuntu1]
<slangasek> pitti: please don't accept the above snapd until the current one clears -proposed (I've just hinted it in)
-queuebot:#ubuntu-release- New binary: conjure-up [amd64] (yakkety-proposed/universe) [2.0.1] (no packageset)
<pitti> slangasek: ack; currently debugging bug 1626651 anyway
<ubot5> bug 1626651 in unity-settings-daemon (Ubuntu) "brightness keys are handled slower in Yakkety than Xenial" [High,Triaged] https://launchpad.net/bugs/1626651
<pitti> gosh, that unapproved queue was empty in the afternoon..
<pitti> well, I plead for "night time, queue is SEP" and stare at that bug :)
-queuebot:#ubuntu-release- Unapproved: neutron-fwaas (yakkety-proposed/main) [1:9.0.0~rc2-0ubuntu1 => 1:9.0.0-0ubuntu1] (openstack, ubuntu-server)
<tsimonq2> sarnold: pong
-queuebot:#ubuntu-release- Unapproved: neutron-lbaas (yakkety-proposed/universe) [2:9.0.0~rc2-0ubuntu1 => 2:9.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron-vpnaas (yakkety-proposed/main) [2:9.0.0~rc2-0ubuntu1 => 2:9.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: policykit-1 (yakkety-proposed/main) [0.105-16 => 0.105-16git1] (core)
<pitti> ^ this is mine; slangasek, Laney, would appreciate a review; the bug trail has the gory explanations, in particular why this is reasonably safe against regressions
<pitti> but I'm happy to explain again if you are unsure, as this is a bit non-obvious
 * pitti waves good night
<cyphermox> ^^^ I *knew* it!
<cyphermox> I'd bet this also fixed ubiquity's pkexec.
<jderose> cyphermox: oh, what's the ubiquity problem with pkexec? don't think i've encountered that
<cyphermox> jderose: because it's only if you try to touch wifi, and I put a workaround in already
<slangasek> santa_: I: libkf5eventviews5: no-symbols-control-file usr/lib/i386-linux-gnu/libKF5EventViews.so.5.2.3
-queuebot:#ubuntu-release- New: accepted libkf5eventviews [amd64] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<jderose> cyphermox: ah, is this when if you connect  to wifi during oem-firstrun, you don't have wifi upon first login?
-queuebot:#ubuntu-release- New: accepted libkf5eventviews [armhf] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5eventviews [powerpc] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5eventviews [s390x] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5eventviews [arm64] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5eventviews [ppc64el] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5eventviews [i386] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<cyphermox> jderose: I don't know, don't think so
<cyphermox> bug # ?
<jderose> cyphermox: okay, sounding promising for a bug we see sometimes... that i still haven't gotten around to filing, but will do tomorrow after i confirm it's still happening on yakkety :)
<cyphermox> ok
<cyphermox> it could be happening, that tends to come up every cycle for a different reason
<cyphermox> I'm kind of hoping we could skip this one though ;)
-queuebot:#ubuntu-release- New: accepted conjure-up [amd64] (yakkety-proposed) [2.0.1]
-queuebot:#ubuntu-release- Unapproved: llvm-defaults (yakkety-proposed/universe) [0.33ubuntu4 => 0.34] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted llvm-defaults [sync] (yakkety-proposed) [0.34]
-queuebot:#ubuntu-release- Unapproved: gnupg2 (yakkety-proposed/main) [2.1.15-1ubuntu4 => 2.1.15-1ubuntu5] (core)
-queuebot:#ubuntu-release- Unapproved: accepted clamav [source] (yakkety-proposed) [0.99.2+dfsg-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-gnome-meta [source] (yakkety-proposed) [0.70]
-queuebot:#ubuntu-release- Unapproved: nova (yakkety-proposed/main) [2:14.0.0~rc2-0ubuntu2 => 2:14.0.0~rc2-0ubuntu3] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted gnupg2 [source] (yakkety-proposed) [2.1.15-1ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-snapdragon [sync] (yakkety-proposed) [4.4.0.1029.21]
-queuebot:#ubuntu-release- Unapproved: accepted linux-snapdragon [sync] (yakkety-proposed) [4.4.0-1029.32]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (xenial-proposed) [2.02~beta2-36ubuntu3.4]
* infinity changed the topic of #ubuntu-release to: Released: Trusty 14.04.5, Xenial 16.04.1, Yakkety final beta2 | Archive: feature freeze, final freeze | Yakkety 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
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (xenial-proposed) [1.66.4]
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.3 => 2.02~beta2-36ubuntu3.4] (core)
<tsimonq2> what's the last part of the topic mean?
<nacc> tsimonq2: "Better the evil that you know"
<tsimonq2> ok good to know :D
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.4 => 2.02~beta2-36ubuntu3.4] (core)
<jderose> nacc: tsimonq2: haha, ""Better the evil that you know", that's great. nice work, infinity! :D
<infinity> jderose: I suspect you can blame Colin for that.
<teward> heh
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (xenial-proposed) [2.02~beta2-36ubuntu3.4]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (xenial-proposed) [2.02~beta2-36ubuntu3.4]
<nacc> so at this point in the cycle, let's says i'm fixing a package in a bug where the fix is also needed in Y. Should I assume it will need to be SRU'd at this point and provide a .1 version? Or can I bump to ubuntu2 safely? I guess given that z isn't open yet, either would be fine due to copy-forward of packages, but what is preferred?
<nacc> *SRU'd into Y itself
<infinity> nacc: Upload to Y with a normal Yish version.
<infinity> nacc: No need for an SRU version scheme.
<nacc> infinity: ok, thanks!
-queuebot:#ubuntu-release- Unapproved: ubuntu-image (yakkety-proposed/universe) [0.6ubuntu3 => 0.7ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (yakkety-proposed) [0.7ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-artwork (yakkety-proposed/universe) [16.10.7 => 16.10.8] (ubuntu-mate)
<flexiondotorg> If someone could accept ubuntu-mate-artwork I really appreciate it :-)
-queuebot:#ubuntu-release- Unapproved: php-arc (yakkety-proposed/universe) [2.2.5-1ubuntu1 => 2.2.5-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted php-arc [source] (yakkety-proposed) [2.2.5-1ubuntu2]
<cjwatson> infinity: nope, that one is slangasek's fault
<cjwatson> I'd gloss it as "better the devil you know"
<nacc> cjwatson: better translation
-queuebot:#ubuntu-release- New binary: libkf5incidenceeditor [ppc64el] (yakkety-proposed/universe) [16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5incidenceeditor [amd64] (yakkety-proposed/universe) [16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5incidenceeditor [armhf] (yakkety-proposed/universe) [16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5incidenceeditor [i386] (yakkety-proposed/universe) [16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5incidenceeditor [s390x] (yakkety-proposed/universe) [16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5incidenceeditor [arm64] (yakkety-proposed/universe) [16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5incidenceeditor [powerpc] (yakkety-proposed/universe) [16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: php-guzzlehttp-ringphp (yakkety-proposed/universe) [1.1.0-2ubuntu1 => 1.1.0-2ubuntu2] (no packageset)
<tsimonq2> fitting for teward, who owns http://dark-net.net/ lol
-queuebot:#ubuntu-release- Unapproved: accepted php-guzzlehttp-ringphp [source] (yakkety-proposed) [1.1.0-2ubuntu2]
<cyphermox> infinity: head's up, I will upload a new shim shortly, we'll need a d-i respin after.
 * teward was pinged
<teward> tsimonq2: hm?
 * teward scrolls up
<teward> oh.  i see.  *goes back to poking his planned nginx merge for z*
<jderose> cyphermox: oh, did you get the sig from MS on the new fixed shim?
<cyphermox> jderose: don't know, fixing an issue with MokManager.
<jderose> cyphermox: okay, gotcha. my ears just perked up at "shim" :P
#ubuntu-release 2016-10-07
-queuebot:#ubuntu-release- New: accepted libkf5incidenceeditor [amd64] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5incidenceeditor [armhf] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5incidenceeditor [powerpc] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5incidenceeditor [s390x] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5incidenceeditor [arm64] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5incidenceeditor [ppc64el] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5incidenceeditor [i386] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (yakkety-proposed) [2:9.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ubiquity (yakkety-proposed/main) [16.10.12 => 16.10.13] (core)
-queuebot:#ubuntu-release- Unapproved: shim-signed (yakkety-proposed/main) [1.21.2 => 1.21.3] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: shim (yakkety-proposed/main) [0.9+1465500757.14a5905.is.0.8-0ubuntu2 => 0.9+1465500757.14a5905.is.0.8-0ubuntu3] (core) (sync)
<doko_> I retried the libreoffice autopkg test triggered by gcc-6, but this looks unrelated to gcc-6. Please could you override it?
<doko_> pitti: ^^^
-queuebot:#ubuntu-release- Unapproved: accepted foomatic-db [sync] (yakkety-proposed) [20161005-1]
<slangasek> cyphermox: the above shim been tested for the MokManager case?
<cyphermox> err, no, woops
 * doko_ curses all these new kde binaries just a few days before release ...
<slangasek> cyphermox: can you test that, so we know for sure before round-tripping all the way to the release? :)
<cyphermox> yeah
<cyphermox> it's trivial to test
<tsimonq2> doko_: it all comes down to lack of developers and Qt 5.6.1 being such a mess
 * cyphermox goes offline for a bit to test this
<tsimonq2> doko_: now that we have another Kubuntu Developer (congrats clivejo!) things will get easier
<tsimonq2> doko_: but yes, we're cursing them too :P
 * tsimonq2 has Kubuntu hat on
<doko_> syq_: please see the update to #835851. can you do this backport?
<doko_> oops, wrong channel
 * doko_ is revealing the super secret Ubuntu mips port ...
<nacc> *finally*
<sarnold> .. maybe we can get ubnt to run on ubuntu? :)
-queuebot:#ubuntu-release- Unapproved: accepted barbican [source] (yakkety-proposed) [1:3.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: xubuntu-default-settings (yakkety-proposed/universe) [16.10.2 => 16.10.3] (xubuntu)
<bluesabre> pitti, the above corrects the backlight slowness in xubuntu
<valorie> doko_: I'll take the curses if we get a working packageset for release
<valorie> the calendar is never our friend, unfortunately
 * valorie puts on the flame-proof underwear
-queuebot:#ubuntu-release- Unapproved: accepted aodh [source] (yakkety-proposed) [3.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted glance [source] (yakkety-proposed) [2:13.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-artwork [source] (yakkety-proposed) [16.10.8]
-queuebot:#ubuntu-release- Unapproved: accepted xubuntu-default-settings [source] (yakkety-proposed) [16.10.3]
-queuebot:#ubuntu-release- Unapproved: accepted designate [source] (yakkety-proposed) [1:3.0.0-0ubuntu1]
<tsimonq2> hmmmm I wonder what machines actually run mips...
<cyphermox> slangasek: now it is tested, mokmanager loads succesfully, and of course the booting works, etc.
-queuebot:#ubuntu-release- Unapproved: accepted python-tooz [source] (yakkety-proposed) [1.43.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: kdepim-addons [amd64] (yakkety-proposed/universe) [16.04.3-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kdepim-addons [ppc64el] (yakkety-proposed/universe) [16.04.3-1ubuntu1] (no packageset)
<cyphermox> oh my, we'll probably have the signed new shim tomorrow.
-queuebot:#ubuntu-release- New binary: kdepim-addons [i386] (yakkety-proposed/universe) [16.04.3-1ubuntu1] (no packageset)
<slangasek> cyphermox: still better than the alternative :)
-queuebot:#ubuntu-release- New: accepted kdepim-addons [amd64] (yakkety-proposed) [16.04.3-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted kdepim-addons [ppc64el] (yakkety-proposed) [16.04.3-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted kdepim-addons [i386] (yakkety-proposed) [16.04.3-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (yakkety-proposed) [3:10.0.0-0ubuntu1]
<cyphermox> slangasek: having the new tomorrow signed on shim?
<slangasek> no, that's the converse
-queuebot:#ubuntu-release- New binary: kdepim-addons [s390x] (yakkety-proposed/universe) [16.04.3-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted akonadi [source] (yakkety-proposed) [4:16.04.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ironic [source] (yakkety-proposed) [1:6.2.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted manila [source] (yakkety-proposed) [1:3.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron-lbaas [source] (yakkety-proposed) [2:9.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (yakkety-proposed) [2:9.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted heat [source] (yakkety-proposed) [1:7.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron-fwaas [source] (yakkety-proposed) [1:9.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (yakkety-proposed) [2:14.0.0~rc2-0ubuntu3]
<slangasek> the alternative is shim.efi -> /etc/alternatives/shim.efi -> /usr/share/.rootkitz/nsa.efi
-queuebot:#ubuntu-release- Unapproved: accepted keystone [source] (yakkety-proposed) [2:10.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron-vpnaas [source] (yakkety-proposed) [2:9.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: kdepim-addons [powerpc] (yakkety-proposed/universe) [16.04.3-1ubuntu1] (no packageset)
<slangasek> ah, someone batch-accepting?
<cyphermox> shh, can't tell people.
<cyphermox> (about the nsa.efi file, i mean)
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (yakkety-proposed) [2.16+16.10ubuntu1]
<slangasek> infinity: were those your accepts above? any reason raspi2 not also accepted?
<slangasek> seems snapdragon went in and raspi2 not, though they have the same rationale from apw
<infinity> slangasek: snapdragon was a simple review, raspi2 needs a bit more time, but it's happening tonight too.
<infinity> slangasek: (the former was a copy forward of an SRU, the latter is a last-minute rebase from 4.4 to 4.8...)
<slangasek> ok
-queuebot:#ubuntu-release- Unapproved: accepted policykit-1 [source] (yakkety-proposed) [0.105-16git1]
-queuebot:#ubuntu-release- Unapproved: accepted shim [sync] (yakkety-proposed) [0.9+1465500757.14a5905.is.0.8-0ubuntu3]
<tsimonq2> cyphermox: shred -n 1000000000 -z nsa.efi && debuild -S -sa && dput ../*source.changes
<tsimonq2> lol
-queuebot:#ubuntu-release- Unapproved: accepted shim-signed [sync] (yakkety-proposed) [1.21.3]
<slangasek> infinity: ^^ that should /not/ need a new d-i upload to pick up for the images, since AFAIK the bits we put on the CD do not include MokManager and the actual shim binary used for CD boot is unchanged
<infinity> slangasek: Kay.  We may need a new d-i for other reasons later anyway, but won't do one for that.
-queuebot:#ubuntu-release- New: accepted kdepim-addons [powerpc] (yakkety-proposed) [16.04.3-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted kdepim-addons [s390x] (yakkety-proposed) [16.04.3-1ubuntu1]
<cyphermox> oh, indeed it wouldn't
<cyphermox> that's good I guess
-queuebot:#ubuntu-release- Unapproved: xubuntu-docs (yakkety-proposed/universe) [16.04.4 => 16.10] (xubuntu)
<bluesabre> ^ Finally got our yakkety docs uploaded
<cyphermox> g'night
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (yakkety-proposed) [16.10.13]
-queuebot:#ubuntu-release- Unapproved: accepted xubuntu-docs [source] (yakkety-proposed) [16.10]
<santa_> slangasek: are you still up?
-queuebot:#ubuntu-release- Unapproved: gnome-photos (yakkety-proposed/universe) [3.22.0-1 => 3.22.1-0ubuntu1] (desktop-extra, ubuntugnome)
<slangasek> santa_: certainly ;)
<valorie> slangasek, the man who never sleeps
<slangasek> well not at 10pm anyway
<valorie> ah, that's my tz too
<slangasek> infinity: why does binutils autopkgtest run now take 2-3x as long on amd64, beginning with the latest glibc upload?
<santa_> slangasek: I wanted to ask you about our next steps with kde packages, we are now in the final freeze, aren't we?
<pitti> doko_: will have a look
<pitti> bluesabre: hm, the polkit change already should fix the backlight?
<slangasek> pitti: I just sorted gcc-6 hinting
<slangasek> santa_: next steps are, do whatever it takes to get these packages into a releasable state
<slangasek> santa_: I just retried the akonadi arm64 build, hopefully that was a random failure rather than a bug
<santa_> slangasek: allright, so we will continue to work on autopkgtest failures to get the things accepted by britney, right?
<slangasek> santa_: yes
<santa_> slangasek: excellent, I have a fix for kwin, if you are willing to sponsor I will prepare a dsc
<slangasek> santa_: please post the link, and if I don't get to it before I drop off, someone in a more European timezone can
<santa_> allright
<santa_> slangasek: regarding akonadi I think it's a race condition when building with -j4, I dind't have time to do a proper research of that, but I think a rebuild will fix it
<slangasek> santa_: ah, so a missing dependency declaration somewhere for a generated header
<slangasek> santa_: kpimtextedit's autopkgtest also appears racy
<slangasek> at least on i386
<santa_> slangasek: the akonadi thing - I think it's a problem in the cmake stuff
<pitti> slangasek: your snapd/ppc64el hint doesn't work; I'll have a look, maybe britney stumbles over the +
<santa_> probable the cmake file for the tests needs adjusting
<slangasek> pitti: the previous hint worked, I *just* updated the version for the new snapd
<santa_> that header is generated automatically by something
<pitti> slangasek: oh, missed the UTC-7, ok :)
<santa_> but I think it's not completely guaranteed that that something happens before the buid of the test
<santa_> slangasek: regarding th current state given by the status page, there are some things stuck on plasma-framework, for instance http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kdeclarative
<santa_> so pressing the update button would help I think
<Mirv> hi! I didn't get e-mail about this rejection, could someone fetch the reason? https://launchpad.net/ubuntu/xenial/+queue?queue_state=4&queue_text=qtbase - just interested if deemed unsuitable for SRU or something wrong in the preparation
<slangasek> Mirv: the reason isn't stored anywhere
<Mirv> ok, I did search all my mailbox and trash though. and not also the rejecter is stored?
<slangasek> Mirv: AFAIK it is not
<Mirv> ok, let's see if someone notices and remebers then
<Mirv> I can see that maybe the code change feels a bit too big with regression potential somewhere despite the unit tests
<slangasek> santa_: I've retried the plasma-framework tests, but they failed pretty consistently across amd64/i386/ppc64el while passing on armhf; this may require harder hinting, pitti should be able to help with that later if it remains an issue
<pitti> Mirv: in practice, I think only me, i_nfinity, s_langasek, L_aney, and a_pw review unapproved (and you just ruled out two); shouldn't be too hard to find out
<pitti> hm, juju's tests have been failing for a while :(
<slangasek> pitti: for xenial, bdmurray and rbasak were certainly doing some SRU processing this week
<pitti> oh, was that SRU, sorry
<slangasek> yeah
<pitti> Mirv: oh, that actually could have been me
<pitti> I remember that I rejected one sync where the origin PPA already got removed
<pitti> so there was no way to review teh package, and I'm not even sure if that actually works (syncing from a removed PPA)
<pitti> ah, we have a hint for juju-core too :(
<Mirv> pitti: no, the PPA is still there https://bileto.ubuntu.com/#/ticket/1964
<Mirv> pitti: oh, robru! why does he say he finalized it by mistake, even though the silo is actually there.
<pitti> Mirv: check the queue item -- clicking on sync leads to https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/1964-deletedppa
<Mirv> but that robru's comment was actually days later regardless
<pitti> Mirv: hm, odd -- that's not what the +queue page leads to
<Mirv> pitti: oh.. so robru deleted the PPA then restored it and rebuilt the binary. right, and the "When" in queue is actually when I uploaded, not when rejected
<pitti> Mirv: ok, that makes sense
<pitti> so you just need to re-sync I figure
<robru> Mirv: same binary. I bincopied it before the ppa was fully removed
<Mirv> robru: oh, ok. but it seems the PPA has different internal id despite the same name so the sync wasn't functional anymore.
<robru> Mirv: interesting to learn that upload queues follow the ppa entity rather than just going by name, which matched
<robru> Yeah
<robru> Mirv: sorry again, i was testing code that prevents finalizing queued uploads and it failed, doh
<Mirv> ok, now it's in the queue again, let's see about its true fate later :)
-queuebot:#ubuntu-release- Unapproved: qtbase-opensource-src (xenial-proposed/main) [5.5.1+dfsg-16ubuntu7.1 => 5.5.1+dfsg-16ubuntu7.2] (kubuntu, qt5, ubuntu-desktop) (sync)
<Mirv> robru: hah! :) no worries.
<slangasek> santa_: akonadi/arm64 looks better this time
<santa_> slangasek: great, here's the proposed fix for kwin http://gpul.grupos.udc.es/sponsor/kwin_5.7.5-0ubuntu2.dsc
<valorie> \o/
<santa_> I had to disable 1 test, just one. I tried so hard but I couldn't figure out a proper environment to get it built
<santa_> I checked upstream code 5.8 but it seems the tests changed so much, so I guess we will drop the patch disabling that test for the next version
<slangasek> santa_: how has this change been tested ? I would not expect 'xvfb-run -a kwin' + 'xvfb-run -a dbus-launch' to put the processes on the same X server
<santa_> slangasek: trial/error with adt-run
<slangasek> hmm
<santa_> I tried various things and got less and less tests failing
<slangasek> I don't think the 'xvfb-run -a kwin &' bit does anything for you
<slangasek> that should spawn a completely separate X server than what's used for dh_auto_test
<santa_> maybe it's unneed, I can recheck
<slangasek> and, I would be concerned about the possibility that on the autopkgtest testbed, this would lead to test timeouts because of dangling processes left behind
<slangasek> (so, it wouldn't be harmless)
<pitti> the testbeds don't care about dangling processes, just the buildds do
<pitti> but starting two different xvfb-runs indeed doesn't make sense
<slangasek> pitti: if they don't care, then I can upload this as-is and let santa_ fix the extra process at leisure
-queuebot:#ubuntu-release- Unapproved: apparmor (xenial-proposed/main) [2.10.95-0ubuntu2.4 => 2.10.95-0ubuntu2.5] (core)
<santa_> I'm testing without the kwin exec btw
-queuebot:#ubuntu-release- Unapproved: kwin (yakkety-proposed/universe) [4:5.7.5-0ubuntu1 => 4:5.7.5-0ubuntu2] (kubuntu)
<santa_> slangasek: another case, I mentioned earlier in this channel that libkscreen autopkgtest is working properly here locally http://gpul.grupos.udc.es/things/libkscreen_5.7.5-0ubuntu1_adt.log
<santa_> any idea about this one?
<pitti> santa_: do you actually test with a qemu testbed?
<pitti> the "cannot connect to wayland" and "segfault" errors don't sound particularly specific to the scalingstack test env
<santa_> pitti: I'm using lxc
<santa_> but I can test with qemu too
 * pitti runs it here for fun too
<slangasek> santa_: where should the wayland server come from within the tests?
<slangasek> maybe the tests work for you in lxc because you have a wayland server running already and the socket is exposed in the container?
<slangasek> but, for instance, xvfb-run won't provide you a wayland server - so my guess is the wayland tests need to be run separately or not at all (depending on whether there's a reliable wayland equivalent to xvfb-run)
-queuebot:#ubuntu-release- Unapproved: accepted kwin [source] (yakkety-proposed) [4:5.7.5-0ubuntu2]
<santa_> slangasek: I'm using an lxc container created with adt-build-lxc, so I doubt I already have a wayland server running there
<slangasek> but you may have one in the host which shows through? or, there may be one started within the container but it relies on getting access to real graphics hardware
<santa_> I doubt it, but as I said I can re-test anything with qemu
<santa_> I stoped using it because there was a concrete package I coudn't get working
<santa_> no because of the package but because qemu timeouted or something like that
<pitti> libkscreen also works here in qemu; so some kind of race condition
<santa_> so, push the retry button?
<pitti> it fails consistently on the infra, that won't work
<santa_> ugh
<santa_> so override it?
<pitti> for now, I'd say yes, bump the override
<pitti> done
 * pitti bumps kwin too
<slangasek> pitti: why does the neutron/s390x failure get an ignore?  openstack is expected to work on s390x, and it seems like the test works /most/ of the time
<pitti> it stopped working reliably in August already
<pitti> and now fails consistnetly
<pitti> I mean, I can unbump the version and leave that one stuck, but I don't think that's going to suddenly raise an interest now :/
<pitti> (and it also regularly blocks a lot of rdeps)
<slangasek> pitti: "fails consistently" for the past 5 runs, but magically worked between 20-9 and 5-10 :)
<slangasek> pitti: I think we need some forcing factor here to make sure those tests are cared for; maybe a critical bug against the openstack packages when this happens
<pitti> ok; IRC pings aren't forceful enough I guess :)
<pitti> I'll file a bug
<pitti> bug 1631260
<ubot5> bug 1631260 in neutron (Ubuntu) "autopkgtest fails on s390x: neutron-server.service failed to start" [Undecided,New] https://launchpad.net/bugs/1631260
<infinity> slangasek: re: binutils autopkgtest, I have no idea, but having a very hard time seeing how glibc would have changed anything there.
<infinity> slangasek: So, I call coincidence.
<slangasek> ok, what else does it coincide with? :)
<pitti> what's wrong with binutils?
<infinity> Changes in scalingstack.
<slangasek> were there changes in SS?
<infinity> There were.  But generally for the better.
<slangasek> pitti: its testsuite started taking 2-3x longer
<slangasek> infinity: ok
<pitti> slangasek: not really - time stamp difference in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/b/binutils/20161006_220952@/log.gz is 3:30 hours
<pitti> slangasek: I figure it was retried two or three times due to intermittent cloud failures
<slangasek> ah
<pitti> a worker auto-retries up to three times on such "tmpfail" issues, then it commits suicide
<pitti> and these three retries add up to the total test time; that's a bit confusing
<infinity> Little bit.
<infinity> Yeah.
<pitti> it's useful for /running (to spot when tests running), but not for the final result
<infinity> THe duration should be of the last test, not the total run.
<pitti> "when tests loop")
<infinity> I want an s390x laptop.
<pitti> filed bug 1631262
<ubot5> bug 1631262 in Auto Package Testing "do not include time for tmpfail retries in result runtimes" [Undecided,New] https://launchpad.net/bugs/1631262
<infinity> And a shawarma.
<infinity> One of those two things will happen in the next half hour.
<pitti> xnox wanted to have an s390x phone in yesterday's meeting -- so how hard can a laptop be then
<infinity> Well, I figure I can cut off a leg and replace it with a lithium-ion prosthetic, and then carry a refrigerating unit on my back.
<slangasek> infinity: iprutils runs 3 daemons out of the box; is that a sensible thing to pull into standard?
<infinity> slangasek: It does?  It didn't used to.  Maybe I live in the past.
<pitti> urgh, priority-mismatches is a pool of sadness
<infinity> slangasek: If the daemons are useful/sane to have on IPR controllers and gracefully don't start in the absence of same, that might be alright.
<infinity> pitti: Yeah, that was my next stop.
<slangasek> infinity: iprupdate, iprdump, iprinit; all are started as part of multi-user.target; I see no sensible disabling
<infinity> pitti: All those py3 modules are curious.
<pitti> darn, and we were so close to kicking perl
<infinity> perl has been in standard off and on forever.
<infinity> I wonder why it fell out.
<pitti> infinity: I actually investigated the lp3lib thing somewhere, hang on
<pitti> that was for a new corner-case feature in software-properties or release-upgrader or so
<infinity> Oh, ick.
<slangasek> infinity: confirmed that they're all running after install on diamond, but it looks like that might actually have ipr so isn't a good test case for auto-disabling
<infinity> Yeah, a VM would be a better test.
<infinity> slangasek: But I'm also curious about why we need them running at all.  Unless the upstream changed drastically, I always used to use iprutils without a daemon to query/config/update controllers.
<infinity> Maybe Colin just enabled them because upstream ships unit files, so why not?
<infinity> slangasek: But, yeah, I don't think I'd be happy with them running on non-IPR systems.  Less opinionated on what's correct for IPR bare metal.
 * infinity -> shawarma.
<pitti> infinity: found the culprit: http://launchpadlibrarian.net/275354292/update-manager_1%3A16.10.2_1%3A16.10.3.diff.gz
<slangasek> infinity: have updated the MIR bug; includes a reference to Red Hat fixing their package to not auto-start unless ipr is present.  Maybe that's been upstreamed and we can take that
<pitti> I wish update-manager could just do that one or two REST calls with urllib, instead of pulling that whole stack ..
<slangasek> infinity: can I leave this to you to figure out from here?
<infinity> pitti: Ugh.  I don't think that's a valuable enough feature to pull lplib into standard, personally.
<infinity> slangasek: I can look after I food.
<slangasek> infinity: ok.  also, it looks perfectly feasible to me to make lsvpd drop its dep on iprconfig, as it should continue functioning in the absence of iprconfig
<infinity> slangasek: Perhaps the better short-term solution.
<slangasek> infinity: cough https://bugs.launchpad.net/ubuntu/+source/lsvpd/+bug/1537116
<ubot5> Ubuntu bug 1537116 in lsvpd (Ubuntu Trusty) "lsvpd: Missing package dependency" [Undecided,Incomplete]
<infinity> slangasek: Well, that's a special bug log.
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-raspi2 [sync] (yakkety-proposed) [4.8.0.1012.14]
-queuebot:#ubuntu-release- Unapproved: accepted linux-raspi2 [sync] (yakkety-proposed) [4.8.0-1012.14]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-photos [source] (yakkety-proposed) [3.22.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: nova (yakkety-proposed/main) [2:14.0.0~rc2-0ubuntu3 => 2:14.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ceilometer (yakkety-proposed/main) [1:7.0.0~rc3-0ubuntu1 => 1:7.0.0-0ubuntu1] (openstack, ubuntu-server)
<jamespage> please could someone reject the nova upload above - I'd like to put in a autopkgtest fix as well to try sort out the current failures
<apw> jamespage, done
<jamespage> apw, ta
<jamespage> xnox had a nice suggestion so trying that
-queuebot:#ubuntu-release- Unapproved: rejected nova [source] (yakkety-proposed) [2:14.0.0-0ubuntu1]
<Laney> he's a useful chap to have around
 * jamespage twiddles thumbs whilst fresh yakkety downloads
<jamespage> gotta love adsl
<apw> he has the giggle factor :)
<Laney> hearing it in my head right now
 * infinity hands Laney some aspirin.
<apw> sorry that was my fault
-queuebot:#ubuntu-release- Unapproved: llvm-toolchain-3.7 (yakkety-proposed/universe) [1:3.7.1-2ubuntu2 => 1:3.7.1-3ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-3.7 [source] (yakkety-proposed) [1:3.7.1-3ubuntu2]
<Laney> let's all have a moment of calm to remember the joy that xnox brings to our lives
<jamespage> urgh
<jamespage> this looks look a pkg ordering resolution issue
<jamespage> nice circular between nova-compute -> nova-compute-kvm -> nova-compute-libvirt -> nova-compute
<jamespage> resulting in nova's membership of libvirt being configured after the daemon is started
<jamespage> yukity yuk
<xnox> Laney, shall i upload gnupg2 for yakkety? enable-ssh-support seems to be broken =/
<Laney> sure, if you've got a fix
<Laney> Reference a bug so it can be punted if necessary
-queuebot:#ubuntu-release- Unapproved: nova (yakkety-proposed/main) [2:14.0.0~rc2-0ubuntu3 => 2:14.0.0-0ubuntu1] (openstack, ubuntu-server)
 * xnox dist-upgrades to latest upload to reverify
<jamespage> apw, OK ^^ is better I think - there is a niggle in the dep order for nova-compute-* things - the test changes make things configure in the right order, but it probably needs more thinking next cycle
<acheronuk> can failing tests of kdeclarative be retried? they seem to be failing against plasma-framework/5.24.0-0ubuntu1 while we now have 5.26
<jamespage> https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1631304
<ubot5> Ubuntu bug 1631304 in nova (Ubuntu) "apt-get install nova-compute has odd configuration order" [Medium,Triaged]
<jamespage> for reference
<acheronuk> same for kxmlgui. tests are failing against plasma-framework/5.24 when there is 5.26 there
<xnox> jamespage, win! \o/
<jamespage> xnox, one of those beggining of time type bugs methinks
-queuebot:#ubuntu-release- Unapproved: llvm-toolchain-3.7 (yakkety-proposed/universe) [1:3.7.1-3ubuntu2 => 1:3.7.1-3ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-3.7 [source] (yakkety-proposed) [1:3.7.1-3ubuntu3]
-queuebot:#ubuntu-release- Unapproved: network-manager-openvpn (yakkety-proposed/main) [1.1.93-1ubuntu1 => 1.2.6-2ubuntu1] (no packageset)
<smb> Hm... shouldn't http://changelogs.ubuntu.com/meta-release contain yakkety by now?
<smb> Just trying to test Xenial to Yakkety release upgrades and "do-release-upgrade -d" acts as there is nothing new
<Odd_Bloke> smb: Changing /etc/update-manager/release-upgrades to have Prompt=normal fixed that for me.
<smb> Odd_Bloke, hm it does. But its odd. I thought "-d" was supposed to override things
<Odd_Bloke> smb: Â¯\_(ã)_/Â¯
<smb> indeed
<xnox> smb, after every LTS release, upgrade-manager reverts to "show me LTS only" and thus -d would work to do xenial -> 18.04 LTS (when in devel)
<xnox> there is gui option to toggle the tickbox too in software sources.
<xnox> clearly, smb, does not read OMG!Ubuntu =)
<smb> xnox, ok... well if you got a gui (server)
<xnox> horum
<xnox> it is a conf file, no idea if there is non text-editor options =/
<smb> xnox, I can perfectly change it as soon as I know its supposed to work like that. Apparently I do not read omg!ubuntu nor did I do that many dist-upgrade tests for a hey-its-a-lts+1-crack-release releases. :-P
<Ukikie> Also upgrades to LTSes reset that var to 'lts'
<xnox> bug 1631320
<ubot5> bug 1631320 in gnupg2 (Ubuntu) "systemd-user cannot connect to gpg-agent ssh-agent" [Undecided,New] https://launchpad.net/bugs/1631320
-queuebot:#ubuntu-release- Unapproved: gnupg2 (yakkety-proposed/main) [2.1.15-1ubuntu5 => 2.1.15-1ubuntu6] (core)
<xnox> Laney, ^
<Laney> xnox: looks right
<Laney> xnox: I think it was always like this
<Laney> at least the internets seems to document using XDG_RUNTIME_DIR
<xnox> Laney, xenial desktop with upstart user session uses /home/xnox/.gnupg/S.gpg-agent.ssh
<Laney> for gpg2?
<xnox> but i think what happened there is that xenial's gpg-agent honoured preset environmental variable (you want it there - you get it there)
<xnox> that's 2.1.11 agent
<xnox> and 2.2 agent is more opinionated - you shall use /this/ socket.
<Laney> anyways :)
-queuebot:#ubuntu-release- Unapproved: accepted gnupg2 [source] (yakkety-proposed) [2.1.15-1ubuntu6]
-queuebot:#ubuntu-release- Unapproved: accepted cpustat [source] (xenial-proposed) [0.01.25-1ubuntu0]
<Laney> xnox: I guess you should fix gpg-agent.conf too
<Laney> (upstart)
<pitti> xnox: does this still actually need the env var at all?
<pitti> xnox: I thought with either XDG_RUNTIME_DIR or GNUPGHOME the path is alwasy the same anyway, so that we can stop having these silly "poke a constant well-known value in to the session env early"
<pitti> and this also works on VT/ssh logins after all, where none of this runs
<pitti> I realize we still need to export those for legacy software which expoects them, but they hsould at least point to the canonical location
<xnox> pitti, nothing to do with GPG agent, has to do everything with SSH_AGENT variables.
<xnox> this is a corner case i use gpg-agent as an SSH agent.
<xnox> pitti, possibly need fixing. on xenial with gpg-agent 2.1 things work with $GNUPGHOME for the enable-ssh-support.
<xnox> but i do not care about gpg-agent ssh integration in yakkety with upstart user session. As far as I understand, e.g. on touch, people can't really use gpg ssh-agent... =/
<xnox> or maybe they can.
<xnox> but i'm not sure why they would. it's no different to using ssh-agent given no support for smartcards.
<Laney> it's not just touch
<Laney> other flavours use upstart
<Laney> I think you should fix the path there too
<jamespage> pitti, hey - are you aware of any changes to the way udev manages perms on devices?  I'm triaging a yakkety specific issue with ceph - basically the ceph/ceph user/group is not being applied via the udev rules afaict
<jamespage> bug 1631328 for context
<ubot5> bug 1631328 in ceph-osd (Juju Charms Collection) "ceph-osd stays blocked on Yakkety: "No block devices detected using current configuration"" [Undecided,New] https://launchpad.net/bugs/1631328
<xnox> Laney, huh? we do have systemd user session everywhere unconditionally as far as I understand. becuase pam logind starts that.
<xnox> (in addition to upstart user session, at times)
<Laney> xnox: gpg-agent.service is started by graphical-session-pre.target.wants/
<xnox> however i don't see gpg-agent started for TTY1 session, and I don't see gpg-agent tty updated upon seat switches.
 * xnox guesses elmo / smb / smoser will kill me if systemd starts spawning gpg-agent left-right-and-center upon tty logins =)
 * smb misses a bit of context but in my world systemd or anything else would just blow up because the keyring won't be there ...
<jamespage> hmm yeah - it appears that the ceph udev rules don't get automatically picked up by udev without a reload?
<caribou> Release Team : LocutusOfBorg has uploaded a fix for llvm-toolchain-3.7 to fix a powerpc FTBS
<caribou> the same fix apply to llvm-toolchain-3.6 which impacts clamav (its only dependency)
<xnox> jamespage, one does need to re-trigger devices to apply newly created rules, that are added after udev spotted a device.
<caribou> debian has just dropped use of llvm for clamav until it can be used with llvm-3.8 so either we do the same for clamav and remove LLVM-36
<jamespage> xnox, yeah just baffled as to why udev is not applying the perms but just spotted something
<xnox> udev is silly
<jamespage> xnox, see last comment in that bug
<acheronuk> can failing tests of kdeclarative be retried? they seem to be failing against plasma-framework/5.24.0-0ubuntu1 while we now have 5.26
<acheronuk>  same for kxmlgui. tests are failing against plasma-framework/5.24 when there is 5.26 there
<apw> acheronuk, is plasma-framework/5.26 in -proposed ?
<acheronuk> apw: yes
-queuebot:#ubuntu-release- Unapproved: supertux (yakkety-proposed/universe) [0.4.0-1 => 0.5.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted supertux [sync] (yakkety-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- Unapproved: magnum (yakkety-proposed/universe) [3.0.0-1 => 3.1.1-0] (no packageset) (sync)
<apw> acheronuk, ok by default each package is tested only with -release pocket packages, it has to be requested manually, trying to find out how :)
-queuebot:#ubuntu-release- Unapproved: accepted magnum [sync] (yakkety-proposed) [3.1.1-0]
<Laney> apw: retry-autopkgtest-regressions --all-proposed will give you the command
<acheronuk> apw: sorry. I am fairly new to this side of the release/migration process. I can just see it they were got to move, a lot else might then get unstuck in response
-queuebot:#ubuntu-release- Unapproved: im-config (xenial-proposed/main) [0.29-1ubuntu12 => 0.29-1ubuntu12.2] (input-methods, kubuntu, ubuntu-desktop)
<apw> Laney, ahh nice
 * apw tries to run the appropriate tests again
<Laney> apw: (or add others as --trigger to just pick those ones)
<Laney> all-proposed is probably easier for KDE stuff though :P
<apw> acheronuk, if we are lucky submitted
<acheronuk> apw: thank you :) if that doesn't resolve it, I'll ask some other kubuntu team members to look again later
<cyphermox> morning!
<pitti> hey cyphermox, how are you?
-queuebot:#ubuntu-release- Unapproved: ceph (yakkety-proposed/main) [10.2.3-0ubuntu1 => 10.2.3-0ubuntu2] (kubuntu, ubuntu-desktop, ubuntu-server)
<cyphermox> bad
<cyphermox> pitti: everytime I do small plumbing repairs I remember why I went in IT
-queuebot:#ubuntu-release- Unapproved: sahara (yakkety-proposed/universe) [1:5.0.0~rc1-1 => 1:5.0.0-1] (openstack) (sync)
-queuebot:#ubuntu-release- Unapproved: zaqar (yakkety-proposed/universe) [3.0.0~b2-1 => 3.0.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted zaqar [sync] (yakkety-proposed) [3.0.0-1]
<Mirv> please be aware of https://bileto.ubuntu.com/#/ticket/2054 (qtbase, workaround from upstream to fix also the different crash on exits, iso-tracker bug) and https://bileto.ubuntu.com/#/ticket/2055 (arm64 QML problem, the fix that is alternative to going back to 4.2 kernel on builders, but the patch may affect other 64-bit platforms too). I'm trying to get QA look into those but the silos are ready
<Mirv> build wise.
<jamespage> could a release team member review my ceph upload - its blocking most of our OpenStack testing on yakkety today so would be nice to get clear
-queuebot:#ubuntu-release- Unapproved: libvirt (yakkety-proposed/main) [2.1.0-1ubuntu8 => 2.1.0-1ubuntu9] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: pandas (yakkety-proposed/universe) [0.17.1-3ubuntu2 => 0.18.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pandas [sync] (yakkety-proposed) [0.18.1-1]
-queuebot:#ubuntu-release- Unapproved: fwts (yakkety-proposed/universe) [16.09.00-0ubuntu3 => 16.09.00-0ubuntu4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libvirt (xenial-proposed/main) [1.3.1-1ubuntu10.4 => 1.3.1-1ubuntu10.5] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: accepted fwts [source] (yakkety-proposed) [16.09.00-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: xen (yakkety-proposed/main) [4.7.0-0ubuntu1 => 4.7.0-0ubuntu2] (kubuntu, ubuntu-desktop, ubuntu-server, virt)
<cjwatson> infinity: Could you test tip of https://anonscm.debian.org/cgit/collab-maint/iprutils.git to see if (a) daemons still come up on systems with ipr and (b) daemons don't come up on systems without ipr?
-queuebot:#ubuntu-release- Unapproved: mistral (yakkety-proposed/universe) [3.0.0~rc1-1 => 3.0.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mistral [sync] (yakkety-proposed) [3.0.0-1]
-queuebot:#ubuntu-release- Unapproved: ironic-inspector (yakkety-proposed/universe) [3.2.0-2 => 4.2.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ironic-inspector [sync] (yakkety-proposed) [4.2.0-1]
-queuebot:#ubuntu-release- Unapproved: murano (yakkety-proposed/universe) [1:3.0.0~rc1-1 => 1:3.0.0-1] (openstack) (sync)
-queuebot:#ubuntu-release- Unapproved: murano-agent (yakkety-proposed/universe) [1:3.0.0~rc1-1 => 1:3.0.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted murano-agent [sync] (yakkety-proposed) [1:3.0.0-1]
<acheronuk> apw: retry seems to have done it ofr kdeclarative if I am not misreading :) can you try for kxmlgui if not done already? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kxmlgui
<acheronuk> seems to be a final blocker ^^
<apw> acheronuk, looking
<apw> acheronuk, submitted
<ahoneybun> acheronuk: final package?
-queuebot:#ubuntu-release- New sync: neutron-dynamic-routing (yakkety-proposed/primary) [2:9.0.0~rc2-1]
<caribou> someone has an opinion on the LLVM-3.6 .vs. clamav upload ?
<pitti> cyphermox: urgh, got disconnected, just got scrollback -- household repairs?
<pitti> cyphermox: and now your kitchen is a swamp?
<cyphermox> no, not that much
<pitti> no wonder IRC had been so quiet in the last hour
<cyphermox> it's barely leaking a drop here and there around the handles, but *any* leakage annoys me, because it's clearly a failure
<pitti> and patching plumbing isn't as easy as in our profession :)
 * pitti does a mass-retry with all-proposed for KDEish stuff, let's see what sticks
-queuebot:#ubuntu-release- Unapproved: chromium-browser (yakkety-proposed/universe) [51.0.2704.79-0ubuntu2~cm1 => 53.0.2785.143-0ubuntu1.1307] (ubuntu-desktop)
<ahoneybun> thanks pitti
<jderose> infinity: fyi, oem-config-gtk isn't installed after doing an OEM install from today's desktop daily. i recall this happening now and then, but i can't remember what you said causes this
<slangasek> cyphermox: trade you a leaky faucet for groundwater seepage in our lower level ;)
<cyphermox> sucks to be you!
<jderose> slangasek: ouch, that sounds rough. where abouts do you live?
<cyphermox> slangasek: is lower level meaning basement, or ground level?
<slangasek> cyphermox: the front is below grade, the back is above grade, so it's a basement when it gives us problems like this
<cyphermox> because to me that sounds like "omg, need to fix the foundation, will cost upwards of 10k, I want to die now"
<slangasek> jderose: Portland
<slangasek> (the bit with high water table and lots of rain)
<davmor2> cyphermox: hey dude shim and mok working today \o/  Haven't tried on hardware will do that shortly
<cyphermox> davmor2: ack, thanks!
<jderose> slangasek: nice. i lived in portland for about 4 years. loved the summers, but eventually decided i personally need more sun, so moved back to colorado :)
<slangasek> jderose: :-)
-queuebot:#ubuntu-release- Unapproved: libsmbios (yakkety-proposed/universe) [2.3.0-0ubuntu1 => 2.3.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted libsmbios [source] (yakkety-proposed) [2.3.1-0ubuntu1]
<caribou> slangasek: seen my prior comment about LLVM-3.6 & clamav ?
-queuebot:#ubuntu-release- Unapproved: libsmbios (xenial-proposed/universe) [2.3.0-0ubuntu1 => 2.3.0-0ubuntu1.1] (no packageset)
<caribou> tl;dr : will upload a fix for LLVM3.6 FTBS on powerpc, then we'll drop LLVM3.6 in Z
<caribou> unless the release team has something against it
<slangasek> caribou: you're asking about whether to patch llvm-3.6 or drop the llvm usage from clamav?
<caribou> slangasek: patch  3.6 as it's been done for 3.7 yesterday
<slangasek> caribou: fixing a build failure is non-controversial
<caribou> slangasek: i know, but you were talking about dropping 3.6 altogether during the meeting,
<caribou> Debian has dropped it in the latest clamav pkg (yesterday) until upstream get support for LLVM 3.8
<slangasek> caribou: well, the question was "why does clamav have its own version".  If the answer is "because it's not ported yet to 3.8 and this is non-trivial", that answers that question
<slangasek> I don't know what dropping llvm support costs us in functionality in clamav; I'm not asking to drop functionality from the package
-queuebot:#ubuntu-release- Unapproved: lsvpd (yakkety-proposed/main) [1.7.7-1 => 1.7.7-1ubuntu1] (no packageset)
<caribou> slangasek: ok, good then; I'll push the 3.6 fix to unblock everything & will take care of the rest during Z
<LocutusOfBorg> I probably will kick llvm-3.6 out of Debian in two days or so
<LocutusOfBorg> please kick it out from Ubuntu if possible
<slangasek> we already have llvm-3.6 in main in xenial, it's not like dropping it before yakkety release gains us anything in terms of support length
<slangasek> dropping it for z will suffice
-queuebot:#ubuntu-release- Unapproved: accepted lsvpd [source] (yakkety-proposed) [1.7.7-1ubuntu1]
<caribou> slangasek: thanks!
<LocutusOfBorg> makes sense, unfortunately 3.7 seems to be failing to build on amd6
<caribou> LocutusOfBorg: if you're ok, I'll upload the powerPC fix monday morning (hate friday's uploads)
<LocutusOfBorg> caribou, I would prefer uploading right now :(
<LocutusOfBorg> I can bother other core-devs in case something breaks
<caribou> LocutusOfBorg: fine with me then src pkg is ready
<caribou> LocutusOfBorg: just doing last minute check & I will upload
<LocutusOfBorg> I hate having fixes for toolchain the week of release
<LocutusOfBorg> :)
<nacc> LocutusOfBorg: i'll be around (and am core-dev now)
<LocutusOfBorg> thanks
<LocutusOfBorg> BTW as soon as this one is over http://debomatic-amd64.debian.net/distribution#unstable/llvm-toolchain-3.6/3.6.2-4/buildlog
<LocutusOfBorg> I'll upload it on Debian, and ask to sync it
<LocutusOfBorg> I took the delta
-queuebot:#ubuntu-release- Unapproved: llvm-toolchain-3.6 (yakkety-proposed/main) [1:3.6.2-3ubuntu3 => 1:3.6.2-3ubuntu4] (kubuntu, ubuntu-desktop, ubuntu-server)
<caribou> LocutusOfBorg: ^^
<LocutusOfBorg> thanks
<pitti> apw: I made an interesting observation in bug 1626436
<ubot5> bug 1626436 in linux (Ubuntu) "[4.8 regression] boot has become very slow" [Medium,Triaged] https://launchpad.net/bugs/1626436
<pitti> I wonder if there's some way to ignore uevents to test this theory
<pitti> sorry, this is #u-devel matter, have this channel in the wrong window
<rcj> yakkety 20161007 live cd on Lenovo x230 and external monitors does not boot to X.  without external monitor I get X but attaching the monitor leads to a 'hall of mirrors' effect outside a certain region of the screen.  Just a heads up, I'm taking more of a look.  Right now have bug #1631349 open
<ubot5> Error: Launchpad bug 1631349 could not be found
<acheronuk> pitti: can kxmlgui test on plasma-framework be re-run with 'retry-autopkgtest-regressions --all-proposed' or whatever the command is? it's failing on plasma-framework 5.24 when we have 5.26 available
<acheronuk> apw kindly tried that with kdeclarative earlier and it seemed to help
<acheronuk> ^^^ or @ slangasek or anyone available who has sec. thank you
<slangasek> acheronuk: pitti mentioned 2 hours ago in here that he was doing a "mass-retry with all-proposed for KDEish stuff", maybe this is already done?
<acheronuk> slangasek: damn. I though I had refreshed the excuses page, but clearly not. now listing both 5.24 & 5.26 and still 'not considered' for some reason http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kxmlgui
 * acheronuk clearly needs more caffination
<acheronuk> slangasek: when I follow the not considered due to dependencies on other things, mostly they seem to lead back after a few levels to that kxmlgui
<slangasek> acheronuk: there appears to be a plasma-framework/ppc64el test still running
<acheronuk> slangasek: my view shows that as regression for 5.24 and absent on that arch for 5.26. neither 'running'
<acheronuk> don't know if you can see something I can't or somewhere I am not looking
-queuebot:#ubuntu-release- Unapproved: cloud-init (yakkety-proposed/main) [0.7.8-14-g94fd35e-0ubuntu1 => 0.7.8-15-g6e45ffb-0ubuntu1] (edubuntu, ubuntu-cloud, ubuntu-server)
<slangasek> acheronuk: http://autopkgtest.ubuntu.com/running
<acheronuk> slangasek: cheers. I am still finding my way around this stuff
<acheronuk> slangasek: that ppc64el test shows no output on that page? is that right? sorry to be a pain :/
<acheronuk> I now with I could learn what's what on this at a slightly calmer time!
<acheronuk> *now wish
<slangasek> acheronuk: there are several stanzas, it's a bit hard to scan that page to spot the right one but the test I was looking at was Release: yakkety Architecture: ppc64el Requester: pitti Triggers: ['mesa/12.0.3-1ubuntu2', 'kxmlgui/5.26.0-0ubuntu1'] All-proposed: 1
<acheronuk> slangasek: yes, I think I found it ok. it's now vanished off that page
 * smoser comes to grovel
<smoser> ah. there it is.
<smoser> Odd_Bloke, noticed an error in the previous upload for cloud-init... it did not actually fixt he issue it reported to
<smoser> his fix he tested and i uploaded.
<jderose> cyphermox: any recent ubiquity changes you can think of that might result in oem-config-gtk not being installed after doing an oem install?
<slangasek> smoser: accepted
<LocutusOfBorg> please accept llvm
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (yakkety-proposed) [0.7.8-15-g6e45ffb-0ubuntu1]
<slangasek> LocutusOfBorg: done
-queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-3.6 [source] (yakkety-proposed) [1:3.6.2-3ubuntu4]
<LocutusOfBorg> thanks
-queuebot:#ubuntu-release- Unapproved: accepted ceilometer [source] (yakkety-proposed) [1:7.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-themes (yakkety-proposed/main) [16.10+16.10.20161005-0ubuntu1 => 16.10+16.10.20161007-0ubuntu1] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: nautilus (yakkety-proposed/main) [1:3.20.3-1ubuntu2 => 1:3.20.3-1ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: oxide-qt (yakkety-proposed/main) [1.17.7-0ubuntu1 => 1.17.9-0ubuntu1] (ubuntu-desktop, ubuntu-qt-packages)
<tyhicks> Hello - I've just sponsored a yakkety oxide-qt upload, on behalf of chrisccoulson, which fixes a number of security issues (see bug #1631448)
<ubot5> bug 1631448 in Canonical System Image "Update to 1.17.9" [Critical,In progress] https://launchpad.net/bugs/1631448
<tyhicks> we'd prefer that it be part of the yakkety release but we can always release it to yakkety-security after the release if it is going to cause too much trouble
<slangasek> jamespage: I'm curious about the change in nova autopkgtests; armhf and s390x both have always run their tests in containers, and don't appear to be /fundamentally/ broken on those archs as they've passed intermittently
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (yakkety-proposed/main) [1.371 => 1.372] (core)
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (yakkety-proposed) [2:14.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted neutron-dynamic-routing [sync] (yakkety-proposed) [2:9.0.0~rc2-1]
-queuebot:#ubuntu-release- New binary: neutron-dynamic-routing [amd64] (yakkety-proposed/universe) [2:9.0.0~rc2-1] (no packageset)
<slangasek> jamespage: I think this ceph upload is wrong; udev rules db is auto-reloaded via inotify, and per the manpage a --reload doesn't change perms on existing devices - I believe you want udevadm trigger --subsystem-match=block --action=change which is the convention used elsewhere
<slangasek> jamespage: (rejected, but happy to discuss)
-queuebot:#ubuntu-release- Unapproved: rejected ceph [source] (yakkety-proposed) [10.2.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (yakkety-proposed) [2.1.0-1ubuntu9]
-queuebot:#ubuntu-release- Unapproved: accepted xen [source] (yakkety-proposed) [4.7.0-0ubuntu2]
<pitti> acheronuk: seems it landed in the meantime
<acheronuk> pitti: indeed. thank you
<pitti> meh, there is just no pleasing this nova/armhf test
<pitti> libvirtError: Failed to connect socket to '/var/run/libvirt/libvirt-sock': Permission denied
<pitti> oh, thanks jamespage, seems your recent upload addresses that
<pitti> jamespage: although that sounds more like forgetting to add some user to some group? it works fine on s390x
<pitti> or rather, "works sometimes" -- there's some race conditino in the startup check
-queuebot:#ubuntu-release- Unapproved: accepted murano [sync] (yakkety-proposed) [1:3.0.0-1]
<jamespage> slangasek, the problem we've seen is that the udev rules get setup without the user/group ownership rules being correctly configured
<jamespage> so when a disk is added, it does not get configured correctly, resulting in a failed bootstrap of the osd unit
<slangasek> jamespage: right, I just read a bit of the bug log... looknig more deeply now
<jamespage> udev reads via inotify, but the user/group is not setup at that point so we end up with ineffect a broken set of udev rules without the reload
<jamespage> potentially not setup
<jamespage> pitti, I think the nova thing is a bit of a victim of Restart=Always
<jamespage> slangasek, pitti: I think it would be possible to drop the container check for nova
<jamespage> the other changes in the upload should fix the test consistently across archs
<slangasek> jamespage: another option for ordering would be to create the user/group in preinst, which would be before udev rules are unpacked :)
<slangasek> semantically, there's lots of precedent for that
<pitti> meh, I have not the slightest idea why perl/rename are on http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt -- they just depend on each other, but nothing depends on them
<slangasek> jamespage: but where are your user/group created?
<jamespage> slangasek, ceph-common postinst
<slangasek> ok
<jamespage> the user/group is requires more generally than for the udev rules
<pitti> preinst is a bit ugly, though -- you need a Pre-Depends: adduser then
<slangasek> jamespage: in which case, ceph-osd Pre-Depends: ceph-common would have this same effect
<pitti> that sounds better indeed
<slangasek> pitti: but is it better to just always do things in the right order, rather than doing them once and then having to fix up a second time?
<jamespage> pitti, context on the other nova test changes - https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1631304
<ubot5> Ubuntu bug 1631304 in nova (Ubuntu) "apt-get install nova-compute has odd configuration order" [Medium,Triaged]
-queuebot:#ubuntu-release- Unapproved: sahara (yakkety-proposed/universe) [1:5.0.0~rc1-1 => 1:5.0.0-1] (openstack) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted neutron-dynamic-routing [sync] (yakkety-proposed) [2:9.0.0-1]
-queuebot:#ubuntu-release- New binary: neutron-dynamic-routing [amd64] (yakkety-proposed/universe) [2:9.0.0-1] (no packageset)
<infinity> jderose: That usually meant the versions are out of sync.
<rcj> slangasek, infinity: If I find a critical issue with the yakkety daily desktop livecd (no X if external display attached) is there anything else I can do to get eyes on it other than filing the bug and marking it @ http://iso.qa.ubuntu.com/qatracker/milestones/360/builds/132831/testcases/1497/results
<slangasek> rcj: contact the desktop team, but they're EU-centric so a bit EOW right now; so maybe an email to ubuntu-desktop?
<rcj> slangasek, thanks
<stokachu> slangasek: when will the archive be frozen?
<infinity> stokachu: Yesterday.
<stokachu> infinity: when will it be unfrozen (typically)
<infinity> stokachu: After we open ZZ.  So, no less than a week, possibly more, it fluctuates.
<stokachu> infinity: thanks
<slangasek> stokachu: what is it you're actually trying to do, that you're asking about the freeze?
<stokachu> slangasek: well we were trying to get juju rc3 into yakkety as rc2 was failing adt tests because of lxd api changes
<stokachu> looks like they'll have to wait until the archive opens again and go from there
<infinity> stokachu: Is rc3 bugfixes over rc2?
<stokachu> infinity: yea
<infinity> stokachu: If so, they should be uploading, and we'll review and see if we want to let it in.
<infinity> stokachu: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2016-October/001195.html
<stokachu> ok ill work with them to try and get that done
<infinity> stokachu: See point 2.
<stokachu> infinity: perfect thanks
<slangasek> infinity: chromium-browser hits ubuntukylin; any concerns about pulling in the (security) upload currently in the queue before mastering their image?
<infinity> slangasek: Nope.
<infinity> slangasek: I'll be uncronning and doing a full set for everyone later tonight so we can get some weekend testing to make us cry on Monday.
<infinity> slangasek: So if you want to squeeze it in before that, go for it.
-queuebot:#ubuntu-release- Unapproved: accepted chromium-browser [source] (yakkety-proposed) [53.0.2785.143-0ubuntu1.1307]
<infinity> slangasek: Oh, and I don't think I'm going to bother britney-blocking until Monday, since these weekend images are purely for testing, I have zero confidence or intent for them to be the final images.
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-themes [sync] (yakkety-proposed) [16.10+16.10.20161007-0ubuntu1]
<slangasek> infinity: ok. there was at least one upload in the unapproved queue that I think should not be accepted into release but could be a candidate for SRU (network-manager-openvpn); how do you want that handled?
<infinity> slangasek: A new upstream?  Fun.
<infinity> Though, I suppose a reasonably "small" diff for a new upstream release.
<slangasek> infinity: yes, /could/ be a candidate for SRU - I haven't dug too deeply, just deeply enough to know I don't like it for release
-queuebot:#ubuntu-release- New: accepted neutron-dynamic-routing [amd64] (yakkety-proposed) [2:9.0.0-1]
-queuebot:#ubuntu-release- New: accepted neutron-dynamic-routing [amd64] (yakkety-proposed) [2:9.0.0~rc2-1]
<infinity> slangasek: Well, feel free to make a call about if you absolutely think it's an SRU candidate.  If so, paperwork, and accept, and an individual block (or block-proposed on the bug) would be fine.
<infinity> slangasek: And if we later re-review it and decide that, no, maybe we can stuff it in release afterall, easy to flip that switch.
<infinity> If you filter out all the po and autotools vomit, it's not actually a huge diff.
<infinity> With solid enough justification and a test plan, it might be suitable for release.
<infinity> Maybe.
<infinity> Oh, and a file move or two.  We need a diff that tracks that somehow.
<infinity> Which implies a patch that could read that format.
<infinity> So that'll never happen.
<slangasek> infinity: ok. for the moment I'll add the block hint and handwave the rest.
<jbicha> yeah, openvpn was stuck in the sponsoring queue for a week, but that's not really y'all's fault
<acheronuk> slangasek: britney-blocking = no more migration from proposed-release I assume?
<slangasek> acheronuk: it means only things manually reviewed and accepted migrate
<acheronuk> slangasek: thanks
<slangasek> acheronuk: seems akonadi tests pass now but only on amd64? with timeouts on ppc64el and armhf
<acheronuk> santa_: ^^^^
<acheronuk> slangasek: ok. thanks.
<santa_> I take note I will be back to work soon
-queuebot:#ubuntu-release- Unapproved: clearlooks-phenix-theme (yakkety-proposed/universe) [6.0.3+git20161006-1 => 7.0-1] (no packageset) (sync)
<acheronuk> santa_: appreciate that very much. next time it won't be so bad, and we should be able to help more
-queuebot:#ubuntu-release- Unapproved: accepted clearlooks-phenix-theme [sync] (yakkety-proposed) [7.0-1]
-queuebot:#ubuntu-release- Unapproved: isenkram (yakkety-proposed/universe) [0.27 => 0.28] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted isenkram [sync] (yakkety-proposed) [0.28]
<slangasek> TypeError: cannot astype a datetimelike from [datetime64[ns]] to [bool]
<slangasek> I'll take "errors I am not going to bother trying to debug" for $400, Alex
<sarnold> boolean time
<slangasek> acheronuk, santa_: kdepim-runtime has a reproducible, cross-architecture autopkgtest failure; I don't know if this is bad code or bad test; maybe it's already on your todo list
<santa_> slangasek: probably bad test, yes it's under the radar
<acheronuk> santa_: under?
<infinity> Stealth test.
<santa_> acheronuk: IN. sorry
<acheronuk> ok :)
<slangasek> hahaha love the kdepim autopkgtest
<slangasek> acheronuk, santa_: badpkg: debian/tests/testsuite does not exist
<slangasek> (after a 1.5h rebuild on the autopkgtest testbed, since 'Restrictions: build-needed' is also set)
<acheronuk> whut?
<slangasek> acheronuk: http://autopkgtest.ubuntu.com/packages/k/kdepim/yakkety/amd64 debian/tests/control was added but debian/tests/testsuite is not there
<slangasek> in kdepim
<slangasek> so that wastes a lot of build time for a test that doesn't exist
<slangasek> (to be fair, autopkgtest ought to detect this itself earlier, /before/ it spends time building)
 * acheronuk looks for a brick wall to bang head against
<slangasek> acheronuk, santa_: and ktp-call-ui depends on kde-telepathy-declarative, a binary package previously built from ktp-common-internals that was removed after vivid
-queuebot:#ubuntu-release- Unapproved: rejected sahara [sync] (yakkety-proposed) [1:5.0.0-1]
<acheronuk> slangasek: so that http://paste.ubuntu.com/23291142/
<slangasek> acheronuk: ok, so ktp-call-ui needs updated to reference that new name?
<acheronuk> slangasek: possibly. It's nearly midnight here and my ability to investigate is somewhat... erm... degraded
<slangasek> ok :)
<acheronuk> it is noted though :)
-queuebot:#ubuntu-release- Unapproved: kcoreaddons (yakkety-proposed/universe) [5.26.0-0ubuntu1 => 5.26.0-0ubuntu2] (kubuntu)
<clivejo> infinity: ^^ thats the security update
-queuebot:#ubuntu-release- Unapproved: accepted kcoreaddons [source] (yakkety-proposed) [5.26.0-0ubuntu2]
<infinity> clivejo: ^^ that's me accepting it
<valorie> yay!
<clivejo> infinity: thanks :)
<infinity> And this is me going to find a pizza.
 * infinity -> pizza.
<sarnold> mmmm pizza
<clivejo> mmmmm pizza
<clivejo> ah sarnold, are you Seth?
<sarnold> clivejo: I'm _a_ Seth anyway
<slangasek> vv infinity reappearing after pizza
<clivejo> the one who commented on LP 1630700 ?
<ubot5> Launchpad bug 1630700 in kcoreaddons (Ubuntu) "CVE - KMail - HTML injection in plain text viewer" [High,In progress] https://launchpad.net/bugs/1630700
 * acheronuk suffer pizza envy
<acheronuk> suffers
-queuebot:#ubuntu-release- Unapproved: update-notifier (yakkety-proposed/main) [3.174 => 3.175] (ubuntu-desktop, ubuntu-server)
<clivejo> acheronuk: me too, but it is 00:15 and if I ate pizza now Id suffer all night!
<bdmurray_> slangasek: that's the update-notifier we talked about
<sarnold> clivejo: yes :)
-queuebot:#ubuntu-release- Unapproved: accepted sahara [sync] (yakkety-proposed) [1:5.0.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (yakkety-proposed) [1.372]
<Ukikie> clivejo: He's got his gecos set correctly and everything too.  (/who sarnold)
<santa_> slangasek: working on kdepim-runtime and ktp-call-ui. so another topic while the code builds: I tested kwin without that kwin call in the testsuite, do you remember? well, aparently it need it, without it I got this: http://gpul.grupos.udc.es/things/kwin_5.7.5_modified_adt.log
<santa_> * it needs it
-queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (yakkety-proposed) [3.175]
<slangasek> santa_: hmm. I think that's probably a bad test then, but that's for another time
<santa_> yeah, we laredy have a lot piling up, but I think we will get everything in time
<santa_> I'm officially living in my own timezone by the way
<slangasek> infinity: have gotten around finally to look at oxide-qt; looks like this may take up to 7h to build, but we should still take it sooner rather than later, so accepting for opportunistic inclusion in images or diversion to SRU queue
-queuebot:#ubuntu-release- Unapproved: accepted oxide-qt [source] (yakkety-proposed) [1.17.9-0ubuntu1]
<tyhicks> thanks and sorry about the late upload
#ubuntu-release 2016-10-08
<infinity> slangasek: Okay.  We're uncronned now.  I'll see how things settle over the next few hours and spin a full set before the end of the day.
<infinity> slangasek: And toss out a call for testing when that's in progress.
<santa_> slangasek: hi, we got a fix by ktp-call-ui, it was uploaded to the archive but it got rejected because apparently ktp-call-ui isn't part of the kubuntu packageset, who should we ask to correct the packageset and put it under our 'protection'?
<santa_> s/we got a fix by ktp-call-ui/we got a fix for ktp-call-ui/
-queuebot:#ubuntu-release- Unapproved: kdepim (yakkety-proposed/universe) [4:16.04.3-0ubuntu1 => 4:16.04.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: juju-core (yakkety-proposed/main) [2.0~rc2-0ubuntu1.16.10.1 => 2.0~rc3-0ubuntu1.16.10.1] (ubuntu-server)
<slangasek> santa_: hmm I believe the DMB has the authority to decide on packagesets.  ktp-call-ui doesn't currently appear to be seeded in kubuntu, though, so I'm not sure whether it's truly a "mismatch" currently?
<santa_> slangasek: well it's clearly a mismatch since it's a package which is part of the "KDE Applications" collection and it's maintained by us, how can I contact the DMB?
<santa_> slangasek: oh btw. trivial fix for kdepim in the upload queue
<slangasek> santa_: official contact address, developer-membership-board@lists.ubuntu.com.  Maybe this is something that infinity could help with quickly, if it's that simple (since he's on the DMB)
<santa_> ok, if we don't get it sorted out quickly I guess you could upload it, right?
<slangasek> yes
<santa_> ok, I'm working on the remaining issues reported by mrs spears
-queuebot:#ubuntu-release- Unapproved: accepted kdepim [source] (yakkety-proposed) [4:16.04.3-0ubuntu2]
<santa_> slangasek: still awake? if not I will come up with some stuff tomorrow, I will go to bed soon
<acheronuk> santa_: you were not kidding about a personal timezone!
<santa_> NO
<santa_> "fortunately" I don't have a job yet
<acheronuk> even still, I am grateful for your effort
<santa_> thank you :)
-queuebot:#ubuntu-release- Unapproved: accepted juju-core [source] (yakkety-proposed) [2.0~rc3-0ubuntu1.16.10.1]
-queuebot:#ubuntu-release- Unapproved: python-django-openstack-auth (yakkety-proposed/main) [2.4.0-0ubuntu1 => 2.4.1-2] (ubuntu-server) (sync)
<acheronuk> morning. can the s390x test on kde-cli-tools be retried? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kde-cli-tools
<acheronuk> looks like maybe a builder error?
-queuebot:#ubuntu-release- Unapproved: accepted nautilus [source] (yakkety-proposed) [1:3.20.3-1ubuntu3]
<slangasek> acheronuk: it already failed twice in a row the same way; doesn't seem likely that a third retry will matter
<slangasek> acheronuk: but the previous version had failing tests on all archs, so I'll override
<acheronuk> slangasek: ok. thank you
<acheronuk> hmmm. kcoreaddons looks distinctly unhappy :/
<slangasek> those may be testbed issues
<slangasek> and there are a number of waiting tests
<acheronuk> yes, I just saw the running ones. for later then
<infinity> pitti: Did we get fresh langpacks for release?
-queuebot:#ubuntu-release- Unapproved: base-files (yakkety-proposed/main) [9.6ubuntu4 => 9.6ubuntu5] (core)
-queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (yakkety-proposed) [9.6ubuntu5]
-queuebot:#ubuntu-release- Unapproved: llvm-toolchain-3.7 (yakkety-proposed/universe) [1:3.7.1-3ubuntu3 => 1:3.7.1-3ubuntu4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-3.7 [source] (yakkety-proposed) [1:3.7.1-3ubuntu4]
-queuebot:#ubuntu-release- Unapproved: gnome-boxes (yakkety-proposed/universe) [3.22.0-1 => 3.22.1-0ubuntu1] (desktop-extra)
<santa_> good morning
<santa_> slangasek: I see modemmanager-qt had an acc failing test, but passed trough britney, have you override it?
<santa_> in any case, https://paste.kde.org/pfjnlxv5f does this look sane to fix the issue)
<santa_> ?
<acheronuk> santa_: I think slangasek is on the US west coast, so may be asleep now
<santa_> no prob I can rest/work on the remaining issues
-queuebot:#ubuntu-release- Unapproved: aspectc++ (yakkety-proposed/universe) [1:2.1-1 => 1:2.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted aspectc++ [sync] (yakkety-proposed) [1:2.1-2]
-queuebot:#ubuntu-release- Unapproved: freemat (yakkety-proposed/universe) [4.2+dfsg1-1ubuntu1 => 4.2+dfsg1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: oclgrind (yakkety-proposed/universe) [15.5-4build2 => 15.5-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: afl (yakkety-proposed/universe) [2.33b-4 => 2.34b-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: irony-mode (yakkety-proposed/universe) [0.1.2-2 => 0.2.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted afl [sync] (yakkety-proposed) [2.34b-2]
-queuebot:#ubuntu-release- Unapproved: accepted irony-mode [sync] (yakkety-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted freemat [sync] (yakkety-proposed) [4.2+dfsg1-2]
-queuebot:#ubuntu-release- Unapproved: accepted oclgrind [sync] (yakkety-proposed) [15.5-5]
-queuebot:#ubuntu-release- Unapproved: ostree (yakkety-proposed/universe) [2016.10-1 => 2016.11-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ostree [sync] (yakkety-proposed) [2016.11-1]
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Yakkety Final] (20161008) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Yakkety Final] (20161008) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Yakkety Final] (20161008) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Yakkety Final] (20161008) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base powerpc [Yakkety Final] (20161008) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Yakkety Final] (20161008) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Yakkety Final] (20161008) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Yakkety Final] (20161008) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate powerpc [Yakkety Final] (20161008) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Yakkety Final] (20161008) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Yakkety Final] (20161008) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Yakkety Final] (20161008) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Yakkety Final] (20161008) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server powerpc [Yakkety Final] (20161008) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Yakkety Final] (20161008) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Yakkety Final] (20161008) has been added
<acheronuk> cw
<acheronuk> whoops
<acheronuk> release team: krunner armhf test on libqapt has been 'test in progress' for a least the last 7hrs  http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#krunner
<acheronuk> kcmutils is failing a test against kde-cli-tools 5.7.2 when there is a new version 5.7.5 now
<acheronuk> kcmutils also seems to have a hung test on amd64 kleopatra
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Yakkety Final] (20161008) has been added
<acheronuk> slangasek said this morning that remaining kcoreaddons test regressions were likely test bed issues. if you concur can you please hint through or override etc
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Yakkety Final] (20161008) has been added
-queuebot:#ubuntu-release- Unapproved: ceph (yakkety-proposed/main) [10.2.3-0ubuntu1 => 10.2.3-0ubuntu2] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Yakkety Final] (20161008) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Yakkety Final] (20161008) has been added
<jamespage> slangasek, ^^ ceph with pre-depends rather that post-inst reload of udev
<jamespage> tested ok in ppa
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Yakkety Final] (20161008) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Yakkety Final] (20161008) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Yakkety Final] (20161008) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Yakkety Final] (20161008) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Yakkety Final] (20161008) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Yakkety Final] (20161008) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Yakkety Final] (20161008) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop powerpc [Yakkety Final] (20161008) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Yakkety Final] (20161008) has been added
<tsimonq2> infinity: nice last paragraph of that email :D :P
-queuebot:#ubuntu-release- Unapproved: kdepim-runtime (yakkety-proposed/universe) [4:16.04.3-0ubuntu2 => 4:16.04.3-0ubuntu3] (kubuntu)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Yakkety Final] (20161008) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Yakkety Final] (20161008) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Yakkety Final] (20161008) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Yakkety Final] (20161008) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop powerpc [Yakkety Final] (20161008) has been added
<slangasek> santa_: modemmanager-qt was overridden because it was not a regression, yes. I don't know if your fix is reasonable as I know roughly nothing about the acc tests
<slangasek> acheronuk: as of last night, the test failures shown for kcoreaddons were testbed issues; now, there are new test results, including new failures that should be investigated
<santa_> slangasek: ok. aabout the remaining things: 1st of all, we got a fix for kdepim-runtime
<santa_> it was a problem in the test itself, so I just applied an upstream commit
<slangasek> jamespage: so what about the issue that the newly-unpacked ceph udev rules are not applied to existing device nodes? Is that not important?
<slangasek> jamespage: (accepting, but the fix looks incomplete to me)
-queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (yakkety-proposed) [10.2.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kdepim-runtime [source] (yakkety-proposed) [4:16.04.3-0ubuntu3]
<acheronuk> slangasek: can the tests I mentioned earlier that seem to be stuck running be budged?
<slangasek> santa_: kdepim-runtime accepted, and since we know it's a bad test I've also hinted it through in case that works out better
<slangasek> acheronuk: looking now
<santa_> slangasek: ok, thank you very much, and I think this might be one the last real problems: kdelibs4support; it has 2 problems
<santa_> 1. the testsuite is failing consistently
<santa_> 2. the acc test is failing consistently
<santa_> to fix the acc test I already commited something to our git
<slangasek> acheronuk: retried
<acheronuk> slangasek: thx :)
<santa_> however I don't have a fix for the testsuite, and I checked the upstream git + executing the tests in a vm (not in the autopkgtest environment) with my kde developer hat on. I still got them failing
<santa_> to good news is that this is not a regression compared with 5.24
<slangasek> santa_: yes, if the conclusion is the kdelibs4support testsuite is bad, I have no problem hinting that in
<santa_> slangasek: not exactly, I don't have a conclusion yet about the failure, however it was failing in 524 as well so I see no point in keeping 5.26 in -proposed
<santa_> slangasek: so yes, my proposal is: let us upload a fix for the acc test, the testsuite is going to fail, but hint it to get it out of -proposed
<slangasek> ok
<slangasek> santa_: hint added
<santa_> thank you very much
<santa_> slangasek: so regarding the remaining issues I think it's just a matter of retrying unless I'm missing something, for instance I would retry the akonadi tests http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#akonadi
<santa_> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kdepim
<santa_> â kdepim too
<acheronuk> santa_: any idea on the kcmutils failing test? just one on i386 :/ http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kcmutils
<santa_> acheronuk: it's kde-cli-tools what's failing, not kcmutils
<acheronuk> santa_: yes, that's what I mean. blocking kcmutils to be more accurate
<santa_> I would retry it
<acheronuk> I think slangasek just did and it failed
<ginggs_> hi, would someone in ubuntu-release look at a wine-development merge FFe please? LP: #1630763
<ubot5> Launchpad bug 1630763 in wine-development (Ubuntu) "FFe: Merge wine-development 1.9.20-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1630763
<slangasek> santa_: the akonadi test has been retried on !amd64 and failed three consecutive times with the same error (and takes 6h+ to time out while doing so); I'm not going to retry those anymore
<tsimonq2> santa_: I'll do that locally to confirm then
-queuebot:#ubuntu-release- Unapproved: kdelibs4support (yakkety-proposed/universe) [5.26.0-0ubuntu1 => 5.26.0-0ubuntu2] (kubuntu)
<clivejo> santa_: ^
<slangasek> santa_: kdepim is also failing on multiple architectures with the same problem (sqlite test failures), why do you expect this to work on a retry?
<slangasek> ginggs_: not me; we have a backlog of KDE stuff to get through -proposed for image mastering, so I'm personally considering the FFe queue closed
<ginggs_> slangasek: np
<slangasek> stokachu, cyphermox: autopkgtest results for juju-core 2.0~rc3 seem worse now?
<santa_> slangasek: ack, so any suggestion? both kdepim and akonadi autopkgtests work fine here locally
<santa_> clivejo: thanks
<clivejo> you're very welcome
<stokachu> slangasek: it failed? we ran tests in their lab and i ran the autopkgtests locally as well
<stokachu> ugh wth
<slangasek> santa_: you probably need to test them on other archs to reproduce; if that's not tractable for release, then we'll have to override
<stokachu> slangasek: autopkgtest -U ../juju-core_2.0~rc3-0ubuntu1.16.10.1.dsc -- qemu ~/autopkgtest/autopkgtest-yakkety-amd64.img  --ram-size 6000 this is what i ran
<stokachu> and it passed for me and in their qa lab
<slangasek> stokachu: ok, looking at the errors
<slangasek> stokachu: Fetching Juju agent version 2.0-rc3 for amd64 // autopkgtest [11:40:04]: ERROR: timed out - if that's accurate, we may be looking at a regression in the testbed's firewall?  or in the support for the proxy environment variables?
<slangasek> stokachu: I'm guessing you probably don't test with firewall + squid proxy (see top of log for proxy settings)?
<stokachu> slangasek: yea this was without any firewall/proxy setup
<stokachu> slangasek: does the test runner have access to squid.internal:3128?
<stokachu> i can try to find a machine on that network to re-run the test with, im not sure where the juju qa lab sits either
<santa_> slangasek: ack, I'm going to try an i386 lxc
<stokachu> doesn't look like any of those proxy settings exist in their ci setup scripts
<stokachu> also im getting hit with the hurricane so if i don't respond the power went out
<jamespage> slangasek, my take is that is unrelated to the bug fixed - this is not a new udev rule for yakkety (already in xenial, where we don't have the same udev loading rules without groups race issue)
<jamespage> thanks for accepting the upload
<stokachu> slangasek: odd because fomr of the other tests pass when attempting to bootstrap, see 14:34:24
<stokachu> some*
<slangasek> stokachu: do those bootstraps both pull from the same server? I would guess that the lxd bootstrap pulls the standard lxd image from the normal place
<slangasek> stokachu: who should I talk to about this if your power does go out?
-queuebot:#ubuntu-release- Unapproved: mandos (yakkety-proposed/universe) [1.7.11-1 => 1.7.12-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mandos [sync] (yakkety-proposed) [1.7.12-1]
-queuebot:#ubuntu-release- Unapproved: pidgin (yakkety-proposed/universe) [1:2.10.12-0ubuntu8 => 1:2.10.12-0ubuntu9] (kubuntu)
<tsimonq2> slangasek: could we please get eyes on kdelibs4support?
<tsimonq2> (going off of this:)
<tsimonq2> 12:10:19 PM < santa_> slangasek: so yes, my proposal is: let us upload a fix for the acc test, the testsuite is going to fail, but hint it to get it out of  -proposed
<santa_> tsimonq2: it's already overriden, as we agreed, no need to poke people about that
<santa_> tsimonq2: to be more specific, if you look here: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kdelibs4support you will see this line:
<santa_> autopkgtest for kdelibs4support/5.26.0-0ubuntu1: amd64: Ignored failure, armhf: Ignored failure, i386: Ignored failure, ppc64el: Ignored failure, s390x: Always failed
<santa_> says "Ignored failure" because steve hinted it
<santa_> the upload we have in the queue just fixes the acc tests, but kdelibs4support failures are already overriden, so even if that upload gets rejected, nobody is going to be harmed :)
<tsimonq2> santa_: sorry, I read that wrong
<santa_> np
<santa_> slangasek: I could reproduce the test failure of akonadi @ i386, I'm trying to get the kdepim one built on quemu/armhf. in any case I doubt very much I will be able or have time to fix those failures. would you consider to override them? if we find it's an actual problem in akonadi I think we could allways fix it later
<santa_> oh, also note:
<santa_> both in akonadi and kdepim the failures are related (I think) to the sqlite akonadi backend which is not the default backend, the default and recommended is mysql
<santa_> so the only thing somewhat concerning I see there is the "tagmodeltest" failure of akonadi/i386
#ubuntu-release 2016-10-09
<jderose> infinity: fyi, oem-config-gtk is installed after doing an oem install from today's daily ISO... so seems fixed, thanks!
-queuebot:#ubuntu-release- Unapproved: ubuntukylin-default-settings (yakkety-proposed/universe) [1.3.14 => 1.3.15] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: freemat (yakkety-proposed/universe) [4.2+dfsg1-2 => 4.2+dfsg1-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted freemat [sync] (yakkety-proposed) [4.2+dfsg1-3]
-queuebot:#ubuntu-release- Unapproved: libint2 (yakkety-proposed/universe) [2.1.0-2 => 2.1.0-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libint2 [sync] (yakkety-proposed) [2.1.0-3]
-queuebot:#ubuntu-release- Unapproved: mpqc3 (yakkety-proposed/universe) [0.0~git20160216-3 => 0.0~git20160216-6] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mpqc3 [sync] (yakkety-proposed) [0.0~git20160216-6]
-queuebot:#ubuntu-release- Unapproved: ubuntukylin-theme (yakkety-proposed/universe) [1.6.0 => 1.6.1.2] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: ubuntukylin-wallpapers (yakkety-proposed/universe) [16.04.0 => 16.10.1] (ubuntukylin)
<pitti> infinity: not yet; I pinged wgrant about the missing export, but I figure need to re-ping
<pitti> cjwatson, wgrant: can you please do a manual yakkety run for https://translations.launchpad.net/ubuntu/yakkety/+language-packs ? We didn't get any export on Friday
<pishuilu> pitti, infinity: I'm a member of Ubuntu Kylin team. Can you help me to approve the following packages? These packages include ubuntukylin-themeãubuntukylin-wallpapers and ubuntukylin-default-settings.
-queuebot:#ubuntu-release- Unapproved: openjdk-9 (yakkety-proposed/universe) [9~b136-1ubuntu1 => 9~b139-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-9 [source] (yakkety-proposed) [9~b139-1]
<acheronuk> pitti: thank you for giving some of the kde stuff a helpful shove towards the release pocket :)
-queuebot:#ubuntu-release- Unapproved: sword (yakkety-proposed/universe) [1.7.3+dfsg-8 => 1.7.3+dfsg-9] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted sword [sync] (yakkety-proposed) [1.7.3+dfsg-9]
<santa_> hi
<santa_> thank you for hinting akonadi
<santa_> about the tag model test failure I have the impression that upstream developers are having issues with it too: https://quickgit.kde.org/?p=akonadi.git&a=commit&h=59c7ae85e87ffd65ef04705c8213369649f30d0e
<santa_> after searching a bit in the akonadi git repo I didn't find anything looking like a fix
<santa_> so thank you again for hinting it
-queuebot:#ubuntu-release- Unapproved: grub (yakkety-proposed/main) [0.97-29ubuntu68 => 0.97-29ubuntu69] (core)
<jbicha> as long as the final language pack for yakkety hasn't started, could I get bug 1631754 sponsored and shepherded through the queues?
<ubot5> bug 1631754 in gspell (Ubuntu) "gspell does not include translations" [High,Triaged] https://launchpad.net/bugs/1631754
<jbicha> on second thought, do translations have to be manually approved by the translation teams before they get into language packs?
<tsimonq2> chrisccoulson: what's going on with Firefox?
-queuebot:#ubuntu-release- Unapproved: jfsutils (yakkety-proposed/main) [1.1.15-2.1 => 1.1.15-2.2] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: libgd-perl (yakkety-proposed/main) [2.53-2.1 => 2.53-3] (ubuntu-desktop) (sync)
<tsimonq2> chrisccoulson: it seems like it's been FTBFS for a while now
<tsimonq2> chrisccoulson: it would be really nice if the issues could be solved so that Yakkety can ship with 49 :)
-queuebot:#ubuntu-release- Unapproved: openjade (yakkety-proposed/main) [1.4devel1-21.1 => 1.4devel1-21.3] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: pycairo (yakkety-proposed/main) [1.8.8-2 => 1.8.8-2.1] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: 4g8 (yakkety-proposed/universe) [1.0-3 => 1.0-3.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted 4g8 [sync] (yakkety-proposed) [1.0-3.1]
-queuebot:#ubuntu-release- Unapproved: alsamixergui (yakkety-proposed/universe) [0.9.0rc2-1-9.1 => 0.9.0rc2-1-9.2] (lubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: ams (yakkety-proposed/universe) [2.1.1-1build1 => 2.1.1-1.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ams [sync] (yakkety-proposed) [2.1.1-1.1]
-queuebot:#ubuntu-release- Unapproved: anon-proxy (yakkety-proposed/universe) [00.05.38+20081230-3 => 00.05.38+20081230-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted anon-proxy [sync] (yakkety-proposed) [00.05.38+20081230-4]
-queuebot:#ubuntu-release- Unapproved: auto-apt-proxy (yakkety-proposed/universe) [1 => 2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted auto-apt-proxy [sync] (yakkety-proposed) [2]
-queuebot:#ubuntu-release- Unapproved: calf (yakkety-proposed/universe) [0.0.60-3 => 0.0.60-4] (ubuntustudio) (sync)
-queuebot:#ubuntu-release- Unapproved: check-postgres (yakkety-proposed/universe) [2.22.0-1 => 2.22.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted check-postgres [sync] (yakkety-proposed) [2.22.0-2]
-queuebot:#ubuntu-release- Unapproved: criticalmass (yakkety-proposed/universe) [1:1.0.0-4build1 => 1:1.0.0-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted criticalmass [sync] (yakkety-proposed) [1:1.0.0-5]
-queuebot:#ubuntu-release- Unapproved: csound (yakkety-proposed/universe) [1:6.07.0~dfsg-3 => 1:6.07.0~dfsg-4] (ubuntustudio) (sync)
-queuebot:#ubuntu-release- Unapproved: crrcsim (yakkety-proposed/universe) [0.9.12-6.1build3 => 0.9.12-6.2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: csmash-demosong (yakkety-proposed/universe) [1.4 => 1.4+nmu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted crrcsim [sync] (yakkety-proposed) [0.9.12-6.2]
-queuebot:#ubuntu-release- Unapproved: accepted csmash-demosong [sync] (yakkety-proposed) [1.4+nmu1]
-queuebot:#ubuntu-release- Unapproved: dh-kpatches (yakkety-proposed/universe) [0.99.36+nmu2 => 0.99.36+nmu3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted dh-kpatches [sync] (yakkety-proposed) [0.99.36+nmu3]
-queuebot:#ubuntu-release- Unapproved: exult (yakkety-proposed/multiverse) [1.2-16.1build1 => 1.2-16.2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted exult [sync] (yakkety-proposed) [1.2-16.2]
-queuebot:#ubuntu-release- Unapproved: arb (yakkety-proposed/multiverse) [6.0.3-1 => 6.0.3-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted arb [sync] (yakkety-proposed) [6.0.3-2]
-queuebot:#ubuntu-release- Unapproved: chasen (yakkety-proposed/universe) [2.4.5-25 => 2.4.5-29] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: fcml (yakkety-proposed/universe) [1.1.1-1 => 1.1.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted chasen [sync] (yakkety-proposed) [2.4.5-29]
-queuebot:#ubuntu-release- Unapproved: freetable (yakkety-proposed/universe) [2.3-4.1 => 2.3-4.2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: rejected fcml [sync] (yakkety-proposed) [1.1.1-2]
-queuebot:#ubuntu-release- Unapproved: gearhead (yakkety-proposed/universe) [1.302-1 => 1.302-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted freetable [sync] (yakkety-proposed) [2.3-4.2]
-queuebot:#ubuntu-release- Unapproved: accepted gearhead [sync] (yakkety-proposed) [1.302-2]
-queuebot:#ubuntu-release- Unapproved: git-remote-hg (yakkety-proposed/universe) [0.3-1 => 0.3-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted git-remote-hg [sync] (yakkety-proposed) [0.3-2]
-queuebot:#ubuntu-release- Unapproved: gnudoq (yakkety-proposed/universe) [0.94-2.1 => 0.94-2.2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnudoq [sync] (yakkety-proposed) [0.94-2.2]
-queuebot:#ubuntu-release- Unapproved: gtkglextmm (yakkety-proposed/universe) [1.2.0-7 => 1.2.0-8] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gtkglextmm [sync] (yakkety-proposed) [1.2.0-8]
-queuebot:#ubuntu-release- Unapproved: highlight.js (yakkety-proposed/universe) [8.2+ds-4build1 => 8.2+ds-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ivtools (yakkety-proposed/universe) [1.2.11a1-7 => 1.2.11a1-8] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted highlight.js [sync] (yakkety-proposed) [8.2+ds-5]
-queuebot:#ubuntu-release- Unapproved: jalv (yakkety-proposed/universe) [1.4.6~dfsg0-1build2 => 1.4.6~dfsg0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ivtools [sync] (yakkety-proposed) [1.2.11a1-8]
-queuebot:#ubuntu-release- Unapproved: accepted jalv [sync] (yakkety-proposed) [1.4.6~dfsg0-2]
-queuebot:#ubuntu-release- Unapproved: jreen (yakkety-proposed/universe) [1.2.0-1fakesync1 => 1.2.0-2fakesync1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: kyotocabinet (yakkety-proposed/universe) [1.2.76-4.1 => 1.2.76-4.2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted jreen [source] (yakkety-proposed) [1.2.0-2fakesync1]
-queuebot:#ubuntu-release- Unapproved: accepted kyotocabinet [sync] (yakkety-proposed) [1.2.76-4.2]
-queuebot:#ubuntu-release- Unapproved: lakai (yakkety-proposed/universe) [0.1-1 => 0.1-1.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted lakai [sync] (yakkety-proposed) [0.1-1.1]
-queuebot:#ubuntu-release- Unapproved: libdbix-class-perl (yakkety-proposed/universe) [0.082840-1 => 0.082840-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libdbix-class-perl [sync] (yakkety-proposed) [0.082840-2]
-queuebot:#ubuntu-release- Unapproved: gri (yakkety-proposed/universe) [2.12.23-9ubuntu1 => 2.12.23-10] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gri [sync] (yakkety-proposed) [2.12.23-10]
-queuebot:#ubuntu-release- Unapproved: libxml-dumper-perl (yakkety-proposed/universe) [0.81-1.1 => 0.81-1.2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libxml-dumper-perl [sync] (yakkety-proposed) [0.81-1.2]
-queuebot:#ubuntu-release- Unapproved: lpr (yakkety-proposed/universe) [1:2008.05.17.1 => 1:2008.05.17.2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted lpr [sync] (yakkety-proposed) [1:2008.05.17.2]
-queuebot:#ubuntu-release- Unapproved: mmc-utils (yakkety-proposed/universe) [0~gita3d3331-1 => 0~gita3d3331-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: mssh (yakkety-proposed/universe) [2.2-1 => 2.2-1.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: mssstest (yakkety-proposed/multiverse) [3.0-4 => 3.0-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mmc-utils [sync] (yakkety-proposed) [0~gita3d3331-3]
-queuebot:#ubuntu-release- Unapproved: myspell (yakkety-proposed/universe) [1:3.0+pre3.1-24.1 => 1:3.0+pre3.1-24.2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mssh [sync] (yakkety-proposed) [2.2-1.1]
-queuebot:#ubuntu-release- Unapproved: netkit-rsh (yakkety-proposed/universe) [0.17-15 => 0.17-16] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: nvidia-texture-tools (yakkety-proposed/universe) [2.0.8-1+dfsg-8build1 => 2.0.8-1+dfsg-8.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted myspell [sync] (yakkety-proposed) [1:3.0+pre3.1-24.2]
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-texture-tools [sync] (yakkety-proposed) [2.0.8-1+dfsg-8.1]
-queuebot:#ubuntu-release- Unapproved: accepted netkit-rsh [sync] (yakkety-proposed) [0.17-16]
-queuebot:#ubuntu-release- Unapproved: accepted mssstest [sync] (yakkety-proposed) [3.0-5]
-queuebot:#ubuntu-release- Unapproved: osdsh (yakkety-proposed/universe) [0.7.0-10.1 => 0.7.0-10.2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted osdsh [sync] (yakkety-proposed) [0.7.0-10.2]
-queuebot:#ubuntu-release- Unapproved: pike7.8 (yakkety-proposed/universe) [7.8.866-5build1 => 7.8.866-6] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pike7.8 [sync] (yakkety-proposed) [7.8.866-6]
-queuebot:#ubuntu-release- Unapproved: purple-plugin-pack (yakkety-proposed/universe) [2.7.0-2 => 2.7.0-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted purple-plugin-pack [sync] (yakkety-proposed) [2.7.0-3]
-queuebot:#ubuntu-release- Unapproved: rumor (yakkety-proposed/universe) [1.0.5-2 => 1.0.5-2.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: safecat (yakkety-proposed/universe) [1.13-2 => 1.13-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: scalapack (yakkety-proposed/universe) [1.8.0-12.3 => 1.8.0-13] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted rumor [sync] (yakkety-proposed) [1.0.5-2.1]
-queuebot:#ubuntu-release- Unapproved: accepted scalapack [sync] (yakkety-proposed) [1.8.0-13]
-queuebot:#ubuntu-release- Unapproved: accepted safecat [sync] (yakkety-proposed) [1.13-3]
-queuebot:#ubuntu-release- Unapproved: sndobj (yakkety-proposed/universe) [2.6.6.1-5 => 2.6.6.1-5.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: solarwolf (yakkety-proposed/universe) [1.5-2.1 => 1.5-2.2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted solarwolf [sync] (yakkety-proposed) [1.5-2.2]
-queuebot:#ubuntu-release- Unapproved: sooperlooper (yakkety-proposed/universe) [1.7.3~dfsg0-2build1 => 1.7.3~dfsg0-2.1] (ubuntustudio) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted sndobj [sync] (yakkety-proposed) [2.6.6.1-5.1]
-queuebot:#ubuntu-release- Unapproved: tcplay (yakkety-proposed/universe) [1.1-2 => 1.1-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted tcplay [sync] (yakkety-proposed) [1.1-3]
-queuebot:#ubuntu-release- Unapproved: trackballs (yakkety-proposed/universe) [1.1.4-4.2 => 1.1.4-4.3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted trackballs [sync] (yakkety-proposed) [1.1.4-4.3]
-queuebot:#ubuntu-release- Unapproved: weathermap4rrd (yakkety-proposed/universe) [1.1.999+1.2rc3-2 => 1.1.999+1.2rc3-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted weathermap4rrd [sync] (yakkety-proposed) [1.1.999+1.2rc3-3]
-queuebot:#ubuntu-release- Unapproved: xcffib (yakkety-proposed/universe) [0.4.2-1build3 => 0.4.2-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted xcffib [sync] (yakkety-proposed) [0.4.2-2]
-queuebot:#ubuntu-release- Unapproved: xfce4-radio-plugin (yakkety-proposed/universe) [0.5.1-3build1 => 0.5.1-4] (xubuntu) (sync)
<stokachu> slangasek: back on the grid
<clivejo> Hi, release team, kjots and zanshin look like they need a no change rebuild. kjots isnt in the kubuntu packagelist so if I upload that it would result in auto-reject. Can someone from the release team trigger those for us?
<santa_> slangasek: â and I think with that we would be done to get the remaining kde packages out of -proposed
<acheronuk> they need a rebuild to pickup the debianabimanagered library packages I think
<santa_> yes
 * clivejo nods
 * acheronuk looks at the generated deps in zanshin pbuilder rebuild, and nods harder
-queuebot:#ubuntu-release- Unapproved: senlin (yakkety-proposed/universe) [2.0.0~rc1-1 => 2.0.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted senlin [sync] (yakkety-proposed) [2.0.0-1]
<tsimonq2> Hello release team.
<tsimonq2> It seems that Lubuntu's seed has changed since the last upload of lubuntu-meta.
<tsimonq2> Could that please be refreshed and uploaded when somebody has a minute?
<cjwatson> tsimonq2: I tried and it's telling me "No changes found"
<tsimonq2> cjwatson: ok, thanks anyways
<cjwatson> tsimonq2: Looks like nobody's actually caused lubuntu-qt-core to exist as a metapackage yet, and that's where the changes are
<tsimonq2> cjwatson: I see, alright
<cjwatson> well, that and lubuntu-gtk-core
<cjwatson> so perhaps that needs some work?  metapackage restructuring seems like not a four-days-before-release thing though, unless something is clearly broken as a result
<tsimonq2> well yes, I'll talk to someone
<tsimonq2> I was just wondering
<tsimonq2> not release-critical
<cjwatson> ok, cool
#ubuntu-release 2017-10-02
-queuebot:#ubuntu-release- Unapproved: accepted abiword [sync] (artful-proposed) [3.0.2-4]
-queuebot:#ubuntu-release- Unapproved: accepted unity-control-center [sync] (artful-proposed) [15.04.0+17.10.20170930-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted fcitx-qimpanel [sync] (artful-proposed) [2.1.3-1]
-queuebot:#ubuntu-release- Unapproved: systemtap (artful-proposed/universe) [3.1-2 => 3.1-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted systemtap [source] (artful-proposed) [3.1-2ubuntu1]
-queuebot:#ubuntu-release- New source: webkit2-sharp (artful-proposed/primary) [2.10.9+git20160917-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted bijiben [source] (artful-proposed) [3.26.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted im-config [source] (artful-proposed) [0.32-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ca-certificates-java [sync] (artful-proposed) [20170930]
-queuebot:#ubuntu-release- Unapproved: accepted kdenlive [source] (artful-proposed) [4:17.08.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: mapnik (artful-proposed/universe) [3.0.13+ds-1~exp2build1 => 3.0.15+ds-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mapnik [sync] (artful-proposed) [3.0.15+ds-1]
-queuebot:#ubuntu-release- Unapproved: mapnik-vector-tile (artful-proposed/universe) [1.2.2+dfsg-1 => 1.5.0+dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-mapnik (artful-proposed/universe) [3.5.14+dfsg-2build2 => 3.6.2+dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mapnik-vector-tile [sync] (artful-proposed) [1.5.0+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: accepted node-mapnik [sync] (artful-proposed) [3.6.2+dfsg-1]
-queuebot:#ubuntu-release- New sync: mapbox-geometry (artful-proposed/primary) [0.9.2-1]
-queuebot:#ubuntu-release- New sync: mapbox-wagyu (artful-proposed/primary) [0.4.3-1]
-queuebot:#ubuntu-release- Unapproved: nomacs (artful-proposed/universe) [3.4.1+dfsg-10 => 3.4.1+dfsg-11] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted nomacs [sync] (artful-proposed) [3.4.1+dfsg-11]
-queuebot:#ubuntu-release- Unapproved: gtksourceview3 (artful-proposed/main) [3.24.4-1 => 3.24.5-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: gnome-2048 (artful-proposed/universe) [3.22.0-1 => 3.26.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-2048 [sync] (artful-proposed) [3.26.1-1]
-queuebot:#ubuntu-release- Unapproved: gnome-dictionary (artful-proposed/universe) [3.26.0-1 => 3.26.1-1] (desktop-extra) (sync)
-queuebot:#ubuntu-release- Unapproved: iagno (artful-proposed/universe) [1:3.22.0-1 => 1:3.26.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted iagno [sync] (artful-proposed) [1:3.26.1-1]
<LocutusOfBorg> please approve src:geary merge, the goal is to minimize delta from Debian
-queuebot:#ubuntu-release- New sync: diet-ng (artful-proposed/primary) [1.4.3-2]
-queuebot:#ubuntu-release- Unapproved: gir-to-d (artful-proposed/universe) [0.11.0-1build2 => 0.11.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gir-to-d [sync] (artful-proposed) [0.11.1-2]
 * apw looks at geary
-queuebot:#ubuntu-release- Unapproved: libundead (artful-proposed/universe) [1.0.7-1 => 1.0.7-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted libundead [source] (artful-proposed) [1.0.7-1build1]
<LocutusOfBorg> apw, it can even become a sync if we throw out unity changes
-queuebot:#ubuntu-release- Unapproved: accepted geary [source] (artful-proposed) [0.12~20170915-0.4ubuntu1]
<ginggs> would someone please bump existing hints 'force-badtest r-bioc-annotationhub/2.8.1-1build1', 'force-badtest r-cran-surveillance/1.13.0-1build1' and 'force-badtest r-cran-dplyr/0.5.0-1ubuntu4/armhf' ?
-queuebot:#ubuntu-release- Unapproved: appstream-generator (artful-proposed/universe) [0.6.5-1ubuntu2 => 0.6.6-1ubuntu1] (no packageset)
<LocutusOfBorg> ta
-queuebot:#ubuntu-release- Unapproved: vibe.d (artful-proposed/universe) [0.7.30-1build3 => 0.8.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted appstream-generator [source] (artful-proposed) [0.6.6-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted vibe.d [sync] (artful-proposed) [0.8.1-2]
<LocutusOfBorg> apw, accepting the leaf diet-ng will help me trying to finish the ldc transition  :)
-queuebot:#ubuntu-release- Unapproved: gtk-d (artful-proposed/universe) [3.6.5-2ubuntu1 => 3.6.6-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: llvm-toolchain-4.0 (artful-proposed/universe) [1:4.0.1-5ubuntu1 => 1:4.0.1-6] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: lintian (artful-proposed/main) [2.5.53ubuntu2 => 2.5.54] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: libpcap (artful-proposed/main) [1.8.1-4ubuntu1 => 1.8.1-5ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: llvm-toolchain-3.9 (artful-proposed/main) [1:3.9.1-16ubuntu5 => 1:3.9.1-17ubuntu1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: r-cran-gbm (artful-proposed/universe) [2.1.1-1build1 => 2.1.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-gbm [source] (artful-proposed) [2.1.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted diet-ng [sync] (artful-proposed) [1.4.3-2]
-queuebot:#ubuntu-release- New binary: diet-ng [amd64] (artful-proposed/universe) [1.4.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: diet-ng [i386] (artful-proposed/universe) [1.4.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: diet-ng [armhf] (artful-proposed/universe) [1.4.3-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: codeblocks (artful-proposed/universe) [16.01+dfsg-2 => 16.01+dfsg-2.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted codeblocks [sync] (artful-proposed) [16.01+dfsg-2.1]
-queuebot:#ubuntu-release- Unapproved: gcc-snapshot (artful-proposed/universe) [20170923-1ubuntu1 => 20171002-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-snapshot [source] (artful-proposed) [20171002-0ubuntu1]
<jbicha> does my patch at LP: #1720492 look ok to upload?
<ubot5> Launchpad bug 1720492 in tasksel (Ubuntu) "regenerate Ubuntu GNOME tasks" [Undecided,New] https://launchpad.net/bugs/1720492
<jbicha> and https://code.launchpad.net/~jbicha/ubuntu-seeds/platform.artful-apt-transport-https/+merge/331612
<cyphermox> they look fine to me
<jbicha> thanks, pushing
-queuebot:#ubuntu-release- Unapproved: tasksel (artful-proposed/main) [3.34ubuntu8 => 3.34ubuntu9] (core)
-queuebot:#ubuntu-release- Unapproved: geary (artful-proposed/universe) [0.12~20170915-0.4ubuntu1 => 0.12.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: evolution-data-server (artful-proposed/main) [3.26.0-1ubuntu1 => 3.26.1-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: kaffeine (artful-proposed/universe) [2.0.12.1-0ubuntu1 => 2.0.13-1] (kubuntu) (sync)
<acheronuk> ^^^ all fixes as far as I can see, and no delta worth keeping
<LocutusOfBorg> please accept the various llvm-* uploads, just some serious bugfix, and delta reduced
-queuebot:#ubuntu-release- Unapproved: llvm-toolchain-5.0 (artful-proposed/main) [1:5.0-2ubuntu1 => 1:5.0-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: python-k8sclient (artful-proposed/universe) [0.3.0-1 => 0.4.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-k8sclient [source] (artful-proposed) [0.4.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: lxd (xenial-backports/main) [2.17-0ubuntu2~ubuntu16.04.1 => 2.18-0ubuntu3~16.04.1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lxd (zesty-backports/main) [2.17-0ubuntu2~ubuntu17.04.1 => 2.18-0ubuntu3~17.04.1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: gnome-tweak-tool (artful-proposed/universe) [3.26.1-1ubuntu1 => 3.26.2-1ubuntu1] (desktop-extra, edubuntu, ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (xenial-backports) [2.18-0ubuntu3~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (zesty-backports) [2.18-0ubuntu3~17.04.1]
-queuebot:#ubuntu-release- Unapproved: gnome-tweak-tool (artful-proposed/universe) [3.26.1-1ubuntu1 => 3.26.2.1-1ubuntu1] (desktop-extra, edubuntu, ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: gnome-disk-utility (artful-proposed/main) [3.26.0-0ubuntu1 => 3.26.1-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: deja-dup (artful-proposed/main) [36.1-0ubuntu1 => 36.2-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: baobab (artful-proposed/main) [3.26.0-0ubuntu1 => 3.26.1-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-desktop3 (artful-proposed/main) [3.26.0-0ubuntu1 => 3.26.1-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-ati (artful-proposed/main) [1:7.9.0-1 => 1:7.10.0-1] (desktop-core, xorg) (sync)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-amdgpu (artful-proposed/main) [1.3.0-1 => 1.4.0-1] (desktop-core) (sync)
-queuebot:#ubuntu-release- Unapproved: dkms (zesty-proposed/main) [2.3-3ubuntu1 => 2.3-3ubuntu1.1] (core)
-queuebot:#ubuntu-release- Unapproved: dkms (xenial-proposed/main) [2.2.0.3-2ubuntu11.3 => 2.2.0.3-2ubuntu11.4] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: lxd (xenial-backports/main) [2.18-0ubuntu3~16.04.1 => 2.18-0ubuntu3~16.04.2] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lxd (zesty-backports/main) [2.18-0ubuntu3~17.04.1 => 2.18-0ubuntu3~17.04.2] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (zesty-backports) [2.18-0ubuntu3~17.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (xenial-backports) [2.18-0ubuntu3~16.04.2]
-queuebot:#ubuntu-release- Unapproved: rejected update-manager [source] (zesty-proposed) [1:17.04.8]
-queuebot:#ubuntu-release- Unapproved: rejected update-manager [source] (xenial-proposed) [1:16.04.10]
-queuebot:#ubuntu-release- Unapproved: firefox (artful-proposed/main) [55.0.2+build1-0ubuntu4 => 56.0+build6-0ubuntu1] (kubuntu, mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: evolution (artful-proposed/universe) [3.26.0-1 => 3.26.1-1] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: dnsmasq (artful-proposed/main) [2.77-2 => 2.78-1] (ubuntu-desktop, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: dconf-editor (artful-proposed/universe) [3.23.4-0ubuntu1 => 3.26.1-1] (ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: gdk-pixbuf (artful-proposed/main) [2.36.10-2 => 2.36.11-1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: gnome-boxes (artful-proposed/universe) [3.26.0-1 => 3.26.1-1] (desktop-extra) (sync)
-queuebot:#ubuntu-release- Unapproved: gnome-session (artful-proposed/main) [3.26.0-0ubuntu1 => 3.26.0-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: live-build (xenial-proposed/main) [3.0~a57-1ubuntu25.4 => 3.0~a57-1ubuntu25.5] (desktop-core)
#ubuntu-release 2017-10-03
-queuebot:#ubuntu-release- Unapproved: gvfs (artful-proposed/main) [1.34.0-0ubuntu1 => 1.34.1-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: budgie-welcome (artful-proposed/universe) [0.5.4 => 0.5.5] (no packageset)
<tsimonq2> Bugfix and translation updates, please accept ^^^^^^^^^
<tsimonq2> (cc fossfreedom ^^)
-queuebot:#ubuntu-release- Unapproved: gnome-music (artful-proposed/universe) [3.26.0-1 => 3.26.1-1] (desktop-extra, ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: gjs (artful-proposed/main) [1.50.0-1 => 1.50.1-1] (desktop-extra, mozilla, ubuntu-desktop) (sync)
<ginggs> any release team around to help me migrate r-base please?
<flocculant> Laney: I thought 'you' weren't building 32bit iso's any longer?
<Laney> flocculant: right, dailies should stop showing up soon
<apw> ginggs, perhaps enumerate what you need and someone can help
-queuebot:#ubuntu-release- Unapproved: glib2.0 (artful-proposed/main) [2.54.0-1ubuntu1 => 2.54.0-1ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-ubuntu-dock (artful-proposed/main) [0.6 => 0.7] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted evolution-data-server [source] (artful-proposed) [3.26.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libpcap [source] (artful-proposed) [1.8.1-5ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-3.9 [source] (artful-proposed) [1:3.9.1-17ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted geary [source] (artful-proposed) [0.12.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted lintian [sync] (artful-proposed) [2.5.54]
<ginggs> apw: so for the test failures in r-bioc-iranges and r-bioc-variantannotation i have traced it back to some weirdness in r-bioc-biocgenerics - i've filed debian bug #877288 and reported the issue upstream - is it reasonable to skip the 3 failing tests out of 170 in these two packages to let this thing migrate?
<ubot5> Debian bug 877288 in src:r-base "r-base: Rebuilding r-bioc-biocgenerics with new R changes behaviour" [Normal,Open] http://bugs.debian.org/877288
-queuebot:#ubuntu-release- Unapproved: accepted baobab [source] (artful-proposed) [3.26.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-desktop3 [source] (artful-proposed) [3.26.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-disk-utility [source] (artful-proposed) [3.26.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-tweak-tool [source] (artful-proposed) [3.26.2.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gtksourceview3 [sync] (artful-proposed) [3.24.5-1]
-queuebot:#ubuntu-release- Unapproved: accepted libpng1.6 [sync] (artful-proposed) [1.6.34-1]
-queuebot:#ubuntu-release- Unapproved: accepted deja-dup [source] (artful-proposed) [36.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-tweak-tool [source] (artful-proposed) [3.26.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kaffeine [sync] (artful-proposed) [2.0.13-1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-dictionary [sync] (artful-proposed) [3.26.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted gtk-d [source] (artful-proposed) [3.6.6-1ubuntu1]
<apw> ginggs, that bug seems to be suggesting we have a build order issue ...
<apw> not that i can really understand what they are asking to do differnt
-queuebot:#ubuntu-release- Unapproved: ntp (artful-proposed/main) [1:4.2.8p10+dfsg-5ubuntu2 => 1:4.2.8p10+dfsg-5ubuntu3] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: thunderbird (artful-proposed/main) [1:52.2.1+build1-0ubuntu1 => 1:52.4.0+build1-0ubuntu1] (mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-ubuntu-dock [source] (artful-proposed) [0.7]
<ginggs> apw: yeah, i am not convinced it's a build order issue
<ginggs> apw: so i'm thinking of uploading r-bioc-iranges and r-bioc-variantannotation with only the failing tests skipped and a note to refer to that bug and where it was forwarded upstream
<apw> ginggs, that does leave a nasty taste, do we know what is broke with those in that state ?
-queuebot:#ubuntu-release- Unapproved: accepted gvfs [source] (artful-proposed) [1.34.1-1ubuntu1]
<LocutusOfBorg> please accept also llvm-toolchain-4.0 and 5.0 syncs, they take eons to build :)
<ginggs> apw: i don't know, only that something is different in the "building" of r-bioc-biocgenerics (it's arch:all) between R 3.4.1 and 3.4.2
<ginggs> oh and 3.4.1.20170921-1 is poorly named, 3.4.2~20170921-1 or 3.4.2~rc1-1 would have been better
-queuebot:#ubuntu-release- Unapproved: sgt-launcher (artful-proposed/universe) [0.2.2-0ubuntu1 => 0.2.3-0ubuntu1] (xubuntu)
<bluesabre> ^ single bug fixed and translations, please approve and release
<ginggs> apw: but i guess it boils down to rather having two known broken packages, than the unknown number of broken packages currently in release (possibly in the region of 50-100), which is why i requested this late transition LP: #1719245
<ubot5> Launchpad bug 1719245 in r-base (Debian) "FFe: Sync r-base 3.4.1.20170921-1 (universe) from Debian unstable (main)" [Unknown,Confirmed] https://launchpad.net/bugs/1719245
<apw> ginggs, based on that trade off i think we have no choice ... lots broken against two known cases broken
<ginggs> apw: ack, thanks, uploading now
<flocculant> Laney: aah right 'soon' just wondered when I saw them :)
-queuebot:#ubuntu-release- Unapproved: accepted budgie-welcome [source] (artful-proposed) [0.5.5]
<chrisccoulson> please reject thunderbird (it will fail to build)
-queuebot:#ubuntu-release- Unapproved: dnsmasq (artful-proposed/main) [2.77-2 => 2.78-1] (ubuntu-desktop, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: rejected thunderbird [source] (artful-proposed) [1:52.4.0+build1-0ubuntu1]
<apw> chrisccoulson, ^
<chrisccoulson> thanks
<LocutusOfBorg> tsimonq2, why are all the budgie-* foo not in sync with Debian?
-queuebot:#ubuntu-release- Unapproved: accepted dnsmasq [sync] (artful-proposed) [2.78-1]
-queuebot:#ubuntu-release- Unapproved: rejected dnsmasq [sync] (artful-proposed) [2.78-1]
<apw> zippy
<Laney> YESNOOOOOOOOO
-queuebot:#ubuntu-release- Unapproved: r-bioc-iranges (artful-proposed/universe) [2.10.2-1build1 => 2.10.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-iranges [source] (artful-proposed) [2.10.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: r-bioc-variantannotation (artful-proposed/universe) [1.22.1-1build1 => 1.22.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-variantannotation [source] (artful-proposed) [1.22.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-themes (artful-proposed/main) [16.10+17.10.20170930-0ubuntu1 => 16.10+17.10.20171003-0ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: gjs (artful-proposed/main) [1.50.0-1 => 1.50.1-1] (desktop-extra, mozilla, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: thunderbird (artful-proposed/main) [1:52.2.1+build1-0ubuntu1 => 1:52.4.0+build1-0ubuntu1] (mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: xorg-server (artful-proposed/main) [2:1.19.3-1ubuntu6 => 2:1.19.3-1ubuntu7] (desktop-core, xorg)
-queuebot:#ubuntu-release- Unapproved: metacity (artful-proposed/universe) [1:3.25.2-2build1 => 1:3.26.0-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: mesa (artful-proposed/main) [17.2.1-0ubuntu1 => 17.2.2-0ubuntu1] (core, xorg)
<tjaalton> mesa bugfix update ^, also xorg-server sync with upstream stable branch which should become 1.19.4 before release
<mitya57> metacity ^, is a stable release (3.25.2 was beta), no new features but some bugfixes/cleanups/translations
<tjaalton> also, x-x-v-ati and -amdgpu updates were synced last night
<tjaalton> low risk
<tjaalton> all of these :)
<Laney> you don't need to ping about the queue
<Laney> it gets regularly reviewed
-queuebot:#ubuntu-release- Unapproved: file-roller (artful-proposed/main) [3.26.0-0ubuntu2 => 3.26.0-0ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: systemd (trusty-proposed/main) [204-5ubuntu20.24 => 204-5ubuntu20.25] (core)
-queuebot:#ubuntu-release- Unapproved: gnome-settings-daemon (artful-proposed/main) [3.26.0-0ubuntu1 => 3.26.1-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: vte2.91 (artful-proposed/main) [0.48.3-0ubuntu1 => 0.48.4-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New source: nvidia-graphics-drivers-384 (artful-proposed/primary) [384.90-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: hylafax (artful-proposed/universe) [3:6.0.6-7 => 3:6.0.6-8] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted hylafax [sync] (artful-proposed) [3:6.0.6-8]
-queuebot:#ubuntu-release- Unapproved: simple-scan (artful-proposed/main) [3.25.90-0ubuntu1 => 3.26.1-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: simple-scan (artful-proposed/main) [3.25.90-0ubuntu1 => 3.26.1-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: eog (artful-proposed/main) [3.25.92-1 => 3.26.1-0ubuntu1] (ubuntu-desktop)
<tjaalton> ok, good
 * mitya57 was not pinging, but rather explaining
-queuebot:#ubuntu-release- Unapproved: rejected glib2.0 [source] (artful-proposed) [2.54.0-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: freeplane (artful-proposed/universe) [1.6.6-1 => 1.6.6-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-session [source] (artful-proposed) [3.26.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted freeplane [source] (artful-proposed) [1.6.6-1build1]
-queuebot:#ubuntu-release- Unapproved: cloud-init (artful-proposed/main) [17.1-0ubuntu1 => 17.1-13-g7fd04255-0ubuntu1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted gjs [sync] (artful-proposed) [1.50.1-1]
-queuebot:#ubuntu-release- Unapproved: rejected gjs [sync] (artful-proposed) [1.50.1-1]
<tsimonq2> .ir
<tsimonq2> Whoops
<acheronuk> again?
-queuebot:#ubuntu-release- Unapproved: gnome-online-accounts (artful-proposed/main) [3.26.0-1ubuntu1 => 3.26.1-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: poppler (artful-proposed/main) [0.57.0-2ubuntu1 => 0.57.0-2ubuntu2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: git (artful-proposed/main) [1:2.14.1-1ubuntu3 => 1:2.14.1-1ubuntu4] (core)
<mdeslaur> poppler and git are security updates only ^
-queuebot:#ubuntu-release- Unapproved: accepted poppler [source] (artful-proposed) [0.57.0-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted git [source] (artful-proposed) [1:2.14.1-1ubuntu4]
<apw> jbicha, which of these simple-scan uploads do you wnat
<jbicha> apw: the one with debian/rules: Add orkaround for Ubuntu translations issue
<jbicha> oops I lost a W
<xnox> infinity, slangasek, apw - could you please reject ntp upload?
<apw> xnox, sure ...
-queuebot:#ubuntu-release- Unapproved: rejected ntp [source] (artful-proposed) [1:4.2.8p10+dfsg-5ubuntu3]
-queuebot:#ubuntu-release- Unapproved: partman-efi (artful-proposed/main) [71ubuntu1 => 71ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: hunspell (artful-proposed/main) [1.6.1-2 => 1.6.2-1] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: fonts-tlwg (artful-proposed/main) [1:0.6.3-2 => 1:0.6.3-3] (desktop-core, personal-gunnarhj) (sync)
-queuebot:#ubuntu-release- Unapproved: aspell-en (artful-proposed/main) [2017.01.22-0-0.1 => 2017.08.24-0-0.1] (kubuntu, ubuntu-desktop, ubuntu-server) (sync)
<cyphermox> hrm
<cyphermox> can someone please reject partman-efi from the artful unapproved queue?
<slangasek> cyphermox: doing
<cyphermox> ta
<cyphermox> I'm rethinking this, my patch would work in ubiquity but make no sense in d-i
<slangasek> cyphermox: done
<cyphermox> (ie. that's why you're rejecting it)
<cyphermox> thanks
-queuebot:#ubuntu-release- Unapproved: rejected partman-efi [source] (artful-proposed) [71ubuntu2]
-queuebot:#ubuntu-release- Unapproved: gnome-control-center (artful-proposed/main) [1:3.26.0-0ubuntu3 => 1:3.26.1-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: enigmail (artful-proposed/universe) [2:1.9.8.2-2 => 2:1.9.8.3-1] (mozilla) (sync)
<jbicha> could we get an Ubuntu 18.04 series registered in launchpad so that it's easier to target bugs for it?
-queuebot:#ubuntu-release- Unapproved: onedrive (artful-proposed/universe) [1.1.20170106-1build2 => 1.1.20170919-1] (no packageset) (sync)
<LocutusOfBorg> apw, you? seem to have accepted src:diet-ng but not the binaries...
-queuebot:#ubuntu-release- Unapproved: accepted onedrive [sync] (artful-proposed) [1.1.20170919-1]
<LocutusOfBorg> it has been built on all applicable archs: amd64 armhf i386
<LocutusOfBorg> this will unblock vibe.d
<LocutusOfBorg> ta
-queuebot:#ubuntu-release- Unapproved: linux-meta (artful-proposed/main) [4.13.0.12.13 => 4.13.0.14.15] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: linux-signed (artful-proposed/main) [4.13.0-12.13 => 4.13.0-14.15] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: linux (artful-proposed/main) [4.13.0-12.13 => 4.13.0-14.15] (core, kernel)
<slangasek> LocutusOfBorg: do you want to provide some color on /why/ you're syncing llvm-toolchain-* during final freeze?
<acheronuk> are we in final freeze?
<acheronuk> wiki says 12th Oct for that
<acheronuk> think we had this before with the wiki telling fibs
<tsimonq2> acheronuk: I *think* the difference between now and FinalFreeze is that now any unseeded packages automatically get approved
<LocutusOfBorg> slangasek, bugs.debian.org/876787 bugs.debian.org/857653 bugs.debian.org/872237
<LocutusOfBorg> three RC bugs, one breaking afl (reverse-dependency)
<LocutusOfBorg> I think they should be fixed
<acheronuk> tsimonq2: that wiki seriously need some sorting :/
<acheronuk> that was NOT me voluteering
 * tsimonq2 pushes acheronuk towards the wiki page :P
<balloons> RAOF, for when you awake, could you have a look at juju-core as an SRU into xenial?
<RAOF> balloons: I'm on holidays for the next two weeks. If it's urgent, please ping someone else ð
<balloons> RAOF, ahh, do have fun!
-queuebot:#ubuntu-release- Unapproved: python3.6 (artful-proposed/main) [3.6.3~rc1-2ubuntu1 => 3.6.3-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: python3-stdlib-extensions (artful-proposed/main) [3.6.3~rc1-0ubuntu1 => 3.6.3-0ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted python3-stdlib-extensions [source] (artful-proposed) [3.6.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python3.6 [source] (artful-proposed) [3.6.3-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gcc-5 (artful-proposed/main) [5.4.1-12ubuntu4 => 5.4.1-13ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted enigmail [sync] (artful-proposed) [2:1.9.8.3-1]
-queuebot:#ubuntu-release- Unapproved: rejected simple-scan [source] (artful-proposed) [3.26.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted firefox [source] (artful-proposed) [56.0+build6-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted thunderbird [source] (artful-proposed) [1:52.4.0+build1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-5 [source] (artful-proposed) [5.4.1-13ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-5.0 [sync] (artful-proposed) [1:5.0-3]
-queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-4.0 [sync] (artful-proposed) [1:4.0.1-6]
#ubuntu-release 2017-10-04
-queuebot:#ubuntu-release- Unapproved: gucharmap (artful-proposed/main) [1:10.0.1-1 => 1:10.0.2-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: gobject-introspection (artful-proposed/main) [1.54.0-1 => 1.54.1-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: gnome-documents (artful-proposed/universe) [3.26.0-1 => 3.26.1-1] (desktop-extra, ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: libqtxdg (artful-proposed/universe) [2.0.0-7 => 2.0.0-8] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: simple-scan (artful-proposed/main) [3.25.90-0ubuntu1 => 3.26.1-0ubuntu1] (ubuntu-desktop)
<jbicha> I figured I might as well fix the typo in the debian/changelog entry since it hasn't been accepted yet, feel free to reject the old simple-scan
<jbicha> chrisccoulson: could you check LP: #1720422 ?
<ubot5> Launchpad bug 1720422 in thunderbird (Ubuntu) "Remove thunderbird from s390x" [Undecided,Incomplete] https://launchpad.net/bugs/1720422
<tsimonq2> So I see that Kubuntu has a header like this on cdimage.ubuntu.com: http://cdimage.ubuntu.com/kubuntu/daily-live/current/HEADER.html
<tsimonq2> How can Lubuntu create a custom one like that?
<cjwatson> there's a pile of horrible stuff in lp:ubuntu-cdimage lib/cdimage/tree.py, plus some custom CSS installed manually
<cjwatson> search for kubuntu in that file and you should find most of it
<cjwatson> (also some corresponding tests)
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (artful-proposed) [17.1-13-g7fd04255-0ubuntu1]
<tsimonq2> cjwatson: Ok, thanks
<tjaalton> could someone accept mesa 17.2.2-0u1
-queuebot:#ubuntu-release- Unapproved: libdrm (artful-proposed/main) [2.4.82-1 => 2.4.83-1] (core, xorg) (sync)
-queuebot:#ubuntu-release- Unapproved: rejected tasksel [source] (artful-proposed) [3.34ubuntu9]
<infinity> jbicha: bb-series created.
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta [source] (artful-proposed) [4.13.0.14.15]
-queuebot:#ubuntu-release- Unapproved: accepted linux [source] (artful-proposed) [4.13.0-14.15]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed [source] (artful-proposed) [4.13.0-14.15]
<apw> tjaalton, this xorg update, does it matter if the previous syncs happen before or after ?
-queuebot:#ubuntu-release- Unapproved: rejected simple-scan [source] (artful-proposed) [3.26.1-0ubuntu1]
<tjaalton> apw: no matter
<tjaalton> no abi update
-queuebot:#ubuntu-release- Unapproved: gsettings-ubuntu-touch-schemas (artful-proposed/main) [0.0.7+17.04.20161109-0ubuntu1 => 0.0.7+17.10.20170922-0ubuntu1] (edubuntu, ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: unity-settings-daemon (artful-proposed/universe) [15.04.1+17.04.20170619-0ubuntu3 => 15.04.1+17.10.20171003-0ubuntu1] (mythbuntu, ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: unity (artful-proposed/universe) [7.5.0+17.10.20170925.1-0ubuntu1 => 7.5.0+17.10.20171003-0ubuntu1] (ubuntukylin) (sync)
<acheronuk> if any release team could ack or whatever on bug #1721191 that would be great
<ubot5> bug 1721191 in Ubuntu "[FFe qtwebview-opensource-src] Sync 5.9.1-2 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1721191
<acheronuk> hopefully that suffices
-queuebot:#ubuntu-release- New binary: linux [s390x] (artful-proposed/main) [4.13.0-14.15] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-documents [sync] (artful-proposed) [3.26.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted gucharmap [sync] (artful-proposed) [1:10.0.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-amdgpu [sync] (artful-proposed) [1.4.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted gobject-introspection [sync] (artful-proposed) [1.54.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-ati [sync] (artful-proposed) [1:7.10.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted xorg-server [source] (artful-proposed) [2:1.19.3-1ubuntu7]
-queuebot:#ubuntu-release- Unapproved: accepted evolution [sync] (artful-proposed) [3.26.1-1]
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (artful-proposed/main) [4.13.0-14.15] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (artful-proposed/main) [4.13.0-14.15] (core, kernel)
<Laney> slangasek: infinity: cjwatson: Do I have to manually delete the old desktop i386 images on nusakan or will they be purged eventually? I see the builds from yesterday have been copied forward into 20171004.
<cjwatson> I suspect they have to be manually deleted, though I don't remember for certain
 * Laney looks for the logic in cdimage
-queuebot:#ubuntu-release- Unapproved: accepted dconf-editor [sync] (artful-proposed) [3.26.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted gdk-pixbuf [sync] (artful-proposed) [2.36.11-1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-boxes [sync] (artful-proposed) [3.26.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-music [sync] (artful-proposed) [3.26.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted sgt-launcher [source] (artful-proposed) [0.2.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: linux [i386] (artful-proposed/main) [4.13.0-14.15] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (artful-proposed/main) [4.13.0-14.15] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: systemd (artful-proposed/main) [234-2ubuntu11 => 234-2ubuntu12] (core)
<xnox> Laney, please review systemd upload ^ that should save the cheerleader, and save the world
<Laney> xnox: everything gets reviewed, I'm working the queue from the bottom up
<Laney> and maybe file a bug upstream about this please?
<xnox> Laney, i have. listed in the lp bug as a remote tracking bug for upstream.
-queuebot:#ubuntu-release- New binary: linux [armhf] (artful-proposed/main) [4.13.0-14.15] (core, kernel)
<Laney> oko
<Laney> OKOOOOOOOOOOO
-queuebot:#ubuntu-release- Unapproved: accepted file-roller [source] (artful-proposed) [3.26.0-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (artful-proposed) [17.2.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-settings-daemon [source] (artful-proposed) [3.26.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted metacity [sync] (artful-proposed) [1:3.26.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted eog [source] (artful-proposed) [3.26.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted hunspell [sync] (artful-proposed) [1.6.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-online-accounts [source] (artful-proposed) [3.26.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted vte2.91 [source] (artful-proposed) [0.48.4-0ubuntu1]
<LocutusOfBorg> -ConditionFileIsExecutable=!/usr/sbin/VBoxService
<LocutusOfBorg> sigh systemd
-queuebot:#ubuntu-release- Unapproved: maas (artful-proposed/main) [2.3.0~alpha3-6250-g58f83f3-0ubuntu1 => 2.3.0~beta1-6301-gca25180-0ubuntu1] (ubuntu-server)
<Laney> xnox: do you want to take https://github.com/keszybz/systemd/commit/6fbdf424b43b229fd9ea639cfcf3f2f0f667cdde or go with your workaround?
<LocutusOfBorg> that systemd will probably break virtualbox, hurray
-queuebot:#ubuntu-release- Unapproved: ubuntu-themes (artful-proposed/main) [16.10+17.10.20170930-0ubuntu1 => 16.10+17.10.20171003-0ubuntu1] (core)
<Laney> how come?
<xnox> LocutusOfBorg, please keep up - all the alternative ntp services now ship conflicts=systemd-timesyncd meaning when both are available neither are run.
-queuebot:#ubuntu-release- New: accepted linux [amd64] (artful-proposed) [4.13.0-14.15]
-queuebot:#ubuntu-release- New: accepted linux [armhf] (artful-proposed) [4.13.0-14.15]
-queuebot:#ubuntu-release- New: accepted linux [ppc64el] (artful-proposed) [4.13.0-14.15]
<xnox> LocutusOfBorg, are you implying that in artful our vboxservices is out of date?
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-384 [source] (artful-proposed) [384.90-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted linux [arm64] (artful-proposed) [4.13.0-14.15]
-queuebot:#ubuntu-release- New: accepted linux [s390x] (artful-proposed) [4.13.0-14.15]
-queuebot:#ubuntu-release- New: accepted linux [i386] (artful-proposed) [4.13.0-14.15]
-queuebot:#ubuntu-release- New: accepted diet-ng [amd64] (artful-proposed) [1.4.3-2]
<xnox> Laney, i am busy fixing other high priority things =/ and i'd rather not redo/recreate the upload.
-queuebot:#ubuntu-release- New: accepted diet-ng [i386] (artful-proposed) [1.4.3-2]
-queuebot:#ubuntu-release- New: accepted diet-ng [armhf] (artful-proposed) [1.4.3-2]
<Laney> :/ indeed
<xnox> Laney, i will cherry-pick that fix, if and when the next systemd upload happens, which i hope to be in bb-series
<LocutusOfBorg> [15:46:18] <xnox> LocutusOfBorg, please keep up - all the alternative ntp services now ship conflicts=systemd-timesyncd meaning when both are available neither are run.
<LocutusOfBorg> AFAIK I never did that on virtualbox
<Laney> well let's see if you're breaking virtualbox :-)
<xnox> Laney, i know i am unbreaking all the ntp users =)
<LocutusOfBorg> and just FTR, you also need to make sure the upstream guest additions fixed it
-queuebot:#ubuntu-release- Unapproved: tasksel (artful-proposed/main) [3.34ubuntu8 => 3.34ubuntu9] (core)
<LocutusOfBorg> I already pinged them BTW
<xnox> Laney, because currently when both ntp & systemd are installed, neither claim to sync time.
<Laney> it's not an either/or, is it?
 * apw pokes queuebot,
<Laney> like, you could keep the unit and drop the conditions apart from the vbox one?
<LocutusOfBorg> I discussed with Michael to have a "Provide=ntp-foo" and having only one of them running, e.g. to avoid them doing the same job together
-queuebot:#ubuntu-release- Unapproved: accepted aspell-en [sync] (artful-proposed) [2017.08.24-0-0.1]
-queuebot:#ubuntu-release- Unapproved: accepted fonts-tlwg [sync] (artful-proposed) [1:0.6.3-3]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (artful-proposed) [1:3.26.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libqtxdg [sync] (artful-proposed) [2.0.0-8]
-queuebot:#ubuntu-release- Unapproved: accepted libdrm [sync] (artful-proposed) [2.4.83-1]
-queuebot:#ubuntu-release- Unapproved: accepted simple-scan [source] (artful-proposed) [3.26.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-themes [source] (artful-proposed) [16.10+17.10.20171003-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-themes [source] (artful-proposed) [16.10+17.10.20171003-0ubuntu1]
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-384 [i386] (artful-proposed/none) [384.90-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-384 [amd64] (artful-proposed/none) [384.90-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected systemd [source] (artful-proposed) [234-2ubuntu12]
<Laney> (^- safety reject, can pick up from the rejected queue if LocutusOfBorg and xnox figure out it's not a problem, otherwise upload a fixed version)
<apw> Laney, plan indeed
<LocutusOfBorg> I'm right now checking
<Laney> I'm leaving those syncs in the queue, asked Trevinh-o a question on #ubuntu-desktop
<Laney> the proper uploads someone else can look at :-)
-queuebot:#ubuntu-release- Unapproved: curl (artful-proposed/main) [7.55.1-1ubuntu1 => 7.55.1-1ubuntu2] (core)
<xnox> LocutusOfBorg, which Michael?
<xnox> LocutusOfBorg, note this change is a cherrypick of what was applied in debian.
<xnox> LocutusOfBorg, i can keep the conflicts on the vbox, but i really need to drop condition on the ntpd
<LocutusOfBorg> if you keep the vbox one I'm fine
<LocutusOfBorg> also, if you fix vbox i'm even happpier
<LocutusOfBorg> I have an old init.d file for vbox, this is why I don't know how to add that conflict
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-384 (artful-proposed/none) [none => 384.90-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-384 [source] (artful-proposed) [384.90-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: ubuntu-settings (artful-proposed/main) [17.10.16 => 17.10.17] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: tasksel (artful-proposed/main) [3.34ubuntu8 => 3.34ubuntu9] (core)
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-384 [amd64] (artful-proposed/universe) [384.90-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-384 [i386] (artful-proposed/universe) [384.90-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-384 [armhf] (artful-proposed/universe) [384.90-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New: rejected nvidia-graphics-drivers-384 [amd64] (artful-proposed) [384.90-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected nvidia-graphics-drivers-384 [i386] (artful-proposed) [384.90-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libdazzle (artful-proposed/universe) [3.26.0-1 => 3.26.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: sysprof (artful-proposed/universe) [3.26.0-2 => 3.26.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-384 [amd64] (artful-proposed) [384.90-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-384 [i386] (artful-proposed) [384.90-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-384 [armhf] (artful-proposed) [384.90-0ubuntu2]
<xnox> LocutusOfBorg, ah..... you must fix virtualbox in debian, and you really should ship systemd unit
<xnox> LocutusOfBorg, cause currently virtualbox is thus broken in unstable
-queuebot:#ubuntu-release- Unapproved: accepted libdazzle [sync] (artful-proposed) [3.26.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted sysprof [sync] (artful-proposed) [3.26.1-1]
<LocutusOfBorg> xnox, please reupload, I think I have a patch
<LocutusOfBorg> I'm testing right now a DoM build, will upload in debian
<LocutusOfBorg> I can reupload if needed
<jbicha> if there are no changes, I believe the package can be accepted from the rejected queue without needing a new upload
<LocutusOfBorg> Laney, ^^ please accept it then
<LocutusOfBorg> I can fix in some hours
<LocutusOfBorg> http://debomatic-amd64.debian.net/distribution#unstable/virtualbox/5.1.28-dfsg-2/buildlog
<LocutusOfBorg> this is the build
<jbicha> LocutusOfBorg: shouldn't you fix vbox first before asking for the other pkg to be accepted? :)
<LocutusOfBorg> meh, even testing is affected
<LocutusOfBorg> usually people complain when I break vbox in a matter of minutes after the first dinstall
<LocutusOfBorg> so, I presume nobody really cares about that VBoxService
<LocutusOfBorg> anyway, now the fix is a matter of remembering how to install a service file with debhelper
-queuebot:#ubuntu-release- Unapproved: tk8.6 (artful-proposed/main) [8.6.7-1 => 8.6.7-1ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: ibus-skk (artful-proposed/universe) [1.4.2-1 => 1.4.2-1.1] (input-methods) (sync)
<rbalint> nacc: i'm preparing the next livecd-rootfs upload to Xenial and i see you have a patch committed already for LP: #1444992
<ubot5> Launchpad bug 1444992 in MAAS "fastpath install duplicates iSCSI initiator names, blocking iSCSI HW" [High,Triaged] https://launchpad.net/bugs/1444992
<rbalint> nacc: could you please add the SRU info?
<nacc> rbalint: will do (note, I didn't do the SRU)
<nacc> rbalint: vtapia did
<rbalint> nacc: ah i see, just checked the committer
<nacc> rbalint: np, i can still do it
-queuebot:#ubuntu-release- Unapproved: im-config (artful-proposed/main) [0.32-1ubuntu1 => 0.32-1ubuntu2] (input-methods, kubuntu, personal-gunnarhj, ubuntu-desktop)
<jbicha> you can delete the duplicate tasksel from the unapproved queue, I didn't see a notification so I reuploaded
-queuebot:#ubuntu-release- New sync: qtwebview-opensource-src (artful-proposed/primary) [5.9.1-2]
<mitya57> acheronuk, tsimonq2: ^^ qtwebview synced
-queuebot:#ubuntu-release- Unapproved: isc-dhcp (zesty-proposed/main) [4.3.5-3ubuntu1 => 4.3.5-3ubuntu1.1] (core)
-queuebot:#ubuntu-release- Unapproved: sqlmap (artful-proposed/universe) [1.1.9-1 => 1.1.10-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted sqlmap [sync] (artful-proposed) [1.1.10-1]
<balloons> rbasak, are you doing sru's today?
<rbasak> balloons: it is my SRU day, but I'm only back today after not having been around much in a few weeks. So I'm mostly catching up, not processing the queue, sorry. Is there anything urgent you need looking at?
<balloons> rbasak, I would appreciate your help in having a look at juju 2.2.4 into xenial; https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1718213
<ubot5> Ubuntu bug 1718213 in juju-core (Ubuntu Xenial) "[SRU] Juju 2.2.4" [Undecided,Triaged]
<balloons> rbasak, and welcome back!
<rbasak> balloons: that sounds like too big a piece for me to manage today, sorry
<balloons> rbasak, ack, no worries. Just trying to have someone take a look this week.
<balloons> bdmurray, will you have some spare cycles to have a look tomorow? ^^
-queuebot:#ubuntu-release- Unapproved: partman-efi (artful-proposed/main) [71ubuntu1 => 71ubuntu2] (core)
<dannf> hi! gcc-5 is stuck in xenial-proposed due to 2 failing autopkgtests. Both are reproducible with the previous gcc-5, and are known bugs (LP: #1699529, LP: #1717920) - could I get an override for that? (CC: doko)
<ubot5> Launchpad bug 1699529 in libreoffice (Ubuntu) "i386 autopkgtests are unstable" [High,Confirmed] https://launchpad.net/bugs/1699529
<ubot5> Launchpad bug 1717920 in linux (Ubuntu Zesty) "autopkgtest profile fails to build on armhf" [High,Confirmed] https://launchpad.net/bugs/1717920
-queuebot:#ubuntu-release- Unapproved: rejected nplan [source] (xenial-proposed) [0.29~16.04.1]
-queuebot:#ubuntu-release- Unapproved: nplan (xenial-proposed/universe) [0.23~16.04.1 => 0.29~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (artful-proposed/main) [4.13.0-14.15] (core, kernel)
<bdmurray> balloons: sure
-queuebot:#ubuntu-release- New binary: vibe.d [amd64] (artful-proposed/universe) [0.8.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: vibe.d [i386] (artful-proposed/universe) [0.8.1-2] (no packageset)
<dannf> hey bdmurray! would you be able to consider the gcc-5/xenial override above? ^
<bdmurray> dannf: I am able to consider that
<dannf> bdmurray: :)
-queuebot:#ubuntu-release- New binary: vibe.d [armhf] (artful-proposed/universe) [0.8.1-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (artful-proposed/main) [2.464 => 2.465] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (artful-proposed) [2.465]
-queuebot:#ubuntu-release- Unapproved: accepted live-build [source] (xenial-proposed) [3.0~a57-1ubuntu25.5]
-queuebot:#ubuntu-release- Unapproved: ostree (artful-proposed/universe) [2017.11-2ubuntu1 => 2017.12-1ubuntu1] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: ntp (artful-proposed/main) [1:4.2.8p10+dfsg-5ubuntu2 => 1:4.2.8p10+dfsg-5ubuntu3] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: thunderbird (artful-proposed/main) [1:52.4.0+build1-0ubuntu1 => 1:52.4.0+build1-0ubuntu2] (mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.18 => 2.408.19] (desktop-core)
<balloons> bdmurray, thank you. Just let me know if you have questions. I appreciate it
-queuebot:#ubuntu-release- Unapproved: onboard (artful-proposed/universe) [1.4.1-2 => 1.4.1-2ubuntu2] (ubuntu-desktop)
<tsimonq2> mitya57: Ack :)
<nacc> rbalint: done
<nacc> vtapia: --^
-queuebot:#ubuntu-release- Unapproved: lua-lgi (artful-proposed/universe) [0.9.1-1 => 0.9.1-1.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted lua-lgi [sync] (artful-proposed) [0.9.1-1.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (artful-proposed) [4.13.0-14.15]
<rbalint> nacc: thanks!
<bdmurray> balloons: Are there plans to get get juju 2.2.4 in Zesty? That's a supported upgrade path from Xenial.
<balloons> bdmurray, we played with a package, but ultimately didn't do an upload for it. Juju isn't in artful, leaving xenial with the only package
<balloons> (once zesty goes EOL that is)
<bdmurray> balloons: why "ultimately didn't do an upload"?
<balloons> mwhudson, ^^
<mwhudson> i guess we forgot?
<mwhudson> it should be easy
<balloons> bdmurray, the packaging is a bit different and I think we wanted to focus on xenial to start
<balloons> mwhudson, aye, I believe my original branch should just work with the same changes
<balloons> as we started with the zesty branch to being with
<mwhudson> heh ironically upstream has just released 1.8.4 after we made a build embedding 1.8.3
<mwhudson> the changes aren't relevant, fortunately
<bdmurray> Also should golang-go still be a build-dep if "upstream no longer builds with Go 1.6"?
<mwhudson> bdmurray: yes, it's required to build go 1.8.3
<bdmurray> mwhudson: its versioned >= 2:1.6 though
<mwhudson> bdmurray: i guess the version dep could be dropped but uh
<bdmurray> oh golang-go is required to build the embbeded go?
<mwhudson> bdmurray: go 1.4 or better is required to build go 1.8.3
<mwhudson> go 1.8.3 is used to build juju-core
<mwhudson> i guess i should have written a lot more in the changelog about this, it's pretty confusing
<bdmurray> Okay, well I'd like to see it updated / SRU'ed in zesty too
<apw> not in artful? replaced by something or just missing
<bdmurray> snaps I'm sure
<apw> ah
<balloons> correct
-queuebot:#ubuntu-release- Unapproved: accepted dkms [source] (xenial-proposed) [2.2.0.3-2ubuntu11.4]
-queuebot:#ubuntu-release- Unapproved: accepted dkms [source] (zesty-proposed) [2.3-3ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted isc-dhcp [source] (zesty-proposed) [4.3.5-3ubuntu1.1]
<nacc> rbalint: np, thanks for prompting me :)
-queuebot:#ubuntu-release- Unapproved: systemd (zesty-proposed/main) [232-21ubuntu6 => 232-21ubuntu7] (core)
-queuebot:#ubuntu-release- Unapproved: gnome-characters (artful-proposed/universe) [3.25.92-1 => 3.26.1-1] (ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: polari (artful-proposed/universe) [3.26.0-1 => 3.26.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted polari [sync] (artful-proposed) [3.26.1-1]
-queuebot:#ubuntu-release- Unapproved: gnome-maps (artful-proposed/universe) [3.26.0-1 => 3.26.1-1] (desktop-extra, ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: evince (artful-proposed/main) [3.25.92-1 => 3.26.0-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: libica (artful-proposed/universe) [3.1.1-1 => 3.2.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libica [sync] (artful-proposed) [3.2.0-2]
-queuebot:#ubuntu-release- Unapproved: gtk+3.0 (artful-proposed/main) [3.22.21-0ubuntu1 => 3.22.24-0ubuntu1] (ubuntu-desktop)
#ubuntu-release 2017-10-05
<tsimonq2> Release Team (cc slangasek infinity): Does this require an FFe? https://bugs.launchpad.net/ubuntu/+source/ffmpeg/+bug/1721249
<ubot5> Ubuntu bug 1721249 in ffmpeg (Ubuntu) "ffmpeg artful update to 3.3.4" [Undecided,New]
<tsimonq2> Debian Multimedia Team also personally recommended it to me.
<tsimonq2> Actually, nvm, answered my own question...
-queuebot:#ubuntu-release- Unapproved: ffmpeg (artful-proposed/universe) [7:3.3.3-4 => 7:3.3.4-2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: mutter (artful-proposed/main) [3.26.0+20170925~ea214fb-1ubuntu1 => 3.26.1-1] (desktop-extra, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: tracker (artful-proposed/main) [2.0.0-1 => 2.0.1-1] (desktop-extra, ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: tracker-miners (artful-proposed/universe) [2.0.0-1 => 2.0.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gnome-calendar (artful-proposed/main) [3.26.0-1 => 3.26.2-1] (desktop-extra, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: pbuilder (artful-proposed/main) [0.228.8 => 0.228.9] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (artful-proposed/main) [2.465 => 2.466] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (artful-proposed) [2.466]
-queuebot:#ubuntu-release- Unapproved: accepted maas [source] (artful-proposed) [2.3.0~beta1-6301-gca25180-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected tasksel [source] (artful-proposed) [3.34ubuntu9]
-queuebot:#ubuntu-release- Unapproved: virtualbox (artful-proposed/multiverse) [5.1.28-dfsg-1 => 5.1.28-dfsg-2] (ubuntu-cloud) (sync)
<LocutusOfBorg> Laney, ^^ with this virtualbox you can accept new systemd
<LocutusOfBorg> well, the iso file is still broken, but that is an upstream problem
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (artful-proposed/main) [2.466 => 2.467] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (artful-proposed) [2.467]
-queuebot:#ubuntu-release- Unapproved: glib2.0 (artful-proposed/main) [2.54.0-1ubuntu1 => 2.54.1-1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: gsettings-ubuntu-touch-schemas (artful-proposed/main) [0.0.7+17.04.20161109-0ubuntu1 => 0.0.7+17.10.20170922-0ubuntu1] (edubuntu, ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: unity-settings-daemon (artful-proposed/universe) [15.04.1+17.04.20170619-0ubuntu3 => 15.04.1+17.10.20171003-0ubuntu1] (mythbuntu, ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: unity (artful-proposed/universe) [7.5.0+17.10.20170925.1-0ubuntu1 => 7.5.0+17.10.20171004-0ubuntu1] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-appindicator (artful-proposed/main) [17.10 => 17.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: chromium-browser (artful-proposed/universe) [61.0.3163.79-0ubuntu1.1371 => 61.0.3163.100-0ubuntu1.1378] (ubuntu-desktop)
<tjaalton> should I worry about powerpc on xenial?
<tjaalton> assuming since xenial still builds binaries for it that is a yes
<slashd> sil2100, good day could you please look at LP: #1718966 (waiting on Trusty upload queue) and LP: #1692334 ready to be released in -updates for Xenial and Zesty. Thanks in advance.
<ubot5> Launchpad bug 1718966 in systemd (Ubuntu Trusty) "Cannot install snaps on Ubuntu 14.04 with /var on its own partition" [Medium,In progress] https://launchpad.net/bugs/1718966
<ubot5> Launchpad bug 1692334 in Ubuntu Cloud Archive ocata "neutron bash completion helper is not installed" [Undecided,New] https://launchpad.net/bugs/1692334
<sil2100> slashd: hey! Sure, I'll look in a bit
<slashd> sil2100, thanks
-queuebot:#ubuntu-release- Unapproved: linux-meta (artful-proposed/main) [4.13.0.14.15 => 4.13.0.15.16] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux (artful-proposed/main) [4.13.0-14.15 => 4.13.0-15.16] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta [sync] (artful-proposed) [4.13.0.15.16]
-queuebot:#ubuntu-release- Unapproved: accepted linux [sync] (artful-proposed) [4.13.0-15.16]
-queuebot:#ubuntu-release- Unapproved: gnome-applets (artful-proposed/universe) [3.24.1-4 => 3.26.0-1] (desktop-extra, edubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted curl [source] (artful-proposed) [7.55.1-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-settings [source] (artful-proposed) [17.10.17]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (artful-proposed/main) [4.13.0-15.16] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (artful-proposed) [4.13.0-15.16]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (trusty-proposed) [204-5ubuntu20.25]
-queuebot:#ubuntu-release- Unapproved: nova (xenial-proposed/main) [2:13.1.4-0ubuntu4 => 2:13.1.4-0ubuntu4.1] (openstack, ubuntu-server)
<slashd> tinoco, ^^
<tinoco> slashd: tku
<coreycb> bdmurray: i've uploaded nova 2:13.1.4-0ubuntu4.1 to the xenial review queue with fixes for the dep8 failures
<slashd> sil2100, thanks for systemd. For the other request python-neutronclient (LP: #1692334), you'll notice 2 autopkgtest failure, but freyes have documented both regressions found in the LP bug.
<ubot5> Launchpad bug 1692334 in Ubuntu Cloud Archive ocata "neutron bash completion helper is not installed" [Undecided,New] https://launchpad.net/bugs/1692334
<sil2100> slashd: yeah, I'll be moving onto the pending queue soon
<slashd> sil2100, sure take your time, was just making sure I gave you all the details for this one ;)
<sil2100> coreycb: hey! Just a reminder for next time - for openstack packages, please use the https://wiki.ubuntu.com/OpenStackUpdates SRU bug template
<sil2100> coreycb: just a formality ;)
<coreycb> sil2100: hey!
<coreycb> sil2100: we should actually align that with the ubuntu SRU template
<sil2100> coreycb: it is aligned, that document has an SRU-template based template for bugs
<sil2100> Approved by the SRU team and such
<coreycb> sil2100: ok good. what bug are you talking about then?
<sil2100> https://bugs.launchpad.net/cloud-archive/+bug/1718730
<ubot5> Ubuntu bug 1718730 in sahara (Ubuntu Zesty) "[SRU] ocata stable releases" [Undecided,Fix committed]
<coreycb> sil2100: oh right, yeah bad habbits
<sil2100> No worries, just a formality bit that is, all good besides that
<coreycb> sil2100: thanks, no i appreciate your keeping me honest
<xnox> slangasek, Laney - given https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1721556 can you please mark open-iscsi as bad test in XENIAL branch of the hints?
<ubot5> Ubuntu bug 1721556 in open-iscsi (Ubuntu Xenial) "ADT tests are broken in xenial" [Undecided,New]
-queuebot:#ubuntu-release- Unapproved: accepted glib2.0 [source] (artful-proposed) [2.54.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected gsettings-ubuntu-touch-schemas [sync] (artful-proposed) [0.0.7+17.10.20170922-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected unity [sync] (artful-proposed) [7.5.0+17.10.20171003-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected unity-settings-daemon [sync] (artful-proposed) [15.04.1+17.10.20171003-0ubuntu1]
<Laney> superseded in the queue already
<Laney> xnox: AFAIK the SRU team manage those hints
 * Laney with the sloping shoulders
-queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (xenial-proposed) [2.408.19]
<LocutusOfBorg> Laney, please virtualbox and systemd <3
<acheronuk> qtwebview-opensource-src in 'new' has been ok'd on it's FFe, so could someone be so kind as to let that through
-queuebot:#ubuntu-release- Unapproved: accepted ibus-skk [sync] (artful-proposed) [1.4.2-1.1]
-queuebot:#ubuntu-release- Unapproved: accepted ntp [source] (artful-proposed) [1:4.2.8p10+dfsg-5ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted thunderbird [source] (artful-proposed) [1:52.4.0+build1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted im-config [source] (artful-proposed) [0.32-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted tk8.6 [source] (artful-proposed) [8.6.7-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ostree [source] (artful-proposed) [2017.12-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected onboard [source] (artful-proposed) [1.4.1-2ubuntu2]
<Laney> tumbleweed: do you think you could drop ubuntu-gnome from seeded-in-ubuntu's data please? it's dead now (cc jbicha)
<Laney> LocutusOfBorg: I'm working it from the bottom, not sure I'll get up that high in time
<Laney> systemd is accepted though
 * Laney wanted to take another look at the proper way to delete desktop/i386 isos from cdimage too
-queuebot:#ubuntu-release- Unapproved: accepted evince [sync] (artful-proposed) [3.26.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-maps [sync] (artful-proposed) [3.26.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-characters [sync] (artful-proposed) [3.26.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted gtk+3.0 [source] (artful-proposed) [3.22.24-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: linux-meta-raspi2 (artful-proposed/universe) [4.10.0.1019.20 => 4.13.0.1004.2] (kernel)
-queuebot:#ubuntu-release- Unapproved: linux-raspi2 (artful-proposed/universe) [4.10.0-1019.22 => 4.13.0-1004.4] (kernel)
<Laney> LocutusOfBorg: you got this unit acked by someone?
<Laney> ExecStart=/etc/init.d/... :((((((
<LocutusOfBorg> Laney, quick and dirty working fix :/
<LocutusOfBorg> sorry but a good service will probably need a lot of time
<LocutusOfBorg> and this one worked well in my sid/artful testing
-queuebot:#ubuntu-release- Unapproved: accepted ffmpeg [sync] (artful-proposed) [7:3.3.4-2]
-queuebot:#ubuntu-release- Unapproved: accepted mutter [sync] (artful-proposed) [3.26.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted tracker-miners [sync] (artful-proposed) [2.0.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-calendar [sync] (artful-proposed) [3.26.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted tracker [sync] (artful-proposed) [2.0.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted pbuilder [sync] (artful-proposed) [0.228.9]
<tumbleweed> Laney: sure
<Laney> LocutusOfBorg: okokokok
<LocutusOfBorg> :)
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox [sync] (artful-proposed) [5.1.28-dfsg-2]
<LocutusOfBorg> btw I update virtualbox in stable ubuntu releases, having two init scripts for different init systems would be a pain to maintain/test
<LocutusOfBorg> I keep every change "backportable"
<Laney> tumbleweed: â¥ â¥
 * Laney punts cdimage to tomorrow
<Laney> night
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.18 => 2.408.19] (desktop-core)
<jbicha> maybe the old ubuntu-gnome 17.10 daily isos should be removed too then?
<slangasek> indeed
<slangasek> done
<slangasek> Laney: wrt deleting the i386 images, AFAIK there is no "proper" way, because the publishing code never knows if you might produce them as part of a separate build.  I've nuked the files, ignored the dangling references in *SUMS and HEADER.html, and will let that clean itself up as they rotate off
<jbicha> LP: #1720422 looks like the only thing blocking thunderbird from migrating to artful, I never got a response from chrisccoulson but I assume he doesn't object
<ubot5> Launchpad bug 1720422 in thunderbird (Ubuntu) "Remove thunderbird from s390x" [Undecided,Incomplete] https://launchpad.net/bugs/1720422
<chrisccoulson> No, I don't object. Kill it with fire
<slangasek> Laney: I think we might need to review the text in HEADER.html though, I think it will still point users to i386 which no longer exists
-queuebot:#ubuntu-release- Unapproved: cups-filters (artful-proposed/main) [1.17.8-0ubuntu1 => 1.17.9-0ubuntu1] (desktop-core, ubuntu-server)
<jbicha> I'd unassign you Chris but LP is timing out for me
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (zesty-proposed) [20170921+dfsg1-0ubuntu1~17.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (xenial-proposed) [20170921+dfsg1-0ubuntu1~16.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (trusty-proposed) [20170921+dfsg1-0ubuntu1~14.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (zesty-proposed) [232-21ubuntu7]
-queuebot:#ubuntu-release- Unapproved: rejected borgbackup [source] (xenial-proposed) [1.0.10-2~16.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected pcl [source] (xenial-proposed) [1.7.2-14ubuntu1.16.04.2]
-queuebot:#ubuntu-release- Unapproved: rejected ppc64-diag [source] (xenial-proposed) [2.7.4-1~16.04]
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (xenial-proposed) [2:13.1.4-0ubuntu4.1]
<ahasenack> hi guys, just a ping about an FFe bug I just filed. Not wanting to "jump the queue", just a heads up: https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/1721272
<ubot5> Ubuntu bug 1721272 in ubuntu-advantage-tools (Ubuntu) "[FFe] Rename 'ubuntu-advantage' script to 'advantage'" [High,New]
<slangasek> ahasenack: can we change that first sentence to not be in passive mood?  "It was requested" by whom?  It's not a major feature change that I feel strongly we should /nack/ an FFe for, but it also doesn't seem like anything that should be a high priority wrt 17.10 release
<ahasenack> sure
<ahasenack> done
<ahasenack> kirkland: wrt to that ubuntu-advantage rename: #1721272
<slangasek> kirkland, ahasenack: fwiw I have concerns about this not from a release team / freeze standpoint, but from an archive admin / filesystem namespace POV.  We've gone down this path before of assuming that the Ubuntu namespace is ours and ours alone, and been bitten when a conflicting package is introduced upstream in Debian
<ahasenack> slangasek: I expected as such: "advantage" is definitely less specific
-queuebot:#ubuntu-release- Unapproved: python-heatclient (zesty-proposed/main) [1.8.0-0ubuntu2 => 1.8.0-0ubuntu3] (openstack, ubuntu-server)
<ahasenack> slangasek: I think next step is for you or another AA to comment on the bug with respect to that
-queuebot:#ubuntu-release- Unapproved: python-heatclient (xenial-proposed/main) [1.1.0-2 => 1.1.0-2ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: r-bioc-s4vectors (artful-proposed/universe) [0.14.3-1build1 => 0.14.3-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-s4vectors [source] (artful-proposed) [0.14.3-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: 389-admin (artful-proposed/universe) [1.1.43-1build1 => 1.1.46-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted 389-admin [sync] (artful-proposed) [1.1.46-1]
-queuebot:#ubuntu-release- Unapproved: nplan (zesty-proposed/main) [0.23~17.04.1 => 0.29~17.04.1] (core)
<cyphermox> bdmurray: nplan for zesty ^
-queuebot:#ubuntu-release- Unapproved: linux-firmware (artful-proposed/main) [1.168 => 1.169] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: console-setup (artful-proposed/main) [1.166ubuntu6 => 1.166ubuntu7] (core)
-queuebot:#ubuntu-release- Unapproved: console-setup (xenial-proposed/main) [1.108ubuntu15.3 => 1.108ubuntu15.4] (core)
-queuebot:#ubuntu-release- Unapproved: r-bioc-iranges (artful-proposed/universe) [2.10.2-1ubuntu1 => 2.10.2-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-iranges [source] (artful-proposed) [2.10.2-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted console-setup [source] (artful-proposed) [1.166ubuntu7]
<bdmurray> cyphermox: noted
-queuebot:#ubuntu-release- Unapproved: dkms (zesty-proposed/main) [2.3-3ubuntu1.1 => 2.3-3ubuntu1.2] (core)
-queuebot:#ubuntu-release- Unapproved: r-bioc-variantannotation (artful-proposed/universe) [1.22.1-1ubuntu1 => 1.22.3-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-variantannotation [sync] (artful-proposed) [1.22.3-1]
-queuebot:#ubuntu-release- Unapproved: dkms (artful-proposed/main) [2.3-3ubuntu2 => 2.3-3ubuntu3] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: r-cran-rcppgsl (artful-proposed/universe) [0.3.2-2ubuntu3 => 0.3.3-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-rcppgsl [sync] (artful-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- Unapproved: dkms (xenial-proposed/main) [2.2.0.3-2ubuntu11.4 => 2.2.0.3-2ubuntu11.5] (kubuntu, ubuntu-desktop)
<Ukikie> "advantage" is also less of a descriptive name, so very vague.
-queuebot:#ubuntu-release- Unapproved: cloud-init (artful-proposed/main) [17.1-13-g7fd04255-0ubuntu1 => 17.1-17-g45d361cb-0ubuntu1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: juju-core (zesty-proposed/main) [2.0.2-0ubuntu2.1 => 2.2.4-0ubuntu0.17.04.1] (ubuntu-server)
<mwhudson> bdmurray, balloons: juju-core now in zesty unapproved as well as xenial unapproved
-queuebot:#ubuntu-release- Unapproved: update-manager (artful-proposed/main) [1:17.10.10 => 1:17.10.11] (core)
<bdmurray> mwhudson: thanks
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (artful-proposed/main) [2.467 => 2.468] (desktop-core)
#ubuntu-release 2017-10-06
<tsimonq2> cyphermox, infinity: What's the next step in getting this merged? https://code.launchpad.net/~viking.redwolf/ubiquity-slideshow-ubuntu/ubiquity-slideshow-ubuntu/+merge/330404
-queuebot:#ubuntu-release- Unapproved: libbson (artful-proposed/universe) [1.7.0-1 => 1.8.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libbson [sync] (artful-proposed) [1.8.0-1]
-queuebot:#ubuntu-release- Unapproved: file-roller (artful-proposed/main) [3.26.0-0ubuntu3 => 3.26.1-0ubuntu1] (ubuntu-desktop)
<jbicha> feel free to drop these obsolete hints: https://paste.debian.net/989241/
-queuebot:#ubuntu-release- Unapproved: curtin (artful-proposed/main) [0.1.0~bzr519-0ubuntu1 => 0.1.0~bzr532-0ubuntu1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted tasksel [source] (artful-proposed) [3.34ubuntu9]
<slangasek> tsimonq2: https://code.launchpad.net/~viking.redwolf/ubiquity-slideshow-ubuntu/ubiquity-slideshow-ubuntu/+merge/330404 - why does it have the set of reviewers listed that it does (neither of whom have acked it)?
-queuebot:#ubuntu-release- Unapproved: libseccomp (zesty-proposed/main) [2.3.1-2.1ubuntu1 => 2.3.1-2.1ubuntu1.1] (core)
-queuebot:#ubuntu-release- Unapproved: udiskie (artful-proposed/universe) [1.7.0-4 => 1.7.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted udiskie [sync] (artful-proposed) [1.7.1-1]
<LocutusOfBorg> apw, can you please update the virtualbox hint? (and fix the kernel module version) :)
<LocutusOfBorg> oops now the hint is on slangasek ./vorlon:force-badtest virtualbox/5.1.28-dfsg-1
-queuebot:#ubuntu-release- Unapproved: gnome-flashback (artful-proposed/universe) [3.24.0-1ubuntu4 => 3.26.0-1ubuntu1] (edubuntu)
-queuebot:#ubuntu-release- Unapproved: gnome-shell (artful-proposed/main) [3.26.0-0ubuntu2 => 3.26.1-0ubuntu1] (desktop-extra, mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: libsdl2 (artful-proposed/universe) [2.0.5+dfsg1-3ubuntu1 => 2.0.6+dfsg1-2ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: insighttoolkit4 (artful-proposed/universe) [4.12.1-dfsg1-1ubuntu1 => 4.12.2-dfsg1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted insighttoolkit4 [sync] (artful-proposed) [4.12.2-dfsg1-1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-settings (artful-proposed/main) [17.10.17 => 17.10.18] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: insighttoolkit4 (artful-proposed/universe) [4.12.2-dfsg1-1 => 4.12.2-dfsg1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted insighttoolkit4 [source] (artful-proposed) [4.12.2-dfsg1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: onboard (artful-proposed/universe) [1.4.1-2 => 1.4.1-2ubuntu1] (ubuntu-desktop)
<Laney> bdmurray: update-manager> changes a translated string AFAICS, did you check with translators if that's ok?
-queuebot:#ubuntu-release- Unapproved: accepted chromium-browser [source] (artful-proposed) [61.0.3163.100-0ubuntu1.1378]
-queuebot:#ubuntu-release- Unapproved: accepted cups-filters [source] (artful-proposed) [1.17.9-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted dkms [source] (artful-proposed) [2.3-3ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-applets [sync] (artful-proposed) [3.26.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-appindicator [source] (artful-proposed) [17.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted libsdl2 [source] (artful-proposed) [2.0.6+dfsg1-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (artful-proposed) [2.468]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-settings [source] (artful-proposed) [17.10.18]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (artful-proposed) [17.1-17-g45d361cb-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted file-roller [source] (artful-proposed) [3.26.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [source] (artful-proposed) [3.26.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted onboard [source] (artful-proposed) [1.4.1-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (artful-proposed) [0.1.0~bzr532-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (artful-proposed) [1.169]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-flashback [source] (artful-proposed) [3.26.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: udisks2 (artful-proposed/main) [2.6.5-2ubuntu1 => 2.6.5-2ubuntu2] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: gnome-games-app (artful-proposed/universe) [3.26.1-1 => 3.26.1.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-games-app [sync] (artful-proposed) [3.26.1.1-1]
-queuebot:#ubuntu-release- Unapproved: tracker-miners (artful-proposed/universe) [2.0.1-1 => 2.0.2-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted tracker-miners [sync] (artful-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- Unapproved: postfix (artful-proposed/main) [3.2.2-1 => 3.2.3-1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: xkeyboard-config (artful-proposed/main) [2.19-1ubuntu1 => 2.19-1.1ubuntu1] (core)
<jbicha> Laney: want to apply this patch to the hints? https://paste.debian.net/989241/
<LocutusOfBorg> also update virtualbox hint to -2 version
<tsimonq2> slangasek: Dylan is listed as Maintainer and gilir is one of our release managers who is busy with Real Life
<ddstreet> slangasek are you sru vanguarding today?  if so can you push lp #1718055 into -updates please, it's at its required aging and i have another initramfs-tools sru i need to get started
<ubot5> Launchpad bug 1718055 in initramfs-tools (Ubuntu Trusty) "update-initramfs fails for MODULES=dep when root is on LVM wich uses nvme device" [Medium,Fix committed] https://launchpad.net/bugs/1718055
<ddstreet> tjaalton or are you sru vanguard ^ ?  might be eod for you though
-queuebot:#ubuntu-release- Unapproved: budgie-welcome (zesty-proposed/universe) [0.4.5 => 0.4.6] (no packageset)
<tjaalton> ddstreet: just about, though spent all day building kernels :/
<tjaalton> I'll have a look
<ddstreet> thanks!
<jbicha> also, budgie-welcome/zesty ^ is needed to avoid problems when webkit2gtk 2.18 is released as a security update, thanks
<jbicha> budgie-welcome was mistakenly dropped from the sponsors queue a few weeks ago
<tjaalton> ddstreet: oh actually, release to -updates is a nono on fridays, as a general rule
<ddstreet> tjaalton ah ok, got it, i'll check back monday.  thnx
<jbicha> tjaalton: can you look at budgie-welcome instead? :)
<bdmurray> Laney: the string is rather new, last couple of weeks, as it is. How would I check?
<Laney> bdmurray: https://wiki.ubuntu.com/UserInterfaceFreeze says to email the ubuntu-translators list
<tjaalton> jbicha: done
-queuebot:#ubuntu-release- Unapproved: accepted budgie-welcome [source] (zesty-proposed) [0.4.6]
<jbicha> :)
-queuebot:#ubuntu-release- Unapproved: firefox-kwallet5 (artful-proposed/universe) [1.3-1 => 1.3-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted firefox-kwallet5 [source] (artful-proposed) [1.3-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libxfont1 (artful-proposed/main) [1:1.5.2-4 => 1:1.5.2-4ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: libxfont (artful-proposed/main) [1:2.0.1-3 => 1:2.0.1-3ubuntu1] (desktop-core, xorg)
<jbicha> slangasek: do you want to work on LP: #1720422 today since I need to do metapackage uploads anyway?
<ubot5> Launchpad bug 1720422 in thunderbird (Ubuntu) "Remove thunderbird from s390x" [Undecided,New] https://launchpad.net/bugs/1720422
-queuebot:#ubuntu-release- Unapproved: indicator-session (artful-proposed/universe) [17.3.20+17.10.20170717.1-0ubuntu3 => 17.3.20+17.10.20171006-0ubuntu1] (edubuntu, ubuntu-mate) (sync)
<acheronuk>  qtwebview-opensource-src in 'new queue' has been ok'd on it's FFe bug #1721191, so could someone be so kind as to let that through
<ubot5> bug 1721191 in Ubuntu "[FFe qtwebview-opensource-src] Sync 5.9.1-2 (universe) from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/1721191
-queuebot:#ubuntu-release- Unapproved: gnome-control-center (artful-proposed/main) [1:3.26.1-0ubuntu1 => 1:3.26.1-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: curtin (xenial-proposed/main) [0.1.0~bzr505-0ubuntu1~16.04.1 => 0.1.0~bzr532-0ubuntu1~16.04.1] (ubuntu-server)
<bdmurray> Laney: That wiki page says to notify the documenation and translation team, so I don't read that as needing "to check" with them, just notify them. Is that correct?
<slangasek> ddstreet: we don't release SRUs on Friday barring extraordinary circumstances and someone available to vanguard regressions over the weekend (which is definitely not me this weekend because I have sprint travel)
<ddstreet> slangasek yep sounds good, i'll check back monday
<slangasek> tsimonq2: right, but you asked for their review rather than a general review; have you decided not to block on them?
-queuebot:#ubuntu-release- Unapproved: curtin (zesty-proposed/main) [0.1.0~bzr505-0ubuntu1~17.04.1 => 0.1.0~bzr532-0ubuntu1~17.04.1] (ubuntu-server)
<bdmurray> ddstreet: Keep in mind Monday is a US and Canadian holiday.
<ddstreet> bdmurray yep thanks
<bdmurray> Laney: I notified them and cc'ed the release team
<tsimonq2> slangasek: yep, please someone merge it and get it uploaded
<cyphermox> slangasek: I am reviewing/merging that, slideshow needs a translation export anyway
<cyphermox> (assuming this is still about slideshow)
-queuebot:#ubuntu-release- Unapproved: libseccomp (artful-proposed/main) [2.3.1-2.1ubuntu2 => 2.3.1-2.1ubuntu3] (core)
<bdmurray> ddstreet: Speaking of Monday, it doesn't look good for getting quorum for the DMB meeting.
<ddstreet> bdmurray yeah i just replied via email asking for an email vote
<ddstreet> assuming nobody has any new questions, since i've already applied before
<ddstreet> bdmurray do you have objections to an email vote?
<bdmurray> I do not although those do tend to drag on.
<ddstreet> hopefully it won't, since everyone had the opportunity to ask me questions already
<ddstreet> we'll see
-queuebot:#ubuntu-release- Unapproved: ippusbxd (artful-proposed/main) [1.30-2 => 1.31-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extensions (artful-proposed/universe) [3.26.0-1 => 3.26.1-1] (ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: libseccomp (zesty-proposed/main) [2.3.1-2.1ubuntu1 => 2.3.1-2.1ubuntu2~17.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: csync2 (artful-proposed/universe) [2.0-8-g175a01c-4 => 2.0-8-g175a01c-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted csync2 [source] (artful-proposed) [2.0-8-g175a01c-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected libseccomp [source] (zesty-proposed) [2.3.1-2.1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [0.7.9-233-ge586fe35-0ubuntu1~16.04.2 => 17.1-17-g45d361cb-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: nodejs (artful-proposed/universe) [6.11.2~dfsg-3ubuntu1 => 6.11.4~dfsg-1ubuntu1] (kubuntu)
<tsimonq2> nodejs is a bugfix release and shouldn't break any freezes, please approve :)
-queuebot:#ubuntu-release- Unapproved: cloud-init (zesty-proposed/main) [0.7.9-233-ge586fe35-0ubuntu1~17.04.2 => 17.1-17-g45d361cb-0ubuntu1~17.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted nplan [source] (zesty-proposed) [0.29~17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted nplan [source] (xenial-proposed) [0.29~16.04.1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (artful-proposed/main) [1:17.10.6 => 1:17.10.7] (core)
#ubuntu-release 2017-10-07
-queuebot:#ubuntu-release- Unapproved: music (artful-proposed/universe) [1.0.7-1.3 => 1.0.7-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted music [sync] (artful-proposed) [1.0.7-2]
-queuebot:#ubuntu-release- Unapproved: kodi (artful-proposed/universe) [2:17.3+dfsg1-2build1 => 2:17.3+dfsg1-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted kodi [sync] (artful-proposed) [2:17.3+dfsg1-3]
-queuebot:#ubuntu-release- Unapproved: varnish-modules (artful-proposed/universe) [0.9.1-4 => 0.12.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ace (artful-proposed/universe) [6.3.3+dfsg-1.2 => 6.4.5+dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ace [sync] (artful-proposed) [6.4.5+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: accepted varnish-modules [sync] (artful-proposed) [0.12.1-1]
-queuebot:#ubuntu-release- New binary: ace [amd64] (artful-proposed/universe) [6.4.5+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ace [s390x] (artful-proposed/universe) [6.4.5+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ace [ppc64el] (artful-proposed/universe) [6.4.5+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ace [i386] (artful-proposed/universe) [6.4.5+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ace [arm64] (artful-proposed/universe) [6.4.5+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ace [armhf] (artful-proposed/universe) [6.4.5+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kodi [amd64] (artful-proposed/universe) [2:17.3+dfsg1-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted ace [amd64] (artful-proposed) [6.4.5+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ace [armhf] (artful-proposed) [6.4.5+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ace [ppc64el] (artful-proposed) [6.4.5+dfsg-1]
-queuebot:#ubuntu-release- New: accepted kodi [amd64] (artful-proposed) [2:17.3+dfsg1-3]
-queuebot:#ubuntu-release- New: accepted vibe.d [armhf] (artful-proposed) [0.8.1-2]
-queuebot:#ubuntu-release- New: accepted ace [arm64] (artful-proposed) [6.4.5+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ace [s390x] (artful-proposed) [6.4.5+dfsg-1]
-queuebot:#ubuntu-release- New: accepted vibe.d [i386] (artful-proposed) [0.8.1-2]
-queuebot:#ubuntu-release- New: accepted ace [i386] (artful-proposed) [6.4.5+dfsg-1]
-queuebot:#ubuntu-release- New: accepted vibe.d [amd64] (artful-proposed) [0.8.1-2]
<cjwatson> infinity: I replied to you on https://bugs.launchpad.net/launchpad/+bug/1720182, but just noticed that AFAICS you aren't subscribed to it so might not see
<ubot5> Ubuntu bug 1720182 in Launchpad itself "not possible for ubuntu-sru team member to use sru-remove" [High,Triaged]
<infinity> cjwatson: Hrm, curious.  And that would affect only deletions?  Cause the next thing Brian will complain about it overrides probably (phasing).
<infinity> cjwatson: Fundamentally, I'm not sure if this is a thing we want a broader group having rights to without sufficient training anyway, and with said training, they can just be full AA.
 * infinity copy and pastes to the bug.
-queuebot:#ubuntu-release- Unapproved: libsdl2 (artful-proposed/universe) [2.0.6+dfsg1-2ubuntu1 => 2.0.6+dfsg1-2ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: python3-defaults (artful-proposed/main) [3.6.2-1ubuntu4 => 3.6.3-0ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: bogl (artful-proposed/main) [0.1.18-11ubuntu1 => 0.1.18-12ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted bogl [source] (artful-proposed) [0.1.18-12ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python3-defaults [source] (artful-proposed) [3.6.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extensions [sync] (artful-proposed) [3.26.1-1]
-queuebot:#ubuntu-release- New: accepted mapbox-geometry [sync] (artful-proposed) [0.9.2-1]
-queuebot:#ubuntu-release- New: accepted qtwebview-opensource-src [sync] (artful-proposed) [5.9.1-2]
-queuebot:#ubuntu-release- New: accepted mapbox-wagyu [sync] (artful-proposed) [0.4.3-1]
-queuebot:#ubuntu-release- New: accepted webkit2-sharp [source] (artful-proposed) [2.10.9+git20160917-1ubuntu1]
-queuebot:#ubuntu-release- New binary: mapbox-geometry [amd64] (artful-proposed/universe) [0.9.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qtwebview-opensource-src [amd64] (artful-proposed/universe) [5.9.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: qtwebview-opensource-src [i386] (artful-proposed/universe) [5.9.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: webkit2-sharp [i386] (artful-proposed/universe) [2.10.9+git20160917-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: webkit2-sharp [amd64] (artful-proposed/universe) [2.10.9+git20160917-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: qtwebview-opensource-src [arm64] (artful-proposed/universe) [5.9.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: qtwebview-opensource-src [armhf] (artful-proposed/universe) [5.9.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: webkit2-sharp [arm64] (artful-proposed/universe) [2.10.9+git20160917-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: webkit2-sharp [armhf] (artful-proposed/universe) [2.10.9+git20160917-1ubuntu1] (no packageset)
<tsimonq2> Can someone please approve nodejs?
-queuebot:#ubuntu-release- New: accepted mapbox-geometry [amd64] (artful-proposed) [0.9.2-1]
-queuebot:#ubuntu-release- New: accepted qtwebview-opensource-src [arm64] (artful-proposed) [5.9.1-2]
-queuebot:#ubuntu-release- New: accepted qtwebview-opensource-src [i386] (artful-proposed) [5.9.1-2]
-queuebot:#ubuntu-release- New: accepted qtwebview-opensource-src [amd64] (artful-proposed) [5.9.1-2]
-queuebot:#ubuntu-release- New: accepted qtwebview-opensource-src [armhf] (artful-proposed) [5.9.1-2]
-queuebot:#ubuntu-release- New binary: mapbox-wagyu [amd64] (artful-proposed/universe) [0.4.3-1] (no packageset)
<tsimonq2> Is anyone on the Release Team who happens to also be an Archive Admin around?
-queuebot:#ubuntu-release- Unapproved: coreutils (artful-proposed/main) [8.26-3ubuntu3 => 8.26-3ubuntu4] (core)
-queuebot:#ubuntu-release- Unapproved: accepted coreutils [source] (artful-proposed) [8.26-3ubuntu4]
-queuebot:#ubuntu-release- Unapproved: music (artful-proposed/universe) [1.0.7-2 => 1.0.7-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted music [sync] (artful-proposed) [1.0.7-4]
#ubuntu-release 2017-10-08
-queuebot:#ubuntu-release- Unapproved: gitg (artful-proposed/universe) [3.23.0-1 => 3.26.0-2~ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gitg [source] (artful-proposed) [3.26.0-2~ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gnome-todo (artful-proposed/universe) [3.25.90-0ubuntu1 => 3.26.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-todo [source] (artful-proposed) [3.26.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gnome-recipes (artful-proposed/universe) [1.6.2-1 => 1.6.2-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-recipes [sync] (artful-proposed) [1.6.2-2]
-queuebot:#ubuntu-release- Unapproved: libexif (artful-proposed/main) [0.6.21-2 => 0.6.21-2.1] (desktop-core, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: geoip (artful-proposed/main) [1.6.11-2 => 1.6.11-2ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (artful-proposed/main) [2.468 => 2.469] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (xenial-proposed) [2.408.19]
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.18 => 2.408.19] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (artful-proposed) [2.469]
-queuebot:#ubuntu-release- Unapproved: accepted geoip [source] (artful-proposed) [1.6.11-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: hitori (artful-proposed/universe) [3.22.3-1ubuntu1 => 3.22.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted hitori [source] (artful-proposed) [3.22.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (artful-proposed/main) [1.402 => 1.403] (core)
-queuebot:#ubuntu-release- Unapproved: firefox-kwallet5 (artful-proposed/universe) [1.3-1ubuntu1 => 1.3-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted firefox-kwallet5 [source] (artful-proposed) [1.3-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: ubuntu-budgie-meta (artful-proposed/universe) [0.16 => 0.17] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-budgie-meta [source] (artful-proposed) [0.17]
-queuebot:#ubuntu-release- Unapproved: ubuntu-gnome-meta (artful-proposed/universe) [0.80 => 0.81] (ubuntugnome)
<jbicha> ^ ubuntu-budgie-meta is obviously seeded but it looks like it was auto-accepted
-queuebot:#ubuntu-release- Unapproved: ubuntukylin-meta (artful-proposed/universe) [0.25 => 0.26] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-meta (artful-proposed/universe) [1.204 => 1.205] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: ubuntustudio-meta (artful-proposed/universe) [0.172 => 0.173] (ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: xubuntu-meta (artful-proposed/universe) [2.217 => 2.218] (xubuntu)
-queuebot:#ubuntu-release- Unapproved: libsemanage (artful-proposed/main) [2.7-1 => 2.7-2] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: gnome-photos (artful-proposed/universe) [3.26.0-1 => 3.26.1-1] (desktop-extra, ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: vala (artful-proposed/universe) [0.36.5-1 => 0.36.6-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: graphicsmagick (artful-proposed/universe) [1.3.26-12 => 1.3.26-13] (ubuntustudio) (sync)
-queuebot:#ubuntu-release- Unapproved: libva (artful-proposed/universe) [1.8.3-1 => 1.8.3-2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: nettle (artful-proposed/main) [3.3-1 => 3.3-2] (core) (sync)
#ubuntu-release 2018-10-01
-queuebot:#ubuntu-release- Unapproved: breezy (cosmic-proposed/universe) [3.0.0~bzr7111-1 => 3.0.0~bzr7119-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: twinkle (cosmic-proposed/universe) [1:1.10.1+dfsg-3 => 1:1.10.1+dfsg-3.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted breezy [sync] (cosmic-proposed) [3.0.0~bzr7119-1]
-queuebot:#ubuntu-release- Unapproved: accepted twinkle [sync] (cosmic-proposed) [1:1.10.1+dfsg-3.1]
-queuebot:#ubuntu-release- Unapproved: patsy (cosmic-proposed/universe) [0.4.1+git34-ga5b54c2-1 => 0.4.1+git34-ga5b54c2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted patsy [source] (cosmic-proposed) [0.4.1+git34-ga5b54c2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: compiz (cosmic-proposed/universe) [1:0.9.13.1+18.10.20180905-0ubuntu1 => 1:0.9.13.1+18.10.20180930-0ubuntu1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mutter [sync] (cosmic-proposed) [3.30.0-3]
-queuebot:#ubuntu-release- Unapproved: accepted mutter [sync] (cosmic-proposed) [3.30.0-4]
-queuebot:#ubuntu-release- Unapproved: accepted libzstd [source] (cosmic-proposed) [1.3.5+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (cosmic-proposed/main) [4.18.0-1002.2] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (cosmic-proposed) [4.18.0-1002.2]
-queuebot:#ubuntu-release- Unapproved: nvidia-prime (cosmic-proposed/main) [0.8.9 => 0.8.10] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: shared-mime-info (cosmic-proposed/main) [1.9-2 => 1.10-1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (cosmic-proposed/main) [1:0.5.4 => 1:0.5.5] (desktop-core, ubuntu-server)
<handsome_feng> Hi, Would someone help to upload the theme and wallpapers packages? LP: #1791416 LP: #179709 Thanks in advance!
<ubot5> Launchpad bug 1791416 in ubuntukylin-wallpapers (Ubuntu) "Please upgrade ubuntukylin-wallpapers to 18.10.1" [Undecided,New] https://launchpad.net/bugs/1791416
<ubot5> Launchpad bug 179709 in update-manager (Ubuntu) "i don't listen the audio" [Undecided,Invalid] https://launchpad.net/bugs/179709
<handsome_feng> Sorry... LP: #1794709
<ubot5> Launchpad bug 1794709 in ubuntukylin-theme (Ubuntu) "Please upgrade ubuntukylin-theme to 1.7.9.2" [Undecided,New] https://launchpad.net/bugs/1794709
<seb128> hey there, is there anything blocking that ffe to get reviewed, bug #1792356? it has been sitting there for 10 days waiting
<ubot5> bug 1792356 in colord (Ubuntu) "[ffe] Update to 1.4.3" [Wishlist,Triaged] https://launchpad.net/bugs/1792356
-queuebot:#ubuntu-release- Unapproved: cryptsetup (cosmic-proposed/main) [2:2.0.4-2ubuntu2 => 2:2.0.4-2ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: makedumpfile (cosmic-proposed/main) [1:1.6.4-2 => 1:1.6.4-2ubuntu1] (core)
<xnox> cascardo, ^^^ i believe the two above together should fix huge initrds for kdumps
<xnox> cascardo, first one, makes cryptsetup set FRAMEBUFFER conditionally, as to not override an existing value.
<xnox> cascardo, the second one, sets FRAMEBUFFER in the settings file. everything seems to work fine for me now.
<ahasenack> hello, good morning. Could someone look at https://code.launchpad.net/~paelzer/britney/hints-ubuntu-ocfs2-cosmic-bump/+merge/355482 for an update to ocfs2-tools hints? It doesn't work on s390x, known bug filed upstream
-queuebot:#ubuntu-release- Unapproved: r-cran-etm (cosmic-proposed/universe) [1.0.4-2 => 1.0.4-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-etm [source] (cosmic-proposed) [1.0.4-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: network-manager-applet (cosmic-proposed/main) [1.8.18-1ubuntu1 => 1.8.18-2ubuntu1] (ubuntu-desktop)
<GunnarHj> Hello, anybody in the release team who can look at the FFe request at bug #1791367?
<ubot5> bug 1791367 in xkeyboard-config (Ubuntu) "[FFe]: Airplane mode key on Asus ZenBook Flip UX561UD laptop not working in gnome-shell (X or Wayland) but working on console (Cosmic 18.10)" [High,New] https://launchpad.net/bugs/1791367
-queuebot:#ubuntu-release- Unapproved: libsdl2 (cosmic-proposed/universe) [2.0.8+dfsg1-2ubuntu1 => 2.0.8+dfsg1-4ubuntu1] (kubuntu)
<LocutusOfBorg> can we please have libsdl2 accepted? we added a testsuite to the package ^^
-queuebot:#ubuntu-release- Unapproved: xfce4-sensors-plugin (cosmic-proposed/universe) [1.3.0-1 => 1.3.0-2] (xubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: shellcheck (cosmic-proposed/universe) [0.4.7-1 => 0.5.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted shellcheck [sync] (cosmic-proposed) [0.5.0-1]
<LocutusOfBorg> libsdl2 will prevent breaking mir changes to migrate before libsdl being fixed
<LocutusOfBorg> also vulkan build regressions and other things
<ginggs> would someone please 'force-badtest pandas/0.23.3-1fakesync1ubuntu1' ? - i believe it has regressed in release http://autopkgtest.ubuntu.com/packages/p/pandas/cosmic/amd64
-queuebot:#ubuntu-release- Unapproved: yaru-theme (cosmic-proposed/main) [18.10.4 => 18.10.5] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: peruse (cosmic-proposed/universe) [1.2+dfsg+20180923-1 => 1.2+dfsg+20181001-1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: gocryptfs (cosmic-proposed/universe) [1.4.3-6 => 1.4.3-7] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gocryptfs [sync] (cosmic-proposed) [1.4.3-7]
-queuebot:#ubuntu-release- Unapproved: kannel (cosmic-proposed/universe) [1.4.5-0ubuntu1 => 1.4.5-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted kannel [source] (cosmic-proposed) [1.4.5-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: intel-vaapi-driver-shaders (cosmic-proposed/multiverse) [2.2.0-1 => 2.2.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted intel-vaapi-driver-shaders [sync] (cosmic-proposed) [2.2.0-2]
-queuebot:#ubuntu-release- Unapproved: enigmail (cosmic-proposed/universe) [2:2.0.8-1 => 2:2.0.8-2] (mozilla) (sync)
-queuebot:#ubuntu-release- Unapproved: update-manager (cosmic-proposed/main) [1:18.10.8 => 1:18.10.9] (core)
<cascardo> xnox: hum... I was sure I had another makedumpfile on the queue, so you replaced that one?
-queuebot:#ubuntu-release- Unapproved: spamassassin (cosmic-proposed/main) [3.4.1-8build1 => 3.4.2-1] (ubuntu-server) (sync)
<cascardo> ah... I was waiting for someone to sponsor it, but it wasn't sponsored
<xnox> cascardo, probably did not....
<xnox> cascardo, which one were you waiting on? bug #?
<rbalint_> infinity, i now referenced the remaining bugs in update-manager's .changes
<cascardo> xnox: LP: #1790788 and LP: #1655280
<ubot5> Launchpad bug 1790788 in makedumpfile (Ubuntu Cosmic) "Customize 'crashkernel' parameter is not properly working" [High,In progress] https://launchpad.net/bugs/1790788
<ubot5> Launchpad bug 1655280 in linux (Ubuntu) "ISST-LTE:pVM:roselp4:ubuntu 16.04: cp: error reading '/proc/vmcore': Bad address when trying to dump vmcore" [High,In progress] https://launchpad.net/bugs/1655280
<cascardo> but no debdiffs there, as my usual sponsors prefer some other method
<xnox> cascardo, but where is the code? do you have a repository somwhere or something?
<xnox> cascardo, also are any changes needed in s390-tools then as well? cause i thought we did set crashkernel paramemter default somewhere.
<xnox> also it was expected for crashkernel= to be on the kernel cmdline, as far as i understand there is no crashkernel key in zipl.conf
<xnox> so something is broken.
-queuebot:#ubuntu-release- Unapproved: boxbackup (cosmic-proposed/universe) [0.13~~git20180313.g16a11e86-1 => 0.13~~git20180313.g16a11e86-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted boxbackup [source] (cosmic-proposed) [0.13~~git20180313.g16a11e86-1ubuntu1]
<cascardo> the sed rule is broken
<cascardo> let me upload the debdiff to the bug
-queuebot:#ubuntu-release- Unapproved: kannel-sqlbox (cosmic-proposed/universe) [0.7.2-4build3 => 0.7.2-4build4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted kannel-sqlbox [source] (cosmic-proposed) [0.7.2-4build4]
<cascardo> I will test your fix before rebasing on top of it
-queuebot:#ubuntu-release- Unapproved: gnome-shell (cosmic-proposed/main) [3.30.0-1ubuntu2 => 3.30.0-3ubuntu1] (desktop-extra, mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: kdenetwork-filesharing (cosmic-proposed/universe) [4:18.04.3-0ubuntu1 => 4:18.04.3-0ubuntu2] (kubuntu)
<ahasenack> hi, this is about the squid3 src removal (replaced by just "squid", which is at v4.x): https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1793654
<ubot5> Ubuntu bug 1793654 in squid3 (Ubuntu) "Source removal: squid3" [Undecided,New]
<ahasenack> seeds were updated already
-queuebot:#ubuntu-release- Unapproved: accepted gnome-boxes [sync] (cosmic-proposed) [3.30.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted mysql-5.7 [source] (cosmic-proposed) [5.7.23-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted graphicsmagick [sync] (cosmic-proposed) [1.3.30+hg15796-1]
-queuebot:#ubuntu-release- Unapproved: accepted colord [sync] (cosmic-release) [1.4.3-3]
-queuebot:#ubuntu-release- Unapproved: rejected ukui-indicators [source] (cosmic-proposed) [1.1.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ukui-control-center [source] (cosmic-proposed) [1.1.6-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-report (cosmic-proposed/main) [1.3.0 => 1.4.0] (ubuntu-desktop)
<Laney> rbalint_: regarding the update-manager in the queue - I think E502 is telling you that to remove the backslashes, not the brackets
<Laney> Not sure that ignoring that one is the right thing to do
-queuebot:#ubuntu-release- Unapproved: accepted networkd-dispatcher [source] (cosmic-proposed) [1.7-0ubuntu7]
-queuebot:#ubuntu-release- Unapproved: accepted networkd-dispatcher [source] (cosmic-proposed) [1.7-0ubuntu8]
<rbalint_> Laney, yes, but if i remove the backslash it complains about line break before binary operator
-queuebot:#ubuntu-release- Unapproved: rejected protobuf [source] (cosmic-proposed) [3.0.0-9.2ubuntu1]
<seb128> is there any release team member active recently?
<didrocks> seb128: sil2100 acked my ubuntu-report FFe a couple of hours ago, so it sounds like yes
<seb128> Laney, oh, thanks for picking up colord :) (just saw the bug comment, I wrote this morning on IRC but the channel doesn't seem much active)
<seb128> I still wonder why it took 10 days+, if the triaged status contributed to have it mentaly filtered by some in a different category than if it has been New
<seb128> didrocks, good :)
<Laney> it's not mental filtering, it's actual filtering: I tend to look at "New" bugs most and the others a bit less often
<Laney> rbalint_: right, there's probably another way to indent those lines
-queuebot:#ubuntu-release- Unapproved: debian-installer (cosmic-proposed/main) [20101020ubuntu552 => 20101020ubuntu553] (core)
<Laney> and np on the review
 * Laney interleaves talking to different people without making it clear which line is for which person
<Laney> keeping you on your toes
<seb128> Laney, k, that makes sense, I note down to change back the status to "New" next time :)
<sil2100> Not sure what's this about but yeah, for instance I only look at FFe's that are 'New' or 'Confirmed', 'Triaged' in the FFe world means 'this has been handled'
<seb128> it was about https://bugs.launchpad.net/ubuntu/+source/colord/+bug/1792356 which was sitting there waiting for review for 10 days
<ubot5> Ubuntu bug 1792356 in colord (Ubuntu) "[ffe] Update to 1.4.3" [Wishlist,Fix released]
<seb128> but was set as Triaged
-queuebot:#ubuntu-release- Unapproved: python-apt (bionic-proposed/main) [1.6.2 => 1.6.3] (core)
<seb128> https://wiki.ubuntu.com/FreezeExceptionProcess mentions that it needs to be "New" though, so I need to remember that for next time :)
<Laney> rbalint_: It'd be OK to ignore W503 though I think, if that would help you (pycodestyle does that by default if I'm reading correctly)
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (cosmic-proposed) [1:2.12+dfsg-3ubuntu7]
-queuebot:#ubuntu-release- Unapproved: accepted libsecret [sync] (cosmic-proposed) [0.18.6-3]
<rbalint_> Laney, ok, let me give it a try
<Laney> great
-queuebot:#ubuntu-release- Unapproved: accepted ibus-pinyin [sync] (cosmic-proposed) [1.5.0-5]
-queuebot:#ubuntu-release- Unapproved: accepted pycodestyle [sync] (cosmic-proposed) [2.4.0-2]
-queuebot:#ubuntu-release- Unapproved: accepted pycodestyle [sync] (cosmic-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-settings (cosmic-proposed/main) [18.10.3 => 18.10.5] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: ubuntu-settings (cosmic-proposed/main) [18.10.3 => 18.10.6] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: python-apt (xenial-proposed/main) [1.1.0~beta1ubuntu0.16.04.2 => 1.1.0~beta1ubuntu0.16.04.3] (core)
<cascardo> xnox: so, I would reject that makedumpfile change. when used on an encrypted desktop, there is no idea what's going on
<xnox> cascardo, sorry, i'm struggling to understand you. could you please rephrase?
<xnox> "there is no idea what's going on" -> ?!
<cascardo> there is no display output
<cascardo> the user has no idea what's going on, no passphrase prompt is ever gonna show up
<xnox> that's unexpected.
<xnox> cascardo, and that's for normal boot right? rather than the kdump boot?
<cascardo> not really... without any framebuffer drivers on the initrd, there is no modesetting reset
<cascardo> no, that's the kdump boot
<cascardo> the one I care about  :-D
<xnox> cascardo, the one you complained about.... that cryptsetup sets FRAMEBUFFER=y and thus initrd is too large.
<xnox> cascardo, i did this change for you, as i thought that's what you want lol.
<cascardo> no, I am complaining about you changing makedumpfile to set FRAMEBUFFER=n
<cascardo> I don't want cryptsetup to set FRAMEBUFFER=y when the system is not encrypted
<cascardo> which I assume is the case on ADT systems
<xnox> sure, but then you still end up with a huge initrd
<cascardo> on encrypted systems, yes. the correct fix would be only to include the needed gpu drivers
<xnox> ah cause gpu drivers do not do sensible thing w.r.t. MODULES=most vs MODULES=dep ?
<cascardo> yep... all of them are included even with MODULES=dep
<xnox> cascardo, problem is that FRAMEBUFFER= is an option for a lot of things.... not just gpu drivers but also to include plymouth and a whole bunch of stuff.
<cascardo> well, just reducing the number of drivers would save a lot of space
<xnox> cascardo, so basically FRAMEBUFFER=y means "let's explode initrd size by many MBs for no reason"
<cascardo> they take most of it, from what I could analyze
<xnox> so plymouth framebuffer brltty console_setup keymap are all sensitive to FRAMEBUFFER=y option
<cascardo> also because of firmware
<xnox> plymouth is quite large, and i see no way to say "cryptsetup=y framebuffer=y plymouth=n"
<xnox> cause i don't think people care about fancy UI for kdumps.... maybe they do
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (bionic-proposed) [2.02-2ubuntu8.6]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (bionic-proposed) [2.02-2ubuntu8.6]
<xnox> horum
-queuebot:#ubuntu-release- Unapproved: shim-signed (bionic-proposed/main) [1.37~18.04.1 => 1.37~18.04.2] (core)
-queuebot:#ubuntu-release- Unapproved: rejected shim-signed [source] (bionic-proposed) [1.37~18.04.2]
<bluesabre> xnox, can you please accept/approve the elementary-xfce cosmic sync?
<bluesabre> :)
-queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (bionic-proposed) [1.37~18.04.2]
<infinity> bluesabre: xnox isn't in the release team.
<bluesabre> ah
<bluesabre> infinity: can you do it? (currently at work but wanted to get it moving while folks were still around)
<xnox> infinity, don't worry i typically silently ignore requests like that to me... just to keep people angry at the release team ;-)
<bluesabre> :D
<xnox> it would be nice if one could ping !sru !archive !release teams....
<infinity> xnox: I don't think it would help. :P
<infinity> xnox: (I also don't want to log on to 30 previously-actioned pings)
-queuebot:#ubuntu-release- Unapproved: accepted elementary-xfce [sync] (cosmic-proposed) [0.13.1-1]
<xnox> infinity, of course it won't, but at least the new excuse will be "but you didn't use the right bot ping command"
<bluesabre> infinity: much appreciated!
<xnox> infinity, but many people have no idea who are archive/release/sru team members....
<xnox> or the difference between the three....
<bluesabre> xnox: sorry for the noise, but thanks for being a good highlight :)
<xnox> bluesabre, mostly because infinity highlights on xnox just to monitor the batshit crazy things i do ;-)
<bluesabre> (thank goodness)
<infinity> Hahaha.  I don't, but that sounds like a solid plan going forward.
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (cosmic-proposed) [20101020ubuntu553]
<infinity> Have to keep the Russian trolls in check.
-queuebot:#ubuntu-release- Unapproved: rejected update-manager [source] (cosmic-proposed) [1:18.10.9]
<xnox> infinity, i highlight on "s390x" and it's interesting when like "juju" "maas" "openstack" "snapd" "snapcraft" channel lit up. Also i bet with all these words, i'll trigger a few people right now too =)))) muahahhahaha
<infinity> xnox: Several of those words trigger me, yes. :P
<xnox> infinity, can you reject cryptsetup and makedumpfile from cosmic unappoved queue for now?
-queuebot:#ubuntu-release- Unapproved: update-manager (cosmic-proposed/main) [1:18.10.8 => 1:18.10.9] (core)
<xnox> infinity, i think there is no consensus yet, if that's what in fact we want to do.
<xnox> so better have it rejected, for now, and resurrect later if the bikeshed goes that way.
-queuebot:#ubuntu-release- Unapproved: accepted apturl [source] (bionic-proposed) [0.5.2ubuntu14.2]
-queuebot:#ubuntu-release- Unapproved: rejected cryptsetup [source] (cosmic-proposed) [2:2.0.4-2ubuntu3]
-queuebot:#ubuntu-release- Unapproved: rejected makedumpfile [source] (cosmic-proposed) [1:1.6.4-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: heat (bionic-proposed/main) [1:10.0.1-0ubuntu2 => 1:10.0.2-0ubuntu1] (openstack, ubuntu-server)
<xnox> tah
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [source] (cosmic-proposed) [3.30.0-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted network-manager-applet [source] (cosmic-proposed) [1.8.18-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kdenetwork-filesharing [source] (cosmic-proposed) [4:18.04.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted yaru-theme [source] (cosmic-proposed) [18.10.5]
<infinity> jdstrand: Why did your evince apparmor profile overhaul delete the Author lines?
<infinity> jdstrand: You consider it enough of a rewrite that Kees's bits are gone?
<jdstrand> infinity: more that the profile has had many authors and kees and I shouldn't get direct bug reports
<infinity> Well, kees wouldn't, cause that email is dead. ;)
<jdstrand> I mean, I can add them back, but we've gotten away from that typically, so I just removed them
<infinity> jdstrand: I don't like seeing attribution removed, generally.  But if kees is party to this and also doesn't care, then yay.
<infinity> (not like any future employer will be judging him based on his portfolio of evince apparmor profiles)
<infinity> xnox: Why are all these openssl rebuilds necessary?  Feature detection at build time?
<infinity> xnox: And, if so, did you investigate which packages actually need that, or is this just a napalm rebuild of all rdeps "just in case"?
<jdstrand> well, I didn't consult with kees. I guess I can real quick
<jdstrand> kees: do you mind that I dropped our names from the evince profile? if so, I can add it back
<infinity> jdstrand: That'd be the polite thing to do (I mean, unless there's an AUTHORS file elsewhere that consolidates, and you're just removing redundant headers, but I imagine that's not the case here)
<jdstrand> it isn't
-queuebot:#ubuntu-release- Unapproved: accepted gnome-pkg-tools [source] (cosmic-proposed) [0.20.2ubuntu3]
<kees> jdstrand, infinity: I'm totally fine with that removal. :)
<infinity> kees: Shiny.
<infinity> Now if only I knew someone who was competent enough to review this diff.
 * infinity stares at kees.
-queuebot:#ubuntu-release- Unapproved: rejected nvidia-prime [source] (cosmic-proposed) [0.8.10]
<kees> infinity: where can I find it?
<infinity> kees: http://launchpadlibrarian.net/390908576/evince_3.30.0-3_3.30.0-3ubuntu1.diff.gz
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (bionic-proposed) [1.6.5]
<xnox> infinity, based on grep for libssl1.1 (>= 1.1.1) from ppa:xnox/ubuntu/openssl -> rebuilding these makes them dep on 1.1.1 rather than 1.1.0
<xnox> infinity, so they use something from 1.1.1 symbols....
<infinity> xnox: That alone isn't a reason to rebuild.
<infinity> xnox: By that logic, we'd rebuild ~50% of libc's rdeps every cycle.
<cjwatson> When I don't want somebody to get support email but want to keep their attribution, I generally compromise by keeping their name but removing their email address.
<xnox> infinity, and eg. curl without rebuild cannot do --tlsv1.3 the flag is there but it claims that "openssl is built without tls 1.3 support"
<xnox> infinity, with rebuild it starts to be able to do tlsv1.3 downloads
<xnox> and --tlsv1.3 flag becomes operational.
<jdstrand> kees: thanks!
<infinity> xnox: Right, so that's a solid argument for cURL.  My question was how you arrived at the conclusion that everything needed that. :)
<kees> infinity: looks good to me. much more restrictive. nice! :)
<infinity> Having a hard time picturing you saying that in anything but leather.
<xnox> infinity, the rest is based on the symbols dep. meaning they use symbols needed to e.g. renew keys in tls 1.3 and the like.
<infinity> jdstrand: Is there any prior art for dynamically creating some of these nastier profile bits?  My only concern is stuff like the "supported archivers" section, where if upstream adds another, the profile will be busted.
<xnox> infinity, this is consisent with how 1.2 was enabled. and e.g. apache2 was shipped for a long time non-rebuilt, and thus didn't do tls1.2......
<infinity> jdstrand: Ditto on supported file formats.
<jdstrand> infinity: no. note that what I added there came from the existing evince abstractions
<jdstrand> abstraction*
<xnox> (note apache2 is not rebuilt, cause mod_ssl only does tls1.3 in trunk; and not in the archive)
<jdstrand> which was too lenient
<jdstrand> I mean, I could've blacklisted or I could take what I wanted from there
<jdstrand> I went with the latter since the former was a bit of what got us in trouble
<infinity> jdstrand: Yeah, I'm not implying any of this is wrong, just that it would be nice to be able to tie into the build system (even with some nasty rgreppry and seddery) to try to determine at build time *what* archivers and formats we should whitelist.
<jdstrand> and for the file rules, I only really modified the thumbnailer. evince and previewer are still using the evince abstraction
<infinity> jdstrand: But also not saying that should block this upload.  Just suggesting it might bite you next year.
<jdstrand> infinity: that would indeed be nice
<jdstrand> there was in ancient days work to statically analyze binaries to suggest profiles
<jdstrand> but that hasn't really been a thing for a long time
<xnox> infinity, my primary concern was for post-release SRU or Security uploads to these packages to not cause a radically new behavior due to them starting to utilize tlsv1.3 / openssl 1.1.1 apis.
<infinity> xnox: Mmkay.  I'm 75% convinced.
<infinity> xnox: My take would be "if it's a new version of an existing symbol, meh, but if it's a new symbol entirely, rebuilding probably picked up new functionality", but given the mess that is OpenSSL, I'm not sure I'd count on being able to make that call reliably.,
<infinity> So, churn on, I guess.
-queuebot:#ubuntu-release- Unapproved: accepted evince [source] (cosmic-proposed) [3.30.0-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ldns [source] (cosmic-proposed) [1.7.0-3ubuntu7]
-queuebot:#ubuntu-release- Unapproved: accepted python-cryptography [source] (cosmic-proposed) [2.3-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted nghttp2 [source] (cosmic-proposed) [1.32.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted unbound [source] (cosmic-proposed) [1.7.3-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted curl [source] (cosmic-proposed) [7.61.0-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted erlang [source] (cosmic-proposed) [1:20.3.8.5+dfsg-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted dovecot [source] (cosmic-proposed) [1:2.3.2.1-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted haproxy [source] (cosmic-proposed) [1.8.13-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted bind9 [source] (cosmic-proposed) [1:9.11.4+dfsg-3ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted libnet-dns-sec-perl [source] (cosmic-proposed) [1.09-1build1]
<xnox> infinity, it's a shame w.r.t. libssl and libcrypto shipped together. most of libcrypto new symbols are that "new editions of the same thing" at least to me; and the libssl ones are all "new functionality looking" -> ie. calls and stuff to do things with the new tls v1.3 handshake / session. =/
-queuebot:#ubuntu-release- Unapproved: accepted vlc [source] (cosmic-proposed) [3.0.4-2build1]
<xnox> cause one cannot do old v1.2 callbacks and things for v1.3 session key updates and the like. Hence nodejs appears to struggle to support tls v1.3 -> all of their tests fail.
<xnox> most likely nodejs 11 will ship with using 1.1.x abi, and set upper limit to v1.2.
<xnox> until they rewrite all of their code to be v1.3 compatible isntead of relying on debug/tracing apis.
-queuebot:#ubuntu-release- Unapproved: rejected calibre [sync] (cosmic-proposed) [3.32.0+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: rejected krita [sync] (cosmic-proposed) [1:4.1.3+dfsg-1]
<infinity> xnox: nodejs is a tire fire, that's not news.
-queuebot:#ubuntu-release- Unapproved: rejected update-manager [source] (cosmic-proposed) [1:18.10.9]
-queuebot:#ubuntu-release- Unapproved: accepted vala-panel-appmenu [sync] (cosmic-proposed) [0.7.1+dfsg1-1]
-queuebot:#ubuntu-release- Unapproved: accepted vala-panel [sync] (cosmic-proposed) [0.4.63+dfsg1-1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-maps [sync] (cosmic-proposed) [3.30.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted krita [sync] (cosmic-proposed) [1:4.1.3+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: accepted catfish [sync] (cosmic-proposed) [1.4.6-1]
-queuebot:#ubuntu-release- Unapproved: accepted entangle [sync] (cosmic-proposed) [1.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-initramfs-tools [source] (bionic-proposed) [0.40ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-initramfs-tools [source] (xenial-proposed) [0.27ubuntu1.6]
-queuebot:#ubuntu-release- Unapproved: plymouth (cosmic-proposed/main) [0.9.3-1ubuntu8 => 0.9.3-1ubuntu9] (core)
-queuebot:#ubuntu-release- Unapproved: accepted python-apt [source] (bionic-proposed) [1.6.3]
-queuebot:#ubuntu-release- Unapproved: keystone (bionic-proposed/main) [2:13.0.0-0ubuntu1 => 2:13.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: strongswan (cosmic-proposed/main) [5.6.3-1ubuntu2 => 5.6.3-1ubuntu3] (ubuntu-server)
<cyphermox> could someone please badtest ubuntu-image autopkgtests for grub2; the issue comes from the new pycodestyle check for escape sequences, not a bug in grub or ubuntu-image.
<cyphermox> qa runtests: commands[0] | python -m flake8 ubuntu_image
<cyphermox> ubuntu_image/helpers.py:68:7: W605 invalid escape sequence '\d'
<cyphermox> (it would unblock grub2)
<tjaalton> and please check the new queue and review spirv-tools & vulkan-*
<infinity> cyphermox: Done.
<infinity> sil2100: Please fix ubuntu-image's W605 errors (see ubiquity trunk for prior art)
<vorlon> cyphermox: why/when did pycodestyle sneak in?  indirect test dep?
<teward> cyphermox: this'll sound like a stupid question, but why not alter the autopkgtests to set up Flake8 to *not* trigger on W605?
<infinity> teward: Err, you mean the autopkgtest infra, or the ubuntu-image tests?
<infinity> The former certainly isn't going to happen.
<infinity> The latter could be done, sure.
<infinity> But if one's fixing ubuntu-image to not fail, they could fix the bug too. :P
<teward> infinity: the ubuntu-image tests
<teward> i was imprecise, my apologies
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (xenial-proposed) [1.2.28]
<teward> infinity: It might mean the autopkgtests have to generate a tox.ini unless one ships with ubuntu-image but you would be able to block the W605 triggers, or other stylistic warnings you don't want to trigger on
<teward> not the *nicest* if you want to be fully PEP8 compliant but
<teward> (and you're right, they could fix the bug too if they're fixing it to not fail)
<infinity> teward: Yeah, I'm not sure the point of this bikeshed.
<infinity> teward: I imagine everyone who uses pycodestyle knows how to ask it to ignore things.  But ignoring things isn't always the best option.
<infinity> (In this case, it's not, IMO)
<infinity> vorlon: You can blame mwhudson for the new pycodestyle.  As for the "sneaking in", that might be britney's fault for not recursing.  Most tests probably depend on pep8 still.
<teward> infinity: i... may have a fix that's a single-character change for Cosmic, let me do some tests...
<infinity> (The lack of recursion was a heated point of contention between pitti and I, his argument being that recursion would cripple the infra without getting us much more useful testing, while I argued that things like the above happen)
<infinity> teward: Yes, it's a single-char fix. :P
<infinity> teward: I was asking sil2100 to fix it because he's upstream, not because I couldn't.
<teward> ack
<teward> :)
<sil2100> infinity: o/
-queuebot:#ubuntu-release- Unapproved: accepted python-apt [source] (xenial-proposed) [1.1.0~beta1ubuntu0.16.04.3]
<sil2100> bleh
<sil2100> (on it)
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-workspaces-to-dock (cosmic-proposed/universe) [48-2 => 49-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-workspaces-to-dock [sync] (cosmic-proposed) [49-1]
-queuebot:#ubuntu-release- Unapproved: uwsgi (cosmic-proposed/universe) [2.0.17.1-6 => 2.0.17.1-7] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted uwsgi [sync] (cosmic-proposed) [2.0.17.1-7]
<infinity> vorlon: Ultimately, I think pitti's probably right about the recursion issue (if britney recursed fully to determine test rdeps, glibc would trigger literally every test in the archive, and perl would be close), but OTOH, I have no good answer for problems like the above, where a commonly-depended-on package becomes a transitional and suddenly a useless test trigger.
-queuebot:#ubuntu-release- Unapproved: firejail (cosmic-proposed/universe) [0.9.54-1 => 0.9.56-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted firejail [sync] (cosmic-proposed) [0.9.56-1]
<cyphermox> vorlon: IIRC it was uploaded as https://launchpad.net/ubuntu/+source/pycodestyle/2.4.0-0ubuntu1 around 09/20
<cyphermox> vorlon: infinity and I investigated that coming up first when we last uploaded ubiquity
<vorlon> cyphermox: ok
<cyphermox> in this case it's definitely a one-char fix :)
-queuebot:#ubuntu-release- Unapproved: linux-kvm (cosmic-proposed/main) [4.18.0-1001.1 => 4.18.0-1002.2] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-kvm (cosmic-proposed/main) [4.18.0.1001.1 => 4.18.0.1002.2] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-image (cosmic-proposed/main) [1.4+18.10ubuntu2 => 1.4+18.10ubuntu3] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted linux-kvm [sync] (cosmic-proposed) [4.18.0-1002.2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-kvm [sync] (cosmic-proposed) [4.18.0.1002.2]
-queuebot:#ubuntu-release- Unapproved: accepted plymouth [source] (cosmic-proposed) [0.9.3-1ubuntu9]
-queuebot:#ubuntu-release- Unapproved: accepted strongswan [source] (cosmic-proposed) [5.6.3-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted nautilus [source] (cosmic-proposed) [1:3.26.4-0ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted libsdl2 [source] (cosmic-proposed) [2.0.8+dfsg1-4ubuntu1]
<sil2100> ubuntu-image in the queue ^
<sil2100> Anyway, I go EOD now
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (cosmic-proposed) [1.4+18.10ubuntu3]
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-settings [source] (cosmic-proposed) [18.10.5]
-queuebot:#ubuntu-release- Unapproved: accepted mate-tweak [source] (cosmic-proposed) [18.10.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: breeze (cosmic-proposed/universe) [4:5.13.5-0ubuntu1 => 4:5.13.5-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: firefox (cosmic-proposed/main) [62.0+build2-0ubuntu1 => 62.0.3+build1-0ubuntu1] (kubuntu, mozilla, ubuntu-desktop)
<jbicha> we don't do anything with autopkgtest "Restrictions: flaky" yet, right?
<vorlon> jbicha: correct
-queuebot:#ubuntu-release- New sync: appmenu-registrar (cosmic-proposed/primary) [0.7.1-1]
#ubuntu-release 2018-10-02
-queuebot:#ubuntu-release- Unapproved: nova (bionic-proposed/main) [2:17.0.5-0ubuntu2 => 2:17.0.6-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: horizon (cosmic-proposed/main) [3:14.0.0-0ubuntu3 => 3:14.0.0-0ubuntu4] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-eventlet (cosmic-proposed/main) [0.20.0-4ubuntu1 => 0.20.0-5] (openstack, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (bionic-proposed/main) [0.130ubuntu3.5 => 0.130ubuntu3.6] (core)
-queuebot:#ubuntu-release- Unapproved: rejected initramfs-tools [source] (bionic-proposed) [0.130ubuntu3.6]
-queuebot:#ubuntu-release- Unapproved: websocket-client (cosmic-proposed/universe) [0.48.0-1 => 0.53.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted websocket-client [sync] (cosmic-proposed) [0.53.0-1]
<RAOF> Is there anything I can do to help the yaml-cpp MIR (and, thus, Mir 1.0.0 in Cosmic) along https://bugs.launchpad.net/ubuntu/+source/yaml-cpp/+bug/1794692 ?
<ubot5> Ubuntu bug 1794692 in yaml-cpp (Ubuntu) "[MIR] yaml-cpp" [Undecided,New]
<sil2100> Ok, nice, suddendly most u-i autopkgtests on cosmic started failing, geh
<sil2100> Not only on the version from yesterday, but also on the version in the archive
-queuebot:#ubuntu-release- Unapproved: llvm-toolchain-snapshot (cosmic-proposed/universe) [1:8~svn342638-1 => 1:8~svn343154-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-snapshot [sync] (cosmic-proposed) [1:8~svn343154-1]
<sil2100> Of course, new voluptuous synced 13 hours ago
<sil2100> ubuntu-image had some issues with the latest pip versions when building the snap, so probably now that version got synced into Debian and Ubuntu
<sil2100> grrrr
-queuebot:#ubuntu-release- Unapproved: accepted mate-hud [source] (cosmic-proposed) [18.10.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-settings [source] (cosmic-proposed) [18.10.6]
<oSoMoN> can someone accept firefox into cosmic-proposed, please?
-queuebot:#ubuntu-release- Unapproved: ubuntu-make (cosmic-proposed/universe) [18.05 => 18.09] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-make [source] (cosmic-proposed) [18.09]
-queuebot:#ubuntu-release- Unapproved: sagemath (cosmic-proposed/universe) [8.2-5ubuntu2 => 8.3-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted sagemath [source] (cosmic-proposed) [8.3-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: julia (cosmic-proposed/universe) [1.0.0-0ubuntu5 => 1.0.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted julia [source] (cosmic-proposed) [1.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: flint-arb (cosmic-proposed/universe) [1:2.12.0-3 => 1:2.14.0-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted flint-arb [sync] (cosmic-proposed) [1:2.14.0-4]
-queuebot:#ubuntu-release- Unapproved: fplll (cosmic-proposed/universe) [5.2.0-3build1 => 5.2.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: fpylll (cosmic-proposed/universe) [0.3.0+ds-3build1 => 0.4.1+ds1-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted fplll [sync] (cosmic-proposed) [5.2.1-2]
-queuebot:#ubuntu-release- Unapproved: maxima-sage (cosmic-proposed/universe) [5.39.0+ds-3 => 5.41.0+ds-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted fpylll [sync] (cosmic-proposed) [0.4.1+ds1-3]
-queuebot:#ubuntu-release- Unapproved: pynac (cosmic-proposed/universe) [0.7.19-2 => 0.7.22-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted maxima-sage [sync] (cosmic-proposed) [5.41.0+ds-2]
-queuebot:#ubuntu-release- Unapproved: accepted pynac [sync] (cosmic-proposed) [0.7.22-2]
<sil2100> infinity: eh, because of your hint on ubuntu-image/1.4+18.10ubuntu2, the new voluptuous migrated from -proposed and caused regressions in ubuntu-image
<sil2100> infinity: there seems to be something highly incompatible between how we used voluptuous 0.9.x and the new 0.11.x and this will require some rewrites in ubuntu-image
<sil2100> Guess I'll just have to release a new ubuntu-image ;/
<sil2100> Need to see what actually changed in voluptuous that we're no longer compatible, I saw this already in the past with our snap builds when we used pip there instead of debs
-queuebot:#ubuntu-release- New binary: fplll [s390x] (cosmic-proposed/universe) [5.2.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pynac [s390x] (cosmic-proposed/universe) [0.7.22-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pynac [ppc64el] (cosmic-proposed/universe) [0.7.22-2] (no packageset)
<Wimpress> sil2100: And chance you can accept ubuntu-mate-artwork in the NEW queue for cosmic please?
-queuebot:#ubuntu-release- New binary: fplll [ppc64el] (cosmic-proposed/universe) [5.2.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pynac [amd64] (cosmic-proposed/universe) [0.7.22-2] (no packageset)
<sil2100> Wimpress, oSoMoN: let me take a look
-queuebot:#ubuntu-release- New binary: fplll [amd64] (cosmic-proposed/universe) [5.2.1-2] (no packageset)
<cjwatson> wxl: Is the isolinux artwork still a problem today?  It took me a while to get an image downloaded, but the one I finally got hold of (from yesterday, I think) seems to show the splash OK for me
<oSoMoN> sil2100, thanks, much appreciated!
-queuebot:#ubuntu-release- New binary: pynac [arm64] (cosmic-proposed/universe) [0.7.22-2] (no packageset)
<didrocks> sil2100: if you wonder about the ubuntu-report diff, every change in vendor/ is how Go 1.11 is generating the vendor directory now (it doesn't filter README.md or .pl files for instance), but those files aren't used
<didrocks> however, they do remove LICENSE files now for vendor :)
-queuebot:#ubuntu-release- New binary: pynac [i386] (cosmic-proposed/universe) [0.7.22-2] (no packageset)
-queuebot:#ubuntu-release- New binary: fplll [arm64] (cosmic-proposed/universe) [5.2.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pynac [armhf] (cosmic-proposed/universe) [0.7.22-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted pynac [amd64] (cosmic-proposed) [0.7.22-2]
-queuebot:#ubuntu-release- New: accepted pynac [armhf] (cosmic-proposed) [0.7.22-2]
-queuebot:#ubuntu-release- New: accepted pynac [ppc64el] (cosmic-proposed) [0.7.22-2]
-queuebot:#ubuntu-release- New: accepted pynac [arm64] (cosmic-proposed) [0.7.22-2]
-queuebot:#ubuntu-release- New: accepted pynac [s390x] (cosmic-proposed) [0.7.22-2]
-queuebot:#ubuntu-release- New: accepted pynac [i386] (cosmic-proposed) [0.7.22-2]
-queuebot:#ubuntu-release- New: accepted fplll [amd64] (cosmic-proposed) [5.2.1-2]
-queuebot:#ubuntu-release- New: accepted fplll [ppc64el] (cosmic-proposed) [5.2.1-2]
-queuebot:#ubuntu-release- New: accepted ubuntu-mate-artwork [amd64] (cosmic-proposed) [18.10.1]
-queuebot:#ubuntu-release- New binary: fplll [armhf] (cosmic-proposed/universe) [5.2.1-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted fplll [arm64] (cosmic-proposed) [5.2.1-2]
-queuebot:#ubuntu-release- New: accepted ubuntu-wallpapers [amd64] (cosmic-proposed) [18.10.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted fplll [s390x] (cosmic-proposed) [5.2.1-2]
-queuebot:#ubuntu-release- New: accepted android-platform-system-core [amd64] (cosmic-proposed) [1:8.1.0+r23-1~stage1.2ubuntu1]
-queuebot:#ubuntu-release- New: accepted android-platform-system-core [armhf] (cosmic-proposed) [1:8.1.0+r23-1~stage1.2ubuntu1]
-queuebot:#ubuntu-release- New: accepted appmenu-registrar [sync] (cosmic-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted android-platform-system-core [arm64] (cosmic-proposed) [1:8.1.0+r23-1~stage1.2ubuntu1]
-queuebot:#ubuntu-release- New: accepted fplll [armhf] (cosmic-proposed) [5.2.1-2]
-queuebot:#ubuntu-release- New: accepted android-platform-system-core [i386] (cosmic-proposed) [1:8.1.0+r23-1~stage1.2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gnome-initial-setup (cosmic-proposed/main) [3.29.92-1ubuntu3 => 3.30.0-1ubuntu1] (ubuntu-desktop, ubuntugnome)
-queuebot:#ubuntu-release- New binary: fplll [i386] (cosmic-proposed/universe) [5.2.1-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted firefox [source] (cosmic-proposed) [62.0.3+build1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: appmenu-registrar [s390x] (cosmic-proposed/none) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: appmenu-registrar [ppc64el] (cosmic-proposed/none) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: appmenu-registrar [amd64] (cosmic-proposed/universe) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: appmenu-registrar [i386] (cosmic-proposed/universe) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: appmenu-registrar [arm64] (cosmic-proposed/universe) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: appmenu-registrar [armhf] (cosmic-proposed/universe) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted vim-julia [source] (cosmic-proposed) [0.0~git20180821.120a0b6-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted appmenu-registrar [amd64] (cosmic-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted appmenu-registrar [armhf] (cosmic-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted appmenu-registrar [ppc64el] (cosmic-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted fplll [i386] (cosmic-proposed) [5.2.1-2]
-queuebot:#ubuntu-release- New: accepted appmenu-registrar [arm64] (cosmic-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted appmenu-registrar [s390x] (cosmic-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted appmenu-registrar [i386] (cosmic-proposed) [0.7.1-1]
<doko> RAOF: replied
-queuebot:#ubuntu-release- New binary: vim-julia [amd64] (cosmic-proposed/none) [0.0~git20180821.120a0b6-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: fpylll [s390x] (cosmic-proposed/universe) [0.4.1+ds1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: fpylll [amd64] (cosmic-proposed/universe) [0.4.1+ds1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: fpylll [ppc64el] (cosmic-proposed/universe) [0.4.1+ds1-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted vim-julia [amd64] (cosmic-proposed) [0.0~git20180821.120a0b6-0ubuntu1]
-queuebot:#ubuntu-release- New binary: fpylll [armhf] (cosmic-proposed/universe) [0.4.1+ds1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: fpylll [arm64] (cosmic-proposed/universe) [0.4.1+ds1-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gap-float (cosmic-proposed/universe) [0.9.0+ds-4build1 => 0.9.1+ds-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gap-float [sync] (cosmic-proposed) [0.9.1+ds-1]
-queuebot:#ubuntu-release- Unapproved: sollya (cosmic-proposed/universe) [6.0+ds-6build1 => 6.0+ds-6build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted sollya [source] (cosmic-proposed) [6.0+ds-6build2]
-queuebot:#ubuntu-release- New binary: fpylll [i386] (cosmic-proposed/universe) [0.4.1+ds1-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xdg-utils (bionic-proposed/main) [1.1.2-1ubuntu2.2 => 1.1.2-1ubuntu2.3] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: xdg-utils (cosmic-proposed/main) [1.1.3-1ubuntu1 => 1.1.3-1ubuntu2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted fpylll [amd64] (cosmic-proposed) [0.4.1+ds1-3]
-queuebot:#ubuntu-release- New: accepted fpylll [armhf] (cosmic-proposed) [0.4.1+ds1-3]
-queuebot:#ubuntu-release- New: accepted fpylll [ppc64el] (cosmic-proposed) [0.4.1+ds1-3]
-queuebot:#ubuntu-release- New: accepted fpylll [arm64] (cosmic-proposed) [0.4.1+ds1-3]
-queuebot:#ubuntu-release- New: accepted fpylll [s390x] (cosmic-proposed) [0.4.1+ds1-3]
-queuebot:#ubuntu-release- New: accepted fpylll [i386] (cosmic-proposed) [0.4.1+ds1-3]
-queuebot:#ubuntu-release- Unapproved: log4shib (cosmic-proposed/universe) [1.0.9-4 => 2.0.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted log4shib [sync] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New binary: log4shib [s390x] (cosmic-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: log4shib [ppc64el] (cosmic-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: log4shib [amd64] (cosmic-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: log4shib [arm64] (cosmic-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: log4shib [armhf] (cosmic-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: log4shib [i386] (cosmic-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-toolchain-snapshot [ppc64el] (cosmic-proposed/universe) [1:8~svn343154-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xml-security-c (cosmic-proposed/universe) [1.7.3-4build1 => 2.0.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted xml-security-c [sync] (cosmic-proposed) [2.0.1-1]
-queuebot:#ubuntu-release- Unapproved: shibboleth-sp2 (cosmic-proposed/universe) [2.6.1+dfsg1-2 => 3.0.2+dfsg0-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted shibboleth-sp2 [sync] (cosmic-proposed) [3.0.2+dfsg0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: xml-security-c [s390x] (cosmic-proposed/universe) [2.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xml-security-c [ppc64el] (cosmic-proposed/universe) [2.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xml-security-c [i386] (cosmic-proposed/universe) [2.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xml-security-c [arm64] (cosmic-proposed/universe) [2.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xml-security-c [armhf] (cosmic-proposed/universe) [2.0.1-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: 389-ds-base (cosmic-proposed/universe) [1.4.0.16-1 => 1.4.0.16-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted 389-ds-base [source] (cosmic-proposed) [1.4.0.16-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: freeipa (cosmic-proposed/universe) [4.7.0-1 => 4.7.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted freeipa [source] (cosmic-proposed) [4.7.0-1ubuntu1]
-queuebot:#ubuntu-release- New binary: xml-security-c [amd64] (cosmic-proposed/universe) [2.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted log4shib [amd64] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted log4shib [armhf] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted log4shib [ppc64el] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted xml-security-c [amd64] (cosmic-proposed) [2.0.1-1]
-queuebot:#ubuntu-release- New: accepted xml-security-c [armhf] (cosmic-proposed) [2.0.1-1]
-queuebot:#ubuntu-release- New: accepted xml-security-c [ppc64el] (cosmic-proposed) [2.0.1-1]
-queuebot:#ubuntu-release- New: accepted log4shib [arm64] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted log4shib [s390x] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted xml-security-c [i386] (cosmic-proposed) [2.0.1-1]
-queuebot:#ubuntu-release- New: accepted log4shib [i386] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted xml-security-c [s390x] (cosmic-proposed) [2.0.1-1]
-queuebot:#ubuntu-release- New: accepted xml-security-c [arm64] (cosmic-proposed) [2.0.1-1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-snapshot [ppc64el] (cosmic-proposed) [1:8~svn343154-1]
-queuebot:#ubuntu-release- New binary: xmltooling [s390x] (cosmic-proposed/universe) [3.0.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: xmltooling [ppc64el] (cosmic-proposed/universe) [3.0.2-1ubuntu1] (no packageset)
<rbalint_> Laney, infinity: is there anything i should do to update-manager for cosmic? i did not do all the paperwork for FFe because it may not be needed, but i can finish the rest
<Laney> rbalint_: It's resting in the queue now, but whoever reviews it will let you know if they have any questions
-queuebot:#ubuntu-release- New binary: xmltooling [arm64] (cosmic-proposed/universe) [3.0.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: xmltooling [i386] (cosmic-proposed/universe) [3.0.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: xmltooling [armhf] (cosmic-proposed/universe) [3.0.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted xmltooling [arm64] (cosmic-proposed) [3.0.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted xmltooling [i386] (cosmic-proposed) [3.0.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted xmltooling [s390x] (cosmic-proposed) [3.0.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted xmltooling [armhf] (cosmic-proposed) [3.0.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted xmltooling [ppc64el] (cosmic-proposed) [3.0.2-1ubuntu1]
-queuebot:#ubuntu-release- New binary: xmltooling [amd64] (cosmic-proposed/universe) [3.0.2-1ubuntu1] (no packageset)
<ahasenack> hi release team, are you ok with an upload that only adds dep8 tests, no other changes? There are no dep8 tests currently for this package. It's a seeded package (sssd). Or do I need an FFe if I really want it in now?
<rbasak> I'm not on the release team, but I believe dep8 only changes are fine and don't need an FFe.
-queuebot:#ubuntu-release- Unapproved: neutron (bionic-proposed/main) [2:12.0.3-0ubuntu1 => 2:12.0.4-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: qutebrowser (cosmic-proposed/universe) [1.4.2-1 => 1.4.2-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted qutebrowser [sync] (cosmic-proposed) [1.4.2-2]
-queuebot:#ubuntu-release- Unapproved: libtgvoip (cosmic-proposed/universe) [2.2.3+git20180828.31fe4af-1 => 2.2.4-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libtgvoip [sync] (cosmic-proposed) [2.2.4-1]
-queuebot:#ubuntu-release- Unapproved: libreoffice (cosmic-proposed/main) [1:6.1.1-0ubuntu1 => 1:6.1.2-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: libreoffice-l10n (cosmic-proposed/main) [1:6.1.1-0ubuntu1 => 1:6.1.2-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: bzflag (cosmic-proposed/universe) [2.4.14-1 => 2.4.16-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted bzflag [sync] (cosmic-proposed) [2.4.16-1]
-queuebot:#ubuntu-release- Unapproved: enigmail (cosmic-proposed/universe) [2:2.0.8-1 => 2:2.0.8-3] (mozilla) (sync)
<oSoMoN> can someone accept libreoffice{,-l10n} into cosmic-proposed, please?
<seb128> and gnome-initial-setup
<Laney> everything will be reviewed
<seb128> and ubuntu-report
-queuebot:#ubuntu-release- Unapproved: packagekit (bionic-proposed/main) [1.1.9-1ubuntu2.18.04.1 => 1.1.9-1ubuntu2.18.04.2] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: packagekit (xenial-proposed/main) [0.8.17-4ubuntu6~gcc5.4ubuntu1.3 => 0.8.17-4ubuntu6~gcc5.4ubuntu1.4] (kubuntu, ubuntu-desktop)
<ahayzen> Hey, is someone able to reject flatpak-builder for bionic ? I have a new debdiff which I want to use instead and have a comment here detailing that https://bugs.launchpad.net/ubuntu/+source/flatpak-builder/+bug/1794875/comments/1
<ubot5> Ubuntu bug 1794875 in flatpak-builder (Ubuntu Bionic) "[SRU] Autopkgtests fail with flatpak 1.0.X, due to missing -y in test scripts" [High,In progress]
-queuebot:#ubuntu-release- Unapproved: rejected flatpak-builder [source] (bionic-proposed) [0.10.9-1ubuntu1]
<apw> ahayzen, ^
<ahayzen> apw, awesome, thanks !
<mfo> xnox, hi. i'm looking for sponsorship for a systemd patch for xenial (LP#1795658), and been routed your way :-)  is this something you can help with, please?
<mfo> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1795658
<ubot5> Ubuntu bug 1795658 in systemd (Ubuntu) "xenial systemd reports 'inactive' instead of 'failed' for service units that repeatedly failed to restart / failed permanently" [Undecided,In progress]
<xnox> mfo, yes. looks good to me.
<xnox> mfo, the debdiff looks very good. I will intergrate into my git repo and upload it. please watch the bug updates as to when it hits proposed for testing.
<mfo> xnox, cool. sure, i'll keep an eye on it. thank you.
<handsome_feng> Hi, could someone help to upload the UbuntuKylin packages which have been approved, Thanks a million!! LP: #1792261 LP: #1791416
<ubot5> Launchpad bug 1792261 in Ubuntu Kylin "[FFe] ukui-greeter" [Medium,Triaged] https://launchpad.net/bugs/1792261
<ubot5> Launchpad bug 1791416 in ubuntukylin-wallpapers (Ubuntu) "Please upgrade ubuntukylin-wallpapers to 18.10.1" [Medium,Triaged] https://launchpad.net/bugs/1791416
-queuebot:#ubuntu-release- Unapproved: s390-tools (cosmic-proposed/main) [2.6.0-0ubuntu5 => 2.6.0-0ubuntu6] (core)
<jbicha> handsome_feng: why did you stop building ukui-screensaver for other architectures? it's stuck in -proposed because of this
<jbicha> https://people.canonical.com/~ubuntu-archive/proposed-migration/cosmic/update_excuses.html#ukui-screensaver
<handsome_feng> jbicha: I uploaded a new version which fix the problem.
<handsome_feng> The new version is in the upload queue.
<LocutusOfBorg> handsome_feng, please give me (also privately is fine) a list of "package-name or dsc link" not a bug with a link to a ppa with 10 packages, unless you want all of them sponsored
<jbicha> handsome_feng: oh I see, thank you :)
<handsome_feng> LocutusOfBorg: https://launchpad.net/~ubuntukylin-members/+archive/ubuntu/1810update and https://launchpad.net/~ubuntukylin-members/+archive/ubuntu/1810new
<handsome_feng> LocutusOfBorg: Thank you so much!!!!!!
<LocutusOfBorg> as said, all of them?
<LocutusOfBorg> 10 packages?
<handsome_feng> Yes, 4 new package and 6 new version package
<LocutusOfBorg> ack.
<teward> bugfix only microrelease bumps are still OK under freeze, right?
<teward> under FeatureFreeze*  (we're past Beta Freeze IIRC)
<LocutusOfBorg> does copy-package work from ppa to archive?
<LocutusOfBorg> ./copy-package --from=ppa:ubuntukylin-members/ubuntu/1810new --from-suite=cosmic --to=ubuntu --to-suite=cosmic ukui-greeter
<LocutusOfBorg> I did this, but no email yet
<cjwatson> needs to be --to-suite=cosmic-proposed
-queuebot:#ubuntu-release- New sync: ukui-biometric-manager (cosmic-proposed/primary) [1.0.0-1ubuntu1]
-queuebot:#ubuntu-release- New sync: ukui-greeter (cosmic-proposed/primary) [1.1.6-0ubuntu1]
<cjwatson> copy-package is lower-level and assumes you know what you're doing, so it doesn't have the suite redirect
<LocutusOfBorg> thanks, I just discovered it :)
-queuebot:#ubuntu-release- New sync: ukui-biometric-auth (cosmic-proposed/primary) [1.0.2-1ubuntu1]
<LocutusOfBorg> I probably remembered some "mapping cosmic to cosmic proposed" stuff
<LocutusOfBorg> and I was too lazy to change :)
<handsome_feng> Thanks, cjwatson, LocutusOfBorg. \o/
-queuebot:#ubuntu-release- New sync: biometric-authentication (cosmic-proposed/primary) [0.9.57-0ubuntu1]
<wxl> cjwatson: yes it does work now. not sure why it took so long to come down the pike.
<cjwatson> that's a relief, anyway
-queuebot:#ubuntu-release- Unapproved: ubuntukylin-wallpapers (cosmic-proposed/universe) [18.04.0 => 18.10.1] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: peony-extensions (cosmic-proposed/universe) [1.1.1-0ubuntu2 => 1.1.2-0ubuntu2] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntukylin-theme (cosmic-proposed/universe) [1.7.6 => 1.7.9.2] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-kylin-software-center (cosmic-proposed/universe) [1.3.14 => 1.5.2] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: indicator-china-weather (cosmic-proposed/universe) [2.2.8-0ubuntu1 => 3.0.0-0ubuntu1] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: kylin-display-switch (cosmic-proposed/universe) [1.0.1-0ubuntu1 => 1.0.3-0ubuntu1] (ubuntukylin) (sync)
 * didrocks doesn't understand why his 2 dput failed to publish in unapproved without notification again
-queuebot:#ubuntu-release- Unapproved: desktop-file-utils (cosmic-proposed/main) [0.23-3ubuntu1 => 0.23-3ubuntu2] (desktop-core)
<didrocks> waiting for 40 minutes and another upload seems to have worked ^
-queuebot:#ubuntu-release- Unapproved: indicator-china-weather (cosmic-proposed/universe) [2.2.8-0ubuntu1 => 3.0.0-0ubuntu1] (ubuntukylin) (sync)
<cjwatson> 2018-10-02 15:04:52 INFO        GPG verification of /srv/launchpad.net/ubuntu-queue/incoming/upload-ftp-20181002-150352-002036/ubuntu/desktop-file-utils_0.23-3ubuntu2_source.changes failed: Verification failed 3 times: ["(7, 9, u'No publi
<cjwatson> c key')", "(7, 9, u'No public key')", "(7, 9, u'No public key')"]
<cjwatson> so either unsigned before, or there was a keyserver glitch
<cjwatson> the latter wouldn't be hugely surprising
<didrocks> cjwatson: I didn't regenerate the source tarball. Uploaded it 3 times (and so, 2 times with -f)
-queuebot:#ubuntu-release- Unapproved: freeipa (cosmic-proposed/universe) [4.7.0-1ubuntu1 => 4.7.0-1ubuntu2] (no packageset)
<didrocks> s/tarball/package/
-queuebot:#ubuntu-release- Unapproved: accepted freeipa [source] (cosmic-proposed) [4.7.0-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: kylin-display-switch (cosmic-proposed/universe) [1.0.1-0ubuntu1 => 1.0.3-0ubuntu1] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-kylin-software-center (cosmic-proposed/universe) [1.3.14 => 1.5.2] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: flatpak-builder (bionic-proposed/universe) [0.10.9-1 => 0.10.9-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ubuntukylin-theme (cosmic-proposed/universe) [1.7.6 => 1.7.9.2] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: peony-extensions (cosmic-proposed/universe) [1.1.1-0ubuntu2 => 1.1.2-0ubuntu2] (ubuntukylin) (sync)
<cjwatson> yeah, unfortunately the keyserver isn't completely made of reliability
-queuebot:#ubuntu-release- Unapproved: ubuntukylin-wallpapers (cosmic-proposed/universe) [18.04.0 => 18.10.1] (ubuntukylin) (sync)
<didrocks> no worry, I was just wondering if that was only me or others as well, it's not the first time I "fight" to dput something
<LocutusOfBorg> oh damn, I did upload them twice, because they ended in unapproved instead of new...
<LocutusOfBorg> so they are duplicated
<didrocks> LocutusOfBorg: do you have the list? Happy to purge
<cjwatson> didrocks: Just you, today
<cjwatson> There's some caching of keys so once you get something through it should be happier for some time
<xnox> please accept https://launchpad.net/ubuntu/cosmic/+queue?queue_state=0&queue_text=xmltooling other arches were already accepted
<xnox> vorlon, ^
<didrocks> cjwatson: ok, at least not related to me/my key, which is already something :)
<didrocks> thx for looking!
<cjwatson> np
-queuebot:#ubuntu-release- Unapproved: keystone (xenial-proposed/main) [2:9.3.0-0ubuntu3.2 => 2:12.0.1-0ubuntu1~cloud0] (openstack, ubuntu-server)
<ahayzen> Hey, FYI for any SRU reviews, the latest flatpak-builder in the bionic queue should fix flatpak autopkgtest failures in bionic-proposed. So it'd be awesome if that could be reviewed. Thanks!
<handsome_feng> didrocks: I think the duplicated packages is ubuntukylin-wallpapers, ubuntukylin-theme, ubuntu-kylin-software-center, peony-extensions, kylin-display-switch, indicator-china-weather.
-queuebot:#ubuntu-release- Unapproved: nginx (cosmic-proposed/main) [1.15.4-0ubuntu1 => 1.15.5-0ubuntu1] (ubuntu-server)
<teward> can someone approve nginx/cosmic-proposed 1.15.5?  It's an upstream provided bugfix-only microrelease which addresses an SSL-related segfault that 1.15.4 introduced.
-queuebot:#ubuntu-release- Unapproved: rejected indicator-china-weather [sync] (cosmic-proposed) [3.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected peony-extensions [sync] (cosmic-proposed) [1.1.2-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: rejected ubuntukylin-theme [sync] (cosmic-proposed) [1.7.9.2]
-queuebot:#ubuntu-release- Unapproved: rejected kylin-display-switch [sync] (cosmic-proposed) [1.0.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected ubuntukylin-wallpapers [sync] (cosmic-proposed) [18.10.1]
<teward> it has no feature changes or anything, but since it's an SSL-related functionality bugfix it is a bit important to get included.
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-kylin-software-center [sync] (cosmic-proposed) [1.5.2]
<didrocks> handsome_feng / LocutusOfBorg: duplicated uploads purged ^
<Laney> teward: it'll be reviewed, no need to insta-ping :P
<handsome_feng> didrocks: Thanks! ^^
<teward> Laney: :P  i'm running on tunnel-vision mode for different tasks :P
<teward> so my apologies :)
<teward> I also wa
<teward> oops ignore that last message :|
<didrocks> yw
<LocutusOfBorg> didrocks, <3
<Laney> I also wa[nted to buy you an ice cream]
<Laney> how very kind of you
<vorlon> xnox: done
-queuebot:#ubuntu-release- New: accepted xmltooling [amd64] (cosmic-proposed) [3.0.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: glance (cosmic-proposed/main) [2:17.0.0-0ubuntu3 => 2:17.0.0-0ubuntu4] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: redshift (cosmic-proposed/universe) [1.11-2ubuntu1 => 1.12-1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: redshift (cosmic-proposed/universe) [1.11-2ubuntu1 => 1.12-2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted openshot-qt [sync] (cosmic-proposed) [2.4.2+dfsg1-1]
-queuebot:#ubuntu-release- Unapproved: rejected calibre [sync] (cosmic-proposed) [3.32.0+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: uwsgi (cosmic-proposed/universe) [2.0.17.1-7 => 2.0.17.1-8] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted uwsgi [sync] (cosmic-proposed) [2.0.17.1-8]
-queuebot:#ubuntu-release- Unapproved: accepted budgie-desktop [sync] (cosmic-proposed) [10.4+git20180830.02.f2dbc215fdb-1]
-queuebot:#ubuntu-release- Unapproved: accepted simple-scan [sync] (cosmic-proposed) [3.30.1.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted ukui-screensaver [source] (cosmic-proposed) [2.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted lubuntu-default-settings [source] (cosmic-proposed) [1.14]
-queuebot:#ubuntu-release- Unapproved: accepted lubuntu-meta [source] (cosmic-proposed) [1.12]
-queuebot:#ubuntu-release- Unapproved: accepted ukui-desktop-environment [source] (cosmic-proposed) [1.2.0]
-queuebot:#ubuntu-release- Unapproved: accepted lubuntu-default-settings [source] (cosmic-proposed) [1.15]
-queuebot:#ubuntu-release- Unapproved: accepted mailman [sync] (cosmic-proposed) [1:2.1.29-1]
<tsimonq2> <3 finally some queue processing
-queuebot:#ubuntu-release- Unapproved: accepted compiz [sync] (cosmic-proposed) [1:0.9.13.1+18.10.20180930-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted vino [source] (cosmic-proposed) [3.22.0-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted shared-mime-info [sync] (cosmic-proposed) [1.10-1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-report [source] (cosmic-proposed) [1.4.0]
-queuebot:#ubuntu-release- Unapproved: accepted xfce4-sensors-plugin [sync] (cosmic-proposed) [1.3.0-2]
-queuebot:#ubuntu-release- New binary: opensaml2 [ppc64el] (cosmic-proposed/universe) [3.0.0-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: opensaml2 [s390x] (cosmic-proposed/universe) [3.0.0-0ubuntu2] (no packageset)
<mdeslaur> can someone please mark the udisks2 s390x as always failing?
<vorlon> mdeslaur: done
<mdeslaur> thanks vorlon
-queuebot:#ubuntu-release- New: accepted opensaml2 [ppc64el] (cosmic-proposed) [3.0.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted opensaml2 [s390x] (cosmic-proposed) [3.0.0-0ubuntu2]
-queuebot:#ubuntu-release- New binary: opensaml2 [arm64] (cosmic-proposed/universe) [3.0.0-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: opensaml2 [armhf] (cosmic-proposed/universe) [3.0.0-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: freeipa (cosmic-proposed/universe) [4.7.0-1ubuntu2 => 4.7.0-1ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted freeipa [source] (cosmic-proposed) [4.7.0-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: curtin (cosmic-proposed/main) [18.1-52-g5f0082d1-0ubuntu1 => 18.1-55-g0a27f283-0ubuntu1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted opensaml2 [arm64] (cosmic-proposed) [3.0.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted opensaml2 [armhf] (cosmic-proposed) [3.0.0-0ubuntu2]
-queuebot:#ubuntu-release- New binary: shibboleth-sp2 [s390x] (cosmic-proposed/universe) [3.0.2+dfsg0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: shibboleth-sp2 [ppc64el] (cosmic-proposed/universe) [3.0.2+dfsg0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (bionic-proposed) [2.35.2+18.04]
-queuebot:#ubuntu-release- New binary: shibboleth-sp2 [i386] (cosmic-proposed/universe) [3.0.2+dfsg0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: shibboleth-sp2 [amd64] (cosmic-proposed/universe) [3.0.2+dfsg0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted devscripts [source] (cosmic-proposed) [2.18.4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.35.2]
-queuebot:#ubuntu-release- Unapproved: shibboleth-resolver (cosmic-proposed/universe) [1.0.0-1build4 => 3.0.0-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted shibboleth-resolver [sync] (cosmic-proposed) [3.0.0-0ubuntu1]
<vorlon> jbicha: is git 2.19.0 meant to be an FFe?
<jbicha> um I didn't file one
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.35.2~14.04]
<jbicha> we would have gotten 2.18 from autosync if it wasn't for the pcre2 situation
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-drivers-common [source] (cosmic-proposed) [1:0.5.5]
<vorlon> but we didn't, and the delta now is quite large and doesn't get the obviously-correct wave-through in the queue from me
<jbicha> ok, I understand. I'm not really interested enough in the update to do the FFe paperwork for git.
<jbicha> anyone in Foundations want to do that?
<sil2100> vorlon: uploaded ubuntu-image to cosmic - the cosmic autopkgtests on github were good so (only snap.sh failed which is expected and not ran for the archive tests)
<sil2100> ...so it should be good to go
-queuebot:#ubuntu-release- Unapproved: ubuntu-image (cosmic-proposed/main) [1.4+18.10ubuntu3 => 1.4+18.10ubuntu4] (desktop-core)
<sil2100> I'll merge it into ubuntu-image trunk once I see if the other series are green, but basically they should
<sil2100> (and shouldn't matter for cosmic anyway)
-queuebot:#ubuntu-release- Unapproved: rejected redshift [sync] (cosmic-proposed) [1.12-1]
-queuebot:#ubuntu-release- Unapproved: rejected enigmail [sync] (cosmic-proposed) [2:2.0.8-2]
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (cosmic-proposed) [1:18.10.9]
-queuebot:#ubuntu-release- New binary: shibboleth-sp2 [arm64] (cosmic-proposed/universe) [3.0.2+dfsg0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: shibboleth-sp2 [armhf] (cosmic-proposed/universe) [3.0.2+dfsg0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted shibboleth-sp2 [amd64] (cosmic-proposed) [3.0.2+dfsg0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted shibboleth-sp2 [armhf] (cosmic-proposed) [3.0.2+dfsg0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted shibboleth-sp2 [ppc64el] (cosmic-proposed) [3.0.2+dfsg0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted shibboleth-sp2 [arm64] (cosmic-proposed) [3.0.2+dfsg0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted shibboleth-sp2 [s390x] (cosmic-proposed) [3.0.2+dfsg0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted shibboleth-sp2 [i386] (cosmic-proposed) [3.0.2+dfsg0-0ubuntu1]
<sil2100> Ok, I'll be going EOD now, but please someone review/accept ubuntu-image in cosmic to fix the voluptuous ADT regressions
<sil2100> infinity, vorlon: ^
<sil2100> o/
-queuebot:#ubuntu-release- Unapproved: accepted breeze [source] (cosmic-proposed) [4:5.13.5-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: xorg-server (cosmic-proposed/main) [2:1.20.1-3ubuntu1 => 2:1.20.1-3ubuntu2] (desktop-core, xorg)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (cosmic-proposed) [1.4+18.10ubuntu4]
-queuebot:#ubuntu-release- New binary: shibboleth-resolver [s390x] (cosmic-proposed/universe) [3.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: shibboleth-resolver [ppc64el] (cosmic-proposed/universe) [3.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: shibboleth-resolver [i386] (cosmic-proposed/universe) [3.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: shibboleth-resolver [amd64] (cosmic-proposed/universe) [3.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: shibboleth-resolver [arm64] (cosmic-proposed/universe) [3.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: shibboleth-resolver [armhf] (cosmic-proposed/universe) [3.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (bionic-proposed/main) [1.1ubuntu1.18.04.5 => 1.1ubuntu1.18.04.6] (desktop-core, ubuntu-server)
<xnox> vorlon, https://launchpad.net/ubuntu/cosmic/+queue?queue_state=0&queue_text=shibboleth-resolver
-queuebot:#ubuntu-release- Unapproved: accepted nginx [source] (cosmic-proposed) [1.15.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted xorg-server [source] (cosmic-proposed) [2:1.20.1-3ubuntu2]
<teward> to whomever accepted nginx, thank you kindly :)
<infinity> teward: T'was I, and you can read my comment on the bug. :P
<teward> once Launchpad stops hitting timeouts, yes. :)
<teward> it's timing out on my phone's crappy connection right now
-queuebot:#ubuntu-release- Unapproved: accepted desktop-file-utils [source] (cosmic-proposed) [0.23-3ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice-l10n [source] (cosmic-proposed) [1:6.1.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted glance [source] (cosmic-proposed) [2:17.0.0-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (cosmic-proposed) [1:6.1.2-0ubuntu1]
<teward> infinity: yep, that's what I thought from the history about freezes.  The bug number was for bug tracking purposes
<teward> because of the recent crap from Sova about a security fix not being 'documented' in the original bug for a Xenial upload
<teward> which we can all point fingers at sbeattie for :P
<teward> force of habit to document things I guess?  :|
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (cosmic-proposed) [3:14.0.0-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted xdg-utils [source] (cosmic-proposed) [1.1.3-1ubuntu2]
<teward> infinity: next time i'll just upload directly, (it's why I didn't sub ubuntu-release to the bug though, since it wasn't FFe-needed)
<infinity> teward: Ahh, I didn't even notice subs, I just read the body of the bug, which smelled like a freeze exception justification bug. :P
-queuebot:#ubuntu-release- Unapproved: rejected curtin [source] (cosmic-proposed) [18.1-55-g0a27f283-0ubuntu1]
<teward> infinity: indeed, it does, but it's a force of habit to have certain bits in there
<teward> infinity: if i'm proposing an update, FFe or not, I try and justify it so there's logic to the changes.
<teward> *some* cases it's obvious
<teward> but yeah, I didn't sub ubuntu-releases intentionally
<teward> but I still try and put a bug for every important change
-queuebot:#ubuntu-release- New: accepted shibboleth-resolver [s390x] (cosmic-proposed) [3.0.0-0ubuntu1]
<teward> also, in case anyone was testing 1.15.4 and bug-files about the segv, i dupe report it to the now-existing bug so i don't have to do all the work again :p
-queuebot:#ubuntu-release- New: accepted shibboleth-resolver [amd64] (cosmic-proposed) [3.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted shibboleth-resolver [armhf] (cosmic-proposed) [3.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted shibboleth-resolver [ppc64el] (cosmic-proposed) [3.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted shibboleth-resolver [arm64] (cosmic-proposed) [3.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted shibboleth-resolver [i386] (cosmic-proposed) [3.0.0-0ubuntu1]
<blackboxsw> infinity: thank you so much on that curtin review. wow. oops
<infinity> blackboxsw: Thank you so much for actually reading reject messages instead of storming in here asking why. ;)
<infinity> Please teach everyone else.
<blackboxsw> hah! yeah definitely. everyone on ubuntu-server  first defaults to look for from:ubuntu to get a rejection email :)
-queuebot:#ubuntu-release- Unapproved: open-iscsi (bionic-proposed/main) [2.0.874-5ubuntu2.2 => 2.0.874-5ubuntu2.3] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: open-iscsi (xenial-proposed/main) [2.0.873+git0.3b4b4500-14ubuntu3.5 => 2.0.873+git0.3b4b4500-14ubuntu3.6] (ubuntu-desktop, ubuntu-server)
<ddstreet> bdmurray can you approve those open-iscsi uploads if you're around ^
-queuebot:#ubuntu-release- Unapproved: moonshot-gss-eap (cosmic-proposed/universe) [1.0.1-3 => 1.0.1-3ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted moonshot-gss-eap [sync] (cosmic-proposed) [1.0.1-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-initial-setup [source] (cosmic-proposed) [3.30.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: session-shortcuts (cosmic-proposed/universe) [1.3 => 1.4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted session-shortcuts [source] (cosmic-proposed) [1.4]
-queuebot:#ubuntu-release- Unapproved: accepted open-iscsi [source] (bionic-proposed) [2.0.874-5ubuntu2.3]
-queuebot:#ubuntu-release- Unapproved: accepted open-iscsi [source] (xenial-proposed) [2.0.873+git0.3b4b4500-14ubuntu3.6]
-queuebot:#ubuntu-release- Unapproved: accepted s390-tools [source] (cosmic-proposed) [2.6.0-0ubuntu6]
-queuebot:#ubuntu-release- Unapproved: accepted peruse [sync] (cosmic-proposed) [1.2+dfsg+20181001-1]
<ahasenack> hi, could someone from the release team please review this to unblock ocfs2-tools stuck in migration? https://code.launchpad.net/~paelzer/britney/hints-ubuntu-ocfs2-cosmic-bump/+merge/355482
-queuebot:#ubuntu-release- Unapproved: accepted libguestfs [source] (bionic-proposed) [1:1.36.13-1ubuntu3.2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-mines [source] (bionic-proposed) [1:3.28.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted squid3 [source] (bionic-proposed) [3.5.27-1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted heat [source] (bionic-proposed) [1:10.0.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (bionic-proposed) [2:17.0.6-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected neutron [source] (bionic-proposed) [2:12.0.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: curtin (cosmic-proposed/main) [18.1-52-g5f0082d1-0ubuntu1 => 18.1-56-g3aafe77d-0ubuntu1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: freeipa (cosmic-proposed/universe) [4.7.0-1ubuntu3 => 4.7.0-1ubuntu4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted freeipa [source] (cosmic-proposed) [4.7.0-1ubuntu4]
-queuebot:#ubuntu-release- Unapproved: enigmail (cosmic-proposed/universe) [2:2.0.8-1 => 2:2.0.8-4] (mozilla) (sync)
-queuebot:#ubuntu-release- Unapproved: python2.7 (cosmic-proposed/main) [2.7.15-4ubuntu3 => 2.7.15-4ubuntu4] (core)
<xnox> vorlon, infinity ^ should fix python2.7 autopkgtest with openssl1.1.1. Basically testsuite backports in 2.7 branch are incomplete w.r.t. 3.6/3.7/master or broken for python2 code in tls1.3 codepaths.
<xnox> bugs.python.org issues filed; github pr's proposed; no responses yet, only a few maintainers "subscribed" to updates.
<xnox> matthias is probably out on public holiday, but these things should be fairly self explanatory, and match 3.6 testsuite.
<xnox> with that in place openssl 1.1.1 should be able to migrate into release pocket
-queuebot:#ubuntu-release- Unapproved: dh-golang (bionic-proposed/main) [1.34 => 1.34.1] (core)
-queuebot:#ubuntu-release- New source: ukui-greeter (cosmic-proposed/primary) [1.1.6-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted keystone [source] (bionic-proposed) [2:13.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: skiboot (bionic-proposed/main) [5.10~rc4-1ubuntu1 => 5.10~rc4-1ubuntu1.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted xdg-utils [source] (bionic-proposed) [1.1.2-1ubuntu2.3]
-queuebot:#ubuntu-release- Unapproved: gradle (cosmic-proposed/universe) [3.4.1-7ubuntu1 => 4.4-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gradle [sync] (cosmic-proposed) [4.4-3]
-queuebot:#ubuntu-release- Unapproved: accepted python2.7 [source] (cosmic-proposed) [2.7.15-4ubuntu4]
-queuebot:#ubuntu-release- Unapproved: rejected gdm3 [source] (bionic-proposed) [3.28.3-0ubuntu18.04.2]
<wxl> do our live images automount swap by design for some reason? maybe a systemd thing?
-queuebot:#ubuntu-release- Unapproved: rejected keystone [source] (xenial-proposed) [2:12.0.1-0ubuntu1~cloud0]
<vorlon> wxl: it is by design; it's to allow the install to run on systems with lower physical RAM than it would otherwise
<wxl> thanks vorlon. btw love the new nick :)
<cjwatson> everything old is new again
#ubuntu-release 2018-10-03
-queuebot:#ubuntu-release- Unapproved: equinox-framework (cosmic-proposed/universe) [4.7.3-3 => 4.7.3-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted equinox-framework [sync] (cosmic-proposed) [4.7.3-4]
<infinity> cjwatson: PS: We miss Kamion.
<tsimonq2> Doeeeet.
-queuebot:#ubuntu-release- Unapproved: python-cryptography (cosmic-proposed/main) [2.3-1build1 => 2.3-1ubuntu1] (core)
<RAOF> There's nothing like a little bottom-up processing of the unaccepted queue to really make C++ development look enticing.
-queuebot:#ubuntu-release- Unapproved: curtin (bionic-proposed/main) [18.1-17-gae48e86f-0ubuntu1~18.04.1 => 18.1-56-g3aafe77d-0ubuntu1~18.04.1] (ubuntu-desktop, ubuntu-server)
<jbicha> RAOF: yes we could use small metrics for bug 1788256 but I'm not sure it would help our users to do that
<ubot5> bug 1788256 in fonts-noto-color-emoji (Ubuntu Bionic) "Update fonts-noto-color-emoji to 20180810 release for Unicode 11" [Low,Confirmed] https://launchpad.net/bugs/1788256
<RAOF> jbicha: I presume you mean large metrics?
<jbicha> yes
<jbicha> I don't think anyone will notice either way though
-queuebot:#ubuntu-release- Unapproved: gradle (cosmic-proposed/universe) [4.4-3 => 4.4-3ubuntu1] (no packageset)
<RAOF> Well, not changing to small metrics does have the appealing property of not changing current behaviour. :)
-queuebot:#ubuntu-release- Unapproved: accepted gradle [source] (cosmic-proposed) [4.4-3ubuntu1]
<jbicha> and the unappealing part of waiting an hour for it to build :)
<RAOF> Your CPU will be bored without some work to do!
-queuebot:#ubuntu-release- Unapproved: curtin (xenial-proposed/main) [18.1-17-gae48e86f-0ubuntu1~16.04.1 => 18.1-56-g3aafe77d-0ubuntu1~16.04.1] (ubuntu-server)
<RAOF> stgraber: LXD 3.0.2 is a spicy point release!
<stgraber> RAOF: yeah, the first few point releases tend to be full of fixes :)
<jbicha> RAOF: are you a real AA yet?
<RAOF> stgraber: It looks like you could do with a little bit more discipline around translatable strings in point releases; there's at least one cosmetic change to a string that'll break existing translations. :P
<RAOF> jbicha: Nope!
<jbicha> too bad, the brotli and woff2 xenial SRUs are a bit more fun
<stgraber> RAOF: yeah, the main issue there is that weblate doesn't make it easy to track translations across branches, though I've heard there's a trick we may use to fix that
<jbicha> I don't even know how I would tell the difference between small and large metrics
<stgraber> RAOF: at which point we'd be able to export new translations for the point releases
<RAOF> That would be nice, but you could also not have changed âThe container is currently running, stop it first or pass --force.â to âThe container is currently running, stop it first or pass --forceâ :)
<stgraber> oh yeah, seems like we could have avoided that one, though skipping those kind of trivial changes later bites you when you try to cherry-pick a more substantial change...
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (bionic-proposed) [3.0.2-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: fonts-noto-color-emoji (bionic-proposed/main) [0~20180424-0ubuntu1 => 0~20180810-0ubuntu1] (ubuntu-desktop)
<jbicha> RAOF: ^
<wxl> why does the grub boot screen (efi) not have the same options as isolinux (non-efi)? how can i correct this? it would be nice if they were in sync, or drew from the same datasource
-queuebot:#ubuntu-release- Unapproved: rejected fonts-noto-color-emoji [source] (bionic-proposed) [0~20180810-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-cryptography [source] (cosmic-proposed) [2.3-1ubuntu1]
<RAOF> jbicha: While my make syntax is obviously, and always, perfect, does your build log indicate that -S is not being passed through âº?
-queuebot:#ubuntu-release- Unapproved: openjdk-lts (cosmic-proposed/main) [10.0.2+13-1ubuntu1 => 11~28-3ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-lts [source] (cosmic-proposed) [11~28-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted enigmail [sync] (cosmic-proposed) [2:2.0.8-3]
-queuebot:#ubuntu-release- Unapproved: accepted python-eventlet [sync] (cosmic-proposed) [0.20.0-5]
-queuebot:#ubuntu-release- Unapproved: accepted spamassassin [sync] (cosmic-proposed) [3.4.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted enigmail [sync] (cosmic-proposed) [2:2.0.8-4]
-queuebot:#ubuntu-release- Unapproved: accepted redshift [sync] (cosmic-proposed) [1.12-2]
<jbicha> dh_auto_build -- PNGQUANT=/usr/bin/pngquant SMALL_METRICS=
<jbicha>  make -j4 PNGQUANT=/usr/bin/pngquant SMALL_METRICS=
<jbicha> the build logs don't mention metrics or -S besides that (you can look at the cosmic build)
<RAOF> Hm, that's odd.
 * RAOF checks the cosmic build
<RAOF> Boo, bad Makefile! No bisucit!
<RAOF> jbicha: What do you think would be the response to an upstream bug asking for a verbose makefile? (ie: an option to not silence all the commands with @)
-queuebot:#ubuntu-release- Unapproved: accepted fonts-noto-color-emoji [source] (bionic-proposed) [0~20180810-0ubuntu1]
<vorlon> LocutusOfBorg: do not sync binary packages from virtualized ppas; that's an automatic reject.
-queuebot:#ubuntu-release- Unapproved: rejected ubuntukylin-wallpapers [sync] (cosmic-proposed) [18.10.1]
-queuebot:#ubuntu-release- Unapproved: rejected ubuntukylin-theme [sync] (cosmic-proposed) [1.7.9.2]
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-kylin-software-center [sync] (cosmic-proposed) [1.5.2]
-queuebot:#ubuntu-release- Unapproved: rejected peony-extensions [sync] (cosmic-proposed) [1.1.2-0ubuntu2]
<tjaalton> xnox: thanks for updating freeipa, but there's no 389-ds-base for 32bit archs anymore which is why the server wasn't supposed to be built on 'any' anymore. just didn't think of the tests at the time, and haven't figured out how to limit those to only 64bit archs
<tjaalton> xnox: sigh, please don't touch these packages without consulting me... upstream dropped support for 32bit archs from 389
<tjaalton> xnox: which was clearly mentioned on the changelog for 1.4.0.13-1
-queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (cosmic-proposed) [18.1-56-g3aafe77d-0ubuntu1]
<infinity> tjaalton: What does "upstream dropped support" mean, really?
<infinity> tjaalton: I note that Fedora still builds 389* for armhf and i386.
<infinity> tjaalton: Err, for armhf anyway.  Maybe they don't build i386 at all in rawhide..
<tjaalton> infinity: if they have bugs, they close them as invalid
<infinity> tjaalton: And, yet, they build it for armhf themselves?
<tjaalton> maybe
<infinity> Not maybe, I'm looking right at it. :P
<tjaalton> I'm sure rhel8 won't
<infinity> rhel8 won't build *anything* for armhf and i386, that doesn't mean we should drop support in Ubuntu for any package where RedHat/Fedora are upstream.
<infinity> Downstreams take on that burden when we choose to have ports.
<infinity> It appears to build and pass testsuites, so artificially limiting arches because upstream won't debug for us isn't helpful.
<infinity> Most of our upstreams also don't have any interest in s390x or ppc64el...
<infinity> Even though RH does.
<tjaalton> I don't want to support those, is that enough?
<infinity> tjaalton: I don't want to support them either, but I don't get to make that call.
<infinity> tjaalton: I mean, if it was literally unsupportable, that would be something, but it builds and tests okay, so... The complaint is about some future issue you've not actually had?
<tjaalton> https://pagure.io/389-ds-base/issue/49365
<infinity> tjaalton: (a) that talks about performance (meh, so what), and (b) there seems to be no resolution to that ticket?  The conversation just peters out.
<infinity> tjaalton: (c) 32-bit fixes are being made, so support clearly isn't gone...
<tjaalton> doesn't necessarily mean that'll continue after buster is frozen
<infinity> tjaalton: Nor would it have to, because... Frozen?  But for now, the Fedora folks seem committed to keeping it working on armhf, and it looks like i386 will benefit from that for free.
<infinity> Since there doesn't seem to be much in the way of non-portable platform-specific code.
<tjaalton> https://fedoraproject.org/wiki/Changes/389-ds-base-remove-686
<tjaalton> ok, seems like they don't thin arm is affected
<tjaalton> think
<infinity> tjaalton: The implication there is that literally anything using gcc atomics on i686 is broken.
<infinity> Which may be true, but singling out a specific package to remove seems like just using it as an excuse. :P
 * infinity shrugs.
<tjaalton> fine..
<infinity> Also, from the Fedora report: "I know of no know issues with the __sync_* or __atomic_* primitives on i686"
<infinity> (and more detail)
<infinity> The broken atomics issue is literally referring to <= i486.
<infinity> We build for i686.
<infinity> Hahaha, and then Carlos tears it apart to point out that FreeIPA is using atomics incorrectly on *all* arches.
<infinity> This bug is a goldmine.
<tjaalton> 389-ds-base, but yes
<infinity> tjaalton: Err, yes, that.
<infinity> tjaalton: The upstream admission that they're "relying on luck to not crash" is also encouraging.
<infinity> Glad my infra isn't based on this?
-queuebot:#ubuntu-release- Unapproved: openvswitch (bionic-proposed/main) [2.9.0-0ubuntu1 => 2.9.2-0ubuntu0.18.04.1] (ubuntu-server)
<RAOF> atomics: if you're not using Acquire/Release you're probably Doing It Wrong.
-queuebot:#ubuntu-release- Unapproved: network-manager (cosmic-proposed/main) [1.12.2-0ubuntu5 => 1.12.4-1ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: qtdeclarative-opensource-src (cosmic-proposed/universe) [5.11.1-4 => 5.11.1-6] (kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: gnome-control-center (cosmic-proposed/main) [1:3.30.0-0ubuntu1 => 1:3.30.1-1ubuntu1] (ubuntu-desktop)
<xnox> infinity, tjaalton, i did make a bit of a mess out of those uploads - but i did troll upstream repos, and I did see that they first removed all 32bit, and then re-introduced some of them, and our abis are supported. Also, if I was debian maintainer i would compile the package for all release arches there too... My primary concern was to see if openssl1.1.1 with python changes regresses freeipa -> and from adt results it did look like so, because
<xnox> of incomplete dropping of 32bit builds to date. As removal of binaries from release suite was not done yet.
<xnox> tjaalton, to me it was easier to reintroduce dropped arches and get freeipa to migrate; for 18.10; and worry about other things later.
<tjaalton> xnox: I'm the sole maintainer on debian
<tjaalton> freeipa server just doesn't work there, because debian
<xnox> tjaalton, sure. i meant in general. I think i did what is right for ubuntu, at least for the next 3 weeks ;-)
<xnox> tjaalton, and like until after openssl1.1.1 migrates =)
<xnox> tjaalton, i often compile and ship in debian things on arches that upstream do not support. due to well debian being a universal OS.
<tjaalton> well the autopkgtest failure is probably some race due to dogtag, and hopefully fixed in 4.7.1~
<xnox> tjaalton, but things I maintain have a lot less depedencies usually, and are much lower in the stack.
<xnox> tjaalton, yeah, i ran them locally, and it did complete. However, i did fully configure the deps and answer debconf questions about like kerberos or some such.
<xnox> tjaalton, i wonder if the installation needs interactively installed and configured debian packages, and cannot deal with debconf-unconfigured things.... but that's just a guess, did not look at the code.
<tjaalton> it used to work, for real
<tjaalton> libkrb5-3 asking questions has been there for ages, and the failure is quite late in the setup phase
<tjaalton> and it's actually installed interactively, just installing the package does nothing
<xnox> ack, horum.
<tjaalton> anyway, I'll revert back to building on arch:any on debian..
-queuebot:#ubuntu-release- Unapproved: pokerth (cosmic-proposed/universe) [1.1.1-10 => 1.1.1-11] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pokerth [sync] (cosmic-proposed) [1.1.1-11]
-queuebot:#ubuntu-release- Unapproved: ibus-table-chinese (cosmic-proposed/main) [1.8.2-2 => 1.8.2-3] (input-methods, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: gjs (cosmic-proposed/main) [1.53.3-1 => 1.54.0-1] (desktop-extra, mozilla, ubuntu-desktop) (sync)
<Laney> We'll need that gjs to switch to mozjs60 (the current supported version) in cosmic. It's going to fail to build or BD-uninst on s390x and then we'll have to remove the stack there.
<Laney> (that's just fyi)
-queuebot:#ubuntu-release- Unapproved: libguestfs (cosmic-proposed/universe) [1:1.38.4-1ubuntu1 => 1:1.38.4-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted libguestfs [source] (cosmic-proposed) [1:1.38.4-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: skimage (cosmic-proposed/universe) [0.14.0-0ubuntu3 => 0.14.0-0ubuntu4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted skimage [source] (cosmic-proposed) [0.14.0-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: gnome-calculator (cosmic-proposed/main) [1:3.30.0-1ubuntu1 => 1:3.30.1-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gpaste (cosmic-proposed/universe) [3.28.2-1 => 3.28.2-1ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gpaste [sync] (cosmic-proposed) [3.28.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: neutron-fwaas-dashboard (cosmic-proposed/universe) [1.3.0-1ubuntu1 => 1.5.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted neutron-fwaas-dashboard [source] (cosmic-proposed) [1.5.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: nvidia-prime (cosmic-proposed/main) [0.8.9 => 0.8.10] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: cloud-init (cosmic-proposed/main) [18.3-46-gbb60f61b-0ubuntu1 => 18.4-0ubuntu1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: mailman-hyperkitty (cosmic-proposed/universe) [1.1.0-8 => 1.1.0-8ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted mailman-hyperkitty [source] (cosmic-proposed) [1.1.0-8ubuntu1]
-queuebot:#ubuntu-release- Unapproved: git (cosmic-proposed/main) [1:2.17.1-1ubuntu2 => 1:2.19.0-1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: kylin-display-switch (cosmic-proposed/universe) [1.0.1-0ubuntu1 => 1.0.3-0ubuntu1] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: indicator-china-weather (cosmic-proposed/universe) [2.2.8-0ubuntu1 => 3.0.0-0ubuntu1] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: epoptes (cosmic-proposed/universe) [0.5.10-2 => 1.0.1-1] (edubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted epoptes [sync] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (xenial-proposed) [1:2.5+dfsg-5ubuntu10.32]
<xnox> apw, could you please process nbs http://people.canonical.com/~ubuntu-archive/nbs.html ? should unblock removal of curl3
-queuebot:#ubuntu-release- Unapproved: neutron (bionic-proposed/main) [2:12.0.3-0ubuntu1 => 2:12.0.4-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: grilo-plugins (cosmic-proposed/main) [0.3.7-1ubuntu1 => 0.3.8-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted samba [source] (xenial-proposed) [2:4.3.11+dfsg-0ubuntu0.16.04.17]
<apw> xnox, zapped
-queuebot:#ubuntu-release- Unapproved: liblouis (cosmic-proposed/main) [3.6.0-3 => 3.6.0-3ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: postfix (cosmic-proposed/main) [3.3.0-1ubuntu1 => 3.3.0-1ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: hplip (cosmic-proposed/main) [3.18.7+dfsg1-2 => 3.18.7+dfsg1-2ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: apache2 (cosmic-proposed/main) [2.4.34-1ubuntu1 => 2.4.34-1ubuntu2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: xfwm4 (cosmic-proposed/universe) [4.12.4-1ubuntu1 => 4.12.5-1ubuntu1] (xubuntu)
<handsome_feng> LocutusOfBorg: Hi, I saw the  ubuntukylin-wallpapers, ubuntukylin-theme, ubuntu-kylin-software-center, peony-extensions are rejected by vorlon with the reason "do not sync binary packages from virtualized ppas",Is it possible for you to upload them again? :)
-queuebot:#ubuntu-release- Unapproved: rejected kylin-display-switch [sync] (cosmic-proposed) [1.0.3-0ubuntu1]
<handsome_feng> emm, and I think the indicator-china-weather will be reject soon. :(
<vorlon> yes, done now
<vorlon> :)
-queuebot:#ubuntu-release- Unapproved: rejected indicator-china-weather [sync] (cosmic-proposed) [3.0.0-0ubuntu1]
<handsome_feng> T_T
<handsome_feng> vorlon: Will the packages(biometric-authentication, ukui-biometric-auth, ukui-biometric-manager) in new queue also be rejected?
-queuebot:#ubuntu-release- Unapproved: gtk+3.0 (cosmic-proposed/main) [3.24.1-1ubuntu1 => 3.24.1-1ubuntu2] (ubuntu-desktop)
<vorlon> handsome_feng: yes, same problem
<handsome_feng> vorlon: ok, got it
-queuebot:#ubuntu-release- New: rejected ukui-biometric-manager [sync] (cosmic-proposed) [1.0.0-1ubuntu1]
-queuebot:#ubuntu-release- New: rejected ukui-greeter [source] (cosmic-proposed) [1.1.6-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected ukui-greeter [sync] (cosmic-proposed) [1.1.6-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected ukui-biometric-auth [sync] (cosmic-proposed) [1.0.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: shotwell (cosmic-proposed/main) [0.30.0-0ubuntu1 => 0.30.1-0ubuntu1] (ubuntu-desktop)
<handsome_feng> vorlon:Is the ukui-greeter [source] the same problem?
<vorlon> handsome_feng: no, that was my reject matching too many entries in the queue
<vorlon> I'm reviewing the rejected source now
-queuebot:#ubuntu-release- New: rejected biometric-authentication [sync] (cosmic-proposed) [0.9.57-0ubuntu1]
<handsome_feng> vorlon: Thanks!
-queuebot:#ubuntu-release- Unapproved: linux-gcp (cosmic-proposed/main) [4.15.0-1021.22 => 4.18.0-1001.2] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-gcp (cosmic-proposed/main) [4.15.0.1021.23 => 4.18.0.1001.1] (kernel) (sync)
<vorlon> handsome_feng: ok, reviewing ukui-greeter, debian/copyright doesn't match the copyright statements in the source; ./bio-verify/bioauthenticationview.* and common/*.cpp are listed as GPL v3 or later and debian/copyright lists GPL v2 or later.  How to reconcile?
<handsome_feng> I will fix that soon and upload to the PPA
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [4.15.0-1022.23] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-37.40] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-37.40] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: linux-signed-gcp (cosmic-proposed/main) [4.15.0-1021.22 => 4.18.0-1001.2] (kernel) (sync)
<handsome_feng> vorlon: Done! And could you help upload this package? Thanks! :) It's in the PPA: https://launchpad.net/~ubuntukylin-members/+archive/ubuntu/1810new
-queuebot:#ubuntu-release- Packageset: Added linux-signed-gcp to kernel in bionic
-queuebot:#ubuntu-release- Packageset: Added linux-signed-gcp to kernel in cosmic
-queuebot:#ubuntu-release- Packageset: Added linux-signed-gcp to kernel in xenial
<vorlon> handsome_feng: your 1.1.6.1 release doesn't exist at https://github.com/ukui/ukui-greeter/releases ; is there risk that someone else at a later time will have a different 1.1.6.1 tarball with a different checksum than the one uploaded here?
<vorlon> handsome_feng: also, since the fix here was to change the license declarations in the upstream source, it's acceptable for you to just say "the copyright statements are wrong and we will fix them in the next release" and have us accept the package that was already uploaded
<handsome_feng> I will release it in github now
<vorlon> ok
<vorlon> meanwhile I've gone ahead and just accepted 1.1.6-0ubuntu1 from the rejected queue, given the above
<handsome_feng> vorlon: oh, got it, sorry, I thought I must fix it before upload.
-queuebot:#ubuntu-release- New binary: ukui-greeter [s390x] (cosmic-proposed/none) [1.1.6-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-greeter [ppc64el] (cosmic-proposed/none) [1.1.6-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-greeter [arm64] (cosmic-proposed/none) [1.1.6-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-greeter [armhf] (cosmic-proposed/universe) [1.1.6-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-greeter [amd64] (cosmic-proposed/universe) [1.1.6-0ubuntu1] (no packageset)
<handsome_feng> vorlon: Thanks! And I have release the 1.1.6.1 in github.
-queuebot:#ubuntu-release- New binary: ukui-greeter [i386] (cosmic-proposed/universe) [1.1.6-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ros-ros-comm (cosmic-proposed/universe) [1.14.2+ds1-10 => 1.14.2+ds1-10ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ros-ros-comm [source] (cosmic-proposed) [1.14.2+ds1-10ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtdeclarative-opensource-src [sync] (cosmic-proposed) [5.11.1-6]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-calculator [source] (cosmic-proposed) [1:3.30.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ibus-table-chinese [sync] (cosmic-proposed) [1.8.2-3]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (cosmic-proposed) [1:3.30.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-prime [source] (cosmic-proposed) [0.8.10]
-queuebot:#ubuntu-release- Unapproved: accepted gtk+3.0 [source] (cosmic-proposed) [3.24.1-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted grilo-plugins [source] (cosmic-proposed) [0.3.8-1ubuntu1]
<handsome_feng> Hi, Is it possible that someone help to upload ubuntukylin-wallpapers and ubuntukylin-theme? These two packages are very important for ubuntukylin 1810. PPA:https://launchpad.net/~ubuntukylin-members/+archive/ubuntu/1810update
-queuebot:#ubuntu-release- Unapproved: accepted liblouis [source] (cosmic-proposed) [3.6.0-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected hplip [source] (cosmic-proposed) [3.18.7+dfsg1-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted apache2 [source] (cosmic-proposed) [2.4.34-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted xfwm4 [source] (cosmic-proposed) [4.12.5-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted shotwell [source] (cosmic-proposed) [0.30.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: network-manager-strongswan (cosmic-proposed/universe) [1.4.4-1 => 1.4.4-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted network-manager-strongswan [sync] (cosmic-proposed) [1.4.4-2]
-queuebot:#ubuntu-release- Unapproved: openmpi (cosmic-proposed/universe) [3.1.2-3 => 3.1.2-5] (kubuntu) (sync)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-37.40]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-37.40]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [4.15.0-1022.23]
-queuebot:#ubuntu-release- Unapproved: neutron (xenial-proposed/main) [2:8.4.0-0ubuntu7.3 => 2:11.0.5-0ubuntu1~cloud1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1022.25] (kernel)
<tsimonq2> What's up with these kernel publishing race conditions causing bionic livefs to be FTBFS lately? :P
-queuebot:#ubuntu-release- Unapproved: friendly-recovery (cosmic-proposed/main) [0.2.38 => 0.2.38ubuntu1] (core)
<xnox> slashd, ^ that diff is very bad.
<xnox> slashd, (1) missing bug # (2) missing multi maintainer attribution
<xnox> slashd, it seems like your ~/.devscripts does not have these two settings set:
<xnox> DEBCHANGE_MULTIMAINT=yes
<xnox> DEBCHANGE_MULTIMAINT_MERGE=yes
<vorlon> tsimonq2: it's always been there in -proposed, since linux-signed was introduced
<xnox> slashd, as in, with those settings, when you did dch --release it would have generated [ Dimitri John Ledkov ] heading for the changes. Currently it looks like you wrote those changes, even though you did not.
<xnox> vorlon, please reject friendly-recovery from cosmic-proposed/main a diff sponsored badly.
<vorlon> xnox, slashd: friendly-recovery friendly-rejected
-queuebot:#ubuntu-release- Unapproved: rejected friendly-recovery [source] (cosmic-proposed) [0.2.38ubuntu1]
<xnox> vorlon, can you force kill and fail the inprogress ros-ros-comm autopkgtest on i386 in cosmic? to be replaced by a run of a new src version, which does not DDoS scalingstack instances.
<xnox> vorlon, current one allocates so many VMs that they eventually fail to provision, and it is restarted in a loop.
<xnox> (the new one already ran, and migrated, just need to rerun it with a python trigger)
<vorlon> xnox: not trivially
<vorlon> xnox: I think if I kill it it goes straight back into the rabbit queue
<vorlon> xnox: but also, it shouldn't restart in a loop?
<xnox> vorlon, no, because that autopkgtest will fail again, because the tests DDoS the crappy L1TF scalingstack. The new source test doesn't allocate 24 VM and thus passes in 30s, instead of wasting 5h trying to allocate 24 VMs failing on anyone of them, and restarting all over again.
<xnox> vorlon, it's been running for 24h now, with autorestarts.....
<xnox> vorlon, i'm constructing a new request for the result i wait.
<xnox> vorlon, but that one needs to be purged somehow, cause it will continue to DDoS
<vorlon> autorestarts> wtf
<xnox> unless it gets lucky
<xnox> hopefully it will notice the old package is gone and use a new one, maybe that will make it pass....
<xnox> i guess we can wait until tomorrow to see if it will really die or not.
<vorlon> well let me see what I can do
<slashd> vorlon, xnox sure ok thanks, will do the modification and re-upload later this week. Thanks
<xnox> slashd, unless i get there first.... i really had not yet a fully successful: select recovery from grub, select network, select root, check network is up, exit, select resume, wait for gdm to appear.
<xnox> on cosmic
<xnox> but i'm not sure if this is a bug in friendly-recovery, or in cosmic.
<vorlon> xnox: confirmed, I shot the nova instance and another started up before I could hit enter
<slashd> xnox, ok my goal was to at least fix the network menu for users (which works for me and confirmed with community too)
<xnox> slashd, sure. but imho it is grave is selecting "resume" does not resume boot =/
<xnox> slashd, sure. but imho it is grave if selecting "resume" does not resume boot =/
<slashd> xnox, right
<xnox> unless like resume is changed to `reboot`
<slashd> xnox, so you suggest we wait to fix resume before uploading anything ?
<vorlon> xnox: ok possibly nuked now
<xnox> slashd, yes. but i'm testing this on cosmic... and i don't know if this is just cosmic broken. there are lots of chatter on #ubuntu-desktop about all the things broken.
<xnox> vorlon, and this 1h 55m zombie is... ? http://autopkgtest.ubuntu.com/running#pkg-ros-ros-comm
<slashd> xnox, ack ok I was too fast then, keep me posted, and let me know if I can be of any help.
<xnox> vorlon, actually now gone
-queuebot:#ubuntu-release- Unapproved: grub2 (cosmic-proposed/main) [2.02+dfsg1-5ubuntu5 => 2.02+dfsg1-5ubuntu6] (core)
<vorlon> xnox: it snuck past me again; I think I've deleted it from the queue for real now
-queuebot:#ubuntu-release- Unapproved: telegram-desktop (cosmic-proposed/universe) [1.3.14-1 => 1.4.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted telegram-desktop [sync] (cosmic-proposed) [1.4.0-1]
-queuebot:#ubuntu-release- Unapproved: grub2-signed (cosmic-proposed/main) [1.107 => 1.108] (core)
<xnox> vorlon, looks good! excuses page got a regression, and there was a failed run, and nothing in the queue, retriggered using the new source which should finish quickly.
<Laney> it would have picked up the new version after it migrated
<Laney> no need to do anything there, which is why I hadn't
<xnox> feck
-queuebot:#ubuntu-release- Unapproved: hplip (cosmic-proposed/main) [3.18.7+dfsg1-2 => 3.18.7+dfsg1-2ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New sync: xxhash (cosmic-proposed/primary) [0.6.5-1]
-queuebot:#ubuntu-release- Unapproved: cloud-init (bionic-proposed/main) [18.3-9-g2e62cb8a-0ubuntu1~18.04.2 => 18.4-0ubuntu1~18.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [18.3-9-g2e62cb8a-0ubuntu1~16.04.2 => 18.4-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted network-manager [source] (cosmic-proposed) [1.12.4-1ubuntu1]
<tsimonq2> vorlon: ah
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (cosmic-proposed) [18.4-0ubuntu1]
<blackboxsw> hi folks , I know it's a busy week. just wanted to give a heads up that we've queued an SRU into xenial and bionic for cloud-init https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1795953
<ubot5> Ubuntu bug 1795953 in cloud-init (Ubuntu) "sru cloud-init (18.3.9-g2e62cb8a-0ubuntu1) to (18.4-0ubuntu1~18.04.1)" [Undecided,New]
<blackboxsw> no rush just wanted to note it so we could hopefully start our SRU aging timer this week.  :) thx for the cloud-init Cosmic
-queuebot:#ubuntu-release- Unapproved: accepted postfix [source] (cosmic-proposed) [3.3.0-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-gcp [sync] (cosmic-proposed) [4.18.0-1001.2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed-gcp [sync] (cosmic-proposed) [4.18.0-1001.2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-gcp [sync] (cosmic-proposed) [4.18.0.1001.1]
-queuebot:#ubuntu-release- Unapproved: budgie-artwork (cosmic-proposed/universe) [0.9.6 => 0.9.7] (personal-fossfreedom, ubuntu-budgie)
<ginggs> would someone please accept openmpi 3.1.2-5?  it fixes at least arpack on armhf and med-fichier on i386
<vorlon> Laney: I see gjs is a sync from experimental; do you want to add any color to this that would save me time figuring out if it needs an FFe?
<vorlon> Laney: or I can search scrollback and see that you already commented at time of upload, ta
<vorlon> Laney: +               --disable-Werror  lol?
-queuebot:#ubuntu-release- Unapproved: neutron (cosmic-proposed/main) [2:13.0.0-0ubuntu4 => 2:13.0.1-0ubuntu1] (openstack, ubuntu-server)
<xnox> vorlon, so i'm failing to reproduce test_ssl failure of python3.6 on i386 as triggered by openssl. python3.6 triggered by python3.6 with openssl 1.1.1 (cause it built against it) did pass once already.
<xnox> vorlon, it appears to be racy, sometimes fails with debug interpreter, sometimes with regular one, sometimes with one or more then one test case.
<xnox> typically upon second connection against the same server from the same test case.
<xnox> hmmmmm
<xnox> i wonder if it could be entropy.
<xnox> can i locally force delete entropy?
<vorlon> force-*delete*?
<vorlon> oh you mean locally for testing
<xnox> yeah
<xnox> ideally namespaced for a container ;-) stgraber do we have namespaced /dev/random yet? =)
<stgraber> xnox: nope, we don't. There were talks at some point about being able to rate-limit reads from /dev/random though
<stgraber> xnox: anyway, for testing you could use a cuse device I guess and have that return whatever you want
<xnox> vorlon, gpg --armor --gen-random 2 -> does not help, as i have Intel cpu feeding me 3k of entropy =/
<vorlon> heh
 * xnox boots a shitty cloud instance -> vendor to not be named
<xnox> vorlon, are you open to hinting python3.6/i386 or is that a no?
 * xnox wonders if i can kill entropy to reproduce the issue, or like if installing havegend in the tests will "help"
<xnox> forcing entropy below 50 now, test_ssl still passing for me
<vorlon> xnox: open to hinting it but not without a bug tracking whatever the heck is causing the functional regression
<vorlon> because having python3.6 eat all an i386 system's entropy in the wild due to openssl 1.1 is also not ok
<xnox> also i don't think that's the problem here, as with no entropy that test still passes.
<xnox> well, the testsuite indicates connection issue =/ connection closed by peer on a quick succession reconnect....
<xnox> which is not nice
<xnox> it was fine with previous python3.6.... i wonder if the post-auth handshake auth should be backed out of python3.6, cause that's what is introduced in this rc.
<xnox> versus the previous 3.6.6-4build1 which was "stable"
<xnox> and python2.7 which also does not have that patch.
<vorlon> cyphermox: rejecting grub2; sbsigntool doesn't exist on all architectures that grub-common exists on, and anyway, I don't think grub-common should have this dep - perhaps grub-efi-amd64 + grub-efi-amd64-signed should be the packages that depend on sbsigntool?
<xnox> not sure how to debug this / narrow this down.
-queuebot:#ubuntu-release- Unapproved: rejected grub2 [source] (cosmic-proposed) [2.02+dfsg1-5ubuntu6]
<vorlon> cyphermox: your fix for LP: #1788727 is much better than mine ,though
<ubot5> Launchpad bug 1788727 in grub2 (Ubuntu Cosmic) "upgrade crashing due to unsigned kernels" [High,In progress] https://launchpad.net/bugs/1788727
<xnox> in general 1.1.1 should be better, as it should be default to elliptic curve keys more, which are shmoller
-queuebot:#ubuntu-release- Unapproved: rejected grub2-signed [source] (cosmic-proposed) [1.108]
<xnox> huh, cpython upstream does not test on i386
<xnox> there is s390x, ppc64el, many amd64.... no i386
-queuebot:#ubuntu-release- Unapproved: gnome-music (cosmic-proposed/universe) [3.30.0-1 => 3.30.1-1] (desktop-extra, ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: diffoscope (cosmic-proposed/universe) [102 => 103] (no packageset) (sync)
<xnox> vorlon, reproduced!
-queuebot:#ubuntu-release- Unapproved: accepted diffoscope [sync] (cosmic-proposed) [103]
-queuebot:#ubuntu-release- Unapproved: bubblewrap (cosmic-proposed/main) [0.3.1-1ubuntu2 => 0.3.1-2] (ubuntugnome) (sync)
<vorlon> xnox: is it a floating point bug?
-queuebot:#ubuntu-release- Unapproved: docker-compose (cosmic-proposed/universe) [1.17.1-2 => 1.21.0-3] (no packageset) (sync)
<vorlon> ;)
-queuebot:#ubuntu-release- Unapproved: accepted docker-compose [sync] (cosmic-proposed) [1.21.0-3]
<xnox> vorlon, whilst building boost with -j12, on an 4core/8hyperthreaded core machine, with 32GB of ram, yet running single CPU i386 VM running test_ssl there results in ConnectionRefused
<xnox> (ie. host under load)
-queuebot:#ubuntu-release- Unapproved: python-docker (cosmic-proposed/universe) [2.5.1-1 => 3.4.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-docker [sync] (cosmic-proposed) [3.4.1-2]
-queuebot:#ubuntu-release- Unapproved: accepted bubblewrap [sync] (cosmic-proposed) [0.3.1-2]
<xnox> vorlon, so basically our cloud is over committed, if my guest exposes races between two races.
<xnox> vorlon, closed connection in one thread; and server thread cannot accept a new connection yet.
<xnox> when host is under load.
<xnox> vorlon, what are my options here? i'm adding an infinite retry loop now.
<vorlon> xnox: I wouldn't call exposing a race evidence of overcommit
<vorlon> infinite retry sounds ok to me :)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (cosmic-proposed/main) [4.18.0-1001.2] (kernel)
-queuebot:#ubuntu-release- Unapproved: graphviz (cosmic-proposed/universe) [2.40.1-4 => 2.40.1-5] (kubuntu) (sync)
-queuebot:#ubuntu-release- New: accepted ukui-greeter [amd64] (cosmic-proposed) [1.1.6-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-greeter [armhf] (cosmic-proposed) [1.1.6-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-greeter [ppc64el] (cosmic-proposed) [1.1.6-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted xxhash [sync] (cosmic-proposed) [0.6.5-1]
-queuebot:#ubuntu-release- New: accepted ukui-greeter [arm64] (cosmic-proposed) [1.1.6-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-greeter [s390x] (cosmic-proposed) [1.1.6-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-greeter [i386] (cosmic-proposed) [1.1.6-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted git [source] (cosmic-proposed) [1:2.19.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted openmpi [sync] (cosmic-proposed) [3.1.2-5]
#ubuntu-release 2018-10-04
-queuebot:#ubuntu-release- New binary: xxhash [s390x] (cosmic-proposed/none) [0.6.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xxhash [arm64] (cosmic-proposed/none) [0.6.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xxhash [ppc64el] (cosmic-proposed/none) [0.6.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xxhash [armhf] (cosmic-proposed/none) [0.6.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xxhash [i386] (cosmic-proposed/none) [0.6.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xxhash [amd64] (cosmic-proposed/none) [0.6.5-1] (no packageset)
<xnox> vorlon, agree, the testsuite's ThreadedEchoServer implementation is no gunicorn...
<vorlon> xnox: sounds like we should badtest this after all, as it's a bug in the tests not in the implementation?
<xnox> vorlon, the ssl bits are all correct and all working fine.
<xnox> vorlon, https://bugs.launchpad.net/auto-package-testing/+bug/1795999
<ubot5> Ubuntu bug 1795999 in python3.6 (Ubuntu) "python3.6 test_ssl fails reliably on systems under load" [Undecided,New]
<xnox> vorlon, is the bug. I do want to file upstream bug report
<xnox> vorlon, but also want to see if this is TLSv1.3 induced.... or not.
<xnox> vorlon, ie. if setting no-tls1.3 flag makes them all actually work fine.... or not.
<xnox> $ git push lp:~xnox/autopkgtest-cloud
<xnox> fatal: remote error: Unexpected Zope exception: TimeoutError: timeout exceeded.
<xnox> loving it =)
<xnox> vorlon, also possibly doing this https://code.launchpad.net/~xnox/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/356110 is better than badtesting it.
<doko> xnox: add python3.8 as well please
-queuebot:#ubuntu-release- Unapproved: openjfx (cosmic-proposed/universe) [8u171-b11-2ubuntu1 => 11+26-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted openjfx [sync] (cosmic-proposed) [11+26-1]
<xnox> doko, updated
-queuebot:#ubuntu-release- New: accepted xxhash [amd64] (cosmic-proposed) [0.6.5-1]
-queuebot:#ubuntu-release- New: accepted xxhash [armhf] (cosmic-proposed) [0.6.5-1]
-queuebot:#ubuntu-release- New: accepted xxhash [ppc64el] (cosmic-proposed) [0.6.5-1]
-queuebot:#ubuntu-release- New: accepted xxhash [arm64] (cosmic-proposed) [0.6.5-1]
-queuebot:#ubuntu-release- New: accepted xxhash [s390x] (cosmic-proposed) [0.6.5-1]
-queuebot:#ubuntu-release- New: accepted xxhash [i386] (cosmic-proposed) [0.6.5-1]
<vorlon> so somebody decided to accept git?
<xnox> wgrant, vorlon - so if I disable tls v1.3 on the echo server..... all tests pass reliably with and without load.
<wgrant> Ahh, so buggy *new* code.
<wgrant> The best kind.
<wgrant> Interesting, though
<xnox> wgrant, which is abi compatible, cause little did the testcode know it's doing tlsv1.3 now....
<wgrant> Is TLS 1.3 slower, or is there a new race in the 1.3 code.
<wgrant> Indeed
<xnox> wgrant, it should be faster, with quicker handshake, and lingering connections with fast reconnect.....
<vorlon> xnox: so that sounds like I shouldn't just merge your autopkgtest-cloud change yet
<xnox> vorlon, well. i think we are overdue migrating openssl 1.1.1
<tsimonq2> or
<tsimonq2> whoops
<xnox> vorlon, and tls 1.3 shit like this will catch "connectivity" issues like this.
<tsimonq2> (irssi alias, /or, grr)
<vorlon> xnox: ok, because when I asked you if I should badtest it you said you wanted to check if it was tls1.3-induced, and it was, but being tls1.3-induced doesn't change the outcome of whether you want the problem worked around? :)
<xnox> vorlon, correct.
<xnox> vorlon, and imho running python on big machines will be nice. the test-suite is parallizable, and takes 2h on single core VMs.
<xnox> vorlon, if we move it to big_packages, it will test quicker.
<xnox> vorlon, so independant of this, imho python testsuite is big enough for big_packages
<xnox> so i'd rather see this both big_packages + badtested
<vorlon> badtested or skiptested?
<vorlon> should moving to big_packages be enough to make the test reliable again?
<xnox> vorlon, i don't know the difference between badtested and skiptested. I have openssl -> python3.6/i386 regression, so "skiptest openssl"?
<xnox> i believe that yes, moving to big_packages will be enough to make it reliable.
<vorlon> xnox: skiptest openssl is "let the new openssl through"; badtest python3.6 is "ignore all future test failures of python3.6"
<xnox> experimenting locally cpushare of 4%+ is good enough
<vorlon> xnox: anyway I've possibly managed to land the change to big_packages, if you want to retest
<xnox> vorlon, i need the "let the new openssl through" because python3.6 itself has passed all tests already and is green to go
<xnox> only openssl itself is blocked at the moment.
<xnox> (python3.6 is >= 1.1.1 because it was rebuild with new openssl, and uses new apis.... hence it did green, over the weekend when things were quiet, with new ssl)
<vorlon> xnox: hinted
<vorlon> afk
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (cosmic-proposed) [4.18.0-1001.2]
-queuebot:#ubuntu-release- Unapproved: varconf (cosmic-proposed/universe) [1.0.1-5 => 1.0.1-6] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted varconf [sync] (cosmic-proposed) [1.0.1-6]
-queuebot:#ubuntu-release- Unapproved: gcc-snapshot (cosmic-proposed/universe) [1:20180908-1ubuntu1 => 1:20181004-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-snapshot [source] (cosmic-proposed) [1:20181004-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-fbdev (cosmic-proposed/main) [1:0.5.0-1 => 1:0.5.0-1ubuntu1] (desktop-core, xorg)
<tjaalton> please approve -fbdev ^
<tjaalton> reverts a commit which broke it when grub gfxpayload=keep is used
<tjaalton> which is used by default..
-queuebot:#ubuntu-release- Unapproved: bluedevil (bionic-proposed/universe) [4:5.12.6-0ubuntu0.1 => 4:5.12.7-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: breeze (bionic-proposed/universe) [4:5.12.6-0ubuntu0.1 => 4:5.12.7-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kactivitymanagerd (bionic-proposed/universe) [5.12.6-0ubuntu0.1 => 5.12.7-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kdeplasma-addons (bionic-proposed/universe) [4:5.12.6-0ubuntu0.1 => 4:5.12.7-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kinfocenter (bionic-proposed/universe) [4:5.12.6-0ubuntu0.1 => 4:5.12.7-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kscreen (bionic-proposed/universe) [4:5.12.6-0ubuntu0.1 => 4:5.12.7-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ksysguard (bionic-proposed/universe) [4:5.12.6-0ubuntu0.1 => 4:5.12.7-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kwin (bionic-proposed/universe) [4:5.12.6-0ubuntu0.1 => 4:5.12.7-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: breeze-gtk (bionic-proposed/universe) [5.12.4-0ubuntu1 => 5.12.7-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kde-cli-tools (bionic-proposed/universe) [4:5.12.6-0ubuntu0.1 => 4:5.12.7-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kmenuedit (bionic-proposed/universe) [4:5.12.6-0ubuntu0.1 => 4:5.12.7-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kwallet-pam (bionic-proposed/universe) [4:5.12.4-0ubuntu1.3 => 4:5.12.7-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: drkonqi (bionic-proposed/universe) [5.12.6-0ubuntu0.1 => 5.12.7-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kscreenlocker (bionic-proposed/universe) [5.12.6-0ubuntu0.1 => 5.12.7-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: khotkeys (bionic-proposed/universe) [4:5.12.6-0ubuntu0.1 => 4:5.12.7-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: libkscreen (bionic-proposed/universe) [4:5.12.4-0ubuntu1 => 4:5.12.7-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: milou (bionic-proposed/universe) [4:5.12.6-0ubuntu0.1 => 4:5.12.7-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plasma-desktop (bionic-proposed/universe) [4:5.12.6-0ubuntu0.1 => 4:5.12.7-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plasma-integration (bionic-proposed/universe) [5.12.6-0ubuntu0.1 => 5.12.7-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plasma-pa (bionic-proposed/universe) [4:5.12.6-0ubuntu0.1 => 4:5.12.7-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plasma-vault (bionic-proposed/universe) [5.12.6-0ubuntu0.1 => 5.12.7-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plymouth-kcm (bionic-proposed/universe) [5.12.6-0ubuntu0.1 => 5.12.7-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: powerdevil (bionic-proposed/universe) [4:5.12.6-0ubuntu0.1 => 4:5.12.7-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: systemsettings (bionic-proposed/universe) [4:5.12.6-0ubuntu0.1 => 4:5.12.7-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: libksysguard (bionic-proposed/universe) [4:5.12.6-0ubuntu0.1 => 4:5.12.7-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plasma-discover (bionic-proposed/universe) [5.12.6-0ubuntu0.1 => 5.12.7-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plasma-sdk (bionic-proposed/universe) [4:5.12.6-0ubuntu0.1 => 4:5.12.7-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: polkit-kde-agent-1 (bionic-proposed/universe) [4:5.12.6-0ubuntu0.1 => 4:5.12.7-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: oxygen (bionic-proposed/universe) [4:5.12.6-0ubuntu0.1 => 4:5.12.7-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plasma-workspace (bionic-proposed/universe) [4:5.12.6-0ubuntu0.1 => 4:5.12.7-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plasma-nm (bionic-proposed/universe) [4:5.12.6-0ubuntu0.1 => 4:5.12.7-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: sddm-kcm (bionic-proposed/universe) [4:5.12.6-0ubuntu0.1 => 4:5.12.7-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: user-manager (bionic-proposed/universe) [4:5.12.6-0ubuntu0.1 => 4:5.12.7-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: xdg-desktop-portal-kde (bionic-proposed/universe) [5.12.4-0ubuntu2 => 5.12.7-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted budgie-artwork [source] (cosmic-proposed) [0.9.7]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-music [sync] (cosmic-proposed) [3.30.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted hplip [source] (cosmic-proposed) [3.18.7+dfsg1-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-fbdev [source] (cosmic-proposed) [1:0.5.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gjs [sync] (cosmic-proposed) [1.54.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (cosmic-proposed) [2:13.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted graphviz [sync] (cosmic-proposed) [2.40.1-5]
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-gsconnect (cosmic-proposed/universe) [11+wip2018.07.26-0ubuntu2 => 11+wip2018.10.03-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-gsconnect [source] (cosmic-proposed) [11+wip2018.10.03-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: orca (cosmic-proposed/main) [3.29.3-3ubuntu1 => 3.30.0-1ubuntu1] (ubuntu-desktop)
<oSoMoN> can someone please approve https://code.launchpad.net/~osomon/britney/hints-ubuntu-libreoffice/+merge/356085 to unblock migration of libreoffice?
-queuebot:#ubuntu-release- Unapproved: rejected flatpak-builder [source] (bionic-proposed) [0.10.9-1ubuntu1]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-138.164] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-138.164]
-queuebot:#ubuntu-release- Unapproved: mailman-hyperkitty (cosmic-proposed/universe) [1.1.0-8ubuntu1 => 1.1.0-9] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mailman-hyperkitty [sync] (cosmic-proposed) [1.1.0-9]
-queuebot:#ubuntu-release- Unapproved: gimp-help (cosmic-proposed/universe) [2.8.2-0.1 => 2.8.2-0.2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gimp-help [sync] (cosmic-proposed) [2.8.2-0.2]
-queuebot:#ubuntu-release- Unapproved: keyrings.alt (cosmic-proposed/main) [3.0-1 => 3.1-1] (core) (sync)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-161.211] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: grilo-plugins (cosmic-proposed/main) [0.3.8-1ubuntu1 => 0.3.8-2ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1022.23~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-161.211]
<jbicha> sil2100: are you an AA?
<jbicha> if so, LP: #1795077 and LP: #1795094 need AA help
<ubot5> Launchpad bug 1795077 in brotli (Ubuntu Xenial) "Backport brotli 1.0.3 to Ubuntu 16.04 LTS" [Medium,In progress] https://launchpad.net/bugs/1795077
<ubot5> Launchpad bug 1795094 in woff2 (Ubuntu Xenial) "Backport woff2 to Ubuntu 16.04 LTS" [Medium,In progress] https://launchpad.net/bugs/1795094
<sil2100> jbicha: hey! Yes, let me take a look
<sil2100> jbicha: ok, let me review brotli in a moment
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1022.23~16.04.1]
-queuebot:#ubuntu-release- Unapproved: dune-istl (cosmic-proposed/universe) [2.6.0-1build1 => 2.6.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted dune-istl [sync] (cosmic-proposed) [2.6.0-2]
-queuebot:#ubuntu-release- Unapproved: r-cran-curl (cosmic-proposed/universe) [3.2-2build1 => 3.2-2build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-curl [source] (cosmic-proposed) [3.2-2build2]
<sil2100> jbicha: ok, might be able to accept brotli soon, just need to do a few more check - good that it has some basic autopkgtests now
<sil2100> Just need to jump out for lunch now
-queuebot:#ubuntu-release- Unapproved: update-manager (cosmic-proposed/main) [1:18.10.9 => 1:18.10.10] (core)
-queuebot:#ubuntu-release- Unapproved: polari (cosmic-proposed/universe) [3.28.0-1 => 3.30.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted polari [sync] (cosmic-proposed) [3.30.0-1]
<rbalint_> sil2100, could you please reject update-manager from cosmic? i'm adding one more fix to avoid crash upon upgrade
-queuebot:#ubuntu-release- Unapproved: rejected update-manager [source] (cosmic-proposed) [1:18.10.10]
<apw> rbalint_, ^
-queuebot:#ubuntu-release- Unapproved: dpkg (bionic-proposed/main) [1.19.0.5ubuntu2 => 1.19.0.5ubuntu2.1] (core)
-queuebot:#ubuntu-release- Unapproved: dpkg (xenial-proposed/main) [1.18.4ubuntu1.4 => 1.18.4ubuntu1.5] (core)
-queuebot:#ubuntu-release- Unapproved: plasma-discover (cosmic-proposed/universe) [5.13.5-1ubuntu3 => 5.13.5-1ubuntu4] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: r-cran-curl (cosmic-proposed/universe) [3.2-2build2 => 3.2-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: plasma-discover (cosmic-proposed/universe) [5.13.5-1ubuntu3 => 5.13.5-1ubuntu4] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-curl [source] (cosmic-proposed) [3.2-2ubuntu1]
<acheronuk> plasma-discover uploaded twice. oops. obviously please reject one :)
-queuebot:#ubuntu-release- Unapproved: flatpak-builder (bionic-proposed/universe) [0.10.9-1 => 0.10.9-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected plasma-discover [source] (cosmic-proposed) [5.13.5-1ubuntu4]
<ahasenack> hi, can someone fetch the reason for the reject in https://launchpad.net/ubuntu/cosmic/+queue?queue_state=4&queue_text=strongswan ? I think it's because it was superseeded by security updates
<ahasenack> cpaelzer, the uploader, is on pto
<Laney> they're not stored
<Laney> Sometimes people paste them into a bug - if there are any linked ones (didn't check), maybe look at those
<ahasenack> not the case here
<ahasenack> but thanks
<apw> Laney, that is sru-reject that does that isn't it ?
 * Laney claims extreme ignorance of tools that start with 'sru' ð
<Laney> I think the release team generally just use the queue's controls directly
<ahasenack> I found the bot message
<ahasenack> set 28 17:03:54 -queuebot/#ubuntu-release-      Unapproved: rejected strongswan [source] (cosmic-proposed) [5.6.3-1ubuntu2]
<ahasenack> but just that
<acheronuk> only record is in the email sent directly to uploader IIRC?
<apw> correct the only guarentted record is the uploaded email
<apw> if it is rejected using sru-reject that goes to the bugs too
<apw> ahasenack, in this case there was an accept at ubuntu2 followed by a reject at ubuntu2 which implies there were clashing versions in the queue
<ahasenack> apw: yeah, I think it was the secteam's upload
<acheronuk> accepted: http://launchpadlibrarian.net/390254692/strongswan_5.6.3-1ubuntu1_5.6.3-1ubuntu2.diff.gz
<acheronuk> rejected: http://launchpadlibrarian.net/390406930/strongswan_5.6.3-1ubuntu1_5.6.3-1ubuntu2.diff.gz
<apw> well they would have trumped you :)
<ahasenack> definitely, and that's fine
<acheronuk> seems so
<ahasenack> it got lost due to the uploader's pto
<ahasenack> (the fact that the upload didn't make it)
<ahasenack> I'll resubmit
<ahasenack> thx for checking
<apw> i wonder if we send that to the uploader, or to the maintainer too
<apw> oh well
-queuebot:#ubuntu-release- Unapproved: linux-aws (cosmic-proposed/main) [4.15.0-1023.23 => 4.18.0-1001.2] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-aws (cosmic-proposed/main) [4.15.0.1023.23 => 4.18.0.1001.1] (kernel) (sync)
-queuebot:#ubuntu-release- New source: fwupd-snap (cosmic-proposed/primary) [1.0]
<mfo> xnox, hi :) sorry to bother for updates but i have to (customer case) -- do you have any news on the upload for LP 1795658 that we talked about a couple days ago, please?
<ubot5> Launchpad bug 1795658 in systemd (Ubuntu Xenial) "xenial systemd reports 'inactive' instead of 'failed' for service units that repeatedly failed to restart / failed permanently" [Medium,Triaged] https://launchpad.net/bugs/1795658
-queuebot:#ubuntu-release- Unapproved: ubiquity-slideshow-ubuntu (cosmic-proposed/main) [139 => 140] (kubuntu, ubuntu-desktop)
<xnox> mfo, i need to prepare an upload with all of these https://bugs.launchpad.net/ubuntu/xenial/+source/systemd =/
-queuebot:#ubuntu-release- Unapproved: caffe (cosmic-proposed/universe) [1.0.0-8build1 => 1.0.0-8ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: grilo-plugins (cosmic-proposed/main) [0.3.8-1ubuntu1 => 0.3.8-2ubuntu1] (ubuntu-desktop)
<mfo> xnox, heh, i understand -- man, you're busy! :-)  so, i see it's in progress, thanks.  do you have any idea about when that might land? may be rough, like this week, next week, etc.
-queuebot:#ubuntu-release- Unapproved: accepted caffe [source] (cosmic-proposed) [1.0.0-8ubuntu1]
-queuebot:#ubuntu-release- Unapproved: nodejs (cosmic-proposed/universe) [8.11.2~dfsg-1ubuntu2 => 8.11.4~dfsg-0ubuntu1] (kubuntu)
<xnox> mfo, aiming to get it accepted into proposed within a week.
<mfo> xnox, sounds good. thanks again, and good luck there :-)
-queuebot:#ubuntu-release- Unapproved: rejected ubiquity-slideshow-ubuntu [source] (cosmic-proposed) [140]
-queuebot:#ubuntu-release- Unapproved: rejected grilo-plugins [source] (cosmic-proposed) [0.3.8-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted keyrings.alt [sync] (cosmic-proposed) [3.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-discover [source] (cosmic-proposed) [5.13.5-1ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted grilo-plugins [source] (cosmic-proposed) [0.3.8-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted orca [source] (cosmic-proposed) [3.30.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ubiquity-slideshow-ubuntu (cosmic-proposed/main) [139 => 140] (kubuntu, ubuntu-desktop)
<xnox> nodejs is a security update + fixups to use old openssl1.0 binary instead of incompatible openssl 1.1.1 (given the package was reverted to openssl1.0, this completes that work)
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity-slideshow-ubuntu [source] (cosmic-proposed) [140]
-queuebot:#ubuntu-release- Unapproved: accepted packagekit [source] (bionic-proposed) [1.1.9-1ubuntu2.18.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted packagekit [source] (xenial-proposed) [0.8.17-4ubuntu6~gcc5.4ubuntu1.4]
-queuebot:#ubuntu-release- Unapproved: grub2 (cosmic-proposed/main) [2.02+dfsg1-5ubuntu5 => 2.02+dfsg1-5ubuntu6] (core)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (cosmic-proposed/main) [1.107 => 1.108] (core)
-queuebot:#ubuntu-release- Unapproved: accepted brotli [source] (xenial-proposed) [1.0.3-1ubuntu1~16.04.1]
<jbicha> thank you
<handsome_feng> By any chance, could someone help upload ubuntukylin-wallpapers and ubuntukylin-theme? LP: #1791416 LP: #1794709, I file the bug almost 1 mouth ago, These two are very important for us :(
<ubot5> Launchpad bug 1791416 in ubuntukylin-wallpapers (Ubuntu) "Please upgrade ubuntukylin-wallpapers to 18.10.1" [Critical,Triaged] https://launchpad.net/bugs/1791416
<ubot5> Launchpad bug 1794709 in ubuntukylin-theme (Ubuntu) "Please upgrade ubuntukylin-theme to 1.7.9.2" [Critical,Triaged] https://launchpad.net/bugs/1794709
-queuebot:#ubuntu-release- New binary: brotli [s390x] (xenial-proposed/universe) [1.0.3-1ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: brotli [ppc64el] (xenial-proposed/universe) [1.0.3-1ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: brotli [powerpc] (xenial-proposed/universe) [1.0.3-1ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: brotli [arm64] (xenial-proposed/universe) [1.0.3-1ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: brotli [i386] (xenial-proposed/universe) [1.0.3-1ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: brotli [armhf] (xenial-proposed/universe) [1.0.3-1ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: brotli [amd64] (xenial-proposed/universe) [1.0.3-1ubuntu1~16.04.1] (no packageset)
<oSoMoN> can someone please approve https://code.launchpad.net/~osomon/britney/hints-ubuntu-libreoffice/+merge/356085 to unblock migration of libreoffice?
-queuebot:#ubuntu-release- Unapproved: sysvinit (cosmic-proposed/main) [2.88dsf-59.10ubuntu1 => 2.88dsf-59.10ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: strongswan (cosmic-proposed/main) [5.6.3-1ubuntu3 => 5.6.3-1ubuntu4] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: sssd (cosmic-proposed/main) [1.16.3-1 => 1.16.3-1ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: whoopsie-preferences (cosmic-proposed/main) [0.19 => 20] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted flatpak-builder [source] (bionic-proposed) [0.10.9-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: strace (cosmic-proposed/main) [4.21-1ubuntu1 => 4.21-1ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: squashfs-tools (cosmic-proposed/main) [1:4.3-6ubuntu1 => 1:4.3-6ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: rootskel (cosmic-proposed/main) [1.124ubuntu1 => 1.124ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: reiserfsprogs (cosmic-proposed/main) [1:3.6.27-2 => 1:3.6.27-2ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: python-openstackclient (cosmic-proposed/main) [3.16.0-0ubuntu1 => 3.16.1-0ubuntu1] (openstack, ubuntu-server)
<tjaalton> is anyone reviewing the new queue anymore?
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (cosmic-proposed/main) [1.424 => 1.425] (core)
-queuebot:#ubuntu-release- Unapproved: netplan.io (cosmic-proposed/main) [0.40 => 0.40.1] (core)
<cyphermox> tjaalton: many people are away today and tomorrow
<tjaalton> cyphermox: I've tried to ping folks for quite a while now
<tjaalton> but ok, doubt anyone heard this one, so I'll try again next week :)
-queuebot:#ubuntu-release- Unapproved: libinput (cosmic-proposed/main) [1.12.0-1 => 1.12.1-1] (desktop-core) (sync)
<cyphermox> tjaalton: yeah, well, like I said, most people are away or EOD today at least
<cyphermox> sil2100: you still around?
-queuebot:#ubuntu-release- Unapproved: netplan.io (bionic-proposed/main) [0.40~18.04.1 => 0.40.1~18.04.1] (core)
<sil2100> cyphermox: hey! Still a bit, what's up?
<cyphermox> sil2100: tjaalton and I have stuff in the queue that might benefit review, if you ahve time.
<sil2100> tjaalton: I am an AA but I'm not sure if my training wheels have been removed already or not, so most probably I'd need to get a double-check from someone else anyway
<cyphermox> ah
<sil2100> cyphermox: what did you want to have reviewed?
<tjaalton> sil2100: ah ok
<cyphermox> netplan.io 0.40.1 in cosmic and bionic
<sil2100> Technically I shouldn't have my training wheels anymore, but no one explicitly told me: "hey, you can review stuff on your own now, kthxbye"
<cyphermox> fixing a small regression there
<sil2100> cyphermox: ok
<tjaalton> well mine is basically a package split mandated by upstream.. so not "new" in that sense
<tjaalton> spirv-tools is though
<sil2100> cyphermox: I'm looking at the cosmic part now, but please in the meantime SRUify the LP: #1795343 bugy
<ubot5> Launchpad bug 1795343 in netplan "netplan backported on bionic (0.40~18.04.1) crash when there is an empty YAML configuration file" [Undecided,Confirmed] https://launchpad.net/bugs/1795343
<sil2100> tjaalton: I can try looking at the vulkan packages tomorro
<sil2100> w
<sil2100> tjaalton: but as said, I'll have to see them to decide if it's safe for me to do it on my own or not
<tjaalton> sil2100: sure, thanks!
<sil2100> cyphermox: btw. why is netplan.io shipping .pyc files anyway?
<tjaalton> spirv-tools is a dependency of vulkan-validationlayers (it used to be bundled in src:vulkan)
<tjaalton> bundled but not packaged, only used for building layers
-queuebot:#ubuntu-release- Unapproved: accepted netplan.io [source] (cosmic-proposed) [0.40.1]
<sil2100> cyphermox: ok, I'm good with the SRU, the change seems very non-regressionable and the test case is already present in the bug so I'll accept it
<sil2100> cyphermox: but for formalities sake, could you clean up the description when you have a moment?
<sil2100> Thanks!
<sil2100> Ok, now I need to go EOD as I am needed elsewhere
<sil2100> o/
-queuebot:#ubuntu-release- Unapproved: accepted netplan.io [source] (bionic-proposed) [0.40.1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: libdebian-installer (cosmic-proposed/main) [0.110ubuntu2 => 0.110ubuntu3] (core)
<bdmurray> Why does xenial-Contents-amd64.gz have an intro in it? neither bionic nor cosmic do.
<bdmurray> infinity: ^
<infinity> bdmurray: They all used to, and it was changed because some silly tools hated the header.
<infinity> bdmurray: But we don't regenerate old releases, so there you go.
<infinity> bdmurray: https://bugs.launchpad.net/launchpad/+bug/1638219
<ubot5> Ubuntu bug 1638219 in Launchpad itself "launchpad: remove headers from Contents files" [Low,Fix released]
-queuebot:#ubuntu-release- Unapproved: hplip (cosmic-proposed/main) [3.18.7+dfsg1-2ubuntu1 => 3.18.7+dfsg1-2ubuntu2] (desktop-core, ubuntu-server)
<bdmurray> infinity: got it, thanks!
-queuebot:#ubuntu-release- Unapproved: parted (cosmic-proposed/main) [3.2-21 => 3.2-21ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: netplan.io (cosmic-proposed/main) [0.40.1 => 0.40.2] (core)
-queuebot:#ubuntu-release- Unapproved: python-parsel (cosmic-proposed/universe) [1.5.0-1ubuntu1 => 1.5.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: python-etcd (cosmic-proposed/universe) [0.4.3-2 => 0.4.3-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-etcd [sync] (cosmic-proposed) [0.4.3-3]
-queuebot:#ubuntu-release- Unapproved: accepted python-parsel [sync] (cosmic-proposed) [1.5.0-2]
<xnox> infinity, awwww nice that it was finally removed!
 * xnox remembers having to parse "debian" and "ubuntu" contents and it was annoying that they are different
<xnox> infinity, also, could you please review https://launchpad.net/ubuntu/cosmic/+queue?queue_state=1&queue_text=nodejs ? it would be nice to get that one in, such that tls1.3 capable curl can migrate.
<infinity> xnox: Given that's a dfsg repack, is that the same orig that Debian will be using, or will we have a bit of a fakesync issue until the next upstream?
-queuebot:#ubuntu-release- Unapproved: awscli (cosmic-proposed/universe) [1.15.79-1 => 1.16.26-1] (ubuntu-cloud) (sync)
<infinity> xnox: Other than that minor concern, it looks somewhat sensible.
<xnox> infinity, 8.12 is out, the 8.11.4 is "pointrelease-1" so i expect next release to have new upstream release instantly.
<xnox> both still part of the 8.x LTS "track"
<xnox> so i expect to fakesync bussiness in DD-series
<xnox> so i expect _no_ fakesync bussiness in DD-series
-queuebot:#ubuntu-release- Unapproved: accepted strongswan [source] (cosmic-proposed) [5.6.3-1ubuntu4]
<infinity> xnox: Mmkay.  And if you're wrong, I assume you're happy (for some value of "happy") to deal with the merges until the 8.12 is a thing?
<infinity> s/until the/until/
<xnox> yeah
<xnox> we/i will have to merge, cause our openssl1.0 is different from debian's too
<xnox> and we are keeping 8.x on LTS
<infinity> xnox: Right, there's clearly merging to do either way, was just pointing out that merging is sometimes a bit more of a pain when the origes don't match.
<xnox> i was going to proposed backporting this upload as a security upload into bionic too
-queuebot:#ubuntu-release- Unapproved: accepted nodejs [source] (cosmic-proposed) [8.11.4~dfsg-0ubuntu1]
<xnox> infinity, yeah, i don't have a good solution on how to do dfsg's right
<xnox> it would be nice that the automatic repack thing is reproducible.
<infinity> xnox: We do it in glibc.  Took some effort, but our orig is 100% reproducible now, which is nice.
<xnox> it would be nice _if_ the automatic repack thing was reproducible.
<infinity> xnox: Means it doesn't matter who does the first upload in which distro, as long as we build the orig with the makefile goop we wrote to do it.
<xnox> infinity, i wonder if i should use .bz2 compression, such that when debian uploads .gz it is syncable ;-)
<infinity> seb128: Randomly deleting binaries on arches isn't sane (cf: random gnome binary deletions on s390x)
<xnox> hahahahhahahah
<xnox> infinity, we are following debian really ;-)
<infinity> xnox: Uhh, no we aren't.
<infinity> xnox: gdm3 builds on s390x in both Debian and Ubuntu, and is published on s390x in Debian, and was deleted in Ubuntu.  It'll come right back in the next upload.
<xnox> infinity, apparently RISC is the future, where RISC is https://buildd.debian.org/status/package.php?p=mozjs60
<jbicha> Debian is like the older brother that talked us into doing it first
<xnox> infinity, please comment on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909536 then =)
<ubot5> Debian bug 909536 in src:mozjs60 "mozjs60: FTBFS on s390x: around 80% of tests crash" [Serious,Open]
<infinity> xnox: I'm also failing to see how that's relevant, if these removed packages don't depend on that library...
<xnox> infinity, but that's the one that will provide gnome-shell's js going forward. and gdm3 is the same js frontend....
<infinity> xnox: That's not an argument for removing working binaries today. :P
<jbicha> infinity: I guess we can have gdm3 build-depend on either gjs or gnome-shell?
<jbicha> it's not working because gdm3 depends on gnome-shell which isn't satisfiable
<xnox> infinity, well, they are trying to land it all coherently.
<xnox> somehow, and that was one way to shove it in
<infinity> jbicha: Uhh, gnome-shell was removed the same way.
<infinity> jbicha: "We removed a working binary, so now others don't work" isn't much of an argument.
<jbicha> gnome-shell actually does build-depend on libgjs-dev which isn't available on s390x because mozjs60 isn't available there
<xnox> infinity, they are removing binaries that have become FTBFS - despite currently existing =)
<jbicha> we switched gjs from mozjs52 to mozjs60 today
<jbicha> LP: #1794721
<ubot5> Launchpad bug 1794721 in gjs (Ubuntu) "Remove gjs from s390x" [Undecided,Confirmed] https://launchpad.net/bugs/1794721
<infinity> jbicha: Okay, so it the plan to rebuild everything against the new one?
<infinity> jbicha: Cause that's not the current state of the world, afaict.
<xnox> the plan is to ship mozjs60 alone, yes.
<xnox> (as far as i understood / followed #ubuntu-desktop chatter)
<infinity> Or, wait.  So confused.
<infinity> Yeah, gnome-shell depends on the new one here.  But it's the same version as was removed on s390x.
<infinity> So, how did it build on s390x?
<infinity> Ignored tests?
<jbicha> yes
<xnox> infinity, yes, it used to ignore tests and fail shortly after exec but before anything could be initialized.
<xnox> infinity, it was a pile of garbage in ELF format
<jbicha> the first build of mozjs60 ignored the build tests but we stopped ignoring them for s390x since we assume it's badly broken there (compared to mozjs52)
<infinity> Okay, that makes a bit more sense.
<xnox> mozjs52 managed a bit of ECMA ECMA scripty scripty
<infinity> I'll still reiterate that removing binaries that would pop right back up with a copy is poor form.
<jbicha> you want no-change rebuilds for all of those?
<xnox> it could have been done better, yes, by using e.g. force-migrate and the like
<xnox> or adding a virtual s390x provides package to britney to smooth the migration
<jbicha> sorry we only do this like once per year and forget ð¿
<infinity> xnox: Ew, what?
<infinity> xnox: Those are all horrible options.
<xnox> infinity, you know what i like ;-)
<infinity> xnox: THe correct way is to upload packages that don't build on s390x.
<xnox> infinity, but you say to keep packages FTBFS on ports arches! =)
<xnox> infinity, they did what you last said to do ;-)
<infinity> (either because of build-deps, build failures, or arch restriction)
<xnox> fair
 * xnox is trolling
<infinity> xnox: I don't mean use arch restriction (that's the last hammer available in a long line), I mean that removing a built package without a new upload where it fails is asking for trouble.
<jbicha> infinity: you want no-change rebuilds now, right?
<xnox> jbicha, they would not be no-change rebuilds.
<xnox> jbicha, no change rebuild would pop binary in NEW again
<infinity> Wouldn't they be?
<infinity> Now if they build-dep on libgjs-dev..
<infinity> s/Now/Not/
<xnox> jbicha, he wants an upload of mozjs60 that does /not/ ignore test results, such that s390x arch is FTBFS
<xnox> jbicha, has that been done already?
<infinity> Or whatever.
<infinity> xnox: THat's already happened.
<xnox> ah, good!
<infinity> xnox: I'm talking about all the GNOME stuff that was just removed, not mozjs.
<infinity> And all that gnome stuff should be dep-wait or FTBFS, not built-but-mysteriously-missing.
<infinity> Unfortunately, I don't know how much "GNOME stuff" that entails.
<infinity> Based on the ubuntu-meta that just got uploaded, I assume gdm3, gnome-shell, and gnome-session, but maybe there were more.
<infinity> xnox: So, on the other hand, "80% of the tests fail with a segv in garbage collection on shutdown" sort of implies this is a single bug in mozjs that it wouldn't actually be hard to find and fix.
<infinity> xnox: I wonder why no one bothered to do that.
<xnox> infinity, we asked firefox upstream -> not interested; asked IBM multiple times -> not interested; chris -> was not interested either; and desktop team now maintains firefox -> i somehow suspect they are not interested either
<xnox> infinity, it was known that the day will come when we will need to move off 52
<xnox> infinity, even if we fix it this one time; it is pain without upstream/ibm/somebody caring going forward, as it tends to regress often.
<xnox> we had xenial-release or some such manage to even build firefox; but the subsequent security sru already regressed.
-queuebot:#ubuntu-release- Unapproved: gnome-characters (cosmic-proposed/main) [3.29.91-1 => 3.29.91-1ubuntu1] (ubuntu-desktop, ubuntugnome)
<infinity> xnox: "asked upstream -> not interested"?  The bug seems to disagree.
<infinity> You know, the one that's had back and forth acitivity for the last month.
<xnox> infinity, my asks were from before this round of asks.
<infinity> I think it's more "upstream doesn't have s390x, so they're playing back and forth with someone who is testing patches".
<xnox> infinity, i'm talking about myself of the engagement i've tried to drum up around this in 2017....
<xnox> infinity, i believe we have offered them a community z/vm for ci
<xnox> from maryst
<infinity> xnox: Anyhow, there's clearly an upstream person working on it.  Helping that upstream person might have been nice.  Not going to go on about it, though.
-queuebot:#ubuntu-release- Unapproved: gnome-documents (cosmic-proposed/universe) [3.30.0-1 => 3.30.0-1build1] (desktop-extra, ubuntugnome)
<infinity> My complaint was with the poorly-handled removals.
<infinity> (But I indeed also have a long-standing issue with "it doesn't work on something other than my laptop, drop !laptop from architecture line")
<infinity> s390x is just the current Belle of that ball.
<xnox> infinity, i dislike publishing arch:all packages in s390x Packages file that are known to be uninstallable
<xnox> imho arch:all publication should be smarter than that.
<infinity> xnox: Okay, and that's relevant to the removal of these s390x packages, how? :P
<infinity> xnox: I don't disagree, that misfeature annoys me, but also, it has nothing to do with the topic of gdm3, gnome-session, and gnome-shell, all of which are arch-dep.
-queuebot:#ubuntu-release- Unapproved: gnome-maps (cosmic-proposed/universe) [3.30.1-1 => 3.30.1-1build1] (desktop-extra, ubuntu-budgie, ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: gnome-sushi (cosmic-proposed/universe) [3.30.0-1 => 3.30.0-1build1] (desktop-extra, ubuntu-budgie, ubuntugnome)
<infinity> And another WAT.
<infinity> Package: libgjs0g
<infinity> Provides: libgjs0-libmozjs-52-0
<infinity> Depends: libmozjs-60-0
<infinity> Uh huh.
 * xnox slowly backs away to hack on systemd
<infinity> jbicha: ^-- lol?
<infinity> jbicha: Should that have been libgjs0h?
<infinity> jbicha: And a new Provides?
<infinity> jbicha: Then these rebuilds would be an actual sane transition. :P
-queuebot:#ubuntu-release- Unapproved: systemd (cosmic-proposed/main) [239-7ubuntu9 => 239-7ubuntu10] (core)
<jbicha> I think it's ok for it to still be libgjs0g, we didn't actually need rebuilds for gjs apps to keep working
<jbicha> the provides field obviously needs updated though
<infinity> jbicha: Yeah, I just pasted the same to Simon.
<infinity> Ahh, and indeed, Simon mentioned in the new upstream bug log that the ABI didn't break.
<jbicha> I'm uploading the provides fix to experimental now
<infinity> But yes, the provides seems silly.
 * infinity shrugs.
<jbicha> apt-cache showpkg libgjs0-libmozjs-52-0 shows only gnome-shell & gnome-sushi will be affected by that
<jbicha> I'll wait to hear back from smcv to make sure
<jbicha> you can reject gnome-sushi since we're not ready for that rebuild yet
-queuebot:#ubuntu-release- Unapproved: update-manager (cosmic-proposed/main) [1:18.10.9 => 1:18.10.10] (core)
-queuebot:#ubuntu-release- Unapproved: update-manager (bionic-proposed/main) [1:18.04.11.5 => 1:18.04.11.6] (core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-themes (cosmic-proposed/main) [16.10+18.04.20180421.1-0ubuntu1 => 16.10+18.10.20181004.1-0ubuntu1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-themes (bionic-proposed/main) [16.10+18.04.20180421.1-0ubuntu1 => 16.10+18.04.20181004-0ubuntu1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: ostree (cosmic-proposed/universe) [2018.8-2~salsa1 => 2018.8-2] (ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ostree [sync] (cosmic-proposed) [2018.8-2]
-queuebot:#ubuntu-release- Unapproved: cockpit (cosmic-proposed/universe) [178-1 => 179-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [sync] (cosmic-proposed) [179-1]
-queuebot:#ubuntu-release- Unapproved: flatpak (cosmic-proposed/universe) [1.0.2-1 => 1.0.3-1] (ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted flatpak [sync] (cosmic-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- Unapproved: flatpak-builder (cosmic-proposed/universe) [1.0.0-1 => 1.0.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted flatpak-builder [sync] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- Unapproved: eris (cosmic-proposed/universe) [1.3.23-6ubuntu1 => 1.3.23-7] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted eris [sync] (cosmic-proposed) [1.3.23-7]
#ubuntu-release 2018-10-05
-queuebot:#ubuntu-release- Unapproved: python-oslo.config (cosmic-proposed/main) [1:6.4.0-0ubuntu1 => 1:6.4.0-0ubuntu2] (openstack, ubuntu-server)
<smoser> hi. maybe someone can verify for me. i think the cloud-init uploads that are in queue for xenial and bionic will ultimately be rejected
<smoser> because they have a .orig.tar.gz that is different than the one that was uploaded to cosmic
<smoser> can someone just verify that and reject them if so ?
-queuebot:#ubuntu-release- Unapproved: cloud-init (bionic-proposed/main) [18.3-9-g2e62cb8a-0ubuntu1~18.04.2 => 18.4-0ubuntu1~18.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<blackboxsw> ok pushed an update for xenial and bionic
<vorlon> smoser: if the orig.tar.gz differs then yes, they would be rejected
<vorlon> not checking at the moment to verify that they are in fact different
-queuebot:#ubuntu-release- Unapproved: accepted whoopsie-preferences [source] (cosmic-proposed) [20]
-queuebot:#ubuntu-release- Unapproved: accepted sysvinit [source] (cosmic-proposed) [2.88dsf-59.10ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.config [source] (cosmic-proposed) [1:6.4.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted squashfs-tools [source] (cosmic-proposed) [1:4.3-6ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted rootskel [source] (cosmic-proposed) [1.124ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted strace [source] (cosmic-proposed) [4.21-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: twisted (cosmic-proposed/main) [18.7.0-2 => 18.7.0-3] (kubuntu, ubuntu-desktop, ubuntu-server) (sync)
<tjaalton> please accept libinput for cosmic, it's a stable update with only fixes
<sil2100> tjaalton: looking
-queuebot:#ubuntu-release- Unapproved: accepted libinput [sync] (cosmic-proposed) [1.12.1-1]
<tjaalton> thanks
-queuebot:#ubuntu-release- Unapproved: kwin (cosmic-proposed/universe) [4:5.13.5-1ubuntu1 => 4:5.13.5-1ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-37.40~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-37.40~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-37.40~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-37.40~16.04.1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-themes (bionic-proposed/main) [16.10+18.04.20180421.1-0ubuntu1 => 16.10+18.04.20181005-0ubuntu1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-themes (cosmic-proposed/main) [16.10+18.04.20180421.1-0ubuntu1 => 16.10+18.10.20181005-0ubuntu1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ledmon [source] (bionic-proposed) [0.90-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: gdm3 (bionic-proposed/main) [3.28.3-0ubuntu18.04.1 => 3.28.3-0ubuntu18.04.2] (ubuntu-desktop)
<Laney> OEM team are asking for that ^-, if someone has a minute
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1022.25]
-queuebot:#ubuntu-release- New: accepted brotli [amd64] (xenial-proposed) [1.0.3-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New: accepted brotli [armhf] (xenial-proposed) [1.0.3-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New: accepted brotli [powerpc] (xenial-proposed) [1.0.3-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New: accepted brotli [s390x] (xenial-proposed) [1.0.3-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New: accepted brotli [arm64] (xenial-proposed) [1.0.3-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New: accepted brotli [ppc64el] (xenial-proposed) [1.0.3-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New: accepted brotli [i386] (xenial-proposed) [1.0.3-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New sync: fonts-fork-awesome (cosmic-proposed/primary) [1.1.2+ds3-3]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (cosmic-proposed) [1.425]
<tjaalton> Laney: yep
<Laney> yep what?
<tjaalton> gdm
<Laney> nod
-queuebot:#ubuntu-release- Unapproved: accepted gdm3 [source] (bionic-proposed) [3.28.3-0ubuntu18.04.2]
<Laney> tjaalton: thanks!
<tjaalton> yw
-queuebot:#ubuntu-release- Unapproved: update-manager (xenial-proposed/main) [1:16.04.14 => 1:16.04.15] (core)
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (bionic-proposed) [2:12.0.4-0ubuntu1]
<smoser> ugh. i just uploaded bionic cloud-init accidnetly. meant to send to a ppa :-(
<smoser> please reject the very recent upload of mine to bionic-proposed.
-queuebot:#ubuntu-release- Unapproved: cloud-init (bionic-proposed/main) [18.3-9-g2e62cb8a-0ubuntu1~18.04.2 => 18.4-0ubuntu1~18.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<smoser> that one
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.35.2 => 2.35.4] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (bionic-proposed/main) [2.35.2+18.04 => 2.35.4+18.04] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.35.2~14.04 => 2.35.4~14.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapd (cosmic-proposed/main) [2.35.2+18.10 => 2.35.4+18.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: nova (cosmic-proposed/main) [2:18.0.0-0ubuntu5 => 2:18.0.1-0ubuntu1] (openstack, ubuntu-server)
<tjaalton> smoser: there are two uploads with the same version?
<smoser> tjaalton: yes. one about 11 hours ago by blackboxsw was designed.
<smoser> one about 1 hour or less ago was by me accidently.
<tjaalton> correction, three
<smoser> the one several days ago has the wrong .orig.tar.gz
<smoser> wrong meaning != the one in archive
<smoser> (same content different hash)
<tjaalton> and should be rejected too?
<smoser> yeah.
<smoser> there is also one with the wrong hash in xenial-proposed at the moment.
<smoser> so if you could reject that too it'd be good.
<smoser> and blackboxsw will upload one with correct orig tarball when he comes in
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (bionic-proposed) [18.4-0ubuntu1~18.04.1]
<tjaalton> done
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (bionic-proposed) [18.4-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (xenial-proposed) [18.4-0ubuntu1~16.04.1]
<smoser> tjaalton: thanks. it looks right now
<xnox> infinity, vorlon - should we try to sneak in gnutls 3.6.4 from experimental? it has tlsv1.3 support
<xnox> and nss 3.39 too =/
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [18.3-9-g2e62cb8a-0ubuntu1~16.04.2 => 18.4-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<blackboxsw> tjaalton just fixed xenial and proposed cloud-init uploads for SRU per SRU process  bug  https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1795953
<ubot5> Ubuntu bug 1795953 in cloud-init (Ubuntu) "sru cloud-init (18.3.9-g2e62cb8a-0ubuntu1) to (18.4-0ubuntu1~18.04.1)" [Undecided,New]
<blackboxsw> tjaalton: so thanks for rejecting the two previous uploads
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (cosmic-proposed) [2.35.4+18.10]
<blackboxsw> vorlon: I'm not sure if tjaalton is EOW.  do you think there will time today to peek at the above cloud-init SRU xenial/bionic?
-queuebot:#ubuntu-release- Unapproved: plasma-discover (cosmic-proposed/universe) [5.13.5-1ubuntu4 => 5.13.5-1ubuntu5] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: distro-info (xenial-backports/main) [0.14build1 => 0.18~ubuntu16.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted distro-info [source] (xenial-backports) [0.18~ubuntu16.04.1]
<vorlon> blackboxsw: I'm off work today
<vorlon> blackboxsw: I might be able to look when I get a moment, but best chance is to get somebody who's actually around (despite not being SRU vanguard)
<blackboxsw> vorlon: I just heard about the vacation day. sorry about the ping. If someone gets to it, great! If not, we will keep calm and carry on.
<tjaalton> blackboxsw: I'm back. this is only for xenial?
<blackboxsw> tjaalton: nice! xenial and bionic
<blackboxsw> https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=cloud-init
<blackboxsw> https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=cloud-init
<tjaalton> blackboxsw: I mean bug 1795953
<ubot5> bug 1795953 in cloud-init (Ubuntu Xenial) "sru cloud-init (18.3.9-g2e62cb8a-0ubuntu1) to (18.4-0ubuntu1~18.04.1)" [Undecided,New] https://launchpad.net/bugs/1795953
<tjaalton> ah
<blackboxsw> ahh yes that bug is for both
<blackboxsw> I'll drop the 18.04.1 from the version in the descr
<blackboxsw> and nominate for bionic
<blackboxsw> done
-queuebot:#ubuntu-release- Unapproved: gimp-help (cosmic-proposed/universe) [2.8.2-0.2 => 2.8.2-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gimp-help [sync] (cosmic-proposed) [2.8.2-1]
<tjaalton> blackboxsw: so I assume this sync has already been pre-approved by someone?
-queuebot:#ubuntu-release- Unapproved: gjs (cosmic-proposed/main) [1.54.0-1 => 1.54.1-1] (desktop-extra, mozilla, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: mozjs60 (cosmic-proposed/main) [60.2.1-1 => 60.2.3-1] (no packageset) (sync)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-138.164~14.04.1] (kernel)
<tjaalton> reading the wikipage..
<blackboxsw> tjaalton: I don't think this is a pre-approved exception to the SRU process. cloud-init has a sanding SRU exception though
<blackboxsw> https://wiki.ubuntu.com/CloudinitUpdates here ... right
<blackboxsw> *standing SRU exception*   rather
<tjaalton> right
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-138.164~14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (bionic-proposed) [18.4-0ubuntu1~18.04.1]
<tjaalton> blackboxsw: I see that xenial has more patches than bionic?
-queuebot:#ubuntu-release- Unapproved: kubuntu-meta (cosmic-proposed/universe) [1.377 => 1.378] (kubuntu)
<blackboxsw> tjaalton: sorry was at lunch. yes, debian/patches in xenial were to retain original behavior, we only really use the patches dir to persist original behavior in an older release if our upstream snapshot added a feature that would have changed the original behavior in the stable series.
<blackboxsw> bionic has had less new features that involved us having to retain original behavior, so less debian/patches
<blackboxsw> over time that will likely grow
<blackboxsw> thx for the bionic acceptance.
<tjaalton> blackboxsw: ok, thanks
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [18.4-0ubuntu1~16.04.1]
<blackboxsw> woot! happy friday happy EOW
-queuebot:#ubuntu-release- Unapproved: cysignals (cosmic-proposed/universe) [1.6.7+ds-4 => 1.6.7+ds-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cysignals [source] (cosmic-proposed) [1.6.7+ds-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu10.3 => 237-3ubuntu10.5] (core)
-queuebot:#ubuntu-release- Unapproved: cortina (cosmic-proposed/universe) [1.1.1-1ubuntu1 => 1.1.1-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cortina [source] (cosmic-proposed) [1.1.1-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: gnome-shell-mailnag (cosmic-proposed/universe) [3.26.0-1 => 3.26.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-mailnag [source] (cosmic-proposed) [3.26.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gnome-shell-pomodoro (cosmic-proposed/universe) [0.13.4-3 => 0.13.4-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-pomodoro [source] (cosmic-proposed) [0.13.4-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: git (cosmic-proposed/main) [1:2.19.0-1ubuntu1 => 1:2.19.1-1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: gnome-sound-recorder (cosmic-proposed/universe) [3.28.1-3 => 3.28.1-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-sound-recorder [source] (cosmic-proposed) [3.28.1-3build1]
-queuebot:#ubuntu-release- Unapproved: stress-ng (cosmic-proposed/universe) [0.09.41-1 => 0.09.42-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted stress-ng [sync] (cosmic-proposed) [0.09.42-1]
-queuebot:#ubuntu-release- Unapproved: babl (cosmic-proposed/universe) [0.1.56-1 => 0.1.58-1] (edubuntu, ubuntugnome, ubuntustudio) (sync)
#ubuntu-release 2018-10-06
-queuebot:#ubuntu-release- Unapproved: pikopixel.app (cosmic-proposed/universe) [1.0-b9c-1 => 1.0-b9d-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: javabeans-activation-framework (cosmic-proposed/universe) [1.2.0-1ubuntu1 => 1.2.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted javabeans-activation-framework [sync] (cosmic-proposed) [1.2.0-2]
-queuebot:#ubuntu-release- Unapproved: fflas-ffpack (cosmic-proposed/universe) [2.3.2-2 => 2.3.2-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted fflas-ffpack [sync] (cosmic-proposed) [2.3.2-3]
-queuebot:#ubuntu-release- Unapproved: cups-filters (cosmic-proposed/main) [1.21.2-1 => 1.21.3-1] (desktop-core, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: meta-gnome3 (cosmic-proposed/universe) [1:3.22+9 => 1:3.22+10] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted meta-gnome3 [sync] (cosmic-proposed) [1:3.22+10]
-queuebot:#ubuntu-release- Unapproved: sword (cosmic-proposed/universe) [1.7.3+dfsg-9.1build2 => 1.7.3.1+dfsg-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted sword [sync] (cosmic-proposed) [1.7.3.1+dfsg-2]
-queuebot:#ubuntu-release- Unapproved: anki (bionic-proposed/universe) [2.1.0+dfsg~b36-1 => 2.1.0+dfsg~b36-1ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: linux-meta (cosmic-proposed/main) [4.18.0.8.9 => 4.18.0.9.10] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux (cosmic-proposed/main) [4.18.0-8.9 => 4.18.0-9.10] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed (cosmic-proposed/main) [4.18.0-8.9 => 4.18.0-9.10] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: pikopixel.app (cosmic-proposed/universe) [1.0-b9c-1 => 1.0-b9d-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: spectre-meltdown-checker (cosmic-proposed/universe) [0.39-1 => 0.40-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted spectre-meltdown-checker [sync] (cosmic-proposed) [0.40-1]
-queuebot:#ubuntu-release- Unapproved: ubuntustudio-controls (cosmic-proposed/universe) [1.5 => 1.6] (ubuntustudio)
-queuebot:#ubuntu-release- New source: trojita (cosmic-proposed/primary) [0.7-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: lubuntu-default-settings (cosmic-proposed/universe) [1.15 => 1.16] (lubuntu)
-queuebot:#ubuntu-release- Unapproved: ubuntukylin-theme (cosmic-proposed/universe) [1.7.6 => 1.7.9.2] (ubuntukylin)
<wxl> vorlon: tsimonq2 just uploaded trojita for lubuntu. if you could review that, i'd greatly appreciate it.
-queuebot:#ubuntu-release- Unapproved: calamares-settings-ubuntu (cosmic-proposed/universe) [21 => 22] (lubuntu)
-queuebot:#ubuntu-release- Unapproved: lxqt-config (cosmic-proposed/universe) [0.13.0-0ubuntu4 => 0.13.0-0ubuntu5] (lubuntu)
-queuebot:#ubuntu-release- Unapproved: nm-tray (cosmic-proposed/universe) [0.4.0-0ubuntu3 => 0.4.1-0ubuntu1] (lubuntu)
-queuebot:#ubuntu-release- Unapproved: ubuntukylin-wallpapers (cosmic-proposed/universe) [18.04.0 => 18.10.1] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: libfm-qt (cosmic-proposed/universe) [0.13.1-5ubuntu4 => 0.13.1-5ubuntu5] (lubuntu)
-queuebot:#ubuntu-release- Unapproved: node-tap (bionic-proposed/universe) [11.0.0+ds1-2 => 11.0.0+ds1-2ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: lubuntu-meta (cosmic-proposed/universe) [1.12 => 1.13] (lubuntu)
#ubuntu-release 2018-10-07
-queuebot:#ubuntu-release- Unapproved: polari (cosmic-proposed/universe) [3.30.0-1 => 3.30.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted polari [sync] (cosmic-proposed) [3.30.1-1]
-queuebot:#ubuntu-release- Unapproved: gettext (cosmic-proposed/main) [0.19.8.1-7 => 0.19.8.1-8] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: vlc (bionic-proposed/universe) [3.0.4-1ubuntu0.1 => 3.0.4-1ubuntu0.2] (kubuntu, mozilla)
-queuebot:#ubuntu-release- Unapproved: calamares-settings-ubuntu (cosmic-proposed/universe) [21 => 23] (lubuntu)
<wxl> infinity, vorlon, someone: if you could please review tsimonq2's uploads, that'd be greeat. we have a bunch of little last minute things.. and one new package (trojita)
<tsimonq2> Assuming we're on the usual Final Freeze cycle there should be a few more things today.
-queuebot:#ubuntu-release- Unapproved: glom (cosmic-proposed/universe) [1.30.4-0ubuntu13 => 1.30.4-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: winetricks (cosmic-proposed/universe) [0.0+20180815-1 => 0.0+20180815-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted glom [sync] (cosmic-proposed) [1.30.4-1]
-queuebot:#ubuntu-release- Unapproved: accepted winetricks [sync] (cosmic-proposed) [0.0+20180815-1]
<wxl> anyone home? :(
-queuebot:#ubuntu-release- Unapproved: budgie-desktop-environment (cosmic-proposed/universe) [0.10.4 => 0.10.5] (personal-fossfreedom, ubuntu-budgie)
<tsimonq2> I guess the Release Team's taking the weekend off.
<tsimonq2> Fun.
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta [sync] (cosmic-proposed) [4.18.0.9.10]
-queuebot:#ubuntu-release- Unapproved: accepted linux [sync] (cosmic-proposed) [4.18.0-9.10]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed [sync] (cosmic-proposed) [4.18.0-9.10]
-queuebot:#ubuntu-release- Unapproved: accepted gjs [sync] (cosmic-proposed) [1.54.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted mozjs60 [sync] (cosmic-proposed) [60.2.3-1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-discover [source] (cosmic-proposed) [5.13.5-1ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted calamares-settings-ubuntu [source] (cosmic-proposed) [23]
-queuebot:#ubuntu-release- Unapproved: accepted nm-tray [source] (cosmic-proposed) [0.4.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted lxqt-config [source] (cosmic-proposed) [0.13.0-0ubuntu5]
-queuebot:#ubuntu-release- Unapproved: rejected calamares-settings-ubuntu [source] (cosmic-proposed) [22]
<tsimonq2> Huzzah, thanks to whoever that is. :)
-queuebot:#ubuntu-release- Unapproved: accepted hplip [source] (cosmic-proposed) [3.18.7+dfsg1-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted lubuntu-default-settings [source] (cosmic-proposed) [1.16]
-queuebot:#ubuntu-release- Unapproved: lubuntu-default-settings (cosmic-proposed/universe) [1.15 => 1.17] (lubuntu)
<tsimonq2> :P
-queuebot:#ubuntu-release- Unapproved: accepted netplan.io [source] (cosmic-proposed) [0.40.2]
-queuebot:#ubuntu-release- Unapproved: accepted python-openstackclient [source] (cosmic-proposed) [3.16.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted parted [source] (cosmic-proposed) [3.2-21ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted linux-aws [sync] (cosmic-proposed) [4.18.0-1001.2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-aws [sync] (cosmic-proposed) [4.18.0.1001.1]
-queuebot:#ubuntu-release- Unapproved: accepted kwin [source] (cosmic-proposed) [4:5.13.5-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (cosmic-proposed) [1.108]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (cosmic-proposed) [2.02+dfsg1-5ubuntu6]
-queuebot:#ubuntu-release- Unapproved: accepted lubuntu-default-settings [source] (cosmic-proposed) [1.17]
-queuebot:#ubuntu-release- Unapproved: accepted lubuntu-meta [source] (cosmic-proposed) [1.13]
<acheronuk> ty from me as well ^^ :)
-queuebot:#ubuntu-release- Unapproved: lxqt-globalkeys (cosmic-proposed/universe) [0.13.0-0ubuntu1 => 0.13.0-0ubuntu2] (lubuntu)
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (cosmic-proposed/main) [1.5ubuntu2 => 1.5ubuntu3] (desktop-core, ubuntu-server)
<wxl> infinity: if you could get libfm-qt and lxqt-globalkeys done that would be great. i can respin images and confirm allthe uploads we did yesterday did what we needed
<tsimonq2> wxl: Just remember that Britney might disagree that you can respin soon after acceptance.
<RAOF> Hm. Now is probably not the most polite time to start a library transition.
-queuebot:#ubuntu-release- Unapproved: grub2 (cosmic-proposed/main) [2.02+dfsg1-5ubuntu6 => 2.02+dfsg1-5ubuntu6] (core)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (cosmic-proposed/main) [4.18.0-9.10] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: meta-gnome3 (cosmic-proposed/universe) [1:3.22+10 => 1:3.22+11] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: vala (cosmic-proposed/universe) [0.42.1-1 => 0.42.2-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted meta-gnome3 [sync] (cosmic-proposed) [1:3.22+11]
-queuebot:#ubuntu-release- Unapproved: jquery-goodies (cosmic-proposed/universe) [12-1 => 12-1.1] (kubuntu) (sync)
#ubuntu-release 2019-09-30
-queuebot:#ubuntu-release- Unapproved: graphene (eoan-proposed/main) [1.9.6-1 => 1.10.0-1] (desktop-core) (sync)
-queuebot:#ubuntu-release- Unapproved: runc (eoan-proposed/universe) [1.0.0~rc8-0ubuntu1 => 1.0.0~rc8+git20190923.3e425f80-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted runc [source] (eoan-proposed) [1.0.0~rc8+git20190923.3e425f80-0ubuntu1]
<LocutusOfBorg> please accept python-json-patch, it should solve the autopkgtest regressions in binutils, due to the current archive being broken (two packages providing jsondiff binary)
<tjaalton> santa_: it's fixed in debian git
-queuebot:#ubuntu-release- Unapproved: accepted thunderbird [source] (eoan-proposed) [1:68.1.0+build3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [source] (eoan-proposed) [1.2.10-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: fwupd (eoan-proposed/main) [1.2.10-1ubuntu1 => 1.2.10-1ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: fwupd (eoan-proposed/main) [1.2.10-1ubuntu2 => 1.2.10-1ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: fwupd (eoan-proposed/main) [1.2.10-1ubuntu2 => 1.2.10-1ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: fwupd (eoan-proposed/main) [1.2.10-1ubuntu2 => 1.2.10-1ubuntu2] (core)
<doko> looks like the armhf autopkg testers are down. could somebody have a look?
<doko> Laney, juliank, vorlon: ^^^
<juliank> doko: all workers seem to be active
<juliank> well except one
<juliank> but there have not been any requests in 2 hours
<doko> juliank: update_excuses shows everything "in progress" for uploads since yesterday
<juliank> rabbitmq down maybe?
<xnox> vorlon:  rbalint: re:snapd change, we have tested latest -updates systemd and it is all good. I do expect snapd sru to go in, and finally fix /snap/bin in path.
<xnox> vorlon:  re: amd64-microcode => yeah =/
<juliank> no idea what happens
<juliank> tests are running, I just triggered one
<juliank> but I don't see it in the log
<juliank> ah, wrong arch
<juliank> doko: so the queues are empty, probably the britney requests have been lost somewhere
<juliank> doko: hmm, no, there are only like 10 in progress tests, and they're in the queue
<juliank> ah, all amrhf
<juliank> yeah, the lxd worker is down
<Laney> the controller?
<Laney> WTF
<Laney> check the conole-log
<Laney> if it's something about ksplice, please go bug IS with that information
<Laney> I don't think I rebooted that one on Friday when some of the other machines were down
<Laney> but that update was suppsoed to not be hitting machines any mroe
<juliank> [11243666.512952] Out of memory: Kill process 12446 (uptrack-upgrade) score 7 or sacrifice child
<juliank> [11243666.514985] Killed process 13791 (ksplice-apply) total-vm:45276kB, anon-rss:11104kB, file-rss:1504kB
<juliank> Laney: ^
<Laney> yes
<Laney> same thing as the other machines then
<Laney> nova reboot it, it should come back
<juliank> Laney: issued reboot request a few secs ago
<Laney> IS should be told that machines are still being killed by this update
<juliank> doko: should be back up
<LocutusOfBorg> can we reschedule the pending tests please?
<LocutusOfBorg> btw please accept python-json-patch, it fixes an RC bug that prevents its installation
<juliank> LocutusOfBorg: reschedule, why?
<juliank> the few armhf ones were queued, just not processed
<juliank> the queue is being processed, we're down to 24 now
<LocutusOfBorg> ack
-queuebot:#ubuntu-release- Unapproved: accepted keystone [source] (disco-proposed) [2:15.0.0-0ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted ibm-java80 [sync] (xenial-release) [8.0.5.40-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected ibm-java80 [sync] (bionic-release) [8.0.5.40-0ubuntu1]
<apw> ^ accepted to xenial-release ?  that is not going to go well at all
<xnox> apw:  why not? it's propietary stand-alone binary, and we copy up from xenial to bionic. Just like any other build, of an unchanged thing
<xnox> oh
<xnox> oh
<xnox> oh
<xnox> it should be partner, right?!
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [amd64] (eoan-proposed) [1.2.10-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [armhf] (eoan-proposed) [1.2.10-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted python-json-patch [source] (eoan-proposed) [1.23-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [arm64] (eoan-proposed) [1.2.10-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [i386] (eoan-proposed) [1.2.10-1ubuntu2]
<xnox> apw:  looks fine on https://launchpad.net/ubuntu/+source/ibm-java80/+publishinghistory
<doko> juliank, Laney: while the armhf tests triggered by binutils were run, the ones triggered by mesa are not. could you have a look again?
<xnox> apw:  can you explain what's "not going well at all" ?
-queuebot:#ubuntu-release- Unapproved: rejected fwupd [source] (eoan-proposed) [1.2.10-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted fwupdate [sync] (eoan-proposed) [12-7]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-guide [source] (eoan-proposed) [19.10.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-mahjongg [sync] (eoan-proposed) [1:3.34.0-1]
<doko> juliank, Laney: while the armhf tests triggered by binutils were run, the ones triggered by mesa are not. could you have a look again?
<apw> xnox, it was accepted into a closed pocket
<juliank> doko: yup, the mesa ones got lost
<apw> xnox, or perhaps it somehow is not closed in partner, so that is a thing
<doko> juliank: not just limited to those ...
<juliank> doko: well yes, git-annex got lost too
<juliank> ah but there also seem to be some test bed failures for apport triggered by binutils
<juliank> The remote "lxd-armhf-10.44.44.116" doesn\'t exist
<juliank> but it does exist
<Laney> that looks like it's running ok to me
<Laney> for the lost ones, probably failed to submit when rabbitmq was down
<Laney> feel free to retry
-queuebot:#ubuntu-release- Unapproved: anjuta (eoan-proposed/universe) [2:3.34.0-1~ubuntu1 => 2:3.34.0-2] (desktop-extra) (sync)
-queuebot:#ubuntu-release- Unapproved: gnome-builder (eoan-proposed/universe) [3.32.0-1 => 3.32.4-2] (desktop-extra) (sync)
-queuebot:#ubuntu-release- Unapproved: jhbuild (eoan-proposed/universe) [3.15.92+20180504~8974bbc4-1 => 3.34.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted jhbuild [sync] (eoan-proposed) [3.34.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted exim4 [source] (eoan-proposed) [4.92.1-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted mate-menu [source] (eoan-proposed) [19.10.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ubiquity (eoan-proposed/main) [19.10.12 => 19.10.13] (core)
-queuebot:#ubuntu-release- Unapproved: accepted libtext-charwidth-perl [sync] (eoan-proposed) [0.04-9]
-queuebot:#ubuntu-release- Unapproved: accepted libtext-wrapi18n-perl [sync] (eoan-proposed) [0.06-9]
-queuebot:#ubuntu-release- Unapproved: accepted spice-vdagent [sync] (eoan-proposed) [0.19.0-2]
<sil2100> apw: yeah, that's a thing
<sil2100> apw: for partner there's just proposed and release basically, so all is good
<sil2100> apw: did you reject the partner upload for bionic?
<sil2100> Since I was sure I accepted that one
<sil2100> But I see a reject here instead
<sil2100> apw: if that was you and your only concern was the pocket it was targetting, I'll accept it from Rejected
<apw> sil2100, i didn't reject (or indeed accpet anyting) i was just supprised by -release
<sil2100> hm, so a misclick!
<sil2100> eh, "FAILED: ibm-java80 (Can't resurrect rejected syncs)", will just re-sync
<LocutusOfBorg> juliank, e.g. git-annex on armhf is seen as "running", but seems not
<juliank> I said that
<LocutusOfBorg> lol sorry you are right
<LocutusOfBorg> can I retry armhf?
-queuebot:#ubuntu-release- Unapproved: ibm-java80 (bionic-release/partner) [8.0.5.35-0ubuntu1 => 8.0.5.40-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ibm-java80 [sync] (bionic-release) [8.0.5.40-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-caja (eoan-proposed/universe) [1.22.1-0ubuntu1 => 1.22.1-0ubuntu2] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntustudio-menu [source] (eoan-proposed) [0.34]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntustudio-meta [source] (eoan-proposed) [0.195]
-queuebot:#ubuntu-release- Unapproved: libreoffice (eoan-proposed/main) [1:6.3.1-0ubuntu2 => 1:6.3.2-0ubuntu1] (ubuntu-desktop)
<Laney> yes, if only one person does it
<juliank> I retried
<juliank> everything in eoan should be retried afaict
<juliank> or rather has been
<juliank> other releases might need some look at
 * juliank had a look
<juliank> No SRUs affected it seems
<Laney> cheers
<LocutusOfBorg> + show=Source: binutils-mipsen (4~c4ubuntu1)
<LocutusOfBorg> doko, ^^ binutils is sad on amd64 and i386...
<doko> known. needs an autopkg fix, or a permanent hint
<LocutusOfBorg> thanks, I really would like to see binutils migrate, since abi-monitor is now fixed
-queuebot:#ubuntu-release- Unapproved: yaru-theme (eoan-proposed/main) [19.10.3 => 19.10.4] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted pidgin [source] (eoan-proposed) [1:2.13.0-2.2ubuntu1]
<santa_> tjaalton: I see, there's a commit doing something similar compared with what I did in those test builds, thanks
<santa_> tjaalton: I guess you a are going to merge all the -2 debian package changes in the ubuntu package?
-queuebot:#ubuntu-release- Unapproved: accepted cups-filters [sync] (eoan-proposed) [1.25.6-1]
<tjaalton> santa_: eventually, yes
<santa_> tjaalton: ok, I will leave that entirely on your hands then, thanks for your time
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1046.49] (kernel)
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (eoan-proposed) [1:6.3.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-builder [sync] (eoan-proposed) [3.32.4-2]
-queuebot:#ubuntu-release- Unapproved: accepted python-caja [source] (eoan-proposed) [1.22.1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: kstars (eoan-proposed/universe) [5:3.2.3-0ubuntu2 => 5:3.3.6-0ubuntu1] (kubuntu)
<RikMills> ^^ LP: #1845922
<ubot5> Launchpad bug 1845922 in kstars (Ubuntu) "[FFE] Update to latest kstars (3.3.6) in Eoan" [Undecided,New] https://launchpad.net/bugs/1845922
<RikMills> I am committing to doing fixes/SRU on that if needed &
-queuebot:#ubuntu-release- Unapproved: accepted kubuntu-settings [source] (eoan-proposed) [1:19.10ubuntu9]
-queuebot:#ubuntu-release- Unapproved: evince (eoan-proposed/main) [3.32.0-1ubuntu3 => 3.34.0-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted evince [sync] (eoan-proposed) [3.34.0-1]
<bdmurray> I want to rescue something out of the rejected queue for disco but there are two of the same version number there. Any ideas? Manually review / accept then figure out how to use sru-accept?
<cjwatson> Hack sru-review a bit to accept a queue item ID?
<cjwatson> The queue tool does that by constructing URLs manually, which is icky but functional
<bdmurray> cjwatson: Ah thanks, I realized I just wanted the most recent one which is what it uses anyway. ;-)
-queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu10.29 => 237-3ubuntu10.30] (core)
<infinity> bdmurray: perhaps sru-review wants a --no-accept switch added to all its other Don't Do Stuff options, so sru-accept can be deleted.
<infinity> Then for your case above, you could have done --no-diff --no-accept.
<infinity> (Or --no-queue might be more apporpriate, telling it to entirely not do anything with the queue, including looking at it?)
<bdmurray> infinity: I wanted to accept it out of rejected but there were 2 packages with the same version #
<infinity> bdmurray: Right, my point was sru-review that didn't touch the queue would be the same as sru-accept, then you could accept it out of band (with web UI or queue tool or whatever).
<bdmurray> infinity: Ah, I see now.
-queuebot:#ubuntu-release- Unapproved: finalrd (eoan-proposed/main) [3 => 4] (core)
<xnox> infinity:  i would appreciate if above is reviewed and accepted =) i'm sure you will enjoy the fact that initramfs-tools uses ${verbose?} these days
<infinity> xnox: Gross.  Looks like someone blindly following recommendations from a static syntax checker.
<infinity> https://salsa.debian.org/kernel-team/initramfs-tools/commit/f277309e0b6b57ff2f8f9411c026394b7635f3d6
<infinity> But no harm in your change, so accepting it.
<infinity> xnox: Also, shouldn't v3 and v4 have been 2.1 and 2.2, so the fake os-release-like file would still be accurate? :)
-queuebot:#ubuntu-release- Unapproved: accepted finalrd [source] (eoan-proposed) [4]
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (eoan-proposed) [19.10.13]
-queuebot:#ubuntu-release- Unapproved: accepted yaru-theme [source] (eoan-proposed) [19.10.4]
<xnox> infinity:  so i changed it from Kelly's Eye to One little duck when i change the calling convention / naming / behaviour of the .finalrd scripts. And all other uploads were stable / unchanged behaviour so far.
<xnox> infinity:  i really have no idea if that file is needed at all. but it keeps systemd-shutdown happy and it's "standard" (lennart) compliant.
<xnox> but yeah, will ponder bumping versions inside it.
<infinity> xnox: Yeah, 3 and 4 didn't deserve major versions, but too late now. :)
<infinity> (I guess systemd has dragged you down the All Versions Are Equal road)
<xnox> infinity:  pondering to upload casper. i guess you want one-tiny-upload per bug, rather than a pile of goo?
<infinity> I do?
<infinity> Assuming the bugs and changes are all called out in the changelog in a way I can review without going insane, I don't mind it all at once.
<xnox> well, mixing critical bugfix with subiquity-netboot-feature is not a good look =)
<infinity> And casper isn't so complex that I expect the changes to intertwine and cause paddedroomery.
<powersj> vorlon, if you have time today there is a cloud-init SRU that is ready for release
<infinity> xnox: But you do you, man.  If there's a small crit you can bang out now, and something more featureful that you might want to intentionally keep in proposed for a few days with a blocking bug while you exercise it, that might be an excuse to break them up.
<xnox> well, i will want to spin up daily desktop, to ensure reboot thing is gone
<infinity> win 165
-queuebot:#ubuntu-release- Unapproved: e2fsprogs (eoan-proposed/main) [1.45.3-4ubuntu1 => 1.45.3-4ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted e2fsprogs [source] (eoan-proposed) [1.45.3-4ubuntu2]
-queuebot:#ubuntu-release- New: accepted gedit-plugins [amd64] (eoan-proposed) [3.34.0-2~build1]
-queuebot:#ubuntu-release- New: accepted gedit-plugins [armhf] (eoan-proposed) [3.34.0-2~build1]
-queuebot:#ubuntu-release- New: accepted gedit-plugins [ppc64el] (eoan-proposed) [3.34.0-2~build1]
-queuebot:#ubuntu-release- New: accepted gedit-plugins [arm64] (eoan-proposed) [3.34.0-2~build1]
-queuebot:#ubuntu-release- New: accepted gedit-plugins [s390x] (eoan-proposed) [3.34.0-2~build1]
-queuebot:#ubuntu-release- New: accepted gedit-plugins [i386] (eoan-proposed) [3.34.0-2~build1]
-queuebot:#ubuntu-release- New: accepted mysql-workbench [amd64] (eoan-proposed) [8.0.17+dfsg-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted mysql-workbench [armhf] (eoan-proposed) [8.0.17+dfsg-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted mysql-workbench [ppc64el] (eoan-proposed) [8.0.17+dfsg-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted mysql-workbench [arm64] (eoan-proposed) [8.0.17+dfsg-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted mysql-workbench [s390x] (eoan-proposed) [8.0.17+dfsg-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted mysql-workbench [i386] (eoan-proposed) [8.0.17+dfsg-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu10.29 => 237-3ubuntu10.30] (core)
-queuebot:#ubuntu-release- Unapproved: rejected systemd [source] (bionic-proposed) [237-3ubuntu10.30]
-queuebot:#ubuntu-release- Unapproved: rejected systemd [source] (bionic-proposed) [237-3ubuntu10.30]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1046.49]
-queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu10.30 => 237-3ubuntu10.31] (core)
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (bionic-proposed) [237-3ubuntu10.31]
#ubuntu-release 2019-10-01
-queuebot:#ubuntu-release- Unapproved: smlnj (eoan-proposed/universe) [110.79-4build1 => 110.79-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted smlnj [sync] (eoan-proposed) [110.79-5]
-queuebot:#ubuntu-release- Unapproved: almanah (eoan-proposed/universe) [0.11.1-2.1 => 0.11.1-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted almanah [sync] (eoan-proposed) [0.11.1-3]
-queuebot:#ubuntu-release- Unapproved: rblcheck (eoan-proposed/universe) [20020316-10 => 20190930-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: rbldnsd (eoan-proposed/universe) [0.998b~pre1-1 => 0.999~20180516-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted rblcheck [sync] (eoan-proposed) [20190930-1]
-queuebot:#ubuntu-release- Unapproved: accepted rbldnsd [sync] (eoan-proposed) [0.999~20180516-3]
-queuebot:#ubuntu-release- Unapproved: 3dldf (eoan-proposed/universe) [2.0.3+dfsg-7 => 2.0.3+dfsg-7ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted 3dldf [source] (eoan-proposed) [2.0.3+dfsg-7ubuntu1]
-queuebot:#ubuntu-release- Unapproved: poedit (eoan-proposed/universe) [2.2.3-2 => 2.2.4-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted poedit [sync] (eoan-proposed) [2.2.4-1]
-queuebot:#ubuntu-release- Unapproved: 3dldf-doc (eoan-proposed/multiverse) [2.0.3+ndfsg-3 => 2.0.3+ndfsg-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted 3dldf-doc [sync] (eoan-proposed) [2.0.3+ndfsg-4]
-queuebot:#ubuntu-release- Unapproved: boinc (eoan-proposed/universe) [7.16.1+dfsg-2 => 7.16.3+dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted boinc [sync] (eoan-proposed) [7.16.3+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: dnsdist (eoan-proposed/universe) [1.4.0~beta1-3 => 1.4.0~rc2-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted dnsdist [sync] (eoan-proposed) [1.4.0~rc2-1]
-queuebot:#ubuntu-release- Unapproved: autoconf (eoan-proposed/main) [2.69-11 => 2.69-11ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: manila (eoan-proposed/universe) [1:9.0.0~rc1-0ubuntu1 => 1:9.0.0~rc1-0ubuntu2] (openstack)
-queuebot:#ubuntu-release- Unapproved: gcc-snapshot (eoan-proposed/universe) [1:20190903-0ubuntu1 => 1:20191001-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-snapshot [source] (eoan-proposed) [1:20191001-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted networking-ovn [amd64] (eoan-proposed) [7.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted spirv-llvm-translator [arm64] (eoan-proposed) [9.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted spirv-llvm-translator [i386] (eoan-proposed) [9.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted spirv-llvm-translator [amd64] (eoan-proposed) [9.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted spirv-llvm-translator [ppc64el] (eoan-proposed) [9.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted spirv-llvm-translator [armhf] (eoan-proposed) [9.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: u-boot (bionic-proposed/main) [2018.07~rc3+dfsg1-0ubuntu3~18.04.1 => 2018.07~rc3+dfsg1-0ubuntu3~18.04.2] (core)
<Laney> LocutusOfBorg: http://autopkgtest.ubuntu.com/packages/d/diffoscope/eoan/s390x wtf
-queuebot:#ubuntu-release- Unapproved: mate-control-center (eoan-proposed/universe) [1.22.2-0ubuntu1 => 1.22.2-0ubuntu2] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: python-aodhclient (eoan-proposed/main) [1.1.1-0ubuntu2 => 1.1.1-0ubuntu3] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-cinderclient (eoan-proposed/main) [1:5.0.0-0ubuntu1 => 1:5.0.0-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-neutronclient (eoan-proposed/main) [1:6.11.0-0ubuntu3 => 1:6.11.0-0ubuntu4] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-novaclient (eoan-proposed/main) [2:15.1.0-0ubuntu1 => 2:15.1.0-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-glanceclient (eoan-proposed/main) [1:2.17.0-0ubuntu1 => 1:2.17.0-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-glareclient (eoan-proposed/universe) [0.5.3-0ubuntu2 => 0.5.3-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New binary: intel-opencl-clang [amd64] (eoan-proposed/universe) [9.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: intel-opencl-clang [i386] (eoan-proposed/universe) [9.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-glareclient [source] (eoan-proposed) [0.5.3-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: grubzfs-testsuite (eoan-proposed/universe) [0.4.1 => 0.4.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted grubzfs-testsuite [source] (eoan-proposed) [0.4.2]
<tjaalton> what's up with mesa triggered tests on armhf all being 'in progress' for several days?
<Laney> juliank said that those had been retried
<Laney> guessing not
<juliank> oh
<juliank> I guess I did not scroll down far enough and only looked at binutils
<LocutusOfBorg> Laney, meh, I still don't understand *how* could the new version migrate with broken autopkgtest on s390x
<LocutusOfBorg> this is why I retried, I didn't notice it was migrated, I wanted to try with the old version, and I discovered after that it has migrated
<LocutusOfBorg> can anybody understand how can a failed test with no hints migrate?
<LocutusOfBorg> btw I'm looking right now at mono to fix it
<LocutusOfBorg> I need to see britney logs to see how it could migrate
<Laney> they are available under proposed-migration/log/
<LocutusOfBorg> yep I'm already having a look
-queuebot:#ubuntu-release- Unapproved: grub2 (eoan-proposed/main) [2.04-1ubuntu6 => 2.04-1ubuntu7] (core)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (eoan-proposed/main) [1.122 => 1.123] (core)
<LocutusOfBorg> Laney,
<LocutusOfBorg> I: [Mon Sep 30 12:12:40 2019] - Checking for new results for failed debuerreotype/s390x for trigger diffoscope/125
<LocutusOfBorg> I: [Mon Sep 30 12:12:40 2019] - diffoscope/s390x triggered by diffoscope/125 already passed
<LocutusOfBorg> this looks impossible...
<LocutusOfBorg> 12.07.38
<Laney> this message is when proposed-migration thinks it has already been told about the result
<ginggs> would someoone please 'force-badtest deepnano/0.0+git20170813.e8a621e-3/amd64' ?  it seems to have not timed out only once there
-queuebot:#ubuntu-release- Unapproved: casper (eoan-proposed/main) [1.419 => 1.420] (desktop-core, ubuntu-server)
<xnox> Laney:  ^ should fix live session shutdown, however asked jibel to confirm if this does indeed work. It works for me, and I hope I'm not just simply getting lucky.
<jibel> xnox, it seems to be working, I'll try a second time
<xnox> yeah =)
<Laney> cool
<Laney> do you know what broke it?
<xnox> Laney:  please accept, and we should respin desktop images.
<xnox> Laney:  so, we mark cdrom.mount in casper to be masked (symlink to devnull), then mount cow overlay filesystem which becomes our /
<xnox> Laney:  it seems like systemd manages to tear down /cdrom, because it is active now.
<xnox> Laney:  and everything goes south from there, with the rest of filesystems in-use / busy.
<xnox> i've tried to do many extensive units to ensure cdrom.mount is LazyUnmount=yes ForceUnmount=yes After=casper.service etc. to end up with still a hang but less broken units. At which point I gave up, and pivoting to shutdown initramfs fixes everything, as we detach / make all filesystems not busy and run systemd-shutdown binary from RAM with all the tools in RAM, meaning it just kills-all unmount-all
<xnox> reboot-now
<xnox> Laney:  i suspect there is more things held up because of more snaps, but gave up tracing things.
<xnox> so in a way, this is a shotgun approach to shutdown, just blast the thing.
<jibel> xnox, ok, it works
<jibel> I'll confirm with the automated tests too once it's on the image
<mwhudson> xnox: finalrd saves the day!?
<xnox> mwhudson:  very
<mwhudson> xnox: also systemd fails to guess dependencies between mount units, or something else?
<xnox> mwhudson:  and the reason why server image is not as affected.
<xnox> mwhudson:  well, systemd is getting strict about things that are "masked" yet "active". Because that really shouldn't be happening.
<Laney> lets do it
<Laney> how come we don't use finalrd everywhere already
<Laney> ?
<xnox> that's a valid question
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (disco-proposed/main) [5.0.0-31.33] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (disco-proposed/main) [5.0.0-31.33] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (disco-proposed/main) [5.0.0-31.33] (core, kernel)
<mwhudson> xnox: hah i hadn't read your changelog when i made my witty remark
<xnox> Laney:  i guess the thinking is that it's not strictly needed, yet it is very needed when things go astray, and it ensures slightly better to have clean shutdowns everywhere.
<xnox> Laney:  i guess i wrote it, and didn't want to force it by default.
-queuebot:#ubuntu-release- Unapproved: accepted casper [source] (eoan-proposed) [1.420]
<Laney> well, suggest it :-)
-queuebot:#ubuntu-release- Unapproved: openjdk-8 (eoan-proposed/universe) [8u232-b04-0ubuntu6 => 8u232-b07-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-8 [sync] (eoan-proposed) [8u232-b07-1]
-queuebot:#ubuntu-release- Unapproved: gcc-snapshot (eoan-proposed/universe) [1:20191001-1ubuntu1 => 1:20191001-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mate-dock-applet (eoan-proposed/universe) [19.10.0-1 => 19.10.0-1ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-snapshot [source] (eoan-proposed) [1:20191001-1ubuntu2]
<Laney> xnox: hope you're fixing the build failure
<Laney> that deletion didn't show up in the debdiff :(
<xnox> Laney:  i used a shitty git checkout that did warn me about it, instead of downloading pull-lp-source
<xnox> sigh
<xnox> yes, will do.
<xnox> fixing properly
-queuebot:#ubuntu-release- Unapproved: casper (eoan-proposed/main) [1.420 => 1.421] (desktop-core, ubuntu-server)
<xnox> Laney:  tested that this new build results in same deb as 1.419
<ginggs> would someone please 'force-badtest gazebo/all/arm64 gazebo/all/armhf gazebo/all/ppc64el' ? it is not built on these architectures
-queuebot:#ubuntu-release- Unapproved: zfs-linux (eoan-proposed/main) [0.8.1-1ubuntu11 => 0.8.1-1ubuntu12] (core)
-queuebot:#ubuntu-release- Unapproved: accepted casper [source] (eoan-proposed) [1.421]
-queuebot:#ubuntu-release- Unapproved: thunderbird (eoan-proposed/main) [1:68.1.0+build3-0ubuntu1 => 1:68.1.1+build1-0ubuntu1] (mozilla, ubuntu-desktop)
<oSoMoN> dear release team, please approve thunderbird 1:68.1.1+build1-0ubuntu1. It's a new upstream point update with a security fix, and equally importantly it's now built against the system-wide libsqlite3 which makes it work on ppc64el and will unblock the migration from -proposed
<Laney> ginggs: doing so
<Laney> why is it that I find some retries from LocutusOfBorg on there
<Laney> doko: I'll badtest binutils and diffoscope
-queuebot:#ubuntu-release- Unapproved: mesa (eoan-proposed/main) [19.2.0~rc4-1ubuntu1 => 19.2.0-1ubuntu1] (core, xorg)
<doko> Laney: looks like binutils now will always file with the autopkg issue finding the wrong version number
<Laney> dunno, but hopefully the patch from ddstreet will get in soon
<ddstreet> Laney i'm working on the testcase now
<Laney> w00t
-queuebot:#ubuntu-release- Unapproved: gdpc (eoan-proposed/universe) [2.2.5-9build1 => 2.2.5-9ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gdpc [source] (eoan-proposed) [2.2.5-9ubuntu1]
<seb128> infinity, doko, libextutils-depends-perl and libextutils-pkgconfig-perl are new depends of libglib-perl (foundations) and libcairo-gobject-perl (desktop), what's the deal with those, do we need MIRs and can they just be promoted as perl things?
-queuebot:#ubuntu-release- Unapproved: gnocchi (eoan-proposed/universe) [4.3.4-0ubuntu2 => 4.3.4-0ubuntu3] (no packageset)
<jamespage> hi release team - I've upload a set of changes to openstack packageset packages which resolve a number of autopkgtest failures which are blocking proposed migrations
<jamespage> nice if they could be accepted please :)
<jamespage> python-*client, manila and gnocchi are all in that category although the gnocchi upload also includes a mysql8 compatibility fix
-queuebot:#ubuntu-release- Unapproved: accepted gnocchi [source] (eoan-proposed) [4.3.4-0ubuntu3]
<doko> seb128: last time cyphermox wanted a short MIR for such packages.
<jamespage> ah but that's in universe...
<cyphermox> doko: seb128: well, at least a bug so we can track what happened
<seb128> cyphermox, doko, do you guys plan to work on that?
<cyphermox> just a paper trail if they're perl packages that we know are otherwise well maintained
<doko> seb128: LP: #1846217
<ubot5> Launchpad bug 1846217 in libextutils-depends-perl (Ubuntu) "[MIR] libextutils-depends-perl, libextutils-pkgconfig-perl (dependency of libcairo-gobject-perl)" [High,Incomplete] https://launchpad.net/bugs/1846217
<seb128> doko, why is it assigned to desktop? https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#foundations-bugs libglib-perl
<doko> seb128: becase the dependency is desktop owned?
<seb128> doko, libglib-perl  is owned by foundations
<doko> seb128: this is according to https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
<doko> I'm not making up things
<seb128> doko, right, but do you know why c-m isn't picking http://launchpadlibrarian.net/442901553/libglib-perl_3%3A1.329-5_3%3A1.329.1-1.diff.gz ?
<doko> seb128: no, but feel free to fix the graph generation
<seb128> if I get bored one day maybe
<seb128> meanwhile back to the topic, those depends are pulled it by both foundations and desktop
<seb128> so I guess anyone with the free cycle can/should file the MIRs
<seb128> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1846151
<ubot5> Launchpad bug 1846151 in ubiquity (Ubuntu) "cannot boot into OS if install with lvm and encryption" [Undecided,New]
<seb128> likely something to test/confirm and maybe rls track?
<seb128> jibel, ^ wdyt?
<jibel> seb128, I can check but it worked for beta
<seb128> jibel, the bug states it's an issue on beta ... might be specific to the laptop model or racy....
<jibel> seb128, nvidia without proprietary drivers
<jibel> systems hangs on boot
<jibel> i'll ask for more data
-queuebot:#ubuntu-release- Unapproved: compiz (eoan-proposed/universe) [1:0.9.14.0+19.04.20190223.1-0ubuntu1 => 1:0.9.14.0+19.10.20190918-0ubuntu1] (ubuntu-mate) (sync)
<seb128> thx
<jibel> + drivers from upstreaml
<jibel> s/drivers/packages
<jibel> Sep 27 18:19:40 LVM nvidia-settings-autostart.desktop[2080]: ERROR: NVIDIA driver is not loaded
<jibel> Sep 27 18:19:40 LVM nvidia-settings-autostart.desktop[2080]: ERROR: Unable to load info from any available system
<seb128> it's from someone from the OEM team, I wonder what they are testing exactly...
<jibel> no idea there is no installation logs
<jibel> seb128, system booted with secure boot on and the kernel refused to load the proprietary drivers
-queuebot:#ubuntu-release- Unapproved: accepted autoconf [source] (eoan-proposed) [2.69-11ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted manila [source] (eoan-proposed) [1:9.0.0~rc1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted python-aodhclient [source] (eoan-proposed) [1.1.1-0ubuntu3]
<xnox> Laney:  casper migrated, can we respin desktop? to see if the automated testing comes back alive?
<xnox> unless there are other things we wan to wait for / see things with tomorrow's daily?
-queuebot:#ubuntu-release- Unapproved: accepted python-cinderclient [source] (eoan-proposed) [1:5.0.0-0ubuntu2]
<Laney> already ahead of you on that one
-queuebot:#ubuntu-release- Unapproved: accepted python-neutronclient [source] (eoan-proposed) [1:6.11.0-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: gnome-desktop3 (eoan-proposed/main) [3.33.91-1ubuntu2 => 3.34.0-2ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted python-novaclient [source] (eoan-proposed) [2:15.1.0-0ubuntu2]
<ginggs> Laney: thanks for gazebo
<ginggs> would someone please 'force-badtest deepnano/0.0+git20170813.e8a621e-3/amd64' ?  it seems to have not timed out only once there
<seb128> apw, could you help again with thunderbird and review the update in the queue? it should resolve the ppc64el issues than have been olding the new tb from migrating out of proposed
<blackboxsw> vorlon: :) If there is time today, we have a small cloud-init SRU that has all attached verifcation logs for xenial, bionic and Disco.
<blackboxsw> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1844334  cloudinit v 19.2.36
<ubot5> Launchpad bug 1844334 in cloud-init (Ubuntu Disco) "SRU cloud-init (19.2.36): Xenial, Bionic, and Disco" [Undecided,Fix committed]
<vorlon> blackboxsw: hi - sorry, had seen powersj's ping yesterday but it fell off the stack.  Do you want to direct this to the SRU vanguard perhaps?
<blackboxsw> absolutely, figured I'd give you first right of refusal. will do
<blackboxsw> bdmurray: or RAOF are either of you available today for a cloud-init SRU review. It should be small this time. https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1844334  cloudinit v 19.2.36
<ubot5> Launchpad bug 1844334 in cloud-init (Ubuntu Disco) "SRU cloud-init (19.2.36): Xenial, Bionic, and Disco" [Undecided,Fix committed]
<blackboxsw> targets are Xenial, Bionic and Disco
-queuebot:#ubuntu-release- Unapproved: accepted python-glanceclient [source] (eoan-proposed) [1:2.17.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (eoan-proposed) [2.04-1ubuntu7]
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (eoan-proposed) [1.123]
<bdmurray> blackboxsw: its on my list for the day
<blackboxsw> excellent bdmurray !
<doko> vorlon: you are wrong with the twitter-bootstrap3 issue. it's now triggered by libevdev, not mailman3
<bdmurray> blackboxsw: I'm gonna set the devel task in that bug to fix released
<blackboxsw> ahh good pt bdmurray
<blackboxsw> thank you
-queuebot:#ubuntu-release- Unapproved: grub2 (eoan-proposed/main) [2.04-1ubuntu7 => 2.04-1ubuntu7] (core)
<bdmurray> I'm surprised somebody else didn't catch it. ;-)
<blackboxsw> I blame it on travel and croissants
-queuebot:#ubuntu-release- Unapproved: grub2 (eoan-proposed/main) [2.04-1ubuntu7 => 2.04-1ubuntu7] (core)
-queuebot:#ubuntu-release- Unapproved: intel-microcode (eoan-proposed/main) [3.20190514.1ubuntu1 => 3.20190918.1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: barbican (eoan-proposed/main) [1:9.0.0~b1~git2019061315.3c2a9960-0ubuntu1 => 1:9.0.0~rc1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ubiquity-slideshow-ubuntu (eoan-proposed/main) [148 => 149] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnocchi (eoan-proposed/universe) [4.3.4-0ubuntu3 => 4.3.4-0ubuntu4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gnocchi [source] (eoan-proposed) [4.3.4-0ubuntu4]
<vorlon> doko: I'm not wrong that there was an open MIR already when you reopened the old one; and libevdev-doc could be demoted if this didn't need to be in main for any functional reason
<vorlon> doko: demoted
-queuebot:#ubuntu-release- Unapproved: bison-doc (eoan-proposed/main) [1:3.4.1+repack-1 => 1:3.4.1+repack-1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: heat (eoan-proposed/main) [1:13.0.0~b2~git2019073114.4563f0d0d-0ubuntu1 => 1:13.0.0~rc1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: budgie-desktop (eoan-proposed/universe) [10.5-0ubuntu5 => 10.5-0ubuntu6] (personal-fossfreedom, ubuntu-budgie)
<blackboxsw> thanks bdmurray for the quick turnaround
-queuebot:#ubuntu-release- Unapproved: budgie-desktop-environment (eoan-proposed/universe) [0.12.2 => 0.12.3] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- Unapproved: blitz++ (eoan-proposed/universe) [1:1.0.1+ds-5 => 1:1.0.1+ds-5ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted blitz++ [source] (eoan-proposed) [1:1.0.1+ds-5ubuntu1]
<ginggs> vorlon: hi, please https://code.launchpad.net/~ginggs/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/373475
<ginggs> autopkgtests pass in debian and for me locally in eoan
-queuebot:#ubuntu-release- Unapproved: c++-annotations (eoan-proposed/universe) [11.1.1-1 => 11.1.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted c++-annotations [source] (eoan-proposed) [11.1.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: casper (eoan-proposed/main) [1.421 => 1.422] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: c-graph (eoan-proposed/universe) [2.0.1-3.1 => 2.0.1-3.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted c-graph [source] (eoan-proposed) [2.0.1-3.1ubuntu1]
<ginggs> infinity: "many big_packages are for timeouts", isn't that what long_tests is for?
-queuebot:#ubuntu-release- Unapproved: sahara (eoan-proposed/universe) [1:11.0.0~rc1-0ubuntu1 => 1:11.0.0~rc1-0ubuntu2] (openstack)
<vorlon> ginggs: our big instances get more cores not just more RAM; the 'autopkgtest' instance flavor has 1 core, an m1.large IIRC 4
<vorlon> so, 'big' vs 'long' are not entirely orthogonal here
-queuebot:#ubuntu-release- Unapproved: cffi (eoan-proposed/universe) [1:0.20.0-1 => 1:0.20.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cffi [source] (eoan-proposed) [1:0.20.0-1ubuntu1]
<seb128> could someone review thunderbird and let it in? we would like some testing of the new version before release, it has been sitting in proposed for a while due to enigmail and jsunit and ppc64el issue, hopefully the one in the queue resolves the last issues and is able to migrate to eaon proper now
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (eoan-proposed) [2.04-1ubuntu7]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (eoan-proposed) [2.04-1ubuntu7]
-queuebot:#ubuntu-release- Unapproved: accepted bison-doc [source] (eoan-proposed) [1:3.4.1+repack-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: cl-asdf (eoan-proposed/universe) [2:3.3.3-2 => 2:3.3.3-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cl-asdf [source] (eoan-proposed) [2:3.3.3-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: dieharder (eoan-proposed/universe) [3.31.1-7build1 => 3.31.1-7ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted dieharder [source] (eoan-proposed) [3.31.1-7ubuntu1]
-queuebot:#ubuntu-release- Unapproved: doxygen (eoan-proposed/universe) [1.8.13-10ubuntu2 => 1.8.13-10ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-desktop3 [source] (eoan-proposed) [3.34.0-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-control-center [source] (eoan-proposed) [1.22.2-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (eoan-proposed) [19.2.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted intel-microcode [source] (eoan-proposed) [3.20190918.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-dock-applet [source] (eoan-proposed) [19.10.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: simplestreams (xenial-proposed/main) [0.1.0~bzr426-0ubuntu1.2 => 0.1.0~bzr426-0ubuntu1.4] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ess (eoan-proposed/universe) [18.10.2-1 => 18.10.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted casper [source] (eoan-proposed) [1.422]
-queuebot:#ubuntu-release- Unapproved: accepted doxygen [source] (eoan-proposed) [1.8.13-10ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted ess [source] (eoan-proposed) [18.10.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted budgie-desktop-environment [source] (eoan-proposed) [0.12.3]
-queuebot:#ubuntu-release- Unapproved: accepted heat [source] (eoan-proposed) [1:13.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted budgie-desktop [source] (eoan-proposed) [10.5-0ubuntu6]
-queuebot:#ubuntu-release- Unapproved: accepted sahara [source] (eoan-proposed) [1:11.0.0~rc1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted barbican [source] (eoan-proposed) [1:9.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: expeyes-doc (eoan-proposed/universe) [4.3-1 => 4.3-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity-slideshow-ubuntu [source] (eoan-proposed) [149]
-queuebot:#ubuntu-release- Unapproved: accepted expeyes-doc [source] (eoan-proposed) [4.3-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted latte-dock [source] (eoan-proposed) [0.9.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gap-grape (eoan-proposed/universe) [4.8.2+ds-1 => 4.8.2+ds-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gap-grape [source] (eoan-proposed) [4.8.2+ds-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: grub2 (eoan-proposed/main) [2.04-1ubuntu7 => 2.04-1ubuntu8] (core)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (eoan-proposed/main) [1.123 => 1.124] (core)
-queuebot:#ubuntu-release- Unapproved: gap-sonata (eoan-proposed/universe) [2.9.1+ds-2 => 2.9.1+ds-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gap-sonata [source] (eoan-proposed) [2.9.1+ds-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (eoan-proposed) [0.8.1-1ubuntu12]
-queuebot:#ubuntu-release- Unapproved: accepted thunderbird [source] (eoan-proposed) [1:68.1.1+build1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gawk-doc (eoan-proposed/universe) [4.2.1-1 => 4.2.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gawk-doc [source] (eoan-proposed) [4.2.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: geomview (eoan-proposed/universe) [1.9.5-2 => 1.9.5-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted geomview [source] (eoan-proposed) [1.9.5-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: getdp (eoan-proposed/universe) [3.0.4+dfsg1-1build1 => 3.0.4+dfsg1-1ubuntu1] (no packageset)
<vorlon> cyphermox: grub2 2.04-1ubuntu8: not practically reviewable as a debdiff, includes no bug references, there is no explanation of what piece was being done /wrong/ with the current version, and AFAIK there are no tests for any of this.  ++verbose?
-queuebot:#ubuntu-release- Unapproved: accepted getdp [source] (eoan-proposed) [3.0.4+dfsg1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gitmagic (eoan-proposed/universe) [20160304-1 => 20160304-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted kstars [source] (eoan-proposed) [5:3.3.6-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gitmagic [source] (eoan-proposed) [20160304-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gnu-standards (eoan-proposed/main) [2010.03.11-1 => 2010.03.11-1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: gnutls28 (eoan-proposed/main) [3.6.9-5 => 3.6.9-5ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: goldencheetah (eoan-proposed/universe) [1:3.5~DEV1810-1 => 1:3.5~DEV1810-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted goldencheetah [source] (eoan-proposed) [1:3.5~DEV1810-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gri (eoan-proposed/universe) [2.12.26-1build2 => 2.12.26-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gri [source] (eoan-proposed) [2.12.26-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gsl-doc (eoan-proposed/multiverse) [2.3-1 => 2.3-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gsl-doc [source] (eoan-proposed) [2.3-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: linux (eoan-proposed/main) [5.3.0-13.14 => 5.3.0-16.17] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta (eoan-proposed/main) [5.3.0.13.14 => 5.3.0.16.18] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-restricted-modules (eoan-proposed/restricted) [5.3.0-13.14 => 5.3.0-16.17] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed (eoan-proposed/main) [5.3.0-13.14 => 5.3.0-16.17] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: haskell98-tutorial (eoan-proposed/universe) [200006-2-2build1 => 200006-2-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted haskell98-tutorial [source] (eoan-proposed) [200006-2-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: linux-meta-kvm (eoan-proposed/main) [5.0.0.1015.15 => 5.3.0.1002.2] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-kvm (eoan-proposed/main) [5.0.0-1015.16 => 5.3.0-1002.2] (core, kernel) (sync)
<cyphermox> vorlon: this is more of the issue with grub being installed instead of shim to /efi/boot and /efi/ubuntu, or the missing mmx64.efi on ESP that I fixed for beta
-queuebot:#ubuntu-release- Unapproved: jags (eoan-proposed/universe) [4.3.0-2build1 => 4.3.0-2ubuntu1] (no packageset)
<cyphermox> the patch was completely mismerged; I fixed it to put it back to the right state (how it was in disco); and renamed the patch accordingly so in the future this does not happen
-queuebot:#ubuntu-release- Unapproved: accepted jags [source] (eoan-proposed) [4.3.0-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: khronos-api (eoan-proposed/universe) [4.6+git20180514-1 => 4.6+git20180514-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted khronos-api [source] (eoan-proposed) [4.6+git20180514-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libforms (eoan-proposed/universe) [1.2.3-1.3 => 1.2.3-1.3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted libforms [source] (eoan-proposed) [1.2.3-1.3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libgcrypt20 (eoan-proposed/main) [1.8.4-5ubuntu1 => 1.8.4-5ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: lilypond (eoan-proposed/universe) [2.19.81+really-2.18.2-13 => 2.19.81+really-2.18.2-13ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted lilypond [source] (eoan-proposed) [2.19.81+really-2.18.2-13ubuntu1]
-queuebot:#ubuntu-release- Unapproved: mathgl (eoan-proposed/universe) [2.4.4-3 => 2.4.4-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted mathgl [source] (eoan-proposed) [2.4.4-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: mh-e (eoan-proposed/universe) [8.5-2.1 => 8.5-2.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted mh-e [source] (eoan-proposed) [8.5-2.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnu-standards [source] (eoan-proposed) [2010.03.11-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: moon-buggy (eoan-proposed/universe) [1:1.0.51-12 => 1:1.0.51-12ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted moon-buggy [source] (eoan-proposed) [1:1.0.51-12ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnutls28 [source] (eoan-proposed) [3.6.9-5ubuntu1]
-queuebot:#ubuntu-release- Unapproved: nbconvert (eoan-proposed/universe) [5.4-2ubuntu1 => 5.4-2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted libgcrypt20 [source] (eoan-proposed) [1.8.4-5ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted nbconvert [source] (eoan-proposed) [5.4-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: ngspice (eoan-proposed/universe) [30.2-1 => 30.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ngspice [source] (eoan-proposed) [30.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: nordugrid-arc-doc (eoan-proposed/universe) [2.0.21-1 => 2.0.21-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted nordugrid-arc-doc [source] (eoan-proposed) [2.0.21-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: octave (eoan-proposed/universe) [4.4.1-6build1 => 4.4.1-6ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted octave [source] (eoan-proposed) [4.4.1-6ubuntu1]
-queuebot:#ubuntu-release- Unapproved: proofgeneral (eoan-proposed/universe) [4.4.1~pre170114-1.1 => 4.4.1~pre170114-1.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted proofgeneral [source] (eoan-proposed) [4.4.1~pre170114-1.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: pspp (eoan-proposed/universe) [1.2.0-2ubuntu1 => 1.2.0-2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pspp [source] (eoan-proposed) [1.2.0-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: pycode-browser (eoan-proposed/universe) [1:1.02+git20181006-3 => 1:1.02+git20181006-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pycode-browser [source] (eoan-proposed) [1:1.02+git20181006-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: dnsdist (eoan-proposed/universe) [1.4.0~rc2-1 => 1.4.0~rc3-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: xfce4-mpc-plugin (eoan-proposed/universe) [0.5.1-1 => 0.5.2-1] (xubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: sbcl (eoan-proposed/universe) [2:1.5.5-2 => 2:1.5.5-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted dnsdist [sync] (eoan-proposed) [1.4.0~rc3-1]
-queuebot:#ubuntu-release- Unapproved: accepted sbcl [source] (eoan-proposed) [2:1.5.5-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: sdcc (eoan-proposed/universe) [3.8.0+dfsg-2build1 => 3.8.0+dfsg-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted sdcc [source] (eoan-proposed) [3.8.0+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-kvm [sync] (eoan-proposed) [5.3.0.1002.2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-restricted-modules [sync] (eoan-proposed) [5.3.0-16.17]
-queuebot:#ubuntu-release- Unapproved: accepted linux [sync] (eoan-proposed) [5.3.0-16.17]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta [sync] (eoan-proposed) [5.3.0.16.18]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed [sync] (eoan-proposed) [5.3.0-16.17]
-queuebot:#ubuntu-release- Unapproved: sgf2dg (eoan-proposed/universe) [4.026-10build1 => 4.026-10ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted sgf2dg [source] (eoan-proposed) [4.026-10ubuntu1]
-queuebot:#ubuntu-release- Unapproved: slime (eoan-proposed/universe) [2:2.24+dfsg-1 => 2:2.24+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (disco-proposed) [5.0.0-31.33]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (disco-proposed) [5.0.0-31.33]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (disco-proposed) [5.0.0-31.33]
-queuebot:#ubuntu-release- Unapproved: accepted slime [source] (eoan-proposed) [2:2.24+dfsg-1ubuntu1]
<vorlon> doko: binutils + binutils-mipsen have now migrated and NBS has been cleaned up, but the autopkgtests still fail; this suggests to me there's still some wrong metadata in debian/control for one or both packages
-queuebot:#ubuntu-release- Unapproved: splash (eoan-proposed/universe) [2.9.0-1 => 2.9.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted splash [source] (eoan-proposed) [2.9.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: stealth (eoan-proposed/universe) [4.02.00-1 => 4.02.00-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted stealth [source] (eoan-proposed) [4.02.00-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: xnee (eoan-proposed/universe) [3.19-3 => 3.19-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted xnee [source] (eoan-proposed) [3.19-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: yodl (eoan-proposed/universe) [4.02.01-2 => 4.02.01-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted yodl [source] (eoan-proposed) [4.02.01-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: yosys (eoan-proposed/universe) [0.8-1build1 => 0.8-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted yosys [source] (eoan-proposed) [0.8-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: owncloud-client (eoan-proposed/universe) [2.5.1.10973+dfsg-1ubuntu1 => 2.5.1.10973+dfsg-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted owncloud-client [source] (eoan-proposed) [2.5.1.10973+dfsg-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: python-networkx (eoan-proposed/main) [2.2-1ubuntu3 => 2.2-1ubuntu4] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted linux-kvm [sync] (eoan-proposed) [5.3.0-1002.2]
-queuebot:#ubuntu-release- Unapproved: python-pymzml (eoan-proposed/universe) [0.7.6-dfsg-5ubuntu3 => 0.7.6-dfsg-5ubuntu4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-pymzml [source] (eoan-proposed) [0.7.6-dfsg-5ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (eoan-proposed) [1.124]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (eoan-proposed) [2.04-1ubuntu8]
-queuebot:#ubuntu-release- Unapproved: grub2 (eoan-proposed/main) [2.04-1ubuntu8 => 2.04-1ubuntu8] (core)
<vorlon> convert: attempt to perform an operation not allowed by the security policy `PS'
<vorlon>  @ error/constitute.c/IsCoderAuthorized/408.
<vorlon> LocutusOfBorg: ^^ is that LP: #1839596?
<ubot5> Launchpad bug 1839596 in imagemagick (Ubuntu Eoan) "imagemagick 8:6.9.10.23+dfsg-2.1ubuntu3 broke reverse-deps" [Critical,Won't fix] https://launchpad.net/bugs/1839596
<vorlon> looks like it is
<vorlon> LocutusOfBorg: so a better question, is there a template for how to fix packages for this?
-queuebot:#ubuntu-release- New binary: linux-signed-gke-5.0 [amd64] (bionic-proposed/universe) [5.0.0-1020.20~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (eoan-proposed/main) [5.3.0-16.17] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (eoan-proposed/main) [5.3.0-16.17] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (disco-proposed/main) [5.0.0-1022.23] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (eoan-proposed/main) [5.3.0-16.17] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (eoan-proposed/main) [5.3.0-16.17] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (eoan-proposed) [5.3.0-16.17]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (eoan-proposed) [5.3.0-16.17]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (disco-proposed/main) [5.0.0-1020.20] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (eoan-proposed) [5.3.0-16.17]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (eoan-proposed) [5.3.0-16.17]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (disco-proposed) [5.0.0-1022.23]
-queuebot:#ubuntu-release- Unapproved: coinor-dylp (eoan-proposed/universe) [1.6.0-1.1ubuntu2 => 1.6.0-1.1ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted coinor-dylp [source] (eoan-proposed) [1.6.0-1.1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: grub2 (eoan-proposed/main) [2.04-1ubuntu8 => 2.04-1ubuntu8] (core)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (disco-proposed) [5.0.0-1020.20]
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.0 [amd64] (bionic-proposed) [5.0.0-1020.20~18.04.1]
-queuebot:#ubuntu-release- Unapproved: stress-ng (eoan-proposed/universe) [0.10.06-1 => 0.10.07-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted stress-ng [sync] (eoan-proposed) [0.10.07-1]
<vorlon> jbicha: why are python-xapp + xapp syncs appropriate?  both are seeded in budgie, python3-xapp is also seeded in mate
<vorlon> jbicha: seems you have quite a few syncs that you might want to elaborate on for the release team to review
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (eoan-proposed) [2.04-1ubuntu8]
-queuebot:#ubuntu-release- Unapproved: accepted python-networkx [source] (eoan-proposed) [2.2-1ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (eoan-proposed) [2.04-1ubuntu8]
#ubuntu-release 2019-10-02
<jbicha> vorlon: I didn't realize Cinnamon stuff was seeded until after I synced
<jbicha> if you're going to reject them, I suggest killing the Cinnamon stuff stuck in eoan-proposed too
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-disconnect-wifi (eoan-proposed/universe) [20.0.3.30-1 => 21-1~exp1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-disconnect-wifi [sync] (eoan-proposed) [21-1~exp1]
-queuebot:#ubuntu-release- Unapproved: openjdk-8 (eoan-proposed/universe) [8u232-b07-1 => 8u232-b07-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-8 [sync] (eoan-proposed) [8u232-b07-2]
<vorlon> jbicha: well I'm not currently planning to reject them, but I'm also not planning to accept them without more info
-queuebot:#ubuntu-release- Unapproved: python3.8 (eoan-proposed/universe) [3.8.0~b4-1 => 3.8.0~rc1-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python3.8 [source] (eoan-proposed) [3.8.0~rc1-1]
-queuebot:#ubuntu-release- Unapproved: python3.7 (eoan-proposed/main) [3.7.4-4 => 3.7.5~rc1-1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted python3.7 [source] (eoan-proposed) [3.7.5~rc1-1]
-queuebot:#ubuntu-release- Unapproved: python3-stdlib-extensions (eoan-proposed/main) [3.7.4-3 => 3.7.5~rc1-1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted python3-stdlib-extensions [source] (eoan-proposed) [3.7.5~rc1-1]
<ginggs> would someone please 'force-badtest deepnano/0.0+git20170813.e8a621e-3/amd64' ?  it seems to have not timed out only once there
<ginggs> also, please lp: #1846193 - together should unblock h5py
<ubot5> Launchpad bug 1846193 in xmds2 (Ubuntu) "Please remove src:xmds2 from eoan" [Undecided,New] https://launchpad.net/bugs/1846193
-queuebot:#ubuntu-release- Unapproved: gcc-7 (eoan-proposed/universe) [7.4.0-12ubuntu2 => 7.4.0-14ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: gcc-8 (eoan-proposed/universe) [8.3.0-22ubuntu2 => 8.3.0-23ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-7 [source] (eoan-proposed) [7.4.0-14ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-8 [source] (eoan-proposed) [8.3.0-23ubuntu1]
<vorlon> doko: yes, binutils debian/control lists various mips* packages that are not actually built from this source, which causes confusion and delay https://paste.ubuntu.com/p/XDcC2tJcQ6/
<vorlon> didrocks: apparently your grub changes break the grubzfs-testsuite autopkgtests
<doko> vorlon: ok, forgot to regenerate the control file
<doko> will upload later
<doko> vorlon: no, wrong. these are native packages
<doko> and the architecture settings are correct
<didrocks> vorlon: ah, interesting, because I did regenerate it before the new grub from a build in a ppa. I'll have a look. Thanks for the head's up
<LocutusOfBorg> vorlon, I guess not, probably "stop using imagemagick" is the template security team has in mind
-queuebot:#ubuntu-release- Unapproved: sahara (eoan-proposed/universe) [1:11.0.0~rc1-0ubuntu2 => 1:11.0.0~rc1-0ubuntu3] (openstack)
-queuebot:#ubuntu-release- Unapproved: python-json-patch (eoan-proposed/main) [1.23-2ubuntu1 => 1.23-3] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: senlin (eoan-proposed/universe) [8.0.0~rc1-0ubuntu1 => 8.0.0~rc1-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted senlin [source] (eoan-proposed) [8.0.0~rc1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: debootstrap (eoan-proposed/main) [1.0.115ubuntu1 => 1.0.116ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: python-taskflow (eoan-proposed/main) [3.7.1-0ubuntu1 => 3.7.1-0ubuntu2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-osprofiler (eoan-proposed/main) [2.8.2-0ubuntu1 => 2.8.2-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: mypy (eoan-proposed/universe) [0.720-2 => 0.720-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (bionic-proposed) [1:2.11+dfsg-1ubuntu7.19]
-queuebot:#ubuntu-release- Unapproved: accepted mypy [sync] (eoan-proposed) [0.720-3]
-queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (bionic-proposed) [19.0.8-0ubuntu0~18.04.3]
-queuebot:#ubuntu-release- Unapproved: mesa (eoan-proposed/main) [19.2.0-1ubuntu1 => 19.2.0-1ubuntu2] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: rejected pulseaudio [source] (bionic-proposed) [1:11.1-1ubuntu7.4]
-queuebot:#ubuntu-release- Unapproved: guile-2.0 (eoan-proposed/universe) [2.0.13+1-5.2ubuntu1 => 2.0.13+1-5.3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted guile-2.0 [source] (eoan-proposed) [2.0.13+1-5.3ubuntu1]
<jamespage> hi release team - the python-taskflow and python-osprofiler uploads in unapproved resolve some py2 support drop issues that where masked earlier in cycle
<jamespage> ditto on sahara if that could be accepted - oddness with armhf autopkgtest env not having curl
-queuebot:#ubuntu-release- Unapproved: python-tenacity (eoan-proposed/main) [5.1.1-0ubuntu1 => 5.1.1-0ubuntu2] (ubuntu-server)
<jamespage> ^^ has a fix for a py2 compat issue which was accidentally dropped in an earlier upload
<jamespage> apw or Laney - any chance you could ack my requests above? proposed migration for the openstack package set is a bit of a car crash so unpicking things
<Laney> jamespage: aye, I'll be reviewing the queue later on today
<Laney> (happy to be beaten by apw)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (eoan-proposed/main) [1.124 => 1.125] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (eoan-proposed/main) [2.04-1ubuntu8 => 2.04-1ubuntu9] (core)
-queuebot:#ubuntu-release- Unapproved: grubzfs-testsuite (eoan-proposed/universe) [0.4.2 => 0.4.3] (no packageset)
<didrocks> FYI, grub2/grub2-signed/grubzfs-testsuite stack should unblock grub2 in proposed ^
-queuebot:#ubuntu-release- Unapproved: accepted grubzfs-testsuite [source] (eoan-proposed) [0.4.3]
-queuebot:#ubuntu-release- Unapproved: accepted python-taskflow [source] (eoan-proposed) [3.7.1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted python-osprofiler [source] (eoan-proposed) [2.8.2-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted sahara [source] (eoan-proposed) [1:11.0.0~rc1-0ubuntu3]
<apw> jamespage, ^
<jamespage> apw: thankyou!
-queuebot:#ubuntu-release- Unapproved: accepted python-tenacity [source] (eoan-proposed) [5.1.1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: youtube-dl (eoan-proposed/universe) [2019.09.12.1-0ubuntu1 => 2019.09.28-1] (ubuntu-budgie, ubuntukylin) (sync)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [5.0.0-1022.23~18.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [5.0.0-1022.23~18.04.1]
-queuebot:#ubuntu-release- Unapproved: haskell98-tutorial (eoan-proposed/universe) [200006-2-2ubuntu1 => 200006-2-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: rejected haskell98-tutorial [sync] (eoan-proposed) [200006-2-3]
<LocutusOfBorg> vorlon, funnily, I knew xnee was a problematic package https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/amsn/+packages
<LocutusOfBorg> unfortunately I didn't have yet time to look to all the logs, and post a summary of what is failing and why
<Laney> infinity: remind me what happened to the new strace?
<Laney> I can't remember how we got <mumble> thing migrated
<ginggs> would an archive admin look at LP: #1843387 please?
<ubot5> Launchpad bug 1843387 in samtools (Ubuntu) "samtools: please remove i386 binary, already gone in Debian" [Undecided,New] https://launchpad.net/bugs/1843387
<ginggs> also LP: #1828409
<ubot5> Launchpad bug 1828409 in htslib (Ubuntu) "please remove htslib on i386" [Undecided,Won't fix] https://launchpad.net/bugs/1828409
-queuebot:#ubuntu-release- Unapproved: python3-defaults (eoan-proposed/main) [3.7.3-1 => 3.7.5-1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted python3-defaults [source] (eoan-proposed) [3.7.5-1]
<Laney> fast review on that one...
<doko> just a version bump, no-change upload
<ginggs> also LP: #1846350
<ubot5> Launchpad bug 1846350 in umis (Ubuntu) "Please remove umis on armhf, i386 and s390x" [Undecided,New] https://launchpad.net/bugs/1846350
-queuebot:#ubuntu-release- Unapproved: proteinortho (eoan-proposed/universe) [6.0.6+dfsg-1 => 6.0.8+dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted proteinortho [sync] (eoan-proposed) [6.0.8+dfsg-1]
<ginggs> and lastly LP: #1846352
<ubot5> Launchpad bug 1846352 in diamond-aligner (Ubuntu) "Please remove diamond-aligner everywhere except amd64" [Undecided,New] https://launchpad.net/bugs/1846352
-queuebot:#ubuntu-release- Unapproved: glance (eoan-proposed/main) [2:19.0.0~b2~git2019073017.733095a8-0ubuntu1 => 2:19.0.0~rc1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: masakari (eoan-proposed/universe) [8.0.0~b2~git2019073018.204fa9c-0ubuntu1 => 8.0.0~rc1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted masakari [source] (eoan-proposed) [8.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: base-files (disco-proposed/main) [10.1ubuntu9.1 => 10.1ubuntu9.2] (core)
-queuebot:#ubuntu-release- Unapproved: base-files (bionic-proposed/main) [10.1ubuntu2.6 => 10.1ubuntu2.7] (core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (xenial-proposed/main) [1:16.04.26 => 1:16.04.27] (core)
-queuebot:#ubuntu-release- Unapproved: base-files (xenial-proposed/main) [9.4ubuntu4.10 => 9.4ubuntu4.11] (core)
-queuebot:#ubuntu-release- Unapproved: fwupd-signed (eoan-proposed/main) [1.9 => 1.10] (core)
<LocutusOfBorg> ^^ this should make fwupd migrate
-queuebot:#ubuntu-release- Unapproved: nova (eoan-proposed/main) [2:20.0.0~b1~git2019061016.1316c1c285-0ubuntu4 => 2:20.0.0~rc1-0ubuntu1] (openstack, ubuntu-server)
<vorlon> doko: so those binutils-mips* packages do get built from binutils source on mips* architectures if we had them?  hmm, that is going to be hard for autopkgtest to figure out
<ogra> just quickly bootstrap mips ...
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-66.75] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (bionic-proposed/main) [5.0.0-31.33~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-66.75] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (bionic-proposed/main) [5.0.0-31.33~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [arm64] (bionic-proposed/main) [5.0.0-31.33~18.04.1] (kernel)
<doko> vorlon: yes, and that will repeat with gcc-* when the gcc-for-build/gcc-for-host changes go in there as well
<vorlon> doko: ok well I can try to find time to work on the autopkgtest changes, but just in general, having the same binary package referenced in debian/control of multiple source packages, over the long term, causes archive confusion
<vorlon> there are a variety of reports that don't know how to handle this case
<doko> vorlon: I mean I can work around that by removing the "native" packages for architectures which we don't build. but probably not anymore for 19.10
<doko> or just remove the mips* stuff
-queuebot:#ubuntu-release- Unapproved: haskell-aeson (eoan-proposed/universe) [1.4.2.0-4 => 1.4.2.0-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted haskell-aeson [sync] (eoan-proposed) [1.4.2.0-5]
-queuebot:#ubuntu-release- Unapproved: systemd (eoan-proposed/main) [242-6ubuntu1 => 242-7ubuntu1] (core)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (bionic-proposed) [5.0.0-31.33~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (bionic-proposed) [5.0.0-31.33~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-66.75]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [arm64] (bionic-proposed) [5.0.0-31.33~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-66.75]
<infinity> Laney: Oops, new strace didn't happen cause I lost track of that brain card while waiting for upstream to release (which he has now).
<infinity> Laney: And I've entirely forgotten which package it was that showed off the bug.
<Laney> ostree
<Laney> Looks like it got badtested so I wasn't getting the nag emails from proposed-migration
<infinity> Lemme see about rolling that fresh strace sometime today.  I don't look forward to battling upstream's testsuite, which never seems to quite work.
<infinity> Although, it somehow passed in that snapshot build I did for you, so maybe there's hope
<Laney> Would be nice if it just slid right in
<Laney> Ta
<infinity> That's what she said?
-queuebot:#ubuntu-release- Unapproved: accepted cinnamon-desktop [sync] (eoan-proposed) [4.0.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted python-xapp [sync] (eoan-proposed) [1.6.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted cinnamon-translations [sync] (eoan-proposed) [4.0.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted xapp [sync] (eoan-proposed) [1.4.9-1]
-queuebot:#ubuntu-release- Unapproved: accepted nemo [sync] (eoan-proposed) [4.0.6-1]
-queuebot:#ubuntu-release- Unapproved: openexr (eoan-proposed/main) [2.2.1-4.1 => 2.2.1-4.1ubuntu1] (ubuntu-desktop)
<mdeslaur> could someone please reject openexr ^
<mdeslaur> I was premature in uploading it
<infinity> mdeslaur: Done.
<mdeslaur> infinity: ta
<infinity> Oh, lovely, the queue is giving me 4MB diffs of systemd against the 243 that was deleted.  Useful.
-queuebot:#ubuntu-release- Unapproved: rejected openexr [source] (eoan-proposed) [2.2.1-4.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (eoan-proposed) [242-7ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (eoan-proposed) [1.0.116ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (eoan-proposed) [19.2.0-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: bind9 (bionic-proposed/main) [1:9.11.3+dfsg-1ubuntu1.9 => 1:9.11.3+dfsg-1ubuntu1.10] (core)
-queuebot:#ubuntu-release- Unapproved: accepted glance [source] (eoan-proposed) [2:19.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (eoan-proposed) [2:20.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: budgie-extras (eoan-proposed/universe) [0.10.1-0ubuntu2 => 0.10.1-0ubuntu3] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- Unapproved: mate-control-center (eoan-proposed/universe) [1.22.2-0ubuntu2 => 1.22.2-0ubuntu3] (ubuntu-mate)
<ddstreet> doko Laney the autopkgtest fix for binutils is just waiting for debian merging, do you need me to nag them to re-review and merge?  I'm not sure how urgent it is to get it working in autopkgtest.u.c
-queuebot:#ubuntu-release- Unapproved: accepted budgie-extras [source] (eoan-proposed) [0.10.1-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted mate-control-center [source] (eoan-proposed) [1.22.2-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: tzdata (eoan-proposed/main) [2019c-1 => 2019c-3] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: firefox (eoan-proposed/main) [69.0.1+build1-0ubuntu2 => 69.0.2+build1-0ubuntu1] (mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: tzdata (bionic-proposed/main) [2019b-0ubuntu0.18.04 => 2019c-0ubuntu0.18.04] (core)
-queuebot:#ubuntu-release- Unapproved: tzdata (xenial-proposed/main) [2019b-0ubuntu0.16.04 => 2019c-0ubuntu0.16.04] (core)
-queuebot:#ubuntu-release- Unapproved: tzdata (disco-proposed/main) [2019b-0ubuntu0.19.04 => 2019c-0ubuntu0.19.04] (core)
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (bionic-proposed) [2019c-0ubuntu0.18.04]
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (xenial-proposed) [2019c-0ubuntu0.16.04]
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (disco-proposed) [2019c-0ubuntu0.19.04]
-queuebot:#ubuntu-release- Unapproved: geary (bionic-proposed/universe) [0.12.0-1ubuntu1 => 0.12.4-4~ubuntu18.04.3] (ubuntu-budgie)
#ubuntu-release 2019-10-03
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (eoan-proposed/main) [2.613 => 2.614] (desktop-core)
<vorlon> infinity: ^^ do you want to review this or should I self-accept?
-queuebot:#ubuntu-release- Unapproved: mistral (eoan-proposed/universe) [9.0.0~b2~git2019073018.c77eeb2d-0ubuntu1 => 9.0.0~rc1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted mistral [source] (eoan-proposed) [9.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (eoan-proposed) [2.614]
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [sync] (eoan-proposed) [2019c-3]
<infinity> vorlon: You probably could have self-accepted.
<infinity> vorlon: Will that actually be enough?  Will apt just select a package from another arch if the native arch doesn't have it?
<infinity> vorlon: I kinda assumed we'd need a bigger hammer to also install linux-image-virtual:amd64 explicitly.
<vorlon> infinity: yeah apt-get will automatically pick the package from the best available arch
<vorlon> infinity: mind you, you can't tell from the autopkgtest, since libc6-dev is currently uninstallable on i386
<infinity> vorlon: That would be fixed by un-NBSing linux in the release pocket.
<infinity> vorlon: Which I think I might do.  I assume we don't consider the one in proposed suitable for release anyway.
<vorlon> infinity: yeah, I think an un-NBSing is in order, I just wasn't sure what invocation would work
<infinity> vorlon: copy-package --from-suite=eoan --to-suite=eoan --force-same-destination --silent --auto-approve -b linux
<infinity> vorlon: Is what I just used.
<vorlon> ok, so un-NBSing all of it
<infinity> vorlon: With the caveat that if you copy a kernel over itself, you also need to reject the duplicate signing tarballs or the publisher poops itself.
 * vorlon nods
<infinity> https://launchpad.net/ubuntu/eoan/i386/linux-libc-dev
<infinity> Should come back in the run starting in a minute.
<infinity> vorlon: Oh, as to "un-NBSing all of it", there's no choice.  Copies are source package level.  You could go and delete everything but linux-libc-dev again if you felt the urge.
<vorlon> right
<infinity> (This is also why I have a fit when people delete binaries on arches without uploading something that stops producing them, because any copy in any direction will just make it poof back to life)
-queuebot:#ubuntu-release- Unapproved: libinput (eoan-proposed/main) [1.14.1-1 => 1.14.1-2] (desktop-core) (sync)
 * infinity decides to try to go sleep at a "normal" hour and see what that's all about.
<infinity> vorlon: It's fully published on ftpmaster, if your test doesn't use a mirror.
 * infinity goes.
<doko> vorlon: do we want to address all the py2 removal issues, where the packages are still referenced in autopkg tests? or ignore them?  triggered by the python3-defaults autopkg tests
-queuebot:#ubuntu-release- Unapproved: ruby-roadie (eoan-proposed/universe) [3.5.0-1 => 3.5.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ruby-roadie [sync] (eoan-proposed) [3.5.1-1]
<doko> Laney: any idea what makes so many packages uninstallable for i386 autipkg tests?
<doko> coreycb: nova needs a newer sqlalchemy
-queuebot:#ubuntu-release- Unapproved: commonmark-bkrs (eoan-proposed/universe) [0.5.4+ds-3 => 0.5.4+ds-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted commonmark-bkrs [source] (eoan-proposed) [0.5.4+ds-3ubuntu1]
<Laney> doko: I don't know off the top of my head, no
<Laney> is it reproducible in chdist or something?
<doko> Laney: would need to setup new env, and today is bank holiday ...
-queuebot:#ubuntu-release- Unapproved: docopt (eoan-proposed/universe) [0.6.2-2 => 0.6.2-2ubuntu1] (no packageset)
<LocutusOfBorg> doko, the i386 sadness is sorted as of log in this chat from two hours or so
<LocutusOfBorg> I'm rescheduling them
<Laney> I think libc6-dev was uninstallable but it's now fixed
<Laney> they should be rescheduled afaict
 * Laney points to LocutusOfBorg 
-queuebot:#ubuntu-release- Unapproved: accepted docopt [source] (eoan-proposed) [0.6.2-2ubuntu1]
<LocutusOfBorg> yes Laney I retried 4 tests, and they are now good, so I'm rescheduling them as we speak
-queuebot:#ubuntu-release- Unapproved: accepted libinput [sync] (eoan-proposed) [1.14.1-2]
<Laney> Gude
<LocutusOfBorg> I retried livecd-rootfs and haskell-aeson, and they have both migrated :)
<LocutusOfBorg> vorlon, your pathspider no change rebuild failed badly because of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906500
<ubot5> Debian bug 906500 in src:pathspider "pathspider: FTBFS in buster/sid (autobuilder hangs)" [Serious,Open]
<LocutusOfBorg> can we just kick it out from proposed too? it need a sourceful fix anyway, and I couldn't fix the issue
-queuebot:#ubuntu-release- Unapproved: emcee (eoan-proposed/universe) [2.2.1-2 => 2.2.1-2ubuntu1] (no packageset)
<LocutusOfBorg> having a package that hangs builders for 2.30 hours in the archive is a sad thing
-queuebot:#ubuntu-release- Unapproved: accepted emcee [source] (eoan-proposed) [2.2.1-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: jupyter-sphinx-theme (eoan-proposed/universe) [0.0.6+ds1-8 => 0.0.6+ds1-8ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted jupyter-sphinx-theme [source] (eoan-proposed) [0.0.6+ds1-8ubuntu1]
-queuebot:#ubuntu-release- Unapproved: oslo-sphinx (eoan-proposed/universe) [4.18.0-3 => 4.18.0-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted oslo-sphinx [sync] (eoan-proposed) [4.18.0-4]
-queuebot:#ubuntu-release- Unapproved: krita (eoan-proposed/universe) [1:4.2.6+dfsg-1 => 1:4.2.7.1+dfsg-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-amdgpu (eoan-proposed/main) [19.0.1-1 => 19.0.1-1ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: qtbase-opensource-src (eoan-proposed/universe) [5.12.4+dfsg-4build1 => 5.12.4+dfsg-4ubuntu1] (kubuntu, qt5)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-ati (eoan-proposed/main) [1:19.0.1-1 => 1:19.0.1-1ubuntu1] (desktop-core, xorg)
<RikMills> could some reject krita? need to fix changelog
<sil2100> RikMills: done
-queuebot:#ubuntu-release- Unapproved: rejected krita [source] (eoan-proposed) [1:4.2.7.1+dfsg-0ubuntu1]
<RikMills> thanks! and fixed version ^^^
<RikMills> umm coming
-queuebot:#ubuntu-release- Unapproved: krita (eoan-proposed/universe) [1:4.2.6+dfsg-1 => 1:4.2.7.1+dfsg-0ubuntu1] (kubuntu)
<RikMills> there ^
-queuebot:#ubuntu-release- Unapproved: python-csb (eoan-proposed/universe) [1.2.5+dfsg-4 => 1.2.5+dfsg-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-csb [source] (eoan-proposed) [1.2.5+dfsg-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-croniter (eoan-proposed/main) [0.3.29-2 => 0.3.29-2ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-debtcollector (eoan-proposed/main) [1.21.0-2 => 1.21.0-2ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted python-croniter [source] (eoan-proposed) [0.3.29-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-debtcollector [source] (eoan-proposed) [1.21.0-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-iptables (eoan-proposed/universe) [0.13.0-2 => 0.14.0~ds-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-iptables [sync] (eoan-proposed) [0.14.0~ds-1]
-queuebot:#ubuntu-release- Unapproved: xfce4-panel (eoan-proposed/universe) [4.14.0-1 => 4.14.1-0ubuntu1] (mythbuntu, ubuntustudio, xubuntu)
-queuebot:#ubuntu-release- Unapproved: python-iptables (eoan-proposed/universe) [0.14.0~ds-1 => 0.14.0~ds-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-iptables [source] (eoan-proposed) [0.14.0~ds-1ubuntu1]
<ddstreet> Laney debian/master autopkgtest has the fix for lp #1845157 if you want to upgrade autopkgtest.u.c
<ubot5> Launchpad bug 1845157 in autopkgtest (Debian) "runner/autopkgtest fails to setup env with binary packages moved to another packge, and different source/binary versions" [Unknown,New] https://launchpad.net/bugs/1845157
<Laney> yah
<Laney> iirc it also has the thing to drop haveged which I might need to revert for a little while
<ddstreet> yeah i believe it does have that as well
<Laney> fortunately IS just turned on virtio-rng for testing in one of the cloud regions
<Laney> so when we get new images tomorrow I can see if that works properly
-queuebot:#ubuntu-release- Unapproved: accepted anjuta [sync] (eoan-proposed) [2:3.34.0-2]
-queuebot:#ubuntu-release- Unapproved: accepted firefox [source] (eoan-proposed) [69.0.2+build1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-tetravex [sync] (eoan-proposed) [1:3.34.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted gnote [sync] (eoan-proposed) [3.34.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted graphicsmagick [sync] (eoan-proposed) [1.4+really1.3.33+hg16115-1]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (eoan-proposed) [2.04-1ubuntu9]
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice-dictionaries [sync] (eoan-proposed) [1:6.3.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted lightsoff [sync] (eoan-proposed) [1:3.34.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted qtbase-opensource-src [source] (eoan-proposed) [5.12.4+dfsg-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted xfce4-mpc-plugin [sync] (eoan-proposed) [0.5.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted compiz [sync] (eoan-proposed) [1:0.9.14.0+19.10.20190918-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-weather [sync] (eoan-proposed) [3.34.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (eoan-proposed) [1.125]
-queuebot:#ubuntu-release- Unapproved: accepted libsigc++-2.0 [sync] (eoan-proposed) [2.10.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted tali [sync] (eoan-proposed) [1:3.32.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-amdgpu [source] (eoan-proposed) [19.0.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted youtube-dl [sync] (eoan-proposed) [2019.09.28-1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd-signed [source] (eoan-proposed) [1.10]
-queuebot:#ubuntu-release- Unapproved: accepted gtkmm3.0 [sync] (eoan-proposed) [3.24.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted xfce4-panel [source] (eoan-proposed) [4.14.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted graphene [sync] (eoan-proposed) [1.10.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-ati [source] (eoan-proposed) [1:19.0.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-json-patch [sync] (eoan-proposed) [1.23-3]
-queuebot:#ubuntu-release- Unapproved: accepted krita [source] (eoan-proposed) [1:4.2.7.1+dfsg-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: grub2 (eoan-proposed/main) [2.04-1ubuntu9 => 2.04-1ubuntu9] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (eoan-proposed/main) [2.04-1ubuntu9 => 2.04-1ubuntu9] (core)
-queuebot:#ubuntu-release- Unapproved: nemo-fileroller (eoan-proposed/universe) [3.8.0-2 => 4.0.0-1] (ubuntu-budgie) (sync)
-queuebot:#ubuntu-release- Unapproved: nemo-python (eoan-proposed/universe) [3.8.0-2 => 4.0.0-1] (ubuntu-budgie) (sync)
<tjaalton> LocutusOfBorg: llvm-9 doesn't build lldb-9 on s390x?
<LocutusOfBorg> correct
<tjaalton> because?
-queuebot:#ubuntu-release- Unapproved: muffin (eoan-proposed/universe) [4.0.7-1 => 4.0.7-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted muffin [source] (eoan-proposed) [4.0.7-1ubuntu1]
<LocutusOfBorg> LLDB_DISABLE_ARCHS := hurd-i386 ia64 powerpc powerpcspe ppc64 riscv64 s390x sparc64
<coreycb> doko: thanks i'll fix that. it should be ok as is but needs an override.
<tjaalton> LocutusOfBorg: ok, need to work around that in spirv-llvm-translator
<LocutusOfBorg> tjaalton, I found this: https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/commit/7138491dc052d46191e80f3c487e4a74157d7a04
<LocutusOfBorg> I can try a build to see if this is a BE issue or similar
<tjaalton> LocutusOfBorg: actually, the build error without lldb-9 is a bug in llvm-9 packaging itself, I guess
<tjaalton> https://pastebin.com/jBiWqG3T
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-166.195] (core, kernel)
<tjaalton>   * Move lit-cpuid from llvm-tools to lldb (wrong package)
<tjaalton> it's wrong again
<tjaalton> or still
<LocutusOfBorg> tjaalton, https://paste.ubuntu.com/p/Qrr6hnNNHR/
<LocutusOfBorg> this happened some days ago in debian--llvm
<LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+sourcepub/10586986/+listing-archive-extra
<LocutusOfBorg> this might work
<tjaalton> LocutusOfBorg: right, but the real fix is to drop lit-cpuid references from LLVMExports.cmake
<LocutusOfBorg> tjaalton, I don't want to do that... ping sylvestre please :)
<tjaalton> didn't he already say "yeah"? :)
<tjaalton> anyway, I'll msg him
<xnox> tjaalton:  not ported yet it seems, do we need to escalate that to IBM?
<tjaalton> xnox: the lldb thing? nah, best to fix llvm packaging so that llvm-9-dev doesn't require lit-cpuid
<tjaalton> maybe for longer therm
<tjaalton> *term
<xnox> ok
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-166.195]
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (eoan-proposed/main) [1:19.10.12 => 1:19.10.13] (core)
<rbalint> please merge this hint for systemd: https://code.launchpad.net/~rbalint/britney/autopkgtest-eoan-hints/+merge/373561
-queuebot:#ubuntu-release- Unapproved: nova (eoan-proposed/main) [2:20.0.0~rc1-0ubuntu1 => 2:20.0.0~rc1-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (disco-proposed) [10.1ubuntu9.2]
-queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (bionic-proposed) [10.1ubuntu2.7]
<tjaalton> LocutusOfBorg: 16:48 <Sylvestre> we have to fix it
<tjaalton> we'll see how :)
-queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (xenial-proposed) [9.4ubuntu4.11]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-66.75~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1061.66] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-66.75~16.04.1] (kernel)
<vorlon> doko: py2 removal and autopkgtests: we should ignore them if they've regressed in release, and any of these are candidates for fixing if people have time but this is also why I haven't been processing any more Debian py2 removals post-FF
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (eoan-proposed) [2.04-1ubuntu9]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (eoan-proposed) [2.04-1ubuntu9]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (eoan-proposed) [1:19.10.13]
<sil2100> vorlon: thank you!
<tsimonq2> infinity, vorlon: I don't suppose you'd mind if Lubuntu uploaded a new Calamares by EOD?
<tsimonq2> It's Lubuntu-only and we have testers standing by.
<tsimonq2> (There's a stop-gap anyway, just communicating about my intentions.)
-queuebot:#ubuntu-release- Unapproved: linux-aws (eoan-proposed/main) [5.0.0-1013.15 => 5.3.0-1002.2] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-aws (eoan-proposed/main) [5.0.0.1013.13 => 5.3.0.1002.2] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-gcp (eoan-proposed/main) [5.0.0-1015.15 => 5.3.0-1003.3] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-gcp (eoan-proposed/main) [5.0.0.1015.41 => 5.3.0.1003.3] (core, kernel) (sync)
<vorlon> LocutusOfBorg: pathspider hanging the buildds for 2h is only a problem if people are blindly trying to rebuild pathspider; but yes I agree it's removable
<vorlon> tsimonq2: no problbem
-queuebot:#ubuntu-release- Unapproved: linux-meta-raspi2 (eoan-proposed/universe) [5.3.0.1005.1 => 5.3.0.1006.2] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed-gcp (eoan-proposed/main) [5.0.0-1015.15 => 5.3.0-1003.3] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-raspi2 (eoan-proposed/universe) [5.3.0-1005.6 => 5.3.0-1006.7] (kernel) (sync)
<tsimonq2> vorlon: Thanks.
<LocutusOfBorg> vorlon, its a problem also for mass rebuilds on ppas and in general, but we are on the same page already, thanks for doing it!
-queuebot:#ubuntu-release- Unapproved: openexr (eoan-proposed/main) [2.2.1-4.1 => 2.2.1-4.1ubuntu1] (ubuntu-desktop)
<rbalint> vorlon, sil2100 could you please consider accepting those hints and let systemd in? https://code.launchpad.net/~rbalint/britney/autopkgtest-eoan-hints/+merge/373561
<rbalint> vorlon, sil2100 the linux hint can be reverted after that if you feel so
<LocutusOfBorg> tjaalton, I might have fixed it, https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+packages
<LocutusOfBorg> if it builds please have a test
<tjaalton> LocutusOfBorg: what should I be looking?
<tjaalton> ah, it's there now
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (xenial-proposed) [1:16.04.27]
<LocutusOfBorg> :)
<LocutusOfBorg> btw if you join #debian-llvm on oftc you can broadcast your requests or bugs more easily
<LocutusOfBorg> doko, do you have any clue about python-azure autopkgtests? looks like they can't handle proxy, and probably they weren't failing before because not run?
<LocutusOfBorg> they are holding also your python upload
<tjaalton> LocutusOfBorg: yeah, I'll try to remember next time
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (eoan-proposed) [2:20.0.0~rc1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted openexr [source] (eoan-proposed) [2.2.1-4.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted nemo-fileroller [sync] (eoan-proposed) [4.0.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted nemo-python [sync] (eoan-proposed) [4.0.0-1]
<infinity> apw: Are you handling all the 5.3 derivative kernels in the queue, or did you want someone else to have a look?
<apw> infinity: i have not looked at any as yet, you are welcome to look with a less jaundiced eye
-queuebot:#ubuntu-release- Unapproved: glance (eoan-proposed/main) [2:19.0.0~rc1-0ubuntu1 => 2:19.0.0~rc1-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1061.66]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-66.75~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-66.75~16.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-gke-4.15 [amd64] (bionic-proposed/main) [4.15.0-1046.49] (no packageset)
<vorlon> seb128: hi, your ruby-gnome demotion has broken screenruler installability
<vorlon> doko: hi, your removal of django-compat from eoan has broken django-background-tasks installability
<seb128> vorlon, thx, fixed by demoting that one as well ... do we have a report listing such issues?
<vorlon> yes
<vorlon> ;)
<infinity> vorlon: Oh, since you seem to also be working on uninst.txt, the libreoffice bug is investigated, filed, and Marcus said he'll upload for it tomorrow.
<vorlon> \o/
<vorlon> infinity: and the rust i386 stuff is a bit wibbly right now, I was trying to remove it at the same time Gianfranco was trying to fix it so we wound up with more uninstallables that I couldn't just wand away.  I have been deferring sorting those out until deciding whether to simply add these to the architecture exclude list in eoan
-queuebot:#ubuntu-release- Unapproved: cinnamon-desktop-environment (eoan-proposed/universe) [3.8 => 4.0] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted cinnamon-desktop-environment [sync] (eoan-proposed) [4.0]
#ubuntu-release 2019-10-04
-queuebot:#ubuntu-release- Packageset: Added rust-core-foundation to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-der-parser to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-im-rc to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-textwrap to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-tls-parser to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Unapproved: eweouz (eoan-proposed/universe) [0.12~ubuntu1 => 0.12] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted eweouz [sync] (eoan-proposed) [0.12]
-queuebot:#ubuntu-release- Unapproved: realmd (eoan-proposed/universe) [0.16.3-2 => 0.16.3-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted realmd [sync] (eoan-proposed) [0.16.3-3]
-queuebot:#ubuntu-release- Unapproved: debian-faq (eoan-proposed/universe) [8.1ubuntu1 => 10.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted debian-faq [sync] (eoan-proposed) [10.1]
-queuebot:#ubuntu-release- New binary: debian-faq [amd64] (eoan-proposed/universe) [10.1] (no packageset)
-queuebot:#ubuntu-release- Packageset: Added rust-backtrace to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-bindgen to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-cargo to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-clap to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-findshlibs to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-nettle-sys to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-packed-simd to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-sleef-sys to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-structopt to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-assert-cli to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-cargo-metadata to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-cbindgen to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-crates-io to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-error-chain to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-failure to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-fern to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-opener to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-parking-lot to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-parking-lot-core to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-pem to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-quick-xml to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-rustfix to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-sloppy-rfc4880 to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-syslog to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-which to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Unapproved: libreoffice (eoan-proposed/main) [1:6.3.2-0ubuntu1 => 1:6.3.2-0ubuntu2] (ubuntu-desktop)
<didrocks> marcustomlinson: here we go ^
<marcustomlinson> didrocks: :)
-queuebot:#ubuntu-release- Unapproved: python-acme (eoan-proposed/universe) [0.36.0-1ubuntu1 => 0.39.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-acme [sync] (eoan-proposed) [0.39.0-1]
-queuebot:#ubuntu-release- Unapproved: checkinstall (eoan-proposed/universe) [1.6.2-6ubuntu1 => 1.6.2+git20170426.d24a630-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted checkinstall [source] (eoan-proposed) [1.6.2+git20170426.d24a630-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: metview (eoan-proposed/universe) [5.6.1-3ubuntu2 => 5.6.1-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted metview [sync] (eoan-proposed) [5.6.1-5]
-queuebot:#ubuntu-release- Unapproved: spirv-llvm-translator (eoan-proposed/universe) [9.0.0-0ubuntu1 => 9.0.0-0ubuntu2] (no packageset)
<LocutusOfBorg> tjaalton, ^^
-queuebot:#ubuntu-release- Unapproved: accepted spirv-llvm-translator [source] (eoan-proposed) [9.0.0-0ubuntu2]
<LocutusOfBorg> it needs the llvm I just uploaded to build
-queuebot:#ubuntu-release- Unapproved: llvm-toolchain-9 (eoan-proposed/main) [1:9-1 => 1:9-1ubuntu1] (no packageset)
<LocutusOfBorg> (at least on s390x)
<tjaalton> you could've waited for me to upload it
<tjaalton> now my git branch is behind ;)
<LocutusOfBorg> it was a quick fix, and I had already tested it... and I think it will go back in sync soon, so I didn't bother to ask :)
<tjaalton> after eoan, yes
<tjaalton> debian NEW handling is super slow these days
<jamespage> hi release team - coreycb uploaded a fix for glance yesterday to resolve a mysql 8 compat issue, but I'd like to fix that in a more generic way
<jamespage> see https://bugs.launchpad.net/ubuntu/+source/sqlalchemy/+bug/1846548 for commentary
<ubot5> Launchpad bug 1846548 in glance (Ubuntu) "Glance manage db_sync fails with MySQL 8" [High,Triaged]
<jamespage> I'm testing glance with an updated sqla package this morning, but this feels like a better approach rather than playing whack-a-mole on individual issues
<LocutusOfBorg> please accept llvm-toolchain-9, thanks
-queuebot:#ubuntu-release- Unapproved: glance (eoan-proposed/main) [2:19.0.0~rc1-0ubuntu1 => 2:19.0.0~rc1-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: sqlalchemy (eoan-proposed/main) [1.2.18+ds1-2ubuntu1 => 1.2.18+ds1-2ubuntu2] (ubuntu-desktop, ubuntu-server)
<jamespage> ^^ those two uploads both relate to https://bugs.launchpad.net/ubuntu/+source/sqlalchemy/+bug/1846548
<ubot5> Launchpad bug 1846548 in sqlalchemy (Ubuntu) "sqlalchemy fails to autoquote reserved works with MySQL 8" [High,In progress]
<jamespage> one to fix it, the other to validate it all works
<jamespage> there may be another glance upload in the UNAPPROVED queue; my revision superceeds that version
<jamespage> thanks!
<rbalint> please consider accepting those hints and let systemd in to eoan https://code.launchpad.net/~rbalint/britney/autopkgtest-eoan-hints/+merge/373561
<rbalint> sil2100, apw Laney ^
-queuebot:#ubuntu-release- Unapproved: dkms (eoan-proposed/main) [2.7.1-4ubuntu1 => 2.7.1-4ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-4.15 [amd64] (bionic-proposed) [4.15.0-1046.49]
-queuebot:#ubuntu-release- Unapproved: tiff (eoan-proposed/main) [4.0.10+git190903-1 => 4.0.10+git191003-1] (core) (sync)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (disco-proposed/main) [5.0.0-1004.8] (core)
<Laney> rbalint: I'm working down a stack of tasks, be with you soon ;-)
<rbalint> Laney, thanks, i'm preparing a new upload to fix LP: #1846509 regression and i'd prefer having this one in first
<ubot5> Launchpad bug 1846509 in systemd (Ubuntu) "networkd doesn't take into account search domain received by DHCP" [Undecided,In progress] https://launchpad.net/bugs/1846509
<xnox> rbalint:  we also need to fixup DVE patch in bionic as proposed. I think it's still missing in bionic uploads.
<xnox> rbalint:  have you seen it, do you have the context what i am talking about?
<rbalint> xnox, LP: #1796501?
<ubot5> Launchpad bug 1796501 in systemd (Ubuntu Disco) "systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes" [Medium,In progress] https://launchpad.net/bugs/1796501
<rbalint> xnox, i thought you just made a typo when asking for a CVE fix which i did include
<rbalint> xnox, looking, but it was not picked as priority for this weeks
<rbalint> xnox, seems good, picking the patch
<xnox> rbalint:  DVE is DNS violation =)
<xnox> https://github.com/dns-violations/dns-violations
<rbalint> xnox, i got it, but we also talked about the CVE :-)
<xnox> rbalint:  which i have no idea about =)
<xnox> rbalint:  if you do, you do you and i don't want to hear about it =)
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (disco-proposed) [5.0.0-1004.8]
-queuebot:#ubuntu-release- Unapproved: linux-meta (eoan-proposed/main) [5.3.0.16.18 => 5.3.0.17.19] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed (eoan-proposed/main) [5.3.0-16.17 => 5.3.0-17.18] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-restricted-modules (eoan-proposed/restricted) [5.3.0-16.17 => 5.3.0-17.18] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux (eoan-proposed/main) [5.3.0-16.17 => 5.3.0-17.18] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-meta (eoan-proposed/universe) [1.253 => 1.254] (ubuntu-mate)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (disco-proposed/main) [5.0.0-1021.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (disco-proposed/main) [5.0.0-32.34] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1024.27] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (disco-proposed/main) [5.0.0-32.34] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (disco-proposed/main) [5.0.0-1023.24] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (disco-proposed/main) [5.0.0-32.34] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: ubiquity (eoan-proposed/main) [19.10.13 => 19.10.14] (core)
<Laney> I'm going to semi self accept that ubiquity
<Laney> it's been reviewed out of band
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (eoan-proposed) [19.10.14]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (disco-proposed) [5.0.0-1023.24]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (disco-proposed) [5.0.0-32.34]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (disco-proposed) [5.0.0-32.34]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (disco-proposed) [5.0.0-1021.21]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (disco-proposed) [5.0.0-32.34]
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (eoan-proposed/main) [1.436 => 1.437] (core)
<ddstreet> Laney i assume you haven't updated autopkgtest.u.c git just yet for the binutils failure?  just checking
-queuebot:#ubuntu-release- Unapproved: util-linux (xenial-proposed/main) [2.27.1-6ubuntu3.8 => 2.27.1-6ubuntu3.9] (core)
-queuebot:#ubuntu-release- Packageset: Added rust-bytecount to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-caps to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-encoding-rs to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-grep to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-grep-searcher to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-once-cell to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-pcap to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-rand to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-signal-hook to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-tokio to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-tokio-core to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-tokio-reactor to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-tokio-signal to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-tokio-tcp to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-tokio-udp to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-tokio-uds to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Unapproved: rust-assert-cli (eoan-proposed/universe) [0.6.3-2 => 0.6.3-2build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-backtrace (eoan-proposed/universe) [0.3.34-1 => 0.3.34-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-bindgen (eoan-proposed/universe) [0.47.0-1 => 0.47.0-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-caps (eoan-proposed/universe) [0.3.2-2 => 0.3.2-2build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-cargo (eoan-proposed/universe) [0.37.0-1 => 0.37.0-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-bytecount (eoan-proposed/universe) [0.5.1-1 => 0.5.1-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-cargo-metadata (eoan-proposed/universe) [0.6.4-1 => 0.6.4-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-cbindgen (eoan-proposed/universe) [0.9.0-1 => 0.9.0-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-clap (eoan-proposed/universe) [2.33.0-4 => 2.33.0-4build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-core-foundation (eoan-proposed/universe) [0.6.4-1 => 0.6.4-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-der-parser (eoan-proposed/universe) [2.0.0-1 => 2.0.0-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-error-chain (eoan-proposed/universe) [0.12.0-1 => 0.12.0-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-crates-io (eoan-proposed/universe) [0.25.0-2 => 0.25.0-2build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-failure (eoan-proposed/universe) [0.1.5-1 => 0.1.5-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-encoding-rs (eoan-proposed/universe) [0.8.17-1 => 0.8.17-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-fern (eoan-proposed/universe) [0.5.8-1 => 0.5.8-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-grep-searcher (eoan-proposed/universe) [0.1.6-1 => 0.1.6-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-im-rc (eoan-proposed/universe) [13.0.0-1 => 13.0.0-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-findshlibs (eoan-proposed/universe) [0.5.0-1 => 0.5.0-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-grep (eoan-proposed/universe) [0.2.4-1 => 0.2.4-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-nettle-sys (eoan-proposed/universe) [1.0.2-1 => 1.0.2-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-once-cell (eoan-proposed/universe) [0.1.8-3 => 0.1.8-3build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-nitrokey (eoan-proposed/universe) [0.3.4-1 => 0.3.4-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-opener (eoan-proposed/universe) [0.4.0-1 => 0.4.0-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-parking-lot-core (eoan-proposed/universe) [0.6.2-1 => 0.6.2-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-pcap (eoan-proposed/universe) [0.7.0-2 => 0.7.0-2build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-packed-simd (eoan-proposed/universe) [0.3.3-4 => 0.3.3-4build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-pem (eoan-proposed/universe) [0.6.1-1 => 0.6.1-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-parking-lot (eoan-proposed/universe) [0.7.1-1 => 0.7.1-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-rand (eoan-proposed/universe) [0.7.0-1 => 0.7.0-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-rustfix (eoan-proposed/universe) [0.4.5-1 => 0.4.5-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-sleef-sys (eoan-proposed/universe) [0.1.2-1 => 0.1.2-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-structopt (eoan-proposed/universe) [0.2.14-1 => 0.2.14-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-ripgrep (eoan-proposed/universe) [0.10.0-2 => 0.10.0-2build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-sloppy-rfc4880 (eoan-proposed/universe) [0.1.5-1 => 0.1.5-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-signal-hook (eoan-proposed/universe) [0.1.7-2 => 0.1.7-2build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-syslog (eoan-proposed/universe) [4.0.1-2 => 4.0.1-2build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-tls-parser (eoan-proposed/universe) [0.8.1-1 => 0.8.1-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-tokio-reactor (eoan-proposed/universe) [0.1.8-1 => 0.1.8-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-tokio-tcp (eoan-proposed/universe) [0.1.3-1 => 0.1.3-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-textwrap (eoan-proposed/universe) [0.11.0-1 => 0.11.0-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-tokio-signal (eoan-proposed/universe) [0.2.7-2 => 0.2.7-2build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-tokio-core (eoan-proposed/universe) [0.1.17-2 => 0.1.17-2build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-tokio (eoan-proposed/universe) [0.1.14-2 => 0.1.14-2build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-tokio-udp (eoan-proposed/universe) [0.1.3-2 => 0.1.3-2build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-which (eoan-proposed/universe) [2.0.1-1 => 2.0.1-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-tokio-uds (eoan-proposed/universe) [0.2.5-1 => 0.2.5-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Packageset: Added dumb-jump-el to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-nitrokey to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-ripgrep to i386-eoan-excludes in eoan
<Laney> ddstreet: switching to release stuff in 2 minutes, will do that then
<infinity> vorlon: I'm just going to blindly ignore all this rust stuff until you're done with it and it appears to have settled down.
<infinity> vorlon: (And I hope you intend to self-accept all those rebuilds)
<vorlon> infinity: does the auto-accept bot interact badly with the fact that these are now in a packageset?
<vorlon> anyway that should be the last of it related to the uninst cleanup
<Laney> any packageset inhibits auto-accept
<vorlon> yeah
<Laney> but there's a whitelist which you can put it in
<vorlon> where does that live?
<Laney> snakefruit
<Laney> it's not in VCS unfortunately
-queuebot:#ubuntu-release- Unapproved: accepted rust-assert-cli [source] (eoan-proposed) [0.6.3-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-bindgen [source] (eoan-proposed) [0.47.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-caps [source] (eoan-proposed) [0.3.2-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-cargo [source] (eoan-proposed) [0.37.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-clap [source] (eoan-proposed) [2.33.0-4build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-crates-io [source] (eoan-proposed) [0.25.0-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-encoding-rs [source] (eoan-proposed) [0.8.17-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-failure [source] (eoan-proposed) [0.1.5-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-findshlibs [source] (eoan-proposed) [0.5.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-backtrace [source] (eoan-proposed) [0.3.34-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-cargo-metadata [source] (eoan-proposed) [0.6.4-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-core-foundation [source] (eoan-proposed) [0.6.4-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-error-chain [source] (eoan-proposed) [0.12.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-grep [source] (eoan-proposed) [0.2.4-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-bytecount [source] (eoan-proposed) [0.5.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-der-parser [source] (eoan-proposed) [2.0.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-cbindgen [source] (eoan-proposed) [0.9.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-fern [source] (eoan-proposed) [0.5.8-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-grep-searcher [source] (eoan-proposed) [0.1.6-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-nettle-sys [source] (eoan-proposed) [1.0.2-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-once-cell [source] (eoan-proposed) [0.1.8-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-packed-simd [source] (eoan-proposed) [0.3.3-4build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-parking-lot [source] (eoan-proposed) [0.7.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-pem [source] (eoan-proposed) [0.6.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-ripgrep [source] (eoan-proposed) [0.10.0-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-signal-hook [source] (eoan-proposed) [0.1.7-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-sloppy-rfc4880 [source] (eoan-proposed) [0.1.5-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-syslog [source] (eoan-proposed) [4.0.1-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-im-rc [source] (eoan-proposed) [13.0.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-opener [source] (eoan-proposed) [0.4.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-pcap [source] (eoan-proposed) [0.7.0-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-rustfix [source] (eoan-proposed) [0.4.5-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-structopt [source] (eoan-proposed) [0.2.14-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-nitrokey [source] (eoan-proposed) [0.3.4-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-rand [source] (eoan-proposed) [0.7.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-textwrap [source] (eoan-proposed) [0.11.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-parking-lot-core [source] (eoan-proposed) [0.6.2-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-sleef-sys [source] (eoan-proposed) [0.1.2-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-tls-parser [source] (eoan-proposed) [0.8.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-tokio-reactor [source] (eoan-proposed) [0.1.8-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-tokio-core [source] (eoan-proposed) [0.1.17-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-tokio [source] (eoan-proposed) [0.1.14-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-tokio-signal [source] (eoan-proposed) [0.2.7-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-tokio-udp [source] (eoan-proposed) [0.1.3-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-which [source] (eoan-proposed) [2.0.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-tokio-tcp [source] (eoan-proposed) [0.1.3-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-tokio-uds [source] (eoan-proposed) [0.2.5-1build1]
<infinity> Laney, vorlon: It is so in VCS.  I moved it there eons ago.
<infinity> bzr+ssh://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-scripts/trunk/
<Laney> sorry for not ever committing any chances to the vcs then :P
<Laney> that'll be one I can't commit to anyway
-queuebot:#ubuntu-release- Unapproved: cloud-init (bionic-proposed/main) [19.2-36-g059d049c-0ubuntu1~18.04.1 => 19.2-36-g059d049c-0ubuntu2~18.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1024.27]
-queuebot:#ubuntu-release- Unapproved: cloud-init (eoan-proposed/main) [19.2-36-g059d049c-0ubuntu1 => 19.2-36-g059d049c-0ubuntu2] (core, edubuntu, ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: cloud-init (disco-proposed/main) [19.2-36-g059d049c-0ubuntu1~19.04.1 => 19.2-36-g059d049c-0ubuntu2~19.04.1] (core, edubuntu, ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: rejected glance [source] (eoan-proposed) [2:19.0.0~rc1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted sqlalchemy [source] (eoan-proposed) [1.2.18+ds1-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (eoan-proposed) [1.437]
-queuebot:#ubuntu-release- Unapproved: accepted glance [source] (eoan-proposed) [2:19.0.0~rc1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-meta [source] (eoan-proposed) [1.254]
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [19.2-36-g059d049c-0ubuntu1~16.04.1 => 19.2-36-g059d049c-0ubuntu2~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<Odd_Bloke> tjaalton: vorlon: o/ There are cloud-init updates in xenial forward that address a critical issue; please review and accept so we can start testing! :)
<infinity> rsync: failed to connect to appstream.internal (10.25.234.15): Connection refused (111)
<vorlon> https://launchpad.net/ubuntu/+source/rust-tokio-uds/0.2.5-1build1 whee that's the right set of architectures
<infinity> Laney: ^--- Did that all break again?
<vorlon> also apparently half these rust packages ftbfs again, so whatever
<Laney> infinity: Could have done, FML
<infinity> vorlon: Aren't they desperately sensitive to build order, like haskell?
<tjaalton> Odd_Bloke: it's Westvleteren-time here, maybe best for me to keep away from the queue ;)
<Laney> can you make that thing email me?
<infinity> Laney: Making the publisher email you could be less than trivial.
<vorlon> infinity: they should not be; haskell has ABI strings that are generated at build time, rust just has sourceful declarations of the interface levels
<Odd_Bloke> tjaalton: Looks like someone else got to it, thanks for replying! :)  Enjoy responsibly. ;)
<vorlon> i.e. nothing should change on a no-change rebuild
<vorlon> Odd_Bloke: who else got to it?
<Laney> should work now
<Odd_Bloke> Oh, no, I'm looking at the wrong thing.
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (eoan-proposed/main) [2.614 => 2.615] (desktop-core)
<Odd_Bloke> vorlon: Feel free to get to it. :)
<vorlon> Odd_Bloke: test case, regression potential on the SRU bug?
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (eoan-proposed) [2.615]
<Odd_Bloke> vorlon: Oh, right, I'm getting the order mixed up.
<Odd_Bloke> Apologies!
<vorlon> and apparently I'm not actually done with the rust removals after all because reverse-depends somehow keeps lying to me, whee
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (eoan-proposed) [1:6.3.2-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-9 [source] (eoan-proposed) [1:9-1ubuntu1]
 * infinity eyeballs ubuntu-archive@snakefruit's 1.4G MBOX and wonders when archive-reports suddenly got so verbose.
-queuebot:#ubuntu-release- Unapproved: accepted tiff [sync] (eoan-proposed) [4.0.10+git191003-1]
-queuebot:#ubuntu-release- Packageset: Added rust-cssparser-macros to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-encoding-rs-io to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-extprim to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-grcov to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-grep-printer to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-native-tls to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-petgraph to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-phf to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-phf-codegen to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-phf-generator to i386-eoan-excludes in eoan
<infinity> cyphermox: If you have a few minutes, could you help review the cloud-init in the eoan queue?  It seems like it would touch on your area of reluctant expertise. :)
-queuebot:#ubuntu-release- Packageset: Added rust-phf-macros to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-quickcheck to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-rusty-fork to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-string-cache-codegen to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-tempfile to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-tokio-fs to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Packageset: Added rust-tokio-threadpool to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Unapproved: openscap (bionic-proposed/universe) [1.2.15-1build1 => 1.2.15-1ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: openscap (xenial-proposed/universe) [1.2.8-1ubuntu0.1 => 1.2.8-1ubuntu0.2] (no packageset)
<Laney> ddstreet: do you have a binutils URL to hand to test your fix?
<Laney> pushing el button now
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1047.50] (kernel)
<Laney> well, I'm going to leave - get any core-dev to do it for you :-)
 * Laney eyes whoever put some weird hacks on the production machine
<Laney> they are being blown away
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1047.50]
<infinity> Laney: "Weird hacks on the production machine" was oddly non-specific.
-queuebot:#ubuntu-release- Unapproved: rust-cssparser-macros (eoan-proposed/universe) [0.3.6-1 => 0.3.6-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-encoding-rs-io (eoan-proposed/universe) [0.1.6-2 => 0.1.6-2build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-cssparser (eoan-proposed/universe) [0.25.9-1 => 0.25.9-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted rust-cssparser [source] (eoan-proposed) [0.25.9-1build1]
-queuebot:#ubuntu-release- Unapproved: rust-grcov (eoan-proposed/universe) [0.4.1-1 => 0.4.1-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-native-tls (eoan-proposed/universe) [0.2.3-1 => 0.2.3-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-phf-codegen (eoan-proposed/universe) [0.7.24-1 => 0.7.24-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-extprim (eoan-proposed/universe) [1.7.0-1 => 1.7.0-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-petgraph (eoan-proposed/universe) [0.4.13-2 => 0.4.13-2build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-grep-printer (eoan-proposed/universe) [0.1.3-1 => 0.1.3-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-phf (eoan-proposed/universe) [0.7.24-1 => 0.7.24-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-phf-generator (eoan-proposed/universe) [0.7.24-2 => 0.7.24-2build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-quickcheck (eoan-proposed/universe) [0.9.0-1 => 0.9.0-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-string-cache-codegen (eoan-proposed/universe) [0.4.2-2 => 0.4.2-2build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-tokio-fs (eoan-proposed/universe) [0.1.6-1 => 0.1.6-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-phf-macros (eoan-proposed/universe) [0.7.24-1 => 0.7.24-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-tempfile (eoan-proposed/universe) [3.1.0-1 => 3.1.0-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-rusty-fork (eoan-proposed/universe) [0.2.1-1 => 0.2.1-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: rust-tokio-threadpool (eoan-proposed/universe) [0.1.15-1 => 0.1.15-1build1] (i386-eoan-excludes)
<vorlon> Odd_Bloke: I see the bug description is updated, thanks, but still lacks a test case; I'd want to know how this is getting tested both for the regressed case and for the Azure(?) case to ensure we don't regress there, so that there's clarity about when this is ready to be released to -updates
<vorlon> infinity: verbose> when mwhudson did some work, although things seem to have gotten even more verbose than that and I don't know when/why
<infinity> vorlon: I quieted the wget, that'll help some.  There's also a local hack from $someone (you?) to echo "Germinate changed", etc.  That'll cause it to spam cron mail even on successful runs.
<vorlon> yeah that was probably me debugging
<infinity> It also seems to be giving checkpoints on britney steps, not sure where that's coming from.
<vorlon> probably lines up with when I was debugging cron.NBS falling over
 * infinity nods.
<vorlon> Laney: sooo are these your cowboyed changes to the whitelist in auto-accept on snakefruit?
<infinity> Those are probably his, yes.
<infinity> Since those packagesets still exist, but we no longer care about them blocking.
<infinity> We should probably delete the packagesets if we haven't already.
<infinity> But his hacks also provide you a useful POC for how to ignore your arch exclude packagesets.
<infinity> Since the old whitelist was only on seeds.
<infinity> Which is also likely obsolete.  We need to spend a few days unwinding all the touch and RTM junk from archive scripts.  It'll simplify a lot of them.
 * vorlon nods
<infinity> Maybe I can do that during downtime at the release sprint, so we're opening Farty Ferret with cleaned infra.
<infinity> s/cleaned/cleaner/
<cyphermox> infinity: ack; looking at cloud-init
<vorlon> infinity: we're past kernel freeze, what kind of review do we want/need on these kernels in the queue?  (Fixes linux-libc-dev being missing on i386, but I don't know what else)
<infinity> vorlon: I've been letting Andy handle those for the most part, but if he's busy, I'll have a poke.  But basically the same level of review we give SRUs.  Make sure changes in debian/ make sense, pay close attention to config changes, skim upstream code chages to see if you spot obvious crack slipping in, ship it.
<infinity> The latter step being a best-effort thing, and I don't expect anyone to ever live up to the one time I noticed a bit-flip in a file that found kamal's RAM failing. :P
<vorlon> :-)
<vorlon> blackboxsw: thanks for the test case writeup
<blackboxsw> vorlon: thanks, I thought I botched the description update and was rewriting it again
<vorlon> blackboxsw: how do we make sure this doesn't regress Azure?
<blackboxsw> ok glad I can click buttons
<blackboxsw> azure I was going to add that now to the test case.
<vorlon> ok
<blackboxsw> we can and will run the same manual azure validation (plus ec2 and oracle to be sure)
<blackboxsw> and openstack
<blackboxsw> adding those items now
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (disco-proposed) [19.2-36-g059d049c-0ubuntu2~19.04.1]
<cyphermox> infinity: cloud-init> the logic is mind-boggling; but the rationale is good. member interfaces will get the master's MAC (well, one of the MACs tends to be elected to be used by the master and then both members get /that/); and it makes sense to skip over these to avoid confusing cloud-init.
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (bionic-proposed) [19.2-36-g059d049c-0ubuntu2~18.04.1]
<cyphermox> ie. I was acking, if that wasn't obvious; the logic in the change just seems really hard to follow
<infinity> cyphermox: Ta.
 * cyphermox really leaving now
<infinity> Looks like Steve liked the same uploads for SRUs, so I'll call that a +2 and accept for eoan. :P
<cyphermox> yup
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (eoan-proposed) [19.2-36-g059d049c-0ubuntu2]
<infinity> Odd_Bloke: Please exercise the poop out of eoan specifically with these changes (and any future changes before release), since we can't just stall the update like we can for an SRU, this *will* end up in the release in 2 weeks.
<blackboxsw> vorlon: thanks, ok cloud-init sru bug updated with additional reference to other cloud manual tests we'll perform
<infinity> blackboxsw: ^
<blackboxsw> infinity: +10  we'll go through all our SRU manual tests on this. plus the additional juju /maas exercise
<infinity> blackboxsw: Ta.
<blackboxsw> which exhibited the problem
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [19.2-36-g059d049c-0ubuntu2~16.04.1]
-queuebot:#ubuntu-release- Unapproved: budgie-desktop-environment (eoan-proposed/universe) [0.12.3 => 0.12.4] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- Unapproved: python-tblib (eoan-proposed/universe) [1.4.0-2 => 1.4.0-2ubuntu1] (no packageset)
<infinity> vorlon: ^-- Should address the last NBS.  Feel free to smack Bryce for not following up, but after I dug into it, I decided to JFDI. :P
<infinity> Though I'm now wondering if I should test django against it in a PPA or something.
<infinity> The part where django's autopkgtests have literally never passed is super helpful.
<infinity> Ahh, the last version was built against tblib 1.4.0, though.  So likely fine.
<infinity> Well, the py3 was, the py2 wasn't, because lol.
<Odd_Bloke> Our cloud-init packages built ~an hour ago, how much longer should I expect to wait to see them on archive.u.c?
<infinity> Odd_Bloke: I'd expect them there somewhere around now?
<infinity> Ish.
<Odd_Bloke> OK, it's there now. \o/
-queuebot:#ubuntu-release- Unapproved: ubuntu-budgie-meta (eoan-proposed/universe) [0.52 => 0.53] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- Unapproved: accepted budgie-desktop-environment [source] (eoan-proposed) [0.12.4]
-queuebot:#ubuntu-release- Unapproved: accepted python-tblib [source] (eoan-proposed) [1.4.0-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-budgie-meta [source] (eoan-proposed) [0.53]
<vorlon> infinity: ok :)
<Laney> vorlon: Dunno, I wouldn't have thought of them as cowboys since I didn't know about any VCS :-)
<vorlon> heh fair
<Laney> but probably
-queuebot:#ubuntu-release- New: accepted debian-faq [amd64] (eoan-proposed) [10.1]
-queuebot:#ubuntu-release- New: accepted lollypop [sync] (eoan-proposed) [1.1.4.16-4]
-queuebot:#ubuntu-release- New binary: lollypop [amd64] (eoan-proposed/universe) [1.1.4.16-4] (no packageset)
<vorlon> infinity: I hope apw is EOD by now; will you review the linuces?
-queuebot:#ubuntu-release- Unapproved: accepted rust-cssparser-macros [source] (eoan-proposed) [0.3.6-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-extprim [source] (eoan-proposed) [1.7.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-grep-printer [source] (eoan-proposed) [0.1.3-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-petgraph [source] (eoan-proposed) [0.4.13-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-phf-generator [source] (eoan-proposed) [0.7.24-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-phf [source] (eoan-proposed) [0.7.24-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-rusty-fork [source] (eoan-proposed) [0.2.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-tempfile [source] (eoan-proposed) [3.1.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-tokio-threadpool [source] (eoan-proposed) [0.1.15-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-encoding-rs-io [source] (eoan-proposed) [0.1.6-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-native-tls [source] (eoan-proposed) [0.2.3-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-phf-macros [source] (eoan-proposed) [0.7.24-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-string-cache-codegen [source] (eoan-proposed) [0.4.2-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-grcov [source] (eoan-proposed) [0.4.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-quickcheck [source] (eoan-proposed) [0.9.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-phf-codegen [source] (eoan-proposed) [0.7.24-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-tokio-fs [source] (eoan-proposed) [0.1.6-1build1]
-queuebot:#ubuntu-release- Unapproved: sqlmap (eoan-proposed/universe) [1.3.9-1 => 1.3.10-1] (no packageset) (sync)
-queuebot:#ubuntu-release- New sync: rust-stream-cipher (eoan-proposed/primary) [0.3.2-1]
-queuebot:#ubuntu-release- Unapproved: rust-ena (eoan-proposed/universe) [0.13.0-1 => 0.13.0-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- New: accepted rust-stream-cipher [sync] (eoan-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New binary: rust-stream-cipher [amd64] (eoan-proposed/none) [0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-stream-cipher [i386] (eoan-proposed/none) [0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-stream-cipher [s390x] (eoan-proposed/none) [0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-stream-cipher [arm64] (eoan-proposed/none) [0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-stream-cipher [ppc64el] (eoan-proposed/none) [0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-stream-cipher [armhf] (eoan-proposed/none) [0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted lollypop [amd64] (eoan-proposed) [1.1.4.16-4]
-queuebot:#ubuntu-release- New: accepted rust-stream-cipher [arm64] (eoan-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New: accepted rust-stream-cipher [i386] (eoan-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New: accepted rust-stream-cipher [s390x] (eoan-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New: accepted rust-stream-cipher [amd64] (eoan-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New: accepted rust-stream-cipher [ppc64el] (eoan-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New: accepted rust-stream-cipher [armhf] (eoan-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New binary: rust-c2-chacha [i386] (eoan-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-c2-chacha [s390x] (eoan-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-c2-chacha [amd64] (eoan-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-c2-chacha [armhf] (eoan-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-c2-chacha [arm64] (eoan-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-c2-chacha [ppc64el] (eoan-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted linux [sync] (eoan-proposed) [5.3.0-17.18]
-queuebot:#ubuntu-release- New: accepted rust-c2-chacha [amd64] (eoan-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-c2-chacha [armhf] (eoan-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-c2-chacha [ppc64el] (eoan-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-c2-chacha [arm64] (eoan-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-c2-chacha [s390x] (eoan-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-c2-chacha [i386] (eoan-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- Packageset: Added rust-ena to i386-eoan-excludes in eoan
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed [sync] (eoan-proposed) [5.3.0-17.18]
-queuebot:#ubuntu-release- New binary: rust-rand-chacha [s390x] (eoan-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-rand-chacha [s390x] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New binary: rust-rand-chacha [i386] (eoan-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-chacha [amd64] (eoan-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-chacha [ppc64el] (eoan-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-chacha [arm64] (eoan-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-chacha [armhf] (eoan-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta [sync] (eoan-proposed) [5.3.0.17.19]
-queuebot:#ubuntu-release- New: accepted rust-rand-chacha [amd64] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-chacha [armhf] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-chacha [ppc64el] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-chacha [arm64] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-chacha [i386] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New binary: rust-rand [amd64] (eoan-proposed/universe) [0.7.0-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- New binary: rust-rand [s390x] (eoan-proposed/universe) [0.7.0-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- New binary: rust-rand [ppc64el] (eoan-proposed/universe) [0.7.0-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- New binary: rust-rand [arm64] (eoan-proposed/universe) [0.7.0-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- New binary: rust-rand [armhf] (eoan-proposed/universe) [0.7.0-1build1] (i386-eoan-excludes)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-drivers-common [source] (bionic-proposed) [1:0.5.2.4]
-queuebot:#ubuntu-release- New: accepted rust-rand [amd64] (eoan-proposed) [0.7.0-1build1]
-queuebot:#ubuntu-release- New: accepted rust-rand [armhf] (eoan-proposed) [0.7.0-1build1]
-queuebot:#ubuntu-release- New: accepted rust-rand [s390x] (eoan-proposed) [0.7.0-1build1]
-queuebot:#ubuntu-release- New: accepted rust-rand [arm64] (eoan-proposed) [0.7.0-1build1]
-queuebot:#ubuntu-release- New: accepted rust-rand [ppc64el] (eoan-proposed) [0.7.0-1build1]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (eoan-proposed/main) [5.3.0-17.18] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (eoan-proposed/main) [5.3.0-17.18] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (eoan-proposed/main) [5.3.0-17.18] (core, kernel)
<vorlon> infinity: ftr the rust ftbfs were not because of things out of order, but because rust-rand was uninstallable in -proposed due to an unfinished API transition
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (eoan-proposed/main) [5.3.0-17.18] (core, kernel)
<vorlon> ... an some other unfinished API transition, which I'm still digging into
<vorlon> rust-lock-api, rust-parking-lot-core
-queuebot:#ubuntu-release- Unapproved: rust-parking-lot (eoan-proposed/universe) [0.7.1-1build1 => 0.9.0-1] (i386-eoan-excludes) (sync)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (eoan-proposed) [5.3.0-17.18]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (eoan-proposed) [5.3.0-17.18]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (eoan-proposed) [5.3.0-17.18]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (eoan-proposed) [5.3.0-17.18]
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-meta (eoan-proposed/universe) [1.254 => 1.255] (ubuntu-mate)
<infinity> vorlon: I'll do some kernel review later tonight before I completely EOW, so that stuff's in for the weekend.
<infinity> vorlon: Oh, but it looks like you got the main kernel at least.
<infinity> vorlon: Except that you missed LRM.
-queuebot:#ubuntu-release- Unapproved: accepted linux-restricted-modules [sync] (eoan-proposed) [5.3.0-17.18]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-meta [source] (eoan-proposed) [1.255]
#ubuntu-release 2019-10-05
<vorlon> infinity: evidently! thanks for getting it
<vorlon> 	mouse-modules-5.3.0-16-generic-lpae-di 5.3.0-16.17 in eoan armhf
<vorlon> you don't say
<vorlon> when was the last time we had a supported armhf system doing d-i?
<vorlon> should I mark libreoffice as not-for-i386
<vorlon> might break some metapackages in the near term, so probably not yet
<vorlon> anyway, yay, rust i386 uninstallables zeroed out; boo, a bunch of them ftbfs due to api transitions that will never finish
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-guide (eoan-proposed/universe) [19.10.1-0ubuntu1 => 19.10.2-0ubuntu1] (ubuntu-mate)
<infinity> vorlon: I think we still build d-i targets for a few things, but I'm not sure any of them qualify as "supported".
<vorlon> infinity: do any of them qualify as "tested" or "functional"? :)
<infinity> vorlon: Recently?
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-guide [source] (eoan-proposed) [19.10.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-ena [source] (eoan-proposed) [0.13.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-parking-lot [sync] (eoan-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted sqlmap [sync] (eoan-proposed) [1.3.10-1]
-queuebot:#ubuntu-release- Unapproved: accepted linux-aws [sync] (eoan-proposed) [5.3.0-1002.2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-aws [sync] (eoan-proposed) [5.3.0.1002.2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-raspi2 [sync] (eoan-proposed) [5.3.0.1006.2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed-gcp [sync] (eoan-proposed) [5.3.0-1003.3]
-queuebot:#ubuntu-release- Unapproved: accepted linux-gcp [sync] (eoan-proposed) [5.3.0-1003.3]
-queuebot:#ubuntu-release- Unapproved: accepted linux-raspi2 [sync] (eoan-proposed) [5.3.0-1006.7]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-gcp [sync] (eoan-proposed) [5.3.0.1003.3]
<LocutusOfBorg> tjaalton, I stole the code from llvm-spirv foo and added that cmake test to llvm-toolchain
<LocutusOfBorg> so we should know in advance if our cmake script breaks
<LocutusOfBorg> tjaalton,     * amd64: intel-opencl-icd, libigdfcl-dev, libigdfcl1, libopencl-clang-dev, libopencl-clang8
<LocutusOfBorg> now your package needs some love for migrate, but at least its a valid candidate, let me know if you want me to do it or not
<LocutusOfBorg> it might just need an AA to accept intel-opencl-lang...
-queuebot:#ubuntu-release- New: accepted intel-opencl-clang [amd64] (eoan-proposed) [9.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted intel-opencl-clang [i386] (eoan-proposed) [9.0.0-0ubuntu1]
<tjaalton> LocutusOfBorg: yes, needs an AA, I'll update the rest of the stack
<tjaalton> thanks for fixing llvm
-queuebot:#ubuntu-release- Unapproved: intel-graphics-compiler (eoan-proposed/universe) [1.0.9-0ubuntu1 => 1.0.2652-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: inkscape (eoan-proposed/universe) [0.92.4-3ubuntu3 => 0.92.4-4] (ubuntustudio) (sync)
-queuebot:#ubuntu-release- Unapproved: python-meshio (eoan-proposed/universe) [3.1.5-1 => 3.1.6-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: iraf (eoan-proposed/universe) [2.16.1+2018.11.01-2build1 => 2.16.1+2018.11.01-2build2] (no packageset)
<tjaalton> LocutusOfBorg: hum, newer intel-compute-runtime needs newer intel-gmmlib, but the media driver isn't tagged for that series yet :/
<tjaalton> I'll poke upstream
<tjaalton> oh, it does't break with the new gmmlib
<tjaalton> current one, so a rebuild is enough
-queuebot:#ubuntu-release- Unapproved: krita (eoan-proposed/universe) [1:4.2.7.1+dfsg-0ubuntu1 => 1:4.2.7.1+dfsg-1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-docs (eoan-proposed/main) [19.10.1 => 19.10.2] (desktop-core, personal-gunnarhj)
-queuebot:#ubuntu-release- Unapproved: intel-gmmlib (eoan-proposed/universe) [19.2.4+ds1-1 => 19.3.2+ds1-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: intel-compute-runtime (eoan-proposed/universe) [19.29.13530-0ubuntu3 => 19.39.14278-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: intel-media-driver-non-free (eoan-proposed/multiverse) [19.2.1+ds1-2 => 19.2.1+ds1-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: intel-media-driver (eoan-proposed/universe) [19.2.1+dfsg1-2 => 19.2.1+dfsg1-2ubuntu1] (kubuntu)
<LocutusOfBorg> badpkg: rules extract failed with exit code 1
<LocutusOfBorg> autopkgtest [09:35:12]: ERROR: erroneous package: rules extract failed with exit code 1
<LocutusOfBorg> i don't understand what is going on with iraf
<LocutusOfBorg> I hope a no change rebuild can fix it
#ubuntu-release 2019-10-06
-queuebot:#ubuntu-release- Unapproved: nvme-cli (bionic-proposed/universe) [1.5-1 => 1.5-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: llvm-toolchain-9 (eoan-proposed/main) [1:9-1ubuntu1 => 1:9-2] (no packageset) (sync)
<bluesabre> The Xubuntu Eoan wallpaper is ready! Can we get a release team ack on https://bugs.launchpad.net/ubuntu/+source/xubuntu-artwork/+bug/1846935 before proceeding with the upload?
<ubot5> Launchpad bug 1846935 in xubuntu-artwork (Ubuntu) "[UIFe] New wallpaper for Xubuntu 19.10" [Undecided,New]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [5.0.0-1020.20~18.04.1] (kernel)
-queuebot:#ubuntu-release- Unapproved: libdazzle (eoan-proposed/main) [3.34.0-2 => 3.34.1-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: gnome-games-app (eoan-proposed/universe) [3.34.0-1 => 3.34.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: glib-networking (eoan-proposed/main) [2.62.0-1 => 2.62.1-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: rxtx (bionic-proposed/universe) [2.2pre2+dfsg1-1 => 2.2pre2+dfsg1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fswatch (eoan-proposed/universe) [1.14.0+repack-9ubuntu1 => 1.14.0+repack-12] (no packageset) (sync)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [5.0.0-1020.20~18.04.1]
-queuebot:#ubuntu-release- Unapproved: ubuntustudio-meta (eoan-proposed/universe) [0.195 => 0.196] (ubuntustudio)
<Eickmeyer> ^Experimental zfs support ^
-queuebot:#ubuntu-release- Unapproved: mate-session-manager (eoan-proposed/universe) [1.22.2-0ubuntu1 => 1.22.2-0ubuntu2] (ubuntu-mate)
