[00:00] <knome> i can't agree more. i had no problem going to copenhagen paid by canonical, but still i think it was all a huge waste of money
[00:00] <knome> not the whole event, but many of the things
[00:00] <knome> expensive accommodation and per-diems to start off with a few things
[00:00] <ScottK> If they kept the interval at 6 months, I might agree it was just financial.
[00:01] <ScottK> 3 months makes no sense.
[00:01] <ochosi> i think the 3 months is mostly a "distraction" to keep ppl from complaining too much
[00:01] <knome> maybe their rationale is to increase quantity to make up some quality
[00:02] <ochosi> you can't just take something away without giving them something in return
[00:02] <knome> 3 months doesn't make sense for the xubuntu team. we're barely starting our engines in that time!
[00:02] <knome> (and no, i'm not telling canonical should adjust their plans to fit the xubuntu team)
[00:03] <TheDrums> And if they change to the rolling idea?  (IIRC, that was just a side comment too)
[00:04] <knome> TheDrums, i belive that would support the 3-month cycle, and i believe that's what ScottK also has in his mind
[00:04] <ochosi> TheDrums: you mean rick-rolling?
[00:04] <knome> i just double-checked the date to make sure it's not april fools
[00:04] <ScottK> TheDrums: It's my assumption that'll be the next announcement.
[00:05] <knome> that would've been a good one though...
[00:05] <TheDrums> That could make things fun for the flavors.
[00:06] <ScottK> I think they'll be unrecognizable when it's all done.
[00:07] <xnox> ScottK: online UDS is 2 days every 3 months vs 4/5 days every 6 months. Closer to a sprint than a half-marathon.
[00:07] <ScottK> My current best idea it to remove KDE from the archive and just distribute the different versions from different PPAs.
[00:07] <xnox> ScottK: I'm sure there will be people against that.
[00:07] <ScottK> xnox: So what am I doing at this first one?  Planning 13.10?  A little soon for that.
[00:07] <ScottK> xnox: Then they shouldn't cancel the releases we depend on.
[00:08] <knome> xnox, i'm sure there are people against everything.
[00:08] <ScottK> Canonical will do what it will do and we'll have to figure out the best way to adjust.
[00:09] <ScottK> I don't think they get the right to change the whole release process and tell us we can't change things as a result.
[00:10] <xnox> ScottK: i am not sure what will be planned. Now that ubuntu touch has landed out-of-archive one big chunk would be integrating that into raring images. But that's not as important for flavours.
[00:10] <knome> ScottK, i can empathize
[00:10] <slangasek> ScottK: why removing KDE from the archive?
[00:11] <slangasek> it's obviously for the Kubuntu team to decide what works best for them, but I don't understand the reasoning there wrt moving things to ppas
[00:11] <ScottK> I think that if we're trying to manage a no release between LTS situation, it' simpler to remove everything except kde4libs and then have one PPA per the four KDE releases that wiould then be happening per Ubuntu release.
[00:12] <slangasek> (and I'm not sure how that squares with the rules for official flavors / use of Ubuntu marks, regarding everything building from the archive)
[00:12] <ScottK> It's just my opinion, not the Kubuntu team.
[00:12] <slangasek> ah, I see
[00:12] <ScottK> You mean like Ubuntu touch?
[00:12] <slangasek> yeah, like that
[00:13] <ScottK> Ubuntu brands have been used lots of times for non-archive builds.  If someone wants to make us call it Ubuntu Kubuntu Remix, then fine.
[00:13] <slangasek> well, the standing "remix" language specifically only allows for archive builds, which was my point :)
[00:13] <xnox> ScottK: there is more qt coming into the archive (all of Ubuntu touch), and PPAs don't have armhf/powerpc. And somehow I don't think Blue Systems will be in favour of a Remix.
[00:13] <cjwatson> Removing all but kde4libs from the archive would make a fair number of other things unbuildable due to bindings and such; it's all fairly intertwingled.
[00:14] <ScottK> xnox: Blue Systems doesn't control Kubuntu.  They don't really have any say at all.
[00:14] <ScottK> cjwatson: I'm just talking outloud at the moment.
[00:14] <xnox> ScottK: ok.
[00:14] <ScottK> It happens one of their employees is on the Kubuntu Council, but only one, IIRC.
[00:15] <ScottK> cjwatson: I'm speculating in the face of an information deficit.
[00:15] <ScottK> It would be nice if the whole story came out at once.
[00:17] <knome> as always, it seems that the communication from canonical seems to be badly organized
[00:18] <tumbleweed> it would be nice if we knew what next week's UDS is for. I see a couple of haphazard blueprints, and no sprint on LP
[00:18] <cjwatson> ScottK: understood
[01:25]  * cjwatson quickly rebuilds kubuntu-active/daily-live, since it broke
[01:53] <cjwatson> Has queuebot lost its notion of stable release queues?
[02:18] <stgraber> cjwatson: that can happen, let me poke it
[02:19] <stgraber> cjwatson: hmm, it's getting some 401 from LP, let's try a restart
[02:22] <cjwatson> stg	Thanks
[02:23] <cjwatson> gah, lag
[02:23] <cjwatson> stgraber: Thanks
[08:27] <ogra_> cjwatson, thanks ! working fine now
[08:27] <ogra_> Riddell, http://cdimage.ubuntu.com/kubuntu-active/daily-preinstalled/current/ please test, if its fine i'll enable the cron job (and default-arches)
[09:26] <psivaa> cjwatson: infinity: today's server images have the kernel mismatch issue, please let me know if you are respinning them for me to watch the smoke tests. Just reported bug 1134123 to tag the failures
[09:26] <ubot2`> Launchpad bug 1134123 in Ubuntu CD Images "Raring server installations fail with kernel mismatch with 20130227 images" [Undecided,New] https://launchpad.net/bugs/1134123
[09:46] <cjwatson> psivaa: Yeah, I suppose I shouldn't have processed some kernels through NEW just before going to bed
[09:47] <cjwatson> And I guess somebody processed NBS or something
[09:48] <cjwatson> Hm, no
[09:48] <cjwatson> Well, I'll sort it out after I get back from the shop, to allow linux/armhf time to publish
[09:49]  * ogra_ wonders if anyone ever read the cdimage user mail on nusakan
[09:49] <ogra_> i get the "you have new mail" notice since a few days
[09:50] <cjwatson> Once a year or so :)
[09:50] <ogra_> heh
[09:51] <cjwatson> Ah, yeah, buildlive still witters at us in cronmail
[09:51] <cjwatson> Once I get buildlive converted to new code I'll probably move that to proper logging
[09:51] <psivaa> cjwatson: ack, thanks
[10:04] <Riddell> ogra_: ooh thanks, testing
[10:20] <psivaa> OEM config short-cut is not present in the desktop images today, reported bug 1134162 for that
[10:20] <ubot2`> Launchpad bug 1134162 in ubiquity (Ubuntu) "/home/oem/Desktop/oem-config-prepare-gtk.desktop is not present in the desktop images" [Undecided,New] https://launchpad.net/bugs/1134162
[10:20] <psivaa> cjwatson: xnox: ogra_ ^
[10:21] <xnox> yeah.... I actually don't know how the shortcuts appear on the desktop, I take it that ubuntu-cdimage project is better for such bug, as my guess is that shortcuts are added at cd building.
[10:22] <xnox> wait, this is oem. config. it should be there.
[10:22] <ogra_> yeah
[10:22] <ogra_> and if anything gets added casper does it, not the build process
[10:22] <xnox> i see.
[10:23] <ogra_> at least in terms of .desktop files
[10:23] <xnox> ogra_: tough chance on having a shortcut if oem-* packages are not installed though =)
[10:24] <xnox> hmm. but it was apt-install'ed.
[10:25] <ogra_> right, either unity changes somehow or we dont install the .desktop file anymore
[10:25] <xnox> ogra_: should oem-* be on the manifest? it's currently missing.
[10:25] <ogra_> i think it should, compare with an older one
[10:26] <xnox> (in squashfs or in the pool, that's the other question)
[10:26] <psivaa> xnox: ogra_ : this issue is with both precise and raring in today's images
[10:26] <ogra_> xnox, in squashfs
[10:26] <ogra_> afaik
[10:26] <xnox> psivaa: oem-config is on the iso in ./pool/main/u/ubiquity/oem-config_2.13.12_all.deb
[10:27] <xnox> let me sync new images.
[10:28] <psivaa> xnox: ahh ok, that may explain why the static validation tests are filing with ./pool is not being present in the images
[10:29] <xnox> psivaa: right, maybe that should be fixed first ;-)
[10:30] <psivaa> xnox: do you need a new bug for that or is the above bug enough to account that? :)
[10:32] <xnox> psivaa: i think it's best to move that bug above to ubuntu-cdimage project.
[10:32] <psivaa> xnox: ack
[10:33] <xnox> psivaa: where do you see static validation errors?
[10:34] <xnox> psivaa: are there raring validation jobs?! https://jenkins.qa.ubuntu.com/search/?q=static
[10:35] <psivaa> xnox: they are both precise and raring but not published
[10:36]  * ogra_ wonderas if we lost the live-ship seed or some such ... pool is filled by it usually
[10:48] <xnox> ogra_: it's interesting there is ./dists/ with usual set but the Packages.gz is empty and there is no pool at all on the cd =)
[10:48] <xnox> psivaa: i expect installing 3rd party software in offline mode not to work either as it depends on the /pool/ as well.
[10:49] <psivaa> xnox: ok, i have not tried that yet. will do in a little while
[10:50] <xnox> psivaa: no need. Image is borked.
[10:50] <psivaa> xnox: ack
[10:50] <xnox> (half-borked for non-essential features)
[10:52] <cjwatson> I'll look shortly
[10:52] <cjwatson> No doubt it's my fault
[11:05] <doko> so what keeps the php-horde packages out of raring?
[11:07] <Laney> their uninstallability
[11:08] <xnox> doko: the fact that -passwd and -whups need removing. As they depend on 4.x stack & php-horde has moved on to 5.x stack.
[11:08] <xnox> doko: or finding / uploading -passwd & -whups that can be installed with 5.x stack.
[11:09] <xnox> doko: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695898
[11:09] <ubot2`> Debian bug 695898 in php-horde-passwd "php-horde-passwd: not installable in sid, depends on old php-horde" [Serious,Open]
[11:10] <xnox> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695899
[11:10] <ubot2`> Debian bug 695899 in php-horde-whups "php-horde-whups: not installable in sid, depends on old php-horde" [Serious,Open]
[11:10] <xnox> and -wicked apperantly as well.
[11:11] <doko> Laney, which reminds me ... haskell in -proposed ;)
[11:12] <Laney> yep, feel free to help :-)
[11:13] <doko> next +1 maintenance cycle =)
[11:55] <cjwatson> Maybe I should teach proposed-migration that udebs may not depend on debs ...
[14:44] <ogra_> cjwatson, hmm, my ubuntu-touch sync script runs sync-mirrors as the last command, it looks like this doesnt happpen (i see the synced dir on nusakan but not on cdimage) do i need to add a PATH to my script (i thought running it as cdimage the PATH would be set correctly)
[14:46] <cjwatson> ogra_: bug 1133315
[14:46] <ubot2`> Launchpad bug 1133315 in Ubuntu CD Images "Export PATH as soon as possible to use cdimage tools" [Undecided,New] https://launchpad.net/bugs/1133315
[14:46] <cjwatson> Let me see about fixing that
[14:47] <cjwatson> Actually, that's something else
[14:47] <ogra_> well, it seems to have actually died before
[14:48] <ogra_> else it would have sent the log by mail
[14:48] <cjwatson> cjwatson@nusakan:~$ sudo -u cdimage env | grep PATH
[14:48] <cjwatson> PATH=/home/cjwatson/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
[14:48] <cjwatson> cjwatson@nusakan:~$ sudo -u cdimage -i env | grep PATH
[14:48] <cjwatson> PATH=/home/cdimage/bin:/home/cjwatson/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
[14:48] <cjwatson> Or something along those lines
[14:48] <cjwatson> Or you could just set PATH, which I think is what I would do
[14:48] <cjwatson> Note how cdimage's crontab sets PATH at the top
[14:49] <cjwatson> Not sure why that isn't set in your script in that case
[14:50] <ogra_> cjwatson, yeah, the script had a bug right before sync-mirrors
[14:52] <cjwatson> Ah, OK, I didn't read you properly
[15:45] <Laney> can someone please promote libarchive13?
[15:46] <cjwatson> Laney: done
[15:46] <Laney> merci
[17:02] <doko> Laney, do you have an idea where to start with the haskel migration?
[17:04] <Laney> it's already well underway
[17:04] <Laney> but there's at least one sub transition
[17:04] <Laney> I've been pulling the latest stuff from exp, rebuild testing and then syncing
[17:04] <doko> I think I added another one.
[17:04] <Laney> starting at the top of the table
[17:04] <Laney> if there's no new package (a sub transition for stuff we already synced), just do a no-change rebuild
[17:04] <doko> libgc1c3,
[17:05] <Laney> some of the things at the top fail to build and require upstream changes (I fixed a few of those already)
[17:05] <doko> and now kaya ftbfs, but as it looks, for unrelated reasons
[17:05] <Laney> check if stuff ftbfs in experimental too, that's usually a good sign that it needs porting
[17:06]  * xnox ponders if we can automate rebuild tries in a ppa or some such.
[17:07] <Laney> i thought about writing a script to do that locally
[17:07] <Laney> read .ben file, try rebuilding, dch --rebuild if successful
[17:22] <infinity> The biggest problem with the Haskell transition is that people overzealously sync/upload too quickly and let arches get out of sync.
[17:23] <infinity> And then you sometimes get to rebuild a chain 17 packages deep to fix it again.
[17:23] <infinity> Such a pain.
[17:23] <Laney> Yeah, wait for the slowest arch
[17:23] <Laney> yay sagari
[17:24] <infinity> Usually, the problem isn't speed, it's FTBFS and people not checking.
[17:24] <infinity> But speed sometimes too, yeah.  Especially when queues are slammed, like today.
[17:25] <cjwatson> Let's drop amd64, it's too far behind
[17:25] <infinity> +1
[17:26] <infinity> Well, no.
[17:26] <infinity> -1
[17:26] <infinity> Let's drop i386 and give all its buildds to adm64.
[17:26] <infinity> amd, too.
[17:26] <ogra_> just replace it with arm64
[17:27] <infinity> Speaking of the confusion between amd64 and arm64, I wonder if everyone else is as excited as I am about AMD getting into the AArch64 race.
[17:27] <infinity> Like, someone who actually knows how to fab and market server-class CPUs...
[17:30] <infinity> I look forward to a future when all our ARM buildds are AMD-based HP DL(mumble)s.
[17:30] <ogra_> ++
[17:31] <ogra_> and then later AMD arm64 laptops with radeon graphics :)
[17:40] <xnox> the most sold processors in the world are still 8-bit, more than 60% market share last time I checked.
[17:41] <xnox> 16bit is still teething in.
[17:50] <slangasek> "give all its buildds to adm64"? infinity has his own port now?
[17:50] <slangasek> though I didn't think he was that old
[17:52] <ScottK> Doesn't help much if it's octal either.
[17:55]  * slangasek thbts at bug #1134461
[17:55] <ubot2`> Launchpad bug 1134461 in base-files (Ubuntu) "/var/mail is real instead of symlink :: /var/spool/mail is symlink instead of real" [Undecided,Invalid] https://launchpad.net/bugs/1134461
[18:03]  * xnox failed to parse "thbts"
[18:06] <slangasek> xnox: a raspberry
[18:07]  * ScottK thought it was a "Bill the cat" imitation.
[18:07] <ScottK> ;-)
[18:07] <ScottK> Of course you all may be too young for that reference.
[18:17] <slangasek> ScottK: the preceding 'ack' was absent
[18:17] <ScottK> Good point.
[18:30] <infinity> cjwatson: *blink*... Did britney have an aneurysm?  The outdates it lists for linux are NBS...
[18:30]  * infinity wonders if the .dsc is wrong.
[18:31] <infinity> Nope.
[18:50] <infinity> cjwatson: Oh, that's because of the NBS in -proposed.  Bother.  I guess I'll clean that manually.
[18:52]  * infinity fixes.
[19:05] <cjwatson> infinity: Lack of reports for -proposed?  I wonder what happened to that work ...
[19:10] <infinity> Dunno.  But now I want them for $stable-proposed too.
[19:11] <infinity> Cause I realised that my change to make linux-* not show on sru-report (for many good reasons) also meant it stopped showing removal commands for it, and now I have built-up cruft. :P
[19:11] <ScottK> Isn't that called exceeding expectations?
[19:12] <infinity> Hrm.
[19:12] <infinity> You just can't make a your face / your mom retort to that.
[19:12] <infinity> "Your face exceeds expectations!"
[19:12] <infinity> "Why, thank you, good sir."
[19:15] <cjwatson> You could make linux-* not show in the main tables but still show removal commands for them.  Just exclude in a different place.
[19:16] <infinity> cjwatson: Well, I wanted "not show" to also mean "not pointlessly walk bugs", and there seemed to be only one place to do that.
[19:16] <infinity> cjwatson: But, yes, some refactoring could fix that.
[19:16] <cjwatson> Yeah, that might involve a pair of changes, or refactoring.
[20:30] <infinity> stgraber: Since slangasek and cjwatson don't seem to be around, want to wield your TB bat and add daviey to ~ubuntu-sru, so he can drive the tools while I'm training him?
[20:32] <stgraber> infinity: will do in a minute when I have a web browser again (doing PXE tests on my laptop at the moment)
[20:32] <infinity> Hah.
[20:34] <stgraber> infinity: added
[21:03] <bdmurray> Can somebody tell me where 'libappindicator_0.4.92-0ubuntu2.diff.gz already exists in Primary Archive for Ubuntu'?
[21:04] <jbicha> bdmurray: https://launchpad.net/ubuntu/+source/libappindicator/0.4.92-0ubuntu2
[21:08] <infinity> bdmurray: It's been superseded, but once a version's used up, it's gone.  No can re-use.
[21:09] <bdmurray> infinity: so just skip over ubuntu2 and ubuntu3?
[21:09] <infinity> bdmurray: Which series are you targetting?
[21:09] <bdmurray> precise
[21:09] <infinity> 0.4.92-0ubuntu1.1
[21:09] <ScottK> Yep
[23:31] <antarus> infinity: around?
[23:31] <antarus> or anyone on release team?
[23:31] <antarus> looks like one of your files is busted
[23:34] <antarus> hrm
[23:34] <antarus> spoke too soon
[23:34] <antarus> silly engineers lying to me ;p
[23:36] <infinity> antarus: Glad I resolved it without doing anything.
[23:36] <ScottK> Good job infinity.
[23:37]  * infinity buffs his nails on his shirt.