| === nhandler_ is now known as nhandler | ||
| geser | someone from ubuntu-release around? I want to ask if it's still enough time to start a OCaml "transition" (new upstream version) with FF only a week away. From a look at the (long) list of affected packages mostly only no-change rebuild will be necessary and only a few syncs. | 00:03 |
|---|---|---|
| geser | (see bug #519199) | 00:04 |
| ubottu | Launchpad bug 519199 in ocaml "Sync ocaml 3.11.2-1 (main) from Debian sid (main)" [Undecided,Triaged] https://launchpad.net/bugs/519199 | 00:04 |
| Hellow | I would say it's possible; Then again, I am far from an expert on the topic :). | 00:04 |
| slangasek | geser: yes, that's possible | 00:05 |
| geser | slangasek: getting FF exceptions (when necessary) won't be a problem then? | 00:06 |
| slangasek | shouldn't be, no | 00:06 |
| geser | thanks | 00:06 |
| StevenK | geser: If you need help, I'm happy to do so | 00:11 |
| geser | StevenK: I'll certainly need sponsoring for the packages in main, thanks for the offer | 00:13 |
| StevenK | geser: If it's just rebuilds I can do them, too | 00:24 |
| geser | StevenK: mostly rebuilds as we have the same version as Debian testing/unstable. see the page from dmentre for the status and the rounds: http://bentobako.org/ubuntu-ocaml-status/transition_monitor/ocaml_transition_monitor.html | 00:30 |
| geser | I guess dmentre will monitor it and announce when the next round can be started like he did during the last transition | 00:31 |
| arakthor | hi | 00:35 |
| arakthor | I'm looking to help by developing with ubuntu or related projects on my spare time. I chekced the wiki and it looks like I can start trying packaging and fixing bugs. Which sort of bugs would be best to start looking at? | 00:36 |
| arand | arakthor: #ubuntu-motu might be a better starting point. | 00:36 |
| arakthor | arand, thank you for the suggestion. the wiki seemed to say the motu was more appropriate for people with more packaging experience; however, I will look there. | 00:37 |
| persia | arakthor: What sort of packages interest you? | 00:41 |
| persia | arand: Why is -motu a better starting point? Does it not depend on people's interest? | 00:42 |
| arakthor | hi persia, from my perspective I usually enjoy programming for low-level applications (on embedded platforms anyway - but I'm not an algorithm wizard). I also would like to learn more about security. I enjoy being able to see the changes from my code so desktop and utilities are probably my best starting point. | 00:45 |
| arand | persia: just figured it a generally more active channel, and as a *startup* I though it would be more helpful, just as a channel... | 00:46 |
| persia | arakthor: #ubuntu-desktop is the right channel for desktop stuff, and #ubuntu-hardened for security. We don't currently have much embedded stuff, although "embedded" is a funny term, and there's lots of Ubuntu that can run on very small hardware (as long as there's a couple gig flash). | 00:46 |
| arakthor | most of my experience with embedded has been on hardware that cannot run ubuntu; usually with no OS or uCOS | 00:47 |
| persia | Work on the low-level applications tends to happen here, but that's usually left to our most expert developers: I'd recommend working in other areas until you've gotten some experience with how we work. | 00:47 |
| persia | arand: I guess I'm oversensitive: we used to force all new contributors to work with MOTU first, but now we're working on enabling interest-based groups to do stuff instead of forcing MOTU->core. As a result, I prefer to send people to channels that interest them, rather than pointing at MOTU who usually end up telling people to fix FTBFS or help with transitions and the like, which doesn't interest everyone. | 00:48 |
| persia | arakthor: That's stuff we just can't handle :) | 00:49 |
| persia | arakthor: There are ports to powerpc and armel though, some of which can run on devices some people consider "embedded". | 00:49 |
| arakthor | yeah, not as hard anymore. I have maemo on my phone and that's rather nice in some ways. | 00:50 |
| persia | and hardly "embedded" :) | 00:50 |
| Caesar | slangasek: ping | 00:50 |
| arakthor | well persia, thank you for the pointers. I will try to talk with somewhere there in the next day or two. have to go study now though. have a good night (or day; or morning) | 00:51 |
| persia | arakthor: Good luck. | 00:52 |
| lifeless | ev: https://code.edge.launchpad.net/~mbp/usb-creator/477529-cruzer/+merge/18311 please comment. | 01:13 |
| lifeless | Fixes Are Good | 01:13 |
| Caesar | bdmurray: I'm not exactly sure why bug #519119 hasn't been automatically marked as fixed | 01:39 |
| ubottu | Launchpad bug 519119 in autofs "Transitional packages need some reworking" [Low,Triaged] https://launchpad.net/bugs/519119 | 01:39 |
| Caesar | The fact that it got uploaded by zul doesn't seem to have been noted on the bug | 01:40 |
| persia | That would happen if the .changes file didn't have the Launchpad-bugs-fixed: header. | 01:40 |
| Caesar | Oh | 01:40 |
| Caesar | So zul did something wrong when he built the package with my debdiff? | 01:41 |
| persia | Last upload seems to be 14 weeks ago, according to https://launchpad.net/ubuntu/+source/autofs | 01:41 |
| persia | Your patch appears to have the correct notation. | 01:42 |
| Caesar | Hmm, ogra was pointing me at something yesterday that indicated two uploads | 01:42 |
| * Caesar consults rmadison | 01:42 | |
| Caesar | rmadison says it's at 5.0.4-3.1ubuntu4 | 01:42 |
| persia | For binaries, but not for source. | 01:42 |
| * persia is confused | 01:42 | |
| Caesar | autofs5 | 5.0.4-3.1ubuntu4 | lucid | source, amd64, i386 | 01:42 |
| Caesar | That says to me the whole box and dice | 01:43 |
| ajmitch | autofs vs autofs5 | 01:43 |
| persia | the bug is against autofs, not autofs5 | 01:43 |
| Caesar | Ah | 01:43 |
| Caesar | It's all messy, the autofs5 source package is taking over some of the autofs(4) packages | 01:43 |
| persia | Is the autofs source still needed with the presence of the autofs5 source? If not, it may be worth filing a removal bug. | 01:43 |
| persia | Only some, or all? | 01:44 |
| Caesar | No, it's no longer needed | 01:44 |
| persia | So there are transition packages for all the binaries produced by autofs source? | 01:44 |
| Caesar | Yes | 01:44 |
| Caesar | There are now | 01:44 |
| persia | Then yeah, file a removal bug :) | 01:44 |
| Caesar | Will do | 01:44 |
| * persia can't ACK it, but maybe zul will | 01:44 | |
| Caesar | I'll just bump this bug over to autofs5 for anatomical correctness | 01:45 |
| persia | But anyway, regarding the specifics of bug 519119 : ideally the bug task would have been changed to be against the autofs5 source if that was where it was being fixed. | 01:45 |
| ubottu | Launchpad bug 519119 in autofs5 "Transitional packages need some reworking" [Low,Triaged] https://launchpad.net/bugs/519119 | 01:45 |
| persia | And if that was done, then the bug should have been automatically closed by the upload. | 01:46 |
| Caesar | Yeah I think I was a bit confused when I filed it | 01:46 |
| Caesar | Okay, so I'll just mark the bug as fixed now? | 01:46 |
| persia | No worries. Just mark it Fix Released manually, and note the package source and version that was uploaded to fix it. | 01:46 |
| persia | Yes. | 01:46 |
| Caesar | Done | 01:46 |
| Caesar | Now to file the removal bug for autofs (source) | 01:47 |
| persia | Any other questions about how this happened that I can answer, or was the above clear enough? | 01:47 |
| Caesar | persia: no, that was all very helpful, thanks | 01:47 |
| persia | Cool. | 01:47 |
| Caesar | Does https://bugs.launchpad.net/ubuntu/+source/engine-pkcs11/+bug/512368 just need a sync request? | 02:09 |
| ubottu | Ubuntu bug 512368 in engine-pkcs11 "Sync request: engine_pkcs11 0.1.8-2 from debian unstable (incoming)" [Wishlist,New] | 02:09 |
| Caesar | It's fixed in Debian | 02:09 |
| persia | Caesar: That *is* a sync request. | 02:11 |
| persia | It's just waiting on an archive-admin to process it. | 02:11 |
| ajmitch | but no sponsors subscribed, just the archive admins | 02:11 |
| persia | fabricesp doesn't count as a sponsor? | 02:12 |
| persia | Oh, subscribed. | 02:12 |
| persia | But he subscribed the archive-admins, so it oughtn't matter. | 02:12 |
| ajmitch | even with the status still at New? | 02:14 |
| persia | Hrm. That's a good question. | 02:14 |
| persia | StevenK: As a procedural matter, would an archive admin consider something actionable if the archive-admins were subscribed by a developer with upload permission to the affected package, but there wasnt an explicit ACK, and the bug state was "New"? | 02:15 |
| === dendro-afk is now known as dendrobates | ||
| === dendrobates is now known as dendro-afk | ||
| crypt-0 | i have a question about kernel module | 02:36 |
| twb | Am I mad? It looks like ubuntu-keyring STILL isn't using jetring | 02:49 |
| crypt-0 | where can i check on the status of a kernel module? i want to see if a specific module is considered "stable" yet. | 02:52 |
| === JFo is now known as JFo-afk | ||
| NCommander | Can any GCC guru shed some light on https://bugs.edge.launchpad.net/ubuntu/+source/openoffice.org/+bug/417009? | 03:59 |
| ubottu | Ubuntu bug 417009 in openoffice.org "all openoffice apps die in 'com::sun::star::ucb::InteractiveAugmentedIOException' on armel in karmic" [High,Confirmed] | 03:59 |
| NCommander | I don't know enough about GCC's internals to understand if OpenOffice.org is goofing its test up or not, or theres a regressionin GCC | 04:00 |
| === JamieBen1ett is now known as JamieBennett | ||
| slangasek | Caesar: pong | 04:37 |
| Caesar | slangasek: hi | 05:28 |
| Caesar | I wanted to float the possibility of a import freeze exception for Puppet and Facter | 05:29 |
| StevenK | Caesar: We have stopped automatic syncs, but manual syncs are still permitted until FF. | 05:31 |
| StevenK | Unless we've changed it for Lucid. | 05:32 |
| === dendro-afk is now known as dendrobates | ||
| crypt-0 | anyone have info why the cryptsetup package inst upgraded to the 1.1.0? | 05:38 |
| crypt-0 | its still using a release candidate for Lucid | 05:38 |
| crypt-0 | the final has been released at http://code.google.com/p/cryptsetup/ | 05:38 |
| Caesar | StevenK: ok thanks | 05:48 |
| pitti | Good morning | 06:40 |
| === kenvandine_ is now known as kenvandine | ||
| === tkamppeter_ is now known as tkamppeter | ||
| === nenolod_ is now known as nenolod | ||
| dholbach | good morning | 08:11 |
| dholbach | pitti: is it expected that a jockey window pops up during a ubiquity installation? | 09:11 |
| dholbach | (with an empty window) | 09:11 |
| dholbach | pitti: http://people.canonical.com/~dholbach/Bildschirmfoto-QEMU.png | 09:13 |
| pitti | re | 09:53 |
| pitti | dholbach: I fixed that yesterday | 09:53 |
| pitti | dholbach: is that jockey 0.5.7? | 09:53 |
| dholbach | pitti: it's yesterday's image, so yeah, it probably wasn't fixed back then | 09:53 |
| pitti | ah, *phew* :) | 09:54 |
| ttx | cjwatson: ping about some eucalyptus-udeb magic... | 10:07 |
| ttx | cjwatson: to support the case where there are multiple CCs (clusters) on a single network, spec says SC / NC should advertise which one (ideally by cluster name) they want to join | 10:09 |
| ttx | cjwatson: Ideally we would preseed eucalyptus/cluster-name in the SC or NC installs based on discovery | 10:10 |
| ttx | cjwatson: I'm just unsure how to best plug that into eucalyptus-udeb.postinst... At that point only the NC has a cluster selection, and it's IP address only. | 10:11 |
| * ttx wonders if multiple clusters on a single network really make any sense. | 10:16 | |
| smoser | i'm starting a new package, trying to use bzr distributed development mode | 10:30 |
| smoser | how can i do what merge-upstream-release would do for the initial packaged release | 10:30 |
| smoser | james_w, ^? | 10:30 |
| smoser | it fails with : | 10:31 |
| smoser | bzr: ERROR: Unable to find the tag for the previous upstream version, 1.1.0, in the branch: upstream-1.1.0 | 10:31 |
| siretart | seb128: re: my seahorse-plugins upload: I did use bzr, and I did push my work to lp:ubuntu/seahorse-plugins | 10:57 |
| seb128 | siretart:... | 11:00 |
| siretart | was that wrong? | 11:00 |
| seb128 | siretart: apt-get source tell you what to use | 11:00 |
| seb128 | or look to control | 11:00 |
| seb128 | yes | 11:00 |
| seb128 | it's under ubuntu-desktop with the debian dir only in bzr | 11:00 |
| siretart | oh, indeed. my bad, I'm sorry | 11:00 |
| seb128 | siretart: np, I've fixed it yesterday since I had an another upload to do | 11:01 |
| siretart | hm. I generally dislike seperating debian/ from the upstream source. | 11:01 |
| siretart | in this case, it wouldn't have mattered since I didn't touch upstream code | 11:02 |
| siretart | so I was quite happy with the branch lp:ubuntu/seahorse-plugins | 11:02 |
| siretart | seb128: speaking of seahorse: do you know someone who could be bribed with an smartcard reader and a gpg smartcard to (finally) implement support for that in seahorse-agent? | 11:03 |
| seb128 | siretart: not really | 11:04 |
| siretart | seb128: I notice that the seahorse-plugins packaging branch has a root directoy that contains only a subdirectory. can you explain my why not moving the contents of that subdirectoy one level up? | 11:06 |
| seb128 | because that's how you use debian dir only with bzr-buildpackage | 11:07 |
| seb128 | it will get the tarball and copy the debian dir over and build | 11:07 |
| siretart | bzr-buildpackage certainly doesn't require it | 11:08 |
| seb128 | that's how we always did debian dir in vcs for gnome | 11:08 |
| seb128 | since debian svn for pkg-gnome to current ubuntu-desktop workflow | 11:08 |
| seb128 | nobody questionned it before ;-) | 11:09 |
| siretart | I'm questioning this practice since years | 11:09 |
| seb128 | I find it handy to have the debian dir being named debian | 11:09 |
| siretart | for svn, it makes more sense because you have partial checkouts | 11:09 |
| seb128 | rather than having ubuntu/ being the debian dir | 11:09 |
| seb128 | well with current scheme you can cp debian over to a source | 11:09 |
| siretart | for bzr, I consider it utterly inconvenient and unnecessary | 11:09 |
| seb128 | without having to mkdir debian | 11:09 |
| seb128 | and cp ubuntu... | 11:10 |
| siretart | well, if the packaging was toplevel, you could just *checkout* in an upstream source directory | 11:10 |
| siretart | currently you have to clumsily fiddle around with cp/mv to have things in the right place | 11:10 |
| seb128 | no you couldn't | 11:12 |
| seb128 | since the directory is named ubuntu, not debian | 11:12 |
| siretart | I think I'll continue using the lp:ubuntu/$package branches and mail you the diff | 11:12 |
| seb128 | you would get ubuntu with the debian dir content | 11:12 |
| siretart | of course you can: 'bzr get :~ubuntu-desktop/seahorse-plugins/ubuntu debian' | 11:12 |
| seb128 | siretart: please don't, open a sponsoring request rather than private emailing me | 11:12 |
| siretart | of course you can: 'bzr get lp:~ubuntu-desktop/seahorse-plugins/ubuntu debian' | 11:12 |
| seb128 | if you don't want to update the official bzr | 11:12 |
| siretart | that will create the branch in a subdirectory called 'debian' | 11:13 |
| Laney | is there something like svn-do for these branches? | 11:13 |
| frafu | Hi pitti, do you have a minute? Should the version of python-distutils-extra not be the same as the version of DistUtilsExtra.auto? | 11:13 |
| seb128 | Laney, what does svn-do do again? | 11:13 |
| Laney | starts a subshell with the upstream source + debian dir | 11:14 |
| frafu | https://bugs.launchpad.net/ubuntu/+source/python-distutils-extra/+bug/520548 | 11:14 |
| ubottu | Ubuntu bug 520548 in python-distutils-extra "DistUtilsExtra.auto.__version__ gives wrong version" [Undecided,New] | 11:14 |
| Laney | useful for doing patches, for exmaple | 11:14 |
| seb128 | Laney, bzr bd-do | 11:14 |
| Laney | cool | 11:14 |
| siretart | seb128: opening sponsoring request? that sounds like an awful lot of burocracy and added latencies when I could also just upload it. this way my patch went into the official branch in hours (without attribution in the bzr log, but still) | 11:14 |
| seb128 | siretart: not the official one | 11:15 |
| seb128 | one which we are not using | 11:15 |
| frafu | Or does anybody else know the answer? | 11:15 |
| seb128 | which break next upload since the official vcs is outdated | 11:15 |
| Laney | seb128: you can have those lp:ubuntu/xxx branches update to the ~ubuntu-desktop ones I think | 11:15 |
| Laney | to point to the^ | 11:15 |
| siretart | Laney: that is what I was using | 11:15 |
| seb128 | Laney, we don't have a full source there | 11:15 |
| seb128 | would that work too? | 11:15 |
| Laney | is that a requirement? | 11:15 |
| Laney | I don't know | 11:15 |
| seb128 | james_w, ^ | 11:15 |
| seb128 | siretart: you are just breaking other people package and workflow by doing that | 11:16 |
| james_w | it is a requirement | 11:16 |
| seb128 | siretart: either update the official bzr or ask for sponsoring | 11:16 |
| siretart | I thought for UDD lp:ubuntu/$package was 'official' | 11:17 |
| siretart | I'll revisit the ubuntu wiki, need to run now, though. | 11:18 |
| frafu | Does anybody know who I should contact to not hide by default the menu items of the onscreen keyboard onboard that is part of the Ubuntu distribution? | 11:18 |
| seb128 | siretart: dunno what is official or not but we don't use those for desktop components | 11:18 |
| seb128 | see control file or apt-get source for the vcs to use | 11:19 |
| cjwatson | ttx: maybe the preseed file generated on the CC (debian/eucalyptus-udeb.finish-install) should set cluster-name to match the name of that cluster | 11:29 |
| === frafu is now known as frafu_afk | ||
| ttx | cjwatson: that wouldn't solve it for the SC (which downloads from the CLC)... | 11:29 |
| cjwatson | ttx: it may well be a bug that SC installation doesn't do CC selection if it found more than one | 11:30 |
| ttx | cjwatson: I'm testing a fix right now | 11:30 |
| ttx | cjwatson: question: I'm using netboot for testing the latest crack, but apparently eucalyptus-udeb is downloaded before apt-setup/local0 takes effect | 11:31 |
| cjwatson | correct | 11:31 |
| cjwatson | apt-setup doesn't affect udeb installation anyway | 11:31 |
| cjwatson | apt => deb, anna => udeb | 11:31 |
| ttx | cjwatson: is there any way to preseed additional repositories in a way that would make it retrieve udebs from an alternate repo ? | 11:31 |
| ttx | I'm trying to netboot from my localmirror + a repo that has my eucalyptus WIP | 11:33 |
| cjwatson | ttx: you can't acquire udebs from more than one repo; the acquisition code isn't smart enough | 11:33 |
| cjwatson | you can change it to acquire from just a single repo | 11:33 |
| cjwatson | by setting mirror/http/hostname (and if necessary mirror/http/directory) on the kernel command line, I think | 11:34 |
| ttx | cjwatson: arh. | 11:34 |
| cjwatson | ttx: to fetch eucalyptus-udeb from somewhere else, I just use this trick: | 11:34 |
| cjwatson | d-i preseed/early_command string wget http://url/to/your/package && udpkg --unpack eucalyptus-udeb_whatever_whatever.udeb | 11:35 |
| cjwatson | and then boot with url=http://url/to/that/preseed.cfg | 11:35 |
| ttx | cjwatson: nice | 11:35 |
| ttx | I'll try that, thanks. | 11:35 |
| === MacSlow is now known as MacSlow|pizza | ||
| soren | Oh, we've dropped tracker by default? | 11:57 |
| soren | I suppose this could be years ago. It's been a while since I've done a regular desktop install :=) | 11:57 |
| seb128 | soren, since hardy | 11:58 |
| * soren chuckles | 11:58 | |
| soren | Ok :) | 11:58 |
| soren | Did we replace it with something else? | 11:58 |
| seb128 | no | 11:59 |
| soren | Alright. | 11:59 |
| seb128 | we decided that it was not useful enough to justify the io cost | 11:59 |
| seb128 | linux is not good at handling io load nicely | 11:59 |
| * soren tends to agree | 11:59 | |
| soren | I was just curious to see that state of it and was surprised it wasn't installed. No worries at all. | 11:59 |
| === MacSlow|pizza is now known as MacSlow | ||
| ttx | cjwatson: testing the early_command trick: I get "Menu item 'eucalyptus-udeb' selected" before 'download-installer', so eucalyptus-udeb.postinst fails with missing avahi lib | 13:13 |
| cjwatson | you might need to add in some manual wget/udpkg pairs for dependent udebs | 13:13 |
| cjwatson | bit of a hack | 13:13 |
| ttx | cjwatson: no way to run 'download-installer' module before 'eucalytpus-udeb' ? | 13:14 |
| cjwatson | dunno, sorry, can't think about this right now | 13:15 |
| ttx | cjwatson: no pb :) | 13:15 |
| cjwatson | don't see why udpkg --unpack would affect menu item ordering, you didn't change it to udpkg -i did you? | 13:15 |
| ttx | no... | 13:15 |
| === jml is now known as jml-afk | ||
| === jml-afk is now known as jml | ||
| === dendrobates is now known as dendro-afk | ||
| === dendro-afk is now known as dendrobates | ||
| === _iron is now known as i_ron | ||
| ttx | cjwatson: fyi, looks like this works: early_command=anna net-retriever && wget eucalyptus-udeb... && && udpkg --unpack eucalyptus-udeb... | 14:17 |
| pitti | jdstrand: would be grand if you could do the udisks source NEW today; it's just an upstream product/source package renaming, not really a new thing | 14:40 |
| jdstrand | pitti: ack | 14:41 |
| pitti | jdstrand: thanks (just uploaded, should hit the queue in 2 mins) | 14:43 |
| === dendrobates is now known as dendro-afk | ||
| === dendro-afk is now known as dendrobates | ||
| jdstrand | k | 14:45 |
| === JFo-afk is now known as JFo | ||
| smoser | Keybuk, around ? I'm wondering if you're expecting to address bug 504883 in near term. | 14:59 |
| ubottu | Launchpad bug 504883 in udev "job with "mounted MOUNTPOINT=/ and net-device-up IFACE=eth0" blocks boot" [Medium,Triaged] https://launchpad.net/bugs/504883 | 14:59 |
| pitti | jdstrand: thanks, that was fast! | 15:05 |
| jdstrand | pitti: ask and ye shall receive :) | 15:05 |
| * persia watches for a wild flurry of requests | 15:06 | |
| pitti | I want a pony! | 15:06 |
| pitti | actually, can I _give_ you a second of boot time? with getting rid of that, we'd be almost there :) | 15:07 |
| jdstrand | hehe | 15:15 |
| Keybuk | cjwatson: this grub-install issue is odd | 15:21 |
| Keybuk | so I press enter, and it prompts me what to do (including choose a different device) | 15:22 |
| Keybuk | I choose /dev/sda | 15:22 |
| Keybuk | it goes back, whirrs, and tells me that grub-install (hd0) failed again | 15:22 |
| Keybuk | smoser: bugs get addressed after FF | 15:26 |
| Keybuk | I have a bunch of updates before FF I want to do | 15:26 |
| Keybuk | then I'll fix bugs | 15:26 |
| Keybuk | because I'm sure my updates will cause lots of new bugs :p | 15:26 |
| Keybuk | (and may even fix that one anyway) | 15:26 |
| smoser | Keybuk, fair enough. my interest in this one is that when i then move cloud-init to running much earlier in the boot process, i'll likely have bugs myself. | 15:27 |
| smoser | so sooner rather than later would be nice | 15:27 |
| Keybuk | smoser: though I can't remember what solution to that one we decided | 15:28 |
| smoser | i think its a bug in udev and then those rules "should work", per slangasek | 15:28 |
| Keybuk | was that just the bug where the event went missing? | 15:28 |
| cjwatson | Keybuk: unfortunately my response to you is approximately the same as your response to smoser, because I have about three hours of work time left before FF :-/ | 15:28 |
| === asac_ is now known as asac | ||
| Keybuk | cjwatson: that's fine ;) | 15:28 |
| smoser | Keybuk, right, missing event | 15:29 |
| Keybuk | cjwatson: obv it's critical for alpha 3 since you can't actually install right now ;) | 15:29 |
| Keybuk | but I can run grub-install by hand :p | 15:29 |
| cjwatson | Keybuk: I never did manage to reproduce your bug, but I only had a chance to try it through once in manual mode | 15:29 |
| cjwatson | Keybuk: manual mode worked fine for me ... | 15:29 |
| Keybuk | cjwatson: auto mode fails every time for me | 15:29 |
| Keybuk | even on a usb key with me being the chicken | 15:29 |
| cjwatson | oh, even auto mode with no preseeding? | 15:30 |
| Keybuk | right | 15:30 |
| cjwatson | *that* I can probably set up quickly | 15:30 |
| Keybuk | that's how I know it failed when I got to choose a different disk | 15:30 |
| Keybuk | I don't remember getting that choice with preseeding | 15:30 |
| cjwatson | though it could be related to using a USB key of course | 15:30 |
| cjwatson | my tests are in KVM with one disk, at the moment | 15:30 |
| LaserJock | superm1: around? | 15:30 |
| Keybuk | could be, though the automated stuff is NFS | 15:31 |
| cjwatson | hm | 15:31 |
| cjwatson | grub-installer shouldn't notice that | 15:31 |
| Keybuk | right | 15:31 |
| === mathiaz_ is now known as mathiaz | ||
| cjwatson | ScottK: do you know where Lucas' rebuild test for foundations-lucid-supportable-binaries is? | 16:12 |
| cjwatson | ScottK: I'm sure I could do some quick analysis of it if that's what's required to unblock this spec | 16:12 |
| persia | cjwatson: lucas just posted a new rebuild test : https://lists.ubuntu.com/archives/ubuntu-devel/2010-February/030230.html | 16:14 |
| persia | cjwatson: From what I've heard (although this may not be complete), the idea is to try to get the number as low as possible, and then start filing removals later. | 16:15 |
| cjwatson | persia: thanks. we should prepare the method for getting the list in advance, though | 16:16 |
| cjwatson | because it isn't just Lucas' list; it's anything in Lucas' list that hasn't been otherwise rebuilt since karmic | 16:16 |
| persia | cjwatson: Ah, so we need to compare against http://qa.ubuntuwire.com/multidistrotools/unchanged/unchanged_since_karmic | 16:17 |
| cjwatson | well, or the trivial python thing I have to do the same test | 16:17 |
| cjwatson | but sure | 16:17 |
| persia | heh, that works too, but doesn't have a handy URL :) | 16:18 |
| superm1 | LaserJock, what's up? | 16:19 |
| cjwatson | lp:~cjwatson/+junk/suite-diff | 16:19 |
| LaserJock | superm1: I just got bit by bug #506816 | 16:28 |
| ubottu | Launchpad bug 506816 in dkms "wl missing after Karmic -> Lucid upgrade" [High,Confirmed] https://launchpad.net/bugs/506816 | 16:28 |
| superm1 | LaserJock, cool! so hopefully you can help figure out the root cause :) | 16:29 |
| LaserJock | superm1: I saved the /var/lib/dkms/bcmwl directory and did the dpkg-reconfigure | 16:29 |
| LaserJock | superm1: what all do you need? | 16:30 |
| superm1 | LaserJock, there is a make.log in there for the kernel that it didnt build on hopefully | 16:30 |
| LaserJock | superm1: the only kernel dir is for the Karmic kernel | 16:30 |
| LaserJock | superm1: I have a 5.10.91.9+bdcom dir and kernel-2.6.31-19-generic-i686 | 16:31 |
| superm1 | LaserJock, ooh weird. | 16:32 |
| persia | Could it potentially be that it built for the *running* kernel, rather than the newly installed kernel? | 16:33 |
| james_w | smoser: hey, you can use bzr dh_make from lp:bzr-builddeb or the upload I will be doing today | 16:33 |
| smoser | james_w, so heres what i did... tell me if i should bothe rwith dh_make | 16:33 |
| superm1 | persia, i wouldnt suspect so at least, because the /etc/kernel/postinst.d scripts are called with the argument of the kernel to process | 16:33 |
| superm1 | LaserJock, but it wouldnt hurt to run modinfo on the kernel module in that bcmwl directory to see if its built against the proper kernel | 16:34 |
| smoser | bzr init; mkdir debian; bzr add debian; (add some basic debian dir, with version 0.0) ; bzr add debian; bzr commit ; bzr tag upstream-0.0 -r 1; bzr merge-upstream | 16:34 |
| smoser | that seems to work with the only exception that i had to 'bzr resolve debian' | 16:35 |
| === dendrobates is now known as dendro-afk | ||
| LaserJock | superm1: modinfo gives me: vermagic: 2.6.31-19-generic SMP mod_unload modversions 586 | 16:36 |
| tseliot | slangasek: do we include plymouth in the initramfs? | 16:36 |
| slangasek | tseliot: not unless we have to (cryptsetup) | 16:37 |
| tseliot | slangasek: ok, so things should work without an initramfs, right? Provided that we have a framebuffer device and kms | 16:38 |
| superm1 | LaserJock, well can you post the tgz of your /var/lib/dkms/bcmwl directory prior to dpkg-reconfigure'ing to the bug and this information so far from IRC. I dont have any other ideas off hand though unfortunately right now | 16:38 |
| tseliot | slangasek: I mean by getting rid of the initramfs (not that I want to do that in Lucid but it may come in handy for oem) | 16:39 |
| superm1 | slangasek was there a deliberation about whether it will be included in the casper case, or is that still up for discussion? | 16:40 |
| ogra | it should efinately stay in casper ... unless we speed it up a lot | 16:41 |
| superm1 | i've currently got some tools that would be dependent upon that, but could possibly be refactored otherwise | 16:41 |
| superm1 | ogra, well casper should be significantly faster thanks to JamieBennett's recent changes | 16:42 |
| ogra | not on arm though | 16:42 |
| ogra | he cut of a third from the bootptocess ... but thats not much with 1.5min | 16:43 |
| smoser | james_w, does the above look not ok ? | 16:43 |
| james_w | smoser: that works I guess | 16:43 |
| james_w | it gives you a slightly odd branch in that you will have two roots, but it's not illegal to have that | 16:44 |
| superm1 | ogra, well I suppose perhaps the decision of whether or not plymouth is in the initramfs could also be arch dependent though, so x86 doesn't get it, but arm does | 16:44 |
| superm1 | ogra, but what's the slowest piece now on arm? is there still a lot of room for improvement you think? | 16:45 |
| ogra | there likely is but not in lucid | 16:45 |
| cjwatson | plenty of x86 casper boots are still clearly slow enough to require a splash screen, and I don't anticipate that changing given typical CD read speeds | 16:45 |
| ogra | and indeed it could be based on arch detection | 16:45 |
| cjwatson | arch detection is a bit of a red herring there I think | 16:45 |
| cjwatson | you're right that it could, but I don't think it should | 16:46 |
| ogra | yeah, but technically you could do that | 16:46 |
| ogra | right | 16:46 |
| superm1 | ogra, for lucid would ripping the extra scripts out that aren't used at all on arm help? Like moving the scripts that are say for UNE to a UNE casper package and those for KDE to a KDE casper package. I'm not sure how slow individual invocations of sh are though, so that might not do too much | 16:48 |
| ogra | no, there are more essential bits ... like locale-gen running at boottime | 16:49 |
| JamieBennett | superm1: take a look at http://www.linuxuk.org/2010/02/ubuntu-live-cds-now-33-faster/ | 16:49 |
| JamieBennett | has some bootcharts | 16:49 |
| ogra | given that we only run english by default and have no language selection on the image boot i'd vote for pregenerated en_GB/en_US for armel images, but that needs proper speccing and discussion, so nothing for lucid | 16:50 |
| persia | ogra: But surely that's just because there's no gfxboot equivalent, no? | 16:51 |
| superm1 | i'd think that would be useful across the board to have pregenerated english, and if other locales are chosen at language selection to generate them | 16:51 |
| ogra | persia, right | 16:51 |
| ogra | superm1, ++, lets have a spec at next UDS for that :) | 16:52 |
| cjwatson | superm1: as English speakers, I'm sure we both think that ;-) | 16:52 |
| superm1 | hehe | 16:52 |
| JamieBennett | ogra: superm1: agreed | 16:52 |
| cjwatson | but I always have to double-check my thinking every time that sort of thing crosses my mind | 16:52 |
| cjwatson | and I can never actually justify it to myself | 16:52 |
| * persia would think selecting the "top 5" locales would make more sense, perhaps following similar logic to that used to select langpacks to go on CDs, but can wait until May to be particularly interested | 16:52 | |
| ogra | well, having them there and only generate additional langs surely doesnt do any harm | 16:52 |
| ogra | apart from costing a little space | 16:53 |
| cjwatson | 3MB for all English locales right now; although I'm not clear on why en_AG is so big | 16:54 |
| superm1 | cjwatson, well if you try to look for the default case of what automatically times out if no selection is picked, and you try to optimize to that scenario at least. then you make a conscious decision that deviating the default scenario increases boot time | 16:54 |
| ogra | another issue we often have are broken board clocks that only are right after first boot .... fallout of that is that apt gets unhappy about the gpg keys somehow | 16:54 |
| ogra | for the pool dir on the image ... | 16:54 |
| cjwatson | superm1: and I think that goes against our commitment to give the best service we can to localised users; it seems like sloppy thinking to me, honestly | 16:54 |
| cjwatson | it's only justifiable if it's really a very tiny amount of space indeed, so perhaps just generating en_US.UTF-8 wouldn't be so bad | 16:55 |
| ogra | yeah | 16:55 |
| cjwatson | but otherwise we're crowding out other useful stuff that could go on the CD (including translations!) for the sake of making English faster | 16:55 |
| ogra | and indeed defaulting to that if no selection exists | 16:55 |
| * ogra would be happy with an arch specific hack for arm though | 16:56 | |
| ogra | we have lots of space atm | 16:56 |
| cjwatson | $ du -cs /usr/lib/locale/en_US.utf8 | 16:56 |
| cjwatson | 1256 /usr/lib/locale/en_US.utf8 | 16:56 |
| cjwatson | that is not a trivial amount of space | 16:56 |
| ari-tczew | dholbach: ping | 16:56 |
| cjwatson | ah, the reason that en_AG showed up as so big in my earlier test was hardlinks; all the English locales come out to about that size in isolation | 16:57 |
| dholbach | ari-tczew: I was just about to head out | 16:57 |
| dholbach | ari-tczew: how can I help? | 16:57 |
| ari-tczew | dholbach: got a minute for sponsoring main? | 16:58 |
| cjwatson | basically I don't think we can justify an extra megabyte for live CD boot speed, at least not on x86. if you want to do that on armel then that's your business. :) | 16:58 |
| ari-tczew | I have refreshed debdiff | 16:58 |
| dholbach | ari-tczew: is this something nobody else can do? | 16:58 |
| ari-tczew | dholbach: heh, doubt | 16:59 |
| dholbach | ari-tczew: best to just ask in here | 16:59 |
| dholbach | no need to block on me | 17:00 |
| ari-tczew | dholbach: but there are not any active sponsors for main like for universe | 17:00 |
| dholbach | ari-tczew: I'll see what I can do about it, but I really need to head out now | 17:01 |
| ari-tczew | ok | 17:01 |
| persia | ari-tczew: There are some, just not many. Just ask, and maybe someone will do it. | 17:01 |
| ari-tczew | ok, so I'm looking for sponsoring @ bug 517297 bug 512430 | 17:02 |
| ubottu | Launchpad bug 517297 in ttf-sil-scheherazade "Fake sync ttf-sil-scheherazade 1.001-6 (main) from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/517297 | 17:02 |
| ubottu | Launchpad bug 512430 in geronimo-jta-1.0.1b-spec "Fake sync geronimo-jta-1.0.1b-spec 1.1-1 (main) from Debian testing (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/512430 | 17:02 |
| cjwatson | ari-tczew: looking | 17:08 |
| cjwatson | ari-tczew: FWIW, you will get a better response if you say which things you want sponsored up-front, rather than starting with "anyone got a minute for sponsoring main" or similar | 17:08 |
| cjwatson | since then people know how much work they're signing up for | 17:09 |
| superm1 | cjwatson, since the translations are kept within debconf for ubiquity, would that localegen stuff only be relevant for live mode, not --only mode? | 17:11 |
| cjwatson | superm1: yes and no, I suspect that some things will still be unhappy if setlocale() fails | 17:12 |
| cjwatson | superm1: but feel free to try it out obviously | 17:12 |
| superm1 | Ok | 17:13 |
| cjwatson | certainly ubiquity is much less likely to have a problem; but remember that there are some failure modes in which ubiquity ends up falling through to gdm | 17:14 |
| === deryck is now known as deryck[lunch] | ||
| superm1 | That should be going away moreso with you adding a vesa fallback though, wont it? | 17:14 |
| cjwatson | not really | 17:15 |
| cjwatson | I'm talking about if ubiquity itself fails | 17:15 |
| superm1 | but if that scenario is still a possibility, can always generate the locale "after" the fall through to gdm but before gdm gets started | 17:15 |
| cjwatson | sure | 17:15 |
| cjwatson | it's all soluble, just needs to not be forgotten | 17:15 |
| LaserJock | superm1: uploaded my bcmwl dir and added a comment, thanks | 17:18 |
| Mirv | cjwatson: I quoted some of your good points regarding usb-modeswitch in my blog http://losca.blogspot.com/ | 17:22 |
| cjwatson | Mirv: you should discuss the quirks question with the kernel team; I was under the impression that updating that sort of thing might well be feasible | 17:25 |
| Mirv | cjwatson: ok. next I was mostly thinking about asking usb-modeswitch developers if they'd rather like a more clear way for them to contribute the information they gather to both upstream and distribution kernels. | 17:26 |
| Mirv | but yes, discussing with kernel team about it would be a good idea in the case of Ubuntu | 17:26 |
| cjwatson | I wouldn't be particularly surprised if the usb-modeswitch developers just plain like doing it in userspace | 17:27 |
| cjwatson | but different people are allowed to like different things ;-) | 17:27 |
| Mirv | might be | 17:28 |
| slangasek | tseliot: yes, even if we were shipping plymouth in the initramfs by default, we would still support initramfsless booting w/ splash | 17:28 |
| slangasek | superm1: it's staying with casper, though we need some bits of casper fixed to talk to plymouth | 17:29 |
| persia | Regarding usb mode quirks: please consider when looking at any solution that a single device may have interesting reasons to do multiple things. For instance, one may have a USB connection to a handheld and want to variously use it for storage, networking, audio, etc. over time. | 17:33 |
| cjwatson | the quirking in the kernel that I'm talking about doesn't prevent that | 17:37 |
| cjwatson | also, decent devices include a USB hub so that all the possible endpoints appear simultaneously | 17:38 |
| cjwatson | this mode-switching thing is AFAIK only done by ultra-cheap devices that want to force advertising on you by mass-storage; I've genuinely never seen it anywhere else | 17:38 |
| maco2 | persia: or a wacom tablet with a pen and eraser and various other devices? | 17:40 |
| smoser | how do i make 'bzr builddeb -S' not include orig source tarball? | 17:41 |
| persia | cjwatson: My smallest handheld (Sharp 922SH) needs it to switch between storage and networking. | 17:41 |
| james_w | smoser: why don't you want one? | 17:41 |
| persia | maco2: Another good example. | 17:41 |
| smoser | because i already uploaded one to ppa | 17:41 |
| smoser | and i think that if i do it again it will be rejected, no? | 17:41 |
| persia | cjwatson: Mind you, it's still storage/networking, but when I have independent editors and browsers on the device, storage is more interesting. | 17:41 |
| cjwatson | persia: I see. My concern is that installing udev rules by default that futz about with the identity of the device is going to create unreliability where it did not previously exist. I don't object to the *tool* being present, merely to the udev rules. | 17:42 |
| cjwatson | smoser: shouldn't care, but you can use bzr bd -S -- -sd | 17:43 |
| cjwatson | smoser: though I'm surprised that it's included by default; see dpkg-genchanges (search for -si) for the default policy | 17:43 |
| persia | cjwatson: I completely agree that the current solution doesn't meet needs. I haven't been able to get it to *work* with my 922SH, I just object to the idea that it only matters for the cheap 128M of ads + 3G modem devices. | 17:43 |
| cjwatson | persia: fair enough, I wasn't aware of devices such as yours | 17:44 |
| smoser | cjwatson, i think its because i'm misusing... i did not create a new changelog entry | 17:44 |
| smoser | but just bumped the one | 17:44 |
| cjwatson | though if usb-modeswitch doesn't work on your device anyway ... :-) | 17:44 |
| cjwatson | smoser: oh, well DDTT :) | 17:44 |
| tseliot | ok, good to know | 17:44 |
| tseliot | slangasek: ^^ | 17:44 |
| smoser | cjwatson, well i just realized that now. | 17:45 |
| persia | cjwatson: The current stuff needs work (and like you say, a cleaner implementation), but I think we'll see more of them as handhelds shrink. I know that at least in the ARM space, there's lots of hardware with usb gadget ports (which users might use for all sorts of stuff). | 17:45 |
| === atomicsteve is now known as vorian | ||
| cjwatson | persia: I don't think our goals are incompatible; I merely want the mode switching to live in the kernel and be done at device initialisation time, rather than having to make round trips through userspace and risk things popping up and claiming the mass storage before userspace has time to switch it away. There's no fundamental reason why the *policy* couldn't live in userspace. | 17:54 |
| cjwatson | This is not a theoretical concern; attempting to use my device with userspace mode switching tools of various stripes simply didn't work due to such race conditions. | 17:54 |
| persia | cjwatson: That makes perfect sense, actually. | 17:55 |
| cjwatson | Unfortunately I don't think the mode switching is in any particularly generic form right now | 17:55 |
| persia | So what would need doing is teaching the kernel that some devices can handle multiple modes, and having the kernel ask some userspace policy agent which mode to use when initialising the device? | 17:58 |
| cjwatson | persia: ideally I think I'd like it to be possible to tell the kernel *in advance*, but I don't know how feasible that is | 18:00 |
| * cjwatson has no intention of actually working on this, so ... | 18:00 | |
| crypt-0 | hi cjwatson | 18:00 |
| cjwatson | hello | 18:00 |
| persia | In advance? That sounds like it either requires the kernel to load some *huge* data store, or not know what to do with heaps of devices. | 18:00 |
| persia | (2^^64 is big) | 18:01 |
| crypt-0 | anyone have info why the cryptsetup package inst upgraded to the 1.1.0? | 18:01 |
| cjwatson | no reason it couldn't have sane defaults | 18:01 |
| crypt-0 | its still using a release candidate for Lucid | 18:01 |
| crypt-0 | the final has been released at http://code.google.com/p/cryptsetup/ | 18:01 |
| cjwatson | no idea, don't know why you're asking me | 18:01 |
| cjwatson | Debian doesn't have it yet, and we normally wait for that, though | 18:01 |
| crypt-0 | its strange that they would keep a release candidate in there for over a month | 18:01 |
| cjwatson | there has to be a good reason to upgrade beyond Debian | 18:02 |
| cjwatson | "it's a release candidate" isn't a good reason | 18:02 |
| crypt-0 | cjwatson, its *probably* safe to assume that it will get upgraded to the stable release before the release of Lucid right? | 18:02 |
| cjwatson | no | 18:02 |
| crypt-0 | hmm | 18:03 |
| cjwatson | we're beyond Debian import freeze and nearly at feature freeze; like I say, there has to be a good reason | 18:03 |
| crypt-0 | a lot of bugfixes? | 18:03 |
| cjwatson | normally, somebody would take responsibility for it and be specific | 18:04 |
| crypt-0 | in crypto software, especially a package that does the FDE for Ubuntu i would expect to be a stable build. | 18:04 |
| cjwatson | if there's a good reason, great; but you just turned up and asked why the version hadn't been bumped :) | 18:04 |
| cjwatson | in isolation, that doesn't cut it | 18:04 |
| cjwatson | anyway, it's not a package I normally work on, so | 18:04 |
| crypt-0 | right | 18:04 |
| cjwatson | any reason you started on IRC, rather than by filing a bug? that's usually the best first step | 18:05 |
| cjwatson | ah, maybe you did, bug 502699? | 18:05 |
| ubottu | Launchpad bug 502699 in cryptsetup "cryptsetup is out of date in lucid" [Undecided,New] https://launchpad.net/bugs/502699 | 18:05 |
| crypt-0 | i thought it would be non-trivial to do, and solve bugs because they are apparently deciding to go with 1.1.0, i dont know why the dont use the final stable build | 18:05 |
| crypt-0 | yes i did :) | 18:05 |
| cjwatson | err, you know, we have tens of thousands of packages. we don't necessarily apply a decision process to every single one. normally we base off whatever's in Debian | 18:06 |
| cjwatson | it's important to understand this | 18:06 |
| crypt-0 | is there a mailing list where i could participate in discussions? right but i think cryptsetup should be stable, because its not just some app you play tetris with. And it is one of the core pacakges. | 18:07 |
| cjwatson | anyway, I'll target this bug to lucid, since it seems like a good idea | 18:07 |
| cjwatson | did you google for Ubuntu mailing lists before asking that question? :-) | 18:07 |
| crypt-0 | thanks | 18:07 |
| crypt-0 | well yes, i think i spotted the right one, but i dont want to troll it like i am here :p | 18:08 |
| cjwatson | oh, you think it's ok to troll here? | 18:08 |
| crypt-0 | i would also like th test the XTS mode | 18:08 |
| cjwatson | that's surprising | 18:08 |
| cjwatson | acceptable use of #ubuntu-devel and ubuntu-devel@lists are pretty similar really | 18:09 |
| crypt-0 | im not tying to troll , im joking | 18:09 |
| cjwatson | ok | 18:09 |
| crypt-0 | but thanks for the help cjwatson | 18:09 |
| cjwatson | the best way to get it upgraded in Ubuntu would be to get it upgraded in Debian first | 18:10 |
| cjwatson | that way we don't have to worry about .orig.tar.gz mismatches and other such tedious things | 18:10 |
| cjwatson | I don't know why the maintainers there haven't picked it up; they may just not have noticed | 18:10 |
| cjwatson | I can go and file a bug there asking for a new version | 18:11 |
| crypt-0 | right, but i think they will before April, nonetheless the sooner the better, it would be good to have it tested now then 3 days before a release. | 18:12 |
| cjwatson | actually that doesn't seem necessary, apparently an upgrade is in progress: http://svn.debian.org/wsvn/pkg-cryptsetup/cryptsetup/trunk/debian/changelog | 18:12 |
| crypt-0 | ahh cool :) | 18:12 |
| crypt-0 | well i gotta get going to class | 18:12 |
| cjwatson | so I assume Jonas is either testing it, or busy | 18:13 |
| crypt-0 | i can help test it, ive been running rc1 since it was out, and upgrading with each release from google code | 18:13 |
| cjwatson | most maintainers like to take at least some responsibility themselves :) | 18:13 |
| crypt-0 | static compile failed on amd64 with rc2 | 18:14 |
| crypt-0 | was fixed in rc3+ | 18:14 |
| crypt-0 | anyway class/work | 18:15 |
| * crypt-0 vanishes | 18:15 | |
| crypt-0 | thx again for your time cjwatson. | 18:16 |
| === deryck[lunch] is now known as deryck | ||
| qense | Do we build gnome-settings-daemon with PackageKit enabled? I have a bug report(bug #516384) of someone who's getting the warning: "Gtk-Message: Failed to load module "pk-gtk-module": libpk-gtk-module.so: cannot open shared object file: No such file or directory" | 19:01 |
| ubottu | Launchpad bug 516384 in nautilus "desktop theme inside nautilus is corrupted" [Low,Incomplete] https://launchpad.net/bugs/516384 | 19:01 |
| seb128 | qense, I doubt it | 19:03 |
| seb128 | qense, the bug is probably a packagegit one though | 19:03 |
| qense | seb128: wouldn't that be weird considering the fact that Ubuntu doesn't use PackageKit? | 19:03 |
| seb128 | qense, ubuntu doesn't but some users do | 19:04 |
| seb128 | qense, this warning is not there in the default installation it must come from some installed component | 19:04 |
| seb128 | qense, google first hint is bug #389766 | 19:05 |
| ubottu | Launchpad bug 389766 in packagekit "Gtk-Message **: Failed to load module "pk-gtk-module": libpk-gtk-module.so: cannot open shared object file: No such file or directory at" [Undecided,Confirmed] https://launchpad.net/bugs/389766 | 19:05 |
| qense | seb128: that makes sense, I'll look into the bug you named. Thank you for your help! | 19:06 |
| === dendro-afk is now known as dendrobates | ||
| === siretart_ is now known as siretart | ||
| kirkland | jcastro: where's the new patches page? | 20:34 |
| jcastro | kirkland, they ended up having to land some db changes so it didn't make edge | 20:35 |
| jcastro | kirkland, 1 march is what they're telling me | 20:35 |
| jcastro | :-/ | 20:35 |
| kirkland | jcastro: what's the best way for me and an upstream to look at the patches Ubuntu is carrying? | 20:35 |
| jcastro | how have you done it in the past? | 20:36 |
| kirkland | jcastro: i use apt-get source | 20:36 |
| kirkland | jcastro: upstream is not debian/ubuntu, doesn't have apt-get | 20:36 |
| jcastro | yeah that's probably the most straightforward. | 20:36 |
| jcastro | I know, that's why we started making +patches | 20:36 |
| jcastro | perhaps throwing the patches on people.u.c prior to review for him? | 20:37 |
| === NCommander_ is now known as NCommander | ||
| === NCommander is now known as Guest88140 | ||
| === Guest88140 is now known as NCommander | ||
| Caesar | slangasek: can I have your opinion on bug #520715 ? | 21:15 |
| ubottu | Launchpad bug 520715 in ruby1.8 "building ruby1.8 with pthread support causes puppet hangs" [Undecided,Triaged] https://launchpad.net/bugs/520715 | 21:15 |
| Caesar | mathiaz might also care about it, depending on how widespread the problem ends up being | 21:16 |
| slangasek | Caesar: I would certainly prioritize the ruby-using applications in main over the ruby extension in universe that this will break | 22:00 |
| slangasek | if lucas can find a solution to the bug when pthreads are used, great, but otherwise puppet should be the priority | 22:00 |
| lucas | slangasek: that's a joke? | 22:01 |
| slangasek | lucas: why would you think it is? | 22:01 |
| lucas | there has been *no* checking at all of other ruby libraries | 22:01 |
| lucas | what if ruby on rails breaks? | 22:01 |
| directhex | i wonder if ironruby-on-rails will be working in time for lucid... | 22:03 |
| cjwatson | there's some precedent in other languages, grotty though it is, of building two versions of the interpreter when there's no way to make everything work at once | 22:03 |
| Caesar | slangasek: thanks for your input | 22:03 |
| Caesar | cjwatson: it's not even known if it's going to be a problem | 22:03 |
| cjwatson | my comment is based on the assumption that it may, which I think is not hopelessly ill-founded | 22:03 |
| slangasek | lucas: rails is also not in main. I would obviously prefer to have the package working for all applications, but supported apps in main take precedence | 22:03 |
| jp-- | hi guys | 22:04 |
| jp-- | what's the best way to upgrade glib-c from 8.04 to the one that's on 9.10? | 22:05 |
| cjwatson | upgrade your distribution to 9.10; upgrading glibc alone is one of the riskier things you can do to a stable release, and certainly obviates many of the points of running a stable release | 22:06 |
| jp-- | cjwatson, I'm working on a special device, I've invested a lot of time to get it working with 8.04, I can't just upgrade it to 9.10, I've made a lot of customizations to 8.04 to make the device work well with it | 22:07 |
| jp-- | there might be a way, I guess | 22:07 |
| jp-- | anyways, thanks! | 22:08 |
| cjwatson | jp--: it is technically possible to just dpkg -i the libc6 package (and whatever else it complains about when you try that), but I expect that things would break | 22:08 |
| Caesar | spectacularly | 22:08 |
| cjwatson | jp--: I would certainly spend quite a bit of time investigating workarounds before doing that | 22:08 |
| slangasek | there tends to be an unfortunate degree of coupling between glibc and the kernel, yes | 22:08 |
| slangasek | ("unfortunate" from the POV of people trying to do this, anyway) | 22:09 |
| jp-- | thanks cjwatson :) | 22:09 |
| lucas | slangasek: I don't think that's an acceptable solution. you might break ruby by changing a parameter deep inside the interpreter, and then explain "oh, we broke ruby? sorry, but puppet is the only thing that matters." | 22:09 |
| cjwatson | rails depends: libsqlite3-ruby depends: libsqlite3-ruby1.8 depends: libsqlite3-0, and libsqlite is linked to pthreads, so there is a possible source of breakage there | 22:09 |
| slangasek | I'm hoping that libsqlite doesn't /spawn/ threads, though | 22:09 |
| Caesar | The "might" needs to come out of this argument | 22:10 |
| Caesar | lucas: How do we satisfy you that we haven't broken Ruby by disabling pthreads? | 22:10 |
| cjwatson | Caesar: I don't think anyone is arguing against doing substantially more testing | 22:10 |
| lucas | Caesar: you are proposing the change. I'm proposing to be conservative. you should prove that it still works. | 22:10 |
| Caesar | lucas: I'm asking what proof will satisfy you that it does | 22:11 |
| jbebel | We'd need a list of requirements for proving that it works to do that. | 22:11 |
| lucas | Caesar: the problem is, really, you can't, because it's so deep in the interpreter that you might not notice the consequences | 22:11 |
| Caesar | lucas: that's not conservative, that's head in the sand | 22:11 |
| cjwatson | personally, I like the option of finding the relevant change between the --enable-threads version that used to work, and the --enable-threads version that now doesn't | 22:11 |
| Caesar | cjwatson: that's been done | 22:11 |
| jbebel | I found it. | 22:11 |
| cjwatson | I didn't see it in the bug report | 22:11 |
| jbebel | It's in the ruby bug I filed. | 22:11 |
| cjwatson | ah yes | 22:11 |
| jbebel | http://redmine.ruby-lang.org/issues/show/2739 | 22:11 |
| jbebel | But it's too deep into other changes to just roll that back. | 22:12 |
| lucas | cjwatson: /usr/lib/ruby/1.8/x86_64-linux/gnome2.so is linked with libpthread as well | 22:12 |
| slangasek | lucas: that's a) not a standard Ubuntu can reasonably accept as a blocker for a fix that might be needed for puppet, b) inconsistent with the fact that upstream provides this as a configure option | 22:12 |
| cjwatson | so I think lucas is entirely within his rights to suggest that that should be the focus of investigations | 22:12 |
| cjwatson | I'm going on memories of similar issues in perl | 22:12 |
| cjwatson | which went through a very similar kind of thing where people flipped pthreads to try to fix individual issues before realising that it wasn't a tenable approach | 22:13 |
| Caesar | It'd be lovely if we could come up with a self-contained test case | 22:13 |
| cjwatson | the upstream bug was filed one (1) day ago, so I'm not sure I see that we should be panicking over it right away | 22:14 |
| jbebel | The problem "appears" to be fixed in the rub 1_8 svn branch, but that has other syntax changes that break things. I'm hoping ruby can merge some change from the 1_8 branch into the 1_8_7 branch which fixes it. | 22:14 |
| Caesar | We've removed the blocking issue by forking Ruby internally | 22:14 |
| lucas | slangasek: the ruby threading code is black magic. we have been running with --enable-pthreads since at least dapper. flipping that now in the standard ruby package is too risky. | 22:14 |
| Caesar | So, no, there's no cause for panic | 22:14 |
| lucas | slangasek: a solution could be to add a ruby-just-for-puppet package | 22:14 |
| jbebel | -and-also-if-you-experience-problems-with-threading-which-has-been-shown-to-be-unreliable-in-ruby-1-8-7 | 22:16 |
| lucas | only with puppet so far | 22:16 |
| Caesar | Only with Puppet with a particular configuration on particular hardware | 22:17 |
| Caesar | It's awesome | 22:17 |
| jbebel | And without pthreads has been shown to be unreliable with nothing except tcltk. | 22:17 |
| jbebel | which is unused. | 22:17 |
| cjwatson | slangasek: libsqlite3 uses pthread_create in code paths which are not obviously-to-me unused | 22:17 |
| slangasek | jbebel: which is not equivalent to showing that it's reliable with other things...? | 22:17 |
| slangasek | cjwatson: twitch | 22:17 |
| jbebel | agreed. | 22:17 |
| lucas | jbebel: you haven't tried with anything besides tcltk :-) | 22:17 |
| jbebel | I dont' know how. I just expect that others would be more interested in evidence that ruby has a regression in the version going into Lucid. | 22:18 |
| cjwatson | jbebel: honestly, I don't think it makes sense to explore this contentious option until we've explored the ruby bug you linked to | 22:18 |
| Caesar | It would help if we could reliably reproduce the problem | 22:18 |
| cjwatson | we have at least one known fallback which is less risky than flipping the configure option | 22:18 |
| Caesar | True, if you're okay with reverting to an older version of Ruby | 22:19 |
| cjwatson | hmm? | 22:19 |
| cjwatson | that wasn't what I said at all | 22:19 |
| lucas | jbebel: you have amd64 packages without pthread somewhere? | 22:19 |
| Caesar | I figured that was the fallback that was less risky | 22:19 |
| cjwatson | no | 22:19 |
| cjwatson | what I meant was a separate ruby build | 22:19 |
| Caesar | Oh, right, sorry | 22:19 |
| jbebel | I do, internally here. I can put them up somewhere. | 22:19 |
| lucas | jbebel: that would be nice | 22:20 |
| jbebel | http://moses.mybox.org/~jbebel/ruby1.8/ | 22:24 |
| lucas | thanks, but not installable on Debian. anyway, will rebuild them using your patch | 22:25 |
| jbebel | Sorry. I built them under Lucid. | 22:26 |
| lucas | yup, different libc version | 22:26 |
| jbebel | The source with my patch included is also on that page. | 22:30 |
| lucas | rbbr (user of ruby-gnome2) crashes on startup with the --disable-pthread version | 22:35 |
| lucas | I haven't tried to rebuild ruby-gnome2 against the non-pthread version, it might help | 22:35 |
| Nikratio | I'm trying to create a branch with a patch for Bug #457702, but I can't quite figure it out. The BzrContributorHowto says to execute "bzr push bzr+ssh://nikratio@bazaar.launchpad.net/~nikratio/ltsp/ubuntu.bug457702", but I just get an error "Working tree has uncommitted changes". | 22:59 |
| ubottu | Launchpad bug 457702 in ltsp "nbd+squashfs errors when rebooting ltsp thin clients" [Undecided,Confirmed] https://launchpad.net/bugs/457702 | 22:59 |
| Nikratio | What do I need to do? | 22:59 |
| geser | Nikratio: did you "bzr commit" your changes to your local branch before you tried pushing? | 23:02 |
| Nikratio | No. I guess I'm used to SVN, where that would be bound to fail. | 23:02 |
| Nikratio | So I just execute bzr commit? | 23:02 |
| cjwatson | yes | 23:03 |
| Nikratio | Hmm: Permission denied (publickey). | 23:04 |
| Nikratio | bzr: ERROR: Connection closed: | 23:04 |
| geser | cjwatson: any chance you might have time to review bug 509900 before FF? | 23:04 |
| ubottu | Launchpad bug 509900 in vim "Merge vim 2:7.2.330-1 from Debian unstable" [Undecided,New] https://launchpad.net/bugs/509900 | 23:04 |
| geser | Nikratio: did you do a "bzr branch" to get a local branch? | 23:04 |
| cjwatson | Nikratio: on commit? | 23:04 |
| cjwatson | Nikratio: you did a bzr checkout, DDTT, use bzr branch for commit | 23:04 |
| cjwatson | Nikratio: to repair without having to branch it all again, run 'bzr unbind' | 23:05 |
| Nikratio | cjwatson: no, the commit worked. The push falied. | 23:05 |
| cjwatson | ok | 23:05 |
| cjwatson | where are you pushing to? | 23:05 |
| Nikratio | I'm executing "bzr push bzr+ssh://nikratio@bazaar.launchpad.net/~nikratio/ltsp/ubuntu.bug457702" | 23:05 |
| cjwatson | geser: not before FF (I'm on holiday next week), but OTOH I don't think this is subject to feature freeze | 23:05 |
| geser | cjwatson: ok, will you do it after your holiday or should I try to find someone else? | 23:06 |
| cjwatson | geser: latter might be better but otherwise I'll do it when I get back | 23:06 |
| Nikratio | cjwatson: so far I have done: 1. bzr get, 2. made the changes, 3. bzr commit, 4. bzr push (failed) | 23:06 |
| geser | Nikratio: have you a SSH key configured on your LP account? | 23:07 |
| cjwatson | Nikratio: do you use an ssh-agent, and if so does it know about your key? | 23:07 |
| cjwatson | geser: yes he does, https://launchpad.net/~nikratio | 23:07 |
| Nikratio | I'm not using an ssh agent | 23:07 |
| cjwatson | that might be the easiest fix | 23:08 |
| geser | without an ssh agent should ssh ask about the passphrase? | 23:08 |
| bdrung | hi, can a core-dev trigger a second try to build libmx4j-java ( https://launchpad.net/ubuntu/+source/libmx4j-java/3.0.2-8 ). javahelper is now in main and it should build now. | 23:09 |
| cjwatson | geser: yes, though I can't remember whether it does when used via bzr | 23:09 |
| cjwatson | Nikratio: do you have multiple ssh keys, or just one? | 23:09 |
| Nikratio | geser, cjwatson: the ssh key on launchpad was obsolete. I updated it and now the push worked. What do I need to do next? Just add the branch URL as a bug comment? | 23:09 |
| cjwatson | bdrung: kicked | 23:10 |
| bdrung | cjwatson: thanks | 23:10 |
| cjwatson | Nikratio: there are several possibilities, but that's one of them, yes | 23:10 |
| sistpoty | ah, that explains why I get "cannot retry this build" ;) | 23:11 |
| geser | Nikratio: for the future: https://wiki.ubuntu.com/DistributedDevelopment/Documentation is also a nice documentation on how to work with bzr on packages | 23:12 |
| cjwatson | Nikratio: I edited BzrContributorHowto to point out that you have to commit before pushing; thanks | 23:14 |
| Nikratio | geser, cjwatson: Will look over the link. Thanks for your help. | 23:17 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
