[10:27] <doko_> cjwatson, auctex b-d's on emacs23 | emacs24, and component-mismatches-proposed complains about it. does this really need a change?
[10:27] <cjwatson> Maybe
[10:27] <cjwatson> Where's auctex seeded?
[10:27] <shadeslayer> could someone point me to the procedure on how to ask for a 13.10.1 for Kubuntu? There's a Critical bug in the UEFI boot that we would like to get fixed : 1242417
[10:27] <shadeslayer> bug 1242417
[10:27] <ubot2> Launchpad bug 1242417 in grub2 (Ubuntu) "UEFI install broken when GRUB_DISTRIBUTOR!=Ubuntu (e.g. Kubuntu/UbuntuStudio)" [High,In progress] https://launchpad.net/bugs/1242417
[10:28] <cjwatson> shadeslayer: I'm not sure we have such a procedure
[10:28] <cjwatson> shadeslayer: Also, I think the installer will fetch grub2 from the network if it can and if it's newer ...
[10:28] <cjwatson> *think*
[10:28] <shadeslayer> :D
[10:28] <shadeslayer> my main concern is for machines without a network
[10:29] <doko_> supported-development-desktop
[10:29] <cjwatson> Send mail to ubuntu-release and I guess we'll see if we can figure something out
[10:29] <shadeslayer> okay
[10:29] <cjwatson> doko_: Which is odd because emacs24 is there explicitly, and that should be sufficient
[10:29] <cjwatson> doko_: Let me look at the underlying germinate output ...
[10:29] <shadeslayer> for machines with a network, most users will probably check "Apply updates when installing", so they should get the fix
[10:30] <cjwatson> shadeslayer: That checkbox actually isn't relevant here
[10:30] <cjwatson> It only applies to stuff in the livefs, which grub isn't
[10:30] <shadeslayer> oh, didn't know that ....
[10:31] <cjwatson> doko_: So, I think this is actually because auctex winds up in the expansion of the development seed
[10:31] <cjwatson> Rather than the explicit seed entry in supported-development-desktop
[10:32] <cjwatson> doko_: Choices are to seed emacs24 explicitly in ubuntu.trusty/development, or to modify auctex
[10:32] <shadeslayer> cjwatson: btw, any news on the dev symlink that was talked about last UDS? :D
[10:32] <cjwatson> doko_: Or to get to the point where we can remove emacs23, I suppose
[10:32] <cjwatson> shadeslayer: It's in the archive, there are some bugs though
[10:33] <shadeslayer> oh, like?
[10:34] <cjwatson> (a) its target seems unreliable (it was pointing to quantal at one point yesterday, although it points to trusty now), (b) in the past it hasn't reliably existed for all pockets, (c) apt issues warnings when you try to use it, (d) I don't think the UI is in place yet
[10:34] <cjwatson> I won't announce it until we've tidied at least some of that up
[10:34] <cjwatson> It is *possible* to use it though, and you can upload to devel
[10:35] <shadeslayer> sounds quite cool, can I make a chroot using devel?
[10:41] <cjwatson> shadeslayer: don't see why not
[10:41] <cjwatson> shadeslayer: it's just a symlink ... although debootstrap won't know about it
[10:42] <cjwatson> shadeslayer: so you'd still need to arrange to call debootstrap with trusty
[10:43] <shadeslayer> cjwatson: yup, created a devel symlink to gutsy
[11:32] <ScottK> shadeslayer: I released the SRU for the updated debootstrap for p/q/r/s yesterday, you shouldn't need to make your own.
[12:10] <shadeslayer> ScottK: we were talking about the devel release
[12:10] <shadeslayer> not trusty
[12:11] <ogra_> there is a difference ?
[12:11] <Laney> 'devel'
[12:11] <shadeslayer> ^^
[12:11] <ogra_> and devel isnt trusty currently ?
[12:11] <shadeslayer> it is, debootstrap just didn't have a script for it
[12:11] <xnox> shadeslayer: "devel" is current alias for "trusty"
[12:11] <cjwatson> He knows
[12:12] <ogra_> oh, for debootstrapping a devel with the actual rolling name !
[12:12] <xnox> bah.
[12:12]  * ogra_ gets it now
[12:12]  * xnox ditto
[12:12] <cjwatson> I'm reluctant to change debootstrap for this because I like to keep it in sync with Debian, and "devel" is awfully generic for that
[12:12] <cjwatson> (and debootstrap doesn't have an interface to select the distribution - it's all one big namespace)
[12:12] <ogra_> linkspace rather :)
[12:13] <cjwatson> I suspect adding a distribution option is the best long-term answer to this
[12:46] <doko_> cjwatson, looking at giflib, Depends: libperl4-corelibs-perl | perl (<< 5.12.3-7), however we didn't complain before about the mismatch
[12:59] <cjwatson> doko: Looking
[13:10] <shadeslayer> cjwatson: I was looking at http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/trusty/grub2/trusty/revision/2359 and it seems like util/grub-install.in has the change applied directly as well?
[13:10] <cjwatson> shadeslayer: yes
[13:10] <shadeslayer> intended?
[13:10] <cjwatson> shadeslayer: yes
[13:11] <shadeslayer> uh okay
[13:11] <cjwatson> shadeslayer: that branch is patches-applied
[13:11] <shadeslayer> I see
[13:11] <cjwatson> shadeslayer: so that for example I can "bzr blame" across both upstream and patches at once
[13:11] <doko> o libapache2-mod-auth-pgsql: libapache2-mod-auth-pgsql
[13:11] <doko>    [Reverse-Depends: Ubuntu.Trusty server-ship seed]
[13:11] <cjwatson> shadeslayer: this is useful to me
[13:11] <doko> this probably should just be removed from the seed
[13:11] <shadeslayer> ack
[13:12] <cjwatson> doko: it was in main in raring; removed for apache 2.4 transition, now fixed in Debian and reintroduced
[13:12] <cjwatson> doko: I'd be inclined to keep it and re-promote since it was there before
[13:12] <doko> libperl4-corelibs-perl?
[13:12] <cjwatson> doko: libapache2-mod-auth-pgsql
[13:13] <cjwatson> doko: I'm still investigating what happened with libperl4-corelibs-perl
[13:13] <cjwatson> (I'm about to go out for a bit, it may have to wait)
[13:15] <shadeslayer> cjwatson: if I upload grub2 with your fix to saucy, would you approve it once you get back?
[13:44] <doko> cjwatson, see https://bugs.launchpad.net/ubuntu/+source/emacs23-non-dfsg/+bug/1243207 for the emacs23 removal
[13:44] <ubot2> Launchpad bug 1243207 in emacs23-non-dfsg (Ubuntu Trusty) "remove emacs23 during the trusty cycle" [Undecided,New]
[13:48] <cjwatson> shadeslayer: Given it's my code, you should get somebody else to do it
[13:48] <cjwatson> doko: thanks
[13:48] <shadeslayer> okay
[13:48] <cjwatson> I mean, I think it's SRU-suitable, certainly, but there should be a different reviewer
[13:48] <doko> cjwatson, what is the bitsize tag?
[13:49] <cjwatson> bitesize, you mean?
[13:49] <doko> yes!
[13:49] <cjwatson> It usually means that it should be an easy and small thing for a new contributor to tackle
[13:49] <doko> sure, fixing dependencies and b-d's?
[13:51] <cjwatson> I guess
[13:51] <cjwatson> Probably ought to involve checking that the packages actually work with emacs24 too?
[13:52] <cjwatson> doko: libperl4-corelibs-perl is because perl-modules provided libperl4-corelibs-perl in saucy, but it no longer does as of perl 5.16
[13:53] <doko> cjwatson, ahh, so we can promote it because the code was already in main
[13:54] <cjwatson> doko: Yep
[14:02] <doko> cjwatson, are you ok with https://bugs.launchpad.net/ubuntu/+source/libtest-most-perl/+bug/1243176 and https://bugs.launchpad.net/ubuntu/+source/libcapture-tiny-perl/+bug/1243172 ?
[14:02] <ubot2> Launchpad bug 1243176 in libtest-most-perl (Ubuntu) "[MIR] libtest-most-perl (b-d of libconvert-binhex-perl)" [Undecided,New]
[14:02] <ubot2> Launchpad bug 1243172 in libparse-recdescent-perl (Ubuntu) "[MIR] b-d's for libtest-fatal-perl" [Undecided,New]
[14:02] <cjwatson> doko: those sound harmless
[14:03] <doko> and the last perlish one is https://bugs.launchpad.net/ubuntu/+source/libunicode-linebreak-perl/+bug/1243178
[14:03] <ubot2> Launchpad bug 1243178 in sombok (Ubuntu) "[MIR] b-d's for po4a (to run the tests)" [Undecided,New]
[14:04] <cjwatson> I expect the lib*-perl ones are pretty harmless; sombok might want a look
[14:04] <cjwatson> (it's probably fine though)
[14:25] <Laney> cjwatson: ^ is the one you pinged me about yesterday
[14:25] <Laney> should be able to remove the old source once that's in
[14:30] <doko> Laney, I don't mind if you do want to coordinate that with Debian
[14:32] <Laney> Well, you're already putting the effort in ;-)
[14:52] <doko> cjwatson, last one for the perl recommends is: https://bugs.launchpad.net/ubuntu/+source/libtext-soundex-perl/+bug/1243180
[14:52] <ubot2> Launchpad bug 1243180 in libtext-soundex-perl (Ubuntu) "[MIR] new recommends for perl 5.18" [Undecided,New]
[14:53] <cjwatson> doko: fine by me
[14:53] <cjwatson> (not that I have any say)
[15:02] <doko> INFO Upload was rejected:
[15:02] <doko> INFO 	libguava-java_15.0-2_all.deb: has 2 file(s) with a time stamp too far in the past (e.g. usr/share/doc/libguava-java/README [Sun Dec 30 23:00:00 1979]).
[15:02] <doko> INFO 	libguava-java-doc_15.0-2_all.deb: has 2 file(s) with a time stamp too far in the past (e.g. usr/share/doc/libguava-java-doc/AUTHORS [Sun Dec 30 23:00:00 1979]).
[15:02] <doko> re-upload?
[15:03] <cjwatson> doko: Will probably need a debian/rules change to fix the timestamps
[15:04] <cjwatson> I expect it worked in Debian because it's arch all and the maintainer had newer timestamps locally
[15:04] <cjwatson> but those aren't recorded in the source ... IMO this is at least an important bug in the Debian package
[15:07] <doko> Laney, mono, "please take" ?
[15:07] <Laney> what?
[15:08] <doko> the comment on mom ...
[15:08] <Laney> oh, let me see
[15:08] <Laney> was that me?
[15:09] <Laney> changed :-)
[15:10] <doko> Laney, but planned for trusty?
[15:11] <Laney> should be, but directhex will take care of it ideally
[15:11] <Laney> still stabilising it
[15:23] <doko> cjwatson, infinity: esys-particle now builds for 18h, the last version did need 6h on x86 ...
[15:30] <infinity> doko: Took 17h on amd64 this time, so I assume i386 will finish up soon.
[15:30] <infinity> doko: Clearly need to move all that junk to an arch_all package.  And maybe pre-optimise the PNGs in the source and turn off PNG mangling at build time.
[15:31] <infinity> But not deeply concerned about doing that today.  I scored it down to -1 on powerpc and arm64, so it won't be harming the queues there for now.
[16:16] <xnox> Hm, there is no xubuntu trusty daily yet.
[16:16] <xnox> Has it not been cronned back on yet, or failing?
[16:17] <infinity> None of them have been cronned back on yet.
[16:18] <infinity> stgraber: Does any magic need to happen to the tracker before we uncron trusty dailies and watch the world burn?
[16:18] <stgraber> yeah, I need to create the series and copy all the test cases, I'll do that after lunch
[16:20] <infinity> alternates and server will be broken until your d-i build filters through anyway.  So, I'll uncron a bit later.
[16:21] <cjwatson> And until d-i is updated to trusty
[16:22] <stgraber> cjwatson: that's what my upload was about
[16:22] <cjwatson> stgraber: I was still working on choose-mirror, at least
[16:23] <cjwatson> stgraber: And cdrom-detect and iso-scan haven't been done either - those are on my list
[16:23] <stgraber> oh yeah, I just did d-i itself...
[16:23] <stgraber> so yeah we need a bit more than just d-i indeed
[16:24] <cjwatson> I'll get them done today or tomorrow
[16:29] <doko> please give back libunicode-linebreak-perl once the fixed sombok is published (afk now)
[17:27] <infinity> cjwatson: I'm thinking we might want to remove arm64 from slow_arches soon.  We'll hit a point where it's doing more harm than good to let it skew.
[17:27] <cjwatson> Yeah, I was thinking of doing that towards the end of the week
[17:29] <infinity> Andy's doing up some HOWTO instructions and polishing off a script to make ubuntu-core plus the 3.12 kernel from their PPA into bootable images for the Foundation Model, so we may even have a plausible thing to point people to to investigate their arm64 issues.
[17:29] <cjwatson> Oh excellent
[20:13] <bdmurray> slangasek: https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/already-installed/+merge/192225
[20:15] <slangasek> bdmurray: would it be better to fix that at the source, and have errors not bucket them against packages in the first place?
[20:16] <slangasek> also, the logging changes look unrelated to me
[20:18] <bdmurray> slangasek: it'd be best to fix the apt bug that is causing the install failures and I'm looking into that.  I'd say this is a temporary measure.  The logging changes are unrelated but I thought they'd help.
[20:19] <slangasek> ok; fwiw this kind of problem has been present in apt in one form or another for quite a while, so I'm not confident that we'll manage to quickly fix all the occurrences
[20:19] <slangasek> I thought fixing the bucketing might be a good intermediate fix instead
[20:20] <bdmurray> okay, I'll think about how these are bucketed then too.