/srv/irclogs.ubuntu.com/2013/10/22/#ubuntu-release.txt

=== psivaa-afk is now known as psivaa
doko_cjwatson, auctex b-d's on emacs23 | emacs24, and component-mismatches-proposed complains about it. does this really need a change?10:27
cjwatsonMaybe10:27
cjwatsonWhere's auctex seeded?10:27
shadeslayercould 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 : 124241710:27
shadeslayerbug 124241710:27
ubot2Launchpad bug 1242417 in grub2 (Ubuntu) "UEFI install broken when GRUB_DISTRIBUTOR!=Ubuntu (e.g. Kubuntu/UbuntuStudio)" [High,In progress] https://launchpad.net/bugs/124241710:27
cjwatsonshadeslayer: I'm not sure we have such a procedure10:28
cjwatsonshadeslayer: 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:D10:28
shadeslayermy main concern is for machines without a network10:28
doko_supported-development-desktop10:29
cjwatsonSend mail to ubuntu-release and I guess we'll see if we can figure something out10:29
shadeslayerokay10:29
cjwatsondoko_: Which is odd because emacs24 is there explicitly, and that should be sufficient10:29
cjwatsondoko_: Let me look at the underlying germinate output ...10:29
shadeslayerfor machines with a network, most users will probably check "Apply updates when installing", so they should get the fix10:29
cjwatsonshadeslayer: That checkbox actually isn't relevant here10:30
cjwatsonIt only applies to stuff in the livefs, which grub isn't10:30
shadeslayeroh, didn't know that ....10:30
cjwatsondoko_: So, I think this is actually because auctex winds up in the expansion of the development seed10:31
cjwatsonRather than the explicit seed entry in supported-development-desktop10:31
cjwatsondoko_: Choices are to seed emacs24 explicitly in ubuntu.trusty/development, or to modify auctex10:32
shadeslayercjwatson: btw, any news on the dev symlink that was talked about last UDS? :D10:32
cjwatsondoko_: Or to get to the point where we can remove emacs23, I suppose10:32
cjwatsonshadeslayer: It's in the archive, there are some bugs though10:32
shadeslayeroh, like?10:33
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 yet10:34
cjwatsonI won't announce it until we've tidied at least some of that up10:34
cjwatsonIt is *possible* to use it though, and you can upload to devel10:34
shadeslayersounds quite cool, can I make a chroot using devel?10:35
cjwatsonshadeslayer: don't see why not10:41
cjwatsonshadeslayer: it's just a symlink ... although debootstrap won't know about it10:41
cjwatsonshadeslayer: so you'd still need to arrange to call debootstrap with trusty10:42
shadeslayercjwatson: yup, created a devel symlink to gutsy10:43
ScottKshadeslayer: I released the SRU for the updated debootstrap for p/q/r/s yesterday, you shouldn't need to make your own.11:32
shadeslayerScottK: we were talking about the devel release12:10
shadeslayernot trusty12:10
ogra_there is a difference ?12:11
Laney'devel'12:11
shadeslayer^^12:11
ogra_and devel isnt trusty currently ?12:11
shadeslayerit is, debootstrap just didn't have a script for it12:11
xnoxshadeslayer: "devel" is current alias for "trusty"12:11
cjwatsonHe knows12:11
ogra_oh, for debootstrapping a devel with the actual rolling name !12:12
xnoxbah.12:12
* ogra_ gets it now12:12
* xnox ditto12:12
cjwatsonI'm reluctant to change debootstrap for this because I like to keep it in sync with Debian, and "devel" is awfully generic for that12: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:12
cjwatsonI suspect adding a distribution option is the best long-term answer to this12:13
=== brainwash_ is now known as brainwash
doko_cjwatson, looking at giflib, Depends: libperl4-corelibs-perl | perl (<< 5.12.3-7), however we didn't complain before about the mismatch12:46
=== doko_ is now known as doko
cjwatsondoko: Looking12:59
shadeslayercjwatson: 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
cjwatsonshadeslayer: yes13:10
shadeslayerintended?13:10
cjwatsonshadeslayer: yes13:10
shadeslayeruh okay13:11
cjwatsonshadeslayer: that branch is patches-applied13:11
shadeslayerI see13:11
cjwatsonshadeslayer: so that for example I can "bzr blame" across both upstream and patches at once13:11
dokoo libapache2-mod-auth-pgsql: libapache2-mod-auth-pgsql13:11
doko   [Reverse-Depends: Ubuntu.Trusty server-ship seed]13:11
cjwatsonshadeslayer: this is useful to me13:11
dokothis probably should just be removed from the seed13:11
shadeslayerack13:11
cjwatsondoko: it was in main in raring; removed for apache 2.4 transition, now fixed in Debian and reintroduced13:12
cjwatsondoko: I'd be inclined to keep it and re-promote since it was there before13:12
dokolibperl4-corelibs-perl?13:12
cjwatsondoko: libapache2-mod-auth-pgsql13:12
cjwatsondoko: I'm still investigating what happened with libperl4-corelibs-perl13:13
cjwatson(I'm about to go out for a bit, it may have to wait)13:13
shadeslayercjwatson: if I upload grub2 with your fix to saucy, would you approve it once you get back?13:15
dokocjwatson, see https://bugs.launchpad.net/ubuntu/+source/emacs23-non-dfsg/+bug/1243207 for the emacs23 removal13:44
ubot2Launchpad bug 1243207 in emacs23-non-dfsg (Ubuntu Trusty) "remove emacs23 during the trusty cycle" [Undecided,New]13:44
cjwatsonshadeslayer: Given it's my code, you should get somebody else to do it13:48
cjwatsondoko: thanks13:48
shadeslayerokay13:48
cjwatsonI mean, I think it's SRU-suitable, certainly, but there should be a different reviewer13:48
dokocjwatson, what is the bitsize tag?13:48
cjwatsonbitesize, you mean?13:49
dokoyes!13:49
cjwatsonIt usually means that it should be an easy and small thing for a new contributor to tackle13:49
dokosure, fixing dependencies and b-d's?13:49
cjwatsonI guess13:51
cjwatsonProbably ought to involve checking that the packages actually work with emacs24 too?13:51
cjwatsondoko: libperl4-corelibs-perl is because perl-modules provided libperl4-corelibs-perl in saucy, but it no longer does as of perl 5.1613:52
dokocjwatson, ahh, so we can promote it because the code was already in main13:53
cjwatsondoko: Yep13:54
dokocjwatson, 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
ubot2Launchpad bug 1243176 in libtest-most-perl (Ubuntu) "[MIR] libtest-most-perl (b-d of libconvert-binhex-perl)" [Undecided,New]14:02
ubot2Launchpad bug 1243172 in libparse-recdescent-perl (Ubuntu) "[MIR] b-d's for libtest-fatal-perl" [Undecided,New]14:02
cjwatsondoko: those sound harmless14:02
dokoand the last perlish one is https://bugs.launchpad.net/ubuntu/+source/libunicode-linebreak-perl/+bug/124317814:03
ubot2Launchpad bug 1243178 in sombok (Ubuntu) "[MIR] b-d's for po4a (to run the tests)" [Undecided,New]14:03
cjwatsonI expect the lib*-perl ones are pretty harmless; sombok might want a look14:04
cjwatson(it's probably fine though)14:04
Laneycjwatson: ^ is the one you pinged me about yesterday14:25
Laneyshould be able to remove the old source once that's in14:25
dokoLaney, I don't mind if you do want to coordinate that with Debian14:30
LaneyWell, you're already putting the effort in ;-)14:32
dokocjwatson, last one for the perl recommends is: https://bugs.launchpad.net/ubuntu/+source/libtext-soundex-perl/+bug/124318014:52
ubot2Launchpad bug 1243180 in libtext-soundex-perl (Ubuntu) "[MIR] new recommends for perl 5.18" [Undecided,New]14:52
cjwatsondoko: fine by me14:53
cjwatson(not that I have any say)14:53
dokoINFO Upload was rejected:15:02
dokoINFO 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
dokoINFO 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
dokore-upload?15:02
cjwatsondoko: Will probably need a debian/rules change to fix the timestamps15:03
cjwatsonI expect it worked in Debian because it's arch all and the maintainer had newer timestamps locally15:04
cjwatsonbut those aren't recorded in the source ... IMO this is at least an important bug in the Debian package15:04
dokoLaney, mono, "please take" ?15:07
Laneywhat?15:07
dokothe comment on mom ...15:08
Laneyoh, let me see15:08
Laneywas that me?15:08
Laneychanged :-)15:09
dokoLaney, but planned for trusty?15:10
Laneyshould be, but directhex will take care of it ideally15:11
Laneystill stabilising it15:11
dokocjwatson, infinity: esys-particle now builds for 18h, the last version did need 6h on x86 ...15:23
infinitydoko: Took 17h on amd64 this time, so I assume i386 will finish up soon.15:30
infinitydoko: 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:30
infinityBut 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.15:31
xnoxHm, there is no xubuntu trusty daily yet.16:16
xnoxHas it not been cronned back on yet, or failing?16:16
infinityNone of them have been cronned back on yet.16:17
infinitystgraber: Does any magic need to happen to the tracker before we uncron trusty dailies and watch the world burn?16:18
stgraberyeah, I need to create the series and copy all the test cases, I'll do that after lunch16:18
infinityalternates and server will be broken until your d-i build filters through anyway.  So, I'll uncron a bit later.16:20
cjwatsonAnd until d-i is updated to trusty16:21
stgrabercjwatson: that's what my upload was about16:22
cjwatsonstgraber: I was still working on choose-mirror, at least16:22
cjwatsonstgraber: And cdrom-detect and iso-scan haven't been done either - those are on my list16:23
stgraberoh yeah, I just did d-i itself...16:23
stgraberso yeah we need a bit more than just d-i indeed16:23
cjwatsonI'll get them done today or tomorrow16:24
dokoplease give back libunicode-linebreak-perl once the fixed sombok is published (afk now)16:29
=== rtg_ is now known as Guest33959
infinitycjwatson: 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
cjwatsonYeah, I was thinking of doing that towards the end of the week17:27
infinityAndy'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
cjwatsonOh excellent17:29
bdmurrayslangasek: https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/already-installed/+merge/19222520:13
slangasekbdmurray: would it be better to fix that at the source, and have errors not bucket them against packages in the first place?20:15
slangasekalso, the logging changes look unrelated to me20:16
bdmurrayslangasek: 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:18
slangasekok; 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 occurrences20:19
slangasekI thought fixing the bucketing might be a good intermediate fix instead20:19
bdmurrayokay, I'll think about how these are bucketed then too.20:20

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!