[00:45] <directhex> when is a good time to break the world?
[00:45] <sebner> directhex: just before weekend!
[00:45] <directhex> i.e. when's the nearest alpha or whatevs being spun?
[00:46] <RAOF> directhex: Uploading 2.10?
[00:46] <RAOF> directhex: The next alpha's some weeks away.
[00:46] <directhex> RAOF: scheduling it, yes
[00:46] <directhex> RAOF: it means rebooting my bitcoin miner away from windows though. or i could use the work laptop
[00:46] <RAOF> 7th of July is alpha 2.
[00:47] <RAOF> If you want to break the world, now's a pretty good time.
[00:47] <directhex> agreed
[00:48] <cjwatson> yeah, it's OK
[00:48] <cjwatson> I expect Linux 3.0 will be breaking random bits of the world for a while too
[00:48] <directhex> cjwatson: the CDs will be oversize until the 2.10 transition is over, FYI
[00:48] <cjwatson> OK
[00:58] <directhex> no turning back now :o
[01:10] <directhex> cjwatson: it seems i (and i guess the mono group) lack the rights to upload cli-common. can it be added to the packageset?
[01:15] <stgraber> hmm, indeed, for some reason it's in the "core" package set
[01:16] <RAOF> directhex: If you need a sponsor for now, I'm happy to help.
[01:18] <directhex> RAOF: well, feel free to syncpackage it yourself from exp
[01:18] <RAOF> Will do.
[01:19] <directhex> s' largely your work anyway isn't it?
[01:19] <RAOF> Quite a lot of the changes will be, yeah.
[02:11] <kees> @pilot out
[02:14] <TheMuso> /c/c
[04:52] <broder> when did the patch pilots become unfriendly?
[04:59] <broder> ...huh. apparently a couple of months ago
[05:13] <lifeless> thats not the intent
[05:13] <lifeless> so perhaps raise that for discussion
[05:26] <pitti> Good morning
[05:27] <pitti> smoser: so that's the reason for it re-starting over and over? not the /dev/xconsole warning?
[05:27] <pitti> smoser: that would at least be a more appropriate behaviour of rsyslog :)
[05:27] <pitti> smoser: fine for me
[05:28] <stgraber> morning pitti
[05:34] <TheMuso> broder: How have they become unfriendly?
[05:34] <TheMuso> Hrm seems oneiric has some LVM troubles, and seems that logging out of any GNOME session is broken, at lesat for me.
[05:35] <TheMuso> broder: I'm interested because if I am appearing less friendly, I want to do something about it.
[05:35] <ajmitch> TheMuso: I think the topic used to have room for mentioning the friendly patch pilots
[05:36] <TheMuso> ah ok.
[05:36] <ajmitch> so I don't think it's any change in attitude, just in what fits in the channel topic :)
[05:40] <TheMuso> ah ok.
[06:01] <broder> TheMuso: yeah, sorry - what ajmitch said
[06:01] <broder> the people themselves are fantastic
[06:01] <TheMuso> ok then thats good.
[06:02] <broder> let's see...if i go and twiddle with...
[06:02] <broder> @pilot in
[06:02] <broder> @pilot out
[06:02] <broder> lame
[07:31] <didrocks> good morning
[07:55] <tkamppeter> pitti, hi
[07:55] <pitti> hello tkamppeter
[08:00] <tkamppeter> pitti, about CUPS, I have found out something about the problems with the USB URIs.
[08:01] <tkamppeter> pitti, the device IDs are absolutely the same when read out via usblp or via libusb.
[08:02] <pitti> tkamppeter: right, that's good (expected though); but I thought we don't have the original device IDs?
[08:02] <tkamppeter> pitti, the two usb backend versions have an inconsistency. The usblp backend removes a repetition of the manufacturer name in the MDL field of the ID, the libusb backend does not do so.
[08:03] <tkamppeter> pitti, this is a bug and can be fixed with a simple patch in the libusb backend.
[08:04] <tkamppeter> pitti, this would solve one of the three causes of differences which I showed to you yesterday.
[08:06] <tkamppeter> pitti, the other two, having no serial number with usblp and having a serial number with libusb and also having the "interface=1" in the URI are additional features of the libusb approach.
[08:07] <tkamppeter> pitti, dropping them would make the URIs absolutely equal, but we should not remove these features.
[08:10] <tkamppeter> pitti, a solution which does not require the user to have his printer turned on while updating CUPS would be to let the libusb-based backend be able to use the old URIs and this is not complicated to code, as the  code for that is in the patch which we dropped. I can create a simpler patch with only that code and the code also somewhat improved, to remove a possible cause for a segfault.
[08:11] <pitti> tkamppeter: I think making this work for printers which are turned on should cover most cases indeed
[08:11] <pitti> tkamppeter: right, I don't like dropping the interface=1 either, as it would again be an inconsistency with how upstream handles that, and also more error prone
[08:22] <tkamppeter> pitti, with the new patch the old URIs will simply be accepted by the new USB backend, allowing the user to print without URI migration. This will help all migrating users, as with using usblp before they could not have two printers of the same model connected when usblp did not reveal the serial numbers and they also could not have used all the interfaces of a multi-interface printer.
[08:22] <tkamppeter> pitti, warnings in error_log could tell that the URIs could be improved.
[08:26] <pitti> that sounds good
[08:26] <pitti> so new printers would use the full URIs, but the old ones keep working
[08:32] <didrocks> @pilot in
[08:40] <dholbach> good morning
[08:47] <tkamppeter> pitti, exactly that, new printers will use the full URIs, but the old ones keep working
[09:26] <tkamppeter> pitti, I have updated CUPS now with the new patch. Can you upload it, so that it gets more testing? Thanks.
[09:27] <pitti> tkamppeter: sure; thanks!
[09:40] <real_ate> hi all! I was hoping someone here could give me a bit of advice when it comes to shipping packages around into remote repositories
[09:40] <real_ate> our company is using ubuntu as a base for our next web application and we're building packages for the update/distribution/installation
[09:41] <real_ate> and we are using an automated build machine to build the packages... all this works... the problem is when we are trying to "ship" the packages
[09:41] <real_ate> our "repository" is located the VPS that is hosting our website
[09:42] <real_ate> but that machine is CentOS
[09:42] <real_ate> and is not likely to change. (bummer)
[09:43] <real_ate> and we can't make use of reprepro on that server so we are kinda stuck on how to get the packages up to the server and still maintain different "releases" on the server
[09:45] <real_ate> we have been building the repo every time from scratch on our build machine and then using scp to *overwrite* the repository. This works ok but because we are not using reprepro to get the packages in there and to maintain the lists and stuff it doen't clean up any unused packages
[09:45] <real_ate> and we are starting to get package sprawl, taking up too much disk space.
[09:45] <real_ate> Can anyone suggest a better way?  thanks in advance :D
[09:46] <geser> real_ate: can't you use reprepro on the build machine and rsync the "result" to your VPS?
[09:48] <real_ate> geser: no because we are dynamically provisioning the build machine on Amazon
[09:48] <seb128> if somebody wants to look at the cairo ftfbs that would be nice, I've no clue about it
[09:48] <seb128> https://launchpadlibrarian.net/73205652/buildlog_ubuntu-oneiric-i386.cairo_1.10.2-6ubuntu1_FAILEDTOBUILD.txt.gz
[09:49] <real_ate> geser: and for that to work it would have to be : Build Packages -> Copy old repo to the EC2 instance -> use reprepro -> copy back
[09:50] <real_ate> and we would be paying for transfer on both ends ;)
[09:50] <geser> real_ate: and the reason for not being able to use reprepro on the VPS are missing "debian" tools?
[09:51] <real_ate> geser: yes
[09:51] <real_ate> geser: we have found that there is debmirror in CentOS, but that has just the same problem
[09:52] <geser> real_ate: can't you create a small debian (or Ubuntu) chroot on your VPS to run reprepro?
[09:52] <seb128> hum, got sidetracked
[09:52] <seb128> so cairo fails on
[09:52] <seb128> "ccQQ5PqR.ltrans1.o:(.text+0x724): undefined reference to `pow'
[09:52] <seb128> collect2: ld returned 1 exit status"
[09:52] <seb128> but it has a -lm
[09:53] <seb128> it builds on a natty builder or in oneiric with gcc-4.5, not with gcc-4.6
[09:53] <real_ate> geser: eh...
[09:53] <real_ate> *thinks about this one*
[09:53] <seb128> changing the -lm order or adding some -L... to the libm.so directory doesn't make it build, not sure what's wrong
[09:54] <seb128> so if somebody has a clue of what is wrong I'm not saying no to know why ;-)
[09:54] <real_ate> geser: so that would mean that we would be runing the ubuntu binaries/libs under the centos 5.6 kernal right?
[09:54] <geser> yes
[09:55] <mjr> are there instructions for making alternate install disks (or more spesifically just the PXE kernel/initrd pair would suffice) for 10.04 LTS, or prebuilt ones with backported kernels from later releases?
[09:56] <real_ate> geser: ... its an interesting suggestion i have to hand it to you! :D real out of the box thinking
[09:58] <real_ate> geser: but we probably won't gain very much on space improvements
[09:59] <slangasek> seb128: I believe I have a bug report open against gcc-4.6 already for that
[09:59] <real_ate> we would have to dedicate a chunk of the disk to the ubuntu chroot, which we can't afford on this machine.
[09:59] <slangasek> seb128: bug #778292
[09:59] <seb128> slangasek, oh, thanks!
[09:59] <seb128> should -flto be turned off or something?
[10:00] <slangasek> seb128: best to ask doko; I only triaged the bug, I don't know what it means :-)
[10:01] <seb128> doko_, hey, what do you recommend for that gcc bug breaking cairo? should we wait a gcc fix or workaround it and how?
[10:02] <geser> real_ate: hmm, can you host your reprepro on one of your workstations and rsync the repository to your VPS?
[10:02] <geser> real_ate: how much disk space do you have available on the VPS?
[10:05] <real_ate> geser: we can't host the reprepro on any of our workstations. This is exactly the problem we are trying to get aroud
[10:06] <real_ate> :D
[10:06] <real_ate> geser: we have quite a large amount of stuff that needs to be built and uploaded
[10:07] <real_ate> and have a terrible (i mean really terrible) upload speed from the office
[10:08] <real_ate> we're talking about 1GB for a full upload of packages, which was taking about 6-12 Hours a pop, depending on the reliability of our connection
[10:09] <real_ate> geser: and its not a matter of not having enough disk space on the VPS, the problem is that we always deal with large files like this and if the repo can't be cleaned things will get out of control very quickly
[10:12] <doko_> seb128: either disable lto, or don't use --as-needed
[10:13] <seb128> doko_, ok, I will turn off --as-needed for now I think, it's the easier to do, thanks
[10:13] <cjwatson> directhex: I've added cli-common to the cli-mono set
[10:14] <cjwatson> broder: topic space is very limited, perhaps not the ideal place to express friendliness
[10:15] <directhex> cjwatson, ta
[10:16] <directhex> cjwatson, need to isolate the armel build failure now. sigh
[10:20] <didrocks> Amaranth: your 07_* patch didn't apply in c-p-m (no -p1 for your patch)
[10:29] <tkamppeter> "sudo lsusb -vvv" hangs on a built-in USB hub on my laptop, can one fix this without rebooting?
[10:33] <micahg> hi doko, I was wondering if you ever saw my question about a libreadline transition
[10:39] <cjwatson> doko_: I'd appreciate a quick look at http://bugs.debian.org/630006, if you have a moment; it's blocking d-i builds
[10:48] <pitti> tseliot: want me to look at bug 756163 ?
[10:48] <tseliot> pitti: yes, please, I really don't know what's going on there
[10:49] <pitti> ok
[10:56] <chrisccoulson> directhex, how familiar are you with the moonlight plugin? and do you know what the mozilla-specific parts of that plugin are used for? (ie, everything in plugin/firefox in the source tree)
[10:57] <directhex> chrisccoulson, i believe that stuff is largely obsolete nowadays, given the steady abandonment of the xpcom apis used by that code, in modern firefox
[10:57] <directhex> chrisccoulson, best bet is to speak to shana on gimpnet for a sane explanation
[10:58] <chrisccoulson> directhex, ok, thanks. i'm not sure if you saw https://lists.ubuntu.com/archives/ubuntu-devel/2011-May/033229.html , but i'm trying to figure out whether we can keep moonlight but just drop the mozilla-specific parts
[10:59] <chrisccoulson> as it's not really much code at all
[10:59] <chrisccoulson> i'll find shana and ask though. thanks!
[10:59] <directhex> chrisccoulson, i didn't see that. i'd definitely talk to andreia though. let me know what she says
[11:00] <chrisccoulson> thanks
[11:01] <directhex> chrisccoulson, relatedly, i know she did some work on gluezilla which is also affected by xulrunner removal. worth bringing that up too.
[11:02] <chrisccoulson> directhex, ok, will do. thanks
[11:04] <directhex> i think gluezilla was updated to work okay with ff4, but segfaults on garbage disposal due to some threading problem. personally i wanted a move to use webkit-sharp for the system.windows.forms.webbrowser control emulation (which is what gluezilla does) since it tends to break less frequently for embedding circumstances than moz
[11:05] <chrisccoulson> directhex, yeah. and mozilla embedding is going to be break quite frequently in the future. do you know if gluezilla uses gtkmozembed?
[11:06] <tkamppeter> pitti, thanks for the upload.
[11:06] <directhex> chrisccoulson, historically? probably. hence the desire to dump it for webkit-sharp.
[11:06] <chrisccoulson> directhex, ah, ok. the reason i asked is that gtkmozembed has actually been removed entirely now - https://groups.google.com/forum/#!topic/mozilla.dev.embedding/c_NMcO-N8wo/discussion
[11:09] <tkamppeter> I have a problem with USB, seems that my Lenovo laptop is not compatible with the Oneiric kernel. Even directly after reboot "sudo lsusb -vvv" hangs and on the system console I get several message "usb 7-1: device descriptor read/64, error -110" and after some minutes I get "hup 7-0:1.0: unable to enumerate USB device on port 1". Anyone has an idea what happens?
[11:13] <real_ate> geser: turns out we can use reprepro over a mounted ssh, and moves happen server side! rockin! ;)
[11:14] <real_ate> we're currently investigating/testing
[11:17] <didrocks> dholbach: hey, seems I'm marked as "community" in most of merges and not in bold in http://reports.qa.ubuntu.com/reports/sponsoring/. However, I'm in the sponsor team, any idea what's missing?
[11:18] <dholbach> didrocks, the sponsoring overview does not know anything about "Community" AFAIK
[11:19] <dholbach> didrocks, ah
[11:19] <didrocks> hum, not sure why I'm not an Ubuntu Developer (neither in italic) :p
[11:19] <dholbach> it's "gedit (upstream)"
[11:19] <dholbach> at least that's the sponsoring overview understands it
[11:19] <didrocks> dholbach: oh ok :)
[11:20] <didrocks> weird: Merge into:lp:~ubuntu-desktop/gedit/ubuntu
[11:20] <dholbach> yes, that's an upstream branch
[11:20] <dholbach> it's not a source package branch
[11:20] <didrocks> not really :)
[11:20] <dholbach> well, in launchpad terms it is
[11:20] <didrocks> it's our desktop team branch :)
[11:20] <didrocks> right
[11:20] <didrocks> I'll add that as well in my report
[11:20] <dholbach> it's not ~<person>/ubuntu/<release>/<pkg>/<title>
[11:20] <seb128> the sponsoring queue only really understand udd merge requests
[11:20] <dholbach> I would prefer not to have to teach the sponsoring overview how the desktop team handles things in a special way
[11:21] <seb128> it doesn't even list other ones if you don't subscribe the sponsors
[11:21] <seb128> dholbach, that's fine, our version page lists our desktop merge requests ;-)
[11:21] <dholbach> great, thanks :)
[11:21] <seb128> it's better than your sponsoring page :p
[11:21]  * seb128 hugs dholbach
[11:21]  * dholbach hugs seb128 back
[11:23] <doko_> cjwatson: ok, looking at it today
[11:32] <mjr> was there instructions somewhere on building a 10.04 alternate installer kernel/pxe-initrd pair with a newer kernel (or prebuilt install images with later backported kernels)?
[11:37] <cjwatson> doko_: thanks
[11:37] <cjwatson> mjr: is this an Ubuntu kernel from -proposed or -updates or something, or a custom one?
[11:41] <mjr> an lts-backport kernel would be fine
[11:43] <mjr> just need a bit of extra hardware support at install-time
[11:44] <mjr> (extra as in supported in newer kernels out of the box)
[11:48] <cjwatson> mjr: basically you need to get the debian-installer source package, change build/config/<architecture>.cfg to have the kernel version + ABI number you want to use, and debuild -b
[11:49] <mjr> okay, sounds like a proper starting point, thanks
[11:49] <cjwatson> if it's not in one of the sources d-i looks in by default, you might need to run 'util/gen-sources.list.udeb' in build/, then copy sources.list.udeb to sources.list.udeb.local and edit it
[11:52] <cjwatson> is somebody other than me processing syncs?  I was in the middle of some
[11:54] <cjwatson> didrocks: ^-
[11:54] <didrocks> cjwatson: yeah, I was as well, sorry
[11:54] <cjwatson> I flushed the ones I was doing individually, so you can go ahead now
[11:55] <didrocks> cjwatson: ok thanks, finishing those I was heading to :)
[11:55] <cjwatson> (I did agda-bin and nautilus-dropbox)
[11:55] <didrocks> oh ok, removing agda-bin then
[12:09] <didrocks> @pilot out
[12:23] <TLE> pitti: Hallo. Thanks for the email. I was wondering.
[12:26] <siretart> chrisccoulson: yes?
[12:34] <TLE> pitti: Is there any special kind of testing that should be done, now that there has been this infrastructure change for firefox?
[12:34]  * dholbach hugs didrocks
[12:34] <TLE> testing l10n-wise I mean
[12:34]  * didrocks hugs dholbach back :)
[12:34] <dholbach> :)
[12:56] <pitti> TLE: just that translations still work; the new langpacks should pull in firefox-locale-*
[12:57] <TLE> pitti: ok thanks
[13:44] <doko_> cjwatson: libffi udeb in NEW
[13:48] <kenvandine> @pilot in
[14:18]  * dholbach hugs kenvandine
[14:19]  * kenvandine hugs dholbach
[14:19] <dholbach> :)
[14:26] <cjwatson> doko_: thanks, will look
[14:28] <cjwatson> doko_: I'm afraid that's wrong - Pre-Depends: multiarch-support is unsatisfiable in d-i
[14:28] <cjwatson> doko_: installing to /usr/lib/$(DEB_HOST_MULTIARCH)/ is fine, but you need to drop the Pre-Depends
[14:29] <cjwatson> (for the udeb)
[14:50] <brendand> mvo - i just put this branch for review https://code.launchpad.net/~brendan-donegan/update-manager/bug791548_networkmanager0.9/+merge/64185
[14:50] <brendand> ignore ubottu
[14:50] <mvo> brendand: its reviewed and merged already, many thanks!
[14:51] <brendand> mvo - perhaps you're thinking of a different one?
[14:51] <brendand> mvo - this one is for the NM problem in O
[14:53] <seb128> hum, kvm sit on the plymouth logo eating cpu when trying to boot isos in oneiric and usb-creator keeps spinning on disk erase and doesn't offer the create a disk on start
[14:53] <seb128> that's going to be interesting to try an iso :p
[14:53] <brendand> mvo - thanks. lp just took a bit :)
[14:54] <mvo> brendand: great!
[14:54] <doko_> cjwatson: hmm, lintian complains about it
[14:55] <doko_> and this is a check, which is enforced by ftp-master
[14:57] <dholbach> if somebody has a bit of time to review pad.lv/mps/ubuntu-sponsoring that'd be nice :)
[15:04] <cjwatson> doko_: totally a lintian bug.  it's overridable, so override it for now and I'll get it fixed in lintian
[15:05] <doko_> ok
[15:06] <doko_> cjwatson: hmm, how is the override file called for an udeb?
[15:07] <cjwatson> oh, that's annoying
[15:08] <cjwatson> same as usual, but it's cruft that shouldn't be in a udeb :-/
[15:08] <cjwatson> /usr/share/lintian/overrides/libffi6-udeb
[15:08] <cjwatson> doko_: alternatively, just don't make the udeb multiarch
[15:08] <cjwatson> there's no particular need for it
[15:09] <cjwatson> that might be better for the momeent
[15:09] <cjwatson> *moment
[15:14] <cjwatson> doko_: fixed in lintian.git, anyway, but it'll take a while for that to be deployed on ftp-master so I think just not making the udeb multiarch is the most straightforward answer
[15:16] <DktrKranz> cjwatson: if that turns to be a blocker, we could see to speed things up. It requires a lintian upload, though.
[15:17] <abhinav-> dholbach: your blog is timing out while loading. cannot open the links posted on fb and twitter
[15:18] <cjwatson> DktrKranz: shouldn't be a blocker, I hope; no udeb ever actually needs to be multiarch
[15:18] <cjwatson> (at least at the moment)
[15:18] <cjwatson> (but thanks)
[15:24] <dholbach> abhinav-, it works for me
[15:25] <dholbach> abhinav-, nigelb had a similar problem yesterday - can you traceroute it and see how far you get?
[15:25] <abhinav-> dholbach: sure
[15:30] <abhinav-> dholbach: it times out after 10 hops. would you like to see the output of traceroute ?
[15:30] <dholbach> abhinav-, what's the last hop?
[15:31] <abhinav-> dholbach: so-1-3-0.0.pjr01.ldn001.flagtel.com (85.95.25.114)  340.677 ms  341.246 ms  342.055 ms
[15:31] <dholbach> for nigelb yesterday it was "so-1-3-0.0.pjr01.ldn001.flagtel.com (85.95.25.114)"
[15:31] <dholbach> aha, interesting - seems you have a similar route and something goes wrong there :-/
[15:31] <nigelb> abhinav-: airtel?
[15:32] <abhinav-> yes
[15:32] <nigelb> dholbach: Our ISPs are the same.
[15:33] <dholbach> I'm sorry, there's not a lot I can do about it
[15:34] <stgraber> well, I guess that blog post will appear on Planet Ubuntu if it's not already there
[15:34] <stgraber> so you can probably read from there instead
[15:35] <stgraber> though you'll be missing the comments
[15:36] <nigelb> stgraber: I just socks proxy through my VPS :-)
[15:36] <stgraber> that works too :)
[15:36]  * stgraber wonders how many people know of ssh's "-D" parameter ;)
[15:39]  * nigelb uses is every so often :D
[15:49] <doko_> cjwatson: re-uploaded, now afk
[15:51] <cjwatson> doko_: thanks
[16:10] <cjohnston> !regression-alert  bug 795520  <-- I was told to do that ;-)
[16:13] <jdstrand> cjohnston: fyi, that bug is private, which is why ubottu can't deal
[16:14] <jdstrand> cjohnston: afaict, there is nothing in the bug that should be kept private...
[16:14] <cjohnston> jdstrand: I wasn't sure, so when I started attaching things, I marked it private
[16:15] <cjohnston> its not private anymore
[16:15] <jdstrand> cjohnston: feel free to use regression-alert again
[16:15] <cjohnston> !regression-alert  bug 795520
[16:15] <cjohnston> now what did i do wrong
[16:16] <cjohnston> no pioe?
[16:16] <cjohnston> pipe
[16:16] <cjwatson> cjohnston: there's no such version of bcmwl published in any Ubuntu release
[16:16] <cjwatson> 5.100.82.38+bdcom-0ubuntu3, but not 5.100.82.38+bdcom-0ubuntu3.1
[16:16] <cjwatson> ah, it was already deleted from natty-proposed
[16:16] <charlie-tca> maybe without the bug? or since it is a bot command, with the | between the command and bug
[16:16] <cjwatson> "bad SRU"
[16:19] <jdstrand> charlie-tca, cjohnston: I think !regression-alert should be on it's own. then describe it after.
[16:19]  * jdstrand updates wiki
[16:19] <cjohnston> I was just given the first part in a PM, so I was trying to make it work.. I guess I got attention anyway.. heh
[16:22] <seb128> cjwatson, pitti, hum, the new lsb version built with python3 witll had an almost 6mb to the cd tomorrow :-(
[16:23] <pitti> ah, it's hte first package to pull in python 3?
[16:23] <cjohnston> cjwatson: is there anything I can do to fix my system with it being deleted?
[16:23] <seb128> pitti, yes
[16:24] <cjwatson> cjohnston: 'sudo apt-get install bcmwl-kernel-source/natty' ought to do it
[16:25] <cjwatson> seb128: hmm, I wonder if this is doko committing to python3 for oneiric.  Let's not worry too much about it immediately
[16:25] <seb128> cjwatson, ok
[16:25] <cjohnston> no errors...
[16:29] <cjohnston> That worked.. I have wireless again.. Thanks cjwatson
[16:41] <jelmer> cjwatson, hi, still there?
[16:42] <cjwatson> jelmer: hi
[16:43] <jelmer> cjwatson: I proposed an SRU for bzr, with ~ubuntu-sru subscribed to the merge proposal
[16:43] <jelmer> cjwatson: Is that sufficient, or should I find a related but and subscribe ~ubuntu-sru to that as well?
[16:44] <cjwatson> I have no idea how the tracker will cope with that
[16:44] <cjwatson> you want pitti for that
[16:44] <jelmer> cjwatson: ah, thanks
[16:44] <jelmer> pitti: hi
[16:51] <seb128> jelmer, they work the reverse way
[16:52] <seb128> jelmer, ubuntu-sru doesn't do sponsoring, they review things in the queue and go back to the bug to read it and accept the upload
[16:52] <seb128> jelmer, so if you need your work to be uploaded you should subscribe ubuntu-sponsors
[16:53] <seb128> jelmer, ideally you would need a bug with the merge proposal also, the sru tracking list bugs and you need a place where testers can comment on whether the update works or not
[16:53] <cjwatson> apw: so, notwithstanding your comments in -meeting, I think at least fixing eglibc would be a pretty good plan.  how about http://paste.ubuntu.com/623518/?  tested out of context ...
[16:54] <cjwatson> (in particular I think we should resolve eglibc problems before accepting the kernel through NEW)
[16:54] <apw> cjwatson, absolutly on the NEW thing
[16:54] <apw> cjwatson, i am not sure that $(( works with 0NN as i think that switches it into octal
[16:55] <jelmer> seb128: bzr has a microrelease exception; there will usually be zero or more bug reports related
[16:55] <apw> i t
[16:55] <cjwatson> apw: I'm not relying on that
[16:55] <apw> s/^\([0-9]*\.[0-9]*\)\([^.0-9]\|$\)/\1.0\2/;
[16:56] <cjwatson> the effect of the added first sed statement is to transform 3.0-0.1 into 3.0.0-0.1
[16:56] <apw> does that not take 2.6.39 -> 2.6.039 ?
[16:56] <cjwatson> no, because [^.0-9] doesn't match in the relevant place there
[16:56] <seb128> jelmer, ok, well pitti left for the w.e already he will be back on tuesday, but from what I can say usually they need at least one bug to list on the tracker, so if your update close no launchpad bug you should open one about the new version
[16:56] <apw> ahh misses the ^, re's suck for reading
[16:56] <cjwatson> I did test that bit :)
[16:56] <seb128> jelmer, so you have at least one bug reference in the changelog for the tracker
[16:56] <cjwatson> <cjwatson@sarantium ~>$ echo $(($(echo "2.6.39-1" | sed 's/^\([0-9]*\.[0-9]*\)\([^.0-9]\|$\)/\1.0\2/; s/\([0-9]*\)\.\([0-9]*\)\.\([0-9]*\)\?.*/\1 \* 10000 + \2 \* 100 + \3/')))
[16:56] <cjwatson> 20639
[16:56] <cjwatson> <cjwatson@sarantium ~>$ echo $(($(echo "3.0-1" | sed 's/^\([0-9]*\.[0-9]*\)\([^.0-9]\|$\)/\1.0\2/; s/\([0-9]*\)\.\([0-9]*\)\.\([0-9]*\)\?.*/\1 \* 10000 + \2 \* 100 + \3/')))
[16:57] <cjwatson> 30000
[16:57] <apw> cjwatson, that look sane then yes, though there is another place it errors due to format
[16:57] <cjwatson> ok, where's that?
[16:58] <cjwatson> oh yes, I see
[16:58] <apw> cjwatson, about line 286 of the preinst
[16:58] <seb128> cjwatson, "  * desktop-o-gtk3-gnome3: ubiquity mostly converted to PyGI, though blocked on porting a custom widget (timezone map)"
[16:58] <jelmer> seb128: I have that, but do I subscribe ubuntu-sru to all the related bugs, to just the MP?
[16:58] <cjwatson> I wonder where the built-in assumptions in glibc it's referring to are
[16:59] <seb128> ev, cjwatson: dunno who is working on that but did you talk to mterry about it? he wanted to do a C library for that widget and has been discussing that upstream with the GNOME guys
[16:59] <cjwatson> seb128: I was just reporting what ev said
[16:59] <seb128> ev, cjwatson: if that's done the lib could probably just build a gir to use
[16:59] <apw> cjwatson, i was trying to find them, but ... not found as yet
[16:59] <cjwatson> apw: sysdeps/unix/sysv/linux/dl-sysdep.c
[16:59] <seb128> cjwatson, ok, I will check with ev, thanks
[16:59] <ev> ah yes, I hadn't considered that
[16:59] <ev> stupidly
[16:59] <ev> will go down that road instead
[17:00] <ev> thanks seb128
[17:00] <mterry> ev, cjwatson, seb128: upstream is going to do some sort of map library, but it likely won't have our geonames timezone completion logic.  So we can patch it in when they have something
[17:00] <cjwatson> so that looks to me as though glibc will treat 3.0 as 3.0.0
[17:00] <apw> cjwatson, that would be appropriate
[17:01] <apw> cjwatson, yeah concur that it does assume all and any part is 8 bits max, but the build only checks that 3rd
[17:01] <apw> cjwatson, so are you going to fix those two in the package ?  so i don't need to look any more ?
[17:01] <cjwatson> right.  I think it's reasonable enough for it to only check the last one, which is the only one people typically fiddle with
[17:02] <cjwatson> yeah, I think I can deal if that's OK with you, but review is good
[17:02] <apw> cjwatson, yep let me have the changes and i can review np
[17:02] <cjwatson> can't easily test it here but don't want to have to fix it twice
[17:02] <apw> i can cirtainly test it if i can figure out how to un-half install the broken version on my machine here
[17:03] <cjwatson> er, you might need to fiddle the new preinst into place in your .deb using ar and tar
[17:03] <apw> i upgraded with a 3,0-0.1 kernel installed on my oeniric and its half installed and refusing due to that change
[17:03] <apw> cjwatson, ouch ... ok
[17:03] <cjwatson> I can provide instructions once I'm finished
[17:03] <apw> where is the .deb its using in archive ? ... ok will await those :)
[17:04] <cjwatson> http://paste.ubuntu.com/623531/
[17:06] <cjwatson> make a temporary directory, cd to it, 'cp /var/cache/apt/archives/libc6_* .'
[17:06] <debfx> how do we deal with ppa packages that cause issues likes file overwrite conflicts? e.g. bug #748715
[17:07] <james_w> charlie-tca, hi, I hear that you get blank pages on status.ubuntu.com. Is that correct?
[17:09] <ogra_> james_w, do you own that ?
[17:09] <cjwatson> ar x libc6_*; gunzip control.tar.gz; tar xf control.tar; apply patch to preinst; tar rf control.tar ./preinst; ar r libc6_* control.tar.gz
[17:09] <james_w> ogra_, I'm involved
[17:09] <cjwatson> then dpkg --unpack libc6_*; dpkg --configure -a
[17:09] <cjwatson> I think that should work
[17:09] <cjwatson> WARNING NOT GENERALLY SANE
[17:09] <ogra_> james_w, do you know if there is a particular reason the arm team isnt on there ?
[17:10] <james_w> ogra_, nope
[17:10] <james_w> ogra_, in the teams list?
[17:10] <ogra_> yeah, how do i get ubuntu-armel added ?
[17:11] <james_w> ogra_, ask cjohnston for now
[17:11] <apw> cjwatson, ok on it
[17:11] <ogra_> k
[17:13] <cjwatson> apw: (this results in a control.tar.gz with two preinst files, but dpkg uses the second which is what we need here)
[17:14] <apw> cjwatson, well its progressing
[17:15] <apw> here goes nothing
[17:18] <apw> cjwatson, ok those fixes look fine to me, test fine in isolation and worked to allow me to finish the package installation
[17:18] <cjwatson> excellent, forwarding to Debian and will upload
[17:19] <apw> cjwatson, i will go look at PS which is producing much vile whining
[17:19] <cjwatson> PS?
[17:19] <cjwatson> ah, procps
[17:21] <apw> yeah, ps and top are both whining same message
[17:21] <apw> any idea where the lightdm/gdm choice is made ?
[17:23] <apw> ahh found it /etc/X11/default-display-manager
[17:40] <apw> anyone got working networking on oneiric ?
[17:41] <tumbleweed> yes
[17:46] <apw> cjwatson, procps seems to be easy to fix, simple one line change.  I've pushed a bzr branch with it on, but as its a 3,.0 (quilt) we're back to the question as to whether one should have the .pc etc in there; perhaps you could review: lp:~apw/procps/kernel-version-fix
[17:47] <cjwatson> apw: there's no question, you match whatever the branch currently does
[17:47] <apw> cjwatson, well its the importer, so it does what it wants
[17:47] <cjwatson> yes.  so match it.
[17:48] <cjwatson> I think your commit matches its behaviour except that it doesn't normally add the .timestamp file, IIRC
[17:48] <cjwatson> (for better or worse)
[17:48] <cjwatson> and actually it doesn't add .pc/.quilt_patches or .pc/.quilt_series either
[17:48] <apw> ahh ok, i'll delete those
[17:49] <cjwatson> I think that's a discrepancy between what happens when you apply patches with quilt and what happens when dpkg-source unpacks the package on a system without quilt installed
[17:49] <montaj> hey guys
[17:49] <montaj> i have a question regarding bug #791467
[17:49] <montaj> it appears that gcdmaster is needed to build cdrdao
[17:49] <cjwatson> apw: otherwise looks fine
[17:49] <montaj> what is the way to procees in this case, attach a patch of the control file to the bug or build a new package and ask somebody to sponsor it?
[17:52] <montaj> I would very grateful if somebody could point me on how to proceed to fix the regression
[17:53] <apw> cjwatson, ok updated with those removed, perhaps you could do the honours if it looks ok
[18:10] <ScottK> montaj: If you know how to fix it, attach a patch and then subscribe the ubuntu-sponsors team to the bug and someone will review it.
[18:31] <kenvandine> @pilot out
[18:47] <cjwatson> apw: merged, thanks, uploading (eglibc also uploaded a while back)
[18:47] <cjwatson> binaries will take a bit
[18:49] <cjwatson> apw: heh, you forgot to add debian/patches/ubuntu-handle-short-kernel-versions.patch - I'll fix it up
[18:49] <cjwatson> and the change to debian/patches/series too
[18:52] <cjwatson> apw: fixed up and uploaded now
[18:59] <apw> cjwatson, i am hopless sometimes, thanks
[20:17] <chrisccoulson> directhex, i just tried building moonlight here, and it fails right at the end. not sure if you can provide any insight for this error:
[20:17] <chrisccoulson> dh_clideps: Could not resolve moduleref: moon for: mscorlib.dll!
[20:17] <chrisccoulson> or anyone else for that matter :)
[20:18] <directhex> chrisccoulson: hm. probably a use-case we didn't consider for cli-common 0.8
[23:36] <ohsix> hm is something else being done with firefox this (natty) cycle? ff5 beta just showed up
[23:38] <micahg> ohsix: that's in -proposed and natty will follow the new mozilla release cycle immediately
[23:38] <ohsix> ok cool
[23:39] <cjwatson> ohsix: http://askubuntu.com/questions/48035/why-is-natty-proposed-suggesting-an-upgrade-to-a-beta-version-of-firefox
[23:39] <ohsix> will it leave proposed after the release or is it just going to soak a bit like most things in -proposed
[23:40] <micahg> ohsix: yes, it will actually be replaced with the release build next week sometime and migrate to -updates/-security on release day (hopefully)
[23:40] <ohsix> ok cool ya that's what the post said; thanks guys