#ubuntu-release 2010-08-30
 * micahg is still wondering if someone can have a look at Firefox in unapproved :)
<asac> micahg: not on sunday i guess ;)
<asac> wait till europe wakes up
<micahg> asac: k, chris is out tomorrow due to holiday in UK, so I said I'd follow up on this
<asac> well. if the bug that its closing is properly mentioned then it will get in
<asac> i am quite sure ;)
<stgraber> ScottK: hmm, nope, where did you post it ?
<micahg> asac: hmm, there isn't a bug specifically allowing upload...that's the issue
<ScottK> stgraber: There are po file changes in the ltsp diff that aren't documented.  Are those wanted/correct?
<stgraber> ScottK: nope, please reject, I'll re-upload
<ScottK> stgraber: Will do.
<stgraber> not sure what happened to -0ubuntu1 because that one was a real mess ... I'm working on a clean -0ubuntu2 and will update the changelog accordingly (as it'll fix the mess made by -0ubuntu1 at the same time)
<ScottK> stgraber: You can reupload it as ubuntu1.
<stgraber> ScottK: nope. Because -0ubuntu1 is what's currently in the archive and is a mess. -0ubuntu2 is the one you just rejected. So I'm reviewing everything that was in .diff.gz in -0ubuntu1 and shouldn't have been there, then will re-upload -0ubuntu2 to fix that + fix d-i and document what was changed.
<ScottK> Ah.  OK.
<ScottK> BTW, I accepted edubuntu-artwork, so at least that's in.
<stgraber> thanks
<ScottK> No problem.  That's what I get paid the big bucks to do.
<ScottK> No, wait.  I don't....
<ScottK> ;-)
<stgraber> ;)
<stgraber> ok, done doing the change-review, updated changelog and re-uploaded ltsp
<stgraber> nothing in these missing upstream changes might break the install process, the only thing it may impact is the thin client boot process but I had already reviewed the upstream changes before I released 5.2.4 upstream and other distros (including Debian) run with these, so they should all be good.
 * stgraber still wonders how he managed to upload a non-clean .diff.gz ... I usually check that there's only debian/ in there ...
<ScottK> po files are weird.
<ScottK> Still waiting for LP to generate the diff.
<stgraber> debdiff will be quite long
<stgraber> but .diff.gz is clean now
<stgraber> so the "upstream => 0ubuntu2" delta is clean now (as in, only debian/ is in there)
 * ScottK nods
<ScottK> (and waits)
<stgraber> "upstream => 0ubuntu1" was a mess with some of the changes from 5.2.4 changes being reverted by what was in the .diff.gz (that wasn't intended)
<ScottK> stgraber: This one still has the po file changes like "+"Language: \n"" in es.po.  I'm guessing a blank Language field isn't right.
<stgraber> ScottK: you see that in .diff.gz ?
<stgraber> oh, that's probably from the .po that are in debian/
 * stgraber looks
<stgraber> ok, found the issue (though I still have no clue what caused it), please reject again ... sorry
<ScottK> No problem.
 * stgraber starts to believe it's to do with running a dpkg-buildpackage locally at some point and the clean target not doing its job properly
<ScottK> Done.
<stgraber> hmm, these Language fields must be added by some debhelper script ...
<stgraber> I just took the debian/ from -0ubuntu1 and applied the changes I wanted and I still have these when diffing both debian/ directories
 * stgraber suspects debconf-updatepo
<stgraber> yup, that's the one ... running it manually causes the Language: \n issue
<stgraber> re-uploaded a new source package with all of these Language: field set so debconf-updatepo doesn't break them ...
<stgraber> I'm really not sure that field is mandatory though as I can't find it set in any of the .po I found ... might be a debconf-updatepo bug
<ScottK> diff still pending.
<ScottK> stgraber: Accepted.
<stgraber> ScottK: thanks
<ScottK> No problem.  You might file a bug against updatepo so it at least gets investigated.
<micahg> ScottK: still around?
<slangasek> micahg: accepted now; sorry for the delay
<micahg> slangasek: no problem, thanks
<micahg> slangasek: do you have time for a quick question?
<slangasek> micahg: sure
<micahg> I have bug 622900 which is a security update, but there's been a bug fix point release afterwards already that can be sync'd, should I update the bug for the new point release and get a new ack or wait till this goes through?
<ubot4> Launchpad bug 622900 in phpmyadmin (Ubuntu) "Please sync phpmyadmin 4:3.3.5.1-1 (universe) from Debian unstable (main) (affects: 1) (heat: 262)" [Medium,Confirmed] https://launchpad.net/bugs/622900
<NCommander> ping, is anyone awake? I just patched a bug which has prevented amd64 images from building, and I'd like to do a one-off respin of ubuntu/amd64 to test, and if successful, spin the entire image set for amd64 since we don't have ANY
<ScottK> NCommander: Bank holiday in the UK today.  You may have to wait for slangasek to wake up.
<NCommander> ScottK: well, once he's up, he can do spins. I did one in DEBUG mode, so I'm sure its fixed
<persia> NCommander, ScottK: Is there a reason we wouldn't want to do spins, so things are ready for tomorrow?
<NCommander> No reason not to where I'm sitting
<NCommander> I wanted to doa headsup ping before I started spinning
<ogra> well, thats for china, how about the rest of the world :P
<persia> ogra, Any "tomorrow".  it's a bank holiday in the UK, but without a respin, it can be a while before there are images.
<ogra> persia, NCommander was referring to "where he sits" :P
<persia> But one of cjwatson, iulian, Riddel, pitti, ScottK, sistpoty, or slangasek needs to make the call.
 * ogra pokes the queue bot ... 
<ogra> i just uploaded ubuntu-netbook-efl-default-settings 0.6 why ist it picked up
<ogra> *isnt
<persia> Takes a bit.
<ogra> well, i have the LP mail since quite a while
<persia> Anyway, I'm not sure it matters that much.  I don't believe any of the release managers are currently about.
<ogra> persia, ScottK is here :)
<ogra> i wanted to nag him about it
<persia> I think he's probably dealing with morning stuff at this hour, and not available until he gets a gap between $work and meetings.
<persia> I could be mistaken.
<cjwatson> NCommander: you don't need to respine
<cjwatson> everything, just one wil be fine I guess
<cjwatson> NCommander: where's the patch?
<NCommander> cjwatson: already deployed
<KE1HA> cjwatson:  Just FYI, a bit off topic but, a user named diva, in the grub channel, ran into your bootloader issue on a dell machine.
<cjwatson> NCommander: please fix the PATH setting in crontab instead
<cjwatson> KE1HA: I'm aware, and yes it's off-topic here
<cjwatson> I'm in that channel too and read it
 * ogra wonders why the  queuebot ignores his upload
<cjwatson> I'll look when I'm not on holiday
<ogra> cjwatson, thanks, i'll try to get the package out of the qeue before though
<ogra> *queue
<cjwatson> ogra: it's not going to be noticed by queuebot now.  some kind of bug with multiple versions of the same package, from a cursory look at the code
<ogra> cjwatson, ah, thanks
<ScottK> ogra: ubuntu-netbook-efl-default-settings is the one you need, right?
<ogra> ScottK, yep
<ScottK> ogra: I can accept that.
<ogra> ScottK, that would be awesome
<ScottK> ogra: Done.
<ogra> thanks a lot :)
<ScottK> You're welcome.
<slangasek> micahg: ah, so apparently I was mistaken and disappeared right as you asked the question. :)  At minimum, I would say you need to update the sync request to mention that it has to be synced from testing now...
<mvo> slangasek: is bug #620956 something that you could look at? if not I'm happy to do it tomorrow, its just a conffile prompt, not criticial
<ubot4> Launchpad bug 620956 in ifupdown (Ubuntu) "Upgrading ifupdown from lucid to maverick creates two spurious debconf questions (affects: 1) (heat: 6)" [High,Triaged] https://launchpad.net/bugs/620956
<jdstrand> skaet, robbiew: hey, so I got ufw 0.30 together and would like to get it into beta, if possible. It wouldn't be devastating if we didn't, but it would be nice, particularly for bug #618410
<ubot4> Launchpad bug 618410 in ufw (Ubuntu) "/etc/ufw/applications.d has wrong syntax (affects: 2) (dups: 1) (heat: 254)" [Undecided,Fix committed] https://launchpad.net/bugs/618410
<jdstrand> skaet, robbiew: I got it into Debian over the weekend, and would like to sync 0.30.0-1 from sid
<jdstrand> skaet, robbiew: as mentioned in the release meeting on friday, this addresses the bugs in https://wiki.ubuntu.com/SecurityTeam/ReleaseStatus/Maverick#Planned%20changes%20for%20Beta
<ScottK> jdstrand: Is it bug fixes or new features too?
<jdstrand> ScottK: bug fixes only
<ScottK> jdstrand: Go ahead an sync then.
<robbiew> yeah...what ScottK said :)
<jdstrand> what is in maverick is a prerelease of 0.30
<jdstrand> rock on
<jdstrand> actually, I may also fix bug #580032 with an ubuntu1
<ubot4> Launchpad bug 580032 in ufw (Ubuntu) (and 2 other projects) "can't read ufw error messages in russian (affects: 2) (heat: 16)" [Undecided,Triaged] https://launchpad.net/bugs/580032
<jdstrand> but cool. uploading :)
<ogra> slangasek, is there a way to tag the linux-ti-omap4 package so no release manager will accept it accidentially ? the resulting binary wont work with the bootloaders yet and i'm a bit scraed someone accepts it by accident
<ogra> (which would make our images unbootable)
<ScottK> ogra: Not uploading it would be the best way.
<ogra> ScottK, to late :)
<ScottK> ogra: You might sent mail to ubuntu-release.
<ogra> i only noticed the kernel team did the upload when it hit the archive already
<ScottK> I can reject it if you want.
<ogra> hmm thats probably the safest
<ScottK> OK.  Would you please let them know what we're doing and why.
<ogra> let me ask
 * ScottK waits
 * ogra wants to coordinate with kernel team before making their uploads go away :)
<micahg> slangasek: so, that would be better than updating for the new version?
<slangasek> mvo: 620956> oh, is *that* what caused those prompts for me, hmm.  I can try to look at it today
<slangasek> mvo: what's your first thought on how to fix this?  checksum match && removal of old "conffile" before upgrade?
<slangasek> ogra: yes, asking us to reject the package is the way to tag it :)
<ogra> ScottK, ok, you can reject it (said tgardner), the binary that will result from that package is for HW (panda ES2.0) thats not even available to the arm team yet and the bootloader we have in the images does not support that HW at all
<slangasek> micahg: if you want the security fix in quickly, I think that's the way to go first, yes
<ogra> slangasek, right, i was hoping there was a less bandwith wasting way :)
<ScottK> OK.  linux-ti-omap4 going away then.
<slangasek> micahg: but I don't think there's one right answer here
<ogra> ScottK, thanks
<micahg> slangasek: k, I'll go for the security fix first, thanks
<ScottK> ogra: Done.
<ogra> thanks :)
<slangasek> so, what was this problem that made all of amd64 not build?
<ScottK> NCommander said he'd committed a fix, but not what it was.
<slangasek> NCommander: where did this amd64 fix land?
<slangasek> ogra: if linux-ti-omap4 has been rejected for upload, does that mean bug #605739 needs retargeting?
<ubot4> Launchpad bug 605739 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "BUG: Bad page state in process swapper pfn:94d23 (affects: 2) (heat: 92)" [High,In progress] https://launchpad.net/bugs/605739
<mvo> slangasek: yeah, checksum-match && removal was what came to my mind, not sure if its ideal, but it will certainly do the job
<ScottK> jdstrand: Your ufw upload has some instances of ""Language: \n"" in it.  stgraber ran into a similar problem on ltsp.  Apparently updatepo is adding it now for some reason.  His solution was to make sure it was present and defined in all the po files.
<ScottK> I'm not sure what happens if it's present and unset, but I doubt it's good.
<jdstrand> ScottK: I see de and es. Shall I just put them in and upload and you'll review/accept?
<ScottK> jdstrand: I let you know when I saw de.  Add them and reupload (same version number, I'll reject the first one)
<jdstrand> ScottK: thanks
<ScottK> jdstrand: Just a nit (not something I'd reject it for, but you mention Postfix in the description for "Mail submission" (587).  Port 587 is defined in an IETF RFC and not at all Postfix specific.
<jdstrand> it seems 0.29.3 didn't have a "Language:" at all
<jdstrand> ScottK: oh, that is a thinko
<jdstrand> ScottK: that was supposed to b generalized and I missed it
<jdstrand> ScottK: but, on the plus side, I am not installing those yet
<ScottK> OK.  There's your bug report....
<jdstrand> hehe
<jdstrand> ScottK: thanks :)
<ScottK> jdstrand: re language, updatepo seems to be adding it now if it's missing.  Not sure why.
<jdstrand> yeah
<jdstrand> I'll add it in and check all of them
<ScottK> 443 is a bit of an interesting one too as it's also used by Microsoft MUAs for smtps.
<ScottK> Neither that nor the MSN usage is supported by the well known ports assignment.
<ScottK> I like how you put insecure in the name of telnet.
<jdstrand> re msn-- yeah, that was tricky-- I did quite a bit of research trying to get them right-- that one was hard
<jdstrand> I'd have to dig up the source, I don't have it handy
<ScottK> I didn't even know about that usage.
<ScottK> Actually, I'm mis remembering.  smtps is 465
<jdstrand> yes, that sounds right
<ScottK> Fixed the Unity FTBFS on amd64 via the obscure magic of the retry button.
<ScottK> jdstrand: pot still has an empty Language: field.
<ScottK> Not sure we care.
<ScottK> (or if it's wrong)
<ScottK> Off for a bit.
<jdstrand> ScottK: I'm not a translations guru, but templates.pot is simply what a translator will use and 'fill in'. a '"Language: \n"' I would think would be expected, since we shouldn't specify a language in the template
<jdstrand> ScottK: to verify this, I ran debconf-gettextize debian/templates and found is does create '"Language: \n"'
<jdstrand> ScottK: so I think it is fine as is. if you don't want it in the diff.gz, I'll reupload
<jdstrand> ScottK: err, I mean autgenerated
<cjwatson> ScottK: empty Language field> gettext 0.18 introduced the Language field, which is supposed to be a more reliable way to identify the po file's language from contents alone than previous header fields.  It tries to guess what its contents should be, but sometimes it fails.  That said, empty Language won't actually break anything that I know of.
<cjwatson> and yes, I'm inclined to agree with jdstrand
<cjwatson> NCommander: I've fixed PATH in crontab and reverted your debian-cd change; hope that's ok
<ScottK> jdstrand and cjwatson: Thanks.
<ScottK> jdstrand: Accepted.
<jdstrand> \o/
<jdstrand> ScottK: thanks
<cjwatson> uploaded openoffice.org-voikko, which should fix the last uninstallable on amd64/i386.  please review
<cjwatson> is there an Ubuntu Studio representative here?
<cjwatson> I had a vague memory it was ScottL
<cjwatson> curious what they're going to do about the linux-headers-rt recommendation from ubuntustudio-desktop, given that linux-rt's been removed
<cjwatson> anything else that's known to be beta-critical and needs review?
<ScottK> cjwatson: Accepted.
<ScottK> Not that I know of.
<cjwatson> ta
<ScottK> didrocks just mentioned in #uubntu-devel that his evolution upload is intended for beta.
<GrueMaster> ScottK: I finished adding the results for Kubuntu 10.04.1  Sorry for the delay, major issues with maverick consumed all my time.  Note that the dove image still fails to boot kdm (bug 571732) and the installer crashes on omap, likely due to low memory.
<ubot4> Launchpad bug 571732 in qt4-x11 (Ubuntu) "ksplashx_scale crashed with SIGILL in QImage::transformed() (affects: 1) (heat: 28)" [Undecided,New] https://launchpad.net/bugs/571732
<ScottK> GrueMaster: OK.  Thanks.  I gather that's not a regression though.
<stgraber> will we get a daily for Edubuntu tomorrow or do we already have to poke someone for a respin ? (to include the oem fix from cjwatson)
<GrueMaster> No.  I had to look up the release notes, as I had done the testing on 10.04 for dove.  Not sure on omap.  Don't know if it was tested.  I also don't know if we officially announced a Lucid image on omap.
<cjwatson> stgraber: autobuilds are still on
#ubuntu-release 2010-08-31
<ScottL> was someone looking for me about the -rt kernel?
<nhandler> ScottL: 1283200465 15:34:25 < cjwatson> curious what they're going to do about the linux-headers-rt recommendation from ubuntustudio-desktop, given that linux-rt's been removed
<ScottL> thanks nhandler
<ScottL> cjwatson, hopefully tomorrow i'll take care of the linux-headers-rt recommendation in ubuntustudio-desktop
<NCommander> cjwatson: that's fine, I fpassed out before I saw your message or I would have done it
<slangasek> ^^ per mvo's request this morning; note that this bug only affects upgrades from systems that aren't up-to-date on lucid-updates, so may not be worth accepting before beta
<persia> Depends on testing methodologies: lots of folks try to do the install/dist-upgrade trick on a VM, and may not remember to update first.
<mvo> slangasek: \o/ for fixing the ifupdown #620956
<Riddell> ev: the standalone installer seems to be working in Kubuntu but when clicking "Try Kubuntu" it goes to the slideshow rather than the live session
<ara> morning all!
<ara> when do we expect the first candidate images?
<persia> cronjob was still enabled last I heard, so today's dailies should be candidates as they become available.
<persia> I believe this will take at least two more hours, perhaps a bit more.
<persia> Err, rather, I'm doing math wrong.  Should be any time now.
<Riddell> ev: hum, the installer seems to freeze this VM
<Riddell> ev: bug 625586 I guess
<ubot4> Launchpad bug 625586 in ubiquity (Ubuntu) "ubiquity killed by OOM killer (affects: 2) (heat: 1154)" [High,New] https://launchpad.net/bugs/625586
<Riddell> the install does complete fine for me if you ignore the UI freeze
<ogra> hrm, lamont i cant reach sycamore or acorn through http, are they down ?
<ogra> (builds failed as well it seems)
<Riddell> bug 627284
<ubot4> Launchpad bug 627284 in ubiquity (Ubuntu) "Try Kubuntu leads to slideshow not live CD (affects: 1) (heat: 6)" [Critical,New] https://launchpad.net/bugs/627284
<ogra> lamont, hmm, in fact i cant reach *any* of the livefs builders
 * ogra wonders whats going on here
<ogra> sycamore.buildd starting at Tue Aug 31 10:02:07 BST 2010
<ogra> ssh: connect to host sycamore.buildd port 22: No route to host
<ogra> sycamore.buildd finished at Tue Aug 31 10:02:10 BST 2010 (failed)
<ogra> geez
<cjwatson> I can't reach acorn or sycamore either, but e.g. kapok is fine
<ogra> are terranova and king still livefs builders ?
<cjwatson> no
<ogra> ah, k
<cjwatson> cardamom weddell royal concordia all work fine.  clementine is reachable but doesn't have a ~buildd directory.
<ogra> clementine is dead since maverick started
<cjwatson> from which I infer that I forgot to update livefs-build-logs-mirror
<ogra> acorn took over
<ogra> and sycamore is a new one for omap4 builds only
<cjwatson> well, that would be why you haven't been getting your logs on the web ;-)
<cjwatson> I'd recommend asking #is about those hosts being down; lamont probably won't be around for a few hours yet
<ogra> cjwatson, yeah, sorry, my fault i should have pinged you about it ... i personally look directly on the buildd nowadays so i forgot
 * cjwatson wonders why the kubuntu daily has uninstallable packages
<cjwatson> building updated kubuntu dvds since those wouldn't normally happen today
<\sh> moins :) can some approve last zend-framework upload 1.10.8 (bug fix only upload -> bug #627319)
<ubot4> Launchpad bug 627319 in zend-framework (Ubuntu) "zend-framework 1.10.8 (bugfix release) (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/627319
<lamont> clementine is a recycled name (sorry) and not a livecd builder.  sycamore was down, is now back up <-- ogra, cjwatson
<ogra> lamont, yeah, i'm alreday building on it again :)
<Riddell> \sh: accepted
<lamont> ogra: acorn was not on my list of hate as of last night, though.
<ogra> it did build the dove and omap3 images but was dead when i tried to reach it today
<lamont> must have gotten annoyed after I went offline
<\sh> Riddell, thx...
<ogra> heh, yeah, it needs its master :)
<\sh> Riddell, when you are at it...could you review bug #627337 and think about it ?? :)
<ubot4> Launchpad bug 627337 in ubuntu "[FFE] FAI 3.4 for Ubuntu Maverick (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/627337
<cjwatson> acorn and sycamore build logs will now be mirrored
<cjwatson> ogra: you want to kick rebuilds?
<ogra> cjwatson, running since ~30min already
<cjwatson> ok
<Riddell> ogra: what ARM images are you expecting to build for beta?
 * cjwatson starts sorting out the tracker
<ara> cjwatson, thanks!
<cjwatson> ubuntu alternates both oversized
<cjwatson> hmm, why isn't "Maverick Beta" an option on http://iso.qa.ubuntu.com/qatracker/admin/addbuild ?
<cjwatson> stgraber: ^- do you know?  I added it in http://iso.qa.ubuntu.com/qatracker/admin/milestone
<ev> Riddell: I've committed a fix for bug 627284.  You're not in -installer, so I wasn't sure if you would notice.
<ubot4> Launchpad bug 627284 in ubiquity (Ubuntu) "Try Kubuntu leads to slideshow not live CD (affects: 1) (heat: 6)" [Critical,Fix committed] https://launchpad.net/bugs/627284
<cjwatson> ev: are there ubiquity fixes pending for beta?
<ev> cjwatson: I was just going to ask.  What are my chances of getting a respin?
<cjwatson> 'cos I was about to start posting desktops, once the tracker will let me
<cjwatson> what's your timeframe?
<ev> as yes, there are fixes I'd like to see in
<cjwatson> can you upload right away?
<ev> yes
<cjwatson> please do then
<ev> should I do the usual freeze exception dance, or are you happy to push it through?
<cjwatson> please just upload it
<cjwatson> I'll check it over in the queue
<ev> will do, thanks
<cjwatson> have we had a translations update recently?
<cjwatson> ... apparently so
<\sh> ScottK, thx
 * cjwatson fixes Ubuntu alternate oversizedness
<cjwatson> hm, there's been an issue updating the seed mirrors for the last week
<cjwatson> actually it was probably ok, just slow
<Riddell> thanks ev
<ev> sure thing, sorry for the screw up there
<ev> cjwatson: uploaded
<cjwatson> ev: accepted (please push the debcommit -r bit to bzr?)
<ev> cjwatson: done, thanks
<Riddell> cjwatson: could you take a look at kdenetwork in unapproved?  it's needed to stop libavcodecs being pulled onto the CD
<cjwatson> ok, is that what the uninstallables are about?
<Riddell> cjwatson: yes
<cjwatson> accepted
<cjwatson> seb128: is there any of this gnome update that's beta-critical, as opposed to would-be-nice?
<cjwatson> I wasn't available yesterday to review it and it doesn't look like others did, and I'd like to start building beta candidates v. soon
<cjwatson> we have a slot for a small number of them if they're needed
<seb128> cjwatson, hi
<seb128> cjwatson, those are not beta stopper no
<seb128> I pinged slangasek about the important ones yesterday
<seb128> we might still want to get some unity changes in the next hour
<cjwatson> ah, ok, so those went in?
<seb128> do you think there is a margin to wait a bit for UNE?
<seb128> cjwatson, yes
<cjwatson> I can hold off on building netbook, yes
<cjwatson> plenty of other stuff to do
<seb128> would be nice, just for an hour
<seb128> I want to sort the status with njpatel when he's online
<cjwatson> I have to wait 1.5 hours or so for ubiquity and kdenetwork anyway
<seb128> they are sprinting in canada this week
<seb128> he should be there rsn
<seb128> ok
<cjwatson> I wonder if I can do anything about the powerpc desktop oversizedness
<cjwatson> that's the only oversized thing left, I think
<cjwatson> a
<cjwatson> probably not a whole lot
<persia> cjwatson, Given how long it's been since Windows worked on powerpc, the lupin and casper-lupin stuff could be dropped (although that might be deeper than you want to play today)
<cjwatson> persia: thanks, done, though it won't make much difference
<ogra> Riddell, ubuntu-netbook for omap3 and 4, kubuntu and kubuntu-mobile for omap3, no idea what NCommander's plans for dove are
<NCommander> ogra: I'll attempt to test tomorrow, can't now
<ogra> NCommander, what images do you plan to have rolled ofr beta was the question
<ogra> *for
 * persia doesn't see anything else obvious, seeing use cases for ntfs, and knowing the reasons libdrm-intel is there.
<ogra> Riddell, nobody in the team will have time to test any of the kubuntu ones though, so testing these is up to the community
<seb128> cjwatson, ok, do we still have a margin to have changes in before the end of the hour out of UNE or is late for that?
<cjwatson> go ahead
<seb128> cjwatson, the shotwell update has small changes and fix import issues and a crasher if you can review that, rather a would be nice to have
<seb128> cjwatson, evo in the queue just fix some files installed at the wrong location, that should make the default signature work and have a menu entry in internet
<seb128> cjwatson, I will upload rsn a telepathy-logger update with a recommends on libdconf0
<seb128> seems we got bitten again by the "libglib2.0-0 recommends are not installed" I asked you about at the sprint
<seb128> ie dconf doesn't get pulled on the iso which leads to have different programs falling back to use the default glib backend which has no storage
<seb128> and I will have an unity update for UNE before end of the hour
<seb128> I think that's it by checking with different desktop and dx people
<ttx> ara, cjwatson: anything blocking using the current server ISO daily as the beta candidate ? Or are we waiting for something to show up to respin ?
<ara> ttx, I don't know. I am waiting as well for images to appear in the tracker
<cjwatson> ttx: I need help with the tracker, which is refusing to let me post images for Maverick Beta
<cjwatson> 14:38 <agy> cjwatson: ara is probably the person to talk to about qatracker
<cjwatson> ara: ^- can you help?
 * ttx shakes its fist towards the tracker to see if it helps
<ara> cjwatson, sure, what's  the issue?
<cjwatson> 12:57 <cjwatson> Can somebody look at iso.qa.ubuntu.com for me?  I added a "Maverick Beta" milestone using http://iso.qa.ubuntu.com/qatracker/admin/milestone, but it's not showing up in the drop-down at the
<cjwatson>                  bottom of http://iso.qa.ubuntu.com/qatracker/admin/addbuild
<cjwatson> 12:57 <cjwatson> I'm wondering if it needs some kind of manual push
<cjwatson> sigh, I wish seb128 had told me about those uploads when I asked earlier
<ara> cjwatson, I'll have a look
<cjwatson> I bet that'll mean another hour
<ara> cjwatson, I see that milestone in the dropdown
<ara> cjwatson, (the first of the list)
<ara> cjwatson, the ordering of that list could be wiser, that's true
<cjwatson> oh, sigh, ok
<cjwatson> can you change the default?
<cjwatson> which is currently Lucid 10.04.1
<cjwatson> ttx: posted
<ttx> cjwatson: thanks !
<seb128> re, sorry system crash on user switching
<ara> cjwatson, done
<cjwatson> seb128: would have been nice to know earlier :-/, but shotwell and evolution accepted now
<cjwatson> ara: thanks
<cjwatson> might be 1530 UTC or so before I can start building candidates
<seb128> cjwatson, sorry I was set on the "let them roll beta iso we can get those later", but somebody raised the dconf issue
<seb128> cjwatson, so I figured we will need to get that anyway so...
<cjwatson> how long will telepathy-logger be?
<seb128> thanks
<seb128> I'm uploading now
<seb128> I was about when my box crashed
<seb128> cjwatson, telepathy-logger shows up in the queue
<cjwatson> accepted, thanks
<seb128> thank you
<Riddell> cjwatson: kdenetwork and ubiquity seem to be in, can I build kubuntu candidate CDs?
<cjwatson> can I do it please
<Riddell> sure
<cjwatson> building
 * cjwatson looks suspiciously at how all his jigdo attempts today yield checksum errors
<cjwatson> wonder if there's a problem on my local mirror ...
 * ttx expects a eucalyptus upload fixing a few beta-targeted bugs, that will generate a server ISO respin.
<stgraber> cjwatson: is your issue fixed ?
<cjwatson> stgraber: yes, thanks
<cjwatson> seb128: is unity-asset-pool for beta, and is there anything else in that list?
<seb128> cjwatson, yes and unity which is coming in 2 minutes
<seb128> that's UNE only
<seb128> and we should be done then
<seb128> we are done for desktop already
<ttx> hm, about server ISOs: looking at the potenial euca upload, there is nothing worth a respin there. So we won't respin over that one alone.
<cjwatson> seb128: any news on unity?
<seb128> cjwatson, hum, I uploaded an hour ago, let me see what happened
<seb128> Rejected:
<seb128> dpkg-source failed for unity_0.2.32-0ubuntu3.dsc [return: 29]
<seb128> hum
<seb128> cjwatson, can we change a source to format 3 in a new revision?
<cjwatson> tar: data/trash.png: Cannot open: File exists
<cjwatson> tar: data/files.png: Cannot open: File exists
<cjwatson> tar: data/applications.png: Cannot open: File exists
<cjwatson> yes
<cjwatson> doesn't mean you can ship files in the .debian.tar.gz that exist in the .orig.tar.gz though
<seb128> oh :-(
<cjwatson> at least I don't think so
<cjwatson> though actually that seems slightly odd
<cjwatson> but can you stick them under debian/ instead as a workaround?
<seb128> sure
<seb128> weird that it works there
<seb128> I can dpkg-source -x it
<cjwatson> the dpkg-source -x failure is reproducible on cocoplum
<cjwatson> dpkg-dev 1.15.5.6ubuntu1~1.IS.PATCHED.8.04
<cjwatson> maybe it's a bug that was fixed since?
<seb128> could be
<seb128> in any case I'm going to fix that, sorry for the delay :-(
<cjwatson> I don't see anything obvious in the dpkg changelog
<cjwatson> maybe report a bug and attach the uploaded files
<cjwatson> spinning other images in the meantime
<seb128> ok, let me get a valid upload in first
<ScottK> cjwatson: Where are we wrt spinning mythbuntu images?  The mythbuntu-common in the queue is desired, but not required for beta.
<ScottK> I've reviewed it and it seems OK if it won't hurt ISO generation signfificantly.
<cjwatson> $ echo ubuntu; for-project ubuntu cron.daily; buildlive ubuntu && for-project ubuntu cron.daily-live; echo xubuntu; for-project xubuntu cron.daily; buildlive xubuntu && for-project xubuntu cron.daily-live; echo ubuntustudio; for-project ubuntustudio cron.daily; echo mythbuntu; buildlive mythbuntu && for-project mythbuntu cron.daily-live
<cjwatson> currently in Ubuntu daily-live
<cjwatson> go ahead and accept it
<cjwatson> may not quite make that build but we can respin quickly
<ScottK> OK.  Thanks.
<ScottK> Done.
<ara> cjwatson, ubiquity is crashing for me on kubuntu
<ara> bug 627489
<ubot4> Launchpad bug 627489 in ubiquity (Ubuntu) "Ubiquity crashes in Kubuntu (Maverick Beta candidate) (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/627489
<cjwatson> ev: ^-
<ev> looking
<ev> ugh, fixing
<GrueMaster> I also saw this yesterday on the http://cdimage.ubuntu.com/kubuntu/ports/daily-preinstalled/20100830/maverick-preinstalled-desktop-armel+omap.img.gz image.
<GrueMaster> Hadn't had time to look at it though.
<seb128> cjwatson, unity uploaded again let's see how it goes this time
<seb128> cjwatson, it's in the queue
<cjwatson> damnit, desktops oversized again
<cjwatson> quite dramatically - I wonder what happened
<cjwatson> unity accepted
<seb128> thanks
<GrueMaster> ev: I'm not sure if I have the same kubuntu installer issue or not.  Could you quickly scan my logs at http://members.dsl-only.net/~tdavis/oem-config-crash.tgz?  This is on omap (armel) platform.
<GrueMaster> If it isn't the same, I'll look into it more and file a bug asap.
<cjwatson> oh, argh, oversized because we've just picked up the last week's worth of seed changes in one go
 * cjwatson cries a little bit inside
<cjwatson> and since the necessary change is in the live task, we'll need the usual publisher runs to fix it.  I'll try to speed it up a bit
<cjwatson> (running 'LPCONFIG=ftpmaster-publish /srv/launchpad.net/codelines/current/cronscripts/publishing/cron.germinate' by hand as lp_publish@cocoplum, since we're at the right time for that to be a useful speedup)
<cjwatson> BTW, Ubuntu alternate and Xubuntu alternate posted
<charlie-tca> Thanks
<charlie-tca> umm, those images don't exist for xubuntu alternate on http://cdimage.ubuntu.com/xubuntu/daily
<charlie-tca> well, got them now
<cjwatson> wait, it's just slow
<charlie-tca> Thanks
 * charlie-tca is in a hurry. It could a long time to sync them on his s-l-o-w connection now
<cjwatson> xubuntu desktop posted
<charlie-tca> Thanks
<cjwatson> hey, I've been downloading a single poxy cd for a couple of hours
<slangasek> maybe a non-poxy one would download faster
<charlie-tca> oh! Maybe mine is just as good, then :-)
<cjwatson> slangasek: if poxy == large :-)
<slangasek> I dunno, maybe the pox causes packet fragmentation?
 * cjwatson applies antibiotics to his ethernet port
<cjwatson> ubuntustudio alternate posted
<cjwatson> ev: any ETA on a ubiquity fix for Kubuntu?
<Riddell> ev: my first test gave me the OOM issue again on Kubuntu
<Riddell> testing again with a console running to get more info
<ev> cjwatson: soonish.  I'm assuming we're only respinning for KDE, right?
<ev> Riddell: ouch.
<cjwatson> ev: I think so
<cjwatson> (for the time being)
<cjwatson> well, Ubuntu desktop does need a respin anyway, but I wasn't planning to wait for ubiquity
<ev> can you?  Looking at the code, it will break in the GTK frontend if you enter a username with ^[0-9A-Za-z] in it.  I'd like to just ressurect the hostname box, reusing the old code making a minor change to make it fit the current flow.
<Riddell> ev: yes lots of plugininstall.py instances running
<ev> Riddell: ughhhhh
<ev> Riddell: logs please
 * cjwatson has a horrible thought
<cjwatson> forgot to update OFFICIAL to say "Beta"
<cjwatson> you can tell I haven't done this for a while
<slangasek> at least that doesn't require respinning any livefses
<cjwatson> done, but all images built until now will say "Alpha" instead.  I don't plan to respin just for this unless somebody tells me I have to
<slangasek> I guess the noise it will cause with users is going to be fairly minimal
<Riddell> ev: http://muse.19inch.net/~jr/tmp/syslog  http://muse.19inch.net/~jr/tmp/debug
<cjwatson> I dunno, feel free to suggest I'm wrong, I know we've done differently in the past (but we had fewer images then)
 * Riddell out for an hour
<cjwatson> Ubuntu and Kubuntu desktops need to be respun anyway, and those are the highest-profile ones aside from perhaps Ubuntu server
<charlie-tca> We can release note xubuntu, if no other respin is needed
<slangasek> cjwatson: I don't feel strongly about it, particularly as none of the noise is going to be directed at me... :)
<cjwatson> heh
<cjwatson> wanna bet
<slangasek> hah :)
<cjwatson> respinning Ubuntu desktop
<slangasek> TBH I've always found it a little bit bothersome that, in preparation of the milestone, we prepare a series of *candidate* images that all get labeled "Beta" or "RC"
<cjwatson> also have commented out the crontab now that the day's normal ports builds have finished
<cjwatson> well, yeah, have always agreed but never saw an alternative
<slangasek> smarter on-the-fly ISO editing :-)
<cjwatson> short of sedding the ISO which gives me the shivers
<slangasek> I said smarter
<slangasek> ;)
<cjwatson> that was a metasyntactic sed :)
<cjwatson> given that there's code that parses .disk/info ...
 * cjwatson confirms that the mythbuntu desktop images have current mythbuntu-common, and posts
<cjwatson> slangasek: do we customarily post the upgrade tests around this time?
<slangasek> cjwatson: yes
<cjwatson> what build id do you use?  just the current date?
<cjwatson> ev: sorry, I didn't notice your comment above.  I can respin Ubuntu desktop again
<ev> cjwatson: okay
<ev> I've committed the hostname fix, just testing now
<ev> then I'll try to reproduce Riddell's scary bug
<ev> err and upload ubiquity, of course
<slangasek> cjwatson: current date, yes
<GrueMaster> Is there a respin planned for Ubuntu-Netbook on Arm?  If not, can we get them enabled in iso.qa.ubuntu.com?
<cjwatson> respin planned
<cjwatson> I'm just waiting for unity to publish
<GrueMaster> ok.
<cjwatson> I think just about all the candidates are up now except arm and DVDs, and of course the Ubuntu and Kubuntu desktop respins
<cjwatson> (for ubiquity)
<GrueMaster> Since there is a respin planned, is there a chance someone can tweak livecd to run /usr/lib/gdm/gdm-set-default-session une-efl prior to building squashfs for armel+dove?  Otherwise there is no way to boot past X.
<cjwatson> I had a respin planned but in like ten minutes
<cjwatson> I'm not sure how quick I can get a livecd-rootfs change in
<cjwatson> can you propose a branch of livecd-rootfs for merging anyway, though?
<cjwatson> is this beta-critical?  should I be building DVDs first, and waiting for this?
<GrueMaster> I wouldn't know where to start.  NCommander is planning on doing it, but he's in China on assignment.
<GrueMaster> This only affects armel+dove.
<GrueMaster> No other platforms would be affected.
<cjwatson> I mean, I can do it, but I'll probably get it slightly wrong
<GrueMaster> (or should).
<GrueMaster> ok.  Not sure how best to proceed then.
<cjwatson> something like http://paste.ubuntu.com/486429/?
 * GrueMaster hates being the only teammate on arm in the PST timezone.
<cjwatson> er, except with chroot $ROOT
<cjwatson> does gdm-set-default-session need $DISPLAY?
<GrueMaster> No display needed.  Here's what we currently have in jasper for omap images.  It is run on first boot.
<GrueMaster> if [ -e /root/usr/share/xsessions/une-efl.desktop ] && [ -e /root/usr/lib/gdm/gdm-set-default-session ];then
<GrueMaster>     chroot /root /usr/lib/gdm/gdm-set-default-session une-efl >>$LOGFILE 2>&1 || true
<GrueMaster> fi
<NCommander> GrueMaster: cjwatson: I'd be glad to do it, but I'm not quite awake enough to trust myself with an editor, and my Dove board is locked at Marvell :-/
<cjwatson> NCommander: does http://paste.ubuntu.com/486431/ seem plausible?
 * GrueMaster likes line 14 of the patch.  :D
<GrueMaster> The rest looks plausible to me, but I'm not familiar with the base code.
<cjwatson> committed
<cjwatson> lamont: do the buildds pull from bzr at the moment, or do I need to upload this livecd-rootfs change?
<lamont> cjwatson: they dist-upgrade ... livecd-rootfs is the then-current-for-the-distroarchseries each build
<cjwatson> ok, so the only delay is publication
<lamont> except that BuildLiveCD.sh is a manual migration from inside the chroot to outside, and should be done via RT
<cjwatson> that's not needed here
<cjwatson> UNE i386 building
<cjwatson> could somebody review livecd-rootfs 1.150 in the queue?  (there's also a 1.149 from earlier)
<cjwatson> I guess I'll build some DVDs after UNE i386
<cjwatson> oh, hell, will need to wait for ubiquity for that anyway, and respin UNE for it
<cjwatson> ev: now blocked
<ev> cjwatson: already uploaded
<ev> haven't got the mail yet though
<cjwatson> ah
<cjwatson> should arrive in a minute or so
<cjwatson> ev: po/Makefile.in seems to keep flipping back and forward between in the package and not in the package
<cjwatson> might benefit from a better clean rule or something
<ev> indeed, will do
<cjwatson> accepted though
<cjwatson> really must make publish-queue faster, by caching or something
<NCommander> cjwatson: that looks sane, but probably needs a smoke test
 * NCommander was going to implement it as a command line switch ...
<cjwatson> I figure it should behave as we want it to behave by default
<NCommander> cjwatson: well, if we ever get 3D, although it won't exist until natty at the earlist
<cjwatson> guess we can worry about it then
<NCommander> cjwatson: indeed. Thanks
<cjwatson> dinnertime; will likely be at least an hour until more spins are usefully possible
<kees> cjwatson: hi! do you have any plans to respin ISOs in the next day? I'm trying to coordinate a security publication. it's currently embargoed, but if you're going to respin, I'd like to get it out asap, otherwise I can wait until maverick is unfrozen.
<cjwatson> kees: planning to respin Ubuntu and Kubuntu desktops shortly, plus all arm and DVDs
<kees> cjwatson: define "shortly" ?
<kees> I suspect I should just probably wait until beta unfreezes. :)
<cjwatson> I thought it would be 10 minutes, but ubiquity needs another hotfix, so a couple of hours
<cjwatson> msg me the details?
<kees> sent
<slangasek> cjwatson: do you want to hand off any of this to me so you can have an evening?
<cjwatson> not sure yet, K is tired and might go to bed early
<cjwatson> I think I'll want to hand some of it off, just not sure what yet
<slangasek> ack
 * slangasek wonders who's still passing around bad recommendations about installing the 'grub' package
<cjwatson> the grub/Windows issues I blogged about recently are another source of this
<cjwatson> grub legacy's stage 1.5 is smaller and so less likely to suffer from it, though it does still happen
<cjwatson> (in fact I was thinking of backporting the workaround to legacy once I have it safely sorted out in 2)
<slangasek> ah
<slangasek> well whoever is telling people to install grub should tell them how to bloody configure it
<slangasek> instead of just telling them to install the package, which doesn't help anything
<cjwatson> I've added caching to publish-queue, so it's now MUCH quicker to run
<cjwatson> as in seconds rather than approaching ten minutes
<ScottK> Nice
<ScottK> cjwatson: Do you still want the livecd-rootfs changes in?
<cjwatson> yes please
<ScottK> cjwatson: Done
<cjwatson> thanks
<cjwatson> server installations are failing to boot after installation (reported by marjo); investigating
<marjo> thx cjwatson
<cjwatson> I wonder if your netbook is PAE-capable
<cjwatson> I see it in kvm, but kvm has given me grief with PAE in the past
#ubuntu-release 2010-09-01
<cjwatson> marjo: can you show me 'cat /proc/cpuinfo' on this system?
<stgraber> any reason the Edubuntu images aren't on the iso tracker ?
<cjwatson> not built yet, awaiting ubiquity builds
<stgraber> oh, ok, I didn't follow -release much today so didn't notice a mass rebuild because of ubiquity ;)
<cjwatson> or pending a respin, if you want to look at it that way
<cjwatson> plus figured you might want your new artwork in
<stgraber> indeed ;) thanks
<cjwatson> slangasek: could you take over?  builds to do and post: once ubiquity 2.3.12 is available (end of this publisher, except on armel), Ubuntu desktop and all DVDs; once ubiquity 2.3.12 [armel] and livecd-rootfs 1.150 are available, all armel images
<cjwatson> slangasek: there's still a question over Kubuntu installation but we may have to resolve that tomorrow at this point
<slangasek> cjwatson: ack
<cjwatson> thanks
<GrueMaster> slangasek: Can you clarify whether or not armel is getting a respin?  I see cjwatson's comment and it makes me wonder.
<GrueMaster> oh, nevermind.
 * GrueMaster eyes are getting fuzzy.
<slangasek> GrueMaster: armel respins triggered; ETA: evening
<GrueMaster> thanks.
<ScottK> slangasek: I think Kubuntu live is worth respinning with 2.3.12 since the oom problem we are having has an unknown cause, I think it's useful to test with the current code.
<slangasek> ScottK: ok; DVD builds are already in progress so it'll be a while before I can schedule those
<slangasek> but I will do so once the queue clears
<ScottK> slangasek: Thanks.  Just give me a ping when it's done please.  If I'm not still up I'll take a crack at it in my AM.
<slangasek> ScottK: 2 of 3 DVD sets done now; kubuntu live not far out
<ScottK> slangasek: Thanks.  Of course I'm just heading off to bed, so I'll pick it up in the morning.
<slangasek> righto
<ScottK> Kubuntu i386 and amd64 are up BTW (insomnia).
<slangasek> yep, posted
<ScottK> If nothing else the respin gave me a chance to verify Bug #608382 from lucid-proposed.
<ubot4> Launchpad bug 608382 in usb-creator (Ubuntu Lucid) (and 3 other projects) "Maverick images burned to usb key on lucid fail to boot - different syslinux version (affects: 50) (dups: 6) (heat: 270)" [High,Fix committed] https://launchpad.net/bugs/608382
<slangasek> cjwatson: respun everything that I understood was outstanding
<ScottK> slangasek: Could I have a Kubuntu live powerpc respin.  This one looks like it might be worth testing.
<slangasek> ScottK: running
<ScottK> Thanks.
<GrueMaster> is kubuntu/ports/daily-preinstalled queued up?
<ScottK> slangasek: ^^^ That could stand a respin too, if you didn't do it.
<slangasek> why is there both a kubuntu and a kubuntu-mobile cron.ports_daily-preinstalled in the crontab :/
<slangasek> spinning kubuntu
<ScottK> We do want images of both, but the mobile one is still somewhat broken atm.
<ScottK> Harrass NCommander for details.
<GrueMaster> Or on general principle.  :P
<ScottK> Sure.  Goes without saying.
<ara> morning all!
<ttx> ara: morning!
<ara> cjwatson, morning
<ara> cjwatson, any particular reason why ubuntu netbook i386 is not on the tracker?
<cjwatson> ara: oh, because it needed respun for new ubiquity and I forgot to tell slangasek this
<cjwatson> ara: I'll check and respin after breakfast
<ara> cjwatson, ok, thanks
<ara> cjwatson, enjoy breakfast
<ara> with the current problems in ubiquity, can we expect a respin later today?
<cjwatson> UNE posted
<cjwatson> possibly
<ogra> cjwatson, hmm, i wonder if we shouldnt make your livecd-rootfs change subarch independent so i can drop the hack from jasper
<ogra> (post beta indeed)
<cjwatson> up to you guys, I was just doing as I was told
<ogra> yeah, i wasnt brave enough to make it a default for all armel images since i wasnt sure if we would get GL drivers in time
<cjwatson> ev: I can accept this if you think it's useful, but I was hoping not to have to respin too many times and there are still several other things that look beta-critical outstanding
<cjwatson> so, what respins do you actively want for this?
<cjwatson> I assume not Kubuntu
<ev> cjwatson: we can wait.  I just wanted to have that queued up in case fixing other bugs takes longer than we have left
<cjwatson> ok
<ScottK> Nice.  I was going to accept a Universe package, but LP logged me out and the login service is down.
<cjwatson> ok, so wubi is sorted pending a rebuild; several important ubiquity bugs are fixed pending a rebuild, still a question mark over Kubuntu AFAIK
<ScottK> My best guess is that one of the 2.3.10 -> 2.3.12 changes reduced the incidence rate of process spawning causing the Kubuntu OOM problem so that my 1GB install was able to succeed while Riddell's 512MB install still failed.
 * ScottK was able to install with 2.3.10 after killing off all the non-essential processes he could find to free up memory.
<cjwatson> wubi> of course bug 613288 is still theoretically hanging over us
<ubot4> Launchpad bug 613288 in ubiquity (Ubuntu) "wubi installation failed - boot configuration store could not be opened (affects: 3) (heat: 141)" [Medium,Confirmed] https://launchpad.net/bugs/613288
<cjwatson> haven't heard of re-reports of that so far though
<cjwatson> marjo: regarding your server installation bug, I think it may be a recurrence of bug 227869.  Your /proc/cpuinfo may help to confirm.  If not that, then I guess it must be a kernel bug of some kind
<ubot4> Launchpad bug 227869 in base-installer (Ubuntu) "Server installer should not use -server kernel for non-PAE CPU's (affects: 1) (heat: 4)" [Medium,Triaged] https://launchpad.net/bugs/227869
<cjwatson> ttx: will bug 627963 require a server respin?
<ubot4> Launchpad bug 627963 in eucalyptus (Ubuntu) (and 1 other project) "CC doesn't start correctly, CLC struggles with certificates (affects: 1) (heat: 6)" [Critical,New] https://launchpad.net/bugs/627963
<ttx> cjwatson: if we find the cause, maybe
 * ttx is getting a bit tired of last-day eucalyptus partycrashers
<ttx> cjwatson: though at this point, I'd rather have the bug release-noted, I think
<cjwatson> ok, want to write something up for MaverickMeerkat/TechnicalOvervieww?
<cjwatson> -w
<ttx> I definitely will, but I need to spend a bit more time on this one.
<ttx> appears to be amd64-only
<ttx> though it takes so long to spin up a test that we hardly have a valid statistic sample
<ara> cjwatson, any decision made on the respin?
<cjwatson> definitely going to, but I'm unsure of timing
<cjwatson> Kubuntu seems too broken to release as yet, which means we need a new ubiquity anyway
<cjwatson> I think I'm going to go ahead and respin Ubuntu desktop once the current publisher run finishes; there are a few useful fixes there, and Wubi will be worth testing.  However my impression is that UNE and Kubuntu will need to wait for more ubiquity work
<cjwatson> ev: ^- does that sound sane?
<ara> cjwatson, so, you're saying, that, although ubuntu desktop will be respin now, it will be respin yet again once the changes in ubiquity gets published?
<cjwatson> I don't think that's necessary if the changes aren't relevant to Ubuntu desktop
<cjwatson> it would be for final, but for beta, not so worried
<cjwatson> bah, inattention loses me time again, forgot to install in OEM mode
<lamont> cjwatson: as a btw sort of thing, someday soon, I'll be upgrading ross to lucid (from karmic), as well as royal.  I'll wait until after beta, of course.
<cjwatson> ok
<cjwatson> adare?
<ev> cjwatson: seems reasonable to me
<ScottK> Note: The stack of kde uploads that are coming for intended for post-beta.
<cjwatson> new Ubuntu desktop posted, fixes a couple of installer issues and (hopefully) Wubi
<ara> cjwatson, thanks!
<charlie-tca> will xubuntu be rebuilt?
<cjwatson> if you want it to be
<charlie-tca> if it is fixing some of these serious bugs, yes
<charlie-tca> desktop only
<ara> cjwatson, are the DVDs going to be respin as well?
<charlie-tca> I think the static ip bug I reported was fatigue on my part. I am running another install to verify, but could not reproduce yet
<cjwatson> ara: good question
<cjwatson> what's your (plural) capacity like?
<cjwatson> charlie-tca: xubuntu desktop respinning
<charlie-tca> Thank you
<ara> cjwatson, our capacity is low... but I think it is better to do the effort. It is a bit strange to release a buggy dvd (when teh desktop is working fine)
<cjwatson> I'll start it off right after Xubuntu, then
<ScottK> cjwatson: If usb-creator is going to -updates, then I think the notes in tech overview (or wherever it landed) need to be updated.
<cjwatson> yes
<cjwatson> skaet: ^- could you do the honours?  it's the one about 10.04 usb-creator being unable to properly create maverick USB sticks - there's now an update in lucid-updates for it (or will be after the next publisher run)
<skaet> cjwatson,  sure.  will take a pass at it.
<seb128> gwibber stopped the old authentification way
<seb128> ups
<seb128> twitter stopped the old authentification way
<seb128> the gwibber update in the queue fix that
<ScottK> seb128: How are you fixing Lucid?
<seb128> I don't think it's a beta blocker but I'm just mentioning it in case somebody would like to slip it in
<ScottK> For Kubuntu we have a similar issue to consider.
<seb128> or if there is a slot between resprins
<seb128> ScottK, you should ask kenvandine
<ScottK> OK.
<seb128> he did the changes to gwibber
<skaet> ScottK,  doublechecking - the one corresponding to bug 608382?
<ubot4> Launchpad bug 608382 in usb-creator (Ubuntu Lucid) (and 3 other projects) "Maverick images burned to usb key on lucid fail to boot - different syslinux version (affects: 51) (dups: 6) (heat: 272)" [High,Fix released] https://launchpad.net/bugs/608382
<ScottK> skaet: Yes.
<skaet> ScottK,  thanks.
<cjwatson> Xubuntu desktop reposted
<ara> charlie-tca, ^
<charlie-tca> Thank you
<cjwatson> Ubuntu DVD respinning
<ara> cjwatson, thanks
<cjwatson> really must automate all this website fiddling
<GrueMaster> cjwatson: What issues were fixed in the installer earlier?  I'm seeing an odd issue of oem-config crashing, but ogra is not.  http://paste.ubuntu.com/486820/
<ogra> wow, that looks weird
<ogra> i finished two test installs successfully here
<ogra> no issues at all (beyond known bugs)
<GrueMaster> I'm going to try zeroing & reflashing my SD (just in case).
<cjwatson> GrueMaster: I don't know what that is; ev might.  The fixes in 2.3.13 were bug 628011 and bug 625258
<ubot4> Launchpad bug 628011 in ubiquity (Ubuntu) "Ubiquity crashes on Ubuntu Netbook (affects: 1) (heat: 6)" [Undecided,Fix released] https://launchpad.net/bugs/628011
<ubot4> Launchpad bug 625258 in ubiquity (Ubuntu) "ubiquity crashed with UnboundLocalError in part_ask_option_changed() (affects: 11) (heat: 54)" [High,Fix released] https://launchpad.net/bugs/625258
<GrueMaster> Neither of those should affect us.  I'll reflash/retest before filing anything.
<ev> GrueMaster: useQuirks isn't from ubiquity and can be ignored - it's been appearing since fairly early on in the release
<ev> GrueMaster: do you have a traceback?
<GrueMaster> ok.  First time I've seen it on armel.
 * ogra has never seen it 
<ogra> part_ask_option_changed() surely cant affect us on preinstalled images :)
<cjwatson> seb128: I think it's unlikely that we can get it into many images, but I don't mind accepting it so that it's there for post-beta.  Done
<GrueMaster> No traceback at the moment.  If I can reproduce it, I'll gather all the info.  Just never saw this oddity before.
<ogra> and the other one is a partitioning issue too
<GrueMaster> that's why I said they wouldn't affect us.  :P
<didrocks> hum, for the netbook image, I just get the ackwardly famous "unknown keyword" on syslinux
<cjwatson> upgrade to the usb-creator that *just* landed in lucid-updates (may not quite be on archive.u.c yet)
<didrocks> even the maverick version has been upgraded?
<didrocks> (it was only on lucid before IIRC)
<seb128> cjwatson, thanks
<cjwatson> maverick hasn't, but maverick didn't suffer from the problem in the first place PROVIDED that you also have maverick's syslinux installed
<cjwatson> well, it suffers from the problem the other way round, for building lucid sticks on maverick; that hasn't been fixed yet
<ScottK> Right, but that's not what the bug was about.
<didrocks> hum weird, I created a desktop live yesterday from my laptop (maverick up-to-date) without any issue, just this time, creating the netbook live with the current iso make the error appear
<ScottK> Probably ought to have another bug for that.
<didrocks> will double check with the desktop iso first. or maybe I pick the wrong iso in the list, let me check
<didrocks> (as adding an iso doesn't select it in usb-creator, it's more than possible)
<didrocks> ok, was my fault. I should have select the wrong iso in usb-creator (probably a jaunty one). I should log a bug and fix that when you add an iso to usb-creator, it should select it. Testing the netbook iso now
<ttx> cjwatson: eod here, server looks good, except some racy issues in eucalyptus that we'll document in releasenotes
<ttx> I'll check in later today to answer any question, and be around early tomorrow.
<GrueMaster> Ok, not reproducing oem-config crash.  Must have been an odd fluke with my SD.
<cjwatson> ttx: ok, thanks
<didrocks> cjwatson: do you know when the .1 iso for netbook respin will be published?
<cjwatson> for netbook I was waiting for ev to sort out this install-from-USB bug
<didrocks> ok, thanks
<ara> If bug 627672 is not going to be fixed for Beta, it should be clearly release noted
<ubot4> Launchpad bug 627672 in ubiquity (Ubuntu) (and 1 other project) "[Maverick Beta] install from USB stuck retrieving files 2/6 Hp Mini (affects: 2) (dups: 1) (heat: 16)" [Undecided,New] https://launchpad.net/bugs/627672
<ara> in my opinion it is quite important
<ara> it makes a lot of installations fail
<cjwatson> ara: 17:29 <cjwatson> for netbook I was waiting for ev to sort out this install-from-USB bug
<cjwatson> Ubuntu DVDs posted
<skaet> cjwatson, pitti,  did the fix to bug 625110 make it in?
<ubot4> Launchpad bug 625110 in udev (Ubuntu Maverick) (and 1 other project) "usb-modeswitch 1.1.4 doesn't switch any device (affects: 2) (dups: 1) (heat: 22)" [High,Fix committed] https://launchpad.net/bugs/625110
<ara> cjwatson, OK, thanks
<ScottK> skaet: Still in the queue.
<ScottK> https://launchpad.net/ubuntu/maverick/+queue?queue_state=1&queue_text=udev
<skaet> ScottK,  thanks.  :)
<ScottK> You're welcome.
<slangasek> does someone know what the deal is with kdm and plymouth in maverick? (bug #628195)
<ubot4> Launchpad bug 628195 in plymouth (Ubuntu) "plymouthd keeps running after entering into kdm (not with gdm) (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/628195
<ScottK> Sure enough.  It does.
<ScottK> root       300     1  0  2883  3540   1 00:46 ?        00:01:39 /sbin/plymouthd --mode=boot --attach-to-session --pid-file=/dev/.initramfs/plymouth.pid
<slangasek> ScottK: since the only plymouth change since lucid is to print "10.10" instead of "10.04", I'm pretty sure this is a regression in the kdm patch to handle stopping plymouth; but the previous bug report I triaged over that way seems not to have resulted in any action
<slangasek> bug #618450
<ubot4> Launchpad bug 618450 in kdebase-workspace (Ubuntu) (and 1 other project) "plymouthd does not quit on starting kdm (affects: 3) (heat: 274)" [Undecided,New] https://launchpad.net/bugs/618450
<ScottK> I'm looking for the init file now.
<slangasek> oh, that one was about using non-Ubuntu packages
<slangasek> it's not about the init file - kdm itself needs to stop plymouth directly with the correct options in order to do the smooth transition to X
<slangasek> and lucid has the patch to do this - I don't know about maverick
<ScottK> So http://bazaar.launchpad.net/~kubuntu-members/kdebase-workspace/ubuntu/annotate/head:/debian/kdm.upstart isn't where we should look?
<slangasek> no
<ScottK> ok
<ScottK> I think I found it.
<slangasek> ScottK: debian/patches/kubuntu_34_kdm_plymouth_transition.diff, in Lucid
<ScottK> Yep.  It changed in Maverick and I think not for the better.
<ScottK> slangasek: http://bazaar.launchpad.net/~kubuntu-members/kdebase-workspace/ubuntu/annotate/head:/debian/patches/kubuntu_34_kdm_plymouth_transition.diff looks like rev 387 is the deadly one.
<ScottK> Riddell: Can you have a look ^^^^
<slangasek> hmm, that really seems to be mostly whitespace changes
<slangasek> sigh, the previous revision nuked the DEP3 patch header
<slangasek> but otherwise also does not change the patch
<ScottK> Maybe it is.
<slangasek> so I guess the breakage is due to changes to other code within kdm
<ScottK> slangasek: apachelogger is looking at it.
<slangasek> ScottK: ok, cool
<GrueMaster> Not getting very far with kubuntu on omap.
<GrueMaster> At least oem-config isn't crashing, though.
<ScottK> GrueMaster: Does the preinstalled image use ubiquity?
<GrueMaster> Somewhat.  It uses oem-config.
<GrueMaster> But it got through all that.  Should have restarted into kdm.
<GrueMaster> I've been experiencing some oddities with SD cards, so I'm trying again after zeroing one out.
<ScottK> ubiquity in KDE is currently having excessive ram use problems.
<ScottK> So it wouldn't suprise me if it had trouble on armel.
<GrueMaster> Especially on beagleboard w/ 256M.
<ScottK> Yep.
<ScottK> It finally got to where it succeeded on my 1GB laptop, but Riddell's 512MB VM still had trouble.
<ScottK> ev was last seen saying he'd finally replicated the issue.
<elmo> cjwatson, et al.: has anyone whined at you about cdimage.u.c being run out of disk space?
<cjwatson> nope
<cjwatson> I can prune some DVD builds
<elmo> thanks
<Daviey> Release Team: Did ttx send some release notes regarding known issues for UEC Beta?
<cjwatson> elmo: freed up 40G, does that help?
<cjwatson> or thereabouts
<elmo> cjwatson: perfect, thanks
<skaet> Daviey, haven't seen any notes from ttx.   Can you please send what you have?
<Daviey> skaet, Hah.. twas just about to give up and go to bed... Will compose them now.
<skaet> Daviey,  thanks!  :)
#ubuntu-release 2010-09-02
<cjwatson> skaet: I think we are on the path to fixes for both the Kubuntu OOM and the USB infinite loop
<cjwatson> it may be a slightly long night
<Daviey> skaet, yo got mail; note it needs ack'ing by ttx .:)
<GrueMaster> cjwatson: what is the issue with kubuntu?  I don't think it affects armel, as I am currently running it on a beagleXM.
<cjwatson> GrueMaster: lots of plugininstall processes being spawned, using up all memory
<cjwatson> I don't know why it would not affect armel
<GrueMaster> We only run oem-install, not full ubiquity.
<GrueMaster> I've had other issues with kubuntu, but oem-install seems to get through fine.  Nothing in the logs indicating oom messages.
<GrueMaster> (and on a 256M system, they become noticable quickly).
<cjwatson> oem-config probably isn't affected, since the tarot cards seem to indicate that it's mostly to do with two parallel debconffilters
<cjwatson> which doesn't happen in oem-config
<GrueMaster> Ok.  That makes me feel a little better.  I hate repining on armel if avoidable.
<GrueMaster> btw:  the livecd fix for dove worked great.
<cjwatson> cool
<cjwatson> somebody available shortly for a ubiquity review?
<cjwatson> (Riddell volunteered on #ubuntu-installer)
<cjwatson> marjo: did you see my comment about your server installation problem?
<cjwatson> 13:22 <cjwatson> marjo: regarding your server installation bug, I think it may be a recurrence of bug 227869.  Your /proc/cpuinfo may help to confirm.  If not that, then I guess it must be a kernel bug of some
<ubot4> Launchpad bug 227869 in base-installer (Ubuntu) "Server installer should not use -server kernel for non-PAE CPU's (affects: 1) (heat: 4)" [Medium,Triaged] https://launchpad.net/bugs/227869
<cjwatson>                  kind
<cjwatson> so, I think the right answer here is probably an alarm to wake me up in 1.5 hours or so to do the necessary respins
<cjwatson> $ wait-for-package ubiquity_2.3.14 && { echo kubuntu; buildlive kubuntu && for-project kubuntu cron.daily-live; echo ubuntu-netbook; buildlive ubuntu-netbook && for-project ubuntu-netbook cron.daily-live; echo kubuntu-mobile; buildlive kubuntu-mobile && for-project kubuntu-mobile cron.daily-live; echo kubuntu dvd; buildlive kubuntu-dvd && for-project kubuntu cron.dvd; }
<cjwatson> no alarm needed after all, but perhaps somebody could post those to the tracker as they appear?
<micahg> hi, I'm looking at bug 628558 which clearly needs an FFe, but I can't find an upstream changelog, we currently have v1.2 which is 2 yrs old and 2.4 was apparently released about 6 months ago, opinions?
<ubot4> Launchpad bug 628558 in calendarserver (Ubuntu) "RQ: update to calendarserver v2.4 from Debian (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/628558
<micahg> oh, the package is in universe and only has 1 rdepend
<ScottK> micahg: Still needs FFe, but if you can fix that, then it won't be hard to get.
<micahg> ScottK: I'm asking about the FFe :)
<ScottK> micahg: You still need to fill it out as best you can.
<ScottK> If it's totally broken to -> working to some degree that's good to know.
<micahg> ScottK: quadrispro seems to know more about it, I'll ask him if he's interested in filing the FFe, thanks
<ScottK> OK.
<slangasek> kubuntu, ubuntu-netbook respins posted
<slangasek> kubuntu-mobile failed to build (again)
<persia> What broke there?  The log seems oddly truncated.
<slangasek> no clue
<ScottK> persia: I don't think we ever got it to build the livefs out of Universe, so it would fail.
<persia> ScottK, I thought you committed that change.  I wonder why NCommander was able to build some images before.
<persia> Anyway, probably not most critical at this time of today.
<ScottK> persia: He built alternates as a test.
<ScottK> AFAIK we've yet to have a live.
<ScottK> Not sure.
<persia> http://cdimage.ubuntu.com/kubuntu-mobile/ports/daily-preinstalled/current/ is live, but not i386.  Old as well.
<slangasek> kubuntu dvds posted
<persia> Maybe he'll be able to see if he has time to check backscroll.
<NCommander> persia: which change?
<persia> NCommander, building kubuntu-mobile against universe.
<persia> I know the metapackage can't do that, but I thought the livefs was built that way.
<persia> (or I'd expect to see some depedencies-cannot-be-satisfied type of error).
<persia> Images aren't building for mysterious reasons.
<NCommander> persia: images should just build if livecd-rootfs is correct.
<persia> That's what I thought, but my limits for livecd-rootfs are "it worked for my locally", which aren't necessarily a good match for what is happening.
<ttx> Morn
 * ttx looks at proposed releasenote text from Daviey
<Daviey> ttx, is it ok?
<ttx> I'm editing it
<ttx> Daviey: as a general rule of thumb, only significant bugs are mentioned. Otherwise this document would be quite long
<ttx> + bugs that are significant tyo people upgrading (starting from beta)
<Daviey> ttx, ack
<ttx> see https://wiki.ubuntu.com/MaverickMeerkat/TechnicalOverview?action=diff&rev2=71&rev1=70
<ttx> I dropped the two harmless ones
<ttx> Daviey: you didn't mention bug 628055 ?
<ubot4> Launchpad bug 628055 in eucalyptus (Ubuntu) "Instances don't go to "running" state: Security Labeling error running aa_change_profile() (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/628055
<Daviey> ttx, Yeah.. perhaps i should have
<Daviey> ttx, it seems inda abstract, and not exactly confirmed
<ttx> Daviey: not sure, since we couldn't reproduce it
<ttx> Daviey: ack
<ara> morning all!
<ara> Riddell, is Kubuntu going to be respin? (has been?)
<Riddell> ara: has been
<ara> Riddell, but it is not the one in the tracker, is it?
<Riddell> yes, 20100902
<ara> Riddell, good, thanks!
 * ara resyncs
<Riddell> although I don't think cjwatson's mega rebuild command included kubuntu alternate and we probably do want to respin those for bug 627549
<ubot4> Launchpad bug 627549 in ubiquity (Ubuntu Maverick) (and 1 other project) "ubiquity crashed in kubuntu oem mode (affects: 1) (heat: 6)" [High,Fix released] https://launchpad.net/bugs/627549
<didrocks> netbook ubiquity is still crashing for me if I select Specify partitions manually (advanced). No trace in the command line. Can somebody confirms?
<didrocks> (20100902)
<Riddell> check /var/log/installer/debug and /var/log/syslog for output
<didrocks> thanks Riddell, apparently a protection errorâ¦
<Riddell> ah, one of them
<didrocks> ara: can you add "Install (manual partitioning)" to the netbook testcase? or should I file it under " Install (entire disk)" and specify the issue?
 * didrocks tries ubuntu desktop to see if I can reproduce there too
<ara> didrocks, we cannot add testcases on the fly, it is a decision made by the release team
<ara> didrocks, you can put it someplace else and specify the issue in the comments, i.e.
<ara> didrocks, if you can try it with ubuntu desktop that would be great
<didrocks> ara: ok, so, if I can't reproduce in the desktop CD, I'll do that
<didrocks> sure
<ara> didrocks, thanks!
<didrocks> yw ;)
<ev> didrocks: I just started a manual partitioning install with Kubuntu desktop without issue.  Do let me know if you can reproduce that crash.
<ev> oh, damn
<ev> kubuntu desktop is broken.  The fix we came up with last night has a corner case.
<Riddell> ev: oh?
<Riddell> I already did a successful install on a virtual machine
<ev> manual partitioning triggered it for me, but I suspect it might be a timing thing
<ara> :-(
<ev> investigating now
<Riddell> I'm doing manual partitioning on a machine here, going ok so far
<ara> ev, if we can identify the root cause and it is a very special case, we might release note it
<ev> sure
<ara> ev, if the USB disk error is not fixed for Ubuntu desktop, I think we might release note it. What do you think? A lot of people installs with a USB key, not only netbook
<ev> well, it's fixed, just not in any spinned CD
<ev> but yes, I think it's most certainly worthy of a release note
<ara> ev, does not the netbook edition include the fix?
<ev> it does
<ara> that's what I thought
<ev> sorry, I misspoke
<didrocks> ev: no issue on the desktop CD for me, it's only the netbook one (under the live session), trying in the installer mode now
<didrocks> ev: FYI: http://paste.ubuntu.com/487118/
<Riddell> kubuntu manual partitioning with oem is good here
<cjwatson> we *could* respin Ubuntu desktop, but it seems to me that there are more than enough respins going on
<cjwatson> I'll do it if QA says to
<cjwatson> Riddell: you want a Kubuntu alt respin then?
<didrocks> ok, manual partition seems to fail only under the unity live, not in the installer mode
 * didrocks reboots once again to confirm
<Riddell> cjwatson: not yet but now I confirmed OEM works I'd like to
<Riddell> or you can
<cjwatson> on its way
<Riddell> thanks
<didrocks> ok, I'm filing the bug for crash in manual partitionning under unity under the " Install (entire disk)" as there is nothing for it in iso.qa.ubuntu.com and I can't reproduce it in the desktop CD
<ara> didrocks, OK, please file the bug and upload the logs to it
<didrocks> ok, filed, in fact, every option is crashing under unity
<didrocks> (wasn't the case last alpha)
<cjwatson> Kubuntu alternate posted
<ara> Riddell, I have installed Kubuntu OEM in a Netbook, and when finished, I get the Kubuntu Netbook interface (expected), but I don't get the "prepare for end user icon"
<Riddell> ara: yes me too, I was premature in my ticking the success box
<Riddell> ara: did you have internet access while installing?
<ara> Riddell, no, I didn't
<Riddell> ara: do you have oem-config-kde installed?
 * ara checks
<cjwatson> Riddell: I've created https://help.ubuntu.com/community/MaverickUpgrades/Kubuntu, but it still needs work that I can't really do as a non-Kubuntu-user (and I don't know what to replace 'update-notifier-kde -u' with since I see that's now in universe and there's a new notification helper).  Could you (have somebody) look over it, please?
<ara> Riddell, no, it does not have it
<Riddell> cjwatson: yes, that's on my todo list for this morning, thanks for starting
<Riddell> ara: checking if having internet during install helps, although there's no reason why it should really
<Riddell> ara: please file a bug with logs et al
<ara> Riddell, will do
<ara> Riddell, bug against? ubiquity?
<Riddell> yes
<cjwatson> didrocks: hm, so not obviously a ubiquity problem since the crash is in libglib
<cjwatson> didrocks: can you repeat, but with 'debug-ubiquity' on the kernel command line (or starting ubiquity with the -d option)?
<didrocks> cjwatson: yeah, I'm quite puzzled, I have also pinged unity guys
<didrocks> sure
<cjwatson> didrocks: that should give you more useful /var/log/installer/debug
<didrocks> doing now
<seb128> didrocks, hum, crash in glib, do you have bug?
<cjwatson> damn, I should sort out image pre-publishing shouldn't I
<seb128> or a stacktrace
<cjwatson> seb128: bug 628672
<ubot4> Launchpad bug 628672 in ubiquity (Ubuntu) "Crash of ubiquity under unity (affects: 1) (heat: 6)" [Critical,New] https://launchpad.net/bugs/628672
<cjwatson> no stacktrace in evidence
<didrocks> the protection error make it think that something under mutter is interferingâ¦
<seb128> didrocks, what protection error?
<cjwatson> that's just kernel-speak for SIGSEGV
<seb128> it seems just a crash
<seb128> weird that apport didn't catch it
<didrocks> ok, I mispoke, sorry
<seb128> didrocks, do you get the issue every time?
<didrocks> seb128: yeah, everytime and only under the unity session
<didrocks> no in the installer mode, not in the desktop live session
<seb128> ok, then get a stacktrace
<seb128> install libglib2.0-0-dbg
<seb128> run ubiquity and attach gdb to the process which crashes
<seb128> then get the crash
<seb128> I'm not sure why apport doesn't catch it...
<ara> Riddell, bug 628681
<ubot4> Launchpad bug 628681 in ubiquity (Ubuntu) "Kubuntu OEM did not install oem-config-kde (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/628681
<cjwatson> Sep  2 08:07:09 ubuntu ubiquity: #015Err cdrom://Kubuntu 10.10 _Maverick Meerkat_ - Beta i386 (20100902)/ maverick/main oem-config-kde all 2.3.14
<cjwatson> Sep  2 08:07:09 ubuntu ubiquity: #015  Unable to unmount the CD-ROM in /cdrom/, it may still be in use.
<cjwatson> sigh
<didrocks> ubiquity log before: http://launchpadlibrarian.net/54764926/ubiquity_debug.log
<didrocks> getting the stacktrace now
<cjwatson> hello, apt, why are you even trying to unmount
<cjwatson> freaky.  install_extras should be well before cleanup so all the stuff that tells apt not to do that should still be in place
<cjwatson> guess I'll rsync and have a look
<cjwatson> not sure we'll have time to fix that for beta though
<Riddell> it's not too important for beta, people can install oem-config-kde, I've also done a successful oem install on my desktop so it doesn't happen every time
<ara> Riddell, can you add it to known bugs under TechnicalOverview, then?
<ev> cjwatson: perhaps the install/plugininstall split broke that somehow
<cjwatson> I was thinking that, but they're both in plugininstall
<ev> well, install_misc, but yeah
<ev> hm
<cjwatson> Riddell: just want to check: in lucid, we put kubuntu-netbook on releases.u.c.  Am I right in believing that (a) kubuntu-netbook has been replaced by kubuntu-mobile for i386 (b) the latter doesn't build right now?
<didrocks> libappmenu :/
<didrocks> seb128: what's the environment variable to export already to disable it?
<seb128> didrocks, unset UBUNTU_MENUPROXY
<didrocks> emptying UBUNTU_MENUPROXY?
<didrocks> ok
<didrocks> trying that to confirm
<seb128> didrocks, I bet it's the same crash that the gnome-display-properties one
<seb128> didrocks, is that i386?
<cjwatson> and can a UNE person remind me which arm images are being released?
<seb128> didrocks, I can scp my update deb if you want to test
<didrocks> seb128: yes, i386
<didrocks> seb128: sure, please :)
<seb128> the one with the crash fix backport
<seb128> ok
<didrocks> ogra: see cjwatson's request? ^
<cjwatson> starting prepublication of the images we have now, anyway
<cjwatson> since that's late
<cjwatson> Checksumming simple tree (pool) ...
<cjwatson> stat: cannot stat `kubuntu/maverick/kubuntu-10.10-alpha2-alternate-amd64.iso': No such file or directory
<mvo> hm, is it ok to upload into the queue for stuff that is trivial? or will that cause work for someone who reviews the queue? I guess its ok, but I want to double check
<cjwatson> WTF
<cjwatson> mvo: it's ok
<mvo> thanks
<seb128> mvo, it's ok to upload for anything I think if you see the queue
<seb128> mvo, it's just that you better ping if you want things reviewed ;-)
<mvo> seb128: haha - ok :)
<seb128> didrocks, http://people.canonical.com/~seb128/appmenu-gtk_0.1.7-0ubuntu2_i386.deb
<mvo> so unfreezing will meld the icecaps :)
<didrocks> seb128: thanks, trying
<cjwatson> ok, some kind of cruft left over from alpha-2 I guess
 * cjwatson cleans up
<cjwatson> skaet: have fixed up publish-image-set.py in lp:ubuntu-archive-tools ('bzr up' to see) and am running through stuff in './publish-image-set --prepublish'.  It doesn't have the right bits for ARM yet, but that's OK, prepublication is idempotent
<mvo> seb128: thanks, nothing beta-critical, just a a bunch of fixes
<didrocks> seb128: cjwatson: the appmenu update fixing it
<seb128> I guess that's worth respinning UNE images?
<cjwatson> sounds like it
<didrocks> updating the bug
<seb128> cjwatson, if we respin can we fix bug #623953 as well?
<ubot4> Launchpad bug 623953 in unity (Ubuntu Maverick) (and 2 other projects) "new tiles are unresponsive (affects: 2) (dups: 1) (heat: 14)" [High,Confirmed] https://launchpad.net/bugs/623953
<seb128> cjwatson, https://code.launchpad.net/~unity-team/unity/unity.fix-unreactive-tiles/+merge/34293 is the diff
<seb128> cjwatson, the unity launcher is pretty useless otherwise, icons don't react to clicks
<cjwatson> is it uploaded?
<seb128> or do you just want appmenu-gtk updates?
<seb128> no but I've both locally
<seb128> ie I can upload in the next 10 minutes
<cjwatson> appmenu not uploaded either?
<seb128> no
<seb128> I was waiting on didrocks confirmation
<cjwatson> please upload both ASAP, then
<seb128> ok
<seb128> didrocks, ^ doing those
<didrocks> seb128: thanks!
<cjwatson> elmo: pre-publishing to releases, please let me know if it ENOSPCes
<seb128> cjwatson, ok, appmenu-gtk uploaded
<seb128> cjwatson, let's play safe and not do the unity change, it's not an important issue for the install and we will get the update after beta
<cjwatson> ok
<seb128> default launchers icons are working that's enough to test unity
<cjwatson> fine, your call
<seb128> didrocks, ^
<didrocks> cjwatson: seb128: ok, will do the change in unity with today's release in any case, after beta freeze. Thanks :)
<cjwatson> appmenu-gtk accepted
<seb128> thanks
<cjwatson> should have a new ubiquity this publisher run as well
<ogra> cjwatson, omap3 and 4 shoudl be released, i cant tell about dove, thats fully un NCommander's hands
<ogra> s/un/in/
<NCommander> cjwatson: dove is about as good as its going to get. ubiquity crashes when you attempt to install, and the icon fails to show up in the launcher
<ogra> NCommander, do you actually want to release in that state ?
<ogra> doesnt really sound like it makes sense if you cant install at all
<cjwatson> so, just to clarify, this corresponds to the ISO tracker entries "Ubuntu ARM Preinstalled omap3", "Ubuntu ARM Preinstalled omap4", and possibly "Ubuntu Netbook armel+dove".  What about "Kubuntu Netbook Arm (omap)"?
 * cjwatson curses the inconsistent naming
<Riddell> kubuntu netbook arm should now be just kubuntu arm and is http://cdimage.ubuntu.com/kubuntu/ports/daily-preinstalled/20100901/
 * ogra didnt make up the kubuntu names, i dont think the kubuntu installs worked 
<Riddell> GrueMaster can confirm
<Riddell> he says they work fine, if slow
<ogra> hmm, i saw several bugs of ubiquity not working i think
<cjwatson> doesn't need additional confirmation I think, just checking
 * ogra checks again
<cjwatson> ogra: he was saying last night that it was fine
<ogra> ok, then release it too
 * cjwatson tries to work out how to encode all this in publish-image-set.py
<ogra> oh, i see, bug 628581 ... it worked but produced a crash file which resulted in the bug i saw passing by during triage
<ubot4> ogra: Bug 628581 on http://launchpad.net/bugs/628581 is private
<Riddell> we should also have kubuntu-mobile images for i386 and arm but seems something is up with the Publishing part of the script http://people.canonical.com/~ubuntu-archive/cd-build-logs/kubuntu-mobile/maverick/daily-live-20100902.log
<cjwatson> Riddell: "Kubuntu ARM" would be painful to deal with.  Shouldn't there be a "desktop" or "mobile" or something in there?
<cjwatson> it's "Kubuntu Desktop i386" after all not "Kubuntu i386"
<cjwatson> publish-image-set.py has started to try to parse this so regularity would help
 * ogra agrees it should be K"ubuntu Desktop arm" and "Kubuntu Netbook arm"
<cjwatson> the image is "maverick-preinstalled-desktop-armel+omap.img.gz"
<ogra> oops, wrong quotes
<Riddell> there is no Kubuntu netbook, netbook and desktop are the same image now
<cjwatson> then just "Desktop"
<ogra> Riddell, hmm ? whats the kubuntu-mobile image then ?
<Riddell> ogra: that's mobile, mobile is different from netbook
<cjwatson> best if it corresponds to the filename
<ogra> Riddell, ok
 * ogra admits he has no clue about kubuntu images at all beyond knowing that it takes minutes to move the cursor if they boot 
<NCommander> cjwatson: The images boot, but we have a regression in ubiquity (probably been there for awhile, but since we didn't use ubiquity on ARM until recently this cycle ...) that prevent installation
<NCommander> cjwatson: I'm on the fence if we should release them, though a part of me is leaning towards no
<ogra> just to clearify ... you are talking about dove :) (omap3/4 is all fine)
<NCommander> indeed
 * cjwatson gives up on trying to encapsulate all this in a single regex
<seb128> re, system crash again on user switching
<seb128> cjwatson, ok, got dx to confirm the unity change has been reviewed and I uploaded
<seb128> cjwatson, up to you to accept it or not
<seb128> we don't need it on the beta image, it's just a would be nice to have
<seb128> you can also accept it after the image build if you want so it's available for upgrades after beta
<cjwatson> at this point it would delay things by an extra hour
<cjwatson> so I'd prefer not, sorry
<seb128> ok, no worry
<seb128> as said it's not a blocker for the install in any way
<seb128> maybe accept it when images are built
<seb128> so people can get upgrade after install
<cjwatson> well, actually, I need to put the publisher on manual anyway
<cjwatson> accepting for beta
<seb128> thanks!
<seb128> sorry for being late I wanted to confirm with somebody from the unity team before uploading it
<seb128> then my box crashed again on user switching
<ara> cjwatson, ubiquity is crashing for me for netbook, how can I tell if it is the same issue didrocks was having?
<cjwatson> ara: can you show us syslog?
<didrocks> ara: i386?
<cjwatson> ogra: is there documentation somewhere that cdimage could link to on how to use preinstalled images?
<ara> yes, i386
<seb128> ara, try unset UBUNTU_MENUPROXY
<seb128> ara, then run ubiquity
<ara> seb128, ok
<seb128> ara, ok get the appmenu-gtk update on launchpad
<didrocks> or install http://people.canonical.com/~seb128/appmenu-gtk_0.1.7-0ubuntu2_i386.deb :)
<seb128> test the official one rather
<didrocks> already published?
<ogra> cjwatson, hmm, http://testcases.qa.ubuntu.com/Install/ARM/PreinstalledImage#Beagleboard%20ARM%20Image%20Testing shoul i put that on the official wiki ?
<seb128> ara, https://edge.launchpad.net/ubuntu/+source/appmenu-gtk/0.1.7-0ubuntu2/+build/1943471/+files/appmenu-gtk_0.1.7-0ubuntu2_i386.deb
<ogra> *should
<seb128> ara, you can just install that and run ubiquity again
<seb128> ara, if you want to try the fix rather than the workaround
<ara> seb128, OK, will try
<seb128> ara, could be better so you confirm the fix works
<seb128> ara, thanks!
<cjwatson> publisher running, all but armel created
<cjwatson> ogra: yes please, perhaps minus verification stuff
<ara> cjwatson, seb128, didrocks: the fix worked
<seb128> great
<didrocks> ok, same bug so, great :)
<seb128> ara, thanks for confirming
<ara> seb128, np :)
<Riddell> cjwatson: do you know what needs fixed to get kubuntu-mobile images published?
<cjwatson> probably
<cjwatson> working on preinstalled-* right now though
<cjwatson> which path on cdimage exactly?
<ogra> cjwatson, i made https://wiki.ubuntu.com/ARM/OMAP as a master page which will link the instructions per release
<ogra> cjwatson, we used to have http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/ for alpha
<cjwatson> ogra: I was talking to Riddell ...
<cjwatson> kubuntu-mobile isn't in ubuntu-netbook :)
<cjwatson> thanks for the URL, I'll use that
<ogra> heh, k
<cjwatson> Riddell: I have a rather experimental set of changes which should do it.  maybe
<Riddell> cjwatson: http://cdimage.ubuntu.com/kubuntu-mobile/daily-live/20100902/
<cjwatson> oh, you mean publishing the dailies.  hmm
<cjwatson> I thought kubuntu-mobile was using a preinstalled form factor - is that wrong?
<Riddell> on ARM it is, not for i386 as far as I know
<Riddell> ScottK: ^^
<cjwatson> ok
<cjwatson> Riddell: can I have short and long descriptions for a mobile image, analogous to desktop -> "desktop CD" and "The desktop CD allows you to try Kubuntu without changing your computer at all ..." from http://cdimage.ubuntu.com/kubuntu/daily-live/current/ ?
<Riddell> "Preview Mobile Image" and "The Mobile Image offers a preview of the Plasma Mobile workspace to try or install"
<cjwatson> Riddell: published.  do you need the size limit bumped?  it says it's oversized right now
<cjwatson> -rw-rw-r-- 1 cdimage cdimage 838125568 Sep  2 05:22 maverick-mobile-i386.iso
<cjwatson>                 ubuntu-mid|kubuntu-netbook|ubuntu-moblin-remix)
<cjwatson>                         # Mobile images are designed for USB drives;
<cjwatson>                         # arbitrarily pick 1GB as a limit.
<cjwatson>                         SIZELIMIT="$((1024 * 1024 * 1024))"
<cjwatson>                         ;;
<cjwatson> maybe if I just use that?
<Riddell> that's fine
<cjwatson> Riddell: http://cdimage.ubuntu.com/kubuntu-mobile/daily-live/20100902/ look ok now?
<cjwatson> hm, why does that say CD
<cjwatson> oh, because it is a CD image.  Do you want it to say image instead?
<Riddell> preferably
<cjwatson> done
<Riddell> lovely, thanks
<cjwatson> respinning netbook
<cjwatson> will do kubuntu straight afterwards
<ScottK> Riddell: That's correct.  We're using preinstalled only on armel.
<Riddell> jr
<Riddell> no, this isn't KDM
<ara> cjwatson, Ubuntu Studio remains untested. I have sent an email to their -devel mailing list asking for testing. But I think that, if they don't do their job, it would be better not to release Ubuntu Studio Beta
<cjwatson> agreed
<cjwatson> skaet: ^- FYI
<cjwatson> ScottL: ^-
<ScottK> They also have a meta upload pending.
<cjwatson> I'd much prefer to release everything if it's possible though
<cjwatson> pending but not actually in the queue yet, right?
<ScottK> It's in the queue.
<ara> cjwatson, skaet: this is the email I sent to their list: https://lists.ubuntu.com/archives/ubuntu-studio-devel/2010-September/002536.html
 * ara -> lunch
<cjwatson> ScottK: huh, I wonder what's up with queuediff
<cjwatson> oh, blah, I bet its scraper doesn't handle batching
<ScottK> Not sure. Now that LP presents the diff in the queue page, I just look at it (I have to accept from there anyway)
<cjwatson> ScottL: it would probably have been clearer to remove ia64 and sparc from update.cfg first, but I've accepted ubuntustudio-meta anyway
 * cjwatson prepublishes ubuntu preinstalled-netbook armel+omap/armel+omap4
<cjwatson> having hacked the scripts so that's possible
<ScottK> prepublishing preinstalled images before 8AM local makes my head hurt.
<cjwatson> kubuntu desktop respinning
<cjwatson> ubuntu netbook i386 reposted
<cjwatson> skaet: we'll need to release-note wubi upgrades as non-functional for beta (again :-( )
<ev> cjwatson: oh?
<cjwatson> *upgrades* - lupin needs the corresponding fix that we applied to wubi
<ev> ahh
<ev> scared me for a minute there :)
<cjwatson> it's in the queue, though I bet there will be other problems, grub2 needs some packaging changes to spot that you're using wubi and not horrifically confuse people
<ScottL> cjwatson,  testing - ackd, ubuntustudio-meta - thank you
<cjwatson> ScottL: do you want a rebuild for that ubuntustudio-meta?
<cjwatson> I'm guessing it might help
<cjwatson> it only takes about 15 minutes to run
<smoser> cjwatson, what time are you expecting/hoping to release?
<ttx> cjwatson: you still need smoser around to nudge the cloud images stuff, right ?
<smoser> I've got to be out for a couple hours (~13:00 UTC to 15:00 UTC).  The uec images are all ready to go.
<ScottL> cjwatson, yes, that would be appreciated
<cjwatson> kubuntu desktop reposted
<smoser> in my absense, someone else *could* do that, a single command on nectarine (promote-daily beta /srv/ec2-images/server/maverick/20100831/  --verbose --allow-existing)
<smoser> and the ami pages data is available at http://bazaar.launchpad.net/~ubuntu-on-ec2/ubuntu-on-ec2/ami-pages/files, but someone has to update the pages on amazon.
<smoser> so, i expect i'll be back before you'd need me, but if not, you can grab my cell phone.
<Riddell> cjwatson: are kubuntu dvds getting respun?
<cjwatson> yes, queued
<cjwatson> since they had no tests and known bugs
<ttx> cjwatson: can we handle smoser's absence in the next two hours ?
<smoser> 2.5
<cjwatson> gosh, I have nectarine access
<cjwatson> ttx: I don't expect to release until my evening at this point
<ttx> cjwatson: ack
<cjwatson> I can do the nectarine bit, apparently, but I think it would be best if I didn't try to do the amazon stuff
<ttx> the amazon stuff can be delayed a bit anyway
<ttx> it's more about updating some references, the AMIs are already usable
<cjwatson> anyway, I don't expect those times for smoser's absence to be a problem
<cjwatson> I'm not entirely happy about leaving bug 627672 open in Ubuntu desktop, but I think if I respin that as well then we won't make it today
<ubot4> Launchpad bug 627672 in ubiquity (Ubuntu Maverick) (and 2 other projects) "[Maverick Beta] install from USB stuck retrieving files 2/6 Hp Mini (affects: 2) (dups: 1) (heat: 16)" [High,Fix released] https://launchpad.net/bugs/627672
<ScottK> slangasek: The KDM plymouth thing is allegedly fixed.  I'm updating the kdebase-workspace 4.5.1 that'll go in after freeze with an improved patch.
<ScottK> cjwatson: Once we're ~confident we won't be doing any more respins, I'd like to get some of the KDE 4.5.1 packages in and building (just the core ones, the leaf ones will wait just fine) so that when we unfreeze it all builds pretty cleanly.
<cjwatson> whoops, might be a plan to turn the publisher back on
<cjwatson> ScottK: ok, will be a while yet
<ScottK> cjwatson: Sure, just wanted to get my place in line.
<cjwatson> skaet: updated wubi notes in tech overview
<cjwatson> ScottL: ubuntustudio reposted
<cjwatson> hm, wait, https://wiki.ubuntu.com/MaverickMeerkat/ReleaseManifest indicates that the omap preinstalled images will go on cdimage not releases, so I should un-prepublish those
<cjwatson> last time, imx51 and dove went on releases, and omap on cdimage
<cjwatson> but David edited the omap line so I guess it's OK by him
<cjwatson> robbiew: your first version of https://wiki.ubuntu.com/MaverickMeerkat/ReleaseManifest was missing imx51 and dove, compared with LucidLynx/ReleaseManifest.  Was this intentional?  What should we do with the existing dove image, if it turns out to be OK to release?
<cjwatson> Riddell: should I be posting kubuntu mobile to the tracker?
<Riddell> cjwatson: I don't think you can, it doesn't have the appropriate bits as far as I know
<cjwatson> Riddell: also, I am hopelessly confused about the fact that we have kubuntu-mobile/daily-live/current/maverick-mobile-i386.iso but kubuntu-mobile/ports/daily-preinstalled/current/maverick-preinstalled-desktop-armel+omap.img.gz
<cjwatson> why is the first mobile and the second desktop?
<cjwatson> Riddell: I can add products, I believe
<Riddell> that won't be deliberate, probably something missing in the scripts
<Riddell> cjwatson: oh if you can add Kubuntu Mobile that would be great
<cjwatson> though I don't know how the download stuff works
<cjwatson> would you mind if I rearranged the arm stuff then, to be mobile?
<cjwatson> the inconsistency is a bit of a pain
<Riddell> cjwatson: yes please do fix the name on that armel image
<cjwatson> I've added a product for Kubuntu Mobile i386 but I don't know how to set up a download URL for it
<ogra> cjwatson, yeah, cdimage is fine
<cjwatson> ok
<cjwatson> ogra: can you edit MaverickMeerkat/ReleaseManifest accordingly?
<ogra> what should i edit there ? it already says cdimage, no ?
<cjwatson> ogra: not for dove?
<cjwatson> oh, you were talking about omap
<ogra> oh, for dove i dont really know :/
<cjwatson> sorry, misread context of your reply
<cjwatson> no edit needed on your part then
<ogra> well, i could have been clearer (as always)
<ogra> but dove is surely not in a quality to go on releases atm
<ogra> so leave it on cdimage
<ogra> uless davidm (who is ill) will say differently for final i guess it will stay there, i'll ask him to add the right stuff to the wiki if he's around again
<ogra> *unless
<cjwatson> ok
<cjwatson> Riddell: done I think, will respin after Kubuntu DVD
<cjwatson> I think we're nearly there
<Riddell> cjwatson: are you able to edit the tests in iso testing too?
<Riddell> skaet, cjwatson: I need to go out in about 2.5 hours, if the release happens when I'm away ScottK can give the OK for the Kubuntu images
 * ScottK waves
<ttx> ara: you marked http://iso.qa.ubuntu.com/qatracker/result/4442/454 started, are you still on those ?
<cjwatson> Riddell: to some extent but I probably ought not to try at this point
<cjwatson> Kubuntu DVD reposted
<cjwatson> Kubuntu Mobile i386 posted, but I don't know how to add testcases for it and will ask #ubuntu-testing for help
<robbiew> cjwatson: yeah...ogra would know better than me about the imx51 and dove images...did we release those for alpha3?
<ogra> robbiew, imx51 doesnt exist ... and i'm not involved with dove, but i think we found a solution already anyway
<robbiew> okay
<scott-work> cjwatson: i realize you are most likely extremely busy but i was wondering if you could take a minute or two and clarify a few points to me about the Beta release (or point me to one who is available)?
<cjwatson> scott-work: go ahead and ask, and I can answer when feasible
<scott-work> cjwatson:  my ignorance is slightly embarassing but i think i'm confused or ignorant about the beta iso image testing
<scott-work> cjwatson: the beta image was available two days ago (i believe) but it appears that we need to test by the end of today so that it can be "released"
<ara> scott-work, when we get to beta freeze, we start publishing candidate images in the tracker
<cjwatson> well, the actual release goes out today, and normally images are available a day or two (ideally two) before for testing; sometimes we need to respin them due to bugs though
<cjwatson> it can be hard work getting everything in on time; if it's not feasible, it's possible to slip individual flavours
<ara> scott-work, so, in order to make sure that those are usable, people test them and report back to the ISO tracker
<cjwatson> (though not ideal)
<scott-work> ara:  i presumed that the ISO tracker test needed to be completed before the next ISO image was to be released in order to secure the next release, i.e. A1 -> A2, etc
<cjwatson> the ISO tracker is a tool to help us validate any given milestone release
<scott-work> ara:  this would result in almost a full month to complete the ISO tests for each image
<ara> scott-work, a full month?
<cjwatson> um
<cjwatson> there is clearly some confusion, how do you get to that?
<cjwatson> oh, I think I see your confuion
<scott-work> cjwatson: oh good, i was having trouble articulating it
<cjwatson> it isn't worth starting testing until the development and bug-fixing for a given milestone is more or less complete
<cjwatson> there's no point starting to test the beta images at alpha 3, because many of the uploads that will go into the beta images aren't there yet
<cjwatson> the point of the ISO testing is to validate that the images we're releasing to users actually work
<scott-work> cjwatson: that last sentence is the key
<cjwatson> obviously there is a use for continuous testing as we go along, but that isn't the purpose of iso.qa
<scott-work> we need to test image rather than the "release", that 's what qa test are for
<scott-work> yes
<cjwatson> (so "it isn't worth starting testing" is a bit exaggerated, sorry)
<scott-work> so at each milestone (alpha1, alpha2, et al) we will have one or two days to validate the ISO images before it will be released for further testing by users/developers ?
<ara> scott-work, that's it
<ScottK> scott-work: Hopefully 3, but it never seems to work out that way.
<scott-work> that was my confusion; not fully understanding the purpose of iso.qa and the time allotted to testing of the image
<scott-work> thank you very much, as studio lead i will be much more diligent with ISO testing in the ffuture
<ScottK> OK. Get to work ....
<robbiew> ScottK cracks the whip :)
<scott-work> lol, i'm actually at work now ;) and sending email the list and on irc at the same time
<cjwatson> better to get this sorted out for beta than for final
<ara> cjwatson, during OEM netbook I got the bug of not installing oem-config
<ara> cjwatson, I have checked the log and have seen that it is the same error as bug 628681
<ubot4> Launchpad bug 628681 in ubiquity (Ubuntu) "Kubuntu OEM did not install oem-config-kde (affects: 1) (heat: 6)" [Undecided,Confirmed] https://launchpad.net/bugs/628681
<ara> cjwatson, do you agree to point to that one (changing the title to cover all of them)
<ara> cjwatson, or do you prefer a new bug
<ara> ?
<cjwatson> let's make it a new bug please
<ara> sure
<ara> will do
<cjwatson> just in case it's the same kind of thing in a couple of places
<ara> OK
<ScottK> ara: Looking at http://iso.qa.ubuntu.com/qatracker/test/4522 I don't see a test case for the "guided" option.
<cjwatson> ara: was bug 628681 an install from USB?
<ubot4> Launchpad bug 628681 in ubiquity (Ubuntu) "Kubuntu OEM did not install oem-config-kde (affects: 1) (heat: 6)" [Undecided,Confirmed] https://launchpad.net/bugs/628681
<cjwatson> it looks like it from the logs but you didn't mention it, so checking
<ara> cjwatson, yes, it was USB
<ara> cjwatson, I will comment it in the bug
<SpamapS> anybody care to comment on bug 625882 .. ABI breakage in libdbi .. new upstream fixes it, but we need to rebuild all of the build-depends ...
<ubot4> Launchpad bug 625882 in libdbi (Debian) (and 7 other projects) "libdbi0: ABI breakage without package name change (affects: 1) (heat: 6)" [Unknown,Unknown] https://launchpad.net/bugs/625882
<ara> ScottK, if you feel that a new testcase is needed, can you please send an email to ubuntu-qa explaining why it is needed?
<ara> ScottK, thanks!
<ScottK> ara: Don't we want a test case for each install option?
<SpamapS> The other option is to sync w/ Debian w/ has regressed to the previous upstream version for squeeze rather than rebuild the build-depending packages (of which there are 6)
<ara> sure, but without previous notice from developers it is hard to keep up with the different options
<ScottK> OK.
<ScottK> ara: It's ubuntu-qa@l.u.c, right?
<ara> ScottK, correct, thanks a lot
<marjo> hi cjwatson
<marjo> cjwatson: re: ubuntu studio i386 running inside virtualbox, running inside virtualbox, "software installation failed" after skipping optional software (CORE only)
<ScottK> SpamapS: Did you do test rebuilds?
<marjo> i chose "no automatic updates"
<cjwatson> marjo: do you have installer logs?
<marjo> cjwatson: "download language support", i chose no
<marjo> cjwatson: Choose software to install: I chose <Continue>
<SpamapS> ScottK: because of the brokenness of libdbi's bin packages, they have to be altered slightly (libdbi0-dev changed to libdbi-dev)
<SpamapS> ScottK: I've tested rrdtool, the others I'm waiting on.
<cjwatson> marjo: I'm running a test here, although logs would be more efficient
<ScottK> SpamapS: Once you've rebuilt them all, ask again and I'll evaluate it.
<marjo> cjwatson: "An installation step failed. You can try to run ... Select and install software"
<marjo> cjwatson: ok
<ttx> skaet, cjwatson: do you need anything more for -server ? Will call it a day in ~15min
<ttx> skaet, cjwatson: smoser should be around to nudge the cloud images
<smoser> i'm here.
<cjwatson> I don't think so
<skaet> ttx,  could you look over the TechnicalOverview and make sure the hightlites are accurate.
<ttx> skaet: I did that, let me recheck :)
<skaet> ttx,  thanks!  :)
<ScottK> cjwatson: Could I get a respin of Kubuntu live powerpc?
<ttx> skaet: looks good to me. You still have a few "waiting input, needs update?" lines in there, though
<ttx> (not -server related)
<ScottK> Now that it looks like we're ~there, I have a tester for it.
<skaet> ttx,  thanks.   will be deleting them in a final pass if can't get more input, before then.  (place holders).
<ttx> skaet: ack
<cjwatson> ScottK: on its way
<ScottK> cjwatson: Thanks.
<cjwatson> right, posted ubuntustudio 20100902.1, which I'm fairly sure will be better
<holstein> hey guys
 * holstein is testing the amd64 ubuntustudio iso's today :)
<Riddell> right I'm away, back in about 6 hours, I think we'll be good for release seems like the dvds are getting tested, ScottK can confirm when it needs confirmed
<cjwatson> Riddell,ScottK: kubuntu-mobile for arm respun with better image names, so it's now preinstalled-mobile as discussed.  That's not on the tracker - do you want me to try to fight with the tracker to get it added, or just test it out of band?
<cjwatson> holstein: as long as you test 20100902.1 not 20100902
<holstein> cjwatson: thats what im just asking about
<ScottK> cjwatson: I'd say let's test it out of band unless you have spare time to play with the tracker.
<cjwatson> not so much
 * holstein is DL'ing from the dailies
<holstein> @ http://cdimage.ubuntu.com/ubuntustudio/daily/current/
<charlie-tca> Well, I guess I will have the ubuntustudio images to sync next time
<holstein> NM
 * holstein totally sorted
<holstein> http://iso.qa.ubuntu.com/qatracker/info/4523
<ScottK> cjwatson: Are we considering lack of wubi testing a blocker?
<cjwatson> I think that's up to you guys
<ScottK> OK.
<cjwatson> my gut feel is that if Wubi is going to break at the moment it's liable to break across the board
<ScottK> OK.  If you know of someone who could test it, both Kubuntu and Xubuntu are asking for wubi testers ....
<marjo__> cjwatson: http://cdimage.ubuntu.com/ubuntustudio/daily/20100902.1/maverick-alternate-i386.iso not found
<ScottK> OK, got one wubi tester.
<marjo__> holstein: were you able to grab the amd64 ubuntu studio OK?
<holstein> marjo__: yeah
<holstein> from http://iso.qa.ubuntu.com/qatracker/info/4523
<marjo__> holstein: can't seem to find the i386 image
<holstein> marjo__: let me see if i can find the i386 one
<marjo__> holstein: thx
<holstein> marjo__: yeah
<holstein> http://iso.qa.ubuntu.com/qatracker/info/4529
<holstein> iso not found
<holstein> let me ask...
<marjo__> holstein: thx for confirming; i already asked cjwatson
<holstein> will that be someone in the studio team that needs to fix it?
<holstein> whatever...
<charlie-tca>  images were just rebuilt, it may not have hit yet
 * holstein making a little noise over there
<holstein> charlie-tca: true
<holstein> marjo__: how about http://iso.qa.ubuntu.com/qatracker/info/4524
<marjo__> holstein: ok, that's available
<holstein> :)
<holstein> hmmm
<holstein> marjo__: i think its the wrong one though
<holstein> 12:25 < cjwatson> holstein: as long as you test 20100902.1 not 20100902
<holstein> that one is 20100902
<holstein> marjo__: lets just wait a bit and see if it 'comes in' auto-magically
<marjo__> holstein: that's what i'm afraid of; cjwatson said he posted ubuntustudio 20100902.1
<marjo__> holstein: ack
<holstein> marjo__: w00t
<holstein> http://iso.qa.ubuntu.com/qatracker/info/4529
<holstein> its there now :)
<holstein> 20100902.1
<marjo__> holstein: yeah, now i see it
<cjwatson> it just takes a while to push to the internal mirrors
<cjwatson> panic not typically required :)
<ScottK> Is the powerpc live for Kubuntu still building?
<cjwatson> no, it's done, I'll post it
<cjwatson> and remove ia64 from that directory ..
<ScottK> Cool.
<ScottK> Thanks.
<cjwatson> ScottK: powerpc isn't on the tracker - the build id is 20100902
<ScottK> cjwatson: Thanks. It doens't need to be on the tracker.
<ScottK> It's more if it doesn't create a smoking hole, it passes.
<cjwatson> hm, the cdimage.u.c public mirror(s) does seem to be being awfully slow to sync
<ScottK> OK.  I was about to ask.
<cjwatson> elmo: would you mind having a quick poke at alpinecurrant and seeing if its rsync has melted or something?
<cjwatson> at least that's the mirror I'm seeing
<cjwatson> I'll do some more data pruning
<charlie-tca> It took up to 15 minutes to sync yesterday
<cjwatson> it's taken most of an hour here
<elmo> it's link is saturated :(
<elmo> ironically, the other two don't have this problem, because they can't saturate their own (Gbit) link with outbound traffic
<elmo> (they're older and slower)
<cjwatson> ah, there we go, it's synced now
<ScottK> Still don't see it at http://cdimage.ubuntu.com/kubuntu/ports/daily-live/
<cjwatson> oh, I meant studio
<cjwatson> I've kicked another sync
<ScottK> Oh.  OK.
<ScottK> cjwatson: powerpc for Kubuntu landed.  I doubt it will get tested in time, so don't hold releasing for it.
<ScottK> (probably do it tomorrow if it works out)
<marjo__> holstein: are you able to test ubuntu studio amd64?
<marjo__> holstein: i can only do i386
<holstein> marjo__: we're talkig about that right now
<holstein> marjo__: im done pretty much
<marjo__> holstein: ack & thx
<holstein> waiting on the last test right now
<holstein> marjo__: may i PM you?
<scott-work> cjwatson: it appears the updates to ubuntustudio-meta didn't make it into the 20100902.1 ISO image
<scott-work> cjwatson: dholbach reported bug 628981
<ScottK> scott-work: Fix is already done/on the way.
<cjwatson> you sure?  it was confirmed installable.
<ubot4> Launchpad bug 628981 in linux-rt (Ubuntu) "linux-headers-rt not installable breaks installation (affects: 2) (heat: 10)" [Medium,Triaged] https://launchpad.net/bugs/628981
<ScottK> Oh, .1.
<cjwatson> I'm pretty certain that dholbach was using 20100902 and just didn't check.
<holstein> cjwatson: i was using .1 though
<cjwatson> (note that I've already followed up to that bug)
<cjwatson> holstein: and ...
<holstein> failed at 'select and install software'
<cjwatson> cdimage@antimony:~/cdimage/www/full/ubuntustudio/daily/current$ grep -- -rt *.list
<holstein> i the alternate installer
<cjwatson> cdimage@antimony:~/cdimage/www/full/ubuntustudio/daily/current$
<cjwatson> linux-headers-rt is not on current images
<cjwatson> holstein: I need installer logs
<holstein> cjwatson: i can do that
<scott-work> how do you get the installer logs when installation fails?
<holstein> yeah
<cjwatson> "save debug logs" from the installer main menu
<holstein> thats what i was about to google ;)
<holstein> cjwatson: i'll do that and get them in here for you, thanks
<lool> Hey there, we have a new package in maverick/NEW called linaro-image-tools; it would be nice to get that included in maverick/universe proper, that requires FFE + NEW queue processing; is the release team ok with that?
<cjwatson> syslog is the important one
<cjwatson> lool: doesn't sound like a major problem, but after beta please
<lool> Oh sorry, it's not out for Ubuntu yet, I'm confused because we announced the Linaro one; my bad
<lool> I intended to mention it post-beta; will raise it up tomorrow or Monday
<cjwatson> Other than Ubuntu Studio, is anyone aware of any reason I shouldn't start publishing the beta?
<cjwatson> The test matrix isn't entirely complete, but looks reasonable; I've gone through all of the red bugs
<ScottK> cjwatson: Kubuntu is ready.
<cjwatson> the Kubuntu partitioning label one is the scariest of them, and Riddell has already declared that not a blocker
<newz2000> what are the expected URLs to be updated for beta? /testing /testing/maverick/beta, is there another one too? (do the release notes go live with beta or is that later?)
<ScottK> cjwatson: Yes.  I was giving you the opinion of the person who signs off on the release, not my personal preference ....
<cjwatson> newz2000: /download?  (I forget)
<newz2000> cjwatson: no, we won't update that until release
<cjwatson> release notes will need to be copied from the tech overview, but IIRC that goes on /testing/maverick/beta?
<newz2000> yeah, that's the way it shows for lucid
<cjwatson> news sidebar
<newz2000> is there a redirect to show the release notes during installation?
<cjwatson> yes, the same one there has been for several releases
 * newz2000 checks on that
<cjwatson> http://www.ubuntu.com/getubuntu/releasenotes?os=$PROJECT&ver=$VERSION&lang=$LANG
<cjwatson> where $PROJECT $VERSION $LANG vary
<cjwatson> starting publishing
<skaet> newz2000, cjwatson,  will do a final pass on the TechnicalOverview with Robbie, and then let you know when its good to clone.
<holstein> cjwatson: Ubuntu-Studio 10.10 "Maverick Meerkat" - Beta amd64 (20100902)
<holstein> i got it from http://iso.qa.ubuntu.com/qatracker/info/4528 though
<holstein> says 20100902.1
<holstein> is this the issue?
<cjwatson> your image is too old, yes.  rsync it up to date
<cjwatson> perhaps you fetched it just before the tracker was updated
<holstein> http://paste.ubuntu.com/487397/
<holstein> cjwatson: well, thats easy enough then :)
<cjwatson> yes, that's the old image
 * holstein tries again
<newz2000> All ready on my end. Only step left is the tech overview. This is my first time doing it on the new system so may need a little extra time (20m should be more than ample)
<cjwatson> hm, our source images are broken
<cjwatson> will have to fix that before final, too late now
<cjwatson> newz2000: was planning to allow at least two hours for mirroring
<cjwatson> does that sound sufficient?
<newz2000> cjwatson: yeah, I think so
<cjwatson> pitti is a god
<cjwatson> this publish-image-set.py is such a time-saver, even if I will have to fiddle about around the edges towards the end
<cjwatson> I can just copy and paste the commands to run, with an eyeball check
<cjwatson> and it gets all the versions from the iso tracker
<cjwatson> syncing out the content for releases.ubuntu.com
<cjwatson> not all the cdimage pieces are in place yet
<ScottK> cjwatson: If I'm not around when the time comes, ryanakca has his finger on the trigger of kubuntu.org.
<cjwatson> things still to do: ubuntu netbook preinstall armel+omap/4; netboot; ubuntu server uec; kubuntu mobile i386/armel; wubi?
<cjwatson> ScottK: is http://cdimage.ubuntu.com/kubuntu-mobile/daily/ stale and removable?
<cjwatson> ISTR building alternates for k-m was just a mistake
<ScottK> We got one good wubi test on kubuntu.
<ScottK> cjwatson: mistake/test, but yes, it can be removed.
<cjwatson> it's gone
<ScottK> cjwatson: I'm working on getting some feedback on the kubuntu mobile images.  I expect we'd release them tomorrow if at all (like powerpc)
<GrueMaster> cjwatson: What is left to do?  <cjwatson> things still to do: ubuntu netbook preinstall armel+omap/4;
<cjwatson> 20:42 <cjwatson> GrueMaster: publication
<cjwatson> 20:43 <cjwatson> that was a public note-to-self
<cjwatson> 20:43 <cjwatson> netboot prepared, not synced
<GrueMaster> ok.  The netboot images will probably not be tested immediately.  Lots of other things happening, and apparently they are low on the radar.
<cjwatson> I wasn't referring to testing
<cjwatson> my comment was "these are the things I still need to publish"
<cjwatson> ubuntu netbook preinstall armel+omap/4 published (pending mirror sync)
<cjwatson> http://releases.ubuntu.com/.manifest trimmed down to just maverick for the sake of the mirror prober
<cjwatson> elmo: acai is taking a long time to come back from sync-mirrors.  is it ok?
<elmo> cjwatson: same deal
<cjwatson> ok, it returned eventually
<cjwatson> jpds: ^- comment about manifest
<cjwatson> ScottL: should I publish Ubuntu Studio for beta?  I held off due to the confusion about the -rt packages, but that seems to have been resolved
<cjwatson> no amd64 tests yet
<cjwatson> smoser: can you please go ahead and publish the EC2/UEC images?
<smoser> cjwatson, yes sir.
<cjwatson> ScottL,scott-work: charlie-tca's test on #-testing seems to be going well so far
<scott-work> cjwatson: good, thank you :)
<marjo__> cjwatson: studio i386 mandatory tests passed
<cjwatson> ScottK: do you want kubuntu mobile to go under kubuntu/releases/ (i.e. with the DVD etc.) or under kubuntu-mobile/releases/ ?
<cjwatson> (the latter will tend to cause the scripts to talk about "Kubuntu-Mobile" everywhere ...)
<cjwatson> but I'm not sure whether you want it with the DVD, or on its own
<ScottK> cjwatson: That latter.  It's a very rough tech preview this cycle, so the further away from production releases the better.
<cjwatson> ok
<cjwatson> ogra: if you're still around, same question for the netbook preinstalled images - do you want them along with the Ubuntu DVD in releases/, or on their own in ubuntu-netbook/releases/ ?
<cjwatson> or maybe even in ports/releases/ or ubuntu-netbook/ports/releases/ or oh god I'm so confused
<cjwatson> publishing ubuntustudio
<marjo__> cjwatson: thx!
<scott-work> marjo__: thanks for tenaciously testing !
<marjo__> scott-work: never give up! thank you!
<cjwatson> netbook preinstalled: I'm opting to place them separately for now
 * holstein is burning the amd64 ubuntustuio iso
<holstein> hopefully the right one ;)
<cjwatson> NCommander: I have not published dove, for now; let me know if that should change
<smoser> cjwatson, http://uec-images.ubuntu.com/releases/maverick/beta/ and http://ubuntu-ec2-maverick-amd64.notlong.com/ and http://ubuntu-ec2-maverick-i386.notlong.com/ are updated. ie "uec images 'Released'"
<cjwatson> notlong.com?
<smoser> they redirect.
<smoser> to amazon pages.
<cjwatson> skaet: I believe everything is now published
<cjwatson> skaet: some of the URLs may take a while given that the datacentre is now presumably frantically shifting data around
<skaet> ack.
<cjwatson> wow, lack of HEADER.html in some of these places too
<cjwatson> um, yeah, give it a while ...
<cjwatson> elmo: acai has been syncing releases for over an hour - this could prove difficult
<cjwatson> skaet: anything else you need from me?
<skaet> cjwatson,  do you have a bung number for the OEM installation mode?
<skaet> s/bung/bug/...
<cjwatson> skaet: bug 628681, bug 628290, bug 628911
<ubot4> Launchpad bug 628681 in ubiquity (Ubuntu) "Kubuntu OEM did not install oem-config-kde (affects: 1) (heat: 6)" [Undecided,Confirmed] https://launchpad.net/bugs/628681
<ubot4> Launchpad bug 628290 in ubiquity (Ubuntu) "OEM installation, missing "Prepare for shipping to end user" icon (affects: 1) (heat: 3440)" [Undecided,New] https://launchpad.net/bugs/628290
<ubot4> Launchpad bug 628911 in ubiquity (Ubuntu) "Ubuntu Netbook OEM did not install oem-config (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/628911
<skaet> cjwatson,  Thanks!    Sleep well.
<charlie-tca> from #ubuntu+1
<charlie-tca> <Sary> Well , you guys are done such a great job .. so thank ya a bunch :-)
<ScottK> skaet: If we the release happens before Riddell gets back, ryanakca will be taking care of getting the announcement on kubuntu.org.
<ScottK> (he may anyway)
<ogra> cjwatson, alpha-3 was in ubuntu-netbook/releases/ hmmm, i'm not really sure i must say :)
<cjwatson> let's just stick with that structure then; that has the virtue that I've done it already ;-)
<ogra> lol
<cjwatson> should be on the website to check out now
<ogra> ok
<cjwatson> so please confirm and such
<ogra> oh, WOW ! you fixed make_web_indicies !
<ogra> thanks so much
<ogra> (that was at the very bottom of my TODO for maverick)
<ogra> cjwatson, perfect
<cjwatson> for preinstalled-*?  yep, happy birthday
<ogra> heh
<cjwatson> at least some of cdimage has yet to catch up :-/
<ogra> looking at cdimage i wonder if it deserves a cleanup spec for natty to avoid all that directory confusion once and for all it is really quite chaotic
<cjwatson> mm, people keep turning up with new requirements :-/
<cjwatson> the ports separation is perhaps unhelpful
<ogra> i think all the different possible release dirs we have are ...
<ScottK> too many
<ogra> havig dailies on a per project base is fine, but milestones and release should all live in the same place
<charlie-tca> Wouldn't many names have to be changed then? All the images have the same name, only the directories change
 * charlie-tca thinks "or I have lost track again and you should ignore me"
<ogra> charlie-tca, only the target dirs for milestones/releases would have to be unified
<charlie-tca> So we could find them easier? That would be nice
<ScottK> It would have been nice to keep that third amd64 builder ....
<holstein> charlie-tca: thanks for doing these ubuntustudio 64bit test :)
<charlie-tca> no problem
<holstein> http://iso.qa.ubuntu.com/qatracker/test/4528
<holstein> we're all tested :)
<marjo__> holstein: thx
<holstein> w00t :)
<marjo__> holstein:  ubuntu studio i386 manual partitioning test case passed
<holstein> sweet
<robbiew> okay ladies and gentlemen...I'm sending the official email
<ogra> wohooo !
<robbiew> and it will sit until slangasek approves the email
<robbiew> lol
<charlie-tca> Thank you, cjwatson
<marjo__> robbiew: thx; test coverage is fairly complete
<slangasek> is that a hint? :)
<robbiew> heh
<cjwatson> how are the CD mirrors looking?
 * robbiew need to relocate back home...battery is low
<marjo__> robbiew: http://iso.qa.ubuntu.com/qatracker/testcases
<robbiew> ack
<cjwatson> well, at least some of them have at least some of the data ;-)
<cjwatson> can somebody who is not behind NAT check the torrents?
<cjwatson> hm, it's a bit late, but let's resurrect queuebot
<cjwatson> didn't realise it was out all day
<newz2000> This is my last beta release as webmaster. :`(
<newz2000> (but that's ok, happy days are still ahead)
<newz2000> and have you ever seen such a pretty beta release page?
<slangasek> robbiew: hey, where did you send that message?  I'm not finding it in the mod queues
<cjwatson> newz2000: overachiever
<cjwatson> ;-)
<cjwatson> hm, we mentioned the Kubuntu Ubiquity redesign but not the Ubuntu one
<robbiew> slangasek: hmm
<newz2000> mt gets the credit. Both for the beauty and the last min pushes to live I inflected on IS
<cjwatson> ah well
<cjwatson> robbiew: are you planning to do the other announcement steps listed in BetaProcess?
<skaet> newz2000,  its a very cool page
<robbiew> slangasek: heh...it was sitting in my outbox of course
<cjwatson> you and your fancy mailers
<cjwatson> telnet smtp.canonical.com 25 doesn't have an outbox
<robbiew> nah...I forgot I turned my mailer offline
<robbiew> heh
<slangasek> back in MY day, the outbox was acoustically coupled to the inbox
<cjwatson> yeah, well MY outbox had to be filled up with coal twice a day, rain or shine
<slangasek> you didn't need your computer to tell you you had mail, you could hear the mail without any fancy sound cards
<robbiew> lol
<skaet> lol
<robbiew> cjwatson: : yeah, I can complete it
<robbiew> BetaProcess that is
<cjwatson> awesome
 * robbiew also adds that to the Links section of /ReleaseTeam ;)
<skaet> cjwatson,  go get some sleep  :)
<cjwatson> my thought exactly
<cjwatson> gosh, fancy, I don't think I'd ever seen /ReleaseTeam
<cjwatson> BTW, planning to let the KDE stuff in the queue flush out in a controlled manner under ScottK's guidance, and I'll open the floodgates again tomorrow morning
<robbiew> cjwatson: /me created it ;)
<robbiew> grrrr...stupid evolution
 * skaet wonders if the demo she got on how to send out the email needs to be redone ;)
<cjwatson> step 1: use mutt
<robbiew> nah...I thought I had auto-complete for ubuntu-announce
<cjwatson> anyway, I shall stop trolling and go to sleep; 'night
<robbiew> I didn't
<robbiew> lol
<robbiew> so it got sent to ubuntu-announce...instead of ubuntu-announce@lists.ubuntu.com
<robbiew> http://www.sadtrombone.com
<skaet> :(
<robbiew> slangasek: you should NOW see it in the moderator queue :/
<robbiew> slangasek: wait...it was rejected...because of the stupid header crap
<robbiew> damn it!
<Riddell> evening
<Riddell> what's the status?
<robbiew> Riddell: announcement sent
<slangasek> robbiew: and moderated
<robbiew> ;)
<skaet> :)
<skaet> ... and in the inbox.  :)
<robbiew> slangasek: BetaRelease says to update http://release-blog.ubuntu.com/....how exactly do I do that :)
 * skaet is interested too...
<slangasek> robbiew: you click on the link that takes you straight to the admin page for it, then you get someone to get you a username and password :)
<slangasek> lemme see if I can swing that
#ubuntu-release 2010-09-03
<slangasek> robbiew, skaet: passwords sent
<skaet> thanks.
<sbeattie> skaet|robbiew: hrm, no 10.04.1 announcement there, might want to add that to the documentation for point releases.
 * sbeattie didn't know http://release-blog.ubuntu.com/ existed until now.
<robbiew> slangasek: thnx for the blog access
<akgraner> robbiew, skaet, slangasek  et al - Thank you!!!!!
<akgraner> hey all - as part of verifying links are correct in posts on the Fridge I found 10 mirrors that aren't working  - who should I tell?
<charlie-tca> It can take some time for all the mirrors to update
<charlie-tca> xubuntu mirrors will take up to 3 days, for example
<akgraner> ahh ok
<akgraner> some of the links were listed as .00 and .04 I fixed those and they seemed to work but thought I should let someone know
<charlie-tca> hmm, not sure who to notify. But, usually got to wait at least 24 hours to make sure
<akgraner> Thanks!  See I learn something new everyday :-)
<charlie-tca> Who is the release manager now? Is it Kate Stewart?
<akgraner> nods
<charlie-tca> email her, maybe?
<akgraner> :-)
<ScottK> akgraner: jpds is the one to tell.
<ScottK> If he's not here now, he'll read the scrollback and find out once he's awake.
<akgraner> okie dokie :-)
<akgraner> Thanks!!! :-)
<ScottK> slangasek: Would you please accept kdeedu in an hour (55 minutes or more from now)?
 * ScottK is going to bed.
<ScottK> (or anyone else who happens by)
<ScottK> Good night.
<lamont> oh meh.  if some kind release manager would sync nmap 5.21-1 from debian to replace 5.21-1~build1 in maverick, that'd be lovely.. the diff exists only in the changelog
<lamont> I suppose that requires paperwork at this point
<ScottK> that or giving me shell access.
<lamont> pretty sure that would be bad for me...
<ScottK> all a matter of priorities.
<lamont> this change isn't so much a priority
<ScottK> ;-)
 * lamont sleeps
<micahg> Do I need an FFe for removing an rpath from libgjs that requires gnome-shell to be have a wrapper for mozjs?  (I have both ready to upload with wrappers)
<slangasek> ScottK: the new kdeedu seems to have dropped a fix needed on armel; is that now upstream?
<slangasek> (the changelog seems to diverge from what's currently in maverick, so I can't even infer that whoever merged it had to have seen it; I'm loathe to set armel a-buildin' such a package that may just FTBFS)
<ara> morning slangasek, all!
 * slangasek waves
 * ttx waves
<cjwatson> NCommander: I've just re-enabled most of the cdimage cron jobs, but have left dove disabled in case you tell me that we want to publish it for beta after all
<NCommander> cjwatson: we might have a possible ubiquity fix but I suspect we're too late for a respin at this point
<cjwatson> respinning is unlikely to be feasible because the archive has moved on
<NCommander> cjwatson: right, ok, forget it. The beta images aren't worth releasing at this point without a working ubiquity :-/
<cjwatson> although it hasn't properly reopened, I'm about to, and quite a few packages have been accepted
<cjwatson> we could publish the images with a patch file attached, if necessary ...
<cjwatson> what are the consequences of dove missing beta?
<NCommander> cjwatson: none, I think. davidm been MIA though so I can't confirm with him, but we don't have a contractical oblingation AFAIK
<ara> cjwatson, good morning
<ara> cjwatson, skaet sent an email to ubuntu-devel earlier this morning that is awaiting moderation. Could you please approve it?
<cjwatson> huh, I thought she was on the accept list
<ara> cjwatson, yes, I was surprised as well
<cjwatson> done and done
<lool> Would love getting a FFE + NEW review of linaro-image-tools; should be fairly trivial, as we only install a single script in a binary package; it has a couple more in the source currently unused
<cjwatson> right, unapproved is entirely flushed now
<ogra> hooray
<cjwatson> lool: accepted linaro-image-tools, seems fine for universe at least
<lool> Thanks
<micahg> Do I need an FFe for removing an rpath from libgjs that requires gnome-shell to be have a wrapper for mozjs?  (I have both ready to upload with wrappers)
<cjwatson> if it's a bug-fix, you have both ready, and you're pretty certain it doesn't affect anything else (have you searched the archive for reverse-deps?), I don't think so
<micahg> cjwatson: great, thanks
<micahg> yes, I search with apt-cache rdepends libgjs0a
<lamont> cjwatson: is it worth the pain to ask for nmap to move from 5.21-1~build1 to 5.21-1 via a sync from debian?
<lamont> I totally spaced that it got stuck in NEW on debian
<lamont> or some such
<cjwatson> lamont: I don't particularly mind - just file a bug in the usual way
<lamont> cool
<ScottK> cjwatson: I have reports that Kubuntu powerpc live image for beta started up and did not create any black holes or otherwise cause the world to end, so I was wondering if you would publish it as a release as well.
<cjwatson> 20100902?
 * ScottK double checks
<ScottK> cjwatson: Yes.  Please.
<cjwatson> ScottK: published and syncing out
<ScottK> cjwatson: Thanks.
<ScottK> slangasek: The Kubuntu netbook 10.04.1 images that you set aside earlier have been validated and should be relased. im51 and omap work.  dove doesn't but it didn't work for 10.04 (don't care if you publish it or not).
<jdstrand> ScottK: hey, so I have a couple questions on the https://wiki.ubuntu.com/FreezeExceptionProcess:
<ScottK> ok
<ScottK> Shoot.
<jdstrand> 1. section '5' (Exceptions for Universe/Multiverse) implies to me that everything you need to know about FFes for universe/multiverse will be under that section
<jdstrand> however, based on other pages, that seems to not be the case
<jdstrand> (eg, new source packages)
<jdstrand> ScottK: can you clarify that?
<jdstrand> (not the page, but my weak understanding)
<ScottK> jdstrand: No.  That's meant to be differences from Main/Restricted, not comprehensive.
<jdstrand> ah
<jdstrand> that makes much more sense then
<jdstrand> *much*
<jdstrand> I have no further questions :)
<ScottK> Great
<jdstrand> ScottK: I may add some wording to that effect to the wiki
<ScottK> Absolutely
<jdstrand> ScottK: thanks btw :)
<ScottK> jdstrand: You're welcome
<slangasek> ScottK: kubuntu-netbook/lucid/armel> seems to be published now, without even having to repeatedly scrub the directory and republish with different commandline args
<slangasek> so for point release ports publishing, an unqualified success
<ScottK> Wahoo! Thanks slangasek.
<lool> Gosh, I had requested a FFE before the release again, I really suck
<lool> cjwatson: Sorry, was really confused about the beta release
<cjwatson> slangasek: dunno if you noticed, but netbook/ports/etc. release publishing should now be marginally less ridiculous with a change I made to publish-release to let you avoid all the ../ silliness
<cjwatson> it's still wonky in a fundamental way, but less irritatingly so
<slangasek> oh, cool
<slangasek> maybe that's why I was pleasantly surprised that publishing worked right the first time :)
<cjwatson> perhaps there should be a notion of source project and target project
<Laney> Does anyone have time to run a couple of reasonably pressing NEW source package syncs required for Banshee?
<Laney> I am led to believe that the plan is agreed with the RT
<Laney> gkeyfile-sharp/experimental gio-sharp/experimental
<Laney> sorry, that's one NEW source one NEW binary only
<Laney> filed them, bug 629899 bug 629895
<ubot4> Launchpad bug 629899 in gio-sharp (Ubuntu) "Sync gio-sharp 2.22.2-1 (universe) from Debian experimental (main) (affects: 1) (heat: 8)" [Wishlist,Confirmed] https://launchpad.net/bugs/629899
<ubot4> Launchpad bug 629895 in ubuntu "Sync gkeyfile-sharp 0.1-1 (universe) from Debian experimental (main) (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/629895
#ubuntu-release 2010-09-04
<ScottK> slangasek: (since you're the furthest west release team member) - It looks like the latest gcc4.4 upload is breaking many/all (not sure) powerpc builds.
<ScottK> (or anyone else).
<ScottK> Given where we are in the release cycle, not sure if that's a push the panic button item or not.
<ScottK> I have access to powerpc hardware and I'm trying to verify reverting fixes it.
 * holstein has *old* ppc hardware
<holstein> but if you need testing
<holstein> let me know
<slangasek> ScottK: do you have an example broken build?
<ScottK> slangasek: kipi-plugins
<ScottK> qt4-x11
<ScottK> kdeedu
<slangasek> ok
<ScottK> There may be more.
<ScottK> So far I've just found C++ examples.
<slangasek> this won't be a quick package to revert, so I'll wait for you to verify that reverting fixes it and in the meantime will poke at the diff (in between having dinner)
<slangasek> the failure mode is just a FTBFS, right?
<ScottK> Yes.
<ScottK> Not a misbuild at least.
<slangasek> ok; so once fixed we can do a mass giveback
<ScottK> Yep
<lamont> slangasek: do  you want the ppc buildds on manual while you wait?
<ScottK> lamont: I vote yes if that counts.
<ScottK> slangasek: My build with the previous gcc4.4 already got past where the current one failed.
<ScottK> I consider it confirmed.
<lamont> done
<ScottK> slangasek: That's about all I can do I think.  Over to you.
<ScottK> I'll check back in and let you know if the build finishes, but I'm confident it will.
<slangasek> "cannot find -lgcc_s" - ah, that definitely lines up with what I'm seeing in this diff
<slangasek> though I guess it'll take a bit to track down the faulty bit
<ScottK> That's good news.  At least it's not magically broken.
<ScottK> I'll leave it with you then.
<ScottK> slangasek: Don't forget to tell lamont when to turn the builders back on ....
<ScottK> Good luck.
<ScottK> slangasek: My test build with the old gcc-4.4 of kipi-plugins succeeded.
<lamont> so if someone wanted to fix gutenprint to not run -j16 at whereever it does that, arm might like it better (gourd may have fallen over completely, or it may just be very angry and slow)
<lamont> after checking, it looks to be just very angry and slow, not down-and-out.
<lamont> but I suspect it would build faster if it were less agressive
 * lamont sleeps
<slangasek> Files in first .deb but not in second
<slangasek> -------------------------------------
<slangasek> -rw-r--r--  root/root   /usr/lib/gcc/powerpc-linux-gnu/4.4/libgcc_s.so
<slangasek> well that probably explains it, don't it
<slangasek> heh; so all the bits are there in debian/rules*, but a missing make dependency means they get executed out of order
<slangasek> oh, no, simpler than that; they're just plain listed out of order
<slangasek> lamont: well, I have a candidate fix now; so turning the powerpc builders back on so we can build it would help :)
<lamont> so... are we expecting these gcc builds now running to be what we need?
<lamont> cjwatson: around?
<ScottK> slangasek, lamont, cjwatson: Looks like powerpc is fixed.  What's the best way to give back the failures?  All or is it easy enough to just do that ones that failed yesterday/today?
 * ScottK queued up enough that there's no rush to decide.
<lamont> ScottK: there's a script to do it, I was just waiting for 4.5 and arm and my sanity to all be happy
<lamont> weekend tasks are kind of interfering with my playtime
<ScottK> lamont: OK.  I think there's enough queued on powerpc that waiting for armel won't slow things down.
<slangasek> lamont: powerpc> hurray!  and armel is in progress then, I guess?
<ScottK> Looks like we'll know in another half a day or so.
 * slangasek nods
<ScottK> Actually gcc-4.4 finished much faster this time.  Looks like we are in business.
<Laney> published?
<ScottK> Yep.
 * Laney tries a give-back
<ScottK> Laney: lamont has a script he'll run to do a mass give back.
<ScottK> lamont: I think you can fire when ready.
<Laney> alright then
<ScottK> slangasek: ^^^
<ScottK> lamont: please tell me you took adare down for a good reason and it didn't just die randomly?
 * ScottK looks around for an FFe to support http://dylanmccall.blogspot.com/2010/09/new-installer-slideshow-for-ubuntu.html
#ubuntu-release 2010-09-05
<lamont> ScottK: adare dies randomly.  lucid hates ppc.  karmic hates ppc, just differently.
<lamont> I'm thinking I'll upgrade ross to lucid, too
<lamont> just not this weekend
<ScottK> OK
<lamont> so... file-roller_2.31.91-0ubuntu1
<lamont> and welcome back, adare
<lamont> pretty sure gutenprint would build faster (esp on armel) if it weren't doing -j16 regardless of CPU count
<ScottK> Might make sense to have a cap for armel.
<lamont> amd64 didn't like it either
<lamont> the machines whine at me when they do things like that
 * ScottK wonders if policy has anything to say about not using ridiculous values of -j.
<ScottK> (not enough to actually look it up though)
<lamont> QMDi10
<lamont> gar
<ScottK> lamont: I got bored/impatient and mashed retry on a large stack of packages.  I think I got them all so don't be suprised if your script doesn't pick up much when you run it.
<Laney> cjwatson: Would you be able to run some syncs out-of-band for me, please? We've a few new source/binary packages to get into Maverick for Banshee by default on UNE and it's really rather pressing now
<Laney> ScottK: alternatively, do you have some free cycles to NEW some stuff if we upload them manually?
<ScottK> Laney: If it's a no change sync from Debian, yes.
<Laney> ScottK: they are, thanks
<Laney> I'll ping you when they are in the queue
<ScottK> Great.
<Laney> ScottK: gtk-sharp-beans gio-sharp gudev-sharp-1.0 in NEW
<ScottK> OK.  I'll try to have a look in a bit.
<Laney> thanks
<cjwatson> sorry, was too late
<Laney> no worries
<Laney> feeling the time pressure on this one. :)
<cjwatson> actually, I see at least gtk-sharp-beans and gudev-sharp-1.0 are still in NEW
<cjwatson> mind if I reject those and sync them?  that way I can process them without having to think
<Laney> gio is only binary NEW
<Laney> yes, please do
<Laney> . o O ( these all belong in the cli-mono packageset too )
<cjwatson> Laney: from unstable?
<cjwatson> oh, and remind me of your LP id
<Laney> I think they all were
<Laney> laney
<Laney> gtk-sharp-beans might have been exp
<cjwatson> not even seeing it in experimental
<Laney> probably awaits dinstall
<Laney> it was NEWed this afternoon
<cjwatson> ah
<cjwatson> done gudev-sharp-1.0
<cjwatson> and done gtk-sharp-beans
<Laney> thanks so much
<Laney> I think those are the only source NEW, there's gio-sharp in binary NEW and libgpod to come also to binary NEW soon (but that's main so I can't upload it)
<Laney> cjwatson: I'll mail you regarding the packageset changes, there's no urgency on those
<slangasek> ogra: there don't appear to be package list files accompanying the preinstalled images; could you fix that?
<slangasek> ogra: (would make it easier to triage bug #630825, since I don't know offhand which uboot is on the omap image)
<ubot4> Launchpad bug 630825 in ubuntu-cdimage "Preinstalled Maverick netbook image won't boot on Gumstix Overo (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/630825
<slangasek> looks like it's probably u-boot-omap3, though :)
<cjwatson> would simplify some of the cdimage scripts if there were a list file, too :)
<slangasek> heh
<cjwatson> I didn't have time to whine about that on Thursday when I was Just Making It Work Damnit
 * ScottK2 fell asleep on the couch instead of doing Laney's New.
<Laney> ScottK: I think you picked the right option
<Laney> there's still some binary new available if you want it
<ScottK> Perhaps in a bit.  Need to go pick up one of the kids.
<stgraber> cjwatson: Hello, did you get that e-mail I sent you on Wednesday about the edubuntu gfxboot splash being 24bit instead of 8bit (and so, not showing up at all) ? (just checking, no rush ;))
<cjwatson> oh, yeah, I did, remind me tomorrow
<stgraber> ok, thanks
#ubuntu-release 2011-08-29
<micahg> can I actually get someone to reject the z88 upload?  I didn't mean to modify the CMakeLIsts.txt file in debian/
<micahg> thanks, I uploaded a second version that's fixed now
<superm1> skaet, i've just gotten back and uploaded a bunch of fixes that will need to be there for mythbuntu b1 ubiquity to work since Daviey didn't get them done last week
<superm1> they're in the approval queue right now
<pitti> good morning
<pitti> uh, LibO/armel _still_ building .. /me feeds the hamster
<pitti> NCommander: bug 820621 is still open, that means that omap is still screwed for b1?
<ubot4> Launchpad bug 820621 in flash-kernel (Ubuntu) "netinstall fails to make omap system bootable during install (affects: 2) (heat: 10)" [High,Confirmed] https://launchpad.net/bugs/820621
<pitti> tracker set up, cron disabled, missing images building now
<pitti> still waiting with mythbuntu for above packages, and with ubuntu for missing ubuntuone-installer (incomplete main promotion/-meta rebuild)
<pitti> jibel: we have images for ubuntu-server armel+ac100; can we add a product for this to the tracker?
<jibel> pitti, I'll add it.
<pitti> jibel: merci
<Daviey> There is also armel cloud images, but they should not be tracked for b1.
<Daviey> (New this sub-cyle)
<pitti> I'm not quite sure whether I'm supposed to add the server EC2 images
<pitti> Daviey: do you know?
<pitti> jibel: ^ or you?
<Daviey> pitti: This was disuccsed before, and there was uncertainity.  I thought the outcome was 'yes'.. but not sure
<pitti> someone else than me used to add these to the tracker with the correct version number
<pitti> Daviey: I meant the normal i386/amd64 ones
<Daviey> TBH, the testing has 100% jenkins coverage, not sure there is really /that/ much beneift of it being in the tracker
<pitti> there is a post-amis-to-iso-tracker.py script, but I've never used it
<pitti> so, education appreciated
<pitti> Daviey: fair enough
<Daviey> Does the tracker have an API for posting pass/fail?
<pitti> I don't know
<pitti> jibel, Daviey: do you know about the "Ubuntu Server UEC i386/amd64" images in the tracker? are they a special mode of the normal Ubuntu server images, or similar to the EC2 ones?
<Daviey> pitti: Well we test the images against Amazon for the automated stuff, then we also do some smoke testing against Ubuntu Cloud.  So yes, they are different.. it's more testing that they work on a different platform.
<pitti> Daviey: so should they be added with the versino of the ubuntu server images, or with the EC2 images?
<Daviey> You've probably noticed that this isn't clearly defined.
<Daviey> pitti: I'm not really sure it makes much difference where they are shown.. probably under EC2 images, as it isn't an ISO.
<pitti> ok, thanks
<jibel> pitti, for ec2 skaet runs a script, but never used it myself.
<jibel> Daviey, no API, hggdh and jamespage review the results and update the tracker.
<Daviey> jibel: Seems kinda man time intensive for something that could be reasonably automated.
<jibel> Daviey, updating the tracker is useful because there is one single place for the full status of the release.
<Daviey> jibel: Yeah, I certainly want to bring the cloud images more centralised into the release process.
<jibel> Daviey, indeed and that easy to automate but has always been low priority
<Daviey> pitti: If post-amis-to-iso-tracker.py doesn't contain anything sensitive, could you pastebinit please?
<pitti> Daviey: oh, want me to run it?
<jibel> Daviey, its in ubuntu-archive-tools
<Daviey> jibel: ah!
<Daviey> pitti: As jibel says, it does make sense for the cloud images to be on there.. But it seems like a waste of time for hggdh and jamespage to go and review each one.
<doko> please accept binutils-h8300-hms and gcc-h8300-hms
<Daviey> jibel: Hah, it provides a HTTP 'API' .. You have to steal a cookie from your browser.
<jibel> Daviey, heh, if you call 'posting an HTML form with a script' an API, sure there is an one ;-)
<jibel> s/an //
<Daviey> ;)
<doko> pitti: I would like to address bug #831410, have packages prepared in a PPA which I would like to copy into oneiric. includes gnat-4.4, gcj-4.4 and gcc-4.4
<ubot4> Launchpad bug 831410 in gnat-4.4 (Ubuntu Oneiric) (and 1 other project) "gnat-4.4 version 4.4.6-1ubuntu1 failed to build in oneiric (affects: 1) (heat: 6)" [High,In progress] https://launchpad.net/bugs/831410
<pitti> doko: gnat sounds fine, does it b-dep on the updated gcc/gcj?
<pitti> doko: what changes in gcc/gcj?
<doko> pitti: the multiarch fixes, which are already in 4.5 and 4.6
<doko> there's nothing which lands on the images
<pitti> right, but we probably still need some package updates for the b1 CDs
<pitti> i. e. need to build packages
<doko> pitti, that is the reason, copying the binaries too, such that the packages don't end up in a broken state
<pitti> doko: so what changes in gcc? is that more or less just a rebuild, or new version etc/
<pitti> ?
<doko>   * Re-work the multiarch patches.
<doko>   * Break older gcj-4.4, gnat-4.4, gdc-4.4 versions, changed gcc_lib_dir.
<doko>   * Fix [ARM] PR target/50090: aliases in libgcc.a with default visibility,
<doko>     taken from the trunk.
<doko>   * Taken from the gnat-4.6 package: debian/patches/ada-symbolic-tracebacks.diff
<doko>     (src/gcc/ada/gcc-interface/Makefile.in): pass -iquote instead of -I-
<doko>     to gnatgcc; fixes FTBFS on i386 and closes: #637418.
<doko>   * Fix libgnat* multiarch installation.
<pitti> doko: ah, thanks
<pitti> doko: so if you know that the "Re-work the multiarch patches." part doesn't break existing package builds, please go ahead
<doko> pitti, I would know, as it's already in 4.5 and 4.6 in the archive
<doko> ok, thanks
<jibel> ogra_, GrueMaster , pitti : server ac100 is posted with same test case than omap and linked to this image http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/current/oneiric-preinstalled-server-armel+ac100.tar.gz
<ogra_> jibel, ac100 wopnt be released with this milestone on release-team request
<jibel> ogra_, GrueMaster tell me if it is not correct and want to update something.
<ogra_> just ignore it
<pitti> jibel: nice, thanks
<pitti> ah, ok; will do that then
<pitti> removed
<jibel> ogra_, ok :)
<ogra_> server builds a lot quicker, we currently only enable that build to easier be ablet to do testbuilds
<jibel> pitti, thanks, it will be ready for next time.
<pitti> right, so it wasn't in vain :)
<ogra_> (desktop fails 60% of the time due to archive skew)
<ogra_> jibel, pitti, same goes for mx5 btw
<pitti> ogra_: we'll just support omap and omap4 for b1, right? anything else, like dove?
<ogra_> nope, only TI stuff this time
<ogra_> (omap3/4)
<doko> fyi, I'm accepting a NEW gcc-mingw-w64-bootstrap package to bootstrap the mingw64 packages, then will remove it again. will save IS manual interaction
<ogra_> pitti, i could need an omap4 testbuild ( i can do it myself if you want, but usually keep my fingers out of antimony during milestone freezes to not add confusion)
<ogra_> server should be fine for that and build fastest
 * ogra_ just needs to check bootability
<pitti> ogra_: sure, will rebuild; does it hurt to rebuild omap, too?
<ogra_> no
<ogra_> i dont think anyone is testing yet anyway
<pitti> started
<ogra_> thanks
<pitti> ubuntu desktops posted
<pitti> building DVDs now; rebuilding alternates
 * ScottK waves.
 * ScottK has no power due to the hurricane that hit the US (working from a restaurant ATM), so please don't block anything on hearing from me.
<pitti> hey ScottK, everything alright with you?
<pitti> the news here sound pretty scary
<ScottK> We were just on the fringe of it.
<ScottK> Other than no power, one fallen tree (didn't hit anything), and some branches to clean up, no problems.
<Daviey> Can swift and glance be accepted from unapproved please?
<pitti> ogra_: http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/20110829.1/ done for testin
<pitti> g
<pitti> cjwatson: http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/oneiric/daily-20110829.1.log complains about "Missing debootstrap-required gcc-4.4-base"
<pitti> started says it needs to move to optional
<pitti> WTH, paste failure
<pitti> http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt says to move that to optional
<pitti> that sounds fine; confirm, please?
<stgraber> Morning
<ogra_> pitti, thanks, rsycing
<pitti> Daviey: ah, these didn't come with linked RC bug reports and looked quite intrusive
<pitti> Daviey: they are required/wanted for beta-1?
<pitti> Daviey: alos, at least glance seems to introduce a new build dep on python-kombu, i. e. it'll just depwait as it is in universe
<Daviey> pitti: Yes.. I mentioned that I wanted a standing FFe for swift, nova & glance as the release cycles perfectly align.
<Daviey> They shipped their beta in time for our beta, rather than a snapshot.
<cjwatson> pitti: confirm
<pitti> cjwatson: cheers
<Daviey> pitti: there is a MIR for kombu
<cjwatson> (note bank holiday today, not necessarily around)
<pitti> Daviey: ok, your call
<Daviey> pitti: rocking, thanks.
<Daviey> cjwatson: bah, wish someone told me. :)
<pitti> Daviey: kombu MIR hasn't been checked/approved yet, so glance won't build
<pitti> Daviey: do you want the new swift in anyway?
<Daviey> pitti: meh, yeah.  I hoped that it might help give it more attention.
<Daviey> Would /really/ like to ship upstrea beta for our beta, rather than a snapshot.
 * skaet waves
<jibel> morning skaet
<skaet> good afternoon jibel
<skaet> :)
<pitti> skaet: FYI, current status: ubuntu alternates blocked on fixing a priority-mismatch, will rebuild in ~ 1 h; ubuntu DVD failed due to an NBS package, fixed seeds, rebuild pending
<pitti> skaet: omap4 images fail due to boot loader reorg, ogra is on it
<pitti> skaet: and ubuntu desktops need rebuild because of ubiquity FTBFS
<pitti> skaet: I updated https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview , but not complete yet
<skaet> pitti,  thanks for the summary (and starting updates to TechOverview)!
<charlie-tca> jibel: don't know yet if accessible will work this milestone.
<ScottK> ^^^ kalzium fixes installability for the Kubuntu dvd livefs, so I'd appreciate someone review/accept it.
<pitti> oh, nice, thanks
<iulian> Shouldn't that be -0ubuntu3?
<ScottK> No.  ubuntu3 was uploaded.
<ScottK> Dunno why the bot thinks it's ubuntu2 -> 4.
<ogra_> pitti, skaet, so that u-boot-linaro upload had an unannounced change in it that broke all omap4 builds, jcrigby or rsalveti will upload a new package soon, please let it through as fast as possible
<skaet> ogra_, ack
<iulian> ScottK: Oh OK. Something's wrong with the bot then.
<cjwatson> the bot works off what rmadison says
<cjwatson> $ rmadison -s oneiric -a source kalzium
<cjwatson>    kalzium | 4:4.7.0-0ubuntu2 |       oneiric | source
<ScottK> So just rmadison being laggy.
<ScottK> (i.e. not unusual)
<cjwatson> right
<cjwatson> though laggier than usual
<cjwatson> I'd investigate if I were actually at work today
<ScottK> Heh.
<ScottK> pitti: I dropped a lang pack on Kubuntu live amd64 for size purposes, so we'll probably want a respin of Kubuntu live regardless of if Ubiquity gets fixed.
<ScottK> i386 is at 701, which, IIRC, we decided was OK now.
<ScottK> BTW, http://people.canonical.com/~ubuntu-archive/testing/oneiric_probs.html seems confused since avogadro doesn't build armel binaries, but it show them as uninstallable.
<cjwatson> but they're still in the archive and in that case probably need to be removed
<pitti> ScottK: ah, I'll remove them then
<ScottK> Ah.  Yes.  Please.  They are unbuildable on armel due to Qt GL/GLES stuff.
<ScottK> Thanks.
<pitti> *zap*
<pitti> ScottK: is someone working on the kde-runtime-active uninstallability?
<pitti>  kde-runtime-active : Depends: plasma-scriptengine-javascript-active (= 4:4.7.0a-0ubuntu2) but it is not going to be installed
<ScottK> pitti: Yes.
<pitti>                       Conflicts: kde-runtime but 4:4.7.0a-0ubuntu2 is to be installed
<pitti> cool
<ScottK> It doesn't affect any images, so I think it's not essential for beta 1 though.
<pitti> ok, gcc-4.4-base priority fixed; /me rebuilds ubuntu alternates
<pitti> I'm not quite sure whether kubuntu-debug-installer is beta-1 critical
<pitti> libreoffice-style-andromeda task fixed as well, starting DVD build
<cjwatson> making progress on the ubiquity test suite; I expect we should be able to upload something today
<pitti> (won't be the final one due to ubiquity, but I'd like to get a working build at least, as it hasn't built for a while)
<cjwatson> aye
<pitti> cjwatson: yay you; moved the free day to tomorrow then?
<cjwatson> no, I might have a word with Steve about some kind of swap when I next see him
<cjwatson> I haven't actually had explicit confirmation that the new-style DVD images work properly as yet
<pitti> I'm eager to get a booting version as well, and tryin git
<pitti> s/ g/g /
<pitti> (I've tried git quite enough, FWIW)
<ScottK> pitti: AIUI the kubuntu-debug-installer is not beta1 critical.
<pitti> http://cdimage.ubuntu.com/daily/20110829.2/report.html
<pitti> yippie
<pitti> jibel: alternate ubuntu added to tracker
<pitti> skaet: I need to leave in about 15 mins for Taekwondo/EOD
<pitti> skaet: alternate posted, DVD building <- if that's done, could you add it to the tracker, please?
<skaet> pitti,  sure.   will do.
<pitti> skaet: and if ubiquity hits the queue, we'll need to let it through and re-trigger desktops/DVDs
<pitti> skaet: I'm fine to do that tomorrow morning, but if you get around to it, it might help speed things up
<pitti> ogra_: I'll read backscroll, just leave stuff here if you want me (or skaet) to trigger new armel builds
<skaet> pitti,  ok.   will keep eye for ubiquity update landing.
<ogra_> pitti, we need the new u-boot built first
<ogra_> before re-builds dont make sense
<pitti> ah, bug 836727 got fixed, that'll need a mythbuntu respin; but let's wait with that until ubiquity lands
<ubot4> Launchpad bug 836727 in casper (Ubuntu) "custom lightdm.conf including commented out autologin-user fails to be setup for live session (affects: 1) (heat: 6)" [Undecided,Fix released] https://launchpad.net/bugs/836727
<skaet> pitti,  who's putting out the ubiquity update?
<pitti> skaet: cjwatson | making progress on the ubiquity test suite; I expect we should be able to upload something today
<skaet> pitti,  ah,  I see it now in backscroll.  (and thanks cjwatson!)
 * infinity puts the publisher on manual so he can shove the u-boot fix in a tiny bit faster and get some testing today.
<jibel> hm, natty upgrade is still a failed bug 836798
<ubot4> Launchpad bug 836798 in pyatspi (Ubuntu Oneiric) (and 1 other project) "natty to oneiric upgrade failed: Could not perform immediate configuration on 'python-pyatspi2' (affects: 1) (heat: 6)" [Critical,Confirmed] https://launchpad.net/bugs/836798
<skaet> jibel,  thanks for flagging.
<charlie-tca> Still getting the onconf and jockey-backend crashes on Xubuntu alternate
 * stgraber hopes the fiber connection gets back online soon, kind of want to test the new ubiquity... (currently on a fallback DSL connection and 3G, but that won't do for ISO images...)
<NCommander> pitti: I have to touch f-k for the u-boot transition before B1 so I should be able to fix it today/tomorrow
<cjwatson> skaet: ^- ubiquity upload for you now
<cjwatson> 156-line diff, should be rather easily reviewable
<infinity> skaet: New live-build upload incoming to fix bug #836810
<ubot4> Launchpad bug 836810 in live-build (Ubuntu) "live-build uses wrong inode size for speedy preinstalled image resizing (affects: 1) (heat: 8)" [High,New] https://launchpad.net/bugs/836810
<infinity> skaet: Localised fix, will only affect ext* images (ie: armel preinstalled stuff)
<skaet> cjwatson,  thanks.  :)  slangasek will do the review.    Desktops/DVDs for all flavors to be rebuilt when it lands?
<micahg> skaet: is it worth getting firefox/thunderbird on powerpc for beta 1?  I think Debian has a fix for them
<infinity> micahg: Build time for mozilla.org sources is pretty insanely high, it'll delay testing by a fair bit.
<skaet> micahg,  prefer to wait until after beta 1.
<micahg> skaet: ok, I'll hold off then
<skaet> micahg,  thanks!
<infinity> skaet: Can I accept my two-line armel-only live-build change, or should I get someone else to review it first? :)
<charlie-tca> jibel, that upgrade bug for pyatspi wouldn't cause my upgrade to core dump on screen, right?
<cjwatson> I'll review it for you
<infinity> cjwatson: \o/
<infinity> cjwatson: It's just a dirty harcoded hack right now (cargo-culted from the known-working livecd.sh implementation) since live-build's ext* handling seemed to be based on the assumption that people would be doing livecds with ext*, not preinstalled images.  Will revisit making it a tunable option later.
<cjwatson> ugh, but ok
<cjwatson> accepted for now
<infinity> cjwatson: Agreed on the ugh, but the ext stuff kinda needs a rewrite to not assume "this is going on a read-only CD".
<cjwatson> yep
<cjwatson> the ugh isn't an immediate problem since we have no actual ext* live CDs
<cjwatson> skaet: rebuilt> yes
<cjwatson> skaet: is slangasek actually around?  I haven't heard from him today
<slangasek> yes, I am
<cjwatson> aha, ok
<infinity> slangasek: Are you sure? :)
<cjwatson> there's another problem in ubiquity, superm1 is working on a fix
<cjwatson> not a regression in 2.7.19 but breakage on the webcam page that will affect real-hardware installations
<cjwatson> (the page hangs, apparently)
<slangasek> 2.7.19 accepted, in the meantime
<stgraber> oh, too bad I don't have a fake webcam in my VM, would have fixed it yesterday otherwise... I guess I actually should use USB passthrough to test that page :)
<ara> skaet, ping
<skaet> ara, what's up?
<skaet> jibel,  Ubuntu DVD posted from build pitti started,  but doesn't have ubiquity change it in.   Do you want to do some sniff testing on it,  or wait until the version with ubiquity updates shows up?
<cjwatson> superm1: thanks, ubiquity 2.7.20 looks good
 * cjwatson accepts
 * skaet drums fingers waiting for it to go through the publishing.....
<skaet> :)
<jibel> skaet, yes I'll do some sniff testing. This is the 1rst 1.5GB DVDs and I know which bugs to avoid in current ubiquity.
<skaet> thanks jibel
<jibel> gilir, about bug 835961 an expert eye is required, but I think it's a problem the the seed not debian-installer.
<ubot4> Launchpad bug 835961 in debian-installer (Ubuntu) "Lubuntu oneiric alternate CD install fails to install lubuntu-desktop (affects: 4) (heat: 22)" [Undecided,Confirmed] https://launchpad.net/bugs/835961
<gilir> jibel, maybe, I copied the seed from the ubuntu one, but maybe I forgot something
<gilir> there is also reports about uninstallable packages on http://cdimage.ubuntu.com/lubuntu/daily/current/report.html but maybe it's not related
<NCommander> gilir: looks distinctly like a seed problem. Its been awhile since I dug into how the alternate installer decides which taskes to install. That being said, looking at tasksel on an oneiric machine, I only see 'Lubuntu minimal installation' and 'Lubuntu LiveCD'
<micahg> the ship seed is used for the alternate install
<micahg> gilir: take a look at line 39 in the lubuntu ship seed
<micahg> gilir: nevermind, shouldn't make a difference
<NCommander> micahg: what's the bzr path for lubuntu's seed so I take a look?
<doko> please could somebody have a look at new unapproved queue, universe packages?
<micahg> NCommander: http://bazaar.launchpad.net/~lubuntu-dev/ubuntu-seeds/lubuntu.oneiric
<NCommander> ah
<NCommander> so the desktop seed is exported in tasksel, it just has a weird name
<NCommander> mcasadevall@daybreak:~/Documents$ sudo apt-get install lubuntu-desktop^
<NCommander> that works, so the seed properly being exported from LP
<NCommander> I think the structure file might be wrong if I remember how tihs all goes together
<infinity> Yeah, the task works.  Though, I'm curious why "lubuntu-desktop" (the package) isn't being seeded into desktop. :P
<NCommander> Yeah, looks like the structure is wrong,
<NCommander> desktop: core
<infinity> That's fine.
<NCommander> and core is defined a core: standard, so that would only be ubuntu-standard+minimal (i.e., cli system only) which explains why d-i installed the wrong files
<infinity> The STRUCTURE is fine.
 * NCommander bows down to infinity's knowledge in this area
<infinity> NCommander: If comparing to the ubuntu seeds, s/core/desktop-common/ and it will make some sense.
<Daviey> Can we pre ubuntu-mir ack promote kombu?  I'd really like glane approved, to get on tomorrows daily.  Glance introduces it as a new dep.. and there is no doubt in my mind that it needs to be accepted.  The MIR in this case is to mostly look for issues, which can surely be done with it already in main.
<Daviey> I know pre-promoting caused upset before.. :/
<Daviey> thoughts?
<NCommander> infinity: I was looking at xubuntu's seed for comparsion, and that one doesn't even define desktop-common :-/
<gilir> is the order in the STRUCTURE important ? core is defined after desktop, maybe it's important ?
<infinity> NCommander: There's more than one way to do it. :)
<NCommander> infinity: seeds cause me brainpain whenever I work with them :-/
<infinity> gilir: This may not be a seed issue at all.  I mean, your tasks seem to be written correctly, right?
<infinity> gilir: And your metapackages generate correctly?
<gilir> infinity, meta-packages are OK yes
<infinity> gilir: It looks to me like d-i just plain doesn't know to install lubuntu-desktop.
<Daviey> NCommander: Yeah, it's not really that easy to check what you have done before committing. germinate doesn't help *that* much.
<infinity> gilir: Though, to nitpick, the lubuntu-desktop package *should* be in your desktop seed.
<infinity> gilir: So that "apt-get install lubuntu-desktop^" does the same tihng as "apt-get install lubuntu-desktop"
<infinity> gilir: (Currently, installing the task won't install the metapackage)
<gilir> infinity, ah right, the other seeds do this
<NCommander> Seems to me that d-i simply isn't selecting the task during the Install Packages Phase
<infinity> That would seem to be the case, yeah.
<infinity> But the task is obviously "there".
<infinity> So blaming the seeds seems a bit wrong.
<infinity> I mean, the seeds might be suboptimal, but if the task exists, even broken, it should try to install it. :)
<infinity> (And other than the above missing metapackage, the seeds seem vaguely fine anyway)
<infinity> I've never implemented a new -desktop flavour in d-i/alternate land.  What sort of mangling is required?
 * NCommander feels like we need a voodoo witchdoctor
<infinity> Perhaps someone just missed a critical "tell this CD it's a lubuntu-desktop CD" step.
 * NCommander pokes around on antimony
<infinity> data/oneiric/preseed/lubuntu/lubuntu.seed:tasksel	tasksel/first	multiselect lubuntu-desktop
<infinity> That would seem to be the bit there. :/
<NCommander> hrm
 * NCommander wonders if the Task: data is ending up on the CD's pool
<NCommander> since the dists files are regenerated by d-cd, its possible its not including the task metadata when it runs apt-ftparchive through everything
<infinity> More curiously, I wonder if the installer has universe enabled at that point, and perhaps it's just filtering out the task.
<infinity> Oh, but xubuntu is universe too, so that should be a solved problem.
<infinity> NCommander: But yes, if it's not pulling the lubuntu seeds on the debian-cd germinate run, that would do it.
<infinity> NCommander: Which seems entirely likely with them being in a non-standard location.
<NCommander> Well, we build xubuntu images with universe so that codepath should work fine (else xubuntu alternates would be foobared)
 * NCommander downloads a lubuntu alternate and pokes its pool
<jdstrand> ScottK: is it ok if I do a sync of otrs2 and phpmyadmin for security fixes? no ubuntu delta on either
<infinity> NCommander: Hrm, cdimage pulls seeds from people/~ubuntu-archive/seeds/, which does include lubuntu.  So, task generation should be working...
<infinity> In theory.
<NCommander> might just need to run through the install and see what the task selector debug output is :-/
<gilir> hum, lubuntu-desktop binary doesn't seems to be in the alternate pool/
<infinity> gilir: Because you didn't seed it.
<infinity> gilir: See above for my complaint on that score. :)
<infinity> That said, while that's a definite bug on your part, d-i installs via tasks, not packages, so it should still be working.
<infinity> Just missing the metapackage.
<gilir> ok thanks :) I pushed the fix for this at least
<infinity> NCommander: Tasks in /srv/cdimage.ubuntu.com/scratch/lubuntu/daily/tasks/oneiric seem fine to me.
<infinity> (Or, at least, seem to be there, with some packages included in lubuntu-desktop)
<infinity> NCommander: And Packages files in /srv/cdimage.ubuntu.com/scratch/lubuntu/daily/tmp/oneiric-amd64/CD1/dists/oneiric also look sane.
 * infinity puzzles.
<infinity> I see no functional differences between this and a xubuntu CD. :/
<NCommander> infinity: all the tasks are correct on the CD ...lubuntu-desktop, lubuntu-core, standard and minimal are all present
<NCommander> # Install the Lubuntu desktop.
<NCommander> tasksel	tasksel/first	multiselect lubuntu-desktop
<NCommander> as is the preseed file
<NCommander> hrm
 * NCommander has an idea
<infinity> Wait, wait, wait.
<infinity> Why is lubuntu-core a task at all?
<infinity> That means that you almost certainly can't install lubuntu-desktop^ without lubuntu-core^...
<gilir> infinity, including lubuntu-core package in lubuntu-desktop task is not enough ?
<infinity> gilir: To be honest, I'm not even sure why you have lubuntu-core.
<NCommander> infinity: trying to install lubuntu-desktop with only the CD is impossible (uninstallable packages)
<infinity> gilir: But if you insist on having it, having the dependencies correct in STRUCTURE (as you do) would get core's packages in the desktop task, if it wasn't for the fact that you made core a task.
<gilir> infinity, to be able to generate a lubuntu-core metapackage
<infinity> gilir: Sure, same question.  Why do you want a metapackage with 5 packages in it?
<NCommander> I thought d-i was supposed to explode if packages were uninstallable, right?
<infinity> gilir: The only reason for "desktop-common" is to have a commin base for kubuntu and ubuntu.  They don't have a desktop-common metapackage or task.
<infinity> NCommander: Ideally, things should explode long before d-i...
<infinity> NCommander: Like, during the image build, perhaps.
<NCommander> infinity: d-cd will still build an alternate with uninstallable packages :-/
<infinity> NCommander: Irksome.
<infinity> NCommander: So, it may not be an infrastruture issue at all, just broken packages?  That doesn't bug me. :P
<infinity> gilir: ^
<infinity> gilir: I'd still say that having lubuntu-core (both as a metapackage and a task) seems wrong, BTW.
<gilir> infinity, well, I only need it as a metapackage :) I'm fine to remove it as a task if it's possible
<slangasek> why do you need it as a metapackage either?
<infinity> ^
<gilir> slangasek, to have an easy way to install a basic / minimal system
<infinity> gilir: Not to be dense, but the tiny package set makes no sense to me anyway.  Who would want it without desktop?
<gilir> well it was useful before ISO was available with the official build system
<infinity> gilir: Sure, but times change. :)
<infinity> gilir: Anyhow, metapackages without tasks are easy.  Remove the task headers from the seed, keep building the metapackage in lubuntu-meta.  The two don't relate at all.
<gilir> infinity, sure :) I could probably make the same by playing with the desktop seed
<infinity> gilir: (But I'd probably argue that all the stuff in core just belongs in desktop)
<infinity> Or, if you're trying intentionally to keep core ~= platform/desktop-common (which could have semantic uses), I'd still argue for removing the task headers, removing the metapackage, and just letting the STRUCTURE deps pull core into desktop.
<infinity> (Which is what happens with desktop-common for ubuntu/kubuntu)
<jibel> text installer vanished from DVDs ?
<doko> infinity, please could you accept timbl?
<stgraber> is it just me or do we have publisher/archive problems? I still don't see ubiquity 2.7.20 here and it built 2.5 hours ago...
<stgraber> (I still get ubiquity 2.7.17)
<skaet> stgraber,  its still not published.
<skaet> arm builds finished about an hour ago
<skaet> we're waiting for current publisher run to pick it up.
<stgraber> oh, arm, that'd explain it indeed :)
<skaet> ok,  looks like ubiquity's landed in the archive.
<skaet> kicking off the desktop, dvd rebuilds
<doko> what is the story behind usplash?
<slangasek> doko: kill all traces of it
<doko> slangasek, I'll assign to ubuntu-archive ;-P
<slangasek> jibel: yes, per discussions at UDS we're replacing the full 4.4GB DVD image with a smaller 1.5GB USB stick
<slangasek> it will still be called a "DVD" image, but it will be smaller and more practical for other uses
<slangasek> doko: isn't it already gone from the archive though? :
<slangasek> doko: also, subscribe rather than assign please, if you want it to show up on the right list :)
<doko> slangasek, but not dependencies, see http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20110816-oneiric.html for the packages starting with usplash*
<slangasek> ah, sure
<slangasek> those should definitely all go away; plymouth is non-optional, usplash conflicts with plymouth
<doko> infinity, slangasek please accept transgui mathgl flphoto, all fixing ftpfs
<gilir> infinity, NCommander I think I found a problem, libavcodec* is excluded from the "ship" seed, which block several packages to be installed
<gilir> is ffmpeg / libavcodec still banned from the CD, or can I safely add it ?
<slangasek> it is still banned from the CD.
<doko> please accept opennebula
<jibel> slangasek, from the discussion on ubuntu-devel I was not sure that it meant dropping the text installer from the new DVDs. Thanks.
<skaet> Ubuntu desktop images (20110829.1) with ubiquity update now posted on iso tracker.
<NCommander> d-i/armel is built, pending publication. omap3 netboot images will likely be unusable due to an issue with ethernet on omap3
<NCommander> ^- skaet
<skaet> Ncommander,  understood.   Is there someone looking at the omap3/ethernet issue?  bug number?
<Daviey> Please can python-carrot be promoted (MIR ack'd) and glance be accepted from unappoved.  Thanks.
<cjwatson> jibel: removed specifically from the Ubuntu DVD; others haven't changed
<cjwatson> anything I can be looking at given a spare half-hour or so before I go to bed?
<Daviey> doko: What was  https://launchpad.net/ubuntu/+source/php5/5.3.6-13ubuntu3.1 for?
<doko> Daviey, accident. but the accident did succeed for armel and powerpc. can you fix the amd64 one?
<Daviey> doko: I was lazy and just fired a rebuild to see if it is a real issue.
<doko> Daviey, fine, then it's your problem now ;-P
<doko> slangasek, ^^^ he volunteered
<Daviey> aww crap.
<cjwatson> gilir: anything that requires libavcodec would cause such a problem, yes, if you still have the blacklist entry.  although Ubuntu Studio images have had libavcodec on them for ages and we agreed that was OK, so I don't see why we couldn't do the same for Lubuntu, really
<Daviey> doko: This wasn't an issue when you did the rebuild last time, was it?
<cjwatson> the TB resolution principally applied to CD images that we were pressing and shipping; for images we just offer for download, I don't see why they need to be treated any differently from packages we offer for download in the archive
<doko> Daviey, I don't know, and slangasek couldn't reproduce this one either :-(
<skaet> cjwatson,  looks like we're seeing issues with the newest images (with new ubiquity, though not sure if related),  can you switch to #u-testing?
<doko> skaet, I'd like to ask lamont tomorrow to give back failed builds on amd64 and i386 and powerpc. the buildds are idle, and should be fine to handle the load
<skaet> doko,  hold off on that please.   We've got too much breakage, and a possibly security update about to land.
<Daviey> doko: looks like it's purging.. gah.
<doko> skaet, can we work around it be up-scoring needed builds?
<Daviey> doko / skaet: If the failed builds were given back, if they succeed they'll be jailed in unapproved so wouldn't endager the archive stability, right?
<infinity> Daviey: No.
<infinity> Daviey: Only sources get shunted to unapproved.
<skaet> doko, what does it hurt to wait 1-2 days?
<Daviey> Hmm, I thought binary was aswell.
<doko> skaet, because the buildds will be loaded after the thaw
<cjwatson> Daviey: never
<doko> Daviey, php5 failed as usual on amd64
<Daviey> doko: yeah
<skaet> doko, if things look better this time tomorrow, we can see about it, but right now priority is getting beta 1 out.
<doko> skaet, we have now five i386 buildds, and three amd64 buildds, that should be fine. ok, I'll ask you again tomorrow
<cjwatson> giving back individual shortish builds isn't a problem (even now IMO), but a mass give-back risks a situation where all available buildds are building something multi-hour
<doko> I would agree, if we only had two buildds/arch
<cjwatson> I've seen that situation with >2
<infinity> Daviey, doko : A quick guess (I can test this), but changing the autoconf build-dep to autoconf2.13 might make it happy.
<Daviey> infinity: it would have used that, no?
<doko> infinity, cool, have a try, and take the issue
<Daviey> infinity: can i assing bug 837049 to you?
<ubot4> Launchpad bug 837049 in php5 (Ubuntu Oneiric) (and 1 other project) "php5 FTBFS (amd64 only) (affects: 1) (heat: 6)" [High,Confirmed] https://launchpad.net/bugs/837049
 * infinity scowls.
<infinity> I'll test and let you know. :P
<skaet> slangasek,  anyone around that can look into the upgrade issues that they're seeing from natty -> oneiric?
<cjwatson> skaet: #ubuntu-devel indicates that TheMuso is looking into it ...
<slangasek> skaet: which upgrade issues are these?
<jibel> slangasek, bug 836798
<ubot4> Launchpad bug 836798 in pyatspi (Ubuntu Oneiric) (and 1 other project) "natty to oneiric upgrade failed: Could not perform immediate configuration on 'python-pyatspi2' (affects: 2) (heat: 12)" [Critical,Confirmed] https://launchpad.net/bugs/836798
<skaet> cjwatson, jibel,   are they the same?  it sounded different from the channel discussion.
<cjwatson> that's the exact bug TheMuso said he was working on
<cjwatson> so what's the other thing you mention as "they"?
<jibel> skaet, it is the critical upgrade issue, the other one I was mentioning is far behind this one in term of importance.
<cjwatson> if you mean the freezes Charlie reported, as I said, a system freeze is always a kernel bug
<jibel> slangasek, the upgrader fails to calculate a correct upgrade path to transition from at-spi1 to at-spi2
<skaet> cjwatson, sorry,  "they" are the bugs - system freeze,  screen dump, pyatspi upgrade.
<cjwatson> I think we all need to try to be quite precise :)
<skaet> :)
<skaet> agreed!
<charlie-tca> Let's not count mine until I see if it can be reproduced
<cjwatson> I'm not desperately worried about an upgrade freeze for the purposes of oneiric beta, because by definition it must be a bug in the *natty* kernel
<cjwatson> if it happened to everyone we'd need to see about some kind of workaround; although we might also expect that something like that that happened to everyone would have been fairly prominent in the stable fix queue by now
<cjwatson> the pyatspi upgrade is more of a concern because that's clearly a logical flaw we can and should fix
<cjwatson> no possibility of it being hardware-specific or whatever
<ScottL> cjwatson, bug #837000
<ubot4> Launchpad bug 837000 in usplash-theme-ubuntustudio (Ubuntu Oneiric) (and 9 other projects) "usplash cruft removal (affects: 2) (dups: 1) (heat: 16)" [High,Confirmed] https://launchpad.net/bugs/837000
<ScottL> cjwatson, how would i fix this?  apparently i need to address removing the ubuntustudio usplash package from oneiric
<skaet> Ubuntu DVD 20110829.1 posted
<slangasek> ScottL: there's no action needed by you for that bug; the archive admins will remove it from the archive
<cjwatson> yep
<cjwatson> plymouth-theme-ubuntustudio already exists
<ScottL> cjwatson, i know about plymouth-theme-ubuntustudio...i made it ;)
<ScottL> heh, probably the only package
<ScottL> slangasek, cjwatson thank you very much :-)
<cjwatson> indeed, I was just emphasising that you don't even need to work on a replacement since you already have one
<cjwatson> infinity: https://launchpadlibrarian.net/76130771/buildlog_ubuntu-oneiric-armel.mrpt_1%3A0.9.4-1ubuntu2_FAILEDTOBUILD.txt.gz - do you think anyone would mind if I removed mrpt's binaries on armel?
<cjwatson> "virtual memory exhausted: Cannot allocate memory" doesn't look exactly promising
<cjwatson> no rdepends
<cjwatson> I suppose I could lob it back and see if a different buildd randomly succeeds, but it takes a day to build
<infinity> cjwatson: A different machine with more swap might like it better.  If there are stale old binaries you want to ditch, though, go nuts.  I doubt anyone will care.
<skaet> Xubuntu daily-live 20110829.1 (posted)
<charlie-tca> Thank you
<doko> infinity, please accept gcc-m68hc1x libavg ckermit
<doko> or somebody else
<Daviey> Please can python-carrot be promoted (MIR ack'd), glance be accepted, cobbler be accepted and openstack-dashboard be rejected. Thanks.
<Daviey> Oh, and kombu promoted. (MIR also ack'd)
<Daviey> not quite sure why python-novaclient was allowed into unapproved it is no change (including version), from what is in the archive
<Daviey> Suprised that wasn't rejected straight away
<cjwatson> doko: the gcc-m68hc1x change is wrong.  O_TRUNC and O_CREAT belong in the flags argument; mode should be a permissions word like 0644 or something
<cjwatson> doko: I'm rejecting that, can you please upload a correct fix instead?
<doko> cjwatson, ok
 * doko grumbles about old toolchain stuff and kees default changes
<cjwatson> ckermit accepted; libavg is mine so can't accept that
<doko> anyway, things will have to wait until tomorrow, afk now
<cjwatson> yeah, me too
<kees> doko: old? the defaults are wonderful :)
<doko> kees, I like pie on my plate only
#ubuntu-release 2011-08-30
<cjwatson> at-spi2-core looks good, accepted
<cjwatson> that should deal with the upgrade problems
<kees> doko: heh
<doko> infinity, Daviey: the php5 build did succeed, wondering how ... please don't touch anything before squlite is demoted
<infinity> doko: Yeah, I won't fix it properly until a bit later.  No worries.
<skaet> stgraber, highvoltage - edubuntu dvd 20110830 has been published (ubiquity fixes).
<stgraber> thanks
<skaet> stgraber, are you going to need a respin to pick up the at-spi2-core upgrade fix?
<stgraber> I'm not aware of that one, what's it fixing?
<superm1> skaet, can we get the respin of mythbuntu to verify the mythbuntu-*, ubiquity, and casper fixes?
<skaet> superm1,  mythbuntu is being built right now (almost done),  one of the builders failed though, but not sure if its serious or not.   Can you have a look at the logs?
<skaet> Tue Aug 30 00:34:28 UTC 2011
<skaet> BUILDING:  mythbuntu live cd
<skaet> kapok.buildd starting at Tue Aug 30 00:34:28 UTC 2011
<skaet> cardamom.buildd starting at Tue Aug 30 00:34:28 UTC 2011
<skaet> kapok.buildd finished at Tue Aug 30 00:41:25 UTC 2011 (failed)
<skaet> cardamom.buildd finished at Tue Aug 30 00:56:31 UTC 2011 (success)
<superm1> skaet, you mean this failure? http://people.canonical.com/~ubuntu-archive/livefs-build-logs/oneiric/mythbuntu/20110830/livecd-20110830-amd64.out
<superm1> i think that's the php5 problem on amd64 that's been discussed above
<skaet> superm1,  yeah,  I think you're right.
<skaet> superm1 - Images just got published to cdimage.   There is one there for amd64 (oversided though).   i386 logs look ok.
<skaet> Do you want me posting the amd64 and i386 one to the iso tracker?
<skaet> superm1, ^^
<superm1> cool thanks.  only post amd64 if it actually has the new stuff, old livefs isn't worth it
<superm1> the oversized problem won't be fixed for b1, not really sure why it's happening still
<skaet> both images have the new ubiquity
<skaet> Mythbuntu 20110830 images posted
<superm1> skaet, er checking http://cdimages.ubuntu.com/mythbuntu/daily-live/20110830/oneiric-desktop-amd64.manifest it still has the old ubiquity 2.7.17, probably because that livefs did fail
<superm1> so you can pull that one off the tracker for now
<skaet> superm1 - will do.
<skaet> done
<skaet> ScottK,  kubuntu desktop images posted (20110830),  several oversize.  Some other issues with the powerpc one that need looking into.
<skaet> gilir,  lubuntu live cd 20110830 posted.
<skaet> ScottK,  kubuntu dvd images posted (20110830)
<pitti> Good morning
<pitti> hey skaet
<pitti> ah, nice, all new images
<skaet> heya pitti,  yup,  and a bunch on new ones still to be spun
<skaet> just a sec and I'll paste the summary
<pitti> nice, no red bugs on the desktops so far
<skaet> pitti,  First round of livecd/dvd rebuilds that worked have been posted.  In  progress:  ubuntu server image build followed by rebuilds of ubuntu live cd;  ubuntu live dvd; edubuntu live dvd to pick up at-spi2-core 2.1.5-0ubuntu3.  Following that is a rebuild of mythbuntu to see if it will pick up php, and succeed for amd64.
<pitti> skaet: hang on, why do we need a rebuild for at-spi2-core2? I thought that was only an upgrade fix?
<skaet> pitti,  in parallel have also started off the ARM images builds pick up ubiquity and other changes.  OMAP3 images aren't working though it seems (network kernel issue).
<skaet> pitti,  seemed to be interfering with people using update-manager, and was marked critical,  so went ahead and started the builds off for the pieces that had reference to it. https://bugs.launchpad.net/ubuntu/+source/at-spi2-core/+bug/836798
<ubot4> Launchpad bug 836798 in at-spi2-core (Ubuntu Oneiric) (and 1 other project) "natty to oneiric upgrade failed: Could not perform immediate configuration on 'python-pyatspi2' (affects: 2) (heat: 12)" [Critical,Fix released]
<pitti> skaet: ah, ok; it's not an issue for installation
<pitti> ^ for bug 837048, in case we do another rebuild
<ubot4> Launchpad bug 837048 in apport (Ubuntu) "ubuntu-bug ubiquity causes a traceback due to an UnboundLocalError (affects: 1) (heat: 6)" [High,Fix committed] https://launchpad.net/bugs/837048
<pitti> I saw it in the iso tracker, if someone wants to review
<pitti> hm, I see bug 689323 all over the place in the tracker, I guess I have a look at this
<ubot4> Launchpad bug 689323 in jockey (Ubuntu Oneiric) (and 2 other projects) "ERROR:dbus.proxies:Introspect error on :1.68:/DeviceDriver: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus) (affects: 411) (dups: 84) (heat: 1120)" [High,Confirmed] https://launchpad.net/bugs/689323
<pitti> already times out on LP, awesome
 * pitti reviews the queue for unseeded packages
<pitti> I'll accept packages slow enough for the buildds to keep up (and keep a free one)
<skaet> pitti,  sounds good.   Thanks!  and on that note,  I'm heading to zzz land.
<pitti> skaet: thanks, sleep well!
<pitti> ugh, I'm afraid bug 689323 warrants a rebuild, as it breaks driver installation for everyone :(
<pitti> I'm testing/uploading a fix now
<ubot4> Launchpad bug 689323 in jockey (Ubuntu Oneiric) (and 2 other projects) "ERROR:dbus.proxies:Introspect error on :1.68:/DeviceDriver: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus) (affects: 411) (dups: 84) (heat: 1124)" [High,Confirmed] https://launchpad.net/bugs/689323
<pitti> NCommander: AYT?
<NCommander> pitti: AYT?
<NCommander> Whats AYT?
<pitti> hey NCommander
<pitti> "are you there"
<pitti> just wondered if there's anyone else around who can review/accept the jockey fix
<NCommander> well, that question was answered
<pitti> heh, yes
<NCommander> looking
<pitti> NCommander: not uploaded yet
<NCommander> LP timed out twice -_-;
<pitti> yes, to look at that bug you need /+text
<NCommander> (I can't actually approve into archive)
<pitti> I just added a bug pattern
<pitti> so that we won't get even more dupes
<NCommander> pitti: What do you want me to review specifically? (i'm reading the text log)
<NCommander> (I assume there is a patch in here somewhere)
<pitti> NCommander: I mean my upload
<NCommander> I'm not an archive admin :-/
<pitti> ah, ok
<pitti> I guess I have to self-approve that then
<NCommander> pitti: I thought you were an admin
<NCommander> Oh
<pitti> skaet went to bed, and it's still too early for the other Europeans
<NCommander> skaet isn't an archive admin either
<pitti> NCommander: yes, but we usually do four-eyes principle during freezes
<pitti> NCommander: she is
<NCommander> When did that change?
<pitti> NCommander: so, to at least do that some justice: the problem is that I tested jockey with the new pygobject 2.90 only, but that was held back due to ubiquity
<pitti> but it breaks with the old pygobject
<NCommander> Ow
<pitti> http://bazaar.launchpad.net/~ubuntu-core-dev/jockey/ubuntu/revision/575
<pitti> this is the fix
<jbicha> new pygobject won't happen until after beta?
<NCommander> This sounds like a bloody headache
<pitti> which I have uploaded just now
<pitti> jbicha: right
<pitti> I can revert that workaround once pygobject 2.90 is in
<pitti> damn, I should have gotten to this earlier
<pitti> anyway, once it's in, I'll trigger new desktops
<pitti> otherwise we'll screw all the nvidia users
<pitti> FTR, self-accepting jockey from the queue; I'll take the bullets
<pitti> and with that I can just as well accept apport as well, to unbreak ubuntu-bug ubiquity
<pitti> ok, I accepted all unseeded packages with good fixes, to make use of the buildds
<pitti> NCommander: so omap is still officially broken, right? I'll just add the omap4 images to the tracker
<NCommander> pitti: just ethernet, and I'm not 100% clear on that, need to reconfirm with GrueMaster
<pitti> ah, ok
<jibel> good morning
<pitti> bonjour jibel
<jibel> morgen pitti
<pitti> jibel: FYI, just started to rebuild all images to pick up latest fixes, in particular the jockey crash
<pitti> sorry about that
<jibel> pitti, no problem, this jockey crash 689323 ?
<pitti> right
<pitti> jibel: IMHO worth rebuilding, as it completely breasks jockey everywhere and thus prevents installation of broadcom/nvidia etc.
<pitti> I also added a bug pattern for it to avoid getting even more dupes
<jibel> ok. I'm verifying the at-spi2-core fix.
<jibel> ubiquity bugs reported during the night are all known. looks good.
<pitti> ubuntu alternate added
<pitti> desktop/server preinstalled omap/omap4 added
<pitti> kubuntu alternate added
<pitti> ubuntu desktop added
<Daviey> Gah, who accepted openstack-dashboard?
<pitti> Daviey: was that wrong? it'll land in binNEW anyway
<pitti> just wanted to give the buildds some fodder
<pitti> and as it's in universe/unseeded it seemed quite harmless
<pitti> Daviey: I can reject the binaries if they are known-bad
<pitti> (https://launchpad.net/ubuntu/oneiric/+queue?queue_state=0)
<pitti> kubuntu desktop posted
<pitti> xubuntu alternate posted
<Daviey> pitti: nah, not really, really bad.
<Daviey> 00:46 < Daviey> Please can python-carrot be promoted (MIR ack'd), glance be accepted, cobbler be accepted and  openstack-dashboard be rejected. Thanks.
<Daviey> 00:47 < Daviey> Oh, and kombu promoted. (MIR also ack'd)
<Daviey> 00:50 < Daviey> not quite sure why python-novaclient was allowed into unapproved it is no change (including version),  from what is in the archive
<Daviey> 00:51 < Daviey> Suprised that wasn't rejected straight away
<pitti> Daviey: so, openstack-dashboard shouldn't be in the archive at all? or a different version?
<Daviey> pitti: it's not that bad.. I just didn't want *that* one accepted without a fix
<pitti> Daviey: ok, keeping in binNEW then
<pitti> Daviey: so, do you want above in beta-1?
<Daviey> pitti: yes please.
<pitti> Daviey: then I'll do the promotions/acceptance now
<Daviey> pitti: Great!  Thanks
<pitti> Daviey: hm, I just see that glance is in universe; should that be on the server image, i. e. seeded and in main?
<Daviey> funny you say that.
<pitti> promoted/accepted
<Daviey> \o/
<pitti> or will they be for b2?
<pitti> I'm a bit confused how a universe package can have a "Task: openstack"
<pitti> or is that not part of the server CD?
<Daviey> pitti: sevrer doesn't have a server-supported, that got broken down a while ago
<Daviey> So there is a seperate seed just for openstack
<Daviey> although currently it is both server-ship and supported.. will probably fall off server-ship before release.
<pitti> just saying that universe packages in seeds are just silently ignored for CD builds, unless the CD has universe enabled (which is only the case for ubuntustudio, mythbuntu, and xubuntu AFAIK, not for server)
<pitti> Daviey: asked in a more direct way, do we actually need a server image rebuild after this?
<Daviey> pitti: Well ideally i would.. which was why i was trying to get it pushed through last night :(
<Daviey> it's not essential tho.
<pitti> Daviey: what would change with a rebuild?
<pitti> Daviey: http://cdimage.ubuntu.com/ubuntu-server/daily/20110830/oneiric-server-amd64.list doesn't have either cobbler nor glance (as they are in universe)
<Daviey> pitti: Hmm, well - i wanted to iso to be usable without net connection for b1. Currently openstack will not work without glance, at all.
<Daviey> So the only thing that changes is that people can use it without direct net connection.. but not that exciting really.
<pitti> xubuntu desktop posted
<cjwatson> morning folks.  anything I can usefully do first?
<pitti> hey cjwatson
<jibel> morning cjwatson
<pitti> cjwatson: I hope you got some sleep after that nightshift.. thanks for the ubiquity fixes!
<pitti> cjwatson: nothign too serious right now, I'm rebuilding all images after the jockey fix, and testing current desktop i386 right now
<cjwatson> it wasn't too late, and I have this afternoon off as a swap for yesterday
<pitti> Daviey: seems that's going to require a bunch of more MIR reviews: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<pitti> glance, ipy, nova, python-anyjson, python-dingus, python-novaclient, python-stompy, socat
<pitti> ubuntustudio posted
<Daviey> pitti: Yeah. :( I did that trick btw: http://people.ubuntu.com/~davewalker/component-mismatches-mir-track.html
<Daviey> Makes it much easier for me to track that for my needs.
<pitti> nice!
<Daviey> Out of interest, what fixed the powerpc oversize?
 * pitti hides his really scary big hammer
<Daviey> eep.
<pitti> Daviey: I dropped another langpack from there, and it shrank massively together with the other images due to the langpack -base refresh
<pitti> the updates packages got quite large
<Daviey> pitti: Hmm, well it's well within size now :_)
<Daviey> oneiric-server-powerpc.iso           30-Aug-2011 04:36    0
<pitti> that looks a little ... overoptimized?
<Daviey> lol
<Daviey> I wonder why power was larger to start with?
<pitti> it tends to be on all images, not sure why
<pitti> do we still ship two kernels on those? (32/64 bit)
<cjwatson> yes
<Daviey> build log isn't that useful
<cjwatson> I think
<Daviey> Using HFS name: squashfs-modules-3.0.0-9-powe_1 for CD1/pool/main/l/linux/squashfs-modules-3.0.0-9-powerpc64-smp-di_3.0.0-9.14_powerpc.udeb
<Daviey> Aborted
<Daviey> make: *** [bin-images] Error 134
<Daviey> ERROR WHILE BUILDING OFFICIAL IMAGES !!
<Daviey> Is it possible to do an inplace arch rebuild, without incrementing?
<cjwatson> we can rebuild a single arch but it will increment
<pitti> mythbuntu posted
<Daviey> Hmm.. exit 134 is often something like out of resource or seg fault.. So i'm wondering if it was just a bad day?
<pitti> skaet indeed got an error when she was building the server images
<pitti> I didn't see that yesterday
<pitti> (in my builds)
<pitti> lubuntu alternate posted (but has uninstallables in report)
<Daviey> Can a rebuild be done without posting to cdimage just to check if it can be reproduced?
<pitti> meh, kubuntu preinstalled failed on libo; I thought we removed LibO for armel
<pitti> Daviey: not really, but we don't need to post it to the tracker
<pitti> Daviey: starting
<Daviey> thanks
<Daviey> The problem is that current symlink seems to be cared about more than the tracker :/.. ah well.
<pitti> Daviey: I can reset the current symlink manually if it fails again
<Daviey> ah groovy
<cjwatson> pitti: er, yes, it can actually :)  but too late now
<cjwatson> DEBUG=1
<pitti> hm, lubuntu desktop failed, only powerpc succeeded; the 0829 build worked, investigating
<cjwatson> lamont: I don't suppose you could help me debug http://people.canonical.com/~ubuntu-archive/livefs-build-logs/oneiric/ubuntu-zh_CN/20110825/livecd-20110825-i386.out ?  ubuntu-defaults-builder is supposed to be installed in the chroot by that point, and that delivers /usr/bin/ubuntu-defaults-image
<pitti> *** glibc detected *** genisoimage: double free or corruption (out): 0x0000000002749800 ***
<pitti> ^ again, when building server images :/
<pitti> genisoimage(v_destruct+0x15)[0x4403a5]
<pitti> genisoimage(hfs_umount+0x101)[0x43d311]
<pitti> genisoimage(make_mac_volume+0x2b5)[0x428985]
<pitti> genisoimage[0x429fc7]
<pitti> genisoimage(main+0x1401)[0x40f021]
<cjwatson> go schily
<pitti> seems it doesn't particularly like hfs today :(
<cjwatson> this rings a bell actually
<pitti> that didn't happen on any of the other images
<pitti> must have hit the "right" combination of bits in the server image
<cjwatson> bug 452212
<ubot4> Launchpad bug 452212 in cdrkit (Ubuntu) "genisoimage: HFS generation crashes on certain tree sizes (affects: 1)" [Undecided,New] https://launchpad.net/bugs/452212
<cjwatson> (you might wish to avoid reading past comment 1 if you have heart problems)
<pitti> heh, I guess that's schily's autoresponder for cdrkit bugs
<cjwatson> (I also suggest not following up to that bug to avoid wakening the beast)
<cjwatson> changing the size a bit should work around the bug
<pitti> hmm, seems skaet's preinstalled pipeline broke somewhere in between kubuntu and kubuntu-mobile
<pitti> lubuntu desktop posted
<pitti> ah, right, both due to LibO being pulled in
 * pitti doesn't understand why it's being pulled in
<pitti> NCommander, ogra_, GrueMaster: FYI, server/ubuntu desktop/core images are on the tracker; kubuntu{,-mobile} failing because it pulls in LibO for yet unknown reasons; should omap4 work now, with the recent bootloader changes?
<ogra_> i hope so, havent tested yet (will do so in a few)
<pitti> bbl, lunch
<jibel> DVDs added to the tracker.
<jibel> (Ubuntu Dvds)
<pitti> re
<pitti> jibel: thanks
<pitti> kubuntu DVD posted
<doko> pitti: postgresql-debversion has an unavail b-d on debhelper
<cjwatson> oh smeg, I missed a piece to make dual-stack IPv4/v6 support work in d-i
<cjwatson> that's extremely annoying
<lamont> cjwatson: what an informative build log
<lamont> :(
<lamont> cjwatson: please provide the exact commandline that is failing
<cjwatson> BuildLiveCD command line or the one being run by BuildLiveCD?
<cjwatson> if the former, I believe it to be 'BuildLiveCD -u zh_CN -d oneiric ubuntu'
<cjwatson> actually, that busybox upload can wait until after b1 - it's correct, but it won't fix the problem I'm seeing
<ogra_> pitti, thumbs up, omap4 preinstalled desktop boots fine (not sure about other issues yet, but u-boot seems sorted now)
<pitti> yay
<cjwatson> EFI installation is very probably broken in b1.
<cjwatson>   * [Config] Set CONFIG_EFI_VARS=m on amd64 and i386
<cjwatson> but no efi-modules udeb
<cjwatson> I don't think we have time to fix that
 * cjwatson accidentally breaks the amd64 porter box's oneiric chroot slightly, and uploads a fix for that
<cjwatson> would be good to have if it doesn't impede CD building (kexec-tools)
<doko> cjwatson, slangasek: ok to remove the wvdial binary on armel? wvstreams was already removed
<cjwatson> doko: yes, I thought I already did
<cjwatson> lamont: any luck?
<stgraber> good morning
<lamont> cjwatson: gah.  got distracted by something else, and up against a breakfast commitment
<pitti> edubuntu posted
<pitti> hey stgraber
<lamont> buildd@cardamom:~$ sudo chroot build-oneiric-live/chroot-oneiric/ dpkg -l > public_html/dpkg.list
<lamont> see if that helps?
<lamont> see also ~buildd/BuildLive.out
<lamont> which is bash -x of the command
<cjwatson> E: Unable to locate package ubuntu-defaults-builder
<cjwatson> argh, we haven't put that in main yet
<cjwatson> pitti: ^- I think we'll need to MIR this
<cjwatson> we'll be supporting it anyway ...
<cjwatson> lamont: thanks, that answers my question
<lamont> ta
<lamont> afk for ~90-120 min
<stgraber> pitti: what's different from yesterday's rebuild? is that the at-spi change?
<cjwatson> pitti: what do you think of a kernel upload to fix broken EFI installation?
<cjwatson> ogasawara says it's just a config revert ...
<cjwatson> but I don't know how far through testing we are, and how much we'd be throwing away
<pitti> stgraber: at-spi, jockey (was totally broken), and a few smaller fixes
<stgraber> pitti: ok, cool. Syncing it now.
<pitti> cjwatson: hmm, that'd mean rebuilds across the board
<cjwatson> yeah, I'm reluctant unless there's another reason to do it
<pitti> i. e. it would take the remaining day today for upload/build, and rebuilds over night
<cjwatson> but ogasawara offered
<pitti> I think we should have the new kernel anyway, unless it changes a lot more than this
<cjwatson> the alternative is to release-note that you can only do EFI installs with the desktop CD
<cjwatson> (which to be fair I haven't tested yet)
<pitti> oh, that just affects alternate?
<cjwatson> d-i only
<cjwatson> my test was with server
<pitti> that seems fine to me; jibel, if we would have a new set of alternates tomorrow morning, can we get that through testing quick enough?
<pitti> Daviey: ^ for server
<cjwatson> for full disclosure I should say that I can't be certain that there aren't other EFI problems behind this
<Daviey> pitti: what is the need for a new image?
 * Daviey reads scrollback
<pitti> from my POV it'd be good to have the new kernel available anyway
<pitti> Daviey: installation on EFI, is that something you are particularly interested in?
<Daviey> I have no interest in EFI at this point. :)
<ogasawara> cjwatson, pitti: I can revert the just the config change and upload, but will wait to do so until I get the green light from you
<Daviey> I don't think there is even server class hardware for public consumption that uses EFI, i might be wrong.
<jibel> pitti, sure, we need 2 hours or so to test alternate.
<cjwatson> there is a *drive* for such server-class hardware (dropping a bunch of legacy stuff => in theory faster boot, though maybe don't hold your breath but that's the idea), but I concede I don't know if it actually exists yet
<cjwatson> I thought the kernel team had some test boards that were on the track to being server-class
<cjwatson> aha, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635897 is the real dual-stack fix for d-i
<ubot4> Debian bug 635897 in isc-dhcp-client-udeb "isc-dhcp-client-udeb: add IPv6 support to dhclient-script" [Wishlist,Open]
<jibel> when desktop images are respun, could you also rebuild wubi disk images ?
<cjwatson> are desktop images being respun?
<pitti> jibel: do we have a reason to?
<pitti> they are not being rebuilt right now, and right now I don't have a "breaker" bug on my radar
<jibel> .tar.xz doesn't include latest fixes
<jibel> e.g jockey crashes
<pitti> tar.xz? I tried the current ubuntu desktop i386 on my netbook, jockey didn't crash, and installed the bcmwl driver
<jibel> Pici, wubi downloads a disk image from here http://cdimage.ubuntu.com/wubi/current/ and latest version if from yesterday. It should be in sync with desktop images IMO
<jibel> pitti, ^
<Pici> Yep.
<jibel> Pici, sorry
<Pici> jibel: np :)
<pitti> jibel: oh, in wubi
<pitti> hm, I don't actually know how to rebuild this
<pitti> jibel: rebuilding now
<jibel> pitti, thanks.
<ogasawara> pitti, cjwatson: just want to confirm it's ok for me upload the kernel with the EFI config change.
<pitti> ogasawara: please do, thanks
<cjwatson> yes, ack from me too
<cjwatson> I'll reroll d-i later
<cjwatson> (probably won't bother waiting for armel since this config change doesn't affect it)
<didrocks> pitti: the unity-2d guys have a fix for bugs #834045 and bug #834001 which seems quite widespread, maybe worth to get that in the beta?
<ubot4> Launchpad bug 834045 in unity-2d (Ubuntu Oneiric) (and 3 other projects) "unity-2d-panel crashed with SIGSEGV in QConfSchema::findKey() (affects: 70) (dups: 74) (heat: 610)" [High,Fix committed] https://launchpad.net/bugs/834045
<ubot4> Launchpad bug 834001 in unity-2d (Ubuntu Oneiric) (and 2 other projects) "unity-2d-panel crashed with SIGSEGV in QConf::notify() (affects: 30) (dups: 29) (heat: 262)" [High,Confirmed] https://launchpad.net/bugs/834001
<pitti> didrocks: is that something that is bad enough to break installation or live system severely? it doesn't seem to here
<pitti> I need to run out for ~ 40 mins, bbl
<skaet> good morning pitti
<didrocks> pitti: it's some kind of a race, which already get 100 dups
<didrocks> pitti: ok, so, the crash of the panel is systematic on startup, then gnome-session respawn it
<Kaleo> pitti, didrocks: I am checking the exact conditions of the crash
<ogasawara> cjwatson: could I get you to approve the kernel upload please.
<jibel> OEM install on DVDs is broken. filing a bug
<pitti> hey skaet
<pitti> didrocks: so independent of this we should have a bug pattern for this
<doko> I'm syncing more ocaml packages which are not in oneiric, to get liquidsoap built
<skaet> heya pitti,   been working my way through the backscroll.    Busy day.   What's on the todos?
<pitti> cjwatson, ogasawara: kernel accepted, thanks!
<pitti> skaet: just accepted a new kernel, need to rebuild alternates with that for fixing EFI installation
<pitti> skaet: desktop/DVD unaffected
<pitti> skaet: I did a full rebuild today to pick up the jockey fix
<pitti> jibel: wubi image shuold be updated now
<pitti> http://cdimage.ubuntu.com/wubi/20110830/amd64.manifest has current jockey, anyway
<skaet> pitti,  do we have a fix/workaround for the server build - I couldn't quite figure it out from the backscroll (interesting bug that ;p )
<pitti> skaet: ubuntu/server armel omap4 confirmed to work, kubuntu fail to build because it pulls in LibO somehow, which is currently broken on armel
<pitti> skaet: the workaround would be to change the image size
<pitti> Daviey: do you care much about server/powerpc?
 * skaet starts feeling the world is a little more fragile than she likes....
<jibel> pitti, thanks, trying now.
<Daviey> pitti: Not for beta1, no
<Daviey> It won't even be QA'd
<didrocks> Kaleo: did you find anything?
<Kaleo> didrocks: not yet
<skaet> pitti, jibel,  just noticed kubuntu mobile i386 hadn't been posted,   done now.
<ogasawara> pitti: bah, kernel fails to build on powerpc due to our config enforcer checking CONFIG_EFI_VARS=y but CONFIG_EFI_VARS doesn't exist on powerpc.
<ogasawara> pitti: so we need to adjust the enforcer to check for CONFIG_EFI_VARS=y | !CONFIG_EFI_VARS, which means another upload
<pitti> ogasawara: is EFI relevant on the old powerpc at all? I didn't think so?
<pitti> skaet: ah, thanks; it should have been pretty much a no-change upload for them, but sure
<ogasawara> pitti: I don't believe so, but arm is also going to fail for the same reason
<pitti> ogasawara: could we just ignore the ppc FTBFS until after beta-1?
<pitti> ogasawara: I suppose arm will build too long for beta-1 anyway
<Daviey> new powerpc, surely it is?
<Daviey> Having the old kernel bin for beta1 for non-mainstream arches doesn't sound too scary IMO.
<pitti> the diff is just the EFI config change, so it wouldn't make much difference either way
<ogasawara> pitti: yep, so I'm fine if you want to just ignore the FTBFS's for now, but just wanted you to be aware.
<pitti> ogasawara: thanks
<skaet> pitti,  so once the kernel publishes:  ubuntu alternate, kubuntu alternate, xubuntu alternate, lubuntu alternate?
<pitti> skaet: yes; Daviey said he doesn't care much about powerpc
<pitti> (for server)
<pitti> skaet: fortunately the DVDs now don't have an alternate part any more :)
<skaet> pitti: +1 :)
<pitti> the DVD is actually quite nice now, 1.5 GB is not too much to download (for me, anyway), and nicely equipped
<skaet> hmm,  wendar's not on the channel,  but she will appreciate hearing that ;)
<skaet> pitti,  so ubuntu server gets added to the alternates list?
<skaet> s/alternates/alternates rebuild/
<pitti> skaet: it is like an alternate, but we don't want a rebuild for EFI
<pitti> we'd need some more changes to it anyway to work around the image build crash anyway
<pitti> erm, ignore me, these are unrelated issues
<slangasek> cjwatson: heh, does schily have an autoresponder on cdrkit bugs?  Seems like something we should block if so...
<slangasek> skaet: where should I be pushing release notes?
<skaet> slangasek, https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview
<skaet> is ready for input and updates. :)
<slangasek> great, thanks :)
 * slangasek prepares to document how he broke ia32-libs
<pitti> "this is not the package you are looking for"
<slangasek> skaet: multiarch is both a "new feature" and a "known issue", but I'd prefer to put the information all in one place in the release notes - what do you recommend?
<skaet> slangasek,  put it in "new feature" for now.   I'll take a pass tomorrow at the content, and see if references back need to be made from known issues.
<slangasek> ok
<pitti> skaet: we'll add some new desktop features soon (music lens, and new lenses)
<skaet> pitti,  thanks.  :)
<pitti> cjwatson: ^ b1 important? alternate/desktop/both?
<pitti> oh, nevermind, saw teh changelog now
<pitti> fixes autologin
<pitti> didrocks: do you have the unity-2d upload ready?
<pitti> didrocks: would be nice to have in the archive in case we respin for autologin
<pitti> skaet, jibel: I'm almost tempted to rebuild for that autologin fix, as we can't fix it with an upgrade
<didrocks> pitti: no, didn't get it tested here as Kaleo is still looking for the way to reproduce it. The fix is just supposed to fix it as far as I understand
<skaet> pitti, bug number?
<pitti> skaet: bug 837165
<ubot4> Launchpad bug 837165 in user-setup (Ubuntu Oneiric) (and 3 other projects) ""Log in automatically" option in Ubiquity not honored by LightDM (affects: 4) (dups: 1) (heat: 28)" [High,Fix committed] https://launchpad.net/bugs/837165
<skaet> thanks!
<pitti> skaet: that's the user-setup which just hit the queu
 * skaet nods
<jibel> pitti, no problem.
<pitti> jibel: how do you usually handle that, do we just run the automatic tests over new images and only manually test the changes, like autologin? or does it require a full manual testing again?
<jibel> pitti, both. I that case I'll verify the fix manually.
<pitti> skaet, jibel: so, I'd accept the package now, so that it's in the archive; if we don't rebuild, it'll be harmless
<pitti> but we rebuild the alternates anyway, so they'll pick up the fix at least
<pitti> but I think if we can afford it we should rebuild the others, too
<jibel> pitti, it's 8 minutes or so to install and test a desktop image.
<superm1> you have to rebuild ubiquity to pick it up too though if you want it in desktop images
<jibel> I mean run 1 test case
<pitti> superm1: ah, right
<pitti> superm1: do we need it built and published, or can ubiquity be rebuilt from a local source?
<skaet> pitti,  we can use today to rebuild the images with these fixes,  that gives testers tomorrow to finish off testing, should be ok.
<pitti> user-setup accepted
<pitti> skaet: *nod*
<pitti> ev: ^ (ubiquity rebuild question)
<superm1> pitti, there are tricks to do it locally I think, but the helper scripts rely on the archive having it published
<pitti> superm1: source only, or binaries, too?
<pitti> superm1: source will be published in about an hour, binaries will probably take two
<pitti> unless it builds in 5 minutes
<pitti> oh, nevermind -- it's in accepted already
<pitti> yay fast buildds
<skaet> :)
<skaet> pitti,  if you could summarize the sequence for doing the builds,  I'll kick them off after the publishing happens, so I can monitor a little closer when you're EOD.
<charlie-tca> Any chance of getting the new Xubuntu logo accepted so if desktop gets re-spun, it is there?
<charlie-tca> https://code.launchpad.net/~knome/debian-cd/xubuntu-logo/+merge/72497
<pitti> charlie-tca: sounds fine; can you upload it?
<charlie-tca> I can have it uploaded, yes
<pitti> thanks
<skaet> charlie-tca,   ok by me too.  :)
<charlie-tca> Thank you both
<pitti> skaet: if we are going to rebuild, I could smuggle in bug 837266 (acpid is in the queue)
<ubot4> Launchpad bug 837266 in acpid (Ubuntu Oneiric) (and 1 other project) "[oneiric] pressing power button immediately shuts down (affects: 4) (dups: 1) (heat: 14)" [High,Fix committed] https://launchpad.net/bugs/837266
<pitti> it just changes a shell script in an obvious way, but it's not a biggie, of course
<pitti> and it'll be perfectly fixed by a dist-upgrade
<pitti> it's just a potential trap for losing your documents when you actually intended to suspend, etc.
<jibel> skaet, bug 837503 on DVDs
<ubot4> Launchpad bug 837503 in ubiquity (Ubuntu Oneiric) (and 1 other project) "'Prepare for shipping' not available on DVDs (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/837503
<jibel> in other words no OEM install on DVDs
<skaet> jibel,  ack.
<skaet> cjwatson,  ^^ is there a quick fix?
<cjwatson> please ask ev
 * cjwatson is off this afternoon
<ev> oh hi
<ev> I have no idea if there's a quick fix. I'm just getting to the oem-config bugs now
<pitti> hey ev, how are you? thanks for the user-setup fix
<ev> sure thing
<pitti> ev: do you have an ubiquity rebuild with that in the pipe?
<ev> pitti: yes
<ev> working on that now
<ogra_> skaet, GrueMaster reports that the netboot images still fail due to the u-boot issues, there is a fixed d-i in bzr, the change only touches arm code, ok to upload ?
<cjwatson> ogra_: please wait until the kernel is published on amd64/i386, so we don't have to upload twice
<cjwatson> https://launchpad.net/ubuntu/+source/linux/3.0.0-9.15
<ogra_> ah, yeah
<ogra_> np
<pitti> darn, the amd64 buildds are being linux'ed (kernel team PPA)
<pitti> as they all take some 6 hours, I'm afraid we might need to have one killed in order to get ubiquity and d-i in in an appropriate time
<ev> new ubiquity incoming
<micahg> pitti: I've got a slew of Mozilla builds as well, but I can hold off a few hours
<chrisccoulson> bad news ;)
<pitti> ev: I asked infinity/lamont to kill a linux build to free an amd64 builder
<ev> great
<micahg> pitti: we have an urgent security fix for Firefox/Thunderbird for oneiric beta, I originally suggested that we build in the PPA, but I think it might be best to build in archive so i386/amd64 can respin and not be blocked on armel, what do you think?
<pitti> that's a six hour build each, right?
 * micahg checks, shouldn't be that long
<pitti> it should finish around the same time as the kernel
<micahg> pitti: about 4.5 hours each
<micahg> for i386/amd64, 17 for armel
<pitti> if you have it ready for upload now, and I can reach infinity or lamont soon to get amd64 builders, it wouldn't extend the time for rebuild
<pitti> micahg: please get it uploaded, so that it's in the queeu
<pitti> micahg: does it change anything else? i. e. what's the regression risk?
<infinity> pitti: I don't have direct access to buildds anymore, it's all lamont (or IS in general)
<pitti> infinity: ah, thanks
<pitti> micahg: actually, as we can't build them side by side, it'll be 9 h
<infinity> Why do we have people uploading a mess of kernels to non-virtual PPAs during a releae freeze anyway? :(
<micahg> pitti: right :(, I reviewed the most of the changes yesterday, there's one patch that's rather large, but I think our risk is higher if we cherry pick
<pitti> ok
<ogra_> micahg, dont care for armel, FF doesnt start at all here and i doubt we can fix that before B1
<micahg> we're just waiting on the upstream tags, Firefox will be ready for Thunderbird, chrisccoulson should be uploading w/in an hour hopefully
<micahg> ogra_: sorry to hear that, we should probably look at that after beta 1, but it's good news that we don't have to wait on it
<ogra_> yeah, i havent researched yet at all what goes on, but it fires off the crash dialog directly on startup
<micahg> ogra_: ah, yes, I did experience that, I'll try to look into it later (I filed a crash report actually, I just have to pull the id)
<ScottK> jdstrand: Not sure if you got your question from yesterday answered or not (I've still now power due to the hurricane, so I'm not the best person to be asking), but I think otrs2 and phpmyadmin are fine.
<pitti> ok, got the linux builds killed; building ubiquity now, and keeping another amd64 builder on manual for firefox
<chrisccoulson> ogra_, mozilla bug 675618 is the arm startup crash
<ubot4> Mozilla bug 675618 in XPCOM "Crash during startup on ARM when linked with recent GNU ld" [Normal,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=675618
<ogra_> awesome !
<jdstrand> ScottK: ah, I did not. Thank you for responding and sorry to hear about the power. that is always a pain
<ev> ugh, failed tests
<pitti> ev: in the tz widget -- that's due to setting a default one now?
<ev> I'm not quite sure what's causing it
<ev> digging into it now
<ScottK> skaet: I still have no power, so please don't block stuff on me.
<pitti> ev: the buildds might have a different $TZ perhaps, so the test behaves different than on your local box?
<pitti> or they have no network, and thus not getting geolocation?
<ScottK> pitti: Are respins planned once ubiquity is updated?
<pitti> ScottK: yes
<ScottK> Great.  I'll adjust Kubuntu seeds for size then.
<pitti> AFAICS, we are waiting on ubiquity, firefox, and thunderbird for desktops
<pitti> and on linux for alternates
<ev> pitti: it doesn't hit the geolocation path
<pitti> ScottK: thanks; although I thought we agreed on a 703 MB size limit, so they wouldn't really be oversized?
<ev> I'm able to produce the error locally
<ev> digging now
<ScottK> pitti: So we did.
<ScottK> I was just responding to a comment that they were.
 * ScottK looking now
<stgraber> pitti, skaet: I'm looking into an Edubuntu bug (ltsp not being translated), if I find a fix for it and we still have time, I may ask you to try and squeeze it before the respin. It's not critical but still annoying.
<pitti> stgraber: you have about 6 hours, sure
<ScottK> pitti: It looks like Kubuntu powerpc livefs generation failed because the last libreoffice upload FTBFS on powerpc.  I thought I'd removed all traces of LO from our powerpc images, so I may need to make some changes there to get it to build.
<pitti> ScottK: so did I (armel preinstalled is the same)
<ogra_> can someone let flash-kernel through, it is needed to fix netboot installs
<pitti> ScottK: but I don't see how LibO gets pulled into the armel kubuntu images
<pitti> ScottK, skaet, cjwatson, jibel: FYI, I added the curretn rebuild dependencies to http://pad.ubuntu-uk.org/ubuntu-release
<pitti> please update as appropriate
<pitti> skaet: ^ I find these pads quite convenient for keeping a running status, easier than mail/IRC (which is hard to edit)
<skaet> pitti,  good idea!  This seems a better way to keep track.   :)
<pitti> "you're not a channel operator"
<pitti> /topic 11.10-beta1 Freeze is in effect | http://pad.ubuntu-uk.org/ubuntu-release for rebuild coordination | Oneiric Ocelot Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team with beer  | we accept payment in cash, check or ocelot food | melior malum quod cognoscis
<pitti> could some one who is please run that? i. e. add the pad to the topic?
* cjwatson changed the topic of #ubuntu-release to: 11.10-beta1 Freeze is in effect | http://pad.ubuntu-uk.org/ubuntu-release | Oneiric Ocelot Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team with beer | we accept payment in cash, check or ocelot food | melior malum quod cognoscis
<pitti> cheers
<cjwatson> pitti: FWIW you're on the access list so you can just ask chanserv
<cjwatson> /quote chanserv op #ubuntu-release pitti
<cjwatson> (or /msg if your client doesn't do /quote right)
 * infinity wonders why the channel is +t
<pitti> oh, that works, thanks
<cjwatson> infinity: we get the odd troll around release time - might've been that
<infinity> Fair enough.
<infinity> ogra_: Accepted.
<ogra_> thx
 * pitti desperately tries to -o now, but my feeble attempts with /mode etc. don't work
<cjwatson> pitti: /mode #ubuntu-release -o pitti
<cjwatson> the syntax is weird
<pitti> /quote chanserv deop #ubuntu-release pitti
<pitti> ah, ^ worked
<pitti> quick dinner, brg
<cjwatson> irssi has '/deop pitti'; I don't recall whether that's client-specific, it probably is
<pitti> cjwatson: ah, that works in weechat, too
 * pitti <- IRC n00b
<cjwatson> I learned this stuff in 1998 or so and most of it has leaked out my ears since
<infinity> It's all muscle memory for me at this point.
<infinity> But I'd be lost if I ever switched from something that wasn't ircII-like.
<ev> pitti: ah, it was a genuine bug.  Hooray for unit tests.
<cjwatson> a genuine code bug rather than a test bug! :)
<pitti> skaet: I added the pipelines which I used yesterday/today to the pad; if you have some improvements, please edit them
<ev> indeed!
<pitti> ev: tests FTW
<skaet> pitti,  thanks!
<pitti> skaet: not sure what you mean with "page links for cross-checking published"
<skaet> pitti, launchpad and archive refs.
<pitti> skaet: I usually do apt-get update and apt-cache show, unless I use wait-for-package
<skaet> pitti,  more efficient than the monitoring of the archive pool pages, at any rate ;)   thanks
 * infinity raises a brow at "check-config: FAIL: value CONFIG_EFI_VARS y"
<infinity> I'm assuming we don't currently care that the kernel is FTBFS on !x86?
<cjwatson> 16:20 <pitti> ogasawara: could we just ignore the ppc FTBFS until after beta-1?
<cjwatson> 16:20 <pitti> ogasawara: I suppose arm will build too long for beta-1 anyway
<cjwatson> 16:20 <Daviey> new powerpc, surely it is?
<cjwatson> 16:21 <Daviey> Having the old kernel bin for beta1 for non-mainstream arches doesn't sound too scary IMO.
<cjwatson> 16:21 <pitti> the diff is just the EFI config change, so it wouldn't make much difference either way
<cjwatson> 16:23 <ogasawara> pitti: yep, so I'm fine if you want to just ignore the FTBFS's for now, but just wanted you to be aware.
<ev> fixed ubiquity uploaded
<infinity> cjwatson: Check.  Seems fair to me.
<ScottK> Would it be possible to try rebuilding the livefs for Kubuntu powerpc only?
<ScottK> I think I fixed the seeds so it won't pull in anything LO related.
<skaet> pitti, ubuntu studio is missing from alternates rebuild triggered by linux kernel.  overight?
 * infinity hands skaet an "s".
<skaet> err,  oversight?
 * skaet accepts "s" from infinity. :)
<skaet> ScottK,  should be possible.   Can you summarize which kubuntu images you're looking for rebuilds to pick up fixes for?
<skaet> (and which architecture ;) )
<ScottK> skaet: The only Kubuntu specific issue if the powerpc livefs build failure.  The rest is the same as the others (ubiquity, kernel, etc)
<ScottK> That's why I'd like to make sure I got the powerpc livefs failure sorted now, while the rest is being sorted out.
<skaet> ahh... gotcha.
 * skaet goes over to type the appropriate runes into the builder. 
<doko> infinity, I hate liquidsoap ...
<infinity> doko: As do I.
<infinity> doko: It was a sync to fix a broken sync, in my defense. :P
<infinity> doko: But yeah.  We now get a whole new ocaml multimedia stack in universe!
<doko> infinity, ok, I think I'll continue syncing this stuff ...
<infinity> doko: cry, taglib, duppy, portaudio?
<infinity> doko: (well, the ocamlish names of above)
<skaet> ScottK,   ARCHES='powerpc' buildlive kubuntu daily-live && ARCHES='powerpc' for-project kubuntu cron.daily-live;   has been kicked off.
<ScottK> Thanks.
<chrisccoulson> hi pitti, you around?
<micahg> pitti: skaet: are you waiting on the firefox fix for respins?
<micahg> chrisccoulson: according to the etherpad, they are waiting
<skaet> micahg, yup we're waiting.  what's the eta?
<stgraber> pitti, skaet: I'm pushing a new ltsp and edubuntu-live now to fix LTSP not being translated for Edubuntu. This LTSP won't change anything for alternate so no rebuild needed there
<micahg> skaet: I think chrisccoulson just has to upload and then someone to accept
<chrisccoulson> skaet, oh, i didn't realise. if we're short on build capacity, then i think it might be best to do the respin without the firefox update, as i'd prefer to get the lucid/maverick/natty updates built first
<micahg> chrisccoulson: I'd rather delay the stable releases 4 hours than miss beta
<skaet> chriscoulson, we've been holding builders for this.
<chrisccoulson> ok, i can do it that way around, but i didn't realize you were holding builders for that
<skaet> yup. :)  thanks.
<chrisccoulson> micahg, are you ready to get your stuff uploaded straight afterwards?
<micahg> chrisccoulson: yeah, I should have everything ready within an hour
<chrisccoulson> thanks
<ev> I've just uploaded ubiquity 2.7.23, which fixes an issue creating a dialog in oem-config-remove-gtk. It's not a fatal error as far as I can tell, but the fix is very small.
<ev> (oem-config-remove-gtk handles removing all of ubiquity and oem-config when oem-config is run by the end user)
<pitti> re
<pitti> chrisccoulson: yes, we are waiting for firefox and tbird
<pitti> chrisccoulson: I reserved buildds
<bdmurray> Is update-manager still waiting to be approved?
<chrisccoulson> pitti, thanks. just about to upload firefox now
<micahg> pitti: do I still need to hold off after firefox/thunderbird are uploaded from uploading my stable release fixes?
<chrisccoulson> i'm trying to get an ETA on thunderbird though
<pitti> bdmurray: yes, it didn't seem to be release critical?
<pitti> micahg: no, should be ok; once ffox/tbird for oneiric are building, we don't have other big stuff to build
<bdmurray> pitti: not exactly release critical however we'll have more people upgrading this week so it would be helpful
<ev> actually, nix that upload
<pitti> ev: .23?
<ev> we've just discovered that oem-config-remove-gtk is using gtk2 and 3
<ev> yes
<pitti> .22 as well then?
<ev> no
<ev> .22 is okay
<pitti> ev: ok, so reject .23, accept .22
<ev> correct
<pitti> ev: but I sense that we'll get another upload?
<pitti> ev: just want to avoid building two in a row
<ev> I don't have time to investigate the problem now as I have a gig to get to
<pitti> ok
<ev> but if everything goes up in flames, do text me
<ev> and I'll have a look when I get home tonight
<pitti> have a good night!
<pitti> meh, and now crested picked a "building private source" instead of ubiquity
<chrisccoulson> right, firefox is uploading
<infinity> pitti: You didn't score ubiquity up?
<ev> thanks!
<ev> night
<pitti> infinity: I did, but 4000 wasn't enough
<infinity> No, it's not. :)
<pitti> 40000 seems to be, though
<infinity> I tend to just lean on the 9 key.
<pitti> building now
<micahg> yeah, I think default private builds are 10k
<pitti> does 2^â -1 work?
<stgraber> would be great if someone could review these ltsp and edubuntu-live uploads as I'd like to see them in the next rebuild (as we rebuild the world anyway), thanks!
<pitti> or is that infinitely improbable?
<pitti> stgraber: yep, at it; was waiting a bit for the diffs
<micahg> pitti: I think that just lands it in infinity's inbox :P
<stgraber> (I'm grabbing ubuntu alternate now to make sure LTSP not being translated doesn't affect alternate. If it does affect alternate, it's going to be a different fix that I'll need to work on ...)
<stgraber> pitti: thanks
 * pitti reserves an i386 buildd as well
<pitti> I assume doko is accepting those ^?
<slangasek> pitti: what's the current story with rebuilds?  anything you'd like to hand off to me?
<infinity> pitti: Me.
<pitti> ah
<pitti> slangasek: we created http://pad.ubuntu-uk.org/ubuntu-release two hours ago to keep track of the dependencies
<pitti> slangasek: in short, we need to rebuild all desktops, alternates, and DVDs, but not server and preinstalled at this point
<doko> pitti, I had the ocaml-* stuff accepted, to get liquidsoap built
<pitti> skaet: do you want to keep the half-done "Image rebuild trigger perspective" section?
<slangasek> pitti: ok - and where's the needle currently on the "more bugfixes" vs. "no more changes so we can get these built" dial? :)
<pitti> skaet: I think we shuold just maintain one direction, otherwise it gets out of sync too easily
<slangasek> e.g., how much longer are firefox and thunderbird expected to take
<chrisccoulson> firefox is uploading right this second :)
<pitti> slangasek: right now on these, from my perspective; i. e get ubiquity built/published, then start kubuntu/lubuntu (which don't use ffox/tbird), and start ubuntu/edubuntu/xubuntu on ffox/tbird
<pitti> slangasek: ffox is being uploaded, tbird was promised "soon"
<slangasek> chrisccoulson: how long's the build on ffox these days?  < 1h, right?
<skaet> pitti,  I find it useful to be able to cross check,  but I can keep it private if you find it confusing.
<pitti> no, 4.5 h on i386
 * skaet is multiplexing
<pitti> skaet: ok
<slangasek> pitti: oh right, because xulrunner is no longer separate?
<pitti> slangasek: yes
 * slangasek nods
<chrisccoulson> xulrunner is completely dead ;)
<pitti> well, libxul
<pitti> slangasek: I reserved two amd64 and one i386 buildd (i. e. on manual)
<pitti> as there are some large kernels and other stuff who crave for a 6 hour tour on the amd64 buildds
<pitti> but we need those for tbird/ffox
<chrisccoulson> i'm still waiting for a list of changeset ID's to build thunderbird from
<pitti> chrisccoulson: ETA?
<pitti> chrisccoulson: it sounds like we should skip that then
<chrisccoulson> pitti - hopefully minutes. i've just asked one of the release drivers
<pitti> chrisccoulson: you'll need at least two hours to craete the source, build, and test and upload it, no?
<chrisccoulson> yeah, i'm wondering whether it's worth delaying it for thunderbird
<pitti> and tbird is a lot less affected by SSL certs than ffox
<pitti> IMHO we can live with a normal upgrade for tbird
<pitti> WDYT?
<pitti> yay, ubiquity succeeded on i386
<chrisccoulson> pitti - yeah, that might be the best plan.
<chrisccoulson> could we add https://support.mozillamessaging.com/en-US/kb/deleting-diginotar-ca-cert to the release notes?
<micahg> I'd buy that, people are much less likely to run TB off live media than FF
<pitti> micahg: but even if they are, SSL certificates don't matter that much?
<slangasek> pitti: and you're hanging around to get those used for the right builds?
<pitti> slangasek: yes, that, and also sorting through other stuff in between
<micahg> pitti: they do for connecting over IMAPS :)
<slangasek> pitti: ok :)
<pitti> micahg, chrisccoulson: right, I'm just concerned that 6 hours build + publish plus another two for local preparation/build/test delays the images too much
<pitti> we need 4 hours or so to rebuild everything, and then need to test all the images, etc.
<pitti> ubiquity built
<micahg> pitti: that's fine, should we upload thunderbird anyways when ready in case there are late respins or would you rather it be staged in the security PPA?
<lamont> why are 1-each of the buildds on manual?
<lamont> is that to manually queue builds?
<slangasek> lamont: reserved for firefox
<slangasek> see pitti
<lamont> ok
<chrisccoulson> pitti - right. i don't think we should wait for thunderbird, and we could probably rel-note the instructions for removing the compromised root
<pitti> lamont: yes, there are packages in the ubuntu kernel PPA which would block them for 6 hours
<pitti> chrisccoulson: ack
<pitti> I updated the pad for the dependencies
<chrisccoulson> hmmm, i need a go-faster button for my internet connection this evening
<chrisccoulson> perhaps if i blow on the cable, the bits will travel along it a bit faster
<pitti> chrisccoulson: you are uploading the orig.tar.gz from home?
<chrisccoulson> pitti - yeah, that probably wasn't the best decision ;)
<pitti> chrisccoulson: for large packages I used to wget the orig to chinstrap, scp the debian.tar/changes/dsc to chinstrap, and dput from there
<chrisccoulson> but it's nearly done now
<pitti> dput from chinstrap looks amazing, even for LibO :)
<chrisccoulson> yeah, i should do that really
<micahg> pitti: chromium was nice from there :)
<pitti> micahg: makes you wish for such an upstream from home, doesn't it?
<micahg> pitti: I'm ok for most use cases (2MB up), but it's pretty cool
<chrisccoulson> i just saw the advisories on lwn, and saw opensuse already has a firefox update
<chrisccoulson> then i realized it's only for 6.0!
<chrisccoulson> http://lwn.net/Articles/456881/
<chrisccoulson> not as fast as us ;)
<pitti> well, admittedly updates for stable releases are more urgent in those cases?
<chrisccoulson> pitti - natty got the same update nearly 2 weeks ago
<chrisccoulson> yay, it's uploaded now \o/
<pitti> nice
<pitti> ... and accepted
 * skaet --> heading out to lunch,  back later.
<pitti> yellow, there's some nice fodder for you, have at it
<micahg> pitti: am I clear to upload now as well for stable releases?
<pitti> firefox building on i386/amd64, builders back on auto
<pitti> micahg: yes
<micahg> pitti: thanks :)
<chrisccoulson> thanks :)
<superm1> ubiquity 2.7.24 should take care of the oem-config-remove-gtk mistake and also fix the panel not showing up
<pitti> superm1: ah, that's what ev discovered?
<superm1> well i fixed his gtk2/gtk3 combo mistake
<superm1> fortunately you can test the python script outside of the ubiquity environment, so it wasn't too difficult to fix
<pitti> superm1: cheers
<stgraber> yeah! LTSP from alternate is properly translated :)
<charlie-tca> pitti: I don't have anyone that can upload the new logo for us. Can someone here with upload rights for it do it?
<charlie-tca> https://code.launchpad.net/~knome/debian-cd/xubuntu-logo/+merge/72497
<micahg> not an upload thing, this needs to be merged in the cdimage team branch apparently...
<charlie-tca> slangasek: any chance you could do this?
<charlie-tca> or maybe cjwatson could help?
<infinity> charlie-tca: I can.
<slangasek> cjwatson should be far away from the computer if he knows what's good for him
<infinity> charlie-tca: I'm piloting today, after all.
<micahg> infinity: no, you can't :)
<charlie-tca> heh
 * slangasek lets infinity do it
<charlie-tca> infinity: thank you
<infinity> micahg: I can't?
<micahg> slangasek: it needs a cdimage team member which is you :)
<infinity> micahg: (or me)
<slangasek> or infinity, AFAIK
<charlie-tca> micahg: how many beers is this going to cost me?
<micahg> infinity: it's not an upload from what I can tell
<infinity> micahg: I know. :P
<infinity> micahg: I'm an all-purpose pilot.
<micahg> infinity: it's the one team you're not a member of AFAICT :P
<infinity> micahg: My active shell on antimony begs to differ.
<infinity> Anyhow..
<slangasek> micahg: one thing is the team in launchpad, another is sudo access on the server that matters :)
<infinity> charlie-tca: Yes, I'll get to that for you.
<charlie-tca> Thank youvery much
<micahg> slangasek: ok, I thought the branch was managed in LP bzr, my mistake then
<slangasek> unfortunately not
<infinity> Though, I probably should be in the LP team, I suppose. :P
<charlie-tca> I got okays from pitti and skaet to do it. I just need some help with it now.
<infinity> I'll get Colin to fix that later.
<micahg> infinity: sorry for doubting your infinite abilities :)
<infinity> micahg: Heh.
<infinity> micahg: S'ok, people still assume I have access to lots of things I don't anymore, so it balances out. ;)
<infinity> Oh how I love binary files in revision control...
<charlie-tca> I am going for a walk then. I need some fresh air
<pitti> erk, now the i386 builders are linuxed and firefoxed, ubiquity will take 25 mins until it starts
<chrisccoulson> micahg, i've done the firefox-stable and firefox-next PPA's as well now
<stgraber> pitti: are edubuntu-live and ltsp already published? I noticed they aren't mentioned in the pad
<pitti> stgraber: being published right now
<pitti> stgraber: i. e. way before ubiquity
<stgraber> perfect
<infinity> charlie-tca: Merged on antimony.
 * infinity lunches.
<pitti> slangasek: can you take over until skaet returns?
<pitti> skaet, slangasek: I just updated the pad again TTBOMK, including charlie-tca's logo fix
<pitti> i386 ubiquity is scored up
<pitti> and one amd64  buildd (crested) is on manual
<pitti> in case we need further builds after ubiquity
<slangasek> pitti: sure, can take over - aren't we just waiting for builds still, though?
<pitti> slangasek: yes, we are
<pitti> slangasek: btw, the pad has my current version of the rebuild pipelines; feel free to update/merge with your's
<pitti> then, good night everyone!
<slangasek> 'night :)
<ScottK> OK.  Back home to where there's no power.  Good luck.
<micahg> is there a reason why there's still an amd64 builder on hold?
<GrueMaster> What is the firefox issue?  I can't even get it to run on armel with today's image.
<GrueMaster> (But I am willing to release note it).
<micahg> GrueMaster: fraudulent certificates, we'll try to get firefox working on armel for final release
<micahg> It's fixed in Firefox 8
<GrueMaster> Ah, ok.
<GrueMaster> micahg: Is there an lp bug I can reference for the iso tracker?
<micahg> GrueMaster: for which, the arm issue, not that I know of, the mozilla one is in scrollback, feel free to file a bug and link them
<charlie-tca> Thank you , infinity
 * skaet --> back 
<astraljava> cjwatson: Sorry to bother you again, but I'm having trouble with my local germinate. Could you possibly upload ubuntustudio's seeds, while Luke isn't to be found on our channel?
<skaet> astraljava,  should I hold off on any rebuilds until the new seeds land?
<astraljava> skaet: I don't know, really. The last build seemed to be at around 0830 UTC, while Colin had postponed the building of images by 12 hours earlier. I don't think it matters much if they get built with old seeds, though.
<cjwatson> you know, there are a bunch of core devs in more appropriate timezones :-P
 * cjwatson runs the update script
<astraljava> cjwatson: Okay, cool. What is the appropriate channel for asking such, then?
<micahg> astraljava: infinity is still piloting in #ubuntu-devel
 * astraljava has just started on worrying about these things since July, really :)
<cjwatson> #ubuntu-devel is better, yes.  But I'm doing this one now.
<cjwatson> Just advice not to lean on one person.
<astraljava> micahg: Thanks! I'll keep that in mind. :) Thank you, Colin, Micah, and skaet (sorry I forget your first name!) :)
<skaet> astraljava,  its Kate ;)
<astraljava> Cheers, Kate! :)
<cjwatson> (BTW, for those not familiar with it, the thing you want to ask for is for somebody to update the ubuntustudio-meta package)
<cjwatson> most developers should be able to pick it up from that since there's an 'update' script in the source package
<micahg> that doesn't even need a core-dev :)
<cjwatson> no, indeed
<astraljava> cjwatson: Oh cool! Thanks so much!
<skaet> gilir, lubuntu has firefox in it,  do you want the respins to contain the security fix?
<gilir> skaet, no, we don't have firefox :)
<skaet> gilir, interesting,  grep on the manifest is showing it. ;)
<gilir> arf, not again :(
 * gilir will check
<skaet> gilir,  definitely on powerpc,  firefox-locale-* on the others.
<skaet> grep firefox *.manifest
<micahg> skaet: firefox-locale-* comes in from the langpacks, not an issue
<micahg> gilir: ^^
<skaet> micahg,  okie. :)
<gilir> ah yes maybe on powerpc, because chromium is not build on it
<gilir> skaet, but powerpc are not part of the tested images for the release, no need to worry for them :)
<skaet> gilir,  coolio.  :)   Your new images should get kicked off with the next set of runs then.
<gilir> cool thanks :)
<cjwatson> ubuntustudio-meta in the queue
<cjwatson> [ 61%] make[3]: *** No rule to make target `/usr/lib64/libpq.so', needed by `bin/libKWWidgets.so.1.0.1009.0'.  Stop.
 * cjwatson sings the I-hate-cmake song
<skaet> slangasek, can you review the pad, and check the time estimates for starting things off is reasonable.
<skaet> cjwatson,  ack,  will hold off for that one then until it shows up.
<slangasek> skaet: times are UTC?
<skaet> slangasek,  yup.   currentl: 2226
<slangasek> skaet: kubuntu/lubuntu desktop/DVD are listed as waiting for ubiquity only - should we push those now?
<slangasek> well, I guess "now" vs. "4 minutes from now" makes little difference ;)
<skaet> slangasek,  figured to trigger them once they showed up in the archive.
 * skaet waiting for publisher run.
<skaet> but basically yes.
<skaet> ScottK said to not hold up on him with powerpc, due to his power issues,  and it would be nice to clear them, and get fresh there before firefox hits.
<slangasek> skaet: ubiquity 2.7.24 is already in the archive
 * skaet nods,  appears so. :)
 * Daviey checks in
<skaet> Daviey, are you expecting any rebuilds?
 * skaet wonders if the server build issue has been sorted.
<cjwatson> can somebody review/accept that ubuntustudio-meta, please?  it should be trivial to reviw
<cjwatson> *review
<cjwatson> server/powerpc you mean?  it's unsortable.
<cjwatson> (again, can we please not have "the <foo> issue" - it's really confusing!)
<infinity> cjwatson: Oh, hah, you already uploaded.  Yeah, I can review/accept.
<cjwatson> the server/powerpc build failure is a genisoimage crash that affects images of certain sizes
<cjwatson> a direct fix for that is unlikely
<skaet> cjwatson,  sorry, yes that is the one I meant.  Didn't know if it was limited to powerpc or wider.  Thank you.
<infinity> cjwatson: Randomly add some nulls to the end of a file? ;)
 * skaet notes: Lubuntu Live CD building,  queued: Kubuntu Live CD ;  Kubuntu DVD
<Daviey> skaet: So regarding powerpc for server.. We have no interest in that image at all.  It will recieve no QA, and TBH - would be better being dropped IMO.
<skaet> Daviey, consider the powerpc image dropped then.    What about the rest of them,  do they need a respin, or are you good with the current images?
<Daviey> We seem to be pretty good. :)
<skaet> Daviey,  coolio.
<skaet> :)
<Daviey> \o/
 * skaet draws nice little ticky mark in that column ;)
<Daviey> skaet: Agreed to drop for b1 or for rest of cycle?
<skaet> Daviey,  yours and Robbie's call for rest of cycle.  For b1 definitely consider it dropped.
<Daviey> skaet: will release note it, and see if anyone screams. :)
<Daviey> i'll bet nobody cares :(
<Daviey> or rather :)
<skaet> Daviey,  feel free to go in and edit release notes now for server while its fresh in mind.  ;)
<skaet> https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview
<Daviey> taht is one for tomorrow, i think :)
<cjwatson> skaet: can I have a slot to run a test-build for the new-style Chinese edition at some point?  OEM is collectively having kittens in my inbox and I'd like them to stop
<Daviey> 23:59 < Daviey> taht is one for tomorrow, i think :)
<Daviey> Day changed to 31 Aug 2011
<skaet> lol,   can't blame me for trying ;)
<Daviey> dammit.
<skaet> cjwatson, now is good.
<skaet> cjwatson do you want me to kick it off?  or are you going to to?
<infinity> Daviey: If I find the round tuits to make the powerpc alternates actually work on my PowerStation, I may have interest in QAing PPC/server.  But not in the next day or two, no. ;)
<cjwatson> skaet: did you see anything I said from "I know it may not necessarily fit exactly right now" onwards?
<Daviey> infinity: Do you think people actually care about running powerpc with server flavour?
<skaet> cjwatson, nope - didn't see that comment either.
<Daviey> infinity: Or would mini.iso be enough to bootstrap people?
<infinity> Daviey: Given that most powerpc hardware you can still buy is either embedded or server-class, and nothing in between, yeah.
<cjwatson> <cjwatson> I know it may not necessarily fit exactly right now, but if somebody could run 'UBUNTU_DEFAULTS_LOCALE=zh_CN buildlive ubuntu daily-live' on antimony at some point and let me worry about any failures, that would be great
<cjwatson> <cjwatson> er, incidentally, what happened to that debian-installer upload?  nobody's done it
<cjwatson> <cjwatson> and it's needed for any alternate/server rebuilds
<cjwatson> <cjwatson> bah, those rebuild markers in the pad are wrong
<infinity> Daviey: But, okay, that's fair.  I'm just as happy with netinst, personally.  As are most datacentre types.
<cjwatson> <cjwatson> fixed them
<Daviey> infinity: Really?  You can still buy power*PC* server hardware?
<Daviey> not POWER, but powerpc?
<infinity> Daviey: All the same architecture.
<cjwatson> and as you can see I've also uploaded debian-installer now; review appreciated
<skaet> cjwatson,  d-i dependency wasn't on the etherpad.   drat.
<infinity> Daviey: (The two in my house happen to be POWER, but whatever)
<cjwatson> skaet: yep.  it is now.
<skaet> heh,  hadn't kicked those ones off, since still missing i386 linux.
<Daviey> infinity: So power can be the same as powerpc.. but it's not optimised, etc.
<Daviey> AIUI.
<cjwatson> Daviey: don't buy everything you're told by the manufacturer :-)
<Daviey> cjwatson: am i wrong?
<Daviey> is power == powerpc for this?
<cjwatson> Daviey: our i386 and amd64 flavours aren't hyper-optimised to run only on the very most modern Intel chips either
<infinity> Daviey: I prefer a 32-bit PPC distro to something "power-optimised", to be fair.
<cjwatson> and sure, you'd get a few more percent out of them that way, no doubt, but there's value in compatibility too
<infinity> Daviey: (With a 64-bit kernel, obviously)
<infinity> cjwatson: Well, you gain a few percent and lose a few, in all 32->64 cases that aren't amd64.
<cjwatson> it's only with extremely recent hardware that people I trust to know what they're talking about have started saying that it's worthwhile running a 64-bit userspace on POWER systems
<infinity> cjwatson: The only reason amd64 is so shiny is because of all those yummy new registers.
<skaet> cjwatson is zh_CN desktop safe to run in parallel with  lubuntu/kubuntu desktop builds?
<cjwatson> skaet: only one livefs build can run at a time; the others will block
<infinity> (But, in the POWER case, you do get some nice new optimisations that can canel out the bloated memory usage)
<infinity> Daviey: Ultimately, the point is "yes, we run on POWER". :)
<cjwatson> infinity: oh, sure, but a lot of the "not optimised" is also "not -march=power7"
<slangasek> skaet: multiarch documentation added to https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview
<skaet> cjwatson,  as soon as lubuntu/kubuntu desktop is finished,  will queue it up.
<skaet> slangasek.   Thanks!  :)
<cjwatson> skaet: thanks
<skaet> np
<cjwatson> infinity: and I think that's at least somewhat analogous to -mtune=generic vs. -mtune=core2, say, which was closer to the point I was trying to make - we don't necessarily need absolute shiniest optimisations for a port to be worthwhile
<cjwatson> although I know that a putative 64-bit userspace port would likely be more heavily optimised
<skaet> linux i386 has landed!   woot!   kicking those alternates off now.  :)
<infinity> cjwatson: Yeah.  And I'm happy with ppc32 remaining generic enough to run on an old G3, if we can have a super-shiny POWER7-targetted ppc64.
<infinity> cjwatson: But that also means I'll end up wanting the genering ppc32 build on my (not exactly obsolete) POWER5 systems. :)
<infinity> s/genering/generic/
<infinity> I think my fingers are tired.
<skaet> Daviey,  https://wiki.ubuntu.com/OneiricOcelot/ReleaseImageContacts,  turns out powerpc wasn't in the list for server,  no need to release note it.
<cjwatson> we should seriously not be having multi-hour discussions about a non-Canonical-supported architecture, anyway
<cjwatson> if it doesn't work, move on
<cjwatson> people can catch up if they want to work on fixing it
<cjwatson> infinity: don't suppose you could review debian-installer?
<infinity> cjwatson: Can and will.
<infinity> And ack on the discussion.
<infinity> I intend to fix it on my PowerStation in my spare time "some day". :P
<infinity> cjwatson: Looks good to me.  You're ready to let it build?  I haven't been watching kernel builds.
<cjwatson> infinity: yeah, the kernel's in place
<infinity> cjwatson: Accepted, then.
<infinity> I'm technically "off" for the day, but I'll be around all evening if people need reviews/etc.  Just nick higlight me.
<infinity> (And I'll still be mucking with things too... So, whatever.  Just expect slightly longer response times)
<skaet> gilir, lubuntu alternate (20110830.1) and lubuntu desktop (20110830.2) posted
#ubuntu-release 2011-08-31
<slangasek> skaet: I'm out for a few hours now; won't be in a position to get online, but you need anything feel free to ring me
<skaet> slangasek,  Thanks.
<skaet> NCommander, GrueMaster,  can you give me a summary of how we look on the ARM side?   anything needing rebuilds?
<skaet> infinity,  ^^ if you have some perspective,  feel free to chime in ;)
<skaet> ScottK, kubuntu desktop (20110831) and kubuntu alternate(20110830.1) posted
<skaet> ScottK, on the desktop,  amd64, amd64+mac, i386 are oversized.
<infinity> skaet: We need all our alternates rebuilt (if that didn't already happen) for that latest d-i.
<infinity> skaet: For desktop, we have "issues" anyway, so I'm not sure we care deeply tonight.
<skaet> infinity, has the d-i been published yet?
 * skaet looking
<skaet> https://launchpad.net/ubuntu/+source/debian-installer/20101020ubuntu60
<skaet> infinity, looks like we're waiting for the arm images to be published.
<highvoltage> how are things, skaet? I'm sorry for being so absent during this cycle, work just got into the way too much.
<skaet> heya highvoltage,  good to see you.  :)  we're just sorting out which images need rebuilds to pick up today's fixes.
<highvoltage> ah great
<skaet> highvoltage, http://pad.ubuntu-uk.org/ubuntu-release;   basically as soon as the firefox fixes get published to the archive, I plan to spin a new set of edubuntu DVDs.   That look ok to you?
<highvoltage> no complaints from me, I noticed today that I get build notifications agin
<highvoltage> *again
<highvoltage> I guess stgraber fixed the mail list for that
<highvoltage> (which is great)
<skaet> :)
<skaet> highvoltage, if you have the time now, while we're waiting for the builds to start off,  would be great if you could add the Edubuntu overview into the release notes.  https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview
<highvoltage> ah yes there is some new information I can add there
<skaet>  :) thanks!
<skaet> ScottK,  kubuntu DVD (20110831) images posted
<GrueMaster> skaet: sorry, I had stepped out and missed your ping.  Desktop armel looks messy, but nothing rebuild worthy.  I am kind of concerned with omap as I don't have networking now, but It may be due to an older board.
<GrueMaster> And I am working to discover if it is a u-boot or kernel issue.
<GrueMaster> I'll get the server testing done tomorrow.
<GrueMaster> (desktop is more complex).
<skaet> GrueMaster, okie.   based on infinity's comments,  which specific images do you want picking up the debian-installer changes?
<GrueMaster> Just the netboot images.
<GrueMaster> Everything else is preinstalled and not affected.
<skaet> Thanks GrueMaster :)
 * skaet appreciates not having to do the grep exercise. ;)
<infinity> GrueMaster: Oh, thanks for that, somehow I keep forgetting ARM doesn't actually have d-i images.
<infinity> GrueMaster: (Well, other than netboot, which is built by d-i itself)
<skaet> infinity, can you paste the netboot building command - I'm scanning the crontab and not seeing it.
 * skaet may be getting tired.
<skaet> GrueMaster, infinity - do we need rebuilds of ubuntu core?
<superm1> skaet, can you accept mythbuntu-default-settings for the ubiquity text rendering fix?
<GrueMaster> I haven't tested it yet, but it is far less complex than the desktop or server, so highly doubtful.
<superm1> hopefully that should be the last of the bugs i think to be fixed for b1
<GrueMaster> It doesn't have boot capabilities on its own.
<skaet> superm1,  am fine with us pulling them in, but would prefer infinity (or one of the other more knowledgeable folk ;) ) do the review. :)
<GrueMaster> skaet: One issue with ubuntu-core that doesn't appear to have been resolved yet is that http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current points to an older version and not the latest daily.
<superm1> Mkay
<skaet> GrueMaster, ack,  probably an oversite at some point.  Will correct now.
<infinity> skaet: I'll be doing core stuff later anyway.
<infinity> skaet: It builds with pretty much zero effort, so I'll get on it in a bit.
<infinity> GrueMaster: That's being fixed.
<infinity> skaet: Fixing that means me committing some fixes to publishing.
<skaet> GrueMaster, latest Ubuntu Core I know about is 20110829.1,  probably best to pull it down manually until jibel and infinity can get things working again.
<skaet> firefox finally published to the mirrors,  am starting off the sequence of builds now.
<micahg> thanks skaet
<skaet> thanks micahg, chrisccoulson   :)
<skaet> builds humming along now,   status of what is going on where, and in which order is on http://pad.ubuntu-uk.org/ubuntu-release if anyone is interested.
<skaet> I'm going to step away for a bit for some dinner, but if someone notices an image has emerged, feel free to post.
<skaet> highlight my nick if issues spotted,  biab.
 * charlie-tca going to sleep soon, will return in about 11 hours
<skaet> charlie-tca - xubuntu builds in that set,  should be up by the time you wake.  (fingers crossed).
<charlie-tca> Thanks. my fingers are crossed too.
 * skaet --> dinner, biab.
<skaet> ubuntu alternate, desktop (20110831) posted
<skaet> xubuntu alternate (30110831) posted
<skaet> ubuntustudio alternate (20110831) posted
 * skaet notes on xubuntu that should have been 20110831
<skaet> astraljava, ^^
 * micahg would have been more interested in xubuntu alternate from the year 3011 :)
<skaet> lol
<skaet> ubuntu dvd (20110831) posted
<nigelb> I didn't know skaet had a time machine :D
<skaet> nigelb,  ...I just wish I could apply it to our mirrors and the build publishers.  ;)
<nigelb> heh
<skaet> pitti,  jibel - I'm calling it a night now.   Edubuntu DVD,  and Xubuntu CD still to come off the builders,  please post to the iso tracker when they emerge.
<skaet> pitti,  http://pad.ubuntu-uk.org/ubuntu-release is up to date with what I know.  :)
 * skaet --> zzz
<pitti> Good morning
<pitti> micahg: I set crested back on auto
<micahg> pitti: thanks, I"ll have more builds later :)
<pitti> ah, I hope the "currently planned rebuilds" in the pad are out of date now, I'll updateit
<pitti> eek, seems kubuntu desktop wasn't rebuilt, doing that now
<pitti> oh, I guess no lightdm -> no autologin fix
<slangasek> ok, who broke the livefs autobuilders? :)
<slangasek> /usr/bin/ubuntu-defaults-image: 130: sudo: not found
<infinity> slangasek: ?
<slangasek> ah, seems to have un-broken itself in a subsequent run
<slangasek> infinity: reading my error mailz
<infinity> Reading is unhealthy.
<skaet> slangasek,  that was cjwatson's zh_CN build.
<slangasek> looks like that's fixed now, but ubuntu/powerpc failed to build because libreoffice is uninstallable there (missing lib)
<slangasek> skaet: ah
<pitti> slangasek: right, ubuntu-defaults-image is only for the localized builds, i. e. Chinese Edition; this is still being set up
<pitti> slangasek: mythbuntu doesn't use firefox, but does use lightdm, I think we should rebuild that, too; I'll trigger thhat
<superm1> pitti, can you accept mythbuntu-default-settings before triggering it?
<superm1> fixes the ubiquity rendering bug
<pitti> superm1: sure
<superm1> thanks
 * superm1 -> bed
<pitti> edubuntu/xubuntu will still build for a while anyway
<pitti> Daviey: is bug 791607 still actually an RC issue? I thought euca is unsupported  now? Or is that still an issue for supporting upgrades?
<infinity> Is this antimony's way of saying I should go to bed?
<infinity> Received disconnect from 91.189.90.135: 2: Packet corrupt
<infinity> Write failed: Broken pipe
<micahg> pitti: feel free to kill a thunderbird 3.1.x build if you need a builder (won't go out until EOD UTC tomorrow)
<micahg> err, EOD UTC today :)
<micahg> it's only ~1hr on everything except armel though
<infinity> slangasek / skaet: ubuntu-core publishing is sane now.  Or, should be.  Have a poke at it and see if it works for you.  All it needs now is someone to write a decent header blurb for it, but that can happen a bit later.
<pitti> micahg: no, should be fine
<pitti> infinity: what does "publishing" mean here? we can start another build?
<micahg> ah, I see I won't be able to grab all the buildds, oh well...it's fine anyways
<infinity> pitti: As in, how they're published. :P
<infinity> pitti: (I'm not in the way of any builds, nor does core need any currently, if either of those was what you were driving at)
<pitti> i. e. http://cdimage.ubuntu.com/ubuntu-core/daily/20110831.1/ ?
<pitti> oh, I see - shiny header.html
<pitti> and the previous ones only had armel builds
<pitti> thanks!
<infinity> pitti: Oh, that can be added to the tracker if anyone has a clue how to test them.  But I was mostly just sanitizing the icky hackjob I had there before for build/publish.
<infinity> pitti: (We are nominally testing/validating core, I guess, but it's basically just "chroot in and see if your shell doesn't segfault, win")
<infinity> Cause, really, how do you test a minimal chroot? :)
<pitti> something like "bash and apt-get install work"?
<pitti> i. e. package management is set up properly
<infinity> pitti: Even the latter won't, unless you set up a resolv.conf.
<pitti> that'd be my expectation, anyway
<infinity> pitti: But sure, that would be an easy testing step.
<pitti> edubuntu DVDs posted
<infinity> Anyhow.  I think it's nap time here.
 * infinity tosses pitti what's left of his cowboy hat.
<infinity> See you in 8 hours. ;)
<pitti> sleep well
<micahg> infinity: +1 :)
<pitti> latest ubuntu core posted
<pitti> not that anyone cares.. "0 notification e-mails have been sent."
<infinity> Oh, one last thing..
<infinity> cjwatson: Should \*gz be added to bin/site-manifest?  Not sure precisely how or what it's used for, but various img.gz and tar.gz images missing from it seems off.
 * infinity sleeps now.
<pitti> xubuntu desktop posted
<jibel> good morning
<pitti> bonjour jibel
<cjwatson> skaet: for the record - netboot images are built by the debian-installer source package.  they're not a cdimage function, and thus you won't find anything pertaining to them in the cdimage crontab.
<cjwatson> infinity: err, maybe - I'll have a look
<astraljava> skaet: Thank you!
<cjwatson> pitti: could you review that ubuntu-defaults-builder upload?  It should fix the overnight failure.
<pitti> mythbuntu posted
<pitti> that was the last image, should all be current and working now
<pitti> cjwatson: sure, doing
<pitti> cjwatson: good morning
<pitti> cjwatson: oh, I guess it shouldn't use sudo if it's already root?
<pitti> right, should have thought about that
<pitti> cjwatson: accepted, thanks for fixing
<cjwatson> in this case sudo isn't installed :)
<cjwatson> (arguably we should depend on it?)
<pitti> cjwatson: I'm happy to add a recommends, but for installing it on the builders it would perhaps better to exit with a meaningful error if you aren't root and sudo is not installed?
<cjwatson> mm, perhaps - at any rate the above change should deal with it for now
<cjwatson> since BuildLiveCD just kicks the whole thing off as root
<cjwatson> infinity: site-manifest now looks at *.img.gz and *.tar.gz too; thanks
<pitti> jibel, cjwatson: do you see anythign which requires urgent attention?
<pitti> if not, I'd reinstall my workstation with the current image, and have lunch in the meantime
<jibel> pitti, testing goes well. major issues on desktop are  bug 837681 and OEM install broken on DVDs
<jibel> 837681	ubiquity (Ubuntu)	New	Critical	Automatic partitioning corrupts GUID partition table (GPT)
<pitti> jibel: OEM install broken on CDs as well?
<jibel> pitti, no only on DVD
<pitti> uh, weird
<pitti> oh, no clickable bug links any more?
<jibel> 837503	ubiquity (Ubuntu)	Triaged	High	'Prepare for shipping' not available on DVDs
<jibel> oem-config is not installed
<cjwatson> 837681> hmm.  that'll be a nightmare to investigate without logs.
 * cjwatson wonders if he can mock up a suitable test VM
<pitti> ok, I think we can release-note oem-config on DVDs
<cjwatson> I know how to fix 837503 but I think you're right that it's release-note fodder for b1
<cjwatson> (commented on the bug)
<jibel> other issue: migration-assistant is broken
<jibel> 829987	migration-assistant (Ubuntu)	Confirmed	High	ubiquity crashed with TypeError: cell_data_func() takes exactly 4 arguments (5 given)
<pitti> ok, back in about an hour; please ring my cellphone if something urgent pops up
<cjwatson> ev: ^- can you look at 829987?
<ev> will do
<cjwatson> confirmed that EFI installations have /sys/firmware/efi again
<jibel> apart from that I'll test ltsp and cjk install this afternoon. ibus was in bad shape last milestone.
<cjwatson> I ported lots of ibus modules to the new libibus, which perhaps may have helped
<ogra_> hmmmm
 * ogra_ cant seem to find out why preinstalled images end up without slideshow
<pitti> re
<ogra_> m
<Daviey> pitti: sorry, just saw your question on scrollback.  The milestone was set really to help encourage those that are working on it.  It is not a release crticial issue.
<pitti> Daviey: ok, so we'll just move it over to b2 I guess
<Daviey> pitti: I plan to move all the milestoned bugs i care about later today.
<Daviey> or rather, s/care/moniotring/
<pitti> Daviey: we have a script for that
<pitti> so we can do it wholesale after release
<pitti> unfortunately it breaks right now, as LP claims to have zero "development releases" of Ubuntu
<pitti> it's trivial to workaround
<pitti> but either way, moving them after the release is more correct, I htink
<cjwatson> grr
<cjwatson> I hate it when I discover new shell quirks during release work
<ogra_> before the friday release meeting would surely be preferred though :)
<cjwatson> 'DISPLAY= $SUDO PROJECT="$FLAVOUR" ARCH="$ARCH" lb build' does not behave the way I expect it to when SUDO is empty
<pitti> ogra_: I can do it right after we unfreeze, i. e. tomorrow
<ogra_> indeed
<cjwatson> I guess parsing of variable assignments happens before parameter expansion
<pitti> eek; that says PROJECT=foo: command not found
<cjwatson> yes
<pitti> cjwatson: shall we just slide an "env" between $SUDO and PROJECT?
<Daviey> pitti: incidently, so do i (have a script) :)
<pitti> that's a real program
<cjwatson> actually I was going to suggest SUDO=env
 * ogra_ was about to say that 
<pitti> cjwatson: or that
<pitti> cjwatson: want me to fix in bzr, or are you on it?
<cjwatson> I'm on it
<cjwatson> uploaded
 * pitti reviews diff from bzr, accepted
<pitti> need to run to the post office, back in 20
<cjwatson> ta
<smoser> cjwatson, could you populate the ISO tracker with https://cloud-images.ubuntu.com/server/oneiric/20110831/
<cjwatson> smoser: I've run the script.  Does it look OK?
<cjwatson> seems to have at least one of the correct ami-* IDs.
<smoser> cjwatson, i think so.
<smoser> checking
<smoser> cjwatson, good. thank you
<pitti> hey smoser
<pitti> smoser: ah, we discussed that yesterday, and Daviey meant that it's not too much value having them there, as they are being tested automatically only anyway?
<pitti> but thanks
<smoser> i wish i would have been consulted.
<smoser> why do we not feel that having a central location at which bugs are recorded and test cases tracked ?
<smoser> s/ ?/is valuable?/
<pitti> well, if it's useful to you, then let's add it
<stgraber> morning
<charlie-tca> Good morning
<Daviey> smoser: hold fire, on the phone
<Daviey> smoser: Yes, it was really a continuation of a prior discussion in here.  I did wonder what the value is in having it on that site, considering the testing is all automated - and copying the pass/fail from one website to another is a little crap.
<Daviey> I totally agree having a central release tracking place is a good thing.
<Daviey> (which is why i was suggesting we look to automate that part)
<cjwatson> sigh, I wish I could test ubuntu-defaults-image more than one commit at a time
 * skaet waves
 * skaet and starts into the backscroll.... 
<cjwatson> pitti: review of ubuntu-defaults-builder 0.18 (just uploaded) welcome :-/
<pitti> hey skaet
<pitti> cjwatson: this just demotes memtest86+ from depends to recommends AFAICS?
<pitti> ah, nevermind, bzr diff -c -3 is the real one
<cjwatson> yeah, promotes it from nothing to recommends
 * pitti waits for it to hit the queue
<cjwatson> I'm hoping that the livefs chroot is set up to install recommends by default
<cjwatson> if it isn't, this will fail anyway due to lack of syslinux-theme-ubuntu, and I shall have to curse and file an RT to get BuildLiveCD amended again
<pitti> cjwatson: calling a local script isn't possible for testing?
<skaet> pitti,  jibel, - so other than bug ev's looking at (bug 829987), all is calm?
<cjwatson> it's less effort to lob it through the autobuild process a few times than to try to replicate a sufficiently faithful local environment
<pitti> cjwatson: I meant, having BuildLiveCD call the script from ~cjwatson or so; I suppose it's not, I was just curious
<cjwatson> that would involve an RT
<cjwatson> and I don't have access to the relevant system anyway
<pitti> skaet: yes, I didn't see other major things pop up except the ones in the pad
<doko_> cjwatson, slangasek: jamespage sees a test failure in lucene2, which goes away when adding/installing fontconfig. were there any changes after the 24th?
<cjwatson> my least-effort access to it is via uploads
<cjwatson> doko_: no idea ...
<pitti> skaet: i. e. oem-config broken on DVDs, EFI (deliberately) broken on server, migration-assitant broken
<cjwatson> well, not deliberately broken, deliberately not respinning to fix
<jamespage> doko_: thats not in lucene2 - that was in jenkins - think out conversation got a little crossed over
<pitti> right, sorry; I meant "deliberately unfixed"
<pitti> "not fixed"
<doko_> jamespage, well, maybe just add it as dependency for now, if we do not find the real reason. can you see, if fontconfig was installed in your succeeding build, maybe pulled in by another dependency?
<jamespage> doko_: ack
 * skaet really likes time scrollback on the pad!  :)
<charlie-tca> skaet: just failed lvm encrypted install on Xubuntu 386 alternate
<pitti> cjwatson: I don't remember, did we use to pre-publish amd64+mac images? publish-image-set doesn't seem to do that
<pitti> we didn't for the final, anyway
<pitti> so I guess it's intended, just want to make sure that this didn't change
<jibel> skaet, and this bug: 837681 ubiquity (Ubuntu) New Critical Automatic partitioning corrupts GUID partition table (GPT)
<pitti> skaet, jibel: the ISO tracker gives me sufficient confidence for ubuntu desktop/alternate to pre-publish, but kubuntu alternate is not tested at all yet, and kubuntu desktop only lightly; so I propose I'll do the pre-publishing later tonight?
<pitti> (we need to do it today for mirrors to catch up)
<cjwatson> pitti: no, they're not on releases
<cjwatson> (for better or worse)
<skaet> pitti, why can't we run them first thing tomorrow?  how long a mirror catch up are we talking about?
<cjwatson> skaet: we can do repeated prepublications, so you can have botrh
<cjwatson> *both
<cjwatson> but the earlier the better really
<pitti> tomorrow is too late, it takes some time to rsync around the world
<pitti> but if we rebuild, another rsync should be a lot faster
<pitti> I need to leave at 19:30 today for Taekwondo, so I could start the pre-publishing at 19:00, which is 2:15 hours from now
<pitti> maybe we'll get some testing on Kubuntu until then
<pitti> I can also pre-publish ubuntu now and kubuntu later, that's even better
<charlie-tca> Both Xubuntu alternate images fail encrypted installs; probably caused by packages needing rebuilds due to changes yesterday
<cjwatson> hm, what would need rebuilds in a way that would affect encrypted installs?
<pitti> charlie-tca: hm, xubuntu got rebuilt last night
<charlie-tca> Can we back them up
<cjwatson> back what up?
<charlie-tca> and today they fail. Yesterdays images worked
<charlie-tca> Can we have them back
<cjwatson> any chance of diagnosing the problem first?
<charlie-tca> bug 838136
<pitti> charlie-tca: you mean releaseing http://cdimage.ubuntu.com/xubuntu/daily/20110830/ instead? in theory yes
<charlie-tca> yes
<charlie-tca> unless we can fix this bug quickly
<pitti> http://paste.ubuntu.com/678937/ is the package version diff between the images
<cjwatson> it would have been quicker to check report.html before starting the tests :)
<pitti> it dropped libwv, tango-icon-theme, libnet-dbus-perl, and indicator-application
<pitti> libwv probably causes the abiword uninstallability
<charlie-tca> Does it only affect encrypted installs?
<charlie-tca> desktop 64 whole disk partitioning worked
<pitti> charlie-tca: should affect all alternate installs
<charlie-tca> oh
<cjwatson> yes, everything.  I advise checking report.html before starting any tests (for images where it exists)
<cjwatson> well, all alternates
<cjwatson> a simple rebuild might fix it; xubuntu-desktop is installable in my chdist environment
<charlie-tca> yes, xubuntu-desktop 64 worked okay
<pitti> I'll try a rebuild; not sure what made these drop off the CD
<cjwatson> charlie-tca: different xubuntu-desktop :-)
<charlie-tca> heh
<pitti> eek, did the DC just fell off the planet?
<pitti> ah no, just LP
<charlie-tca> lol
<charlie-tca> okay, back to testing the desktop images then
<skaet> cjwatson - so decision is to definitely release note 837681 (since limited to amd64+mac?).  Also, what's outlook on  829987?  fix likely?
<cjwatson> 829987 no idea, ask ev
<skaet> ack, will do
<smoser> Daviey, regarding having the results there... i agree they're not all that much value, but the one thing that is there that is no where else is the links to bugs that were found.
<cjwatson> 837681 no proof that it's limited to amd64+mac
<ev> on 829987 now
<smoser> in the jenkins there is no way to say "this failure was this bug".
<ev> was busy fixing oem-config stuff
<cjwatson> it could well be all systems requiring GPT
<ev> which I'm still doing, but I'll put that down for a moment
<cjwatson> i.e. anything EFI or with >2TB disk
<smoser> although, i dont know how i can see historical results on ISO testing so that is not really all that valuable.
<Daviey> smoser: I do agree.. This was why i raised the suggestion of automating copying of the results in the meeting yesterday.
<Daviey> Release team, can i have some advice on bug #836668 ?
<Daviey> It doesn't seem that we have any archive dependencies that require mongodb support for kombu, and it does build ok without this build dep.  However, introducing a delta in kombu to keep pymogo out of main would seem to be more work involved, than maintaining pymongo which currently seems to be maintenance free; and it's only been tested with this build dep so far in the cycle.
<smoser> Daviey, but you'd still need human intervention to mark the bug.
<smoser> and, really, i think iso tracker is severely lacking if you can't see historical results (which i've never been able to see).
<Daviey> smoser: Yeah, that is true.. but it's less time itesive to go and make fails with a bug #, than marking all the ones which passed
<ev> right, 829987 is fixed (it was just the wrong function prototype for GTK3 - passing the data argument is now required)
<skaet> ev,  Thanks!
<ev> sure thign
<ev> thing even
<pitti> charlie-tca: ok, that's better: http://cdimage.ubuntu.com/xubuntu/daily/20110831.1/report.html
<pitti> charlie-tca: posted to tracker
<charlie-tca> Okay, I will try again
<charlie-tca> Thank you very much, both pitti and cjwatson
<pitti> charlie-tca: that should never have made it to the tracker in the first place, sorry about that
<charlie-tca> Well, as long as things are fixable. I get nervous this late when things fail that bad
<pitti> rightfully so :)
<pitti> hmm
<pitti> the tracker says we tested server 20110829.1, but we only ahve 20110830
<ScottK> I've gotten some good installs on Kubuntu live, so if history is a guide we'll likely be ~good to go.
<pitti> hggdh, jibel: seems you tested the server images; can you please check .info/ about the build stamp?
<pitti> I wonder whether it was just added to the tracker with the wrong version, or if we did a rebuild yesterday and lost the old image
<Daviey> pitti: .1 was for the powerpc respin, it was only limited to the single arch.
<jibel> pitti, the tracker is wrong. we tested "Ubuntu-Server 11.10 "Oneiric Ocelot" - Beta amd64 (20110830)"
<Daviey> 20110829.1 was never created for normal arches.
<pitti> jibel: *phew*, thanks
<hggdh> :-)
<pitti> I guess if I bump the tracker, we lose all testing results, though
<pitti> so I'll just fix up the version when publishing
<hggdh> thank you ;-)
<jibel> pitti, I'll update the buildnumber
<pitti> jibel: ah, DB hackery? thanks
<jibel> pitti, new bug for your team. Launching pgadmin3 crashes metacity
<pitti> eek
<jibel> done
<pitti> ScottK: right, and Kubuntu desktop has some successful test cases
<ScottK> The hardware I have available for testing is 32bit, so if someone could work on amd64, it'd be really helpful.
<pitti> ScottK: do you have power again?
<ScottK> pitti: Yes.  Got it back last night.
<pitti> yay
<ScottK> Equally important from a productivity perspective is that school for our 8 year old got power back so today was the first day of school (was supposed to be Monday).
<pitti> skaet: FTR, I pre-published ubuntu desktop/alternate/server and kubuntu desktop
<pitti> I'll do kubuntu alternate once we get a successful test
<skaet> pitti, thanks.
<pitti> skaet: if we re-spin, the update will at least be faster
 * skaet nods
<pitti> hush, mirrors out there, go sync
<ScottK> I've got the Kubuntu i386 dvd downloaded for after I finish Kubuntu desktop testing.
<jibel> LTSP is ok on alternates, next on the list is CJK installation
<stgraber> jibel: you didn't happen to try LTSP in french did you? would have been interested to know if when logging in on the thin client you get the session in the right language (it's not the case for edubuntu).
<pitti> skaet: I think at this point all bugs on https://launchpad.net/ubuntu/oneiric/+bugs?orderby=-importance&field.milestone%3Alist=39143 are OK to move to b2
 * skaet looking
<pitti> skaet: that would clear the list for real b1 showstoppers which come in
<jibel> stgraber, I didn't but I do it again in franch
<jibel> *french
<stgraber> jibel: cool
<pitti> skaet: if you concur, I can run the script to move them wholesale
<skaet> pitti,  scanned them, and concur.  Thanks.
<pitti> so, if a b1 blocker turns up, we'll see it more clearly on https://launchpad.net/ubuntu/oneiric/+bugs?orderby=-importance&field.milestone%3Alist=39143 now
<pitti> skaet: not sure whether you want to target bug 837681 there for the time being?
<pitti> (and move it over if we don't get to it)
<skaet> pitti,  would like bug 837681 moved back to b1 until we hear from cjwatson.
<pitti> skaet: please go ahead
<pitti> seems appropriate to me
<pitti> dinner, bbl
<skaet> pitti, done.
<jibel> stgraber, login screen and session on the thin client are in french
<charlie-tca> Xubuntu 64bit alternate install worked.
<pitti> skaet: targetted it to oneiric, too
<pitti> charlie-tca: good
<charlie-tca> Thank you again
<skaet> :)
<cjwatson> lamont: can you tell me whether the innermost livefs build chroot is configured to disable installation of Recommends by default?  It appears that this is so, but I'd like to chec
<cjwatson> *check
<pitti> jibel: do you guys test the kubuntu alternates, or is that a community effort?
<stgraber> skaet, pitti: Edubuntu looks good but LTSP doesn't work on it... I'm looking at fixing that now (two separate bugs), if I can get something within the next 1-2 hours I'll probably ask for a respin. Edubuntu isn't on releases.u.c (only on cdimage) so we're not affected by mirroring and I'll have time to re-test both images tonight.
<skaet> stgraber,  ok.  Will be standing by.   Are there bug numbers?
<pitti> stgraber: understood
<stgraber> skaet: I don't think so, not sure what the problem exactly is yet. One if LTSP not showing up translated on LTSP live (need to look at upstream code) and the other is LTSP just not booting at all post-install.
<stgraber> the first I'm fine release-noting but the second I want it fixed (and as it's likely to be the same package, I'd fix both at once)
<skaet> stgraber,  thanks for the explanation.  Noted.
<pitti> skaet: need to leave for Taekwondo now
<skaet> ev,  can you upload ubiquity (with migration assistant bug fix), would like to get it build and standing by for rebuilds.
<pitti> skaet: can you take over the con?
<skaet> pitti,  thanks for the head's up,  yup.   please check in when you get back though ;)
<pitti> skaet: I just updated the pad wrt. kubuntu pre-publishing
<pitti> skaet: back in about 2.5 hours, I'll check back in then before going to sleep
<skaet> pitti,  thanks!
<pitti> skaet: at that point I'll pre-publish kubuntu alternate, regardless of the testing result
<pitti> if it still doesn't have any tomorrow afternoon, we can still skip it
<pitti> but I guess it should have some tests by then
<skaet> ok
<pitti> so, cu
<stgraber> skaet: found the problem with LTSP for Edubuntu. Now to find a fix :)
<skaet> stgraber: :)
<stgraber> skaet: and fixed. I'll upload a new edubuntu-live and ltsp in the next 5 minutes or so.
<skaet> even better.   :D
<stgraber> skaet: that's bug 838265 and bug 838268. Both packages are now uploaded and should show up in the queue soon.
<skaet> stgraber, sounds good.  Thanks.
<skaet> slangasek, ^^ can you review?
<slangasek> skaet: yep, reviewing
<skaet> slangasek, Thanks! :)
<slangasek> stgraber: ev doesn't seem to be around; could you prepare an upload of the ubiquity trunk so we can get those fixes in?
<slangasek> ev: ^^ unless there's something still in progress here that we need to hold off for?
<stgraber> slangasek: I'm currently testing one last fix. Colin said he'd upload when he gets back from dinner.
<slangasek> ok
<slangasek> I suppose there's no sense in edubuntu respins until ubiquity is also in?
 * skaet nods
<charlie-tca> looks like ubuntustudio 64 will need a respin -
<charlie-tca> http://paste.ubuntu.com/679164/
<charlie-tca> Can someone kick a respin for ubuntustudio or should I file a bug report on the fail to install?
<slangasek> charlie-tca: are those issues fixed in the source package?
<slangasek> a respin without a source fix shouldn't do any good there
<charlie-tca> Xubuntu had almost the same fails; respin worked
<charlie-tca> Xubuntu also had abiword failing to build though
<slangasek> well, I don't see why a rebuild would fix this but I also don't see why the image missed picking up those packages; trying a respin
<charlie-tca> I know the first two packages should have worked; we have them in the xubuntu images that are now working
<slangasek> this was the error in the logs: Link from /srv/cdimage.ubuntu.com/ftp-universe/pool/universe/t/ttf-sil-andika/ttf-sil-andika_1.0.basic-4_all.deb to /srv/cdimage.ubuntu.com/scratch/ubuntustudio/daily/tmp/oneiric-i386/CD1/pool/universe/t/ttf-sil-andika/ttf-sil-andika_1.0.basic-4_all.deb failed: No such file or directory
<slangasek> some kind of archive skew during the build, then
<slangasek> cjwatson: ^^ is this a new problem?  I don't remember it having shown up before
<cjwatson> tools/hardlink is relatively new code, but why's it getting ENOENT
<cjwatson> and the archive's meant to be locked
<cjwatson> sorry, no cycles to look at this
<cjwatson> just lost an hour's work on the parted bug due to USB cable slippage
<cjwatson> so kind of stressed
<skaet> release team members,  parted needs to be figured out and we need to understand it enough to know if its safe to release tomorrow or not.   Please assist cjwatson if he asks for any help.
<cjwatson> thanks, for now it's a one-person-at-a-time job though
<cjwatson> ubiquity uploaded
<skaet> thanks cjwason.   slangasek, ^^
<slangasek> reviewing
<slangasek> strange set of whitespace changes in bin/oem-config-remove-gtk, bin/ubiquity which are otherwise untouched
<slangasek> cjwatson: ^^ can you tell me if that's deliberate/harmless/uh-oh?
<cjwatson> deliberate and harmless, though I probably should have waited 'til later before committing that
<cjwatson> (pyflakes was whining in red at me)
<slangasek> ok
<bjf> pgraner, skaet What I can tell you at this point is that out of 5941 bugs open against linux, 106 had drives 2 TB or larger
<bjf> pgraner, skaet I'm not checking if any of those are the same system with multiple bugs, i can do that, if you'd like
<skaet> bjf,  thanks!
<slangasek> ev, cjwatson: I see the change in ubi-language.py that addresses not trying to connect signals in oem-config, but there's a very large delta due to dropping a wrapping try/except... that doesn't seem related to this change?
<bjf> pgraner, skaet, is that enough info or do you want me to determine how many of those 105 were the same system?
<cjwatson> I'm afraid I just uploaded it and haven't extensively reviewed it
<skaet> bjf, as long as the 106 weren't all from the same system.   We have the evidence we need that this is a use case that is important.    If its a 5 minute task do it,  otherwise, we have enough for now.
<cjwatson> I don't mind putting back the try/except if you'd rather, since that's easy and it's harmless
<slangasek> cjwatson: ok.  in practice this shows up as the language page failing to be instantiated either way I think, so I'll not worry unless you tell me to
<cjwatson> skaet: is this related to the parted bug I'm working on?
<bjf> skaet, i'll work on it
<skaet> cjwatson, yes,  trying to figure out how many >2T systems might be out there.
<cjwatson> skaet: neither you nor I know exactly what the trigger for this bug is
<cjwatson> I really recommend not going on long hunts until we have more infor
<cjwatson> information
<cjwatson> I can't even tell you yet whether non-Mac >2T systems are affected
<slangasek> ubiquity accepted
<cjwatson> it's quite possible that it's isolated to Macs; it's also quite possible that it isn't
<skaet> cjwatson, understood.   It was asked earlier if we even had some >2T filesystems out there now, and bjf has answered that.
<cjwatson> yep, I was getting bugs related to that a year or two ago
<cjwatson> >2T is one of the big drivers for GPT and hence EFI
<cjwatson> (the "hence" isn't as much of a requirement as the manufacturers would like you to think, but anyway)
<pitti> hello again
<skaet> thanks for the backgound.
<skaet> hiya pitti,  welcome back
<cjwatson> I wish resize2fs weren't so slow ...
<pitti> ah, so ltsp/edubuntu-live were uploaded
<slangasek> superm1: I see there's a mythbuntu-log-grabber ftbfs fix in the queue; would you want that in beta-1?  (It doesn't look critical, but we have a window right now)
<skaet> pitti,  yup, and migration assistant fix just went up.   Will start off edubuntu rebuilds when it lands.
<pitti> skaet: ah, good
<slangasek> skaet: only edubuntu?
<skaet> ubuntu rebuilds are still ??? though.
<pitti> skaet: I don't think we should rebuild the other images for that, though
<skaet> slangasek,  will do any others that want it.
<pitti> if we get a GPT fix, then yes
<slangasek> I would say push the lot to the queue if we care about these ubiquity fixes
<slangasek> the migration-assistant crash wasn't edubuntu-specific?
<pitti> slangasek: right, it wasn't
<slangasek> I assumed it was being pushed because we wanted it for ubuntu
<skaet> slangasek,   I'll trigger ubuntu rebuilds once we understand if we're going to need to wait for parted or not.
<slangasek> skaet: we could always respin again if we find out we need parted, no?  better to make the buildds useful in the meantime
<slangasek> so that if we *don't* need parted, we haven't waited for nothing
<skaet> slangasek,  ok,  will launch them one by one,  so can interrupt.
<slangasek> right, sounds like a plan
<skaet> after ubiquity is published in the archives :)
<ScottK> What's the ubiquity fix?
<skaet> migration assistant
<ScottK> OK, doesn't affect Kubuntu.
<pitti> skaet, slangasek: can you also re-pre-publish the ubuntu images if/when you respin them, please?
<cjwatson> hmm, still can't reproduce ...
<slangasek> can do
<cjwatson> oh, BLAST, parted does its own subarch detection doesn't it
<cjwatson> so I need to hack libparted as well as just archdetect
<pitti> skaet, slangasek: do you have the situation under control, or need me to do anything right now?
<skaet> slangasek,pitti  I've got the pad scored for the rebuilds and triggers.
<skaet> pitti,  I'll be adding the publish/not status at the bottom of it,  started now.
<skaet> will flesh it out through the day.
<cjwatson> ScottK: there are a couple of other changes too, but I don't think they're vital for the KDE frontend.  Bug 770320 would affect you but is hardly respin-worthy on its own.
<skaet> pitti, if you've got any data add it to the pad,  otherwise,  situation is as under control as its going to be ;)
<pitti> skaet: no further data from me, as I just returned
<pitti> skaet: ok, then I'll go to sleep, and come back in 8 hours
<skaet> Thanks pitti.
<pitti> good luck!
<superm1> slangasek, no rush for it right now, just let it  through after b1
<pitti> skaet: oh, forgot: kubuntu alternates still have no tests, but I'll pre-publish it now
<pitti> at worst we re-pre-publish it
<skaet> pitti,  ok,  but if they don't get tested,  we're not going to release them.
<pitti> skaet: right
<pitti> but if they are good, we have them ready
 * skaet nods
<ScottK> cjwatson: Thanks.
<pitti> skaet: done
<pitti> good night everyone
<skaet> thanks pitti,  sleep well.
<skaet> superm1,  you ok with the mythbuntu images that are available being shipped tomorrow?
<superm1> skaet, yeah they're cool with me.  won't solve the oversize issue on amd64 by b1
<ScottK> jibel: Do you have anyone that could test http://iso.qa.ubuntu.com/qatracker/result/6391/55 - I'd feel a lot better with releasing if I knew that was a "sometimes" problem and not an "always" problem.
<bjf> pgraner, skaet, the number of bugs filed against unique systems with 2TB drives appears to be 90
<skaet> Thanks bjf!
<bjf> pgraner, skaet if you have any further requests, let me know, for now I'll consider this done
<skaet> bjf,  consider it done.  :)  much appreciated.
<jibel> ScottK, confirmed.
<ScottK> jibel: Thanks.
<ScottK> jibel: Confirmed it happens all the time or confirmed it's a sometimes problem?
<jibel> ScottK, it happens all the time. create more than 2 partitions and change one, the installer crashes.
<stgraber> ScottK: I'll have a look. I have another kubuntu-only ubiquity bug I'm looking at so I can have a quick look at this one.
<ScottK> stgraber: Thanks.
<ScottK> skaet: We could probably release note for Bug #838273 ^^^ if we have to, but it does concern me.
<stgraber> jibel: did you get a trace in /var/log/installer/debug?
<ScottK> jibel: Thanks again.
<cjwatson> there wasn't anything obvious in the logs in the bug, that I saw
<skaet> ScottK,  let me know if there's any chance of a respin, or if you want to hold off on the images.
<ScottK> skaet: Let's plan on release noting, but if stgraber can find something soon/low risk we can think about it.
<stgraber> jibel: can you give me more detail on your setup? I tried with a disk that already had 3 partitions and it worked fine here.
<stgraber> jibel: did you start with a blank disk, then created 3 partitions?
<jibel> stgraber, on kubuntu ?
<stgraber> jibel: yep
<jibel> charlie-tca, ^
<charlie-tca> two hard drives, one is 200GB, one is 40GB
<charlie-tca> four existing partitions on 200GB, two of which are /swap
<charlie-tca> two partitions on 40GB, / and /swap
<stgraber> oh, I found what's wrong with my setup. My image is 32bit. downloading 64bit now
<charlie-tca> tried to change / on 40gb, no problem.
<charlie-tca> clicked on the first partition on 200GB, clicked change, got thrown out of the installer
<charlie-tca> will run it again and grab the logs if you need them?
<cjwatson> aha, reproduced the parted bug, finally
<cjwatson> (archdetect stubbed to print i386/mac; PARTED_GPT_APPLE=1 inserted in /lib/partman/init.d/30parted; otherwise followed directions in bug
<cjwatson> )
 * skaet very happy to hear reproduced.  :)
<skaet> jibel, any problems if I go in and remove from the iso tracker, the images its clear we're not going to be releasing?
<skaet> or should I just mark them as invalid?
<jibel> skaet, go and remove.
<cjwatson> I can at least say that the parted bug is definitely Mac-only
<skaet> jibel, thanks, will do.
<skaet> cjwatson,  *whew*   That makes me feel a lot better.
<cjwatson> I'm not sure it does me.  There may well be more Macs than systems with >2TB disks.
<skaet> cjwatson, yeah, but we can hold back the amd64+mac images.
<skaet> nice identifiable affected subset.
<skaet> not great, but better than the big ??
<cjwatson> skaet: the amd64 images brick at least some Macs
<cjwatson> do you really want to do that?
<cjwatson> also, the i386 images are affected
<ScottK> skaet: Kubuntu alternates look good.
<skaet> cjwatson,  hmm... I misunderstood then I thought it was only Macs - are there i386 Macs?
<cjwatson> almost any amd64 system can install using i386
<cjwatson> (the exception being pure UEFI, but that doesn't cover Macs)
<cjwatson> and given that historically we've tended to recommend i386 rather than amd64 for desktop systems ... (though that should be changing with multiarch)
<skaet> Can we not say prominently in the release notes;  "These images are not intended for installation on Mac's, do not do so unless you're a developer and willing to help us debug if there are problems" ?
<cjwatson> we could, but I think that's a pretty bad last resort
<skaet> understand.  will let you get back to figuring it out.
<GrueMaster> skaet: All armel testing is now complete.  Some big issues with netboot, but they can be worked around.
<skaet> GrueMaster,  re: netboot,  will we release omap and omap4  - or just omap?
<GrueMaster> both
<skaet> GrueMaster,  ok, thanks.   Can you add the workaround information to the issue in the release notes?
<GrueMaster> Already adding to the tracker.  Will add to the release notes wiki.
<skaet> Perfect.  Thank you. :)
 * cjwatson tests a fix
<charlie-tca> slangasek: I don't know why or how, but ubuntustudio re-spin installs good now
<charlie-tca> Thank you for doing the re-spin
<cjwatson> if anyone wants to preview, the patch I'm working with is http://paste.ubuntu.com/679243/
<cjwatson> on the grounds that Linux refuses to treat a partition table as GPT unless it has a 0xEE protective partition *starting at LBA 1*
<cjwatson> we were failing to enforce the latter condition
<cjwatson> so I think this only affects systems where the BIOS GRUB partition doesn't start at LBA 1; but who knows how many systems that might be, I suspect quite a few
<cjwatson> hmm, maybe not quite right, trying http://paste.ubuntu.com/679246/ instead
<cjwatson> brick> incidentally I'm awaiting results of a test fix for that, since obviously it's pretty bad too, but we released natty with that bug so ... :-/
<cjwatson> ... and we need *slightly* more than that to guarantee that GRUB stays happy with the GPTness as well as Linux
<skaet> stgraber,  https://launchpad.net/ubuntu/+source/edubuntu-live/11.08.7,  is only building i386.  Is this expected?
<stgraber> skaet: yep, it's an arch:all package
<skaet> stgraber,  thanks.
<stgraber> ScottK: ok, got a crash including a stacktrace. Going to grab some dinner and I'll debug that when I'm back.
<GrueMaster> skaet: Did you want me to document the workarounds for netboot-omap/omap4 on the pad document?  Might be easier than me trying to find the wiki page ogra usually works on.
<skaet> GrueMaster, https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview
<GrueMaster> ok
<skaet> If you can add it directly will save someone (ie. me) transcribing it later ;)
<slangasek> cjwatson: so this affects all mac systems because gpt is required there, rather than just being an issue for >2TB disks?
<cjwatson> yes, exactly
<cjwatson> it's not an issue on non-Mac systems because it's a bug in the legacy MBR code path, which is Apple-only because we love standards and want more of them
<cjwatson> uploaded a fix, which is http://paste.ubuntu.com/679260/
<cjwatson> full test (insofar as I can) is still running, but I've checked that sfdisk output now looks a lot more plausible
<cjwatson> i.e. 0xee partition first, only one of it
<cjwatson> we'll need testing on a real Mac though, so hopefully Chad can provide that
 * skaet nod
<skaet> (Chad was recovering his system, not sure if its operational or not yet)
<cjwatson> I mentioned on #ubuntu-testing that gptsync from a live CD should fix it
<skaet> yup,  missed that post.  just saw it.
<skaet> slangasek,  ubiquity just published to the archives,  I'll do a build with it so we have it in hand,  while waiting for parted to build/publish.   Will do respin tonight.
<skaet> stgraber, ltsp is published, but edubuntu-live appears to have missed this cycle.   Do you want me to wait for the parted fix and respin then?  or respin when edubuntu-live publishes?
<slangasek> skaet: ok.  anything you need from me?
<slangasek> aside from parted review, which I'm doing now
<skaet> slangasek,  thanks!
<cjwatson> hm, I think given parted uploaded now, it might be more efficient to just wait for it?
<cjwatson> well, it'll take two hours from now
<cjwatson> (probably)
<cjwatson> I suppose you might get two or three builds in in that time
<skaet> cjwatson, yeah I figure I can gt the images in about an hour.
<skaet> yeah
<cjwatson> just don't want to burn out testers
<skaet> I wont publish the results of the just ubiquity build, unless things go south with the parted+ubiquity one.
 * skaet gets some insurance ready.
<cjwatson> makes sense
<slangasek> does parted take > 9 min to build?
<cjwatson> about 11 mins last time on i386
<slangasek> ok
<slangasek> should I hold the publisher for it?
<cjwatson> 4 mins or so on amd64
<cjwatson> 50-odd mins on armel, 14 mins on powerpc
<cjwatson> that might be worthwhile
<slangasek> so worth holding the publisher for a couple mins to get it in this hour IMHO
<cjwatson> maybe on everything !armel
 * slangasek nods
<cjwatson> since armel is in different antimony build passes anyway
<skaet> slangasek if you can speed up the publisher part you have my sincere thanks.
<skaet> slangasek,  feel free to nudge edubuntu-live along while you'r at it for parted
<slangasek> nudge along?
<skaet> publish
<slangasek> it already is, unless there's another version pending?
<skaet> hmm.. wasn't showing up on the mirror when I just checked.
<slangasek> antimony's mirror, or another?
<cjwatson> the mirror doesn't show anything until the publisher runs, and the publisher will publish everything that's pending (no way to make it not do so)
<skaet> main one.
<skaet> http://archive.ubuntu.com/ubuntu/pool/universe/e/edubuntu-live/?C=M;O=D
<cjwatson> that's not the one antimony usses
<cjwatson> *uses
<slangasek> right, that's just propagation lag; it's published on cocoplum, antimony gets it from a more direct source than archive.u.c
<cjwatson> I've heard reports of problems with archive.u.c syncing; I would not recommend relying on archive.u.c as your data source
<slangasek> the best way to confirm antimony can see it is to tell antimony to update its mirror
<slangasek> (hence the wait-for-package tool()
<skaet> gotcha.
<cjwatson> oh, wow, wait-for-package is going to do fun things if there's something else building
<cjwatson> it doesn't respect the "build-image-set is running" semaphore
<cjwatson> must fix that ...
<skaet> infinity was educating me a bit about it last night, but I still have a bit to learn and some things to write.
<infinity> cjwatson: Sadly, the issues with archive.u.c seem to go all the way back to syowa, meaning that antimony syncing from syncproxy has similar issues. :/
<cjwatson> the way I tend to predict whether a package will be available to antimony is (a) see if LP says it's published (and not "yet to be published in the repository" or whatever it says) and (b) check 'ps -u lp_publish f' on cocoplum to make sure the publisher has actually completed, as there's a window between LP thinking it's done and it actually being on disk such that antimony can see it
<infinity> cjwatson: I have no idea why our internal mirror world seems to have pooped itself lately, but...
<cjwatson> infinity: jpds pointed me at https://rt.admin.canonical.com/Ticket/Display.html?id=46572 - apparently there are some hardware problems around there
<slangasek> infinity: all the more reason to test by actually pulling the mirror down
<slangasek> rather than using any sort of proxy metric
<infinity> slangasek: Yeah, I've been testing by just syncing the mirrors.
<slangasek> can someone bump the build score for parted? i386 is already built and accepted, amd64 is listed as starting in 1h
<cjwatson> the problem with just syncing on antimony is that if a build is in progress you may cause it to have inconsistent Packages/Release files
<infinity> slangasek: Sure.
<slangasek> well, assuming bumping the build score will do any good and the buildds aren't just plain saturated
<cjwatson> urgh, they're saturated
<cjwatson> I think
<infinity> They sure are.
<infinity> Bumping the score brought it from > 1 hour wait to... 42 minutes.
<slangasek> pff
<infinity> cjwatson: I only sync when there aren't builds, since I'm syncing to see if I want to start builds.  But point taken.
<infinity> cjwatson: Sadly, syncing from syncproxy still is leading to inconsistencies.  Were there technical reasons (or just concerns about ftpmaster's precious CPU time?) why we don't sync from cocoplum?  It's the only source that's actually guaranteed sane.
<slangasek> should we invoke lamont --kill-build paraview/amd64?
<skaet> ok, if we're going to be waiting on those buildds, am tempted to start building that insurance - unless it will make some things worse.
<cjwatson> infinity: I don't remember, elmo told me to do it this way about seven years ago
<cjwatson> slangasek: yes
<cjwatson> if you can get hold of lamont, I haven't heard from him today IIRC
<slangasek> lamont: ohai
<slangasek> skaet: I don't think it will make anything worse if you're just doing a smoketest build - it will certainly finish before we need to get other builds going
<slangasek> infinity: interpret for me - https://launchpad.net/builders/ says 3 amd64 builders, I only see 1 of them currently building a package in archive?
<infinity> slangasek: I see 3...
<infinity> elmo freed up crested for us.
<slangasek> infinity: which ones?
<cjwatson> two of them are building non-virt PPAs
<infinity> ^
<slangasek> ok
<slangasek> so the ubuntu-security-proposed ones, right
<slangasek> elmo: thanks :)
<infinity> And canonical-kernel-team.
<infinity> Are we going to need more emergency builds tonight?  I can toss crested on manual to avoid blocking it again.
<infinity> (Okay, silly question, "are we going to have more unforseen issues", but whatever)
<cjwatson> might be a good plan.
<cjwatson> though any such uploads aren't going to come from me, unless leaning on the z key is likely to improve some unfortunate package
<infinity> It's possible.
<stgraber> skaet: I'm fine waiting for parted
<infinity> For the love of... It takes longer to purge paraview's build-deps than it takes to build parted.
<infinity> *taps foot*
<elmo> I particularly love how we still purge the build-deps on the virtualized buildders
<elmo> which are cow snapshots that are goiong to get thrown away anyway
<infinity> At UDS-P, someone corner me, force beer down my throat, and get me to make abort() work.
<infinity> elmo: I think there was once an argument that people wanted to have the "do build-deps correct remove/purge" data.  Which, of course, no one got around to exporting.
<infinity> elmo: So, that's kinda special.
<slangasek> in the meantime, someone want to get us a powerpc builder to go with the amd64 one (and score up parted appropriately)?  that's not as urgent though.
<cjwatson> OK, my VM test with the updated parted passed
<infinity> elmo: 1-line fix to just make sbuild stop doing the removal step.
<cjwatson> for whatever that's worth
<slangasek> i.e., if powerpc isn't going to be ready soon, I'll pull the trigger with i386+amd64
<cjwatson> so I'm crashing now.  one of these days I want a beta where I'm not critical-path. :-P
<infinity> cjwatson: Stop doing critical things.
<infinity> slangasek: PPC will build in a minute or so.
<slangasek> cjwatson: cross-train doko on parted? :) 'night :)
<cjwatson> SMS me if the world falls over again, and I'll probably hear it
<slangasek> infinity: ok
<slangasek> if the world falls over, wouldn't you hear that without us needing to use SMS
<cjwatson> not if it all does so at once, principle of relativity and all that
<infinity> Depends on how he lands.
<infinity> slangasek: It's possible that LP is lying to me about when I get PPC CPU time. :P
<slangasek> that's not very sporting of it
<cjwatson> skaet: oh FWIW, I think we should rebuild alternate for parted 2.3-6ubuntu2
<infinity> It's a bit of a jerk that way.
<cjwatson> I suspect we can get away without server for that
<cjwatson> somebody should update the pad with things like which other desktops are to be rebuilt for parted 2.3-6ubuntu2
<cjwatson> I've updated it with the version information
<cjwatson> anyway, really gone
<infinity> slangasek: I imagine it makes as much sense to just turn the publisher crank once parted_amd64 is uploaded, do some x86 builds, and ppc will get there later.
<infinity> FSVO "later".
<slangasek> infinity: except the ppc builds now trigger as part of the same job, so if it's not too long of a wait we're better off getting powerpc in at the same time
<infinity> ARCHES="amd64 i386"; buildstuff && for-project do-stuff?
<infinity> But we can summon elmo to buy us a PPC buildd too.
<slangasek> the syntax is not an issue, the human time spent doing it twice is
<infinity> *nod*
<slangasek> however, this minute is longer than the ones I tell my wife it'll take me before I get off the computer and am ready to leave the house, so let's go with that for now
<infinity> Getting elmo to tackle a wandering Xserve.
<infinity> If he hasn't gone to sleep. ;)
<infinity> Okay, adare incomine.
<infinity> incoming, too.
<infinity> After 7 minutes of build-dep removal...
<infinity> Seriously.  beer.  abort().  Remind me.
<infinity> slangasek: There.  parted/ppc building, and adare also on manual in case we need it.
<slangasek> thanks :)
<infinity> I sometimes wonder if we should turn davis into another PPC buildd.  How often do people actually use the porter machines?
<infinity> Mostly, people seem to just throw stuff at the archive and pray anyway. :/
<slangasek> I use it
<infinity> Well, yes.  I figure a few of us do.
<infinity> Well, I'm not in that list only because my house is littered with PPC hardware.
<elmo> if we want to turn something into a buildd, it should be sulfur, not davis
<infinity> elmo: Oh, we have another PPC machine hiding in the DC?
<elmo> yeah, an openpower one
<infinity> Oh, shiny.
<ScottK> stgraber: Great.
<micahg> I have more mozilla builds, do you need me to hold off on long stuff?
<slangasek> well, we don't have an i386 buildd held in reserve yet
<micahg> slangasek: I can wait a couple hours for the firefox/xulrunner ones, I might have some other builds though, will ask if any of them are > 20 min
<slangasek> alternatively if we can get an i386 buildd marked manual, you wouldn't need to wait
<infinity> I can steal one, sure.
<infinity> There, roseapple is ours.
<infinity> micahg: Just upload whatever.  If we screw ourselves, it's not your fault. ;)
<micahg> infinity: heh, ok, thanks, I have to wait a bit on those builds anyways as there might be a respin of the respin :-/
<infinity> Of the respin of the respin of the respi...
<infinity> *head explodes*
<slangasek> mmk, parted builds all done, so we can run the publisher again right after this finishes
<slangasek> micahg: hmmm?  Point is we have buildds reserved now, so we won't trip over any builds you queue
<infinity> ^
<micahg> slangasek: no point for you :), just mumbling...
<slangasek> micahg: I don't understand your "I have to wait a bit on those builds anyways"
<micahg> slangasek: wait to upload
<slangasek> yes, why do you?
<micahg> slangasek: I don't want to upload then repackage and upload build2 :)
<slangasek> do you mean that they're builds for oneiric?
<slangasek> oh, you mean respins of the source
<slangasek> not of images
<micahg> slangasek: yes
<slangasek> I didn't know packages spun, only CDs :)
<micahg> Mozilla's good at spinning :)
 * slangasek coughs
<infinity> I propose we change the verb used for creating CD images from "spin" to "twirl" for the next release week.
<infinity> "Can you twirl me a new xubuntu-desktop?" just sounds like it would add levity.
<slangasek> skaet: parted publishing for i386/amd64 done; powerpc pending publication
#ubuntu-release 2011-09-01
<stgraber> hmm, either my brain stopped working or that kubuntu installer crash doesn't make sense
<stgraber> it's basically complaining of a missing attribute of a TreeItem instance but that attribute is set in its constructor...
<stgraber> ScottK: I'm surprised jibel and charlie-tca could reproduce the bug that easily. I had it happen here once but the stack trace doesn't make sense (as I said before) and I've been playing with the manual partitioner for 5 minutes now without a single crash
<stgraber> ScottK: at least I found a bug in the crash handler that was making it crash, so at least with the next upload when it crashes we should get a proper trace :)
<skaet> rebuilding ubuntu desktop,  edubuntu dvd, ubuntu dvd, ubuntu alternate started.   Anything else to add to queue.
<skaet> ?
<holstein> skaet: let me ask about ubuntustudio...
<holstein> skaet: NM... i wont get anyone who knows in a timely manner :.
<stgraber> skaet: do you have an ETA for edubuntu? (wondering if I test them tonight or first thing tomorrow morning)
<skaet> stgraber,  I'm estimating about 1.5-2 hrs for them popping out.
<skaet> Probably best early tomorrow as its getting late for you there?
 * skaet not sure if stgraber is night or morning person. ;)
<stgraber> I'm definitely not a morning person :) I should at least have time to zsync them and maybe start testing then
<skaet> ok, from side band,  looks like ScottK wants Kubuntu with parted fix,  adding those to the list as well.
<skaet> stgraber - will ping you directly as soon as they emerge then.
<stgraber> thanks
<skaet> np
<skaet> charlie-tca, do you want a respin with the parted fix picked up?
<ScottK> Do we get stgraber's Ubiquity change too?
<stgraber> ScottK: the crash handler for the kde installer? haven't released a new ubiquity for that. Was hoping to find the reason for the other crash, though I guess I'll need to get barry on that as it seems to be some python weirdness
<ScottK> OK.
<ScottK> Once we have something to test we can update Ubiquity from a live session even if it's not on the CD.
<stgraber> fixing the crash handler would only let us get tracebacks easily but wouldn't fix any crash, don't think it's worth waiting for
<ScottK> OK.
<stgraber> yep. Hopefully someone will have a clue of what's wrong and we'll have something to test tomorrow.
<stgraber> I also asked again in the bug report for anyone who can reproduce the issue reliably. That'd help a lot for debugging...
<ScottL> skaet, i think charlie-tca already asked for a respin on ubuntu studio amd64
<ScottL> i would presume the same problem would affect i386 as well
<skaet> ScottL,  yup, addint it to the list
<skaet> what about Xubuntu though?
<ScottL> skaet, thank you :)
<ScottL> that i can't answer about, although the backscroll says something
 * skaet goes back and sees what she's missed....
<ScottK> skaet: It'd be useful to get an idea of where this change might affect things.  I probably won't have time to redo 100% of the testing we did today, so I need to know where to focus.
<ScottK> slangasek: ^^^ I'd appreciate suggestions?
<skaet> ScottK, installation with default partioning, a manual partitioning test - should be done at a minimum.   Best on a powerpc and also on regular is my estimate,  but will let slangasek comment further ;)  (and educate me too)
<ScottK> I don't anticipate releasing PPC for Kubuntu this milestone.
<skaet> my bad
<ScottK> (usual Kubuntu PPC tester has a dead machine ATM)
<skaet> sorry,  worked on mac's when they were only powerpc,  so brain slip
<skaet> meant to say on a mac.
<skaet> s/Best on a powerpc/Best on a mac/
<ScottK> K
<ScottK> Not sure I have a Mac tester, but we can at least do some regression testing with other hardware.
<infinity> Just go to a mall, armed with a CD, and flog a "genius" until they let you use one of the floor models.
<infinity> The flogging the genius part is really worth the effort.
<ScottL> skaet, these images that are being rebuilt are the QA images, correct?
<skaet> ScottL,  yes,  I'll post them on the iso tracker as soon as they emerge.
 * skaet likes infinity solution to testing Macs ,  ;)
<charlie-tca> reading the backlog
<charlie-tca> just got back
<charlie-tca> I don't want any respin I don't have to do
<charlie-tca> skaet: ^  ^
<charlie-tca> I don't know what the parted fix is.
<skaet> charlie-tca,  if people are installing on macs, its a rather nasty bug that corrupts the partions.
<infinity>   * When creating a legacy MBR on Apple systems, only ever mark an existing
<infinity>     partition as a fake protective partition if it is the first partition
<infinity>     and it starts at LBA 1, otherwise GRUB and the Linux kernel respectively
<infinity>     will fail to treat the disk as GPT; if there is no partition fitting
<infinity>     these criteria, then fall back to creating a fake protective partition
<infinity>     (LP: #837681).
<skaet> thanks infinity,  was just going to pull that ;)
<charlie-tca> so, that affects any mac, not just the mac specific images?
<skaet> charlie-tca,  yeah that's what cjwatson indicated to me when I hoped it was just mac specific images...
<charlie-tca> That's going to delay beta1 until tomorrow night sometime
<charlie-tca> I can't get all the images tested again tonight
<infinity> The mac-specific images are rather poorly-named, to be fair.
<skaet> charlie-tca,  probably doing spot tests is appropriate.  Change is limited in scope.
<skaet> basically making sure no regressions on the i386, amd64 for the partitioning tests is appropriate.
<charlie-tca> I suppose we should re-spin then. If I don't, mac users are screwed
<skaet> charlie-tca,  I'll add them to the queue for tonights builds.   And then you can decide in the morning with pitti whether to add them to the tester or not.
<charlie-tca> okay
<charlie-tca> If they build and I can run them in the morning, I will add them. I still have to do the release notes, too
<skaet> charlie-tca that seems reasonable.  Feel free to add to release notes now. ;)
<charlie-tca> Yeah, if I can get my eyes to focus i sure will
<skaet> charlie-tca, understood.  Sleep instead, if that will help.   There will be synch time in the morning.
<charlie-tca> Okay, thanks
<ScottK> charlie-tca: I don't intend to fully retest Kubuntu.  I mostly want to do some regression testing to make sure the common partitioning scenarios work.
<ScottK> For a Beta, I think that's OK.
<charlie-tca> Thanks. I will try to do that too.
<skaet> Ubuntu desktop & alternate posted. 20110901.  archs: amd64, amd64+mac, i386
<skaet> Ubuntu desktop & alternate posted. 20110901.  archs: amd64, amd64+mac, i386
<skaet> erg... posted that already
<skaet> meant to type
<skaet> Ubuntu Studio alternate posted.   20110901.   archs: amd64, i386
<skaet> ScottL, charlie-tca ^^
<charlie-tca> thank you
<skaet> yw
 * holstein downloading :)
<ScottL> thank you skaet
<skaet> :)
 * ScottL is going upstairs to start downloading as well
 * skaet figures she's got another 30 minutes before the next one show up, so giving in to her dog's plantive looks and going for a short walk. biab.
<skaet> ScottK,  kubuntu alternate posted 20110901:  archs: amd64, i386, amd64+mac
<charlie-tca> skaet: I feel like my notes are a bit long winded this time. Feel free to cut them where you see fit.
<charlie-tca> I updated them, anyway
<skaet> Thank you charlie-tca.  :)   Will make it easier tomorrow. :)
<charlie-tca> yw
<skaet> stgraber, highvoltage,  refreshed Edubuntu DVD's just posted to the tracker.  20110901
<skaet> charlie-tca, xubuntu alternate is off the builder, and sitting in the dailies.   Let me or pitti know if you want it posted.
<stgraber> skaet: cool, thanks
<infinity> Is anyone awake enough to do more emergency upload/publish/respin cycles tonight, or should I relinquish our manual buildds back to auto for the night?
<stgraber> I'm not planning on uploading anything :)
<stgraber> pitti should show up in a few minutes though
<infinity> I mostly just want to give powerpc a chance to catch up again.
<infinity> I'm sure pitti can have adare halted again if he needs it.
<infinity> pitti: If you need to do an emergency kill on a buildd to push something through, try to make sure it's not insighttoolkit on ross.  That's been building for half a day, would be a shame to kill it now. :)
<slangasek> ScottL: the ubuntustudio amd64 respin earlier was for a broken CD, not related to pulling in any updates, fwiw - not that this precludes respinning to get those package updates
<slangasek> ScottK: sorry, not sure which change it is you're talking about retesting for - the parted one?
<slangasek> the change is deep in the GPT-handling code.. I don't think there's a need for rigorous testing outside of machines that use GPT
<skaet> inifinity, relinquish away
 * skaet was in other window...
<skaet> Ubuntu DVD posted (20110901)
<skaet> Daviey, I tried building ubuntu server during the rebuilds tonight, and it is still crashing the build.   Just in case you see the logs.
<pitti> Good morning
<pitti> infinity: builder killing> noted; still catching up with backscroll to see whether something needs a rebuild
<pitti> charlie-tca: hey
<pitti> charlie-tca: should we post/use the new xubuntu alternate?
<pitti> I'm not quite sure why xubuntu desktop wasn't rebuilt for the same reason
<pitti> ah, building
<skaet> good morning pitti
<skaet> pad should be fairly current
<skaet> charlie-tca wasn't sure if they wanted to pick up the new images or not.  Alternate is built,  and livecd is about to build.
<skaet> (after kubuntu finishes)
<skaet> sequence currently in flight is on the pad
<pitti> I'll re-pre-publish kubuntu alternate and the ubuntu desktop/alternate
<pitti> so that they get a few hours to rsync into the world
<skaet> pitti,  sounds good.
 * skaet notes (and wants to be reminded) we probably need to put something into the checklist about this to do day -1.
<pitti> skaet: "this"?
<pitti> skaet: pre-publishing is there already
<skaet> pitti,  arrgh.  did it again.   s/this/prepublishing/
<pitti> that's on https://wiki.ubuntu.com/BetaProcess already
<skaet> yup you're right.
<skaet> somehow glossed over it on my earlier read.
 * skaet needs to go to bed now ;)
<skaet> pitti, is the pad fairly clear on what's left?
<pitti> skaet: yes, it is
<pitti> skaet: so in my day, I'll finish the posting to the tracker, coordinate about teh yay/nay with charlie-tca, give the tech notes an once-over again, and watch out for more trouble in general
<pitti> skaet: I'll also prepare the publishing, so that we just need to press the "sync out" button
<pitti> skaet: do you handle the announcement mail/web site update coordination in your tomorrow?
<skaet> pitti, yup,  I'll handle the announce mail/web site update coord. Probably around my afternoon, after we get all the ok's and updates in the notes.
<skaet> Kubuntu CD 20110901 published
<infinity> pitti: Not (pre-)publishing ubuntu-core for beta?
<skaet> infinity, its on cdimage, not release...  last I learned.
<infinity> skaet: Oh, fair enough.  I never pay attention to simple/full politics.
<pitti> infinity: AFAIK we only put ubuntu/kubuntu desktop/alternate on releases.u.c.
<skaet> infinity, np.  Let us know if you hear different,  but cdimage should be ok for it.
<pitti> core is fairly new, so there might not be a firm decision yet, but I think cdimage is fine
<infinity> pitti: Yeah, cdimage is fine for now anyway.
<infinity> pitti: If I hear differently before final release, it's not rocket science to move it to simple.
<skaet> pitti, key bugs still need to be added to release notes, will take a pass when I wake up.  Expect jibel will add some too.
<pitti> skaet: ah, I'll look into this, too
<pitti> skaet: kubuntu desktop was right on time :) all necessary images pre-published now
<skaet> :)
<skaet> pitti, kubuntu dvd is about to emerge, after that xubuntu desktop.    Can you publish?   I'm thinking its time for me to turn go get some zzz.
<pitti> skaet: yep, will do; sleep well!
 * infinity thinks it's probably bedtime.
<skaet> Thanks pitti!
<skaet> Sleep well infinity!   Thanks for your help today!
<infinity> NP.
<pitti> infinity: good night!
<rickspencer3> good morning/evening all
<pitti> hey rickspencer3
<rickspencer3> hey pitti
<rickspencer3> so I hear that >2TB bug got fixed by cjwatson last night?
<pitti> rickspencer3: right
<rickspencer3> sweet
<pitti> we re-spin images, they need fast testing now
<rickspencer3> pitti, was jibel able to confirm the bug fix in the test lab?
<pitti> rickspencer3: I don't think so, that happened in the middle of the night here
<rickspencer3> ah
<pitti> that'll need to happen today
<rickspencer3> cool
<rickspencer3> middle o fht enight here is middle of the ngiht for cjwatson too!
<rickspencer3> I love that dude
<pitti> +1
<pitti> I hope we won't see him before mid-day today
<pitti> GrueMaster, ogra_: oh, the pad says to not publish omap for ubuntu; is that still current? I thought it works for netboot?
<jibel> morning
<pitti> bonjour jibel
<pitti> jibel: ca va?
<jibel> morgen pitti.
<jibel> Es geht mir gut, danke schÃ¶n. Und dir ?
<pitti> un peu fatiguÃ©, mais bon
<pitti> jibel: we got a new set of images over night, for the GPT bug
<pitti> I'm just doing my second test install on amd64 desktop, looking good so far
<pitti> but I haven't tested GPT/mac
<jibel> I'm syncing them.
<pitti> kubuntu DVDs posted
<pitti> charlie-tca: xubuntu desktop/alternate 20110901 are now available; please let me know about whether or not to post them
<jibel> pitti, rickspencer3 I'm not sure how I can test the GPT bug without a Mac.
<jibel> chadadavis (the reporter) will test it when he's online (morning CEST)
<rickspencer3> hi jibel
<jibel> The best I can do is mimic the test cjwatson did but I'll need his directions because I don't know how to fake an architecture.
<jibel> Hi rickspencer3
<rickspencer3> jibel, oh, I thought it impacted machines with >2TB harddrives as well
<rickspencer3> and that you were able to replicate that in your lab
<jibel> rickspencer3, no I've not been able to replicate.
<rickspencer3> oh, bummer
<rickspencer3> so, this is it a bit worrisome
<rickspencer3> what if:
<rickspencer3> 1. the bug is not fixed and/or
<rickspencer3> 2. there are significant regressions
<pitti> perhaps Chad can validate/
<pitti> ?
<rickspencer3> is the last image sufficiently tested to release that one today?
<pitti> for the regressions, we should re-exercise all the standard tests on MBR partitions
<pitti> rickspencer3: no, we are just starting with that
<jibel> rickspencer3, I'll retest the partitioner for every case excepted the GPT bug that Chad will do.
<rickspencer3> maybe we should get some macs in the testing lab?
<pitti> I now tested "full disk" and manual, I'll do an autoresize test on amd64/desktop now
<pitti> argh, I don't get autoresize offered, presumably my image is too small
<jibel> LVM is good
 * pitti gets a bigger one, and will test the amd64 DVD one for the first install
<pitti> jibel: does it help at all if I do some desktop/DVD tests, or do you do them anyway with some scriptery?
<pitti> well, if for nothing else it'll help me being more confident in the respin :)
<jibel> pitti, I'll do it. I'm currently running, alternate default install, resize on amd64/i386 , I'll start desktop as well in a minute.
<pitti> jibel: I mean, I'm already at it, just wondering if that will help you at all
<jibel> pitti, the more eyes the better.
<pitti> ubuntu DVD amd64 live and install went fine
<pitti> starting ubuntu desktop autoresize test
<cjwatson> jibel: I'm sceptical that it's worthwhile doing another faked-architecture test; I know that part works, what I need to have verified is that it actually works on a real Mac
<cjwatson> Chad said he'd be around on CEST to give it a go
<cjwatson> (I checked that last night before uploading)
<pitti> good morning cj "hero" watson
<cjwatson> rickspencer3: I initially thought >2TB disks could be affected, but once I narrowed down the bug it was clear that it was localised to Macs (with any size of disk, although depending on the prior partitioning arrangements)
<rickspencer3> hi cjwatson
<rickspencer3> ok, that makes sense
<rickspencer3> I asked pgraner about maybe getting some Macs for the testing lab
<pitti> cjwatson: the pad currently says to not publish amd64+mac; is that obsolete now that the gpt fix is in? i. e. should move from "new" to "pending testing"?
<pitti> s/from "new"/from "no"/
<cjwatson> IMO yes
<pitti> that's what I thought, too; doing
<cjwatson> oh, must get back to the xorriso guy about the work needed to make the need for a separate amd64+mac image GO THE HELL AWAY
<cjwatson> then people can stop being confused by it :)
<pitti> autoresize worked well on amd64 desktop
<jibel> ubuntu alternate, dvd and desktop ok on amd64 and i386. tested entire disk, autoresize, manual, encrypted lvm.
<jibel> now testing ltsp
<pitti> but it seems it's now being used for image publishing status as well
<infinity> Indeed.
<ogra_> pitti, apart from netboot omap3 all should be releasable
<pitti> anyway, it's just a release team tool, nothing like an official report
<pitti> ogra_: cool, thanks; I'll update it then
<ogra_> ubuntu-core is missing tests on the isotracker though
<pitti> ogra_: ah, want me to create core i386/amd64 test cases?
<pitti> (I'm not sure whether I'm able to, but I'll try)
<ogra_> well, untar, chroot, apt-get install <something> ... is the testcase
 * ogra_ can do that quickly 
<infinity> Which is missing some steps. ;)
<pitti> ogra_: I mean, do you want test cases for i386/amd64 core in the tracker?
<infinity> (like, have a valid resolv.conf)
<ogra_> infinity, your baby ^^^
<infinity> I'm not sure if I care that it's in the tracker, TBH, unless people want it there for paper trails.
<ogra_> well, are we supposed to do milestones ?
<infinity> I tested i386 and amd64 when I built them yesterday, for all that "testing" a minimal chroot is "making sure it contains binaries that don't all segv".
<ogra_> then it should live on the tracker
<infinity> Yeah, probably.
<infinity> Then I guess we need one or two silly/simple testcases.
<infinity> Honestly, if the image builds, it works.
<ogra_> pitti, add it then :)
<ogra_> infinity, agreed
<infinity> (Well, unless there's a hideous bug in some part of Essential, but then every image in the archive is broken)
<ogra_> well, by the looks of it, we might have actual -core images next release
<ogra_> they will  need bootability testing ...
<pitti> I guess http://testcases.qa.ubuntu.com/Install/ARM/Core will work for i386/amd64 as well
<ogra_> sure
<ogra_> hmm, tobin actually tested it, why doesnt it show as done on the front page
<infinity> The paths on that page are wrong.
<infinity> But otherwise, that works.
<pitti> hmm
<pitti> I added the two products
<pitti> and actually also added two test cases, but they don't appear
<pitti> hang on
<infinity> ogra_: I'm trying to fight having bootable core images, TBH.  But we'll see where that goes.  I imagine some lively discussion at UDS about it all.
<pitti> ah, now
<pitti> ogra_: added
<infinity> ogra_: Once they're bootable, they need an installer to set things up, once they have an installer, they need... You see the problem.
<infinity> Expectations go up when it's bootable, and bloat happens.
<ogra_> infinity, you got me fully on your side, but i think some upper level wants a proof of concept :)
<ogra_> (which would essentially be linaros nano image though, it actually is a minimal image with root login and some pre-configuration)
<infinity> Well, I could turn core into a bootable image on ARM with some reuse of linaro tools (which I think is the sane way to go), but I'd like to generalise those tools a bit more first, and make them not ARM specific.
<infinity> Then everyone can have their cake and eat it too.  And I'm not stuck generating "bootable rootfses" for the world, which is silly.
<infinity> Anyhow, not really release-related, so I'll go to bed and stop babbling in the wrong channel. :P
<ogra_> yeah, way to late for you anyway, go sleep :)
<astraljava> Hey guys, where should I talk about beta1 QA testing?
<pitti> astraljava: here, or in #ubuntu-testing
<astraljava> pitti: Okay, thanks. I'll go on here, then. alternate install doesn't have auto-resize option for partitioning, yet on our ISO QA tracker that's a mandatory testcase.
<pitti> astraljava: it's only offered if there is actually sufficient space available
<pitti> astraljava: I just tested it successfully two hours ago on the current ubuntu desktop amd64 image
<astraljava> pitti: So if I'm using vbox with a dedicated file as a hard drive partition?
<pitti> it worked for me with a 10 GB image, but not with 6 (that's too small for two installations)
<astraljava> Okay, thanks!
<cjwatson> yep, that's a conditional test
<cjwatson> or should be
<cjwatson> there are multiple reasons why you might not see it - insufficient space is just one of them
<cjwatson> bug 835961 looks fatal for the Lubuntu alternate images to me
<cjwatson> no gilir around though ...
<cjwatson> pitti: could you give me a TB second opinion on https://bugs.launchpad.net/ubuntu/+source/lubuntu-meta/+bug/835961/comments/12 ?  I'm tempted to Just Do It and respin, but I'd like a check
<pitti> I'm done with fixing grammar/spelling etc. on https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview, and updating it with noteworthy bugs from the ISO tracker
<pitti> cjwatson: looking
<pitti> cjwatson: fully agree, updated bug
<cjwatson> I think the roots of the libav* deps are gnome-mplayer and guvcview
<pitti> cjwatson: curious that the lubuntu desktop squashfs built; shouldn't it have the same problem, or don't we have a blacklist there?
<cjwatson> they're recommends, so it's possible there's a bit of nondeterminism
<pitti> ah
<cjwatson> and yes, no blacklist for the squashfs anyway
<pitti> http://cdimage.ubuntu.com/lubuntu/daily/current/report.html doesn't show lubuntu-desktop as being uninstallable, just some extra packages
<cjwatson> the blacklist is done at the ship-live level ...
<pitti> ah
<cjwatson> it's not ideal
<pitti> right, it's in the desktop squashfs
<pitti> so we already ship the lubuntu desktop images with it; might as well do the alternates, too
<cjwatson> committed
<pitti> are you doing the rebuild, or want me to?
<cjwatson> I will
<cjwatson> running now
<cjwatson> (pad updated)
<ScottL> slangasek, ack'd ty
<cjwatson> is that kubuntu-meta upload needed for b1?
<ScottK> cjwatson: No.
<ScottK> Any idea what's happening at Installing system 64%?  Seems like I'm stuck there.
<ScottK> Nevermind
<ScottK> Asking seems to have fixed it.
<ScottK> Looking good here. bbiab.
<charlie-tca> Away
<charlie-tca> good morning
<pitti> hey charlie-tca
<pitti> http://cdimage.ubuntu.com/lubuntu/daily/20110901/report.html is empty now, yay
<pitti> (looked at cdimage, not mirrored yet)
 * pitti posts that image
<pitti> cjwatson: ^
<charlie-tca> pitti: Starting those tests on the new image. I will get back to you
<pitti> charlie-tca: yay
<cjwatson> ah, thanks, sorry I missed it
<pitti> cjwatson: you didn't, it just finished (I followed it on cdimage)
<pitti> for some reason the lubuntu one took very long
<ScottK> Still testing Kubuntu images, but so far, so good, so I don't anticipate any problems with pre-publishing.
<pitti> ScottK: I already did that (faster rsync if we need to do it again)
<ScottK> OK.  Great.
<stgraber> morning
<pitti> hey stgraber, good morning
<jibel> morning stgraber
<stgraber> ok, finally testing Edubuntu. Should have both of them entirely tested in the next two hours
<charlie-tca> pitti: I will accept the images dated today. I have tried to them, ran an install off each one, and they are working
<charlie-tca> pitti: let's publish them
<pitti> charlie-tca: nice, thanks!
<pitti> charlie-tca: added to the tracker; can you please mark the tests you just ran?
<charlie-tca> sure
<stgraber> would be great if someone could review that UIFe, bug 838829
<skaet> good afternoon pitti, cjwatson
<stgraber> hmm, something seems wrong with the bot: https://bugs.launchpad.net/ubuntu/+source/edubuntu-artwork/+bug/838829
<stgraber> updated that UI freeze exception to target unity-2d instead of edubuntu-artwork as it's been suggested we should fix it there
<pitti> hey skaet
<skaet> heya pitti
<skaet> looks like things are settling into the groove for a release,  mostly. ;)
<pitti> yeah
<skaet> nice work.  :)
<pitti> skaet: at this point I'm confident in all images except for lubuntu alternate
<skaet> any updates on lubuntu images
<skaet> lol
<pitti> skaet: it was rebuilt a few hours ago and now everything should be installable
<pitti> but we haven't gotten any test yet
<skaet> anyone spot gilir around?
<skaet> or is there another member of the lubuntu community we can contact?
<pitti> downloading lubuntu alternate amd64
<pitti> I'll give it a whirl
<skaet> thanks pitti
<pitti> skaet: are you ok with me publishing the other images already, or do you still want to wait a bit?
<skaet> I'll go start off a round of release notes scrubbing
<skaet> pitti,  lets wait a bit for some of the north american testing results to trickle in.
<skaet> when do you plan on EODing?
 * skaet assuming no crisis pops up, of course ;) 
<jibel> pitti, skaet I'm testing lubuntu alternate i386|amd64 entire disk and resize
<pitti> ah, as always jibel is ahead of me :)
<pitti> skaet: if all goes well, in about two hours
 * stgraber is filing a bunch of Chinese specific bugs... has been a while since I last tried it
<pitti> skaet: I gave the TechOverview a review and did a couple of bug additions and language fixes
<pitti> skaet: I think the "known issues" is reasonably complete now; I left out the tracker bugs for the crashes (apport/duping/bug patterns will handle those) and the ones which break images which we won't publish
<pitti> skaet: btw, I updated the pad so that we'll publish amd64+mac and omap images
<skaet> pitti, yup saw that ogra blessed them.   Some of those bugs look painful though, but its a limited audience, so ...
<pitti> skaet: I'd like to update the tracker to disable the images that we won't publish (like omap/netboot), and retire the section in the pad
<pitti> skaet: as publish-image-set will read it from the tracker
<pitti> and it seems fairly redundant in the pad anyway
<pitti> ok?
<pitti> (netboot in particular isn't published anyway, of course)
<pitti> but e. g. kubuntu desktop amd64+mac
<pitti> and kubuntu mobile
<ScottK> pitti: I thought we were doing the +mac images now that the GPT bug is fixed?
<pitti>     amd64+mac      NO per ScottK IRC
<ScottK> (and it does have some testing)
<pitti> ScottK: fine with me
<ScottK> Thanks.
<ScottK> My mistake.
<pitti> ScottK: we'll still skip mobile and powerpc, right?
<pitti> ScottK: np
<ScottK> Yes
<ScottK> And omap.
<pitti> right
<pitti> ScottK: tracker doesn't have kubuntu omap4 either
<pitti> but IIRC that failed as well due to libo (whatever pulled that in)
<skaet> pitti,  go ahead with the disables
<pitti> so, netboot armel disabled, the rest should be released
 * skaet goes off to do a review
<pitti> skaet: ok, tracker updated and is consistent now, pad cleaned up
<skaet> pitti:  :D  Thank you!
<pitti> this isn't supposed to grow to a large form anyway, just for temporary scribbling like rebuild triggers
<skaet> pitti,  it was a good idea though for communicating and summarizing with IRC.   I just added release images, since there was so much flux, and being able to get the expectations clear as to what was still needed was useful.
<pitti> yep, that was fine
 * skaet likes the historical playback too.  ;)
<pitti> skaet: when do you think we can unfreeze? from my POV as soon as lubuntu alternate got tested?
<skaet> pitti,  agreed.
<pitti> skaet: there's a few high-profile bug fixes there, like ubiquitous unity-2d crashes, or jockey crash (failing to install nvidia), etc.
<skaet> pitti,  yeah, getting them in will be good.
<stgraber> yeah, the unity-2d ones are a bit annoying :) it's respawning fine but I get apport everytime I open a session post-install...
<jibel> lubuntu alternate looks good. it installs, boots, user can login and install updates. tested entire disk, resize, encrypted lvm on amd64 and i386
<skaet> jibel,  excellent!   Thank you.
<stgraber> I should have Edubuntu amd64 tested in the next 10 minutes
<skaet> ok pitti,  lets wait for stgraber, then open it.
<pitti> jibel: yay
<pitti> skaet: roger
<skaet> :)
<pitti> skaet: then I'll start the publishing exercise, that'll also take me some 30 to 60 minutes to triple-check all the header html etc.
<skaet> pitti,  sounds good. :)
<skaet> Daviey,  Server section of the release notes is looking a little sparse,  you've got lots of neat stuff with this release.  Can you add something?
<ScottK> Is OK if I start slowly accepting seeded packages from the queue?  The sooner we start, the less chance of a late Friday surprise.
<skaet> ScottK, can you take a pass at the Kubuntu part of the release notes?    Would like to get that wrapped.
<ScottK> Sure.
<slangasek> stgraber: how's Edubuntu amd64 looking?
<skaet> Thanks!
<stgraber> slangasek: testing ltsp now, should be done in a minute or so. Just spent a bit of time debugging the UI (for some reason I decided to try a Chinese install...)
<stgraber> and so got into bug 771510 breaking everything :)
<ScottK> skaet: Where am I looking?
<stgraber> pitti, skaet, slangasek: Ok, Edubuntu amd64 works fine.
<slangasek> ScottK: https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview
<ScottK> slangasek: Thanks.
<pitti> stgraber: yay
<skaet> https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview
 * skaet is just too slow typing today it seems ;)
<pitti> skaet: ok, I think it's time to open the floodgates and time for pushing some bits out to the web :)
<skaet> pitti,  make it so. :)
 * pitti pushes the buttons
 * skaet applauds (and holds breath),  then crosses fingers.   ;)
<infinity> \o/
<ScottK> Done.
<skaet> Thanks ScottK
<stgraber> I guess we'll need to test Chinese installs a bit more often in the future ;) my final release test list for Edubuntu usually is English, French (for translation), German (also for translation), Chinese (to test ibus), Arabic (to test right-to-left) and Greek (quite a lot of Edubuntu users)
<skaet> slangasek, I think we need to put something in about the new DVDs in the release notes.   Any opinions on where is best?
<pitti> skaet: bug 771510
<pitti> that affects all desktop/DVD images at least; not sure about alternate
<pitti> workaround is to install in English and use language-selector afterwards, or edit /etc/default/locale
<pitti> so, release-note-y
<skaet> pitti,  yup, at this stage release-note-y
<micahg> I take it it's ok to do a security sync at this point?
<pitti> beware of some queuebot flood
<pitti> micahg: yes
<micahg> pitti: thanks
<slangasek> skaet: I'd be inclined to put it at the very top of new features - unless it fits under Ubuntu Desktop, in which case I would at least call it out with a subheading?
<skaet> slangasek,   thanks.
 * skaet sees the floodgates opened.
<nigelb> woah.
<NCommander> skaet: eeek
<nigelb> I thought there was some spam in here.
<pitti> prepare for even more oneiric goodness
<skaet> NCommander,  when did you ping last night?   didn't see it.
<cjwatson> trying another ubuntu-defaults-image build
<NCommander> skaet: I sent you a PM asking if you what you wanted to do with omap3 images.
<NCommander> er,omap3 netboot
<skaet> NCommander,  not seeing it in my logs, and was worried about them.    Best to use #u-release channel at this time in the cycle.
<skaet> :)
<NCommander> oops
<skaet> NCommander, do you want any changes to the images we're publishing?
 * skaet we can still pull them from the publishing and site.
<pitti> I'm not actually sure how to "publish" netboot
<NCommander> ^- GrueMaster - your call
<pitti> it's not an iso or so, I think that requires some different magic
<cjwatson> manual HTML, I'll do it
<GrueMaster> I would recommend publishing it with notes.  I have had people ping me in other channels for it (and even email through LP).
<skaet> GrueMaster,  do we need to add more cautions into the overview,  as well as the individual bugs you've noted already?
<GrueMaster> I added something last night to the link you gave me.  I'll review it after our IRC meeting.
<GrueMaster> I also will go through the bugs and document workarounds.
<skaet> Thanks GrueMaster,  sounds good.
<cjwatson> pitti: done, though the links won't work until after the next publisher run
<pitti> thanks
<slangasek> anyone here know what's going on with ubuntuone-couch?  shows up for demotion on components-mismatches, and is also dep-wait on python-mocker - is this an MIR in progress with a dep that got missed, or a deliberate demotion?
<pitti> slangasek: it might be related to ubuntuone using ubuntuone-installer now, instead of shipping them by default
<pitti> but these shuold be in main anyway, I think
<pitti> nessita/dobey probably know better, though
<slangasek> oh, actually only dep-wait in the rebuild archive; in the real archive it's built, but python-mocker is still in universe
<slangasek> what's going on with libreoffice on powerpc?  Is someone working on that, or should I kill-thread the livefs build failure mails? :)
<pitti> slangasek: a new libo was just accepted from unapproved which ought to fix armel/ppc builds
<slangasek> ok
<pitti> cjwatson: hm, at least the failure mails have logs now -- that's progress?
<pitti> cjwatson: do we need more recommends for genisoimage and isohybrid?
<cjwatson> just added that
<cjwatson> yeah, I fixed the logging
<pitti> cjwatson: IS didn't take the part about fixing the mail subject?
<cjwatson> not sure, but I'm not too worried
<pitti> (it was part of the patch that you sent to the RT)
<cjwatson> maybe the new BuildLiveCD hadn't propagated out yet; it wasn't strictly needed to get past the immediate failure, only to improve things for the future
<doko> skaet, ok to give back the failed builds on all architectures? we never gave them back this release cycle
<pitti> doko: they won't build very fast, but sure
<skaet> pitti, cjwatson, slangasek,  ^^ am ok with starting it, as it won't hurt anyone ?
<cjwatson> yes
<skaet> thanks for your patience doko,  looks like its a go for it.
<GrueMaster> skaet: As soon as the Tech Overview wiki is released, I will edit the omap3 netboot info.
<skaet> Thanks GrueMaster,  Daviey ^^ please ping GrueMaster when you're done.
<pitti> skaet: *phew*, publishing done, pressed the big red "sync" button
<skaet> pitti.  Thank you.  :)
<skaet> cjwatson,  I thought there was an email announcing the DVD images - but can't seem to find it.   Do you have a pointer to an email/changelog I can cross check against?
<cjwatson> skaet: try the natty beta-2 announcement
<skaet> for DVD image content?
<cjwatson> oh, I misunderstood
<cjwatson> I thought you were looking for a format for announcing DVD images as part of a release announcement
<skaet> no,  looking for some content to put into the release notes and general announce. ;)
<skaet> I though there was something mailed out in the last month,  but after poking around for 15 minutes, and not finding, figured better to ask.
<cjwatson> so you mean for the new smaller DVD images
<skaet> yes
<cjwatson> I don't see anything other than the discussion on ubuntu-devel, which is not terribly helpful for this
<cjwatson> https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-great-cd-debate sort of
<skaet> Will use that then - just thought there was a summary already somewhere.
<skaet> Will post my draft for review then.
<pitti> whoops, TechOverview links to /natty
<cjwatson> I don't think so.  The exec summary is that the DVD images have been turned into extended desktop images with additional language support and a few extra applications, and thereby reduced to a more manageable size of around 1.5 GB
<pitti> no, ignore me
<cjwatson> (that's probably a more useful summary than anything you'll get out of the spec, since most of this was put together after UDS)
<pitti> smoser: can you please press the publish button for http://cloud-images.ubuntu.com/releases/oneiric/beta-1/ ?
<smoser> utlemming, ^ you want to handle ?
<astraljava> Ubuntu Studio homes in and tells all of their testcases are successfully done.
<skaet> astraljava, yay!  :)
<skaet> cjwatson, will keep it to that then.   Was wanting a bit more details of the applications, but we can do that in the formal release notes.
<skaet> by formal release notes - I mean the 11.10 release - final set. ;)
<cjwatson> the current list is inkscape, gimp, pitivi, and a more complete LibreOffice suite
<cjwatson> you can look at the usb seed if you want full details
<GrueMaster> skaet: Done editing the tech overview.  I also added a note on there about the older Panda ES2.0 (prerelease) boards.
<skaet> Thanks cjwatson.
<skaet> Thanks GrueMaster
<ogra_> skaet, to be honest, looking at the tech overview, i dont really have anything for the release notes this time, most of the team fought with image buildability or general bugs, there are no actual highlights on image content this time
<skaet> ogra_,  ok.  Thanks for the follow up.
<ogra_> and the line under ubuntu arm is info from last alpha
<ogra_> that should go (preinstalled-pool)
<skaet> ogra_, delete away.
<ogra_> k
<pitti> skaet, cjwatson: hm: TechOverview says it should be http://releases.ubuntu.com/kubuntu/oneiric/beta-1
<pitti> while reality is http://releases.ubuntu.com/kubuntu/oneiric/
<pitti> i. e. without the /beta-1
<pitti> which one is right?
<pitti> I think it's cdimage, and we should fix TechOverview
<pitti> but making triple sure
<pitti> http://releases.ubuntu.com/kubuntu/natty/ also exists, no /final or so
<skaet> pitti appreeciate it.
<skaet> ScottK,  ^^ can you confirm it should be: http://releases.ubuntu.com/kubuntu/oneiric/
<pitti> skaet: same for ubuntu
<GrueMaster> skaet: I noticed Kubuntu Arm on the Tech Overview.  Did it even get tested?  I didn't see an entry on the iso tracker.
<cjwatson> pitti: reality is correct
<cjwatson> skaet,ScottK: ^-
<skaet> GrueMaster,  delete it.   It didn't get tested.
<cjwatson> the /beta-1 suffix is only for cdimage.u.c
<pitti> cjwatson: ok, thanks for confirming
<pitti> skaet: TechOver fixed
<pitti> skaet: fixed harder for netboot
<GrueMaster> Hmm.  It's gone now.  Was there yesterday iirc.
<skaet> Thanks pitti!
<pitti> skaet: ok, seems to be mostly right now; now we need an hour of patience until stuff gets mirrored
<pitti> (or two)
 * pitti has some dinner in the meantime
<skaet> pitti,  enjoy your dinner.
 * cjwatson -> dinner
<skaet> cjwatson, enjoy yours as well.
 * skaet --> lunch,  be offline for a bit, then back. 
<ScottK> skaet: I'm sure whatever pitti says is right.
<ScottK> GrueMaster: If you didn't get a chance to test Kubuntu arm, then I know it didn't get tested.
<GrueMaster> ScottK: My time this cycle is overloaded with server testing.  I honestly didn't get as much time testing the ubuntu desktop images that I would have liked.
<GrueMaster> But I noticed the kubuntu arem images weren't even on the tracker this time.
<ScottK> Sure. Not being critical, just saying if it'd been tested, you'd know.
<ScottK> Not sure why that was.
<utlemming> cloud-images are published, however with the addition of the armel images the scripts didn't populate them to them to http://uec-images.ubuntu.com/releases/oneiric/beta-1/
<GrueMaster> I thought it was a Kubuntu decision and as overloaded as I am, didn't say anything.  Sorry about that.
<skaet> ScottK, since it was about where Kubuntu was pointing to, figured you should be aware. ;)
<ScottK> Thanks.
<pitti> a stack of pancakes later..
<ScottK> Would someone please look at https://wiki.kubuntu.org/OneiricOcelot/Beta1/Kubuntu and verify I described the download locations correctly?
<pitti> skaet: all download links in the release announcement confirmed to work, cdimage mirroring complete
<pitti> skaet: I also did a random sample on https://launchpad.net/ubuntu/+cdmirrors and it seems more than half of the mirrors have beta-1
<skaet> pitti, excellent.  :)  just putting up a draft of the Upgrade instructions on community page.   Can you take a pass to check it?
<pitti> skaet: so we now need IS to run the mirror prober, and get it online
<pitti> ScottK: looks good to me
<ScottK> pitti: Thanks.
<skaet> https://help.ubuntu.com/community/OneiricUpgrades
<pitti> skaet: http://www.ubuntu.com/getubuntu/releasenotes/1110 link doesn't work yet, I guess that's expected?
<skaet> pitti,  try now
<skaet> sorry
<skaet> yeah
<pitti> no, I get to http://www.ubuntu.com/
<skaet> that won't work until web team makes it live.
<pitti> skaet: "Upgrade from 11.10 to 11.04" that would be backwards :)
<skaet> heh,  see why I wanted someone to check ;)
<pitti> skaet: "Open the Update Manager application from the System â Administration menu." that doesn't actually exist any more in unity
<pitti> that would be something like Windows key + "update"
<skaet> ack.
<skaet> :)
<pitti> skaet: I don't think these instructions will work for beta releases
<pitti> you need update-manager -d
<pitti> as in our Tech Notes
<pitti> these instructions are valid for the final release
<ScottK> Yep.
<ScottK> Kubuntu section needs the same change.
<skaet> pitti, yes you're right.
<pitti> "Download the alternate installation CD from http://releases.ubuntu.com/natty/"
<pitti> in the Upgrading Using the Alternate CD/DVD section
 * skaet did a fast clone from natty and should have spent more time on it before asking.  :/
<pitti> heh, np -- perhaps just grep for "atty"?
<pitti> skaet: seems it's the only one
<skaet> there's always one.  ;)
<pitti> "Just visit http://releases.ubuntu.com/11.04/," in the torrent section
<skaet> yeah, that needs to be matching the announce now.
<ScottK> Can I edit now?
<skaet> ScottK,  if pitti's not in,  go ahead.
<pitti> I'm not editing any page
<pitti> skaet: btw, release meeting tomorrow, or do we skip it?
<skaet> pitti,  skip it.   I'll send out the cancellation later.
<charlie-tca> oh, thank you
 * skaet needs to sleep tonight, not work on agendas.   
<pitti> can't say I'm overly disappointed :)
<skaet> and its been a long, long week for the entire team... and everyones efforts and patience is VERY much appreciated!
<ScottK> Kubuntu fixed.
<skaet> Thanks ScottK
<ScottK> Just got another amd64+mac install success story.
<pitti> good night everyone!
<skaet> good night pitti!  sleep well and thank you!!
<stgraber> pitti: bye!
<elmo> is unity known to be broken for upgrades from 11.04 right now or am I just special?
<highvoltage> the two concepts aren't mutually exclusive.
<skaet> elmo, there are a couple of known bugs still. :( seeing a crash or something more subtle?
<elmo> highvoltage:  well played
<elmo> skaet: no, I mean, as in, unity appears to be causing upgrade-manager -d to break
<skaet> classic
<elmo> skaet: but, actually it looks more like it's a combination of a stupid transparent proxy setup by incompetent sysadmins  and archive.ubuntu.com de-sync problems
<elmo> the latter at least is fixed - I guess I'll go and look at the former
<skaet> elmo,  thanks.   Let us know if it persists.
 * skaet crosses fingers
 * Daviey checks in
<elmo> nope, it really is broken for me - is anywhere other than mvo good at decoding update-manager apt spew?
<slangasek> I could have a peek
<Daviey> elmo: If it's spew, it sounds at the very least a usability bug.. raise it with the log.. the worst that will happen is that it'll be Invalid. :)
<elmo> I also notice update-manager is leaking private ppa passwords
<ScottK> So the log in a bug would be double plus good.
<slangasek> in bug reports, or where?
<elmo> slangasek: /var/log/dist-upgrade is 755
<elmo> http://paste.ubuntu.com/680120/
<slangasek> oh, and private ppa configs are 0600?
<elmo> yeah
<elmo> and the password is included in the log spew
<elmo> I'll file a bug about it
<skaet> elmo, yes please.
<slangasek> i386 or amd64 system?
<elmo> slangasek: i386
<slangasek> ok
<slangasek> well, step 1, gvfs shouldn't be using Conflicts on libgvfscommon0
<slangasek> but that one it solves
<Daviey> "Broken unity-2d-panel:i386 Depends on libunity-2d-private0" .. I assume that is a non-archive package?
<Daviey> I suck, forget that
<elmo> http://paste.ubuntu.com/680123/
<slangasek> Broken libindicator6:i386 Breaks on libindicator3 [ i386 ] < 0.3.22-0ubuntu1 -> 0.3.22-0ubuntu2 > ( universe/libs ) (<= 0.3.93-0ubuntu1)
<elmo> I have some non-archive packages installed, but nothing to do with unity, I don't think
<slangasek>   Considering libindicator3:i386 10 as a solution to libindicator6:i386 5
<slangasek>   Holding Back libindicator6:i386 rather than change libindicator3:i386
<slangasek> that's not good
<slangasek> libindicator6 should drop the Breaks: libindicator[123], there are no file overlaps
<elmo> slangasek: shall I file those two as bugs?
<slangasek> elmo: yes please
<slangasek> hmm, I see some at-spi noise in here still
<elmo> slangasek: a bug against update-manager too for giggles?
<ScottK> "Update-manager should make it work anyway"
<slangasek> elmo: for the log perms?
<slangasek> no, it's not update-manager's job to predict wrong package relationship declarations in advance
<slangasek> only to fix them up as a last resort, and we have a better resort here
<elmo> no no
<elmo> I didn't mean it should be magic
<elmo> I meant in case mvo wanted to see if there was any other stuff in there of interest
<elmo> the logs is #839094, I'll go file the other 2
<slangasek> well, I'm confident that libindicator6 is the root of all the problems, but feel free to disbelieve me :)
<slangasek> and as that's a quick'n'easy fix, once the bug is filed I'll shoot off an upload
<elmo> slangasek: #839098 is libindicator bug
<elmo> and #839101 is the gvfs one
<elmo> slangasek: thanks a lot
<slangasek> elmo: thanks for the report!
<skaet> +1
<skaet> slangasek,  I need a one liner about multiarch for the announce email.
 * skaet figures we should say something there.
<ScottK> Works more better and ia32-libs is shrinking.
<slangasek> man
<slangasek> you're talking to the guy who can't fit sentences on twitter
<skaet> Multiarch is now the default. ??
<skaet> just some sort of flag, is the hope.
<slangasek> maybe it's best to avoid the jargon term "Multiarch" in the announcement?
<slangasek> Ubuntu 11.10 Beta 1 enables support for installing 32-bit library and application packages on 64-bit systems.
<slangasek> that's the first line of what I put in the tech overview, maybe that works?
<skaet> slangasek, yeah that works.  :)
<skaet> thanks
<slangasek> n/p :)
<slangasek> libindicator uploaded
* skaet changed the topic of #ubuntu-release to: 11.10-beta1 released!  | http://pad.ubuntu-uk.org/ubuntu-release | Oneiric Ocelot Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team with beer | we accept payment in cash, check or ocelot food | melior malum quod cognoscis
<Laney> hoorah
<skaet> Thanks everyone for your help getting this one out!!  :)
<Daviey> Is it too late for a respin?
<charlie-tca> I would say thank you to everyone too. This one was not easy to get done!
<slangasek> Daviey: you're free to spin :)
<Daviey> heh
<ScottK> skaet: Shouldn't it be ocelot pelts?
<skaet> ScottK,  ocelots are endangered, we want to feed them, not skin 'em ;)
<ScottK> But are they tasty?
<ScottK> I guess I'm unlikely to find out.
<skaet> lol.  true.  :)
<charlie-tca> um, not to put a damper on things, but server images are missing from http://releases.ubuntu.com/oneiric/
<Daviey> charlie-tca: well spotted
<skaet> charlie-tca, Daviey - investigating...
<jibel> and wubi.exe
<robbiew> Daviey, you're fired
<jibel> charlie-tca, that's because Daviey is waiting for a respin
<Daviey> robbiew: good stuff.
<skaet> slangasek, can you help here.
<charlie-tca> Thank you, jibel
<charlie-tca> That is a good reason
<Daviey> (no, i'm not)
<jibel> j/k
<robbiew> lol
<robbiew> utlemming: you shut down your test instances, right?
<robbiew> lol
<utlemming> robbiew: why would I want to do that? I was hoping to break my high score
<robbiew> heh
<Daviey> robbiew: He has a cronjob to do it just in case :)
<utlemming> yes, yes, I do
<Daviey> considering the filenames are consistent, doing a crawl and HEAD requests prior to anouncement might be good.
<sladen> hello all.  Late drop wallpaper time
<sladen> bug #833990 (default wallpaper, slightly tweak from previous version that shouldn't affect documentation or screenshots) + bug #829213 (community wallpapers;  not set by default, only potentially visible in screenshots of Apperance control panel, where they are interchangable with any other selection)
<Daviey> sladen: Yeah, Yeah, we've done the last minute fix gag already
<sladen> Daviey: one has to be seen to do *something* ;-)
<skaet> sladen,  ok,  if its not affecting the documentation and screenshots means we should be fine.   Thanks for explaining.
<slangasek> skaet: help with what?  disrespectful engineers? :)
<skaet> slangasek,  we haven't published the server images.
<slangasek> ah
<slangasek> yes, I can help with that :)
<skaet> Thank you!  I'm needing sleep, and would probably make things worse if I started in at it. :P
<robbiew> eh...it's just server...who runs that anyway
<skaet> lol
<slangasek> skaet: is 20110901 the correct image to publish?  Because the ISO tracker (and therefore publish-image-set) says 20110830 is what was tested
<slangasek> and that one went away due to the image rotation policy when 20110901 was spun
<skaet> slangasek,  publish 20110830,  that was the one tested.
<slangasek> yeah, can't do that :/
<slangasek> 20110901 probably shouldn't have been spun if we intended 20110830 to be published, since it's spinning the new image that expires the older ones...
<skaet> The images are still on the iso tester though.
<slangasek> the iso tester doesn't know what's actually on the server
 * skaet lives and learns
<slangasek> it just believes whatever people tell it about the versions
<slangasek> so is there a way to get 20110901 tested quickly?
<skaet> Daviey, robbiew - any options here.
<skaet> ?
<Daviey> 20110830 is gone?
<Daviey> gah
<Daviey> why is only one being kept?
<slangasek> it's two that are kept
<slangasek> rather, two days worth
<Daviey> I can only see one on cdimage
<robbiew> does hggdh have a version lying around
<robbiew>  or in jenkins?
<slangasek> yes, because there was no run on 20110831
<skaet> what about on the auto testers?
<hggdh> robbiew: version of what?
<robbiew> server beta iso
<robbiew> 20110830
<Daviey> The known issues, other than EFI are not resolved.
<slangasek> I'm somewhat uncomfortable with the idea of reconstituting the images from elsewhere unless you can show me the SHA256SUMS.gpg to go with it
<hggdh> robbiew: just checked, it has already been updated to today's image, sorry
<Daviey> So at automated test run would be 'ok' to release with, plus a manual smoke test IMO.  However, that will not complete quickly.
<hggdh> and not on Jenkins either, we only keep the current version there
<slangasek> how long?
<Daviey> hggdh: Do you know how long a test run takes?
<Daviey> the jenkins tests
<hggdh> on Jenkins? ~ 30 minutes
<hggdh> want one?
<skaet> yes please
<Daviey> hggdh: all images, or just 1?
<slangasek> we're only releasing amd64 and i386, right?
<hggdh> Daviey: right now we fire off all tests
<slangasek> So max 2 images
<robbiew> right
<Daviey> sorry, s/images/testcases
<slangasek> (I see there's also an amd64+mac server, is that used?)
<slangasek> should I bump to 20110901 on iso.qa, then?
<skaet> slangasek, no.
<hggdh> Daviey: jenkins run started
<slangasek> skaet: no to the first or second question?
<skaet> only ones we care about right now and publish... amd64 and i386
<Daviey> slangasek: Yes please.
<slangasek> ack
<Daviey> hggdh: thanks.
<robbiew> we don't care about amd64+mac server
<skaet> sorry slangasek,  typing IRC speed again.
<robbiew> I mean, I "care"...but you know
<Daviey> hggdh: Are you able to smoke a manual test to gain confidence aswell?
<hggdh> Daviey: yeah. Now if this is about today's image, already did it ;-)
<Daviey> slangasek: So we 'lost' the final release candidate last cycle for the cloud images, due to the same issue last cycle... causing much stress,
<Daviey> I think when we have a declared candidate, for milestones/releases.. the images need to chowned/chmodded to stop the cleanup removing them without manual intervention.
<hggdh> Daviey: I will smoke-test i386; AMD64 was smoke-tested earlier on today
<Daviey> Losing the candidates is suck.
<Daviey> hggdh: you are my hero.
<skaet> slangasek, Daviey - yeah we need some redundancy here.    Not sure what the solution is, but when something goes on the tracker, getting it shadowed somewhere seems logical to me.
<slangasek> logical but difficult to implement
<Daviey> slangasek: What will happen if the cleanup doesn't have access to rm them?
<slangasek> because the iso tracker and cdimage.u.c don't actually know anything about each other
<slangasek> Daviey: er, I don't actually see any way to block the access to rm them.  I would much rather we have a command that sets antimony into "Milestone mode", disabling the automatic cleanup and the cronjob at once
<Daviey> slangasek: Yes, i don't care about automating it, but a human removing permission on cdimage for the cleanup script to rm them?
<skaet> Lets talk about this with jibel tomorrow, and see if he has some ideas how we can clone them somewhere when they're loaded to the iso tracker - that may be the angle to tackle it from.   Not sure.
<Daviey> slangasek: ah ok.
<slangasek> Daviey: there are no accounts having write access to the directories in question other than the account doing the actual removal
<slangasek> so it's hard to set perms such that an rm will fail :)
<Daviey> slangasek: Yeah, if only it were possible to add more users to servers. :)
<Daviey> But yes, i agree your implementation is better.
<slangasek> posted to the tracker
<skaet> thanks slangasek
<Daviey> This should mean that EFI issue can be un-release-noted.
<hggdh> of the 24 Jenkins tests, 20 have already finished successfully
<hggdh> er, 21 have finished
<hggdh> Daviey: i386 smoke test successful; Jenkins run successful
<slangasek> jenkins run for both archs?
<hggdh> slangasek: yes. Two failures noted on AMD64, but these are caused by a local issue; I am hand-running these two now
<hggdh> slangasek: I updated the tracker with the Jenkins runs
<Daviey> I am also running a smoke on amd64.
<Daviey> hggdh: thanks!
 * skaet --> needs to shift location.   biab.
<hggdh> slangasek: I very much doubt I will be able to run *all* tests in a timely manner, though
<Daviey> hggdh: suitable confidence is enough i think.
<hggdh> Daviey: then I guess we have it, 13/16 tests run for each AMD64 and i386
<slangasek> are the other test cases not automated yet?
<slangasek> Daviey: you're happy for me to publish then?
<Daviey> slangasek: 4 more mins pls
<hggdh> slangasek: they are indeed not automated -- they require user intervention (encrypted LVM, RAID1) or resources I do not have access to (ESX)
<hggdh> for the user intervention we may be able to address very soon, though
<Daviey> slangasek: I am happy.. FIRE!
<Daviey> hggdh: does anyone actually test ESX?.. it seems to be skipped every milestone.
<hggdh> we had someone to test it before -- but I myself do not have access to a VMWare ESX. I *think* Canonical has it installed, but IDK the details
<Daviey> hggdh: we should probably get to the bottom of that before b2.
<hggdh> Daviey: certainly
<hggdh> pfui! We may die of a lot of different things, but boredom will not be it ;-)
<Daviey> :)
 * skaet sees edit is done on the WIKI - thanks Daviey.
<Daviey> np
<Daviey> slangasek: Did you publish it?
<elmo>   
<slangasek> Daviey: done
<Daviey> slangasek: thanks!
<skaet> Thanks slangasek!!
<skaet> Thanks Daviey, hggdh!
<hggdh> skaet: my pleasure
 * Daviey heads to bed. Thanks.
<skaet> crontab edited.  (have left server commented)
#ubuntu-release 2011-09-02
<skaet> Server images have shown up on http://releases.ubuntu.com/oneiric/,   mirrors will pick it up through the evening.
<skaet> Release team meeting for 9/2 cancelled.  Note sent out.
 * skaet figures its time to consider it EOD.  good night all.
<micahg> night skaet, thanks for another great milestone  release
<skaet> thanks micahg!
#ubuntu-release 2011-09-04
<micahg> does adding of build hardening require an FFe?
#ubuntu-release 2012-08-27
<babyface> why no quantal desktop iso built on Aug 26?  I checked the build log, and now it's "Reading state information...", what's wrong with the build server?
<ogra_> hmm. we are still building precise dailies ... is that wanted ?
<seb128> can I get https://bugs.launchpad.net/ubuntu/+source/indicator-messages/+bug/1040259 review,approved?
<ubot2`> Ubuntu bug 1040259 in thunderbird "FFE: libmessaging-menu transitions for quantal" [High,Fix committed]
<seb128> hum
<seb128> no reply on friday, nobody around today ... I wonder if I should just upload ;-)
<Laney> seb128: You say it's being tested â I assume the results are good?
<seb128> Laney, no, it doesn't start and will destroy your desktop :p
<Laney> well, the bug doesn't say :P
<seb128> Laney, joke aside, it's in the desktop team ppa and ken, lars, chris, I and probably some others are running it
<Laney> will you stage in proposed?
<seb128> it works fine with that set: empathy, thunderbird, xchat-gnome
<seb128> oh and gwibber
<seb128> so that covers default install and popular IRC client
<seb128> yes, I will stage in proposed
<Laney> and
<Laney> the old API is deprecated but still available?
<seb128> no
<seb128> well the indicator doesn't consume the old api
<seb128> so those will not show in the indicator
<Laney> hum
<Laney> so is there anything in the archive which will regress and isn't on the list to be fixed?
<seb128> no
<seb128> evolution-indicator is being worked by cyphermox
<seb128> we will port pidgin and liferea soon as well
<Laney> ok let's add tasks for those and milestone them and then i'll approve it
<seb128> Laney, done
<Laney> seb128: approved
<seb128> Laney, thanjs
<seb128> thanks
<Laney> np
<balloons> I marked the Ubuntu Desktop armhf+omap4 for rebuild.. several folks reported it was bad.. checking the image size, it's 22 mb.. yikes
<Laney> I think that buildd had problems
<Laney> ogra_: ?
<infinity> I think Oli's been fiddling with lamont.
<infinity> Though, a 22MB image is pretty awesome.
<ogra_> yeah, we can add so much new stuff now !
<balloons> +1!
<ogra_> i didnt really bother to do a rebuild given they will be rebuild anyway by cron, do you urgently need a respin ?
<balloons> ogra_, not urgently.. I marked it for rebuild so it wouldn't show up as valid on the list
<ogra_> ah, k
<balloons> aka, so I wouldn't have another person emailing me about not being able to get the image to work
<ogra_> i still have to get used to the fact that the isotracker isnt only used during milestones
<balloons> afaik, anytime there is an invalid image that's the best way to prevent others from stumbling over the bad image
<balloons> so.. please feel free to do it if you know the image is bad :-)
<ogra_> balloons, i'll try to remember that next time after getting out of panic and debugging mode ...
<balloons> thanks ogra_ :-)
<stgraber> skaet: sorry for the delay for the edubuntu-live work. I finally got it working as I wanted, so I'm doing some final testing and will have it uploaded in the next hour.
<skaet> stgraber,  ok.
<stgraber> (^ is a pre-approved FFe for edubuntu-live to include a dialog to install any needed langpack when starting the live environment)
<stgraber> skaet: edubuntu-live uploaded and that's it for my last minute feature changes, anything from now will come with a FFe request (not that I'm expecting anything at this point)
 * skaet nods
<jocarter> a benevolent nod from skaet!
<jocarter> (at least that's how I imagined it :p)
<knome> self-appointed too?
<skaet> :)
<stgraber> jocarter: if you have some hardware you can test Edubuntu on, please test tomorrow's build in non-english to see if my dialog shows up and does what it's supposed to
<stgraber> jocarter: I tested with alpha-3 as that's the last image I can get to work in kvm, but maybe some things changed after that
<knome> stgraber, that was probably the best testcase description i've ever read :)
<knome> i will have to write that down... "boot xubuntu and check if it does what it's supposed to"
<stgraber> knome: that's pretty much my usual testcase for anything in the archive ;)
<knome> heh :)
<stgraber> knome: for some reason, I'm assuming that the people who helped speccing the work for the next release probably can expand "does what it's supposed to do" without needing flow charts and screenshots
<knome> stgraber, depends... sometimes, i need to be reminded :)
<knome> stgraber, and flow charts are always nice!
<Laney> do you know if the kernel packageset is managed with a script?
<Laney> no, I don't think so
<knome> asking yourself, eh?
<Laney> I remembered where the script is and looked at it
<Laney> but now you also all get to share in this knowledge
<knome> :)
<Laney> knome: What's the xubuntu/studio plan for dealing with the gtk2 indicators problem?
<knome> Laney, unfortunately, we haven't have time to put up a good plan yet.
<knome> Laney, the last minute change wasn't really hoped for.
<Laney> hmm
<Laney> to be fair, it was announced on -devel
<knome> yeah, but not too early
<knome> i'm not judging anybody by it, but we simply haven't had time to think about that through yet
<knome> if you have an idea, please feel free to propose at #xubuntu-devel or our mailing list
<knome> cooperation doesn't hurt.
<knome> especially as we are really busy with the UIF
<ajmitch> is there something I'm missing that I need to do to get a package through NEW for quantal?
<seb128> ajmitch, you mean?
<ajmitch> unity-lens-help, it's been in the queue for almost 2 weeks
<seb128> ajmitch, lack of reviewers
<ajmitch> ok
<seb128> I looked quickly at it
<seb128> but it was non trivial for some reason and I delayed it and didn't have time to come back to it yet
 * ajmitch did a fix of the changelog after Laney spotted that I hadn't added any actual changes in the version uploaded
<Laney> trolling pays
<ajmitch> you're the master at it
<seb128> ajmitch, I rejected the old one to avoid confusion
<ajmitch> ok, thanks
<ajmitch> Laney: you should put your name forward for ~ubuntu-archive, it'd be fun
<slangasek> ?
<ajmitch> slangasek: don't worry :)
<Laney> I would be interested in that to be honest ;-)
<Laney> slangasek: He's complaining about NEW delays :-)
<slangasek> yes, this seems to me like a legitimate thing for him to do, so I don't understand the "it'd be fun" bit
<ajmitch> that's just me trying to convince him to do more work
<slangasek> ah, heh
 * ajmitch would offer to help out in some way if it'd be useful
<xnox> thanks stgraber, i know jocarter or somebody else did mention LTSP to me before, but you clearly know more details about it =)
<stgraber> xnox: np. It's essentially the one weird case where people install servers used my hundreds of users using the alternate media.
<xnox> s/my/by/
#ubuntu-release 2012-08-28
 * Laney respins the failed ubuntu dailies
<xnox> FFe process applies to unseeded/universe packages as well. True or False?
<Laney> yes
<knome> hi Laney
<Laney> hey knome
<knome> Laney, i'm sorry, i had a misunderstanding on the gtk2 indicator issue - i'm been told we knew about it well before
<knome> Laney, and now the answer for your question: we are going to reupload them; if you can help..
<knome> Laney, ..then please tell us you can. :)
<Laney> help in what way?
<Laney> I can't help you maintain them ...
<knome> help reuploading
<knome> of course not, but we still need to reupload them
<Laney> ah, well if you prepare a package then I can help on that side
<knome> we'll get it sorted
<Laney> you'll need FFe too.
<knome> yes, i hope those will be granted
<knome> mr_pouit is working on it with gilir from lubuntu
<davmor2> Hey guys there looks to be an issue with webcam detection on my laptop did a current install from yesterday and ubiquity fails on the webcam page.  This in turn nails the system I have to hard power switch it, reisub fails, ssh fails.  I'm going to see if it effects the installed system and see if I can get some debug info from there
<davmor2> yeap same issue running cheese it just kills the system completely
<davmor2> over the the kernel channel I guess and hopefully they can help
<phillw> is the quantal kernel in todays release, or do we need to await for a rebuild ( re: http://irclogs.ubuntu.com/2012/08/28/%23ubuntu-meeting.txt|IRC )
<slangasek> phillw: what do you mean by "in today's release"?  any quantal daily builds are using a quantal kernel.
<phillw> slangasek: the notes from http://irclogs.ubuntu.com/2012/08/28/%23ubuntu-meeting.txt
<phillw> was that updated Q kernel in for todays respins, or does it have to wait untill tomorrow?
<Laney> you can check the manifest files to find out exactly which packages are included
<phillw> Laney: do have a link handy, save me spending time on google when all I want to do is let the Qa teams know we have 'the final' kernel to be tested quickly before feature freeze lands on Thursday?
<bjf> phillw: if you are talking about 3.5.0-13.13 then it will probably be in tomorrows daily. that quantal kernel was only published 7 hrs. ago.
<phillw> bjf: thanks I'm referring to the part of the email http://pastebin.com/F8zYn4i6
<Laney> eg http://cdimage.ubuntu.com/daily-live/current/quantal-desktop-amd64.manifest
<phillw> It's always fun to the testers that they have 24 hours before a feature freeze for a kernel :P
<bjf> phillw: that's the kernel version i just mentioned
<phillw> no worries, I'll let them all know :)
<cyphermox> arf, I blindly uploaded indicator-sync 12.10.1-0ubuntu1; it's perhaps not so clear, but it's a bugfix release despite the API/ABI changes; nothing should be using it in the archive yet
<micahg> cyphermox: I'm sure you're aware that new binaries need an FFe
<seb128> micahg, do they?
<micahg> seb128: that's what I've been told
<seb128> micahg, where is it written?
<micahg> seb128: https://wiki.ubuntu.com/FeatureFreeze
<micahg> second section, second bullet
<micahg> that's ABI, not general though
<seb128> micahg, that's not about new binaries, but about abi changes
 * micahg thought this was fixed last cycle....
<seb128> micahg, that page has no new binary mention
<seb128> there is no "binary" match at all in fact
<micahg> well, if you want to get technical, the first line doesn't say source explicitly :)
 * micahg wishes a release person would come to his defense here :)
<seb128> well,I disagree that new binaries should require a ffe in a systematic way
<seb128> the documentation doesn't state it should
<seb128> so if that's a real rule it should be stated somewhere
<micahg> I would argue that it could have in impact on how other packages use this package in question
<seb128> we have been accepting some new -dbg recently without asking for a ffe
<micahg> *crickets*
<seb128> why would adding a dbg impact on other packages?
<micahg> seb128: that's a case where it wouldn't, but cases where you add a data/common package certainly could
<seb128> ok, so the rules is not about "new binaries", it's more specific ;-)
<micahg> well, some FFes you know will be approved, but you file them anyways, but I'll let someone from the release team verify what I've said before I go on with it
<slangasek> seb128: it has an impact on how the developers are spending time post-FF; uploading (and archive processing) of -dbg packages doesn't seem like very much focusing on bugfixes?
<slangasek> but I wouldn't reject a -dbg package I saw in the NEW queue during FF
<slangasek> because it wouldn't be worth arguing about
<seb128> right, that's basically my position as well...
<seb128> slangasek, well, I could argue that -dbg can be useful for debugging,bug fixing
<slangasek> no, that's what we have .ddebs for :)
<seb128> ;-)
<seb128> yeah, I wish we had ddebs support in launchpad though for those upstream who do daily builds and such in ppas using the same packaging
<Laney> I understand that this indicator-sync upload /was/ an ABI break though?
<Laney> So should have had an exception however you read that page...
<Laney> it's kind of unfortunate that it now FTBFS on arm* ppc too
<seb128> Laney, oh, it's indicator-sync we are talking about ;-) I joined just to read the comment on new binaries
<seb128> Laney, well, indicator-sync is NEW in the archive for less than a week and used by nothing and there is a ffe for u1 to use it
<seb128> Laney, I'm unsure there is a need to file yet another ffe for a new package just to make it work when it never worked
#ubuntu-release 2012-08-29
 * ScottK always thought it was clear that anything that hit New needed an FFe and is said to see the rules lawyers have taken over.
<fginther> Greetings! May I ask someone to review some precise uploads (evemu, frame, grail and geis) or at least provide an estimate of when this might occur? Thanks.
<cyphermox> ScottK: micahg: what I wrote before was precisely because I knew it was missing an FFE, sorry if that wasn't clear.
<cyphermox> just filed for this: https://bugs.launchpad.net/ubuntu/+source/indicator-sync/+bug/1043343
<ubot2`> Ubuntu bug 1043343 in indicator-sync "FFE: indicator-sync 12.10.1 -- fix namespacing errors in Gir and module naming consistency" [Undecided,New]
<cyphermox> I'm going to need to do another upload because it failed to build on arm* and powerpc anyway
<psivaa> There are some inconsistencies in the folder structure for quantal d-i images for amd64
<psivaa> bsdtar reports boot
<psivaa> boot/grub
<psivaa> instead of ./boot
<psivaa> ./boot/grub
<tumbleweed> what's the difference?
<psivaa> hmm may be not
<rtg> I am planning to upload a new kernel with a fix for uvcvideo that has caused a number of lockups during live CD installations. Any objections? (no ABI bump required)
<stgraber> bugfix only, no ABI bump, sounds good to me
<rtg> stgraber, 2 bug fixes: bug #1042903 and bug #1042809
<ubot2`> Launchpad bug 1042903 in linux "mgag200 driver hangs on HP ProLiant Gen 8 platform" [Medium,Confirmed] https://launchpad.net/bugs/1042903
<ubot2`> Launchpad bug 1042809 in linux "HP Webcam-101 (uvcvideo) locking machine" [High,Confirmed] https://launchpad.net/bugs/1042809
<stgraber> rtg: right, so assuming you're not planning another upload for beta1, I think this should be uploaded now so it's all built by the time we freeze tomorrow
<rtg> stgraber, mere seconds ago...
<tedg> So I've got a couple FFe's that I'm tracking and I'd like to figure out their status.  bug 1042757  and bug 1040221
<ubot2`> Launchpad bug 1042757 in unity-greeter "FFe request: Unity greeter network indicator" [Undecided,New] https://launchpad.net/bugs/1042757
<ubot2`> Launchpad bug 1040221 in unity-greeter "FFe request: Provide remote login options" [Undecided,New] https://launchpad.net/bugs/1040221
<tedg> The second is still waiting on MIR reviews from security, but they've said they would be doing them today.
<tedg> slangasek, Laney, do you guys perhaps know?  ^
<Laney> seems skaet is on it
<seb128> Laney, where do you see that?
<Laney>  Kate Stewart (kate.stewart) wrote 3 minutes ago: 	#1
<Laney> When can the code land?
<Laney> https://bugs.launchpad.net/ubuntu/+source/unity-greeter/+bug/1042757/comments/1
<ubot2`> Ubuntu bug 1042757 in unity-greeter "FFe request: Unity greeter network indicator" [Undecided,New]
<seb128> Laney, oh, I didn't see the updates yet ;-)
<Laney> :P
<Daviey> Has someone reverted the squashfs usage in server iso?  It's in A3, but not in daily.
<ogra_> Daviey, i definitely see it in my daily arm images
<ogra_> must be that crappy x86 arch
<slangasek> cronjob still shows 'buildlive ubuntu-server daily && for-project ubuntu-server cron.daily'
<slangasek> it also shows a daily i386 iso being built.  have those not been turned off?
<Daviey> they should not have been turned off
<slangasek> Daviey: but we're not releasing them, so why build them?
<slangasek> or are you still gathering info about whether to release them?
<Daviey> dave@frap:~$ curl http://cdimage.ubuntu.com/ubuntu-server/daily/current/quantal-server-amd64.list  2>/dev/null | grep filesystem.squashfs
<Daviey> dave@frap:~$ curl http://cdimage.ubuntu.com/releases/quantal/alpha-3/quantal-server-amd64.list 2>/dev/null | grep filesystem.squashfs
<Daviey> /casper/filesystem.squashfs
<Daviey> slangasek: gather info.. the deal is to be promoting amd64.. but we should still be building i386..
<Daviey> If i wanted i386 to stop being built, i'd have done it :)
<Daviey> ogra_ / slangasek: So somthing has changed between alpha 3 and now.
<slangasek> Daviey: well, the message I saw earlier this cycle was that you were proposing to not ship i386 server at all
<ogra_> we got a new live-build very recently
<slangasek> ogra_: which should not impact whether the squashfs is included in the CD
<ogra_> did you chekck the contents of your squashfs ?
<slangasek> the squashfs /isn't included on the CD/, live-build can't have caused that
<Daviey> slangasek: that was the message.. but everywhere i've said that, i also said that we would still be building it.. just not 'releasing it'
<Daviey> which has been the status for all the Alpha's so far.
<slangasek> Daviey: hmm, well.  I don't see the point in having it built if it's not going to be released
<Daviey> slangasek: The not releasing it for milestones was an effort to gather "oh noes".  We will likely still be releasing it for final.. but a step whcih requires thought to retrieve
<Daviey> (we know too many people are downloing i386 when they really want amd64, so this is to help them :)
<slangasek> Daviey: ah
<ogra_> ogra@anubis:~/Desktop/images$ mount-image-partition quantal-server-armhf+omap4.img 2 /mnt/
<ogra_> ogra@anubis:~/Desktop/images$ find /mnt -name *.squashfs
<ogra_> /mnt/install/filesystem.squashfs
<ogra_> thats todays armhf build
<Daviey> i'm going to blame ogra_ :)
<ogra_> heh, wasnt me :)
<ogra_> sadly the .list files are generated for the first partition the script finds it seems
<ogra_> so my .list looks quite different from x86
<ogra_> even more intresting is that you had a /casper in your server images ... live-installer uses /install afaik
<slangasek> Daviey: when was the last known-good build?
<slangasek> nothing more recent than a3?
<slangasek> the last commit that seems to change squashfs handling in the debian-cd branch is cjwatson's 1802 from 2012-07-31
<Daviey> yeah
<Daviey> slangasek: Well, we don't have legacy images atm :(
<Daviey> i'm wondering if the jenkins install log exposes this.. but i doubt it
<slangasek> "legacy images"?
<slangasek> Daviey: how did you determine that the squashfs wasn't there?  only by looking at the .list?
<slangasek> seems to be a bug in the .list generation
<slangasek> because when I download the image, it's there
<Daviey> slangasek: yes, i looked at the .list
<Daviey> wait, you see it in the daily?
<slangasek> yes
<ogra_> slangasek, you would have huge amounts of bugs from testers and complaining people on IRC if it wasnt there
<slangasek> the .list generation is buggy in some way I haven't bothered to track down
<Daviey> i'm looking at it right now.. not in /casper/filesystem.casper?
<ogra_> (installs would all fail)
<slangasek> ogra_: no, you wouldn't
<slangasek> Daviey: /install/filesystem.squashfs
<Daviey> ogra_: it falls back gracefully
<Daviey> GRR
<Daviey> slangasek: it was moved from /casper/ .. I didn't know. Sorry.
<Daviey> Why was it moved?
<slangasek> so in fact, this is due to cjwatson's change moving the file on you ;)
<ogra_> oh, we still have the packages for a debootstrap on the images ?
<slangasek> maybe because casper/ is a misnomer?
<Daviey> Curse that man! ;)
<slangasek> ogra_: no, we don't, but debian-cd includes the packages *only* if it doesn't find them in the squashfs
<ogra_> oh, ok, a build time fallback
 * ogra_ thought install time
<Daviey> (and runtime)
<slangasek> (rather, in the manifest, since it can't actually introspect the squashfs)
<slangasek> Daviey: well, a runtime fallback wouldn't do much good if the packages weren't actually available on the image... but the image build ensures that they are if necessary
<Daviey> ogra_: Unless i am mistaken, di looks in a given location for the squashfs.. if it doesn't exist.. (or location preseeded (inc. http)), it will use the mirror, either local pool or a.u.c for debs
<ogra_> Daviey, ah, network would be possible, yeah, though live-installer would still bark at you i guess
<Daviey> ogra_: I don't think it does bark.. just fallback.
<ogra_> k
<Daviey> ogra_: netinstall therefore defaults to using debs, but can be preseeded (or have the squashfs already in the right place) to use live-install.
<Daviey> I might be mistaken.. that was my understanding, and assumption i've been working on.
<ogra_> your assumption might be right :)
<sbeattie> SpamapS: can you use your SRU admin powers to release icedtea-web in natty-proposed and oneiric-proposed to their respective security pockets (they fix a regression introduced by a security update).
<sbeattie> also, releasing icedtea-web for precise-updates would be appreciated, too.
<slangasek> what are those rejects about?
<infinity> Working with cnd on it all right now.
<slangasek> ok
<Daviey> sbeattie: Spamaps is at a conf'.. might have better luck with another member of the team.
<slangasek> infinity: bug #1043517 is an interesting dupe; desktop install with no ubuntu-desktop package installed
<ubot2`> Launchpad bug 1043517 in resolvconf "package resolvconf 1.63ubuntu15 failed to install/upgrade: ErrorMessage: pre-dependency problem - not installing resolvconf (dup-of: 1017001)" [Undecided,New] https://launchpad.net/bugs/1043517
<ubot2`> Launchpad bug 1017001 in apt "package resolvconf 1.63ubuntu14 failed to install/upgrade: ErrorMessage: pre-dependency problem - not installing resolvconf" [Critical,Confirmed] https://launchpad.net/bugs/1017001
<slangasek> sbeattie, Daviey: looking
<slangasek> sbeattie: the same package version is also in {natty,oneiric}-updates; does it need copied there too?
<sbeattie> slangasek: yes, the versions in {natty,oneiric}-proposed should also be copied to -updates
<slangasek> ok
<slangasek> reading the bug now
<sbeattie> (I wasn't sure if that would happen automagically or not)
<slangasek> the natty package hasn't built on armel
<sbeattie> yeah, it won't because openjdk-6 FTBFS on armel.
<slangasek> ok.  is this a regression vs. the previous version in natty-updates?
<slangasek> seems not
<sbeattie> no, it's not.
<slangasek> sbeattie: ok, done
<slangasek> (well, once I accept from this silly unapproved queue)
<sbeattie> slangasek: thanks! :)
<infinity> slangasek: Are you using an old sru-release?
<slangasek> maybe?
 * slangasek checks
<slangasek> I didn't think I was
<infinity> slangasek: "sru-release -s natty icedtea-web" would have just autmagically copied-with-accept to updates and security.
<slangasek> oh
<infinity> slangasek: Shouldn't hit unapproved.
<slangasek> right, so no I'm not because I didn't use 'sru-release' at all but copy-package :P
<infinity> Ahh.
<slangasek> which was bad of me
<infinity> Meh, gets the job done.
<slangasek> doesn't append the bug comments though
<infinity> Nope, that it doesn't.
<infinity> Of course, while I'm praising the joys of sru-release, I just got an OOPS mailed to me from my latest copy.
<infinity> Grr.
<knome> there's an awkward bug with xfwm4 in quantal. it appeared maybe a week ago, and the problem is that 1px wide window borders are not drawn/drawn incorrectly with nvidia proprietary drivers. we're quite sure this relates to a recent xorg update. anybody has any ideas what might have causing that?
<knome> it also happens on vbox installations, so it's probably not (only) linked to nvidia drivers
<infinity> knome: Filing a bug on xorg-server might be a good start, then.
<knome> infinity, obviously, i've gathered that much myself. thanks anyway.
#ubuntu-release 2012-08-30
<utlemming> stgraber: can you add http://cloud-images.ubuntu.com/quantal/20120829.3/ to the tracker for Beta-1?
<ScottK> cyphermox: There were others that came after you that went and finely parsed the text of the FFe rules.  It wasn't you I was referring to.
<cyphermox> ScottK: I wasn't taking it personal. indicator-sync was clearly uploaded when it shouldn't have
<cyphermox> ScottK: btw, I have a FFE for it now; since there needs to be another upload anyway, and one for the official release of ModemManager 0.6
<cyphermox> if you have time
<ScottK> No.  Sorry.  On travel for work, been in meetings all day/driving and need to catch up on work stuff tonight.
<stgraber> utlemming: hmm, that's a kind of weird request considering we haven't actually entered beta-1 freeze yet ;) I can certainly do it tomorow though once the beta-1 milestone actually exists on the tracker
<seb128> hey, could you guys ack those today?
<seb128> https://bugs.launchpad.net/bugs/1043589
<ubot2`> Ubuntu bug 1043589 in compiz "[FFe] Add support for OpenGL|ES" [High,Fix released]
<seb128> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1043676
<ubot2`> Ubuntu bug 1043676 in unity "FFe: webapps, previews and coverflow support to Unity/bamf/nux" [High,Confirmed]
<seb128> or review them and comment at least ;-)
<seb128> ogra_, ^
<ogra_> :D
<Laney> Could somebody take a look at NEW today? ;-)
<Daviey> slangasek: Now that netboot/mini.iso can support retrieving a squashfs to install.. I'd like to expose it for server, but does it also make sense to do it for all flavours ?
<Daviey> taking note of the extra cdimage storage requirement?
<ogra_> are they notable ?
<ogra_> its only kernel, initrd and bootloader in a single image
 * ogra_ would be surprised if that was above 20M per image
<ogra_> ah, its 30 for x86 actually
<Daviey> ogra_: No, the whole squashfs, i mean
<ogra_> how big is it ?
<Daviey> omap4 is 149M, powerpc is 245M.. the rest are in the middle
<ogra_> hmm, we currently effectively offer mini.iso on omap4
<Daviey> Oh, we alreayd expose desktop squashfs
<ogra_> http://ports.ubuntu.com/ubuntu-ports/dists/quantal/main/installer-armhf/current/images/omap4/netboot/boot.img-fb.gz is only 15M (but its gzipped)
<Daviey> http://cdimage.ubuntu.com/livecd-base/
<ogra_> oh, how did that end up public ?
<ogra_> i dont think thats what you think it is :)
<Daviey> ah
<ogra_> (look at the manifests ... i think its similar to -core but in a squashfs
<ogra_> )
<Daviey> yeah
<ogra_> i personally would pretty much like to keep the existing mini.isos for people using a local mirror, coundt we add a big-mini.iso or so ? :)
<ogra_> *couldnt
<Daviey> ogra_: You are missing my point.
<Daviey> ogra_: "d-i live-installer/net-imagestring http://path.to.flavour.squashfs" .. and it grabs the squashfs to isntall
<Daviey> so it's still the small image.. but you can use it to grab the squashfs aswell.
<ogra_> right, but how do you make sure the right default preseed is used in that case ?
<Daviey> ogra_: Well, you are preseeding already, right?
<ogra_> well, probably a moot question, the normal netinst also doesnt make use of the pre-flavour preseeding
<ogra_> *per-flavour
<ogra_> Daviey, at image creation time a default preseed gets put into the normal images ...
<ogra_> thats not the casde for netinst
<ogra_> *case
<ogra_> thats what i was referring to
<Daviey> ogra_: Yes, but i'm asking what the difference is?
<Daviey> ogra_: the out-of-the-box mini.iso or netinst wouldn't change.
<ogra_> yep, i got that now
<Daviey> This is just about exposing the squashfs, so people can preseed it.
<ogra_> Daviey, for the default preseeding, look on nusakan in debian-cd in the data dir
<Daviey> ogra_: ok, but what does that change? :)
<ogra_> i.e. data/quantal/preseed/ubuntu-server/ubuntu-server.seed
<ogra_> nothing :)
<ogra_> its just that these arent in the netinst images
<ogra_> but as you mentioned, netinst/mini.iso wont change
<Daviey> ogra_: right.. but if you are using the netinstall/mini.iso, you'd want to supply that preseed anywya, right?
<ogra_> well, we dont atm
<Daviey> ogra_: you might not.. :)
<ogra_> and i doubt people using netinst actually put these preseed files in place
<ogra_> (especially since they woudl have to pull them out of debian-cd first)
<Daviey> ogra_: actually, you raise a good point.. MAAS doesn't have all of those entries in it's preseed.  It should. Thanks
<slangasek> Daviey: hmm, the desktop squashfs doesn't work quite the same as the server one, I'm not sure we want to do that
<Daviey> slangasek: ok
<utlemming> stgraber: oh...I got my dates confused. I was thinking that B1 was today, not next week. whoops.
<davmor2> hey guys can I just confirm that kernel version 3.5.0-13.14 is on the live cd isos please,  I see this Get:489 http://ftpmaster.internal/ubuntu/ quantal/main linux-image-3.5.0-13-generic amd64 3.5.0-13.14 [11.7 MB] from http://people.canonical.com/~ubuntu-archive/livefs-build-logs/quantal/ubuntu/20120830/livecd-20120830-amd64.out so I'm assuming so
<Laney> davmor2: http://cdimage.ubuntu.com/daily-live/current/quantal-desktop-amd64.manifest
<ogra_> linux-image-3.5.0-13-generic	3.5.0-13.14
<ogra_> linux-image-extra-3.5.0-13-generic	3.5.0-13.14
<ogra_> linux-image-generic	3.5.0.13.13
<ogra_> looks fine
<davmor2> ogra_, Laney: ta I'll try an install and see if the webcam issue is gone away then :)
<ogra_> i had installer webcam issues on the ac100 too ... and there the kernel didnt change since precise
<ogra_> so you might still hit some issues (no crashes or hardlocks though)
<davmor2> ogra_: that kernel should include the fix for my issue, with a hp 101 webcam running on the uvcvideo driver
<ogra_> yep, i saw the discussion in -kernel yesterday
<davmor2> ogra_: I just want to be sure it had landed before I wasted 10 minutes updating and burning the iso :)
<ogra_> heh, yeah
<mterry> skaet, hello!  So my plan is to update lightdm & (a hobbled) unity-greeter in quantal today.  I will disable the features in unity-greeter that have pending MIRs and FFes.  But it's not as easy to disable the new API in lightdm.  But since the only consumer is unity-greeter, and it will be disabled there, I'm assuming it wouldn't be breaking FF to upload a remote-login-capable but unused lightdm?
<mterry> Actually, I suppose I could have that API always return an error
<skaet> mterry,  that should be fine.
<Laney> skaet: are we hard freezing the archive this time?
<skaet> Laney,  yes,  we'll freeze at 2100.
<Laney> righto
<tumbleweed> so we get to exercise our new queue admin rights \o/
<Laney> we have that?
<stgraber> I'll be uploading ubiquity-slideshow-ubuntu pretty close to that time, hopefully all the flavours will have their slideshow updated by then
<stgraber> Laney: yep, we do, Colin added the ACL a couple of weeks ago
<tumbleweed> Laney: yeah, go and look at +queue (looks like we have the permissino to do NEW too, but obviously shouldn't)
<Laney> well I can see that, but I thought it was for backporters
<Laney> nice either way
 * skaet --> back to conf
<Laney> == All rights for laney ==
<Laney> Queue Administration Rights for ubuntu-backporters: archive 'primary', pocket 'Backports'
<Laney> Queue Administration Rights for ubuntu-release: archive 'primary', pocket 'Release' in quantal
<Laney> Queue Administration Rights for ubuntu-release: archive 'primary', pocket 'Proposed' in quantal
<micahg> ubuntu-release has rights on the release and proposed pockets
<Laney> true dat
<Laney> I know that the UI doesn't match what the permissions allow
<tumbleweed> right. but we need queue admin for Release to let things thorugh during freezes
<Laney> oh good, I was going to suggest that sru got the same for the other series, but they already have
<Laney> probably the ubuntu-archive memberships can be cleaned up then?
<micahg> cleaned up?
<Laney> some people were added to accept SRUs
<micahg> oh, memberships, yes, I think ScottK already suggested that :)
 * micahg parsed that as permissions somehow :)
<cyphermox> hi, could someone please review https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/1043929 ?
<ubot2`> Ubuntu bug 1043929 in network-manager-applet "FFE: Behavior when policy limits access to nm-applet functions is inconsistent / should hide disallowed actions" [Undecided,New]
<stgraber> cyphermox: looking
<cyphermox> thanks. I got two others too if you have a bit more time
<stgraber> cyphermox: are these changes coming from upstream?
<cyphermox> no
<cyphermox> those are changes from Canonical PS
<cyphermox> stgraber: btw, we should be able to re-enable adhoc wpa shortly too; there are working patches to do this and a minimal change to wpa to get it to work and actually be secured
<stgraber> ok, anyway, looks pretty close to bugfix to me. Showing options that aren't allowed is just wrong. Diff seems reasonable from my rather limited knowledge of gtk
<stgraber> cyphermox: I'm assuming this has all been tested for a few days already? (if you intend on getting this uploaded before beta1 freeze, 21:00 UTC today)?
<cyphermox> stgraber: it was far more for the addition of hiding them if the env variable is found
<cyphermox> yes, though not by me
<cyphermox> Wellark was working and testing that
<stgraber> ok, FFe granted.
 * infinity wonders who this stgraber guy is.
<cyphermox> the others are bug 1043343 and bug 1043486
<ubot2`> Launchpad bug 1043343 in indicator-sync "FFE: indicator-sync 12.10.1 -- fix namespacing errors in Gir and module naming consistency" [Undecided,New] https://launchpad.net/bugs/1043343
<ubot2`> Launchpad bug 1043486 in modemmanager "FFE: ModemManager 0.6 in Quantal" [Undecided,New] https://launchpad.net/bugs/1043486
<cyphermox> ^^ indicator-sync has new binaries
<Laney> cyphermox: are they beta critical?
<cyphermox> Laney: indicator-sync I think they wanted for beta
<Laney> also, do you have a fix for the ftbfs of -sync?
<cyphermox> yes
<cyphermox> modemmanager is less pressing
<stgraber> cyphermox: for MM, do you already have a package ready for upload?
<cyphermox> seb128: indicator-sync beta-critical?
<Laney> well, you might as well go ahead with that since it got uploaded already
<cyphermox> stgraber: yes
<Laney> I can't see -sync getting on media or anything for the beta
<cyphermox> Laney: no, there is that
<Laney> so probably not technically subject to the freeze
<stgraber> cyphermox: ok, I'm assuming you test-built on x86 and tested with the hardware you have around?
<cyphermox> yup
<cyphermox> test build on amd64 and i386 usually, and test with all the modems I have
<cyphermox> (I should list those somewhere)
<stgraber> ok, I'll grant it then. I'll leave the decision of uploading to the archive before the freeze or right after it up to you
<cyphermox> MM is going to land after
<stgraber> ok
<Laney> I'd like people to be explaining their testing in FFe requests
<Laney> I find it really helps when considering them
<stgraber> cyphermox: granted
<stgraber> Laney: agreed. I happen to know what kind of testing cyphermox does for NM and MM, but having it written explicitly in the request would surely help people less familiar with these
<Laney> I've been pushing back a bit with that
<cyphermox> ok
<cyphermox> Laney: the actual fix for the FTBFS will be to disable the automated tests
<cyphermox> they tend to fail 1/4 times on amd64/i386 too
<infinity> cyphermox: Disabling tests sounds like the wrong answer...
<cyphermox> infinity: I know, but they do fail for no reason, even if running them manually (with an actual bus and all) works
<infinity> cyphermox: I suppose finding the bug (either in the code or the tests) and fixing it would be out of the question? :P
<cyphermox> infinity: I would like upstream to find the bug instead of me spending multiple hours hacking at this :)
<cyphermox> the tests are buggy; the code itself appears sane
<cyphermox> and on top of that, the tests are being run wrong (IMO) in make check
<cyphermox> I did bring that up to upstream :)
<Laney> if it helps to motivate them I can nack the FFe until this is fixed ;-)
<seb128> re
<seb128> cyphermox, Laney: indicator-sync is not important for beta1 no, it's not useful as long as the U1 side doesn't land ... are they ready to land that?
<cyphermox> Laney :)
<Laney> cyphermox: I'm not completely joking â we're not supposed to be landing untested code so I would at the least appreciate a b2 milestoned bug about it
<seb128> let charles know about test issues
<seb128> he will fix them I'm sure
<cyphermox> seb128: yeah, I'm working on it
<cyphermox> Laney: I know, but it's not untested
<seb128> https://code.launchpad.net/~charlesk/indicator-sync/lp-1040137/+merge/121932
<cyphermox> charles says he can run the tests on build and it always works
<seb128> it might fix it
<Laney> fix r48 wtf
<Laney> hahaha
<cyphermox> I can also run the examples successfully
<cyphermox> -s
<Laney> I don't doubt it, but it should be working in an automated setup really
<cyphermox> yes
<Laney> so if you just milestone a bug and assign it to charles then I'll be happy for now ;-)
<cyphermox> Laney: https://bugs.launchpad.net/ubuntu/+source/indicator-sync/+bug/1043956
<ubot2`> Ubuntu bug 1043956 in indicator-sync "Automated tests during build fail regularly (though not always)" [Undecided,New]
<Laney> cheers
<Laney> milestoned
<cyphermox> sweet
<cyphermox> now I should just make that also have an upstream task
<bdmurray> infinity: are you doing sru work today?
<tjaalton> hey, i've uploaded a new -synaptics for precise-proposed to fix bug 956071, tested it here and it works. could someone let it through?
<ubot2`> Launchpad bug 956071 in oem-priority/precise "Xorg crashed with SIGSEGV in XIGetDeviceProperty()" [High,Confirmed] https://launchpad.net/bugs/956071
<infinity> bdmurray: I've been doing a little here and there between sessions, that's all.
<micahg> umm, I've got a few branches to sponsor for Ubuntu Studio, but I won't be able to get to it until this evening
<iulian> Could somebody clear those two haskell binaries from NEW so I can finish off the transition (a few more rebuilds).
<micahg> cjwatson: Laney: since you're marked as engineering contacts for beta 1, just wanted to let you know that I'll have some uploads a few hours after beta freeze for Ubuntu Studio (sorry, lack of time on my part and they're lacking uploaders of their own)
<micahg> it's all Ubuntu Studio specific stuff, so shouldn't impact anyone else either
<knome> hey micahg :)
<ScottK> Laney: Some people were accepted to do release stuff too.
<knome> hey stgraber! i uploaded a new xubuntu slideshow to ubiquity-slideshow-ubuntu yesterday; will it be in quantal, or do i need to do something else? :)
<xnox> knome: should be part of the respin. Is it using the new way of doing things?! =)
<knome> the xubuntu slideshow or the branch?
<knome> where's skaet when you need her?
<xnox> knome: the package structure, cause the translations are now ogranised in a different way, as far as I know.
<knome> xnox, i don't know about that, i'm just maintaining the xubuntu slideshow
<xnox> knome: did you test the new slideshow in quantal daily basically?
<knome> no, just precise
<xnox> and did it work ok?
<knome> but i can still run tests in quantal
<xnox> please test in quantal daily CD in a VM
<knome> sure
<xnox> thanks.
<knome> xnox, works like a dream.
<xnox> knome: ok. good =)
<seb128> hey
<seb128> can we get bug #1042757 reviewed?
<ubot2`> Launchpad bug 1042757 in unity-greeter "FFe request: Unity greeter network indicator" [Medium,Fix committed] https://launchpad.net/bugs/1042757
<seb128> we have the feature ready to land, we had to distro patch it out because it's not approved yet
<seb128> Laney, slangasek, no-skaet (:p):
<slangasek> seb128: acked
<seb128> slangasek, thanks!
<slangasek> seb128: can this get uploaded today, then?
<seb128> slangasek, yeah, we were just waiting for the ack
<slangasek> ok
<seb128> the update landed this morning with the feature distro patched out because it was not acked
<seb128> so it's just a matter or dropped the patch
<stgraber> knome: I'll do an upload later today
<stgraber> xnox: I usually do an upload of the slideshow right before UI freeze
<xnox> stgraber: ah ok. Didn't know.
<xnox> stgraber: which branches is that, out of interest?
<stgraber> xnox: lp:ubiquity-slideshow-ubuntu
<xnox> stgraber: ok. got it confused with defaults-builder.
<stgraber> skaet: FYI ltsp is failing on quantal at the moment, trying to get a fix ready by 21:00 UTC but might end up being a tiny bit late
<skaet> stgraber,  ack.
<stgraber> knome: uploading slideshow now
<xnox> freeze.....
<stgraber> skaet: right, didn't make it by 21:00 UTC. wifi is too slow ;) hoping to get ltsp uploaded in the next 30min
 * skaet understands WIFI too slow..... only too well :P
<stgraber> skaet: uploading ltsp now. It fixes two critical bugs in ltsp-client-builder, I'm not sure I won't need to fix something else afterwards, but at this point I really need a new CD build to check that
<stgraber> and there's a talk I need to attend in a few minutes...
<skaet> stgraber, ok.
<knome> stgraber, thanks :)
<knome> skaet, hey
<skaet> hiya knome
<knome> skaet, so, a few things
<knome> skaet, i believe beta release notes are not being written yet?
<skaet> knome,  not yet, setting them up to be ready to be added into by monday.
<knome> skaet, ok, good :)
<skaet> :)  if you need them earlier though just let me know and I'll rearrange some tasks.
<knome> nah, we started writing them to our blog, we can always copy from there
<knome> another thing
<knome> i've made sure the xubuntu website doesn't refer to "derivative" anywhere
<stgraber> thanks! we're slowly getting there
<knome> exactly...
<stgraber> skaet: ok if I respin ubuntu alternate as soon as LTSP is published?
<knome> wait.. ubuntu isn't dropping alternate?
<stgraber> well, it still exists at the moment
<stgraber> and ltsp is broken on it, so I'm fixing it ;)
<knome> heh
<knome> that's one more issue we need to talk about..
<knome> if ubuntu drops them, xubuntu would most probably follow the motion
<stgraber> it's up to you, d-i will still be fully supported
<knome> d-i as in?
<stgraber> debian-installer
<knome> right.
<skaet> stgraber,  ok by me.    I think its likely alternates will drop.
<knome> we've been talking about dropping alternate anyway, so this kind of concludes it.
<skaet> slangasek,  did you and jason come to agreement on whether we'll be having alternates for desktop or not.
<skaet> ?
<slangasek> skaet: we are not having them
<slangasek> (for Ubuntu)
<knome> skaet, what's the deadline when you'd like to know if xubuntu does alternates for beta 1?
<knome> skaet, today? :P
<skaet> knome,  as soon as possible.  Definitely before the candidate images start on monday.
<knome> skaet, ok. i'll let you know before monday
<stgraber> skaet: ok, will respin in a few minutes then. LTSP is on some other media and can also be used with the netboot image, alternate is just the easiest way of testing it ;)
<stgraber> speaking of changes for beta1, what's the status of llvmpipe?
<stgraber> will we be able to use kvm to test beta1?
<jbicha> hi, could I get ubuntu-gnome-default-settings accepted too? thanks
<stgraber> jbicha: is there some magic I'm missing or are you missing a glib-compile-schemas call?
<jbicha> stgraber: that should be automatic, isn't that what's going on at line 3 of http://paste.ubuntu.com/1176741/
<stgraber> jbicha: looks like it, good. I somehow missed the fact that we now have a trigger for it
<skaet> stgraber, need to catch up on the archives to see if I can figure out the story on llvmpipe.
<stgraber> skaet: it'll be a massive pain for beta1 if we can't use kvm for testing
<jbicha> dh_installgsettings is an awfully noisy trigger these days but I blame desrt for that ;)
<xnox> stgraber: yes llvmpipe is awesome in VMs
<stgraber> xnox: "awesome", as in, it works with unity now? last I checked it was still blacklisted and buggy
<xnox> stgraber: it works very well. The best video card to select for KVM is vmvga. Then you can get something like 2360x1770 resolution flicker free (with enough ram to the VM)
<xnox> and it's fast.
<stgraber> xnox: cool, good to hear it's finally working
<xnox> I do want to recommend disable some "slow" effects. E.g. unminimize "geany" effect is slow on llvmpipe.
<xnox> stgraber: setting resolution to 640x480 makes it a complete speedster ;-)
<stgraber> hehe
<seb128> skaet, hey
<seb128> skaet, when would be the last limit to land a compiz,unity update for beta1?
<stgraber> seb128: an hour ago?
<skaet> seb128,  we've gone into beta freeze now.
<skaet> scope of change and impact now.
<seb128> stgraber, very useful thanks...
<seb128> skaet, did you see the compiz and unity ffe?
<seb128> skaet, basically not landing means no arm* desktop
<seb128> that landing has GLES support
<seb128> and yes, I know we are late
<seb128> I wouldn't ask otherwise...
<seb128> I would just upload
<seb128> or "would have uploaded"
<stgraber> seb128: so it's all ready for upload on your side? I think that next week would be too late and Friday is a bad idea, so today would be the deadline from my point of view
<skaet> seb128,  archive is frozen so it will need to be manual let through.   So upload if its ready and tested.   Will see where we are tomorrow, after tonights images are built and tested.
<seb128> stgraber, no, it's not, they have a testing ppa and still need to deal with some bugs
<seb128> it's going to be tomorrow afternoon at the earliest
<seb128> better if later, I was trying to see how much "too late" monday would be...
<seb128> skaet, stgraber: the alternative is no arm* desktop in beta1 one and no tested of webapp,coverflow and previews in unity for beta1 nor testing of GLES
<skaet> seb128, would like it discussed in the meeting tomorrow then.
<seb128> skaet, ok, I do plan to discuss it there
<seb128> I know it's a bit of a between rock and hard place situation
<stgraber> seb128: I'm assuming this is going to bring new binary packages and bump the API too?
<seb128> no new binaries no
<seb128> well, there are api addition to bamf and nux
<seb128> but nothing out of unity uses that
<seb128> it's a self contained set
<stgraber> ok, so, reverting compiz + unity would be a way out if it blows up (but no arm support then)
<seb128> right
<stgraber> assuming we let that stuff in tomorrow, will you have people around over the weekend to fix it?
<seb128> I doubt there wil be blows up, they have a good testsuit running on every commit and they do manual testing and those updates are being tested in ppa for a week
<seb128> I will be around to fix things that can go wrong from a distro perspective
<seb128> I will check with the unity guys how available they are
<stgraber> ok, assuming we have someone who can revert/fix + upload over the weekend if it blows up, I think I'd be ok (but far from happy) to have it land tomorrow by end of day
<seb128> but I guess they will have to make effort and get some people available in case it goes wrong
<seb128> ok, thanks
<stgraber> there's also the fact that skaet, infinity and I will be traveling on Saturday, so you'll have to find another release team member to review + accept
<seb128> well, let's get an update at the release meeting
<seb128> I hope to have things ready by then
<stgraber> ok
<xnox> is quantal frozen, or both quantal & quantal-proposed frozen?
<stgraber> I'm assuming all pockets are frozen but maybe I'm not up to date on how LP works for that stuff
<Laney> micahg: what is it?
<Laney> will it let them actually get images again?
<cjwatson> ^- livecd-rootfs fixes zh_CN/i386 build failure; doesn't fix as-yet-undiagnosed zh_CN/amd64 build failure, should have no effect on other builds
<cjwatson> (not really back, still on vacation tomorrow, just catching up on a bit of the mail backlog and fixing some obvious stuff)
<cjwatson> ^- all three non-urgent for beta, just "lest I forget" kinds of things
<stgraber> skaet: ltsp still isn't fully working, pushing another fix upstream, will upload in a few minutes
#ubuntu-release 2012-08-31
<stgraber> skaet: uploaded ltsp with the required fixes
<stgraber> it's going to be horribly slow though as llvmpipe over network is a nightmare
<stgraber> trying in VMs locally (so supposedly pretty fast), I have almost a second latency and all the fading is horribly slow
<stgraber> but at least you get a "working" session
<micahg> Laney: yeah, it's a new meta to drop the indicators and their settings and look packages
<cjwatson> ^- beta-critical bug fix; requires debian-installer upload after its binaries have published
<stgraber> can someone review ltsp too, it's beta critical
<stgraber> I'll take biosdevname
<stgraber> accepted
<stgraber> also accepted livecd-rootfs. Does that one still need manual deployment on the buildds? can't remember if it auto-updates or not
<stgraber> slangasek: if you have a minute, can you review LTSP? I believe infinity is at some meeting at the moment so can't poke him to do it ;)
<infinity> stgraber: It auto-upgrades.
<stgraber> oh, looks like infinity's back! if you have a sec, can you look at ltsp?
<cjwatson> ltsp looks fine to me
<cjwatson> though it'd be nice to update the comment along with the X_COLOR_DEPTH setting - but it's temporary so hopefully this won't matter for long
<cjwatson> accepted
<micahg> can someone please review the 3 ubuntu studio packages here ^^^
<pitti> ^ only fixes a dependency, and adds/fixes autopkgtests, so I'd appreciate if it could be accepted
<pitti> FYI, dpm prepared quantal langpacks, uploading now and waving throug queue
<phillw> hiyas good people, a question on the updating of respins
<pitti> hm, why does queuebot say that gvfs and gtkmm have been accepted, while they are still in unapproved?
<pitti> is it getting confused because of the langpack uploads/accepts?
<pitti> stgraber: ^
<pitti> ^ fixes two beta-milestoned major bugs; review appreciated!
<Laney> Riddell: are you guys on top of the kde-telepathy stuff?
<Laney> looks like it goes back to https://launchpad.net/ubuntu/+source/ktp-common-internals/0.5.0-0ubuntu1
<cjwatson> pitti: gvfs> killall is in psmisc - is that guaranteed to be installed in this context?  (besides, pkill is a better habit to be in IMO, which requires procps)
<pitti> cjwatson: it is installed on our jenkins test boxes, but I'll add it anyway, thanks for spotting (and change to pkill)
<pitti> oh, silly pkill/pgrep
<pitti> I was wondering why pgrep gvfs-udisks2-volume-monitor utterly fails
<pitti> Name:gvfs-udisks2-vo
<pitti> (in status)
 * pitti adds -f
<pitti> cjwatson: FYI, http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/quantal/gvfs/quantal/revision/224
<Laney> knome: hey, looks like pidgin-libnotify is broken for now due to the indicator-messages transition, causing xubuntu to fail to build
<knome> Laney, can you drop that until we fix the indicators? thanks
<Laney> it'll need a pidgin upload to drop it
<Laney> can you test an upload just dropping the recommends?
<knome> i'm not a technical person, and i'm busy with real work now
<knome> if you can, ask micahg or mr_pouit for that
<seb128> Laney, I plan to port pidgin-libnotify but probably not today
<Laney> seb128: fair enough, so since it probably won't make beta i'll disable it for now
<seb128> yeah, I agree
<Laney> skaet: hey! when do you want to disable crontab and start pushing to the b1 milestone on the tracker?
<skaet> Laney,  current plan is for Monday to disable the crontab
<skaet> I think we can enable the milestone though today.
<skaet> Will see if there's any new data that changes that after the meeting later today.
<Laney> well, they won't really be candidate builds as long as cron is on
<skaet> Laney,  we're still missing some bits to land before any images can be considered candidates.
<ogra_> what has cron to do with the content of the image ?
<Laney> it means that the builds will be overwritten
<skaet> ogra_,  more a comment on the contents of candidates
<ogra_> sure, but people should upload to proposed anyway
<skaet> won't have true candidates until then.   However gathering testing data over the weekend is useful to see if there are some "surprises" lurking.
<skaet> s/then/all the missing bits land
 * ogra_ still waits for a "compiz surprise" on arm :)
<ScottK> I know we have an upload that needs to happen for Kubuntu to fix KDE telepathy FTBFS.
<ScottK> Should be done today though.
<Laney> ah, good, I pinged Riddell about that earlier
<ScottK> shadeslayer is going to fix it.
<Laney> ^ is needed for xubuntu, please have a look
<shadeslayer> yep
<skaet> Laney,  lets talk about the crontab disable/milestone enable after we get the data from the weekly meeting.
<Laney> ok
<ScottK> skaet: Let's not keep moving stuff earlier.
<skaet> ScottK, https://wiki.ubuntu.com/BetaProcess  Release minus 6 day tasks
<ScottK> skaet: Stopping the cronned image builds is release -3, i.e. Monday.
<Laney> that's what we are currently saying
<Laney> I was just checking and then confused because I thought that images posted to the milestone were supposed to be 'genuine candidates' (at least not /guaranteed/ to not be candidates due to cron still being on)
<Laney> but if I'm mistaken then ho hum.
<ogra_> skaet, FYI, i'll not be around for the meeting today, steve will cover for me
<skaet> thanks ogra_
 * skaet appreciates knowing who to nick highlight ;)
<pitti> ^ this makes autopkgtest actually report failed tests (*blush*), and fixes two race conditions in the tests
<pitti> this only changes debian/tests/, nothing else, so I'd appreciate if it could be reviewed/accepted
<dobey> hey all
<dobey> i was wondering if we'll need a freeze exception to fix bug #974637 ? it's technically a regression, so just wondering if we need a UIFE for it, or just to notify i18n/docs teams that a change is coming
<ubot2`> Launchpad bug 974637 in ubuntu-sso-client "Qt Registration and Log-in dialogs have no way to perform the other action" [High,Triaged] https://launchpad.net/bugs/974637
<jbicha> dobey: if the strings change, then yes you'll need to notify the -translators list
<jbicha> we still don't have any docs for Ubuntu One or any of the sign-on part of USC
<dobey> right; i know we'll have to notify either way. i just wanted to verify whether we needed the full FFe/UIFe process for it
<ScottK> dobey: All U/I changes need a U/IFe now, AIUI.
<ScottK> Would someone please respin Kubuntu i386/amd64 live.  They should build now.
<stgraber> pitti: hmm, yeah, queuebot or the LP API get confused when all the langpacks land/are accepted
<Laney> doing
<Laney> ScottK: I don't see any upload that would have fixed it?
<ScottK> Laney: It was getting KDE telepathy out of binary new.
<ScottK> Thanks.
<Laney> I see, hence the other arches still being broken
<ScottK> Yes.
<ScottK> We'll need another upload for that.
<Laney> kubuntu-amd64 on kapok.buildd finished at 2012-08-31 14:52:15 (failed)
<dobey> ScottK: "now" as in "we are past UI freeze" or "now" as in "the rules have changed since last cycle" ?
<ScottK> dobey: As in we're past UIF.
<ScottK> Laney: Thanks.  My mail didn't have the log, so let me have a look.
<ScottK> Laney: I don't see the log: http://people.canonical.com/~ubuntu-archive/livefs-build-logs/quantal/kubuntu/
<ScottK> Can you point me at it or send it to me?
<Laney> ScottK: They sync at :0
<ScottK> OK.  Thanks.
<ScottK> Right, so apparently that wasn't enough.  Investigating.
<Laney> i386 seems to be working
<ScottK> Yeah.
 * ScottK shakes fist at shadeslayer 
<ScottK> I don't see it.
<ScottK> i386 working is progress.
<stgraber> seb128: bug 1044436 (screenshot attached)
<ubot2`> Launchpad bug 1044436 in unity "unity on llvmpipe is unusable when in 16bit mode" [Undecided,New] https://launchpad.net/bugs/1044436
<seb128> stgraber, thanks
<slangasek> balloons: ok
<Laney> so we won't be releasing alternates with b1?
<slangasek> Laney: that's correct
<Laney> or everything thereafter, I suppose
<balloons> slangasek, just in general, there was anticipation that ubiquity wasn't going to meet needs.. folks claiming they could only get the alt installer to work, etc, etc
<slangasek> balloons: "anticipation that it won't meet the needs" is not useful technical feedback :)
<Laney> we should make sure cron, pad, ... is updated then
<skaet> urg... forgot to ask that
<balloons> slangasek, I know, I was just pointing out people are hesitant to change (not surprising)
<slangasek> we genuinely want to know about any concrete problems that prevent the desktop CD from being usable
<skaet> ScottK,  is Kubuntu going forward with alternate or dropping them too?
<Daviey> balloons: Sounds like panicking.. mini.iso should be able to cover their needs IMO.
<slangasek> but yeah, vague concerns that it won't work are not going to change the calculation
<ScottK> skaet: Not sure the status of that.  Riddell?  We don't have the U/I work done in the installer to support everything, so I'm not sure.
<skaet> ScottK,  ok, we'll leave them in there for you for now.
<balloons> slangasek, yes don't misunderstand. I wasn't attempting to change direction. I encouraged those that had issues to voice them on your thread
<Riddell> ScottK, skaet: I don't see us getting the UI work done in the installer this cycle, so presume to keep alternate
<skaet> Riddell,  ok.
<xnox> ScottK: I didn't see any code/branches that bring in crypto/lvm support in the Qt frontend. And I'm not doing them (no time, nor post 3.5 Qt knoweledge)
<slangasek> balloons: yep, sorry, that comment is really addressed to those raising such concerns and I'm using you as a proxy ;)
<skaet> Daviey,  do we move i386 out of Depreceated?
<xnox> ah ok =)
<slangasek> balloons: anyway, I'm confident based on the feedback on list that we're adequately covered with the other images
<ScottK> xnox: Yes.  Known.
<skaet> https://wiki.ubuntu.com/QuantalQuetzal/ReleaseManifest
<skaet> also, any update on the netboot image?
<xnox> ScottK: i'm a was out of sync reading backlog =)
<ScottK> OK
<balloons> slangasek, :-). no worries. Can you summarize your suggested images for folks who's needs might be better addressed by the mini iso, etc now?
<skaet> knome,  I'm assuming you'll be keeping Xubuntu alternates this release as well, unless you indicate differently.
<skaet> s/release/beta release/
<slangasek> balloons: there's a bug open against ubuntu-release-notes that has the current recommendations
<slangasek> skaet: btw, is there supposed to be a quantal series for the ubuntu-release-notes project?
<skaet> Riddell,  are we trying for the Kubuntu Active images for beta 1?
<slangasek> AFAICS it's not there, but maybe I'm doing it wrong
 * skaet goes to cross check it
<gilir> skaet, bug report about indicator-applications-gtk2 is bug 1044442
<ubot2`> Launchpad bug 1044442 in ubuntu "Re-introduce indicator-applications-gtk2" [Undecided,In progress] https://launchpad.net/bugs/1044442
<slangasek> http://pad.ubuntu.com/ubuntu-release is currently primed for 12.04.1... if we delete the alternate references, we'll need to add them back for 12.04.2, I guess?
<slangasek> would it be better to have two separate pads?
<skaet> slangasek,   rather just recreate it each release
<skaet> rather than pointing folks to different places
<skaet> maybe just copy off for now?
<slangasek> hmm, ok
<skaet> and copy back
<slangasek> I don't want to be in charge of copying it back ;)
<skaet> it is history saved.
<skaet> I'll do it.
<slangasek> ok
<skaet> let me finish looking at sorting out release notes, and then that will be next
<slangasek> skaet: thanks, don't let me rush you :)
<skaet> :)
<Riddell> skaet: yes I'd like kubuntu active but it needs a bugfix to the session login I've not looked into yet, it'll still be a tech preview at best
<skaet> slangasek, try again now to target to quantal,  should be sorted now.
<skaet> for ubuntu-release-notes
<skaet> thanks gilir
<slangasek> skaet: works now, thanks :)
<seb128> skaet, stgraber, Laney: ^ please ack libreoffice, the changelog doesn't list specific bugs but it's to address some of the appmenu implementation issues with the ff landing (like making unity eat 100% cpu for hours)
<seb128> well, that's a new rc version (we aim at 3.6.1 for quantal) as well
<seb128> but it includes the menus improvements and it would be really good to have those in beta1
<skaet> Laney,  can you review?
<Laney> ok
<skaet> ev, have all updates for WUBI for 12.10 beta 1 been made?
<Laney> please somebody look at pidgin-libnotify so that xubuntu can hopefully get some images
<ev> skaet: I don't think we do anything special for beta
<Daviey> skaet: yeah
<skaet> ev, ok, thanks
<skaet> Daviey,  ok I'll move i386  back later.   what about the netboot image?
<Daviey> skaet: netboot is still important
<jibel> skaet, slangasek I filed bug 1044452, could someone knowledgeable look at it ?
<ubot2`> Launchpad bug 1044452 in ubuntu "Quantal Bootspeed: Regression from Precise" [Undecided,New] https://launchpad.net/bugs/1044452
<tumbleweed> Laney: typo in the bug quoted in the pidgin-libnotify changelog. otherwise seems reasonable
<Laney> hmm
<Laney> shall I reupload?
<tumbleweed> meh, it's easy enough to figure out
<ScottK> I'll be out for awhile.  If shadeslayer manages to fix kde-telepathy, someone please accept it.
<mterry> Hello!  Could a release team member look at bug 1044447 when possible, to tell me which of the four options you'd prefer?  Or if the whole thing is awful.  :)
<ubot2`> Launchpad bug 1044447 in unity-lens-photos "[FFe, MIR] unity-lens-photo in quantal" [Undecided,New] https://launchpad.net/bugs/1044447
<xnox> | please approve this
<xnox> V
<Laney> mterry: #1 sounds fine, as long as you don't expect it for B1 :-)
<mterry> Laney, no, not at all  :)
<mterry> Laney, but hopefully shortly after it's out
 * mterry investigates oauthlib then
<Laney> make sure not to break the other rdeps while you're at it :P
 * xnox the arrow worked! \0/ please approve ubiquity fixing critical bug in the ask page & removing alpha warning.
<xnox> the debdiff is tiny
<mterry> Hopefully not yeah  :)
<Laney> slangasek: ^ (ubiquity) ?
<seb128> can I get https://bugs.launchpad.net/ubuntu/+source/indicator-session/+bug/1044464 acked?
<ubot2`> Ubuntu bug 1044464 in indicator-session "UIFe: add an Online Account menuitem" [Medium,Fix committed]
<seb128> it's a small UIFe, I would like to land that today still
<seb128> just adding an entry to indicator-session
<slangasek> Laney: does that mean you're passing the review to me?
<Laney> slangasek: yes, I'm asking if you would do it
<Laney> slangasek: also, do you know of a workaround for timeouts when accepting packages?
<Laney> libreoffice here
<slangasek> jibel: will try to look at this, but the amount of time passed means it's going to be harder to trace
<slangasek> Laney: hum, timeouts when accepting them which way?
<slangasek> Laney: AIUI the API is the only way for us to do accepts at this time
<slangasek> Laney: and yes, will review ubiquity
<Laney> API using "queue"
<Laney> queue -s quantal-proposed -Q unapproved accept libreoffice â thusly
<slangasek> Laney: yeah, we can't use the more direct method anymore because we don't have sudo on pepo :/
<Laney> keep trying until caches get sufficiently warmed up?
<slangasek> I guess so?
<Laney> ok, cheers
<slangasek> xnox: should these partman string issues be unit-testable?
<slangasek> (ubiquity accepted)
<xnox> slangasek: all of them are, apart from the ones that need dynamic substitution after we detect $OS.
<xnox> slangasek: there three that never change (dont' have $OS substitution: custom, lvm, crypto) but pulled the same way as the rest (replace/resize/upgrade/etc)
<Laney> ah, there we go
<Laney> fifth time lucky
<xnox> slangasek: so a unit-test can catch this in the future for those three without subs, others are more tricky. Currently they are skipped in the translation unit-test.
<slangasek> xnox: I guess best practice would be to add said unit test ASAP, so we at least test the parts that are testable
<xnox> slangasek: unfortunately partman integration is not unit-tested currently, If you have any thought on how to unit test partman they'd be very welcome.
<slangasek> xnox: no specific ideas, sorry
<xnox> slangasek: i will think about it and implement some unit tests.
<seb128> Laney, stgraber, skaet: ^ please consider that one, it fixes some bug and it lands a few UI tweaks that would be nicer to get earlier than late
<skaet> seb128, Daviey,  can you please take a pass at putting the appropriate upgrade information in to: https://help.ubuntu.com/community/QuantalUpgrades
<skaet> slangasek,  do we want to put some special comments there about the alternates?  ie. what to do if you're used to using alternates?  or is there a better place?
<seb128> skaet, ok
<slangasek> skaet: I don't think we want to put comments about the alternates, just remove them?  The supported upgrade method is now the network upgrade
<shadeslayer> uhm, could someone approve that ^
<tumbleweed> shadeslayer: done
<shadeslayer> thanks :)
<shadeslayer> I also have a fixed armhf build for telepathy-qt that's test building atm
<shadeslayer> but that'll take some time
<micahg> slangasek: when you get a chance, could you please review my gnome-dictionary SRU in precise, it affects lucid -> precise upgrades
<cjwatson> Laney: I have a branch in progress that moves bug processing on queue accept to an async job, which will deal with that problem.  In the meantime you can ask webops on #launchpad-ops (internal) to run queue accept as lp_archive@pepo for you, or harass GSA to fix the RT about us not having sudo any more :-)
<cjwatson> I think it stalled partly due to my vacation and partly because it took a while for the DB patch to be deployed (largely because fastdowntime was on hold for a bit following the DC move)
<slangasek> micahg: gnome-dictionary accepted
<seb128> is there any way release people could start reviewing the unity stack (bamf, compiz, ...)?
<micahg> slangasek: thanks
<seb128> Laney, slangasek, stgraber, skaet: is there anyone to review the unity stack as it gets uploaded? (some components already in the queue, I would like to get comments while I'm still around to reply to eventual concerns)
<slangasek> seb128: let me have a look
<seb128> slangasek, thanks, bamf and compiz there so far, nux about to come, unity in a bit
<skaet> thanks slangasek.
<stgraber> seb128: busy with plumbers, so if slangasek can do it, that'd be great. Poke me once accepted though so I can make sure it gets built immediately (if there's something else in the buildd queue)
<slangasek> seb128: bamf accepted; but eh, why spend the effort trying to verify that the public functions weren't used, instead of just bumping the soname?
<seb128> slangasek, the #ps guys didn't want to "make the transition" harder and they had rolled their testing ppa etc already, I tried to argue a bit but I decided I didn't care enough to fight that battle and moved to the other components in their stack where most of work was laying (compiz, unity especially)
<seb128> slangasek, thanks for approving it
<slangasek> meh, false optimization
<slangasek> who should I go lecture about ABIs? :)
<seb128> mhr3 ;-)
<seb128> well racarr is the one who broke it, mhr3 argued it was easier to not change the soname ;-)
<infinity> slangasek: What's with the kexec-tools upload you sponsored to precise without a bug closure in the changelog?
<slangasek> infinity: that's an interesting question
<slangasek> infinity: I thought I sponsored one /with/ a bug closure in the changelog
<infinity> slangasek: The changelog disagrees. :P
<slangasek> infinity: must be your imagination, I see the ref there plain as day
<slangasek> queuebot: shhhhh
<infinity> slangasek: *smirk*
<infinity> slangasek / cjwatson: I'm not going to accept that debian-installer until after the current ti-omap4 kernel has made it from the PPA to proposed, since the last one had a nasty regression.
<infinity> (for precise)
<infinity> slangasek: Y'know, since it's technically your SRU day and all.
<slangasek> infinity: hmm, so what are you doing SRU processing for?  Aren't you supposed to be somewhere throwing peanuts at Lennart?
<infinity> I'm throwing Stephane at Peter and Matthew.
<stgraber> ...
<infinity> He's compact.
<stgraber> infinity: what happened to your wifi? shouldn't you be looking at your syslog?
<slangasek> infinity: trying to get on the olympic swiss tossing team?
<infinity> slangasek: I'm actually mostly doing some work in this session to debug my wireless for Seth. :P
 * skaet tempted to go downstairs and watch.... 
<cjwatson> infinity: mkay.  I was mostly just throwing it at the archive as the most efficient way to respond to a question from rbasak earlier today without him actually being on IRC to be responded to.
<infinity> cjwatson: Fair enough.  I had planned to do the same upload a bit later, so less effort for me. :P
<cjwatson> What I'm actually supposed to be doing right now is writing a best man speech, so this is displacement activity ...
<infinity> cjwatson: Someone invited you to a public event to say something nice about them?
<infinity> cjwatson: I suspect a speech questioning their sanity might work.
<cjwatson> I think it's revenge for me doing the same in reverse seven years ago.
 * slangasek grins
<slangasek> infinity: any test case for bug #1034568?
<ubot2`> Launchpad bug 1034568 in build-essential "build-essential shouldn't be Multi-Arch: foreign" [Undecided,In progress] https://launchpad.net/bugs/1034568
<infinity> slangasek: dpkg-deb -I?
<slangasek> dpkg-deb -I succeeds in both cases. :)
<infinity> *rolls eyes*
<infinity> Pedant.
<slangasek> yes
<slangasek> accepted
<infinity> dpkg-deb -I | swiss-toss
<infinity> slangasek: But thanks for reminding me that I might need to SRU up some of those eglibc bugs.  At least the ones that aren't pretty obvious.
<infinity> I kinda didn't bother after we delayed it.
 * slangasek pauses his terminal where it is :)
<ScottK> slangasek or infinity: Would you please retry Kubuntu amd64 live?
<slangasek> looking
<ScottK> Thanks.
<infinity> ScottK: Only if you fix the symbols file in telepathy-qt.
<ScottK> infinity: shadeslayer is working on that.  Test build on armhf was fine.
<ScottK> I want to make sure we don't have another problem before we upload to the archive.
<infinity> ScottK: Yay, just glad that someone's fixing.
<ScottK> Since amd64 doesn't have that problem, it should have been fine.
<ScottK> See.  No threats needed.
<infinity> ScottK: (I think slangasek was doing it for you anyway)
<seb128> slangasek, nux and unity as well quantal-proposed, having them reviewed before I take off would be appreciate
<seb128> d
<shadeslayer> ScottK: someone will have to upload tp-qt since it's not in the kubuntu packageset
<infinity> shadeslayer: Give me a pointer to it.
<shadeslayer> infinity: https://launchpad.net/~rohangarg/+archive/nightly/+files/telepathy-qt_0.9.3-0ubuntu2.dsc , but I'm just waiting for it to build on amd64 and i386 to make sure it doesn't break on those
<shadeslayer> https://launchpad.net/~rohangarg/+archive/nightly/+build/3757038
<infinity> shadeslayer: Erm.  Why only "on armhf"?
<infinity> shadeslayer: Tell me that this includes the armel and powerpc symbols changes too.
<shadeslayer> infinity: haven't tested it on armel and powerpc since I don't hardware to test build on those arch's
<infinity> shadeslayer: armel is the same hardware as armhf.  But if you were using symbolhelper, why not just feed it all the build logs?
<infinity> That's kinda the point of it.
<infinity> (Or, you can do it by hand from the failed build logs...)
<shadeslayer> well, I did use symbol helper, and I believe it worked for armhf, but patches fail to apply for armel and powerpc most likely because some of the symbols were already patched
<shadeslayer> plus, there are more missing symbols not in the build log that I found out later on
<infinity> shadeslayer: Perhaps I'll do this, since I can test on all the arches.
<infinity> shadeslayer: (As for the patch application failure, that's because you were trying to do it incrementally... What you wanted was "pkgkde-symbolshelper batchpatch armel.log armhf.log powerpc.log" on the same invocation)
<infinity> shadeslayer: Anyhow, verifying this here now.
<shadeslayer> yeah, that's what I've did now, lemme test build
<shadeslayer> alright
<infinity> shadeslayer: I'm already on it.
<shadeslayer> okay
<shadeslayer> thanks!
<knome> hey skaet
<slangasek> seb128: looking at them now - though I hope you realize I can't do reviews and XDG_RUNTIME_DIR at the same time ;)
<seb128> slangasek, I do and I wouldn't ping you if I could get anyone else from the release team to review them but seems they are all focussed on plumbers ;-)
<seb128> slangasek, thanks for the reviews!
<slangasek> http://paste.ubuntu.com/1178764/ - heh
<slangasek> and there's unity accepted
<seb128> slangasek, their contributors script seems buggy, I will tell them ... thanks ;-)
<slangasek> :)
<infinity> shadeslayer: My arm and PPC testbuilds may end up interfering with my plans to drink heavily tonight, but I'll make sure this gets uploaded on the weekend if I don't finish tonight.
<skaet> knome, ?  specific question?  ;)
<knome> skaet, no, just re: the alternates, i will inform you before monday on our final decision if that's still ok..
<knome> had real work and life mess up today's schedule..
<skaet> knome,  fair 'nuf.   :)  thanks.
<knome> no problem
<herton> infinity, just heads up, ^ ti-omap4 finished building, run the script here for the sync
<infinity> herton: Accepted.
<herton> thanks
<stgraber> seb128: is the unity stack ready to be copied? looks like the build queue is empty
<seb128> no
<infinity> herton: No problem.  Thanks for doing the rebase.
<seb128> stgraber, build failed on slow archs for unity due to mismatch versions in nux,compiz
<seb128> stgraber, it needs a retry after the next publisher run on those
<seb128> stgraber, then they are ok to publish once they built
<seb128> so ~1h
<stgraber> ok
#ubuntu-release 2012-09-01
<cjwatson> ^- fixes Chinese edition amd64 image build failure, which is the last of our long-running failures
 * stgraber looks
<stgraber> accepted
<cjwatson> ta
<stgraber> (debdiff wasn't terribly useful with that one, took a bit more manual checking)
 * cjwatson looks forward to less cronmail
<infinity> cjwatson: Accepted d-i/precise
<cjwatson> thanks
<infinity> Anyone with @ on this channel want to fix the topic to stop lying about the state of the archive?
<infinity> (Or fix the channel mode...)
* cjwatson changed the topic of #ubuntu-release to: Quantal Quetzal Alpha 3 released! | Archive: Beta Freeze | Quantal Quetzal Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or birdseed | melior malum quod cognoscis
<cjwatson> infinity: also you have @ (and @-less use of /topic) here now
<cjwatson> (which probably means I didn't need to op myself to do that, but anyway ...)
<stgraber> remaining bits of the unity stack are now building
<stgraber> would be nice if someone could monitor and copy to the release pocket once they're done
<stgraber> cjwatson: I'm assuming that's for biosdevname? ^
<stgraber> (waiting on very slow internet to download it)
<cjwatson> Yeah
<stgraber> just did a very quick review of mountall, seems kind of reasonable but not confident enough (just got back from an open bar...) to actually accept it. Will do another review tomorrow morning if nobody got to it before then.
<stgraber> (having the autoconf generate stuff change doesn't really help)
<bencer> hi, anybody from the -release team could have a look at this FFe? #1043654
 * stgraber releases unity into the release pocket
<ogra_> hmm
 * ogra_ meanwhile points at bug 1044709
<ubot2`> Launchpad bug 1044709 in compiz "compiz 0:0.9.8.0-0ubuntu1 from quantal-propsed crashed with SIGSEGV on omap4" [High,New] https://launchpad.net/bugs/1044709
<stgraber> doh
<stgraber> ogra_: though my understanding is that even with this bug, it's no worse than what we had or am I wrong?
 * ogra_ tries to find a fix but its not quick (testbuild takes 30min for every iteration)
<ogra_> stgraber, riht, it just crashes on start of the desktop
<ogra_> *right
<Mirv> compiz was compiled with gles: https://launchpadlibrarian.net/114154546/buildlog_ubuntu-quantal-armhf.compiz_1%3A0.9.8.0-0ubuntu1_BUILDING.txt.gz
<ogra_> yes
<stgraber> ok, good, so that definitely needs to be fixed ASAP but we don't need to try and figure out an immediate revert as it wouldn't actually improve things
<ogra_> but i fear the installing of the cmake file we tinkered with breaks it
<ogra_> right, leave it as is ...
<ppisati> ah!
<ppisati> ogra_: how is the release going?
<Mirv> ogra_: I don't think we did and cmakefile change for compiz, or do you mean unity?
<ogra_> ppisati, beyond the above bug its really fine
<ppisati> ogra_: cool
<ogra_> Mirv, i mean the debian/rules hack for FindGLES2.cmake
 * ppisati is on its way to Rhodes, just did a pitstop @home and wanted to check
<Mirv> ogra_: ah, that
<stgraber> ogra_: I'll be leaving the hotel soonish as I have to get to the airport, but if you can figure out a fix, just upload directly to -proposed and I'll review + accept + pocket copy whenever I get connectivity again
<ogra_> we used to install it under Modules in the past, now it goes directly to the package target dir ...
<ogra_> and i suspect that changes something
<ogra_> stgraber, k
<ogra_> i suspect that will need testing on x86 then though
<Mirv> ogra_: I think the end result was the same, compiz-dev has the wanted too copies of both FindCompiz and FindOpenGLES2.cmake, under cmake-2.8 and cmake-2.8/Modules
<ogra_> (recently someone complained about that for plymouth even though there were only arm changes)
<Mirv> s/too/two/
<ogra_> Mirv, FindOpenGLES2.cmake needs to be under cmake-2.8/Modules i think
<Mirv> ogra_: like I said it is
<Mirv> both there and the parent dir
<ogra_> hmm
<Mirv> (looking at http://launchpadlibrarian.net/114154559/compiz-dev_0.9.8.0-0ubuntu1_armhf.deb with file-roller)
<ogra_> yeah, i see that here too
<ogra_> i just dont get why it worked before
<ogra_> cant be the build itself
<Mirv> that's a pretty good question, maybe worth looking at the good ol' patch to see if there was some hard-coding or something somewhere still
<ogra_> right, thats what i did
<ogra_> inspecting the packagin bits ...
<ogra_> and the only real difference is the debian/rules stuff
<Mirv> I mean the patch itself, if you meant it worked back when it was patched on top of sources http://is.gd/qx7Nze
<ogra_> ah, no, the patch has nothing in common anymore with the actually landed code i think
<ogra_> afaik there was a lot re-written upstream
<Mirv> yes not really, just thought if there was something forgotten to be defined in the re-write
<ogra_> well, and when i tested the test4 package (but only by running binary-arch and binary-indep after applying teh change) it worked fine
<Mirv> oh...
<ogra_> so i dont think its the compiled code
<Mirv> very weird, though
<ogra_> at runtime compiz seems to try to use opengl ...
<Mirv> since I got up to test8, I wonder what phase the test4 was at..
<ogra_> the one that was missing &&
<Mirv> test4 was (possibly) this where I fixed the installed plugins at http://bazaar.launchpad.net/~timo-jyrinki/compiz/gles_arm_install_fix/revision/3283
<Mirv> which you then fakeroot installed manually
<ogra_> hmm, no i dont think i did
<Mirv> ok :) hard to remember
<Mirv> anyway, the devil is once again in some very little detail, similar to that actual debian/rules fix to correct the packaging to work
<ogra_> must have been somewhere between 3283 and 3286
<ogra_> actually between 3284 and 3285
<ogra_> *but* ....
<ogra_> i think i didnt remove the compiz-dev.install.arm{el,hf} files when changing debian/rules
 * ogra_ wonders if that could make any difference 
<tumbleweed> oh, FFS. now libreoffice FTBFS on i386
<ogra_> as long as armhf builds
<stgraber> looks like a packaging mistake, so I'm assuming the rest will fail too
<stgraber> dh_install: missing files, aborting
<Mirv> ogra_: they probably didn't exist at the time, since you were only debugging the test4 version that failed to build since I _hadn't_ yet added the compiz-dev.install.arm{el,hf}, and you fixed that with the debian/rules change
<ogra_> yeah, i wasnt serious
<Mirv> phase of the moon etc more likely
<ogra_> Mirv, well, still, there was a test i did that worked ...
<Mirv> I wonder if any runtime option would affect which backend is used
<ogra_> well, we ddint need one in the past
<ogra_> and i didnt need one when testing
<ogra_> oha !
<ogra_> Mirv, ok, downgrading to the test4 packages doesnt help
<infinity> The libreoffice failure just looks like mild dyxlexia.  s/VX/XV/ on debian/rules would make it happy.
<infinity> The diff makes it stick out fairly well:
<infinity> http://launchpadlibrarian.net/114223440/libreoffice_1%3A3.6.1~rc2-1ubuntu1_1%3A3.6.1~rc2-1ubuntu2.diff.gz
<infinity> I'd fix it, but I'm not uploading libreoffice from airport wireless. :P
<infinity> ScottK: ^--- New telepathy-qt should actually build on all arches, if you'd like to accept it for me.
 * infinity gets on his plane now.
 * Laney starts a -j8 build in The Cloud
 * ogra_ would appreciate if someone could let the new unity upload into the archive asap after it built (i just uploaded to -proposed)
<ogra_> it should fix the GLES issues
<ogra_> (one line fix)
<slangasek> ogra_: looking.  does that mean something wasn't tested before upload that should have been?
<ogra_> slangasek, it wasnt tested from what was uploaded to proposed, right, i tested from PPA builds
<ogra_> (which apparently worked, i spent half the day poking on compiz because i thougth it was at fault, but then discovered debian/rules in unity)
 * slangasek looks at the diff and sighs
<ogra_> yeah
<slangasek> ok, so is that fix committed to the right place now?
<ogra_> not yet in bzr (i found the upload more important, caring for bzr sync now)
<slangasek> ogra_: I notice the tree is not altogether clean (build cruft left behind); I'm going to scrub it and reupload
<slangasek> also, do you have any idea where the unity 6.4.0 orig.tar.gz is that should be here?
<ogra_> oh
<ogra_> intresting, no, and i dont have it in my test build chroot either
<slangasek> it wasn't in the previous version of the package that was uploaded, either
<slangasek> (which escaped notice when reviewing it, because queuediff doesn't show such things..)
<ogra_> seems that packae came down as a native one from the server already, i have a unity_6.4.0-0ubuntu1.tar.gz
<ogra_> phew
<ogra_> and all the desktop team gone ... i have no idea wheer the orgi tarballs come from
<ogra_> (and cant type)
<slangasek> did the ppa have one?
<ogra_> i dont even see 0.6.4 anymore https://launchpad.net/~unity-team/+archive/release/+packages?field.name_filter=&field.status_filter=published&field.series_filter=quantal
<ogra_> hmpf
<ogra_> slangasek, i'd say we leave that as a monday exercise for Mr. "foo" :)
<ogra_> i'll hunt him down on monday ...
<slangasek> yeah, I don't consider this a blocker
<slangasek> so why are there still separate patch series for arm vs x86 in the package?
<ogra_> good question, i havent looked into unity for a while apart from testing the binaries, the patch isonly  a one line change to CMakeLists.txt though
<ogra_> i'll ask the linaro GLES guys if we still need it
<ogra_> i dont really get why the test stuff didnt get cleaned up, i know i ran debian/rules clean before rolling the srouce package
<ogra_> *source
<slangasek> ogra_: or maybe it's still needed but it should be made a conditional relative to some of the other stuff that's already set
<slangasek> ogra_: did you run ./debian/rules clean with the architecture set to armhf? :)
<ogra_> no, just "fakeroot debian/rules clean" but on an armhf builder
<slangasek> hmm
<slangasek> ogra_: ok, so it failed to build on i386+amd64
<ogra_> err
<ogra_> [  3%] [  3%] /build/buildd/unity-6.4.0/obj-i686-linux-gnu/generated/networkarearegion.xml:1: parser error : Document is empty
<ogra_> ^
<ogra_> [  4%] ^
<ogra_> unable to parse /build/buildd/unity-6.4.0/obj-i686-linux-gnu/generated/networkarearegion.xml
<ogra_> oh my
<ogra_>  /build/buildd/unity-6.4.0/obj-i686-linux-gnu/generated/networkarearegion.xml:1: parser error : Start tag expected, '<' not found
<ogra_> i wonder why it didnt fail before, thats definitely not caused by my change
 * ogra_ starts to suspect that the cruft in the former debdiff is actually needed somehow
<slangasek> no, the cruft truly was cruft
<slangasek> this may be an over-parallelization bug
<ogra_> well, i see the networkarearegion.xml.in file in the .pot
<ogra_> i did my build with -j4 on the mx6 ... not sure how many jobs the buildd assigns by default on x86 indeed, but i had no probs building multithreaded
<slangasek> the failed amd64 build was -j8
<ogra_> hmm, k
<slangasek> so I actually didn't remove the changes to the .pot file, because those looked like a legitimate refresh rather than build cruft
<slangasek> but, double-checking
<ogra_> well, that must have been a refresh during my build
<ogra_>  # SOME DESCRIPTIVE TITLE.
<ogra_> -# Copyright (C) YEAR Canonical\ Ltd
<ogra_> +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
<ogra_> and that doesnt look so good
<ogra_> it also stripped the bugmail contact
<slangasek> it doesn't, but it was plausible that it was the legitimate output of a refresh
<ogra_> heh, the arm arches are both nearly done
 * ogra_ waits for an x86 deboostrap to finish and gets coffee ... 
<ogra_> yay for one line fixes that turn into nightshifts ...
<highvoltage> :(
<knome> highvoltage, nick revert?
<highvoltage> knome: yeah the new one didn't stick
<knome> highvoltage, are you sure you remembered to set it sticky? ;)
<highvoltage> knome: ah that must what I've been doing wrong!
<knome> :)
<ogra_> hmm, builds fine with -j8 on my amd64 machine
<ogra_> same on x86
<slangasek> ogra_: yeah, I gave the builds back
<slangasek> built fine for me here too; whatever it was, seems to be a latent problem
<ogra_> yup
<ogra_> and survived
<ogra_> hmm, each of my testbuilds has the same cruft in the debdiff
<ogra_> that package needs quite some love :)
<ogra_> i386 looks fine too now
<Mirv> I think the root problem for the mess was the non-updated lp:ubuntu/unity, which let to the original packaging branch being based off from earlier version and some merge wasn't then complete
<Mirv> or actually... the unity packaging was never right
<Mirv> ogra_: funny though that you had a "non-foo" unity build since only compiz ever had the architectures line specified correctly
<ogra_> Mirv, yeah, well, sorted for now ...
<ogra_> i'll talk to lukas next week
<ogra_> the clean target needs overhaul and it needs a proper tarball
 * ogra_ is tired now and calls it a day
#ubuntu-release 2012-09-02
<infinity> slangasek: Can you accept that telepathy-qt build fix of mine in the queue?
<slangasek> let's see
<slangasek> infinity: accepted
<infinity> slangasek: Shiny.  Worked in a PPA, so here's hoping the no-determinstic world of C++ symbols doesn't break it again. :P
<infinity> (I swear the list kept changing on every test build... Ridiculous)
<ogra_> argl !
<ogra_> please someone let the nux upload in, it has the same issue unity had
<ogra_> (trivial one line fix to make arm work)
<infinity> ogra_: Oops.
<infinity> ogra_: Are we holding unity up on the bizarre .pot diff?
<infinity> I guess queuebot answered that. :P
<ogra_> infinity, nah, slangasek said thats no stopper
<ogra_> GRRR
<ogra_> seems thats not enough for a buildd ... needs fixes for the deps too
<infinity> I take it you didn't test in sbuild?  Naughty Oli.
<ogra_> (it built in my chroot but that had unity b-deps already, grumble)
<ogra_> hmm, still doesnt work, i suspect we need a no-change upload for unity too after nux has built
<ogra_> sigh, thats such a mess
<infinity> ogra_: Look on the bright side.  You haven't wasted a long weekend with intense pain, foreign hospitals, and sitting in airports.
<infinity> And uploading libreoffice...
<ogra_> oh, yeah, tha latter is worst ...
<infinity> At least it gave me time to sort out the geis and friends library rename in oneiric.
<ogra_> no, i havent, but i promised my mom on friday to come back today ... so i dont have eternal time to hunt that mess down :/
<infinity> That was the last round of NEW for it.
<ogra_> i dont get why the packaging from precise was just carried over modulo the gles patch
<ogra_> *wasnt
<ogra_> infinity, now with fixed deps :)
<ogra_> thx
<infinity> NP.
<infinity> I need someone to review that LibO for me.
<ogra_> i can take a look for obvious stuff, but dont tryst my skills if it comes to C++
<infinity> It's make/shell.
<infinity> Just debian/rules.
<ogra_> *trust even
<ogra_> link ?
<infinity> http://launchpadlibrarian.net/114393345/libreoffice_1%3A3.6.1~rc2-1ubuntu2_1%3A3.6.1~rc2-1ubuntu3.diff.gz
<ogra_> well, looks sane ... what *is* ca-XV actually ?
<ogra_> chinese canadian ?
<infinity> Hahaha.  I have no clue. :P
<infinity> ca is Catalan though, isn't it?
<ogra_> oh, indeed
<ogra_> its funny that the typo isnt in the rm line
<infinity> The rm line was in the previous revision.
<ogra_> heh, k
<infinity> The 4 lines I changed were all new.
<infinity> (Well, the previous previous... You know what I mean)
<ogra_> we'll i'd say upload ... cant get worse anyway
<infinity> It's uploaded. :P
<infinity> But not accepted.
<infinity> I suppose it's a given that we want libreoffice built on i386, so I can fudge release management to use your review to leverage my other hat...
 * ogra_ wonders if slangasek's cats play with the cable 
<infinity> ogra_: I'll accept it and blame you.  Welcome to the release team for the next 10 seconds.
<ogra_> haha, go ahead
<ogra_> hmm, with the right b-deps nux takes significantly longer to build on arm
<infinity> ogra_: Hahaha.
<infinity> ogra_: I'd say that's likely a good sign. :P
<Laney> oh, nice, I was just going to upload LO
<infinity> Laney: Does your diff match mine?  That would be a nice sanity check.
<infinity> ogra_: nux copied to -release
<Laney> yeah, think so
<infinity> Laney: So you caught the missing "cat" too? ;)
<ogra_> infinity, yeah, i saw, thanks
<Laney> I lined up the &&s for sanity, then it stood out
<infinity> Laney: Fair enough. ;)
<Laney> that's about as far as the sanity goes
<Laney> probably enough libreoffice for the next year ;-)
<infinity> Amen.
<ogra_> infinity, one more unity upload and we're done ...
<ogra_> (no change ... should be in the queue in a second)
<ogra_> there it is
<ogra_> while there is a flickering issue when moving windows around (which i'm happy to release B1 with) it seems to all work fine ... yay
 * ogra_ will leave that bit to rsalveti :)
<Laney> ogra_: why the diff?
<ogra_> Laney, which diff ?
<ogra_> Laney, http://paste.ubuntu.com/1181348/
<ogra_> thats what i uploaded
 * ogra_ has to go now else my mom will get angry 
<Laney> ogra_: check the diff on Launchpad
<ogra_> url ?
<Laney> sec
<ogra_> i can only see approved stuff usually
<Laney> https://launchpad.net/ubuntu/quantal/+queue?queue_state=1
<Laney> https://launchpadlibrarian.net/114433172/unity_6.4.0-0ubuntu2_6.4.0-0ubuntu3.diff.gz
<ogra_> oh, ignore the diff.gz, better check with debdiff
<ogra_> 6.4.0 is a complete mess (accidentially uploaded as native etc)
<ogra_> the debdiff should be fine (there is no orig.tar.gz anywhere, not even in the unity PPA so we have to live with that mess until someone re-packages)
<ogra_> anyway, i'm hours late due to that sh*t and i'm out now
<Laney> I see the same thing when I debdiff
<Laney> yeah, gotta go fix my bike actually :P
 * ogra_ really didnt plan to woth through for two days including a half nightshift
<Laney> can look later
<ogra_> F*CK !!!!
<Laney> go away!
<Laney> /kick
<ogra_> why does LP show something different from what i see here
 * ogra_ doesnt get that 
<ogra_> anyway, out now, if it isnt fixed tonight when i return i'll take another look ... its just a rebuild after all
 * ogra_ waves
<jbicha> is it intentional that the i386 quantal daily has the German language pack but amd64 doesn't?
<Mirv> ogra_: the unity tarball was uploaded to https://launchpad.net/unity on Friday
<Mirv> https://launchpad.net/unity/6.0/6.4/+download/unity-6.4.0.tar.bz2
<stgraber> jbicha: yes
<stgraber> jbicha: there's more room on 32bit images than on 64bit
<jbicha> stgraber: what limit are we shooting for, for quantal? because if it's 800MB, we have room, right?
<stgraber> jbicha: it's usually something we tweak around release but yeah, we'll likely fill some of the remaining space on all images with langpacks
<stgraber> though i386 will still likely have more langpacks than amd64, just because the files tend to be smaller, leaving more room for langpacks
<jbicha> ok, cool
<Laney> ogra_: rejecting yours, mine has the expected diff
<Laney> stgraber: could you maybe look at unity please? (no-change rebuild)
<stgraber> Laney: sure
<stgraber> accepted
<slangasek> ogra_: nah; I seem to have been having some IPv6 routing problems last night
<Laney> oh. argh.
<Laney> https://launchpad.net/ubuntu/+source/unity/6.4.0-0ubuntu3
<ogra_> Laney, thx, checking the log
 * ogra_ scratches head 
<ogra_> that cant be ..
<ogra_> it doesnt do that in a local build
<ogra_> hmm, i wonder why
<ogra_> given that dash/previews/CMakeLists.txt actually hadcodes the linker stuff
<ogra_> *hard
<ogra_> Mirv, any idea about https://launchpadlibrarian.net/114534081/buildlog_ubuntu-quantal-armel.unity_6.4.0-0ubuntu3_FAILEDTOBUILD.txt.gz woudl be appreciated
 * ogra_ really isnt good at cmake
<ogra_> i understand that -lGL -lGLU is hardcoded in dash/previews/CMakeLists.txt
<ogra_> (i still dont understand why it builds locally ... i actually built that version twice successfully here )
<iulian> Why are new versions of packages being uploaded without a bug reference number? The diff is huge and impossible to review. :-(
<ogra_> what package are you referring to ?
<iulian> ogra_: nemiver, caribou, genius.
<iulian> They were uploaded just a few minutes ago.
<ogra_> well, its universe, does FF apply there ?
<Laney> FF certainly does, beta freeze not
<ogra_> hrm, the cmale syntax doesnt seem to know "else"
<iulian> They should've been approved first before uploaded.
<ogra_> *cmake
<rsalveti> ogra_: I'm working on trying to get the kernel in place for a fully working unity on panda now
<ogra_> rsalveti, well, i would first like a working unity at all
<jbicha> caribou is a GNOME micro-release on the way to the next stable release so that should be fine
<rsalveti> ogra_: what is the issue still?
 * rsalveti just got back from plumbers
 * ogra_ already spent his whole weekend to sort that mess
<ogra_> /usr/bin/ld: cannot find -lGL
<ogra_> /usr/bin/ld: cannot find -lGLU
<ogra_> https://launchpadlibrarian.net/114534081/buildlog_ubuntu-quantal-armel.unity_6.4.0-0ubuntu3_FAILEDTOBUILD.txt.gz
<ogra_> some new code that hardcodes GL
<rsalveti> I just the bug you sent me, but I believe it was all lack of the right build dependencies?
<rsalveti> :-((
<ogra_> funnily i can build it locally in a clean chroot on armhf without *any* issue
<iulian> jbicha: I can't see any bugs mentioned in the changelog. How are we supposed to know that? :(
<ogra_> rsalveti, looking at dash/previews/CMakeLists.txt ... there is  ....  set (LIBS ${CACHED_UNITY_DEPS_LIBRARIES} "-lunity-core-${UNITY_API_VERSION} -lm -lGL -lGLU") ...
<rsalveti> oh, hardcoded
<ogra_> i could just override that with an if (${CMAKE_SYSTEM_PROCESSOR} STREQUAL "armv7l") it seems ...
<ogra_> but there is no "else" command and i'm not sure if one set just overrides a formerly set one
<rsalveti> I believe there's a way to depend on when you're building for gl or gles
<ogra_> read: i have not much clue about cmake
<ogra_> that seems to be our last showstopper
<jbicha> iulian: the NEWS entry in the caribou diff is rather small...
<rsalveti> alright, will set my builders and machines so I can give it a try
<ogra_> my locally build unity works just fine (apart from an off flickering bug but i'm willing to live with that for B1)
<rsalveti> ogra_: at least we have all the right packages in place already, right?
<rsalveti> I mean, the version which all supposes support gles
<ogra_> rsalveti, yup, compiz and nux are fine now
<rsalveti> yeah, cool
<ogra_> and the current desktop image has PVR OOTB
<rsalveti> that's great :-)
<ogra_> right on first boot
<rsalveti> ogra_: will take a look in a few
<rsalveti> the kernel changes are also possible for b1, but not that critical I'd also say
<rsalveti> and the changes are quite intrusive, so we'd probably need a few days for testing and such
<ogra_> rsalveti, thx, i'm really getting exhausted after the second day with the same crappy stuff
<ogra_> yeah, lets keep them for post beta
<rsalveti> cool
<ogra_> the current kernel is ok ... it boots and all devices seem to work :)
<rsalveti> yeah :-)
<ogra_> oh, if you touch unity, beware, it somehow turned into a native package with the last upstream dump
<rsalveti> oh, ok
<ogra_> and the clean target doesnt seem to properly clean up, check your debdiffs ;)
<rsalveti> haha, ok :-)
<iulian> jbicha: I've just noticed it's a bug fix upload. It would've made my life a lot easier if I had seen "bug fix release" somewhere in the changelog. I personally first read debian/changelog when I review things so I know what to expect.
<micahg> Laney: with the new ubuntu-gnome, beta freeze might indeed apply to those packages
<ogra_> micahg, why, does it apply to xubuntu or lubuntu (beyond what they define as freeze themselves)
<ogra_> ?
<jbicha> caribou is the only one out of that set that is part of ubuntu-gnome
<micahg> ogra_: beta freeze applies to packages that affect all images (I was supposed to fix the wiki)
<micahg> s/all/any/
 * micahg does that now
<ogra_> ah, k
<ogra_> i thought its up to the flavours to decide that for their packagesets
<micahg> ogra_: flavors can decide if something should get in or not if it only affects them
<ogra_> yeah, thats what i remembered
<micahg> but they still need to coordinate with the release team and not just blindly upload
<micahg> if anyone wants to review https://wiki.ubuntu.com/BetaFreeze?action=diff&rev2=8&rev1=7 to make sure I didn't miscommunicate anything
 * ogra_ finds it confusion that the wiki marks deletions in green
<ogra_> *confusing
<ogra_> micahg, i would add a line about flavurs
<ogra_> i.e. "this also applies to derivative flavour images built in the ubuntu infrastructure" or some such
<micahg> ogra_: saying what?  flavors ship images the same as anyone else
<micahg> ok
<micahg> done
<ogra_> perfect :)
<xnox> micahg: ogra_: my understanding was that we were meant to use proposed somehow....
<ogra_> well, yes and no :)
<micahg> xnox: yeah, I didn't include anything about that as the previous version didn't :)
<ogra_> proposed in any case for sets of packages that have a dependency chain
<micahg> proposed can be used during freeze to continue uploads as well
<micahg> oh, hrm, maybe not this time around :)
<micahg> wasn't included in the release announcement
<ogra_> well, it will still work as last time :)
<slangasek> ogra_: so in nux supposed to be fixed now in quantal?  compiz still segfaults for me here
<ogra_> do you run compiz standalone without unity ?
<slangasek> ogra_: I'm trying to use the default desktop
<ogra_> (else its likely unity that segfaults ... unity being a set of compiz plugins somewhat hides where the crash actually comes from)
<ogra_> (thats actually why i spent so much time in looking into compiz instaed of unity in the beginning yesterday
<ogra_> )
<ogra_> slangasek, i just updated bug 1044709
<ubot2`> Launchpad bug 1044709 in unity "unity-6.4.0 from quantal-proposed crashed with SIGSEGV on omap4" [Critical,Fix released] https://launchpad.net/bugs/1044709
<ogra_> slangasek, and rsalveti is looking into fixing it
<ogra_> what i still dont get is why it builds properly in a local chroot on armhf here
<ogra_> i could give you properly working binaries :) my panda desktop runs just fine over here
<slangasek> ogra_: so that unity task should be reopened then?
<ogra_> yes
<ogra_> something like this should fix it i guess http://paste.ubuntu.com/1182513/
<ogra_> (untested and not 100% sure since i dont speak cmake ...)
<ogra_> but i guess rsalveti has a better and cleaner way
<ogra_> (or will find one at least)
<slangasek> well, the first part shouldn't be done that way... -fPIC should be the default, not the exception
<slangasek> (and I wonder if they have a good reason for not using -fPIC on i386)
<ogra_> it is like that in all other CMakeLists.txt files in the source
<ogra_> that part i just took over from the others
<slangasek> oh; then I guess unity is completely broken on powerpc
<slangasek> because that sure isn't going to work on any !x86 arch :P
<ogra_> well, as i said, it works fine on armhf (even without that fix) over here ... i must have a magic chroot or something ...
<ogra_> i even re-rolled the chroot today to make sure its clean
<ogra_> (several times)
 * ogra_ sets the bug back to triaged
<xnox> ogra_: cmake syntax looks valid, but it is not very CMake'ish way to set -fPIC
<xnox> slangasek: while I agree that -fPIC should be the default, but little does CMake care....
<ogra_> xnox, yeah, starting a testbuild now, i have set up my build env completely from scratch now, we'll see how it goes
#ubuntu-release 2013-08-26
<darkxst> infinity, hi, can organise someone to setup ddebs on that ppa today (ppa:gnome3-team/gnome3-next), thanks!
<slangasek> ara, stgraber: looks like we're sorted now wrt old-releases?  (apparently it required a manual sync by IS?)
<stgraber> slangasek: the sync is still failing but at least they triggered one manually
 * slangasek nods
<slangasek> which should be as many as we need for the next few months
<ara> cool, thanks!
<rtg> sarnold, can you process bug #1214979 now that the point release is done ?
<ubot2`> Launchpad bug 1214979 in apparmor (Ubuntu Precise) "Feature buffer full in precise with LTS kernel" [Undecided,Fix committed] https://launchpad.net/bugs/1214979
<sarnold> rtg: yes, thanks for the reminder
<NikTh> Hello,
<NikTh> Can someone to change this[1] please ?  [1] - http://i.imgur.com/McFyLrP.jpg
<infinity> NikTh: Yup.
<NikTh> infinity: Thanks :-)
<slangasek> grumble, how'd I miss that
<slangasek> infinity: thanks
<infinity> slangasek: Because the front page indexes are done by hand, and someone always forgets a bit?
<slangasek> well, I followed the checklist
<slangasek> so maybe the checklist is missing a bit
<infinity> NikTh: Done.
<infinity> slangasek: It could be missing the "verify correctness of simple/HEADER.html" bit.
<NikTh> Also here https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop , the LibreOffice version is 3.5.7 , not 3.5.4 .. but this I can change it my self :-)
<infinity> slangasek: Although, publish-image-set used to have some verbage to that effect, I thought.
<slangasek> infinity: publish-image-set has some verbiage which is completely wrong for the point release, fwiw
<infinity> slangasek: That would do it. :P
<NikTh> infinity: Maybe the 10.04.4 LTS should be removed from there ? Or place a (server only) next to it ?
<infinity> NikTh: Certainly not removed.
<infinity> NikTh: You'll note if you click through that it only has server ISOs, I archived the desktop ones off.
<NikTh> infinity: Yes, you have right.  Server Install CD , only. OK.
<infinity> I suppose if we think people are trying to make informed decisions about what to install based on that page, either a prominent pointer to a lifecycle page on the wiki, or an "(Approximate EOL: Foo 13, 20XX)" after each one might be helpful.
<infinity> If I could remember the name of the wiki page with the release/eol dates...
<NikTh> infinity: https://wiki.ubuntu.com/Releases
<infinity> NikTh: Danke.  You'd think I'd remember that, given the edits I've done to it.
 * infinity is still convinced that wikis are where data goes to die.
<NikTh> infinity:  :-)
<NikTh> Question (of topic a little bit). gnome-session --version , results in 3.2 version (on 12.04.3 LTS) , but "system monitor"(GUI) reads 3.4 version of Gnome. How you define the gnome version in an Ubuntu release ?
<slangasek> xnox: bug #1216853> er... since when do we support PXE booting livefs images?
<ubot2`> Launchpad bug 1216853 in casper (Ubuntu) "LiveCD missing nfs/crypt kernel modules in the initramfs - During PXE booting failed to mount nfs directory" [High,Confirmed] https://launchpad.net/bugs/1216853
<cjwatson> since years
<cjwatson> I remember lifeless (I think) helping to get that working way back when
<cjwatson> well, I don't know about "support" since it isn't well-tested, but it is meant to work
<slangasek> oh, hmm
<slangasek> I thought we only PXE booted the d-i images
<cjwatson> it was definitely made to work end to end with ubiquity at one point
<cjwatson> ... or at least live session booting, but I think ubiquity too
<xnox> yeah, it does work and i think even someone deploys desktop machines like that.
<xnox> let's see if fixing bug 1217041 resolves bug 1216853
<ubot2`> Launchpad bug 1217041 in initramfs-tools (Ubuntu Precise) "initramfs-tools: please include separated nfs modules" [Undecided,Confirmed] https://launchpad.net/bugs/1217041
<ubot2`> Launchpad bug 1216853 in casper (Ubuntu) "LiveCD missing nfs/crypt kernel modules in the initramfs - During PXE booting failed to mount nfs directory" [High,Confirmed] https://launchpad.net/bugs/1216853
<infinity> xnox: Oh bah, I thought I backported that to precise. :/
<xnox> infinity: =/ happens. I am confused about crypt modules. cryptsetup was changed to only include them in the initramfs, if needed or if a flag variable is set. Can live-cd somehow include crypt modules in the initramfs unconditionally?
<infinity> xnox: The problem is that that won't fix the ISO, even if we backport it now.
<infinity> (Unless we respin the point release)
<xnox> infinity: well not 12.04.3, but i somehow thought precise-daily will get fixed and well 12.04.4.
<xnox> Yeah, -rc7 which hopefully fixes javac SEGV =)
<xnox> infinity: are precise-dailies build with -proposed enabled again?
<infinity> xnox: Nope, but could do.
 * infinity tried to remember the syntax...
<infinity> slangasek: When you tore all the PROPOSED out of crontab, was it "PROPOSED=1"?
<slangasek> infinity: yes
<slangasek> is that what we want at this point?
<slangasek> or should that only be done for one-off testing?
<infinity> slangasek: Why not?  May as well have proposed enabled up until a few weeks before .4
<infinity> It shouldn't suffer the same consistency/installability issues that devel-proposed does, and if it does, we want to know about it anyway.
<slangasek> well, ok
<infinity> xnox: precise-daily is all proposey again.
 * infinity still finds it bizarre that anyone outside our QA labs would consider PXE booting the desktop CD a sane and reasonable option.
<infinity> Different strokes, I guess.
<xnox> slangasek: infinity: i guess the price cd will gain all the verification-failed packages which haven't been removed from -proposed.
<infinity> xnox: That's fine.  It's incentive for us to actually remove stuff from proposed. :P
<slangasek> cjwatson: so can you remind me the rationale for https://help.ubuntu.com/community/UbuntuHashes and it's annoying immutability?
<slangasek> s/it's/its/
<infinity> slangasek: I think the rationale was that it's https, and provides a trust path for people who don't/can't trust the GPG signed hashes for some weird reason or other.
<infinity> (A weak rationale, to be sure, but there it is)
<infinity> It could use all the EOL releases removed...
<slangasek> is that something we want to encourage, though?  (maybe, maybe not - just want to make sure we have a clear and understood rationale for this thing that lives outside ubuntu-cdimage's control and causes more work)
<infinity> I'm not sure.  The argument seems a bit dubious when it's indistinguishable from a random wiki page that could also be https and made to look identical with incorrect values.
<slangasek> well, it's a "well-known" address, it's https, and it's not generally modifiable
<infinity> Perhaps replacing it with a GPG verification HOWTO (including Win32 instructions) might not be a bad plan, and https links to our signing keys.
<xnox> infinity: where are the GPG key fingerprints published? not many have trust of path to that, is there some https location with those?
<infinity> xnox: We could make one.
<infinity> (If there isn't one already)
<slangasek> if we do, please make sure that updating it becomes part of the documented key rotation process
<xnox> a fingerprint is listed here: https://help.ubuntu.com/community/VerifyIsoHowto but that's not explicit, just a by-product of the procedure output.
<infinity> slangasek: Or have it automagic somehow.
<slangasek> infinity: which is not going to happen day 1, so it needs to be documented :P
<xnox> http://archive.ubuntu.com/ubuntu/project/ has the keyring.
<slangasek> not the cdimage keyring
 * xnox never knew we have souce.isos
<infinity> We ship the cdimage key in the ubuntu-keyring package, is that not the same keyring found on /ubuntu/project/?
<slangasek> infinity: why would we ship the cdimage key in the ubuntu-keyring package?  Oh, is that needed for trusting the apt sources on alternate CDs?
<infinity> slangasek: That, yes.
<infinity> slangasek: See `apt-key list`
<slangasek> hmm, ok
<slangasek> regardless, the point is to have an https trust path for those that don't already have the joy of running Ubuntu
<infinity> Right, so an automated process that tears out the keyring from ubuntu-keyring and dumps it to a well-known https location doesn't sound like it'd be rocket surgery.
<infinity> In both GPG keyring format and massive ASCII-armored blob of doom.
<infinity> A bit of work, sure, but would cut down on skinning cats seven different ways down the road.
<infinity> And, realistically, anyone who can't be bothered to set up PGP/GPG to test the MD5SUM signature probably also won't do due diligence to make sure our SSL cert is trustworthy in any meaningful way. :P
<infinity> (Alternately, we could stick with the status quo, but maybe open up the list of people who can update that page a little bit...)
<sarnold> if we're redesigning things, I'd quite like an .asc file for each .iso, to save the hassle of downloading a sha256sums file and seeing a few dozen FAIL messages, or juggling three or four sha256sums files depending upon the versions of ubuntu I've downloaded
<sarnold> if we had a nice gpg detached sig for each iso, there'd be no name collisions and no dozen listed files that I _didn't_ download..
<infinity> sarnold: The only minor concern with that is that it makes the directory a bit messier and confusing to people who have no idea what an "asc" is, download the wrong file, and wonder why they can't burn it.
<infinity> One would hope that people that easily confused are downloading via direct links from www.u.c/download, but I suspect that's not always true.
<sarnold> infinity: yeah, it would roughly double the files in each directory. But I hope the one-second download time might be a clue that it isn't a full-featured operating system they just downloaded :)
<infinity> sarnold: Maybe it's just really efficient?
<sarnold> infinity: haha, very efficient :)
<infinity> sarnold: I'm sure I could download some old Slack or Debian floppies on my link in a second or so.  That Linux thing isn't supposed to be bloated like Windows, right? :)
<sarnold> infinity: just be sure you've got at least 16 megabytes of RAM if you're going to use X11!
<darkxst> infinity, hi
<infinity> darkxst: Yo.
<darkxst> infinity, can you get those ddebs sorted for me ;)
<infinity> darkxst: Remind me of which PPA it was?
<darkxst> ppa:gnome3-team/gnome3-next
<infinity> darkxst: Iz done.
<darkxst> infinity, thanks ;)
<xnox> infinity: can linux-signed be hinted to not wait for autopackagetest of a wrong version to pass, the right version has passed.
<infinity> xnox: Yeah, I'll hint it in a bit, and try to get someone to dig deeper into WTF goes wrong there.
<stgraber> cjwatson: FYI I'm going to override the autopkgtest result for network-manager as britney seems to be confused. It's the second upload where it thinks it's still running even though it passed.
#ubuntu-release 2013-08-27
<cjwatson> slangasek: It's not immutable to me :-)  I argued against its existence to start with, but it's fairly entrenched now; I'm inclined to agree that autoupdating it is the right answer
<cjwatson> stgraber: The cases where it thinks it's still running need jibel to investigate, in general
<Laney> I'd be interested in knowing what went wrong
<Laney> we were kind of hamstrung and it would have been nice to know where to poke
<jibel> cjwatson, stgraber I'm investigating that case, that's my priority for this week
<jibel> and also why tests are not requested when new autopkgtest are introduced
<cjwatson> jibel: Thanks.  There was lots of interest at DebConf in what we're doing, and I directed a few people towards you for details
<psivaa> cjwatson: infinity: not sure if you've already been notified.. but http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/saucy/daily-20130827.log does not look as usual
<psivaa> for saucy server images
<ogra_> psivaa, wow, that are fast builds at least ...  just 1min buildtime
<ogra_> :)
<cjwatson> psivaa: did somebody already respond while I was offline?
<psivaa> cjwatson: ogra_ did :) but i see you'd have been online by then
<cjwatson> I meant respond in a way that indicated investigation of the cause :)
<cjwatson> looks like royal is having some trouble, although it's not entirely dead; I'll ask IS
<ogra_> i did only respond with a pointlessly bad joke
<psivaa> cjwatson: ogra_: ok thanks
<cjwatson> Roll on livefs builds in LP
<Ampelbein> Hi there. A question about the -proposed migration: The package emscripten, https://launchpad.net/ubuntu/+source/emscripten, is not considered for migration because on powerpc one of it's depends is uninstallable (nodejs). But since emscripten was never in Ubuntu before, shouldn't it be allowed to migrate despite this problem?
<cjwatson> No.  If it weren't built on powerpc at all, that would be fine, but you aren't allowed to increase the number of uninstallables.
<Ampelbein> Ok, I see.
<cjwatson> bdmurray: I fixed a phased-updater crash triggered by a recent change to the override file
<bdmurray> cjwatson: I see, thanks
<xnox> skellat: release in may? =)))))
<xnox> ARghhh
<skellat> xnox: Nope, just careful timing is all
<xnox> =))))
<skellat> xnox: Yikes, vUDS-1311 will have me out for at least one day as I have an election on November 5th I'm probably going to be ordered to help conduct as a poll judge/returning officer.
<skellat> That'll be a 13 hour day for me ensuring Ohio's election laws are enforced.
<xnox> skellat: =/
<xnox> skellat: but but but T release schedule timings have been known for years! =)))))
<slangasek> whereas US election dates have been known for centuries
<xnox> slangasek: O RLY?! =) i didn't know that.
<skellat> Yeah, the first Tuesday in November is usually a General Election in most jurisdictions in the US
<skellat> This is an off-year but we've got local candidates (I didn't make the ballot as one) and a bunch of tax levy questions up
<slangasek> xnox: yeah, none of that "let's dissolve the government, la-de-dah" here ;)
<skellat> Ballotpedia.org has a bunch of elections listed (Ohio's are strangely missing) for November 5th so having UDS in week 3 of the cycle may not be a good thing for US participation
<xnox> slangasek: did I tell you, I'm trying to naturalise as Scottish? =)
<slangasek> xnox: so I assume you've already talked to Phil Hands about getting yourself a Debian kilt
<xnox> slangasek: not sure there is enough people to make a new order. the fabric is special.
<ogra_> does it have swirls ?
<ogra_> woevn in ?
<ogra_> *woven
<slangasek> no, it's a proper tartan
<slangasek> that happens to spell Debian in morse code
<sil2100> infinity: hello! Did you have time to browse through the patches for the XIM SRU thing?
<sil2100> infinity: (bug #1043627)
<ubot2`> Launchpad bug 1043627 in nux (Ubuntu Raring) "[SRU] Add XIM Support to Nux" [Undecided,Confirmed] https://launchpad.net/bugs/1043627
<infinity> slangasek: It's Debian in morse?  I never knew that.
<slangasek> yep
<ogra_> heh
<ogra_> revealing easter eggs :)
<infinity> sil2100: Not yet, no.  I'll try to get to it Soon(tm).
<knome> infinity, slangasek: haven't talked with the team closely yet, but i suspect xubuntu would like one alpha and two betas for T
<slangasek> knome: good to know, thanks
<knome> i don't think exact dates matter too much to us, but obviously that might change, especially if there is any hope xfce 4.12 would be landing
<skellat> Of which we still haven't been advised by upstream.
<infinity> knome: Is 4.12 the mythical GTK3 release?
<knome> but for now, i wouldn't refrain from scheduling anything because that "might" land
<knome> infinity, no.
<infinity> knome: Kay.  Cause I was going to say, I wouldn't count on that landing. :P
<skellat> Lets hope Xfce 4.12 doesn't become Duke Nukem Forever
<knome> infinity, some parts have optional gtk3 modes built-in
<knome> tbh, i wouldn't count on anything landing, xfce having only one active core developer at the moment
<knome> we've already been starting to prepare the possibility to cherry-pick some 4.11 (4.12 development) features
<knome> even for the LTS.
<skellat> Noskcaj has been hard at work on that in Ubuntu and upstream in Debian
<pkern> Is the SRU queue patch piloted? :)
<xnox> infinity: when you have time can you please move liblzo2-2-udeb  to main, to unbreak installing onto btrfs (for those who do it....)
<cjwatson> I'll do that now
<cjwatson> (done)
<xnox> thanks.
<sarnold> RAOF: hello :) I'm trying to push along the apparmor package that has been in precise-proposed for a while. I finished validation on the 2.7.102-0ubuntu3.8 version for 1091642 987578 and 982619 last week. That version has spent over 100 days in -proposed. Kernel team and server team would quite like the 2.7.102-0ubuntu3.9 version for 1214979.
<infinity> pkern: Anything with ubuntu-sponsors subscribed is patch piloted.  Target release isn't particularly relevant.
<sarnold> RAOF: which would be best? pushing the 3.8 version in, since it has passed verification on its three bugs and has waited for over 100 days? or dropping it, pushing 3.9 into precise-proposed, and then re-verifying 3.9 against all four bugs?
 * jdstrand votes for the former
<jdstrand> but I don't have a vote
<cjwatson> well, I'd do the former but you marked it all v-needed again :P
<jdstrand> if I did, it would be a shiny, very strong vote
<infinity> I'll release it as-is, I've looked at the bugs.
<infinity> I looked at this last week too, but we were mid-freeze, ish.
<sarnold> cjwatson: I'd be happy to reset them all back to verification-done :)
<infinity> sarnold: Do so, please.  But that won't change when I run the scripts. ;)
<sarnold> infinity: hehe, thanks :)
<infinity> Oh, bah, but I used my hacked-up sru-release that doesn't twiddle bugs.
<infinity> Oh well.  It's released regardless.
<infinity> Just very stealhtily.
<infinity> * Previous update closed (LP: #982619) (LP: #1091642) and (LP: #987578)
<ubot2`> Launchpad bug 982619 in apparmor (Ubuntu Precise) "aa-logprof wrongly transforms PUx to UPx" [High,Fix released] https://launchpad.net/bugs/982619
<ubot2`> Launchpad bug 1091642 in apparmor (Ubuntu Quantal) "apparmor parser fails due to matchflags not being reset" [Undecided,Fix released] https://launchpad.net/bugs/1091642
<ubot2`> Launchpad bug 987578 in evince (Ubuntu) "Evince is not allowed to use exo-open" [Low,Fix released] https://launchpad.net/bugs/987578
<infinity> sarnold: ^-- The right way to do that is "dpkg-genchanges -S -v(last-version-in-updates)"
<infinity> sarnold: Mentioning the bugs again in your new changelog entry is just confusing. :)
<infinity> sarnold: (Not that it matters now, since we released the previous version instead)
<sarnold> infinity: good point. I didn't realize there'd be a better way to do that. I'd be happy to fix te changelog and ask jdstrand to re-upload a fixed 3.9.
<infinity> sarnold: Can you reupload that with that changelog line dropped, just to satisfy my anal-retention?
<infinity> Or, I can for you.  *shrug*
<infinity> I'll just do it, since I'm here.
<sarnold> infinity: cool, thanks. :)
<infinity> And now I get to see how sru-review behaves when there's two of something in the queue.  Kinda curious.
<infinity> Ahh, correctly.  Good.
<infinity> sarnold: Oh, hah.  There's also one in the queue from Tim before yours.  You guys REALLY wanted to fix this, I see. :P
<sarnold> infinity: oh there is? we also really failed to communicate, I see.
<sarnold> infinity: yes, yes we did. :)
<infinity> sarnold: Yeah, he beat you by 5 days.  They're identical except for the changelog, I'll take his. :P
<sarnold> infinity: nice, that's encouraging. :)
<infinity> Actually, no.  I'll take yours.  Your changelog entry is less pants.
<pkern> infinity: Ok thanks. (I used another launchpad account that's not actually a MOTU, but it's for main so it probably doesn't matter much.)
<utlemming> who owns the CSS sheet at http://releases.ubuntu.com/include/style.css?
<cjwatson> ubuntu-cdimage
<utlemming> cjwatson: the style sheet was updated recently with the png files being relative. That broke cloud-images.ubuntu.com
<cjwatson> Eh, by "recently" I guess you mean "about a year ago"
<utlemming> cjwatson: while it worked until recently. Looking the wayback machine, link went from http://releases.ubuntu.com/include/bg_dots.png to bg_dot.png
<cjwatson> -rw-r--r-- 2 cdimage cdimage 1647 Sep  4  2012 style.css
<cjwatson> if it broke recently then it's not the fault of the CSS ...
<infinity> My new hobby: touching files with timestamps from the past to confuse people.
<cjwatson> cloud-images.ubuntu.com seems to have the background dots for me
<utlemming> cjwatson: what is your browser?
<cjwatson> firefox
<utlemming> cjwatson: version? my firefox doesn't show it
<cjwatson> 23.0, default in saucy
<utlemming> cjwatson: okay, thanks, I'm running the same. I'll dig further
<cjwatson> and relative paths in CSS files are defined to be relative to the CSS file
<infinity> You could be set to some intensely paranoid cross-site sadness setting.
<cjwatson> so it should work fine
<infinity> But it works here in a not-really-tweaked Firefox and Chrome.
<Ampelbein> utlemming: Are you connecting via https maybe?
<utlemming> yeah, I am
<utlemming> and going http fixes it
<infinity> Right, so your browser is blocking the https/http mix, most likely.
<Ampelbein> And rightfully so.
<infinity> Might even be a subtle icon telling you about it.
<utlemming> infinity: you win the prize, "firefox has blocked content that is not secure"
<Ampelbein> So the site needs to be fixed to not include style sheets, scripts or whatever over http when https is requested.
<infinity> Or just host the content locally and use relative paths instead of abusing releases.ubuntu.com.
<cjwatson> I'd recommend the latter.
<cjwatson> And mixed content blocking by default is new in Firefox 23, which is why you've only just started noticing this.
<elmo> this is what assets.ubuntu.com is for
<elmo> it has these kind of things on both http and https
<tkamppeter> sarnold, hi, did you already have a look into openjpeg?
<elmo> FYI
<elmo> utlemming: ^--
<utlemming> elmo: thanks for the tip, most appreciated
<sarnold> tkamppeter: yes, I'm working on it now. from what I've seen so far it's some -gross- code. :(
<tkamppeter> sarnold, what does -groos- code mean?
<tkamppeter> s/groos/gross/
<sarnold> tkamppeter: a fair number of warnings from gcc, at least one for "uninitialized variable", where the code path choice is controlled by the value on the far end of a pointer. confusing signed char and unsigned char. casting the return value from malloc.
<tkamppeter> sarnold, there are two projects about JPEG2000, libopenjpeg and libjasper, what is the one to be preferred?
<sarnold> tkamppeter: I'm sorry, I haven't looked at libjasper.
<sarnold> tkamppeter: do you know why the poppler project picked openjpeg?
<tkamppeter> sarnold, I found out now why we switched to libopenjpeg in GS: Performance, see http://bugs.ghostscript.com/show_bug.cgi?id=692002.
<ubot2`> bugs.ghostscript.com bug 692002 in JPX/JBIG2 encode/decode "Jpeg 2000 decoding is EXTREMELY slow" [Normal,Resolved: fixed]
<sarnold> tkamppeter: aha. pity that none of them reported before and after timings on the same machine.
<sarnold> tkamppeter: thanks for satisfying my curiosity there :)
<tkamppeter> sarnold, so seems that openjpeg is the faster but less clean code.
<robert_ancell> how do I find what is keeping mir in -proposed?
<slangasek> robert_ancell: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<slangasek> according to that, it's a "valid candidate"
<slangasek> however, according to http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt, it makes a number of unity packages uninstallable?
<slangasek> does unity-mir need an upload?
<robert_ancell> slangasek, thanks!
<slangasek> ah - back on update_excuses, unity-mir has an unsatisfiable dep on libmirserver1, so I guess that's the root problem
<robert_ancell> huh, I wasn't aware unity-mir was in the archive...
<robert_ancell> slangasek, could unity-mir be blocked because it attempts a ppc build and mir no longer builds against ppc?
<robert_ancell> so it's sitting in depwait
<slangasek> robert_ancell: no, it's blocked because it has a dependency on all archs on a version of libmirserver1 that proposed-migration says isn't there
<slangasek> unity-mir isn't even built on ppc
<robert_ancell> slangasek, https://launchpad.net/ubuntu/+source/unity-mir/0.1+13.10.20130827-0ubuntu1/+build/4910196 says it's in depwait
<slangasek> yes, but the powerpc depwait is completely ignorable
<slangasek> the problem is the *currently up-to-date* binaries on unity-mir in saucy-proposed were built against a *previous* version of libmirserver1
<slangasek> and since the dep on libmirserver1 is a strict versioned dep, unity-mir needs a rebuild
<slangasek> this can be reproduced locally by enabling saucy-proposed (in a chroot) and trying to install unity-mir
<slangasek> rather, trying to install libunity-mir1
#ubuntu-release 2013-08-28
<robert_ancell> slangasek, it looks like the dependencies are built on version-1 of mir, which is the problem. I'll email didrocks and see if the autolander is malfunctioning on this
<slangasek> robert_ancell: ok.  AIUI didrocks is on vacation this week, so if this needs to go through now-ish and is otherwise ok, you might just want to do a no-change rebuild of unity-mir to saucy?
<robert_ancell> slangasek, ah, ok
<robert_ancell> thanks!
<Laney> do we have germinate output for touch builds?
<Laney> does it even use germinate?
<infinity> Laney: It uses metapackages (ubuntu-touch) instead of tasks right now.
<infinity> Though, that should probably change.
<Laney> yeah I wanted it for the "why is this package in the image" part of the output
<Laney> oh well
<infinity> Laney: So, the answer is "sort of".  It has a seed, and the meta source uses germinate, but we don't germinate its tasks and use them to build images.
<xnox> This cycle redhat-cluster got split into separate packages, and some portions dropped. One of the re-introduced packages from the split is dlm, which is needed to build clvm binary from lvm2 package.
<xnox> i have now uploaded lvm2 with build-dep on libdlm-dev, can dlm please be promoted back to main?
<xnox> bug 1213132
<ubot2`> Launchpad bug 1213132 in dlm (Ubuntu) "[MIR] dlm" [Undecided,New] https://launchpad.net/bugs/1213132
<xnox> build-dep https://launchpad.net/ubuntu/+source/lvm2/2.02.98-1ubuntu5
<cjwatson> doko_: xnox done
<cjwatson> err
<cjwatson> sorry doko_
<cjwatson> xnox: done
<cjwatson> could somebody NEW-process packagekit-qt for me?  I was the sponsor
<Riddell> infinity, slangasek: I think we'd like to be part of all alphas/betas
<Riddell> cjwatson: I'll take a look
<cjwatson> ta
<jbicha> can you let eclipse-cdt migrate to saucy? it's depwait on armhf because of eclipse
<cjwatson> that amounts to a request to remove eclipse-cdt/armhf, I guess?
<jbicha> yes
<cjwatson> I'll get back to you once lillypilly gets back to me
 * Laney calls for beta 1 participants
<Laney> just noticed that the schedule has a freeze tomorrow and I signed up for this one
<ogra_> didnt we just have an alpha ?
<Laney> depends how you define 'just', I suppose
<Laney> july 25th
<ogra_> a blink of an eye ago :)
<ogra_> geez, time flies if you play with phones
<Laney> you might be getting confused with 12.04.3
<ogra_> nah ... but i was convinced the alpha was this month
<ogra_> obviously not :)
<mlankhorst> quick must get 9.2 in soo nthen :P
<Laney> pheature phreeze
<mlankhorst> can llvm-3.3 be moved to main?
<mlankhorst> https://launchpad.net/ubuntu/saucy/+source/mesa/9.2-1ubuntu1
<ogra_> does anyone have an idea whats up with alsa-lib in proposed ? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html shows it as valid candidate .... and i cant find any blockers, but it still didnt come out
<ScottK> ogra_: Looking at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt - it looks like it succeeded on the last run.
<ogra_> ScottK, yeah, looks like it went in now
<ogra_> i'm just to impatient :)
<Mirv> slangasek: can you join the Qt 5.1 session in one hour to comment on the regressions it has, like would it be better to have it with known regressions that developers and then kicked to fix or FFe when everything has been fixed?
<Mirv> or not like regressions it itself has, but that it causes to other components
<ScottK> 5.1.1 is out, BTW.
<Mirv> ScottK: yep, building in https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-daily - it's essentially the same as ~20130820 snapshots but with one Mac OS related commit added
<ScottK> Did you merge from Debian?
<ScottK> If we're going to get ahead of them again, we ought to pick up their packaging changes.
<Mirv> ScottK: most 5.1.0 changes have been merged by me or mitya57
<ScottK> OK.  Great.
<Mirv> at least the important ones (qtbase, qtdeclarative)
<mlankhorst> ScottK:
<mlankhorst> can you move llvm-3.3 to main?
<ScottK> Is there an approved MIR?
<mlankhorst> ScottK: it replaces llvm-3.2 as dep for mesa
<mlankhorst> I think a mir for a version bump is a bit of overkill :)
<mlankhorst> http://irclogs.ubuntu.com/2013/08/21/%23ubuntu-devel.txt from earlier conversaion about it
<olli> hi there
<olli> thostr_1, and I wanted to check with the release team to see if FFe https://bugs.launchpad.net/ubuntu/+bug/1215980 and FFe https://bugs.launchpad.net/ubuntu/+bug/1215397
<ubot2`> Launchpad bug 1215980 in Ubuntu "[FFe] Freeze exception for converged indicators" [Undecided,New]
<ubot2`> Launchpad bug 1215397 in Ubuntu "[FFe] Freeze exception for converged scope packages" [Undecided,New]
<roaksoax> howdy! Is there someone who can take care of a package in the NEW queue? It is a soon to be dependency for MAAS: djorm-ext-pgarray
<ScottK> mlankhorst: https://launchpad.net/ubuntu/+source/llvm-3.3 is curiously empty.
<cjwatson> I think he must mean llvm-toolchain-3.3
<ScottK> Yes, that seems more likely.  Thanks.
<mlankhorst> oops yeah that one :)
<ScottK> mlankhorst: Did you upload mesa to build-dep on it yet?
<ScottK> If you didn't, it'll just fall right back to Universe.
<Laney> Riddell: can I bounce your mail to the list for the record, please?
<Laney> you sent it just to me
<mlankhorst> ScottK: yes
<mlankhorst> it's build-dep waiting
<ScottK> OK.
<Riddell> Laney: done
<Laney> merci
<ScottK> mlankhorst: https://launchpad.net/ubuntu/+source/llvm-toolchain-3.3/+publishinghistory
<mlankhorst> cheers
<olli> just noticed by question above was incomplete, so let's try again: are there any issues or missing information with FFe 1215980 and 1215397?
<olli> by/my
 * olli gets coffee
<mlankhorst> do the archive builds auto retry?
<Laney> from dep wait they do
<mlankhorst> ah k, it should be good to go then :)
<Mirv> anyone up to the Qt 5.1 session? https://plus.google.com/hangouts/_/368836c93bc010c273ce53686164a50dd2e47904?authuser=0&hl=en
<ScottK> Mirv: What plugin do I need to install?
<ScottK> Nevermind.  Figured it out.
<slangasek> Mirv: I'm afraid I'm running video on the foundations track, can't easily join
<mlankhorst> hm, looks like like llvm-3.3-dev depends on libjsoncpp0 too, yikes..
<mlankhorst> although it seems that llvm-3.2 already required libjson, it was just not an external dependency
<mlankhorst> an internal json copy was used instead
<mlankhorst> it would be easy to use the internal copy again though, if it's preferred that libjson doesn't get to main
<xnox> mlankhorst: libjson? upstart is already using a json library. Or is it something else?
<Laney> libjsoncpp
<Laney> according to that binary package name anyway
<xnox> Laney: ah, so not the libjson-c2 / json-c. mlankhorst use json-c =))))
<mlankhorst> xnox: I'd rather not rewrite support :P
<mlankhorst> xnox: is it easy to change in llvm by just replacing deps?
<slangasek> I imagine the API is different
<mlankhorst> guess so :/
<mlankhorst> can I revert the change and use the included copy?
<slangasek> mlankhorst: given that libjsoncpp is in the archive, we (or rather, the security team) would prefer to just support that package instead of having an embedded copy in llvm to support
<mlankhorst> ok
<ScottK> Someone even faster than me on bind9.
<cjwatson> I run new-binary-debian-universe pretty much out of my hindbrain
<cjwatson> Conscious thought is occasionally involved but only if it looks weird ...
<xnox> Please de-new upstart, we decided that the $world should not depend on dconf & glib, thus the tiny dconf bridge is in a separate binary package.
#ubuntu-release 2013-08-29
<sarnold> tkamppeter_: I'm sorry to NAK openjpeg with so little time before featurefreeze, but that code needs serious attention before it should be exposed to untrusted data.
<maclin> cjwatson, hi, I have a problem about the ubuntukylin daily iso. The user cannot login neither in live mode nor after installation.
<maclin> we have proposed the Bug #1218172. I guess it's about the gnome-session and gnome-settings-daemon packages. Can you help to confirm it?
<ubot2`> Launchpad bug 1218172 in UbuntuKylin "lightdm cannot login (ç³»ç»æ æ³ç»å½) on ubuntukylin daily iso(0822+)" [Critical,Confirmed] https://launchpad.net/bugs/1218172
<infinity> maclin: Probably a better question for #ubuntu-desktop than here.
<maclin> infinity, thanks. we do the test in ubuntu daily iso and the problem does not exist. So I guess this problem is about the image building process?
<infinity> maclin: Hard to say without someone who would be better at debugging it (like the #ubuntu-desktop people)
<maclin> I find that the gnome-session and gnome-settings-daemon get lost in UbuntuKylin daily ISO
<infinity> maclin: Hrm.  Curious.
<infinity> Where do the ubuntukylin seeds live?
<maclin> infinity, we use the default-setting
<infinity> maclin: So, you've got bigger problems than just a few missing packages.  No compiz, no unity, no ubuntu-desktop.  This is probably our fault somewhere. :P
<infinity> maclin: Let me respin a new ISO and see if this was transient..
<mlankhorst> hmz
<mlankhorst> infinity: yikes llvm-3.3 was kicked back to universe because mesa ftbfs because of libjsoncpp
<infinity> mlankhorst: Looks like libjsoncpp needs an MIR...
<infinity> mlankhorst: lcov as well.
<infinity> http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
<mlankhorst> hm fun
<infinity> mlankhorst: Happy filing.
<infinity> At least your life doesn't suck as hard as the people who thought location-service needed to depend on 7000 ruby gems.
<mlankhorst> fortunately lcov only depends on debhelper
<infinity> And libgd-gd2-perl, but that's already in main.
<RAOF> infinity: location-service is ruby? Sounds like muchos fun!
<infinity> RAOF: It build-deps on some ruby doc generation thing, it looks like.
<infinity> RAOF: Though, why this was chosen for a Canonical project (I assume this is a Canonical project?) is beyond me.
<infinity> Given the "libubuntu-" names, I'm going to go with probably yes. :P
<RAOF> :)
<mlankhorst> infinity: meh, lcov loooks like an optional dependency, only used when codecoverage is added to DEB_BUILD_OPTIONS :P
<infinity> mlankhorst: Alright, so we could patch that our or MIR it.  Whichever.
<mlankhorst> but shrug I'll mir it
<infinity> mlankhorst: I'm assuming we're less lucky on the json thing, though.
<infinity> mlankhorst: MIRs for build, debug, and analysis tools are generally non-controversial, compared to runtime stuff.
<mlankhorst> ah k
<mlankhorst> I added one for lcov https://bugs.launchpad.net/ubuntu/+source/lcov/+bug/1218209
<ubot2`> Launchpad bug 1218209 in lcov (Ubuntu) "[MIR] lcov" [Undecided,New]
<mlankhorst> still working on libjsoncpp
<mlankhorst> but meh from the bug reports in lcov it looks like it might be better to patch out codecoverage support..
<infinity> Hrm?  I see one bug in Ubuntu, 3 in Debian...
<infinity> Certainly nothing terrible.
<mlankhorst> yeah about gcc-4.7 support, makes me wonder if things even work :P
<infinity> Hrm, fair enough.
<mlankhorst> I'll give it a shot, but if not could lcov be dropped as build-dep? it would probably fail if doing a manual build with codecoverage added to DEB_BUILD_OPTIONS though, but then again that would already be
<infinity> Patching that out for now seems reasonable.
<infinity> I'll just patch it out now.
<mlankhorst> ok :-)
<mlankhorst> shall i mark the lcov bug as invalid then?
<infinity> I'm on it.
<mlankhorst> k
<infinity> mlankhorst: I think I'll just leave it "new", so it magically pops up again if we re-add the build-dep after lcov is fixed. :P
<infinity> mlankhorst: Hrm.  So, llvm-toolchain-3.2 uses a bundled jsoncpp.  Ick.
<infinity> mlankhorst: But we could revert 3.3 to doing the same thing.  Or fix 3.2 to use the system library.  Only doing one or the other seems silly.
<infinity> Ahh, and indeed, if I merged 3.2 with Debian, it has the same "use the system version" change.
<infinity> mlankhorst: So, yeah, that's probably the right thing to do, so carry on with the MIR.  Mention that it affects both 3.3 and 3.2 (or will, after we merge it :P)
<mlankhorst> https://bugs.launchpad.net/ubuntu/+source/libjsoncpp/+bug/1218220
<ubot2`> Launchpad bug 1218220 in libjsoncpp (Ubuntu) "[MIR] libjsoncpp" [Undecided,New]
<mlankhorst> infinity: but llvm 3.2 will no longer be in main after mesa builds against 3.3 :P
<infinity> Is mesa really the only thing that keeps llvm in main?
<mlankhorst> i think so
<infinity> Hrm.
<infinity> Given how stagnant this is upstream, maybe I should just revert to the static copy for now, then.
<infinity> The libjson0 package also has no symbols file, or other such fanciness.
<infinity> Which, of course, a static version wouldn't need.
 * infinity ponders.
<mlankhorst> ah right, I missed that
<infinity> Okay, so, when you mean to remove libjsoncpp0, don't scare the crap out of yourself and type "apt-get purge libjson0"
<mlankhorst> haha
<mlankhorst> interesting, it has no issues trying to remove upstart here..
<infinity> Yeah, maybe I'll just re-enable the static copy for now.  It's a few thousand lines of public domain cargo-cult, might actually be safer than a shared lib with lousy versioning.
<mlankhorst> hm probably
<infinity> Wish I'd come to this conclusion before I made you file bugs... And before I uploaded. :P
<mlankhorst> lol
<mlankhorst> hey sometimes showing people they're wrong is best done by doing exactly what they want you to do
<infinity> Alright, uploaded AGAIN. :P
<mlankhorst> infinity: will it promote the build to main because llvm-toolchain is still being kicked back to universe?
<infinity> mlankhorst: llvm-toolchain-3.3 is still in main.  component-mismatches wants me to move it, that doesn't mean I have done so.
<mlankhorst> ah
<infinity> mlankhorst: So, once it's built, retries on the mesa builds should work.
<mlankhorst> yeah
<infinity> Now, I totally didn't test build this, cause I'm a cowboy like that, so watch it fail...
<mlankhorst> if you think you're rough, I didn't look twice before crossing the road today
<infinity> Don't forget to look up for Cesnas making emergency landings.
<infinity> Cessnas*
<mlankhorst> :D
<infinity> Okay, the Internet is kinda awesome.
<infinity> I had no idea Cessna actually listed prices online.  If there was a shop with a "buy now" button, I'd be set.
<pkern> The Internet is full of cats.
<infinity> Only 26M for a top of the line Citation, a bargain.
<mlankhorst> infinity: hahaha
<mlankhorst> but it only takes 3 hours to build on armhf, I'll get some coffee :)
<infinity> mlankhorst: 39 minutes on PPC though, so at least I get a test build soon. :P
<Laney> can we haz emails about component-mismatches-proposed?
<infinity> Hrm, yeah, we may have failed to advertise its existence.
<infinity> Then again, most people aren't aware of the non-proposed version either, from what I can tell.
<Laney> I don't mean advertisement
<Laney> I mean "New component-mismatches"
<infinity> Oh, you mean emails to -release on changes.
<Laney> that thing
<infinity> That could be noisier than expected.  Not sure.
<infinity> Perhaps still a good idea.
<Laney> Probably if we have both going
<Laney> but still, it's remarkably easy to miss, at least for me
<sil2100> infinity: hello! Can I poke you about moving unity-scope-mediascanner from the NEW queue? I see the sync request is there and it would be cool to get it out to the universe (tm)
<infinity> sil2100: W: unity-scope-mediascanner source: field-name-typo-in-dep5-copyright file -> files (line 6)
<infinity> sil2100: Care to fix your copyright file in bzr?
<sil2100> Oh noes
<sil2100> Doing that
<infinity> Otherwise, looks fine.
<sil2100> What a typo... thanks for accepting!
<cjwatson> maclin: gnome-session is removed as part of the line "apt-get purge --auto-remove -y ibus ibus-gtk ibus-gtk3 python-ibus ibus-pinyin-db-android libopencc1" in ubuntukylin-default-settings/hooks/chroot
<cjwatson> maclin: So perhaps you need to work out some more subtle way to do that
<maclin> cjwatson, thanks, we will check the problem of dependency
<Laney> We have gnome-settings-daemon depending on ibus so removing that is going to be problematic
<maclin> Laney, the dependency between ibus and gnome-settings-daemon is added recently?
<Laney> maclin: Some time this cycle; let me check when
<seb128> this month
<seb128> that's quite recent yes
<seb128> but that was in the work for some months, we emailed desktop/devel list about that mid-cycle
<Laney>  Wed, 21 Aug 2013 11:22:42 -0400
<Laney> But indeed it was no surprise
<maclin> yes, the problem appears since 22th this month
<jbicha> maclin: you guys are subscribed to ubuntu-devel, right?
<seb128> Laney, maclin: it would be much easier for everyone if UbuntuKylin was using the same input method framework than Ubuntu, not sure why we can't reconciliate both on ibus :/
<Laney> Yes, but I can't pretend to understand the issues there
<Laney> Don't we have some new guys to work on this stuff now? :-)
<maclin> seb128,we have to choose fcitx as default instead of ibus.
<seb128> maclin, you don't "have" to, you decide to do that ;-)
<seb128> maclin, you could add the input methods engines you need to ibus instead
<maclin> seb128,yes,it's suitable for us:)
<Laney> I thought you could use im-config to configure this stuff anyway
<Laney> or do they conflict?
<maclin> seb128, Laney, if we don't remove ibus, the default input method will be ibus
<Laney> maclin: If you don't do anything else, that is true - I'm saying that I thought this was the problem that im-config solves
<maclin> Laney, does im-config change the default option in default-settings?
<Laney> maclin: I'm not sure how you set a system default with it
<Laney> You could talk to happyaron though
<infinity> im-config  invoked  from  the  root  account  updates  the   system   configuration   file
<infinity> ^-- From the manpage.
<infinity> So invoking im-config during image build should set it system-wide.
<cjwatson> man --nj  IYF
<cjwatson> (for pasting)
<infinity> But I like all the extra spaces!
<Laney> It made it scan in an exciting way
<cjwatson> To the tune of the Flintstones?
<Laney> maclin: So yeah. I'd look into that if I were you. Yay for fewer forced removals and unpleasant surprises.
 * infinity is not having a yabba dabba do time.
<maclin> jbicha, just see your message, yes, we did
<maclin> Laney, thanks for your suggestion :-)
<infinity> mlankhorst: mesa built on powerpc, I call it a success.  Screw the other arches.
<Laney> maclin: Bear in mind beta 1 is quite soon ;-)
<mlankhorst> infinity: hah I just wanted to look if I could find llvm in the archive before retrying mesa builds:P
<mlankhorst> other !armhf are finishing up too
<jbicha> maclin: what I mean is that we announced a call for testing several weeks ago and didn't hear from Kylin that there could be a problem until today
<cjwatson> (If you've ever read the poem "Paradise Lost", read its first one and a half lines in light of my previous comment; you'll never read it the same way again)
<infinity> The meter's a bit off.
<infinity> Or my copy has an extra word yours doesn't.
<cjwatson> You have to read "Of" on the up-beat, yes.
<infinity> It's certainly catchy.
<maclin> jbicha, sorry to say that we miss the testing call...but we will catch up...
<infinity> mlankhorst: I'm going to try to get some sleep.  I leave the armhf mesa retry to you.
<mlankhorst> sure
<xnox> please hint upstart to go past mysql-5.5 adt failure ( 	5.5.32-0ubuntu3 ) mysql never passed. So it's not a regression that upstart is causing.
 * xnox did ping #-server about fixing mysql adt.
<sil2100> It seems I'm not really knowledgable about this, but can anyone tell me why libcolumbus cannot leave -proposed? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#libcolumbus doesn't list any particular problems
<xnox> sil2100: please look in both reports listed at http://people.canonical.com/~ubuntu-archive/proposed-migration/
<xnox> sil2100: trying: libcolumbus
<xnox> skipped: libcolumbus (16 <- 53)
<xnox>     got: 88+0: i-88
<xnox>     * i386: unity-lens-applications
<xnox> sil2100: it causes unity-lens-applications to be uninstallable.
<xnox> (on i386)
<sil2100> xnox: thanks for clearing that up! Didn't really know how to interpret this output
<xnox> sil2100: yeah, it's criptic, but one gets used to it. Usually search for package name in question, as low down the list as possible. As it could be tried a few times, in combination with other packages. In the end it will list what breaks / is uninstable. From that point, one can open e.g. saucy+saucy-proposed chroot to see for one self why combinations of a&b fail to install together.
<sil2100> xnox: makes sense now, thanks ;)
<xnox> sil2100: in this case it's easy, unity-lens-applications still depends on libcolumbus0-0 instead of libcolumbus1
<cjwatson> sil2100: See also https://wiki.ubuntu.com/ProposedMigration
<mlankhorst> yay, armhf mesa build started
<xnox> can mysql-5.5 adt failure be hinted through for upstart? a new mysql which fixes it has been upload, but it will take at least 3 hours to build & it would be great to have upstart though to release pocket before FF & Beta1 migration block.
<xnox> Laney: ^
<Laney> xnox: I'd rather see if it works properly
<Laney> if necessary I'll unblock upstart
<rbasak> I'm not convinced mysql adt failures were really blocking anything
<rbasak> Since they've never passed
<Laney> that doesn't matter
<cjwatson> autopkgtests in proposed-migration aren't a ratchet
<cjwatson> They must pass or they block
<rbasak> eg. I got 5.5.32-0ubuntu3 migrated despite the failures
<rbasak> Or did someone ack that manually?
<cjwatson> That would have been hinted manually then, or else there was a failure in the tools
<Laney> people asked p-m to skip them
<rbasak> Ah
<cjwatson> cjwatson:force-badtest mysql-5.5/5.5.32-0ubuntu1
<cjwatson> (older version, but)
<Laney> Good to see things being fixed rather than ignored
<xnox> rbasak: failed adt mysql is blocking upstart migration to -release pocket.
<rbasak> I ignored it because I didn't think it was blocking anything, and therefore not urgent.
<rbasak> I'm annoyed that a failing dep8 test was written and uploaded and never passed.
<rbasak> Rather than helping, it feels that uploading tests that fail from the beginning just create extra work.
<jodh> https://staging.jenkins.qa.ubuntu.com anyone ? :)
<cjwatson> rbasak: That is certainly true.
<Laney> rbasak: did you see the review of failures that pitti posted to ubuntu-devel some time ago?
<Laney> there's a couple of maas ones that fail too
<rbasak> Laney: I did. But none of those are related to any work I've done, and I didn't see them as a priority to pick up over the work I'm already doing.
<rbasak> When I touch a package I generally try and fix anything outstanding with it. mysql was an exception because I was reverting yet another problem that didn't get tested before upload.
<xnox> rbasak: sure. but failing mysql-5.5 test will block migrating _all_ packages from -proposed to -release which are listed in Depends:*. Thus a failing test adt test, always blocks migrations. Unless it's a package with no Depends.
<rbasak> xnox: right. I understand that now.
<xnox> ok.
<Laney> halp
<Laney> I can't reproduce the problems p-m has with gst-plugins-{good,bad}1.0
<Laney> maybe they want hinting? there are mutually updated conflicts/replaces
<cjwatson> I haven't looked, but in general mutual conflicts won't get autohinted
<cjwatson> so you probably want to "easy" the relevant set of packages
<Laney> Worth a punt
<cjwatson> autohinting basically works off Depends as I understand it
<Laney> cjwatson: yeah that worked
<cjwatson> cool
<smartboyhw> skaet, that list should be correct, although I'm thinking that some people might be good to be included too....
<skaet> smartboyhw,  if there are other names that should be included,  please respond to the email with them.  :-)   Best if we have backups identified, etc.
<smartboyhw> skaet, um, I might get killed for over-interfering if I post them...
<smartboyhw> skaet, I can private message you, and you can ask the flavour leads
<smartboyhw> :)
<skaet> smartboyhw,  what ever works.  :-)
<bdmurray> Could an SRU team member have a look at my ubuntu-release-upgrader uploads?
<slangasek> bdmurray: looking
<bdmurray> slangasek: thanks
<phillw> Riddell: does kubuntu have ppc tester(s) yet, if not - would you like me include kubuntu in the call for PPC testers on Monday?
#ubuntu-release 2013-08-30
<ScottK> phillw: We may, but yet please.  The more the merrier in any case.
<phillw> ScottK: okies. I will, I'm also going to announce on ubuntu forum apple area :)
<maclin> hi,guys, Is there any problem with the qatracker building? I requested a rebuild this morning and the status has keeping re-building for nearly 6 hours.
<smartboyhw> ^ That's for UbuntuKylin
<maclin> yes, thanks smartboyhw
<maclin> Anyone could help to check it? I even can't cancel the rebuild request.
<phillw> maclin: AFAIK, we are still on cron-job rebuilds. Only when the cron is suspended can we ask the system for re-spins (e.g after Monday when beta 1 trips in for us). I'm sure one of the release team will correct my rough and basic knowledge of how it all works; but that is it to my knowledge.
<smartboyhw> phillw, huh? I asked for an Ubuntu Studio rebuild yesterday and it worked
<smartboyhw> Maybe the day before yesterday, forgotten
<phillw> maclin: 14 22 * * *	for-project ubuntukylin cron.daily-live --live
<phillw> 22:14 UTC is the build time for kylin
<phillw> smartboyhw: 20:34 UTC is for ubuntu studio
<smartboyhw> phillw, actually, where can I find that-.-
<phillw> If you're ever unsure, look it up on http://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/view/head:/etc/crontab
<phillw> I have the times in the lubuntu area so people know not to start a test suite one hour before a respin :D
<phillw> Those times do come with a bit of small print "Please note from the release team: Sure, as long as it's clear that it's subject to change - We're not intending to make any promises here. We won't change them around frivolously or anything but it's possible."
<phillw> the times on the link are the times, the entries onto your wiki page, should you let people know; are subject to change.
<Laney> hello
<Laney> I'm about to generate the beta block
<jodh> Laney: have you heard any update on the mysql-blocking-upstart issue? upstart is still in -proposed.
<phillw> Laney: will the late FFe squeeze in?
<Laney> jodh: checking
<Laney> jodh: Guess I'll skip that then :-/
<Laney> jamespage: ^^^ have you seen this?
<Laney> phillw: what FFe?
<Laney> (We can do unblocks)
<jamespage> Laney, I was just looking now
<jamespage> stderr is causing the DEP-8 test to fail
<Laney> jamespage: might be because of the stderr output
<Laney> ha
<jamespage> I'm testing a fix now
<jamespage> but it takes ~3 hours to build
<Laney> ok
<phillw> Laney: the one from micah for gnumeric etc.? it is on the ubuntu-release emails?
<Laney> phillw: yes
<jamespage> if mysql is the last thing holding it please force it throught
<Laney> I don't know where the uploads stand though, didn't check yet
<jodh> Laney/jamespage: this is rather unfortunate - having a new version of upstart appear in the archive on a Friday is not optimal imho :(
<Laney> jamespage: ok, but really really ideally not any more
<phillw> Laney: it was ~ 13:00 today.
<jamespage> Laney, trying my best
<jamespage> sorry
<Laney> I know, thanks for fixing it ;-)
<jamespage> not sure why I'm apologizing actually - I did not write the DEP-8 tests and they have never actually passed...
<jamespage> but hey - its a server package
 * jamespage takes it like a man
<Laney> collective responsibility
<Laney> very cabinet of you
<phillw> Laney: the community flavours affected would really like this in for the beta 1 if at all possible.
<Laney> phillw: Someone has to upload it then
<jodh> jamespage, Laney: am I reading these mysql test results correctly? they all passed, but the overall test failed due to stderr output right?
<jamespage> jodh, thats right
<Laney> jodh: seems like it
<Laney> (hint updated)
<jamespage> jodh, the fix is 2>&1
<smartboyhw> Laney, if you can ACK Bug 1218736 it would be great
<ubot2`> Launchpad bug 1218736 in oxygen-gtk3 (Ubuntu) "[FFe]Please update oxygen-gtk3 to 1.2.0" [Undecided,In progress] https://launchpad.net/bugs/1218736
<jodh> Laney: so, what are the options wrt getting upstart into main? I'd rather not go through the whole FFE process as I actually uploaded 2 days ago, but ideally, I'd like upstart to hit the archive monday now due to the mysql delays.
<Laney> jodh: No FFe
<Laney> jodh: Now you get the entire Europe and US days - is that not enough?
<phillw> Laney: his eta was ~ 13:00 UTC today (micah) Adam Conrad was pretty relaxed and appreciated that they do need to land. May I ask why the sudden "we're closing"?
<jodh> Laney: lets hope so.
<infinity> jodh: Getting upstart into "main"?  You mean into the release pocket?
<jodh> infinity: right
<smartboyhw> phillw, you did report a FFe bug right?
<Laney> phillw: What? There's no closing. No need to panic.
<infinity> jodh: I'll let it slip in right now.
<Laney> We can unblock. micahg knows how to ask.
<Laney> infinity: I just pushed the force-badtest update.
<infinity> Oh, or Laney will. ;)
<Laney> Although...
<phillw> smartboyhw: nope, it was done using the release team email list to get permission from all the flavours it would affect. The result of that was that we would much rather prefer it in for the Beta 1, than after.
<smartboyhw> phillw, can't you read the mail ScottK wrote?
<Laney> The version on excuses is ubuntu3 but I forced for ubuntu5
<Laney> hope that works
<smartboyhw> <ScottK> Yes.  Please go ahead (like today so we can minimize architectural changes
<smartboyhw> after Beta), but also please file an FFe bug for the record (I'll be happy to
<smartboyhw> bless if after I sleep).
<infinity> Laney: It won't work, no.  I'll just add a skiptest for that upstart version while I'm in there. :P
 * Laney glares at adt-britney
<phillw> smartboyhw: it was not for me to raise a Ffe bug report. It *was* being handled via the mailing list :)
<smartboyhw> phillw, ?
<Laney> It's fine. Calm down. Far more important that someone actually does the work and uploads now.
<smartboyhw> Laney, both me and phillw are not uploaders
<phillw> Laney: indeed, please give micah time. Us mere mortals are used to ~17:00 UTC as cut off time :)
<Laney> (a) That doesn't stop you from doing the work, (b) micahg indicated he would in his initial mail
<phillw> Laney: how do I file an FFe that affects several flavours?
<smartboyhw> phillw, just file it?
<infinity> phillw: Huh?
<phillw> I'm lubuntu release manager only.
<smartboyhw> No need to care about flavours
<smartboyhw> Just report a bug through Launchpad
<infinity> phillw: An FFe is for allowing a package upload to the archive, it has nothing to do with flavours.
<Laney> He has time. Don't know what you're talking about with 1700UTC. The freezes were yesterday.
<infinity> Granted, if micahg uploads those before filing a bug, no one's going to complain, Scott's just going to make sure he does the paperwork at some point.
<infinity> At any rate, discussing an upload that hasn't happened yet is silly.  Wait for micahg to get around to it.
<phillw> I've only ever done an SRU, can someone pop into -quality and talk me through it so as not to antagonise people here?
<smartboyhw> infinity, sigh, I will do the FFe bug
<infinity> smartboyhw: If you do, follow up to the list thread, so micahg knows he doesn't have to file another. :P
<smartboyhw> infinity, sure
<infinity> smartboyhw: You can just copy and paste his original email, FWIW.  Don't need to be fancy here, two release engineers already ACKed it.
<infinity> (One of them's just anal about paperwork)
<smartboyhw> infinity, :P
<jibel> jamespage, you could use the restriction allow-stderr in dep8 control file instead of redirecting stderr
<jamespage> jibel, I could
<jamespage> jibel, but I'm half way throught testing it with redirection in the script itself
<Laney> jibel: Do you know why upstart/excuses shows an older version of mysql-5.5?
<Laney> I guess it's something to do with the depends being dropped
<phillw> Laney: when I started, it was still yesterday :) But, I just had a sneaky feeling that all that was agreed on the mailing list would count for nothing when faced with "the rules" :)
<Laney> Well don't.
<Laney> bah, did python-apt break API?
<infinity> phillw: What are you on about?  What was agreed on the mailing list counts for everything, the FFe is fine, the sky is not falling.  However, arguing to include something that hasn't been uploaded is.  Uhm.  Meaningless.
<smartboyhw> Laney, bug 1218763
<ubot2`> Launchpad bug 1218763 in goffice (Ubuntu) "[FFe] Please update gnumeric to upstream version 1.12.6 and goffice to 0.10.6" [Undecided,New] https://launchpad.net/bugs/1218763
<jibel> Laney, because that was the version in the archive when upstart 1.10-0ubuntu1 was uploaded
<Laney> jibel: Ah, and it's a bug that this wasn't updated for subsequent versions, OK then
<Laney> beta 1 supercalifragilisticexpialidocious block pushed
<smartboyhw> Laney, Bug 1218763 and Bug 1218766 to the Ubuntu Release Team's ACK.
<ubot2`> Launchpad bug 1218763 in goffice (Ubuntu) "[FFe] Please update gnumeric to upstream version 1.12.6 and goffice to 0.10.6" [Undecided,New] https://launchpad.net/bugs/1218763
<ubot2`> Launchpad bug 1218766 in xfce4-settings (Ubuntu) "[FFe] Please update Xfce4-settings to upstream version 4.11" [Undecided,New] https://launchpad.net/bugs/1218766
<Laney> smartboyhw: ok, thanks for filing
<smartboyhw> phillw, ^ happy?
<smartboyhw> Laney, if you can, do Bug 1218736 or me too:)
<ubot2`> Launchpad bug 1218736 in oxygen-gtk3 (Ubuntu) "[FFe]Please update oxygen-gtk3 to 1.2.0" [Undecided,In progress] https://launchpad.net/bugs/1218736
<smartboyhw> Huh, 36, 63 and 66
<smartboyhw> Lucky number!
<xnox> Laney: please unblock & migrate upstart =) since well mysql-5.5 5.5.32-0ubuntu3 will for sure never pass now, as the version moved on now & it's not a direct r-dep anymore.
<Laney> xnox: yes, unblocking it
<Laney> I saw your sidestepping of the issue :P
<xnox> Laney: I have no idea what you are on about, it is valid for mysql to drop that depends =))) _and_ it's been failing to build on i386 a couple of times, so it needed a rebuild anyway on i386 =)
<phillw> smartboyhw: thanks.
<phillw> infinity: can you kick off a manual respin of ISos'?
<phillw> if there is a respin authorised person about, could you please kick ubuntu-kylin off. their release manager marked it for a respin some 10 hours ago now. He did not know that the iso's are still under cron control and it is sat as status rebuilding.
<Laney> they are
<cjwatson> requested rebuilds should happen regardless of cron
<phillw> cjwatson: in that case, there is something stopping the kylin one. He came on several hours ago to say he had requested a respin several hours before and it had not happened.
<cjwatson> I think rebuild-requests is stuck - there's a process there that's been running since Aug 12, but it shouldn't be long-running
<cjwatson> I'll try killing it and letting it respawn
<cjwatson> Not that I see any locking either, so maybe that isn't it
<cjwatson> Oh, cdimage tried to rebuild, the build failed, it marked the rebuild as Built in the iso.qa database when the build ended, but it never published a new version (since it failed) so it effectively looks stuck
<phillw> cjwatson: I'm just going to copy and paste that explanation.. I've read it three times now.... "build failed and system the didn't know what to do as it does not have such error trapping, yet."
<phillw> Am I close?
<cjwatson> Please don't copy and paste my explanation as it's not an explanation, I'm thinking out loud
<cjwatson> If you start copying every word I say then I'll just investigate silently instead
<cjwatson> I think you'd probably prefer it if I were a little more verbose though
<cjwatson> I've forcibly reset those rebuilds to the Requested state - let's see what happens
<cjwatson> An actual investigation of the bug here requires stgraber, but perhaps I can poke it into action for now
<phillw> cjwatson: that is why I asked if my interpretation was close. It means I have a basic idea and can then pass that on. Please do not be offended over the standing joke of the language devs speak in; it was meant jokingly and not as to cause offence :'(
<cjwatson> I don't think it's valuable to pass on my random intermediate musings.
<cjwatson> They're mostly for the benefit of stgraber reviewing this log later.
<cjwatson> There we go, it's rebuilding now, though apparently building i386 twice (whoops, that's my fault)
<phillw> twice is better than zero :) Thanks.
<cjwatson> (There were two i386 requests in the Built state, and I idiotically reset both to Requested)
<phillw> cjwatson: you were perfectly entilted to say "wait for stgrabber", that you did not and got the builds for that team going is a testament to the sort of guy you are. I'm sure that their TL would agree fully with that sentiment, but to save any more issues with c & P I will not ask him.
<Laney> hmm
<Laney> why didn't infinity's force-skiptest for upstart stick?
<cjwatson> What I mean is that rather than wasting the UbuntuKylin people's time with intermediate comments, I'd rather they just saw their build land.
<Laney> W: [Fri Aug 30 09:20:51 2013] - Overriding force-skiptest[upstart] = ('1.9.1-0ubuntu3', 'adconrad', 'None') with ('1.10-0ubuntu1', 'adconrad', 'None')
<Laney> W: [Fri Aug 30 09:20:51 2013] - Overriding force-skiptest[upstart] = ('1.10-0ubuntu1', 'adconrad', 'None') with ('1.9.1-0ubuntu5', 'stgraber', 'None')
<Laney> hah
<cjwatson> Which should hopefully happen in a bit now.
<cjwatson> Laney: mm, yeah, delete the old-versioned hint
<Laney> already done
<cjwatson> stupid code, my fault :)
<Laney> well, modulo merging
<phillw> so would they :) and ...
<phillw> (10:36:42) phillw: maclin: they are now rebuilding
<phillw> (10:40:02) maclin: phillw, thanks
 * Laney renames self to zzzzzlaney
<smartboyhw> Laney, do it then
<smartboyhw> :)
<mlankhorst> boy the archive admins are fast, llvm-toolchain-3.2 no longer in main for saucy :)
<xnox> =)))) lolz
<Laney> upstart went in
<xnox> jodh: ^ \o/
<jodh> Laney: yah - thanks
<jodh> yay even :)
<jamespage> Laney, jodh: my fix for mysql tested OK locally - uploaded so should not block in future...
<Laney> jamespage: \o/
<Laney> did you use the VM based stuff to test it?
<Laney> run-adt-test
<Laney> thanks for caring about tests :-)
<jamespage> Laney, yes
<Laney> neat
<jamespage> still takes about 1.5 hrs to run on my laptop with SSD and multi-core
<jamespage> and its running in /dev/shm as well
<jamespage> blimey
<jamespage> thats a full regression test suite and a half
<micahg> Laney: phillw: had an early night, finishing up now
<Riddell> what's the name of the core package set?
<Riddell> this doesn't work   ./edit-acl query -P ubuntu-core-dev -S saucy
<micahg> I think it's just core
<Riddell> ah hah, thanks
<micahg> ScottK: you mentioned you'd ACK Bug #1218763 ?
<ubot2`> Launchpad bug 1218763 in goffice (Ubuntu) "[FFe] Please update gnumeric to upstream version 1.12.6 and goffice to 0.10.6" [Undecided,New] https://launchpad.net/bugs/1218763
<micahg> haha, onlyjob just uploaded to Debian, I think I'll just grab from there
<ScottK> micahg: Ack'ed.
<stgraber> cjwatson: so sounds like I messed up the case where a product fails to build? weird that we never had that happen before. I'll take a look at what's happening in that case (I think the state should be set as done even on failure as the rebuild was processed)
<micahg> phillw: Laney: done with goffice/gnumeric, will try to keep an eye on it
<smartboyhw> ScottK, according to the procedure on wiki.ubuntu.com/FreezeExceptionProcess, that should have been an Triaged;P
<smartboyhw> Anyhow
<ScottK> OK.  Feel free to change it.
<smartboyhw> ScottK, I can't anyway
<micahg> too late, already sync'd :)
<smartboyhw> micahg, well, it isn't a problem anyway
<cyphermox> hi, I uploaded network-manager yesterday, and autopkgtests seem to be failing -- I'm just been debugging this with pitti and it looks as though it may still be an issue related to dbus 1.6.12-0ubuntu5 -- downgrading it, tests begin passing again
<cyphermox> would it be possible to ignore the tests results?  ^^
<cjwatson> stgraber: That's what it looked like; there was a limit to how much I could investigate from my end, but the status was definitely 3
<stgraber> infinity: hey, was it you who re-enabled proposed for the precise builds? if so, you missed all the desktop images ;)
<stgraber> infinity: just noticed as ara was wondering why the current dailies didn't include the proposed initramfs-tools
 * stgraber fixes
<xnox> stgraber: thank you!
<maclin> cjwatson, the amd64 image of ubuntukylin is ready, but the i386 image is not.  Is there any error during building?
<cjwatson> maclin: The logs are all public
<cjwatson> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/saucy/ubuntukylin/  and  http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntukylin/saucy/
<cjwatson> (sorry that the bits of those URLs are in opposite orders - historical mistake)
<cjwatson> It's possible I confused it by accidentally re-requesting two i386 builds at once
<maclin> cjwatson, you mean it is still building?
<cjwatson> No, I think I broke it by mistake
<cjwatson> I was manually poking the database ...
<cjwatson> It's certainly not still building
<JackYu> cjwatson, wow, so you will rebuild one?
<cjwatson> I'm just going to do another one by hand
<cjwatson> Actually, I should be able to do it in the tracker, one moment
<JackYu> cjwatson, thanks:)
<doko> binutils (2.23.52.20130727-1ubuntu1 to 2.23.52.20130828-1ubuntu1)
<doko> Maintainer: Ubuntu Core developers
<doko> Not touching package due to block request by laney (contact #ubuntu-release if update is needed)
<doko> Not considered
<doko> Laney, ?
<Laney> beta 1 freeze
<doko> ahh
<doko> which is unfortunate, hmm, will have to copy this to a ppa for the test rebuild
<ScottK> doko: It's only Friday, I don't think it's a big deal to unblock it if it's important.
<chiluk> can I get some love from an sru-team member for curl and apt that are currently sitting on the upload queue for p,q,r ?
<chiluk> bdmurray already sponsored the upload. *thanks btw
<bdmurray> chiluk: they should wait 7 days after being verified unless there is some real hurry
<chiluk> today is day 7
<bdmurray> chiluk: oh you meant reviewing them not releasing, sorry
<chiluk> bdmurray it's still sitting in the upload queue... hasn't been released to proposed yet.
<chiluk> bdmurray it's still sitting in unapproved.. iirc, you need someone else to approve it since you sponsored it right?
<bdmurray> chiluk: yes, we generally prefer that.
<bdmurray> infinity: could you have a look at those uploads?
<chiluk> bdmurray, also doesn't curl need to be approved and built before apt can be built right?
<chiluk> because of the new builddeb on the latest curl for apt..
<chiluk> or is launchpad smart enough to hold off on the apt build until curl has completed.
<cjwatson> maclin,JackYu: looks better now (belatedly)
<JackYu> cjwatson :)
<jamespage> hey - could the ceph upload for raring be reject please - I have another bug I'd like to squash alongside the point release
<stgraber> jamespage: done
<jamespage> stgraber, thanks
<chiluk> stgraber can I get the uploads for p,q,r curl and apt approved?  currently sponsored, but stuck in queue.  fyi apt has a new builddeb on the new version of curl.
<infinity> stgraber: Did I really?  Go me.
<infinity> stgraber: Oh, bah.  I didn't even notice those were still two-parter lines.
<slangasek> stgraber: ^^ don't worry about curl/apt, I'm working on it (#-devel)
<stgraber> ok
<adam_g> any SRU members able to accept the openstack updates into raring-proposed? (cinder, glance, keystone, horizon, nova, quantum)  i'd love to get them verified and released before upcoming CVEs start getting released against whats in -updates
<micahg-work> can someone please unblock goffice/gnumeric
<cyphermox> Laney: hey
<sergiusens> can anyone get https://launchpad.net/ubuntu/saucy/+source/click/0.4.0 published?
<sergiusens> stgraber: ? ^^
<sergiusens> released*
<stgraber> sergiusens: it's currently blocked by the Beta1 block that Laney put in place
<stgraber> sergiusens: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<stgraber> Laney: I'll release a bunch of touch related packages since they're not affected by beta1 and not seeded outside of ubuntu-touch. Would be great if you could update your block accordingly.
<sergiusens> stgraber: thanks
<stgraber> letting through system-image, click and click-apparmor
<infinity> stgraber: eglibc totally qualifies as touch-only, right?
<stgraber> infinity: sure ;) to be honnest I'm not really sure why the block is already in place, I'd have expected it to be put in place on Monday but whatever
<stgraber> I guess we've usually been late at putting the block in place, so maybe we're trying to balance it out by being early for once :)
<jdstrand> stgraber: fyi, apparmor-easyprof-ubuntu is also touch only
<jdstrand> I will be uploading a new one of those in a minute
<infinity> stgraber: Well, I still hope to get this eglibc verified to my satisfaction and convince someone that 2 days after FF is "close enough" over the weekend, but we'll see. :)
<infinity> Just one last patch to rebase, and one last testsuite failure to effin' figure out and commit an upstream fix for.
<infinity> If my laptop would stop locking up (thanks, i915 developers, you guys are AWESOME), this would go better.
<stgraber> jdstrand: unblock lines are per-version, so until it's on proposed-migration I can't see the version number and so can't let it through
<cjwatson> or just have jdstrand tell you the version in advance ...
<stgraber> that works too :)
<infinity> Maybe it's time for me to spend a few hundred dollars on a decently-beefy build server I can slap under my desk headless and stop abusing my laptop.
<stgraber> or just rent one, I hear there's a company in Germany with cheap Haswell servers
<infinity> stgraber: Hah.  Yeah.  I'd use my current co-lo machine, but it's way slower than my laptop.
<infinity> stgraber: I'm still considering the move.  The latency (and worse, bandwidth) between them and I wasn't stellar, but maybe I can cope.
<infinity> mosh does generally cover up the ineractive latency issues, at least.
<infinity> s/ineractive/interactive/
<jdstrand> stgraber: fyi, apparmor-easyprof 1.0.25 uploaded. it isn't critical or anything. I just saw you let the others go through and thought I'd mention this one
<stgraber> the latency doesn't bother me that much actually, I only notice it when I fly to Europe and wonder why my shell feels weird all of a sudden
<micahg-work> can someone please unblock goffice/gnumeric
<stgraber> bandwidth based on what you measured last time is pretty bad, not sure what kind of crappy routes it's going through for you... though for a build machine, good bandwidth to Canonical DC is probably more important than good bandwidth to your place
<stgraber> jdstrand: ok, I'll add an unblock for it
<infinity> stgraber: Yeah, it's more about bandwidth to normal people, because it also hosts websites.
<infinity> stgraber: (Which is why the "just put it on an ipv6 tunnel and get better routes" solution isn't a solution)
<micahg-work> please unblock goffice 0.10.6-1 and gnumeric 1.12.6-1 (didn't realize I need to give versions :))
<stgraber> micahg-work: done
<micahg-work> thanks
 * micahg-work disappears
<phillw> thanks stgraber :)
<phillw> stgraber: btw, did you get to the bottom of the problem with -kylin not building?
<stgraber> phillw: I know what the problem is, but I haven't got around to fixing it, probably next week
<phillw> stgraber: okies, once the cron is suspended on monday, would it impact any of the teams asking for / agreeing to a respin?
<stgraber> so long as their product builds, no
<stgraber> and since we've only had that problem happen once in the past 2 months, it's doubtful it'll happen again this week (especially with the soft freeze in place)
#ubuntu-release 2013-08-31
<xnox> stgraber: feature freeze.
<xnox> as in I thought the blocks are in because of feature freeze, but i am probably wrong. do we do blocks, or force everything to go into unapproved?
<cjwatson> we don't block for feature freeze, nor unapproved.
<cjwatson> the blocks are for beta freeze.
<xnox> ok. i must be confused then.
<darkxst> Can we get upgrade test-cases added for Ubuntu GNOME on isotracker?
<darkxst> balloons, ^
<jbicha> darkxst: I think I found a button to do that in the iso.qa admin
<jbicha> http://iso.qa.ubuntu.com/admin/config/services/qatracker/products
<darkxst> jbicha, button clicked! no idea where the testcase went though, I can't see it!
<jbicha> it was added to http://iso.qa.ubuntu.com/qatracker/milestones/270/builds/52446/testcases
<darkxst> jbicha, no, I did it on amd64]
<darkxst> oh but it got added to both i386+amd64
<jbicha> I did the other one to test the button
<darkxst> ah!
* cjwatson changed the topic of #ubuntu-release to: Launchpad maintenance 2013-08-31 | Released: 13.10 Alpha 1, 13.04, and 12.04.2 | Archive: open | Saucy Salamander Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or beer | melior malum quod cognoscis
* cjwatson changed the topic of #ubuntu-release to: Released: 13.10 Alpha 1, 13.04, and 12.04.2 | Archive: open | Saucy Salamander Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or beer | melior malum quod cognoscis
<tumbleweed> why do we have http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu-gnome.saucy.new/ ? (and relatedly why is ubuntu-gnome.saucy broken)
<stgraber> queuebot (and my IRC session) is going offline for a couple of hours
#ubuntu-release 2013-09-01
<cjwatson> tumbleweed: It might have had problems relating to the LP downtime
<cjwatson> tumbleweed: Indeed it looks as though it's cleaned itself up now?
#ubuntu-release 2014-08-25
<elfy> good day channel, I'm trying to install with the mini iso for a test xubuntu, it's failing to find kernel modules - from tty4 it appears to be looking for 3.16.0-6 still - not really sure who to talk to about that :)
<infinity> elfy: Where did you download said mini.iso from?  The current one in utopic would certainly be looking for -10
<elfy> infinity: mmm - probably one I had from the other day ...
<elfy> http://archive.ubuntu.com/ubuntu/dists/utopic/main/installer-amd64/current/images/netboot/
<elfy> infinity: no - I got it again from there ^^
<elfy> on saturday
<infinity> Well, 336 (ie: current) was definitely built against -10, so I'm not sure what to say, unless you have an angry proxy between you and the real file.
<infinity> Or a failure to actually write it to your media?  I've made that mistake before. :P
<elfy> nope - no angry proxies - and I'm as positive as I can be that I wrote it to media, which is just a partition here - booting with a vm
<elfy> I'm just running through a trusty one to get the testcase right, then I'll have another go with the utopic one - which I am completely sure I've just written to the partition :)
<elfy> infinity: ok - well that's all conspired to make me look daft as a brush ... thanks anyway :)
<bluesabre> infinity: can you add menulibre to the xubuntu packageset for trusty/utopic? I thought it had already been added, but I guess I've just been doing debian syncs all cycle
<Mirv> I wonder what's up with proposed migration of libaccounts-qt, libaccounts-glib and ubuntu-system-settings-online-accounts? I'm not seeing them even in update_output, and they were published in proposed >1h ago.
<Mirv> ok, that was an useful complaint, now they are there. odd delay.
<Wellark> who could take care of these
<Wellark> https://bugs.launchpad.net/ubuntu/+source/libhud-qt/+bug/1360671
<ubot2> Ubuntu bug 1360671 in libhud-qt "drop from archive" [Undecided,New]
<ubot93> Launchpad bug 1360671 in libhud-qt (Ubuntu) "drop from archive" [Undecided,New]
<Wellark> https://bugs.launchpad.net/ubuntu/+source/share-app/+bug/1360670
<ubot2> Ubuntu bug 1360670 in share-app "drop from archive" [Undecided,New]
<ubot93> Launchpad bug 1360670 in share-app (Ubuntu) "drop from archive" [Undecided,New]
<sconklin> Lately I've been having a lot of problems with the US archives, yet there are no updates on the Ubuntu Status twitter account (since June). Is there a problem? http://paste.ubuntu.com/8141244/
<stgraber> sconklin: to be accurate, that's the EC2 US East archive (hosted in EC2), not the US archive (hosted by Canonical in 1SS)
<stgraber> utlemming: ^
<sconklin> stgraber: yes, but the reason I switched to the ec2 archive is because I was getting repeated errors from the Canonical one a couple of weeks ago
<sconklin> I no longer have those error logs
<stgraber> sconklin: rcj just escalated this issue to #is
<sconklin> ok, thanks
<sconklin> what's the appropriate reporting path for archive issues? Not IRC, I would hope
<utlemming> sconklin: the reporting path would be to drop into #ubuntu-mirrors
<sconklin> utlemming: thanks!
<utlemming> sconklin: however, to address the repeated errors, we have engineering on that problem. It is an absolute requirement to have rock stable mirrors. We're aware and working on it.
<utlemming> sconklin: what I think you hit was a problem where S3 is "eventually consistant". In repeated launches, it looks like the issue is cleared. You may need to purge /var/lib/apt/lists/* and run "apt-get update"
<sconklin> utlemming: if I wanted to set up an official full mirror, sponsored and maintained, where would I start - is asing in #ubuntu-mirrors also approriate for that?
<utlemming> sconklin: that would be the place to start, yes
<infinity> rtg: Dude.  If you're going to upload packages I maintain, at least version them correctly.
<infinity> rtg: (or ask...)
<rtg> infinity, which one ? utopic or trusty ?
<infinity> rtg: Yes.
<infinity> rtg: utopic was wrong, which leads to trusty being more wrong. :)
<rtg> hmm, no good deed goes unpunished
<infinity> Quite.
<infinity> rtg: An upstream version rev ahead of Debian should be -0ubuntuX
<infinity> rtg: So Debian's -1 will trump it.
<infinity> rtg: Or, again, just ask me and I would have updated it in Debian and synced.
<rtg> infinity, same for powerpc-utils ?
<infinity> rtg: Oh no.
<infinity> rtg: What did you do to powerpc-utils?
<rtg> nothing yet, but was planning the same buthery
<rtg> butchery*
<infinity> rtg: Yeah, please don't.
<infinity> rtg: And please don't take IBM at their word that all of these should be wholesale SRUed back to trusty either.
<rtg> I was just cleaning up bugs with the ppc64le tag
<infinity> rtg: Kay.  The userspace stuff, I'd prefer if you assign it in my direction, and I can sort out who should own it (though ppc-*-utils and librtas really are me, in that I maintain them in Debian too)
<rtg> infinity, so, do you wanna reject trusty librtas ?
<infinity> I will, yes.
<rtg> I will slink away and do something else
<infinity> I can probably yank the utopic one too, before anything ends up depending on it. :P
<infinity> Aww, dang, it migrated.
<infinity> rtg: Sorry, not trying to be a jerk about it.  And if you'd just versioned with -0ubuntuX, I'd care less, cause I could just overwrite it with a Debian upload.
<rtg> ok, lesson learned
<infinity> rtg: So, please do remember proper "we're ahead of Debian" versioning in the future. :)
<zul> can someone have a look at oslo-config i think its stuck in the proposed-migration or something
<infinity> zul: Or it no longer produces half its binaries.
<infinity> out of date on i386: python-oslo.config-doc, python3-oslo.config (from 1:1.3.0-2ubuntu1)
<infinity> zul: It looks like you completely reverted the Debian merge you'd done earlier.
<zul> infinity:  yeah it got superseeded by a newer requirement for keystone
<zul> infinity:  ill see what i can do
<robru> is anybody around with the power to nuke queuebot? it is flipping it's shit in #ubuntu-ci-eng
<robru> it has somehow become stuck on a single message and is repeating it every time it polls. I even changed the status and it won't report the new status or stop reporting the old status.
<DalekSec> I presume stgraber isn't around?
<robru> oh, just noticed he's in this channel. he isn't in ci-eng channel
<robru> stgraber: http://paste.ubuntu.com/8144951/ so that's a thing
<wxl> we close to beta1 testing yet?
#ubuntu-release 2014-08-26
<elfy> stgraber: not sure if releasetasksignup is right - but, if the mail to release asking for who's participating lands today I'm not sure I'll see it - Xubuntu DO want to participate in Beta's - thanks
<stgraber> elfy: noted, thanks
<stgraber> elfy: yeah, I'll send the e-mail out in a few minutes, I unfortunately was rather busy yesterday and couldn't get to it... (was traveling all of last week so had some catching up to do...)
<stgraber> Riddell: will Kubuntu participate in Beta 1? If so, are all products participating (Desktop + Plasma 5)?
<Riddell> stgraber: hi, yes I'm all for beta 1 and I'm all for desktop and plasma5 to be in it
<stgraber> zequence: are you planning on releasing a beta 1 this week?
<stgraber> Riddell: perfect, thanks
<stgraber> utlemming, rcj: are you guys participating in beta 1?
<rcj> stgraber, yes
<stgraber> JackYu: hey there, are you planning to participate in Beta 1?
<stgraber> who are the contacts for Ubuntu Gnome and Lubuntu these days?
<JackYu> stgraber, yes:)
<elfy> stgraber: wxl is the lubuntu QA guy I believe
<stgraber> ah cool.
<stgraber> wxl: hey there, are you going to release a Beta 1 this week?
<stgraber> Riddell: so I'm updating the manifest with the current contacts for all flavours, is ScottK still the right fallback for when you're not around?
<Riddell> let me check
<stgraber> ideally, I'd like to have two contacts listed for each flavour, that makes reaching people a bit easier :)
<elfy> stgraber: listed where?
<stgraber> elfy: http://iso.qa.ubuntu.com/qatracker/series/43/manifest
<stgraber> elfy: speaking of which, do you have a fallback contact for Xubuntu?
<elfy> stgraber - knome was the project lead - new one is ochosi on IRC Simon SteinbeiÃ - and there's me QAing
<elfy> I was getting there :p
<stgraber> cool, so I'll list you first and ochosi as the fallback
<elfy> yep - wfm
<stgraber> rcj: I've updated the cloud image contacts to be you and utlemming now (with you as the first contact)
<stgraber> superm1: when doing mythbuntu release-y things, do you have a backup contact?
<superm1> tgm4883:
<stgraber> thanks
<stgraber> elfy: xubuntu desktop failed to build
<stgraber> Unpacking xubuntu-live-settings (14.10.4) ...
<stgraber> dpkg: error processing archive /var/cache/apt/archives/xubuntu-live-settings_14.10.4_all.deb (--unpack):
<stgraber>  trying to overwrite '/etc/xdg/xdg-xubuntu/autostart/light-locker.desktop', which is also in package xubuntu-default-settings 14.10.4
<zequence> stgraber: I think we will skip it this time around, and just do the final beta.
<stgraber> zequence: ok
<smoser> hey. i'ave 2 questions
<smoser> a.) do we actually need a FFe for bug 1361737
<ubot2> Launchpad bug 1361737 in ubuntu "[ffe] New dependency for openstack python-oslo.utils" [High,New] https://launchpad.net/bugs/1361737
<ubot93> bug 1361737 in Ubuntu "[ffe] New dependency for openstack python-oslo.utils" [High,New] https://launchpad.net/bugs/1361737
<smoser> b.) why did that not automatically sync. it was accepted into testing on 2014-08-19
<gaughen> infinity, slangasek, stgraber any thoughts on smoser's question above?
<stgraber> smoser: for b), quite simple, because the 19th is after the 7th (DIF)
<smoser> ah. yeah. that is quite simple
<stgraber> smoser: I'm never quite sure if we need a FFe for new packages, anyway, I granted that one.
<stgraber> from a whole distro point of view, it's a new feature, though what we really care about post-feature freeze is new features in existing packages, not so much new packages
<smoser> stgraber, additionally to argue that it is not needed... there is a broken package if we dont pull it in (well, not now, but guaranteed on next upload)
<smoser> thanks.
<elfy> stgraber: mmm - so - we wait to see if it builds next time around?
<stgraber> elfy: your package is busted, I'm pretty much sure I can build it 50 times and it'll still fail
<elfy> ok - thanks
<stgraber> elfy: xubuntu-live-settings and xubuntu-default-settings both ship the same file, so you get a conflict at install time and dpkg fails
<stgraber> elfy: so just drop light-locker.desktop from one of the two and you should be fine (unless there are other similar conflicts later on)
<elfy> k - ty, ochosi bluesabre ^^
<elfy> yep - that'll be someone else's issue to deal with - way above my paygrade :)
<gaughen> stgraber, since you have surfaced and are being super helpful, are you an archive admin too?
<gaughen> don't run and hide stgraber!
<elfy> stgraber: looking at jenkins I'm guessing it all went wrong 2 days ago, that being the last daily we seem to have
<stgraber> gaughen: I'm an archive admin but kinda busy with other things at the moment :)
<gaughen> stgraber, darn it! okay, zul had two packages he needed pushed fwd.
<stgraber> gaughen: besides, I probably shouldn't be reviewing python-lxc seeing how I'm the upstream for that one :)
<gaughen> stgraber, now *that* is a very fair reason. you are a bit biased, eh?
<stgraber> gaughen: yeah, haven't quite reached the point where I don't remember any of that code yet ;)
<Riddell> bah all the slideshows still say 14.04
<Riddell> uploaded version 85 of ubiquity-slideshow
<Riddell> stgraber: you not put in the package freeze?
<stgraber> Riddell: I usually put it in place mid-afternoon on Tuesday which is in a couple of hours
<Riddell> ah, you moved across the planet
<stgraber> Riddell: I do that occasionaly :)
<wxl> stgraber: yep thanks for the update i'll get on it right now. i've been waiting impatiently :)
<stgraber> wxl: ok, adding you and spinning some images then
<stgraber> wxl: do you want both alternate and desktop on amd64, amd64+mac, i386 and powerpc or just a subset of that?
<wxl> stgraber: yes, i want all of them. we might not get the ppc/amd64+mac again, but it's worth a shot.
<stgraber> wxl: building now
<wxl> stgraber: btw do YOU know the *exact* targets for amd64+mac? it seems to me there are no intel macs this is relevant to anymore, since apple now offers firmware updates.
<stgraber> wxl: no idea, sorry
<wxl> stgraber: that seems to be everyone's impression. ;)
<wxl> stgraber: is it too early for me to make a release note to our users?
<stgraber> wxl: so usually I don't maintain any central list of release notes, feel free to create a wiki page for your product and give me the link so I can include it in the announcement on Thursday
<wxl> stgraber: i'll work on it throughout the final testing and have something final by then. meanwhile: https://wiki.ubuntu.com/UtopicUnicorn/Beta1/Lubuntu
<wxl> stgraber: and sorry i didn't mean a release note, i meant a testing announcement XD
<stgraber> wxl: well, maybe wait for your desktop images to finish building too, but otherwise, no reason not to get testers now.
<wxl> stgraber: that's what i figured :)
<stgraber> ok, time to setup the beta1 migration block
<cjwatson> stgraber: err I was *almost* done with perl 5.20 and am a bit worried it'll bitrot if I leave it further
<cjwatson> stgraber: I don't suppose it would be possible to finish that?  I just need to test-build perlkde against my putative perlqt fix, then upload perlqt, then retry perlkde
<stgraber> cjwatson: I don't think anyone would mind you getting those in so long as they make it in today
<cjwatson> I think I should be an hour or two away
<stgraber> ok, sounds good then
<cjwatson> so you'd prefer me to just do a giant unblock, rather than deferring the master block?
<stgraber> cjwatson: well, the giant block is already in place and I may not be around when you land your stuff, so it may be simpler for you to either do a giant unblock or just comment my block for one britney run when you're ready
<stgraber> I'm not aware of anything currently in proposed which flavours want to avoid migrating to the release pocket, so either way should be fine
<cjwatson> OK, giant unblock is doable I guess, thanks
<infinity> cjwatson: commenting the block gets a new kernel too, which might be wanted (and may well not be).
<infinity> stgraber's call, though.
<stgraber> infinity: just went through the changelog, not seeing anything urgent in there (nor anything harmful), so I guess we'll just minimize the changes for now in the hope of getting beta1 images ready ASAP so we can lift the whole block then
<infinity> stgraber: *nod*
<bluesabre> stgraber: uploaded a xubuntu-default-settings that will fix the beta build failure, in proposed now
<gaughen> cjwatson, infinity if you all have a break between sessions, was hoping I could get you to put your archive admin hat on and look at python-lxc and granite, pretty please!!!!
<stgraber> bluesabre: ok, I'll push an unblock for it
<bluesabre> stgraber, thanks!
#ubuntu-release 2014-08-27
 * cjwatson unblocks the perl transition, hopefully
<cjwatson> giant unblock line :)
<cjwatson> proposed-migration is taking a while ...
<elfy> morning - I see that the xubuntu issue should be sorted now, can we get a rebuild of our image for testing please - tia
<bzoltan> hello, I am about to release a new UI Toolkit package and I see here http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html that the landing is blocked with "Not touching package due to block request by freeze" excuse.
<asac> anyone can help bzoltan ?
<cjwatson> bzoltan,asac: unblocked
<bzoltan> cjwatson: Thank you
<asac> cjwatson: nice one! you should really be in bed though :(
<asac> (i guess)
<asac> thanks a bunch!
<cjwatson> eh, whatever, I wouldn't usually be in bed at only 12:30 at home and my sleep patterns are all funny here
<ochosi> stgraber: hey there! elfy previously mentioned it in this chan, but the problem with the xubuntu iso should be fixed now, so if you could do a rebuild of the image that'd be great! thanks!
<Saviq> is the status in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#url-dispatcher correct? /topic says archive is open?
<cjwatson> topic is wrong
* cjwatson changed the topic of #ubuntu-release to: Released: Trusty Final, Utopic Alpha 2 | Archive: frozen for beta 1 | Utopic Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis
* cjwatson changed the topic of #ubuntu-release to: Released: Trusty Final, Utopic Alpha 2 | Archive: migration blocks in place for beta 1 | Utopic Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis
<cjwatson> Saviq: I've unblocked url-dispatcher
<Saviq> cjwatson, thanks
<elfy> hi - is there anyone about who can get a xubuntu utopic beta built please
<elfy> didn't see that ochosi had asked earlier - sorry :)
<Mirv> could someone please unblock webbrowser-app from the freeze?
<Mirv> bzoltan: ^
<Mirv> it includes a fix that would be needed together with the ubuntu-ui-toolkit that was already unblocked earlier
<zul> can someone de-binary new python-oslo.utils please?
<cjwatson> Mirv,bzoltan: done
<bzoltan> cjwatson: thanks
<Mirv> thanks
<stgraber> ochosi: rebuilds are usually self service nowadays from the ISO tracker UI. Anyway, kicked one for you now.
<ochosi> stgraber: self service? is that hard to do/learn or does one need special rights for that?
<ochosi> thanks anyway though!
<ogra_> stgraber, oh, since you say iso tracker ... rtm is there bug missing any entries to select actual builds
<ogra_> smells like we miss some backend stuff there
<stgraber> zul: there you go
<zul> stgraber:  thank you
<stgraber> ochosi: not very hard, head to iso.qa.ubuntu.com, login, make sure to tick any team boxes listed on the SSO page, then on the milestone page, select the products you want to rebuild and click the rebuild button at the end of the page
<ochosi> stgraber: oh great, i'll look into that!
<stgraber> ogra_: ok, so the problem seems to be that nusakan never managed to push a build to the tracker for rtm...
<ogra_> ah
<stgraber> KeyError: "Milestone 'Unknown series' not found"
<elfy> stgraber: oh ... I didn't realise we could trigger a rebuild when there's not one available on the tracker otherwise I would have done so - sorry
<ogra_> heh, yeah ... its not even ubuntu :)
<stgraber> ogra_: how urgent is it? I'
<stgraber> *I'm sort of busy with other things and I suspect cjwatson is busy being at Debconf at the moment
<ogra_> not super urgent ... the stuff from the mail thread is more urgent
<ogra_> (getting system-image set up asap )
<ogra_> i can build manually on nusakan for the time being
<ogra_> or rsalveti for the US shift
<shadeslayer> sigh
<shadeslayer> https://code.launchpad.net/~rohangarg/ubiquity/plasma5/+merge/228528 < languishing in review for a month
<shadeslayer> not cool
<Riddell> shadeslayer: onto it
<shadeslayer> cheers
<shadeslayer> Riddell: mind uploading/respinning ISO's?
<shadeslayer> Riddell++
<Riddell> yay, colin fixed perlkde!
<Riddell> genius
<Riddell> well obviously he broke it in the first place by uploading the new perl, but still genius
<Riddell> umm, what are those 25 entries?
<shadeslayer> 0.o
<stgraber> Riddell: cloud images + xubuntu
<shadeslayer> you know the world is weird when PPC finishes before x86*
<stgraber> new Power machines are quite a bit faster than x86 these days
<Riddell> stgraber: will you add upgrade tests?
<stgraber> the problem is that most people got used to the very old ppc kit we had which was indeed kinda slow
<stgraber> Riddell: I can do that yeah
<Riddell> stgraber: would you know what to report problems in the initial boot menu on the live image as? there's no option for OEM and a random Back.. menu entry
<stgraber> Riddell: that'd probably be gfxboot, unless you're testing on efi
<Riddell> bug 1362225 and bug 1362226 reported
<ubot2`> Launchpad bug 1362225 in gfxboot "menu option for "Back..."" [Undecided,New] https://launchpad.net/bugs/1362225
<ubot2`> Launchpad bug 1362226 in gfxboot "No OEM option in pre-boot menu" [Undecided,New] https://launchpad.net/bugs/1362226
<ubot93> bug 1362225 in gfxboot (Ubuntu) "menu option for "Back..."" [Undecided,New] https://launchpad.net/bugs/1362225
<ubot93> bug 1362226 in gfxboot (Ubuntu) "No OEM option in pre-boot menu" [Undecided,New] https://launchpad.net/bugs/1362226
<Riddell> gosh, double the bug bots
<shadeslayer> Riddell: they had bug reports already
<Riddell> shadeslayer: oh?
<shadeslayer> yes
<Riddell> where?
<shadeslayer> on launchpad somewhere
<shadeslayer> see previous image testing
<Riddell> bug 1334189
<ubot2`> Launchpad bug 1334189 in gfxboot-theme-ubuntu "syslinux offers no OEM mode on Kubuntu Utopic Alpha 1" [Undecided,Confirmed] https://launchpad.net/bugs/1334189
<ubot93> bug 1334189 in gfxboot-theme-ubuntu (Ubuntu) "syslinux offers no OEM mode on Kubuntu Utopic Alpha 1" [Undecided,Confirmed] https://launchpad.net/bugs/1334189
<Riddell> how do syslinux and gfxboot relate?
<shadeslayer> Riddell: it's the same thing, I called it syslinux, though I think the correct name is gfxboot
<Riddell> stgraber: we need a respin of kubuntu-plasma5 once ubiquity is in but I'm about to leave, shadeslayer has bravely volunteered to be the co-contact for the kubuntu-plasma5 images, could you also set him up with access to iso.qa to respin the images?
<stgraber> Riddell: access is done through team membership, so you'd need to setup a new LP team for that, make shadeslayer a member of it and then I can add that to the tracker
<Riddell> stgraber: what team is used currently?
<stgraber> Riddell: none because both you and ScottK are members of ~ubuntu-release which has right on every product already
<Riddell> oh I see
<Riddell> stgraber: can you use ~kubuntu-council then?
<stgraber> sure
<Riddell> never like to set up yet another team if it can be avoided
<Riddell> or ~kubuntu-dev maybe?
<shadeslayer> too broad?
<Riddell> shrug, all trusted people
<stgraber> kubuntu-dev means all coredevs too, so probably not that great an idea
<Riddell> yeah, those coredev are a pretty dodgy lot :)
<stgraber> :)
<stgraber> shadeslayer: you should be all set
<stgraber> took a while because you guys had a ton of products I had to update :)
<shadeslayer> question, is there a special page I have to go to?
<shadeslayer> nope
<shadeslayer> stgraber: how do I respin ISO's?
<ogra_> shadeslayer, http://iso.qa.ubuntu.com/
<ogra_> log in
<stgraber> shadeslayer: so when you login to the tracker it should show you a tick box for kubuntu-council
<ogra_> click on "utopic daily"
<stgraber> shadeslayer: once logged in, head to the beta-1 page, you should see tick boxes
<ogra_> check the products yu want to see on the left
<stgraber> shadeslayer: tick the ones you want to respin and head to the bottom of the page and select rebuild
<ogra_> set a checkmark on the right for the ones you want to re-spin
<shadeslayer> ahhh
<shadeslayer> ok
<ogra_> and select rebuild
<shadeslayer> stgraber: ogra_ thanks
<ogra_> :)
<shadeslayer> I went to the admin page
 * ogra_ is in parrot mode today :)
<shadeslayer> and was trying to look there
 * shadeslayer gives ogra_ some chillies
<ogra_> yummy !
<shadeslayer> huh
<shadeslayer> all the builders seem to be in Cleaning mode
<shadeslayer> what's that?
<apw> i assume you mean the PPA builders ...
<ogra_> probably the mode where they all switch to UPS power ... so the cleaning woman has a free socket for vaccum cleaning
<shadeslayer> heh
<shadeslayer> apw: yes
<apw> shadeslayer, someone is poking it for us
<shadeslayer> :)
<shadeslayer> plasma 5 ISOs rebuilding
<zul> can an archive admin please review python-osprober, python-lxc, and openstack-granite please?
<apw> shadeslayer, and it looks un-bungged now
<smoser> hey..
<smoser> i uploaded percona-* before feature freeze (https://launchpad.net/ubuntu/utopic/+queue?queue_state=0&queue_text=)
<smoser> since they're not cleared from New, do i needto open a FFE to get them in ?
<stgraber> no, we usually look at the upload date
<gaughen> jdstrand, arges  oh great archive admins, would one of you please have a look at openstack-granite, python-lxc, python-osprofiler pretty please!!!!
<arges> gaughen: sure
<shadeslayer> So how come the plasma 5 iso is still rebuilding ?
<arges> gaughen: i dont see those packages in the upload queue, nor as pending srus. What are you looking for exactly?
<wxl> i finally found someone to do amd64+mac testing but he won't be able to finish until 28 Aug 1200 UTC. is that beyond the cutoff for testing?
<stgraber> shadeslayer: it failed to build
<wxl> â stgraber
<stgraber> wxl: 1200 UTC tomorrow should be fine I think, I plan on releasing in the afternoon here
<stgraber> (here being US/Canada east coast)
<shadeslayer> stgraber: oh? :S
<stgraber> shadeslayer: http://people.canonical.com/~ubuntu-archive/cd-build-logs/kubuntu-plasma5/utopic/daily-live-20140827.log
<stgraber> no log though, that's not super useful... let me re-trigger see if that fixes it
<shadeslayer> Yeah :/
<shadeslayer> stgraber: thx
<wxl> stgraber: sounds good. i'm us/ca west
<wxl> stgraber: if you're wondering what's going on, just ping me
<shadeslayer> stgraber: would be nice if the state actually reflected that it failed
<shadeslayer> I only checked iso.qa.ubuntu.com every 30 minutes or so
<gaughen> slangasek, cjwatson, infinity --^
<gaughen> oh shoot, I didn't see your reply arges, silly irc not scrolling
<gaughen> zul, can you answer arges questions.
<stgraber> arges: they are in utopic new
<stgraber> arges: https://launchpad.net/ubuntu/utopic/+queue
<arges> stgraber: ahh i automatically assumed it was a trusty thing
<arges> gaughen: are there bug numbers associated with these new packages?
<shadeslayer> stgraber: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/utopic/kubuntu-plasma5/+build/5057 i386 failed again
<shadeslayer> muchos fun
<shadeslayer> stgraber: shall I hit rebuild again on i386?
<stgraber> shadeslayer: let's see what happens to amd64 first
<stgraber> the lack of build log is really rathe annoying though
<shadeslayer> ack
<shadeslayer> stgraber: I think amd64 succeeded
<stgraber> yeah, looks like it did
 * shadeslayer hits rebuild on i386 then
<stgraber> I'll trigger yet another build once that one finishes (it'll fail unless both build)
<shadeslayer> oh
<stgraber> don't do that, it won't notice it
<shadeslayer> I see
<shadeslayer> did not know
<shadeslayer> holding off then
<dbarth> hi
<dbarth> i'm trying to get the new oxide (1.2) be acked for landing in utopic
<dbarth> oxide 1.2 is a pre-requ. for a new webapp autologin feature, part of an upcoming silo landing (7)
<dbarth> please advise what I need to provide to unfreeze oxide
<dbarth> it may just be the normal multi-arch issue, where oxide is not avaiable but on x86 and armhf
<dbarth> for ref: https://launchpad.net/ubuntu/+source/oxide-qt
<shadeslayer> dbarth: maybe its because of the utopic archive freeze?
<dbarth> shadeslayer: happening right now?
<dbarth> well, if so, i missed that part of the schedule
<stgraber> dbarth: beta 1 is this week, archive is partly frozen until at some point tomorrow
<dbarth> hmm, the channel topic update is recent indeed
<dbarth> ok, i'll try my luck tomorrow then ;)
<shadeslayer> ^^
<shadeslayer> dbarth: don't ubuntu-phone things get a freeze exception?
<shadeslayer> I vaguely recall seeing something related to ubuntu-phone things getting a exception
<dbarth> i'd love if i can get such an exception
<dbarth> the utopic landing for this silo is really tomorow morning, so i guess i can ask to the EU/UK folks tomorrow
<shadeslayer> hurray
 * shadeslayer tests
<shadeslayer> stgraber: heh yeah, I broke it :p
<shadeslayer> tomorrow is going to be fun
<asac`> stgraber: i believe slangasek said at some point that such "beta" freezes shouldn't really exist or at least shouldn't be any practical hinderance anymore? just remember that any landing coming from touch is super critical at this point in time.
<asac`> this was about oxide-qt request
<asac`> err whatever dbarth wanted
<gaughen> arges, Chuck submitted these before feature freeze so we thought a bug wasn't needed
<gaughen> and apologies for the delay, I had to bug zul
<asac`> would be cool if someeone could check out dbarth's unfreeze request above from release team for his touch landing
<asac`> thanks
<stgraber> asac: we don't do hard freezes, so people are still free to upload as they wish, so on that side it's much more relaxed that in the past. The only thing we do is hold the packages in -proposed until after the freeze is lifted.
#ubuntu-release 2014-08-28
<zul> arges:  no because they were uploaded before the feature freeze
<jdstrand> fyi, the squid3 in utopic-proposed is for a security update. wouldn't mind if it went through, but it's ok to wait if it would cause more work for people
<infinity> jdstrand: There is no squid3 in proposed...
<infinity> Oh, you JUST copied it.
<jdstrand> yeah, I pre-advised
<infinity> jdstrand: It should migrate unhindered, I imagine.
<jdstrand> s/in utopic-proposed/on its way to utopic-proposed/
<jdstrand> ok cool
<jdstrand> thanks
<dbarth> hi, so following the discussion with stgraber later yesterday, how can i get oxide-qt-1.2 to pass in utopic?
<tseliot> hi, can an admin please approve ubuntu-drivers-common in utopic-proposed (it says "Not touching package due to block request by freeze") ?
<infinity> tseliot: The block message should be pretty clear, I'd think.
<infinity> tseliot: stgraber will remove the block when the current milestone is out.
<tseliot> infinity: oops I misread the release schedule
<Sweetshark> hi there. When will the utopic freeze lift? We have a libreoffice package in there that upstream just released talking about CVEs: http://blog.documentfoundation.org/2014/08/28/libreoffice-4-3-1-fresh-announced/ -- unfreezing could prevent a launchpad bug filing galore ...
<Sweetshark> (FWIW, it seems both CVEs are Windows-only anyway)
<Sweetshark> correct that: the CVEs are not windows-only, so an update would be appreciated.
<zul> arges: #1362579 - python-osprofiler, #1362586 - openstack-granite, and #1362588 - python-lxc
<Riddell> new ubiquity up to revert change I made yesterday which tried to add sddm support but didn't work
<Riddell> Sweetshark: should be this evening
<arges> zul: so i'm not on the ~ubuntu-release team so you'll need to get their ack on those new packages.
<zul> arges:  k
<Riddell> stgraber: kubuntu-plasma5 images will appear at http://cdimage.ubuntu.com/kubuntu-plasma5/releases/utopic ?
<stgraber> Riddell: that looks right
<elfy> stgraber: our release notes will be at https://wiki.ubuntu.com/UtopicUnicorn/Beta1/Xubuntu
<stgraber> elfy: thanks.
<elfy> is there a utopic one of these https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes/
<elfy> I can't find one
<ogra_> stgraber, just a FYI ... you forgot to re-enable the s-i cronjob :)
<ogra_> i switched it on again so we could get images from the nightly builds ...
<ogra_> (i.e. dont rely on that it is off)
<stgraber> elfy: not at this point. We usually don't set that up for the opt-in milestones and instead let the flavours organize things on their end.
<stgraber> ogra_: oops, sorry about that
<ogra_> stgraber, yeah, no prob, i just want that you are aware it  is on again
<elfy> stgraber: okey doke, thanks
<dbarth> stgraber: hi; can you confirm if phone updates can get a freeze exception? i'm pinging again about the oxide-qt 1.2 held in proposed
<stgraber> dbarth: if you're calling about the beta-1 freeze, then the answer is no. We only block the source packages which DO affect the products participating in the beta. So if your package is held, it's because one of its binary packages is somehow part of the images we'll be releasing in a few hours.
<stgraber> dbarth: according to seeded-in-ubuntu, binary packages coming from oxide-qt are included in ubuntukylin which does participate in this beta
<dbarth> so we're stuck, ok
<dbarth> lifted around when? monday? tuesday?
<stgraber> in the next 2-3 hours
<dbarth> oh, even better; then i'll come back in a bit ;)
<dbarth> cool
<dbarth> thanks for your patience
<stgraber> Riddell, wxl, elfy, rcj: http://pad.ubuntu.com/14-10-beta1-announcement
<Riddell> stgraber: you don't need a quote for the betas :)
<rcj> stgraber, Added a suggestion in the pad to call out cloud daily builds separate from those on cdimage.u.c
<rcj> stgraber, I'm just waiting on utlemming to review the text as well.  I'm not sure if we have updates for our example clouds.
<stgraber> rcj: ok, I'm still waiting for kubuntu and lubuntu to mark their images ready so it'll likely be another 2 to 3 hours before I send out the announcement
<jdstrand> arges: hey, would you be able to verify 1294861?
<jdstrand> bug 1294861
<ubot2`> Launchpad bug 1294861 in eglibc "time zone files are not set up correctly" [Medium,Fix committed] https://launchpad.net/bugs/1294861
<ubot93> bug 1294861 in eglibc (Ubuntu Trusty) "time zone files are not set up correctly" [Medium,Fix committed] https://launchpad.net/bugs/1294861
<jdstrand> arges: there is a security update that infinity prepared built on top of that and he said we could publish if you verified it
<wxl> stgraber: any idea why all of a sudden i can't edit any more?
<wxl> stgraber: nevermind. ibus/chrome :(
<arges> jdstrand: yes i'll verify it
<jdstrand> thanks!
<jdstrand> no, if only the sparc build would finish
<jdstrand> now*
<arges> jdstrand: ok its verifeid
<arges> verified
<jdstrand> arges: thanks!
<rcj> stgraber, Cloud text is good in the announcement notes.  Images are available @ EC2 and Azure now.
<wxl> stgraber: lubuntu is ready with i386, amd64, amd64+mac and if i can play my cards right, maybe ppc
<stgraber> wxl: cool, can you update the tracker to reflect that?
<wxl> stgraber: oh yeah sure duh
<stgraber> Riddell: how about you?
<stgraber> I'm about to head out for lunch, so my plan is to start publishing when I'm back, that is in about an hour if that works for you guys?
<wxl> stgraber: sorry still getting used to being a release manager :)
<Riddell> stgraber: yeah should do, just starting testing new plasma5 imagse
<Riddell> welcome along wxl
<wxl> thanks Riddell :) you're kubuntu?
<elfy> hi wxl :)
<wxl> hi elfy :)
<Riddell> wxl: yep, the original and best linux desktop :)
<Riddell> I might be biased on the second point there
<wxl> Riddell: probably a bit. how's plasma 5 coming along?
<Riddell> wxl: ask me in half an hour when this install is done :)
<wxl> Riddell: heheh ok
<wxl> man, ibus is weird sometimes :/
<Riddell> input methods are always weird
<wxl> well it wasn't playing nice with chrome and then i restarted it and it works fine. i dont' know. i work here from the neck down.
<Riddell> nobody has ever understood them who lives west of china
<wxl> hahahah
<Riddell> yes we had chrome not taking any input recently when ibus was installed
<wxl> Riddell: here's my big question for kubuntu: does unicode input work like one would expect??
<Riddell> wxl: what do you mean, lots of characters are unicode
<wxl> Riddell: like in konsole. can't ctrl-shift-u <some control code>
<Riddell> you mean CKJ characters?
<Riddell> I don't think we have a feature like ctrl-shift-u <some control code>
<Riddell> I can change keymapping fine and then I get Â¡spanish characters!
<wxl> even my compose key doesn't work right in konsole
<wxl> ibus fixes things up
<wxl> i've just never had this issue in any other flavor i've dealt with
<Riddell> how do you mean compose key?
<Riddell> Ã© Ã« et al work fine in konsole if I have a spanish keyboard set, they need two keypresses
<wxl> like i can do <compose key (which i ahve set to alt)> .. and i get â¦
<Riddell> how do you set compose key?
<wxl> i don't need to use different languages, per se, i need to use different characters that are ultimately universal (like math characters)
<wxl> in keyboard settings i think
<wxl> but the unicode is the weirdest part
<wxl> ctrl-shift-u has worked in every distro i've ever dealt with except kubuntu
<wxl> sorry everyone i don't mean to make this #kubuntu :)
<tgm4883> If I wanted to add a media file (mp4) to the mythbuntu ISO, would we need to package that mp4 up, or is there another way for adding media files?
<Riddell> tgm4883: best just package it up like ubuntu unity does
<tgm4883> Riddell: good to know. Thanks
<Riddell> see example-content
<Riddell> wxl: if I set compose key in settings I can now compose stuff like Ã© with my english uk keyboard
<Riddell> using compose-'-e
<Riddell> compose-.-. gives me Ë
<Riddell> which is handy to know for speaking Catalan
<wxl> Riddell: that's what i mean! it acts differently than elsewhere
<wxl> Riddell: and still compose key doesn't help with things like â
<wxl> i mean i could make it as such, but this should be native stuff that "just works"
<wxl> Riddell: and from what i can tell scanning bug reports complaints about it gets responses like "we do input differently"
<Riddell> hmm well I'm afraid I've no idea but I'm going to akademy next week so I could try asking the locale dude, he knows all
<wxl> Riddell: that'd be super cool. let me know! and to be clear, MY issue is not about language or locale, but about wanting to use things like mathematical symbols or the occassional emoji âº
<wxl> wow i wish akademy was in the US. i'd go.
<wxl> btw, to be clear, my loyalties lie with lubuntu but we use kubuntu at work :)
<Riddell> we'll take you willing or not :)
<wxl> well i tried to get lubuntu going for our standard desktop but our main it guy insisted on having something a bit more user friendly. i hadn't used kde since, well, a long time. i was rather pleased with the change :)
<Riddell> wxl: what does lubuntu recommend these days for making usb drives with the images on?
<wxl> Riddell: well i still recommend dd :) but i've also had good luck with unetbootin. we have also had a lot of suggestions to use mkusb but i've never done it.
<Riddell> makes me sad that we don't have a good answer for the very important issue of installing our product :(
<wxl> Riddell: dd never fails my friend
<Riddell> wxl: until you mistype and it wipes your hard disk!
<wxl> Riddell: so don't mistype. i've used it for years and never had a problem.
<wxl> Riddell: but really unetbootin hasn't ever failed me either
 * wxl is STILL trying to get ppc testing done. with first time testers. 
 * wxl chews his fingernails.
<Riddell> you still have ppc?  my old mac died years ago
<wxl> i have a couple ppcs but didn't have time to do the actual testing myself Riddell
<Riddell> wxl: I'm stating to feel the pain of not having automated install tests like ubuntu does with Utah
<Riddell> I wish I knew how to make them
<wxl> Riddell: yeah that would be so nice
<infinity> Riddell: Talk nicely to jibel, I'm sure he can help point you in the right direction (and I think, but am not sure, that we might even do some automated smoketesting for flavours already).
<infinity> Riddell: Not that one shouldn't also manually test, which always finds a different class of bugs (ie: the bugs you don't already know about and test for), but it's a good start to know if things are complete crap.
<elfy> is that the stuff reported at jenkins?
<infinity> Maybe?
<infinity> I'm actually remarkably ignorant to how much automation we do or don't have for flavours, and where it is.
<elfy> https://jenkins.qa.ubuntu.com/view/Ubiquity/view/Lubuntu/ <-wxl
<infinity> Ahh, I see no matching Kubuntu URL here.
<elfy> yea
<infinity> I guess it might just be a matter of asking?
<wxl> elfy: wuzzat?
<elfy> infinity: well a question asked generally gets an answer - I'd not know it though :)
<elfy> wxl: auto tests
<infinity> jibel would know, if he's around.
<wxl> elfy: huh. interesting.
<elfy> yea
<elfy> wxl: very useful - it would be have been a whole lot more if I'd noticed ours were failing 2 or days prior to beta - we might have not had to run about at the last minute :)
<elfy> and now I've seen the rss feed for that ...
<wxl> elfy: if we have an issue there, should we just file a bug against ubiquity? also, what about the alternates?
<elfy> wxl I can't answer those questions
<wxl> elfy: hehehe ok :)
<Riddell> stgraber: kubuntu-plasma5 is broken on i386 but works on amd64, can we publish 1 arch only?
<stgraber> Riddell: sure
<stgraber> Riddell: simply mark the one that works as ready, anything that's not ready doesn't get published
 * Riddell makes it sew
<stgraber> wxl: so what's going on with powerpc?
<wxl> stgraber: i got a tester working on it, or at least he said he was
<stgraber> wxl: ok, so I'm ready to push out beta-1 here and all the other flavours are ready, do you have any kind of ETA on that?
<wxl> stgraber: well i said we'd probably release around 2100 utc so ig you're ready you should probably just push it out and we'll call it a learning experience
<wxl> â¦unless you want to wait
<stgraber> Riddell, rcj, elfy: are you guys fine with waiting another 2 hours?
<wxl> even if i can just have the alternate done it will make a darn big difference
<elfy> stgraber: yea I'm fine with that - all we need to do is publish something external
<stgraber> wxl: I'm around for the next 4 hours so I don't really mind on my end, but it depends on the other folks, so if they're all fine with it, we can do that
<wxl> stgraber: sounds good, thanks.
<Riddell> should be fine
<stgraber> ok and rcj is US based so that should be easy for him too, let's plan on releasing at 20:30 UTC then
 * stgraber goes to work on other stuff till then :)
<Riddell> 1 hour to go!
<rcj> stgraber, that's fine.  our beta-2 image are available for cloud use now actually
<wxl> thanks folks!!!
<elfy> wxl: that's ok, one day the boot'll be on the other foot :p
<stgraber> I'm going to drop the beta 1 migration freeze now though since none of you are going to be respinning anyway
<wxl> elfy: i just hope the guy gets done in time yikes
<stgraber> Riddell: 1 hour? are you confusing UTC and BST?
* stgraber changed the topic of #ubuntu-release to: Released: Trusty Final, Utopic Alpha 2 | Archive: open, feature freeze | Utopic Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis
<wxl> ok i sent a message to the tester in mind to tell him he's got two hours and told him to make sure he at least gets the alternate done
<wxl> we may have to release the alternate only. he's kind of new to testing, soâ¦
<Riddell> #
<elfy> sounds like awesome fun ;)
<jibel> Riddell, we have most of the flavours on https://jenkins.qa.ubuntu.com/view/Ubiquity/view/All/? as infinity pointed out, just not Kubuntu. If someone wants to write autopilot tests for UI driven installations, I'm happy to add them
<wxl> jibel: docs on writing tests are where?
<Riddell> jibel: yes, what would that involve?
<jibel> wxl, Riddell this is the tool we use to execute the tests http://unity.ubuntu.com/autopilot/, current ubiquity test are written for gtk but autopilot supports a qt backend as well
<jibel> the code of current tests is in ubiquity trunk http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/files/head:/autopilot/
<jibel> you can use it as example
<wxl> jibel: and this is only for UI software?
<Riddell> jibel: how does this relate to utah?
<jibel> wxl, yes
<jibel> Riddell, it's different from utah. Utah is doing preseeded installations and doesn't exercise the UI.
<wxl> jibel: so one could use utah for the alternate installer?
<jibel> wxl, yes
<wxl> jibel: cool thanks for the heads up!
<Riddell> jibel: what's the use of testing preseeded installations?
<jibel> plars, ^ where is the code of iso smoke test we run with utah?
<wxl> jibel: are you also one of the parties responsible for managing utah tests?
<jibel> Riddell, you find all sort of issues with the base components of the installer
<plars> jibel: iirc that's all in lp:ubuntu-test-cases and lp:ubuntu-test-runlists
<wxl> jibel: where are the results of utah tests? on jenkins as well?
<plars> wxl: http://ci.ubuntu.com/smokeng/utopic/desktop/ for desktop
<wxl> plars: thanks!
<wxl> plars: there used to be alternates for precise but now there are not?
<plars> wxl: iirc, the alternative image was dropped in 12.10 or so
<wxl> plars: well not for lubuntu :)
<plars> wxl: none of the flavors are covered by these tests though
<wxl> plars: well time to get writing :)
<mapreri> umh... why anjuta is not migrating?
<Riddell> mapreri: probably blocked by beta freeze?
<mapreri> Riddell: since 07-21? umh... today is beta1, let's see tomorrow...
<cjwatson> mapreri: it makes anjuta-extras uninstallable, as noted in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<cjwatson> Depends: libanjuta-3-0 (>= 2:3.2.0), libc6 (>= 2.4), libcairo2 (>= 1.6.0), libgcc1 (>= 1:4.1.1), libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.31.8), libgtk-3-0 (>= 3.3.16), libpango-1.0-0 (>= 1.18.0), libpangocairo-1.0-0 (>= 1.14.0), libstdc++6 (>= 4.1.1), dconf-gsettings-backend | gsettings-backend, anjuta (>= 2:3.10), anjuta (<< 2:3.11)
<mapreri> cjwatson: do you know that http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html says "Valid candidate", do you?
<cjwatson> mapreri: update_excuses is only the first stage; update_output is the second
<cjwatson> mapreri: https://wiki.ubuntu.com/ProposedMigration
<cjwatson> "Valid candidate" is necessary but not sufficient for migration
<mapreri> cjwatson: what a complex migration machinery... is some of a WIP to a more complete infrastructure?
<cjwatson> mapreri: making it more "complete" would not make it less complex :P
<cjwatson> it's a computationally difficult problem
<cjwatson> no plans to significantly change it
<cjwatson> although I would like to set up a clone of the Debian package tracking system at some point to make it easier to see what's going on with any given package
<mapreri> cjwatson: seriously? do we have a so difficult dependency chain to cause a computational issue?
<cjwatson> hell yes
<mapreri> cjwatson: do you mean the new one? that would be nice
<cjwatson> the general problem is NP-complete; the two-stage system makes a *big* difference to its practical feasibility
<cjwatson> even today we have some cases where a run takes on the order of an hour if a big enough transition is in progress
<cjwatson> though usually it's significantly less than that
<cjwatson> I mean the new one yes
<wxl> cjwatson: correct me if i'm wrong, but you aren't the mastermind behind the original amd64+mac release?
<cjwatson> more o rless
<mapreri> and why not integrating the output of the two-stage script in a single page?
<cjwatson> well that's more or less what the PTS does
<cjwatson> I don't have the necessary weeks to go and reorganise the output
<mapreri> indeed
<cjwatson> and reorganising the output would make it harder to plug in the PTS unless carefully coordinated with Debian
<mapreri> ah, now all is explained :) so the usual reason
<wxl> cjwatson: cuz i'm trying to figure out whether or not it's even relevant any more, at least for intel macs. it seems apple pushed out a bunch of firmware releases to bump up the efi version on those early macs and i'm thinking it is unnecessary for them. any recent experience? i'm having trouble finding testers with the hardware.
<cjwatson> no idea
<cjwatson> I'm reluctant to drop it without quite strong proof
<wxl> cjwatson: well as you said, it's still relevant to other machines from that time period, at least as long as the firmware hasn't been upgraded. i'd just been inclined to call it something like amd64-old_efi
<cjwatson> obviously it would be nice not to have to build it, but it would be annoying to drop it and then have to put it back later
<cjwatson> and indeed it turned out not to be just Macs
<cjwatson> (IIRC)
<cjwatson> but it's been a long time
<wxl> i knowâ¦
<wxl> well, i'm going to continue to investigate the situation and try to find targets. i'll let you know if i find anything concrete out. still, i agree we keep it jic.
<wxl> i feel like i do need to find some machines that it's relevant to, though.
<cjwatson> it was 2008/2009 kind of era I believe
<wxl> fyi cjwatson i've been working on trying to figure this all out and here's what i've come up with so far https://wiki.ubuntu.com/Lubuntu/Testing/PPC%26Mac64#amd64.2B-mac
<wxl> stgraber: my tester ran out of time. release away.
<stgraber> wxl: ok
<stgraber> starting publishing of the images now, then will wait a few minutes for them to sync and then push out the announcement
<wxl> stgraber: i await your word
<stgraber> hmm, looks like it's the first time we release a plasma 5 image, the tool needs updating
<wxl> Riddell: â
<Riddell> yes it's the first time
<stgraber> I just made the tool not crash for now and will publish manually, the image name for kubuntu plasma 5 doesn't quite work with what the tool expects...
<stgraber> as in, the image type isn't part of the name. We may want to rename the tracker entry to Kubuntu Plasma 5 Desktop instead, then update publish-image-set to consider "Kubuntu Plasma 5" as a project, that should do the trick
<Riddell> it's always felt inconsistent to me what is a name and what is a type
<stgraber> things are slowly syncing...
<elfy> good good - I see our's
<wxl> np
<elfy> stgraber: you got an issue with us publishing our blog page now? I've been up for 17 hours and want to press the button on it ;)
<stgraber> elfy: if you can wait until the frontends are done syncing (xubuntu is only on 2 out of 5 apparently), then I'll push the main announcement out too
<elfy> okey doke
<stgraber> elfy: go ahead
<wxl> we're a go stgraber ?
<stgraber> wxl: yep
<wxl> thx stgraber
<Riddell> awooga!
 * Riddell publishes http://www.kubuntu.org/news/14.10-beta-1
 * Riddell hugs elfy, stgraber, wxl and wanders off to sleep
<stgraber> good night!
<wxl> bi Riddell :) thanks
<shadeslayer> Riddell: remind me to get you a beer tomorrow
<Riddell> um, not sure what for but ok sure :)
<shadeslayer> for taking over the release :p
<shadeslayer> we should do a release parteh at my awesome terrace
<Riddell> you have a terrace?
<Riddell> you're ill anyway, go back to resting
<elfy> stgraber: thanks - wandering off now
<elfy> cya Riddell :)
<shadeslayer> Riddell: yes
<shadeslayer> a kickass one
<shadeslayer> Riddell: I'm fine now
<shadeslayer> or well
<shadeslayer> for now
<shadeslayer> :p
<shadeslayer> You can drink beer, I'll drink the water :D
#ubuntu-release 2014-08-29
<infinity> cjwatson: Don't do your usual NBS cleaning when you wake up, IBM is relying on that NBS kernel (and the old d-i) for testing until we revert a change in the current kernel.
<ogra_> stgraber, did you do a rtm touch image build ?
<stgraber> ogra_: nope
<ogra_> stgraber, yeah, found the issue ... there was a new device tarball ...
<ogra_> (which makes image planning pretty hard now)
#ubuntu-release 2015-08-24
<veebers> Is there anyone around at this time that can help me with my package stuck in proposed?
<veebers> Currently it's been held back by an autopkgtest failure in another project that is unrelated. (autopilot in proposed, autopilot-gtk has failing tests on wily, due to gcc5 changes, which is the unrelated part)
<Laney> veebers: wouldn't it be a good idea to fix autopilot-gtk's tests?
* Laney changed the topic of #ubuntu-release to: Released: Trusty 14.04.3, Vivid 15.04, Wily Alpha 2 | Archive: feature 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
<veebers> Laney: oh aye, the failures are 'fixed' I'm just in conversation regarding that. Was due to the xpathselect library needing to be rebuilt w/ gcc5
<veebers> Laney: we're not ignoring the failures by any means :-)
<Laney> veebers: There's these ones too http://autopkgtest.ubuntu.com/packages/a/autopilot-gtk/wily/amd64/
<veebers> Laney: that's the ones I'm talking about
<Laney> or is that what you  mean?
<Laney> ok
<veebers> Laney: I'm not sure why those autopkgtests are failing, but on my wily machine I attempt to build at it fails like that, I rebuild and install xpathselect and the ap-gtk build succeeds
<Laney> Huh
<Laney> I just looked into that autopilot-gtk failure a bit. Can't confirm that rebuilding xpathselect changes anything, but rebuilding *autopilot-gtk* itself does.
<Laney> Ah
<Laney> I bet that the xpathselect in wily-proposed is an ABI break
 * Laney thanks autopkgtest
<Laney> sil2100: ^^^ FYI that xpathselect upload was suspicious (just checked who published the silo)
<Laney> Trevinho: ^ fyi too
<Trevinho> Laney: looking at the AP failures, I was seeing the very same failures with previous versions as well, did I miss something?
<Laney> Trevinho: The index out of range thing is new with the rebuilt xpathselect
<Laney> compare https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/amd64/a/autopilot-gtk/20150819_132411@/log.gz and https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/amd64/a/autopilot-gtk/20150820_151042@/log.gz
<Trevinho> Laney: so... want me to change soname or xpathselect or what else? And rebuild AP probably..
<Laney> we need to rename xpathselect to add a "v5" to the end of the package name
<Laney> I can do this, already did a bunch of them already
<Laney> then things which depend on it need rebuilding too
<Trevinho> Laney: oh, if want, go for it... What should I do with my silo then?
<Laney> what else is in it?
<seb128> unity that already migrated
<Laney> good job this isn't used for anything critical path ;-)
<Laney> Trevinho: will use the same silo I guess
<Trevinho> Laney: ok, make it yours
<Laney> just stack up on yours
<Laney> I would guess that the ap-gtk failure is going to go back to https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/amd64/a/autopilot-gtk/20150819_132411@/log.gz
<Trevinho> unity has not a strict dependency on that... and so most of stuff I guess... We dload it it and probably other libs do that
<Laney> which one?
<Trevinho> mh, I didn't check, but probably gtk module for AP introspection does the same
<Laney> ya, that should be fine
<Laney> Trevinho: Just wasted/used some time trying to fix that other AP failure, so will do the renaming and stuff after lunch
<Laney> hopefully should also unflakify this test
<Trevinho> ok
<Laney> seems you can't do Eventually(raises(stuff))
<Laney> I probably knew that once
<Laney> and now I know it again!
<Laney> biab
<coreycb> hi release team, we have 2 openstack Liberty uploads for the beta 2 release that we need to upload to wily.  can we get approval to upload them?  FFE bug 1488094
<ubot93> bug 1488094 in neutron-vpnaas (Ubuntu) "[FFE] glance, neutron-vpnaas liberty-2 release" [Undecided,New] https://launchpad.net/bugs/1488094
<flexiondotorg> Laney, infinity I need some quick advice.
<flexiondotorg> The MATE 1.10 migration in Debian unstable didn't get completed prior to the feature freeze.
<flexiondotorg> Due in part to me being on jury service for 3 weeks and my Debian sponsors being on summer vacation and attending DebConf.
<flexiondotorg> Consequently MATE in the 15.10 is a mix on 1.8 and 1.10. Therefore afflicted by segfaults and regressions.
<flexiondotorg> Do I need to file for an FFe for each package I want to sync from Debian unstable?
<flexiondotorg> My Debian sponsors are back from vacation and have been uploading MATE to unstable for the last 2 days. It is (almost) complete there now.
 * ogra_ bets you can get along with a simgle bu for all MATE related FFe packages
<ogra_> *bug
<flexiondotorg> ogra_, So create a bug listing all unsynced MATE packages then reference that in each sync request?
<ogra_> thats what we did in the past for i.e. phone images when needing approval for an FFe
<flexiondotorg> ogra_, My question is does I need FFe because technically the sync will be fixing bugs?
<ogra_> it brings in new upstream versions ...
<ogra_> which makes it fall under FF
<Laney> No
<ogra_> no ?
<Laney> Numbers don't matter
<ogra_> thats new then
<Laney> the changes do
 * ogra_ still thinks just a blanket FFe for all MATE packages should be fine 
<ogra_> after all it is you who knows best if syncing them is helpful anyway
<didrocks> as Laney said, it just depends what the new release bring. If it's bug-fix only, then no need for FFe
<didrocks> if it's new features, that's the F of FFe ;)
<ogra_> well ... if you have 3 packages out of 10 that need FFes it is still less paperwork to have a blanket one  for all of MATE ;)+
<didrocks> or just open a bug with those 3 packages, and explain what new features it will bring in (and thus, the risks)
<ogra_> (and after all we are talking about universe here ... where the rules used to be less strict anyway ... not sure thats still the case)
<didrocks> less strict == getting the FFe accepted easily, yeah
<didrocks> but not as "no need for FFe"
<ogra_> indeed
<Laney> unseeded maybe, but these are on a flavour
<Laney> The request coming from a flavour developer gives it more weight though.
<ogra_> would the conversation not be anyway: flexiondotorg files an FFe bug, you ask him to judge the feature impact since he is most familiar with the code and he tells you to approve/deny  ?
<ogra_> sonds a bit like total waste of time and unneded buerocracy if it works like that in the end
<apw> best to get a minion to file it ;)
<ogra_> well, it if is only for the sake of paperwork i'd even say if a flavour lead asks for it, dont require and FFe
<ogra_> and use the miniont time for better stuff ;)
<ogra_> *minion
<flexiondotorg> OK, so in which case. Some MATE packages in the 15.10 archive are v1.8 and syncing would bump them to 1.10 and they would bring new features in most cases.
 * ogra_ just thinks it is pointless to require paperwork if the final decider is also the requesting person in the end ... and i guess most of the time thats the case for flavours
<flexiondotorg> So, is the consensus for me to file an FFe for all MATE packages I'd like syncing, then reference that in the sync requests?
<flexiondotorg> All the packages are MATE specific and will only impact (positively) Ubuntu MATE.
<Laney> I don't really know why ogra is getting himself worked up
<ogra_> yeah, by the current rules
<ogra_> Laney, i'm not worked up at all
<Laney> flexiondotorg: I think just do it this one time
<Laney> call that an ack from me :)
<ogra_> just analyzing
<didrocks> Laney: yeah, seems like the current discussion is taking more time than following the process itself :)
<flexiondotorg> Laney, So just start creating sync requests and say you've approved them?
<Laney> sure, just paste this in or whatever
<ogra_> i'm just wonderign if the process is still helpful at all
<Laney> After you get it all in line then follow feature freeze
<ogra_> or if we shouldnt loosen it a little
<macjack> infinity: Hello infinity, I found "README.diskdefines" in each single 14.04.3 ISO file, it will show "Beta"
<flexiondotorg> Laney, OK, thanks.
<macjack> infinity: is it typo? Thanks
<Laney> ogra_: Getting yourself in the middle of a discussion about a specific request isn't going to bring about the change you want though
<Laney> go start a thread on list or something
<infinity> macjack: Yeah, the string didn't get changed before release.  Congrats on being the first person other than me that noticed. :P
<macjack> infinity: I am the lucky guy :) lol
<macjack> infinity: anyway, thanks for replying, just to be sure it is formal release :)
<infinity> macjack: It is, yes.  Just an embarrassing error that fixing post-release isn't worth doing.  Perhaps a note in the release notes wouldn't be a bad idea.
<flexiondotorg> infinity, Can you do me a favour please? deja-dup-caja has been in the Wily NEW queue for weeks, could you assist it's promotion please?
<flexiondotorg> infinity, It is a plugin for Caja (the MATE filemanager) that provides integration with Deja Dup backup.
<flexiondotorg> infinity, I requested the plugin and help with it's development. It's inclusion will only affect/benefit Ubuntu MATE.
<coreycb> hello, looking for an archive admin's opinion.   we have packages prepped for switching from python-mysqldb to python-pymysql, which is a drop in replacement for python-mysqldb.  do we need an FFE to update d/control for these package updates?
<coreycb> for context, MIR bug 1477668
<ubot93> bug 1477668 in python-pymysql (Ubuntu) "[MIR] python-pymysql" [High,Incomplete] https://launchpad.net/bugs/1477668
<michi> sil2100: Thanks for your help with the train builds!
#ubuntu-release 2015-08-25
<flexiondotorg> Mirv, thank you for all the sponsoring. I really appreciate it.
<flexiondotorg> Mirv, I've just file a sync request for Marco (the MATE window manager) which I think will help mate-settings-daemon make it's way out of wily proposed.
<Mirv> flexiondotorg: you're welcome!
<Mirv> ok.
<flexiondotorg> Mirv, thanks. You've saved Ubuntu MATE 15.10 beta 1.
<Mirv> :)
<flexiondotorg> There are still some packages stuck in NEW on the Debian side but with everything you've sponsored I'll have a working system for the most part :-)
<Mirv> sounds good
<flexiondotorg> Mirv, do you have the time to sponsor another sync? https://bugs.launchpad.net/ubuntu/+source/mate-tweak/+bug/1488407
<ubot93> Launchpad bug 1488407 in mate-tweak (Ubuntu) "Sync mate-tweak 3.5.1-1 (universe) from Debian unstable (main)" [Undecided,New]
<Laney> flexiondotorg: do you know who's in on this beta?
<Laney> I only know about you and xubuntu
<flexiondotorg> Mirv, and if you are able can you also take a look at deja-dup-caja which has been in the Wily new queue for some weeks.
<flexiondotorg> Laney, I'll ask around. I know Xubuntu are defo in Beta.
<Laney> ty
<flexiondotorg> Lane Ubuntu GNOME are in.
<flexiondotorg> Laney, ^^^^
<Mirv> flexiondotorg: I can sync, but only release team can check the NEW queue
<flexiondotorg> Mirv, OK. Do you know who I can ask?
<Mirv> flexiondotorg: https://launchpad.net/~ubuntu-release/+members
<flexiondotorg> Thanks.
<Laney> Mirv: no, you mean ~ubuntu-archive
<Mirv> oh, right...
<Mirv> flexiondotorg: what laney said :)
<Mirv> so this one https://launchpad.net/~ubuntu-archive/+members
<flexiondotorg> Thanks.
<flexiondotorg> Laney, I assume Ubuntu Cloud are participating?
<flexiondotorg> Laney, I'm waitig for confirmations from Lubuntu and Kubuntu.
<flexiondotorg> Laney, Ubuntu Kylin are in.
<Laney> flexiondotorg: Probably. They go it alone mostly anyway though.
<flexiondotorg> Laney, That was a reference to Cloud?
<Laney> Ya
<Laney> They have a different way of publishing
<flexiondotorg> Laney, Kubuntu are in.
<flexiondotorg> Laney, This is what I know - https://wiki.ubuntu.com/WilyWerewolf/Beta1
<Laney> flexiondotorg: I guess it's probably going to be the same as A2
<Laney> Just need to hear from Lubuntu if so
<Laney> http://iso.qa.ubuntu.com/qatracker/series/52/manifest
<flexiondotorg> Laney, I'm really trying with Lubuntu. I've run out of people to poke.
<Laney> No worries, can assume they are in and change later if necessary
<flexiondotorg> OK
<flexiondotorg> didrocks, Can you take a look at deja-dup-caja in the Wily NEW queue please?
<didrocks> flexiondotorg: not right now, but I can add that to my list of TODOs
<flexiondotorg> It has been there for a few weeks. It is a new feature for Caja (the MATE file manger) that adds integration for Deja Dup backup.
<flexiondotorg> didrocks, Thanks.
<flexiondotorg> didrocks, It will only affect/benefit Ubuntu MATE.
<didrocks> flexiondotorg: sounds good, I think you talked about it in LUP
<flexiondotorg> didrocks, Probably :-)
<flexiondotorg> And UOS 15.05.
<flexiondotorg> didrocks, Thank you.
<didrocks> flexiondotorg: I wans't the NEWing the source. I'm looking at the binary though
<didrocks> flexiondotorg: I was wondering about having only python 2.7 support, is it what caja is supporting?
<flexiondotorg> didrocks, Currently yes.
<didrocks> flexiondotorg: ok, NEWed then
<flexiondotorg> Who should I thank :-)
<flexiondotorg> I'm going to try and port all python2 to Python3 in MATE 1.12
<didrocks> not sure for source NEW, we don't have logs for that part unfortunately :/
<didrocks> that would be nice !
<flexiondotorg> I've already ported most of my own stuff for 15.10.
<flexiondotorg> Hopefully someone will see my thanks for processing deja-dup-caja. Thank you.
<didrocks> heh ;)
<slickymasterWork> flexiondotorg, is there any prevision for when the url for B1 will land at http://iso.qa.ubuntu.com/ ?
<slickymasterWork> for both 64 and 32 bit
<flexiondotorg> Laney, ^^^^^^^^^^^^^^^^^^^^6
<slickymasterWork> tks flexiondotorg
<flexiondotorg> Please see slickymasterWork question.
<Laney> I didn't start on it yet
<Laney> soon
<slickymasterWork> ok Laney, thanks for the heads up
<Laney> slickymasterWork: Setting it up now
<Laney> I guess I'll kick them off in 10 minutes, then a little bit after that they will come
<slickymasterWork> great
<slickymasterWork> thanks
<Laney> flexiondotorg: Just committed the beta 1 freeze, let someone on the RT know if stuff should go through it
<flexiondotorg> Laney, could you update ubuntu-mate-meta please? I've just pushed some seed changes as a result of the syncs Mirv kindly complete for me earlier.
<Laney> Momento
<flexiondotorg> Laney, I acknowledge your beta 1 freeze comment.
<flexiondotorg> And I am sorry I've just requested a package update.
* Laney changed the topic of #ubuntu-release to: Released: Trusty 14.04.3, Vivid 15.04, Wily Alpha 2 | Archive: beta 1 freeze, feature 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
<flexiondotorg> Laney, who is conducting your role on Thursday?
<Laney> flexiondotorg: Didn't hear back yet
<flexiondotorg> OK.
<Laney> Soon I start asking people in ~ubuntu-cdimage directly
<Laney> :)
<flexiondotorg> Can you tell me what is hold mate-settings-daemon in wily/proposed?
<flexiondotorg> I need to know if this is just a build dep delay, which should now e unblocked of if I need to fix something.
<Laney>  ubuntu-mate-core : Depends: mate-settings-daemon-pulse but it is not installable
<Laney> Fixed with new meta?
<flexiondotorg> Yes.
<flexiondotorg> Laney, ^^^
<Laney> ok, let me build this
<flexiondotorg> Thank you.
<flexiondotorg> Sorry for delaying.
<Laney> I started rebuilds of all flavours apart from MATE
<flexiondotorg> OK
<Laney> If you want things past the freeze, please give me a list like this: unblock pkga/versiona pkgb/versionb ...
<Laney> (everything on your iso will be frozen)
<flexiondotorg> Understood.
<Laney> So you'll want at least settings-daemon and meta
<flexiondotorg> Please.
<Laney> Give me the line please
<Laney> Otherwise I have to go look up the versions myself ;)
<flexiondotorg> OK, but I can't upload/update the ubuntu-mate-meta
<flexiondotorg> Laney, unblock mate-settings-daemon/1.10.1-1
<Laney> I'm doing the meta now
<Laney> it'll be current version + 1
<flexiondotorg> Laney, unblock ubuntu-mate-meta/1.130
<flexiondotorg> Laney, confirmation from Lubuntu that they are participating.
<Laney> cool
<Laney> uploaded, unblocked
<flexiondotorg> Lubuntu say to always include them in all pre-releases.
<flexiondotorg> Laney, Many thanks.
<Laney> http://iso.qa.ubuntu.com/qatracker/milestones/345/builds <- starting to appear
<Laney> self service respins after this
<coreycb> infinity, do you know if openstack core packages have any sort of standing exception for uploads after feature freeze?
<flexiondotorg> Laney, Are the Ubuntu MATE builds queued?
<Laney> flexiondotorg: no, you want to wait for your new packages to get in
<Laney> flexiondotorg: once rmadison shows you they are there, feel free to trigger it
<flexiondotorg> Laney, OK. I'll keep an eye on rmadison.
<flexiondotorg> Can I trigger then build or do you need to kick of the first one?
<Laney> You can
<Laney> Just go to the daily milestone and do it from there
<flexiondotorg> OK
<flexiondotorg> Mirv, can you do me another favour please? https://bugs.launchpad.net/ubuntu/+source/mate-media/+bug/1488485
<ubot93> Launchpad bug 1488485 in mate-media (Ubuntu) "Sync mate-media 1.10.0-1 (universe) from Debian unstable (main)" [Undecided,New]
<flexiondotorg> That recently landed in Debian and is required for Ubuntu MATE 15.10 beta 1.
<flexiondotorg> Laney, unblock mate-media/1.10.0-1
<Laney> k
<flexiondotorg> Laney, the unblock is subject to the following sync happening https://bugs.launchpad.net/ubuntu/+source/mate-media/+bug/1488485
<ubot93> Launchpad bug 1488485 in mate-media (Ubuntu) "Sync mate-media 1.10.0-1 (universe) from Debian unstable (main)" [Undecided,New]
<Laney> Doesn't matter, if the version doesn't match it'll be ignored
<flexiondotorg> OK
<Mirv> flexiondotorg: done
<flexiondotorg> Mirv, thank you so much.
<flexiondotorg> Laney, can you advise on the status of mate-media? I see it is in wily-proposed but don't know if it will be automatically promoted.
<Laney> flexiondotorg: If it's missing builds but it is built then probably waiting for the next run
<cjwatson> It was probably only missing builds due to being in NEW, which I handled ~40 minutes ago
<flexiondotorg> Laney, cjwatson rmadison show no record of mate-media 1.10.0-1 in wily-proposed now. I'm confused.
<cjwatson> It'll get there
<cjwatson> Oh, it's because it was removed from wily-proposed and migrated to wily, the first must have happened before a publisher run started and the second after, or similar
<cjwatson> Give it a bit more, it'll show up in wily
<flexiondotorg> cjwatson, Thanks.
<ari-tczew> Laney: even no-change syncs are forbidden to upload now?
<Shinikake> o7
<ScottK> p*
 * infinity nods sagely.
#ubuntu-release 2015-08-26
<darkxst> infinity, the i386 is stuck  for some reason
<darkxst> (ubuntu GNOME build)
<infinity> darkxst: It's being sorted.
<darkxst> infinity, k, thanks
<infinity> darkxst: There's just two fresh builds going, so the amd64 one from two hours ago will invalidate.  Didn't notice that one, sorry.
<darkxst> doesnt matter, not like anyone started testing it
<infinity> darkxst: Right, these builds will actually show on the milestone now, I fixed that.  So, should be good to go in ~30m or whatever.
<darkxst> hopefully its not to broken!
<darkxst> infinity, can you increase the size limits on images, to get rid of the oversized messages? we have a nominal 1.5GB limit now
<darkxst> atleast that is what our teams decided, clearly the servers don't know this yet!
<flexiondotorg> infinity, Awake or sleeping?
<flexiondotorg> didrocks, Can you do me a favour? Please can you update the ubuntu-mate-meta package?
<didrocks> flexiondotorg: sure, doing that
<didrocks> flexiondotorg: you pushed your changes to your seed?
<flexiondotorg> I've got a couple of packages missing.
<flexiondotorg> I have pushed seed changes.
<flexiondotorg> didrocks, Thanks.
<didrocks> flexiondotorg: yw, running the update :)
<flexiondotorg> 3 new packages should turn up.
<flexiondotorg> Cheers.
<didrocks> I'll send you the diff
<doko> Riddell, looks like a lot of my fixes for kde stuff were overridden again, and gcc-5 hangs again for kde issues :-/
<flexiondotorg> Laney, unblock ubuntu-mate-meta/1.131
<Laney> ok
<didrocks> flexiondotorg: looking good to you? http://paste.ubuntu.com/12197794/ (got 4 new packages, not 3)
 * flexiondotorg checks...
<flexiondotorg> didrocks, Yes, that's exactly what I expected to see. Thank you.
<didrocks> flexiondotorg: yw! uploading
<didrocks> (done)
<flexiondotorg> didrocks, Cheers. I've spent weeks negotiating with Debian Legal about the MATE documentation. More weeks adding it all in. Then forget to include the damn package in the seeds ;-)
<didrocks> ahah ;)
<sil2100> Hello release team! I would need to disable the importer for a short while
<flexiondotorg> Laney, ^^^^^^^
<Laney> yes?
<flexiondotorg> Does the request from sil2100 mean anything to you?
<sil2100> I'll reenable it in a moment, just the image copies take ages
<sil2100> Delta creation is slow
<sil2100> Laney: I can actually leave the importer running if you want, just my copy-image calls might block if from time to time
<Laney> I don't think it affects me, do what you want :)
<sil2100> Ok, thanks :) In case you guys need to re-spin some flavor images, I can enable the importer then if needed
<sil2100> Since I usually disable it as otherwise it can block my copy-image from happening if it starts running
<infinity> sil2100: The importer has no relation to flavour images (or anything other than system-image).
<sil2100> Ah, right, ubuntu-core/ubuntu-personal are not affected by this, nvm then ;)
<sil2100> infinity: btw. did you get my pokes with questions about britney?
<infinity> sil2100: I did, I need to respond soon.  Sorry, was out all last week.
<sil2100> infinity: no worries, just hope you got some sleep yesterday at least
<infinity> sil2100: Sort of. :/
<ogra_> flexiondotorg, importer means phones, snappy and the ubuntu-pocket-desktop that use system-image ... we developed  habit of announcing here when we disable it so in case i forget to switch it on again someone can poke me about it ... there is no other easy way to let others that depend on it know why or who disabled it
<flexiondotorg> ogra_, Thanks for explaining :-)
<infinity> ogra_: One could, I dunno, leave their name in a comment when they comment it out. ;)
<ogra_> details :P
<ogra_> infinity, if sil2100 announces it in advance i can intercept if i'm just waiting for an important snappy import ;)
<ogra_> (not that i would though ...)
<ogra_> (waiting i mean)
<infinity> (At this point, I think you're just talking to yourself)
<ogra_> haha
<sil2100> ;)
<infinity> I need to pick a new timezone for the week, mine's not working out.
<infinity> Anyone have anything good to say about theirs?
<ogra_> it is sunny and warm in mine
<infinity> Beats smokey and warm in mine.
<infinity> s/warm/hot/
<infinity> It seems every tree in a 200km radius is committing suicide, with no regard whatsoever to my need to breathe.
<infinity> s/to my/for my/ ... I need coffee.  Or sleep.  *flips coin*
<Shinikake> EST is pretty nice this time of day.
 * Shinikake sips a Brazilian blend.
<ogra_> infinity, decaf *and* sleep ?
<infinity> ogra_: I don't understand that first word.
<ogra_> lol
<infinity> ogra_: Silly German.
<infinity> I guess it'll be a coffee and glibc rebase sort of morning.
<infinity> No one wants me actually awake when I do that.
<infinity> ogra_: Are you still of the opinion that no one in the phone world cares about wily (other than if we completely break it, of course)?
<ogra_> infinity, i am ... but then i'm a snappy dude now :)
<infinity> ogra_: ie, should I give them N days to play with glibc 2.22 and report back to me, or just trust the desktop/server/autopkgtest QA is good enough?
<ogra_> wily wont end up on any phones ... and gcc5 breaks all store apps
<infinity> Righto.  Then I'm inclined to not give them control over my QA. :P
<ogra_> but people landing stuff in wily like to at least test on a semi working image ...
<ogra_> so breaking it completelly might cause an outcry
<ogra_> -l
<infinity> ogra_: I have no intention of *breaking* glibc, I just don't want a repeat of when I landed 2.21 with, literally, one bug anyone cared about, and it spawned more meetings and specs than UDS.
<ogra_> yeah, no worries ... phones are and stay vivid based
<Riddell> <cyphermox> Riddell: looks like it's much more than modemmanager: all of dbus looks messed up
<Riddell> no upgrades I guess for beta 1 ^^
<ogra_> Riddell, didnt it always ?
<Riddell> ogra_: always mess up?
<ogra_> dbus looking mssed up :)
<ogra_> +e
<flexiondotorg> Mirv any chance you can help me out?
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-settings/+bug/1488930
<ubot93> Launchpad bug 1488930 in ubuntu-mate-settings (Ubuntu) "ubuntu-mate-settings 15.10.1 bugfix release [debdiff attached]" [Undecided,New]
<flexiondotorg> Laney, unblock ubuntu-mate-settings/15.10.1
<Laney> flexiondotorg: anyone on the team can do these, you don't need to ask me directly
<Laney> but done
<flexiondotorg> Laney, any chance you could sponsor a couple of uploads for me?
<Laney> infinity: slangasek: stgraber: anyone: Any of you able to do the B1 publishing tomorrow in my stead?
<Laney> I'll be at BF & probably not available
<Laney> (but if I am then I'll let you know)
<flexiondotorg> Laney, I am going to be unavailable from 13:30 till 15:00 tomorrow. Hopefully that won't impact my chasing.
<flexiondotorg> Riddell, any chance you could sponsor a couple of packages for me please?
<Riddell> flexiondotorg: in a bit, I'm in a meeting now
<flexiondotorg> Riddell, Thanks. When you're free please take a look at:
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-settings/+bug/1488930
<ubot93> Launchpad bug 1488930 in ubuntu-mate-settings (Ubuntu) "ubuntu-mate-settings 15.10.1 bugfix release [debdiff attached]" [Undecided,New]
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-welcome/+bug/1488968
<ubot93> Launchpad bug 1488968 in ubuntu-mate-welcome (Ubuntu) "ubuntu-mate-welcome 1.0.3 new bugfix release [debdiff attached]" [Undecided,New]
<stokachu> infinity:just confirming you saw the openstack package upload?
<coreycb> hello, can an archive admin please promote python-pymysql to main? this will help get some of our openstack packages out of dependency waits.
<cjwatson> coreycb: I'll take care of it, and a few others I see in the queue
<coreycb> cjwatson, thanks
<cjwatson> coreycb: all done
<coreycb> cjwatson, thanks, appreciate it
<infinity> Laney: If all the paperwork is covered and I have to do nothing but pull the trigger, I'm down.  I don't have the time to crack any whips.
<sil2100> Dear release team! The importer is now re-enabled and the daily-builds of rc-proposed (vivid touch) as well
<sil2100> (just a heads up)
<flexiondotorg> infinity, Please can you unblock ubuntu-mate-welcome/1.0.3
<flexiondotorg> unblock ubuntu-mate-welcome/1.0.3
<flexiondotorg> unblock mate-netbook/1.10.0-1
<flexiondotorg> unblock eom/1.10.3-1
<coreycb> hi, can an archive admin please promote python-taskflow and python-oslo.db to main?  that'll fix some of our openstack dependency waits.  also we have an FFE ( bug 1489096 ) for python-troveclient that is also needed to fix some openstack packages that are ftbfs.
<ubot93> bug 1489096 in python-troveclient (Ubuntu) "[FFE] Please sync python-troveclient (1.2.0-3) from Debian (experimental)" [Undecided,New] https://launchpad.net/bugs/1489096
<infinity> flexiondotorg: Done * 3.
<flexiondotorg> infinity, Thanks very much :-)
<cyphermox> flexiondotorg: some of that wasn't built yet ;)
<flexiondotorg> cyphermox, I learned yesterday that that doesn't matter :-)
<infinity> coreycb: We can never sync that package from Debian unless Debian bumps the epoch in the version (which you could ask them nicely to do).
<coreycb> infinity, I was wondering.. ok
<cyphermox> flexiondotorg: well, it's just that sometimes things don't build :)
<infinity> coreycb: Versions can't go back in time. :P
<coreycb> infinity, yeah, I'll cancel it and update our package
<infinity> coreycb: However, if you find that a merge ends up identical in every way except the version number, please do ask the Debian maintainer to add the epoch to paper over our oops.  If you ask nicely, I'm sure he won't mind.
<coreycb> infinity, maybe that's an option.  I'll check with zigo.  thanks.
<infinity> coreycb: Bleh.  There's exactly zero mention in the changelog as to WHY we even added the epoch.  Oh well.
<infinity> coreycb: Our packaging seems quite different, but it would be nice for that to not be true.
<coreycb> infinity, I've compared our package with debian's and it's ok to sync, assuming the version issue is settled
<coreycb> infinity, yeah I think it was just a mistake
<cjwatson> Initial release with an epoch *blink*
<cjwatson> Probably should have been caught in NEW review.
<infinity> cjwatson: It may have been a case of "our users have this installed already due to $random_ppa, and we want to support upgrades", but I don't think I'm the one who reviewed it.
<infinity> (And if it was me, I don't remember. :P)
<flexiondotorg> infinity, I see ubuntu-mate-settings failed to build while trying to parse the time?
<flexiondotorg> infinity, Can you shed any light on this for me?
<infinity> flexiondotorg: Huh.  Can't say I've ever seen that failure mode before. :P
<flexiondotorg> infinity, dpkg-genchanges -S -sa works fine here.
<infinity> flexiondotorg: I've retried it to see if it was some weird cosmic ray thing.
<flexiondotorg> infinity, Thanks.
<flexiondotorg> infinity, Just out of interest, what "time" is it parsing?
<infinity> flexiondotorg: Dunno, you'd have to follow the code.
 * flexiondotorg is suddenly very tired and thinks it might be time for bed ;-)
<infinity> flexiondotorg: Huh, no, it really does hate you.
 * infinity grabs the source.
 * flexiondotorg is curious.
<flexiondotorg> cyphermox, Sponsored that upload and encountered the same issue initially. But used a different machine to do the build in the end.
<infinity> Err, that's not a good sign. :P
<infinity> And, indeed, same thing here.
<cyphermox> it's the changelog timestamp from the previous upload
<flexiondotorg> OK.
<infinity> dpkg-genchanges has no business parsing old entries..
<infinity> Though, I don't see anything wrong with that one either.
<cyphermox> *shrugs*  if I kept just the latest it was happy
<flexiondotorg> debuild -S works on the machine I have access to.
<flexiondotorg> The previous change log time stamp have July rather Jul and June rather than Jun.
<infinity> flexiondotorg: Yuo're not using the latest dpkg, I assume.
<flexiondotorg> Could that be the issue.
<flexiondotorg> infinity, I'm on 15.04.
<infinity> Oh, could be, yes.
<flexiondotorg> This machine at least.
 * infinity hacks a bit.
<flexiondotorg> infinity, Thanks.
<infinity> Okay, it's fixed in git.  Lemme rev dpkg and retry your build.
<flexiondotorg> infinity, Many thanks.
<infinity> flexiondotorg: You'll probably want to go and correct history sometime, but the new dpkg will actually tell you which lines are broken, making that easier.
<infinity> flexiondotorg: Like so: http://paste.ubuntu.com/12202661/
<flexiondotorg> infinity, Thanks.
 * flexiondotorg is a bit puzzled why lintian is not spitting out errors when dpkg is clearly upset.
<infinity> Oh, embarrassing, it trips on some of my lines in the dpkg changelog. :P
<infinity> flexiondotorg: dpkg very recently switched to a newer/stricted timedate parsing module to drop a dependency (the new one is from perl itself, not a module).
<infinity> flexiondotorg: Like many such things that Just Worked for ten years, changing it has been entertaining.
<flexiondotorg> :-D
<flexiondotorg> infinity, Any chance you could sponsor a sync for me?
<flexiondotorg> https://bugs.launchpad.net/bugs/1489185
<ubot93> Launchpad bug 1489185 in mate-tweak (Ubuntu) "Sync mate-tweak 3.5.2-1 (universe) from Debian unstable (main)" [Undecided,New]
<infinity> Hrm.  Not convinced the new implementation is quite sane yet either.
<flexiondotorg> I have a howling bug in mate-tweak 3.5.1
<flexiondotorg> So I had 3.5.2 uploaded to Debian unstable earlier.
<flexiondotorg> infinity, I realise you're busy but if you can find the time to sponsor the following syncs I'd be most grateful.
<flexiondotorg> infinity, Both fix signifcant issues I'd really prefer to not be in 15.10 Beta 1 tomorrow.
<flexiondotorg> mate-tweak      https://bugs.launchpad.net/bugs/1489185
<flexiondotorg> caja-extensions https://bugs.launchpad.net/bugs/1489186
<ubot93> Launchpad bug 1489185 in mate-tweak (Ubuntu) "Sync mate-tweak 3.5.2-1 (universe) from Debian unstable (main)" [Undecided,New]
<ubot93> Launchpad bug 1489186 in caja-extensions (Ubuntu) "Sync caja-extensions 1.10.0-1 (universe) from Debian unstable (main)" [Undecided,New]
<infinity> flexiondotorg: Hold on, I'm still fixing dpkg.  The rabbit hole went deeper. :P
<flexiondotorg> infinity, Oh. Sorry to hear that.
<sil2100> flexiondotorg: I could sponsor those, but it's already a bit late here, not sure if I wouldn't fall asleep before doing that
<flexiondotorg> sil2100, If you're able to stave off sleep I'd really appreciate.
<flexiondotorg> sil2100, I'd like to respin the isos first thing so I can run through the tests.
<flexiondotorg> sil2100, Where are you?
<sil2100> flexiondotorg: let me see what I can do here, maybe I can pick it up before infinity has time - since those are universe packages
<sil2100> Poland, EU
<flexiondotorg> sil2100, England.
<flexiondotorg> So, yes. Past your bed time ;-)
<sil2100> flexiondotorg: did you check if the mate-tweak builds correctly on wily? Do you have any build-logs handy?
<flexiondotorg> sil2100, One sec...
 * sil2100 wonders if this requires a FFe
<flexiondotorg> https://launchpadlibrarian.net/215553291/buildlog_ubuntu-wily-amd64.mate-tweak_3.5.2-1~wily1.1_BUILDING.txt.gz
<sil2100> In theory new upstream versions should, but on the other hand it has only bugfixes it seems?
<flexiondotorg> sil2100, The is no new features.
<flexiondotorg> It is just fixes.
<sil2100> flexiondotorg: thanks for the log, looks good
<flexiondotorg> sil2100, You're welcome.
<sil2100> Will just double-check something and I'll sponsor it, one moment
<sil2100> Ok, sync request submitted, it's in wily-proposed
<sil2100> Now let me take a look at caja-extensions and what's up with that one...
<flexiondotorg> sil2100, https://launchpadlibrarian.net/213463416/buildlog_ubuntu-wily-amd64.caja-extensions_1.10.0-1~wily1_BUILDING.txt.gz
<sil2100> flexiondotorg: do you have a build-log for caja-extensions maybe? And maybe a list of changes introduced in this release? Since the changelog only mentions 'new upstream release' basically
<flexiondotorg> sil2100, The issue here is that Caja (the MATE file manager) is already at version 1.10
<flexiondotorg> sil2100, See up a couple of comment for build log.
<sil2100> Thanks :)
<flexiondotorg> sil2100, caja-extensions in the 15.10 are 1.8. So there are some significant regressions.
<flexiondotorg> sil2100, See my comment in the sync request where I dicussed this (and other MATE 1.10 sync) with several devs.
<sil2100> hm, indeed, and you mentioned that didrocks and Laney agreed on this sync, yes?
<flexiondotorg> sil2100, Ultimately, Laney ack'd it.
<flexiondotorg> sil2100, Yes, it was discussed with those in my comment.
<flexiondotorg> sil2100, Here is a transcript - http://paste.ubuntu.com/12201355/
<sil2100> flexiondotorg: yeah, I see the discussion, it seems to be fine - caja-extensions anyway is only seeded in ubuntu-mate
<flexiondotorg> sil2100, Yep.
<sil2100> Let me just do a final check and do iiit
<flexiondotorg> Sure. Thanks for help me out.
<flexiondotorg> unblock mate-tweak/3.5.2-1
<sil2100> flexiondotorg: what worries me a bit with caja-extensions is that it failed to build for armhf in the PPA
<flexiondotorg> sil2100, All the armhf stuff has failed in my PPAs for months.
<flexiondotorg> But always builds "for real".
<flexiondotorg> I think something is not setup quite right in my PPAs.
<flexiondotorg> https://launchpad.net/~ubuntu-mate-dev/+archive/ubuntu/crazy-mate/+packages
<sil2100> Indeed I see there's something strange going on, ok, let's sync it - if it fails building in -proposed then we'll know
<flexiondotorg> You can see there all the armhf fails in the PPA. But those that have made it to the archive all built correctly.
<sil2100> But then we wouldn't be able to sync it anyway, not without patching, so +1 from me
<sil2100> Yeah, just checked a few of those
<sil2100> flexiondotorg: ok, both packages now in -proposed, there's not much more I can do now
<sil2100> :)
<flexiondotorg> sil2100, Many thanks!
<sil2100> yw!
<flexiondotorg> unblock caja-extensions/1.10.0-1
<infinity> flexiondotorg: Alright, once the dpkg testsuite passes here, I'll upload this hideous hack.
 * infinity feels icky.
<flexiondotorg> infinity, Go you :-)
#ubuntu-release 2015-08-27
<infinity> flexiondotorg: I'm going somewhere because of this, that's for sure.
<infinity> I think we might need to rethink date validation in changelogs. :P
<flexiondotorg> infinity, Would it be a warm destination? ;-)
<infinity> flexiondotorg: Quite.
<flexiondotorg> lol
<flexiondotorg> unblock mate-tweak/3.5.2-1
<flexiondotorg> unblock caja-extensions/1.10.0-1
<infinity> flexiondotorg: Are you expecting people to actually pick up those unblocks as you announce them?
<flexiondotorg> infinity, Well I was directing them at Laney but he said that wasn't necessary
<flexiondotorg> infinity, unblock mate-tweak/3.5.2-1
<flexiondotorg> infinity, unblock caja-extensions/1.10.0-1
<infinity> flexiondotorg: Got those two.  Were there others?
<flexiondotorg> infinity, I'll check excuses...
<infinity> Nah, looks like I have the lot now.
 * infinity bumps the caja-extensions/arm64 build so it builds this month.
<sil2100> I go to sleep now, good luck guys o/
<flexiondotorg> sil2100, Cheers.
<flexiondotorg> infinity, That is the unblocks sorted thanks.
<flexiondotorg> Yeah, arm64 is holding up the rest right now.
<flexiondotorg> infinity, Can you help caja-extensions out on the Wily NEW queue please?
<infinity> flexiondotorg: Already done.
<flexiondotorg> infinity, You star!
<infinity> queuebot is just slow.
<infinity> queuebot: Wake up.
<flexiondotorg> infinity, Thanks a lot for your help today.
<infinity>  dpkg-genchanges -b -mLaunchpad Build Daemon <buildd@lgw01-39.buildd> >../ubuntu-mate-settings_15.10.1_amd64.changes
<infinity> dpkg-genchanges: warning:     debian/changelog(l24): assuming long month name 'July'
<infinity> LINE:  -- Martin Wimpress <code@flexion.org>  Mon, 20 July 2015 00:03:37 +0100
<infinity> dpkg-genchanges: binary-only upload (no source code included)
<infinity>  dpkg-source --after-build ubuntu-mate-settings-15.10.1
<infinity> flexiondotorg: ^-- There, it built, with anger.
<flexiondotorg> Sorry I helped you find a bug that made you do dirty things.
<infinity> dpkg-buildpackage: binary-only upload (no source included)
<flexiondotorg> infinity, Brilliant. Thanks,
<flexiondotorg> I'm going to get some sleep while the arm64 build catch up and I spin some isos in the morning for a final test.
<flexiondotorg> infinity, Thanks.
<infinity> flexiondotorg: What are you missing on arm64?
<infinity> flexiondotorg: I can bump it up.
<flexiondotorg> infinity, Sec...
<flexiondotorg> infinity, eom and mate-netbook
<infinity> flexiondotorg: Both bumped.
<flexiondotorg> infinity, I've lost count of how many beers I owe you.
<infinity> flexiondotorg: All the beers.
<flexiondotorg> infinity, I must sleep. Ctach you tomorrow. Thanks for everything.
<Laney> infinity: flexiondotorg is your whip cracker
 * flexiondotorg is ready to crack the whip. Everyone seem to be in good shape at this point.
<flocculant> flexiondotorg: pretty much so over here ;)
<darkxst> flexiondotorg, you've done a great job with the whip! thanks
<flexiondotorg> darkxst, Thanks for the kind words.
<flexiondotorg> didrocks, Would you be able to update ubuntu-mate-meta again for me?
<flexiondotorg> didrocks, A new version of caja-exentions landed last night that adds a new plugins I'd like to ship.
<didrocks> flexiondotorg: sure, seed pushed?
<flexiondotorg> didrocks, Think so. Just double checking everything is in...
<flexiondotorg> didrocks, Yes. all set thanks.
<didrocks> updating
<darkxst> flexiondotorg, I hope your not planning to spin up new images this late!
<flexiondotorg> darkxst, I am :-)
<flexiondotorg> But it is fine.
<flexiondotorg> I've already tested the new package from PPA builds.
<didrocks> flexiondotorg: Added caja-wallpaper to core
<didrocks> Added gstreamer1.0-tools to core
<darkxst> flexiondotorg, your only making mor work for yourself, I wouldnt re-spin for anything that wasnt a critical installer fail, at this point
<flexiondotorg> didrocks, That is correct.
<flexiondotorg> darkxst, I have time on my hands today.
<didrocks> flexiondotorg: uploaded
<darkxst> flexiondotorg, and your testers also ?
<flexiondotorg> darkxst, Only the PowerPC stuff needs smoke testing.
<flexiondotorg> infinity, Laney unblock ubuntu-mate-meta/1.132
<darkxst> flexiondotorg, your nuts unless these actually break installs!
<flexiondotorg> darkxst, The build already happened a bit earlier.
<darkxst> flexiondotorg, I'll send you a chicken, maybe that will help ;) but I wouldn't be touching anything but super critical install bugs at this point
<flexiondotorg> darkxst, And to be clear. Without the new packages that landed last night Ubuntu MATE was extremely unstable.
<flexiondotorg> Should be much, much better now.
<darkxst> right but unless your blowing the world up, land the fixes after the freeze ligts
<darkxst> lifts
<darkxst> the milestones are mostly about testing the installer, ISO's and what not
<darkxst> flexiondotorg, I only respin for things that affect the installer, anything else, can wait until freeze is lifted IMO
<flexiondotorg> darkxst, Well some of the issue were affecting the installed. I had Caja spawn hundred of windows on me during the Live session install. That was reported by another tester too.
<flexiondotorg> Hence some of the paackage updates last night and the respin.
<Laney> What about this unblock?
<flexiondotorg> Laney, I don't need it for a respin.
<Laney> The freeze gets lifted when we decide all the images are good
<darkxst> flexiondotorg, follow the rules, and wait for the freeze too lift!
<flexiondotorg> Laney, OK.
<darkxst> flexiondotorg, and while I really appreciate you stepping up and cracking the whip against the flavours, I've also seen you push through lots of stuff during the freeze
<flexiondotorg> Well I sorry I've Ive misunderstood the purpose of this process. I have requested changes that have resolved issue that do impact the installer.
<flexiondotorg> I admit that some update a to address critical bug in essential components that are not installer specific.
<Laney> flexiondotorg: You don't have to make your image look like the archive exactly, because users will get to upgrade after we release (not the case for the final release of course)
<darkxst> flexiondotorg, updates can land the minute the freeze lifts
<flexiondotorg> Laney, Yeah, I understand that.
<flexiondotorg> Some of the update were required to ensure the Live session was stable enough for an install to complete.
<Laney> Sure, some updates are fine
<Laney> Especially ones like that - so carry on doing those
<flexiondotorg> I'll not pay so much attention to behaviour regressions in future pre-releases that do not directly impact the installer.
<lordievader> Kubuntu has been marked ready too \o/
<flexiondotorg> lordievader, Thanks.
<darkxst> flexiondotorg, its not just the installer, but if you have genuine cases where things are breaking ok
<lordievader> How is the state of the other images?
<darkxst> its the smaller like like meta package updates and what not that probably could have waited
<flexiondotorg> lordievader, Last night everyone reported testing was going well.
<flexiondotorg> No showstoppers I'm aware of.
<flexiondotorg> I've just installed Ubuntu MATE in the Live session on two different machines and the Caja spawning issue are gone. So Ubuntu MATE is in good shape too now.
<lordievader> I didn't like finding bug 220961, but I guess/hope no one would use a rootfs <= 4Gb.
<ubot93> bug 220961 in ubiquity (Ubuntu) "[MASTER] ubiquity crashes instead of notifying the user of not enough disk space" [High,Triaged] https://launchpad.net/bugs/220961
<darkxst> flexiondotorg, the archives are a shared resource, you kind of need to understand that, maybe mate has a much smaller overlap but still
<Laney> I think he gets the message now
<darkxst> or I scared him off, which really wasnt the plan
<Laney> flexiondotorg: thanks for your help and interest ;-)
<flexiondotorg> Laney, darkxst :-)
<flexiondotorg> Laney, darkxst I'm just completing the test schedules. UBuntu MATE will be marked ready soon.
<flexiondotorg> Laney, Just checking if Lubuntu want to release their PowerPC images.
<flexiondotorg> Laney, And following up with Xubuntu.
<Laney> Maybe I'll get to be the button presser after all
<darkxst> flexiondotorg, you seem to have all the contacts
<flocculant> who'll just about pass it later when I see someone else from our release team
<flexiondotorg> flocculant, Thanks.
<flocculant> had issues with usb boot fails unless I used gnome-disks
<flexiondotorg> Laney, I've prepared the release notes/email.
<Laney> neat
 * darkxst needs dinner
<darkxst> flexiondotorg, your doing good dude, just don't be so ambitious about landing stuff through the milestone freezes!
<flocculant> flexiondotorg: also seen bug 1361951 again
<ubot93> bug 1361951 in partman-ext3 (Ubuntu) "Ubiquity freezes during partition creation" [Medium,Triaged] https://launchpad.net/bugs/1361951
<flexiondotorg> flocculant, I've not hit that. But I'm just about to run the manual partition tests so I'll see if I can reproduce.
<flexiondotorg> Wait for it...
<flexiondotorg> Laney, that's it. Full house.
<flexiondotorg> Laney, everything marked ready and I have confirmation from Lubuntu that ther PowerPC images should not be released.
<flexiondotorg> flocculant, I tried to make bug 1361951 happen but it "worked for me".
<ubot93> bug 1361951 in partman-ext3 (Ubuntu) "Ubiquity freezes during partition creation" [Medium,Triaged] https://launchpad.net/bugs/1361951
<flocculant> flexiondotorg: yea - I think it's probably one of those sometime things
<flocculant> boot from usb failing is another story ...
<Laney> flexiondotorg: ok, will look soon
<flexiondotorg> Laney, Lubuntu, Xubuntu, Ubuntu MATE and Kubuntu all confirm they have release notes in order.
<flexiondotorg> Laney, What about cloud images?
<Laney> flexiondotorg: Dunno. Odd_Bloke / utlemming - any news on B1 cloud images?
 * flexiondotorg makes notes of new contacts.
<Odd_Bloke> Laney: We're currently syncing the image we expect to be beta 1 out to the clouds.
<Laney> cool
<Laney> flexiondotorg: I'll probably look at this after lunch
<flexiondotorg> Laney, OK. But I am unavailable from 13:30 to 15:30.
<Laney> NP
<flexiondotorg> Laney, all flavours are ready with release notes. I have release announce for Wily Beta 1 all ready to go.
<infinity> Laney: I've come down ill, so probably won't be around to handle ISO publishing.  Hopefully, based on flexiondotorg's message above, you can get it out before you need to take off?
<infinity> Laney: If not, I'd suggest asking stgraber very nicely to push the button.
 * flexiondotorg has errands to run, will be back around 15:30 BST
<Laney> infinity: Yeah, no worries, I'm going to start it now
<Laney> flexiondotorg: good to go
 * Laney drops the freeze
 * Laney enables cron, marks milestone as done
* Laney changed the topic of #ubuntu-release to: Released: Trusty 14.04.3, Vivid 15.04, Wily Alpha 2 | Archive: feature 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
<flexiondotorg> Laney, I'm back in the room.
<Laney> Send ze mail
<flexiondotorg> Laney, OK.
<Laney> well, maybe check a torrent or two first
<flexiondotorg> OK. I'll check...
<flexiondotorg> Laney, email sent.
<Laney> thanks!
<Laney> Someone give me the keys to u-d-a already ;)
<flexiondotorg> Laney, my email is awaiting moderation. cjwatson helped with that last time.
<Riddell> flexiondotorg: I'm not sure Groot was a warewolf :)
<ogra_> warez wolf :)
<flexiondotorg> Riddell, Due to the stiffness of Groot's larynx you're not able to hear that he is actually saying "Wily Werewolf" ;-)
<cyphermox> robru: still looking for +1 maintenance tasks?
<Laney> "fix n-m arm64 tests"
<cyphermox> Laney: nah, that's still up to me
 * Laney takes cyphermox's delegation badge away
<cyphermox> it's more like "figure out a way to make those tests optional on arm64"
<Laney> is that a real fix?
<ogra_> note that we might have arm64 phones sooner or later
<ogra_> (probably sooner)
<cyphermox> good enough for me. This is trying to do some stuff with traps/signal which is irrelevant to NM when the rest of the unit tests work
<flocculant> flexiondotorg: just so you remember - there are 3 u's in Xubuntu ;)
<cyphermox> unless someone wants to spend a whole lot of time trying to understand why it fails there reproducibly, and failed on ppc64el twice and then started working
<flexiondotorg> flocculant, Oh bother!
<flexiondotorg> flocculant, Sorry.
<cjwatson> flexiondotorg: done
<flexiondotorg> cjwatson, Thanks you.
<flocculant> flexiondotorg: I'm sure you didn't do it deliberately
<flexiondotorg> flocculant, I didn't.
<robru> cyphermox: yeah but can you email me? I'm super sick, will look at it later
<cyphermox> ok, but then I'll look later too. if you're really sick you should focus on sleeping or medicating to make it better
<cyphermox> tbh I was sick on Monday, I had one dose of DXM and lots of sleep and it helped a *lot* :)
 * Laney has the Âµdebbug
<Laney> (a cold)
<cyphermox> Laney: yeah :/
<Laney> seems others got it worse
<cyphermox> yup
<Odd_Bloke> Laney: flexiondotorg: It's my fault for not being clearer earlier, but the way cloud images work is that we sync out and then flick a switch to make them public; so we haven't actually released anything yet. :)
<Laney> Odd_Bloke: oh, well, do it!
<Odd_Bloke> Laney: Yep, doing it now.  :)
<rtg> Can I get http://archive.ubuntu.com/ubuntu/pool/universe/b/blcr/blcr_0.8.5-2.1.dsc removed from Wily ? It has not worked since kernel 2.6.13 and is no longer active or maintained upstream.
<robru> can I get a NEW review on this packaging? https://code.launchpad.net/~bregma/libertine/package-split/+merge/268946
<teward> can an archive admin look at https://bugs.launchpad.net/ubuntu/+source/electrum/+bug/1481033 which was filed long before feature freeze and was never actually looked at?  it's a removal request for the electrum package, in Universe.  Or, if it was looked at, can someone say why it wasn't addressed/handled?
<ubot93> Launchpad bug 1481033 in electrum (Ubuntu) "Please remove electrum from the archive" [Undecided,New]
<teward> (it was filed on August 3rd)
#ubuntu-release 2015-08-28
<boiko> hi, can anyone please check what is going on with telepathy-ofono in the excuses page? the boot test is listed as a regression
<pitti> boiko -- ah, disappeared
<coreycb> hi, can someone on the release team please take a look at the following FFEs?  this will help unblock most of the openstack packages.  bug 1488094 and bug 1489096.
<ubot93> bug 1488094 in glance (Ubuntu) "[FFE] glance liberty-2 release" [Undecided,New] https://launchpad.net/bugs/1488094
<ubot93> bug 1489096 in python-troveclient (Ubuntu) "[FFE] Please sync python-troveclient (1:1.2.0-4) from Debian (experimental)" [Undecided,New] https://launchpad.net/bugs/1489096
<coreycb> bdmurray, the python-neutronclient sru is ready for review
<bdmurray> coreycb: Okay, I'll have a look shortly.
<coreycb> bdmurray, thanks
<robru> stgraber: thanks
<doko> skipped: gcc-5 (1 <- 92)
<doko>     got: 252+0: a-71:a-44:a-35:i-36:p-35:p-31
<doko>     * amd64: libboost-date-time1.55-dev, libboost-date-time1.55.0, libboost-log1.55-dev, libboost-thread1.55-dev, libboost1.55-all-dev
<doko> slangasek, could that be forced in? it's an unconditional breaks
<slangasek> doko: it breaks libboost-date-time1.55.0 but there are no other reverse-dependencies of this in wily?
<doko> slangasek, http://people.canonical.com/~ubuntu-archive/transitions/html/boost1.58.html
<doko> down to 20 (from 85 this morning)
<doko> I mean, I can remove that breaks again, if that's easier
<slangasek> doko: right, that tells me the state of the transition as a whole; I'm just looking to confirm whether this breaks any revdeps of libboost-date-time1.55.0
<slangasek> and the answer, based on update_output, is 'no'
<slangasek> so yes I'm happy to force this
<doko> ok, thanks
<slangasek> if I can remember the britney syntax ;)
<slangasek> doko: N.B. as an archive admin you could actually satisfy britney's requirements by removing those binaries from wily
<doko> slangasek, yes, already doing for some leaf packages
<slangasek> doko: you've been doing binary removals for this?
<doko> slangasek, iirc, one on armhf, and one on powerpc.
<doko> one even
<slangasek> ok
#ubuntu-release 2015-08-29
<Laney> can someone clean up libxpathselect1.4 in wily-proposed please?
<infinity> Laney: Done.
<doko> this cgal build on armhf drives me crazy ... it works just fine locally without any armhf specifics
<doko> infinity, you introduced that, any idea?
<doko> ScottK, Riddell: anybody of you looking at current kde fallout?  this is just a mess ...
<ScottK> I'm not.  I'm working on Debian gcc5 stuff.
<doko> wrong channel
<ScottK> I'm still not.
<doko> would be good to know what you are, not what you are not
#ubuntu-release 2015-08-30
<Logan> doko: what's the fallout, out of curiosity?
<doko> Logan, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kde-runtime -> e.g. kopete
<doko> Riddell, ^^^
<doko> could somebody hint gdal mia vtk6 gtkglextmm ipe grass cgal qscintilla2 bullet graphicsmagick
#ubuntu-release 2016-08-29
<LocutusOfBorg> any archive admin to remove fcl/armhf pretty please? this will make kido and tinyxml2 transitions end
<LocutusOfBorg> already removed in debian
<bdmurray> tjaalton: In your blog post at https://tjaalton.wordpress.com/2016/03/11/no-catalystfglrx-video-driver-in-ubuntu-16-04/ you mention HWE stack and 14.04.  Was it discussed with AMD?
<tjaalton> bdmurray: yep
<bdmurray> tjaalton: What was / is the plan?
<tjaalton> plan of what? there is amdgpu-pro -driver (beta) which folks are free to try. it's not in the archive because the packaging is not open source yet aiui
<bdmurray> tjaalton: Currently people with fglrx installed are encountering failures when trying to upgrade to lts-xenial e.g. https://paste.ubuntu.com/23095154/
<tjaalton> well it certainly should just remove fglrx
<bdmurray> tjaalton: what about "users relying on pro/workstation class features"?
<tjaalton> they are either screwed or have to download the "pro" driver manually..
<tjaalton> this is all in the release notes
<tjaalton> written by alberto I think
<bdmurray> slangasek: Do you have an opinion on just removing fglrx for 14.04 users?
<slangasek> bdmurray: if they're on the HWE stack, I think that's the right answer
<slangasek> maybe with an added warning in the hwe-support output?
<bdmurray> slangasek: I was looking through forums or askubuntu and one user was surprised they were on the HWE stack - they had downloaded and installed 14.04.2 or so and didn't know the implications of that.
<tjaalton> yeah one option is to fall back on 14.04.1
<bdmurray> slangasek: So they'd made no concious choice to be using the HWE stack.
<slangasek> sure
<slangasek> but I don't think we want update-manager to give them options "upgrade stack or downgrade?"
<slangasek> we can add some messaging about how to get onto the trusty stack if that's what they need to be using
<slangasek> (maybe just in the wiki page)
<bdmurray> slangasek: Okay, so add a warning to hwe-support-status re fglrx tell them to really read the wiki, update the wiki, and upload xserver-xorg-core-lts-xenial w/ breaks on fglrx, fglrx-core, fglrx-updates, and fglrx-updates-core.
<slangasek> bdmurray: yes, +1 from me for that
<tjaalton> additional breaks?
<slangasek> tjaalton: the breaks are needed in order for the resolver to reach the correct solution of removing fglrx, instead of bailing
<bdmurray> tjaalton: additional? I don't see any for -lts-xenial and fglrx
<tjaalton> okay then
<tjaalton> bdmurray: it doesn't provide the driver abi which xserver needs
<tjaalton> that alone should make it uninstall
<tjaalton> which has worked fine so far for other drivers at least..
<slangasek> that's a nice theory ;)
<bdmurray> tjaalton: well, it didn't - https://paste.ubuntu.com/23095154/
<tjaalton> I saw that
<slangasek> it works for the other drivers because there's a newer version that can replace them
<tjaalton> no I mean if a driver wasn't rebuilt
<slangasek> ok
<tjaalton> it'd remove the driver and -all
<slangasek> but the other piece is that fglrx has reverse-dependencies
<tjaalton> been hit by that a few times..
<slangasek> that permutes the weights apt assigns for removal
<tjaalton> yeah that's probably it then
#ubuntu-release 2016-08-30
<bdmurray> slangasek: I've uploaded xorg and update-manager changes for fglrx and hwe support
<slangasek> bdmurray: \o/ thanks
<acheronuk> do daily isos stop building after so many failures? e.g. https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/yakkety/kubuntu
<jbicha> acheronuk: I tried asking in #kubuntu-devel this weekend for someone to try to rebuild the yakkety iso since it might work now (the kactivities binary has been removed)
<tsimonq2> jbicha: that's what we're trying to get done now ;)
<cjwatson> There's nothing automatic that stops image builds after failures.
<tsimonq2> oh, weird
<cjwatson> But the Kubuntu image build is commented out of the crontab for some reason.
<tsimonq2> could someone rebuild Kubuntu Yakkety then?
<cjwatson> I've uncommented it and started a build.
<tsimonq2> ahh, so a member of the release team might have done that
<tsimonq2> thanks so much cjwatson! :)
<tsimonq2> acheronuk: ^
<cjwatson> Could have been an accident when dealing with disabled builds around the beta.
<acheronuk> jbicha: yes I saw that. yofl is snowed under with other commitments I think, so proably didn't see it
<acheronuk> may still fail, but would be nice to give it a poke and see now kactivities is gone
<cjwatson> Yep.
<cjwatson> Should be on automatic as usual now, anyway.
<acheronuk> thank you :)
<cjwatson> np
<jbicha> cjwatson: since we already missed today's run, do you want to run a kubuntu iso rebuild now?
<cjwatson> jbicha: 08:39 <cjwatson> I've uncommented it and started a build.
<jbicha> thanks
 * acheronuk crosses everything it works
<acheronuk> BTW, are these the build scripts? http://bazaar.launchpad.net/~ubuntu-cdimage/debian-cd/ubuntu/files
<cjwatson> That's part of them, but debian-cd is mostly not very interesting for live-CD-type builds.
<cjwatson> The top level is lp:ubuntu-cdimage, but most of the actual live filesystem content is constructed by the livecd-rootfs and live-build packages.
<cjwatson> (lp:ubuntu-cdimage is mainly coordination and publishing)
<acheronuk> ah. ok. thanks
<acheronuk> that seemed to build :D
<barry> release team, can i get a rubber stamp for LP: #1617007 ?
<ubot5> Launchpad bug 1617007 in twine (Ubuntu) "[FFE] twine 1.8.1-1" [Undecided,New] https://launchpad.net/bugs/1617007
<apw> ^ /me is on that ...
<bdmurray> slangasek: Could you review the update-manager / xorg-server-lts-xenial uploads in the Trusty queue?
<robru> xnox: if you're still about can you take a look at my reply to your review of my branch? thanks
<slangasek> bdmurray: looking
<xnox> weird, i didn't get an email.
<robru> xnox: oh I replied to the email I got
<robru> xnox: my reply went through lp
<xnox> robru, lp is slow =) finally got your email. responded on launchpad instead.
<xnox> robru, the order of how things are cloned and merged matters a lot....
<xnox> ideally one should fetch/reset to project's master branch first
<xnox> and then from there call: merge lp:proposed-repo proposed-fix-branch
<xnox> instead of reverse. See my further comments.
<slangasek> bdmurray: accepted, thanks
<robru> xnox: slangasek: what's the git equivalent of bzr-builddeb, specifically the part that allows it to merge debian/changelog without conflicts?
<slangasek> robru: 'dpkg-mergechangelogs'
<xnox> robru, i have a thing for you sir!
<xnox> robru, "just" specify
<xnox> [merge "dpkg-mergechangelogs"]
<xnox>         name = debian/changelog merge driver
<xnox>         driver = dpkg-mergechangelogs -m %O %A %B %A
<slangasek> (which is the underlying implementation in bzr-builddeb's implementation also)
<xnox> in ~/.gitconfig
<xnox> and then there is more
<robru> xnox: slangasek: great, thanks
<xnox> $ cat ~/.config/git/attributes
<xnox> debian/changelog merge=dpkg-mergechangelogs
<xnox> together first thing creates a merge strategy
<xnox> the second thing sets a "global" (XDG_BASE_DIR location) attribute to change git behaviour for files that match that pattern in any repository
<robru> xnox: what do you mean "any repository"? what repositories will not be handled by the global gitconfig?
<xnox> robru, ~/.gitconfig creates a merge strategy, and no files use it.
<xnox> robru, ~/.config/git/attributes sets the attribute for any repositories that this user will operate on. "Usually" attributes in git are set on per repository basis in .git/info/attributes and thus don't propagate across clones at all.
<xnox> "usually" attributes are used on windows systems to specify line-endings conversions and some such stuff.
<robru> xnox: ah
<xnox> dpkg-mergechangelogs is "weird"
<robru> xnox: will git know to look in ~/.config if no $XDG_* variables are set? this is not running as an interactive user
<robru> xnox: better question, where does git look for global attributes when no $XDG_* vars are set ;-)
<robru> xnox: nm, "If $XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/attributes is used instead."
<xnox> robru, yes... XDG spec says to try $HOME/.config if e.g. XDG_CONFIG_HOME is not set.
<xnox> that's why XDG base dir spec is good.
<robru> xnox: hm, not working, any ideas here: http://paste.ubuntu.com/23113050/ ?
<xnox> robru, ok, and what users runs git? and is the home for that user in /var/www ?
 * xnox checks my configs more
<robru> xnox: yes, www-data is running git, and /var/www is $HOME
<robru> I'll try to reproduce locally, maybe it's a real conflict
<xnox> robru, $ sudo apt install dpkg-dev ?
<robru> xnox: already installed
<xnox> robru, check permissions on those files too... should be owned by www-data.
 * xnox tries to find a way to validate which attributes are applied for a file
<xnox> $ git check-attr --all debian/changelog
<xnox> debian/changelog: merge: dpkg-mergechangelogs
<robru> xnox: this may be a legitimate conflict, these changelogs were both done by hand so it's not clear to me that this is quite what mergechangelogs was meant for: http://paste.ubuntu.com/23113075/
<xnox> horum. yeah.
<xnox> quick way to check that dpkg-mergechangelogs work is to "merge" a git-import-dsc "commit"
<xnox> or run the check-attr command.
<xnox> if that shows as enabled for debian/changelog, then all is good, and one should get less merge conflicts.
<robru> xnox: oh I see, it's trying to merge two different entries with the same version number, that's why
<xnox> robru, which means that dpkg-mergechangelogs is doing something, and trying to be helpful.
<xnox> possibly
<robru> xnox: ok thanks, yeah I think everything is good, just bad example to test with
 * xnox wonders if launchpad has dpkg-mergechangelogs setup
<xnox> for git
<cjwatson> xnox: it does not, but it would at most only matter for merge previews
<cjwatson> xnox: and arguably setting it up for those would be misleading, because it would mean an apparently conflict-free merge would only be conflict-free if you happened to have dpkg-mergechangelogs set up
<xnox> true, yet it would be so nice.
<xnox> to be honest, i'm failing to see why debian/ubuntu does not ship that enabled globally by default.
<xnox> it would be easy enough to do.
#ubuntu-release 2016-08-31
<xnox> Laney, pitti: may i inquire about the bug #1615039
<ubot5> bug 1615039 in gnupg2 (Ubuntu) "[FFe] /usr/bin/gnupg --version should be 2.1" [Undecided,In progress] https://launchpad.net/bugs/1615039
<xnox> i have a merge done, testing at the moment, but i'm ready to upload it. Thinking to block it in proposed for a little while to see the fallout.
<xnox> some say that cdimage infra and some such may blow up.
<tjaalton> infinity: looks like I'm not attending the sprint, so any lts discussion would have to be online :)
<apw> xnox, that sounds like the sort of breakage that won't be detected in -proposed ?
<Laney> xnox: Might want to do it closer to the start of a cycle than the end?
<Laney> Unless you have a very good idea of what might break and how to fix it
<cjwatson> (and if you do, I'd like to know how to noninteractively delete a secret key using gnupg2, for test suite purposes ...)
<xnox> Laney, all packages in the archive are fixed to deal with gnupg2 and our gpg-agent.service is solid (unlike debian's)
<xnox> Laney, we already see syncs in 16.10 with versioned breaks that assume that gnupg2 -> gnupg migration has happened.
<xnox> Laney, i don't know where gpg in invoked, and if that will affect anything.... launchpad signs things by itself. Somebody mentioned that livecd building may be using gpg for some things... but i'm not sure if that is happening in yakkety chroot or not.
<xnox> ditto cdimage, i thought it's doing everything on the host and not inside chroots.
<xnox> cjwatson, good question
<jbicha> it feels a bit broken that seahorse in xenial suddenly uses gpg2 (only) so running gpg from the command line and running seahorse show different results
<jbicha> (of course, the gnupg2>gnupg migration in yakkety doesn't help xenial)
<seb128> is that a recent change in xenial due to a SRU?
<jbicha> no, it was like that on release
<seb128> k, I didn't parse what you wrote correctly then
<cjwatson> xnox: snapd uses gpg1 because AFAICT this problem cannot be handled sanely in gpg2 as it stands ... (but seriously, don't spend huge amounts of time on it, I wasted half a day and gave up)
<cjwatson> (but snapd can cope with the gnupg2 -> gnupg migration having happened, I was careful)
<cjwatson> and yes, LP/cdimage does all the signing in the fixed base system and won't immediately be affected by a change in yakkety, AFAIK
<xnox> cool.
<Laney> xnox: there you go
<xnox> cjwatson, gpg2 --batch --yes --pinentry-mode loopback --delete-secret-and-public-key 0x28E7DEFB99F919E1145F18F381565D68A1290D19
<xnox> works... but public key is gone too.
<xnox> so if you want to keep public key, export it first, stash, and re-import just public key.
<cjwatson> xnox: --pinentry-mode loopback didn't work for me
<cjwatson> I forget the exact details but I did try that and IIRC the error message was something like that the loopback mode was disabled
<xnox> horum.
<apw> isn't the public key in the normal place, and the secret key in its own per key file, you might be able to just remove those directly (what could go wrong)
<cjwatson> ... yeah, um, not doing that.
<xnox> apw, still cached in the agent, so one needs to kill the agent too.
<cjwatson> even if I thought it would get past review which it wouldn't :)
<xnox> but yeah rm private_keys-v1.d/*.key works
<xnox> (i made typo above, for sake of people not copy & pasting)
<apw> cjwatson, i truly hope not indeed :)
<bdmurray> arges: Could you have a look at my livecd-rootfs upload in the Xenial queue?
<arges> bdmurray: sure
<apw> xnox, i am supprised --delete-secret-keys <fingerprint> --yes doesn't work from teh manual, but i assume that has been tested
<xnox> yeah.
<xnox> cjwatson, gpg --batch  --delete-secret-and-public-key $fingerprint </dev/null seems to work in debian sid chroot with gpg 2.1.14, and matching gnupg-agent
<xnox> gpg --batch  --delete-secret-key $fingerprint </dev/null
<xnox> too
<cjwatson> when I tried that I'm pretty sure I got a pinentry prompt, but I'll try again at some point, thanks.
<xnox> yeah, i get pinentry prompts or errors here on ubuntu desktop with gnupg 2.1.11
<apw> cjwatson, some documentation implies --yes will prevent pinentry on that batch delete, though our version does not mention it
<cjwatson> yes, the docs said that but they appeared to lie based on my experience + reading of the source
<cjwatson> you are now about half an hour into my four-hour rabbit hole the other day :-)
 * apw self flagilates
<xnox> cjwatson, have you ever seen this before? http://paste.ubuntu.com/23116380/
 * xnox has reconstructed chroots already, and there is nothing special in my schroot/sbuild
<cjwatson> xnox: afraid not
<cjwatson> isn't ESTALE mostly an NFS thing?
<xnox> true. but i don't have any NFS....
<jbicha> could fcl/armhf please be removed (Debian did this too) since it's holding up the tinyxml2 transition
<LocutusOfBorg> bug #1617835
<ubot5> bug 1617835 in fcl (Ubuntu) "Please remove fcl/armhf from yakkety" [High,New] https://launchpad.net/bugs/1617835
<doko> gave back failed packages in -proposed. at least four now built and migrated
<ginggs_> thanks doko - i received some mails about packages that still failed - btw how much do we care about things already in yakkety that ftbfs with gcc 6? e.g. LP: #1619035
<ubot5> Launchpad bug 1619035 in protobuf (Ubuntu) "FFe: Sync protobuf 3.0.0-6 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1619035
<doko> ginggs_: I'm usually fine with such requests, but would like to wait until that migrated to testing
<doko> just to make sure we have a somehow clean migration
<ginggs_> ok, thanks
<bdmurray> slangasek: Could you merge https://code.launchpad.net/~mterry/ubuntu-archive-tools/phablet-teams/+merge/303163
<slangasek> bdmurray, mterry: what's the reason for the switch from -bugs to -team? someone is eager to be overwhelmed with bug mail? :)
<slangasek> I suppose since unity-api-bugs has no remaining members except for the two of us, a change of some sort is needed there
<bdmurray> slangasek: the -team teams already exist and were subscribed to packages as it was, so to eliminate confusion.  People were submitting mirs with -team subscribed and didn't know about -bugs.
<slangasek> right
<slangasek> so as long as they're all happy with the resulting bug mail, that's fine
<slangasek> (merged)
<bdmurray> thanks
#ubuntu-release 2016-09-01
<Mirv> this would still be wanted to get in before do_ko starts archive rebuild, but I guess there was no progress on evaluating those KDE dh_acc failures? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src - the only change in that upload is the powerpc configure switch
<Mirv> I'd have the next qtbase upload ready in a PPA, but I was thinking you might want to get this one to the release pocket first due to the powerpc linker fix
<slangasek> Mirv: I think the conclusion is that the failures are clearly not regressions caused by qtbase-opensource-src, I just didn't get the hints added
<Mirv> slangasek: ok, thanks if you can add those.
<slangasek> I did explicitly retry akonadi-calendar against devel, and it fails there: http://autopkgtest.ubuntu.com/browse.cgi/packages/akonadi-calendar/yakkety/amd64
<slangasek> so adding hints now
<slangasek> ah, but I also uploaded a new bluez-qt, and those tests should be rerun now against current version; let me kick that off, then add hints
<slangasek> (triggered)
<slangasek> and retriggering yade/s390x for proper results
<Mirv> ok!
<slangasek> Mirv: everything is clearing, the only blockers now are a pending bluez-qt/ppc64el retry which got lost because the tool didn't tell me I spelled 'ppc64el' wrong, so retrying now; and akonadi/s390x, which looks like it died somewhere along the way so retriggering that also
<slangasek> Mirv: if those don't both clear in the next hour or so, maybe pitti can help
<pitti> heh, I just retried bluez-qt against -proposed
<pitti> (I'm just in my morning round through excuses.html)
<Mirv> thanks steve
<Mirv> and pitti too :)
<jamespage> apologies for some NEW sync noise for openstack packages today - python-os-vif and python-cursive (not yet reviewed in debian) are both to support the newton b3 milestone this week
<jamespage> nothing on iso's
 * apw is looking at ^^
<xnox> https://bugs.launchpad.net/ubuntu/+source/ubuntu-touch-meta/+bug/1619468
<ubot5> Launchpad bug 1619468 in ubuntu-touch-meta (Ubuntu Yakkety) "Uninstallable ubuntu-touch-meta" [Critical,New]
<xnox> pitti, ^
<xnox> that causes a few things failing to migrate
<xnox> e.g. python-gnupg for no reason.
<mwhudson> bdmurray: oops (juju-mongodb3.2 missing bug ref)
<mwhudson> infinity: ayt?
<jbicha> nein?
<xnox> sil2100, you may want to close the bug #1619468  or mark it as duplicate or whatever
<ubot5> bug 1619468 in ubuntu-touch-meta (Ubuntu Yakkety) "Uninstallable ubuntu-touch-meta" [Critical,New] https://launchpad.net/bugs/1619468
<infinity> mwhudson: Nope.
<mwhudson> infinity: how do you feel about deleting containerd/powerpc from yakkety & xenial-updates?
<mwhudson> the new version ftbfs there
<mwhudson> in a way that's going to be a royal pain to fix
<mwhudson> (and this is blocking docker migrating, which isn't built on powerpc anyway)
#ubuntu-release 2016-09-02
<tjaalton> bdmurray: oops, sorry for missing the xserver-lts-xenial diff, I'll merge it now and upload again
<tjaalton> but not before the sru is released of course
<xnox> can gnupg2 triggered libmail-gnupg-perl test use (libmail-gnupg-perl,gnupg) from proposed?
<xnox> similar with apt
<xnox> or like hint apt/gnupg2/libmail-gnupg-perl to go in together
<doko> ginggs_: do you want to look at the shogun ftbfs, or should we just demote it?
<ginggs_> doko: please demote it, that looks like debian #835411
<ubot5> Debian bug 835411 in src:eigen3 "eigen3: causes FTBFS in other packages" [Serious,Open] http://bugs.debian.org/835411
<xnox> Laney, is there some way to hint gnupg2 to go in together with libmail-gnupg-perl.
<Laney> hi xnox
<xnox> apt tests actually passed and it migrated, libmail-gnupg-perl in proposed also passes its tests, and snapd is all good as well.
<Laney> sure, but that's not much use if the tests are failing
<Laney> you probably want them re-run?
<xnox> yes but libmail-gnupg-perl & gnupg2 should be rerun with proposed.
<xnox> and the retry button doesn't offer me to do that.
<Laney> ok
<Laney> 'go in together' means something else to me
<xnox> as in testing libmail-gnupg-perl from release with gnugp2 from proposed will always fail.
<xnox> libmail-gnupg-perl from release works with gnupg2 in release; libmail-gnupg-perl from proposed works with gnupg2 in proposed or release;
<jbicha> xnox: you can manually append &trigger=gnupg2/2.1.15-1ubuntu2 to the url the retry button suggests
<xnox> that bit is right.
<xnox> i think i need two triggers.... gnupg2 and libgnupg-interface-perl/$proposed-version
<Laney> xnox: I did them for you
<xnox> thanks
<xnox> is there a magic how-to? granted i don't cause such things often.....
<Laney> Maybe you can pass &trigger= more than once
<Laney> I just ran a command on snakefruit
<xnox> i wonder if my depends are not explicit enough in the libmail-gnupg-perl case
<xnox> Laney, can gnupg2 be hinted with skiptests and hinted to libgnupg-interface-perl to migrate together with gnupg2?
<xnox> horum looking at http://autopkgtest.ubuntu.com/packages/libm/libmail-gnupg-perl/yakkety/amd64 triggers are still incorrect
 * xnox fiddles
<xnox> tadah https://autopkgtest.ubuntu.com/request.cgi?release=yakkety&arch=amd64&package=libmail-gnupg-perl&trigger=gnupg2%2F2.1.15-1ubuntu2&trigger=libmail-gnupg-perl%2F0.22-1ubuntu2
<Laney> xnox: did that work?
<Laney> I'm not that comfortable forcing gpg-related tests
<doko> kenvandine: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-007/+sourcepub/6843960/+listing-archive-extra   there is no need to drop the java package and the java build-deps
<kenvandine> doko, why?  we don't want to do an MIR for tomcat
<doko> kenvandine: we did the archive reorg last cycle
<doko> kenvandine: build-deps from universe are fine
<kenvandine> oh they are?
<kenvandine> that's good :)
<teward> unless they add new runtime deps
<kenvandine> ok
<kenvandine> they don't in this case
<teward> s/new runtime deps/new runtime binary dependencies on something in universe as a result of building with the Universe package(s)/
 * teward was imprecise
<doko> and I assume the java module will end up in universe anyway
#ubuntu-release 2016-09-03
<doko> jbicha: are you running a bot for your syncs?
<sergiusens> slangasek I am guessing it is still Friday for you wrt ^ :-) (if not, Monday is fine and I'll find someone on the roll for then)
<flocculant> cyphermox: language choice appears to be missing if you install via the try/install option (bug 1619857)
<ubot5> bug 1619857 in ubiquity (Ubuntu) "Language choice missing when installing from try/install option" [Undecided,New] https://launchpad.net/bugs/1619857
<flocculant> cyphermox: sorry - didn't see the language choice there for looking ...
<cyphermox> flocculant: thanks, I'll look.
<flocculant> cyphermox: no - I mean I didn't see the choice - but it was there - marked my bug invalid
<flocculant> cos there's no 'reported bug while tired' option
#ubuntu-release 2017-08-28
-queuebot:#ubuntu-release- New: accepted network-manager [amd64] (artful-proposed) [1.8.2-1ubuntu4]
-queuebot:#ubuntu-release- New binary: fonts-noto-cjk [amd64] (artful-proposed/main) [1:1.004+repack3-2] (kubuntu, personal-gunnarhj, ubuntu-desktop)
<flexiondotorg> slangasek Who will be assisting the 17.10 Beta 1 iso spinning/release etc?
<flexiondotorg> Beta 1 scheduled for August 31st.
<flexiondotorg> I've started gathering the participating flavours.
<tsimonq2> fwiw, Laney did Nusakan for last cycle's Beta 1, but looks like he's not in the chan
<micahg> doesn't appear to be online
<slangasek> flexiondotorg: looks like sil2100 might take point, and I'm working on getting things set up on the tracker.  Is http://iso.qa.ubuntu.com/qatracker/series/62/manifest accurate to your understanding?
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Artful Beta 1] (20170828) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Artful Beta 1] (20170828) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop amd64 [Artful Beta 1] (20170828) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop i386 [Artful Beta 1] (20170828) has been added
-queuebot:#ubuntu-release- Unapproved: neutron-lbaas-dashboard (zesty-proposed/universe) [2.0.0-0ubuntu1 => 2.0.0-0ubuntu1.1] (no packageset)
<flexiondotorg> slangasek sil2100 From the feedback I've had so far, the tracker looks correct.
<valorie> any guesses on when Kubuntu beta 1 will roll out for prelim testing?
<slangasek> valorie: just now triggered the builds, now that flexiondotorg has confirmed whose should be built.  so, soon
<slangasek> sil2100: ^^
<valorie> ping sil2100 slangasek flexiondotorg - Kubuntu is participating in beta 1
<valorie> cool
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Artful Beta 1] (20170828) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Artful Beta 1] (20170828) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Artful Beta 1] has been updated (20170828.1)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Artful Beta 1] has been updated (20170828.1)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Artful Beta 1] (20170828.2) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Artful Beta 1] (20170828.2) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop amd64 [Artful Beta 1] has been updated (20170828.1)
-queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop i386 [Artful Beta 1] has been updated (20170828.1)
-queuebot:#ubuntu-release- New sync: hunspell-dz (artful-proposed/primary) [0.1.0-1]
<tsimonq2> What's up with the respin? ^^^^
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Artful Beta 1] (20170828.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Artful Beta 1] (20170828.1) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Artful Beta 1] (20170828.1) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Artful Beta 1] (20170828.1) has been added
<slangasek> tsimonq2: is it a respin?  sorry, I overlooked that there were already builds posted for lubuntu which I didn't trigger; that was the batch trigger of all flavors for beta1
<tsimonq2> slangasek: I'm just assuming respin because of timestamps with "20170828.1" and there's two sets of Lubuntu notifications
<tsimonq2> slangasek: And ok, cool.
<slangasek> tsimonq2: yes, it is a "respin" based on the scrollback that I overlooked :-)
<tsimonq2> Alright :)
<tsimonq2> slangasek: Being on the safe side here -- do metapackage updates (i.e. meta-kde or something) violate Feature Freeze?
<slangasek> tsimonq2: they might; but I'm also not going to yell at flavors for changes they make to their own images
<slangasek> although actually, now that I think of it
<slangasek> sorry, that came out wrong ;)
<slangasek> what I was going to say is, I think we might want a respin of all images again for beta-1 immediately, since I just now dropped resolvconf from the bootstrap set
<slangasek> (it was in progress last week but had to be reverted until new systemd landed)
<tsimonq2> ack
<tsimonq2> Hmm, I'm new to having archive upload access (:P), if a package is blocked from migrating because an rdep fails autopkgtests, and I upload a new version that fixes them, does the rdep automatically get a retry against the blocked package, or do I have to do sometime to it?
<tsimonq2> s/sometime/something/
<tsimonq2> (that question should have probably went to #ubuntu-devel but whatever :) )
<tsimonq2> Oh, nvm, I RTFM'ed
-queuebot:#ubuntu-release- New binary: meta-kde [amd64] (artful-proposed/universe) [5:92] (kubuntu)
-queuebot:#ubuntu-release- New binary: meta-kde [ppc64el] (artful-proposed/universe) [5:92] (kubuntu)
-queuebot:#ubuntu-release- New binary: meta-kde [i386] (artful-proposed/universe) [5:92] (kubuntu)
-queuebot:#ubuntu-release- New binary: meta-kde [arm64] (artful-proposed/universe) [5:92] (kubuntu)
-queuebot:#ubuntu-release- New binary: meta-kde [s390x] (artful-proposed/universe) [5:92] (kubuntu)
-queuebot:#ubuntu-release- New binary: meta-kde [armhf] (artful-proposed/universe) [5:92] (kubuntu)
<slangasek> tsimonq2: OOI which M did you R?
<tsimonq2> slangasek: hm?
<slangasek> tsimonq2: which manual did you read
<tsimonq2> slangasek: https://wiki.ubuntu.com/ProposedMigration#How_to_re-run_autopkgtests_with_dependencies_on_other_packages_in_the_proposed_pocket
<slangasek> tsimonq2: ok.  which package are you uploading in order to fix - the failing package or the package that caused it to fail?
<tsimonq2> slangasek: I'm looking to get nodejs to migrate
<tsimonq2> slangasek: I uploaded fixes to node-tap and node-evp-bytestokey.
<tsimonq2> slangasek: I *think* I figured it out (I can retry things now that I'm a member of ~motu, thankfully)
<slangasek> tsimonq2: ok.  since node-evp-bytestokey has already migrated to artful, you don't need any special triggers, you just have to hit the retry button
<tsimonq2> slangasek: Yep, and I did exactly that :)
 * slangasek nods
<tsimonq2> slangasek: What about node-tap?
<slangasek> tsimonq2: that one shows autopkgtest regressions in its own revdeps that will need sorting... and you'll want to trigger a node-tap retest against node-tap+nodejs from -proposed in parallel to that
<tsimonq2> slangasek: ack, thanks!
<tsimonq2> slangasek: Also, mind giving the aforementioned meta-kde a review? ;)
<slangasek> tsimonq2: heh, I said you could update metapackages; you neglected to mention you needed NEW review... ;)
<tsimonq2> slangasek: That makes a difference? :P
<slangasek> tsimonq2: one is asking the archive admins to do something, the other is not
<tsimonq2> slangasek: True
<tsimonq2> slangasek: My point is, does it make a difference irt Feature Freeze?
<slangasek> this looks like a pretty major change from what was there in zesty; why the change?
<tsimonq2> The Ubuntu delta does a lot of what's in Debian already
<tsimonq2> i.e. package renames, etc.
<slangasek> ok, but why *change*?  according to the last changelog these binary packages were all deliberately dropped because they are orthogonal to the kubuntu-meta package
<tsimonq2> slangasek: These packages aren't provided by kubuntu-meta itself, but it's getting to a point where kubuntu-desktop might not have all of KDE (we've been having second thoughts about PIM) -- having a KDE-specific metapackage with non-Kubuntu packaging would be beneficial for people who want KDE Plasma without Kubuntu
<tsimonq2> Why change? Well, it's getting closer to Debian and it provides metapackages that are beneficial for end users.
<tsimonq2> (i.e. the same reason why lubuntu-meta and the lxde metapackages still exist independently)
<tsimonq2> Specific entry:
<tsimonq2> +  * Remove kde-standard, kde-full, kde-plasma-desktop and
<tsimonq2> +    kde-plasma-netbook metapackages, kubuntu has its own meta packages
<tsimonq2> (I think my point reflects why we should bring those back)
<valorie> not netbook, for god's sake
<tsimonq2> valorie: My point is, that should be dealt with in Debian
<valorie> zombie, it is
<slangasek> tsimonq2: I find this argument dubious; the role of flavor teams is precisely to curate the installed set of packages on behalf of Ubuntu users.  Who wants to install the not-Kubuntu KDE meta packages?
 * valorie hands tsimonq2 the magick sword
<slangasek> tsimonq2: btw, do you want to comment on Debian bug #872580 with whatever info is relevant?
<ubot5> Debian bug 872580 in node-evp-bytestokey "[node-evp-bytestokey] FTBFS with node v6" [Serious,Open] http://bugs.debian.org/872580
<tsimonq2> slangasek: meta-kde> "Who wants to install the not-Kubuntu KDE meta packages?" - you would be surprised, actually
<tsimonq2> Regardless, on the flipside, I don't see a reason why the delta *should* exist
<tsimonq2> slangasek: node-evp-bytestokey> sure
<slangasek> sure; usually we don't have a delta because we blacklist such packages entirely ;)
<tsimonq2> !info lxde
<ubot5> lxde (source: lxde-metapackages): Metapackage for LXDE. In component universe, is optional. Version 9 (zesty), package size 1 kB, installed size 10 kB
<tsimonq2> slangasek: :P
<slangasek> tsimonq2: that just shows that no one has blacklisted it *yet* :)
<tsimonq2> slangasek: But I think blacklisting is besides the point, fwiw
<tsimonq2> If we're going to blacklist it, why have any Ubuntu changes?
<slangasek> I don't know?  I didn't make those changes
<slangasek> I do think it's better to drop this package instead, but I won't block it.  However, I think the Kubuntu team should get a say in what's done with this package
<tsimonq2> valorie, clivejo: ^^
<valorie> well, acheronuk, not me
-queuebot:#ubuntu-release- Unapproved: lxd (xenial-backports/main) [2.16-0ubuntu2~ubuntu16.04.1 => 2.17-0ubuntu2~ubuntu16.04.1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lxd (zesty-backports/main) [2.16-0ubuntu2~ubuntu17.04.1 => 2.17-0ubuntu2~ubuntu17.04.1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (xenial-backports) [2.17-0ubuntu2~ubuntu16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (zesty-backports) [2.17-0ubuntu2~ubuntu17.04.1]
<slangasek> heh; resolvconf demotion hasn't taken effect yet because there have been no new publications to artful.  Guess I need to fix something.  Oh look, there's a source package that will migrate if I accept the new binaries synced from Debian :P
-queuebot:#ubuntu-release- New: accepted fonts-noto-cjk [amd64] (artful-proposed) [1:1.004+repack3-2]
-queuebot:#ubuntu-release- New: accepted meta-kde [arm64] (artful-proposed) [5:92]
-queuebot:#ubuntu-release- New: accepted meta-kde [i386] (artful-proposed) [5:92]
-queuebot:#ubuntu-release- New: accepted meta-kde [s390x] (artful-proposed) [5:92]
-queuebot:#ubuntu-release- New: accepted meta-kde [amd64] (artful-proposed) [5:92]
-queuebot:#ubuntu-release- New: accepted meta-kde [ppc64el] (artful-proposed) [5:92]
-queuebot:#ubuntu-release- New: accepted meta-kde [armhf] (artful-proposed) [5:92]
<flexiondotorg> slangasek I've just heard that Xubuntu would like to participate in 17.10 Beta 1 as well.
<valorie> yay!
#ubuntu-release 2017-08-29
<slangasek> how do I persuade flavors to not do optional milestones, instead ;)
<jbicha> slangasek: I don't think we need 2 Alphas, we only did 1 last cycle and it wasn't a problem
<slangasek> doko: do you have any insights into why the lapack rebuild with current toolchain breaks python-scipy on i386?  I tried a lapack rebuild with -ffloat-store and it doesn't help
<slangasek> ok, triggering rebuildsfor resolvconf; sorry, should've done this earlier, only just now realized that apt was lying to me locally
<slangasek> doko: rebuilding lapack with gfortran-6 doesn't appear to help
<Ukikie> slangasek: I don't suppose you'd look at xfce4-statusnotifier-plugin in NEW?
-queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop amd64 [Artful Beta 1] has been updated (20170829)
-queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop i386 [Artful Beta 1] has been updated (20170829)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Artful Beta 1] has been updated (20170829)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Artful Beta 1] has been updated (20170829)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Artful Beta 1] has been updated (20170829)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Artful Beta 1] has been updated (20170829)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Artful Beta 1] (20170829) has been added
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Artful Beta 1] (20170829) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Artful Beta 1] has been updated (20170829)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Artful Beta 1] has been updated (20170829)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Artful Beta 1] has been updated (20170829)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Artful Beta 1] has been updated (20170829)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Artful Beta 1] has been updated (20170829)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Artful Beta 1] has been updated (20170829)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Artful Beta 1] has been updated (20170829.1)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Artful Beta 1] has been updated (20170829.1)
<tsimonq2> jbicha: I can make a good argument for 3 on an LTS release :P
<tsimonq2> (Alphas)
-queuebot:#ubuntu-release- Unapproved: lubuntu-meta (xenial-proposed/universe) [0.65.1 => 0.65.2] (lubuntu)
<ginggs> would someone please bump 'force-badtest node-tap/8.0.0-4ubuntu4/armhf' in vorlon's hints?
<slangasek> done
<ginggs> slangasek: thanks!
<slangasek> on that note, re-triggering node-tap tests for new nodejs now
<slangasek> well, the new node-tap doesn't seem to fare any better with nodejs
<tsimonq2> :(
<flocculant> slangasek: re "how do I persuade flavors" - I'd not take much persuading at all ;)
<ginggs> slangasek, tsimonq2: i'll have a look at node-tap and skipping those tests that fail with node6 with another upload, unless you want to hint it through?
<tsimonq2> Hinting it through wfm fwiw
<Laney> slangasek: I think I saw some questions from you, but I managed to lose them and forget what they were - mind reminding me?
<Laney> Something about cloud images...
<clivejo> jbicha: are you around?
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Artful Beta 1] has been updated (20170829.1)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Artful Beta 1] has been updated (20170829.1)
<flocculant> jbicha: have you seen gnome-software seg faulting on artful 32bit iso? bug 1713344, bug 1713701
<ubot5> bug 1713344 in gnome-software (Ubuntu) "gnome-software core dump" [Undecided,Confirmed] https://launchpad.net/bugs/1713344
<ubot5> bug 1713701 in gnome-software (Ubuntu) "Gnome Software fails to run on 17.10 Beta 1 i386" [Undecided,Confirmed] https://launchpad.net/bugs/1713701
<jbicha> I haven't been running the 32 bit iso
<flocculant> well no - me neither for years ... but we do test it - and g-s crashes there
<mitya57> tsimonq2, Do you upload the new version of dep or rdep?
<mitya57> tsimonq2, nevermind
<flocculant> jbicha: and you're the closest to some Gnome dude that I know of :)
 * mitya57 somehow thought that the old message was at the bottom of the log
<ginggs> would someone please bump 'force-badtest node-tap/8.0.0-4ubuntu5/armhf' in vorlon's hints? - last time today, i promise
<apw> ginggs, looking
<ginggs> apw, wait it might have passed
<ginggs> lol http://autopkgtest.ubuntu.com/packages/n/node-tap/artful/armhf
-queuebot:#ubuntu-release- Unapproved: sbuild (zesty-proposed/universe) [0.71.0-2ubuntu1 => 0.71.0-2ubuntu2] (no packageset)
<slangasek> Laney: hi! the question was, do you know why the base images used for autopkgtest on amd64 got bigger on the 23rd (to include the full cloud seed)
-queuebot:#ubuntu-release- New binary: node-pako [amd64] (artful-proposed/universe) [1.0.5+ds-2ubuntu1] (no packageset)
<Laney> slangasek: ah right, ok - can you point me at a specific instance so we're looking at the same thing?
<Laney> hmm
<Laney> looks like cloud images have taken a holiday over the past few days
 * Laney doesn't know where their build logs are
<slangasek> Laney: where I noticed it was in the artifacts for cantor tests before/after the 23rd
<Laney> slangasek: so I think the first task is to get cloud images for artful back in lgw01/lcy01
<Laney> presumably comes down to getting current ones on https://cloud-images.ubuntu.com/artful/current/ ?
<slangasek> "back in"? D:
<Laney> ubuntu@juju-prod-ues-proposed-migration-machine-3:~> nova image-list | grep artful | grep -v adt
<Laney> 1 ubuntu@juju-prod-ues-proposed-migration-machine-3:~>
<slangasek> wat
<Laney> the fallback for adt is to dist-upgrade the previous one
<Laney> so it's not terminal
<Laney> but still
<slangasek> ok, let me chase that
<Laney> do you know where buildlogs are, OOI?
<Laney> (slightly absent; desktop team meeting)
<slangasek> Laney: I've got philroche helping me track it down
 * Laney nod
<slangasek> Laney: it looks like the previous image build failures are resolved and should propagate soon-ish
<slangasek> Laney: images themselves were building but the pipeline for publishing them broke.  anyway, build logs if you can read them: https://launchpad.net/~cloudware/+livefs/ubuntu/artful/cpc/
<Laney> nope
<slangasek> Laney: k.  known bug that they're not public :/
<Laney> slangasek: ho hum
<Laney> well, I'll keep an eye out for them turning back up in ScalingStack at least
<slangasek> philroche: ^^ do you mind updating us here (or passing the baton to whoever takes it over EOD) once the cloud images are published again?
-queuebot:#ubuntu-release- New binary: node-chokidar [amd64] (artful-proposed/universe) [1.7.0-1] (no packageset)
<philroche> slangasek: Ack. I'm EOD now but I have passed baton to rcj
-queuebot:#ubuntu-release- New: accepted node-chokidar [amd64] (artful-proposed) [1.7.0-1]
-queuebot:#ubuntu-release- New binary: mutter [ppc64el] (artful-proposed/main) [3.25.91-0ubuntu1] (desktop-extra, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: mutter [i386] (artful-proposed/main) [3.25.91-0ubuntu1] (desktop-extra, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: mutter [amd64] (artful-proposed/main) [3.25.91-0ubuntu1] (desktop-extra, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: mutter [s390x] (artful-proposed/main) [3.25.91-0ubuntu1] (desktop-extra, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: mutter [arm64] (artful-proposed/main) [3.25.91-0ubuntu1] (desktop-extra, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: mutter [armhf] (artful-proposed/main) [3.25.91-0ubuntu1] (desktop-extra, ubuntu-desktop)
<flexiondotorg> tsimonq2 Ping
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (zesty-proposed/main) [4.10.0-34.38] (core, kernel)
-queuebot:#ubuntu-release- New binary: node-watchpack [amd64] (artful-proposed/universe) [1.3.1-2] (no packageset)
<slangasek> at some point, the answer to a flavor coming in two days before a beta saying "we're participating in the milestone" needs to be "no, you aren't"...
<coreycb> bdmurray: hi, can you take a look at releasing nova to zesty-updates for this? https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1706297
<ubot5> Ubuntu bug 1706297 in nova (Ubuntu Zesty) "[SRU] ocata stable releases" [Undecided,Fix committed]
<bdmurray> coreycb: bug 1697610 part of the same nova upload seems unverified
<ubot5> bug 1697610 in libvirt (Ubuntu Zesty) "aarch64: logfile not supported in this QEMU binary" [Medium,Triaged] https://launchpad.net/bugs/1697610
<coreycb> bdmurray: ah right, ok. that's going to be tested soon.
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (zesty-proposed) [4.10.0-34.38]
-queuebot:#ubuntu-release- Unapproved: uwsgi (xenial-proposed/universe) [2.0.12-5ubuntu3 => 2.0.12-5ubuntu3.1] (no packageset)
<LocutusOfBorg> fossfreedom, syncing ubuntu-budgie
<fossfreedom> LocutusOfBorg, syncing?
<jbicha> LocutusOfBorg: I think there's still some Ubuntu delta
<LocutusOfBorg> fossfreedom, I remember some little change
<LocutusOfBorg> I asked you a while ago
<jbicha> LocutusOfBorg: the changes from 10.4-0ubuntu3 at least
<LocutusOfBorg> why are them still relevant?
<LocutusOfBorg> - libmutter-0-dev (>= 3.24) | libmutter-1-dev (>= 3.25.90),
<LocutusOfBorg> -# libmutter-dev (>= 3.18) | libmutter-0-dev (>= 3.24) | libmutter-1-dev (>= 3.25.90),
<LocutusOfBorg> + libmutter-dev (>= 3.18) | libmutter-0-dev (>= 3.24) | libmutter-1-dev (>= 3.25.90),
<LocutusOfBorg> this isn't to me
<jbicha> they were added after 10.4-1
<LocutusOfBorg> you mean the change in debian/budgie-desktop.gsettings-override?
 * LocutusOfBorg looks at http://launchpadlibrarian.net/335083873/budgie-desktop_10.4-0ubuntu3_10.4-1.diff.gz
<jbicha> yes
<LocutusOfBorg> ack, readding them as delta
<LocutusOfBorg> why isn't it in Debian? fossfreedom I asked you around 10 times, I was pretty sure the mentors package was "ready to be syncd"
<LocutusOfBorg> anyhow, uploaded, please check again :)
<fossfreedom> sorry - its late, and I'm tired :(  I'm confused with the discussion we are having.  What am I looking at?
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Artful Beta 1] (20170829) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Artful Beta 1] (20170829) has been added
<LocutusOfBorg> look at this upload https://launchpad.net/ubuntu/+source/budgie-desktop/10.4-1ubuntu1
<LocutusOfBorg> this is debian, plus one change in gsettings-override
 * LocutusOfBorg goes to sleep
<tsimonq2> flexiondotorg: Pong.
<fossfreedom> LocutusOfBorg, night.  I hadn't requested a re-upload any additional changes to Debian due to lots of other project priority matters.  sorry about that.  That sync/merge is fine.  cheers.
<fossfreedom> jbicha ... though I'm worried - mutter has been updated today but launchpad says "pending publication" - does this mean that budgie-desktop will compile against the older libmutter-0-dev rather than the newer libmutter-1-dev ?
<LocutusOfBorg> https://launchpadlibrarian.net/335085015/buildlog_ubuntu-artful-amd64.budgie-desktop_10.4-1ubuntu1_BUILDING.txt.gz
<LocutusOfBorg> buildlog shows -0-dev
<LocutusOfBorg> fortunately :)
<LocutusOfBorg> (so it can migrate)
<jbicha> fossfreedom: mutter is still in the new queue so it's fine
<fossfreedom> jbicha, ah - that explains it.  cheers.  I presume a no change rebuild to budgie-desktop is then required once mutter is then released from the new queue?
<jbicha> fossfreedom: I don't think a no-change rebuild will work because both mutters will be in the archive during the transition, but it will be ok :)
<fossfreedom> ta - fingers and toes have now been uncrossed
<rcj> slangasek, Laney: artful build is in progress.  I'll be checking on it throughout my evening
#ubuntu-release 2017-08-30
-queuebot:#ubuntu-release- New binary: nodejs [amd64] (artful-proposed/universe) [6.11.2~dfsg-3ubuntu1] (kubuntu)
<doko> slangasek: lapack, no I'll have a look later
-queuebot:#ubuntu-release- New binary: golang-golang-x-image [amd64] (artful-proposed/universe) [0.0~git20170523.0.426cfd8-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-golang-x-image [amd64] (artful-proposed) [0.0~git20170523.0.426cfd8-1]
-queuebot:#ubuntu-release- New: accepted node-watchpack [amd64] (artful-proposed) [1.3.1-2]
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.27.4~14.04 => 2.27.5~14.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.27.4 => 2.27.5] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (zesty-proposed/main) [2.27.4+17.04 => 2.27.5+17.04] (desktop-core, ubuntu-server)
<sil2100> flexiondotorg: hey! I have added ubuntustudio to Beta 1 as per e-mail request
<philroche> Laney: slangasek: artful serial 20170829 has been published http://cloud-images.ubuntu.com/artful/20170829/
-queuebot:#ubuntu-release- New binary: hugo [amd64] (artful-proposed/universe) [0.25.1-2] (no packageset)
<sil2100> Actually someone already updated the crontab earlier, but yeah
<flexiondotorg> sil2100 Thanks. I'll try and track down who on their team is driving the release.
<sil2100> flexiondotorg: for now I wrote Ross as the driver as her requested adding to Beta 1, but I guess that's not a rule, right?
<flexiondotorg> Ross looks like the right person. I'll get in touch with them :-)
<Laney> philroche: nice - do you know how they make it from there to ScalingStack?
<wgrant> Laney: They get automatically synced by glance-simplestreams-sync, probably hourly.
<Laney> wgrant: k, so I'll wait one hour before whinging
<wgrant> Laney: Which region?
<Laney> wgrant: Got distracted, sorry. lcy01 and lgw01 both seem to be missing artful, or is that me?
-queuebot:#ubuntu-release- Unapproved: sssd (xenial-proposed/main) [1.13.4-1ubuntu1.7 => 1.13.4-1ubuntu1.8] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: libqapt (xenial-proposed/universe) [3.0.2-0ubuntu1.1 => 3.0.2-0ubuntu1.2] (kubuntu)
<wgrant> Laney: The ubuntu-g-s-s on both might need to be reconfigured to include artful. I forget exactly what the current pattern is.
-queuebot:#ubuntu-release- Unapproved: libva (xenial-proposed/universe) [1.7.0-1 => 1.7.0-1ubuntu0.1] (kubuntu)
<tsimonq2> Could I please get an SRU team review on bug 1710993 as soon as reasonably possible?
<ubot5> bug 1710993 in lubuntu-meta (Ubuntu Xenial) "PulseAudio requirement breaks Firefox on ALSA-only systems after 55.0.1 update" [Critical,In progress] https://launchpad.net/bugs/1710993
<apw> tsimonq2, that looks like a resonable response to the problem to me; what are you hoping for here
<tsimonq2> apw: Someone to let it in to xenial-updates and to approve my MP to lubuntu.xenial
<tsimonq2> :P
<tsimonq2> apw: In my honest opinion as Lubuntu Release Manager, given the changes, I can justify an exemption to the 7 day rule.
-queuebot:#ubuntu-release- New sync: libdazzle (artful-proposed/primary) [3.25.91-1]
-queuebot:#ubuntu-release- New sync: template-glib (artful-proposed/primary) [3.25.3-1]
-queuebot:#ubuntu-release- New: accepted hugo [amd64] (artful-proposed) [0.25.1-2]
-queuebot:#ubuntu-release- Unapproved: gthumb (trusty-proposed/universe) [3:3.3.1.is.3.2.7-0ubuntu1 => 3:3.3.1.is.3.2.7-0ubuntu1.1] (desktop-extra, xubuntu)
<tsimonq2> Could an archive admin please look at nodejs in artful NEW?
<apw> tsimonq2, looking
<tsimonq2> apw: Thanks
<doko> tsimonq2, apw: already accepted
 * apw keeps the hell away from the button lest it get eaten
-queuebot:#ubuntu-release- New: accepted hunspell-dz [sync] (artful-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted mutter [amd64] (artful-proposed) [3.25.91-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mutter [armhf] (artful-proposed) [3.25.91-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mutter [ppc64el] (artful-proposed) [3.25.91-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted node-pako [amd64] (artful-proposed) [1.0.5+ds-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted template-glib [sync] (artful-proposed) [3.25.3-1]
-queuebot:#ubuntu-release- New: accepted libdazzle [sync] (artful-proposed) [3.25.91-1]
-queuebot:#ubuntu-release- New: accepted mutter [i386] (artful-proposed) [3.25.91-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted nodejs [amd64] (artful-proposed) [6.11.2~dfsg-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted mutter [arm64] (artful-proposed) [3.25.91-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mutter [s390x] (artful-proposed) [3.25.91-0ubuntu1]
<tsimonq2> Thanks apw :D
-queuebot:#ubuntu-release- New binary: hunspell-dz [amd64] (artful-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted hunspell-dz [amd64] (artful-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New binary: template-glib [ppc64el] (artful-proposed/universe) [3.25.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: template-glib [amd64] (artful-proposed/universe) [3.25.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: template-glib [s390x] (artful-proposed/universe) [3.25.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libdazzle [i386] (artful-proposed/universe) [3.25.91-1] (no packageset)
-queuebot:#ubuntu-release- New binary: template-glib [arm64] (artful-proposed/universe) [3.25.3-1] (no packageset)
-queuebot:#ubuntu-release- New: rejected libdazzle [source] (artful-proposed) [3.25.5-0ubuntu1]
-queuebot:#ubuntu-release- New binary: libdazzle [s390x] (artful-proposed/universe) [3.25.91-1] (no packageset)
-queuebot:#ubuntu-release- New binary: template-glib [i386] (artful-proposed/universe) [3.25.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libdazzle [amd64] (artful-proposed/universe) [3.25.91-1] (no packageset)
-queuebot:#ubuntu-release- New binary: template-glib [armhf] (artful-proposed/universe) [3.25.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libdazzle [arm64] (artful-proposed/universe) [3.25.91-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted template-glib [amd64] (artful-proposed) [3.25.3-1]
-queuebot:#ubuntu-release- New: accepted template-glib [armhf] (artful-proposed) [3.25.3-1]
-queuebot:#ubuntu-release- New: accepted template-glib [ppc64el] (artful-proposed) [3.25.3-1]
-queuebot:#ubuntu-release- New: accepted template-glib [arm64] (artful-proposed) [3.25.3-1]
-queuebot:#ubuntu-release- New: accepted template-glib [s390x] (artful-proposed) [3.25.3-1]
-queuebot:#ubuntu-release- New: accepted template-glib [i386] (artful-proposed) [3.25.3-1]
-queuebot:#ubuntu-release- New binary: libdazzle [armhf] (artful-proposed/universe) [3.25.91-1] (no packageset)
<acheronuk> cd
<apw> dvd
 * acheronuk ponders annoying focus stealing
<acheronuk> time to set that to high instead of medium
<tsimonq2> usb
-queuebot:#ubuntu-release- New: accepted libdazzle [amd64] (artful-proposed) [3.25.91-1]
-queuebot:#ubuntu-release- New: accepted libdazzle [armhf] (artful-proposed) [3.25.91-1]
-queuebot:#ubuntu-release- New: accepted libdazzle [s390x] (artful-proposed) [3.25.91-1]
-queuebot:#ubuntu-release- New: accepted libdazzle [arm64] (artful-proposed) [3.25.91-1]
-queuebot:#ubuntu-release- New: accepted libdazzle [i386] (artful-proposed) [3.25.91-1]
<tsimonq2> BD? Does anyone even use those? :P
-queuebot:#ubuntu-release- Unapproved: doomsday (zesty-proposed/universe) [1.15.8-3 => 1.15.8-3ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected gthumb [source] (trusty-proposed) [3:3.3.1.is.3.2.7-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: gthumb (trusty-proposed/universe) [3:3.3.1.is.3.2.7-0ubuntu1 => 3:3.3.1.is.3.2.7-0ubuntu1.1] (desktop-extra, xubuntu)
-queuebot:#ubuntu-release- Unapproved: rejected libqapt [source] (xenial-proposed) [3.0.2-0ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: rejected libva [source] (xenial-proposed) [1.7.0-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: rejected doomsday [source] (zesty-proposed) [1.15.8-3ubuntu0.1]
-queuebot:#ubuntu-release- New binary: node-browserify-zlib [amd64] (artful-proposed/universe) [0.1.4+20151015git49bcb7551a1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libqapt (xenial-proposed/universe) [3.0.2-0ubuntu1.1 => 3.0.2-0ubuntu1.2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: doomsday (zesty-proposed/universe) [1.15.8-3 => 1.15.8-3ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libva (xenial-proposed/universe) [1.7.0-1 => 1.7.0-1ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted gthumb [source] (trusty-proposed) [3:3.3.1.is.3.2.7-0ubuntu1.1]
-queuebot:#ubuntu-release- New sync: fonts-lohit-deva-marathi (artful-proposed/primary) [2.94.2-1]
-queuebot:#ubuntu-release- New sync: fonts-lohit-deva-nepali (artful-proposed/primary) [2.94.2-1]
-queuebot:#ubuntu-release- New sync: python-xapp (artful-proposed/primary) [1.0.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (zesty-proposed) [1:17.04.7]
-queuebot:#ubuntu-release- Unapproved: nut (trusty-proposed/main) [2.7.1-1ubuntu1.1 => 2.7.1-1ubuntu1.2] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected nut [source] (xenial-proposed) [2.7.2-4ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: rejected nut [source] (trusty-proposed) [2.7.1-1ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: nut (trusty-proposed/main) [2.7.1-1ubuntu1.1 => 2.7.1-1ubuntu1.2] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: nut (xenial-proposed/main) [2.7.2-4ubuntu1.1 => 2.7.2-4ubuntu1.2] (ubuntu-server)
<slangasek> heads up to those participating in beta1, ifupdown priority is being dropped now from important to optional, completing the netplan transition for 17.10; that means any respins are going to have ifupdown dropped, and use network-manager + networkd exclusively
<slangasek> if you would like a respin before beta-1 to get extra testing of this scenario, feel free (just give it ~30m for the publisher before triggering)
-queuebot:#ubuntu-release- New: accepted fonts-lohit-deva-marathi [sync] (artful-proposed) [2.94.2-1]
-queuebot:#ubuntu-release- New: accepted node-browserify-zlib [amd64] (artful-proposed) [0.1.4+20151015git49bcb7551a1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted fonts-lohit-deva-nepali [sync] (artful-proposed) [2.94.2-1]
-queuebot:#ubuntu-release- New: accepted python-xapp [sync] (artful-proposed) [1.0.1-1]
<tsimonq2> slangasek: Lubuntu is respinning now then
<slangasek> tsimonq2: you mean in 15 minutes, right? :)
<tsimonq2> slangasek: The build queue will take 30 minutes to get to building them :P
 * tsimonq2 's guess
<tsimonq2> long build queues today
<tsimonq2> But yeah, didn't read that part... I think we're safe though
-queuebot:#ubuntu-release- New binary: fonts-lohit-deva-marathi [amd64] (artful-proposed/none) [2.94.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-xapp [amd64] (artful-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fonts-lohit-deva-nepali [amd64] (artful-proposed/none) [2.94.2-1] (no packageset)
<tsimonq2> Meh, worst case scenario I just do another quick respin
<cjwatson> build queues> Oh, that's probably fixable.  Let me see.
<tsimonq2> slangasek: What version numbers should I be expecting for the images to pull in?
<slangasek> tsimonq2: you should be expecting no ifupdown pulled in at the bootstrap phase
<tsimonq2> ack
<slangasek> and ideally not at all
<tsimonq2> Sure, gotcha
<cyphermox> slangasek: oh, did you move it out of important already too?
<slangasek> cyphermox: just now, yes.  Is that ok?
<cyphermox> of course
<cyphermox> I noticed you mention it, that's all, very cool
 * cjwatson wonders if anyone here cares about https://rt.admin.canonical.com/Ticket/Display.html?id=105525
<cjwatson> (company-internal, but it's an upgrade to launchpad-buildd 148)
<cjwatson> does it need to be delayed until after beta 1, or is it OK to go ahead?
<cjwatson> changelog is the top block of http://bazaar.launchpad.net/~canonical-launchpad-branches/launchpad-buildd/trunk/view/head:/debian/changelog
<slangasek> cjwatson: the last line makes me pause and think it would be best to wait 24h
 * apw was all happy till that last line :)
<cjwatson> Right, so Friday morning?
<slangasek> cjwatson: even Thursday EOD should be fine; very low risk of us still respinning ISOs for beta-1 at that point
<cjwatson> Thursday EOD isn't fine by me because I want to be around for it
<cjwatson> so I've followed up saying Friday morning
<slangasek> ok :)
 * cjwatson doesn't want to rescue builders from the pub
<slangasek> ack
<apw> cjwatson, but that is such fun, using a touchscreen
 * ogra_ just doesnt let his builders go to the pub in the first place
<slangasek> that's why we have an AA team
<Odd_Bloke> To go to the pub?
<ogra_> +1
<cjwatson> I mean the builders are in a cloud, if they started running from the pub I'm not sure I'd know
-queuebot:#ubuntu-release- Unapproved: accepted lubuntu-meta [source] (xenial-proposed) [0.65.2]
<tsimonq2> Excellent
-queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop amd64 [Artful Beta 1] has been updated (20170830)
-queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop i386 [Artful Beta 1] has been updated (20170830)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Artful Beta 1] has been updated (20170830)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Artful Beta 1] has been updated (20170830)
-queuebot:#ubuntu-release- New: rejected template-glib [source] (artful-proposed) [3.25.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted fonts-lohit-deva-marathi [amd64] (artful-proposed) [2.94.2-1]
-queuebot:#ubuntu-release- New: accepted fonts-lohit-deva-nepali [amd64] (artful-proposed) [2.94.2-1]
-queuebot:#ubuntu-release- Unapproved: libc++ (xenial-proposed/universe) [3.7.0-1 => 3.7.0-1ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-130.179] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-94.117] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-130.179]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-94.117]
-queuebot:#ubuntu-release- Unapproved: lxd (trusty-backports/universe) [2.0.10-0ubuntu1~14.04.1 => 2.0.10-0ubuntu1~14.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected nplan [source] (xenial-proposed) [0.26~16.04.1]
-queuebot:#ubuntu-release- New binary: auto-multiple-choice [amd64] (artful-proposed/universe) [1.3.0-3ubuntu1] (no packageset)
<slangasek> jbicha: no love for the shotwell autopkgtests?
-queuebot:#ubuntu-release- New sync: jsonrpc-glib (artful-proposed/primary) [3.25.3-2]
<jbicha> slangasek: https://bugzilla.gnome.org/781802
<ubot5> Gnome bug 781802 in import "Ubuntu import autopkgtest fails with 0.26.1" [Major,New]
<jbicha> I don't have a camera
<jbicha> if we drop the ios patch, the autopkgtests pass
<slangasek> jbicha: so all that's needed is some sort of PTP-capable device?
<jbicha> and somebody to record the data so that the test passes, yes
<slangasek> jbicha: alright, well next time domestic plate tectonics exposes the old digital camera, I think I might be able to help with that
<tsimonq2> slangasek: This might be related to the DNS changes... https://lists.ubuntu.com/archives/lubuntu-devel/2017-August/001068.html
<slangasek> tsimonq2: it certainly might be.  for a bug report we would want to see the contents of /etc/netplan
<slangasek> tsimonq2: and since this was an alternate install, it would be useful to know what the state of the network was while the installer itself was running
<slangasek> and whether the problem is broadly reproducible
<tsimonq2> Ok
-queuebot:#ubuntu-release- New: accepted auto-multiple-choice [amd64] (artful-proposed) [1.3.0-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: fuse-umfuse-ext2 (trusty-proposed/universe) [0.4-1.1 => 0.4-1.1ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Artful Beta 1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Artful Beta 1] has been marked as ready
#ubuntu-release 2017-08-31
<xnox> slangasek, to get ocaml moving https://bugs.launchpad.net/ubuntu/+source/why/+bug/1714135
<ubot5> Ubuntu bug 1714135 in coq (Ubuntu) "drop coq/arm64 binaries from artful FTBFS" [High,Triaged]
-queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop i386 [Artful Beta 1] has been updated (20170831)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Artful Beta 1] has been updated (20170831)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Artful Beta 1] has been updated (20170831)
<slangasek> xnox: prooftree binary removal is problematic, it has a runtime but no buildtime dep on coq.  I'll remove, but coq either needs sorting soon on arm64 or prooftree will need something done to keep the binary from growing back
<doko> now looking at the source packages in the NEW queue ...
-queuebot:#ubuntu-release- New: accepted jsonrpc-glib [source] (artful-proposed) [3.25.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted python-xapp [amd64] (artful-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted jsonrpc-glib [sync] (artful-proposed) [3.25.3-2]
-queuebot:#ubuntu-release- New binary: jsonrpc-glib [amd64] (artful-proposed/none) [3.25.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: jsonrpc-glib [ppc64el] (artful-proposed/none) [3.25.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: jsonrpc-glib [ppc64el] (artful-proposed/none) [3.25.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: jsonrpc-glib [armhf] (artful-proposed/universe) [3.25.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: jsonrpc-glib [amd64] (artful-proposed/universe) [3.25.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: jsonrpc-glib [i386] (artful-proposed/universe) [3.25.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: jsonrpc-glib [i386] (artful-proposed/universe) [3.25.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: jsonrpc-glib [armhf] (artful-proposed/universe) [3.25.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: jsonrpc-glib [arm64] (artful-proposed/universe) [3.25.3-2] (no packageset)
<doko> calc-stats, really? a collection of trivial shell scripts?
-queuebot:#ubuntu-release- New binary: jsonrpc-glib [s390x] (artful-proposed/universe) [3.25.3-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted jsonrpc-glib [amd64] (artful-proposed) [3.25.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted jsonrpc-glib [i386] (artful-proposed) [3.25.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted jsonrpc-glib [amd64] (artful-proposed) [3.25.3-2]
-queuebot:#ubuntu-release- New: accepted jsonrpc-glib [armhf] (artful-proposed) [3.25.3-2]
-queuebot:#ubuntu-release- New: accepted jsonrpc-glib [ppc64el] (artful-proposed) [3.25.3-2]
-queuebot:#ubuntu-release- New: accepted jsonrpc-glib [armhf] (artful-proposed) [3.25.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted jsonrpc-glib [arm64] (artful-proposed) [3.25.3-2]
-queuebot:#ubuntu-release- New: accepted jsonrpc-glib [s390x] (artful-proposed) [3.25.3-2]
-queuebot:#ubuntu-release- New: accepted jsonrpc-glib [ppc64el] (artful-proposed) [3.25.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted jsonrpc-glib [i386] (artful-proposed) [3.25.3-2]
<doko> bdrung: rdma-core: Files: * Copyright: disclaimed
<doko> it's hard to tell which files are affected by this
<doko> bdrung: why is this package Ubuntu only? I see the ITP, but the package is not in Debian's new queue
<doko> kirkland: is there any rationale for uploading calc-stats? should it go to main? if yes, Python3 is the language of choice (unless you prefer go ;p)
-queuebot:#ubuntu-release- New: rejected rdma-core [source] (artful-proposed) [15~rc1+git20170821-0ubuntu1]
<slangasek> python3 is the language of choice for universe, not just for main ;) - and no, this is not targeted at main
<slangasek> xnox: ppx-deriving/arm64 also fun
-queuebot:#ubuntu-release- New: rejected caja-admin [source] (artful-proposed) [0.0.1-1~git1]
<doko> slangasek: do you know why unity-mail sits there for three months?
<LocutusOfBorg> hello, now that castxml is fixed, I did the trivial insighttoolkit4 merge, so we can again have the python bindings here
-queuebot:#ubuntu-release- New: accepted xchat-gnome [source] (artful-proposed) [1:0.30.0~git20141005.816798-0ubuntu10]
<LocutusOfBorg> please accept in case that new package
<slangasek> doko: I haven't looked at it at all
-queuebot:#ubuntu-release- New: accepted xfce4-statusnotifier-plugin [source] (artful-proposed) [0.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: xfce4-statusnotifier-plugin [ppc64el] (artful-proposed/none) [0.1.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: xfce4-statusnotifier-plugin [amd64] (artful-proposed/none) [0.1.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: xfce4-statusnotifier-plugin [i386] (artful-proposed/none) [0.1.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-gopherjs-gopherjs [amd64] (artful-proposed/universe) [0.0~git20170702.0.2b1d432-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xfce4-statusnotifier-plugin [arm64] (artful-proposed/none) [0.1.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-github-gopherjs-gopherjs [amd64] (artful-proposed) [0.0~git20170702.0.2b1d432-1]
-queuebot:#ubuntu-release- New binary: xfce4-statusnotifier-plugin [armhf] (artful-proposed/none) [0.1.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted plymouth-kcm [source] (artful-proposed) [5.10.4-0ubuntu1]
-queuebot:#ubuntu-release- New binary: xfce4-statusnotifier-plugin [s390x] (artful-proposed/none) [0.1.0-0ubuntu1] (no packageset)
<Ukikie> Thanks!
-queuebot:#ubuntu-release- New binary: plymouth-kcm [ppc64el] (artful-proposed/none) [5.10.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: plymouth-kcm [amd64] (artful-proposed/none) [5.10.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: plymouth-kcm [i386] (artful-proposed/none) [5.10.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted unity-mail [source] (artful-proposed) [1.7.5.1]
-queuebot:#ubuntu-release- New: accepted xfce4-statusnotifier-plugin [arm64] (artful-proposed) [0.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted xfce4-statusnotifier-plugin [i386] (artful-proposed) [0.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted xfce4-statusnotifier-plugin [s390x] (artful-proposed) [0.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted xfce4-statusnotifier-plugin [amd64] (artful-proposed) [0.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted xfce4-statusnotifier-plugin [ppc64el] (artful-proposed) [0.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted xfce4-statusnotifier-plugin [armhf] (artful-proposed) [0.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: plymouth-kcm [arm64] (artful-proposed/none) [5.10.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: plymouth-kcm [armhf] (artful-proposed/none) [5.10.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: plymouth-kcm [s390x] (artful-proposed/none) [5.10.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: unity-mail [amd64] (artful-proposed/none) [1.7.5.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal-kde [source] (artful-proposed) [5.10.4-0ubuntu1]
<doko> LocutusOfBorg: I don't see any castxml upload
-queuebot:#ubuntu-release- New: accepted plymouth-kcm [amd64] (artful-proposed) [5.10.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted plymouth-kcm [armhf] (artful-proposed) [5.10.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted plymouth-kcm [ppc64el] (artful-proposed) [5.10.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted unity-mail [amd64] (artful-proposed) [1.7.5.1]
-queuebot:#ubuntu-release- New: accepted plymouth-kcm [arm64] (artful-proposed) [5.10.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted plymouth-kcm [s390x] (artful-proposed) [5.10.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted plymouth-kcm [i386] (artful-proposed) [5.10.4-0ubuntu1]
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal-kde [amd64] (artful-proposed/none) [5.10.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal-kde [ppc64el] (artful-proposed/none) [5.10.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal-kde [i386] (artful-proposed/none) [5.10.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal-kde [arm64] (artful-proposed/none) [5.10.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal-kde [armhf] (artful-proposed/none) [5.10.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal-kde [s390x] (artful-proposed/none) [5.10.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal-kde [amd64] (artful-proposed) [5.10.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal-kde [armhf] (artful-proposed) [5.10.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal-kde [ppc64el] (artful-proposed) [5.10.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal-kde [arm64] (artful-proposed) [5.10.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal-kde [s390x] (artful-proposed) [5.10.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal-kde [i386] (artful-proposed) [5.10.4-0ubuntu1]
-queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop amd64 [Artful Beta 1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Artful Beta 1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Artful Beta 1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop i386 [Artful Beta 1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Artful Beta 1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Artful Beta 1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Artful Beta 1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Artful Beta 1] has been marked as ready
<ginggs> doko: from LocutusOfBorg "Fixed Castxml is already in artful since a week, it is insighttoolkit4 that is re-enabling the binding"
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Artful Beta 1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Artful Beta 1] has been marked as ready
-queuebot:#ubuntu-release- Packageset: Added linux-gcp to kernel in artful
-queuebot:#ubuntu-release- Packageset: Added linux-meta-gcp to kernel in artful
-queuebot:#ubuntu-release- Packageset: Added linux-gcp to kernel in xenial
-queuebot:#ubuntu-release- Packageset: Added linux-meta-gcp to kernel in xenial
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Artful Beta 1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Artful Beta 1] has been marked as ready
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (zesty-proposed) [2.27.5+17.04]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.27.5]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.27.5~14.04]
<apw> ^ regression fixes for snapd in -proposed
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (xenial-proposed/main) [0.122ubuntu8.8 => 0.122ubuntu8.9] (core)
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (xenial-proposed) [0.122ubuntu8.9]
-queuebot:#ubuntu-release- Unapproved: accepted powerpc-utils [source] (zesty-proposed) [1.3.2-1ubuntu3~17.04]
<xnox> slangasek, one more ocaml casualty https://bugs.launchpad.net/debian/+source/why/+bug/1714223
<ubot5> Ubuntu bug 1714223 in why (Ubuntu) "RM why FTBFS on most arches, removed from stable/testing" [High,Triaged]
-queuebot:#ubuntu-release- Unapproved: rejected docker.io [source] (xenial-proposed) [1.13.1-0ubuntu1~17.04.1]
<slashd> Good day sil2100, do you have some cycle today to look at releasing CUPS in xenial-updates ? It reaches the minimum aging in -proposed, verification has been done, .... note that there is 2 autopkgtest failures found, but based on my investigations they can safely be ignore (I have updated the SRU template under regression to add more details)
<sil2100> slashd: hey! Sure thing, will just finish this review and move on to releases
<slashd> sil2100, thanks
<xnox> slangasek, and this too... =( https://bugs.launchpad.net/ubuntu/+source/ocsigenserver/+bug/1714238
<ubot5> Ubuntu bug 1714238 in ppx-deriving (Ubuntu) "drop ppx-deriving/arm64 binaries from artful FTBFS" [High,Triaged]
<xnox> slangasek, http://people.canonical.com/~ubuntu-archive/transitions/html/ocaml.html looks nice; arm64 is b0rked thus dropping binaries there is the way to migrate the lot.
<xnox> and it is suspected that these are borken due to pie-by-default which we will not be reverting in the gcc toolchain and all of these are universe niche packages
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (xenial-proposed) [3.20.5-0ubuntu0.16.04.6]
<slashd> thanks a bunch sil2100 for releasing CUPS
<apw> s/bunch/lot/
<kirkland> doko: does not need to be in main, no
<kirkland> doko: doesn't need python either;  it's just shell :-)
<flexiondotorg> Rosco2: Hi
<flexiondotorg> sil2100: Rosco2 is the Ubuntu Studio release manager.
<sil2100> o/
<flexiondotorg> Rosco2: sil2100 is manage the image releases etc.
<Rosco2> Just doing my first installation test in VM now
<Rosco2> We will be a little late today - but don't let us stop you
<Rosco2> I will sing out if there is a big issue
<doko> kirkland: what is the package for in any case? I just see it as polluting the /usr/bin namespace
<sil2100> Rosco2: I guess we need to have all flavours tested before we start release
<doko> so the removal of the _fpectl extension in python seems to cause some issues ... I'll do some no-change uploads tomorrow once python3.6 is synced
<Rosco2> OK - but I have to go out in 15 minutes for a bit - release notes will be late
<slangasek> tsimonq2: were there any more reports of bad networking with the lubuntu beta1 alternate?
<flexiondotorg> Rosco2: How's it going?
<flocculant> flexiondotorg: tracker's looking a bit poorly for studio - will at least smoketest 32bit install for them
<flocculant> Rosco2: ^^
<flexiondotorg> flocculant: Thanks. I'm just finishing for the day, so will smoke test amd64.
<flocculant> looks like that's in progress
<flexiondotorg> Yeah, but Rosco2 said he had to go out.
<flocculant> right - just thought I would say :)
<flocculant> not the smallest iso in the world to grab ...
<Rosco2> My first install failed to install grub. Was already an older Artful in there.
<Rosco2> Will try installing to an empty disk
<flocculant> Rosco2: 2 minutes till I have iso - then I'll run 32bit install - unless you're ontop of it :)
<Rosco2> Sorry - I have not started to download 32bit
<flexiondotorg> Back in a bit....
<flocculant> Rosco2: ok - it's almost done now
<flocculant> done and marked on tracker
<sil2100> Please give me a sign once it's all green
<Rosco2> Just starting another Ubuntu Studio 64 bit install on an empty disk
<sil2100> I'm going out for a run right now, but I'll be back soon
<Rosco2> flocculant, thanks!
<flocculant> Rosco2: np
-queuebot:#ubuntu-release- New binary: polyorb [s390x] (artful-proposed/universe) [2.11~20140418-4] (no packageset)
-queuebot:#ubuntu-release- New binary: polyorb [ppc64el] (artful-proposed/universe) [2.11~20140418-4] (no packageset)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Artful Beta 1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Artful Beta 1] has been marked as ready
<Rosco2> flexiondotorg, thanks for the extra install test. My 2nd install onto an empty disk worked too. Marked as ready.
<Rosco2> Just about finished the release notes too
<Rosco2> sil2100, Done!
<Rosco2> Thanks all for the help - our team was missing today!
<sil2100> Excellent, let me settle down and proceed
<flexiondotorg> Rosco2: Nice one
<flexiondotorg> sil2100: I'm ready when you are.
-queuebot:#ubuntu-release- New binary: polyorb [amd64] (artful-proposed/universe) [2.11~20140418-4] (no packageset)
<sil2100> flexiondotorg: generating source images still, this supposedly takes a bit
<sil2100> Once that's done I start publishing
<flexiondotorg> Ok. I've got a draft announcement email ready.
<flexiondotorg> Sorry this is late for you. I was trying to get this sorted by far earlier in the day.
-queuebot:#ubuntu-release- New binary: polyorb [i386] (artful-proposed/universe) [2.11~20140418-4] (no packageset)
<sil2100> No worries, sorry it's taking so long, didn't know this step takes *this* much time
<flexiondotorg> Yeah, I don't know the steps but I do know it's lengthy
-queuebot:#ubuntu-release- Unapproved: wpa (xenial-proposed/main) [2.4-0ubuntu6 => 2.4-0ubuntu6.1] (core)
<bdmurray> slangasek: Could you confirm how often the pending SRU report is generated? and if its not gonna be for a while could you re-run it?
<flexiondotorg> sil2100: Is everything still whirring?
<sil2100> It finished \o/ Ok, let me move on to publishings, one moment
<flexiondotorg> Okies :-)
<sil2100> No idea how long this will take as it's my first time, I assume much less time ;p
-queuebot:#ubuntu-release- Unapproved: accepted nut [source] (trusty-proposed) [2.7.1-1ubuntu1.2]
<sil2100> Going smooth so far, should be done in some moments
<bdmurray> tsimonq2: Is bug 1674868 fixed in artful?
<ubot5> bug 1674868 in fuse-umfuse-ext2 (Ubuntu Trusty) "Fuse-ext2 deadlocks on creating symlinks" [High,Confirmed] https://launchpad.net/bugs/1674868
<slangasek> bdmurray: looks like the pending sru report is supposed to run twice an hour
<bdmurray> slangasek: Oh? I must have been thinking about the phased-updater then.
<slangasek> xnox: according to update-output, frama-c/i386 is going to block the ocaml migration, and that doesn't appear to be on your remove list.
<sil2100> flexiondotorg: aaaalmost there, small hiccup, slangasek is helping me out
 * flexiondotorg hovers finger over send
<sil2100> flexiondotorg: ok, I think it's... done!
-queuebot:#ubuntu-release- Unapproved: accepted nut [source] (xenial-proposed) [2.7.2-4ubuntu1.2]
<sil2100> Or wait
<flexiondotorg> I'll check the usual places...
<sil2100> hmm
-queuebot:#ubuntu-release- Unapproved: maas (trusty-proposed/main) [1.9.5+bzr4599-0ubuntu1~14.04.1 => 1.9.5+bzr4599-0ubuntu1~14.04.2] (ubuntu-server)
<flexiondotorg> Not quite done.
<sil2100> I guess we need to wait a bit still
<sil2100> Since I see it all good on nusakan but maybe it needs to propagate
 * sil2100 waits impatiently
<flexiondotorg> I see directories but no files. So it is coming....
 * flexiondotorg observes some files appearing...
<sil2100> flexiondotorg: slowly slowly!
<sil2100> I see lubuntu already
-queuebot:#ubuntu-release- Unapproved: accepted sssd [source] (xenial-proposed) [1.13.4-1ubuntu1.8]
<flexiondotorg> Mine has appeared.
<flexiondotorg> What is the measure of "it's finished"?
<flocculant> just after it not being finished I guess :D
<flexiondotorg> I don't know what finished looks like :-)
 * flexiondotorg awaits confirmation from sil2100 
<sil2100> Let me double check
<flexiondotorg> Nothing seeding from what I've tested.
<sil2100> flexiondotorg: looks like DONE
<flexiondotorg> sil2100: Can you confirm torrents?
<flexiondotorg> No peers.
<sil2100> Interesting
<flexiondotorg> Torrents just started to trickle.
<flexiondotorg> I think it is done now ;-)
<flexiondotorg> I'll send the email :-)
<sil2100> Phew
<sil2100> They took their sweet time then
<sil2100> I think it's time for me to re-enable the cronjobs
<sil2100> Done
<flexiondotorg> sil2100: Thanks for your help!
<flexiondotorg> Email sent.
<flexiondotorg> slangasek: Thanks for helping out.
<sil2100> flexiondotorg: thanks for driving this! And thank you for your patience, next time will be smoother ;)
<flexiondotorg> It always takes ages ;-)
<flexiondotorg> I bought wine.
<valorie> seeding all the beta torrents
<flexiondotorg> valorie: Me too :-)
-queuebot:#ubuntu-release- Unapproved: maas (xenial-proposed/main) [2.2.2-6099-g8751f91-0ubuntu1~16.04.1 => 2.2.3-6106-g314b2b2-0ubuntu1~16.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: maas (zesty-proposed/main) [2.2.2-6099-g8751f91-0ubuntu1~17.04.1 => 2.2.3-6106-g314b2b2-0ubuntu1~17.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: polyorb [arm64] (artful-proposed/universe) [2.11~20140418-4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted libqapt [source] (xenial-proposed) [3.0.2-0ubuntu1.2]
-queuebot:#ubuntu-release- New binary: polyorb [armhf] (artful-proposed/universe) [2.11~20140418-4] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-94.117~14.04.1] (kernel)
-queuebot:#ubuntu-release- Unapproved: accepted libva [source] (xenial-proposed) [1.7.0-1ubuntu0.1]
-queuebot:#ubuntu-release- New binary: insighttoolkit4 [i386] (artful-proposed/universe) [4.12.1-dfsg1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted uwsgi [source] (xenial-proposed) [2.0.12-5ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: accepted wpa [source] (xenial-proposed) [2.4-0ubuntu6.1]
-queuebot:#ubuntu-release- Unapproved: rejected docker.io [source] (xenial-proposed) [1.13.1-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected runc [source] (xenial-proposed) [1.0.0~rc2+docker1.13.1-0ubuntu1~17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted apparmor [source] (xenial-proposed) [2.10.95-0ubuntu2.7]
-queuebot:#ubuntu-release- Unapproved: accepted sbuild [source] (zesty-proposed) [0.71.0-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted neutron-lbaas-dashboard [source] (zesty-proposed) [2.0.0-0ubuntu1.1]
 * tsimonq2 yawns
<tsimonq2> slangasek: Sooo I remember seeing when the ISOs were first added that Alternates haven't been building since 8/22, then forgot when I sent you that email >_<
<tsimonq2> slangasek: But yeah, that's on my post-Beta todo list
<tsimonq2> slangasek: But Lubuntu won't have alternates for this point release
<tsimonq2> bdmurray: I'll look in a bit
<tsimonq2> (i.e. 4-5 hours)
 * tsimonq2 goes AFK for the aforementioned number of hours
<slangasek> tsimonq2: not building at all?
<slangasek> tsimonq2: I see alternate builds on the 27th and 28th
<slangasek> ah, build /attempts/; let's see
<slangasek> Missing debootstrap-required ifupdown
<slangasek> Missing debootstrap-required resolvconf
-queuebot:#ubuntu-release- Unapproved: accepted doomsday [source] (zesty-proposed) [1.15.8-3ubuntu0.1]
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Artful Beta 1] (20170831) has been added
<xnox> slangasek, i'm not imagining and you did ping me somewhere about ocaml stuff still stuck in something i have missed right?!
<slangasek> xnox: frama-c
<slangasek> xnox: ftbfs on i386, and rendered uninstallable by the coq migration, per update_output
<xnox> slangasek, it's "installable" meaning all arches are installable in -proposed, and i386 got built against release pocket *sigh*
<slangasek> xnox: rather, i386 ftbfs
<slangasek> I looked at the build log and then ran away again
<xnox> slangasek, i'm confused why it is building internal copy of libjemalloc when that is a stand-alone package in debian/ubuntu
<bdmurray> win 17
<slangasek> xnox: I wondered about that; but I also know jemalloc is out of date in Debian/Ubuntu
<slangasek> tsimonq2: lubuntu alternate image has built now; apparently your last respin after we talked about ifupdown may have happened too soon after the archive changes, or something?  it built fine now
-queuebot:#ubuntu-release- Unapproved: docker.io (xenial-proposed/universe) [1.12.6-0ubuntu1~16.04.1 => 1.13.1-0ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: runc (xenial-proposed/universe) [1.0.0~rc2+docker1.12.6-0ubuntu1~16.04.1 => 1.0.0~rc2+docker1.13.1-0ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: docker.io (zesty-proposed/universe) [1.12.6-0ubuntu4 => 1.13.1-0ubuntu1~17.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: runc (zesty-proposed/universe) [1.0.0~rc2+docker1.12.6-0ubuntu1 => 1.0.0~rc2+docker1.13.1-0ubuntu1~17.04.1] (no packageset)
<acheronuk> does it make sense to now test those alternates? at this late stage?
<acheronuk> or stay skipped until beta2 and get on with release?
<slangasek> they've missed beta1
<slangasek> someone might still like to test them and know whether they work
<acheronuk> slangasek: ok. I thought things were being delayed from the sound of it. no probs then :)
<rbalint> (release-team:) please take a look at this feature-freeze exception: LP: #1714019
<ubot5> Launchpad bug 1714019 in unattended-upgrades (Ubuntu) "Please merge unattended-upgrades 0.96 (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/1714019
<valorie> acheronuk: the beta 1 images were released a few hours ago
<valorie> you should read kubuntu-devel ML
<valorie> lol
<acheronuk> valorie: hehe. I'm catching up..... and dealing with pings wanting patches fixed. not got to emails yet
<valorie> hmmm
<valorie> should have sent.....
<acheronuk> hmmm. thunderbird silently crashed while I was away. that doesn't help. no my unread count is massive
<valorie> :(
<xnox> slangasek, looks like jemalloc fix in frama-c is a one liner
<slangasek> isn't that usually the way? :)
-queuebot:#ubuntu-release- Unapproved: systemd (zesty-proposed/main) [232-21ubuntu5 => 232-21ubuntu6] (core)
#ubuntu-release 2017-09-01
<xnox> or not, sigh.
<xnox> their atomics are broken on 32bit
<xnox> kill i386
<slangasek> doko: it seems the gnat-7 transition is still incomplete in artful-proposed; what are the rules for package naming wrt ABIs, in ada-space? e.g. is it reasonable for me to just take the patches from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872427 that do s/libanet1-dev/libanet2-dev/, s/libanet0.3.3/libanet0.3.4/?
<ubot5> Debian bug 872427 in src:anet "anet: please rebuild with gnat-7" [Normal,Open]
-queuebot:#ubuntu-release- New binary: freerdp2 [amd64] (artful-proposed/universe) [2.0.0~git20170725.1.1648deb+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: freerdp2 [ppc64el] (artful-proposed/universe) [2.0.0~git20170725.1.1648deb+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted freerdp2 [amd64] (artful-proposed) [2.0.0~git20170725.1.1648deb+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted polyorb [amd64] (artful-proposed) [2.11~20140418-4]
-queuebot:#ubuntu-release- New: accepted polyorb [armhf] (artful-proposed) [2.11~20140418-4]
-queuebot:#ubuntu-release- New: accepted polyorb [ppc64el] (artful-proposed) [2.11~20140418-4]
-queuebot:#ubuntu-release- New: accepted freerdp2 [ppc64el] (artful-proposed) [2.0.0~git20170725.1.1648deb+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted polyorb [i386] (artful-proposed) [2.11~20140418-4]
-queuebot:#ubuntu-release- New: accepted polyorb [arm64] (artful-proposed) [2.11~20140418-4]
-queuebot:#ubuntu-release- New: accepted polyorb [s390x] (artful-proposed) [2.11~20140418-4]
-queuebot:#ubuntu-release- New binary: freerdp2 [i386] (artful-proposed/universe) [2.0.0~git20170725.1.1648deb+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: freerdp2 [arm64] (artful-proposed/universe) [2.0.0~git20170725.1.1648deb+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: freerdp2 [armhf] (artful-proposed/universe) [2.0.0~git20170725.1.1648deb+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted freerdp2 [arm64] (artful-proposed) [2.0.0~git20170725.1.1648deb+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted freerdp2 [i386] (artful-proposed) [2.0.0~git20170725.1.1648deb+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted freerdp2 [armhf] (artful-proposed) [2.0.0~git20170725.1.1648deb+dfsg1-1]
-queuebot:#ubuntu-release- New binary: anet [ppc64el] (artful-proposed/universe) [0.3.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: anet [i386] (artful-proposed/universe) [0.3.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: anet [amd64] (artful-proposed/universe) [0.3.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: anet [arm64] (artful-proposed/universe) [0.3.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: anet [s390x] (artful-proposed/universe) [0.3.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: anet [armhf] (artful-proposed/universe) [0.3.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted anet [amd64] (artful-proposed) [0.3.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted anet [armhf] (artful-proposed) [0.3.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted anet [ppc64el] (artful-proposed) [0.3.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted anet [arm64] (artful-proposed) [0.3.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted anet [s390x] (artful-proposed) [0.3.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted anet [i386] (artful-proposed) [0.3.4-0ubuntu1]
-queuebot:#ubuntu-release- New binary: libalog [ppc64el] (artful-proposed/universe) [0.5.2-2ubuntu4] (no packageset)
<valorie> is the archive now open, or is the /topic accurate?
<slangasek> both
-queuebot:#ubuntu-release- New binary: libalog [arm64] (artful-proposed/universe) [0.5.2-2ubuntu4] (no packageset)
-queuebot:#ubuntu-release- New binary: libalog [s390x] (artful-proposed/universe) [0.5.2-2ubuntu4] (no packageset)
<slangasek> feature freeze doesn't mean the archive is closed
-queuebot:#ubuntu-release- New binary: libalog [armhf] (artful-proposed/universe) [0.5.2-2ubuntu4] (no packageset)
-queuebot:#ubuntu-release- New binary: libalog [amd64] (artful-proposed/universe) [0.5.2-2ubuntu4] (no packageset)
-queuebot:#ubuntu-release- New binary: libalog [i386] (artful-proposed/universe) [0.5.2-2ubuntu4] (no packageset)
<xnox> slangasek, $ apt install python python-numpy -> seems to fail in artful schroot with release & proposed enabled. And I am confused how that can be.
<xnox> ah
<xnox>  libpython2.7-stdlib : Breaks: python-numpy (< 1:1.12.1-3.1) but 1:1.12.1-3ubuntu2 is to be installed
-queuebot:#ubuntu-release- New: accepted libalog [amd64] (artful-proposed) [0.5.2-2ubuntu4]
-queuebot:#ubuntu-release- New: accepted libalog [armhf] (artful-proposed) [0.5.2-2ubuntu4]
-queuebot:#ubuntu-release- New: accepted libalog [ppc64el] (artful-proposed) [0.5.2-2ubuntu4]
-queuebot:#ubuntu-release- New: accepted libalog [arm64] (artful-proposed) [0.5.2-2ubuntu4]
-queuebot:#ubuntu-release- New: accepted libalog [s390x] (artful-proposed) [0.5.2-2ubuntu4]
-queuebot:#ubuntu-release- New: accepted libalog [i386] (artful-proposed) [0.5.2-2ubuntu4]
<tsimonq2> slangasek: soooo Alternate amd64 looks to be FTBFS...
<tsimonq2> bdmurray: Hey, any reason why kdecoration, ksshaskpass, and polkit-kde-agent-1 weren't released to zesty-updates as part of bug 1687444?
<ubot5> bug 1687444 in polkit-kde-agent-1 (Ubuntu Zesty) "Zesty SRU tracking bug for KDE's Plasma 5.9.5" [Undecided,Fix committed] https://launchpad.net/bugs/1687444
<acheronuk> tsimonq2: phased update halted: http://people.canonical.com/~ubuntu-archive/phased-updates.html
<tsimonq2> oh
<acheronuk> tsimonq2: forwarded you the emails I got
<tsimonq2> acheronuk: ack
<tsimonq2> thanks
<acheronuk> tsimonq2: oh, different packages. that is odd
 * acheronuk shouldn't even be awake
<acheronuk> tsimonq2: no idea on kdecoration, ksshaskpass, and polkit-kde-agent-1 then
<acheronuk> that SRU has been nothing but bother :/
<tsimonq2> acheronuk: Maybe it stops all packages with that bug marked as being fixed
<slangasek> tsimonq2: I don't see any evidence that the amd64 alternate is being built.  I've seen it get stuck that way before when trying to trigger from the iso tracker, I didn't manage to debug it then or now.  I'll trigger one manually on the server
<tsimonq2> slangasek: Alright.
<slangasek> grumble, what's with the huge pile of red under init-system-helpers
 * tsimonq2 scratches head
<tsimonq2> Why is nodejs not a valid candidate, Britney?
<slangasek> tsimonq2: 'test in progress'
<tsimonq2> All of the autopkgtests pass or are ignored failures...
<tsimonq2> slangasek: oh what where?
<slangasek> node-browserify-zlib/i386
<tsimonq2> Oh
<tsimonq2> meh :|
<slangasek> only 10 spots down in the queue currently
<tsimonq2> Ah ok
<tsimonq2> (well it's been in proposed for two days, you think it'd be done by now...)
<slangasek> it triggers autopkgtests for all the node modules
<slangasek> takes a bit to churn through them all
<tsimonq2> ic
<tsimonq2> ok
<tsimonq2> How often does Britney run? (i.e. what's the cron entry?)
<slangasek> it runs more or less constantly
<slangasek> the interval depends on how long a given run takes, rather than on the cron setting
<tsimonq2> ah ok
<tsimonq2> nodejs migrated \o/
<tsimonq2> (again, I merged from Debian after it migrated a few days ago)
<tsimonq2> slangasek: I'm borderline, would you consider merging this from Debian breaking Feature Freeze? https://tracker.debian.org/news/867092
<slangasek> tsimonq2: nothing in that changelog stands out to me as requiring an FFe
<tsimonq2> Alright, cool.
<doko> slangasek: the gnat changes look ok
<doko> xnox: as I mentioned here earlier. sorting out today the dropping of the _fpectl extension
 * slangasek grumbles at the nfs-utils racey autopkgtets
<slangasek> no, 'sync' does not guarantee that the nfs client sees the removal of a file :P
<tsimonq2> (it has to then read the changes that have been synced after the sync is done, maybe an API call or something before it tries to do it (what I assume by race condition)? idk what I'm talking about, carry on :P)
-queuebot:#ubuntu-release- Unapproved: stunnel4 (xenial-proposed/universe) [3:5.30-1 => 3:5.30-1ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: dbusada [i386] (artful-proposed/universe) [0.4.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: dbusada [ppc64el] (artful-proposed/universe) [0.4.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: dbusada [amd64] (artful-proposed/universe) [0.4.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: dbusada [arm64] (artful-proposed/universe) [0.4.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted dbusada [amd64] (artful-proposed) [0.4.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted dbusada [i386] (artful-proposed) [0.4.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted dbusada [arm64] (artful-proposed) [0.4.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted dbusada [ppc64el] (artful-proposed) [0.4.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: dbusada [armhf] (artful-proposed/universe) [0.4.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: dbusada [s390x] (artful-proposed/universe) [0.4.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted dbusada [armhf] (artful-proposed) [0.4.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted dbusada [s390x] (artful-proposed) [0.4.0-0ubuntu1]
 * tsimonq2 thinks package changelog urgency should have an effect on triggered autopkgtests in the queue...
<tsimonq2> (maybe it does and I'm not seeing it, idk)
<slangasek> it does not
<slangasek> we don't have very involved queue management of autopkgtests generally
-queuebot:#ubuntu-release- New: accepted insighttoolkit4 [i386] (artful-proposed) [4.12.1-dfsg1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-94.117~14.04.1]
-queuebot:#ubuntu-release- Unapproved: flashcache (zesty-proposed/universe) [3.1.3+git20150701-5 => 3.1.3+git20150701-5ubuntu0.17.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-toolchain-snapshot [s390x] (artful-proposed/universe) [1:6.0~svn311834-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-snapshot [s390x] (artful-proposed) [1:6.0~svn311834-2ubuntu1]
<cjwatson> upgrade to launchpad-buildd 148 in progress
 * apw holds his breath
<cjwatson> WCPGW
<cjwatson> I mean it's only a 6000+-line diff
<apw> heh, what indeed ...
-queuebot:#ubuntu-release- Unapproved: accepted flashcache [source] (zesty-proposed) [3.1.3+git20150701-5ubuntu0.17.04.1]
<LocutusOfBorg> slangasek, I'm going to upload dbusada in debian, with all the patches in the bug tracker
<LocutusOfBorg> it will go in new queue, and I'll sync after
<LocutusOfBorg> (after the transition is finished)
<doko> LocutusOfBorg: please ping the debian-ada ML
<LocutusOfBorg> I'm uploading in deferred/10
<LocutusOfBorg> and pinging then
<LocutusOfBorg> done, replied on the bug and cc'd debian-ada
<cjwatson> We're rolling back launchpad-buildd 148 due to some unexpected networking issues with LXD
<LocutusOfBorg> doko, do you plan to promote llvm-5.0 to main?
<doko> when it would build ...
<LocutusOfBorg> oh already done
<LocutusOfBorg> yep, I'm looking at the failures
<LocutusOfBorg> hopefully sylvestre will sort them out soon
<LocutusOfBorg> lets see gnat migrate in some minutes
<doko> gnat still has some failing autopkg tests
<LocutusOfBorg> doko, where
<doko> https://launchpad.net/ubuntu/+source/gnat
<doko> http://people.canonical.com/~ubuntu-archive/proposed-migration/artful/update_excuses.html
<LocutusOfBorg> yes, but all the failures are fixed
<LocutusOfBorg> just running autopkgtests queues are full
<LocutusOfBorg> I already retried them
<LocutusOfBorg> unless you know something I'm not aware of
<LocutusOfBorg> llvm-* uploaded
<LocutusOfBorg> doko, why did you break borgbackup? :p bugs.debian.org/873921
<doko> LocutusOfBorg: why do you reassign without rebuilding? it will stay broken this way
<LocutusOfBorg> how can I rebuild it since pybuild is broken?
<LocutusOfBorg> I: pybuild base:184: python3.5 setup.py config
<LocutusOfBorg> ImportError: /usr/lib/python3/dist-packages/Cython/Compiler/Code.cpython-35m-x86_64-linux-gnu.so: undefined symbol: PyFPE_jbuf
<doko> because you don't use the built version
<LocutusOfBorg> sure, no dinstall yet
<doko> buildds use incoming, not just since today
<LocutusOfBorg> I did test rebuild on my laptop, I don't use builders as testbed
<infinity> LocutusOfBorg: http://incoming.debian.org/debian-buildd/ is open to the public, you can add it to your unstable/experimental build chroots sources.list.
<LocutusOfBorg> infinity, but if cython is broken, 100 reverse-dependencies needs rebuilds/binNMUs why the hell should I do a sourceful NMU?
<LocutusOfBorg> I can do it in Ubuntu, but we don't do no change sourceful uploads in Debian
<LocutusOfBorg> I know how to grab incoming, but the point is another, not changing SONAME breaks partial upgrades
<LocutusOfBorg> I really dislike it :p
<infinity> LocutusOfBorg: I was only responding to your issues that your local test rebuild wouldn't match what would happen in the archive, not what you should or shouldn't upload.
<LocutusOfBorg> infinity, yes, the answer was not directed to you :) thanks!
<LocutusOfBorg> btw, what the hell happened to ghostscript? not installable on ppc64el and s390x, breaking ettercap build-dependencies... can anybody please help me?
<doko> so where are these 100 reverse-dependencies breaking?
<LocutusOfBorg> reverse-depends -r artful -b src:cython |wc -l
<LocutusOfBorg> 235
<infinity> LocutusOfBorg: Probably just poor timing of arch:all and arch:any binaries being published.
<doko> and every one of these referencing the _PyFPE symbol?
<LocutusOfBorg> sorry doko I had a long week (see debian private), I'm just back to work, please do the NMUs/rebuilds as necessary, I have some pressing stuff to do now
<xnox> doko, i think we simply want cython to migrate soon
<doko> xnox: tell that the autopkg testers ... current tests are all green
<doko> python-numpy autopkg tests might be a problem
<xnox> slangasek, math.c fails to compile with comments (-C -O2) on i386 only. hence i think this is a valid reason to just kill i386. =) </har har>
<xnox> https://bugs.launchpad.net/ubuntu/+source/jemalloc/+bug/1714514
<ubot5> Ubuntu bug 1714514 in glibc (Ubuntu) "math.c broken on i386, when compiling with -O2 -C" [High,Triaged]
<LocutusOfBorg> doko, that symbol is used not only by borgbackup
<LocutusOfBorg> curl -s https://codesearch.debian.net/results/8896aabe2a135a21/packages.json | jq -r '.Packages[]' |wc -l reports 43
<LocutusOfBorg> https://codesearch.debian.net/search?q=PyFPE&perpkg=1
<infinity> xnox: Why on earth would anyone expect -C to do reasonable things?
<xnox> infinity, it seems like they do annotations in comments and preserve them and then do instrumentation with it. it sounds and looks crazy.
<xnox> infinity, and something is borked in the i386 code path for it.
<xnox> i've touched frama-c before, and I do remember drinking cider afterwords.
<doko> LocutusOfBorg: your "analysis" is flawed. See Include/pyfpe.h
<doko> xnox: send a diff compared to GCC 6, and we can forward it
<doko> in any case, we can find these with the next test rebuild
<LocutusOfBorg> I don't understand sorry, but I trust you doing the needed stuff to make things good again
<doko> if it was a long week, end it early ;-)
<LocutusOfBorg> :-)
-queuebot:#ubuntu-release- Unapproved: nova (zesty-proposed/main) [2:15.0.6-0ubuntu1 => 2:15.0.6-0ubuntu1.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New binary: llvm-toolchain-snapshot [i386] (artful-proposed/universe) [1:6.0~svn311834-2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: nova (xenial-proposed/main) [2:13.1.4-0ubuntu3 => 2:13.1.4-0ubuntu4] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New sync: hyperlink (artful-proposed/primary) [17.3.1-2]
-queuebot:#ubuntu-release- New: accepted hyperlink [sync] (artful-proposed) [17.3.1-2]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-snapshot [i386] (artful-proposed) [1:6.0~svn311834-2ubuntu2]
-queuebot:#ubuntu-release- New binary: hyperlink [amd64] (artful-proposed/none) [17.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted hyperlink [amd64] (artful-proposed) [17.3.1-2]
-queuebot:#ubuntu-release- New sync: caja-admin (artful-proposed/primary) [0.0.1-1]
-queuebot:#ubuntu-release- New sync: caja-rename (artful-proposed/primary) [17.3.28~bzr14+repack1-2]
<jbicha> doko: ^ since you rejected the last caja-admin upload yesterday
<jbicha> I don't think a FFe is required for caja-admin since it was in the new queue before Feature Freeze
<jbicha> Debian FTP Team was ok with those being Python2; the Debian and Ubuntu MATE devs are pushing MATE to convert more stuff away from python2
<jbicha> it's needed to replace caja-gksu (from caja-extensions source)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.10.0-34.38~16.04.1] (kernel)
-queuebot:#ubuntu-release- Unapproved: neutron (xenial-proposed/main) [2:8.4.0-0ubuntu4 => 2:8.4.0-0ubuntu5] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted python-certbot-apache [source] (xenial-proposed) [0.14.2-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- New: accepted python-certbot [source] (xenial-proposed) [0.14.2-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- New: accepted python-certbot-nginx [source] (xenial-proposed) [0.14.2-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- New binary: python-certbot [amd64] (xenial-proposed/none) [0.14.2-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-letsencrypt [source] (xenial-proposed) [0.4.1-1ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted python-letsencrypt-apache [source] (xenial-proposed) [0.4.1-1ubuntu0.16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.10.0-34.38~16.04.1]
-queuebot:#ubuntu-release- New binary: node-foreground-child [amd64] (artful-proposed/universe) [1.5.6-3] (no packageset)
<slangasek> someone want to fix the pcs autopkgtest to not freak out about a proxy being set in the environment?
<slangasek> (that would help ruby-json and python2.7 be migratable)
<xnox> doko, i don't think it is gcc-6 vs 7 related; as gcc-6 -std=gnu11 -C -O2 also bombs out in a same manner. -std=c11 does not.
<xnox> doko, so will bisect math.h to possibly locate when/where incompatibility with -O2 -C gnu11 started
<xnox> slangasek, enough of ocaml migrated right? there are some dubious NEW things
<slangasek> xnox: it migrated? hurray!
<xnox> slangasek, well check if you are happy with things. cause you said before "too much of proposed is ocaml". not sure if enough of it is resolved.
<xnox> 19 packages migrated together
<slangasek> xnox: yes, the remaining stuff in -proposed seems to be just leaf packages that are stuck
<slangasek>     * amd64: adabrowse, adacgi3, gnat-gps, libadasockets6-dev
<slangasek> four packages left to clear gnat 7
-queuebot:#ubuntu-release- New binary: adacgi [ppc64el] (artful-proposed/universe) [1.6-19.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: adacgi [amd64] (artful-proposed/universe) [1.6-19.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: adacgi [armhf] (artful-proposed/universe) [1.6-19.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: adacgi [arm64] (artful-proposed/universe) [1.6-19.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: adacgi [s390x] (artful-proposed/universe) [1.6-19.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: adacgi [i386] (artful-proposed/universe) [1.6-19.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted adacgi [amd64] (artful-proposed) [1.6-19.1ubuntu1]
-queuebot:#ubuntu-release- New: accepted adacgi [armhf] (artful-proposed) [1.6-19.1ubuntu1]
-queuebot:#ubuntu-release- New: accepted adacgi [s390x] (artful-proposed) [1.6-19.1ubuntu1]
-queuebot:#ubuntu-release- New: accepted adacgi [arm64] (artful-proposed) [1.6-19.1ubuntu1]
-queuebot:#ubuntu-release- New: accepted adacgi [ppc64el] (artful-proposed) [1.6-19.1ubuntu1]
-queuebot:#ubuntu-release- New: accepted adacgi [i386] (artful-proposed) [1.6-19.1ubuntu1]
<xnox> slangasek, one new language per release. I've never done ocaml before, so i'm not touching ada.
<slangasek> :)
<tsimonq2> Can someone please reject fuse-umfuse-ext2 from Trusty Unapproved?
<LocutusOfBorg> slangasek, I did sync adasockets from experimental
<LocutusOfBorg> and uploading gnat-gps
<LocutusOfBorg> this should (modulo somebody accepting from new queue) finally make things migrate
<slangasek> LocutusOfBorg: oh excellent, I ignored the problems long enough that they've gone away
<slangasek> LocutusOfBorg: thanks!
<LocutusOfBorg> :) thanks to you for caring and pushing the transition
<LocutusOfBorg> I want now to push the changes in debian too
<slangasek> LocutusOfBorg: you've gotten gnat-gps to build?  I kept running into one build failure or another (the upload I did was a mis-upload)
<LocutusOfBorg> slangasek, I did merge it from unstable
<LocutusOfBorg> there was a new release
<LocutusOfBorg> did you forget to check unstable? :)
<slangasek> apparently so
<slangasek> I only checked for open bugs, which is where I found the patches for most of them ;)
-queuebot:#ubuntu-release- New binary: adasockets [ppc64el] (artful-proposed/universe) [1.10.1-0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: adasockets [arm64] (artful-proposed/universe) [1.10.1-0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: adasockets [s390x] (artful-proposed/universe) [1.10.1-0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: adasockets [armhf] (artful-proposed/universe) [1.10.1-0.1] (no packageset)
<LocutusOfBorg> I honestly didn't check to build, it takes one hour or so
<LocutusOfBorg> but I'm mostly sure it will build correctly, the new release is the usual "gnat-7 release"
-queuebot:#ubuntu-release- New: accepted adasockets [arm64] (artful-proposed) [1.10.1-0.1]
-queuebot:#ubuntu-release- New: accepted adasockets [ppc64el] (artful-proposed) [1.10.1-0.1]
<LocutusOfBorg> in case, tomorrow morning I'll fixup
-queuebot:#ubuntu-release- New binary: adasockets [amd64] (artful-proposed/universe) [1.10.1-0.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted adasockets [armhf] (artful-proposed) [1.10.1-0.1]
-queuebot:#ubuntu-release- New: accepted adasockets [s390x] (artful-proposed) [1.10.1-0.1]
-queuebot:#ubuntu-release- New: accepted adasockets [amd64] (artful-proposed) [1.10.1-0.1]
#ubuntu-release 2017-09-02
-queuebot:#ubuntu-release- New sync: html5-parser (artful-proposed/primary) [0.4.3-1]
 * tsimonq2 still needs a reject on fuse-umfuse-ext2 in Trusty queue
<slangasek> tsimonq2: hi, what was the reason for rejecting?
<tsimonq2> slangasek: Changelog is wrong
<slangasek> tsimonq2: so you're reuploading with a fixed changelog?"
<tsimonq2> slangasek: I want to SRU fixes for Xenial, Zesty, and upload to Artful, and the same revision is in all of those
<tsimonq2> slangasek: Yep
<slangasek> ok
-queuebot:#ubuntu-release- Unapproved: rejected fuse-umfuse-ext2 [source] (trusty-proposed) [0.4-1.1ubuntu0.1]
<tsimonq2> slangasek: Thanks
-queuebot:#ubuntu-release- Unapproved: fuse-umfuse-ext2 (trusty-proposed/universe) [0.4-1.1 => 0.4-1.1ubuntu0.14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fuse-umfuse-ext2 (zesty-proposed/universe) [0.4-1.1 => 0.4-1.1ubuntu0.17.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fuse-umfuse-ext2 (xenial-proposed/universe) [0.4-1.1 => 0.4-1.1ubuntu0.16.04.1] (no packageset)
<acheronuk> morning. does feature freeze inhibit me getting some old obsolete plasma4/kde4 stuff removed from artful? I mean really broken pointless stuff like 3rd party plasma desktop widgets for plasma 4 which can't possibly work with now plasma 5, and have no new versions
<tsimonq2> I don't see anything prohibiting that.
<acheronuk> neither do I, but better to ask before I start writing bugs and subbing people/teams
<tsimonq2> acheronuk: The same people probably approve FFes :P
<acheronuk> so what?
 * tsimonq2 shrugs
<acheronuk> I know I'm asking a question that I'm 99% sure of the answer, but I've had 1%s bite be on the a*** before
<tsimonq2> ok
<tsimonq2> That's fair.
<slangasek> acheronuk: if the rationale is clear enough for the removal bug, I generally wouldn't expect a formal FFe process around that
<acheronuk> slangasek: it would be. not going to attack everything on 'reverse-depends libplasma3', just the truly broken and pointless
<slangasek> fwiw I'm going to go ahead and dump all the glibc-triggered autopkgtests from the queue now; there are other things for the runners to be working on that's more interesting, and glibc 2.24 is going to wind up being superseded soon anyway
<slangasek> if it comes to it they can be retried after python have a chance to get through
<slangasek> Laney: I'm noticing some problems with ppc64el autopkgtests hitting the network when they weren't having that problem before (snapd; init-system-helpers).  have you heard of any proxy issues from bos01?
<Laney> slangasek: nope, I'd usually check IS channels for chatter about an issue like that and if I don't find any then file a ticket
<jbicha> acheronuk: many archive removals happen in the final days of the release cycle
-queuebot:#ubuntu-release- Unapproved: gnutls28 (zesty-proposed/main) [3.5.6-4ubuntu4.2 => 3.5.6-4ubuntu4.3] (core)
-queuebot:#ubuntu-release- New binary: linux [s390x] (artful-proposed/main) [4.12.0-13.14] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (artful-proposed/main) [4.12.0-13.14] (core, kernel)
<LocutusOfBorg> slangasek, mysqldb is in main... can we drop this delta? https://launchpad.net/ubuntu/+source/python-django/1:1.11.4-1ubuntu1
<jbicha> LocutusOfBorg: you need to talk to the Server team about that but I believe they intentionally want to use pymysql by default
<LocutusOfBorg> IIRC we dropped that delta a while ago on other packages already
-queuebot:#ubuntu-release- New binary: linux [arm64] (artful-proposed/main) [4.12.0-13.14] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [armhf] (artful-proposed/main) [4.12.0-13.14] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [i386] (artful-proposed/main) [4.12.0-13.14] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [amd64] (artful-proposed/main) [4.12.0-13.14] (core, kernel)
#ubuntu-release 2017-09-03
-queuebot:#ubuntu-release- New sync: golang-1.9 (artful-proposed/primary) [1.9-1]
-queuebot:#ubuntu-release- New: accepted golang-1.9 [sync] (artful-proposed) [1.9-1]
-queuebot:#ubuntu-release- New: accepted node-foreground-child [amd64] (artful-proposed) [1.5.6-3]
-queuebot:#ubuntu-release- New: accepted html5-parser [sync] (artful-proposed) [0.4.3-1]
-queuebot:#ubuntu-release- New binary: html5-parser [ppc64el] (artful-proposed/universe) [0.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: html5-parser [amd64] (artful-proposed/universe) [0.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: html5-parser [s390x] (artful-proposed/universe) [0.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: html5-parser [i386] (artful-proposed/universe) [0.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: html5-parser [arm64] (artful-proposed/universe) [0.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: html5-parser [armhf] (artful-proposed/universe) [0.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-1.9 [s390x] (artful-proposed/universe) [1.9-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted html5-parser [amd64] (artful-proposed) [0.4.3-1]
-queuebot:#ubuntu-release- New: accepted html5-parser [armhf] (artful-proposed) [0.4.3-1]
-queuebot:#ubuntu-release- New: accepted html5-parser [ppc64el] (artful-proposed) [0.4.3-1]
-queuebot:#ubuntu-release- New: accepted html5-parser [arm64] (artful-proposed) [0.4.3-1]
-queuebot:#ubuntu-release- New: accepted html5-parser [s390x] (artful-proposed) [0.4.3-1]
-queuebot:#ubuntu-release- New: accepted html5-parser [i386] (artful-proposed) [0.4.3-1]
-queuebot:#ubuntu-release- New binary: golang-1.9 [i386] (artful-proposed/universe) [1.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-1.9 [amd64] (artful-proposed/universe) [1.9-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-1.9 [amd64] (artful-proposed) [1.9-1]
-queuebot:#ubuntu-release- New: accepted golang-1.9 [s390x] (artful-proposed) [1.9-1]
-queuebot:#ubuntu-release- New: accepted golang-1.9 [i386] (artful-proposed) [1.9-1]
-queuebot:#ubuntu-release- New binary: golang-1.9 [arm64] (artful-proposed/universe) [1.9-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-1.9 [arm64] (artful-proposed) [1.9-1]
-queuebot:#ubuntu-release- New: accepted linux [amd64] (artful-proposed) [4.12.0-13.14]
-queuebot:#ubuntu-release- New: accepted linux [armhf] (artful-proposed) [4.12.0-13.14]
-queuebot:#ubuntu-release- New: accepted linux [ppc64el] (artful-proposed) [4.12.0-13.14]
-queuebot:#ubuntu-release- New: accepted linux [arm64] (artful-proposed) [4.12.0-13.14]
-queuebot:#ubuntu-release- New: accepted linux [s390x] (artful-proposed) [4.12.0-13.14]
-queuebot:#ubuntu-release- New: accepted linux [i386] (artful-proposed) [4.12.0-13.14]
<LocutusOfBorg> hello can anybody please hint kcrash/i386 kcrash/amd64 and kwin/i386 please?
<LocutusOfBorg> they are regressed in release, and blocking abi-compliance-checker
<LocutusOfBorg> maybe kwin works, test is just flaky
<tsimonq2> acheronuk | clivejo: ^^^^
<tsimonq2> LocutusOfBorg: They know well which tests are flaky and which tests actually work :P
<acheronuk> kwin is usually all flake
<LocutusOfBorg> lots of "k*" is now in unstable
<LocutusOfBorg> what about a big sync?
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (artful-proposed/main) [4.12.0-13.14] (core, kernel)
<tsimonq2> LocutusOfBorg: Kubuntu merges from Debian at the beginning of each cycle
<tsimonq2> It's easier to do it that way
<tsimonq2> Please don't sync
<tsimonq2> (even if it's not, it's Kubuntu policy)
<acheronuk> yep. priority is maybe a FFE on some thing, and getting the rest working smoothly
<acheronuk> and for k* apps, there is some stuff we would need to update our tooling to cope with. direct syncs or even merges right now would be huge borkage
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (artful-proposed) [4.12.0-13.14]
-queuebot:#ubuntu-release- New binary: libjpeg-turbo [amd64] (artful-proposed/main) [1.5.1-0ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: libjpeg-turbo [ppc64el] (artful-proposed/main) [1.5.1-0ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: libjpeg-turbo [i386] (artful-proposed/main) [1.5.1-0ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: libjpeg-turbo [s390x] (artful-proposed/main) [1.5.1-0ubuntu2] (core)
<LocutusOfBorg> please accept it ^^ we forgot to have a development package, this unblocks dcm2niix and probably others
-queuebot:#ubuntu-release- New binary: libjpeg-turbo [arm64] (artful-proposed/main) [1.5.1-0ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: libjpeg-turbo [armhf] (artful-proposed/main) [1.5.1-0ubuntu2] (core)
<doko> LocutusOfBorg: why is this necessary? why can't dcm2niix use the jpeg headers?
<tsimonq2> Anyone know what's going on with the s390x autopkgtester?
<tsimonq2> Doesn't look like the queues have not been moving for several hours
<LocutusOfBorg> doko, it doesn't work with jpeg, it looks for that library
<LocutusOfBorg> what is the purpose of providing a .so.foo without the .so symlink?
<LocutusOfBorg> btw for 18.04 I really would like to sync that libjpeg with Debian...
<LocutusOfBorg> slangasek, please update the kcrash hint? force-badtest kcrash/5.37.0-0ubuntu1/ppc64el
<LocutusOfBorg> adding amd64 and i386 would be lovely
<jbicha> LocutusOfBorg: see LP: #1419267 LP: #1056566
<ubot5> Launchpad bug 1419267 in libjpeg-turbo (Ubuntu) "libjpegturbo.so missing from -dev package" [Medium,Confirmed] https://launchpad.net/bugs/1419267
<ubot5> Launchpad bug 1056566 in libjpeg-turbo (Ubuntu) "Missing pkgconfig file" [Undecided,Confirmed] https://launchpad.net/bugs/1056566
<slangasek> LocutusOfBorg: kcrash hint updated
<LocutusOfBorg> ta
<LocutusOfBorg> jbicha, I would say we shoudl close them?
<slangasek> LocutusOfBorg: the jpeg libraries are very divergent between Ubuntu and Debian, and I am not comfortable making a change to the set of -dev packages provided post-FF when this might result in changes to which version is selected at build time on a no-change rebuild.
<slangasek> LocutusOfBorg: so please revert this change, which is not a matter of "forgetting" the dev package, and maybe come with a complete plan for closing the delta when 18.04 opens?
<LocutusOfBorg> slangasek, sorry, I don't get it
<LocutusOfBorg> let me explain, this wasn't installed
<LocutusOfBorg> so not technically usable, and it has only one reverse-dependency
<LocutusOfBorg> how can adding a package make things worse?
<LocutusOfBorg> nobody should use it right now
<slangasek> LocutusOfBorg: that's the only reference to libturbojpeg0-dev, or anything that libturbojpeg0-dev provides, anywhere in the archive?
<LocutusOfBorg> reverse-depends -r artful -b libturbojpeg0-dev
<LocutusOfBorg> reverse-depends: Error: <p>Package not published in specified release</p>
<slangasek> that's not how you check
<LocutusOfBorg> reverse-depends -r sid -b libturbojpeg0-devReverse-Build-Depends
<LocutusOfBorg> =====================
<LocutusOfBorg> * dcm2niix
<slangasek>  Provides: libturbojpeg-dev
<LocutusOfBorg> https://codesearch.debian.net/search?q=libturbojpeg0-dev
<LocutusOfBorg> https://codesearch.debian.net/search?q=libturbojpeg-dev
<LocutusOfBorg> I still say nothing, unless my checks are wrong
<slangasek> for completeness you should check directly against the artful sources; but ok, yes, I don't find any other references there
<slangasek> $ grep-dctrl -sPackage -FBuild-Depends,Build-Depends-Indep libturbojpeg /var/lib/apt/lists/*artful*Sources
<slangasek> Package: dcm2niix
<slangasek> $
<LocutusOfBorg> I don't know about an artful "codesearch.ubuntu.com" :)
<LocutusOfBorg> ta
<slangasek> no, but if you're uploading packages to artful it's your responsibility to have an artful environment to check against
<slangasek> anyway, turns out this is fine; the set of jpeg packages is a disaster in Debian and it's a different disaster in Ubuntu because of the delta, but neither of those is a reason to block this particular binary package from being in
<LocutusOfBorg> well, I thought reverse-depends was enough, together with codesearch
<LocutusOfBorg> and I agree, however I would like to have the same disaster as in Debian for 18.04
<LocutusOfBorg> the package might be syncable with a small no-change transition
<slangasek> right, except that reverse-depends doesn't return results for unknown packages
-queuebot:#ubuntu-release- New: accepted libjpeg-turbo [amd64] (artful-proposed) [1.5.1-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted libjpeg-turbo [armhf] (artful-proposed) [1.5.1-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted libjpeg-turbo [ppc64el] (artful-proposed) [1.5.1-0ubuntu2]
<LocutusOfBorg> ta!
-queuebot:#ubuntu-release- New: accepted libjpeg-turbo [arm64] (artful-proposed) [1.5.1-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted libjpeg-turbo [s390x] (artful-proposed) [1.5.1-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted libjpeg-turbo [i386] (artful-proposed) [1.5.1-0ubuntu2]
<LocutusOfBorg> I will also have a look at updating to 1.5.2
<LocutusOfBorg> but I didn't look if it has new features or not
-queuebot:#ubuntu-release- New binary: golang-github-go-macaron-cache [amd64] (artful-proposed/universe) [0.0~git20151013.0.5617353-1] (no packageset)
<LocutusOfBorg> s390x, why you not running autopkgtests?
<tsimonq2> LocutusOfBorg: I asked 11 hours ago. It hasn't been running autopkgtests for probably 16
<acheronuk> maybe it's seem sense?
<acheronuk> *seen
<tsimonq2> *since too? :P
<tsimonq2> s/11/7/
<acheronuk> no, I meant sense
<tsimonq2> Oh?
<acheronuk> if I was s390x, I would give up on them too
<tsimonq2> LOL
<tsimonq2> Ohhhhhhhhhh
<tsimonq2> XD
-queuebot:#ubuntu-release- New: accepted golang-github-go-macaron-cache [amd64] (artful-proposed) [0.0~git20151013.0.5617353-1]
#ubuntu-release 2018-08-27
<tsimonq2> infinity, slangasek: Can haz merge? :) https://code.launchpad.net/~wxl/debian-cd/ubuntu/+merge/353762
<tsimonq2> wxl's not wrong. XD
<slangasek> tsimonq2: done
 * slangasek frowns at tests being queued in the huge queue that shouldn't be
<tsimonq2> slangasek: Does prod have the changes (so I can kick off a respin)?
<slangasek> tsimonq2: it does
<tsimonq2> slangasek: Awesome, thanks.
<slangasek> so are any rust packages installable anywhere? because you wouldn't think so by looking at update_excuses
<tsimonq2> pytest is close; python-ulmo just needed a test retry and hovercraft will likely pass soon because it failed on dep problems... I wish I could make pytest migrate but I just can't seem to doit/0.31.1-1 </horrible pun> :D
 * acheronuk groans ^^
<ginggs> tsimonq2: fwiw, i filed debian bug #907379
<ubot5> Debian bug 907379 in src:doit "doit: autopkgtest regression" [Normal,Open] http://bugs.debian.org/907379
<tsimonq2> ginggs: You beat me to it! :D
<tsimonq2> ginggs: Thanks.
<tsimonq2> ginggs: (Was seriously >< this close to submitting my own.)
<tsimonq2> ginggs: Do you have a lead on what could be causing this? https://github.com/pytest-dev/pytest/issues/3061 seems to be the closest thing in the upstream changelog.
<gitbot> pytest-dev issue 3061 in pytest "ImportWarning: can't resolve package from __spec__ or __package__" [Plugin: Debugging, Plugin: Warnings, Topic: Collection, Closed]
<tsimonq2> But there was also rework of that code upstream right before this.
<ginggs> tsimonq2: no idea, I thought this looked promising https://github.com/pydoit/doit/commit/b40ad81ae4f2ebec1964c4b0da5ac9146c7ffc03
<ginggs> but it is already in the debian packaging
<ginggs> tsimonq2: did you try with doit straight from git?
<tsimonq2> ginggs: Upstream seems to have Travis set up with an old pytest, so I think it's pytest, but I can try from Git.
<tsimonq2> I don't believe there is anything pertinent in there.
<tsimonq2> Yeah, I don't think it's the right tree to be barking up.
<tsimonq2> If anything I'm very likely to just Git bisect the pytest packaging and find out where the code is that makes it fail.
<tsimonq2> Maybe there's some downstream adjustments necessary.
<tsimonq2> (s/Maybe/It's very likely that/)
-queuebot:#ubuntu-release- New sync: cmake-vala (cosmic-proposed/primary) [1-1]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-158.208] (core, kernel)
<tsimonq2> Oh noes, I actually uploaded that to the archive /o\
<tsimonq2> I shouldn't actually be able to upload something to the archive with ~ppa in the version string... yikes.
 * tsimonq2 switches to dput-ng
<smb> Could someone here add linux-azure to the "kernel" package set for trusty?
<sil2100> smb: on it
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-158.208]
<smb> sil2100, ah u2 :) thanks
<sil2100> smb: hm, I guess I'll also add linux-signed-azure to the xenial packageset, since it seems to be missing there
<sil2100> smb: done
<smb> sil2100, oh, guess, that and meta, and same for trusty
<smb> sil2100, normally we have the tracking bugs only for the kernel package, so won't notice missing nomination abilities for the other ones
<smb> sil2100, and uploads are indirect anyway
<smb> sil2100, all looking in sync and good now, thanks
-queuebot:#ubuntu-release- Packageset: Added linux-azure to kernel in trusty
-queuebot:#ubuntu-release- Packageset: Added linux-meta-azure to kernel in trusty
-queuebot:#ubuntu-release- Packageset: Added linux-signed-azure to kernel in trusty
-queuebot:#ubuntu-release- Packageset: Added linux-signed-azure to kernel in xenial
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (bionic-proposed/main) [0.130ubuntu3.2 => 0.130ubuntu3.3] (core)
-queuebot:#ubuntu-release- Unapproved: rejected initramfs-tools [source] (bionic-proposed) [0.130ubuntu3.3]
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (bionic-proposed) [0.130ubuntu3.3]
<mwhudson> tsimonq2: https://gist.github.com/mwhudson/616499edb1191bd99c987bbbd8781ce9
<mwhudson> oh wait i made a repo, https://github.com/mwhudson/dput-wrap
-queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (bionic-proposed/main) [1:0.5.2 => 1:0.5.2.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (bionic-proposed) [1:2.11+dfsg-1ubuntu7.5]
-queuebot:#ubuntu-release- New source: kubernetes (cosmic-proposed/primary) [1.0]
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox-ext-pack [source] (bionic-proposed) [5.2.10-3ubuntu18.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (bionic-proposed) [2.02-2ubuntu8.4]
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.4 => 2.02-2ubuntu8.4] (core)
-queuebot:#ubuntu-release- Unapproved: openssh (xenial-proposed/main) [1:7.2p2-4ubuntu2.4 => 1:7.2p2-4ubuntu2.5] (core)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (bionic-proposed) [2.02-2ubuntu8.4]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-5 [source] (xenial-proposed) [5.4.0-6ubuntu1~16.04.11]
-queuebot:#ubuntu-release- Unapproved: accepted yaml-cpp [source] (xenial-proposed) [0.5.2-4ubuntu1~16.04.4]
-queuebot:#ubuntu-release- Unapproved: accepted rax-nova-agent [source] (bionic-proposed) [2.1.15-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.4 => 2.02-2ubuntu8.4] (core)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (bionic-proposed) [2.02-2ubuntu8.4]
-queuebot:#ubuntu-release- Unapproved: rejected libreoffice-l10n [source] (xenial-proposed) [1:5.1.6~rc2-0ubuntu1~xenial4]
-queuebot:#ubuntu-release- Unapproved: rax-nova-agent (xenial-proposed/universe) [2.1.12-0ubuntu2~16.04.0 => 2.1.15-0ubuntu1~16.04.0] (no packageset)
<slangasek> infinity: well then, why does glibc 2.28 cause cminpack to regress its test suite involving numeric operations?
<slangasek> retrying all the failed autopkgtests with glibc, both with --no-proposed and without
-queuebot:#ubuntu-release- Unapproved: accepted rax-nova-agent [source] (xenial-proposed) [2.1.15-0ubuntu1~16.04.0]
<infinity> slangasek: Either a bug in glibc or a bug in the testsuite?
<slangasek> infinity: nothing number-y changed in glibc 2.28 of note?
<infinity> slangasek: My bet would be on a testsuite expecting a specific amount of lack of precision, and libm getting more accurate, but let's see.
<slangasek> grep uploaded to make it not complain that glibc got better
<infinity> slangasek: libm's badness improves pretty much every release, to some degree, but no major noteworthy things, I don't think.
<slangasek> alright.  whatever happened, it happened cross-architecture
<infinity> Well, except for this, but I read this literally as "added functions", so hard to see how that would break un-rebuilt binaries:
<infinity> * <math.h> functions that round their results to a narrower type are added
<infinity>   from TS 18661-1:2014 and TS 18661-3:2015:
<infinity> Oh, no.  That's now how to read that.
<infinity> This may indeed be a case of increased accuracy.
<infinity> Except, wow, I have no idea what that testsuite output actually means. :P
<infinity> I'll final l2 norm YOUR residuals.
<wxl> slangasek: thanks for merging my new lubuntu logos for ubuntu-cdimage.. today's daily shows the boot menu as black though, which is.. perplexing. any ideas?
<infinity> slangasek: The "approximat solutions" deltas seem plausibly similar at least.
<slangasek> wxl: no, I know almost nothing about this part of the image bot
<slangasek> boot
<wxl> slangasek: got any suggestions as to who might be good to chat with?
<slangasek> wxl: cjwatson?  to be clear, are you saying that it's black where the logo should be instead?
<wxl> slangasek: yeah, and the blue background that's part of the image is missing
<infinity> slangasek: And cminpack upstream hasn't seen a commit in over a year.  Excellent.
<infinity> slangasek: Odd on "Debian Science" actually understanding it well enough to field a bug? :P
<slangasek> no idea
<infinity> Hrm.  And while it's reasonably leafy, it does have a little bit of an rdep chain.
<infinity> Bother.
<infinity> Guess I'll file a bug and hope for comments.
<infinity> My gut says it's just different rounding and a too-specific testsuite.
<infinity> Based on the "solutions" bits.
<LocutusOfBorg> anybody, can please tell me if it is ok to drop libxml2-udeb package?
<LocutusOfBorg> it breaks migration-assistant, and then it is not migrating
<LocutusOfBorg> but somebody is telling that migration assistant is broken because it depends also on other non-udeb packages...
<LocutusOfBorg> who is correct? (sorry but I don't speak udeb)
<infinity> Err, wat?
 * slangasek glares at the completely bogus provides: of libmems1
<infinity> LocutusOfBorg: So, err, yeah, why did you drop libxml2-udeb? :P
<infinity> LocutusOfBorg: But maybe a rebuild of migration-assistant will just make it drop the dep, lemme see.
<slangasek> it won't
<slangasek> I already looked
<slangasek> it uses libxml extensively, and Debian didn't care because m-a is Ubuntu-specific
<infinity> What do you mean "Debian didn't care"?
<infinity> libxml2-udeb isn't from Debian.
<infinity> You mean "the person who synced over Debian changes didn't care".
<infinity> Err, ubuntu changes.
<slangasek> infinity: I believe when I looked at the Debian changelog it mentioned dropping the udeb there
<infinity> Not in any recent history.
<slangasek> ok
<slangasek> then yes, why are people dropping udebs?
<infinity> I mean, not between 6.1 and 7 which is where we synced and dropped our delta that (re)added the udeb.
<infinity> LocutusOfBorg: So, yeah, why that sync, and who told you it was "ok"?
<infinity> LocutusOfBorg: And please merge instead of syncing, kthx.
<infinity> Although, migration-assistant hasn't been in main forever.  Do we even care anymore?
<infinity> It's clearly not used in our installer(s), if it was, it would be seeded still.
<infinity> revno: 1748
<infinity> committer: Evan Dandrea <evan.dandrea@canonical.com>
<infinity> branch nick: platform.quantal
<infinity> timestamp: Fri 2012-05-25 15:24:39 +0100
<infinity> message:
<infinity>   Drop migration-assistant per https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-testing-migration-assistant.
<infinity> LocutusOfBorg: Maybe don't merge.
<infinity> slangasek: ^-- In light of the above happening in, uhm, 2012, maybe it's time to just delete the package? :P
<infinity> slangasek: +/- 1?
<slangasek> infinity: ok
<infinity> Kay, solving it that way then.
-queuebot:#ubuntu-release- New binary: ros-bond-core [s390x] (cosmic-proposed/universe) [1.8.3-1] (no packageset)
<infinity> LocutusOfBorg: Alright, deleting migration-assistant instead, but yeah, please actually discuss stuff like this before syncing instead of letting it sit for 2 months. :P
<infinity> And gone.
-queuebot:#ubuntu-release- New: accepted debian-el [amd64] (cosmic-proposed) [37.6]
-queuebot:#ubuntu-release- New binary: ros-bond-core [amd64] (cosmic-proposed/universe) [1.8.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ros-bond-core [s390x] (cosmic-proposed) [1.8.3-1]
<slangasek> to be fair, it's easy to overlook udeb revdeps, since half the tools don't handle them
-queuebot:#ubuntu-release- New binary: ros-bond-core [ppc64el] (cosmic-proposed/universe) [1.8.3-1] (no packageset)
<infinity> slangasek: Sure, but "I wonder if I can just drop this Ubuntu delta that generates another package" is a thing that might need review by someone who knows what's what.
<infinity> (Teaching reverse-depends(1) about udebs would also be nice, though)
<infinity> And I'm not sure why that hasn't been done.  It's trivial, as it's Just Another set of Packages Files.
<slangasek> because reverse-depends talks to a service
<infinity> Well, yes.  Teaching the service is what I meant.
<slangasek> well iirc, when I tried to look into getting it to also give useful annotations for alternative-depends in its output, I found the service implemented in some weird language?
<infinity> German?
<slangasek> rustubycaml
<infinity> My favourite.
<slangasek> rustubycamell, rather
<LocutusOfBorg> infinity, slangasek I'm pretty sure I discussed it two months ago, but libxml2 was broken because of some failing tests, this is why I spotted the udeb thing only yesterday
<LocutusOfBorg> there was a good reason for the sync
<LocutusOfBorg> but we discussed this 7 months ago
<LocutusOfBorg> in the meanwhile I readded it as ubuntu delta
<LocutusOfBorg> https://salsa.debian.org/xml-sgml-team/libxml2/commit/76b5366a78a1439ab31ce8fe3ebefe4fdb8b6212
<LocutusOfBorg> we also discussed it with installer team IIRC but meh, who remembers what happened more than one hour ago?
 * LocutusOfBorg goes back looking a movie, "memento" is on air :)
<LocutusOfBorg> thanks for fixing!
-queuebot:#ubuntu-release- New binary: ironic [amd64] (cosmic-proposed/universe) [1:11.1.0-0ubuntu3] (openstack)
<tsimonq2> mwhudson: <3
<ginggs> would someone please 'force-badtest pymca/5.3.2+dfsg-1/ppc64el pymca/5.3.2+dfsg-1/s390x' - no longer built on those architectures
<slangasek> AssertionError: assert nan == 0.3342377271245026
 * slangasek looks askance at python-cffi
<ginggs> also please 'force-badtest julia/0.7.0-2ubuntu1/i386' not built there either
<slangasek> ginggs: looking
<slangasek> ginggs: done
<ginggs> slangasek: ta!
<slangasek> infinity: r-cran-rgenoud will be another "interesting" one
<infinity> slangasek: Is that assertion on all arches, or just ppc?
<infinity> slangasek: If it's PPC, I know what the bug is (and it's being worked on), if it's all arches, lol?
<slangasek> infinity: the python-cffi assertion is i386
<infinity> Oh, fun.
<infinity> That might be a bad testsuite disapproving of some libm fixes.
<infinity> slangasek: Can you start an actual list of stuff like this you find so I can go through them?
<infinity> I guess you could card it.
-queuebot:#ubuntu-release- New binary: panko [amd64] (cosmic-proposed/universe) [5.0.0-0ubuntu3] (no packageset)
<slangasek> infinity: could; but I'm almost to the bottom of the false-positives on update_excuses so you could just use that
<infinity> slangasek: Sure, if you've decided reds on excuses are all legit, that works too.
<slangasek> nearly there
<infinity> Well, legit and/or needs eyeballs.
<slangasek> mwhudson: seems there would be fewer packages needing badtesting if python-scipy were able to migrate
<slangasek> infinity: unrar-free probably just needs a new valgrind, which I'm uploading now but will obviously take a while to build
<slangasek> infinity: for bonus points, the armhf apt autopkgtest regression is reproducible
<slangasek> infinity: I do like the fcoe-utils/arm64 regression best of all, though - glibc 2.28 has caused this package to no longer find PCI support on the testbed ;)
<infinity> slangasek: Wha?
<xnox> slangasek, we appear to migrate things without grouping them with built-using. e.g. go things should be grouped with 'built-using' things, like we group the silo ppa stuff.
<xnox> slangasek, cause e.g. prometheus-node-exporter migrated, but only passes with all-proposed things.
<mwhudson> slangasek: the backend for reverse-depends is in that super oddball language, python, iirc
<slangasek> mwhudson: oh ok ;)
<mwhudson> although i am now entirely failing to find the repo again
<mwhudson> slangasek: ah https://bazaar.launchpad.net/~stefanor/+junk/reverse-deps/files
<infinity> slangasek: That's bizarre.  It looks like the test itself is working the same with both, but upgrading glibc makes it more verbose?
<infinity> slangasek: ... and makes it see a qemu PCIe bridge?
<infinity> ...how?
<slangasek> xnox: we don't block migrations based on build-depends either; this might be something better handled via an audit report at end of cycle, rather than making proposed-migration more brittle
<infinity> slangasek: Those two tests also used different kernels (-7 versus -9), maybe that's the real culprit?
<LocutusOfBorg> please somebody bump mariadb hint to mariadb-10.1
<LocutusOfBorg> ehm 1:10.1.35-1ubuntu1
<mwhudson> slangasek: scipy: figuring out scientific software's autopktest fails is always so much fun
<slangasek> LocutusOfBorg: I thought I saw mariadb-test being sorted; has that not yet reached Ubuntu?
<mwhudson> particularly the ones that only crop up on s390x
<mwhudson> something in the stack has picked up an endian bug? hooray
<mwhudson> and skimage fails on 32 bit
<infinity> slangasek: Ahh, no, -7 failed the same way in an earlier run.  Back to WTF.
<infinity> slangasek: FWIW, i386 fails (and has always failed) the same way due to the same stderr message.
<infinity> slangasek: So this looks more like a progression on arm64 that leads to a regression due to the test being broken WRT not ignoring that message.
<slangasek> righty-o
<infinity> slangasek: amd64 passes because it doesn't find a bridge to enumerate to then tell us it can't do PCI caps. :P
<slangasek> heh
<infinity> slangasek: i386 (and now arm64) find a bridge and tell us it's naughty.
<infinity> Still no idea why a glibc upgrade would tickle that, but carefactor there is low.  I think fixing the test to ignore that one stderr message and suddenly make i386 pass is the right option.
<slangasek> infinity: then why did the no-proposed retry succeed?
<slangasek> ok
<LocutusOfBorg> slangasek, what?
<slangasek> LocutusOfBorg: I definitely saw that the missing mariadb-test package was being reintroduced in Debian.  And I see it in -proposed as well.  that was the previous rationale for the badtest
<xnox> mwhudson, yeah, lets ask ibm to do s390le
<slangasek> LocutusOfBorg: so I would not just bump the mariadb-10.1 hint without a specific rationale
<infinity> xnox: You're in a timeout.
 * xnox ð
<LocutusOfBorg> slangasek, https://ci.debian.net/data/autopkgtest/unstable/amd64/m/mariadb-10.1/873043/log.gz
<LocutusOfBorg> does it help to know that the failure is exactly the same?
<LocutusOfBorg> I can report a debian bug if you want, or if nobody did it
<LocutusOfBorg> https://ci.debian.net/packages/m/mariadb-10.1/unstable/amd64/
<slangasek> LocutusOfBorg: knowing that the testsuite fails in the same way in Debian and Ubuntu is not an argument for us ignoring the breakage in Ubuntu
<xnox> because debian revert our fixes, and won't put them back - cause they /only/ fix autopkgtests?!
<xnox> (that used to be the case, not sure if the current failure is still the same thing or something else)
<LocutusOfBorg> https://jira.mariadb.org/browse/MDEV-15096
<LocutusOfBorg> https://www.google.it/search?q=CURRENT_TEST%3A+main.mysql_client_test_nonblock&oq=CURRENT_TEST%3A+main.mysql_client_test_nonblock&aqs=chrome..69i57.202j0j7&sourceid=chrome&ie=UTF-8
<LocutusOfBorg> seems that upstream is aware since some years, and nobody caring :/
 * LocutusOfBorg too tired to look at it today, g'night!
<sarnold> heh, I though tyou said "too tired to at it on a friday night".. and got my hopes up.
<mwhudson> hm
<mwhudson> can we just stop building for i386? :)
<mwhudson> and armhf (pushing it now)
<sarnold> I'd also be content with "sorry, that package is no longer available on this architecture because it can't be linked"
<sarnold> how much time do we spend on chromium-browser, firefox, .. ceph? .. who else takes forever..
<mwhudson> i think some underlying numeric package now has precision issues on x87 or something
<infinity> x87 is garbage.
<mwhudson> yes
<infinity> The only way to get accurate math on x86 is to ignore x87.
<infinity> Which is slooooow.
<mwhudson> or ignore x86!
<infinity> Amen.
<infinity> Sing it, sister.
<mwhudson> does ubuntu assume sse for x86?
<mwhudson> wait no i DONT CRE
<mwhudson> *CARE
<infinity> No.
<infinity> We assume base 686 + PAE (and the latter only for the kernel)
<mwhudson> imexam + python-astropy: fail only on s390x
<mwhudson> skimage: fails on 32 bit
<mwhudson> python-scipy itself: fails on i386
<mwhudson> (well and armhf but it's never passed there)
<mwhudson> oh wait: http://autopkgtest.ubuntu.com/packages/p/python-scipy/cosmic/i386
 * mwhudson checks hints
<mwhudson> hm was hinted for 0.19.1-2ubuntu1
<infinity> slangasek: bash to the rescue: http://paste.ubuntu.com/p/wkQF9X8yXw/
<slangasek> infinity: instead of 'run fcoeadm --interface >&4 2>&1 |grep -v "^PCI capabilities are not supported$" >&2 4&>1' ? :)
<infinity> slangasek: Yeah, I started down fd shuffling route, then remembered bash could do this readably.
<slangasek> jbicha: why did you reintroduce ubuntu-desktop on s390x in ubuntu-meta 1.407?
<infinity> slangasek: Also, harder with fd-shuffling to get the rest of stderr to stay on stderr instead of lumping it all in stdout.
<infinity> Though, I think yours does that.
<infinity> Maybe.
<infinity> slangasek: Because it's not unity-based anymore and all the deps actually build?
<slangasek> infinity: we deliberately did not ship an ubuntu-desktop package on that architecture because Canonical does not support the desktop on s390x
<infinity> slangasek: Canonical doesn't support the desktop on ppc64el either.
<slangasek> now the package exists, without even a comment in the changelog as to why the architecture exclusion list was reverted
<slangasek> yes, and we shouldn't have it there either
<infinity> I heartily disagree. :P
<infinity> I don't think having random arch differences based on what Canonical has contracts for is particularly sane.
<jbicha> because it makes the changelogs more confusing if we don't build ubuntu-desktop on all architectures
<jbicha> see https://launchpad.net/ubuntu/+source/ubuntu-meta/1.406
<jbicha> because the update script doesn't actually handle that case very well
<slangasek> yes, and such disagreements ought to be discussed, instead of being rendered a fait accompli by changing it and letting it leak into an LTS
<jbicha> you could split ubuntu-desktop into its own separate source package if you wanted
<slangasek> dude
<slangasek> jbicha: that is not grounds for making a unilateral decision about architecture support in ubuntu-meta
<infinity> slangasek: How does the presence of a metapackage change anything about any of the packages it depends on?  If we really want to not have GNOME supported on s390x at all, we shouldn't be building it (but, please don't).
<slangasek> and if you care so much about changelog readability, why did you not document this change in the changelog?
<slangasek> infinity: it makes a significant difference in the kind of awkward conversation you get to have with a user who tries to install ubuntu-desktop and then wants support for it
<infinity> slangasek: And if that user installs a bunch of random desktop packages in main and starts up that same conversation, it's less awkward?
<slangasek> ideally we wouldn't have any of those packages in main on s390x
<slangasek> for this reason
<jbicha> ok, I should have mentioned it in the changelog, I guess I just didn't want to have an argument about it but that's not a very good reason
<slangasek> that's weird, can't reproduce the telepathy-logger-qt autopkgtest regression in a cosmic chroot
<slangasek> LocutusOfBorg: seen the diaspora-installer autopkgtest regressions (openssl)?
<slangasek> infinity: looks like mysql-5.7/ppc64el is also fail-y after a rebuild against the new ppc64el
<slangasek> infinity: eh, ignore that, looks like 5.7.23 in general has been fail-y on ppc64el
<xnox> jbicha, that change only broke release-upgrade from xenial->bionic for everyone on s390x, in addition to being against what was agreed before between ubuntu & ibm.
<xnox> (the z side of ibm)
<infinity> xnox: How would it have broken release upgrade?
<xnox> infinity, because giggles =)https://bugs.launchpad.net/ubuntu-z-systems/+bug/1787668
<ubot5> Ubuntu bug 1787668 in ubuntu-release-upgrader (Ubuntu) "ubuntu-release-upgrader crashed with KeyError: "The cache has no package named 'ubuntu-desktop'"" [High,In progress]
<slangasek> xnox: I don't think it broke the release-upgrade; I think the release-upgrader itself is just broken for using ubuntu-desktop as a key package on this arch when it shouldn't
<infinity> xnox: Unless you're implying we accidentally install a desktop on every server installation on upgrade, I call BS on "broke ... for everyone".
<xnox> infinity, it has broken logic for when a key package is in next release; but not current.
<xnox> as far as i understand the bug so far.
<infinity> Oh.  Well, that's hardly jbicha's fault.
<xnox> infinity, re not having ubuntu-desktop. At the time i had more strong opinion about it, given lack of physical displays; lack of stable mir/wayland display manager or ssh forwarding for mir/wayland; now that we are back to just X it is slightly easier to say that X things are possibly useful.
<xnox> infinity, but not unless one can watch cat videos on youtube. imho installing ubuntu-desktop should give that ability to the user, and i believe firefox is still broken on s390x.
<xnox> infinity, i have not checked, but ppc64el ubuntu-desktop does pass the cat video test i believe.
<infinity> I don't think cat videos are a hard requirement for a functional desktop. :P
<sarnold> infinity: break them and find out.. :)
<infinity> Though, I admit it's a nice-to-have.
<infinity> xnox: fwiw, firefox exists on s390x in bionic.  How broken is it?
<xnox> infinity, i have made this argument before, i believe re:i386 -> until it can haz cat videos it is a real desktop.
<infinity> s/bionic/bionic-updates/
<xnox> infinity, it does exist, it does exec, it fails between exec and showing a window; most JS tests fail
<xnox> infinity, it compiles into a binary.
<infinity> Ahh, so rust is borked.
<xnox> that too.
<sarnold> qt's not happy on ppc64el either https://bugreports.qt.io/browse/QTBUG-56975
<infinity> Which seems like a larger problem for a server/cloud-type system than just firefox JS.
<infinity> Given rust is gaining more traction in that space.
<xnox> infinity, rust itself is better than all of firefox, i thought the testsuite failures for rust on s390x were small-ish
<mwhudson> i'm sure ibm have teams of toolchain engineers just roaming around looking for toolchains to support
<xnox> (at least at the time i fleshed it out with chrisccoulson )
<infinity> xnox: Well, firefox JS broken == rust broken, these days.
<xnox> mwhudson, i have requested that for rust and firefox, it went mia -> not a priority for that subteam.
<xnox> infinity, but i do want to put my little paw dawn and show some claws re:cat-video requirement.
<infinity> xnox: If the rust testsuite isn't catching what firefox's JS engine does, then one could consider firefox JS a better rust testsuite. :P
<sarnold> rust 'tier 1' platforms is mighty small list :(  https://forge.rust-lang.org/platform-support.html
<jbicha> xnox: could you try epiphany-browser on s390x?
<infinity> People other than masochists run epiphany on purpose?
<jbicha> depends on how desperate you are for cat videos, I guess
<infinity> I mean, I'll have a friendly vim-vs-emacs style argument about firefox-vs-chromium any day, but bringing epiphany into it is akin to the guy in the corner piping up with "I prefer pico!"
<infinity> ie: We all agree that guy's wrong.
<slangasek> galeon ftw
<xnox> there was an odd browser with an apparmor profile as well
<xnox> i spotted recently
<xnox> is it galeon?
<sarnold> qutebrowser perhaps? https://github.com/qutebrowser/qutebrowser/blob/81b3ef937ebf202670c1561429552874ed51d32a/misc/apparmor/usr.bin.qutebrowser
<xnox> sarnold, https://launchpad.net/ubuntu/+source/surf
<sarnold> I didn't expect that
<xnox> sarnold, an apparmor profile unsuitable for usr-merge to be precise ;-)
<sarnold> lol
<slangasek> xnox: galeon was a gnome 1.x (?) wrapper around embedded mozilla
<xnox> slangasek, there was gnome before 3?
<jbicha> "surf is a simple web browser based on WebKit2/GTK+. It is able to display websites and follow links." < https://surf.suckless.org/
 * xnox ponders that i should be advocating demoting ubuntu-desktop binary package from main to universe on all arches that fail cat-video test
<xnox> slangasek, how do you feel about releasing systemd?
<xnox> there is only one assertion on arm64
<xnox> subprocess.CalledProcessError: Command '['ps', 'u', '-C', 'gdm-x-session']' returned non-zero exit status 1.
<xnox> in a boot-and-services test case
<slangasek> xnox: which release?
<xnox> cosmic-proposed -> -release
<slangasek> xnox: so you want me to badtest it?
<xnox> yes please.
<xnox> and i'm thinking to debug and file gdm3 bug + mark it expectfailed on arm64 for cosmic
<xnox> not sure what the point is, in src:systemd validating ubuntu-desktop on a non-UA arch.
<slangasek> xnox: arm64 is desktoppier than some of the others
<xnox> sure
<xnox> but the arm64 microsoft laptops are not linux supported yet =/
<slangasek> xnox: anyway, looks like a fair trade here
<slangasek> (since we currently have 3 archs ignored in release pocket instead of 1)
<xnox> oh
<xnox> it's been baking for a long time, and i had to fix many things yes =/
<xnox> v238 and v239 were quite shit
 * slangasek gives the idle autopkgtest runners something more to do (mass retry of failed autopkgtests)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.7 => 2.525.8] (desktop-core)
#ubuntu-release 2018-08-28
<mwhudson> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
<flocculant> yea
<mwhudson> slangasek: some of the failures preventing python-scipy from migrating are probably real problems in scipy
<mwhudson> but the python-scipy build does not run the tests
<mwhudson> it attempts to run the tests and then ignore the results (...) but it doesn't even do that
<mwhudson> /<<PKGBUILDDIR>>/debian/tests/python3: 7: /<<PKGBUILDDIR>>/debian/tests/python3: AUTOPKGTEST_TMP: parameter not set
<mwhudson> and the autopkgtests have always failed on s390x so that's no help either
 * mwhudson goes home in a grump
-queuebot:#ubuntu-release- New binary: cpp-hocon [s390x] (cosmic-proposed/universe) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cpp-hocon [ppc64el] (cosmic-proposed/universe) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted cpp-hocon [ppc64el] (cosmic-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted ros-bond-core [amd64] (cosmic-proposed) [1.8.3-1]
-queuebot:#ubuntu-release- New: accepted cpp-hocon [s390x] (cosmic-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted ros-bond-core [ppc64el] (cosmic-proposed) [1.8.3-1]
<tsimonq2> Oooh, I figured out doit. pytest + doit should migrate on the next Britney run or two.
-queuebot:#ubuntu-release- Unapproved: snapd-glib (bionic-proposed/main) [1.41-0ubuntu0.18.04.1 => 1.43-0ubuntu0.18.04.1] (kubuntu, ubuntu-desktop, ubuntu-server)
<tsimonq2> ...you could say, I "did it." </terrible pun>
<tsimonq2> slangasek: Could you badtest php-text-password/1.2.1-2? It has an RC bug open in Debian and it fails when retried against itself with the same error: http://autopkgtest.ubuntu.com/packages/p/php-text-password/cosmic/amd64
<slangasek> tsimonq2: done
<tsimonq2> slangasek: Thanks.
<tsimonq2> slangasek: Same situation with php-analog/1.0.7-2.
<slangasek> tsimonq2: nah I just removed that package
<tsimonq2> slangasek: How 'bout php-pimple/3.0.2-2ubuntu1?
<slangasek> tsimonq2: where's the evidence that it fails against the release pocket?  (I have just triggered exactly this test to check, but the results aren't available yet)
<tsimonq2> slangasek: Same error, RC bug, looks just like the aforementioned packages. Thanks for triggering the test, it should confirm it.
<slangasek> tsimonq2: ok.  test results are in, and it confirms
<slangasek> I triggered release-pocket-only tests of everything that's blocking php-defaults
<tsimonq2> ack, so we *are* looking at the same thing. ;)
<slangasek> and they're all badtestable (done)
<tsimonq2> Awesome.
<slangasek> and now I'm not looking at any more of these tonight ;)
<tsimonq2> hehe
<tsimonq2> http://autopkgtest.ubuntu.com/packages/d/doit/cosmic/arm64 lolwat
 * tsimonq2 can't tell if it's an autopkgtest bug or if it's an oversight in the submission syntax...
<slangasek> tsimonq2: did you trigger that test before doit 0.31.1-1ubuntu3 was actually published?
<tsimonq2> slangasek: No, I waited until it was published.
<tsimonq2> slangasek: But I did do it immediately after I confirmed it was in LP so ... race condition somewhere?
<slangasek> well, the error looks to me like the autopkgtest runner couldn't find it on the internal archive server
<tsimonq2> Huh.
<slangasek> yes, 'published' in launchpad means that a launchpad api call has finished wrt that package, not that the publishing run is complete
<tsimonq2> slangasek: fflas-ffpack badtest on armhf? Looks like you retried against release: http://autopkgtest.ubuntu.com/packages/f/fflas-ffpack/cosmic/armhf
<tsimonq2> Ah, got it.
<tsimonq2> How long should I expect to wait for the publishing run?
<slangasek> I'd give it about 5 minutes generally
<tsimonq2> OK
<slangasek> fflas-ffpack> I'm really not looking at any more of these tonight
<tsimonq2> OK ;)
 * tsimonq2 waits for some UK folks.
<tsimonq2> Thanks slangasek.
<ginggs> tsimonq2: now you can send your doit fix to debian and impress your AM ;)
<tsimonq2> ginggs: ahaha
<tsimonq2> I haven't got an email from them yet...
<tsimonq2> I was going to anyway, after I confirm pytest migrated.
<slangasek> tsimonq2: but if /you/ wanted to look at other things, you could tell me why the telepathy-logger-qt/ppc64el acc failure isn't reproducible for me
<tsimonq2> slangasek: Sure thing, I'll see if I can make heads or tails of it.
<tsimonq2> ginggs: Wait a minute ... I KNEW I recognized the name from somewhere!
<ginggs> tsimonq2: you got it!
<tsimonq2> ginggs: Somehow I wonder if frontdesk is lurking in here and just decided to assign me that AM... :P
-queuebot:#ubuntu-release- Unapproved: unbound (bionic-proposed/main) [1.6.7-1ubuntu2.1 => 1.6.7-1ubuntu2.2] (ubuntu-server)
<LocutusOfBorg> sil2100, thanks for rejecting vbox-ext-pack :) the problem was that people are keeping reporting the same bug over and over, without prior doing apt-get update, so they keep using the version in release... -.-' I then fixed twice the same bug and of course the resulting (working) upload was a no-op
<LocutusOfBorg> LOL
<LocutusOfBorg> (I asked here to reject some seconds after the upload, but nobody did it)
<LocutusOfBorg> sorry for wasting your time! we should probably gain a "reject your uploaded package by yourself" button
<xnox> jbicha, slangasek, infinity - ehhh if rust is busted, and firefox is busted, it means gjs is busted too, and hence no gnome-shell and no display/login-manager either, no?!
<xnox> cause it's all gnome-shell these days? or is gdm3 somehow not js? i thought it is....
 * xnox wonders if everything is busted on arm64 then if gdm doesn't come up
 * xnox goes to dig deeper.
<tkamppeter> I have synced cups-filters 1.21.1 on Monday and now it is hanging in -proposed with
<tkamppeter> Invalidated by dependency
<tkamppeter> Depends: cups-filters glibc (not considered)
<tkamppeter> Depends: cups-filters poppler
<tkamppeter> What does this mean? Do I have to no-change-upload it? Or simply wait until a problem of the glibc package gets solved?
<LocutusOfBorg> tkamppeter, fixing xpdf might help :p
<jbicha> xnox: I don't think gjs is using rust yet, see https://salsa.debian.org/gnome-team/mozjs60 (uploaded to Debian NEW)
<xnox> jbicha, ah, interesting, thanks.
<xnox> tkamppeter, it means this thing picked up a dependency on the newer glibc; which itself is not yet ready to migrate.
<xnox> tkamppeter, meaning you already gained a new abi
<jbicha> new versions of librsvg do use rust though
<rbalint> hi, please sync ruby-concurrent it should fix autopkgtest
<LocutusOfBorg> .
<ahasenack> infinity: hi, good morning/afternoon/evening, I guess with the glibc upload, you are all busy and can't take a look at squid in new? :)
<xnox> jbicha, so, gdm3 looks fine to me in arm64 vm, if it has a video graphics card provided, a virtio one for example.
<xnox> slangasek, do you use grab-merge from MoM? i think we need to fix it to correctly unpack and preserve executable bits
<xnox> slangasek, it looks like it doesn't. and e.g. apt-setup and ifupdown were bitten by that recently
<xnox> it is a recurring thing.
<xnox> mwhudson, too
<oSoMoN> hi all, I filed bug #1789240 yesterday to request a feature freeze exception for libreoffice 6.1, and it was marked confirmed because someone said this bug affects them, should I reset the status to New to ensure the release team sees it?
<ubot5> bug 1789240 in libreoffice (Ubuntu) "[FFe] libreoffice 6.1.0" [Undecided,Confirmed] https://launchpad.net/bugs/1789240
<LocutusOfBorg> archive admins, can I please make insighttookit4 build only on amd64 and i386? there is no point on "building everywhere and discard failures" this is a medical image processing tool, upstream refuses to maintain anything non x86 unless somebody provides patches, and we shouldn't give users a false sense of good package being installed
<LocutusOfBorg> slangasek, ^^ since you too don't like test being ignored :)
<LocutusOfBorg> it requires a bunch of removals on other architectures for reverse-deps
<LocutusOfBorg> apw, ^^
<tkamppeter> cpdb-libs has a problem with the autopgk test. The test passes on all architectures except arm64. On arm64 I get:
<tkamppeter> autopkgtest [09:21:04]: test text_frontend_vs_cups_backend: [-----------------------
<tkamppeter> autopkgtest [09:21:19]: test text_frontend_vs_cups_backend: -----------------------]
<tkamppeter> autopkgtest [09:21:19]: test text_frontend_vs_cups_backend:  - - - - - - - - - - results - - - - - - - - - -
<tkamppeter> text_frontend_vs_cups_backend FAIL non-zero exit status 139
<tkamppeter> Meaning that before the script outputs anything on stderr or stdout it exits with status 139. What does this mean.
<tkamppeter> ?
<seb128> could someone review ffe bug #1789380 which is a simple GNOME app update?
<ubot5> bug 1789380 in gnome-calendar (Ubuntu) "[ffe] Update to 3.29.92" [Wishlist,New] https://launchpad.net/bugs/1789380
-queuebot:#ubuntu-release- Unapproved: fonts-noto-color-emoji (bionic-proposed/main) [0~20180424-0ubuntu1 => 0~20180810-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: nova-lxd (bionic-proposed/main) [17.0.0-0ubuntu1 => 17.0.1-0ubuntu1] (ubuntu-server)
<sil2100> seb128: on it in a moment
<slangasek> xnox: I don't know about rust itself being busted; I know that there are bunches of rust library packages with impossible dependencies
<slangasek> xnox: yes, I use grab-merge from MoM, and yes, it would be nice if it didn't drop +x :/
<slangasek> tjaalton: dogtag-pki's autopkgtests still aren't looking very healthy, but at least it's not hanging now?
<tjaalton> slangasek: right, pushed a new httpcomponents-client to fix a failure installing pki-kra, but the autopkgtest failure is something else..
<tjaalton> everything installs fine here, dunno what that encoding error is about
<slangasek> tjaalton: well, on the test runners, stdout is a file not a pipe, so python's locale handling defaults to ascii; you can probably reproduce this by redirecting stdout locally
<sil2100> seb128: have you already tested the new gnome-calendar on cosmic in some PPA or such?
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-34.37] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-34.37] (core, kernel)
<tjaalton> slangasek: hmm could be that it was trying to print out the error then? maybe wait and see if new libhttpclient-java fixes this too
<seb128> sil2100, no, but it's in Debian and it's a sync, the upstream changes are small and it got local testing
<seb128> also it's only an app, not a session component
<seb128> we still have plenty of time to catch any regression and fix it
<sil2100> seb128: approved this time, but please remember there are procedures that need to be followed for every FFe: https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze_Exceptions
<oSoMoN> sil2100, on the topic of FFe, did you see my question in this channel earlier?
<seb128> sil2100, thx, and will do, r-t member got less stricts over the cycle on having a diff etc when requests are trivial like that one so I got lazy as well, but I will remember to include the details for the next one
<oSoMoN> wondering whether the status of bug #1789240 should be set to New
<ubot5> bug 1789240 in libreoffice (Ubuntu) "[FFe] libreoffice 6.1.0" [Undecided,Confirmed] https://launchpad.net/bugs/1789240
<sil2100> seb128: yw! In practice I also feel not all of the points should be required, but for now let's try not to create double standards, as current procedures state those as needed ;)
<sil2100> (and maybe think about tweaking it some official manner)
<seb128> right
<sil2100> oSoMoN: I'll look at it in a minute as well
<oSoMoN> thanks!
-queuebot:#ubuntu-release- Unapproved: magnum (bionic-proposed/universe) [6.1.0-0ubuntu1 => 6.1.1-0ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: magnum (bionic-proposed/universe) [6.1.0-0ubuntu1 => 6.1.1-0ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: magnum (bionic-proposed/universe) [6.1.0-0ubuntu1 => 6.1.1-0ubuntu0.18.04.1] (no packageset)
<coreycb> whoa, sorry about that. ^^ please just choose one, they're all the same.
<coreycb> 2 attempts at a PPA upload with reversed arguments
<teward> coreycb: oopsies?
<coreycb> teward: ya
-queuebot:#ubuntu-release- New: accepted ndctl [source] (bionic-proposed) [61.2-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- New: accepted pmdk [source] (bionic-proposed) [1.4.1-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- New binary: ndctl [amd64] (bionic-proposed/none) [61.2-0ubuntu1~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-34.37]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-34.37]
-queuebot:#ubuntu-release- New: accepted ndctl [amd64] (bionic-proposed) [61.2-0ubuntu1~18.04.1]
<oSoMoN> thanks sil2100!
<sil2100> yw!
<slangasek> tsimonq2: I see a new upload of telepathy-logger-qt, but considering the existing ppc64el failure wasn't reproducible for me locally, I'm unsurprised that it also didn't fix the problem?
<slangasek> tjaalton: printing out an error> why does the error message contain non-ascii chars, either? :)
<tsimonq2> slangasek: Yeah, it was a shot in the dark.
-queuebot:#ubuntu-release- New binary: pmdk [amd64] (bionic-proposed/universe) [1.4.1-0ubuntu1~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted pmdk [amd64] (bionic-proposed) [1.4.1-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: magnum (bionic-proposed/universe) [6.1.0-0ubuntu1 => 6.1.1-0ubuntu0.18.04.1] (no packageset)
<tjaalton> slangasek: good question..
-queuebot:#ubuntu-release- New binary: libminc [s390x] (cosmic-proposed/universe) [2.4.03-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libminc [ppc64el] (cosmic-proposed/universe) [2.4.03-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libminc [i386] (cosmic-proposed/universe) [2.4.03-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libminc [arm64] (cosmic-proposed/universe) [2.4.03-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libminc [armhf] (cosmic-proposed/universe) [2.4.03-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libminc [amd64] (cosmic-proposed/universe) [2.4.03-1] (no packageset)
<tsimonq2> slangasek: telepathy-logger-qt> It fails when retried against itself (as you might have seen)... hint?
<tsimonq2> oh
<tsimonq2> I can read...
<tsimonq2> Yeah, that's not against -release, but it's still weird...
-queuebot:#ubuntu-release- New binary: libreoffice [s390x] (cosmic-proposed/main) [1:6.1.0-0ubuntu1] (kubuntu, ubuntu-desktop)
 * tsimonq2 just can't seem to figure out what error 25 means.
-queuebot:#ubuntu-release- New binary: libreoffice [ppc64el] (cosmic-proposed/main) [1:6.1.0-0ubuntu1] (kubuntu, ubuntu-desktop)
<mwhudson> xnox: i haven't actually done much merging recently, just fixing fallout from the bugs you mentioned
<xnox> mwhudson, right but i think it was grab-merge induced loss of +x not human error
<xnox> in apt-setup
<mwhudson> yeah, certainly
<mwhudson> well grab-merge or mom itself?
<slangasek> grab-merge doesn't meddle with file perms
<slangasek> it's a MoM bug
-queuebot:#ubuntu-release- New binary: libreoffice [i386] (cosmic-proposed/main) [1:6.1.0-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libreoffice [amd64] (cosmic-proposed/main) [1:6.1.0-0ubuntu1] (kubuntu, ubuntu-desktop)
#ubuntu-release 2018-08-29
<slangasek> well, the porter chroots I have access to are broken, and I can't reproduce the sagetex autopkgtest failures (uninstallabilities) w/ chdist
<slangasek> oh, I /can/ reproduce the armhf one
<slangasek> aha sagemath
<tsimonq2> slangasek: Speaking of that, I would probably have a fix for this telepathy-logger-qt issue if I had access to an Ubuntu-based porterbox... :P
<tsimonq2> Maybe spin up an LXD container or something? ;)
<tsimonq2> Â¯\_(ã)_/Â¯
-queuebot:#ubuntu-release- New binary: libreoffice [armhf] (cosmic-proposed/main) [1:6.1.0-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libreoffice [arm64] (cosmic-proposed/main) [1:6.1.0-0ubuntu1] (kubuntu, ubuntu-desktop)
<tsimonq2> slangasek: Could you please kick the can on python-fluids/0.1.72-2? Regressed autopkgtests in release, and it'll make sphinx (plus a few friends) migrate.
<tsimonq2> Hah, so it seems like imexam/0.8.0-2's s390x autopkgtest fails with the same error as the FTBFS for the no-change rebuild...
 * tsimonq2 retries against itself in release
 * tsimonq2 bets we can kick the can on python-scipy as well.
<tsimonq2> Same situation with skimage/0.14.0-0ubuntu2/armhf and skimage/0.14.0-0ubuntu2/i386... autopkgtests fail on the same architectures with the same error that it's FTBFS with after a no-change rebuild. Retrying against release...
<tsimonq2> After that, python-scipy *should* migrate.
<tsimonq2> ...wat? Why does imexam/0.8.0-2/s390x pass? O_o
<mwhudson> uh wat
 * tsimonq2 is confused at the fact that both my skimage retry and my imexam retry have higher versions than their triggers...
<mwhudson> tsimonq2: i *think* there's an endian bug in scipy but as so many things ignore the results of tests during build (angryface) it's hard to know what's going on
<tsimonq2> mwhudson: Maybe if I could get the autopkgtest infra to play nice I'd be able to confirm that. ;P
<tsimonq2> mwhudson: Oh, right, python-scipy won't be done for a while npw.
<tsimonq2> *now
<tsimonq2> 12:52:46 AM < tsimonq2> slangasek: fflas-ffpack badtest on armhf? Looks like you retried against release: http://autopkgtest.ubuntu.com/packages/f/fflas-ffpack/cosmic/armhf
<tsimonq2> Perhaps a UK/European/other side of the pond ~ubuntu-release member like apw can look ^
<slangasek> tsimonq2: not sure how an Ubuntu-based ppc64el porterbox would help you, given that I already said it wasn't reproducible for me...
<slangasek> tsimonq2: python-fluids> if by 'kick the can' you mean 'badtest', no; that's a python3.7+scipy-related test failure, I'm retriggering the tests with --all-proposed
<tsimonq2> Oh hey.
<slangasek> tsimonq2: skimage> mwhudson was already looking at this yesterday and believes this is a regression in scipy.
<mwhudson> and i've looked a bit today and am absolutely no further into understanding it btw
<tsimonq2> slangasek: ppc64el> ack
<slangasek> fflas, let's see
<tsimonq2> slangasek: python-fluids, skimage> ack as well.
<mwhudson> i am currently of the opinion that scientists should not write software but i'll probably get over that
<tsimonq2> hah
<slangasek> yeah, hinting the ffpack
<tsimonq2> \o/
<tsimonq2> Thanks.
<slangasek> mwhudson: I return to that assessment every single time I touch a Debian Med or Debian Science package, then I have to remind myself that their goals are different than mine
<mwhudson> right
<slangasek> and also, that the real bug is for almost any modern scientific software to be built for architectures with a 32-bit address space
<mwhudson> but the tests fail -> disable the tests mentality is ... surely contrary to their goals too
<mwhudson> that's more of a maintainer thing than an upstream thing of course
<tsimonq2> slangasek: telepathy-logger-qt> If I could figure out what exactly error 25 even *is*, that'd be a good first step, heh...
<tsimonq2> ohh
<tsimonq2> Just had to look further up, jeez:
<tsimonq2> dh_acc: abi-compliance-checker -q -l libtelepathy-logger-qt-dev -v1 17.08.0-2build1 -dump debian/libtelepathy-logger-qt-dev.acc -dump-path debian/libtelepathy-logger-qt-dev/usr/lib/powerpc64le-linux-gnu/dh-acc/libtelepathy-logger-qt-dev_17.08.0-2build1.abi.tar.gz returned exit code 2
<tsimonq2> slangasek: How far did your debugging attempts go down the acc rabbit hole? :P
<slangasek> tsimonq2: I ran the autopkgtest and it didn't exit non-zero.
<slangasek> so there was no rabbit hole
<tsimonq2> I have a feeling if I passed -debug to acc it'll point directly a problem... if I had a porterbox I could just do it via shell, but I don't have a PPA big enough to copy over qtbase (bug 1789361) so I either need to wait for my PPA expansion request to be processed or use Bileto (which it isn't meant for)...
<ubot5> bug 1789361 in Auto Package Testing "When queueing tests against a PPA, if a trigger isn't found it should fall back to devel-proposed" [Undecided,New] https://launchpad.net/bugs/1789361
<tsimonq2> Oh.
<tsimonq2> So looks like the error can be easily found when retrying against itself, due to my no-change rebuild...
<tsimonq2> Mkay, so it *is* doable with a PPA then...
<tsimonq2> Hmm, this is a nice little TODO in the dh_acc code :P "# TODO if next command fails, should output debug/log info?"
<acheronuk> tsimonq2: you can get artifacts output. e.g. https://git.launchpad.net/~kubuntu-packagers/kubuntu-packaging/+git/khtml/tree/debian/tests/acc?h=kubuntu_cosmic_archive
<tsimonq2> acheronuk: TIL, thanks, but first I want to see if this acc hack works :P
<slangasek> figured out why armhf autopkgtest runners seemed to be going awol; we'd had a cowboyed edit to the cronjob to restart the runner systemd units hourly (and why do I not now find the related bug report?), and the lxd worker was recently reprovisioned so lost that bit.
<tsimonq2> acheronuk: Darn, just looked and it didn't... I'll try that.
<slangasek> so we should be back to not having a 3h window where armhf queues are not progressing.
<tsimonq2> \o/
<tsimonq2> acheronuk: This is actually super sweet... thanks.
<slangasek> hmmm that was https://bugs.launchpad.net/auto-package-testing/+bug/1735878 and it was reported closed.
<ubot5> Ubuntu bug 1735878 in Auto Package Testing "worker auto restarting should be handled by systemd unit, not by cronjob" [Medium,Fix released]
<acheronuk> tsimonq2: say that if if gives useful output for this ;)
<tsimonq2> acheronuk: hehe
<tsimonq2> acheronuk: It very likely will, it seems.
<slangasek> ... so the pkill was removed but the crontabs were never actually redeployed
<slangasek> I think this actually means the lxd worker wasn't actually redeployed recently... it was redeployed in May which means this was broken for a while until it got noticed
<tsimonq2> slangasek: So I found our error...
<tsimonq2> Creating library ABI dump ...
<tsimonq2> ERROR: can't pack the ABI dump: Cannot allocate memory
<tsimonq2> O_O
<tsimonq2> See https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic-tsimonq2-upload-testing/cosmic/ppc64el/t/telepathy-logger-qt/20180829_044637_96ed1@/artifacts.tar.gz
<tsimonq2> If it's truly an OOM issue, I'm not sure what the next step is here.
<tsimonq2> ...can someone with access to the infra cowboy a resource bump or something weird like that?
<tsimonq2> Â¯\_(ã)_/Â¯
<slangasek> tsimonq2: well, in theory that gives me a path to reproduce it, then I can look at what's taking memory and if it's fixable
<tsimonq2> slangasek: Awesome.
<slangasek> fwiw the ppc64el runners have 1.5GiB of total memory
<tsimonq2> hmm
<slangasek> acc is implemented in perl and it uses this much memory? sad
<tsimonq2> I'm willing to bet it's glibc's fault, fwiw. :P
<slangasek> highwatermark of memory usage for a-c-c on ppc64el is 768960k according to /usr/bin/time
<slangasek> tsimonq2: I've run the tests every which way; -proposed glibc is not a requirement for reproducing
<tsimonq2> huh
<tsimonq2> slangasek: But if there's 1.5 GB *total*, that means if there's any other test running it'll oom?
<slangasek> no
<slangasek> it's 1 autopkgtest per VM
<tsimonq2> ah
<slangasek> but other processes take up memory, so I'm not sure what the effective available memory is
<slangasek> tsimonq2: I just traced a running instance of the autopkgtest and there was never less than 840MB free on the node
<tsimonq2> O_o
<tsimonq2> I'm out of ideas if oom isn't it.
<tsimonq2> Maybe an acc bug if it's not that..
<slangasek> so I *can* make a-c-c OOM, but not in an autopkgtest runner context
<slangasek> the actual OOM happens when calling 'zip', hmm
<tsimonq2> Sounds about right: https://github.com/lvc/abi-compliance-checker/blob/master/abi-compliance-checker.pl#L9366
<slangasek> that's what I was going by
<tsimonq2> tar does seem more likely, which the code below has.
<slangasek> ah, zip is only used on windows, ok
<tsimonq2> Because that code's ran on Windows.
<tsimonq2> jinx
<slangasek> ah of course
<slangasek> clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x75b7f8544520) = -1 ENOMEM (Cannot allocate memory)
<slangasek> because forking tar means creating a copy of the process first and that process is oversized :P
<slangasek> freeing memory before invoking tar would fix it
<slangasek> and the failure should be generically reproducible with a cgroup (but not with ulimits, which was my first attempt)
<acheronuk> slangasek: suddenly getting some armhf tests fail with "mkdir: cannot create directory â//.configâ: Permission denied"
<acheronuk> any issue you know of?
<slangasek> no
<acheronuk> slangasek: ok. thanks. retried 1, and it passed. retrying another but takes a while.
-queuebot:#ubuntu-release- Unapproved: brltty (bionic-proposed/main) [5.5-4ubuntu2 => 5.5-4ubuntu2.0.1] (core)
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1018.21] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-135.161] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1018.21]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-135.161]
-queuebot:#ubuntu-release- Unapproved: avahi (bionic-proposed/main) [0.7-3.1ubuntu1 => 0.7-3.1ubuntu1.1] (core)
-queuebot:#ubuntu-release- New binary: python-cffi [amd64] (cosmic-proposed/main) [1.11.5-2] (kubuntu, ubuntu-desktop, ubuntu-server)
<rbalint> LocutusOfBorg, it seems erlang now can be a sync, how do you feel about updating it for cosmic? Debian changes are mostly bugfix releases
<LocutusOfBorg> rbalint, ack
<LocutusOfBorg> can you please double check why is it a sync?
-queuebot:#ubuntu-release- Unapproved: glib2.0 (bionic-proposed/main) [2.56.1-2ubuntu1 => 2.56.2-0ubuntu0.18.04.1] (core) (sync)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-135.161~14.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-135.161~14.04.1]
-queuebot:#ubuntu-release- New: accepted cmake-vala [sync] (cosmic-proposed) [1-1]
-queuebot:#ubuntu-release- New: accepted ironic [amd64] (cosmic-proposed) [1:11.1.0-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted libminc [arm64] (cosmic-proposed) [2.4.03-1]
-queuebot:#ubuntu-release- New: accepted libminc [i386] (cosmic-proposed) [2.4.03-1]
-queuebot:#ubuntu-release- New: accepted libminc [s390x] (cosmic-proposed) [2.4.03-1]
-queuebot:#ubuntu-release- New: accepted libreoffice [arm64] (cosmic-proposed) [1:6.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libreoffice [i386] (cosmic-proposed) [1:6.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libreoffice [s390x] (cosmic-proposed) [1:6.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted murano-agent [amd64] (cosmic-proposed) [1:3.5.1-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted panko [amd64] (cosmic-proposed) [5.0.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted ironic [amd64] (cosmic-proposed) [1:11.1.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted libminc [armhf] (cosmic-proposed) [2.4.03-1]
-queuebot:#ubuntu-release- New: accepted libreoffice [amd64] (cosmic-proposed) [1:6.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libreoffice [ppc64el] (cosmic-proposed) [1:6.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted node-csv-spectrum [sync] (cosmic-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted python-cffi [amd64] (cosmic-proposed) [1.11.5-2]
-queuebot:#ubuntu-release- New: accepted libminc [amd64] (cosmic-proposed) [2.4.03-1]
-queuebot:#ubuntu-release- New: accepted libreoffice [armhf] (cosmic-proposed) [1:6.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted panko [amd64] (cosmic-proposed) [5.0.0-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted libminc [ppc64el] (cosmic-proposed) [2.4.03-1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-7 [sync] (cosmic-proposed) [1:7~+rc2-1~exp1]
-queuebot:#ubuntu-release- New binary: node-csv-spectrum [amd64] (cosmic-proposed/universe) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted node-csv-spectrum [amd64] (cosmic-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [4.15.0-1019.20] (no packageset)
<ahasenack> anybody looking at the twisted migration?
<ahasenack> I could help perhaps
<ahasenack> current version in cosmic (17.x) fails with py3.7, the new one has that fixed
<ahasenack> or at least that particular failure
<ahasenack> ugh, http://autopkgtest.ubuntu.com/packages/t/twisted/cosmic/amd64 has one lonely green only, from 2017
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [4.15.0-1019.20]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [4.15.0-1023.24] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-34.37~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-34.37~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-34.37~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-34.37~16.04.1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (bionic-proposed/main) [1:18.04.24 => 1:18.04.25] (core)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (bionic-proposed) [1:18.04.25]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (bionic-proposed) [1.4+18.04ubuntu2]
<infinity> xnox, bdmurray: ^--- Can we verify that (a) s390x now works and (b) snap migration on amd64 still works?  If both are actually tested, I'm happy with that SRU being fasttracked post-verification.
<bdmurray> infinity: Sure I can test the snap migration still working bit.
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (xenial-proposed) [1.4+16.04ubuntu2]
<infinity> slangasek: Did you look at all into the python-cffi/i386 thing?
<infinity> slangasek: Just to make sure glibc isn't off the deepend, I did this: https://paste.ubuntu.com/p/VRXRzT9gKK/
<slangasek> infinity: no; did mwhudson mutter about it? I don't recall now
<infinity> slangasek: So now very curious where it's pulling NaN from.
<infinity> slangasek: Oh.  So it does that cos(1.23) in two dlopen tests, and it's only one (dlopen_filename) that's returning NaN, so I think what it's actually doing is failing to dlopen by path.
<infinity> Which also seems weird, but slightly easier to debug.
<infinity> Maybe.
<xnox> infinity, do-release-upgrade xenial->bionic fails; do-release-upgrade --proposed xenial->bionic goes past that point and is downloading all the things for me. So I can reproduce original bug; and proposed stuff fixes everything.
<xnox> on s390x
<infinity> xnox: Shiny.  Tell the bug, please.
<infinity> xnox: Though maybe without the --proposed thing, don't want IBM people telling their customers that's how to upgrade. :P
<xnox> hahahhahhaha
<xnox> infinity, the bug is commented
<infinity> Ta.
<xnox> slangasek, ubuntu-cloud-keyring binary from ubuntu-keyring needs to move from universe to main; it is seeded in bionic and cosmic. cosmic is easy.
<xnox> slangasek, but i don't know if there is components-missmatch report for bionic, or how to copy/publish it from bionic-release/universe to bionic-security|updates/main ?
<infinity> slangasek: There is no c-m for stable series.  And the copy trick needs to be done by an AA.
<infinity> Err.
<infinity> xnox: ^
<infinity> No can brain.
<xnox> infinity, yeah, that's what a vague recalled, but this happens to me only once every 4 years, so details are fuzzy.
<xnox> vaguely
<xnox> anyway volleyball
<infinity> xnox: I'm a bit confused.
<infinity> xnox: Oh.  Less confused now.
-queuebot:#ubuntu-release- New binary: llvm-toolchain-7 [ppc64el] (cosmic-proposed/universe) [1:7~+rc2-1~exp2] (no packageset)
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-7 [ppc64el] (cosmic-proposed) [1:7~+rc2-1~exp2]
<slangasek> infinity: btw telepathy-logger-qt/ppc64el is definitely ignorable, if we get to that point.  hitting the threshold where abi-compliance-checker uses > 50% of free memory in the testbed is not a regression in any of the involved packages
<infinity> slangasek: Fun.
<slangasek> (I'm trying to work around the failure in a-c-c, but perl)
<infinity> One has to write some spastically bad Perl to eat all your RAM.
<infinity> https://accidentallyquadratic.tumblr.com/ ?
<slangasek> it's using Data::Dumper for the objects that represent the complete ABI of a very dense C++ lib
<slangasek> so yes, that's less than ideal
<slangasek> but I'm not going to refactor that code to teach it how to stream to a file
<bdmurray> infinity: xnox and I have verified bug 1787668
<ubot5> bug 1787668 in Ubuntu on IBM z Systems "ubuntu-release-upgrader crashed with KeyError: "The cache has no package named 'ubuntu-desktop'"" [High,In progress] https://launchpad.net/bugs/1787668
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1023.24~16.04.1] (kernel)
<infinity> bdmurray: Danke.  Releasing.
-queuebot:#ubuntu-release- New binary: llvm-toolchain-7 [amd64] (cosmic-proposed/universe) [1:7~+rc2-1~exp2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fwupdate (cosmic-proposed/main) [12-3ubuntu1 => 12-3ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: fwupdate (cosmic-proposed/main) [12-3ubuntu1 => 12-3ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: fwupdate (cosmic-proposed/main) [12-3ubuntu1 => 12-3ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: fwupdate (cosmic-proposed/main) [12-3ubuntu1 => 12-3ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: fpc (bionic-proposed/universe) [3.0.4+dfsg-18ubuntu1 => 3.0.4+dfsg-18ubuntu2] (no packageset)
<cyphermox> ugh, fwupdate probably shouldn't have been uploaded at all
<cyphermox> slangasek: infinity: do you recall what the state is for fwupdate vs. fwupd?
<slangasek> cyphermox: I've said that going forward we will not sign uefi binaries for the unseeded one; however I see that both are in main, I could've sworn I had already processed that demotion
<slangasek> I did remove fwupdate-signed
<slangasek> fwupdate needs fixed to not spit out uefi signing requests
<mwhudson> infinity, slangasek: i haven't looked at cffi
-queuebot:#ubuntu-release- Unapproved: rejected fwupdate [amd64] (cosmic-proposed) [12-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected fwupdate [armhf] (cosmic-proposed) [12-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected fwupdate [arm64] (cosmic-proposed) [12-3ubuntu1]
<slangasek> cyphermox: so, I've rejected the above
-queuebot:#ubuntu-release- Unapproved: rejected fwupdate [i386] (cosmic-proposed) [12-3ubuntu1]
<mwhudson> i can, in a couple hours, if you want
<mwhudson> i still hate everything about scipy and am going to ignore that today so i actually achieve something
<cyphermox> slangasek: ok
<cyphermox> slangasek: can you block shim-signed 1.37 in proposed? LP is timing out here...
<cyphermox> maybe I'm being extra paranoid, but I wouldn't mind just breaking my system if it turns out I made some error.
<cyphermox> nvm, got LP to let me do what I want after all
<slangasek> ok
<xnox> slangasek, infinity - so can one of you please promote ubuntu-cloud-kerying into bionic-updates/main somehow?
<xnox> slangasek, infinity - so can one of you please promote ubuntu-cloud-keyring into bionic-updates/main somehow?
<slangasek> xnox: what references it in bionic?
<xnox> same thing as in cosmic, supported-misc-servers
<xnox> but no reports...
<slangasek> copying
<slangasek> and promoted
<slangasek> cyphermox: I see shim-signed having migrated to cosmic, was that what you expected?
<cyphermox> nah
<cyphermox> but it's fine
<cyphermox> everything can migrate.
<xnox> slangasek, linux-image-generic|lowlatency|oem do not depend on intel-microcode in bionic. still.
<xnox> they appear to do so in cosmic.
<xnox> slangasek, is this expected?!
<slangasek> xnox: which version? I see the dep from 4.15.0.33.35 linux-image-generic in bionic
<xnox> reverse-depends -r bionic intel-microcode must be telling me lies then!
<xnox> let me finish upgrading this instance and double check with apt
<slangasek> xnox: does reverse-depends know about -updates?
<xnox> slangasek, yeah, it's there, thanks!
#ubuntu-release 2018-08-30
<tsimonq2> slangasek: Do you typically require bugs for demotion to -proposed?
<tsimonq2> slangasek: node-grunt-contrib-concat should be demoted so node-source-map can migrate (along with a few rdeps).
<tsimonq2> slangasek: Debian bug 878337, https://github.com/gruntjs/grunt-contrib-concat/issues/188
<gitbot> gruntjs issue 188 in grunt-contrib-concat "update for source-map 0.7.x" [Open]
<ubot5> Debian bug 878337 in src:node-grunt-contrib-concat "node-grunt-contrib-concat: FTBFS and Debci failure with node-source-map 0.6" [Serious,Open] http://bugs.debian.org/878337
<tsimonq2> https://launchpad.net/ubuntu/+source/node-d3-request/1.0.6-3/+build/14813077 O_o wat?
<tsimonq2> "Build for superseded Source"
<tsimonq2> slangasek: Perhaps even completely remove node-d3-request and node-d3-hierarchy, depending on what this error is. :P
<tsimonq2> vim-youcompleteme could be removed as well; ycmd doesn't look like it'll be fixed anytime soon (isn't even in Cosmic at all).
<cjwatson> The build must have been superseded when it was previously removed from cosmic-proposed.
<cjwatson> Retrying such a build works now that it has an active publishing record again, though.  I've done that.
<tsimonq2> Huh.
<tsimonq2> That's a new one (for me).
<cjwatson> The package was probably removed when the build wasn't in a terminal state.
<cjwatson> Somewhat unusual but happens occasionally.
<tsimonq2> Ah.
<cjwatson> (Or, more specifically, when it was in "Needs building".)
<cjwatson> That state more usually happens when the source package is superseded by a newer version (hence the name) before the previous builds had been dispatched.
-queuebot:#ubuntu-release- New binary: node-d3-request [amd64] (cosmic-proposed/universe) [1.0.6-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted node-d3-request [amd64] (cosmic-proposed) [1.0.6-3]
<tsimonq2> cjwatson: Could you do binary NEW processing on the other package when it goes in the queue as well?
<tsimonq2> node-d3-hierarchy
-queuebot:#ubuntu-release- New binary: node-d3-hierarchy [amd64] (cosmic-proposed/universe) [1.1.5-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-7 [amd64] (cosmic-proposed) [1:7~+rc2-1~exp2]
-queuebot:#ubuntu-release- New: accepted node-d3-hierarchy [amd64] (cosmic-proposed) [1.1.5-2]
<slangasek> tsimonq2: I don't typically /do/ demotions to proposed; if it's bad enough to be removed from release I usually don't want it hanging around in -proposed either
<tsimonq2> slangasek: Ah.
<slangasek> tsimonq2: node-grunt-contrib-concat has 5 reverse-build-dependencies, I'm not going to remove it without a plan for sorting those
<tsimonq2> slangasek: ack
-queuebot:#ubuntu-release- Unapproved: tkblt (bionic-proposed/universe) [3.2.7-1 => 3.2.7-1ubuntu1] (no packageset)
<acheronuk> [07:20] <acheronuk> slangasek: suddenly getting some armhf tests fail with "mkdir: cannot create directory â//.configâ: Permission denied"
<acheronuk> another http://autopkgtest.ubuntu.com/packages/k/kcoreaddons/cosmic/armhf
<acheronuk> thinking home is / by the looks of it
<acheronuk> something amiss with armhf runners
<jibel> The pending sru report is out of date (last update 2 days ago), could someone have a look?
<tsimonq2> cjwatson: ^ This wouldn't happen to be related to MoM, would it?
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [4.15.0-1023.24]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1023.24~16.04.1]
<cjwatson> tsimonq2: no, they're pretty independent
<cjwatson> jibel: I've killed the stuck run, so it should recover soon
<jibel> cjwatson, thanks
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (bionic-proposed/main) [1.1ubuntu1.18.04.5 => 1.1ubuntu1.18.04.6] (desktop-core, ubuntu-server)
<LocutusOfBorg> infinity, hello, diaspora-installer is regressed testsuite, because of glibc
<LocutusOfBorg> unfortunately testsuite is downloading a gem file from internet, and there is no new upstream version...
<LocutusOfBorg> what do you propose?
<LocutusOfBorg> the result seems clear: linux_sigar.c:1177:22: error: called object âmajorâ is not a function or
<LocutusOfBorg> of course release pocket is fine because of old glibc
<LocutusOfBorg> I'm testing diaspora-installer from debian
-queuebot:#ubuntu-release- Unapproved: rejected magnum [source] (bionic-proposed) [6.1.1-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected magnum [source] (bionic-proposed) [6.1.1-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected magnum [source] (bionic-proposed) [6.1.1-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (bionic-proposed) [10.1ubuntu2.3]
<slashd> o/ sil2100, can you please release gdm3 for 'X' when you have a moment today | LP: #1782152 ?
<ubot5> Launchpad bug 1782152 in gdm3 (Ubuntu Bionic) "GDM blocks SIGUSR1 used in PAM scripts" [Medium,Fix committed] https://launchpad.net/bugs/1782152
<slashd> sil2100, and 'python-urllib3' for 'X' as well | LP: #1771988
<ubot5> Launchpad bug 1771988 in Ubuntu Cloud Archive mitaka "certificate validation with IP address based SAN's fails" [High,In progress] https://launchpad.net/bugs/1771988
<sil2100> slashd: hey! I'll take a look after lunch, my problem with gdm3 when I was doing releases in the morning was that bionic isn't verified yet - e.g. there's 3 bugs in it but 2 not verified yet
<sil2100> slashd: usually we want later series to be released - not a hard rule though
-queuebot:#ubuntu-release- Unapproved: libreoffice (bionic-proposed/main) [1:6.0.3-0ubuntu1 => 1:6.0.6-0ubuntu0.18.04.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: ubuntu-report (bionic-proposed/main) [1.2.0~bionic => 1.3.0~18.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libreoffice-l10n (bionic-proposed/main) [1:6.0.3-0ubuntu1 => 1:6.0.6-0ubuntu0.18.04.1] (ubuntu-desktop)
<slashd> sil2100, tks for python-urllib3
<sil2100> slashd: as for gdm3... I would prefer to wait for bionic in this case, especially that it's a new upstream release
<sil2100> So even though small, there's a risk it might introduce some regressions and actually get removed from -proposed
<sil2100> Problem is I think Lan_ey is away this week still, so someone else would have to verify it
<slashd> sil2100, ack thanks
<slashd> dgadomski, fyi ^
-queuebot:#ubuntu-release- Unapproved: accepted maas [source] (bionic-proposed) [2.4.2-7034-g2f5deb8b8-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (bionic-proposed) [18.04.14.8]
-queuebot:#ubuntu-release- Unapproved: accepted qtdeclarative-opensource-src [source] (bionic-proposed) [5.9.5-0ubuntu1.1]
<Trevinho> sil2100: hey, could you please accept glib from bionic queue?
<Trevinho> actually I've an extra fix on https://bileto.ubuntu.com/#/ticket/3393 but needs to be published first
<sil2100> Trevinho: ok, I'll get to it in a minute
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.7 => 2.525.8] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (bionic-proposed) [2.525.8]
<LocutusOfBorg> any AA wants to fix this? https://bugs.launchpad.net/ubuntu/+source/anbox/+bug/1780655
<ubot5> Ubuntu bug 1780655 in anbox (Ubuntu) "RoM: please remove this from ubuntu, doesn't work" [Undecided,New]
<Trevinho> sil2100: thanks
<Trevinho> also if you can land that ppa would be nice :)
<Trevinho> so we get both in a shot
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.525.8]
<sil2100> Trevinho: so just to know for sure, you want to overwrite the upload that's in Unapproved with the one in the silo?
<Trevinho> sil2100: if that's possible yes, otherwise we can reiterate later
<Trevinho> but I was waiting upstream to apply that patch before adding it, now it's merged, so...
<sil2100> I need to see how the .changes file looks
<sil2100> Since I guess right now if I publish this, the SRU tools will miss the previous upload
<sil2100> Because the .changes file was generated without -v, so no mention of .1 in it
-queuebot:#ubuntu-release- Unapproved: accepted unbound [source] (bionic-proposed) [1.6.7-1ubuntu2.2]
<sil2100> Trevinho: ok, in this case I can either review the one that's already in the queue or I guess I'd have to ask you prepare a new upload that would include both the fixes
<sil2100> (or have both versions mentioned in the .changes file)
<Trevinho> sil2100: well, so go with queue, I'll prepare the sru of the other later
<Trevinho> as i also wanted to mention the commit in the dep
<sil2100> Trevinho: ok!
-queuebot:#ubuntu-release- Unapproved: binutils (xenial-proposed/main) [2.26.1-1ubuntu1~16.04.6 => 2.26.1-1ubuntu1~16.04.7] (core)
-queuebot:#ubuntu-release- New binary: vmware-nsx [amd64] (cosmic-proposed/universe) [13.0.0-0ubuntu1] (no packageset)
<seb128> Trevinho, it reminds me we need to reupload your nautilus SRU that got rejected because the version was not "standard enough" :/
<Trevinho> seb128: at this point if you want to wait for the search fix....
<seb128> no
<seb128> because that's another set of packages
<seb128> and I don't want to make the SRU too complicated
<seb128> I would prefer the search fix set to be that onlu
<seb128> only
<Trevinho> ok
<seb128> Trevinho, can you "fix"/amend the bionic branch in git to what it should
<seb128> your git foo is better than mine, I would probably manage after some googling and poking around, but "uncommit" is not something I know how to do properly yet
<seb128> shrug, it's annoying that we delay fixes for our LTS users and create work for ourself just to be pedentic of versioning
<seb128> but oh well, let's keep the ranting for another day
<ahasenack> any idea why txtorcon is "missing build"? 18.0.2-2 build on Aug 21st http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#txtorcon
<ahasenack> oh, it's looking for a "python-txtorcon" deb...
<seb128> ahasenack, because it is, see the changelog on https://launchpad.net/ubuntu/+source/txtorcon/18.0.2-2
<seb128>   * No longer builds a Python 2 package (Closes: #905253)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (bionic-proposed/main) [1.93.4 => 1.93.5] (core)
<seb128> that binary needs to be deleted from cosmic if it has no rdepends
<ahasenack> so it needs a manual poke when a deb goes missing
<seb128> reverse-depends lists ooniprobe though
<seb128> so that might need to be fixed first
<sergiusens> sil2100: evening! I have a request for you if you can spare the moment, mind taking a look at getting snapcraft into the -updates (LP: #1787419)?
<ubot5> Launchpad bug 1787419 in snapcraft (Ubuntu Bionic) "[SRU] New stable micro release 2.43" [Undecided,Fix committed] https://launchpad.net/bugs/1787419
<ahasenack> seb128: thanks
<seb128> ahasenack, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905211 is a request to remove that one from Debian, maybe the path to go
<ubot5> Debian bug 905211 in ftp.debian.org "RM: ooniprobe -- ROM; not easily maintained; too many js deps" [Normal,Open]
<seb128> yw!
<ahasenack> that is blocking twisted now
<ahasenack> after a long chain of deps
<ahasenack> iiuic
<sil2100> sergiusens: sure!
<ahasenack> twisted -> foolscap -> txtorcon
<seb128> should be fine to rm ooniprobe and python-txtorcon
<sergiusens> sil2100: as always, thank you very much!
<slangasek> acheronuk: tests shouldn't be writing to $HOME anyway, this would be a buggy test, not a broken test runner
<slangasek> acheronuk: if the software requires $HOME to be set somewhere sane, then it should be pointed somewhere in the tree by the test itself
<acheronuk> slangasek: it is https://git.launchpad.net/~kubuntu-packagers/kubuntu-packaging/+git/kcoreaddons/tree/debian/tests/testsuite?h=kubuntu_cosmic_archive
<acheronuk> but clearly the armhf runners have changed so if is skipping that with a home of / it can't write to
<acheronuk> slangasek: test for update manager on armf are also sometimes getting the same
<acheronuk> slangasek: mkdir() failed: '[Errno 13] Permission denied: '/.cache''.
<slangasek> acheronuk: yes, it's categorically wrong to use a $HOME from the environment in a package build or autopkgtest
<acheronuk> slangasek: I can change kde tests not to, but I can't for update-manager
<slangasek> well, Foundations should certainly fix our bug also :)
<slangasek> bdmurray: ^^ ?
<bdmurray> slangasek: update-manager uses $HOME in its autopkgtests is that correct?
<acheronuk> bdmurray: it's filing some tests with "mkdir() failed: '[Errno 13] Permission denied: '/.cache''."
<acheronuk> *failing
<slangasek> bdmurray: sounds like it's relying on $HOME from the caller environment yes, and it shouldn't; it should set its own local $HOME for use
<acheronuk> not sure of the package's fault or somthing like pytest/nose
<acheronuk> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/armhf/u/update-manager/20180829_133612_1ecf1@/artifacts.tar.gz
<acheronuk> nose-tests-stout with the error
<acheronuk> again, only on armhf
<acheronuk> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/armhf/u/update-manager/20180829_133612_1ecf1@/log.gz
-queuebot:#ubuntu-release- Unapproved: debian-installer (trusty-proposed/main) [20101020ubuntu318.43 => 20101020ubuntu318.44] (core)
<bdmurray> xnox: Can you add SRU info to bug 1781242?
<ubot5> bug 1781242 in Ubuntu on IBM z Systems "as segfault with invalid -march= option" [Low,In progress] https://launchpad.net/bugs/1781242
-queuebot:#ubuntu-release- Unapproved: accepted glib2.0 [sync] (bionic-proposed) [2.56.2-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted network-manager-openconnect [source] (bionic-proposed) [1.2.4-1ubuntu1]
<jbicha> bdmurray: sorry about the ridiculous 16.4 MB diff for fonts-noto-color-emoji/bionic
<bdmurray> jbicha: Its so ridiculous I'm going to save it for last
-queuebot:#ubuntu-release- Unapproved: accepted nova-lxd [source] (bionic-proposed) [17.0.1-0ubuntu1]
<jbicha> no problem
-queuebot:#ubuntu-release- Unapproved: accepted avahi [source] (bionic-proposed) [0.7-3.1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted fpc [source] (bionic-proposed) [3.0.4+dfsg-18ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted tkblt [source] (bionic-proposed) [3.2.7-1ubuntu1]
<bdmurray> rbalint: Can you add SRU info to bug 1785093?
<ubot5> bug 1785093 in unattended-upgrades (Ubuntu) "RecursionError error in call_adjusted() when package is pinned < 100" [Undecided,Fix released] https://launchpad.net/bugs/1785093
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-report [source] (bionic-proposed) [1.3.0~18.04]
<bdmurray> jbicha: Could you add some more details to the regression potential of that fonts-noto-color-emoji bug?
<jbicha> do you have suggestions? that part of an SRU is the hardest for me to come up with something that feels useful
<jbicha> my point there was that Google ships this to their customers. But we are rebuilding it so our version isn't necessarily exactly what they test and release
<rbalint> bdmurray, updated the SRU, but the test is missing for now because i suspected pinning to be the trigger but it turned reading (down-)pinning did not work in python-apt basically at all
<bdmurray> jbicha: What could go wrong in the rebuild process? How would we know something was busted?
<jbicha> there is a test case
<jbicha> I've never seen a problem building it yet
<jbicha> do you like the regression potential in bug 1766736? ð¤  (it was accepted before release so wasn't an SRU)
<ubot5> bug 1766736 in fonts-noto-color-emoji (Ubuntu Bionic) "Update Noto Emoji to April 2018" [Low,Fix released] https://launchpad.net/bugs/1766736
<bdmurray> jbicha: The Regression Potential is an estimate of severity or likelihood rather what could go wrong and how can we watch out for it.
<bdmurray> s/is/isn't/
<jbicha> I added a sentence now. Sorry if I seem to be making this difficult :(
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (cosmic-proposed/main) [4.18.0-7.8] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (cosmic-proposed/main) [4.18.0-7.8] (core, kernel)
<slangasek> someone here know why lubuntu images failed with a complaint that libreoffice-kde4 is not installable (which indeed it is not, it is only in cosmic-proposed)?
<slangasek> has someone been removing binaries that have revdeps?
<slangasek> perhaps this was meant to be removal of the NBS libreoffice-kde4 binary that's in cosmic-proposed
 * slangasek attempts to resuscitate
<tsimonq2> That's interesting, because we depend on libreoffice-kde, not kde4, because the kde5 one should (!) land either in this cycle or next.
<tsimonq2> Thanks slangasek.
<tsimonq2> Oh, so it *did* land, and it's in -proposed...
<tsimonq2> Nice.
<slangasek> yeah, seb128 removed the wrong one by mistake (https://launchpad.net/ubuntu/cosmic/amd64/libreoffice-kde4)
<tsimonq2> Ah.
<acheronuk> linux-image-generic/amd64 unsatisfiable Depends: linux-image-4.18.0-7-generic
<acheronuk> not good
<slangasek> why are you pulling from cosmic-proposed?
<acheronuk> pulling what?
<slangasek> acheronuk: linux-image-generic
<acheronuk> was a test failure: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/amd64/a/akonadi-search/20180830_223519_e60a9@/log.gz
<slangasek> ok
<slangasek> so pulling from cosmic-proposed because --all-proposed, fair enough :)
<slangasek> should be fixable with a retry
<acheronuk> well, I triggered against several package versions in -proposed instead. but if that fixing itself anyway, then :)
#ubuntu-release 2018-08-31
<xnox> bdmurray, re bug 1781242 -> done
<ubot5> bug 1781242 in Ubuntu on IBM z Systems "as segfault with invalid -march= option" [Low,In progress] https://launchpad.net/bugs/1781242
-queuebot:#ubuntu-release- New binary: knot [s390x] (cosmic-proposed/universe) [2.7.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: knot [ppc64el] (cosmic-proposed/universe) [2.7.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: knot [amd64] (cosmic-proposed/universe) [2.7.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: knot [armhf] (cosmic-proposed/universe) [2.7.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: knot [arm64] (cosmic-proposed/universe) [2.7.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: knot [i386] (cosmic-proposed/universe) [2.7.2-2] (no packageset)
<mwhudson> slangasek: fwiw i'm planning on doing proposed-migration things on monday so feel free to highlight me with anything you think i should look at
<mwhudson> infinity: you too ^
<mwhudson> infinity: i'll look at that r-cran-rgenoud thing first probably
<slangasek> mwhudson: on Monday> I'm sure it'll look all different by then ;)
<tsimonq2> Maybe glibc will be migrated? *cough* ;)
-queuebot:#ubuntu-release- New: accepted knot [amd64] (cosmic-proposed) [2.7.2-2]
-queuebot:#ubuntu-release- New: accepted knot [armhf] (cosmic-proposed) [2.7.2-2]
-queuebot:#ubuntu-release- New: accepted knot [ppc64el] (cosmic-proposed) [2.7.2-2]
-queuebot:#ubuntu-release- New: accepted knot [arm64] (cosmic-proposed) [2.7.2-2]
-queuebot:#ubuntu-release- New: accepted knot [s390x] (cosmic-proposed) [2.7.2-2]
-queuebot:#ubuntu-release- New: accepted knot [i386] (cosmic-proposed) [2.7.2-2]
<acheronuk> slangasek: kernel uninstallability in -proposed didn't sort itself then?
<acheronuk> :/
<slangasek> I don't know of any reason it hasn't
<slangasek> ah because linux-signed is still stuck in NEW
<slangasek> the efi blobs got accepted but not the packages, sorry
<acheronuk> aha. right
<slangasek> fixed now; allow a bit for publishing
<acheronuk> great. thanks
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (cosmic-proposed) [4.18.0-7.8]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (cosmic-proposed) [4.18.0-7.8]
-queuebot:#ubuntu-release- New binary: ros-pcl-msgs [amd64] (cosmic-proposed/universe) [0.2.0-8] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-dynamic-reconfigure [amd64] (cosmic-proposed/universe) [1.5.49-4] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-navigation-msgs [amd64] (cosmic-proposed/universe) [1.13.0-8] (no packageset)
-queuebot:#ubuntu-release- New binary: knot-resolver [ppc64el] (cosmic-proposed/universe) [3.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: knot-resolver [i386] (cosmic-proposed/universe) [3.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1019.20~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: knot-resolver [armhf] (cosmic-proposed/universe) [3.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: knot-resolver [amd64] (cosmic-proposed/universe) [3.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: knot-resolver [arm64] (cosmic-proposed/universe) [3.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1019.20~16.04.1]
<LocutusOfBorg> hello, ping wrt diaspora-installer test hints
<LocutusOfBorg> slangasek, cminpack is the last glibc blocker, and testsuite seems flaky enough on almost all architectures, with combo that is a dead upstream.... hint?
<LocutusOfBorg> they seems to be the usual "floating point precision issues" that comes with every new glibc
<LocutusOfBorg> we might fix the testsuite by updating the numbers, but I don't know how to double check the math behind with another tool
<LocutusOfBorg> for sure a change from 1.8410966e-16 to 1.4686870e-16 is not that important, (did anybody really care about this precision level?)
<LocutusOfBorg> infinity, ^^
-queuebot:#ubuntu-release- New: accepted knot-resolver [amd64] (cosmic-proposed) [3.0.0-2]
-queuebot:#ubuntu-release- New: accepted knot-resolver [armhf] (cosmic-proposed) [3.0.0-2]
-queuebot:#ubuntu-release- New: accepted knot-resolver [ppc64el] (cosmic-proposed) [3.0.0-2]
-queuebot:#ubuntu-release- New: accepted ros-navigation-msgs [amd64] (cosmic-proposed) [1.13.0-8]
-queuebot:#ubuntu-release- New: accepted knot-resolver [arm64] (cosmic-proposed) [3.0.0-2]
-queuebot:#ubuntu-release- New: accepted ros-dynamic-reconfigure [amd64] (cosmic-proposed) [1.5.49-4]
-queuebot:#ubuntu-release- New: accepted knot-resolver [i386] (cosmic-proposed) [3.0.0-2]
-queuebot:#ubuntu-release- New: accepted ros-pcl-msgs [amd64] (cosmic-proposed) [0.2.0-8]
<LocutusOfBorg> infinity,  here you have your disapora-installer testsuite regression with new glibc http://autopkgtest.ubuntu.com/packages/diaspora-installer
<xnox> LocutusOfBorg, well, clearly the bug is upstream.... and sigar bit needs upgrading.
<xnox> no?
<xnox> hmmm but there is no new sigar....
<LocutusOfBorg> xnox, exactly
<LocutusOfBorg> we can't easily patch something that downloads broken stuff from the internet I would say
<LocutusOfBorg> I can open a sigar bug, but that is all
<xnox> rubygems doesn't have like, inline patch functionality or something? =) to like patch things on the fly.
<xnox> or like fail, patch things inline, continue build =)
<LocutusOfBorg> who speaks ruby? :) I don't!
<smb> Would/could someone get the systemd/i386 failure on http://people.canonical.com/~ubuntu-archive/proposed-migration/cosmic/update_excuses.html#iproute2 overridden/ignored? From the various logs it fails for different reasons than iproute2 changes
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (trusty-proposed) [20101020ubuntu318.44]
<slashd> mfo, ^ d-i will start building in trusty-proposed
<mfo> slashd, cool, thanks for the ping!
<slashd> mfo, there will be some delay for 'd-i', it failed to build due to following bug : https://bugs.launchpad.net/ubuntu/+source/shim/+bug/1708245
<ubot5> Ubuntu bug 1708245 in shim (Ubuntu Artful) "shim can't enable validation and enroll keys in one sitting" [Undecided,Fix committed]
<slashd> amd64 only failed ^
<slashd> mfo, once that bug fix, you can request the rebuild of 'd-i' for amd64
<mfo> slashd, ack. interesting, there's no trusty track for the shim/signed bug. i'll take a look.
<teward> remind me if we're under FeatureFreeze, should I upload *and* file the FFe bug?
<teward> or should I file the bug and wait for the approval>?
<teward> (this is for NGINX)
-queuebot:#ubuntu-release- New binary: neutron-taas [amd64] (cosmic-proposed/universe) [4.0.0~a1~git2018083141.84846d5-0ubuntu1] (no packageset)
<LocutusOfBorg> xpdf fixed! poppler is now ok
<xnox> slangasek, infinity - any difference in e-16 is irrelevant, and is in fact encoding specific glibc version / cpu values. Hence it never passed on other arches.
<xnox> imho cminpack should be overriden, cause the value changes are insignificant. or e.g. do you want to update assertions for all of our achres to have it always green?
<xnox> it would need to be refreshed with next major compiler/glibc/-lm changes
<xnox> doko, https://bitbucket.org/cffi/cffi/issues/378/float-test-failures-with-gcc8-on-ppc64el should this be escalated to gcc ppc64el maintainers?
<slangasek> xnox: can you offer a citation for this claim re: cminpack?  because previously an amd64 it passed with glibc 2.21-2.27, not a single autopkgtest failure back to xenial
<xnox> slangasek, correct. but the test suite difference are beyond the architecture precision capabilities...
<xnox> slangasek, i can study that futher.
<slangasek> xnox: I'm fp-dumb, but if you can provide a reference for this "beyond the architecture precision capabilities" I will override
<slangasek> (we should file a bug against the package in Debian at the same time)
<slangasek> LocutusOfBorg: and in what sense is cminpack the last blocker? there are 5 autopkgtest regressions reported on update_excuses
<slangasek> xnox: retried all the failed systemd-triggered tests so far; nothing particularly interesting there, a couple flaky and some needing --all-proposed or similar
<slangasek> (glibc entanglement, basically)
<LocutusOfBorg> slangasek, indeed, I missed them because too huge queue, perl and glibc are tricky to look at
<LocutusOfBorg> btw some stuff still needs rebuilds, e.g. dante and something else
-queuebot:#ubuntu-release- Unapproved: gnome-flashback (bionic-proposed/universe) [3.28.0-1ubuntu1 => 3.28.0-1ubuntu1.1] (edubuntu)
<slangasek> LocutusOfBorg: bro; apitrace; unscd; dante.  Done.
<xnox> slangasek, infinity - i hate that all udebs get >= latest glibc dep by default instead of proper >= acient-glibc-any-ubuntu-provides based on shlibdeps
<xnox> and hence getting stuck behind glibc, needlessly.
<slangasek> xnox: I have a solution for that, it begins with s and ends with biquity
<bdmurray> slangasek: https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/ubuntu-security-bugs/+merge/354138
-queuebot:#ubuntu-release- Unapproved: accepted nodejs [source] (bionic-proposed) [8.10.0~dfsg-2ubuntu0.3]
<slangasek> bdmurray: landed, thanks
<LocutusOfBorg> dante was already good but meh, thanks!
<slangasek> LocutusOfBorg: heh, ok
<slangasek> xnox: wow, very interesting failure in the open-iscsi autopkgtest w/ --all-proposed, it appears to implicate finalrd + liblz4?
<slangasek> xnox: or like, systemd's own lib deps fail to be copied to the finalrd for /lib/systemd/systemd-shutdown ?
<LocutusOfBorg>     * amd64: ayatana-indicator-printers, bluez-cups, boomaga, cloudprint, cloudprint-service, cups, cups-core-drivers, cups-filters, cups-filters-core-drivers, cups-tea4cups, cups-x2go, hplip, hplip-gui, indicator-printers, lsb, lsb-printing, lubuntu-desktop, minc-tools, pdf2djvu, printer-driver-all-enforce, printer-driver-cups-pdf, printer-driver-gutenprint, printer-driver-hpcups, printer-driver-postscript-hp,
<LocutusOfBorg> printer-driver-splix, ubuntu-mate-core, ubuntu-mate-desktop
<LocutusOfBorg> what the hell is going on with cups-filters?
<LocutusOfBorg> why is update_output_notest even worse now
<slangasek> because it's picking local minima that are suboptimal
<slangasek> it'll clean up with a 'hint glibc' when the time comes, but I don't want to add that early since it'll just increase the time to generate _notest.tx
<slangasek> t
<slangasek> jamespage, coreycb: I'm retrying the neutron/s390x autopkgtest failure against the new python-oslo.reports, but it might be good if neutron's autopkgtests didn't spit out generic messages on failure telling users to look at logs they'll never be able to get to
<slangasek> (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/s390x/n/neutron/20180831_100538_5c078@/log.gz)
<coreycb> slangasek: i agree that would be useful
<LocutusOfBorg> ack thanks
<LocutusOfBorg> slangasek, wrt diaspora installer is it ok to hint?
<slangasek> LocutusOfBorg: I don't know; I hadn't seen any information to suggest it was ok, it looked to my like it was regressing with packages in -proposed.  What's your reason for thinking it would be ok?
<infinity> Hrm, python-cffi/i386 is annoying.  Reducing the testcase to something more easily iterable fails to reproduce the bug.
<LocutusOfBorg> slangasek, it is indeed a bug
<LocutusOfBorg> but the test downloads ruby gems fom the internet
<LocutusOfBorg> so we can't do anything wrt this
<LocutusOfBorg> I think I'll open a bug here https://github.com/hyperic/sigar/issues?q=is%3Aissue+is%3Aclosed
<ginggs> close, but no sigar
<infinity> LocutusOfBorg: If it's straight up broken, it should be demoted, not hinted.
<infinity> (or temporarily removed)
<slangasek> "the test downloads ruby gems from the Internet" is not a good justification for removing functioning software from the release
<infinity> s/test/package/
<infinity> It's an *installer* package.
<infinity> If it's broken upstream, we no can fix.
<infinity> Unless it's literally just the test part that is broken.
<slangasek> ok
<LocutusOfBorg> https://github.com/hyperic/sigar/issues/122
<gitbot> hyperic issue 122 in sigar "Build failure with glibc 2.28" [Open]
<LocutusOfBorg> I don't honestly know if the package installed works or not TBH
<LocutusOfBorg> it is a distributed social network site, so it might be needing some gems for who knows which corner case
<LocutusOfBorg> but as infinity said, downloading stuff from the internet is difficult to fi
<LocutusOfBorg> *fix
<LocutusOfBorg> there is a possible entry point with cflags
<LocutusOfBorg>         su diaspora -s /bin/sh -c "bundle config --local build.sigar '--with-cppflags=\"-fgnu89-inline\"'"
<LocutusOfBorg> but I don't think we can "add a flag to fix a build failure" in this case
<infinity> LocutusOfBorg: You could add flags to ignore all the warnings, but those warning are legit bugs.
<infinity> So...
<slangasek> ah, so the openssl-entangled failures are actually glibc 2.28-caused failures, because new openssl requires new glibc and sigar ftbfs with new glibc
<slangasek> so that is a rationale for skiptest'ing openssl
<slangasek> but openssl won't migrate until glibc is migratable
<LocutusOfBorg> infinity, linux_sigar.c:1178:22: error: called object âminorâ is not a function or
<LocutusOfBorg> function pointer
<LocutusOfBorg> this is not a warning...
<slangasek> and when glibc migrates it will break diaspora-installer
<slangasek> so
<infinity> LocutusOfBorg: Ahh, I missed that one. ;)
<LocutusOfBorg> :)
<infinity> LocutusOfBorg: Which is direct fallout from the warnings above.
 * LocutusOfBorg goes to sleep, cheers!
<LocutusOfBorg> yep sure
<slangasek> yes, the "test" failure is that the package fails to install
<slangasek> no, we should not badtest that
<infinity> slangasek: FWIW, I stared at cminpack some more (and looked at upstream commit history), and I agree with xnox on his assessment.
<slangasek> infinity: ok cool.  you'll file a bug on the Debian package entitled "don't do stupid test"?
<LocutusOfBorg> nice :)
<infinity> slangasek: It looks like upstream has adjusted those ref files in the past for glibc precision changing.  We only have ref files for one arch (which just happen to also work on ARMv7 because reasons), and the current results appear to show *improved* precision.  So, it's failing due to a progression.
<infinity> slangasek: Yeah, I will do something along those lines.
<infinity> WHY DO YOU HATE ME, PYTHON-CFFI.
<infinity> WHY.
<slangasek> yes, why would a library whose raison d'Ãªtre is to propagate segfaults from C code into an interpreted language be anything but sunshine and light
<infinity> From what I can tell, the library actually works right.
<infinity> In that, if I tear out the offending test and run it in isolation, it works.
<infinity> So, the test harness is doing something Very Wrong.  But only on i386.  And wat?
<slangasek> I think I'm in favor of demoting diaspora-installer, adding a temporary blocks, skiptesting openssl, retesting diaspora-installer to get it to a state that p-m will agree it should be blocked based on test state, remove explicit blocks, let things migrate
<slangasek> then when upstream gets itself together, a re-test should let it migrate on its own
<slangasek> infinity: not enough -ffloat-store?
<infinity> Needs more -funrolling of loops.
<slangasek> LP: #1790215
<ubot5> Launchpad bug 1790215 in diaspora-installer (Ubuntu) "upstream gems broken with glibc 2.28, fails to install" [Undecided,New] https://launchpad.net/bugs/1790215
<slangasek> infinity: was a serious suggestion, if that wasn't obvious.  If not using -ffloat-store, one fp-related test could taint another's state
<infinity> slangasek: The failure looks more like a complete failure to dlopen(libm.so.6)
<infinity> The why is harder to figure out.
<slangasek> ok
<slangasek> diaspora-installer demoted etc etc up to "retesting diaspora-installer"
<slangasek> infinity: do you want another set of eyeballs on it?  how are you currently trying to iterate?
<infinity> slangasek: Well, I started with isolating the test (which then made it pass, *sigh*), then rant the testsuite with LD_DEBUG=all, which might not be helpful.  Tracing back through the twisty maze of abstraction to reconstruct the exact test environment, but for only the failing test, might be helpful.
<infinity> Debugging through a python interpreter is not my forte.
<slangasek> how did you try isolating the test?
<infinity> slangasek: Literal copy and paste.
<xnox> slangasek, ouch
<infinity> slangasek: http://paste.ubuntu.com/p/jXBN4fKNRZ/ <-- Minus the print statements, that *is* the test.
<slangasek> ok
<slangasek> xnox: btw, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/i386/b/bluez-qt/20180831_184226_c6600@/log.gz - there must be some magic here wrt pinning of base packages, but I'm afraid I don't know where it is happening
<slangasek> (the failure due to libc6 dep, fine; but libdbus is obviously from dbus source)
 * infinity does that again, but logs the result so he can actually search through it...
<slangasek> xnox: addendum: only i386 shows that problem with libdbus pinning
<xnox> slangasek, lz4 thing looks a bit crazy
<xnox> slangasek, but i would blame incomplete injection of systemd from this environment, into the child VM as prepared by the autopkgtest
<xnox> as in like a bug in ./debian/tests/patch-image or some such
<infinity> cminpack hinted and Debian bug filed.
<infinity> slangasek: Okay, LD_DEBUG stomped on my theory.
<infinity> slangasek: https://paste.ubuntu.com/p/9n5nGh4KYG/ <-- Looks like it's dlopen()ing and binding the symbol just fine.
<slangasek> infinity: ok. and I've spent the last half hour intermittently wondering why I couldn't reproduce the failure before noticing that I was testing on amd64
<infinity> \o/
<infinity> slangasek: Aaaaand, you're right.
<infinity> slangasek: Adding another float test right before breaks it.
<slangasek> fun
<infinity> slangasek: Specifically, a test that does x = m.sin(1.23)
<infinity> Which is, indeed, nan.
<infinity> slangasek: Reproducer: http://paste.ubuntu.com/p/3kH6Wf3kY5/
<slangasek> is this a problem then of libm itself not being built with -ffloat-store?
<slangasek> or is that unrelated
<infinity> slangasek: I feel like the entire libm testsuite would fail on i386 if that was the issue. :P
<slangasek> fair
<infinity> Also, gcc docs seem to imply that ffloat-store is a really bad idea except in rare cases where you want it to fix precision.
<infinity> And this isn't a precision issue.
<xnox> slangasek, it looks to me like our cloud has changed. And VMs used to come up with a graphical display such that gdm3 could start on them. But not anymore.
<xnox> slangasek, what's the right way to enumerate and assert that "there are no displays here"?
<xnox> or maybe systemd's test to install gdm3 and expect it to be started is not a good one?
<slangasek> xnox: I'm not aware of any recent changes on the cloud
<xnox> Command '['ps', 'u', '-C', 'gdm-x-session']' returned non-zero exit status 1.
<xnox> or gdm3 not liking anymore what's there.... locally above does work in a VM, if i add a virtio graphics/display.
<xnox> hmmmm
<xnox> unless i broke something
<xnox> hunting this things is not fun
<xnox> slangasek, how can i get credentials to launch VMs into the autopkgtest user and ssh into them?
<xnox> slangasek, specifically with autopkgtest neutron network-id and machine size?
<slangasek> xnox: non-trivially.  But if you want me to remote hands a VM I will
<xnox> slangasek, ok. let me prepare two requests then.
<xnox> they will come in an email....
 * infinity decides his brain won't work without food, and goes to remedy that.
<infinity> slangasek: I
<infinity> Erm.
<infinity> slangasek: I'm getting dangerously close to thinking it might be an okay idea to bisect where glibc broke this, cause I'm not doing well with attempts to reason it out.
<infinity> I guess bisection will also start out with me seeing if vanilla upstream has the same bug.
<slangasek> ok
<infinity> Since I'm sure as heck not bisecting with Debian patches on top of every iteration.
<infinity> slangasek: I mean, I'm not convinced it's a glibc bug, but if it's a cffi bug, I don't think I'll understand why or how until I see the glibc commit that broke it. :P
<infinity> slangasek: So, sadly, I think that might be an "over-the-weekend" project, cause even if I throw the builds at one of the kernel team's stupid huge machines, it'll take a while to drill down.
<infinity> Plus, I need to write a quick recipe to build upstream in a way that will kinda work on Debian/Ubuntu without all of userspace blowing up.
<infinity> (someone remind me to upstream multiarch six years ago, thanks)
<xnox> infinity, i use rpath / ld preload just that one library for the binary under test; when rebuilding systemd things without patches for same reason.
<xnox> such that _everything_ else still uses sensible things.
<xnox> and yeah build, copy into a vm or whatnot, run hackish shell script test... continue regression.
<slangasek> infinity: no concerns, obviously it holds up migration for a bit but things are looking good to me overall and it takes as long as it takes.  You know anything on timing of rebuild tests?
<infinity> slangasek: "rebuild tests" as in bisection passes, or as in doko's rebuild tests of the world?
<slangasek> infinity: the latter
<infinity> Not sure.
<slangasek> I haven't heard him complain yet that he's waiting on glibc :)
<infinity> Heh.
<infinity> He will soon.
<infinity> But he could also copy glibc from proposed for that, so that's not blocking him.
<slangasek> also he uploaded binutils so he must not be in a hurry
<xnox> slangasek, re: starts with s and ends with biquity -> no arch support this cycle either!
-queuebot:#ubuntu-release- Unapproved: update-manager (bionic-proposed/main) [1:18.04.11.4 => 1:18.10.4] (core)
-queuebot:#ubuntu-release- Unapproved: rejected update-manager [source] (bionic-proposed) [1:18.10.4]
#ubuntu-release 2018-09-01
<slangasek> acheronuk[m]: it's still a bug for autopkgtests to rely on $HOME to be set somewhere useful in the environment; nevertheless I would certainly like to know why all of a sudden, autopkgtests are running in the armhf containers as user 'systemd-coredump'.
<slangasek> acheronuk[m]: it looks like a preponderance of the failing tests were on a node I was manually fiddling with to try to debug snapcraft failures, and the lxd profile may not have been 100% restored, sorry.  Testing a possible fix now.
<slangasek> hmmm but here's another failure on a different node
<slangasek>   * adt-virt-lxc: Stop hardcoding the "ubuntu" suggested normal user; instead,
<slangasek>     call "getent passwd" to detect the first user with uid >= 500. Don't
<slangasek>     advertise suggested-normal-user if none exists.
 * slangasek sighs
<slangasek> xnox: ^^ where does this systemd-coredump user come from?  it appears to be in none of the systemd maintainer scripts and is not mentioned in the changelog
<slangasek> xnox: answer: /usr/lib/sysusers.d/systemd.conf but why and how is it picking uids?
<slangasek> is it valid for systemd-coredump to have uid 998? yes.  Is it weird? also yes.
<slangasek> anyway, I think I have the autopkgtest harness fixed; force-restarting
<acheronuk> slangasek: I see. thank you
-queuebot:#ubuntu-release- New binary: node-rollup [amd64] (cosmic-proposed/universe) [0.50.0-1build1] (no packageset)
#ubuntu-release 2018-09-02
-queuebot:#ubuntu-release- New: accepted node-rollup [amd64] (cosmic-proposed) [0.50.0-1build1]
<slangasek> doko: python2.7/arm64 reproducible autopkgtest regression
<slangasek> doko, infinity: also, glibc/amd64 fails its autopkgtest with the new binutils
<mitya57> Can someone please reject gnome-flashback upload in bionic SRU queue? I want to add one more fix to it.
<cpaelzer> slangasek: thanks for the qemu/glibc trigger
<cpaelzer> I didn't have the time yet to look in detail, all others so far turned out to be real nova/cinder things fixed by jamespage - so I didn't realize it was glibc this time
#ubuntu-release 2019-08-26
-queuebot:#ubuntu-release- New binary: mir [amd64] (eoan-proposed/main) [1.4.0-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: haskell-filepattern [amd64] (eoan-proposed/universe) [0.1.1-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: thrift [s390x] (eoan-proposed/universe) [0.11.0-6] (no packageset)
-queuebot:#ubuntu-release- New binary: thrift [amd64] (eoan-proposed/universe) [0.11.0-6] (no packageset)
-queuebot:#ubuntu-release- New binary: thrift [i386] (eoan-proposed/universe) [0.11.0-6] (no packageset)
-queuebot:#ubuntu-release- New binary: thrift [ppc64el] (eoan-proposed/universe) [0.11.0-6] (no packageset)
-queuebot:#ubuntu-release- New: accepted thrift [amd64] (eoan-proposed) [0.11.0-6]
-queuebot:#ubuntu-release- New: accepted thrift [ppc64el] (eoan-proposed) [0.11.0-6]
-queuebot:#ubuntu-release- New: accepted thrift [i386] (eoan-proposed) [0.11.0-6]
-queuebot:#ubuntu-release- New: accepted thrift [s390x] (eoan-proposed) [0.11.0-6]
-queuebot:#ubuntu-release- New: accepted haskell-language-python [amd64] (eoan-proposed) [0.5.6-2]
<LocutusOfBorg> any AA around please?
<LocutusOfBorg> how can I trick all-proposed=1 to also pick up the kernel version in proposed pocket?
<LocutusOfBorg> https://autopkgtest.ubuntu.com/packages/firewalld/eoan/i386
<LocutusOfBorg> I need the kernel in proposed to see this test green...
 * LocutusOfBorg tries a new trigger
<LocutusOfBorg> oh indeed, the chroot of the autopkgtests needs to be installed with new kernel, not just upgraded with apt, a reboot is needed
<LocutusOfBorg> meh, I'm uploading a workaround of firewalld then
<LocutusOfBorg> when are autopkgtests chroots updated? are them updated with proposed kernel too?
<LocutusOfBorg> Laney, ^^
<Laney> VM or container not chroot, daily, and no
<Laney> if it's broken with the current kernel, and fixed with one in proposed, you probably want to wait for the proposed one to be released
<Laney> otherwise you'll get a broken thing to migrate
<LocutusOfBorg> Laney, I uploaded again with the workaround
<LocutusOfBorg> the kernel in release *is already broken*
<LocutusOfBorg> it could have been hinted, but I prefer to do 3 uploads instead of asking
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1839154
<ubot5> Launchpad bug 1839154 in linux (Ubuntu) "please backport upstream patch to kernel 5.2" [Critical,Fix committed]
<LocutusOfBorg> a stupid typo in kernel prevented the iptable from being correctly initialized on eoan kernel
-queuebot:#ubuntu-release- New binary: golang-github-anacrolix-missinggo [amd64] (eoan-proposed/universe) [2.1.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-mcuadros-go-gin-prometheus [amd64] (eoan-proposed/universe) [0.1.0+git20190723.c7374e9-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-anacrolix-missinggo [s390x] (eoan-proposed/universe) [2.1.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-anacrolix-missinggo [arm64] (eoan-proposed/universe) [2.1.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-anacrolix-missinggo [ppc64el] (eoan-proposed/universe) [2.1.0-4] (no packageset)
<rbalint> could someone please merge this for systemd?: https://code.launchpad.net/~rbalint/britney/autopkgtest-eoan-hints/+merge/371793
-queuebot:#ubuntu-release- New binary: haskell-dense-linear-algebra [i386] (eoan-proposed/universe) [0.1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-easytest [amd64] (eoan-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-dense-linear-algebra [amd64] (eoan-proposed/universe) [0.1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-easytest [i386] (eoan-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-dense-linear-algebra [arm64] (eoan-proposed/universe) [0.1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-dense-linear-algebra [armhf] (eoan-proposed/universe) [0.1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-easytest [arm64] (eoan-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-easytest [armhf] (eoan-proposed/universe) [0.2.1-1] (no packageset)
<jdstrand> cpaelzer: hey, fyi, iptables 1.8.3-2ubuntu2 is still in proposed. I noticed this cause I uploaded a new ufw that deals with 1.8 primary chain ordering differently (adjusted the test instead of the result)
<jdstrand> cpaelzer: I also couldn't reproduce the chains being different, but that's ok
<ahasenack> jdstrand: I was just asking in #ubuntu-devel about iptables
<ahasenack> jdstrand: can you help parse that update_output.txt output?
<jdstrand> ahasenack: I looked. unfortunately I don't work with the autopkgtest infra and didn't see anything obvious
<ahasenack> that's post dep8 tests, but thanks
-queuebot:#ubuntu-release- New binary: haskell-dense-linear-algebra [s390x] (eoan-proposed/universe) [0.1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-dense-linear-algebra [ppc64el] (eoan-proposed/universe) [0.1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-easytest [ppc64el] (eoan-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (xenial-proposed/main) [1:16.04.26 => 1:16.04.27] (core)
<LocutusOfBorg> vorlon, would you mind kicking gr-dab out from release pocket?
<LocutusOfBorg> FTBFS incompatible with gnuradio
<LocutusOfBorg> I tried to fix, but also python3 not ready...
<vorlon> LocutusOfBorg: where can I see that it FTBFS?
<LocutusOfBorg> I'm opening an RC
<LocutusOfBorg> <BTS> Opened #935822 (serious) in src:gr-dab 0.3-4 by Gianfranco Costamagna (locutusofborg) Â«gr-dab: FTBFS with latest gnuradioÂ». https://bugs.debian.org/935822
<ubot5> Error: debian bug 935822 not found
<LocutusOfBorg> http://debomatic-amd64.debian.net/distribution#unstable/gr-dab/0.3-4/buildlog
<LocutusOfBorg> vorlon, do you want a no change rebuild for the archive? just to keep a track?
<vorlon> LocutusOfBorg: that would make for a clearer audit trail later, yes
<LocutusOfBorg> done, it makes sense
<LocutusOfBorg> I tried to fix, but needs porting to python3, lots of incompatibilities with latest gnuradio, and no upstream activity
<RikMills> vorlon: kde4libs has been removed from unstable. I am fixing the last few things here so we can remove kde4 as well
<vorlon> RikMills: cheers! reverse-depends on kde4libs currently shows quite a list
<RikMills> vorlon: yeah, I double checked with: https://people.canonical.com/~ubuntu-archive/transitions/html/html/kde4libs-rm.html
<RikMills> they can all go when kde4libs does, except breeze and oxygen that I have are having their kde4 build parts removed in uploads I just did
<RikMills> *that are having
<RikMills> 'reverse-depends src:kde4libs' also shows a big list, as some of the old monolithic kde4 sources produced silly numbers of .debs
<LocutusOfBorg> and now vorlon the failure is in eoan-proposed...
<vorlon> RikMills: I see that qt-at-spi is removed in Debian as part of the qt4 deprecation but the package is seeded in various live images
<vorlon> LocutusOfBorg: thanks
<RikMills> hmm. wonder why tracker did not see that
<vorlon>     update-alternatives --set $bin /usr/bin/python$PYMAJOR-$bin
<vorlon> what the hell
<vorlon> RikMills: because the tracker doesn't know about seeds
<RikMills> I meant that it build depends on kde4libs
<vorlon> oh
<RikMills> I just copied Simon's config for the qt4 one. maybe there is something amiss
<RikMills> ok. so lubuntu, mate and kylin need to update their seeds and meta I guess?
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.28 => 2.525.29] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (disco-proposed/main) [2.578.6 => 2.578.7] (desktop-core)
<RikMills> a fixed qtcurve removing kde4 support is now syncing
<vorlon> coreycb: it looks like python-oslo.reports needs an upload yet to drop python2 support, which holds up python-os-testr->python-stestr->python-subunit2sql->python-oslo.db->migrate-> removal of python-sphinxcontrib.issuetracker
<mitya57> RikMills: thanks for your work on removing kde4libs. It will help me with my goal to remove qtwebkit :)
<coreycb> vorlon: thanks i'll take care of that
<coreycb> vorlon: i just uploaded a new python-oslo.reports
<vorlon> coreycb: cheers!
<ahasenack> hi, can I get some help with the iptables migration? Specifically, with parsing the bit in update_output.txt
<ahasenack> I can't find out which package(s?) is causing trouble
<ahasenack> it looks like all of miniupnpd, strongswam, systemd, and keepalived have been rebuilt already and picked up the new sonames for libip4tc and libip6tc
<rbalint> vorlon, could you please merge this for systemd?: https://code.launchpad.net/~rbalint/britney/autopkgtest-eoan-hints/+merge/371793
<rbalint> ahasenack, it is systemd keeping it back, i just uploaded ubuntu13 which has no known regression and should migrate with the hints above
<rbalint> (please push retries for flaky tests in the next ~8 hours as i'll be sleeping :-))
<ahasenack> rbalint: I see, thanks
<ahasenack> I'll keep my eye on it until my eod
<rbalint> infinity, vorlon: could you please review livecd-rootfs in disco and bionic?
<vorlon> rbalint: rationale is incorrect for a new linux/ hint in the hints file
<vorlon> (the new kernel shows failures wrt nvidia, not zfs)
<rbalint> vorlon, this seems zfs to me https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/l/linux/20190825_151941_46d1f@/log.gz
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-60.67~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-60.67~16.04.1] (kernel)
<rbalint> vorlon, hm there are several errors
<vorlon> rbalint: looks to me like the zfs module build succeeds in that one
<vorlon> nb the previous failure was that it was trying to download the wrong package url from the archive and failing
<vorlon> anyway, I agree with the conclusion to bump the hint, so I've fixed up the comment and committed
<rbalint> vorlon, thanks!
<rbalint> vorlon, you are right, it is nvidia now
<tsimonq2> vorlon: lubuntu-update-notifier> ack.
-queuebot:#ubuntu-release- Unapproved: netplan.io (bionic-proposed/main) [0.97-0ubuntu1~18.04.1 => 0.98-0ubuntu1~18.04.1] (core)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-60.67~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-60.67~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (disco-proposed) [2.578.7]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.525.29]
<vorlon> coreycb: is python-hacking on your radar? copious python2 openstack build-dependencies, no version currently in -proposed
<coreycb> vorlon: it is now, thanks. will take a look soon.
<vorlon> coreycb: looks like a pile should migrate now as soon as python-swiftclient is gone
#ubuntu-release 2019-08-27
<vorlon> lastlog hacking
<vorlon> uh yes
<vorlon> coreycb: so I was reading nbs wrong wrt python-hacking, apparently that binary is NBS and has a large number of *reverse*-build-dependencies, most of them already fixed in -proposed, so nevermind
-queuebot:#ubuntu-release- Unapproved: mesa (bionic-proposed/main) [19.0.8-0ubuntu0~18.04.1 => 19.0.8-0ubuntu0~18.04.2] (core, xorg)
<RikMills> vorlon: do you need removal bugs for any of the kde4 stuff
<fossfreedom> Quick question on process everyone? A newer version of what was a ubuntu only package (lightdm-settings) has now been accepted and uploaded to Debian unstable. Should I raise a FFe to sync it to eoan or can I force sync it without a FFe?
<Laney> depends what's in it
<Laney> if there are new features, then yeah - if it's only bug fixes then nope
<fossfreedom> I will double check... thx... think its translations plus bug fixes.  But will confirm
<Laney> LocutusOfBorg: http://autopkgtest.ubuntu.com/packages/g/gnome-shell-pomodoro/eoan/s390x please be more careful about retries, that one is never going to work
<Laney> unfortunately we lied to britney with a FauxPackage, so it does think that gnome-shell/s390x exists
<Laney> but humans can be smarter
<LocutusOfBorg> Laney, I did a mass retry of builds and tests on sunday after the first "big migration", that wasn't on purpose...
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (disco-proposed) [1:3.1+dfsg-2ubuntu3.4]
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (bionic-proposed) [1:2.11+dfsg-1ubuntu7.18]
<LocutusOfBorg> (btw retrying the proposed pocket made a lot of stuff build successfully and migrate yesterday, e.g. some rust-* packages, ~100 haskell libraries, and some python stuff migrated due to fixed testsuite in release pocket)
<foka> Hi!  I am wondering, now that Eoan has entered Feature Freeze, does that mean uploads to Debian sid are no longer automatically pulled in?
<cjwatson> Yes
<foka> Thanks for the clarification!
<foka> I am trying to get hugo 0.57.2 into Eoan, and, looking at "update excuses", noticed that hugo is stuck partly due to autopkgtest regression in golang-github-aws-aws-sdk-go (32-bit issues) which I have since fixed in Debian.
<foka> I have also fixed the "Always failed" autopkgtest for golang-github-jesseduffield-go-getter
<foka> So, if it is not too much trouble, could golang-github-aws-aws-sdk-go/1.21.6+dfsg-2 and golang-github-jesseduffield-go-getter/0.0~git20180822.906e156-3 be synced from Debian at your convenience?  Many thanks!
<LocutusOfBorg> syncpackage: Sponsoring this sync for Anthony Fok (foka)
<LocutusOfBorg> .
<LocutusOfBorg> thanks for fixing golang!
<foka> LocutusOfBorg: Thank you so much for your help!
<LocutusOfBorg> anytime you want :)
<foka> If you have time, could you please help get golang-github-google-go-cmp/0.3.0-1 unstuck?  Many thanks!
<foka> And please sync golang-github-denverdino-aliyungo/0.0~git20180921.13fa8aa-2 from Debian too.  mwhudson seems to have fixed an autopkgtest error for it too.
<ahasenack> rbalint: hey, iptables migrated, due to your systemd upload migrating too, thankx
<ahasenack> thanks*
<foka> LocutusOfBorg: Please sync golang-github-prometheus-common/0+git20181119.b36ad28-2 too when it becomes available.
<foka> LocutusOfBorg: Its autopkgtest started to fail mysteriously due to previous testdata certificates which expired on 2019-07-13.  Upstream has regenerated new test certs to be good for 40 years, hence I've backported https://github.com/prometheus/common/pull/186 to golang-github-prometheus-common/0+git20181119.b36ad28-2, uploaded to Debian minutes ago.
<gitbot> prometheus issue (Pull request) 186 in common "config: extend validity of testdata certs" [Closed]
<foka> LocutusOfBorg: Many thanks for looking after golang packages in Ubuntu!
<LocutusOfBorg> foka, all done,
<LocutusOfBorg> lets see if the stick unstuck go-cmp
-queuebot:#ubuntu-release- Unapproved: makedumpfile (disco-proposed/main) [1:1.6.5-1ubuntu1 => 1:1.6.5-1ubuntu1.1] (core)
<foka> LocutusOfBorg: Thanks a million!
<Laney> ddstreet: what incident are you referering to in https://salsa.debian.org/ci-team/autopkgtest/merge_requests/55/diffs#note_105172 ?
<gitbot> Debian CI issue (Merge request) 55 in autopkgtest "ssh-setup/nova: add --nova-stop-start param" [Opened]
<Laney> ummmmm, forget the anchor
<ddstreet> Laney in bos01, arm64 systems can't be rebooted, only stop/started
<ddstreet> if that's what you are asking, why i proposed adding that
<ddstreet> Laney https://portal.admin.canonical.com/119924
<Laney> yes
<Laney> I am surprised that one cloud is apparently broken and I don't know about it
<Laney> oh ok, not a production one
<ddstreet> right, i dont have (direct) access to the prod cloud
<ddstreet> only canonistack
<ddstreet> and of course, submitting jobs to the prod cloud via autopkgtest.u.c
<Laney> ok
<LocutusOfBorg> foka, HUGO MIGRATED! thanks!
<LocutusOfBorg> (and the 3 related golang packages)
<Laney> holy component-mismatches
-queuebot:#ubuntu-release- Unapproved: accepted s390-tools [s390x] (eoan-proposed) [2.10.0-0ubuntu2]
<fossfreedom> Quick heads up ... getting reports that the gtk 3.34 uplift today has resulted in a login loop to budgie desktop. Will need to investigate.   If there are any bug reports please ping me. TIA
<vorlon> Laney: libreoffice -> gst; and the bileto ppa was published before 0ubuntu5 was released with the fix
<vorlon> oh, but now gnome-control-center is also pulling it in
<vorlon> fsvo "it"
<LocutusOfBorg> can any AA please accept golang-github-anacrolix-missinggo ?
<LocutusOfBorg> it isn't built on every arch that built on debian
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (eoan-proposed/main) [5.2.0-15.16] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (eoan-proposed/main) [5.2.0-15.16] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (eoan-proposed/main) [5.2.0-15.16] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (eoan-proposed/main) [5.2.0-15.16] (core, kernel)
-queuebot:#ubuntu-release- New: accepted haskell-dense-linear-algebra [arm64] (eoan-proposed) [0.1.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-dense-linear-algebra [ppc64el] (eoan-proposed) [0.1.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-easytest [arm64] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-easytest [ppc64el] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-dense-linear-algebra [armhf] (eoan-proposed) [0.1.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-easytest [armhf] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-dense-linear-algebra [s390x] (eoan-proposed) [0.1.0.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-anacrolix-missinggo [amd64] (eoan-proposed) [2.1.0-4]
-queuebot:#ubuntu-release- New: accepted golang-github-anacrolix-missinggo [ppc64el] (eoan-proposed) [2.1.0-4]
-queuebot:#ubuntu-release- New: accepted golang-github-mcuadros-go-gin-prometheus [amd64] (eoan-proposed) [0.1.0+git20190723.c7374e9-2]
-queuebot:#ubuntu-release- New: accepted haskell-dense-linear-algebra [i386] (eoan-proposed) [0.1.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-easytest [i386] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-anacrolix-missinggo [arm64] (eoan-proposed) [2.1.0-4]
-queuebot:#ubuntu-release- New: accepted haskell-dense-linear-algebra [amd64] (eoan-proposed) [0.1.0.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-anacrolix-missinggo [s390x] (eoan-proposed) [2.1.0-4]
-queuebot:#ubuntu-release- New: accepted haskell-easytest [amd64] (eoan-proposed) [0.2.1-1]
<Laney> vorlon: different 'it' now; this is something that seb128 added so I'll leave it for him to sort out
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (eoan-proposed) [5.2.0-15.16]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (eoan-proposed) [5.2.0-15.16]
-queuebot:#ubuntu-release- New binary: golang-github-anacrolix-ffprobe [amd64] (eoan-proposed/universe) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (eoan-proposed) [5.2.0-15.16]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (eoan-proposed) [5.2.0-15.16]
<vorlon> Laney: ack
-queuebot:#ubuntu-release- Unapproved: cmake (bionic-proposed/main) [3.10.2-1ubuntu2.18.04.1 => 3.10.2-1ubuntu2.18.04.2] (core)
<LocutusOfBorg> please reject the above cmake ^^ I want a testcase from user before uploading
<LocutusOfBorg> I thought I was able to replicate locally but I might be wrong...
-queuebot:#ubuntu-release- Unapproved: sssd (bionic-proposed/main) [1.16.1-1ubuntu1.3 => 1.16.1-1ubuntu1.4] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected cmake [source] (bionic-proposed) [3.10.2-1ubuntu2.18.04.2]
<fossfreedom> any AA's around?  please can v10.5-0ubuntu4 that I just uploaded to eoan-proposed be removed?  I forgot to add another changelog entry.  TIA
<fossfreedom> budgie-desktop that is!
<infinity> fossfreedom: eoan isn't frozen, thus no queue, thus versions uploaded are burned and can't be rejected and reused.  Just upload on top.
<fossfreedom> infinity: just upload the same version or do I have to bump another version?
<infinity> fossfreedom: New version.  You can't reuse versions once they're in the archive.
<infinity> fossfreedom: You can just s/0ubuntu4/0ubuntu5/ and fix your changelog, if you want.
<fossfreedom> ok thx
<vorlon> RAOF: E: libmirwayland-dev: arch-dependent-file-not-in-arch-specific-directory usr/bin/mir_wayland_generator
<vorlon> RAOF: it's an error for libmirwayland-dev to be Multi-Arch: same with such contents
-queuebot:#ubuntu-release- New: accepted mir [amd64] (eoan-proposed) [1.4.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mir [armhf] (eoan-proposed) [1.4.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mir [ppc64el] (eoan-proposed) [1.4.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mir [arm64] (eoan-proposed) [1.4.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mir [i386] (eoan-proposed) [1.4.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (trusty-proposed/main) [10ubuntu0.14.04.3 => 10ubuntu0.14.04.4] (no packageset)
<ahasenack> hi, can someone please remove 19.5.1~ubuntu14.04.1 from the trusty unapproved queue? Another sru was uploaded that is more urgent
<ahasenack> er, I mean, ubuntu-advantage-tools 19.5.1~ubuntu14.04.1
-queuebot:#ubuntu-release- Unapproved: ibm-java80 (xenial-proposed/partner) [8.0.5.35-0ubuntu1 => 8.0.5.40-0ubuntu1] (no packageset)
<rbasak> ahasenack: done
<ahasenack> rbasak: thanks! And are you time shifting again? :)
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-advantage-tools [source] (trusty-proposed) [19.5.1~ubuntu14.04.1]
-queuebot:#ubuntu-release- Unapproved: netplan.io (disco-proposed/main) [0.97-0ubuntu1~19.04.1 => 0.98-0ubuntu1~19.04.1] (core)
<vorlon> coreycb: python-swiftclient fails autopkgtests because no such command 'swift'
-queuebot:#ubuntu-release- Unapproved: accepted netplan.io [source] (bionic-proposed) [0.98-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: netplan.io (disco-proposed/main) [0.97-0ubuntu1~19.04.1 => 0.98-0ubuntu1~19.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: rejected netplan.io [source] (disco-proposed) [0.98-0ubuntu1~19.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted netplan.io [source] (disco-proposed) [0.98-0ubuntu1~19.04.1]
<ginggs> can LP: #1828409 be actioned now, since removing all of i386 is not the current plan?
<ubot5> Launchpad bug 1828409 in htslib (Ubuntu) "please remove htslib on i386" [Undecided,Won't fix] https://launchpad.net/bugs/1828409
<RAOF> vorlon: Urgh, thanks for catching that. I got wlcs' version of that, but missed it in Mir. (Relatedly, I should fix more of the lintian output for Mir so that actual problems are more prominent â¹ï¸)
#ubuntu-release 2019-08-28
<RikMills> vorlon: do you need any more doing for the kde4 removal? bugs etc on non debian things?
-queuebot:#ubuntu-release- New binary: mir [amd64] (eoan-proposed/main) [1.4.0-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: mir [i386] (eoan-proposed/main) [1.4.0-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: mir [ppc64el] (eoan-proposed/main) [1.4.0-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New sync: ocaml-mmap (eoan-proposed/primary) [1.1.0-1]
-queuebot:#ubuntu-release- New sync: ocaml-topkg (eoan-proposed/primary) [1.0.1-1]
-queuebot:#ubuntu-release- New sync: ocaml-stdio (eoan-proposed/primary) [0.12.0-1]
-queuebot:#ubuntu-release- New sync: golang-github-ensighten-udnssdk (eoan-proposed/primary) [1.3.4-1]
-queuebot:#ubuntu-release- New sync: golang-github-nesv-go-dynect (eoan-proposed/primary) [0.6.0+git20190806.63e11f6-1]
-queuebot:#ubuntu-release- New sync: golang-github-mitchellh-go-linereader (eoan-proposed/primary) [0.0~git20190213.1b945b3-1]
-queuebot:#ubuntu-release- New sync: golang-github-mitchellh-go-linereader (eoan-proposed/primary) [0.0~git20190213.1b945b3-1]
-queuebot:#ubuntu-release- New sync: golang-github-sethvargo-go-fastly (eoan-proposed/primary) [1.2.1+git20190805.5c6c8bd-1]
-queuebot:#ubuntu-release- New sync: golang-github-nesv-go-dynect (eoan-proposed/primary) [0.6.0+git20190806.63e11f6-1]
-queuebot:#ubuntu-release- New binary: haskell-text-format [amd64] (eoan-proposed/universe) [0.3.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-text-format [i386] (eoan-proposed/universe) [0.3.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-text-format [ppc64el] (eoan-proposed/universe) [0.3.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-text-format [s390x] (eoan-proposed/universe) [0.3.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-text-format [arm64] (eoan-proposed/universe) [0.3.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-text-format [armhf] (eoan-proposed/universe) [0.3.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: mir [armhf] (eoan-proposed/main) [1.4.0-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: mir [arm64] (eoan-proposed/main) [1.4.0-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: golang-gopkg-ldap.v3 [amd64] (eoan-proposed/universe) [3.0.3-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-getlantern-hidden [amd64] (eoan-proposed/universe) [0.0~git20190325.f02dbb0-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-getlantern-hidden [amd64] (eoan-proposed/universe) [0.0~git20190325.f02dbb0-1ubuntu3] (no packageset)
<LocutusOfBorg> can we have please some fast haskell ocaml golang accept ^^ ?
<LocutusOfBorg> leaf packages unblocking some stuff
-queuebot:#ubuntu-release- New: accepted golang-github-anacrolix-ffprobe [amd64] (eoan-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-text-format [arm64] (eoan-proposed) [0.3.2-3]
-queuebot:#ubuntu-release- New: accepted haskell-text-format [i386] (eoan-proposed) [0.3.2-3]
-queuebot:#ubuntu-release- New: accepted haskell-text-format [s390x] (eoan-proposed) [0.3.2-3]
-queuebot:#ubuntu-release- New: accepted haskell-text-format [amd64] (eoan-proposed) [0.3.2-3]
-queuebot:#ubuntu-release- New: accepted haskell-text-format [ppc64el] (eoan-proposed) [0.3.2-3]
-queuebot:#ubuntu-release- New: accepted haskell-text-format [armhf] (eoan-proposed) [0.3.2-3]
-queuebot:#ubuntu-release- Unapproved: cogl (disco-proposed/main) [1.22.2-6 => 1.22.2-6ubuntu1] (desktop-core)
<LocutusOfBorg> vorlon, assuming https://autopkgtest.ubuntu.com/packages/golang-go.crypto/eoan/amd64 has regressed in release, can we hint?
<LocutusOfBorg> looks like the failing test is trying to ssh on some devices, and it doesn't fail...
<LocutusOfBorg> maybe the configuration has changed in the meanwhile?
<LocutusOfBorg> I'm trying to run the test against itself, but it seems to be harder than I thought
<LocutusOfBorg> in any case, hinting would be appreciated...
-queuebot:#ubuntu-release- Unapproved: packagekit (disco-proposed/main) [1.1.12-5 => 1.1.12-5ubuntu0.1] (desktop-core)
<slashd> o/ rbasak (SRU vanguard) or any other SRU member: Good day, could you please (if you have time) release ubuntu-advantage-tools found in Trusty upload (LP: #1840091). Thanks in advance !
<ubot5> Launchpad bug 1840091 in ubuntu-advantage-tools (Ubuntu Trusty) "ubuntu-advantage enable-esm should ensure correct package requirements are met" [High,In progress] https://launchpad.net/bugs/1840091
<rbasak> vorlon: ^ any guidance on handling SRU requests in the ESM period please?
<rbasak> Would these be handled by the regular SRU team, or something special?
<rbasak> And what should be the criteria for acceptance - same policy as usual, or different?
-queuebot:#ubuntu-release- Unapproved: makedumpfile (bionic-proposed/main) [1:1.6.5-1ubuntu1~18.04.1 => 1:1.6.5-1ubuntu1~18.04.2] (core)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-161.189] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-161.189]
-queuebot:#ubuntu-release- Unapproved: accepted makedumpfile [source] (disco-proposed) [1:1.6.5-1ubuntu1.1]
<slashd> rbasak, vorlon : For sure u-a-tools will need to land in trusty-updates (new Depends are also in trusty-updates), as it is the tool required to enable ESM.
-queuebot:#ubuntu-release- Unapproved: accepted makedumpfile [source] (bionic-proposed) [1:1.6.5-1ubuntu1~18.04.2]
<rbalint> hi, LP: #1841790
<ubot5> Launchpad bug 1841790 in systemd (Ubuntu) "[FFe] Please accept systemd 241 to Eoan" [Undecided,New] https://launchpad.net/bugs/1841790
-queuebot:#ubuntu-release- New binary: poppler [s390x] (eoan-proposed/main) [0.80.0-0ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: poppler [amd64] (eoan-proposed/main) [0.80.0-0ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: poppler [ppc64el] (eoan-proposed/main) [0.80.0-0ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: poppler [i386] (eoan-proposed/main) [0.80.0-0ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: poppler [arm64] (eoan-proposed/main) [0.80.0-0ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: poppler [armhf] (eoan-proposed/main) [0.80.0-0ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted poppler [amd64] (eoan-proposed) [0.80.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted poppler [armhf] (eoan-proposed) [0.80.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted poppler [ppc64el] (eoan-proposed) [0.80.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted poppler [arm64] (eoan-proposed) [0.80.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted poppler [s390x] (eoan-proposed) [0.80.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted poppler [i386] (eoan-proposed) [0.80.0-0ubuntu1]
<vorlon> RikMills: yes, all of the Ubuntu-specific packages that you want removed need to have removal request bugs filed against them
<vorlon> rbasak: ubuntu-advantage-tools is a special case because it needs to be SRUed into the main archive past the end of standard support in order to make ESM itself work, yes
<vorlon> LocutusOfBorg: if the autopkgtests have regressed in release, then yes, we should hint
<rbasak> vorlon: I understand that; my question is what process should be followed? Or do you want to take it with your TB hat?
<vorlon> rbasak: same process
<rbasak> OK
<vorlon> RikMills, Wimpress: appmenu-qt is seeded in ubuntu-mate, mate-applet-appmenu -> appmenu-qt
<vorlon> probably just needs appmenu-qt to be dropped across the board as a recommends
<vorlon> RikMills: and I'm stealing the meta-kde merge from you, in order to drop kopete for the qt4 removals
<RikMills> vorlon: kopete doesn't need to be removed
<vorlon> oh?
<RikMills> we have the Qt5 port
<vorlon> ok
<RikMills> I'll try to get to removal bugs tonight. thank you
<vorlon> RikMills: looks like kde-runtime in particular has some Ubuntu-specific revdeps
<vorlon> kfilereplace, kgraphviewer, lemonpos, semantik
<vorlon> kdepimlibs might be removable, but the reverse-depends is not automatically processable because that source package has superseded binaries in debian/control
<vorlon> ok, kdepimlibs is removable after libkfbapi and kde-runtime go
<RikMills> lemonpos looks dead
<RikMills> semantik has a Qt5 port, but honestly I am not inclined to maintain that
<RikMills> I guess if someone misses it, it could be brought back
<vorlon> yeah I think the presumption should be by this point that they should all be removed rather than effort spent fixing them up
<vorlon> but I still want that in a bug report for each ;)
<RikMills> I'll be able to properly site down and do those in ~2hrs. hope that is ok
<vorlon> wfm
<slashd> vorlon, rbasak, with that being said ... does one of you comfortable to accept u-a-tools in Trusty ?
<rbasak> slashd: I'll review it now.
<slashd> rbasak, vorlon thanks to both of you
<rbasak> slashd: is this needed in ubuntu-advantage-tools in newer releases?
<rbasak> One can expect apt to be installed, but what about apt-transport-https for example?
<slashd> rbasak, it's really esm specific inside Trusty, IMHO it will be a must to have in the future when X and so on will enter in their ESM phase
<slashd> but not critical for now
<rbasak> slashd: the bug needs an open task for all future LTS releases then?
<slashd> rbasak, doing it now
<vorlon> rbasak: by the time xenial enters ESM, the client is going to be replaced completely
<rbasak> slashd: I'm also not sure about accepting in Trusty without at least ensuring the fix is committed somewhere for the future so it lands in the future releases in time without relying on someone to remember.
<vorlon> so I think in this case the policy should be waived
<rbasak> vorlon: I was about to ask you. Thanks :)
<rbasak> "is going to be" -> careful there though. Plans change - especially when it's as easy as a delay.
<slashd> rbasak, done
<slashd> rbasak, I'll make sure to submit a patch to andreas for current devel release
<rbasak> Thanks!
<slashd> ahasenack, ^
<slashd> rbasak, actually Erlon (the author of the patch) is out for 1 or 2 days, when he'll come back I'll make sure he does a MP for ahasenack reviewal.
<rbasak> Sure
<rbasak> Well, I remain reluctant, but you have vorlon's +1 above.
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-advantage-tools [source] (trusty-proposed) [10ubuntu0.14.04.4]
<slashd> rbasak, I admit it's a particular situation, but it will definitely help users to use esm without less trouble, and I'll make sure Erlon does the job in future LTS release that will come to EOL eventually
<rbasak> Thanks :)
<slashd> I already target the series, and assigned it to Erlon in LP, and I'll have a discusion with him as soon as he come back from PTO
<slashd> rbasak, thanks to you
<vorlon> rbasak: there's a complete rewrite of the client that is going to be landed in trusty-updates, definitely before xenial goes ESM.  It's been delayed for polish but is definitely happening
<vorlon> because the ESM service implementation is changing and the old client will not work with ESM for xenial
<vorlon> so I'm confident in this case :)
<slashd> rbasak, vorlon, so it's safe to say that we can postpone the fix until the new client is released ? and re-evaluate by then ?
<slashd> for x and late
<vorlon> yes
<slashd> thanks
<rbasak> I have accepted it into Trusty
<slashd> will update the LP accordingly
<slashd> done
-queuebot:#ubuntu-release- Unapproved: rejected lyx [source] (xenial-proposed) [2.1.5-0ubuntu0.16.04.1]
<slashd> vorlon, once we confirm it works, would you be fine with a potential early release ? or you prefer to let it bake for 7 days still ?
<slashd> I don't expect much ppl testing u-a-tools in trusty-proposed ;/ minus support anyway
<vorlon> in principle yes
<slashd> vorlon, ok tks again
<vorlon> coreycb: you updated python-os-net-config to python3 this cycle, and Debian removed it rather than moving it to python3 (Debian bug #935878).  Should we also remove it?
<ubot5> Debian bug 935878 in ftp.debian.org "RM: python-os-net-config -- ROM; Not relevant to Debian, depends on cruft packages" [Normal,Open] http://bugs.debian.org/935878
<coreycb> vorlon: yeah i think we can get rid of that. do we need an RM bug?
<vorlon> coreycb: no, just your agreement that I can remove it based on Debian's removal
<coreycb> vorlon: yes i agree. we don't maintain tripleo either.
<coreycb> jamespage: fyi ^
<slashd> vorlon, rbasak : It built and being published: https://launchpad.net/ubuntu/+source/ubuntu-advantage-tools/10ubuntu0.14.04.4/+publishinghistory, rmadison is update, but I can't see the new binary package still in proposed : http://archive.ubuntu.com/ubuntu/pool/main/u/ubuntu-advantage-tools/ . Is it possible an automatic thing no longer work to publish the .deb in trusty ? or it's just me not being patient enough ?
<vorlon> slashd: I see it in the package pool.  I'd give it a little more time to see if it shows up on the frontend mirrors, and if it's not there in an hour we should check with IS
-queuebot:#ubuntu-release- New binary: haskell-filepattern [amd64] (eoan-proposed/universe) [0.1.1-1build2] (no packageset)
<slashd> vorlon, sound good thanks for confirming
-queuebot:#ubuntu-release- New binary: gnome-getting-started-docs [amd64] (eoan-proposed/main) [3.33.90-0ubuntu1] (personal-gunnarhj, ubuntu-desktop)
<rbalint> vorlon, we discussed it with xnox and he agrees that it is desired to upgrade systemd to 241 in eoan: LP: #1841790
<ubot5> Launchpad bug 1841790 in systemd (Ubuntu) "[FFe] Please accept systemd 241 to Eoan" [Undecided,New] https://launchpad.net/bugs/1841790
<vorlon> hmm who promoted libpoppler-qt5-1 to main in -proposed?
<rbalint> vorlon, based on the positive bileto results it should migrate smoothly
<vorlon> rbalint: I don't think I can give that a proper review at the moment and will have to defer to someone else on the release team
<rbalint> vorlon, ok, could you pick someone?
<vorlon> no
<rbalint> vorlon, ok, i'll poke them :-)
<rbalint> maybe infinity is interested ^
-queuebot:#ubuntu-release- Unapproved: gnome-initial-setup (bionic-proposed/main) [3.28.0-2ubuntu6.16.04.4 => 3.28.0-2ubuntu6.16.04.5] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: gnome-initial-setup (bionic-proposed/main) [3.28.0-2ubuntu6.16.04.4 => 3.28.0-2ubuntu6.16.04.6] (ubuntugnome)
<RikMills> LP: #1841822
<ubot5> Launchpad bug 1841822 in plasma-mobile-config (Ubuntu) "Please remove from Eoan" [Undecided,New] https://launchpad.net/bugs/1841822
<RikMills> LP: #1841825
<ubot5> Launchpad bug 1841825 in semantik (Ubuntu) "Please remove from Eoan" [Undecided,New] https://launchpad.net/bugs/1841825
<RikMills> LP: #1841821
<ubot5> Launchpad bug 1841821 in lemonpos (Ubuntu) "Please remove from Eoan" [Undecided,New] https://launchpad.net/bugs/1841821
<RikMills> LP: #1841828
<ubot5> Launchpad bug 1841828 in kfilereplace (Ubuntu) "Please remove from Eoan" [Undecided,New] https://launchpad.net/bugs/1841828
<RikMills> LP: #1841830
<ubot5> Launchpad bug 1841830 in kgraphviewer (Ubuntu) "Please remove from Eoan" [Undecided,New] https://launchpad.net/bugs/1841830
<RikMills> vorlon: ^^
<RikMills> any more needed, please shout
<vorlon> RikMills: could I also get a bug report for the kde-l10n stuff?  don't necessarily need you to bother with a task for each source, just pick one
<vorlon> RikMills: also libkfbapi
<vorlon> coreycb: python-os-xenapi blocks keystone+python-oslo.log
<vorlon> and my attempt at a straightforward removal of python2 failed :)
<coreycb> vorlon: thanks i'll take a look. making progress though!
<vorlon> indeed!
<RikMills> LP: #1841834
<ubot5> Launchpad bug 1841834 in kde-l10n-engb (Ubuntu) "Please remove all kde-l10-* sources from Eoan" [Undecided,New] https://launchpad.net/bugs/1841834
<RikMills> LP: #1841835
<ubot5> Launchpad bug 1841835 in libkfbapi (Ubuntu) "Please remove from Eoan" [Undecided,New] https://launchpad.net/bugs/1841835
<RikMills> vorlon ^^
<vorlon> RikMills: thanks
 * RikMills didn't even realise that facebook api thing existed
<RikMills> good riddance
<vorlon> yeah it probably doesn't work at all with current fb
<RikMills> I would bet big money on that
<RikMills> vorlon: mate just updates seed and meta to drop qt-at-spi
<vorlon> sweet
<RikMills> tsimonq2 told me to just get a core dev to do the same for lubuntu if he wasn't around
<RikMills> kylin have dropped from seed, but when I tried their meta it dropped a fair few other recommends, so they need to check that
<RikMills> handsome_feng: I get this on your meta: https://paste.ubuntu.com/p/79hw4jqDHd/
<RikMills> on just seeing what would happen...
<vorlon> RikMills: next: kffmpegthumbnailer
<RikMills> vorlon: not in debian either? it has a Qt5 version which is maybe why I thought it must have
<vorlon> RikMills: haven't looked beyond having seen that it's blocking removals
<vorlon> looks Ubuntu specific, first uploaded to lucid
<vorlon> RikMills: and libdbusmenu-qt looks like it might need a merge
<RikMills> kffmpegthumbnailer does. struggling to find kde source repo
<RikMills> vorlon: libdbusmenu-qt has been synced. staying in -proposed for 'reasons'
<vorlon> ok
<RikMills> skipped: libdbusmenu-qt (759, 0, 78)
<RikMills>     got: 49+0: a-3:a-2:a-32:i-8:p-2:s-2
<RikMills>     * armhf: kdelibs-bin, kdelibs5-dev, kdelibs5-plugins, kdoctools, kffmpegthumbnailer, libkactivities-dev, libkcmutils4, libkde3support4, libkdeclarative5, libkdeui5, libkdewebkit5, libkdnssd4, libkemoticons4, libkfile4, libkhtml5, libkidletime4, libkimproxy4, libkio5, libkmediaplayer4, libknewstuff2-4, libknewstuff3-4, libknotifyconfig4, libkparts4, libkprintutils4, libkrosscore4, libkrossui4, libktexteditor4, libkutils4,
<RikMills> libplasma3, sni-qt
<vorlon> those reasons are kde4libs, which shakes out after kffmpegthumbnailer
<RikMills> yup
<RikMills> vorlon: LP: #1841859
<ubot5> Launchpad bug 1841859 in kffmpegthumbnailer (Ubuntu) "Please remove from Eoan" [Undecided,New] https://launchpad.net/bugs/1841859
<crydotsnake-M> Hello Everyone! :)
<RikMills> crydotsnake-M: hi.
<RikMills> ^^ a new Kubuntu tester who might benfit from lurking in here
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [19.2-21-ge6383719-0ubuntu1~16.04.1 => 19.2-24-ge7881d5c-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<crydotsnake-M> :)))
-queuebot:#ubuntu-release- Unapproved: cloud-init (bionic-proposed/main) [19.2-21-ge6383719-0ubuntu1~18.04.1 => 19.2-24-ge7881d5c-0ubuntu1~18.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (disco-proposed/main) [19.2-21-ge6383719-0ubuntu1~19.04.1 => 19.2-24-ge7881d5c-0ubuntu1~19.04.1] (core, edubuntu, ubuntu-cloud)
<blackboxsw> vorlon: if there is time today, the cloud-init update to SRU is queued and includes the patches we wanted for that SRU. If no time today, I'll hit up sil2100  tomorrow^
-queuebot:#ubuntu-release- New binary: marco [amd64] (eoan-proposed/universe) [1.22.2-1ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- New binary: marco [i386] (eoan-proposed/universe) [1.22.2-1ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: accepted ibm-java80 [source] (xenial-proposed) [8.0.5.40-0ubuntu1]
-queuebot:#ubuntu-release- New binary: marco [arm64] (eoan-proposed/universe) [1.22.2-1ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- New binary: marco [armhf] (eoan-proposed/universe) [1.22.2-1ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- New: accepted ocaml-mmap [sync] (eoan-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted ocaml-topkg [sync] (eoan-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted ocaml-stdio [sync] (eoan-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-ensighten-udnssdk [sync] (eoan-proposed) [1.3.4-1]
-queuebot:#ubuntu-release- New: rejected golang-github-mitchellh-go-linereader [sync] (eoan-proposed) [0.0~git20190213.1b945b3-1]
-queuebot:#ubuntu-release- New: accepted golang-github-mitchellh-go-linereader [sync] (eoan-proposed) [0.0~git20190213.1b945b3-1]
-queuebot:#ubuntu-release- New: accepted golang-github-nesv-go-dynect [sync] (eoan-proposed) [0.6.0+git20190806.63e11f6-1]
-queuebot:#ubuntu-release- New: rejected golang-github-nesv-go-dynect [sync] (eoan-proposed) [0.6.0+git20190806.63e11f6-1]
-queuebot:#ubuntu-release- New: accepted golang-github-sethvargo-go-fastly [sync] (eoan-proposed) [1.2.1+git20190805.5c6c8bd-1]
-queuebot:#ubuntu-release- New binary: ocaml-mmap [amd64] (eoan-proposed/none) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-mmap [i386] (eoan-proposed/none) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-stdio [amd64] (eoan-proposed/none) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-topkg [amd64] (eoan-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-stdio [i386] (eoan-proposed/none) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-topkg [i386] (eoan-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rlottie [sync] (eoan-proposed) [0~git20190721.24346d0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted ocaml-mmap [amd64] (eoan-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted ocaml-stdio [amd64] (eoan-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted ocaml-topkg [amd64] (eoan-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New binary: golang-github-ensighten-udnssdk [amd64] (eoan-proposed/none) [1.3.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-nesv-go-dynect [amd64] (eoan-proposed/none) [0.6.0+git20190806.63e11f6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-mmap [arm64] (eoan-proposed/none) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-stdio [armhf] (eoan-proposed/none) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-topkg [armhf] (eoan-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ocaml-mmap [i386] (eoan-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted ocaml-topkg [i386] (eoan-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New binary: golang-github-sethvargo-go-fastly [amd64] (eoan-proposed/none) [1.2.1+git20190805.5c6c8bd-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-topkg [arm64] (eoan-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ocaml-stdio [i386] (eoan-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New binary: ocaml-stdio [arm64] (eoan-proposed/none) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-mitchellh-go-linereader [amd64] (eoan-proposed/none) [0.0~git20190213.1b945b3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted mysql++ [sync] (eoan-proposed) [3.2.5-1]
-queuebot:#ubuntu-release- New binary: ocaml-mmap [armhf] (eoan-proposed/none) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-github-ensighten-udnssdk [amd64] (eoan-proposed) [1.3.4-1]
-queuebot:#ubuntu-release- New: accepted golang-github-nesv-go-dynect [amd64] (eoan-proposed) [0.6.0+git20190806.63e11f6-1]
-queuebot:#ubuntu-release- New: accepted ocaml-mmap [arm64] (eoan-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted ocaml-stdio [arm64] (eoan-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted ocaml-topkg [arm64] (eoan-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-mitchellh-go-linereader [amd64] (eoan-proposed) [0.0~git20190213.1b945b3-1]
-queuebot:#ubuntu-release- New: accepted ocaml-mmap [armhf] (eoan-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted ocaml-topkg [armhf] (eoan-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-sethvargo-go-fastly [amd64] (eoan-proposed) [1.2.1+git20190805.5c6c8bd-1]
-queuebot:#ubuntu-release- New: accepted ocaml-stdio [armhf] (eoan-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New binary: marco [ppc64el] (eoan-proposed/universe) [1.22.2-1ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- New binary: rlottie [amd64] (eoan-proposed/none) [0~git20190721.24346d0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rlottie [armhf] (eoan-proposed/none) [0~git20190721.24346d0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mysql++ [amd64] (eoan-proposed/none) [3.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rlottie [i386] (eoan-proposed/none) [0~git20190721.24346d0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rlottie [arm64] (eoan-proposed/none) [0~git20190721.24346d0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mysql++ [i386] (eoan-proposed/none) [3.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mysql++ [arm64] (eoan-proposed/none) [3.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mysql++ [armhf] (eoan-proposed/none) [3.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-mmap [ppc64el] (eoan-proposed/none) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rlottie [ppc64el] (eoan-proposed/universe) [0~git20190721.24346d0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted rtl8821ce [amd64] (eoan-proposed) [5.2.5.2.1.30816.20190425-0ubuntu1]
-queuebot:#ubuntu-release- New binary: mysql++ [ppc64el] (eoan-proposed/universe) [3.2.5-1] (no packageset)
#ubuntu-release 2019-08-29
-queuebot:#ubuntu-release- New binary: marco [s390x] (eoan-proposed/universe) [1.22.2-1ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- New binary: rlottie [s390x] (eoan-proposed/universe) [0~git20190721.24346d0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mysql++ [s390x] (eoan-proposed/universe) [3.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted mysql++ [arm64] (eoan-proposed) [3.2.5-1]
-queuebot:#ubuntu-release- New: accepted mysql++ [ppc64el] (eoan-proposed) [3.2.5-1]
-queuebot:#ubuntu-release- New: accepted mysql++ [armhf] (eoan-proposed) [3.2.5-1]
-queuebot:#ubuntu-release- New: accepted mysql++ [s390x] (eoan-proposed) [3.2.5-1]
-queuebot:#ubuntu-release- New: accepted mysql++ [amd64] (eoan-proposed) [3.2.5-1]
-queuebot:#ubuntu-release- New: accepted ocaml-mmap [ppc64el] (eoan-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted rlottie [arm64] (eoan-proposed) [0~git20190721.24346d0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted rlottie [i386] (eoan-proposed) [0~git20190721.24346d0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted rlottie [s390x] (eoan-proposed) [0~git20190721.24346d0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted mysql++ [i386] (eoan-proposed) [3.2.5-1]
-queuebot:#ubuntu-release- New: accepted rlottie [armhf] (eoan-proposed) [0~git20190721.24346d0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted rlottie [amd64] (eoan-proposed) [0~git20190721.24346d0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted rlottie [ppc64el] (eoan-proposed) [0~git20190721.24346d0+dfsg-2]
<vorlon> RikMills: kde-artwork-active also has a build-depends on kdelibs5-dev and seems to be Ubuntu-only
-queuebot:#ubuntu-release- New binary: typerep [amd64] (eoan-proposed/universe) [1:0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: typerep [i386] (eoan-proposed/universe) [1:0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: typerep [armhf] (eoan-proposed/universe) [1:0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: typerep [arm64] (eoan-proposed/universe) [1:0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: typerep [ppc64el] (eoan-proposed/universe) [1:0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: typerep [s390x] (eoan-proposed/universe) [1:0.12.0-1] (no packageset)
<LocutusOfBorg> please accept haskell-filepattern amd64 binary (it was kicked out in previous ubuntus)
<LocutusOfBorg> well, it was accepted only on some archs
<RikMills> vorlon: LP: #1841891
<ubot5> Launchpad bug 1841891 in kde-artwork-active (Ubuntu) "Please remove from Eoan" [Undecided,New] https://launchpad.net/bugs/1841891
<RikMills> thanks!
<tjaalton> sil2100: hi, could you check out mesa for bionic from the queue?
<RAOF> tjaalton: I could do that for you if you like :)
<tjaalton> RAOF: oh yes, thanks
<RAOF> tjaalton: In return, I'll complain about my screen blanking each time the AMD GPU on this Kaby Lake G powers up ð
<tjaalton> heh
<tjaalton> have a bug yet?
<RAOF> Not yet.
<RAOF> Harumph. snaps really make dmesg unusable.
<RAOF> tjaalton: So, that mesa update will need to migrate only once the associated kernel is published, yes?
<tjaalton> RAOF: right
<tjaalton> which should be next week
<tjaalton> RAOF: migrated to updates that is, but can enter proposed whenever
<RAOF> Yeah, it looks good. I'm just finishing setting up my SRU-acceptance-environment
<sil2100> tjaalton: sure o/
<sil2100> rbasak: hey, re: the Colin's e-mail regarding block-proposed, I just landed support for block-proposed-SERIES tag in sru-report - should I remove showing the blocked icon for block-proposed maybe?
<sil2100> rbasak: since from what Colin said this should be only for the devel series, right?
<tjaalton> sil2100: RAOF will take care of it, thanks
<sil2100> Ok
<LocutusOfBorg> vorlon, please kick out from eoan golang-gopkg-square-go-jose.v2, it is gone from Debian testing too
<mwhudson> LocutusOfBorg: humorously enough i'm working on a script to identify packages like golang-gopkg-square-go-jose.v2 this week
-queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (bionic-proposed) [19.0.8-0ubuntu0~18.04.2]
<rbasak> sil2100: yeah sure. I don't mind either way - it's whatever meaning we choose to attach to the block-proposed tag.
<apw> rbasak, well it semantically blocks devel for that package, regardless of what meaning we add
-queuebot:#ubuntu-release- Unapproved: accepted sssd [source] (bionic-proposed) [1.16.1-1ubuntu1.4]
<mfo> sil2100, thanks for releasing of uw-imap just in time! :- )
-queuebot:#ubuntu-release- New sync: haskell-splitmix (eoan-proposed/primary) [0.0.2-1]
-queuebot:#ubuntu-release- New sync: haskell-bytestring-to-vector (eoan-proposed/primary) [0.3.0.1-1]
-queuebot:#ubuntu-release- New sync: haskell-dec (eoan-proposed/primary) [0.0.3-1]
-queuebot:#ubuntu-release- New sync: haskell-githash (eoan-proposed/primary) [0.1.3.1-1]
-queuebot:#ubuntu-release- New sync: haskell-network-byte-order (eoan-proposed/primary) [0.0.0.0-1]
-queuebot:#ubuntu-release- New sync: haskell-lens-family-core (eoan-proposed/primary) [1.2.3-1]
-queuebot:#ubuntu-release- New sync: haskell-serialise (eoan-proposed/primary) [0.2.1.0-1]
<LocutusOfBorg> please do some haskell game ^^
<LocutusOfBorg> we had some test in "running" since 10-11 days... I rescheduled them
<LocutusOfBorg> I think I remember the server got lost some days ago, and work didn't get restored correctly=
<LocutusOfBorg> ?
<LocutusOfBorg> apw, or somebody else, can you please hint ghub-plus-el on s390x? it always failed everywhere, it passed on s390x once by chance on 2017...
<LocutusOfBorg> and probably new tests have been added after that "pass"
-queuebot:#ubuntu-release- Unapproved: accepted net-snmp [source] (disco-proposed) [5.7.3+dfsg-5ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: asterisk (disco-proposed/universe) [1:16.2.1~dfsg-1 => 1:16.2.1~dfsg-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted net-snmp [source] (bionic-proposed) [5.7.3+dfsg-1.8ubuntu3.2]
-queuebot:#ubuntu-release- Unapproved: accepted net-snmp [source] (xenial-proposed) [5.7.3+dfsg-1ubuntu4.3]
-queuebot:#ubuntu-release- New binary: haskell-bytestring-conversion [i386] (eoan-proposed/universe) [0.3.1-6build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: asterisk (bionic-proposed/universe) [1:13.18.3~dfsg-1ubuntu4 => 1:13.18.3~dfsg-1ubuntu4build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-bytestring-conversion [s390x] (eoan-proposed/universe) [0.3.1-6build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-bytestring-conversion [amd64] (eoan-proposed/universe) [0.3.1-6build1] (no packageset)
<blackboxsw> Hi sil2100. We have a cloud-init SRU update queued for xenial/bionic/disco ï¿¼ cloud-init (source)
<blackboxsw> 19.2-24-ge7881d5c-0ubuntu1~16.04.1 to replace ï¿¼ 19.2-21-ge6383719-0ubuntu1~16.04.1.  in -proposed.   If you have time today, please take a peek  so we may continue our SRU testing
-queuebot:#ubuntu-release- New binary: haskell-bytestring-conversion [arm64] (eoan-proposed/universe) [0.3.1-6build1] (no packageset)
<blackboxsw> The change there is that, while testing the SRU, we also discovered a bug in the Exoscale datasource so we don't want to publish without the latest exoscale fix.
-queuebot:#ubuntu-release- New binary: haskell-bytestring-conversion [armhf] (eoan-proposed/universe) [0.3.1-6build1] (no packageset)
<blackboxsw> for context, I chatted with v-orlon and he's good with us referencing the same SRU process bug in our two most recent changelog entries.  As they are both related to the open #1841099
-queuebot:#ubuntu-release- Unapproved: mailsync (disco-proposed/universe) [5.2.2-3.1build1 => 5.2.2-3.1build1.19.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mailsync (bionic-proposed/universe) [5.2.2-3.1build1 => 5.2.2-3.1build1.18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (disco-proposed/main) [5.0.0-1001.2] (core)
-queuebot:#ubuntu-release- New: accepted typerep [amd64] (eoan-proposed) [1:0.12.0-1]
-queuebot:#ubuntu-release- New: accepted typerep [armhf] (eoan-proposed) [1:0.12.0-1]
-queuebot:#ubuntu-release- New: accepted typerep [ppc64el] (eoan-proposed) [1:0.12.0-1]
-queuebot:#ubuntu-release- New: accepted typerep [arm64] (eoan-proposed) [1:0.12.0-1]
-queuebot:#ubuntu-release- New: accepted typerep [s390x] (eoan-proposed) [1:0.12.0-1]
-queuebot:#ubuntu-release- New: accepted typerep [i386] (eoan-proposed) [1:0.12.0-1]
-queuebot:#ubuntu-release- New binary: rust-proptest [arm64] (eoan-proposed/universe) [0.9.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-proptest [armhf] (eoan-proposed/universe) [0.9.4-1] (no packageset)
<sil2100> blackboxsw: hey! Let me try looking at that after the meeting
-queuebot:#ubuntu-release- New binary: rust-proptest [ppc64el] (eoan-proposed/universe) [0.9.4-1] (no packageset)
<coreycb> vorlon: python-os-xenapi should be all set with dropping py2 packages but may need a nudge to get out of -proposed
<vorlon> coreycb: cheers :)
-queuebot:#ubuntu-release- New binary: rust-proptest [amd64] (eoan-proposed/universe) [0.9.4-1] (no packageset)
<vorlon> Recommends: fcitx-config-gtk | kde-config-fcitx, fcitx-frontend-all | fcitx-frontend-fbterm, fcitx-ui-classic | fcitx-ui-light, im-config (>= 0.5)
<vorlon> I think that's been discussed before
<LocutusOfBorg> something is happening with the queue...
<LocutusOfBorg> e.g. I can't no change rebuild ocaml-data-notation
<vorlon> tsimonq2: ^^ so back on Apr 11 we discussed here that seeding fcitx metapackage is wrong, because it has dumb depends and pulls in fcitx-frontend-all; I'm going to delete fcitx-frontend-qt now so it'll just become an unsatisfied recommends and drop out of the seed that way, but you might want to clean it up properly
-queuebot:#ubuntu-release- Unapproved: prayer (disco-proposed/universe) [1.3.5-dfsg1-6 => 1.3.5-dfsg1-6build0.19.04.1] (no packageset)
<LocutusOfBorg> oh... ocaml-data-notation is scheduled for removal
<LocutusOfBorg> nice then
<LocutusOfBorg> getting an email about the failure might be nice, but meh, I see they are coming after 24 hours :p
-queuebot:#ubuntu-release- Unapproved: prayer (bionic-proposed/universe) [1.3.5-dfsg1-4build1 => 1.3.5-dfsg1-4build2] (no packageset)
-queuebot:#ubuntu-release- New: rejected haskell-language-python [amd64] (eoan-proposed) [0.5.6-1ubuntu1]
<vorlon> seb128: you deleted fwupdate from eoan without cleaning up reverse-deps
<vorlon> seb128: you made lubuntu-desktop uninstallable
<seb128> vorlon, urg, sorry :(
<vorlon> and the package is still in Debian unstable, so why delete it?
<seb128> willcooke, ^ what was the driver for the request?
<seb128> vorlon, sorry was a bit too quick on this one, I'm leaving for holiday/airport like in an hour and tried to wrap all the things on my todo, might be best to just restore it and deal with it later
<vorlon> ok
<vorlon> restored
<willcooke> vorlon, seb128 - OEM team want it gone because it doesn't play well with the new version of fwupd (AIUI) which is needed in order to flash new docking stations.  It's considered EOL upstream AIUI
<vorlon> willcooke: then there should've been a bug report against the package with ubuntu-archive subscribed so there was an audit trail
<willcooke> https://bugs.launchpad.net/ubuntu/+source/fwupdate/+bug/1841744
<ubot5> Launchpad bug 1841744 in fwupdate (Ubuntu) "Drop fwupdate from the archive from E" [Wishlist,Fix released]
<vorlon> ah, so there was a bug but not linked from the removal comment :)
<vorlon> ok
-queuebot:#ubuntu-release- New binary: rust-proptest [s390x] (eoan-proposed/universe) [0.9.4-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-proptest [amd64] (eoan-proposed) [0.9.4-1]
-queuebot:#ubuntu-release- New: accepted rust-proptest [armhf] (eoan-proposed) [0.9.4-1]
-queuebot:#ubuntu-release- New: accepted rust-proptest [s390x] (eoan-proposed) [0.9.4-1]
-queuebot:#ubuntu-release- New: accepted rust-proptest [arm64] (eoan-proposed) [0.9.4-1]
-queuebot:#ubuntu-release- New: accepted rust-proptest [ppc64el] (eoan-proposed) [0.9.4-1]
-queuebot:#ubuntu-release- New: accepted haskell-filepattern [amd64] (eoan-proposed) [0.1.1-1build1]
<vorlon> cjwatson: fix for the multiple-override race - woot!
<cjwatson> Fingers crossed :)
 * vorlon finds a package to repeatedly override for testing
<cjwatson> vorlon: Which package did you choose?
<blackboxsw> thanks sil2100
<vorlon> cjwatson: oh sorry I hadn't actually done so, I was joking :)
-queuebot:#ubuntu-release- New: accepted mir [amd64] (eoan-proposed) [1.4.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted mir [armhf] (eoan-proposed) [1.4.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted mir [ppc64el] (eoan-proposed) [1.4.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted mir [arm64] (eoan-proposed) [1.4.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted mir [i386] (eoan-proposed) [1.4.0-0ubuntu2]
<sergiusens> vorlon: can you please look at snapcraft stuck on proposed-migration, it marks armhf error,  I suspect it is because full-isolation cannot be satisfied, http://autopkgtest.ubuntu.com/packages/snapcraft marks it with code14 ... any suggestions to move this forward is welcomed
-queuebot:#ubuntu-release- New: accepted golang-gopkg-ldap.v3 [amd64] (eoan-proposed) [3.0.3-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-github-getlantern-hidden [amd64] (eoan-proposed) [0.0~git20190325.f02dbb0-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted golang-github-getlantern-hidden [amd64] (eoan-proposed) [0.0~git20190325.f02dbb0-1ubuntu3]
<vorlon> LocutusOfBorg: looks like haskell-gtk is going to block because of gtk2hs-buildtools on ppc64el, any prognosis there?
<vorlon> sergiusens: looking
<vorlon> sergiusens: not all of the tests specify isolation-machine, several of them are failing on package installation rather than being SKIP
<vorlon> sergiusens: I will override the test failure, but maybe that needs some cleanup
-queuebot:#ubuntu-release- Unapproved: lttng-modules (bionic-proposed/universe) [2.10.5-1ubuntu1.3 => 2.10.8-1ubuntu1~18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected lttng-modules [source] (bionic-proposed) [2.10.5-1ubuntu1.3]
-queuebot:#ubuntu-release- Unapproved: accepted lttng-modules [source] (bionic-proposed) [2.10.8-1ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (disco-proposed) [19.2-24-ge7881d5c-0ubuntu1~19.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (bionic-proposed) [19.2-24-ge7881d5c-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [19.2-24-ge7881d5c-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New binary: golang-github-getlantern-errors [amd64] (eoan-proposed/universe) [0.0~git20190325.abdb3e3-1] (no packageset)
<tsimonq2> vorlon: fcitx> Alright, sounds good to me. I'll review logs from then to make sure I'm caught up with the rationale.
<blackboxsw> thanks sil2100
-queuebot:#ubuntu-release- New: accepted haskell-filepattern [amd64] (eoan-proposed) [0.1.1-1build2]
<LocutusOfBorg> vorlon, I'm asking for help in Debian-haskell since few days
<LocutusOfBorg> there is a fedora bug open, no action so far
<LocutusOfBorg> help is appreciated
<LocutusOfBorg> but meh, lets do the big work, and then we will have only that left failure
<sergiusens> vorlon: ah, thanks! I will fix
#ubuntu-release 2019-08-30
-queuebot:#ubuntu-release- Unapproved: rdma-core (bionic-proposed/main) [17.1-1ubuntu0.1 => 17.1-1ubuntu0.2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: rust-gtk [s390x] (eoan-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gtk [ppc64el] (eoan-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gtk [amd64] (eoan-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gtk [i386] (eoan-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gtk [arm64] (eoan-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gtk [armhf] (eoan-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-gtk [amd64] (eoan-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-gtk [armhf] (eoan-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-gtk [arm64] (eoan-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-getlantern-errors [amd64] (eoan-proposed) [0.0~git20190325.abdb3e3-1]
-queuebot:#ubuntu-release- New: accepted rust-gtk [ppc64el] (eoan-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-gtk [i386] (eoan-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-gtk [s390x] (eoan-proposed) [0.7.0-1]
<LocutusOfBorg> vorlon, or any other AA
<LocutusOfBorg> old binaries left on *: libtyperep-camlp4-dev (from 113.00.00-3ubuntu2)
<LocutusOfBorg> please cleanup NBS-proposed ^^
<cpaelzer> @release team - I like the automatic reminders if onan SRU dep8 tests failed
<cpaelzer> thanks!
<cpaelzer> umm I meant SRU-Team, but the release team does a lot of good things as well - I guess my subconciousness wanted to thank them as well :-)
<infinity> sil2100: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1842024
<ubot5> Launchpad bug 1842024 in glibc (Ubuntu) "[FFe] glibc 2.30 for eoan" [Undecided,New]
<sil2100> infinity: looking! I see the test build succeeded, I assume you checked installability already as well
<sil2100> Ah, indeed you did
<infinity> sil2100: Yeah.  Testing a build of gcc-9 against it too.
<doko> \o/
<RikMills> lintian in proposed
<RikMills> lintian/amd64 unsatisfiable Depends: libfile-find-rule-perl
<RikMills> lintian/amd64 unsatisfiable Depends: libio-async-loop-epoll-perl (>= 0.20)
<RikMills> huh?
<RikMills> oh. nvm
<RikMills> lintian is in main. those are not
<RikMills> :/
-queuebot:#ubuntu-release- Unapproved: ceph (bionic-proposed/main) [12.2.12-0ubuntu0.18.04.2 => 12.2.12-0ubuntu0.18.04.3] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ceph (disco-proposed/main) [13.2.6-0ubuntu0.19.04.3 => 13.2.6-0ubuntu0.19.04.4] (desktop-core, ubuntu-server)
<LocutusOfBorg> FYI, since it is difficult to have hints for autopkgtests, I'm patching rust packages to just return true in testsuite
<LocutusOfBorg> sad thing, they pass from neutral to fail
<LocutusOfBorg> vorlon`, please, somebody with some time, can hint a set of packages that passed from neutral to fail?
<LocutusOfBorg> I don't want to patch half a dozen rust packages forever
<jsech> there is any ETA for move linux-image 4.15.0-60 (Bionic) to stable?
<apw> jsech, that is likely a question better asked on #ubuntu-kernel
<jsech> ok thx
<coreycb> Hi all, I was trying to force a package to not use an eoan-proposed package by setting the depends to python3-django << 2:2.2.4-1 but that doesn't work. any tips?
<LocutusOfBorg> coreycb, depends: python3-django (==1:1.11.22-1) ?
<coreycb> LocutusOfBorg: i tried that as well but it still wants to pull in 2:2.2.4-1
<coreycb> LocutusOfBorg: hmm i wonder if dh_python is overriding. let me check.
<coreycb> LocutusOfBorg: no dh_python isn't overriding
-queuebot:#ubuntu-release- Unapproved: ec2-hibinit-agent (bionic-proposed/main) [1.0.0-0ubuntu4~18.04.2 => 1.0.0-0ubuntu4~18.04.3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ec2-hibinit-agent (xenial-proposed/main) [1.0.0-0ubuntu4~16.04.2 => 1.0.0-0ubuntu4~16.04.3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ec2-hibinit-agent (disco-proposed/main) [1.0.0-0ubuntu4.19.04.1 => 1.0.0-0ubuntu4.19.04.2] (no packageset)
<rbalint> tjaalton, could you please review and hopefully accept them? ^
<vorlon> LocutusOfBorg: do you have a list of these packages that you want hinted?
-queuebot:#ubuntu-release- New source: python-masakariclient (eoan-proposed/primary) [5.4.0-0ubuntu1]
<LocutusOfBorg> yes vorlon
<vorlon> are you going to give that list to me also? ;-)
<LocutusOfBorg> yes, let me open a pad somewhere
-queuebot:#ubuntu-release- Unapproved: accepted ec2-hibinit-agent [source] (disco-proposed) [1.0.0-0ubuntu4.19.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted ec2-hibinit-agent [source] (bionic-proposed) [1.0.0-0ubuntu4~18.04.3]
-queuebot:#ubuntu-release- Unapproved: accepted ec2-hibinit-agent [source] (xenial-proposed) [1.0.0-0ubuntu4~16.04.3]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (disco-proposed) [5.0.0-1001.2]
<LocutusOfBorg> vorlon, https://etherpad.openstack.org/p/hints
<LocutusOfBorg> I'm still editing, feel free to delete from there if anything is added to hints :)
-queuebot:#ubuntu-release- Unapproved: accepted sane-backends [source] (disco-proposed) [1.0.27-3.2ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted sane-backends [source] (bionic-proposed) [1.0.27-1~experimental3ubuntu2.2]
-queuebot:#ubuntu-release- New binary: doris [amd64] (eoan-proposed/multiverse) [5.0.3~beta+dfsg-12] (no packageset)
<vorlon> LocutusOfBorg: rust-num-traits: we appear to be working at cross-purposes.  You say you disabled the testsuite on i386 to get it to build, why should we be deliberately building a package that doesn't pass its tests?  I had been ripping out the reverse-dependencies of rust-num-traits instead on i386
<vorlon> it's a numeric package and it's buggy on i386 and the testsuite shows this
<LocutusOfBorg> vorlon, it was not a regression
<LocutusOfBorg> testsuite has been disabled in previous release, it is a bug RC in debian, we don't care about i386...
<LocutusOfBorg> so, eventually i386 will come back from Debian...
<LocutusOfBorg> also I saw you removed, but rust-im was broken then
<LocutusOfBorg> this one https://launchpad.net/ubuntu/+source/rust-im-rc
-queuebot:#ubuntu-release- New source: python-purestorage (eoan-proposed/primary) [1.17.0-0ubuntu1]
<vorlon> LocutusOfBorg: if it comes back on its own because Debian fixes it, fine.  That's not a reason to ignore test failures and ship known-broken stuff though.  Also, per the changelog, "ignore test results everywhere"?
<vorlon> LocutusOfBorg: regardless, I think introducing a delta to get a package to build on i386, vs removing the i386 binaries, is a bad call given that i386 is no longer supported as a host architecture
<tjaalton> rbalint: sorry, was off today
-queuebot:#ubuntu-release- Unapproved: ibm-java80 (xenial-release/partner) [8.0.5.40-0ubuntu1 => 8.0.5.40-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ibm-java80 (bionic-release/partner) [8.0.5.35-0ubuntu1 => 8.0.5.40-0ubuntu1] (no packageset) (sync)
<coreycb> vorlon: we're in a little bit of a pickle with python3-django. i attempted to update openstack dashboard packages with (Build-)Depends on << 2:2.2.4-1 to prevent using the version in eoan-proposed, but the builds still wants to use 2:2.2.4-1. side note: upstream may or may not land 2.2.4 support this cycle; it hasn't landed yet. have any suggestions on how to move forward? can i force BDs to use what's in
<coreycb> eoan-release?
<cjwatson> B-D: << basically doesn't work except at best maybe to force failures
<cjwatson> The only way to do something like that would be to have a parallel source package with the earlier version you need
<coreycb> cjwatson: ok thanks for confirming. i tried = as well and no luck there either.
<cjwatson> I have no idea whether that is practical in this case
<coreycb> cjwatson: what do you mean by parallel?
<cjwatson> In general (notwithstanding the conversation in #ubuntu-devel at the moment ...) older versions of binary packages aren't kept around
<cjwatson> Sometimes it's possible to have a separate older version with different source and binary *names* (not just versions) to work around this
<cjwatson> I suspect that's pretty impractical with python3-django though
<cjwatson> So ... yes, you're in a pickle, and it's kind of inherent to the Debian-style distribution model generally only shipping one version of things
<coreycb> cjwatson: thanks for the explanation. certainly doesn't sound pretty.
<cjwatson> Since the newer python-django hasn't migrated to release yet, we're not yet committed to shipping with it, of course
<cjwatson> But I don't know how much other stuff that would hold back
<vorlon> coreycb: right, the end goal is that by the end of the cycle, -proposed is approximately empty, and everything in the release pocket which we ship is self-hosting in terms of build/install/test
<vorlon> in practice only "install" is hard-enforced, build+test are squishier, at least partly by design in order to avoid making it even harder than necessary to move things from proposed to release due to ordering constraints
<vorlon> we also build against everything in -proposed because that's usually also the correct optimization (and sometimes strictly required, for transitions)
<vorlon> coreycb: so if openstack isn't going to be compatible with python-django 2.2 by release time, then we should probably remove it from -proposed to let packages build
<vorlon> (or you could disable any build-time tests that rely on a compatible django?)
<cjwatson> Though check how much else that would break that's already been built against it ...
<coreycb> vorlon: ah, so install Depends should understand << logic?
<coreycb> vorlon: yes you said that. so maybe i can disable tests
<coreycb> i'll look into that a bit more and also see if the upstream patches are backward compatible in case they do land.
<vorlon> coreycb: both runtime and build-time depends "understand" << logic, it's just a question of how the archive helps you resolve unsatisfied deps
<coreycb> vorlon: right ok
<cjwatson> All that Depends: << is likely to do is help prevent other things from migrating when they would break you
 * vorlon nods
<cjwatson> It won't make it possible for django 1.11 and 2.2 to coexist in eoan
<coreycb> cjwatson: vorlon: ok thanks for all the info. i have some homework to do and will get back to you if we need to look into keeping 1.11.
<vorlon> coreycb: the reality is, python-django 2.2 doesn't look like it's going anywhere for eoan anyway, there are various revdeps with failing autopkgtests unrelated to openstack
-queuebot:#ubuntu-release- New binary: haskell-criterion-measurement [amd64] (eoan-proposed/universe) [0.1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-bytestring-conversion [ppc64el] (eoan-proposed/universe) [0.3.1-6build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-criterion-measurement [i386] (eoan-proposed/universe) [0.1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-libyaml [amd64] (eoan-proposed/universe) [0.1.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-libyaml [i386] (eoan-proposed/universe) [0.1.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-cassava-megaparsec [amd64] (eoan-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-criterion-measurement [arm64] (eoan-proposed/universe) [0.1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-cassava-megaparsec [i386] (eoan-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-criterion-measurement [armhf] (eoan-proposed/universe) [0.1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-libyaml [armhf] (eoan-proposed/universe) [0.1.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-libyaml [arm64] (eoan-proposed/universe) [0.1.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-cassava-megaparsec [arm64] (eoan-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-cassava-megaparsec [armhf] (eoan-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-libyaml [ppc64el] (eoan-proposed/universe) [0.1.1.0-2] (no packageset)
<coreycb> vorlon: i wouldn't object to sticking with 1.11 this cycle
-queuebot:#ubuntu-release- New binary: haskell-libyaml [s390x] (eoan-proposed/universe) [0.1.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-cassava-megaparsec [ppc64el] (eoan-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-cassava-megaparsec [s390x] (eoan-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-criterion-measurement [ppc64el] (eoan-proposed/universe) [0.1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-criterion-measurement [ppc64el] (eoan-proposed) [0.1.1.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-cassava-megaparsec [arm64] (eoan-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-cassava-megaparsec [ppc64el] (eoan-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-libyaml [armhf] (eoan-proposed) [0.1.1.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-libyaml [s390x] (eoan-proposed) [0.1.1.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-cassava-megaparsec [armhf] (eoan-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-libyaml [ppc64el] (eoan-proposed) [0.1.1.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-cassava-megaparsec [s390x] (eoan-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-cassava-megaparsec [amd64] (eoan-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-criterion-measurement [arm64] (eoan-proposed) [0.1.1.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-libyaml [amd64] (eoan-proposed) [0.1.1.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-libyaml [i386] (eoan-proposed) [0.1.1.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-cassava-megaparsec [i386] (eoan-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-libyaml [arm64] (eoan-proposed) [0.1.1.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-criterion-measurement [armhf] (eoan-proposed) [0.1.1.0-1]
-queuebot:#ubuntu-release- New: accepted doris [amd64] (eoan-proposed) [5.0.3~beta+dfsg-12]
-queuebot:#ubuntu-release- New: accepted haskell-criterion-measurement [i386] (eoan-proposed) [0.1.1.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-criterion-measurement [amd64] (eoan-proposed) [0.1.1.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted shadow [source] (disco-proposed) [1:4.5-1.1ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted shadow [source] (bionic-proposed) [1:4.5-1ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted shadow [source] (xenial-proposed) [1:4.2-3.1ubuntu5.5]
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (disco-proposed) [5.0.0-1ubuntu2.5]
#ubuntu-release 2019-08-31
<tkamppeter> Hi, seems that the server for the armhf autopkg tests for the eoan-proposed migration needs attention, see ghostscript and cups-filters packages.
<vorlon> tkamppeter: thanks for the heads-up, looking
<vorlon> Laney, juliank: looks like the lxd-hosting VMs are being hit by a kernel bug wrt networking https://paste.ubuntu.com/p/yJKZTfrDFD/
<juliank> That's a bit unfortunate
<vorlon> I've rebooted lxd-armhf1 and am working on getting it up again, to see if it's reproducible and/or we can pinpoint the trigger
<vorlon> but also, /srv is filled up with images for dead containers from previous autopkgtests
<juliank> eww
<vorlon> # lxc list | wc -l
<vorlon> 551
<vorlon> #
<vorlon> so yeah, afk while the lxc delete runs
#ubuntu-release 2019-09-01
-queuebot:#ubuntu-release- New binary: parfive [amd64] (eoan-proposed/universe) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted parfive [amd64] (eoan-proposed) [1.0.0-2]
<fossfreedom> ^^^ I'm a little confused (not for the first time) - if nonpackageset packages such as parfive are being sync'd from unstable - why are none of the v4 cinnamon packages currently in unstable not also sync'ing to eoan?
<mitya57> fossfreedom: we are in Debian import freeze so packages are synced manually, not automatically
<fossfreedom> ah - so someone sync'd parfive
<mitya57> If you expand the last entry (Status=Deleted) in https://launchpad.net/ubuntu/+source/parfive/1.0.0-2/+publishinghistory, you will see that it was âCopied from debian sid in Primary Archive for Debian GNU/Linux by Steve Langasekâ
<fossfreedom> thx
<vorlon> it was synced specifically because it's a new package and a build-dependency of new sunpy, which needed an update for compatibility with new astropy
<fossfreedom> the reason for the question is that I found a usability issue in cinnamon and was wondering whether to go through the sponsorship process to get it fixed in ubuntu eoan's older version ... it was already fixed in the later version in Debian. you've answered my Q. thx
<ginggs> Eickmeyer: what do you think of blender 2.80+dfsg-3 for eoan?
<Eickmeyer> ginggs: I say go for it. My people usually like to have the latest on most packages anyhow.
<ginggs> Eickmeyer: ok, I'll prepare an FFe :-) it will need your input since it is seeded in ubuntustudio
<Eickmeyer> ginggs: Might also have to be a sync request as well if you're planning on bringing it in from Debian.
<ginggs> Eickmeyer: 'requestsync -e blender' does it all in one.  Please +1 LP: #1842215
<ubot5> Launchpad bug 1842215 in blender (Ubuntu) "FFe: Sync blender 2.80+dfsg-3 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1842215
<Eickmeyer> ginggs: Done
<ginggs> Eickmeyer: thanks!
-queuebot:#ubuntu-release- New binary: haskell-bytestring-conversion [amd64] (eoan-proposed/universe) [0.3.1-6build2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-bytestring-conversion [s390x] (eoan-proposed/universe) [0.3.1-6build2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-bytestring-conversion [i386] (eoan-proposed/universe) [0.3.1-6build2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-bytestring-conversion [ppc64el] (eoan-proposed/universe) [0.3.1-6build2] (no packageset)
-queuebot:#ubuntu-release- New sync: haskell-bytestring-to-vector (eoan-proposed/primary) [0.3.0.1-2]
-queuebot:#ubuntu-release- New binary: haskell-bytestring-conversion [arm64] (eoan-proposed/universe) [0.3.1-6build2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-bytestring-conversion [armhf] (eoan-proposed/universe) [0.3.1-6build2] (no packageset)
-queuebot:#ubuntu-release- New sync: haskell-githash (eoan-proposed/primary) [0.1.3.1-3]
<LocutusOfBorg> hello, is removing python2 packages considered a "feature"?
<ginggs> do you mean, as in Feature Freeze?
<LocutusOfBorg> yes, like this one (an example)
<LocutusOfBorg> reverse-depends -b python-sql -r eoan
<LocutusOfBorg> no reverse-deps, the new Debian upload just dropped python2 binding
-queuebot:#ubuntu-release- New sync: haskell-network-byte-order (eoan-proposed/primary) [0.0.0.0-2]
-queuebot:#ubuntu-release- New sync: haskell-serialise (eoan-proposed/primary) [0.2.1.0-3]
-queuebot:#ubuntu-release- New sync: haskell-simple (eoan-proposed/primary) [0.11.2-4]
-queuebot:#ubuntu-release- New sync: haskell-simple-templates (eoan-proposed/primary) [0.8.0.1-6]
-queuebot:#ubuntu-release- New sync: haskell-splitmix (eoan-proposed/primary) [0.0.2-2]
<vorlon> LocutusOfBorg: reverse-depends doesn't pick up on test dependencies; so it's not entirely free of risk that dropping the package will reduce releasability of the archive.
-queuebot:#ubuntu-release- New binary: ejabberd-contrib [amd64] (eoan-proposed/universe) [0.2019.08.19~dfsg0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ejabberd-contrib [i386] (eoan-proposed/universe) [0.2019.08.19~dfsg0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ejabberd-contrib [arm64] (eoan-proposed/universe) [0.2019.08.19~dfsg0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ejabberd-contrib [ppc64el] (eoan-proposed/universe) [0.2019.08.19~dfsg0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ejabberd-contrib [armhf] (eoan-proposed/universe) [0.2019.08.19~dfsg0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ejabberd-contrib [s390x] (eoan-proposed/universe) [0.2019.08.19~dfsg0-3] (no packageset)
<mwhudson> vorlon: looks plausible? https://paste.ubuntu.com/p/JfZ4cNTxRv/
#ubuntu-release 2020-08-24
-queuebot:#ubuntu-release- New binary: ayatana-indicator-sound [riscv64] (groovy-proposed/universe) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libreoffice [armhf] (groovy-proposed/main) [1:7.0.1~rc1-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: bup [riscv64] (groovy-proposed/universe) [0.31-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-meta [source] (bionic-proposed) [1.417.5]
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.17 => 2.02-2ubuntu8.18] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.27 => 2.02~beta2-36ubuntu3.28] (core)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (bionic-proposed/main) [1.93.19 => 1.93.20] (core)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (xenial-proposed/main) [1.66.27 => 1.66.28] (core)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (focal-proposed/main) [5.4.0-1022.22] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp-5.4 [amd64] (bionic-proposed/main) [5.4.0-1022.22~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libreoffice [amd64] (groovy-proposed) [1:7.0.1~rc1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libreoffice [armhf] (groovy-proposed) [1:7.0.1~rc1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libreoffice [s390x] (groovy-proposed) [1:7.0.1~rc1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libreoffice [arm64] (groovy-proposed) [1:7.0.1~rc1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libreoffice [ppc64el] (groovy-proposed) [1:7.0.1~rc1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure-5.4 [amd64] (bionic-proposed) [5.4.0-1023.23~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (focal-proposed) [5.4.0-1022.22]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp-5.4 [amd64] (bionic-proposed) [5.4.0-1022.22~18.04.1]
-queuebot:#ubuntu-release- New binary: ruby-kramdown-parser-gfm [amd64] (groovy-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-gke-5.3 [amd64] (bionic-proposed/universe) [5.3.0-1034.36] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (xenial-proposed/main) [1.361.4 => 1.361.5] (core)
-queuebot:#ubuntu-release- Unapproved: command-not-found (focal-proposed/main) [20.04.2 => 20.04.4] (core)
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.3 [amd64] (bionic-proposed) [5.3.0-1034.36]
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (bionic-proposed/main) [1.417.4 => 1.417.5] (core)
<tjaalton> Wimpress: hi, the mate updates on focal queue all have a version of '-0ubuntu0'?
-queuebot:#ubuntu-release- New: accepted ayatana-indicator-sound [amd64] (groovy-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted ayatana-indicator-sound [armhf] (groovy-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted ayatana-indicator-sound [riscv64] (groovy-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted ayatana-indicator-sound [arm64] (groovy-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted ayatana-indicator-sound [s390x] (groovy-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted ayatana-indicator-sound [ppc64el] (groovy-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted bup [riscv64] (groovy-proposed) [0.31-1]
-queuebot:#ubuntu-release- New: accepted libplacebo [arm64] (groovy-proposed) [2.72.0-2]
-queuebot:#ubuntu-release- New: accepted libplacebo [i386] (groovy-proposed) [2.72.0-2]
-queuebot:#ubuntu-release- New: accepted libplacebo [riscv64] (groovy-proposed) [2.72.0-2]
-queuebot:#ubuntu-release- New: accepted ruby-kramdown-parser-gfm [amd64] (groovy-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: rejected dragonfly-reverb [source] (groovy-proposed) [3.2.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libplacebo [ppc64el] (groovy-proposed) [2.72.0-2]
-queuebot:#ubuntu-release- New: accepted libplacebo [armhf] (groovy-proposed) [2.72.0-2]
-queuebot:#ubuntu-release- New: accepted libplacebo [s390x] (groovy-proposed) [2.72.0-2]
-queuebot:#ubuntu-release- New: accepted cfitsio [armhf] (groovy-proposed) [3.490-2]
-queuebot:#ubuntu-release- New: accepted cfitsio [amd64] (groovy-proposed) [3.490-3]
-queuebot:#ubuntu-release- New: accepted cfitsio [armhf] (groovy-proposed) [3.490-3]
-queuebot:#ubuntu-release- New: accepted cfitsio [riscv64] (groovy-proposed) [3.490-3]
-queuebot:#ubuntu-release- New: accepted libplacebo [amd64] (groovy-proposed) [2.72.0-2]
-queuebot:#ubuntu-release- New: accepted cfitsio [riscv64] (groovy-proposed) [3.490-2]
-queuebot:#ubuntu-release- New: accepted cfitsio [ppc64el] (groovy-proposed) [3.490-3]
-queuebot:#ubuntu-release- New: accepted cfitsio [arm64] (groovy-proposed) [3.490-3]
-queuebot:#ubuntu-release- New: accepted cfitsio [s390x] (groovy-proposed) [3.490-3]
-queuebot:#ubuntu-release- New: accepted cfitsio [amd64] (groovy-proposed) [3.490-2]
-queuebot:#ubuntu-release- New: accepted cfitsio [ppc64el] (groovy-proposed) [3.490-2]
-queuebot:#ubuntu-release- New: accepted ilmbase [arm64] (groovy-proposed) [2.5.3-2]
-queuebot:#ubuntu-release- New: accepted ilmbase [i386] (groovy-proposed) [2.5.3-2]
-queuebot:#ubuntu-release- New: accepted ilmbase [riscv64] (groovy-proposed) [2.5.3-2]
-queuebot:#ubuntu-release- New: accepted cfitsio [arm64] (groovy-proposed) [3.490-2]
-queuebot:#ubuntu-release- New: accepted ilmbase [armhf] (groovy-proposed) [2.5.3-2]
-queuebot:#ubuntu-release- New: accepted pysiogame [amd64] (groovy-proposed) [4.20.01-1]
-queuebot:#ubuntu-release- New: accepted cfitsio [s390x] (groovy-proposed) [3.490-2]
-queuebot:#ubuntu-release- New: accepted ilmbase [ppc64el] (groovy-proposed) [2.5.3-2]
-queuebot:#ubuntu-release- New: accepted ilmbase [amd64] (groovy-proposed) [2.5.3-2]
-queuebot:#ubuntu-release- New: accepted ilmbase [s390x] (groovy-proposed) [2.5.3-2]
-queuebot:#ubuntu-release- New binary: linux-signed-gke-5.4 [amd64] (bionic-proposed/universe) [5.4.0-1022.22~18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (bionic-proposed) [2.02-2ubuntu8.18]
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (bionic-proposed) [1.93.20]
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.18 => 2.02-2ubuntu8.18] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.18 => 2.02-2ubuntu8.18] (core)
<xnox> vorlon:  https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4221/+build/19871413
<vorlon> xnox: lgtm thank you
<xnox> vorlon:  will copy that into the archive once riscv64 publishes
<xnox> vorlon:  and then will work on rebuilds
-queuebot:#ubuntu-release- New: accepted base-files [amd64] (focal-proposed) [11ubuntu5.2]
-queuebot:#ubuntu-release- New: accepted base-files [amd64] (bionic-proposed) [10.1ubuntu2.10]
-queuebot:#ubuntu-release- New: accepted base-files [amd64] (xenial-proposed) [9.4ubuntu4.13]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (focal-proposed) [1.450.2]
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (bionic-proposed/main) [1.417.4 => 1.417.5] (core)
<xnox> redoing glib2.0 builds
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-meta [source] (bionic-proposed) [1.417.5]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (bionic-proposed) [1.417.5]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (xenial-proposed) [1.361.5]
<ricotz> xnox, hi, what is the reason for having a git snapshot of libffi?
<xnox> ricotz:  Intel CET support
<xnox> seb128:  i will fix up glib2.0 build in a moment.
<ricotz> xnox, I see, ty
<ricotz> no bug tracking it and no mention in the changelog about it doesn't look good at all imho
<ricotz> xnox, note there was a glib 2.65.1-1 uploaded
<xnox> ricotz:  i know
<ahasenack> xnox: will you do a new ffi upload? The package name libffi8ubuntu1 doesn't look right
<xnox> ahasenack:  libffi8ubuntu1 is the one that vorlon asked for. if you don't like libffi8ubuntu1 name, take it up with vorlon.
<ahasenack> I see you apparently didn't like it too :)
<xnox> very much not =)
<ahasenack> haha
<xnox> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4221/+packages is where libffi8.1.0 => libffi8ubuntu1 rebootstrap is ongoing, should make things installable in groovy-proposed shortly after all them finihs.
<ahasenack> cool
<xnox> Running suite(s): gtk-doc-glib
<xnox> glib-unused.txt:1:E: 36 unused documentation entries
<xnox> hm
<xnox> vorlon:  can you please remove glib2.0 2.65.1-1 from groovy-proposed, such that i can copy in glib2.0 2.64.4-1build2 built against libffi8 in?
<xnox> 2.65.1-1 appears to ftbfs on amd64 causing lots of sad. something something failing doc tests
<xnox> Running suite(s): gtk-doc-glib
<xnox> glib-unused.txt:1:E: 36 unused documentation entries
<xnox> ok reproducible in experiemntal and 2.65.2 as well.
<xnox> so gonna skip that, and reupload to bileto ppa
<xnox> ok twiddle thumbs
#ubuntu-release 2020-08-25
-queuebot:#ubuntu-release- Unapproved: valgrind (bionic-proposed/main) [1:3.13.0-2ubuntu2.2 => 1:3.13.0-2ubuntu2.3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: valgrind (focal-proposed/main) [1:3.15.0-1ubuntu9 => 1:3.15.0-1ubuntu9.1] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (xenial-proposed) [2.02~beta2-36ubuntu3.28]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (bionic-proposed) [2.02-2ubuntu8.18]
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (xenial-proposed) [1.66.28]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (bionic-proposed) [2.02-2ubuntu8.18]
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.28 => 2.02~beta2-36ubuntu3.28] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.28 => 2.02~beta2-36ubuntu3.28] (core)
-queuebot:#ubuntu-release- Unapproved: accepted shim [sync] (focal-proposed) [15+1552672080.a4a1fbe-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (focal-proposed) [1.40.4]
-queuebot:#ubuntu-release- New: accepted build-essential [amd64] (focal-proposed) [12.8ubuntu1.1]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1081.92~16.04.1] (kernel)
-queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (bionic-proposed) [1.37~18.04.7]
-queuebot:#ubuntu-release- Unapproved: accepted shim [sync] (bionic-proposed) [15+1552672080.a4a1fbe-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (xenial-proposed) [2.02~beta2-36ubuntu3.28]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (xenial-proposed) [2.02~beta2-36ubuntu3.28]
-queuebot:#ubuntu-release- Unapproved: accepted shim [sync] (xenial-proposed) [15+1552672080.a4a1fbe-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (xenial-proposed) [1.33.1~16.04.6]
-queuebot:#ubuntu-release- Unapproved: grubzfs-testsuite (focal-proposed/universe) [0.4.10 => 0.4.10.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.4 [amd64] (bionic-proposed) [5.4.0-1022.22~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1081.92~16.04.1]
<ricotz> rbasak, hi :), any progress on https://bugs.launchpad.net/ubuntu/+source/vala/+bug/1891318 ?
<ubot5> Ubuntu bug 1891318 in vala (Ubuntu) " [SRU] Update to vala 0.48.9 in focal " [Undecided,New]
<rbasak> RAOF: ^ any progress on the GNOME MRE clarification please?
-queuebot:#ubuntu-release- Unapproved: snapd (bionic-proposed/main) [2.45.1+18.04.2 => 2.46+18.04] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.45.1ubuntu0.2 => 2.46] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (focal-proposed/main) [2.45.1+20.04.2 => 2.46+20.04] (core)
<Eickmeyer> ubuntu-archive (specifically vorlon): any progress on dragonfly-reverb?
<rbalint> sil2100, could you please merge one more hint for systemd? https://code.launchpad.net/~rbalint/britney/hints-ubuntu/+merge/389807
<DWSR> Hey everyone, I'm looking for some information on how to build a custom Ubuntu image for a Raspberry Pi. Is the build process for Ubuntu documented publicly somewhere?
<RikMills> login to bileto is broken?
<vorlon> so it appears
<vorlon> sil2100: ^^ ?
<RikMills> :/
<rbalint> ubuntu-archive what is the status of udebs? systemd migration is blocked on udeb dependencies in groovy
<rbalint> ubuntu-archive also on libreswan but it can be hinted https://code.launchpad.net/~rbalint/britney/hints-ubuntu/+merge/389807
<vorlon> rbalint: udebs are all being demoted to universe; looking at this now
<vorlon> demoted libudev1-udeb, udev-udeb in groovy and groovy-proposed
<rbalint> vorlon, thanks!
-queuebot:#ubuntu-release- Unapproved: sbsigntool (focal-proposed/main) [0.9.2-2ubuntu1 => 0.9.2-2ubuntu1.20.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: sbsigntool (bionic-proposed/main) [0.6-3.2ubuntu2 => 0.6-3.2ubuntu2.18.04.1] (core)
<sil2100> vorlon, RikMills: geh, crap, let me try getting to that
<sil2100> (but most likely tomorrow)
<RikMills> sil2100: no worries. still ~2 days to feature freeze ;)
<RikMills> I have already mostly test built elsewhere already...
<Eickmeyer> vorlon: Any progress on dragonfly-reverb? I've honestly been trying to get this into the archive since March and it keeps stalling-out.
#ubuntu-release 2020-08-26
<RAOF> rbasak: The current state of GNOME MRU clarification is I've talked with Seb and he's gone âyeah, I don't know; we should clarify thatâ, and I've written https://discourse.ubuntu.com/t/scope-of-gnome-mru/18041
-queuebot:#ubuntu-release- Unapproved: ubuntustudio-default-settings (focal-proposed/universe) [20.04.2.1 => 20.04.2.2] (ubuntustudio)
<Eickmeyer>  ^ bug 1892949
<ubot5> bug 1892949 in ubuntustudio-default-settings (Ubuntu Groovy) "[SRU] grub can no longer detect kernels after ubuntustudio-lowlatency-settings is uninstalled" [High,Fix committed] https://launchpad.net/bugs/1892949
<RAOF> Eickmeyer: Could I trouble you for a better changelog entry for that SRU? The changelog entry is the only user-visible notification of *why*  we're SRUing something, and âadd ubuntustudio-lowlatency-settings.postrmâ is entirely uninteresting to users.
<RAOF> Yes, there's a link to the actual bug there. We'd still prefer that you summarise the fix (and what it fixes).
<RAOF> Something like âEnsure removing ubuntustudio-lowlatency-settings package doesn't remove all kernels from GRUB boot menuâ or, similar.
-queuebot:#ubuntu-release- Unapproved: rejected ubuntustudio-default-settings [source] (focal-proposed) [20.04.2.2]
<ginggs> ubuntu-archve would someone please remove pyhst2's amd64 binaries from -release?  this would help me by allowing nvidia-cuda-toolkit to migrate.  libhst2 can migrate later along with nvidia-graphics-drivers-450 and linux-restricted-modules-*
<ginggs> ubuntu-archive even ^
<apw> ginggs, would -450 migrating take libhst2 with it as things stand and solve your issue too?
<ginggs> apw: yes it would
<ginggs> apw: i'd like nvidia-cuda-toolkit to migrate so i can sync in the next version from experimental, before feature freeze though
<apw> ginggs, sorry i left the context out; i am hoping that what i just did to the archive will let that pile migrate in the next run, maybe
<ginggs> apw: ok, that sounds great, thanks!
<apw> ginggs, if it doesn't (and all things are possible, i won't be supprised if there is something else hiding in here) then we can revisit the removal
<ginggs> apw: ack
<sil2100> RikMills, vorlon: ok, bileto login should now work once again
<sil2100> Took a bit of digging in though, phew
<RikMills> sil2100: excellent. thank you :)
<ginggs> apw: it worked \o/ thanks!
<apw> ginggs, miraculously
-queuebot:#ubuntu-release- Unapproved: s390-tools (groovy-proposed/main) [2.12.0-0ubuntu6 => 2.14.0-1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: sosreport (focal-proposed/main) [3.9.1-1ubuntu0.20.04.2 => 4.0-1~ubuntu0.20.04.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: nvidia-cuda-toolkit [amd64] (groovy-proposed/multiverse) [11.0.3-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: sosreport (focal-proposed/main) [3.9.1-1ubuntu0.20.04.2 => 4.0-1~ubuntu0.20.04.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected sosreport [source] (focal-proposed) [4.0-1~ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: secureboot-db (bionic-proposed/main) [1.4~ubuntu0.18.04.1 => 1.4.1] (core)
-queuebot:#ubuntu-release- Unapproved: secureboot-db (xenial-proposed/main) [1.4~ubuntu0.16.04.1 => 1.4.1~ubuntu0.16.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: secureboot-db (trusty-proposed/main) [1.4~ubuntu0.14.04.1 => 1.4.1~ubuntu0.14.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: secureboot-db (focal-proposed/main) [1.5 => 1.6~20.04.1] (core)
-queuebot:#ubuntu-release- New source: nvidia-graphics-drivers-450 (bionic-proposed/primary) [450.66-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New source: nvidia-graphics-drivers-450 (focal-proposed/primary) [450.66-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- New source: nvidia-graphics-drivers-450-server (bionic-proposed/primary) [450.51.06-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New source: nvidia-graphics-drivers-450-server (focal-proposed/primary) [450.51.06-0ubuntu0.20.04.1]
<Eickmeyer> RAOF: Thanks, reuploaded.
-queuebot:#ubuntu-release- Unapproved: ubuntustudio-default-settings (focal-proposed/universe) [20.04.2.1 => 20.04.2.2] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: linux-signed-oem-5.6 [amd64] (focal-proposed/main) [5.6.0-1023.23] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle-5.4 [amd64] (bionic-proposed/main) [5.4.0-1022.22~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: nvidia-cuda-toolkit [ppc64el] (groovy-proposed/multiverse) [11.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-5.6 [amd64] (focal-proposed) [5.6.0-1023.23]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle-5.4 [amd64] (bionic-proposed) [5.4.0-1022.22~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted command-not-found [source] (focal-proposed) [20.04.4]
 * apw is looking at nvidia-*450*
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-450 [source] (bionic-proposed) [450.66-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-450 [source] (focal-proposed) [450.66-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-450 [i386] (bionic-proposed/multiverse) [450.66-0ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-450 [i386] (focal-proposed/multiverse) [450.66-0ubuntu0.20.04.1] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-450 [amd64] (bionic-proposed/multiverse) [450.66-0ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-450 [amd64] (focal-proposed/multiverse) [450.66-0ubuntu0.20.04.1] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: nvidia-cuda-toolkit [arm64] (groovy-proposed/multiverse) [11.0.3-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: chromium-browser (focal-proposed/universe) [84.0.4147.105-0ubuntu0.20.04.1 => 1:85.0.4183.83-0ubuntu0.20.04.1] (ubuntu-desktop)
<slashd> o/ sru vanguard, could you please reject my sosreport upload ? I'll re-upload later, I need to talk to sil2100 about some specifics first.
<slashd> in focal ^ https://launchpad.net/ubuntu/focal/+queue?queue_state=1&queue_text=sosreport
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (focal-proposed/main) [1:20.04.24 => 1:20.04.25] (core)
-queuebot:#ubuntu-release- Unapproved: rejected sosreport [source] (focal-proposed) [4.0-1~ubuntu0.20.04.1]
<sergiodj> hi there, libapache2-mod-wsgi has been dropped on Debian and we've just sync'ed mod-wsgi, so I filed https://bugs.launchpad.net/ubuntu/+source/mod-wsgi/+bug/1893100 to make sure we RM libapache2-mod-wsgi from groovy
<ubot5> Ubuntu bug 1893100 in mod-wsgi (Ubuntu) "[RM] libapache2-mod-wsgi from groovy" [Undecided,New]
<vorlon> Eickmeyer: hi, so I'm continuing the review of dragonfly-reverb, and I've just run into the same issue with the font as .cpp that RAOF previously noted to you.  The Open Font License is not GPL-compatible; we can't have binaries that contain both GPL code and compiled-in fonts that are under the SIL Open Font License, that's not distributable
<vorlon> Eickmeyer: I also found some smaller issues with debian/copyright declaring wrong licenses for a few files; they're all GPL-compatible licenses so it's not a major issue but should still be fixed: https://paste.ubuntu.com/p/JHXQ3PDZnn/
<vorlon> Eickmeyer: however, the embedded font makes the whole binary package nondistributable, so this is a reject, unless we could prove that the embedded font is not actually used
<vorlon> (i.e. not compiled in)
<vorlon> Eickmeyer: well I just checked, and it is definitely compiled into the binary.  So that needs to be addressed before this can be accepted.
-queuebot:#ubuntu-release- Unapproved: smartmontools (xenial-proposed/main) [6.4+svn4214-1 => 6.4+svn4214-1ubuntu0.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: smartmontools (bionic-proposed/main) [7.0-0ubuntu1~ubuntu18.04.1 => 6.5+svn4324-1ubuntu0.1] (ubuntu-server)
-queuebot:#ubuntu-release- New: rejected dragonfly-reverb [source] (groovy-proposed) [3.2.0-0ubuntu1]
<teward> vorlon: i'll copy/paste this to them in Telegram, I seem to remember they're suffering from system-not-available problems.  Ten bucks says this won't get in on the groovy cycle this close to freezes
<teward> (re: dragonfly-reverb)
<vorlon> given that it will require an upstream fix, I'm not surprised, unfortunate that it is
<teward> yup
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (focal-proposed/main) [2.664.5 => 2.664.6] (desktop-core, i386-whitelist)
<teward> vorlon: this will sound a liiiiiitle bit janky, but... assuming that single font isn't crucial to the application could it be yanked out during build-time before ti actually builds so the font isn't compiled in?
<teward> just wondering :p
<teward> (it's a janky approach but still)
<teward> ... oh ffs, 18.04 -> 20.04 upgrade broke my sbuild envs locally >.>
<teward> *spends the next hour redoing his sbuild*
<sarnold> any application that has compiled in a specific font is unlikely to handle that font going missing
<sarnold> if you're lucky you wind up with big blank areas where text should be
<sarnold> if you're unlucky it'll fall over and won't let you do anything
<sarnold> if you're very unlucky they've never read danluu's page about file IO, and it'll corrupt stuff while falling over
<teward> hah lol sarnold
<RikMills> vorlon: quick query on your copyright comments. I note you imply that some incompatible copyright files may be ok if not compiled in/used? reason I ask as I want to get a source uploaded that opensuse had to repack the tar to remove unittests with non-free licenses, if we are not running or shipping the tests, can I avoid doing that repack?
<vorlon> teward: well there is an api call, that's scattered throughout the source code, that returns this font; so I don't know what the consequences are for making this internal api call fail
<RikMills> I should also note that the issues are fixed in upstream git, so this problem will go away when they do a new release
-queuebot:#ubuntu-release- Unapproved: accepted fonts-noto [source] (focal-proposed) [20200323-1build1~ubuntu20.04.1]
<RikMills> or maybe I should play safe and do a git snapshot?
-queuebot:#ubuntu-release- Unapproved: accepted util-linux [source] (focal-proposed) [2.34-0.1ubuntu9.1]
<vorlon> RikMills: if they're not embedded, it's at least not a combined work; but even a hard-coded requirement for a specific font that is loaded externally is a license issue under the GPL
<vorlon> RikMills: unit tests in source code under a different license are not a GPL problem
-queuebot:#ubuntu-release- Unapproved: accepted kazam [source] (focal-proposed) [1.4.5-3ubuntu0.1]
<RikMills> vorlon: understood. in that case I think I will upload as it is, and let the review decide. should there in the end be as issue, I can always the re-do the source
<RikMills> vorlon: thanks :)
<RikMills> ps. it is the example files for the unittests that were the issue. upstream grabbed some form somewhere on the internet without thinking about licences
<RikMills> *from somewhere
<RikMills> vorlon: damn. you are talking about combining incompatible free licenses are you not? penny just dropped. I think I am going to have to repack/snapshot after all
 * RikMills blames the lateness of the hour in the UK
<RikMills> it is a weird thing, but I often find the copyright stuff MORE mind-bending than the quantum physics exams I had to do at Uni!
<teward> RikMills: you mean RE: dragonfly-reverb?
<teward> yeah that one's incompatible free licenses
<teward> SIL Open Font License isn't compatible with GPL
<teward> :P
<vorlon> RikMills: if the test suite is not being shipped in a binary package, it still doesn't matter.  You're allowed to combine GPL and non-GPL code into a single binary /which you don't distribute/.
#ubuntu-release 2020-08-27
<Eickmeyer> vorlon, teward: notified upstream that dragonfly-reverb, when compiled, is basically done so illegally: https://github.com/michaelwillis/dragonfly-reverb/issues/66
<Eickmeyer> Read the backscroll. Thanks for putting this to bed (finally!). :)
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (groovy-proposed/main) [5.8.0-18.19] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (groovy-proposed/main) [5.8.0-18.19] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (groovy-proposed/main) [5.8.0-18.19] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (groovy-proposed) [5.8.0-18.19]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (groovy-proposed) [5.8.0-18.19]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (groovy-proposed) [5.8.0-18.19]
<xnox> vorlon:  interesting that ruby2.7 just built for you. when i try to rebuild it locally all the rubygem specification timing/date comparison fails. I wonder if it is becuase my chroots locally use GMT instead of UTC or some such.
<xnox> anyway glad that it built fine in launchpad.
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-450 [amd64] (focal-proposed) [450.66-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (focal-proposed/main) [5.4.0-45.49] (core, kernel)
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-450 [i386] (focal-proposed) [450.66-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (focal-proposed/main) [5.4.0-45.49] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (focal-proposed/main) [5.4.0-45.49] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (focal-proposed) [5.4.0-45.49]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (focal-proposed) [5.4.0-45.49]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (focal-proposed) [5.4.0-45.49]
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (focal-proposed/main) [5.4.0-45.49] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (focal-proposed) [5.4.0-45.49]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-5.4 [amd64] (bionic-proposed/main) [5.4.0-45.49~18.04.2] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-5.4 [s390x] (bionic-proposed/main) [5.4.0-45.49~18.04.2] (no packageset)
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-450 [amd64] (bionic-proposed) [450.66-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-115.116] (core, kernel)
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-450 [i386] (bionic-proposed) [450.66-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-115.116] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-115.116]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-115.116]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-5.4 [arm64] (bionic-proposed/main) [5.4.0-45.49~18.04.2] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-5.4 [amd64] (bionic-proposed) [5.4.0-45.49~18.04.2]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-5.4 [s390x] (bionic-proposed) [5.4.0-45.49~18.04.2]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-5.4 [arm64] (bionic-proposed) [5.4.0-45.49~18.04.2]
<RikMills> Laney: britney runs are crashing :/
<apw> RikMills, got a reference to 'crashing' in the log
<RikMills> apw: https://paste.ubuntu.com/p/9qXwTy9bs6/
<RikMills> similar in all runs from 06:40 this morning
<apw> RikMills, and yet different specifics, odd
 * RikMills nods
<apw> RikMills, and it actually failed the same way at 01:40:05 and then worked the one after
<RikMills> o_O
<apw> RikMills, and happened yesterday too like 4 from last
<apw> 21:16:23.log
<apw> so randomly happening recently i think
<RikMills> not surprised that went under the radar if only occasional until, this morning then
-queuebot:#ubuntu-release- New binary: jollyday [amd64] (groovy-proposed/universe) [0.5.10-1] (no packageset)
<apw> RikMills, yeah it seems to mention one then move on, which is odd
<apw> in the next run i mean
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-115.116~16.04.1] (kernel)
<LocutusOfBorg> hello apw can you please NBS-proposed cleanup this one?
<LocutusOfBorg> old binaries left on riscv64: mariadb-plugin-rocksdb (from 1:10.3.22-1ubuntu2)
<LocutusOfBorg> upstream seems like to have decided to not support rosksdb on riscv64
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-115.116~16.04.1] (kernel)
<LocutusOfBorg> the build time goes from 4 hours to 6 on riscv64
<LocutusOfBorg> I asked to maybe reintroduce it on https://bugs.launchpad.net/ubuntu/+source/mariadb-10.3/+bug/1876814
<ubot5> Ubuntu bug 1876814 in mariadb-10.3 (Ubuntu) "Package mariadb-10.3 forked in Debian, patches not upstreamed" [Undecided,New]
-queuebot:#ubuntu-release- Unapproved: shim-signed (bionic-proposed/main) [1.37~18.04.7 => 1.37~18.04.8] (core)
<RikMills> apw: the packages britney is mentioning in the crash seem to be ones that are 'grouped' from a landing ppa?
<RikMills> apw: ha! latest run seems ok. :rolleyes
<apw> RikMills, if it hadn't worked i was going to consider removal; if it is working ok sometimes, then we can wait on laney
<RikMills> yeah, I saw the 4/5 fails in a row and jumped to a conclusion. fingers crossed
<apw> RikMills, oh it was good you brought it up, as we could have missed it
<RikMills> indeed
<apw> RikMills, i bet there is a bug in the group-by-ppa module from the rebase, and it only triggers on some of the packages in the group; and processing order is run dependant
<RikMills> sounds likely
<RikMills> apw: any change you could remove the ppc64el, s390x & riscv64 release binaries of libkf5mailimporter? the version in proposed gained a build dep the depends on qtwebengine, so is no longer buildable on those architectures
<RikMills> *any chance
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (focal-proposed) [1:20.04.25]
<sil2100> RAOF: hmmm
<sil2100> RAOF: so I see you have removed memtest86+ from focal-proposed as per SRU verification failed - I don't think that was necessary
<LocutusOfBorg> ubuntu-archive please old binaries left on riscv64: mariadb-plugin-rocksdb (from 1:10.3.22-1ubuntu2)
<sil2100> RAOF: the only bug that was verification-failed from what I see was LP: #1874125, which was a bug for a no-change-rebuild
<ubot5> Launchpad bug 1874125 in memtest86+ (Ubuntu Focal) "Untranslatable strings in grub menu" [Undecided,Confirmed] https://launchpad.net/bugs/1874125
<sil2100> RAOF: the other bug was important for our enablement of the 20.04.1 upgrades
<sil2100> RAOF: and it was *not* verification-failed, so we need to re-include it basically with the same changes
<sil2100> RAOF: actually, that version was verification-done...
<sil2100> RAOF: eh, now I need to think if I can to undelete it somehow
<sil2100> apw: do you know if we can somehow re-publish deleted package versions in the archive?
<sil2100> cjwatson: hey! Maybe you know ^ ? Can we re-publish deleted package versions somehow?
-queuebot:#ubuntu-release- Unapproved: accepted grubzfs-testsuite [source] (focal-proposed) [0.4.10.1]
<sil2100> I wonder what would happen if I copy-package this with binaries to a PPA and then bin-sync back to the archive?
<cjwatson> sil2100: in a standup, give me 20 minutes
<sil2100> cjwatson: thanks!
<sil2100> Ah, I forgot about --force-same-destination
<sil2100> Maybe that would work
<ahasenack> hi ubuntu-archive, did someone move bin:nginx-full (from src:nginx) from universe to main in groovy?
<ahasenack> it was in universe all is life, up until groovy
<ahasenack> and that is generating component mismatches
<ahasenack> https://launchpad.net/ubuntu/groovy/amd64/nginx-full/1.18.0-3ubuntu1 is the last one that was in universe
<ahasenack> https://launchpad.net/ubuntu/groovy/amd64/nginx-full/1.18.0-3ubuntu2 was in main already
<cjwatson> sil2100: right, --force-same-destination should work as long as you also use --include-binaries so that it doesn't try to rebuild
<sil2100> Thanks, trying that!
<sil2100> It's always a bit scary as the binaries aren't listed when running the command
<sil2100> But I remember that's normal
<cjwatson> indeed, the list of binaries is guesswork
-queuebot:#ubuntu-release- Unapproved: memtest86+ (focal-proposed/main) [5.01-3.1ubuntu1 => 5.01-3.1ubuntu2.1] (desktop-core, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted memtest86+ [sync] (focal-proposed) [5.01-3.1ubuntu2.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-115.116~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-115.116~16.04.1]
<rbasak> sil2100: could I have an additional SRU hat review on https://bugs.launchpad.net/ubuntu/+source/sup-mail/+bug/1888749 please? Also this will need an AA hat review/accept as it's in NEW.
<ubot5> Ubuntu bug 1888749 in sup-mail (Ubuntu Focal) "sup-mail broken and unusable after Bionic to Focal upgrade" [Medium,In progress]
-queuebot:#ubuntu-release- Unapproved: neutron (focal-proposed/main) [2:16.0.0-0ubuntu0.20.04.2 => 2:16.1.0-0ubuntu1] (openstack, ubuntu-server)
<ddstreet> Laney i updated autopkgtest-cloud worker-lxd.conf to put haveged in the long_tests (and was merged), but then i re-ran haveged for armhf and it still timed out after ~3h, does the autopkgtest-cloud lxd worker need to be restarted to pick up the change? or does a different worker conf need editing or something?
-queuebot:#ubuntu-release- Unapproved: sosreport (focal-proposed/main) [3.9.1-1ubuntu0.20.04.2 => 4.0-1~ubuntu0.20.04.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: glance (focal-proposed/main) [2:20.0.0-0ubuntu0.20.04.1 => 2:20.0.1-0ubuntu1] (openstack, ubuntu-server)
<ahasenack> hi ubuntu-archive, did someone move bin:nginx-full (from src:nginx) from universe to main in groovy?
<ahasenack> https://launchpad.net/ubuntu/groovy/amd64/nginx-full/1.18.0-3ubuntu1 is the last one that was in universe
<ahasenack> https://launchpad.net/ubuntu/groovy/amd64/nginx-full/1.18.0-3ubuntu2 was in main already
<seb128> ahasenack, it was not me and I don't know if we have logs for binary promotions
<ahasenack> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#nginx
<ahasenack> it should be reverted
-queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (focal-proposed) [4.0-1~ubuntu0.20.04.1]
<ahasenack> unless we discover the reason why it was moved, and perhaps sometihng else needs to be done then
<cjwatson> seb128: We do
<cjwatson> https://launchpad.net/ubuntu/groovy/amd64/nginx-full
<cjwatson> Says it was vorlon
<seb128> cjwatson, ah, thanks, I don't know how to end up there from the UI but good to know about the URL at least
<xnox> seb128:  from build, click on binary header to get to binary, then click to it, and then history. or yeah, just construct the url
<ahasenack> vorlon: hi, when you get online, could you please move nginx-full back to universe? See chat above. Unless I'm missing something
-queuebot:#ubuntu-release- Unapproved: accepted rpcbind [source] (xenial-proposed) [0.2.3-0.2ubuntu0.16.04.1]
<vorlon> ahasenack: according to https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.html something wants it in main, that's why it's promoted; work out what that is and fix it so we can demote it cleanly?
<ahasenack> vorlon: sorry, I don't see "nginx" (subscring search) in that page, what am I missing?
<vorlon> ahasenack: that's the point - it's not in the page, so component-mismatches does not believe it's a candidate for demotion
<ahasenack> but it's requiring packages in universe
<vorlon> but it's also strange that it has binary deps that are in universe and *those* are not listed for promotion
<ahasenack> yeah
<ahasenack> nginx-full/amd64 in main cannot depend on libnginx-mod-http-geoip2 in universe
<ahasenack> and so on
<cpaelzer> hi, anyone of the release team around to oconsider https://code.launchpad.net/~paelzer/britney/hints-ubuntu-groovy-vagrant-libvirt/+merge/389888 ?
<vorlon> ahasenack: fwiw nginx-full shows up in germinate-output via supported-misc-servers.depends
<ahasenack> hmm
<ahasenack> let's see when that was added/changed
<ahasenack> cpaelzer: does that ring any bell?
<cpaelzer> I haven't committed anything yet :-)
<cpaelzer> but I can take a look as part of the seed cleanup I do
<ahasenack> I'm checking too
<cpaelzer> ahasenack: ok, if you don't conclude on it let me know what I should continue tomorrow ok?
<vorlon> I'm going to try demoting it and see what changes
<ahasenack> grep nginx-full -r shows nothing
<ahasenack> $ grep nginx -r .
<ahasenack> ./platform/supported-misc-servers: * nginx
<ahasenack> ./platform/supported-maas: * nginx-core
<ahasenack> maybe nginx
<cpaelzer> ahasenack: seed -> nginx -> nginx-full
<cpaelzer> as seen in https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.groovy/all+extra
<ahasenack> nginx has this weird depends sequence: nginx-core (>= ${source:Version}) | nginx-full (>= ${source:Version})  | ..
<ahasenack> it's a very long a | b | c | d | ... depends line, ugh
<cpaelzer> if it should just be nginx-core we can exchange that in the seed
<cpaelzer> do you happen to know what the (current) preferred root package to keep in is?
<ahasenack> no
<ahasenack> the amount of meta packages this one has is incredible
<tseliot> sil2100, hey, I don't know if the question you asked me still needs an answer
<cpaelzer> ahasenack: I think you need to look into and decide which of -core/-full/-light we actually want to support and then we set that in the seed
<cpaelzer> or it is an actual issue with a new dependency from -full
<ahasenack> I need to understand if this changed from the previous upload to now in the pkg, or in the seeds
<ahasenack> working on it
<tseliot> vorlon, hi, can you approve nvidia 450 and 450-server in bionic-proposed and focal-proposed (in NEW), please?
<ahasenack> because 1.18.0-3ubuntu2 was already in main, and that was unexpected
<ahasenack> as 1.18.0-3ubuntu1 was in universe, and we didn't ask for any universe->main movement as we didn't expect it
<cpaelzer> the dependency of nginx -> nginx-full (as alternative) was there quite some time
<cpaelzer> despite the dependnecy being there in focal https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.focal/all+extra does not list it
<cpaelzer> maybe it would be in component mismatch focal as "need to be promoted"
<cpaelzer> is that report somewhere?
<ahasenack> don't know
<ahasenack> checking the diff between the nginx uploads in d/control, it's not clear to me why anything in that would have triggered this
<cpaelzer> I have not seen a difference on that end either
<cpaelzer> but on the three B/F/G germinate output it is way different
<cpaelzer> e.g. bionic germinate lists nginx-full but it is not in main there - /me is puzzled
<ahasenack> didn't rbasak say a while ago that there was something odd with germinate recently in groovy?
<cpaelzer> I asked, in focal&groovy he was puzzled by some things missing
<rbasak> eg. https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.eoan/rdepends/memcached/ exists but https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.focal/rdepends/memcached/ does not
<rbasak> seeded-in-ubuntu says that memcached is no longer seeded
<rbasak> src:memcached is still in main in Focal and in Groovy
<rbasak> I didn't understand why this is the case
<rbasak> memcached is still in supported-misc-servers in platform: https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/tree/supported-misc-servers#n36
<rbasak> nginx is also in there via the same seed.
<rbasak> So it sounds like it might well be the same issue to me.
<rbasak> Though, oddly
<rbasak> https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.groovy/rdepends/nginx/nginx does exist and lists Supported-Misc-Servers
<sil2100> tseliot: hey! Yeah, I guess it's still something I might like to investigate
<tseliot> sil2100, ginggs replied, but perhaps you were offline: "<ginggs> I think removing pyhst2's binaries on amd64 will allow nvidia-cuda-toolkit to migrate, and pyhst2 can migrate when n-g-d-450 and l-r-m are sorted"
<tseliot> and 450 and the lrm should be sorted in groovy now
<ginggs> tseliot:  a p w performed a miracle and everything migrated without having to remove pyhst2 on amd64.   as noted, pyhst2 was removed on ppc64el previously
<tseliot> great :)
<ginggs> tseliot: btw, I think your drivers are missing a .shlibs file
<ginggs> you used to have https://github.com/tseliot/nvidia-graphics-drivers/blob/304-xenial/debian/nvidia-304.shlibs
-queuebot:#ubuntu-release- Unapproved: pluma (focal-proposed/universe) [1.24.0-1 => 1.24.1-0ubuntu1] (ubuntu-mate, ubuntukylin)
<tseliot> ginggs, that was ages ago, and a leftover from the original debian packaging, I think
<ginggs> tseliot: i think it's still needed
-queuebot:#ubuntu-release- Unapproved: mate-system-monitor (focal-proposed/universe) [1.24.0-1 => 1.24.1-0ubuntu1] (ubuntu-mate, ubuntukylin)
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-450-server [source] (focal-proposed) [450.51.06-0ubuntu0.20.04.1]
<tseliot> ginggs, does anything other than nvidia rely on those libraries?
-queuebot:#ubuntu-release- Unapproved: mate-screensaver (focal-proposed/universe) [1.24.0-1 => 1.24.1-0ubuntu1] (ubuntu-mate)
<ginggs> tseliot: well the one issue I recall was if one built a GL package locally, with nvidia drivers installed, it would pick up a dependency on that version of the nvidia driver, instead of libgl1
<ginggs> tseliot: the issue i saw most recently was pyhst2 picked up a dependency on nvidia-graphics-drivers-450 instead of any nvidia driver that provides libcuda
<vorlon> tseliot: nvidia-graphics-drivers-450-server> done
<tseliot> ginggs, patches are welcome. I have a lot on my plate
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-450-server [amd64] (focal-proposed/none) [450.51.06-0ubuntu0.20.04.1] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-450-server [i386] (focal-proposed/none) [450.51.06-0ubuntu0.20.04.1] (i386-whitelist)
<tseliot> vorlon, thanks, now only 450 is missing
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-450-server [source] (bionic-proposed) [450.51.06-0ubuntu0.18.04.1]
<ginggs> tseliot: thanks, i'll have a look
<tseliot> great
<vorlon> tseliot: missing> I don't see it waiting in the new queue for me in those series?
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-450-server [i386] (focal-proposed) [450.51.06-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-450-server [amd64] (focal-proposed) [450.51.06-0ubuntu0.20.04.1]
<tseliot> vorlon, it seems that somebody accepted them: https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-450/450.66-0ubuntu0.18.04.1 https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-450/450.66-0ubuntu0.20.04.1
<tseliot> vorlon, they should be move to restricted though
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-450-server [i386] (bionic-proposed/multiverse) [450.51.06-0ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rpi-eeprom (focal-proposed/multiverse) [7.8-0ubuntu0.20.04.1 => 7.8-0ubuntu0.20.04.2] (no packageset)
<vorlon> tseliot: component fixed
<RikMills> vorlon: could you remove the release ppc64el, s390x, riscv64 release binaries for libkf5mailimporter? proposed version can no longer build on those, as now has a build dep that requires qtwebengine
<tseliot> vorlon, thanks!
-queuebot:#ubuntu-release- New source: raspberrypi-userland (focal-proposed/primary) [0~20200520+git2fe4ca3-0ubuntu2~20.04.1]
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-450-server [amd64] (bionic-proposed/multiverse) [450.51.06-0ubuntu0.18.04.1] (no packageset)
<vorlon> RikMills: done
<RikMills> ty!
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-450-server [amd64] (bionic-proposed) [450.51.06-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-450-server [i386] (bionic-proposed) [450.51.06-0ubuntu0.18.04.1]
<ahasenack> vorlon: hi, did you try the demotion of nginx-full?
-queuebot:#ubuntu-release- Unapproved: libreoffice (focal-proposed/main) [1:6.4.5-0ubuntu0.20.04.1 => 1:6.4.6-0ubuntu0.20.04.1] (ubuntu-desktop)
<ahasenack> I see you did
<ahasenack> vorlon: could there be something wrong with component-mismatches? https://pastebin.ubuntu.com/p/vTKF3NDGXv/
<ahasenack> granted that Depends line boggles my mind
<ahasenack> vorlon: it's in main again, is that happening automatically?
<ahasenack> https://launchpad.net/ubuntu/groovy/amd64/nginx-full
<vorlon> ahasenack: I only demoted it for -proposed so far; I guess I should do so for release pocket also, done
<ahasenack> ah, thanks
<ahasenack> let's see if it behaves :)
<Eickmeyer> sil2100: Can I get a quick ACK on SRU bug 1892949?
<ubot5> bug 1892949 in ubuntustudio-default-settings (Ubuntu Focal) "[SRU] grub can no longer detect kernels after ubuntustudio-lowlatency-settings is uninstalled" [High,In progress] https://launchpad.net/bugs/1892949
<enyc> Hrrm, not sure which channel to use  ....   packages.ubuntu.com  seems broken if i'm not mistaken
<enyc> .... come back to life eventualyl!
<sil2100> Eickmeyer: looking
<sarnold> enyc: broken in what way? seems to be working for me
<sarnold> eg this gave an expected result https://packages.ubuntu.com/search?searchon=contents&keywords=do-release-upgrade&mode=exactfilename&suite=eoan&arch=any
<enyc> sarnold: it was giving cosnsntant  internal error contant rhonda@ubuntu.com   whenevre clicking on any package details....
<enyc> sarnold: e.g.   https://packages.ubuntu.com/virtualbox-qt       would work ... but if you then clicked on focal-updates (or any other distro)  to see actual details,   was *consistently*  failing
<enyc> working again now!
<sarnold> enyc: aha, hooray it's working anyway :)
<vorlon> ahasenack: hur hur; nginx-core is arch: any, nginx-full in arch: all, so since nginx is not built on i386, the arch: all nginx that's in main tries to pull in arch: all nginx-full for installability on i38
<vorlon> 6
<vorlon> ahasenack: I think this is best solved by making nginx-full arch: any
<ahasenack> but it's just a metapackage
<vorlon> and nginx, as well
<vorlon> yes, but it's an "arch-dependent" metapackage by virtue of i386 being messy
<ahasenack> so it's because we don't have it on i386
<ahasenack> more delta with debian
<ahasenack> can't this be sorted with something in multiarch?
 * ahasenack thinks
<vorlon> it can't because germinate doesn't support multiarch
<vorlon> and component-mismatches relies on germinate output
<ahasenack> ah, that
<ahasenack> so it is because of seeds
<ahasenack> I'll file a bug for this, as in 2 weeks for now we will be "why is this metapackage arch any?"
<ahasenack> vorlon: so this: https://paste.ubuntu.com/p/bbJNQ2RFRt/
<Eickmeyer> vorlon, teward: I've been hit with a huge surprise. The dragonfly-reverb developers are switching Noto Sans to Bitstream Vera as of right now. I took a cursory glance at the license, and it seems to be GPL-compatible. Thoughts?
-queuebot:#ubuntu-release- Unapproved: accepted ubuntustudio-default-settings [source] (focal-proposed) [20.04.2.2]
<teward> vorlon: ahasenack: Debian upstream's your next hop :p
<teward> get them to make the change for nginx metapackage any
<teward> then we'll trickle in the change
<ahasenack> teward: they will never take this, i386 isn't a problem they have
<teward> because I don't know if it causes problems in Debian
<teward> ahasenack: the 'maintainership' has changed, they might
<teward> also
<teward> >teward: they will never take this, i386 isn't a problem they have
<teward> you haven't asked
<teward> them
<teward> sooooooooooooo
<teward> **try**?
<ahasenack> I tried for othe rpackages
<ahasenack> but sure, it varies
<teward> we're trying to *reduce* the deltas not introducing *new* deltas
<ahasenack> since maintainers are different
<teward> ahasenack: TO BE FAIR
<teward> a lot of our delta was absorbed upstream
<teward> SO
<teward> s/upstream/in Debian/
<teward> if you haven't tried
<teward> you're going to get the standard "Ask Debian" reply that is typical of upstreaming things :p
<sarnold> o/~ to be faaaaair o/~
<teward> *yeets sarnold into /dev/null* :P
<teward> for reasons
<teward> ahasenack: if the argument can be made in a way that makes sense i'm pretty sure they won't object
<teward> ahasenack: i can reach out to them if you REALLY want me to
<teward> but i'm currently on a conference call for security issues @ work
<ahasenack> don't even know yet if this works
<Eickmeyer> sil2100: Hey! Where did we land?
<Eickmeyer> nm, just got the email. :D
<ahasenack> teward: uploaded, let's see if the component mismatch is gone by tomorrow (https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.html)
<ahasenack> then we can talk about debian :)
<teward> ahasenack: um
<teward> you broke it
<teward> nginx-full has third party components not permitted to be in main
<teward> nginx-core's the only Main-permitted flavor
<teward> sarnold can attest to that 'cause sarnold handled the initial MIR in 14.04 cycle
<teward> (nginx-full also is NOT a metapackage, because not all modules are 'dynamic' and are statically compiled in)
<teward> so if you are treating nginx-full as a metapackage, you are doing it wrong.
<teward> (`nginx-core | nginx-full | nginx-light | nginx-extras` is the dependencies for a reason for the `nginx` metapackage in that order)
<ahasenack> teward: hold
<ahasenack> I do NOT want nginx-full in main
<teward> then i wonder why it's calling a misma... ohhhhhhhhhhhhhhhhhhhh sorry
<teward> i derped (E:DeadBrain)
<ahasenack> something was pulling it into main, and we didn't know why
<ahasenack> see vorlon's diagnostic/troubleshooting above
<ahasenack> see the dance between main and universe here: https://launchpad.net/ubuntu/groovy/amd64/nginx-full
<teward> o.O
<teward> yeah as i said, i derped and misread
<ahasenack> cool :)
-queuebot:#ubuntu-release- Unapproved: cloud-init (focal-proposed/main) [20.2-45-g5f7825e2-0ubuntu1~20.04.1 => 20.3-2-g371b392c-0ubuntu1~20.04.1] (core, edubuntu, ubuntu-cloud)
<LocutusOfBorg> vorlon, pleeeeeeease old binaries left on riscv64: mariadb-plugin-rocksdb (from 1:10.3.22-1ubuntu2)
<vorlon> LocutusOfBorg: oops, had tried to do this once already but fat-fingered the command and hadn't looked at error output. done now
<LocutusOfBorg> lovely thanks
<vorlon> Eickmeyer: yes, bitstream vera license is GPL-compatible, so that would be fine
<Eickmeyer> vorlon: Ok, I'll respond accordingly.
<Eickmeyer> vorlon: Is Debian Import Freeze in effect yet?
<Eickmeyer> Really, anybody can answer this question ^
<vorlon> Eickmeyer: no, but will take effect before end of the day
<Eickmeyer> vorlon: Ok, lsp-plugins has an upgradabilty issue that has been solved by the latest upload of lsp-plugins to Sid.
<vorlon> well, the Debian archive only gets refresh 4x daily, so if it hasn't already synced, you should assume the need to follow up with a manual sync
<Eickmeyer> Ok, that makes sense. Thanks.
 * enyc meows!
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [20.2-45-g5f7825e2-0ubuntu1~16.04.1 => 20.3-2-g371b392c-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (bionic-proposed/main) [20.2-45-g5f7825e2-0ubuntu1~18.04.1 => 20.3-2-g371b392c-0ubuntu1~18.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<blackboxsw_> Hi vorlon or any other SRU vanguard around, if there is time today. We just queued uploads into -proposed for xenial bionic and focal for cloud-init 20.3 as part of https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1893064 if someone would be able to let this uploads in to start "-proposed" aging and SRU verification we'll  be able to start our verification sooner and potentially release next week.
<ubot5> Ubuntu bug 1893064 in cloud-init (Ubuntu Focal) "sru cloud-init (20.2-45 to 20.3-0) Xenial, Bionic, and Focal" [Undecided,New]
-queuebot:#ubuntu-release- New binary: mutter [s390x] (groovy-proposed/main) [3.37.91-1ubuntu1] (desktop-core, desktop-extra)
-queuebot:#ubuntu-release- New binary: mutter [amd64] (groovy-proposed/main) [3.37.91-1ubuntu1] (desktop-core, desktop-extra)
-queuebot:#ubuntu-release- New binary: mutter [ppc64el] (groovy-proposed/main) [3.37.91-1ubuntu1] (desktop-core, desktop-extra)
-queuebot:#ubuntu-release- New binary: mutter [armhf] (groovy-proposed/main) [3.37.91-1ubuntu1] (desktop-core, desktop-extra)
#ubuntu-release 2020-08-28
-queuebot:#ubuntu-release- New binary: mutter [riscv64] (groovy-proposed/main) [3.37.91-1ubuntu1] (desktop-core, desktop-extra)
<RAOF> blackboxsw_: Presumably you didn't mean to have `* <TODO: Create list with LP: # included>` in the SRU bug?
<RAOF> (And all the rest of the un-filled-in cloud-init SRU template?)
<blackboxsw_> RAOF: hiya. the rest of that template should be filled in shortly as it was a placeholder for the process bug.
<blackboxsw_> all of those TODOs are ones that we will in generally during validation and verification, but I'll fill in that top section now.
<blackboxsw_> sorry RAOF updated that top-level list of ubuntu-related items in this SRU
<blackboxsw_> I suppose we should have had that up there to aid the initial -proposed acceptance of the uploads. I'll tweak our SRU process to make sure we have that filled in before pinging next SRU
<blackboxsw_> I put packaging related changes up at the top to inform about deb-specific alterations beyond just syncing tip functionality from cloud-init master
-queuebot:#ubuntu-release- New binary: mutter [arm64] (groovy-proposed/main) [3.37.91-1ubuntu1] (desktop-core, desktop-extra)
<blackboxsw_> The rest if theTODOs we remove as we perform and attach verification logs for each section to the bug
<RAOF> Cool, thanks.
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (focal-proposed) [20.3-2-g371b392c-0ubuntu1~20.04.1]
<RAOF> blackboxsw_: It looks like the changes to bionic/ec2-dont-apply-full-imds-network-config.patch and renderer-do-not-prefer-netplan.patch only change nonfunctional lines; is there a good reason for those changes to exist?
<blackboxsw_> RAOF, good question. /me checks.
<blackboxsw_> RAOF the ec2 patch changes the default
<blackboxsw_> +                    self.ds_cfg, 'apply_full_imds_network_config', False))
<blackboxsw_> from True to False
<blackboxsw_> so it makes sure we only setup dhcp on eth0 on ec2 in bionic
<blackboxsw_> instead of full network config from imds
<blackboxsw_> so image creators have to explicitly from ec2 datasource config in the image to apply_full_imds_network_config: true to get full net config.
<blackboxsw_> checking the renderer patch
<RAOF> blackboxsw_: Ah, sorry. I mean, why, in the SRU debdiff, are the changes to those patches only in nonfunctional lines.
<blackboxsw_> ohh checking the debdiff
<RAOF> This also applies to the xenial patch refreshes, other than the ubuntu-advantage patch.
<blackboxsw_> RAOF: my brain is broken, how do I get to the debdiff ... n/m found it http://launchpadlibrarian.net/495289918/cloud-init_20.2-45-g5f7825e2-0ubuntu1~18.04.1_20.3-2-g371b392c-0ubuntu1~18.04.1.diff.gz
<blackboxsw_> hrm when we pulled a new upstream snapshot with our tooling quilt patches couldn't apply so we quilt push -f; quilt refresh'd (with a minor ubuntu-advantage tweak for backward compatible behavior.
<blackboxsw_> I'll probably have to look at this with fresh eyes tomorrow to be sure
<RAOF> Ah. Yeah, you probably only needed to refresh a single patch.
<blackboxsw_> yeah, probably so, just wondering why the diff paths would have changed across quilt refresh .... a/b prefix vs  cloud-init.orig/ cloud-init
<blackboxsw_> makes sense RAOF we can wrap that up tomorrow
<blackboxsw_> do you prefer a reject and reupload of 20.3-2-g371b392c-0ubuntu1~18.04.1.diff.gz   or do you think that is worth  bumping the upload ver to 20.3-2-g371b392c-0ubuntu2
<RAOF> I can just reject, and you can use the same version.
<RAOF> It's nitpicky, but we've had weirder bugs in SRUs :)
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (bionic-proposed) [20.3-2-g371b392c-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (xenial-proposed) [20.3-2-g371b392c-0ubuntu1~16.04.1]
<blackboxsw_> it's good, we should get to the bottom of why, or at least avoid non-functional quilt patch changes
<blackboxsw_> thanks for this, do you prefer I ping you if we can get this fairly early US-time tomorrow, or just roll over to next SRU vanguard friday
<RAOF> blackboxsw_: If it's before about 0530 UTC pinging me is fine, otherwise the next SRU vanguard.
<RAOF> Ahem. 0730 UTC.
 * RAOF fails at timezones.
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [20.2-45-g5f7825e2-0ubuntu1~16.04.1 => 20.3-2-g371b392c-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<blackboxsw_> RAOF: meh n/m about tomorrow. I couldn't help it. I fixed it manually on the current branches and re-uploaded bionic and xenial redacting those diffs. We'll have to sort tomorrow how our tooling, release process ended up adding empty quilt patch refreshes.
<RAOF> Sorry to keep you up!
<blackboxsw_> my own fault, if I weren't at the screen trying to figure out how to care for an aquarium, I wouldn't have made myself avail :)
-queuebot:#ubuntu-release- Unapproved: cloud-init (bionic-proposed/main) [20.2-45-g5f7825e2-0ubuntu1~18.04.1 => 20.3-2-g371b392c-0ubuntu1~18.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<blackboxsw_> ok have a good day RAOF thanks for the reviews
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (bionic-proposed) [20.3-2-g371b392c-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [20.3-2-g371b392c-0ubuntu1~16.04.1]
<cpaelzer> I didn't get hold of a release team member yesterday to consider https://code.launchpad.net/~paelzer/britney/hints-ubuntu-groovy-vagrant-libvirt/+merge/389888 - is now someone around?
<rbalint> sil2100, as we discussed i'd like to upload an almost bugfix only glibc which i planned for yesterday but testing took longer. the builds are here: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4234/+packages
<rbalint> sil2100, the only notable non-bugfix is LP: #188798 to unblock focal sru
<ubot5> Launchpad bug 188798 in metacity (Ubuntu) "metacity crashed with SIGSEGV in g_timeout_dispatch()" [Medium,Expired] https://launchpad.net/bugs/188798
<rbalint> i mean LP: #1887989 :-)
<ubot5> Launchpad bug 1887989 in glibc (Ubuntu Groovy) "[20.04 Feature] Enable glibc for POWER10" [Undecided,In progress] https://launchpad.net/bugs/1887989
<rbalint> sil2100, i hope it is still ok to upload that
<sil2100> rbalint: yeah, proceed - although I see the package FTBFS on riscv in bileto?
<rbalint> sil2100, riscv64, lovely, it only took 8.5 hours :-\. luckily it is flaky and will pass after a few tries or we can land LP: #1891686
<ubot5> Launchpad bug 1891686 in dpkg (Ubuntu) "Please default to nocheck on riscv64" [Undecided,New] https://launchpad.net/bugs/1891686
<rbalint> sil2100, thank, going ahead, it will be fine (famous last word)
<xnox> doko: vorlon: so python3.9 on riscv64, imho is going into infinite loop. b5 built in like 16h
<xnox> but current build is going for 3days now
<xnox> 3 days, 5:33:59 load avg: 0.00 running: test_compileall (77 hour 10 min)
<xnox> and this doesn't looks like it's going to complete ever.
<xnox> 0:39:05 load avg: 1.06 [ 74/407] test_compileall passed (2 min 48 sec)
<xnox> is what it should be (from b5 logs)
<rbasak> sil2100: could I have an additional SRU hat review on https://bugs.launchpad.net/ubuntu/+source/sup-mail/+bug/1888749 please? Also this will need an AA hat review/accept as it's in NEW.
<ubot5> Ubuntu bug 1888749 in sup-mail (Ubuntu Focal) "sup-mail broken and unusable after Bionic to Focal upgrade" [Medium,In progress]
<xnox> restarted python3.9 on riscv64, if it gets stuck on test_compileall again, will skip it somehow, and try again.
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-450-server (focal-proposed/restricted) [450.51.06-0ubuntu0.20.04.1 => 450.51.06-0ubuntu0.20.04.2] (i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-450-server (bionic-proposed/restricted) [450.51.06-0ubuntu0.18.04.1 => 450.51.06-0ubuntu0.18.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-450-server [source] (focal-proposed) [450.51.06-0ubuntu0.20.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-450-server [source] (bionic-proposed) [450.51.06-0ubuntu0.18.04.2]
<sil2100> rbasak: will try to comment on the bug later today
<rbasak> Thanks!
-queuebot:#ubuntu-release- Unapproved: rejected zfcpdump-kernel [source] (focal-proposed) [5.4-0ubuntu1]
<vorlon> xnox: am I missing something where https://people.canonical.com/~ubuntu-archive/transitions/html/libffi8.html is needed vs https://people.canonical.com/~ubuntu-archive/transitions/html/auto-libffi.html ?
<xnox> vorlon:  i updated libffi in bzr, to catch things that reference 8.1.0 & 7 abi as abad. yet it's not updating online.
<xnox> vorlon:  i am working off auto-libffi only now.
<vorlon> ok
<xnox> vorlon:  i don't know why libffi8 is "stuck"
<xnox> RAOF:  you accepted source-new microcode-initrd, will you also review/accept the binary it produces? https://launchpad.net/ubuntu/groovy/+queue?queue_state=0&queue_text=microcode-initrd or is it bad in some way?
<xnox> vorlon:  you accepted source-new shim-canonical, and then in v2 upload i fixed spelling/typpos pointed out, will you also review/accept the binary NEW it produces? https://launchpad.net/ubuntu/groovy/+queue?queue_state=0&queue_text=shim-canonical or is it bad in some way?
<vorlon> cat: 'does not exist': No such file or directory
<vorlon> >_><
<vorlon> (https://launchpad.net/ubuntu/+source/haskell-conduit-extra/1.3.5-1build3/+build/19885708)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (groovy-proposed/main) [5.8.0-1004.4] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (groovy-proposed/main) [5.8.0-1002.2] (core, kernel)
-queuebot:#ubuntu-release- Packageset: 86 entries have been added or removed
-queuebot:#ubuntu-release- Unapproved: cinder (bionic-proposed/main) [2:12.0.9-0ubuntu1.2 => 2:12.0.10-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: horizon (bionic-proposed/main) [3:13.0.2-0ubuntu3 => 3:13.0.3-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron (bionic-proposed/main) [2:12.1.0-0ubuntu1 => 2:12.1.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron-fwaas (bionic-proposed/main) [1:12.0.1-0ubuntu1 => 1:12.0.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New source: dragonfly-reverb (groovy-proposed/primary) [3.2.1-0ubuntu1]
<teward> vorlon: dragonfly-reverb uploaded because upstream got off their lazy butts and switched fonts.  Guess they don't like "oops you're doing illegal stuff" as their tagline so :p
<teward> that should be good when you review it
<valorie> nice
#ubuntu-release 2020-08-29
-queuebot:#ubuntu-release- New binary: haskell-http-download [amd64] (groovy-proposed/universe) [0.2.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-http-download [s390x] (groovy-proposed/universe) [0.2.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-http-download [ppc64el] (groovy-proposed/universe) [0.2.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-http-download [arm64] (groovy-proposed/universe) [0.2.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-http-download [armhf] (groovy-proposed/universe) [0.2.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-http-download [riscv64] (groovy-proposed/universe) [0.2.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New sync: node-srs (groovy-proposed/primary) [0.4.9-1]
-queuebot:#ubuntu-release- New: accepted haskell-http-download [amd64] (groovy-proposed) [0.2.0.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-http-download [armhf] (groovy-proposed) [0.2.0.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-http-download [riscv64] (groovy-proposed) [0.2.0.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-http-download [arm64] (groovy-proposed) [0.2.0.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-http-download [ppc64el] (groovy-proposed) [0.2.0.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-http-download [s390x] (groovy-proposed) [0.2.0.0-2]
-queuebot:#ubuntu-release- New: accepted nvidia-cuda-toolkit [amd64] (groovy-proposed) [11.0.3-1]
-queuebot:#ubuntu-release- New: accepted nvidia-cuda-toolkit [ppc64el] (groovy-proposed) [11.0.3-1]
-queuebot:#ubuntu-release- New: accepted jollyday [amd64] (groovy-proposed) [0.5.10-1]
-queuebot:#ubuntu-release- New: accepted nvidia-cuda-toolkit [arm64] (groovy-proposed) [11.0.3-1]
-queuebot:#ubuntu-release- New binary: haskell-github [amd64] (groovy-proposed/universe) [0.23-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-github [ppc64el] (groovy-proposed/universe) [0.23-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-github [s390x] (groovy-proposed/universe) [0.23-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (groovy-proposed) [5.8.0-1004.4]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (groovy-proposed) [5.8.0-1002.2]
<xnox> uploaded llvm-toolchain-9 that should build on armhf
<xnox> ghc still building
<xnox> python3.9 still building on riscv64, and doesn't look like it is stuck.... yet.
-queuebot:#ubuntu-release- New binary: haskell-github [arm64] (groovy-proposed/universe) [0.23-1] (no packageset)
<LocutusOfBorg> xnox, the build was good https://launchpad.net/ubuntu/+source/llvm-toolchain-9/1:9.0.1-14build1
<LocutusOfBorg> you just uploaded before it finished
<xnox> LocutusOfBorg:  le sigh
<xnox> it failed like 3 retries before
<xnox> i hate it
<LocutusOfBorg> its more armhf sucking
<LocutusOfBorg> same fot ghc
<LocutusOfBorg> *for
-queuebot:#ubuntu-release- New binary: hgsubversion [amd64] (groovy-proposed/universe) [1.9.3+git20190419+6a6ce-5] (no packageset)
<LocutusOfBorg> wow this haskell migration makes no sense to me
-queuebot:#ubuntu-release- New: accepted haskell-github [amd64] (groovy-proposed) [0.23-1]
-queuebot:#ubuntu-release- New: accepted haskell-github [ppc64el] (groovy-proposed) [0.23-1]
-queuebot:#ubuntu-release- New: accepted hgsubversion [amd64] (groovy-proposed) [1.9.3+git20190419+6a6ce-5]
-queuebot:#ubuntu-release- New: accepted haskell-github [arm64] (groovy-proposed) [0.23-1]
-queuebot:#ubuntu-release- New: accepted haskell-github [s390x] (groovy-proposed) [0.23-1]
-queuebot:#ubuntu-release- New binary: haskell-pantry [amd64] (groovy-proposed/universe) [0.4.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-pantry [ppc64el] (groovy-proposed/universe) [0.4.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-pantry [s390x] (groovy-proposed/universe) [0.4.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-pantry [amd64] (groovy-proposed) [0.4.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-pantry [s390x] (groovy-proposed) [0.4.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-pantry [ppc64el] (groovy-proposed) [0.4.0.2-1]
-queuebot:#ubuntu-release- New binary: haskell-pantry [arm64] (groovy-proposed/universe) [0.4.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-pantry [arm64] (groovy-proposed) [0.4.0.2-1]
#ubuntu-release 2020-08-30
<RikMills> vorlon: lintian is once again uninstallable on i386 in proposed, due to no libtext-markdown-discount-perl on i386
<ginggs> ubuntu-archive would someone please remove python-biom-format and metaphlan2 from release? p-b-f is not compatible with pandas 1.0 - debian bug #950929
<ubot5> Debian bug 950929 in src:python-biom-format "python-biom-format: FTBFS with pandas 1.0: test failures" [Serious,Open] http://bugs.debian.org/950929
<ginggs> ubuntu-archive please also pyhst2 not compatible with cuda 11 - debian bug #968318
<ubot5> Debian bug 968318 in src:pyhst2 "pyhst2: FTBFS with CUDA 11: Unsupported gpu architecture 'compute_30'" [Important,Open] http://bugs.debian.org/968318
<ginggs> ubuntu-archive and eztrace-contrib - debian bug #968312
<ubot5> Debian bug 968312 in src:eztrace-contrib "eztrace-contrib: FTBFS with CUDA 11: cuda_runtime.cu(92): error: function "cudaMalloc(void **, size_t)" has already been defined" [Important,Open] http://bugs.debian.org/968312
<vorlon> rolling back haskell-gi-pango, build-depends on haskell-gi-harfbuzz which is stuck in Debian NEW
<vorlon> RikMills: libtext-markdown-discount-perl bootstrapping on i386
<vorlon> ... except old haskell-gi-pango requires an older haskell-haskell-gi-base, so nevermind. >_<
-queuebot:#ubuntu-release- Packageset: Removed libproc-processtable-perl from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added libtext-markdown-discount-perl to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added msgpack-c to i386-whitelist in groovy
<vorlon> so we'll need to get haskell-gi-harfbuzz out of Debian NEW somehow
-queuebot:#ubuntu-release- Packageset: Added libproc-processtable-perl to i386-whitelist in groovy
<vorlon> ginggs: python-biom-format, metaphlan2 done
<vorlon> ginggs: pyhst2 done
<RikMills> vorlon: ty!
<RikMills> sbuild-build-depends-libtext-markdown-discount-perl-dummy : Depends: libmarkdown2-dev but it is not installable
<RikMills> :(
<ginggs> vorlon: thanks very much
<ginggs> vorlon: please also remove eztrace-contrib, not compatible with CUDA 11 - debian bug #968312
<ubot5> Debian bug 968312 in src:eztrace-contrib "eztrace-contrib: FTBFS with CUDA 11: cuda_runtime.cu(92): error: function "cudaMalloc(void **, size_t)" has already been defined" [Important,Open] http://bugs.debian.org/968312
<LocutusOfBorg> vorlon, can you please NBS-cleanup missing build on amd64: libnotcurses++-dev, libnotcurses++1, libnotcurses-dev, libnotcurses1, notcurses-bin, notcurses-data, python3-notcurses (from 1.6.9+dfsg.1-2)
<LocutusOfBorg>  ?
<vorlon> RikMills: fixed
<vorlon> LocutusOfBorg: er, that's not NBS, the notcurses package in -proposed is FTBFS on all archs?
-queuebot:#ubuntu-release- Packageset: Added discount to i386-whitelist in groovy
<vorlon> ginggs: eztrace-contrib removed
<ginggs> vorlon: ta
<LocutusOfBorg> sorry vorlon fixed now, I syncd it
<LocutusOfBorg> vorlon, can you please make aseba migrate? some i386 dropping should be sufficient
<LocutusOfBorg> vorlon, also, please remove llvm-toolchain-9 1:9.0.1-14ubuntu1 and restore previous 1:9.0.1-14build1
<LocutusOfBorg> context is above, the armhf failure is not related to gcc-10 but to armhf infrastructure being unreliable
<LocutusOfBorg> moreover riscv64 is still building, while on 14build1 was fine
<vorlon> LocutusOfBorg: how did aseba/i386 get in there anyway?
<LocutusOfBorg> vorlon, you kicked it off because of something that has been fixed in the meanwhile
<vorlon> hmm ok
<vorlon> anyway, removed
<LocutusOfBorg> Deleted on 2020-01-14 by Steve Langasek
<LocutusOfBorg> Depends on removed enki-aseba; Debian bug #936483
<ubot5> Debian bug 936483 in src:enki-aseba "enki-aseba: Python2 removal in sid/bullseye" [Serious,Fixed] http://bugs.debian.org/936483
<LocutusOfBorg> so, probably nobody cared to do the i386 cleanup in focal...
<vorlon> I did i386 cleanups in focal
<LocutusOfBorg> not for proposed pocket only? :)
<vorlon> perhaps not for -proposed pocket, no
<vorlon> wrt llvm-toolchain-9, since the upload happened and the armhf build was superseded, deleting it now will require a whole new build on armhf; is that really what you want?
<LocutusOfBorg> yes, because the build in ubuntu1 has been restarted anyway due to some armhf outage...
<LocutusOfBorg> I restarted it one hour ago, we don't loose so much time
<LocutusOfBorg> unfortunately armhf is a try and retry approach... :(
<vorlon> ok
<LocutusOfBorg> I'm deleting armhf and riscv64 of ubuntu1
<vorlon> alright, 14build1 copied baeck
<LocutusOfBorg> llvm-10 and llvm-11 will have testsuite green by tomorrow, I need some sleep before kicking them
<LocutusOfBorg> thanks!
<vorlon> so if someone could get ahold of a copy of haskell-gi-harfbuzz from Debian NEW and get it uploaded, that would be a big help for the libffi transition
<LocutusOfBorg> I was going to ask on debian ftp
<mwhudson> ah hi
<vorlon> and the armhf outage took out the ghc build too, hnngh
<mwhudson> is haskell-gi-harfbuzz not in DHG_Packages?
<vorlon> I don't know what/where that is
<vorlon> the source package has no Vcs fields
<vorlon> er
<vorlon> I mean pango doesn't
<LocutusOfBorg> find . -name "*gi-harfb*"
<LocutusOfBorg> ./haskell-gi-harfbuzz
<vorlon> which was where I was hoping to find documentation of related packages
<LocutusOfBorg> its in DHG
<mwhudson> i guess we would have to make a new orig
<mwhudson> i'm not sure i got a very friendly time to be on +1 maint :)
<mwhudson> libffi, ghc, glibc, build farm outages, riscv builds that aren't going to complete before i stop work for the day
<vorlon> mwhudson: well https://people.canonical.com/~ubuntu-archive/transitions/html/auto-libffi.html looks much better than it did on Friday ;)
<LocutusOfBorg> vorlon please triple check, its my first time I do something so bad / nasty
<mwhudson> vorlon: yeah i guess that's not too bad
<LocutusOfBorg> orig tarball md5sum is the same as https://ftp-master.debian.org/new/haskell-gi-harfbuzz_0.0.3-1.html
-queuebot:#ubuntu-release- New source: haskell-gi-harfbuzz (groovy-proposed/primary) [0.0.3-1~build1]
<LocutusOfBorg> vorlon, ^^
<vorlon> LocutusOfBorg: cheers; I'm going afk now but I'll queue it for review later today
