| arcticpenguin380 | why isnt reiser4 in ubuntu | 00:31 |
|---|---|---|
| cjwatson | because it is not upstream, and it is not compelling enough to develop the local expertise that would be necessary to integrate and support it ourselves in the absence of support from the main kernel developers | 00:32 |
| cjwatson | if and when it is integrated into mainline Linux, we'll almost certainly include it | 00:33 |
| arcticpenguin380 | ext4 is in the kernel but not avalibalbe for installation | 00:34 |
| mjg59 | arcticpenguin380: ext4 is not guaranteed to maintain a consistent on-disk format yet | 00:35 |
| mjg59 | Until that's guaranteed, we can't offer it for installation | 00:35 |
| === Traxer is now known as Traxer|on | ||
| === Traxer|on is now known as Traxer | ||
| === greeneggsnospam is now known as jsgotangco | ||
| mwolson | maintainer of the emacs22 package speaking | 02:32 |
| mwolson | would a main sponsor be willing to act on Bug #172389, which has had a new version languishing for 4 weeks? | 02:32 |
| ubotu | Launchpad bug 172389 in emacs22 "Please upload emacs22 22.1-0ubuntu10" [Undecided,Fix committed] https://launchpad.net/bugs/172389 | 02:32 |
| mwolson | the patch attached there fixes a handful of other bug reports in addition to that particular one | 02:32 |
| MacSlow | how can one force a autoreconf if a new option for configure has been introduced? | 04:06 |
| TheMuso | MacSlow: Depends on how the package gets built now. | 04:08 |
| TheMuso | There is the autoreconf command, which might help in what you want to do. | 04:08 |
| MacSlow | TheMuso, I know how to do it all "outside" of dpkg with the normal upstream codebase | 04:09 |
| MacSlow | TheMuso, but I want to avoid adding the diff to the configure file to a debian/patch/foo_bar.patch | 04:10 |
| MacSlow | I just added the diff to the configure.in | 04:10 |
| MacSlow | and added a one-line diff to the debina/rules file | 04:10 |
| MacSlow | but during "dpkg-buildpackage -rfakeroot" configure is not automatically recreated (thinking of it, it makes sense that it's not recreated) | 04:11 |
| crimsun | I presume you're passing -f. | 04:11 |
| MacSlow | no | 04:12 |
| MacSlow | crimsun, would that need to be passed to dpkg-buildpackage?! | 04:12 |
| crimsun | (to autoconf) | 04:12 |
| mwolson | thanks to whoever just uploaded emacs22 22.1-0ubuntu10; it is much appreciated | 04:17 |
| crimsun | mwolson: yw. | 04:17 |
| MacSlow | crimsun, there's no autoconf-related dh_something command or is there? | 04:23 |
| crimsun | MacSlow: not AFAIK. | 04:24 |
| crimsun | I certainly don't claim to be an authority on debhelper, however. | 04:24 |
| MacSlow | so there's no way around adding the diff to configure itself?! | 04:25 |
| TheMuso | No I don't think there is any dh magic to help. | 04:25 |
| MacSlow | damn | 04:25 |
| crimsun | MacSlow: well, err, what I've done in the past is use "autoreconf -f" [or "autoconf -f"] | 04:25 |
| MacSlow | crimsun, I know about that | 04:26 |
| crimsun | it does bloat your Build-Depends, but it has always worked for me. | 04:26 |
| MacSlow | I just wanted to avoid doing this bigger delta to upstream | 04:26 |
| MacSlow | but I hate taht | 04:26 |
| MacSlow | that | 04:26 |
| === awalton__dos is now known as awalton__ | ||
| === lando__ is now known as lando | ||
| MacSlow | a ~3000 line diff just for a newer version of the configure file | 04:37 |
| MacSlow | *spew³* | 04:37 |
| RAOF | MacSlow: Isn't autotools wonderful? :( | 04:43 |
| MacSlow | RAOF, well it's more me "fighting" with the deb-tool infrastructure | 04:44 |
| * MacSlow regrets not being a seasoned MOTU à la seb128, dholbach & Co | 04:44 | |
| === greeneggsnospam is now known as jsgotangco | ||
| RAOF | It would be rather nice to have a dh_autoconf or somesuch; basically a special-cased patch system. | 04:45 |
| RAOF | Because you'd like the build to be repeatable as possible, so you don't particularly want to autoreconf during package build, but it's really ugly to have the huge diffs. | 04:47 |
| === asac_ is now known as asac | ||
| tjaalton | mjg59: hey, will you push the DIX patch upstream? | 07:40 |
| soren | pitti: Archive day today? | 07:41 |
| mjg59 | tjaalton: Which one? | 07:42 |
| mjg59 | tjaalton: Oh, the scaling one? It's in bugzilla already | 07:42 |
| tjaalton | mjg59: the one that stevenk applied on xserver | 07:42 |
| mjg59 | I didn't write it :) | 07:42 |
| tjaalton | ah | 07:42 |
| tjaalton | which bug? | 07:42 |
| mjg59 | Hm. | 07:43 |
| tjaalton | right, it was "from", not "by" :) | 07:43 |
| mjg59 | Don't have it to hand, I'm afraid | 07:43 |
| tjaalton | ok, I'll dig it up | 07:43 |
| tjaalton | mjg59: you mentioned a while ago that synaptics needs some love.. any news on that? | 07:44 |
| mjg59 | Still working on the Xi code for that | 07:44 |
| tjaalton | ok | 07:45 |
| dholbach | good morning | 07:55 |
| Hobbsee | morning dholbach | 07:56 |
| dholbach | hey Hobbsee | 07:56 |
| * Hobbsee sigh | 08:00 | |
| Hobbsee | please do *not* run cron.daily when i'm not at dinner! | 08:00 |
| pitti | Good morning | 08:03 |
| pitti | soren: archive day> yes | 08:03 |
| pitti | hendrixski: sure, see first paragraph of https://wiki.ubuntu.com/DebuggingProgramCrash | 08:04 |
| Hobbsee | morning pitti! | 08:06 |
| pitti | hey Hobbsee | 08:09 |
| * pitti waves to dholbach, too | 08:10 | |
| * Hobbsee hugs pitti | 08:10 | |
| * pitti tickles Hobbsee | 08:10 | |
| * Hobbsee stomps on pitti's feet | 08:10 | |
| === carlos_ is now known as carlos | ||
| * pitti jumps away in time and steals the long pointy stick | 08:11 | |
| pitti | hey carlos! | 08:11 |
| carlos | pitti: hi | 08:11 |
| Mithrandir | Hobbsee: you're aware that cron.daily is supposed to run at like 0600 in the morning? At which point you should not be at dinner. | 08:12 |
| Hobbsee | Mithrandir: yeah, but the laptop is never on then, so i'm expecting it runs when it gets turned on | 08:12 |
| * pitti sighs at new -- 223 items | 08:13 | |
| warp10 | Good morning | 08:16 |
| Mithrandir | pitti: if you do two of those, there'll only be 221 left! :-) | 08:17 |
| pitti | Mithrandir: hey -- I should've thought of that! | 08:18 |
| pitti | good morning warp10 | 08:18 |
| warp10 | Hey pitti! | 08:18 |
| Mithrandir | pitti: and then you can do two more and there'll only be 219 left. And so on. :-P | 08:18 |
| pitti | hm, seems that nobody else processed NEW during the week :/ | 08:18 |
| soren | Hm... Do I want "Intel 3945ABG Wireless Card" or "Dell Wireless 1505 802.11a/g/n" ? | 08:26 |
| Hobbsee | the former | 08:26 |
| thegodfather | probably intel | 08:26 |
| seb128 | pitti: I didn't but I can give you a hand on it today | 08:26 |
| RAOF | Performance or guaranteed-working. Choices... :) | 08:27 |
| seb128 | any thunderbird user around? | 08:27 |
| thegodfather | soren: 11n is still in draft | 08:27 |
| soren | pitti: Which one did you get in your Dell? | 08:27 |
| Hobbsee | seb128: yeah | 08:27 |
| thegodfather | soren: not a full RFC/standard/spec | 08:27 |
| soren | thegodfather: That's a good point. | 08:27 |
| * Hobbsee --> dinner | 08:27 | |
| seb128 | I'm probably missing something obvious, but how do I update the messages counts? | 08:27 |
| pitti | soren: I have the 3945 | 08:27 |
| soren | pitti: And you're happy? | 08:27 |
| pitti | soren: I had the alternative of a 4965 | 08:27 |
| pitti | soren: it's working fine, at least with the gutsy kernel | 08:28 |
| Hobbsee | soren: iwl3945 seems to work fine. | 08:28 |
| Hobbsee | on hardy | 08:28 |
| pitti | soren: the iwl3945 driver (hardy) has troubles with my home's wifi | 08:28 |
| seb128 | like evolution does on send&receive | 08:28 |
| soren | Oh. It says the 4965 is only for Core Solo. | 08:28 |
| seb128 | to know which folders have unread mails | 08:28 |
| pitti | soren: but it worked fine for all wifis in London | 08:28 |
| soren | pitti: Interesting. | 08:28 |
| seb128 | pitti: what sort of issue? | 08:28 |
| soren | pitti: Yours is the Latitude D430? | 08:29 |
| pitti | soren: once I do have a connection, it works fine here, too | 08:29 |
| seb128 | nm0.7 doesn't work on my home wifi, I had to downgrade to 0.6 | 08:29 |
| seb128 | using my d630 | 08:29 |
| pitti | but often it doesn't see the essid | 08:29 |
| seb128 | it was working fine in london | 08:29 |
| pitti | so it takes some rounds of rmmod/modprobe/sudo iwlist scanning until it works | 08:29 |
| pitti | soren: d430, yes | 08:29 |
| soren | erk | 08:29 |
| Hobbsee | seb128: are you subscribed to the folders? | 08:30 |
| Hobbsee | seb128: oh, change mail.check_all_imap_folders_for_new to true, in about:config | 08:31 |
| Hobbsee | and make sure you're subscribed to the folders you want | 08:31 |
| seb128 | Hobbsee: ok, no wonder people think thunderbird is faster if it doesn't update anything :-p | 08:31 |
| Hobbsee | :P | 08:31 |
| pitti | soren, seb128: nm0.7 works well here (same as 0.6) | 08:33 |
| MacSlow | seb128, any idea how to force "dpkg-buildpackage -rfakeroot" regenerate configure from configure.in, which is altered by an included patch? | 08:55 |
| seb128 | urg? | 08:56 |
| seb128 | cdbs-edit-patch 90_autoconf_update | 08:56 |
| seb128 | autoconf | 08:56 |
| seb128 | rm -rf autom4te.cache | 08:56 |
| seb128 | ctrl-D | 08:56 |
| MacSlow | seb128, I want to avoid addint a ~3000 lines diff to my patch just for having --enable-gconf be used | 08:56 |
| seb128 | run autoconf usually is not that much change | 08:56 |
| seb128 | we do it for lpi in lot of packages | 08:56 |
| pitti | (provided that you use the same autoconf version) | 08:56 |
| MacSlow | pitti, seb128: well I'm on current hardy here | 08:57 |
| seb128 | that doesn't matter | 08:57 |
| MacSlow | ? | 08:57 |
| seb128 | using the same autoconf than upstream does the diff smaller | 09:00 |
| seb128 | but you don't care about 30 lines or 3000 lines changes | 09:00 |
| seb128 | that's still small in the diff.gz | 09:00 |
| MacSlow | I could live with 30, but not with 3000 | 09:01 |
| seb128 | why not? | 09:02 |
| seb128 | don't look at the GNOME packages in ubuntu and debian then | 09:03 |
| MacSlow | Ok I won't :) | 09:03 |
| seb128 | we have many autoreconf patches with ten of thousand lines of changes | 09:03 |
| MacSlow | I try to keep patches comphrehendable | 09:03 |
| seb128 | that's just running autoconf there and doing a patch with the changes, what is the issue, | 09:03 |
| seb128 | 90_autoconf_update is a patch with autoconf update as indicated by the name | 09:03 |
| seb128 | who would like to read that? | 09:04 |
| seb128 | that's the reason why we split the code change and the autoconf run | 09:04 |
| seb128 | you have your small patch for changes you wrote | 09:04 |
| seb128 | and one for the autotools update that nobody read, they just know that's an autoconf call to update | 09:04 |
| MacSlow | hm... well for two days now I'm trying to get the patch into shape so I can hand it over to you, mvo or pitti for uploading | 09:05 |
| MacSlow | and I still don't know how to make sure the new strings will show up for translation in LP | 09:05 |
| seb128 | just ask on IRC if you are blocked, I'm happy to help you | 09:05 |
| MacSlow | there's no .pot file anywhere in libwnck-2.21.90 | 09:06 |
| seb128 | easy enough, just make sure the file with the strings is listed in po/POTFILES.in | 09:06 |
| MacSlow | it is | 09:06 |
| mvo | MacSlow: if you pass the patch to one of us and tell about the outstanding issues, we are happy to help getting around those packaging issues | 09:06 |
| seb128 | the pot are created at build by running intltool-update -p usually | 09:06 |
| MacSlow | it's not adding new source files... just adding some strings in existing sources | 09:06 |
| seb128 | cdbs does that for you | 09:06 |
| seb128 | just build and look after the build to the po directory | 09:06 |
| seb128 | if you have _() correctly around those they will be translatable | 09:07 |
| MacSlow | well the build does not work (incorporate my changes, due to the --enable-gconf not being applied to configure) | 09:07 |
| MacSlow | seb128, I know how to use all the gettext stuff in the upstream-land... but getting that "through" the debian-tool-chain-infrastructure is... *sigh* | 09:08 |
| seb128 | MacSlow: come on, there is nothing to do, just build your package and look to po/ and the pot is there | 09:09 |
| seb128 | MacSlow: and for the configure update I gave you the exact commands to type 15 minutes ago | 09:10 |
| seb128 | MacSlow: anyway I'm happy to do the packaging changes and check that the template is correctly updated, just send me the patch you have with the corresponding bug number | 09:11 |
| MacSlow | seb128, ok verified that the libwnck.pot does have the newly introduced strings | 09:13 |
| MacSlow | trying the configure-stuff now | 09:13 |
| TheMuso | pitti: Nothing seemed to change for me re jockey. I even removed the firmware, and the driver didn't end up spewing firmware needed dmesg output. | 09:13 |
| pitti | TheMuso: changed> it doesn't detect and show the driver for you? | 09:14 |
| TheMuso | pitti: Not in the window, nothing is listed. | 09:15 |
| pitti | TheMuso: ok; can you please send me jockey-gtk --debug --list output again? | 09:16 |
| TheMuso | pitti: Ok. | 09:16 |
| MacSlow | seb128, hm... compilation currently fails due to not foudn gconf-includes... trying to figure out why | 09:29 |
| seb128 | MacSlow: where is your patch. | 09:30 |
| seb128 | ? | 09:30 |
| MacSlow | seb128, for libwnck-2.21.90... http://people.ubuntu.com/~mmueller/changelog http://people.ubuntu.com/~mmueller/02_expose_wm_keybindings.patch http://people.ubuntu.com/~mmueller/90_autoconf_update.patch | 09:33 |
| seb128 | and what error do you get? | 09:34 |
| MacSlow | on compilation of pager.c:41:32 error: gconf/gconf-client.h: No such file or directory | 09:35 |
| seb128 | ah | 09:35 |
| MacSlow | somehow the stuff from configure does not get pulled in | 09:35 |
| seb128 | you did Makefile.am changes | 09:35 |
| MacSlow | it works with doing th stuff again upstream | 09:35 |
| seb128 | not only configure | 09:35 |
| MacSlow | hm.. | 09:35 |
| seb128 | change the 90_autoconf_update to be 90_autoreconf_update | 09:35 |
| seb128 | and run autoreconf -v -f instead of autoconf there | 09:35 |
| MacSlow | autoreconf should have been better | 09:36 |
| seb128 | that will update the Makefile.in too | 09:36 |
| MacSlow | I'll redo the 90_thing with autoreconf -v -f | 09:36 |
| === doko_ is now known as doko | ||
| MacSlow | next try | 09:39 |
| MacSlow | nope that failed with the same error | 09:40 |
| seb128 | is GCONF_CFLAGS set in the Makefile? | 09:42 |
| MacSlow | seb128, see http://people.ubuntu.com/~mmueller/02_expose_wm_keybindings.patch | 09:43 |
| seb128 | MacSlow: still broken? | 09:44 |
| seb128 | let me try | 09:44 |
| MacSlow | right in the first 30 lines or so | 09:44 |
| MacSlow | those changes there work with libwnck-2.21.90 when building it normaly (without the debian-tools) | 09:44 |
| MacSlow | no clue why it fails otherwise | 09:45 |
| seb128 | MacSlow: looks like you did run autoreconf in your autoreconf patch | 09:46 |
| seb128 | MacSlow: can you put your dsc and diff.gz online? | 09:46 |
| seb128 | I just tried the patch with an autoreconf -v -f run and that build fine | 09:46 |
| MacSlow | but wasn't that what you told me? | 09:46 |
| seb128 | what? | 09:47 |
| seb128 | <seb128> change the 90_autoconf_update to be 90_autoreconf_update | 09:47 |
| seb128 | and run autoreconf -v -f instead of autoconf there | 09:47 |
| seb128 | you have a Makefile.am change, so you need to autoreconf, you were just speaking about configure this morning when I told you to run autoconf only to update | 09:47 |
| MacSlow | you meant me to edit the fiile 90_auto(re)conf_update directly?! | 09:48 |
| seb128 | no | 09:48 |
| seb128 | drop the patch | 09:48 |
| MacSlow | I assumed you meant recreate it and use "autoreconf -v -f" instead of "autoconf" | 09:48 |
| seb128 | cdbs-edit-patch 90_autoreconf_update | 09:48 |
| seb128 | autoreconf -v -f | 09:48 |
| seb128 | rm -rf autom4te.cache | 09:48 |
| seb128 | ctrl-D | 09:48 |
| seb128 | debuild | 09:49 |
| seb128 | yes, that's what I did | 09:49 |
| MacSlow | ok... so know I have a freshly grabbed libwnck-2.21.90 | 09:51 |
| MacSlow | I copied changelog and 02_expose_wm_keybindings.patch | 09:51 |
| MacSlow | no 90_autoconf_update or 90_autoreconf_update yet | 09:51 |
| MacSlow | I now create that by calling cdbs-edit-patch 90_autoreconf_update (followed by the stated commands in the created shell session)?! | 09:52 |
| MacSlow | seb128, ? | 09:53 |
| MacSlow | is there a difference between calling "debuild" or "dpkg-buildpackage -rfakeroot"? | 09:55 |
| seb128 | MacSlow: yes, do those | 09:55 |
| MacSlow | it fails here still | 09:55 |
| dholbach | MacSlow: debuild makes use of dpkg-buildpackage -rfakeroot and writes a build log (it's a wrapper) | 09:55 |
| pitti | MacSlow: debuild does some extra magic, cleaning environment, and selecting GPG keys, etc. | 09:55 |
| seb128 | calling lintian too | 09:55 |
| * MacSlow hates this day | 09:55 | |
| pitti | -rfakeroot shouldn't be necessary in hardy any more, BTW | 09:55 |
| seb128 | MacSlow: copy the dsc and diff.gz online | 09:56 |
| dholbach | MacSlow: calm down - it's not that bad :-) | 09:56 |
| MacSlow | dholbach, dude you have no idea how unproductive I feel right now | 09:56 |
| dholbach | MacSlow: take one step, then the next - you'll figure it all out and it'll be fine | 09:57 |
| MacSlow | dholbach, I just followed seb128's described steps exactely and it failed | 09:57 |
| seb128 | MacSlow: copy the dsc and diff.gz and I'll help you | 09:58 |
| MacSlow | I mean how much damage can I cause by copy&pasting seb128's commands | 09:58 |
| seb128 | MacSlow: it'll be easier with a quick glance | 09:58 |
| MacSlow | seb128, they are of use although the build failed? | 09:58 |
| seb128 | yes, precisely | 09:58 |
| seb128 | I want to try with the same version here | 09:58 |
| MacSlow | http://people.ubuntu.com/~mmueller/libwnck_2.21.90-0ubuntu2.diff.gz http://people.ubuntu.com/~mmueller/libwnck_2.21.90-0ubuntu2.dsc | 10:00 |
| MacSlow | there you go | 10:00 |
| TheMuso | pitti: Interesting that. I use it out of pure habbit, and likely will nver stop using rfakeroot. :) | 10:02 |
| pitti | TheMuso: well, I grew up with debuild, and I'm a lazy typer :) | 10:03 |
| TheMuso | haha | 10:03 |
| MacSlow | pitti, Ctrl-R for the rescue I always say | 10:03 |
| pitti | heh | 10:03 |
| seb128 | MacSlow: ok, I confirm the bug | 10:04 |
| MacSlow | seb128, so my setup here is broken? | 10:04 |
| MacSlow | any idea what's causing it? | 10:05 |
| seb128 | MacSlow: looking at it | 10:07 |
| MacSlow | ok | 10:07 |
| seb128 | MacSlow: bah, I figured | 10:16 |
| MacSlow | is it nasty? | 10:16 |
| seb128 | MacSlow: you dropped the debian/rules --enable-gconf use | 10:16 |
| MacSlow | but how? | 10:17 |
| seb128 | don't ask me | 10:17 |
| seb128 | you diff.gz give a rules not using this option | 10:17 |
| seb128 | you like took the source | 10:17 |
| seb128 | copied the patch | 10:17 |
| seb128 | the changelog | 10:17 |
| seb128 | run autoreconf | 10:17 |
| seb128 | and forgot to update rules? | 10:17 |
| seb128 | you likely rather | 10:17 |
| MacSlow | but it's in the file 02_expose_wm_keybindings.patch | 10:18 |
| seb128 | oh | 10:18 |
| seb128 | patches are applied by the rules | 10:18 |
| MacSlow | how could that have been "dropped"? | 10:18 |
| seb128 | you edit rules directly | 10:18 |
| seb128 | what you did is racy | 10:19 |
| seb128 | the rules is read before the patches are applied | 10:19 |
| seb128 | so the change is not used | 10:19 |
| MacSlow | *sigh* | 10:19 |
| seb128 | rules is a Makefile | 10:19 |
| MacSlow | so how would what I did in 02_expose_wm_keybindings.patch be done the "right" way? | 10:20 |
| seb128 | edit directly debian/rules and drop the change from the patch | 10:20 |
| seb128 | patches are for source change | 10:20 |
| seb128 | the packaging is a debian thing, we directly edit the debian directory | 10:20 |
| MacSlow | ok | 10:20 |
| MacSlow | now for the 1432nd try | 10:21 |
| MacSlow | here goes the debuild | 10:23 |
| seb128 | is it working now? | 10:23 |
| MacSlow | did not break yet | 10:23 |
| seb128 | that show a bug in your code BTW | 10:24 |
| seb128 | if --enable-gconf is not used the build try to build with gconf anyway and breaks | 10:24 |
| pitti | TheMuso: ah, thanks; got the bug | 10:26 |
| MacSlow | seb128, so the configure.in stuff is broken?! | 10:26 |
| TheMuso | ~pinp | 10:26 |
| seb128 | MacSlow: yes | 10:26 |
| TheMuso | pitti: np | 10:27 |
| MacSlow | seb128, at least the build of the libwnck with my additions now finally worked here | 10:27 |
| pitti | TheMuso: I'll add a test case for this, fix it in trunk, and then go back to your box to verify it later; if you can leave my login for a day? | 10:27 |
| MacSlow | seb128, I'll look into the configure.in issue | 10:27 |
| TheMuso | pitti: I can leave it running for a day if you need. | 10:28 |
| MacSlow | seb128, once that's done I'll ping you again or email you or mvo for upload if you're ok with the rest of it (ok three icons and the translations are still missing) | 10:28 |
| MacSlow | seb128, that those can come later | 10:28 |
| pitti | TheMuso: as you prefer; alternatively I can just send you updated .debs for testing; more work for you, less power consumption :) | 10:28 |
| MacSlow | seb128, anyway did you try the newer version of libwnck? | 10:29 |
| pitti | TheMuso: (well, I'll need testing from you for the graphical bits and the root operations anyway) | 10:29 |
| TheMuso | pitti: The mini doesn't use a lot so its no big deal. | 10:29 |
| TheMuso | pitti: Righto, I can leave it on overnight at least, so you can do what you need to. | 10:29 |
| pitti | TheMuso: cool, thanks; I'll mail you | 10:29 |
| TheMuso | pitti: No problem. | 10:29 |
| TheMuso | ...and I'm off for the night, and the weekend. | 10:30 |
| dholbach | TheMuso: have a great weekend! | 10:31 |
| TheMuso | dholbach: You too. | 10:31 |
| seb128 | MacSlow: I think the issue is ENABLE_GCONF case, you look for yes but don't handle the auto case there | 10:34 |
| MacSlow | seb128, there's implicit support for "auto"? | 10:36 |
| === \sh_away is now known as \sh | ||
| seb128 | MacSlow: enable_gconf is not set in your case if the configure option is not used, you can add a [enable_gconf=yes] to set a default case | 10:51 |
| seb128 | MacSlow: but your configure will still be buggy I think | 10:51 |
| seb128 | if test "x$enable_gconf" != "xno"; then | 10:51 |
| seb128 | PKG_CHECK_MODULES([GCONF], [gconf-2.0 >= 2.20.0]) | 10:51 |
| seb128 | CFLAGS=-DUSE_GCONF | 10:51 |
| seb128 | that should be conditional to whether the gconf-2.0 is installed | 10:51 |
| seb128 | because you set the CFLAGS anyway there | 10:52 |
| seb128 | MacSlow: setting the default value to yes should do the trick | 10:54 |
| Riddell | asac: network-manager-kde 0.7 in my ppa if you want to test, it didn't work for me (but neither did the gnome applet) | 11:15 |
| asac | Riddell: gnome applet didn't? how? | 11:16 |
| asac | Riddell: do we have a bzr sync for nm kde 0.7? where is that maintained? | 11:17 |
| Riddell | asac: no, I just stole the source from suse | 11:17 |
| Riddell | asac: gnome applet didn't show any devices for me | 11:18 |
| asac | so they do in house development? | 11:18 |
| asac | Riddell: anything in /etc/n/i ? | 11:18 |
| Riddell | asac: just "lo" | 11:18 |
| asac | can you paste syslog somewhere? does nm bring down interfaces if you start it? | 11:19 |
| asac | Riddell: ^^ | 11:19 |
| Riddell | asac: Feb 8 11:24:14 wido NetworkManager: <WARN> nm_dbus_manager_init_bus(): Could not get the system bus. Make sure the message bus daemon is | 11:25 |
| Riddell | running! Message: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory | 11:25 |
| asac | Riddell: huh .. which version? | 11:25 |
| Riddell | is what happens when I /etc/init.d/dbus stop and start again | 11:25 |
| asac | is there still a nm around? | 11:25 |
| Riddell | dbus 1.1.2-1ubuntu2 network-manager 0.7~~svn20080121t191418+eni1-0ubuntu0~pre7 | 11:25 |
| asac | isn't system bus hal? | 11:26 |
| Riddell | I imagine hal uses it | 11:27 |
| === Kopfgeldjaeger is now known as KGJ|frustriert | ||
| asac | Riddell: do you still have the 25NetworkManager in /etc/dbus-1/event.d ? | 11:31 |
| asac | Riddell: 0.7 is restarted by /etc/init.d/NetworkManager restart atm | 11:31 |
| soren | pitti: Your laptop has the trackpoint thing, doesn't it? | 11:37 |
| pitti | soren: both a touchpad and a trackpoint | 11:38 |
| soren | pitti: Awesome. I just ordered mine, and it suddenly occured to me that I wasn't sure if it had such a thing. | 11:39 |
| Riddell | asac: when I run /etc/init.d/NetworkManager I get http://kubuntu.org/~jriddell/tmp/nm | 11:54 |
| asac | console kit | 11:57 |
| asac | is that related to nm? | 11:59 |
| === cjwatson_ is now known as cjwatson | ||
| cjwatson | Riddell: does kdm register a ConsoleKit session? | 12:13 |
| cjwatson | (sorry if I missed the discussion due to network trouble) | 12:13 |
| Riddell | cjwatson: it tries to, seems to be having some issues though | 12:14 |
| Riddell | asac: not that I know of | 12:15 |
| persia | tjaalton: Are you planning to update nvidia-legacy so that bug #72979 can be executed? I'm perhaps a little confused about activity from just reading bug reports. | 12:32 |
| ubotu | Launchpad bug 72979 in nvidia-settings "Please remove nvidia-settings from gutsy" [Low,Confirmed] https://launchpad.net/bugs/72979 | 12:32 |
| tjaalton | persia: refresh :) | 12:38 |
| tjaalton | persia: I just uploaded a new revision which installs nvidia-settings in nvidia-glx-legacy | 12:39 |
| tjaalton | so nvidia-settings can be removed from hardy | 12:39 |
| persia | tjaalton: Excellent! That bug has been bothering me for a rather long time. Thank you. | 12:39 |
| tjaalton | no problem, now some lunch -> | 12:40 |
| cjwatson | mvo: current apt-key/ubuntu-keyring is having trouble adding the CD signing key; it says "gpg: error reading key: public key not found" | 12:42 |
| cjwatson | mvo: I think that this line is wrong? | 12:43 |
| cjwatson | if $GPG --list-sigs --with-colons $add_key | grep ^sig | cut -d: -f5 | grep -q $master_key; then | 12:43 |
| cjwatson | mvo: shouldn't that be $GPG_CMD --keyring $ADD_KEYRING, rather than $GPG? | 12:43 |
| cjwatson | since the key isn't necessarily in /etc/apt/trusted.gpg yet | 12:43 |
| mvo | cjwatson: let me check | 12:50 |
| dholbach | MOTU Q&A session in #ubuntu-classroom in 10 minutes | 12:50 |
| mvo | cjwatson: you are right (of course). fixing it now, I will upload a new apt today that will also include the networkless-install bits | 13:04 |
| cjwatson | mvo: thanks! I just uploaded an apt-setup that seeds /var/lib/apt/lists with signed Release files | 13:11 |
| mvo | nice! | 13:11 |
| cjwatson | mvo: is there any more to AptAuthenticationReliability, or can I mark it implemented now? | 13:11 |
| mvo | cjwatson: I think that was it, we should be done (modulo bugs of course) | 13:12 |
| cjwatson | mvo: maybe the notification on failed updates? | 13:12 |
| mvo | cjwatson: right, that one is sitting here in my local disk, I'm a bit unsure if we should enable it. there is a warning now in update-notifier/update-manager if the last update of the sources.list did work for a certain amount of days (7 currently) | 13:13 |
| cjwatson | if s/did work/did not work/, I think that's good enough for me | 13:14 |
| mvo | yeah, s/did work/did not work/ indeed :) | 13:15 |
| cjwatson | we could enable the warning and turn it off if it annoys people | 13:15 |
| mvo | and check how much people actually see it, how widespread the problem is | 13:16 |
| mvo | that sounds like a plan | 13:16 |
| ScottK | pitti: The trimmed amavisd-new (removed the milter) is uploaded, so it should be ready to be promoted. | 13:20 |
| pitti | ScottK: ah, neat; I checked this morning and didn't see it yet | 13:20 |
| ScottK | I just uploaded. | 13:21 |
| ScottK | pitti: Do you have a moment to discuss another issue. | 13:21 |
| pitti | ScottK: sure | 13:26 |
| ScottK | pitti: I've been looking after clamav for some time and as I'd imagine you're aware there is quite a security problem in Dapper. | 13:26 |
| ScottK | I've got a list of 12 or 13 CVEs that are open and valid against the current Dapper clamav. | 13:27 |
| ScottK | It's old enough to be unmaintainable for any reasonable effort MOTU might be able to muster. | 13:27 |
| ScottK | In dapper-backports, we uploaded the current clamav package (with some small changes to work on Dapper) and updated all the rdepends. | 13:28 |
| ScottK | It's been several weeks now with no bugs filed. | 13:28 |
| ScottK | pitti: My proposal is that these updates be copied from backports to dapper-updates. | 13:29 |
| ScottK | At this point our choices boil down to this or leave the vulnerabilities. | 13:29 |
| ScottK | If you think this is worth considering, I can file a bug with the CVEs and a complete package list. | 13:30 |
| pitti | ScottK: I do think that it is worth considering | 13:33 |
| pitti | ScottK: depending on how much positive feedback we got? | 13:33 |
| pitti | ScottK: I think we should open/find a bug suitable for SRU, copy -backports to -proposed, and call for testing | 13:33 |
| ScottK | Myself and a few other people tested all of these uploads in a PPA before they were backported and documented the test results. | 13:33 |
| pitti | ah, great | 13:33 |
| ScottK | https://wiki.ubuntu.com/MOTU/Clamav?action=show | 13:34 |
| pitti | can you please include a pointer to these results into the bug? | 13:34 |
| ScottK | Yes | 13:34 |
| ScottK | Will do. | 13:34 |
| pitti | oh, that looks like great documentation | 13:35 |
| DktrKranz | pitti, do you think this is applicable to normal issues too (not concerning security vulnerabilities) ? . I saw some requests to release upgrades for completely broken apps (mainly youtube clients) | 13:35 |
| pitti | ScottK: if it really has been proven that well already, that should suffice for verification | 13:36 |
| jdong | DktrKranz: when the original is so defective that it "couldn't possibly get any worse"... I'd like for a procedure like this to be documented to take a new version trhough backports->proposed->updates | 13:36 |
| ScottK | pitti: OK. I do think we've tested it pretty thoroughly. | 13:37 |
| ScottK | pitti: I've also uploaded a New amavisd-new-milter source package to maintain that binary in Universe. | 13:37 |
| DktrKranz | jdong, really. I tried to isolate single patches for some of these packages, but changes are invasive as much as backport new release. | 13:38 |
| pitti | ScottK: what's the X in claws-mail-clamav? | 13:38 |
| ScottK | It doesn't exist in Dapper | 13:38 |
| frafu | Hello, as you probably know, an accessibility tab has been added to the mouse control panel in GNOME 2.22 (and consequently, it is also available in hardy). However, the new accessibility features are in a separate module that is currently as a new module in the build queue for universe. | 13:39 |
| pitti | DktrKranz: if the regression potential for a package is zero because it doesn't work at all, I'm fine with updates; if it works under some conditions, upgrades have to be evaluated to avoid regressions | 13:39 |
| ScottK | pitti: If you look at the PPA - https://launchpad.net/~ubuntu-clamav/+archive - you'll see we've got packages for all the releases for testing. | 13:39 |
| frafu | My question: Should I file the mir right away, or do I have to wait for mousetweaks to be available in the universe repo? | 13:40 |
| pitti | ScottK: ah, I see | 13:40 |
| pitti | ScottK, DktrKranz: well, in this case my feeling is that the updates should go to -proposed in the first place, and not to -backports; WDYT? | 13:41 |
| jdong | pitti: do you think this workflow should be documented as an exception on the StableReleaseUpdates process, or do you feel this is rare enough that we can seek approval informally from you on a case-by-case? | 13:41 |
| persia | frafu: it's better to wait until it is in universe, but you might get started on the wiki entry beforehand, given the tight timing for hardy. | 13:41 |
| pitti | jdong: I think we should keep the workflow, and rather add the condition to the list of acceptable SRUs | 13:41 |
| jdong | ok | 13:42 |
| ScottK | Makes sense | 13:42 |
| ScottK | I do think for situations where the package supports a service that makes random non-compatible changes it ought to be SRUable. | 13:42 |
| frafu | persia: I have already written the mir in the wiki: https://wiki.ubuntu.com/MainInclusionReportMousetweaks | 13:43 |
| DktrKranz | pitti, going through -backports sounds like an additional step to be taken, since we should test packages on -backports and -proposed. | 13:43 |
| pitti | if it worked in breezy, then it already falls under the 'major regression' case | 13:43 |
| pitti | DktrKranz: right; -backports isn't really meant for bug fixes, it's for new features | 13:43 |
| jdong | DktrKranz: I don't think going through backports is unreasonable for introducing a new upstream version of anything, if it came from Hardy | 13:44 |
| frafu | It would be odd to have the gui in hardy but no the functions because mousetweaks is missing. | 13:44 |
| ScottK | jdong: It depends on if something's fundamentally broken or not. | 13:44 |
| jdong | ScottK: hmm... actually on second thought, I don't think going through backports is a good idea | 13:45 |
| jdong | the backports buildd's build against all components | 13:45 |
| jdong | so it can't be guaranteed to be "just like -updates" | 13:45 |
| elmo | jdong: err, what? | 13:46 |
| jdong | elmo: backporting a packages from main is allowed to build against multiverse ;-) | 13:47 |
| jdong | it was like during Breezy or so that we had issues with changing definitions of sections and the decision was just to do away with sections altogether :) | 13:48 |
| elmo | jdong: umm, seriously? | 13:48 |
| jdong | elmo: yeah... | 13:48 |
| * jdong can sense elmo's blood boiling :) | 13:49 | |
| DktrKranz | pitti: suppose we have a package in gutsy broken beyond any repair, and hardy new upstream version fixes the issue, which version should we adopt to avoid clashing with existing packages? | 13:49 |
| * ScottK steps to the other side of the room, away from the late jdong. | 13:50 | |
| DktrKranz | using ~gutsy as backports do? | 13:50 |
| Hobbsee | jdong: what crack are you proposing now? | 13:50 |
| jdong | Hobbsee: none :) I'm just recapping on crack from 1.5yrs ago :) | 13:51 |
| ScottK | Hobbsee: Actually it's DktrKranz's crack. | 13:51 |
| Hobbsee | and a soyuz bug, it appears | 13:51 |
| ScottK | My fault though. I started it. | 13:51 |
| jdong | DktrKranz: rmadison azureus; and yes ~gutsy1 | 13:51 |
| DktrKranz | ScottK, heh :) | 13:51 |
| jdong | Hobbsee: It was intended functionality, not a soyuz bug (this time :D) | 13:52 |
| pitti | jdong: hm, so what's the current status of bug 184386? that's a bit confusing | 13:52 |
| ubotu | Launchpad bug 184386 in gutsy-backports "Please backport bzr-svn (0.4.5-1) from Hardy" [Undecided,New] https://launchpad.net/bugs/184386 | 13:52 |
| Hobbsee | jdong: so it was a crack decision. got it. | 13:52 |
| jdong | pitti: don't backport for now, awaiting a sync of 0.4.7-1 to hardy, at which point, backport | 13:52 |
| pitti | jdong: also in relation to bug 188781 ? | 13:52 |
| ubotu | Launchpad bug 188781 in bzr-svn "[backport-request] bzr-svn not installable when backports enabled" [Undecided,Invalid] https://launchpad.net/bugs/188781 | 13:52 |
| jdong | pitti: those two are dupes | 13:52 |
| pitti | bzr-svn | 0.4.7-1 | hardy/universe | source, all | 13:53 |
| jdong | Hobbsee: well considering the restrictions placed on the origins of backports, IMO not all that crackful | 13:53 |
| jdong | pitti: oh, already synced :) guess I'm not on the ball | 13:53 |
| pitti | jdong: so "the bzr-builddeb issue" (whatever that is) is ok? | 13:53 |
| jdong | pitti: ask dholbach, I'm not sure :D | 13:53 |
| pitti | jdong: I did it this morning, I think | 13:53 |
| jdong | pitti: gimme a quick second to make sure bzr-svn 0.4.7 actually works on Gutsy | 13:54 |
| pitti | jdong: marked as dup, thanks | 13:54 |
| pitti | jdong: ok; no rush, we can do it later | 13:54 |
| dholbach | pitti, jdong: bzr-builddeb on backports is all sorted out - I thought I had replied on all the bugs | 13:54 |
| === greeneggsnospam is now known as jsgotangco | ||
| pitti | dholbach: yeah, it just wasn't clear to me what the issue was | 13:55 |
| jdong | pitti: what's unclear to me is how it was resolved | 13:56 |
| dholbach | it might have been the bzrtools dependency or something | 13:56 |
| jdong | the issue I assume was bzr 1.0 does not work with bzr-builddep $existingversion | 13:56 |
| jdong | bzrtools (>= 0.18), | 13:56 |
| jdong | yep it's surely a dep | 13:56 |
| jdong | pitti: btw, bzr-svn 0.4.7-1 is good for gutsy-backports | 13:57 |
| pitti | so, if everything is alright, I wait for jdong's final ack for bzr-svn, and then we backport | 13:57 |
| pitti | cool | 13:57 |
| === pedro__ is now known as pedro_ | ||
| jdong | pitti: ready to do this all again with bzr 1.10? :D | 13:58 |
| pitti | sure | 13:58 |
| * pitti ♥ bzr | 13:59 | |
| jdong | don't we all :) | 13:59 |
| pitti | and bzr-svn is so great | 13:59 |
| jdong | even my TODO list is managed via bzr :) | 13:59 |
| pitti | my /etc backup, too | 13:59 |
| jdong | nice | 13:59 |
| soren | pitti: Er... Why was netcat-openbsd rejected? | 14:04 |
| pitti | soren: it was a duplicate in the queue | 14:05 |
| pitti | someone synced it without NEWing | 14:05 |
| soren | Ah. | 14:06 |
| pitti | slangasek: ^ might have been you? if you sync new pacakges from Debian, please keep a list and immediately NEW them (U pkg1 pkg2; q accept pkg1 pkg2) | 14:06 |
| soren | That was you, I think :) | 14:06 |
| pitti | soren: I synced the second one, yes (the bug was still open) | 14:06 |
| soren | Ah, ok. | 14:06 |
| soren | Ah, yes, I see there's an accepted one from bigon. Ok, good. | 14:06 |
| soren | Awesome, actually. | 14:07 |
| ScottK | pitti: Bug #190187 for clamav in Dapper. | 14:09 |
| ubotu | Launchpad bug 190187 in clamav "Dapper clamav has multiple security issues that require upgrade to new version to fix" [Undecided,Fix released] https://launchpad.net/bugs/190187 | 14:09 |
| seb128 | pitti, thekorn: is that a known issue? | 14:09 |
| seb128 | File "/usr/lib/python2.5/site-packages/launchpadbugs/lptime.py", line 61, in __new__ | 14:09 |
| seb128 | raise ValueError, "Unknown date format (%s)" %time_str | 14:09 |
| seb128 | ValueError: Unknown date format (2008-02-08 14:12:50 CET) | 14:09 |
| pitti | hell, gutsy-backports/NEW is crowded | 14:10 |
| seb128 | pitti: the retrace is breaking on that an untagging bugs which are not retraced | 14:10 |
| pitti | seb128: oh, I got the same this morning on drescher, but I already talked about this with thekorn and we couldn't reproduce it anywhere but drescher | 14:11 |
| seb128 | bah | 14:11 |
| seb128 | python2.4 thing again? | 14:11 |
| ScottK | pitti: If you'd be willing to copy the clamav + rdepends straight to dapper-updates, I will definitely commit to be here to fix any problems (I'm already bug contact on all the packages. | 14:11 |
| pitti | seb128: I hacked the instance on drescher | 14:11 |
| seb128 | pitti: could you do the same on ronne? | 14:11 |
| soren | doko: I've been thinking about kvm and gcc.. Qemu compiled with gcc-3.4 is very well tested. The new code generator is brand new and has seen only very limited testing. I'm not sure if I'm completely comfortable making such a drastic change just to make it compile with gcc-4.x. | 14:11 |
| pitti | ScottK: yeah, seems we got much testing on that one | 14:11 |
| seb128 | pitti: or rather the retracers | 14:11 |
| pitti | seb128: no, it's not 2.4 specific | 14:11 |
| seb128 | pitti: or point me the change and I'll do the retracers update | 14:12 |
| pitti | seb128: it worked just fine in my dapper chroot | 14:12 |
| pitti | seb128: I replaced the raise with "t = time.gmtime()[0:6]" and added import time | 14:12 |
| pitti | seb128: i. e. ignore the date | 14:12 |
| seb128 | ok, thanks | 14:12 |
| pitti | seb128: that's not the chroots, right? just the digger? | 14:13 |
| seb128 | pitti: /tmp/tmpNW8_bN/usr/bin/apport-retrace | 14:13 |
| seb128 | pitti: that's the retracer no? | 14:14 |
| doko | hrm. that would move 3.4 and 4.0 to main again | 14:14 |
| soren | doko: I know. | 14:14 |
| pitti | seb128: I think we just need to replace the p-lp-bugs instance on ronne with the current version, too | 14:14 |
| seb128 | pitti: do you have a script doing the update? | 14:15 |
| pitti | seb128: erm, no, they shouldn't be in /tmp/ | 14:15 |
| soren | doko: At this point, the "new world order" of qemu is hardly a few weeks old. | 14:15 |
| pitti | seb128: only one to create a completely new retracer | 14:15 |
| pitti | seb128: I can do it now if you want | 14:15 |
| doko | pitti: any opinion? | 14:15 |
| seb128 | pitti: would be nice, thanks | 14:15 |
| pitti | seb128: oh, according to the log it failed in the chroot, not in the digger | 14:16 |
| pitti | I'd really hate to promote two gccs again | 14:16 |
| seb128 | pitti: what I though | 14:16 |
| soren | doko: Why is 4.0 needed? | 14:16 |
| doko | libgcc2 for hppa | 14:17 |
| pitti | it's not feasible to give 4.2 a try and only use 3.4 if that actually breaks? | 14:17 |
| soren | pitti: I'd really rather do it the other way around. | 14:17 |
| pitti | we still have plenty of time until the release | 14:17 |
| soren | pitti: We *know* 3.4 gives good results. | 14:17 |
| soren | pitti: I can promise to revisit this on at least a weekly basis. | 14:18 |
| soren | pitti: Hoping to switch to 4.0 before release, but not promising that that will be the case. | 14:18 |
| soren | Er.. | 14:19 |
| soren | 4.4, I mean. | 14:19 |
| pitti | 4.2? | 14:19 |
| soren | Or 4.3.. Whichever is the default nowadays. | 14:19 |
| soren | I forget :) | 14:19 |
| pitti | heh | 14:19 |
| soren | 4.2.3. | 14:19 |
| pitti | see, that's part of the problem -- plethora of compiler versions :) | 14:19 |
| pitti | seb128: hm, that already was the latest version in the chroot | 14:20 |
| pitti | so that's a real bug, I think | 14:20 |
| pitti | seb128: I just apply the nasty hack then | 14:20 |
| seb128 | pitti: thanks | 14:20 |
| soren | There are two sides to this really: I really, really want kvm to be as solid as possible, and you want to keep old compilers out of main. At this point, I'm not sure whether those two wishes can be fulfilled at the same time. | 14:21 |
| pitti | seb128: I h4x0red the hardy/i386 chroot now | 14:22 |
| soren | pitti, doko: From #kvm: | 14:25 |
| soren | 15:23:02 < danpb_ltop> soren: the new code generator is faaaaar from complete | 14:25 |
| soren | 15:23:14 < danpb_ltop> soren: there's going to be a long time with a hybrid of the old & new generators | 14:25 |
| soren | ...so I'm not getting my hopes up. | 14:25 |
| pitti | oh, too bad | 14:25 |
| pitti | so, I guess it's up to doko whether we can maintain 3.4 for hardy? | 14:26 |
| ScottK | pitti: Do you want me to subscribe ubuntu-archive on the clamav bug to get it in your work flow or is it OK as is? | 14:26 |
| pitti | (still gives me a bad taste, though wrt. mantainability of qemu in the first place, if it is still using such ancient code) | 14:26 |
| soren | pitti:That's not the issue at all. | 14:27 |
| soren | pitti: It's not that the code is not compatible with 4.0 and beyond. | 14:27 |
| elmo | soren: pitti's point still stands | 14:27 |
| pitti | I might understand it wrongly | 14:27 |
| pitti | ScottK: fine for me, I have a tab open | 14:28 |
| elmo | we have nothing else in main that requires gcc-3.4 | 14:28 |
| elmo | and now kvm and it's "2nd generation virtualization" is pulling it back in... | 14:28 |
| elmo | I'm trying not to giggle, really, I am, but... | 14:28 |
| ScottK | pitti: OK. Thanks. I'll just leave it to you then. | 14:28 |
| soren | pitti: During build time, qemu depends on a particular layout of the machine code, gcc spews out. gcc-4.0 changed dramatically in that respect, and there's no way to force it to do what we want it to. | 14:28 |
| frafu | Could anybody please tell me what branch I have to checkout in order to add mousetweaks to the hardy desktop seed? The following document only talks about the case of core-devs and read-only!? | 14:29 |
| doko | hmm, 4.9 is so new | 14:29 |
| doko | s/4.9/4.0/ | 14:29 |
| persia | frafu: You don't need to do that. The MIR approver will update the seeds. | 14:29 |
| pitti | persia: no, not the approver | 14:30 |
| pitti | taking care of the seeds is the responsibility of the requestor | 14:30 |
| persia | pitti: Who does then? A sponsor? | 14:30 |
| soren | elmo: My point is that it's not a matter of "ancient code" per se. | 14:30 |
| pitti | yeah, someone who knows the package and where it should go to | 14:30 |
| persia | pitti: Ah. That makes sense. | 14:30 |
| pitti | persia: of course, if I'm asked to do it, I'll do it | 14:30 |
| pitti | but it's not the default | 14:31 |
| frafu | In fact I am looking at how to do point 5 of https://wiki.ubuntu.com/MainInclusionProcess | 14:31 |
| pitti | I'm just not sure whether we can touch the seeds right now, they are currently undergoing restructuring (cjwatson?) | 14:31 |
| persia | frafu: mousetweaks is required to make part of gnome-control-center work properly, right? You might consider asking for the dependency to be added there, rather than changing the seeds. This would also fix the case where the "ubuntu-desktop" package was not installed. Try asking in #ubuntu-desktop. | 14:32 |
| cjwatson | pitti: don't let me block you; I'll deal with merging | 14:32 |
| cjwatson | pitti: I'm waiting for a Launchpad fix before I can finalise it | 14:32 |
| === MetalMusicAddict is now known as _MMA_ | ||
| pitti | yay dependency chains :) ok, I'll add it then | 14:32 |
| persia | pitti: To the seed? Should not the GUI depend on the daemon to implement point 5, rather than a seed change? | 14:33 |
| pitti | frafu: mousetweaks is in universe, though | 14:33 |
| pitti | persia: yes, that would make more sense | 14:33 |
| frafu | No; it will also work without mousetweaks, but if you try to activate the a11y features of the new mouse control panel you get a dialog telling you to install mousetweaks | 14:33 |
| pitti | persia: (see, that's why the requestor is responsible, not the approver :) ) | 14:33 |
| persia | pitti: The light dawns... | 14:34 |
| pitti | frafu, persia: so maybe the two of you can discuss where it belongs (with a comment from seb128 maybe) and then you tell me what to do? | 14:34 |
| persia | frafu: Submit a debdiff against gnome-control-center to ubuntu-main-sponsors with the additional dependency. This will put it on the right list to get it included in all the right places (pitti will be chasing point 6) | 14:34 |
| Mez | pitti, from successful completion of a backport on your part, how long does it take to hit the archive ? | 14:34 |
| seb128 | pitti, frafu, persia: a gnome-control-center depends seems correct until we get recommends installed then we can use that there | 14:35 |
| pitti | Mez: source> about an hour, binary> depends on buildd speed; usually less than a day | 14:35 |
| persia | seb128: Sounds sane. Thanks for the input. | 14:35 |
| pitti | Mez: unless it's stuck in NEW, of course | 14:35 |
| Mez | pitti - hope not | 14:35 |
| Mez | pitti, well you backported it 28 mins ago... so I'll wait | 14:35 |
| thekorn | pitti, seb128, this date/time error is really weird, | 14:36 |
| thekorn | there might be a problem with the timezone information | 14:36 |
| pitti | File "/usr/lib/python2.5/site-packages/launchpadbugs/connector.py", line 95, in NewComment | 14:37 |
| pitti | return getattr(self.module, "Comment")(*args, **kwargs) | 14:37 |
| pitti | TypeError: __init__() got an unexpected keyword argument 'attachment' | 14:37 |
| pitti | thekorn: ^ another failure from the retracer | 14:37 |
| pitti | known already? or do you want a bug? | 14:37 |
| frafu | mousetweaks is not in universe yet; it is waiting for a build depend for the hppa architectures; the other architectures are already built | 14:38 |
| pitti | thekorn: ah, I explicitly call it with ..., attachment=att); seems the API changed? | 14:39 |
| thekorn | pitti, no, not known, can you please open a bugreport | 14:39 |
| persia | frafu: Right. Submit the debdiff for now, and the sponsor will apply it once it has passed binary NEW. | 14:39 |
| pitti | thekorn: i. e. NewComment() doesn't accept an optional parameter attachment any more? | 14:39 |
| thekorn | pitti, let me check | 14:39 |
| Mez | pitti, another question - how do I find the build queues for backports pocket? | 14:40 |
| thekorn | pitti, damn, the argument changed into "...attachments=set()...", | 14:41 |
| ScottK | Mez: It's the same queue | 14:41 |
| thekorn | but then it's a bug, I did not want to change the API | 14:41 |
| pitti | Mez: try https://edge.launchpad.net/ubuntu/gutsy/+builds | 14:41 |
| pitti | thekorn: ok, shall I report that one then? | 14:41 |
| pitti | thekorn: I stopped the retracers for now, since that sounds like it'll break all retraces | 14:42 |
| thekorn | pitti, I will fix it now | 14:42 |
| frafu | So I submit a debdiff against gnome-control-center in launchpad; correct? (I am new to this, so I prefer to ask to be sure) | 14:42 |
| Mez | ScottK, pitti, thanks... *sighs as what he's looking for doesnt seem to be in any state on the build* | 14:43 |
| pitti | thekorn: oh, great, thanks; I'll manually patch the retracers then | 14:43 |
| persia | frafu: That'd be my recommendation, assuming the MIR was approved (I haven't checked). | 14:43 |
| pitti | ScottK: moved to -updates, thanks! | 14:45 |
| ScottK | pitti: Wonderful. Thanks for getting to it so quickly. | 14:45 |
| pitti | frafu: I don't see a MIR for mousetweaks on https://bugs.launchpad.net/~ubuntu-mir/+subscribedbugs | 14:45 |
| pitti | ScottK: exemplary verification and documentation | 14:46 |
| * ScottK wonders if he should mention to pitti that he's up for core-dev on Tuesday and that might be worth a mention ... | 14:47 | |
| pitti | ooooh | 14:47 |
| * pitti fanboys ScottK's nomination | 14:47 | |
| frafu | Yes; I thought I had to wait for mousetweaks to be in universe before applying to mir; I have already prepared https://wiki.ubuntu.com/MainInclusionReportMousetweaks | 14:47 |
| frafu | pitti: should I add it now? | 14:48 |
| pitti | frafu: ah, please | 14:49 |
| pitti | frafu: yes, that was correct | 14:49 |
| thekorn | pitti, ok, this might fix the attachment issue, http://paste.ubuntu.com/4340/ | 14:49 |
| frafu | pitti: ok; | 14:49 |
| pitti | thekorn: thanks a lot | 14:52 |
| cjwatson | Riddell: I'm adding proxy configuration to the advanced dialog in ubiquity, but I've run out of time to do the Qt side as well; could I get you to do that bit? | 14:53 |
| cjwatson | it's pretty small, I'm just way out of practice with qt4-designer | 14:53 |
| Riddell | cjwatson: can do | 14:55 |
| cjwatson | thanks - I'll mail you a reminder once I've done the GTK side | 14:55 |
| soren | doko, pitti: alternative plan: | 14:57 |
| doko | include the gcc-3.4 source in kvm? | 14:58 |
| soren | Hah! | 14:58 |
| soren | How'd you guess? | 14:58 |
| soren | doko, pitti: I work on a patch to kvm to make it refuse to do anything at all if hardware acceleration isn't available. That should alleviate the need for gcc-3.4. | 14:59 |
| pitti | aah | 14:59 |
| pitti | soren: so that people can install qemu from universe instead? | 14:59 |
| pitti | that sounds great | 14:59 |
| * pitti hugs soren | 14:59 | |
| soren | doko, pitti: However, we want to do some thorough testing, so we'd like to keep the door open for the option to include gcc-3.4 if it turns out to be troublesome. | 14:59 |
| pitti | soren: we can always do that as last resort, yes | 15:00 |
| soren | pitti: So the action plan now? Can we push kvm to main, dropping gcc-3.4 dependency when I'm done with the patch (which might be shortly after ff)? | 15:01 |
| soren | Or should we hold off kvm until the patch is done? and how does that work w.r.t. feature freeze? | 15:01 |
| persia | soren: Would it be possible to keep the fallback mechanism, but only use it if qemu is installed (from universe)? | 15:01 |
| soren | persia: Not entirely. | 15:02 |
| soren | persia: I wanted to, but it's not. | 15:02 |
| pitti | soren: traditionally we did promotions/demotions way past FF | 15:02 |
| persia | soren: Ah. Oh well. | 15:02 |
| soren | pitti: Ah, no worries, then. | 15:02 |
| soren | pitti: Ah, right, I remember something about a partman-auto-crypto-lvm-magic thing that went in and out of main quite frequently shortly before gutsy released. *cough* :) | 15:03 |
| pitti | soren: excellent plan, thanks | 15:04 |
| pitti | so we can have the cake and eat it, too | 15:04 |
| soren | \o/ | 15:04 |
| pitti | erk, p-lp-bugs Unknown date format did it again | 15:07 |
| pitti | quick, I need a crash bug to retrace for testing :) | 15:09 |
| Amaranth | pitti: start compiz | 15:11 |
| pitti | *laugh* | 15:11 |
| soren | Amaranth: I was going to say evolution :) | 15:12 |
| Amaranth | compiz, evolution, OOo, take your pick ;) | 15:12 |
| pitti | I'll watch it for abit | 15:12 |
| Amaranth | i can't think of any reproducable crasher, that must be a good thing | 15:12 |
| Ng | I can! | 15:13 |
| hendrixski | morning all | 15:13 |
| Ng | alt-space on a borderless window makes some part of compiz segfault :) | 15:13 |
| Ng | (bug #185784) | 15:14 |
| ubotu | Launchpad bug 185784 in compiz "gtk-window-decorator SIGSEGV opening window menu on undecorated windowa" [Medium,New] https://launchpad.net/bugs/185784 | 15:14 |
| hendrixski | pitti, Xchat tells me that you sent me an answer about making repositories with the .ddebs but I can't scroll up enough to find it. :-( may I ask you to repost the answer? | 15:15 |
| pitti | hendrixski: I don't remember a question about .ddebs | 15:15 |
| pitti | hendrixski: oh, s/making/using/, yes | 15:15 |
| soren | pitti: Will you make it all the way down the queue to, say, dnsmasq-base today? | 15:16 |
| soren | pitti: Also, can I have a pony? | 15:16 |
| pitti | hendrixski: look at the first paragraph on https://wiki.ubuntu.com/DebuggingProgramCrash | 15:16 |
| zul | pitti: hello is libxen3 still in binary new? | 15:16 |
| pitti | soren: I keep getting distracted from NEW, but I'm at it; i'll get to dnsmasq, though | 15:16 |
| * soren hugs pitti | 15:16 | |
| soren | pitti: Lovely, thanks. | 15:17 |
| pitti | zul: yes, it is | 15:17 |
| zul | pitti: ok thanks | 15:17 |
| pitti | soren: netcat-openbsd binary-NEWed | 15:17 |
| zul | i wont bug you then | 15:17 |
| hendrixski | pitti, I saw that page before, I don't see on it hwere it says how to make repositories with .ddeb files :-( | 15:17 |
| soren | zul: https://edge.launchpad.net/ubuntu/hardy/+queue?queue_state=0&queue_text=libxen | 15:17 |
| soren | pitti: Whee! | 15:17 |
| hendrixski | because when I run apt-ftparchive, all it puts in the Packages file is the regular .deb's and none of the .ddeb's :-( | 15:18 |
| pitti | hendrixski: right, I misunderstood it as "where to get them" | 15:18 |
| hendrixski | pitti, it's Ok. I probably didn't ask the question very well. here's where I'm at: | 15:18 |
| pitti | hendrixski: bzr get http://people.ubuntu.com/~pitti/bzr/ddeb-retriever/ | 15:19 |
| hendrixski | I made a bunch of them, when I installed dpkg-create-dbgsym and ran dpkg-buildpackage | 15:19 |
| pitti | hendrixski: that is the code which builds ddebs.ubuntu.com | 15:19 |
| pitti | hendrixski: and it calls apt-ftparchive appropriately | 15:19 |
| hendrixski | ah | 15:19 |
| pitti | hendrixski: please let me know if you have questions about it | 15:20 |
| hendrixski | sweet. I'm getting it right now. So I just run the ddeb-retriever script in the directory where the ddebs are and it'll make the Packages.gz? | 15:22 |
| pitti | no, ddeb-retriever itself runs much more | 15:23 |
| frafu | pitti: mir-bug for mousetweaks has been filed and it shows up in https://bugs.launchpad.net/~ubuntu-mir/ | 15:23 |
| pitti | hendrixski: it calls archive_tools.create_indexes() which is the function you wnat | 15:24 |
| hendrixski | pitti, ah, ok.. 'cause I just ran it and got import errors... google says I need to install python-apt ... but if I only need archive_tools.create_indexes() I can figure out how to use it by reading through the code, right? | 15:26 |
| pitti | you'll still need python-apt, I think | 15:26 |
| * hendrixski apt-gets it | 15:27 | |
| pitti | hendrixski: but you don't actually need to use my code | 15:27 |
| pitti | hendrixski: but you can look at it how to call apt-ftparchive | 15:27 |
| pitti | hendrixski: (it took me some hours to get that working, too; it's very nonobvious) | 15:27 |
| pitti | soren: any idea why dnsmasq is split into -base and dnsmasq in that weird way? | 15:29 |
| soren | pitti: WHy is it weird_ | 15:29 |
| soren | ? | 15:29 |
| hendrixski | pitti, heh, yeah, I spent a few hours googling for it yesterday, and even asked about it at my LUG meeting last night... nobody could find it so that's when I posted the question on this channel last night. We figured there must be a third party tool for it :-p | 15:29 |
| pitti | soren: dnsmasq should be arch: all, but isn't | 15:29 |
| pitti | soren: and hardly has any files | 15:30 |
| soren | pitti: Gah, I told him to change that.. | 15:30 |
| pitti | soren: and dnsmasq-base has binaries | 15:30 |
| soren | pitti: It's to make the upgrade path sane fo ranyone who's used to having dnsmasq installed. | 15:30 |
| pitti | soren: the common pracice is that -base is arch: all and has the non-arch stuff (conffiles, mo files, etc.) and dnsmasq has the binaries | 15:30 |
| pitti | soren: that's even more confusing; why would someone rename dnsmasq to -base when there's no other package? | 15:31 |
| soren | pitti: Right. dnsmasq-base has all the binaries and stuff so that stuff like libvirt can depend on it without suddenly installing a running dchp and dns server on the system. | 15:31 |
| pitti | soren: aah | 15:31 |
| soren | pitti: And for people who are used to having dnsmasq installed, they'll get the expected results. | 15:31 |
| pitti | so that should be s/-base/-bin/? | 15:31 |
| soren | It could be. | 15:31 |
| soren | I took the packaging from an upstream rc. | 15:32 |
| pitti | ok, that clears it up a bit | 15:32 |
| pitti | so apart from dnsmasq not being arch:all it looks alright | 15:32 |
| soren | I can change it here, and tell him to do the same before he uploads to Debian. | 15:32 |
| soren | Would you prefer that_ | 15:32 |
| * soren is going nuts over changing keyboard mappings.. | 15:33 | |
| soren | Would you prefer that? | 15:33 |
| pitti | soren: sounds good; I'll accept it for now | 15:33 |
| soren | pitti: WHy shouldn't dnsmasq be arch: all? | 15:33 |
| soren | pitti: It has not binaries. | 15:33 |
| soren | pitti: Er.. It has not arch-specific binaries. | 15:33 |
| pitti | soren: for that very reason :) | 15:33 |
| soren | Whuh... | 15:34 |
| soren | You want me to change it to arch: any because it has no binaries? wtf? | 15:34 |
| pitti | it should be arch:all | 15:34 |
| soren | It... is? | 15:34 |
| pitti | soren: no, I'd like you to change it to arch:all | 15:34 |
| * soren is confused | 15:34 | |
| soren | My local version here is arch:all. | 15:34 |
| pitti | soren: no, in NEW I have dnsmasq_2.40-1ubuntu1_{sparc,powerpc,lpia,ia64,i386,hppa,amd64}.deb | 15:35 |
| soren | How does that make sense? It's been there all the time? | 15:35 |
| soren | Why would it be regarded as NEW? | 15:35 |
| pitti | http://archive.ubuntu.com/ubuntu/pool/universe/d/dnsmasq/dnsmasq_2.40-1ubuntu1.diff.gz | 15:36 |
| pitti | soren: that has arch:any for dnsmasq | 15:36 |
| pitti | soren: -base is NEW | 15:36 |
| soren | pitti: Hmm... so it does. | 15:36 |
| sistpoty|work | tjaalton: I've seen that nvidia-settings is removed... can you ship the headers/lib from the restricted-modules package then? | 15:37 |
| soren | pitti: Ok, I'll change that with my next upload. You also want me to rename -base to -bin? | 15:37 |
| pitti | soren: don't worry about the renaming if it introduces a delta to debian; it just confused me a bit | 15:37 |
| soren | pitti: I'll see if I can make upstream do the same. That'll make everything much easier. | 15:37 |
| tjaalton | sistpoty|work: no, those are not available anymore | 15:38 |
| sistpoty|work | tjaalton: sure they are... I just checked the latest nvidia-settings upstream | 15:38 |
| tjaalton | sistpoty|work: at least the nvidia installers don't have them | 15:38 |
| tjaalton | sistpoty|work: where's that? | 15:38 |
| sistpoty|work | tjaalton: ftp://download.nvidia.com/XFree86/nvidia-settings/ | 15:39 |
| tjaalton | sistpoty|work: ok, so the real solution would be to drop n-s from the drivers and ship the latest upstream? | 15:40 |
| sistpoty|work | tjaalton: I guess so | 15:41 |
| sistpoty|work | tjaalton: though I don't know the relationship between the library and the restricted modules (in case of hidden dependencies) | 15:41 |
| tjaalton | I don't think there are any | 15:42 |
| sistpoty|work | then I guess that would be the best solution... *shrug* | 15:42 |
| * persia notes this will be confusing for users who have been told to ignore the independent n-s since pre-Dapper | 15:43 | |
| tjaalton | and I closed all the open bugs against it :) | 15:44 |
| sistpoty|work | heh | 15:45 |
| tjaalton | although most of them were about conflicts | 15:45 |
| tjaalton | or wrong api version | 15:45 |
| sistpoty|work | persia: l-r-m could recommend nvidia-settings, so nvidia-settings could happily live in universe? (I've seen no signs of it being non-free so far) | 15:47 |
| persia | sistpoty|work: Would it still work that way with recommends-by-default? | 15:48 |
| pitti | frafu: FYI, I just binary-NEWed mousetweaks | 15:48 |
| tjaalton | sistpoty|work: it was Suggests before | 15:48 |
| soren | pitti: Ah... I was nice enough to send the patch to fix the architecture (and a few other things) things to dnsmasq upstream, but didn't apply them here. Go figure. | 15:48 |
| sistpoty|work | persia: yes | 15:48 |
| pitti | soren: lol | 15:49 |
| tjaalton | sistpoty|work: how about just providing the headers from nvidia-settings source? | 15:49 |
| frafu | pitti: good news :-) thanks | 15:49 |
| sistpoty|work | tjaalton: and have nvidia-settings binary come from l-r-m? | 15:50 |
| tjaalton | sistpoty|work: binary, desktop-file etc | 15:50 |
| sistpoty|work | tjaalton: sure, why not | 15:50 |
| tjaalton | man-page too | 15:50 |
| persia | That sounds more reasonable to me. Easier to ensure nvidia-settings works with whichever are the current drivers. | 15:51 |
| sistpoty|work | then there would only be a libnvsomething-dev packages from the nvidia-settings source... I like the idea | 15:52 |
| tjaalton | persia, sistpoty|work: I'm away most of the weekend, so it would be cool if you have time to make those changes | 15:53 |
| sistpoty|work | tjaalton: sure, will do | 15:54 |
| tjaalton | maybe I should fix lrm before it hits all the mirrors.. | 15:55 |
| tjaalton | hmm actually there isn't anything to fix :) | 15:56 |
| tjaalton | I was just confused | 15:56 |
| sistpoty|work | yes, only get nvidia-settings source back in, but I'll take care for this | 15:56 |
| tjaalton | sistpoty|work: yep, thanks | 16:01 |
| sistpoty|work | np | 16:01 |
| pitti | thekorn: your fix has a small bug | 16:09 |
| pitti | self.__attachments = set(attachment) | 16:09 |
| pitti | TypeError: 'Attachment' object is not iterable | 16:09 |
| pitti | thekorn: that should be set([attachment]), I think | 16:09 |
| pitti | thekorn: also, I think | 16:12 |
| pitti | if isinstance(attachment, LPAttachment): | 16:12 |
| pitti | self.__attachments = set([attachment]) | 16:12 |
| pitti | thekorn: that should be s/self.__attachments/attachment/ | 16:12 |
| pitti | thekorn: since below you always iterate over attachment | 16:12 |
| pitti | thekorn: alternatively, replace the following line ('if attachment:') with 'else:' ? | 16:13 |
| pitti | thekorn: the former is incorrect; else: is fine, I think | 16:13 |
| * soren boggles at https://answers.edge.launchpad.net/udpkg/+question/23226 | 16:18 | |
| maximilion | Hello :) Ubuntu was easy enough to get running proper, now I feel like coding :) If I want to make a 3D game, which 'engines' do you recommend? | 16:18 |
| pitti | zul: libxen NEWed | 16:18 |
| * soren hugs pitti again | 16:18 | |
| zul | pitti: thank you | 16:18 |
| soren | Thanks very much! | 16:18 |
| * soren begins the upload spree. | 16:19 | |
| maximilion | Hmm, seems the guy that recommended I ask here didn't know if this was only for devs of the distro. | 16:19 |
| maximilion | Sorry if this is the wrong place. If so, could someone give me a hint (forum, channel...)? | 16:19 |
| jdong | maximilion: I don't know where specifically it's best to ask that question, but this channel is certainly not going to give you meaningful answers :) | 16:22 |
| maximilion | That's ok. Is this channel only for OS coders, or other contributors? | 16:23 |
| pitti | maximilion: it's mostly used by developers *of* ubuntu (see topic), not developers *on* ubuntu | 16:24 |
| pitti | maximilion: however, there is a debian/ubuntu games team which might have some input | 16:24 |
| maximilion | Yep, got it. Well, I'm far from that level yet ;) | 16:24 |
| maximilion | See you anyway :) | 16:24 |
| slinky_ | exit | 16:24 |
| slinky_ | d'oh! | 16:25 |
| === \sh is now known as \sh_away | ||
| ulaas | hi! how to install ubuntu on a sata raid card not have modules by default but have source code to build? | 17:12 |
| slangasek | pitti: but AFAICS, syncing a package is orthogonal to reviewing a package for NEW processing? Or is it implicit that if the package was accepted in Debian, it doesn't need further review before accepting? | 17:15 |
| pitti | slangasek: yes; we generally assume that stuff that went through Debian NEW is distributable | 17:16 |
| pitti | slangasek: otherwise it'd cost us weeks at the beginning of a release | 17:17 |
| slangasek | mm, fair enough | 17:17 |
| ulaas | how to install ubuntu on a sata raid card not have modules by default but have source code to build? | 17:22 |
| slangasek | ulaas: this is not a support channel; please see #ubuntu for support | 17:23 |
| ulaas | slangasek: already did. sorry | 17:25 |
| seb128 | slangasek: is pam_getenv supposed to use /etc/default/locale nowadays? | 17:37 |
| cjwatson | its manual page hints that it ought to in the future | 17:38 |
| cjwatson | I think the future is now :) | 17:38 |
| seb128 | slangasek: on new installation pam_getenv -l LANG doesn't return anything which makes gdm always use english | 17:38 |
| slangasek | seb128: uh, the point of moving the lang stuff to /etc/default/locale was to have a file that wasn't under PAM's purview, that was guaranteed to be sourceable as shell and would only contain the locale settings | 17:43 |
| slangasek | seb128: so please adjust gdm to source the file directly? | 17:43 |
| seb128 | slangasek: will do, I was just wondering if pam_getenv was still supposed to return something useful | 17:45 |
| cjwatson | slangasek: lots of things seem to do pam_env.so [readenv=1] envfile=/etc/default/locale | 17:45 |
| cjwatson | like shadow and gdm; I did the same in openssh 'cos it seemed like the usual practice | 17:46 |
| slangasek | seb128: I would argue not, but then I think pam_getenv was written by Mithrandir so he may have had different plans | 17:46 |
| slangasek | cjwatson: yes, the convention is that PAM services that care about the env should pull from both files; but for things that aren't PAM, the locale setting is exposed in a separate file with different syntax requirements | 17:47 |
| slangasek | ah, no, looks like hartmans wrote pam_getenv | 17:49 |
| === dreamnid_ is now known as dreamnid | ||
| ScottK | pitti: I'm looking at dapper-upates and I see that clamav was copied over, but I don't see any of the reverse depends copied? | 18:06 |
| pitti | ScottK: erm, there are more source packages? | 18:07 |
| thekorn | pitti, this patch should fix the lptime issue for me, http://paste.ubuntu.com/4350/ | 18:07 |
| ScottK | pitti: It was listed in that bug. | 18:07 |
| thekorn | it is a little rough but works ;) | 18:07 |
| ScottK | pitti: Do you want me to do it with also affects ... | 18:07 |
| pitti | ScottK: what was the bug# again? I'll do it right now | 18:08 |
| ScottK | pitti: Bug #190187 | 18:08 |
| ubotu | Launchpad bug 190187 in clamav "Dapper clamav has multiple security issues that require upgrade to new version to fix" [High,Fix released] https://launchpad.net/bugs/190187 | 18:08 |
| pitti | ScottK: sorry, I missed that | 18:08 |
| ScottK | No problem. | 18:08 |
| ScottK | Thanks for tending to it. | 18:08 |
| pitti | thekorn: heh, great | 18:08 |
| pitti | ScottK: all copied over | 18:15 |
| ScottK | pitti: Thanks again. | 18:16 |
| * swingr is away: Gone away for now. | 18:23 | |
| evand | meh, can we pop up a warning when we discover the user has installed the nvidia package from nvidia.com, perhaps in Jockey? It is still evil, right? | 18:24 |
| === Traxer is now known as Traxer|on | ||
| === Traxer|on is now known as Traxer | ||
| === azeem_ is now known as azeem | ||
| jdong | what's the status of bug 177570? | 18:52 |
| ubotu | Launchpad bug 177570 in hal "[hardy] two batteries display when left clicking on g-p-m" [Medium,Confirmed] https://launchpad.net/bugs/177570 | 18:52 |
| jdong | it seems like the cause and proposed solutions are pretty complete already | 18:53 |
| jdong | can someone with expertise weigh in on what to do? | 18:53 |
| mjg59 | jdong: It probably needs to be reassigned to the kernel | 18:54 |
| jdong | mjg59: ok, so the solution is to only build one of the two interfaces? | 19:03 |
| mjg59 | jdong: That's the simplest one, yes | 19:05 |
| mjg59 | Though it can also be worked around in hal | 19:05 |
| === _stefan_ is now known as sistpoty | ||
| jdong | mjg59: would you be willing to comment on the bug report? | 19:17 |
| jdong | mjg59: have you had a chance to review bug 188261 yet? | 19:37 |
| ubotu | Launchpad bug 188261 in pm-utils "[debdiff] pm-utils modunload nonfunctional" [Medium,Triaged] https://launchpad.net/bugs/188261 | 19:37 |
| Aloha | what is the scope of ubuntu support? | 19:45 |
| jdong | Aloha: can you clarify/rephrase? | 19:46 |
| Aloha | jdong, like what kind of problems does paid support help you with? like if i rm -fr / my computer will they walk me through something. or if my network card or sound card doesn't work will they walk me trhough that? | 19:47 |
| jdong | that's more clear a question, but I don't have an answer :) | 19:48 |
| === cjwatson_ is now known as cjwatson | ||
| mjg59 | jdong: I'm back in the UK next week and should have time to deal with bugs then | 20:08 |
| sladen | good answer! | 20:09 |
| mjg59 | This week is implementation | 20:10 |
| === Ubulette_ is now known as Ubulette | ||
| sistpoty | hm... if I'll reupload nvidia-settings (which was killed today), should I include all changelog entries in the .changes file (since it's a new package then)? | 21:03 |
| ScottK | You're keeping them all in debian/changelog, right? | 21:05 |
| sistpoty | ScottK: the only ubuntu change was from me... so I "reimported" the unstable package, add a new upstream version and currently try to make it build | 21:06 |
| sistpoty | (in a way tjaalton agreed with me today) | 21:06 |
| ScottK | In that case I'd just put whatever wasn't previously in Ubuntu in .changes. | 21:06 |
| sistpoty | hm... okey... though I guess LP will treat is as completely new (*hopefully*) | 21:07 |
| === Ubulette_ is now known as Ubulette | ||
| doko | slangasek: please accept bash-completion (NEW) and move it to main (splitted out from bash) | 22:34 |
| === kylem_ is now known as kylem | ||
| slangasek | doko: done | 23:21 |
| geser | slangasek: can you move sivp to multiverse as it build-depends on scilab from multiverse or should I open a bug for it? sivp is in contrib in Debian | 23:56 |
| slangasek | geser: done | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!