| === Snova_ is now known as Snova | ||
| === Snova_ is now known as Snova | ||
| scientes | how do i build nvidia driver for my specific kernel | 02:54 |
|---|---|---|
| scientes | m-a is broken | 02:54 |
| scientes | and i dont know to give dkms for version etc | 02:54 |
| scientes | module=nvidia version=180 doesnt work | 02:54 |
| TheMuso | scientes: What kernel are you running? | 02:55 |
| scientes | 2.6.27.11-g | 02:55 |
| TheMuso | scientes: you need linux-headers-generic installed | 02:56 |
| scientes | have that | 02:56 |
| scientes | the only way to get it to work is to restart but thats stupid | 02:56 |
| scientes | you shouldnt break m-a | 02:56 |
| TheMuso | scientes: the nvidia kernel driver in intrepid afaicr uses dkms. | 02:57 |
| scientes | dkms build -m nvidia -v 180 | 02:57 |
| scientes | Error! DKMS tree does not contain: nvidia-180 | 02:57 |
| scientes | Build cannot continue without the proper tree. | 02:57 |
| scientes | give me the command that occurs on startup for dkms | 02:57 |
| TheMuso | scientes: I don't know enough about dkms to help any further sorry. | 02:58 |
| scientes | bingo | 02:58 |
| scientes | /etc/init.d/dkms_autoinstaller start | 02:58 |
| cjwatson | robert_ancell: have you managed to get anywhere with bug 353090? | 03:02 |
| ubottu | Launchpad bug 353090 in guadalinex "(jaunty) Text hidden on "Who are you?" step" [High,Confirmed] https://launchpad.net/bugs/353090 | 03:02 |
| cjwatson | robert_ancell: (I'm off to bed now, but will read messages) | 03:02 |
| cjwatson | does anyone here suffer from bug 44194 (or, failing that, even just using WPA wireless networking would be somewhat interesting)? If so, could you please make sure you're up to date with jaunty and then upgrade to the wpasupplicant package in my PPA (https://launchpad.net/~cjwatson/+archive/ppa)? | 03:23 |
| ubottu | Launchpad bug 44194 in openssl "wpasupplicant doesn't start when the network start" [High,Fix released] https://launchpad.net/bugs/44194 | 03:23 |
| cjwatson | I don't actually have a WPA network here so it's a bit tricky ... | 03:24 |
| cjwatson | and I'd like a bit of testing from people who know what they're doing and how to recover from problems before unleashing it on the large number of subscribers to that bug | 03:25 |
| * cjwatson goes to fall over for a bit | 03:26 | |
| TheMuso | cjwatson: I run a WPA wireless network here with a couple of Ubuntu WPA clients. I'll get latest updates and check that bug to see whether I suffer from it, and if so, will test your fix. | 03:33 |
| slangasek | cjwatson: I do have separate /usr, so I could do some testing; would probably be another day or two before I get a chance though, with the rebooting & fiddling involved | 03:37 |
| TheMuso | Oh, separate /usr, and static wpa config. I have neither configuration here. :) | 04:09 |
| === Snova_ is now known as Snova | ||
| ikus060 | May someone give me some clue, I'm looking for the source code that define the behaviour of Apple Keyboard | 04:27 |
| * calc wonders if there is anything stopping us from flipping a bit to compressing all debs by default with lzma | 04:52 | |
| calc | aiui opensuse already does that for rpm's | 04:52 |
| Keybuk | calc: isn't the reason we don't more to do with lzma's massively increased speed and memory requirements? | 04:58 |
| calc | well it takes more on the compression side but takes less cpu time to decompress than even bz2 | 04:58 |
| calc | memory requirement was ~ 30MB iirc to decompress | 04:58 |
| Keybuk | calc: but bz2 uses more cpu time to decompress than there are seconds left in the universe's life | 04:58 |
| Keybuk | so that bar is so low, you practically trip over it on the way in | 04:59 |
| calc | iirc it would save us ~ 200MB on the alternate cd when i tested it before | 04:59 |
| Keybuk | the alternate CD is not the only problem space-wise | 04:59 |
| Keybuk | and, pointedly, the alternate is the fallback in the low memory situations | 04:59 |
| calc | yea, getting lzma onto the desktop cd would be more problematic :\ | 04:59 |
| Keybuk | I'd be interested to see benchmarks, but I'd be surprised if lzma performed anywhere near gzip | 04:59 |
| Keybuk | obviously it can be enabled on a package-by-package basis like we do with bz2 | 04:59 |
| calc | hmm true | 05:00 |
| Keybuk | we already use bz2 for mostly-text debs where we remember | 05:00 |
| calc | how much ram does the alternate disk take by itself i would think we would still be well below the minimum install requirements even with lzma | 05:00 |
| Keybuk | no idea | 05:00 |
| calc | roughly 3x slower than gzip to decompress | 05:01 |
| calc | with bzip being 8x slower than gzip | 05:01 |
| Keybuk | what's the difference in compression like? | 05:02 |
| calc | as of 7.10 gzip for a whole cd would be 708MB vs 500MB for lzma | 05:02 |
| Keybuk | really? | 05:02 |
| Keybuk | you tried it? | 05:02 |
| calc | also reduces bandwidth requirements obviously for network updates, etc | 05:02 |
| calc | https://wiki.ubuntu.com/dpkg-lzma | 05:02 |
| calc | yea when i patched dpkg to support lzma | 05:03 |
| calc | original was a mixture of bzip2 and gzip already on the cd, i recompressed it all with gzip, bzip2, and lzma to get numbers to see if everything was in one format | 05:03 |
| Keybuk | I just picked on a random package | 05:04 |
| Keybuk | -rw-r--r-- 1 scott scott 170K 2008-09-29 18:04 upstart_0.3.9-8_i386.deb | 05:04 |
| Keybuk | -rw-r--r-- 1 scott scott 170K 2009-04-06 21:04 upstart_0.3.9-8_i386.deb_lzma | 05:04 |
| Keybuk | zero difference | 05:04 |
| Keybuk | well | 05:04 |
| Keybuk | -rw-r--r-- 1 scott scott 173672 2008-09-29 18:04 upstart_0.3.9-8_i386.deb | 05:04 |
| Keybuk | -rw-r--r-- 1 scott scott 173754 2009-04-06 21:04 upstart_0.3.9-8_i386.deb_lzma | 05:04 |
| Keybuk | the lzma is, in fact, larger | 05:04 |
| calc | the ods file on the wiki shows the all the packages on the cd as of 7.10 | 05:05 |
| Keybuk | I instantly disbelieve the wiki page | 05:05 |
| calc | there were a small numbers of packages like that which grew very slightly | 05:05 |
| Keybuk | 05:05 | |
| Keybuk | original | 05:05 |
| Keybuk | 05:05 | |
| Keybuk | none | 05:05 |
| Keybuk | 05:05 | |
| Keybuk | gzip | 05:05 |
| Keybuk | 05:05 | |
| Keybuk | bzip2 | 05:05 |
| Keybuk | 05:05 | |
| Keybuk | lzma | 05:05 |
| robert_ancell | cjwatson: will update you when I can... | 05:05 |
| Keybuk | 05:05 | |
| Keybuk | lzma saves | 05:05 |
| Keybuk | openoffice.org-core | 05:05 |
| Keybuk | 05:05 | |
| Keybuk | 37215228 | 05:05 |
| Keybuk | 05:05 | |
| Keybuk | 112219498 | 05:06 |
| Keybuk | 05:06 | |
| Keybuk | 38941278 | 05:06 |
| Keybuk | 05:06 | |
| Keybuk | 37319546 | 05:06 |
| Keybuk | 05:06 | |
| Keybuk | 27002374 | 05:06 |
| Keybuk | 05:06 | |
| Keybuk | 10212854 | 05:06 |
| Keybuk | err | 05:06 |
| Keybuk | BAD PASTE | 05:06 |
| Keybuk | what I was trying to point out is that the original number doesn't match ANY of the other numbers! | 05:06 |
| Keybuk | so, according to that wiki page, all of the packages are apparently compressed with fairyzip | 05:06 |
| calc | for upstart as of 7.10 it was gzip 159454, bzip2 157482, lzma 138966, but of course has changed now | 05:06 |
| calc | Keybuk: eh? | 05:07 |
| Keybuk | upstart has not changed since 7.10 | 05:07 |
| calc | fairyzip? | 05:07 |
| Keybuk | not majorly anyway | 05:07 |
| Keybuk | calc: as in, the numbers do not match | 05:07 |
| calc | compiler has | 05:07 |
| Keybuk | calc: openoffice.org-core original should match bzip identically | 05:07 |
| Keybuk | otherwise the test is not valid | 05:07 |
| calc | well i was using the regular utils to compress not whatever dpkg does internally | 05:08 |
| Keybuk | dpkg just uses them too | 05:08 |
| calc | maybe it uses some different args to tar for older compatibility? | 05:08 |
| Keybuk | not that I know of | 05:08 |
| Keybuk | easiest way is just to extract and recompress the control.tar.gz | 05:09 |
| Keybuk | gunzip && bzip2 | 05:09 |
| calc | the difference is on the order of 0.28% | 05:09 |
| calc | thats what i did and it ended up with different sizes than dpkg | 05:09 |
| Keybuk | you recompressed the entire cd? | 05:09 |
| calc | i'm not sure if i still have the scripts but i used dpkg to pop out the control and the data and then recompressed the data and stuffed it back in | 05:10 |
| calc | yes, and the ods shows all the packages | 05:10 |
| Keybuk | cool | 05:11 |
| Keybuk | I'm surprised it's honestly that much | 05:11 |
| calc | a lot of the differences were in the range of .01% difference between original and the same compression type as original | 05:11 |
| calc | but they look like they consistently ended up different sizes than the original packages compressed in at least supposed to be the same way | 05:12 |
| Keybuk | we're already using lzma for things like openoffice now, right? | 05:13 |
| calc | yea | 05:13 |
| === thunderstruck is now known as gnomefreak | ||
| calc | it bought 14% over bzip2 on OOo source in a test i just did | 05:18 |
| calc | not bad considering how big OOo is, heh | 05:18 |
| Keybuk | the unlzma times seem quite reasonable here | 05:19 |
| Keybuk | unlzma data.tar.lzma 7.85s user 0.53s system 96% cpu 8.670 total | 05:19 |
| Keybuk | gunzip data.tar 2.86s user 0.46s system 99% cpu 3.331 total | 05:19 |
| calc | yea | 05:20 |
| Keybuk | it's the lzma times that really bite though | 05:20 |
| calc | yea | 05:20 |
| calc | but that is a one time cost... depends on if it is too high a one time cost i guess | 05:20 |
| Amaranth | Keybuk: lzma fails even worse once your gzip implementation uses threads | 05:20 |
| Amaranth | calc: that was the inflate time, not the deflate time | 05:21 |
| Keybuk | once per upload/build cost | 05:21 |
| calc | Amaranth: i was talking about deflate, yes | 05:21 |
| calc | Amaranth: deflate takes much longer | 05:21 |
| calc | Keybuk: we already have a huge cost by dpkg-shlibdeps, yuck | 05:22 |
| Keybuk | not that huge | 05:22 |
| Keybuk | lzma has been running for what seems like minutes so far... | 05:22 |
| calc | Keybuk: for OOo it is like 50% of the build time for a cached build i think | 05:22 |
| calc | on the order of 20min+ | 05:22 |
| Amaranth | eep | 05:22 |
| calc | i need to dig into that later this week since i have my bugs under control | 05:22 |
| Amaranth | calc: every time you talk about OOo building you make me less and less likely to ever even apt-get source it :P | 05:23 |
| calc | i had talked to cjwatson about having a way to disable that option, heh | 05:23 |
| calc | both the lzma and dpkg-shlibdeps could have flags to disable them for developer building and only enable them on buildds or something if needed | 05:23 |
| calc | or so developers can disable them if they need to build quickly in any case :) | 05:24 |
| Keybuk | lzma data.tar 206.26s user 0.53s system 99% cpu 3:27.41 total | 05:24 |
| Keybuk | gzip data.tar 19.77s user 0.32s system 99% cpu 20.099 total | 05:24 |
| calc | yea compression is yucky | 05:24 |
| calc | hmm it was only 4x slower in my test back in 7.10 though, that is interesting | 05:25 |
| calc | another place where lzma could help is in archive files like Contents, (amd64) gzip is 15759388, bzip2 is 12875965, and lzma is 10991062 | 05:26 |
| calc | currently we appear to only have gzip versions available | 05:27 |
| calc | contents isn't grabbed all the time but packages file see similar percentage improvements | 05:28 |
| Keybuk | yes | 05:30 |
| Keybuk | because the publisher run needs to take longer ;) | 05:30 |
| calc | lol :-) | 05:30 |
| TheMuso | c | 06:10 |
| bluefox_ | Congratulations on Ubuntu Jaunty Beta for x86_64! | 06:39 |
| bluefox_ | You should add to your milestones, "Almost as stable as WindowsME!" | 06:39 |
| === bluefox_ is now known as bluefoxicy | ||
| JanC | <Amaranth> Keybuk: lzma fails even worse once your gzip implementation uses threads | 06:41 |
| JanC | lzma2 should be much better with multiple cores... | 06:41 |
| JanC | don't know if there is a linux port of that already? | 06:41 |
| JanC | it divides the file in "blocks" that it can compress in parallel | 06:43 |
| slangasek | bluefoxicy: trolling is inappropriate and unwelcome. | 06:44 |
| jdong | slangasek: wrong bluefox :) | 06:45 |
| jdong | friendly fire!!!!111 | 06:45 |
| jdong | wait... | 06:46 |
| jdong | what the... | 06:46 |
| jdong | you know what, I'm gonna go to bed now. Night :) | 06:46 |
| slangasek | jdong: night :) | 06:46 |
| Mithrandir | it's been entirely stable from me, apart from sometimes failing to power off properly. | 06:46 |
| jdong | the OS itself has been great, but audio problems with proprietary crap has regressed | 06:47 |
| jdong | high CPU usage, latency, and cutouts from Skype especially, also Flash. | 06:47 |
| jdong | other than that, by far one of the cleanest upgrades I've done | 06:48 |
| JanC | about lzma2: http://sourceforge.net/forum/forum.php?thread_id=2965956&forum_id=45797 | 06:52 |
| JanC | (appears it's still alpha or beta though) | 06:53 |
| TheMuso | jdong: Sorry not much we can do re skype, other than you kill pulseaudio to use skype. | 07:06 |
| TheMuso | jdong: Oh try also using direct hardware input for the microphone via skype, and only use pulse for output. | 07:06 |
| slangasek | TheMuso: pulseaudio-module-x11 Recommends: gnome-audio | ubuntu-sounds, which confuses germinate; is there any reason not to reverse the order of these? | 07:45 |
| TheMuso | slangasek: persia actually asked to have them turned around at one point, I can't remember his reasoning however. I think its in the changelog, let me look. | 07:46 |
| hile | should it be supported to change /usr/bin/python symlink to other supported versions than python2.6 in jaunty? | 07:46 |
| slangasek | TheMuso: arguably the Recommends should be dropped entirely... | 07:46 |
| slangasek | hile: no | 07:47 |
| hile | ok | 07:47 |
| persia | I asked to switch it around precisely because it confused germinate. Dropping it would also meet my goals. | 07:47 |
| slangasek | persia: you asked to have gnome-audio listed first because of germinate? | 07:47 |
| persia | (or perhaps not "confuse" but rather "generated a behaviour I didn't want") | 07:47 |
| slangasek | ah | 07:47 |
| hile | fair enough, that would complicate things very much :) | 07:47 |
| TheMuso | Yeah I think pitti dropped them, but somehow they were re-added. I'll remove them. | 07:47 |
| slangasek | TheMuso: ok, cheers :) | 07:48 |
| persia | slangasek, Yes. I don't remember the specifics, but it was something about gnome-audio being installed when there was an ubuntu-sounds alternative available: perhaps related to universe flavours. | 07:48 |
| persia | RIght. That was it: for universe flavours, ubuntu-sounds wasn't getting installed because gnome-audio was available. | 07:48 |
| slangasek | persia: ok. the current formulation is going to prefer pulling in gnome-audio for universe flavors; it also causes germinate to want to pull gnome-audio into main. All told, it results in rather a bit of inconsistency. | 07:48 |
| hile | I just had some personal code using default python which did not work in 2.6 and I changed 'temporarily' the link, noticing upgrade failed horribly - if it were supposed to be supported to change default python, there would have been a couple of bug reports to be done | 07:49 |
| persia | slangasek, I'd agree, especially because I think we'd generally prefer ubuntu-sounds anyway. | 07:49 |
| * slangasek nods | 07:49 | |
| hile | anyway, just fixed my own code, that's the better solution anyway :) | 07:49 |
| slangasek | hile: right - generally, packages are allowed to depend on a specific version of the 'python' package, and expect /usr/bin/python to be that version. | 07:50 |
| slangasek | packages that need a version of python *other* than the current default can still invoke it as /usr/bin/python2.x | 07:50 |
| persia | Note that packages that *do* use /usr/bin/python2.x need to be very careful about the libraries that may be available to that version of python. | 07:51 |
| hile | yeah this was not packaged code anyway, just some local projects | 07:56 |
| * StevenK sighs at libdvdread reporting itself as 0.9.4 in Jaunty | 07:57 | |
| * slangasek sighs at ogmrip having unreasonable requirements for libdvdread's version reporting | 07:58 | |
| slangasek | :) | 07:58 |
| StevenK | slangasek: Ah, so you do know what is going on. | 07:59 |
| StevenK | slangasek: I can patch libdvdread with a one-line patch and then ogmrip requires no changes. | 07:59 |
| slangasek | StevenK: I got as far as the FTBFS and punted on it | 07:59 |
| slangasek | I have no preference on how you fix it | 07:59 |
| slangasek | well; if you change libdvdread, I prefer that it not make other packages FTBFS :) | 08:00 |
| * StevenK sobs at the rdepends list. | 08:01 | |
| StevenK | slangasek: In other news, do you know about openoffice.org-qa-{api-test,tools} in NBS? | 08:12 |
| StevenK | slangasek: They look to have circular Depends, too | 08:13 |
| slangasek | StevenK: yeah - I actually removed those two just now | 08:25 |
| === reed is now known as Guest85285 | ||
| robert_ancell | cjwatson: have workaround for bug 353090 | 09:04 |
| ubottu | Launchpad bug 353090 in ubiquity "(jaunty) Text hidden on "Who are you?" step" [High,In progress] https://launchpad.net/bugs/353090 | 09:04 |
| seb128 | hey robert_ancell | 09:06 |
| robert_ancell | seb128: morning seb | 09:08 |
| davmor2 | Guys I got an issue with samba. I've got a share on my hardy server that works with vista, xp and intrepid but doesn't with jaunty. I'm just looking through the bug report now to see if it's known but thought I'd better add it here too | 09:08 |
| === Guest85285 is now known as reed_ | ||
| cjwatson | robert_ancell: cool, thanks! will look into that. presumably if the parent widgets aren't realized then .realize() just harmlessly does nothing? | 09:50 |
| === seb128_ is now known as seb128 | ||
| ogra | asac, do you have an idea about bug 356517 | 10:20 |
| ubottu | Launchpad bug 356517 in udev "udev does not detect eth0 on armel" [Undecided,Invalid] https://launchpad.net/bugs/356517 | 10:20 |
| mvo | could someone please eyeball http://launchpadlibrarian.net/24926831/debdiff ? | 10:22 |
| cjwatson | mvo: looks ok to me | 10:23 |
| mvo | thanks | 10:24 |
| mvo | tests work fine too, I will upload | 10:24 |
| === mdz_ is now known as mdz | ||
| asac | ogra: driver issue i would think | 10:27 |
| asac | ogra: do you have a lshal from such a board for me? | 10:28 |
| ogra | i can produce one | 10:28 |
| asac | ogra: please do and attach to bug (i asked now) | 10:28 |
| === azeem_ is now known as azeem | ||
| c_korn | hello. why is the number of processes not limited in /etc/security/limits to prevent fork bombs? | 10:37 |
| mnemo | good question | 10:38 |
| mnemo | it's insane that somebody can login to a non-root shell and disrupt the whole system | 10:38 |
| c_korn | I read that debian is not affected | 10:53 |
| seb128 | by what? | 10:54 |
| c_korn | <c_korn> hello. why is the number of processes not limited in /etc/security/limits to prevent fork bombs? | 10:54 |
| seb128 | oh, dunno about that one | 10:54 |
| cjwatson | Debian does not set a maximum number of processes in /etc/security/limits.conf either, so I don't know where you read that. You can check the differences yourself: http://patches.ubuntu.com/p/pam/pam_1.0.1-9ubuntu1.patch | 11:02 |
| cjwatson | I imagine the problem is that there is no sensible default. Any limit that will be high enough to avoid impeding legitimate work would also be high enough that a forkbomb would cause problems well before it ever reached the limit | 11:03 |
| cjwatson | weren't there kernel scheduler changes to try to level out timeslices among users, so that even if one user had a zillion processes running, another user could still get their processes scheduled effectively? | 11:04 |
| cjwatson | that's a much better approach to this kind of problem | 11:04 |
| ogra | asac, attached | 11:05 |
| c_korn | "I'll quickly mention here that Debian did not suffer the same fate as the others; congrats to the Debian development team." ( http://www.securityfocus.com/columnists/308 ) but in the comments someone said debian is affected | 11:06 |
| c_korn | so the kernel scheduler has to be fixed instead of setting a maximum number of processes? | 11:13 |
| c_korn | has to be hard because the problem still exists | 11:13 |
| cjwatson | all approaches to this problem are hard; there is no easy answer (assuming you don't just ignore some of the constraints, as journalists are apt to do) | 11:14 |
| mnemo | im a customer at a small shared web hosting where they give ssh access | 11:15 |
| mnemo | they not big and professional but I really like the ssh access | 11:15 |
| mnemo | I tried a fork bomb in that shell and their server got hosed | 11:15 |
| mnemo | they run debian, but a really old version | 11:15 |
| mnemo | i bet there is lots of ubuntu server installs like that, where a fairly large set of semi-untrusted people are given non-root accounts | 11:16 |
| mnemo | i dont pretend to have a solution though.. | 11:16 |
| asac | ogra: that unfortunate. why does that driver need that parent? | 11:18 |
| cjwatson | the general term for scheduler fixes that address this problem is "group scheduling" | 11:19 |
| asac | ogra: udi = '/org/freedesktop/Hal/devices/net_00_00_45_67_89_ab' | 11:19 |
| asac | info.parent = '/org/freedesktop/Hal/devices/computer' (string) | 11:20 |
| cjwatson | you can google for it with site:lwn.net for a number of good explanations | 11:20 |
| === Mez is now known as CrazyShoe | ||
| === CrazyShoe is now known as Mez | ||
| asac | ogra: is that kind of a special device? | 11:22 |
| asac | e.g. not pci et al? | 11:22 |
| asac | ogra: we opted out managing virtual devices | 11:22 |
| asac | ogra: linux.sysfs_path = '/sys/devices/virtual/net/eth0' (string) | 11:22 |
| c_korn | "if a user is running a fork bomb then other users are not affected at all [CPU scheduling wise], and the admin can log in and disable the user as well.)" | 11:24 |
| cjwatson | I suspect that the problem is that we have cgroup scheduling enabled, but aren't properly setting up cgroups for tasks | 11:24 |
| c_korn | as this seems to be a bigger problem I might open a question in launchpad for the ubuntu kernel | 11:26 |
| asac | cjwatson: did your broadcom driver finally get a proper name or do you still see 'NULL(info.linux.driver)' in the syslog? | 11:26 |
| cjwatson | /var/log/syslog.6.gz:Mar 31 21:00:08 sarantium NetworkManager: <info> (wlan0): new 802.11 WiFi device (driver: 'NULL(info.linux.driver)') | 11:27 |
| cjwatson | asac: ^- | 11:27 |
| asac | sigh | 11:27 |
| asac | ogra: ^^ | 11:28 |
| cjwatson | asac: that said it works fine ... | 11:28 |
| asac | cjwatson: yes. we still carry a patch for that | 11:29 |
| asac | i hoped we could drop it | 11:29 |
| robert_ancell | cjwatson: yes, afaik realize() is not an issue for already realized widgets | 11:31 |
| asac | ogra: can you drop the lp199140_dont_manage_virtual_devices.patch; that whould work; then i need the syslog while it works | 11:33 |
| robert_ancell | cjwatson: re-read your question, yes it will realize any unrealized parents | 11:35 |
| c_korn | I asked a question in launchpad about it: https://answers.launchpad.net/ubuntu/+question/66716 | 11:37 |
| c_korn | thanks for your answers (in this channel) | 11:37 |
| Riddell | asac: how does firefox do its mimetype detection currently? | 11:38 |
| ogra | asac, its ARM ... | 11:38 |
| ogra | asac, there is no publically expo9sed PCI bus on any ARM devices | 11:38 |
| * ogra twiddles thumbs installing the build deps ... | 11:49 | |
| === siretart_ is now known as siretart | ||
| KaiL | siretart, plans for xine-lib 1.1.16.3? It's a security update | 12:15 |
| === thunderstruck is now known as gnomefreak | ||
| siretart` | KaiL: dtchen: I see that darren already has prepared an 1.1.16.3 upload. I'll check with him and merge that in the ubuntu hg branch | 12:23 |
| KaiL | ah, ok | 12:23 |
| RicardoPerez | seb128: hi, the fix for bug #352657 has a nasty side-effect. it's better to remove it or to code another variant of the same fix. I've posted the problem in the bugreport | 12:28 |
| ubottu | Launchpad bug 352657 in evolution-indicator "All the strings from evolution-indicator shows untranslated" [Low,Confirmed] https://launchpad.net/bugs/352657 | 12:28 |
| seb128 | RicardoPerez: hi, I've read your comment on the bug and I don't get the issue there, waiting on ted to be online | 12:29 |
| RicardoPerez | seb128: OK. are you followed the steps to reproduce the new issue? | 12:31 |
| seb128 | no | 12:32 |
| seb128 | I've been too busy for that, I'm waiting for ted as said before | 12:32 |
| RicardoPerez | seb128: ok, thanks for all | 12:33 |
| seb128 | you should relax a bit, the way you pressure one bugs nominating everything for jaunty etc is not helping there | 12:33 |
| seb128 | everybody is busy | 12:33 |
| slytherin | I have a quick question. Rhythmbox has support for using brasero for CD writing. Considering that we have removed nautilus-cd-burner from default install and also totem is using brasero, shouldn't rhythmbox packaging be updated accordingly? | 12:34 |
| seb128 | slytherin: no, it's too late in the cycle for a such technology change | 12:34 |
| RicardoPerez | seb128: yes, sorry about that. I'm not nominating anything since you told me about | 12:35 |
| slytherin | seb128: thought so. Just wanted confirmation. | 12:35 |
| slytherin | seb128: Oh, and I have another specific question related to gst-plugins-base package. How do I stop from i686 getting added to arch list in debian/control file everytime I do debuild -S (lintian gives error about i686)? | 12:36 |
| seb128 | slytherin: though it's easy to test and fedora is doing it already so we might want to consider it | 12:37 |
| seb128 | slytherin: I don't know, I've not been looking to that, we are on sync with debian for this one, does that create any issue? | 12:37 |
| slytherin | seb128: the libasound2-dev build dependency has specific architectures. the list of arch is generated by using output of some command and I always get this problem. I believe the pbuilder will also fail building the package but I didn't try it yesterday. I will try today and let you know. | 12:39 |
| seb128 | slytherin: I doubt it's a stopping error | 12:41 |
| slytherin | seb128: I will check again tonight. | 12:41 |
| slytherin | Although why it should use any architecture list is beyond me. | 12:42 |
| seb128 | it's probably because some things are not available on bsd or hurd for example | 12:42 |
| seb128 | so they need to make a list not including those | 12:43 |
| ogra | asac, ok, works with dropping the patch there are additional deriver issues though | 12:43 |
| slytherin | seb128: but then doing [!bsd !hurd] is easier right? | 12:43 |
| slytherin | anyway, i will check if it fails to build. | 12:44 |
| seb128 | slytherin: not sure why they don't exclude archs only, they use type-handling which does that listing | 12:47 |
| asac | ogra: can you give me a syslog anyway? | 12:47 |
| ogra | will do | 12:48 |
| ogra | asac, attached | 12:50 |
| lamont | Error org.freedesktop.DBus.Error.Failed: Element <syslog> not allowed inside <busconfig> in configuration file | 13:36 |
| lamont | ^^ do we care that the jaunty upgrade from intrepid says that during hal install? | 13:36 |
| === Sikon is now known as LucidFox | ||
| lamont | I'm betting it's transient and because we're mid-upgrade | 13:36 |
| cjwatson | mvo: doc-base aging period waived; copied to -updates | 14:07 |
| cjwatson | slangasek: ^- | 14:07 |
| mvo | cjwatson: thanks! | 14:07 |
| ogra | asac, mind if i assign bug 356517 to NM and milestone it ? | 14:27 |
| ubottu | Launchpad bug 356517 in udev "udev does not detect eth0 on armel" [Undecided,Invalid] https://launchpad.net/bugs/356517 | 14:27 |
| asac | ogra: not sure if its a NM issue. | 14:31 |
| ogra | asac, its works fine if i drop your patch | 14:31 |
| ogra | that will need special casing on arm | 14:31 |
| asac | ogra: well. upstream wouldnt work | 14:31 |
| asac | ogra: drop the NULL patch we also have | 14:31 |
| ogra | as i said above, arm has no PCI bus | 14:32 |
| asac | (which is actually causing the bug that makes the virtual patch fail) | 14:32 |
| ogra | you mean drop both ? | 14:32 |
| ogra | or only the NULL one ? | 14:32 |
| asac | ogra: yes. try to drop both. if it still works that would be good to know | 14:32 |
| ogra | ok, but i urgently need to milestone it else we wont get it past release managers | 14:33 |
| asac | ogra: from what i see now what we need is a way to differentiate between the case we fixed by the virtual device bug and the armel valid virtual ethernet | 14:33 |
| === sabdfl1 is now known as sabdfl | ||
| ogra | well, you know what arch youre on | 14:34 |
| lamont | is there a nice little inotify app (or something) somewhere that will tell me who is modifying _that_ file? | 14:35 |
| lamont | because having both domain and search directives in resolv.conf offends me | 14:36 |
| lamont | mostly because it scares me to have such cluelessness displayed in such a critical file | 14:39 |
| liw | lamont, oh, that's a clever idea: a generic inotify app to catch access to a specific file, I like that | 14:41 |
| Mithrandir | you don't know who did it, though | 14:42 |
| Mithrandir | ps ax in incron for /etc/resolv.conf, maybe | 14:42 |
| lamont | Mithrandir: ew | 14:42 |
| lamont | make it chattr -i resolv.conf and see who screams? | 14:43 |
| lamont | well, +i | 14:44 |
| lamont | mv: cannot move `/etc/resolv.conf.dhclient-new' to `/etc/resolv.conf': Operation not permitted | 14:44 |
| lamont | ^^WINNAR | 14:44 |
| === nturner_ is now known as nturner | ||
| === ubott2 is now known as ubottu | ||
| ogra | asac, without NULL i dont see eth0 in the nm-applet anymore | 15:18 |
| asac | yeah | 15:19 |
| asac | so not supported upstream either | 15:20 |
| ogra | well, all i can say is that it used to work until some days ago | 15:20 |
| asac | i will talk to dan | 15:20 |
| asac | ogra: right. because of the NULL patch which we have in ubuntu to support the broadcom thing | 15:20 |
| asac | so mostly out of luck ;) | 15:21 |
| ogra | can i assign it to NM and milestone ? | 15:21 |
| asac | ogra: well. given that we want to support it, please do | 15:21 |
| ogra | ok :) | 15:21 |
| asac | ogra: please assign to me and set in progress | 15:21 |
| jcastro | I am looking for some openweek volunteers: https://wiki.ubuntu.com/UbuntuOpenWeek/Prep | 15:22 |
| jcastro | holler at me if you have questions | 15:22 |
| ogra | evil Keybuk just left me with a homeless bug :P | 15:23 |
| seb128 | jcastro: when is it? | 15:23 |
| jcastro | seb128: the week after release | 15:23 |
| seb128 | oh ok | 15:23 |
| seb128 | what about getting sleep etc ... ;-) | 15:24 |
| Keybuk | ogra: ? | 15:24 |
| jcastro | seb128: that's what the weekend is for! | 15:24 |
| ogra | Keybuk, just joking, bug 356517 | 15:24 |
| ubottu | Error: Could not parse data returned by Launchpad: Unknown host. (https://launchpad.net/bugs/356517/+text) | 15:24 |
| seb128 | jcastro: DOH, I though those were to catch up on bug emails while IRC is not running ;-) | 15:25 |
| jcastro | seb128: you can do that during the times when you are not doing a session, heh | 15:25 |
| seb128 | heh ;-) | 15:26 |
| Keybuk | ogra: ah, iz HAL bug | 15:26 |
| Keybuk | honestly, I suspect you're not going to get a HAL fix in time for jaunty | 15:26 |
| ogra | Keybuk, hal ? | 15:26 |
| Keybuk | I think so, HAL tends to get grumpy about devices hanging off /computer | 15:26 |
| ogra | Keybuk, its a bunch of bugs ... one is that the driver doesnt detect plug events | 15:26 |
| Keybuk | ICBW though | 15:27 |
| ogra | one other is that NM ignores non PCI NICs | 15:27 |
| Keybuk | is NM ignoring them or is HAL? | 15:27 |
| ogra | lshal has it | 15:27 |
| ogra | and it worked until last week | 15:27 |
| Keybuk | ok | 15:27 |
| Keybuk | I'll shut up then | 15:28 |
| ogra | but indeed lshal has it under computer | 15:28 |
| Keybuk | sure, it's a platform device | 15:28 |
| ogra | since ARM has no publically exposed PCI bus | 15:28 |
| Keybuk | in general, udev has little to do with network interfaces other than renaming them | 15:28 |
| Keybuk | I didn't think ARM *had* a PCI bus | 15:28 |
| ogra | yeah | 15:28 |
| ogra | it does | 15:28 |
| Keybuk | I thought the individual bits of the board were just hardwired into certain bits | 15:28 |
| Keybuk | why don't they expose it then? | 15:28 |
| ogra | but its not accessible from anywhere | 15:28 |
| Keybuk | seems kinda silly | 15:28 |
| ogra | tedg, once told me, i didnt really understand his explanation :) | 15:29 |
| ogra | but apparently there is a PCI bus in the backend thats not exposed anywhere | 15:29 |
| ogra | so you can add the cheap PCI components but hardwire them | 15:29 |
| ogra | (he probably can elaborate on that :) ) | 15:30 |
| tedg | ogra: I was just saying that it could have an on-chip PCI bus. That's relatively common for SoCs. Not sure about those chips specifically. | 15:30 |
| ogra | right | 15:31 |
| ogra | on-chip PCI bus was the term i was missing :) | 15:31 |
| tedg | I worked at Motorola, so we did mostly Motorola proprietary buses across the chips, but I would imagine someone that doesn't have that history would be better off using something they're more familiar with. | 15:31 |
| tedg | You'd be amazed what we could do with a 68K bus :) | 15:31 |
| ogra | well, doesnt gain us much if the HW doesnt expose it | 15:31 |
| ogra | the thing is that nowadays every SW is written with the assumption that HW is PCI or USB ... | 15:33 |
| ogra | and visible to the kernel | 15:34 |
| ogra | through either of these busses | 15:34 |
| agateau | I just figured out a bug in ubuntu installer: when installing from an usb hard drive, a cdrom entry is added to /etc/fstab for the drive, as a result one can't mount any usb harddrive after install has finished | 15:43 |
| agateau | which package should this be reported to? | 15:43 |
| agateau | ubiquity? | 15:43 |
| cjwatson | agateau: no need to re-report it; bug 33512 | 15:44 |
| ubottu | Launchpad bug 33512 in partman-target "Removeable devices shouldn't be put into fstab" [Wishlist,New] https://launchpad.net/bugs/33512 | 15:44 |
| agateau | cjwatson: oh ok | 15:45 |
| agateau | looks old according to bug id | 15:45 |
| cjwatson | agateau: the reason we can't just remove it is that apt-cdrom depends on it (unless that's been fixed recently) | 15:45 |
| cjwatson | it's a very long-standing issue indeed, known at least since hoary | 15:45 |
| agateau | cjwatson: annoying, it really makes first boot experience not as smooth as it could be | 15:45 |
| cjwatson | I know, but the alternative right now is a regression in other cases | 15:46 |
| agateau | cjwatson: ok | 15:47 |
| agateau | i am afraid this will become more common as more people install from usb (think netbook) | 15:47 |
| cjwatson | agateau: I'm painfully aware of the problem | 15:48 |
| agateau | cjwatson: isn't it possible to use "auto" for the filesystem? | 15:48 |
| * agateau has not tried it | 15:49 | |
| cjwatson | agateau: um | 15:49 |
| cjwatson | agateau: it's not the filesystem that changes, it's the device name | 15:49 |
| cjwatson | agateau: the fix is for apt to find CD devices dynamically | 15:50 |
| agateau | cjwatson: in my case: i had no cd device, but it tried to mount my usb stick as iso9660, if fs was set to auto, I guess it would have worked (mounted in /media/cdrom, but it's less naughty) | 15:51 |
| cjwatson | mm, ISTR auto being problematic in some cases though | 15:51 |
| cjwatson | anyway, would rather get it fixed properly | 15:52 |
| agateau | sure, was just trying to figure a workaround for jaunty | 15:52 |
| cjwatson | it's not a regression in jaunty; hardy was used on netbooks as well and has the same problem | 15:53 |
| cjwatson | so given that I *know* that things like language pack installation are excruciatingly sensitive to changes in this area, I'd rather leave it alone for jaunty | 15:53 |
| agateau | yes, but as time passes, more people try ubuntu on netbooks, especially with unr coming | 15:53 |
| cjwatson | for now, I think it's still the case that more people require non-English systems than require netbooks :-) | 15:53 |
| agateau | :) | 15:53 |
| cjwatson | I'm not saying the bug is unimportant; just that incautious changes in this area have a high risk attached to them | 15:54 |
| agateau | i understand | 15:54 |
| agateau | at least i know this is a known bug, if i ever come up with a more clever idea, i'll comment the bug entry | 15:54 |
| cjwatson | I'm sure there's a better bug about this, but I couldn't find it easily | 15:55 |
| agateau | I assume using /dev/scd0 instead of /dev/sdb1 is not a good idea either | 15:55 |
| ogra | isnt that whats currently used ? | 15:56 |
| agateau | ogra: no, my machine had a /dev/sdb1 entry | 15:56 |
| cjwatson | ogra: it's dynamic | 15:56 |
| ogra | ah | 15:56 |
| cjwatson | agateau: if the device had actually been /dev/scd0, I'm sure it would have used that ... | 15:57 |
| cjwatson | bear in mind that device names can be different post-installation from during installation | 15:57 |
| agateau | cjwatson: hmm, yes you are right, in my case I was using a usb stick so /dev/sdb1 was correct at install time | 15:57 |
| === taavikko_ is now known as taavikko | ||
| ArneGoetje | cjwatson: about translations for the Live CD: do we download the new translations from Rosetta and put them into the packages? Who takes care of this? | 16:04 |
| cjwatson | ArneGoetje: I do | 16:04 |
| ArneGoetje | cjwatson: ok. do you have a list of source packages for which we are doing this? | 16:05 |
| cjwatson | ArneGoetje: on the phone, will get back to you | 16:05 |
| ArneGoetje | cjwatson: ok | 16:05 |
| jdong | TheMuso: yeah, I figured Skype would be one of those things; Any particular reason you can think of that CPU usage has regressed significantly since Intrepid+pulse? | 16:09 |
| ebroder | Do the buildds see packages that were just built? Or only packages that have been accepted into the archive? | 16:22 |
| ebroder | (I'm wondering about the failed mpb 1.4.2-12ubuntu1 build - it should have used the libctl 3.0.3-1ubuntu1 that was uploaded shortly before) | 16:24 |
| savvas | I think they have to be in the archive, but I'm generally wrong today so.. wait for another reply :) | 16:26 |
| savvas | #launchpad or #ubuntu-motu people should probably know if no-one replies | 16:27 |
| ebroder | Ok | 16:27 |
| cjwatson | ebroder: build-dependencies have to be not only accepted into the archive, but published | 16:40 |
| ebroder | cjwatson: Huh, ok | 16:41 |
| cjwatson | ebroder: the only short-cut that buildds have is that they fetch files from the master archive, so they can get away with publication not quite being complete (germinate doesn't have to have run, and archive.ubuntu.com doesn't have to have been pulsed) | 16:41 |
| cjwatson | ebroder: but trying to rely on this is difficult unless you have direct access to see exactly what state the system is in | 16:41 |
| cjwatson | you can use versioned build-dependencies to force things | 16:42 |
| ebroder | I did | 16:42 |
| ebroder | "Build-Depends: ... libctl-dev (>= 3.0.3-1ubuntu1) ..." | 16:42 |
| cjwatson | ebroder: in that case, no harm done, it can be retried later | 16:44 |
| ebroder | Ok. Should I ping someone, or will it happen automatically? | 16:44 |
| cjwatson | oh, that's why it failed rather than going to dep-wait as it normally would | 16:45 |
| cjwatson | libctl-dev: Depends: guile-1.6-dev but it is not going to be installed | 16:45 |
| ebroder | Right - the new version changed that dependency | 16:45 |
| cjwatson | ebroder: your sponsor has a retry button; ask whoever it was to poke it in (say) an hour's time | 16:46 |
| ebroder | Thanks - will do | 16:46 |
| cjwatson | actually give it a bit more than an hour, say 1.5 hours for luck | 16:46 |
| ebroder | *nods* | 16:46 |
| mok0 | ebroder: I am responsible for that versioning | 16:47 |
| ebroder | mok0: Oh, hi. Thanks for the sponsorship | 16:49 |
| mok0 | ebroder: I will make sure meep and mbp get built | 16:50 |
| ebroder | Oh hmm...meep probably built successfully against the old libctl-dev. I bet that'll need another upload. Anyway, I'll let you take care of it. Thanks | 16:51 |
| mok0 | ebroder: It failed to build on my sbuilder because of a missing dep, so I assumed it was alright | 16:52 |
| ArneGoetje | cjwatson: do you have a list of source packages, for which you are going to pull translations from Rosetta and put them into the packages directly? I would like to give our translators a notice to focus on those templates until the deadline on 9th. | 16:53 |
| === fader_ is now known as fader|lunch | ||
| cjwatson | ArneGoetje: sorry for the delay. debian-installer/+pots/debian-installer, debian-installer/+pots/help, gfxboot-theme-ubuntu/+pots/bootloader | 17:02 |
| ArneGoetje | cjwatson: that's all? | 17:03 |
| cjwatson | ArneGoetje: with the usual caveat that I only consider those strings in debian-installer/+pots/debian-installer that are specific to Ubuntu - I don't import updates to strings already translated in Debian, since that's a hideous amount of work for me | 17:03 |
| cjwatson | ArneGoetje: yes, that's all. debian-installer/+pots/debian-installer is an aggregated .pot file that gets spread out to lots of other packages | 17:03 |
| cjwatson | and includes e.g. ubiquity | 17:04 |
| ArneGoetje | cjwatson: ok... how about the desktop applications? they are only shipped with language packs? | 17:04 |
| cjwatson | ArneGoetje: right | 17:04 |
| ArneGoetje | cjwatson: ok, thanks | 17:05 |
| cjwatson | technically apt debconf dpkg iso-codes language-selector also need manual updates, but we've never done those for the first four; I don't know if you do something for language-selector | 17:06 |
| cjwatson | if you want me to do that, I have scripts to help me so I can do it if you like | 17:06 |
| cjwatson | (language-selector only, I'd rather not introduce large diffs to the other four) | 17:06 |
| ArneGoetje | cjwatson: hmm... I planned to do language-selector and iso-codes | 17:07 |
| ArneGoetje | cjwatson: the language and country lists in language-selector are taken from iso-codes | 17:07 |
| === njpatel is now known as njpatel_away | ||
| cjwatson | could you please not do iso-codes? | 17:09 |
| cjwatson | I'm concerned that doing that will result in a vast unmergeable diff against Debian | 17:09 |
| cjwatson | that's a case where we really, really need to get translations sent upstream | 17:09 |
| ArneGoetje | cjwatson: okay... so rather push those to upstream? | 17:10 |
| cjwatson | individual translators would need to do that | 17:10 |
| cjwatson | IME if you try to do it centrally you end up trying to mediate disputes between translators in 60 languages you don't speak | 17:10 |
| ArneGoetje | cjwatson: got it | 17:11 |
| cjwatson | we've been synced with Debian on iso-codes for a while, btw | 17:11 |
| cjwatson | I realise it's non-ideal in some ways, but would prefer not to rock that particular boat right before release; iso-codes is used by chunks of the installer too | 17:11 |
| Keybuk | I love the smell of X lock-ups in the morning | 17:13 |
| ArneGoetje | cjwatson: ok, I'll still ask the translation teams to submit their translations for iso-codes back to upstream (alioth), though we won't sync before release anymore | 17:14 |
| lool | seb128: We just noticed that ubiquity was probably failing to reboot with gdm-signal as it used to (it seems it works with "reboot" at the moment); should it be ported to a ConsoleKit call? | 17:15 |
| * jdong angrily kicks fglrx | 17:15 | |
| ArneGoetje | cjwatson: I will also put a note for translators into those templates on Rosetta explaining this. | 17:15 |
| jdong | I'm sorry I didn't pay attention in art class when we talked about picasso, don't punish me for it NOW... | 17:16 |
| lool | seb128: What would be the best way to reboot cleanly after an install? Copy the logic in gnome-session for Restart? | 17:16 |
| seb128 | lool: no, the gdm-signal still works that's what update-notifier is using | 17:16 |
| lool | seb128: It's not installed anymore, is it? | 17:16 |
| seb128 | lool: we didn't switch to the new gdm yet | 17:16 |
| lool | powermanagement-interface ships the gdm-signal bianry | 17:16 |
| ogra | seb128, pmi is gone | 17:16 |
| seb128 | use gdmflexiserver directly? | 17:16 |
| lool | seb128: When I say "gdm-signal" I mean the gdm-signal command-line tool | 17:16 |
| seb128 | let me look at what mvo does in update-notifier | 17:17 |
| lool | seb128: Here I'm using CK I think (I'm logging in with startx), and I think GPM starts the gnome-session dialog which calls into CK I think | 17:17 |
| ArneGoetje | cjwatson: should we set a deadline when we will do the final translation sync from Debian for iso-codes? | 17:17 |
| cjwatson | lool,seb128: sending a dbus call to consolekit looks like a sensible approach to me | 17:18 |
| seb128 | lool: you can do that, you will take the session down the same was than a xorg crash though | 17:18 |
| cjwatson | ArneGoetje: it depends on when Debian chooses to do uploads | 17:18 |
| seb128 | if you use gnome-session you will get cleaner session closing | 17:18 |
| seb128 | and session saving if there is work open | 17:18 |
| cjwatson | use gnome-session in what specific way? | 17:18 |
| lool | seb128: There doesn't seem to be a gnome-session-save reboot option, you mean the gnome-session dbus api? | 17:18 |
| seb128 | there is no dbus api for that | 17:18 |
| cjwatson | remember that ubiquity does not actually start a gnome session in its "Install Ubuntu" mode | 17:19 |
| mvo | seb128: I use the source from gdm-signal in u-n | 17:19 |
| ArneGoetje | cjwatson: well, I mean after what point in a release cycle we won't update that package anymore... | 17:19 |
| lool | cjwatson: good point | 17:19 |
| cjwatson | only when it's started from a full desktop | 17:19 |
| seb128 | right, in the installed context you can use the policykit dbus api | 17:19 |
| lool | cjwatson: However you could try gnome-session and fallback on direct CK, if there's any benefit to that | 17:19 |
| seb128 | but gdm-signal should still be working | 17:19 |
| cjwatson | ArneGoetje: I think, actually, translations would need to be sent upstream; but I'm not certain | 17:19 |
| lool | seb128: it's not installed anymore | 17:19 |
| seb128 | that's what update-notifier uses | 17:19 |
| lool | seb128: Then update-notifier is broken; nothing depends on powermanagement-interface anymore :-/ | 17:20 |
| cjwatson | oh, upstream is pkg-isocodes.alioth.debian.org | 17:20 |
| seb128 | lool: well if it's not and update-notifier using it then we have an issue | 17:20 |
| mvo | lool: u-n is shipping its own copy | 17:20 |
| lool | seb128: Yeah | 17:20 |
| lool | mvo: Oh | 17:20 |
| cjwatson | ArneGoetje: non-language-pack translation deadline would seem sensible | 17:20 |
| cjwatson | powermanagement-interface is in universe now, in fact | 17:20 |
| ArneGoetje | cjwatson: that would be this Thursday. | 17:20 |
| cjwatson | yes | 17:21 |
| seb128 | cjwatson, lool: if you don't care about the session state call the consolekit dbus api | 17:21 |
| seb128 | it's easy and do the job | 17:21 |
| mvo | lool: well, not literatelly building the binary, but shipping the small source-file as part of the u-n source | 17:21 |
| mvo | and calling from u-n into that | 17:21 |
| cjwatson | seb128: certainly don't care about it in "Install Ubuntu" mode | 17:21 |
| lool | I don't think we care about the session; we're rebooting into a pristine home dir in all cases; execpt when using casper persistence and rebooting into the live CD perhaps? | 17:22 |
| cjwatson | seb128: $GNOME_DESKTOP_SESSION_ID says "this-is-deprecated". What's a modern way to tell whether gnome-session is in use? | 17:22 |
| cjwatson | lool: persistence is a valid enough case | 17:22 |
| lool | cjwatson: Can't you check for the dbus service being there? (well call into CK if the gnome-session call fails) | 17:22 |
| ogra_ | why would the gnome-session call fail | 17:23 |
| seb128 | cjwatson: I would do what lool says, query for gnome-session over dbus | 17:23 |
| cjwatson | YM if gnome-session-save --kill --silent returns non-zero? | 17:23 |
| cjwatson | ogra_: if there's no GNOME session | 17:23 |
| lool | ogra_: if it's not running | 17:23 |
| ogra_ | oh | 17:23 |
| lool | cjwatson: I meant the gnome-session dbus call | 17:23 |
| cjwatson | org.gnome.SessionManager.Shutdown or something? | 17:24 |
| cjwatson | that doesn't seem to distinguish between shutdown and restart | 17:24 |
| cjwatson | oh, I should use Logout with mode=2 by the looks of things | 17:25 |
| lool | gsm_logout_supports_reboot() tries CK first and then falls back to GDM | 17:25 |
| cjwatson | I need to set the response to the shutdown dialog up-front | 17:26 |
| ogra_ | what does fusa do btw ? | 17:26 |
| lool | cjwatson: gnome-session should be future proof and backwards compatible: http://paste.ubuntu.com/146297/ | 17:27 |
| lool | This should work with new GDM and our old GDM, with or without CK | 17:27 |
| ogra_ | hmm, update-notifier just does "gdm_set_logout_action(GDM_LOGOUT_ACTION_REBOOT);" | 17:27 |
| lool | That wont work with plain CK | 17:27 |
| ogra_ | no | 17:27 |
| lool | ie next cycle | 17:27 |
| ogra_ | nor with python | 17:27 |
| * ogra_ was under the wrong assumption u-n was python | 17:28 | |
| === ogra_ is now known as ogra | ||
| cjwatson | lool: right, how do I preset the shutdown dialog response though? | 17:29 |
| seb128 | see consolekit_action() in fusa 84_session_management.patch | 17:30 |
| seb128 | on how to use consolekit | 17:30 |
| seb128 | but right, fusa doesn't use the session dialogs | 17:30 |
| seb128 | they just connect the restart action to their own dialog | 17:30 |
| seb128 | you might want to do that | 17:30 |
| lool | cjwatson: Right, it might be easier to talk to gdm or CK directly :-/ | 17:31 |
| cjwatson | but that won't get us session saving | 17:31 |
| lool | No :-/ | 17:31 |
| cjwatson | this is obscenely convoluted :-/ | 17:31 |
| tedg | lool: cjwatson: My understanding is that gnome-session doesn't do session saving on it's own dialog for reboot :-/ | 17:31 |
| seb128 | well you said that you don't care for the installer? | 17:31 |
| lool | cjwatson: You could set the gdm logout action to reboot, then run gnome-session-save --force-logout | 17:31 |
| lool | (if present) | 17:32 |
| seb128 | tedg: that's going to be fixed this week ;-) | 17:32 |
| cjwatson | seb128: no, I didn't | 17:32 |
| seb128 | so just call the ck api | 17:32 |
| davmor2 | pitti: bug 357133 | 17:32 |
| cjwatson | seb128: I said I didn't care about it in "Install Ubuntu" mode (i.e. installer launched directly without a full desktop), but it's valid in the full-desktop case if you're running from a USB stick with persistence | 17:32 |
| ubottu | Launchpad bug 357133 in jockey "Jaunty: Kubuntu jockey applet shouldn't call kdesudo" [Undecided,New] https://launchpad.net/bugs/357133 | 17:32 |
| cjwatson | lool: well, that's pretty much what I used to do | 17:33 |
| cjwatson | but everyone is telling me I should be using dbus now ;-) | 17:33 |
| seb128 | the easier right now is probably what update-notifier does and what lool said | 17:33 |
| pitti | davmor2: I thought I already fixed that | 17:33 |
| cjwatson | clone the gdm-signal code? | 17:33 |
| seb128 | yes | 17:33 |
| lool | cjwatson: Yeah, except it seems the dbus API doesn't seem to allow avoiding the dialogs | 17:33 |
| cjwatson | ok, I can do that | 17:33 |
| seb128 | it's tested and known to work | 17:33 |
| davmor2 | pitti: it is if you call it from the menu this is from the panel applet | 17:33 |
| seb128 | we will work on a clean solution for gnome-session in karmic | 17:34 |
| seb128 | there has been discussion for adding dbus api for those actions | 17:34 |
| cjwatson | though blimey, what a lot of code | 17:34 |
| cjwatson | I think I'd want to convert it to Python and strip it down for convenience | 17:34 |
| pitti | davmor2: oh argh | 17:34 |
| lool | cjwatson: Just FTR, gnome-session talks to the gdm socket directly, it writes 'REBOOT' or something like that; you could either copy gdm-signal's code or do that in ubiquity | 17:34 |
| davmor2 | pitti: If you wait a short time after install you get the applet appear in the panel. If you click on that kdesudo gets called up first | 17:35 |
| cjwatson | yes, the protocol does not look difficult | 17:35 |
| pitti | davmor2: yep, just spotted it in the code, thanks | 17:35 |
| pitti | will care for it | 17:35 |
| davmor2 | 'nps | 17:35 |
| cjwatson | except for having to mess about with authentication | 17:35 |
| cjwatson | hmm, there are no python libxau bindings? | 17:36 |
| lool | As long as we use old gdm, it's probably best to stick to telling it to reboot; so we need one implementation, we could either expose the gnome-session one or copy it in ubiquity; the gnome-session one is only available for live, not for pure install mode :-/ | 17:36 |
| cjwatson | maybe I will have to do this in C then :- | 17:36 |
| cjwatson | :-/ | 17:36 |
| ogra | python-dbus ? | 17:37 |
| seb128 | what did you to do until intrepid? | 17:37 |
| cjwatson | seb128: called gdm-signal | 17:37 |
| ogra | seb128, gdm-signal | 17:37 |
| seb128 | and why does it break now? | 17:37 |
| lool | seb128: not included anymore | 17:37 |
| seb128 | can't we get gdm-signal back on the CD for jaunty? | 17:37 |
| cjwatson | ogra: I'm getting a little tired of the circular conversation ... | 17:37 |
| seb128 | it's tiny | 17:37 |
| cjwatson | it comes with the rest of powermanagement-interface | 17:37 |
| ogra | it could be separated | 17:37 |
| cjwatson | I thought we had tried rather hard to simplify that out | 17:37 |
| seb128 | ok, I think we discussed the options enough | 17:37 |
| lool | Size: 10960 | 17:37 |
| seb128 | my favority would be the update-notifier way | 17:38 |
| cjwatson | ogra: (we'd already discussed the problems with the dbus api above) | 17:38 |
| ogra | seb128, is there any similar python function to gdm_set_logout_action() ? | 17:39 |
| seb128 | anyway as said discussed enough, I think cjwatson knows the option and can decide which one he prefers next | 17:39 |
| seb128 | ogra: not that I know about no | 17:39 |
| cjwatson | I'm happy enough to just clone the code for the moment, as update-notifier does | 17:39 |
| cjwatson | it's not pretty, but will serve | 17:39 |
| seb128 | ok | 17:40 |
| cjwatson | I already have a src/cut-and-paste/ directory for this kind of purpose ;-) | 17:41 |
| mvo | it will all be good with gdm-new and dbus | 17:41 |
| lool | cjwatson: plars opened a bug for the reboot issue we were seeing on babbage | 17:42 |
| mvo | until then "copy-n-paste" | 17:42 |
| lool | cjwatson: i told him to reassign to ubiquity | 17:42 |
| cjwatson | lool: thanks | 17:49 |
| === fader|lunch is now known as fader_ | ||
| pjwaffle | hi | 17:54 |
| liw | hmph, I upgraded to the current intrepid, and now my wired network doesn't work | 18:01 |
| pjwaffle | Hey I am curious why doesn't anyone setup a port for Linux to use the Minix or a BSD kernel... like Debian did | 18:01 |
| seb128 | liw: try jaunty? | 18:01 |
| liw | seb128, the upgrade to current intrepid was in preparation for upgrading to jaunty; now I can't do that, until I fix the network | 18:01 |
| pjwaffle | oops I mean for Ubuntu to use a BSD kernel or Minix | 18:01 |
| liw | hm, looks like udev decide to rename my eth0 to eth1 | 18:02 |
| liw | er, no it didn't, that's my wireless, so that's ok | 18:03 |
| liw | aha, I had 8139cp loaded, rmmod that and modprobe 8139too, and all is well (having both drivers is just silly) | 18:04 |
| LaserJock | pjwaffle: not enough interest so far? | 18:04 |
| alex-weej | asac: https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/349663 - also the reason for the hinting choice not working? | 18:22 |
| ubottu | Ubuntu bug 349663 in fontconfig "debconf options still present but not working" [Low,Triaged] | 18:22 |
| asac | alex-weej: if you mean "debconf hintin choice not working", then yes. | 18:23 |
| Chipzz | pjwaffle: because it REALLY is not as simple as "let's just set up a port. k done" | 18:24 |
| pjwaffle | chipzz: I know but debian did it | 18:25 |
| Chipzz | aside from a different kernel it also involves a different libc. and then incomatibilities ensue | 18:25 |
| Chipzz | *incompatibilities | 18:25 |
| pjwaffle | true | 18:25 |
| Chipzz | you obviously have no idea what you're talking about :) | 18:25 |
| pjwaffle | I know I am still an intermediate user so your right... I was just curious | 18:26 |
| Chipzz | also, what advantage would it have? | 18:26 |
| Chipzz | I doubt anyone would really care for ubuntu running on a freebsd kernel | 18:26 |
| pjwaffle | people who have more experience on BSD or with minix a smaller disc | 18:26 |
| pjwaffle | cover more users | 18:27 |
| Chipzz | no we wouldn't | 18:27 |
| pjwaffle | ive used bsd and there's vast differences | 18:27 |
| Chipzz | people who have more experience with BSD would just... run BSD? | 18:27 |
| === allquixotic_ is now known as allquixotic | ||
| pjwaffle | true but Ubuntu has a big repo and is easy to use | 18:27 |
| Chipzz | it's a niche market | 18:27 |
| Chipzz | and the very small advantage very likely would be no means justify the effort | 18:28 |
| pjwaffle | i guess | 18:28 |
| Chipzz | pjwaffle: for debian it may make more sense because debian has more "power-users" anyway | 18:29 |
| Chipzz | but that's hardly the audience ubuntu is targetting | 18:29 |
| === beuno_ is now known as beuno | ||
| broonie | Well, it's more about people being interested enough to volunteer as anything else. | 18:33 |
| broonie | than, rather | 18:33 |
| === allquixotic_ is now known as allquixotic | ||
| === njpatel_away is now known as njpatel | ||
| liw | sysklogd looks for a symbol matching Version_[0-9]+ in System.map, but Ubuntu (intrepid, jaunty) doesn't seem to include one; Debian (lenny) does; anyone know what's up? | 18:56 |
| === bluesmoke_ is now known as Amaranth | ||
| LordKow | ugh great, i take it removed symbols from a dependency upgrade is quite likely to break reverse depends. vlc 1.0 in jaunty might become impossible unless some changes get reversed | 19:39 |
| LordKow | and im not about to have my ppa bloated with all of these reverse-depends being rebuilt against a new dep | 19:40 |
| calc | LordKow: removing symbols from a library without bumping its soname is a critical bug i think | 19:41 |
| calc | LordKow: what library removed symbols without bumping soname? | 19:42 |
| LordKow | calc, the schroedinger lib has all kinds of symbol issues going on. however, i dont think this applies to the jaunty repos. im trying to bump schroedinger to 1.0.6 (currently at 1.0.5). i'll pastebin the portion of the symbols diff i have right now... i forgot to log the pbuilder output | 19:44 |
| calc | oh i was just wondering if it affected other packages | 19:45 |
| LordKow | calc, what im doing will most definitely but http://pastebin.com/m4615e8aa still seems weird | 19:45 |
| calc | LordKow: if it just affects vlc then someone needs to remind them that library sonames exist for a reason | 19:45 |
| LordKow | i've done lib upgrades before that remove and add symbols but the #MISSING concerns me | 19:45 |
| LordKow | that occurs when rebuilding the current jaunty schroedinger lib (based on 1.0.5) using the 1.0.6 source | 19:46 |
| * calc doesn't know what missing means as opposed to removed | 19:47 | |
| LordKow | exactly, neither do i. | 19:47 |
| LordKow | oh well, maybe it's the same as - without a +... just emphasizing the fact that the symbol is no longer there. | 19:48 |
| LordKow | obviously, any deps that utilize that removed symbol will be broken. | 19:48 |
| calc | yea | 19:49 |
| === zul_ is now known as zul | ||
| LordKow | i guess i'll go back to the vlc source and see if they had a particular reason for bumping the min version of schroedinger to 1.0.6. if they didn't i'll simply reverse it. | 19:49 |
| LordKow | anyways, i think reversing those changes is the only viable option right now to keep vlc 1.0 snapshots usable in jaunty. unless i disable building vlc against the schroedinger lib. dont think i want to do the latter though. | 19:52 |
| kees | asac: can you take a look my patch for bug 352779? this duplicates for n-m the logic in dhcp3's dhclient scripts for MTU handling. | 19:52 |
| ubottu | Launchpad bug 352779 in dhcp3 "Bad MTU for eth0 in 9.04 amd64" [High,In progress] https://launchpad.net/bugs/352779 | 19:52 |
| === beuno_ is now known as beuno | ||
| asac | kees: where did you get that magic barrier from? | 20:01 |
| asac | e.g. 576 | 20:01 |
| kees | asac: it was long-long discussed for the dhcp3 changes | 20:01 |
| kees | asac: basically, 64 is never right, and 576 is only done on locally configured PPP connections where the user wants lower latency over potentially broken networking | 20:02 |
| kees | asac: ultimately, 576 and lower is never right when sent over DHCP | 20:02 |
| kees | asac: the addition of "interface-mtu" to /etc/dhcp3/dhclient.conf (which n-m uses) introduces this issue | 20:03 |
| kees | asac: many weird edge network devices misbehave (sending 64 and 576) when asked for interface mtu | 20:03 |
| kees | asac: especially true, it seems, for ComCast in the US. | 20:04 |
| infinity | kees: Oh, eww, n-m is honoring MTU from DHCP now? | 20:05 |
| kees | infinity: yeah, it seems that way. | 20:05 |
| * infinity is so glad he runs his own DHCP servers most places he connects... | 20:05 | |
| kees | infinity: it's certainly the right thing to do for PPPoE and other stuff, but unfortunately, tons of devices are monsterously stupid. | 20:06 |
| infinity | kees: I'll admit that for PPPoE, I've always just set my own MTU. | 20:07 |
| infinity | kees: And for both PPPoE and PPPoA, I think I've had exactly one provider out of 6 or 7 that actually set a correct MTU via DHCP anyway. :/ | 20:07 |
| kees | infinity: heh | 20:09 |
| slangasek | infinity: "oh eww, n-m is bypassing the dhclient script which handles this and many other things" | 20:10 |
| infinity | slangasek: Heh. | 20:12 |
| asac | kees: committed upstream. thanks! | 20:19 |
| kees | asac: great, thanks! | 20:20 |
| slangasek | darn; I guess that means n-m is still duplicating logic w/ dhcp3-client, and we still don't get samba integration back | 20:22 |
| sabdfl | debian_defaults not up to date? | 20:26 |
| sabdfl | is there a hotlist of "top issues known in the archive"? | 20:26 |
| directhex | coo, a sabdfl | 20:26 |
| sabdfl | one of the many ;-) | 20:27 |
| directhex | not many have gold-plated rocket ships, though | 20:27 |
| jdong | sabdfl: directhex is trying to rewrite the kernel in mono! | 20:28 |
| jdong | *ducks* | 20:28 |
| sabdfl | genius | 20:28 |
| sabdfl | will it run on windows, finally? | 20:28 |
| cody-somerville | I get something like that after the installation of a number of python packages - "INFO: using unknown version '/usr/bin/python3.0' (debian_defaults not up-to-date?)" | 20:28 |
| savvas | jdong: you should direct that to linus :) | 20:28 |
| cody-somerville | I hope that doesn't mean things will start trying to run with python 3.0 | 20:28 |
| jdong | apparently, someone did a CoLinux port of Ubuntu. | 20:28 |
| sabdfl | cody-somerville: yes, i just saw that here too | 20:28 |
| jdong | it'd be better if they published the sources but meh, GPL details ;-) | 20:28 |
| directhex | jdong, why else do you think i'm being shipped to UDS? gotta discuss the port with the kernel people! | 20:29 |
| savvas | cody-somerville: just remove python3.0 :P | 20:29 |
| jdong | directhex: thanks on monodevelop awesomeness btw, is this the first time we've released with an up to date MD stack? :) | 20:29 |
| directhex | jdong, it's not 100% up to date - monodevelop-vala and monodevelop-debugger-* need updating. but they're on git.debian.org and git hates my guts | 20:30 |
| directhex | jdong, thing is, until 2.0 appeared, 1.0 was the most recent stable release. and releasing svn snapshots is a bit :/ | 20:30 |
| mvo | sabdfl: the message is harmless (but anonying) - i will talk to doko what we can do about it | 20:30 |
| jdong | directhex: indeed | 20:31 |
| sabdfl | thanks mvo | 20:31 |
| slangasek | mvo: how can I diagnose why update-manager doesn't want to remove packages to allow ekiga to upgrade? | 20:31 |
| hyperair | directhex: git loves you if you read the manpage ;) | 20:31 |
| slangasek | (apt-get dist-upgrade is perfectly happy doing so) | 20:32 |
| infinity | slangasek: Does apt-get give similar results? | 20:32 |
| infinity | Jinx. | 20:32 |
| mvo | currently, python3.0 is neither in supported nor unsupported nor old current in this debian_defaults file, this is why the message appears. | 20:32 |
| mvo | slangasek: I uploaded a new ekiga with a transitional package that should fix it, probably waiting in binary-NEW ? | 20:32 |
| slangasek | mvo: oh, let me check :) | 20:33 |
| directhex | hyperair, manpages plural. every git command has its own, and those commands have intentionally unhelpful names, to ensure you don't know which manpage to read | 20:33 |
| slangasek | mvo: still, my question was "how can I diagnose" :) | 20:33 |
| mvo | slangasek: hm, but I had the held-back thing for apt-get dist-upgrade too | 20:33 |
| hyperair | directhex: righ right | 20:33 |
| hyperair | directhex: tab completion ftw | 20:33 |
| slangasek | mvo: I see ptlib in NEW, is that what you mean? | 20:33 |
| mvo | slangasek: yes | 20:33 |
| directhex | hyperair, and, of course, doing a simple thing requires multiple commands and multiple manpages | 20:33 |
| hyperair | directhex: well ask hanska, he's our git dictionary | 20:33 |
| slangasek | libpt2.4.2 as a transitional package? that concerns me a bit... | 20:34 |
| hyperair | directhex: depends on how complex you're donig | 20:34 |
| mvo | slangasek: apt-get dist-upgrade should come to the same results, that is the easiest diagnose | 20:34 |
| infinity | Just a bit... | 20:34 |
| hyperair | doing* | 20:34 |
| directhex | hyperair, he's generally only online at weekends during term time. and i don't know where in italy he is - hopefully he hasn't had a house fall on him | 20:34 |
| slangasek | mvo: oh, you're right, it does hold it back, hmm | 20:34 |
| mvo | slangasek: it affects only users running the devel release, we could skip the package or I can try to come up with something else | 20:34 |
| slangasek | mvo: ok, how about 'gnome-keyring', which is the other package I have being held back by update-manager but that apt-get dist-upgrade *will* upgrade? | 20:34 |
| hyperair | directhex: well then you can ask me =D | 20:35 |
| infinity | mvo: That's a pretty ugly-looking transitional package... | 20:35 |
| hyperair | directhex: i'm... less of a dictionary, but i've picked up a fair few things from #git | 20:35 |
| mvo | it is :/ | 20:35 |
| savvas | go on now, git! :p | 20:36 |
| directhex | hyperair, Laney accidentally imported a bz2 as orig for monodevelop-vala. is this an issue? | 20:36 |
| mvo | slangasek: give me a minute, I need to check the source (for the held-back) | 20:36 |
| infinity | mvo: Why is it required, exactly? | 20:36 |
| mvo | slangasek: if the transtional package is too ugly, feel free to reject and we must think of something else | 20:36 |
| hyperair | directhex: no it isn't. | 20:37 |
| hyperair | directhex: just make sure to import the gz | 20:37 |
| slangasek | mvo: well, it is technically incorrect since this transitional package won't provide any of the functionality of libpt2.4.2 | 20:37 |
| hyperair | directhex: if it bothers you much, you can switch to the pristine-tar branch and remove the bz2 files | 20:37 |
| slangasek | and there wasn't even a libpt2.4.2 binary package prior to jaunty, so I wouldn't want to ship with it | 20:37 |
| mvo | infinity: apts scoring algorithm is confused and thinks its better to keep the libpt2.4.2 and hold back ekiga than to go for the new libpt2.6.1 - the root of the problem is that it does not properly consider conflicts/replaces when it calcualtes that score. something I'ma bit hesitant to fix at this point | 20:38 |
| infinity | mvo: Ahh, so it's pretty much that nr_removed == nr_added, and it balks at that? | 20:38 |
| mvo | infinity: yes | 20:38 |
| infinity | mvo: So, artificially lowering the removed count by one (with the transitional package) "fixes" it? | 20:38 |
| infinity | mvo: Ew? :) | 20:38 |
| slangasek | mvo: was the new ekiga in before beta? | 20:38 |
| savvas | anyone taking care of packagekit? | 20:38 |
| slangasek | seems not, binaries were all published Mar 27 or later :( | 20:39 |
| infinity | slangasek: Short of fixing apt, I'm not seeing a way around this. You? | 20:39 |
| directhex | hyperair, i just want monodevelop-vala and monodevelop-debugger-* 2.0 in the archive before jaunty releases. and a beer. i don't really care about the fine detail | 20:39 |
| infinity | slangasek: (I'm still with you on the "ew", though) | 20:39 |
| slangasek | mvo: ah, gnome-keyring is held back only because of gnome-keyring-dbgsym installed here, so please ignore that one | 20:40 |
| mvo | we could add some magic to update-manager to kick it, but it would leave the apt-get users out | 20:40 |
| mvo | slangasek: aha, ok. I think I should still add a --debug option or something to it, just in case | 20:40 |
| hyperair | directhex: what are the outstanding issues? | 20:40 |
| slangasek | infinity, mvo: could the horrible names of the libpt plugins packages be fixed instead? | 20:41 |
| mvo | slangasek: I can look for alternative solutions tomorrow, today I'm not in shape anymore :) | 20:42 |
| slangasek | ok :) | 20:42 |
| slangasek | I'll meditate on this one a bit yet today | 20:42 |
| slangasek | but I've always thought those plugin package names were gratuitously ugly, so maybe we can make the ugliness cancel out | 20:42 |
| infinity | slangasek: While making them unversioned (but with versioned depends) might fix future upgrade issues, I don't see how it would help the current issue. :/ | 20:42 |
| mvo | sure, if you fix it while I'm asleep I send you a virtual cup of finest japanese tea | 20:43 |
| slangasek | infinity: because if we agree the versioned package names are gratuitous, it's not harmful to provide the old package names as transitional packages | 20:43 |
| directhex | hyperair, monodevelop-debugger-gdb: simply needs a new orig, and pushing to the archive | 20:43 |
| infinity | slangasek: Oh, lollerskates, thus satisfying the need to have "extra packages", but doing it with the plugins instead of the library? | 20:44 |
| slangasek | yep | 20:44 |
| infinity | slangasek: Still vile, but agreed that it's slightly less so. | 20:44 |
| ikus060 | Hi, is there any channel for linux developper. I need to do some modification the kernel to have a better support of my keyboard | 20:44 |
| ikus060 | Any suggestion where I should go for help ? | 20:45 |
| directhex | hyperair, monodevelop-debugger-mdb: simply needs a new orig, and pushing to the archive | 20:46 |
| james_w | savvas: I keep an eye on them, what's up? | 20:47 |
| === emgent_ is now known as emgent | ||
| directhex | hyperair, monodevelop-vala: upstream was updated to 2.0 using a bz2 orig - in theory ready to go, as long as we can get a gzip orig from pristine-tar somehow (e.g. revert & re-do using gzipped orig) | 20:49 |
| directhex | hyperair, those are the outstanding issues. no actual work - simply requires "proper" updating rather than me attaching orig/diff to an ubuntu bug & ignoring debian | 20:49 |
| hyperair | directhex: pristine-tar commit /path/to/orig.tar.gz | 20:50 |
| hyperair | directhex: make sure you name your .orig.tar.gz correctly | 20:50 |
| savvas | james_w: sorry for the delay, my mouse broke :) could someone take a look at bug 347327 ? packagekit can't handle unicode folder (and perhaps file?) names when a user tries to install .deb files | 20:52 |
| ubottu | Launchpad bug 347327 in packagekit "crashes when installing packages from non ascii folders" [Medium,Confirmed] https://launchpad.net/bugs/347327 | 20:52 |
| james_w | savvas: yeah, I saw it | 20:52 |
| directhex | hyperair, okay, and next? | 20:53 |
| hyperair | directhex: that should be it. try git buildpackage | 20:53 |
| savvas | james_w: it's really not that super-important, but Desktops are allowed to be localized with unicode, would be nice to get it fixed :) | 20:53 |
| james_w | savvas: sure, would be nice | 20:53 |
| hyperair | directhex: if you've import-orig'd before, it won't import again because there are no changes, so basically you have to pristine-tar commit it manually. | 20:53 |
| james_w | savvas: it's not on my list to try and fix for jaunty. I would happily sponsor a fix though | 20:53 |
| savvas | james_w: ok, I'll check it out during the weekend, maybe I still have some luck left after python transition :) | 20:55 |
| james_w | heh :-) | 20:55 |
| directhex | hyperair, and the cure for "fatal: The remote end hung up unexpectedly"? | 20:58 |
| hyperair | directhex: the cure is to fix the server. | 20:59 |
| hyperair | there should be another message before that | 20:59 |
| directhex | o_o | 20:59 |
| directhex | directhex@desire:~/Projects/pkg-mono-git/monodevelop-vala$ git push | 20:59 |
| directhex | fatal: The remote end hung up unexpectedly | 20:59 |
| hyperair | directhex: git remote | 21:03 |
| directhex | directhex@desire:~/Projects/pkg-mono-git/monodevelop-vala$ git remote | 21:03 |
| directhex | origin | 21:03 |
| hyperair | git config remote.origin.url | 21:03 |
| hyperair | are you sure it's right? | 21:04 |
| hyperair | directhex: ^ | 21:04 |
| savvas | is there a way to see the type of character codec for python text strings? to show if it's ascii or utf-8? | 21:04 |
| directhex | git://git.debian.org/pkg-cli-apps/packages/monodevelop-vala.git | 21:05 |
| hyperair | directhex: i don't think you can push to that. | 21:05 |
| hyperair | directhex: you need to push through ssh. | 21:05 |
| directhex | sigh. GIT IS CONVENIENT AND EASY! | 21:05 |
| * directhex mails cake to Keybuk | 21:05 | |
| hyperair | directhex: yeah it is, if you know how to use it. | 21:05 |
| hyperair | no wait, noone said it's easy. | 21:06 |
| hyperair | it's got a hell of a learning curve | 21:06 |
| hyperair | kinda like gnu screen and vim | 21:06 |
| hyperair | they're awesome stuff but you need to figure them out first | 21:06 |
| iulian | You need to write good configs. | 21:07 |
| savvas | ..and until you do, some other guy is using gedit and happily creates 100 lines of working, tested code :P | 21:07 |
| hyperair | directhex: if you checked out using svn:// you wouldn't be able to commit would you? | 21:07 |
| hyperair | lol | 21:07 |
| hyperair | savvas: you never know when you have to edit some config files on some random remote server =) | 21:07 |
| directhex | hyperair, and because you use debian on them, you have nano! | 21:07 |
| savvas | ah that | 21:08 |
| cody-somerville | I love gedit :) | 21:08 |
| iulian | vim ftw. | 21:08 |
| hyperair | i love geany. | 21:08 |
| savvas | hyperair: I think I can still open it with gedit using gnome's backend for sftp/ftp :) | 21:08 |
| directhex | ed. the one true editor | 21:08 |
| hyperair | directhex: sed. | 21:08 |
| hyperair | better yet, cat. | 21:09 |
| hyperair | cat is the ultimate editor. | 21:09 |
| hyperair | savvas: that's assuming the remote ssh server supports sftp | 21:09 |
| hyperair | savvas: my router doesn't have sftp though it has ssh | 21:09 |
| directhex | butterflies! | 21:09 |
| hyperair | wut | 21:09 |
| savvas | scp then :p | 21:11 |
| savvas | or I'll eventually stop giving ideas and use pico lol | 21:11 |
| hyperair | hahah | 21:11 |
| hyperair | there isn't a nano on my router ;) | 21:12 |
| savvas | you and your router | 21:12 |
| hyperair | yes, me and my router =p | 21:12 |
| savvas | you know where you can put it - on the shelf for "lost and never meant to be found" :P | 21:13 |
| hyperair | physically never be found ;) | 21:13 |
| hyperair | i'll leave it connected | 21:14 |
| hyperair | my internet connection is on the line here! | 21:14 |
| * savvas inverts the hacker symbol and cracks the router with vim.. and a hammer | 21:15 | |
| hyperair | read-only filesystem. | 21:15 |
| hyperair | =D | 21:15 |
| hyperair | vim can't damage a router | 21:15 |
| savvas | hammers are always handy! | 21:16 |
| hyperair | not if you can't find it physically | 21:16 |
| savvas | what's your address again? :p | 21:16 |
| hyperair | my ip address? whois me and find out =p | 21:17 |
| ion_ | hyperair: Who stole your reverse? | 21:19 |
| hyperair | ion_: reverse? | 21:19 |
| ion_ | The hostname an IP address maps to | 21:20 |
| hyperair | ask the network admins in my uni =p | 21:20 |
| === rbelem is now known as rbelem_afk | ||
| seb128 | does anybody knows how to easily recreate a stock grub menu.list configuration? | 21:40 |
| mkrufky | make distclean | 21:41 |
| mkrufky | make menuconfig | 21:41 |
| seb128 | no, the grub menu that you get after installation | 21:42 |
| seb128 | ie make it look at the available linux image and list those and other installs which are detected on other disks too | 21:42 |
| mkrufky | im sorry, you said GRUB menu | 21:43 |
| mkrufky | my bad | 21:44 |
| mkrufky | lol | 21:44 |
| hyperair | lol | 21:44 |
| hyperair | update-grub. | 21:44 |
| mkrufky | its my fault -- i thought this was #linuxtv .... | 21:44 |
| * mkrufky hides | 21:44 | |
| hyperair | seb128: ^ | 21:44 |
| seb128 | upgrade-grub will keep your local changes | 21:44 |
| hyperair | seb128: delete it first | 21:44 |
| seb128 | I want to wipe it for a clean version | 21:44 |
| seb128 | ok, easy enough | 21:44 |
| hyperair | mmhmm | 21:44 |
| hyperair | then update-grub gives you a stock one | 21:45 |
| seb128 | it seems to not list other installs | 21:46 |
| seb128 | only linux images on the current distro | 21:46 |
| seb128 | I've an intrepid install on an another disk and it's not there from a quick glance | 21:46 |
| hyperair | you have to share the /boot i think. | 21:47 |
| seb128 | there is no way to do whatever the installer do? | 21:47 |
| hyperair | no wait that is a bad idea | 21:47 |
| hyperair | hmm | 21:47 |
| hyperair | i'd just add an entry manually. | 21:48 |
| hyperair | like chainloader +1 kinda thing | 21:48 |
| slangasek | seb128: detecting foreign OSes is done via udebs in the installer, so no, no easy way to reproduce that from an installed system; OTOH, there are various bugs that result from trying to incorporate those boot entries directly, instead of just chainloading as hyperair mentions | 21:53 |
| seb128 | slangasek: ok thanks | 21:55 |
| RAOF | seb128: And grub2 uses the output of os-prober to automatically generate those items, but that's obviously not terribly useful if you're not using grub2. | 21:58 |
| === yofel_ is now known as yofel | ||
| Keybuk | directhex: cake is bad | 22:10 |
| directhex | Keybuk, even if it's delicious & moist & not git? | 22:11 |
| Keybuk | especially then | 22:11 |
| * Keybuk does not want to become a tubbers | 22:12 | |
| cody-somerville | I'll eat the cake. | 22:13 |
| ion_ | The cake is a lie. | 22:14 |
| cody-somerville | I was afraid of that. | 22:15 |
| slangasek | mmm, lye cake | 22:17 |
| slangasek | infinity: or, we could just remove libpt2.6.1's Conflicts: on libpt2.4.2, which is incorrect | 22:26 |
| infinity | slangasek: Oh, they have no file conflicts? | 22:27 |
| slangasek | nope | 22:27 |
| infinity | slangasek: In that case, the old lib just ends up orphaned, autocleaned, and problem solved... | 22:27 |
| slangasek | yep | 22:27 |
| infinity | slangasek: Why was mvo trying to force the removal, I wonder? | 22:27 |
| slangasek | it wasn't his idea :) | 22:28 |
| slangasek | he was just trying to clean up the update-manager problem | 22:28 |
| infinity | slangasek: Oh, inherited from upstream maintainer? | 22:28 |
| slangasek | no, inherited from the person who packaged the new upstream version of ptlib | 22:28 |
| slangasek | cp debian/in/$(PACKAGE)-00list debian/patches/00list | 22:29 |
| * slangasek swears at the octave3.0 maintainer | 22:29 | |
| slangasek | as if using dpatch wasn't annoying enough to begin with | 22:30 |
| slangasek | let's just clobber the changes on every rebuild, hurray | 22:30 |
| LordKow | so how easy/not easy is it to fork a lib and allow it to co-exist with the one in the jaunty repos? I remember a ppa doing it with the kde libs for amarok2 in intrepid. the key would be making sure the rev deps that should use the one in the jaunty repos continue to do so while only a specific package utilizes the forked-libs | 22:39 |
| === Snova_ is now known as Snova | ||
| larsivi | I get version conflicts for OOo in jaunty - is that something that is well known and scheduled for fixing? | 22:45 |
| seb128 | is xvfb-run known to be broken? | 22:48 |
| seb128 | $ xvfb-run ls | 22:48 |
| seb128 | [: 182: Illegal number: | 22:48 |
| seb128 | xvfb-run: error: display :99 already in use | 22:48 |
| === rbelem_afk is now known as rbelem | ||
| Laney | At the risk of being rude, can someone look at bug 356612? It fixes a regression in automake and blocks an upload I need to make | 22:58 |
| ubottu | Launchpad bug 356612 in automake1.10 "Regression vs 1.10.1: depfiles problem causes some source packages to ftbfs now" [Undecided,Confirmed] https://launchpad.net/bugs/356612 | 22:58 |
| hyperair | why risk of being rude? | 22:58 |
| Laney | prodding sponsors | 22:59 |
| seb128 | Laney: I would but I've no enough clue about automake to review that | 22:59 |
| Laney | well it's just a backport from upstream but yeah, fair enough | 22:59 |
| seb128 | try to get Keybuk or slangasek to look at it | 23:00 |
| Laney | that should have hilighted them ;) | 23:00 |
| * Keybuk is a conference this week | 23:01 | |
| Keybuk | AT a conference | 23:01 |
| ion_ | ATH0 a conference | 23:03 |
| slangasek | calc: any more interesting bugs on OOo? | 23:05 |
| calc | slangasek: not yet, it looks like OOo might be safe to upload RSN :) | 23:06 |
| slangasek | how soon is that? | 23:07 |
| calc | and no response from the catalan people about their buggy file | 23:07 |
| calc | either later tonight or tomorrow morning (is that ok?) | 23:07 |
| slangasek | yeah, that works | 23:08 |
| calc | ok | 23:08 |
| seb128 | slangasek: does "xvfb-run ls" works for you? | 23:09 |
| seb128 | Keybuk: if you can write on IRC you can probably have a quick look to a sponsoring request and ack an upstream backport too ;-) | 23:10 |
| slangasek | calc: did you see that sparc failed with a different compiler error this time? | 23:10 |
| slangasek | calc: might be advantageous to get OOo uploaded right now, if we're having a carnival of build failures | 23:10 |
| slangasek | otherwise, you should plan to just drop sparc completely in the next upload so that it's not hanging over our heads | 23:10 |
| slangasek | seb128: don't have it installed; I can have a look | 23:11 |
| calc | yea seems sparc fails differently each time but works fine for debian :-\ | 23:11 |
| seb128 | slangasek: would be nice, I want somebody to confirm if it's broken or if I've a local issue | 23:11 |
| slangasek | calc: well we clearly don't have an identical source package and we know we don't have the same default compiler options on the buildd; so the fact that it works fine for Debian doesn't mean there aren't OOo bugs here... | 23:14 |
| slangasek | seb128: confirmed the failure here | 23:14 |
| Keybuk | seb128: no, because that involves getting to launchpad | 23:14 |
| Keybuk | which has so far timed out three times in a row for me ;) | 23:14 |
| seb128 | slangasek: I've opened bug #357338 if you want to milestone it | 23:14 |
| ubottu | Launchpad bug 357338 in xorg-server "xvfb-run broken in jaunty using dash" [High,New] https://launchpad.net/bugs/357338 | 23:14 |
| seb128 | slangasek: it breaks builds using xvfb-run | 23:14 |
| seb128 | or rather target it for jaunty | 23:15 |
| * slangasek nods | 23:15 | |
| seb128 | thanks | 23:17 |
| Ampelbein | hi there! could someone look at bug 352653 . It's a minor packaging issue and I wonder if the information provided is enough for a FreezeException? | 23:24 |
| ubottu | Launchpad bug 352653 in coherence "python-coherence: /usr/share/dbus-1/services/org.Coherence.service should be included" [Low,Triaged] https://launchpad.net/bugs/352653 | 23:24 |
| calc | ugh i'm still getting new bugs on gutsy | 23:27 |
| * calc told the users to just test out jaunty and upgrade if it works, heh | 23:28 | |
| ScottK | Ampelbein: There was a new coherence upload in Debian today. Did that (by chance) fix this bug? | 23:28 |
| Ampelbein | ScottK: I'll check that, thanks for the pointer. | 23:28 |
| ScottK | No problem. | 23:29 |
| directhex | calc, tell them to try karmic! | 23:30 |
| slangasek | ArneGoetje: there are a number of new gnome-user-guide-$ll packages added in the latest upload; could those get added to the dependencies of language-pack-gnome-*? | 23:31 |
| Ampelbein | ScottK: no, this did not get fixed. the services-file is still not provided. should i file a bug in debian, too and link it? | 23:33 |
| seb128 | the debian maintainers know about that | 23:33 |
| seb128 | I mailed him a week ago and he replied that somebody else was looking at the issue | 23:33 |
| seb128 | I will try pinging him again, you don't need a freeze exception for bug fixes yet though, just subscribe sponsors | 23:34 |
| Ampelbein | ok, done that already. thanks. | 23:35 |
| slangasek | "Grep'ing the whole file is not good either: AIX grep has a line limit of 2048" | 23:40 |
| slangasek | >_< | 23:40 |
| ion_ | The following people find AIX grep relevant: | 23:42 |
| sladen | cjwatson: what's the status of debs with a .tar.lzma ? Are they allowed in the archive/soyuz (lintian is complaining) | 23:42 |
| seb128 | slangasek: ok, your new comment is sort of what I suggested in the bug description ;-) | 23:45 |
| slangasek | seb128: yeah. :) | 23:46 |
| seb128 | slangasek: that's not the only issue though, I've changed it to use bash just to try and it still breaks on "display already used" | 23:46 |
| seb128 | when called several times | 23:46 |
| slangasek | doh | 23:46 |
| seb128 | I would suggest just dropping the change from the previous upload for jaunty | 23:46 |
| slangasek | that's fair | 23:47 |
| slangasek | Laney: automake sponsored | 23:47 |
| Laney | slangasek: woo! Thanks a bunch | 23:47 |
| seb128 | I will wait for bryce to comment on the bug though maybe he can fix it easily | 23:47 |
| bryce | seb128: already dropped | 23:48 |
| seb128 | bryce: thanks | 23:49 |
| bryce | seb128: I don't care enough about xvfb to try fixing it | 23:49 |
| seb128 | bryce: I don't care either as long as I can still build pygtk ;-) | 23:49 |
| bryce | besides I'd probably just break it some other way in the process (it's not my patch originally, just sponsored from a contributor) ;-) | 23:49 |
| seb128 | right, let's go back to a known situation for jaunty | 23:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!