[00:31] why isnt reiser4 in ubuntu [00:32] 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:33] if and when it is integrated into mainline Linux, we'll almost certainly include it [00:34] ext4 is in the kernel but not avalibalbe for installation [00:35] arcticpenguin380: ext4 is not guaranteed to maintain a consistent on-disk format yet [00:35] Until that's guaranteed, we can't offer it for installation === Traxer is now known as Traxer|on === Traxer|on is now known as Traxer === greeneggsnospam is now known as jsgotangco [02:32] maintainer of the emacs22 package speaking [02:32] would a main sponsor be willing to act on Bug #172389, which has had a new version languishing for 4 weeks? [02:32] Launchpad bug 172389 in emacs22 "Please upload emacs22 22.1-0ubuntu10" [Undecided,Fix committed] https://launchpad.net/bugs/172389 [02:32] the patch attached there fixes a handful of other bug reports in addition to that particular one [04:06] how can one force a autoreconf if a new option for configure has been introduced? [04:08] MacSlow: Depends on how the package gets built now. [04:08] There is the autoreconf command, which might help in what you want to do. [04:09] TheMuso, I know how to do it all "outside" of dpkg with the normal upstream codebase [04:10] TheMuso, but I want to avoid adding the diff to the configure file to a debian/patch/foo_bar.patch [04:10] I just added the diff to the configure.in [04:10] and added a one-line diff to the debina/rules file [04:11] but during "dpkg-buildpackage -rfakeroot" configure is not automatically recreated (thinking of it, it makes sense that it's not recreated) [04:11] I presume you're passing -f. [04:12] no [04:12] crimsun, would that need to be passed to dpkg-buildpackage?! [04:12] (to autoconf) [04:17] thanks to whoever just uploaded emacs22 22.1-0ubuntu10; it is much appreciated [04:17] mwolson: yw. [04:23] crimsun, there's no autoconf-related dh_something command or is there? [04:24] MacSlow: not AFAIK. [04:24] I certainly don't claim to be an authority on debhelper, however. [04:25] so there's no way around adding the diff to configure itself?! [04:25] No I don't think there is any dh magic to help. [04:25] damn [04:25] MacSlow: well, err, what I've done in the past is use "autoreconf -f" [or "autoconf -f"] [04:26] crimsun, I know about that [04:26] it does bloat your Build-Depends, but it has always worked for me. [04:26] I just wanted to avoid doing this bigger delta to upstream [04:26] but I hate taht [04:26] that === awalton__dos is now known as awalton__ === lando__ is now known as lando [04:37] a ~3000 line diff just for a newer version of the configure file [04:37] *spew³* [04:43] MacSlow: Isn't autotools wonderful? :( [04:44] 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 === greeneggsnospam is now known as jsgotangco [04:45] It would be rather nice to have a dh_autoconf or somesuch; basically a special-cased patch system. [04:47] 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. === asac_ is now known as asac [07:40] mjg59: hey, will you push the DIX patch upstream? [07:41] pitti: Archive day today? [07:42] tjaalton: Which one? [07:42] tjaalton: Oh, the scaling one? It's in bugzilla already [07:42] mjg59: the one that stevenk applied on xserver [07:42] I didn't write it :) [07:42] ah [07:42] which bug? [07:43] Hm. [07:43] right, it was "from", not "by" :) [07:43] Don't have it to hand, I'm afraid [07:43] ok, I'll dig it up [07:44] mjg59: you mentioned a while ago that synaptics needs some love.. any news on that? [07:44] Still working on the Xi code for that [07:45] ok [07:55] good morning [07:56] morning dholbach [07:56] hey Hobbsee [08:00] * Hobbsee sigh [08:00] please do *not* run cron.daily when i'm not at dinner! [08:03] Good morning [08:03] soren: archive day> yes [08:04] hendrixski: sure, see first paragraph of https://wiki.ubuntu.com/DebuggingProgramCrash [08:06] morning pitti! [08:09] hey Hobbsee [08:10] * pitti waves to dholbach, too [08:10] * Hobbsee hugs pitti [08:10] * pitti tickles Hobbsee [08:10] * Hobbsee stomps on pitti's feet === carlos_ is now known as carlos [08:11] * pitti jumps away in time and steals the long pointy stick [08:11] hey carlos! [08:11] pitti: hi [08:12] 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] Mithrandir: yeah, but the laptop is never on then, so i'm expecting it runs when it gets turned on [08:13] * pitti sighs at new -- 223 items [08:16] Good morning [08:17] pitti: if you do two of those, there'll only be 221 left! :-) [08:18] Mithrandir: hey -- I should've thought of that! [08:18] good morning warp10 [08:18] Hey pitti! [08:18] pitti: and then you can do two more and there'll only be 219 left. And so on. :-P [08:18] hm, seems that nobody else processed NEW during the week :/ [08:26] Hm... Do I want "Intel 3945ABG Wireless Card" or "Dell Wireless 1505 802.11a/g/n" ? [08:26] the former [08:26] probably intel [08:26] pitti: I didn't but I can give you a hand on it today [08:27] Performance or guaranteed-working. Choices... :) [08:27] any thunderbird user around? [08:27] soren: 11n is still in draft [08:27] pitti: Which one did you get in your Dell? [08:27] seb128: yeah [08:27] soren: not a full RFC/standard/spec [08:27] thegodfather: That's a good point. [08:27] * Hobbsee --> dinner [08:27] I'm probably missing something obvious, but how do I update the messages counts? [08:27] soren: I have the 3945 [08:27] pitti: And you're happy? [08:27] soren: I had the alternative of a 4965 [08:28] soren: it's working fine, at least with the gutsy kernel [08:28] soren: iwl3945 seems to work fine. [08:28] on hardy [08:28] soren: the iwl3945 driver (hardy) has troubles with my home's wifi [08:28] like evolution does on send&receive [08:28] Oh. It says the 4965 is only for Core Solo. [08:28] to know which folders have unread mails [08:28] soren: but it worked fine for all wifis in London [08:28] pitti: Interesting. [08:28] pitti: what sort of issue? [08:29] pitti: Yours is the Latitude D430? [08:29] soren: once I do have a connection, it works fine here, too [08:29] nm0.7 doesn't work on my home wifi, I had to downgrade to 0.6 [08:29] using my d630 [08:29] but often it doesn't see the essid [08:29] it was working fine in london [08:29] so it takes some rounds of rmmod/modprobe/sudo iwlist scanning until it works [08:29] soren: d430, yes [08:29] erk [08:30] seb128: are you subscribed to the folders? [08:31] seb128: oh, change mail.check_all_imap_folders_for_new to true, in about:config [08:31] and make sure you're subscribed to the folders you want [08:31] Hobbsee: ok, no wonder people think thunderbird is faster if it doesn't update anything :-p [08:31] :P [08:33] soren, seb128: nm0.7 works well here (same as 0.6) [08:55] seb128, any idea how to force "dpkg-buildpackage -rfakeroot" regenerate configure from configure.in, which is altered by an included patch? [08:56] urg? [08:56] cdbs-edit-patch 90_autoconf_update [08:56] autoconf [08:56] rm -rf autom4te.cache [08:56] ctrl-D [08:56] seb128, I want to avoid addint a ~3000 lines diff to my patch just for having --enable-gconf be used [08:56] run autoconf usually is not that much change [08:56] we do it for lpi in lot of packages [08:56] (provided that you use the same autoconf version) [08:57] pitti, seb128: well I'm on current hardy here [08:57] that doesn't matter [08:57] ? [09:00] using the same autoconf than upstream does the diff smaller [09:00] but you don't care about 30 lines or 3000 lines changes [09:00] that's still small in the diff.gz [09:01] I could live with 30, but not with 3000 [09:02] why not? [09:03] don't look at the GNOME packages in ubuntu and debian then [09:03] Ok I won't :) [09:03] we have many autoreconf patches with ten of thousand lines of changes [09:03] I try to keep patches comphrehendable [09:03] that's just running autoconf there and doing a patch with the changes, what is the issue, [09:03] 90_autoconf_update is a patch with autoconf update as indicated by the name [09:04] who would like to read that? [09:04] that's the reason why we split the code change and the autoconf run [09:04] you have your small patch for changes you wrote [09:04] and one for the autotools update that nobody read, they just know that's an autoconf call to update [09:05] 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] and I still don't know how to make sure the new strings will show up for translation in LP [09:05] just ask on IRC if you are blocked, I'm happy to help you [09:06] there's no .pot file anywhere in libwnck-2.21.90 [09:06] easy enough, just make sure the file with the strings is listed in po/POTFILES.in [09:06] it is [09:06] 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] the pot are created at build by running intltool-update -p usually [09:06] it's not adding new source files... just adding some strings in existing sources [09:06] cdbs does that for you [09:06] just build and look after the build to the po directory [09:07] if you have _() correctly around those they will be translatable [09:07] well the build does not work (incorporate my changes, due to the --enable-gconf not being applied to configure) [09:08] 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:09] MacSlow: come on, there is nothing to do, just build your package and look to po/ and the pot is there [09:10] MacSlow: and for the configure update I gave you the exact commands to type 15 minutes ago [09:11] 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:13] seb128, ok verified that the libwnck.pot does have the newly introduced strings [09:13] trying the configure-stuff now [09:13] 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:14] TheMuso: changed> it doesn't detect and show the driver for you? [09:15] pitti: Not in the window, nothing is listed. [09:16] TheMuso: ok; can you please send me jockey-gtk --debug --list output again? [09:16] pitti: Ok. [09:29] seb128, hm... compilation currently fails due to not foudn gconf-includes... trying to figure out why [09:30] MacSlow: where is your patch. [09:30] ? [09:33] 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:34] and what error do you get? [09:35] on compilation of pager.c:41:32 error: gconf/gconf-client.h: No such file or directory [09:35] ah [09:35] somehow the stuff from configure does not get pulled in [09:35] you did Makefile.am changes [09:35] it works with doing th stuff again upstream [09:35] not only configure [09:35] hm.. [09:35] change the 90_autoconf_update to be 90_autoreconf_update [09:35] and run autoreconf -v -f instead of autoconf there [09:36] autoreconf should have been better [09:36] that will update the Makefile.in too [09:36] I'll redo the 90_thing with autoreconf -v -f === doko_ is now known as doko [09:39] next try [09:40] nope that failed with the same error [09:42] is GCONF_CFLAGS set in the Makefile? [09:43] seb128, see http://people.ubuntu.com/~mmueller/02_expose_wm_keybindings.patch [09:44] MacSlow: still broken? [09:44] let me try [09:44] right in the first 30 lines or so [09:44] those changes there work with libwnck-2.21.90 when building it normaly (without the debian-tools) [09:45] no clue why it fails otherwise [09:46] MacSlow: looks like you did run autoreconf in your autoreconf patch [09:46] MacSlow: can you put your dsc and diff.gz online? [09:46] I just tried the patch with an autoreconf -v -f run and that build fine [09:46] but wasn't that what you told me? [09:47] what? [09:47] change the 90_autoconf_update to be 90_autoreconf_update [09:47] and run autoreconf -v -f instead of autoconf there [09:47] 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:48] you meant me to edit the fiile 90_auto(re)conf_update directly?! [09:48] no [09:48] drop the patch [09:48] I assumed you meant recreate it and use "autoreconf -v -f" instead of "autoconf" [09:48] cdbs-edit-patch 90_autoreconf_update [09:48] autoreconf -v -f [09:48] rm -rf autom4te.cache [09:48] ctrl-D [09:49] debuild [09:49] yes, that's what I did [09:51] ok... so know I have a freshly grabbed libwnck-2.21.90 [09:51] I copied changelog and 02_expose_wm_keybindings.patch [09:51] no 90_autoconf_update or 90_autoreconf_update yet [09:52] I now create that by calling cdbs-edit-patch 90_autoreconf_update (followed by the stated commands in the created shell session)?! [09:53] seb128, ? [09:55] is there a difference between calling "debuild" or "dpkg-buildpackage -rfakeroot"? [09:55] MacSlow: yes, do those [09:55] it fails here still [09:55] MacSlow: debuild makes use of dpkg-buildpackage -rfakeroot and writes a build log (it's a wrapper) [09:55] MacSlow: debuild does some extra magic, cleaning environment, and selecting GPG keys, etc. [09:55] calling lintian too [09:55] * MacSlow hates this day [09:55] -rfakeroot shouldn't be necessary in hardy any more, BTW [09:56] MacSlow: copy the dsc and diff.gz online [09:56] MacSlow: calm down - it's not that bad :-) [09:56] dholbach, dude you have no idea how unproductive I feel right now [09:57] MacSlow: take one step, then the next - you'll figure it all out and it'll be fine [09:57] dholbach, I just followed seb128's described steps exactely and it failed [09:58] MacSlow: copy the dsc and diff.gz and I'll help you [09:58] I mean how much damage can I cause by copy&pasting seb128's commands [09:58] MacSlow: it'll be easier with a quick glance [09:58] seb128, they are of use although the build failed? [09:58] yes, precisely [09:58] I want to try with the same version here [10:00] 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] there you go [10:02] pitti: Interesting that. I use it out of pure habbit, and likely will nver stop using rfakeroot. :) [10:03] TheMuso: well, I grew up with debuild, and I'm a lazy typer :) [10:03] haha [10:03] pitti, Ctrl-R for the rescue I always say [10:03] heh [10:04] MacSlow: ok, I confirm the bug [10:04] seb128, so my setup here is broken? [10:05] any idea what's causing it? [10:07] MacSlow: looking at it [10:07] ok [10:16] MacSlow: bah, I figured [10:16] is it nasty? [10:16] MacSlow: you dropped the debian/rules --enable-gconf use [10:17] but how? [10:17] don't ask me [10:17] you diff.gz give a rules not using this option [10:17] you like took the source [10:17] copied the patch [10:17] the changelog [10:17] run autoreconf [10:17] and forgot to update rules? [10:17] you likely rather [10:18] but it's in the file 02_expose_wm_keybindings.patch [10:18] oh [10:18] patches are applied by the rules [10:18] how could that have been "dropped"? [10:18] you edit rules directly [10:19] what you did is racy [10:19] the rules is read before the patches are applied [10:19] so the change is not used [10:19] *sigh* [10:19] rules is a Makefile [10:20] so how would what I did in 02_expose_wm_keybindings.patch be done the "right" way? [10:20] edit directly debian/rules and drop the change from the patch [10:20] patches are for source change [10:20] the packaging is a debian thing, we directly edit the debian directory [10:20] ok [10:21] now for the 1432nd try [10:23] here goes the debuild [10:23] is it working now? [10:23] did not break yet [10:24] that show a bug in your code BTW [10:24] if --enable-gconf is not used the build try to build with gconf anyway and breaks [10:26] TheMuso: ah, thanks; got the bug [10:26] seb128, so the configure.in stuff is broken?! [10:26] ~pinp [10:26] MacSlow: yes [10:27] pitti: np [10:27] seb128, at least the build of the libwnck with my additions now finally worked here [10:27] 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] seb128, I'll look into the configure.in issue [10:28] pitti: I can leave it running for a day if you need. [10:28] 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] seb128, that those can come later [10:28] TheMuso: as you prefer; alternatively I can just send you updated .debs for testing; more work for you, less power consumption :) [10:29] seb128, anyway did you try the newer version of libwnck? [10:29] TheMuso: (well, I'll need testing from you for the graphical bits and the root operations anyway) [10:29] pitti: The mini doesn't use a lot so its no big deal. [10:29] pitti: Righto, I can leave it on overnight at least, so you can do what you need to. [10:29] TheMuso: cool, thanks; I'll mail you [10:29] pitti: No problem. [10:30] ...and I'm off for the night, and the weekend. [10:31] TheMuso: have a great weekend! [10:31] dholbach: You too. [10:34] MacSlow: I think the issue is ENABLE_GCONF case, you look for yes but don't handle the auto case there [10:36] seb128, there's implicit support for "auto"? === \sh_away is now known as \sh [10:51] 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] MacSlow: but your configure will still be buggy I think [10:51] if test "x$enable_gconf" != "xno"; then [10:51] PKG_CHECK_MODULES([GCONF], [gconf-2.0 >= 2.20.0]) [10:51] CFLAGS=-DUSE_GCONF [10:51] that should be conditional to whether the gconf-2.0 is installed [10:52] because you set the CFLAGS anyway there [10:54] MacSlow: setting the default value to yes should do the trick [11:15] 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:16] Riddell: gnome applet didn't? how? [11:17] Riddell: do we have a bzr sync for nm kde 0.7? where is that maintained? [11:17] asac: no, I just stole the source from suse [11:18] asac: gnome applet didn't show any devices for me [11:18] so they do in house development? [11:18] Riddell: anything in /etc/n/i ? [11:18] asac: just "lo" [11:19] can you paste syslog somewhere? does nm bring down interfaces if you start it? [11:19] Riddell: ^^ [11:25] asac: Feb 8 11:24:14 wido NetworkManager: nm_dbus_manager_init_bus(): Could not get the system bus. Make sure the message bus daemon is [11:25] running! Message: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory [11:25] Riddell: huh .. which version? [11:25] is what happens when I /etc/init.d/dbus stop and start again [11:25] is there still a nm around? [11:25] dbus 1.1.2-1ubuntu2 network-manager 0.7~~svn20080121t191418+eni1-0ubuntu0~pre7 [11:26] isn't system bus hal? [11:27] I imagine hal uses it === Kopfgeldjaeger is now known as KGJ|frustriert [11:31] Riddell: do you still have the 25NetworkManager in /etc/dbus-1/event.d ? [11:31] Riddell: 0.7 is restarted by /etc/init.d/NetworkManager restart atm [11:37] pitti: Your laptop has the trackpoint thing, doesn't it? [11:38] soren: both a touchpad and a trackpoint [11:39] pitti: Awesome. I just ordered mine, and it suddenly occured to me that I wasn't sure if it had such a thing. [11:54] asac: when I run /etc/init.d/NetworkManager I get http://kubuntu.org/~jriddell/tmp/nm [11:57] console kit [11:59] is that related to nm? === cjwatson_ is now known as cjwatson [12:13] Riddell: does kdm register a ConsoleKit session? [12:13] (sorry if I missed the discussion due to network trouble) [12:14] cjwatson: it tries to, seems to be having some issues though [12:15] asac: not that I know of [12:32] 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] Launchpad bug 72979 in nvidia-settings "Please remove nvidia-settings from gutsy" [Low,Confirmed] https://launchpad.net/bugs/72979 [12:38] persia: refresh :) [12:39] persia: I just uploaded a new revision which installs nvidia-settings in nvidia-glx-legacy [12:39] so nvidia-settings can be removed from hardy [12:39] tjaalton: Excellent! That bug has been bothering me for a rather long time. Thank you. [12:40] no problem, now some lunch -> [12:42] 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:43] mvo: I think that this line is wrong? [12:43] if $GPG --list-sigs --with-colons $add_key | grep ^sig | cut -d: -f5 | grep -q $master_key; then [12:43] mvo: shouldn't that be $GPG_CMD --keyring $ADD_KEYRING, rather than $GPG? [12:43] since the key isn't necessarily in /etc/apt/trusted.gpg yet [12:50] cjwatson: let me check [12:50] MOTU Q&A session in #ubuntu-classroom in 10 minutes [13:04] 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:11] mvo: thanks! I just uploaded an apt-setup that seeds /var/lib/apt/lists with signed Release files [13:11] nice! [13:11] mvo: is there any more to AptAuthenticationReliability, or can I mark it implemented now? [13:12] cjwatson: I think that was it, we should be done (modulo bugs of course) [13:12] mvo: maybe the notification on failed updates? [13:13] 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:14] if s/did work/did not work/, I think that's good enough for me [13:15] yeah, s/did work/did not work/ indeed :) [13:15] we could enable the warning and turn it off if it annoys people [13:16] and check how much people actually see it, how widespread the problem is [13:16] that sounds like a plan [13:20] pitti: The trimmed amavisd-new (removed the milter) is uploaded, so it should be ready to be promoted. [13:20] ScottK: ah, neat; I checked this morning and didn't see it yet [13:21] I just uploaded. [13:21] pitti: Do you have a moment to discuss another issue. [13:26] ScottK: sure [13:26] 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:27] I've got a list of 12 or 13 CVEs that are open and valid against the current Dapper clamav. [13:27] It's old enough to be unmaintainable for any reasonable effort MOTU might be able to muster. [13:28] In dapper-backports, we uploaded the current clamav package (with some small changes to work on Dapper) and updated all the rdepends. [13:28] It's been several weeks now with no bugs filed. [13:29] pitti: My proposal is that these updates be copied from backports to dapper-updates. [13:29] At this point our choices boil down to this or leave the vulnerabilities. [13:30] If you think this is worth considering, I can file a bug with the CVEs and a complete package list. [13:33] ScottK: I do think that it is worth considering [13:33] ScottK: depending on how much positive feedback we got? [13:33] ScottK: I think we should open/find a bug suitable for SRU, copy -backports to -proposed, and call for testing [13:33] 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] ah, great [13:34] https://wiki.ubuntu.com/MOTU/Clamav?action=show [13:34] can you please include a pointer to these results into the bug? [13:34] Yes [13:34] Will do. [13:35] oh, that looks like great documentation [13:35] 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:36] ScottK: if it really has been proven that well already, that should suffice for verification [13:36] 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:37] pitti: OK. I do think we've tested it pretty thoroughly. [13:37] pitti: I've also uploaded a New amavisd-new-milter source package to maintain that binary in Universe. [13:38] 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] ScottK: what's the X in claws-mail-clamav? [13:38]