=== ScottK-vacation is now known as ScottK [02:01] hellow [04:07] good morning [04:08] dholbach: It's what, 5am? [04:08] StevenK: I didn't sleep very well, so I thought "why not get up and do some work?" - YAWN [04:09] morning dholbach! [04:09] hi Hobbsee [04:11] wow. since when does hppa only have 8 pending builds for intrepid? [04:11] Hobbsee: Since the other 5,000 failed [04:11] StevenK: ahh. that'd do it. [04:18] oheh. If one sees an FTBFS mail, one can almost be 100% sure that it is hppa that has failed. [04:19] do you have spam filters to throw them away? [04:25] james_w: congratulations! [04:26] * Darklock is still up, celebrating the fall of the CSU in bavaria :-> === bddebian2 is now known as bddebian [04:50] * Hobbsee beats dholbach with a herring [04:50] dholbach: yes, 6 mails later, I understand that james_w is a MOTU! :P [05:04] Master Of The Universe? [05:04] it is...... [06:38] Good morning [06:38] Hi pitti. [06:41] pitti! [06:41] * Hobbsee waves the "we love pitti" flag around, and drapes it over pitti's shoulders [06:43] (thanks to the we love pitti fanclub for the flag, which got borrowed) [06:43] * pitti blushes [06:44] BenC: I sub'ed you to bug 271956, I'd like to get your "still works" ack before uploading this; thanks in advance! [06:45] Launchpad bug 271956 in makedumpfile "Upgrade to new upstream version 1.2.9" [Undecided,New] https://launchpad.net/bugs/271956 [06:47] heh [06:47] i will bring a "we love pitti" flag to UDS [06:47] :D === macd_ is now known as macd [06:49] pitti: So, wgrant and I found two things that aren't in NBS, and should be. lib{32,64}ffi4 [06:51] StevenK: Ah, thanks - I'd forgot about those! [06:51] StevenK: oh? libffi4 was NBS, and removed a while ago [06:52] pitti: lib32ffi4 is still listed on amd64 [06:52] Filename: pool/universe/g/gcc-4.2/lib32ffi4_4.2.3-2ubuntu7_amd64.deb [06:52] $ asrc gcc-4.2|grep Binary.*ffi [06:52] $ [06:52] lib{32,64}ffi4 are very arch-specific, definitely NBS, but not in NBS. [06:52] sorry, asrc = apt-cache show-src [06:53] Right. [06:53] They're not built any more. [06:53] Their source is long gone. [06:53] They're still published. [06:53] But they're not in the generated NBS lists. [06:53] Built from gcc-4.2, which is currently 4.2.4-3ubuntu2 [06:54] http://launchpad.net/ubuntu/intrepid/amd64/lib32ffi4 [06:55] It could be because they're arch-specific, or because their source is published in another distroseries, or blah blah blah... [06:55] I've seen this previously, which arch-specific stuff. Is there maybe a way to tweak the NBS finder to find things like this? The last I found was some leftover linux-meta stuff. [06:56] s/which/with/ [06:56] I'm not entirely sure how the NBS finder works [06:56] Do we have the source? [06:59] wgrant: for the reverse depends checker yes, but the list of stale packages is created by a soyuz script, which isn't too useful without the corresponding database, etc. [07:00] pitti: Ahh, so it is a Soyuz bug after all. === fargiola` is now known as fargiolas|afk [08:37] to whoever build retried gnome-python-extras that didn't work because pygtk is out of sync between arch all and any pacakges due to xvfb being broken [08:39] seb128: oh, indeed, I was going to ask you about pygtk [08:39] seb128: I sponsored that trivial fix for the example hashbang, and it FTBFSed all over the place [08:39] seb128: oh, first: bonjour! [08:40] seb128: some failed due to xvfb, amd64 failed due to "extension "RANDR" missing on display ":99.0"" [08:41] That's an awesome FTBFS error in so many ways :) [08:41] pitti: guten tag ;-) [08:41] seb128: so I could maybe try the workaround with the mesa build dep, too? [08:41] pitti: we could, would be nice if the xorg guys were fixing xvfb though [08:41] * directhex hands pitti cake [08:48] I don't see a bug on that. Does it need one? [08:54] persia: well, not really; we need to get the damn thing building; if that's tricky to do, we could use a bug as discussion place, of course [08:54] I'll set up an intrepid chroot somewhere; it locally built fine [08:55] pitti: Makes sense. I was thinking one against xvfb, as I was also looking at pygtk today. [08:55] oh, xvfb, indeed [08:56] pitti: just do the workaround for pygtk I would say [08:56] seb128: will that also help for the xrandr thing? [08:57] seb128: I can do a test build on i386, but I currently don't have an amd64 pbuilder at hand [08:57] pitti: that seems to be a random xvfb error, dunno about it but it might [08:57] lool: ping [08:57] slangasek: pong [08:57] pitti: other option is to comment the xvfb-run call in debian/rules, it's just to call the testsuite [08:57] What did I break /again/ [08:58] :-P [08:58] pitti: or try the xvfb workaround on your ppa quickly? [08:58] seb128: hm, test suite iz good [08:58] seb128: oh, ppa, right! [08:58] pitti: ppa are great ;-) [08:58] pitti: I'm not the RANDR stuff is a failure [08:59] lool: :-) I see that elisa-plugins-good recommends: gtreamer0.10-ffmpeg and gstreamer0.10-plugins-ugly, both of which are in universe; I think those need to be demoted to Suggests? === dholbach_ is now known as dholbach [08:59] slangasek: Good point; I'll demote them for Ubuntu [08:59] lool: (I'm trying to track down why ffmpeg stuff is being wrongly pulled onto the livefs; elisa itself isn't to blame for this, but I might as well mention it :) [09:00] seb128: uploaded to my ppa, crossing fingers [09:01] slangasek: Hmm which verison of elisa-plugins-good are you looking at? [09:01] lool: 0.3.5-2; is that not current? [09:01] no, currents didn't build [09:01] No, the current one doesn't build because a package needs promotion to main and the MIR is pending since 10 days [09:01] ah [09:01] oh, well then [09:01] :) [09:02] I have in my TODO "* Find out who's processing MIR and ping them" [09:02] lool: ubuntu-mir ; pitti and doko [09:02] But also "* write a MIR for python-cssutil" [09:02] Of course the latter before the former :-P [09:26] pitti: bah, the pygtk builds failed in your ppa too [09:26] ah, same problem [09:32] pitti: dunno if you saw, I followed up to the console-kit-daemon crasher bug; the log certainly doesn't tell me anything, and the crashes are still happening [09:33] slangasek: ah, I hoped it would have a truncated log, or at least tell me at which precise point it crashes (when writing a session open or close log, or so) === mdz_ is now known as mdz [09:36] I reproduce the pygtk FTBFS in pbuilder [09:36] pitti: did there end up being any problems with langpack generation (bug #273489)? You suggested during the meeting to follow up on #-devel, not sure whether that's happened yet [09:36] Launchpad bug 273489 in rosetta "Remaining Intrepid template approvals" [Critical,Fix committed] https://launchpad.net/bugs/273489 [09:36] seb128: sorry to bug you again, but do you plan to update gst-plugins-base to latest prerelease? This is regarding DVD playback blocked with resindvd plugin. [09:37] slangasek: I did followup with jtv; apparently the rosetta export crashes for ominous reasons, he is investigating [09:37] ok [09:38] slytherin: not likely before beta now, no [09:38] pitti: Re: python-dateutil MIR; there's an embedded storm copy in elisa which is the code which relies on python-dateutil [09:38] ups [09:38] I don't know how easy it would be for storm to move to python-tz; I'll try to ask them, but it's unlikely that it happens in time for intrepid [09:38] somewhat I manage to close xchat-gnome tabs while switching workspaces sometimes [09:39] seb128: Ok. So should I try backporting the fix form upstream cvs? I will do that sometime tonight. [09:39] slytherin: if you want to, I'll try to update the version after beta [09:39] Ok, I think xvfb-run exits because it tries to kill Xvfb which already exited [09:40] (the program is set -e and the kill clearly fails) [09:40] * slytherin looks through intrepid schedule [09:50] lool: so eliza actually uses the time zone db in python-dateutil? [09:50] lool: I guess it's much easier in the end to make p-dateutil use the system tzdata than trying to convert storm [09:50] pitti: elisa uses storm which uses dateutil for db dates I guess [09:51] pitti: Got the same comment on #storm that it'd be simpler to fix python-dateutil [09:54] there are no way to get list of all package with name of /package/version upstream/ubuntu version/ ? [09:55] apt-cache send me the full version, no separate upstream version and ubuntu version [09:55] * lool tries a pygtk build with -s -noreset [09:59] Cool, pygtk actually liked that [10:01] slangasek, pitti: could you please look at pygtk 2.13.0-0ubuntu5 waiting for approval? It fixes a FTBFS similar as the one on the buildds for me (in pbuilder here though) [10:01] (Well it wasn't processed yet I guess) [10:03] seb128: I think I pushed a fixed pygtk [10:03] seb128: Are other packages likely affected? [10:03] lool: the change you mentionned was one of the workaround listed on #ubuntu-x the other day [10:04] Too bad I had to search for it then [10:04] seb128: How come it wasn't applied? [10:04] lool: well, gnome-python-extras, I opted for the libgl1-mesa-dri build-depends which was supposed to workaround that too, let's see if it builds after pygtk [10:04] It's not the same failure [10:04] ok so ignore my comment ;-) [10:04] shingara: there is a debian project for getting the upstream version based on debian/watch files [10:05] what project ? [10:05] ddpo [10:06] lool: thanks for fixing it, there is still a xvfb bug though? [10:08] shingara: Everything before the last - in a version should be the upstream version, or close to it. [10:09] xserver-xorg-driver-all_1:7.3+10ubuntu10 [10:09] and this package is the exception? [10:09] There's no upstream version for that. [10:09] It's a native metapackage. [10:09] seb128: Well it's a Xvfb design issue [10:09] ah [10:09] Rather xvfb-run [10:10] seb128: xvfb-run seems to assume only one client will connect, it seems [10:10] lool: which is not the case there? [10:11] lool: the issue you tracker was a different one indeed, the other one was a loop due to swrast_dri.so not being available [10:11] seb128: I think I had to add bdeps to pygtk already to fix this IIRC [10:11] * Build-dep on xauth and xfonts-base as xvfb-run needs these and also bdep [10:11] on libgl1-mesa-dri for now until Xvfb can start without AIGLX support or [10:11] this dep is added to the package. [10:11] pygtk 2.13.0-0ubuntu1 [10:12] ah right [10:12] seb128: I think what happens is that "make check" starts multiple individual commands (one per test) and each test connects and disconnects from the DISPLAY [10:12] that one is a xvfb bug then ;-) [10:12] Well, it's made to run a "client" not a command starting multiple clients [10:13] And the flag to not close after the first client is the one I added [10:13] It might be that we were trying to run multiple tests but in fact were only running one! [10:13] lool: ok, so that was not what we discussed the other day, thanks for fixing this one ;-) [10:13] I'm not too happy with xvfb-run in general, but here I think it's ok that we have to pass this special fla [10:14] flag [10:14] right, it's just weird that things were working without that before [10:14] Well TBH I'm not sure how they did [10:15] Perhaps make check was completing really quickly because of the closed Xorg connection and kill had still something to kill [10:15] No idea :-/ [10:15] lool: did you upload the fixed version to intrepid? [10:16] Yes [10:16] thanks [10:16] I pinged slangasek and pitti to unblock it [10:17] I should have pushed to my ppa to make sure [10:18] the bug fix explanation makes sense and if you verified in pbuilder that should be good enough ;-) [10:22] lool: rock, thank you [10:26] pitti: I think we should act on the python-dateutil situation one way or the other; it seems the only doable solution is to fix python-dateutil to use tzdata; I don't want to keep elisa non-buildable and non-installable further, so could you either demote elisa to universe or promote python-dateutil to main until we sort it out? === Ng_ is now known as Ng [10:27] I have no idea of the time budget to fix python-dateutil, but I have an idea of my time availability and I fear that nobody will step up before the intrepid release to fix it, so I prefer that we get at least some elisa testing, even if it's universe, or live with the tzdata copy in main [10:29] can I upload a main package directly to -proposed or should I wait for the ubuntu-sru ack? [10:29] it's held in -proposed until the bug is approved anyway ... [10:30] ok, I guess I can upload then [10:32] james_w: Congrats [10:32] thanks lool [10:33] seb128, pitti: pygtk failed ot build in ppa and ubuntu; it's a new error again [10:33] gra [10:34] bah, and all that just to fix an example script :/ [10:35] Now it's "Xvfb failed to start"; it does start with the same command-line in my pbuilder though [10:35] xvfb-run -s -noreset /usr/bin/make -C build-2.5 check [10:35] make[1]: Entering directory `/tmp/buildd/pygtk-2.13.0/build-2.5' [10:35] ... [10:35] xvfb-run -s -no-reset /usr/bin/make -C build-2.5 check [10:35] Xvfb failed to start [10:35] make: *** [build-2.5/build-stamp] Error 1 [10:35] dpkg-buildpackage: failure: debian/rules build gave error exit status 2 [10:36] (first is my pbuilder, second it buildd) [10:36] Now it might need some love from someone using sbuild [10:38] lool: so the pygtk in the queue shouldn't be accepted? [10:38] slangasek: No use to, it will ftbfs [10:38] :/ [10:38] Hmm I suspect XVFBARGS might get overwritten with -s [10:39] Not sure how this affects Xvfb [10:39] Anyone could do a test build in sbuild? Or should I throw at my ppa? [10:39] I'd like to change '-s -no-reset' to '-s "-no-reset -screen 0 640x480x8"' [10:40] lool: ppa will be faster to try [10:40] lool: i'd be surprised if that was the problem [10:40] jcristau: Any idea what it could be? [10:41] GRAH [10:41] I typoed the one I uploaded [10:41] to my ppa [10:41] lool: i'm tempted to change the default ERRORFILE in xvfb-run... [10:42] oh, yeah, there is an extra "-" [10:42] yeah [10:42] lool: accepted pygtk, let's cross fingers [10:43] jcristau: Wow this would certainly help debugging indeed! [10:48] lool: looking into -dateutil now [10:58] Status: Successfully built [10:58] woohoo [10:58] So the typo in my ppa upload was the only issue, sorry for the confusion [10:58] jcristau: And sorry for bothering :) [10:59] The second ppa upload with the proper flag name built fine [10:59] lool: I think I fixed -dateutil [10:59] pitti: woah [10:59] pitti: Well thanks [11:00] pitti: So I do owe you some beverage [11:00] lool: at least I broke the test suite after removing the tarball, and it runs fine again with my fix [11:01] could someone have a look at bug 231407 [11:01] Launchpad bug 231407 in pulseaudio "pulseaudio causes restart- volume-restore.table file not found" [Undecided,Confirmed] https://launchpad.net/bugs/231407 [11:01] it's still present in intrepid beta [11:01] no sound for VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller === xyz is now known as xyz_ [11:02] jcristau: I kind of wonder whether this kill isn't racy in all cases: here we have multiple commands, so it's obvious why it might fail, but even for a single client, it's not impossible that Xvfb shuts down before the kill is reached === xyz_ is now known as xxyz [11:02] lool: why would Xvfb exit? [11:03] jcristau: When X client disconnects [11:03] only if you pass -terminate [11:04] jcristau: I thought this was the default; I'm puzzled as to why -noreset helps if -terminate isn't the default [11:05] jcristau: Aha, the default is -reset [11:06] the default is to regen (shut down clients and screens, and re-init everything) [11:06] jcristau: I suspect the server restarts between commands [11:06] Hmm is this a good default [11:07] jcristau: Heh the xprint backend has dispatchExceptionAtReset = 0 [11:08] Since 2006; don't know how to check earlier history [11:11] jcristau: https://bugs.freedesktop.org/show_bug.cgi?id=764 seems to be related to Xprt [11:11] Freedesktop bug 764 in Server: Config: startup scripts "Xprt permanently resets itself after each client disconnect" [Critical,Resolved: fixed] [11:11] dd831c7a5c1b0c540a78350aadaeb34a8aa67395 in changelog [11:12] The rationale for xprint is slowness, and the fact that resources need to be configured again [11:13] * jcristau pretends Xprt doesn't exist [11:14] Xpfrt! [11:16] jcristau: I can't come up with an use case of xvfb-run where one wants to reset the server for multiple clients though: the script inherently suggests you're running a single command to do some stuff [11:16] So even if the Xvfb default has some rationale behind it, xvfb-run could pass -noreset by default I think [11:36] mvo: oh, you dropped the "remove landscape-client stub" update-manager code? IMHO this should still be present, we only install landscape-common by default [11:36] mvo: maybe you can drop that change from 1:0.93.18 and reupload (same version number is ok)? I'll accept it afterwards, so that we'll get hte xorg driver transition in time for beta [11:37] pitti: thanks, I can fix this after lunch [11:37] sorry, there seems to have been some confusion about the right handling of this [11:37] mvo: right, there was; this is the current approach now (isntall -common by default, but not -client) [11:37] mvo: I rejected the current upload; please ping me after you uploaded the new version, for immediate processing; thanks! *hug* [11:38] pitti: Can you have a look at linux-lpia? [11:38] pitti: It is mainly so we can switch back to aufs [11:39] StevenK: accepted, doesn't really affect ubuntu desktops [11:41] pitti: Thanks [11:46] * persia tries harder to make the lpia alternate CD work for installing ubuntu desktops [11:47] ls [11:47] / [12:07] hi [12:15] a package wants to install a dependency which has been renamed (libgsl0 became libgsl0ldbl), how could I fix that in the best way? [12:16] create an alias for that package? [12:16] rebuild the package with the old dependenc. [12:16] +y [12:17] Mithrandir, how can I rebuild that package? [12:17] and where should I get the old dependency? [12:17] or maybe, is there a way to ignore that dependency? because it is already installed [12:17] whyking: You don't need the old dependency: rebuilding should pull the new dependency. [12:18] hmm? You have package foo that depends on libgsl0. So you download the source, rebuild it using dpkg-buildpackage and install using dpkg. [12:20] can't I just tell apt-get to ignore the broken dep? [12:20] sth like --ignore-missing [12:20] because you don't have it installed? [12:21] Mithrandir, I have [12:21] everything is in place.. but he wants to install the old dependency.. the new one is installed [12:21] no, you don't. libgsl0ldbl and libgsl0 are two distinct libraries. [12:22] Mithrandir, are they? so why was libgsl0 deleted? [12:22] because it was superseded by libgsl0ldbl [12:22] but they are not completely compatible. [12:22] so you need to rebuild any applications depending on libgsl0 [12:22] ok, but it should work nonetheless then [12:22] mhh [12:23] I'd rather not :-/ its a huge source [12:23] no other way? [12:24] whyking: Rebuild anything depending on libgsl0ldbl with libgsl0, but that's the reverse of what everyone else will be doing. [12:24] persia, alright.. I guess I'll have to wait for upstream to fix it then [12:24] thanks [12:38] apachelogger: why is libksquirrel marked i386-only? [12:47] slangasek: should packages in main have a -dbg or -dbgsym package or is it only nice to have? [12:48] geser: -dbgsym packages are autogenerated; -dbg packages get in the way of this more than anything, so I wouldn't call them nice to have at all [12:48] slangasek: they 'get in the way'? [12:48] slangasek: libselinux has neither, and I wonder if it's important or only a wishlist bug [12:49] siretart: some packages are known to do things in the creation of their -dbg packages which breaks the -dbgsym extraction [12:49] slangasek: What about cases where -dbgsym autogeneration fails? [12:49] slangasek: From http://revu.ubuntuwire.com/details.py?package=libksquirrel: - Only build on i386 for now, have to talk to upstream about fixing amd64 build. [12:49] -dbg is only useful if the package needs a second pass to build useful debugging [12:49] if it doesn't, then a request for -dbg is neither important not wishlist, it's invalid [12:49] (or wontfix I suppose) [12:49] s/not/nor/ [12:49] if -dbgsym autogeneration fails, it should probably be fixed :-) ask pitti [12:50] * siretart wonders if he should make ffmpeg and xine stop building -dbg package in ubuntu [12:50] there's no need to introduce diffs to stop building -dbg packages [12:50] make them stop building -dbg packages in Debian :P [12:50] contrariwise, there's no need to put any effort into building them either [12:50] the problem is libselinux doesn't use debhelper so dh_strip isn't used and the trigger to build the -dbgsym doesn't get called [12:50] geser: ah, yes, heh [12:50] exceptions are things like python modules which need a second pass [12:51] it would be straightforward to call the dbgsym extractor, wouldn't it? [12:51] slangasek: I could, but I've found them rather useful. espc. for non-maintstream architectures. [12:51] 'mainstream', even. [12:51] it should be possible, if such change is deemed worth it [12:52] it should be no harder than creating a separate -dbg package, and produces better results [12:52] slangasek: are there guidelines in debian when and when not to provide -dbg packages? [12:52] siretart: no, unfortunately [12:53] :( [12:53] so we have awesomeness like -dbg packages for firewall tools [12:53] soren: hmm, and the revu page doesn't show the reason for the build failure... but ok, thanks [13:06] re [13:07] what's up wrt. -dbgsym breakage? [13:07] seb128: looking into the camera bug now [13:07] pitti: thanks [13:08] pitti: what dbgsym breakage? [13:08] discussed half an hour ago here, between slangasek, siretart, and cjwatson [13:08] pitti: not a breakage, but only a question how important it is if a package in main has no -dbgsym (or -dbg) package [13:08] pitti: see bug 275082 [13:08] Launchpad bug 275082 in libselinux "no debug symbols package in intrepid" [Undecided,Confirmed] https://launchpad.net/bugs/275082 [13:08] geser: oh; well, if it's a package which gets a lot of crash reports, we should fix it; otherwise I wouldn't waste too much time on it [13:09] pitti: turns out it's a package that doesn't use debhelper. I guess it's fairly easy to call the helper by hand too [13:09] seb128: hi, do you have any idea about the gstreamer0.10 build failure? [13:09] pitti: does ffmpeg/xine-lib break the apport retracer by providing -dbg packages? both are using debhelper [13:09] slangasek: oh, no, I wanted to ask lool or slomo about those [13:10] yes, it is: pkg_create_dbgsym debian/foo [13:10] siretart: ATM the retracer doesn't consider -dbg packages [13:11] lool, seb128: yay, pygtk built everywhere [13:11] pitti: that didn't answer my question ;) [13:12] siretart: ok, then; to literally answer your question: "no" :) [13:12] excellent :) [13:13] seb128: did you hear any news from the TB regarding my inquiry about ffmpeg? [13:13] siretart: "break" in the sense of "non-symbolic result if no -dbgsym is available": yes, "-dbg are merely available/present" -> no [13:13] siretart: no [13:13] seb128: FYI, an updated ffmpeg package is currently in debian NEW [13:13] pitti: okay, that means users have to retrace themselves. okay [13:15] lool, slomo: ping? Do you know what's up with the gstreamer.10 ftbfs?: http://launchpadlibrarian.net/17880819/buildlog_ubuntu-intrepid-i386.gstreamer0.10_0.10.20.2-1_FAILEDTOBUILD.txt.gz [13:24] pitti: have you some time to help me on the fdi file for some smart card readers? [13:25] geser: oh, sure; what's the issue? [13:25] pitti: do you think that the fdi file in 267682 is a right solution, and ready fo upload? [13:26] slangasek: I think it's a reasonable workaround for intrepid, yes; it's not a long-term correct solution (we should clean up that entire mess in jaunty) [13:27] slangasek: it was tested by a couple of thinkpad users now AFAICS [13:27] pitti: ok. Can you prepare the upload to add the fdi file to wherever is the appropriate place, or should I ask someone else about this? [13:28] slangasek: I think the most correct place would be the -evdev driver, wrt. correct behaviour of backported packages (i. e. we should not ship it in hal) [13:28] inspired by kirkland's work I started to write a similar file to grant access to smart card readers. I got it nearly working. I'm currently stuck at the point that it only works if I hardcode the device file name into the fdi file. [13:28] slangasek: yes, I can prepare the upload [13:28] pitti: ok, thanks [13:28] see http://paste.ubuntu.com/50012/ for my current fdi and policy file and the lshal output for the smart card reader [13:28] geser: you mean access to the raw device? [13:29] geser: do you know that a while ago StevenK already prepared this for all removable block devices? [13:29] pitti: to e.g. /dev/bus/usb/001/002 [13:30] pitti: it's to finally close bug 57755 which got stuck as it used a new group (scard) for it in the udev rules [13:30] Launchpad bug 57755 in gnupg "Udev Rules for SmartCard Support" [Wishlist,Confirmed] https://launchpad.net/bugs/57755 [13:31] geser: oh, right, I misunderstood what you meant with smartcards, nevermind [13:31] pitti: does it matter that the smart card reader appears as a character device and not as a block device? [13:32] geser: yes, it does; I mixed it up with "SD card" [13:33] I mean those to read a OpenGPG card [13:33] geser: right, I know now [13:34] geser: so, the tricky bit is to find out that a particular device is in fact an sd card reader [13:35] would it be possible to use the product id and vendor id? like in the proposed udev rules from that bug [13:35] asac: one-liner patch for you in ~mdz/network-manager/ubuntu.0.7/ [13:37] geser: yes, that's always a possibility, if there's a reasonably small list [13:37] geser: some devices have a particular device or interface class, but if that's not the case, there's no other way than to use vendor/product ID lists [13:37] pitti: update-manager uploaded [13:39] geser: btw, hal supports int_outof="0x001;0x002;0x003", that makes the rules shorter to write [13:39] pitti: currently it's only a small list, 2 or 3 devices from SCM which gpg supports natively [13:40] so the user needs access to the device file [13:40] mvo: and accepted, thanks [13:40] geser: if the list gets longer, the fdi should probably be autogenerated during build, but for now, a static one seems ok to me [13:41] geser: allow_inactive should be false, though, otherwise several user sessions race for grabbing the device [13:41] Hobbsee: bouh [13:42] geser: otherwise your paste looks quite good to me [13:42] seb128: i'm sorry? [13:42] seb128: (oh, and re: the last ping, i figured it out, thanks) [13:42] Hobbsee: nice to mail about not testing uploads to upload an anjuta which can't built [13:42] seb128: yeah, well. [13:43] pitti: do you have an idea why it only works if I hardcode the device file into the fdi? [13:43] Hobbsee: we need the new anjuta version, huat is working on it [13:43] if I use the copy-property line I get no acl for it [13:43] seb128: at least i found about it pretty quickly. And i'm not sure why no one in debian's reported the same problem yet. [13:43] seb128: yes, so he said. [13:44] Hobbsee: anjuta 2.24 has been uploaded to debian [13:44] seb128: yes, it has, and there's a grave bug about it. [13:45] seb128: however, it's not passed to unstable yet, and i'm surprised that the unstable version hasn't been rebuilt at all - given that it should be uninstallable by now? [13:45] mvo: could the upgrader be set to purge kdm-kde4 ? [13:45] geser: why do you copy it from the device's parent, and not from the device itself? [13:45] Hobbsee: I can't parse that [13:45] geser: the device you pasted already has linux.device_file, which seems to be the correct one? [13:46] pitti: good question, I tried looking at how the other files do it [13:46] geser: drop the @info.parent: [13:46] Hobbsee: I'll fix anjuta, I'm talking regularly to huat about it for some days now [13:47] pitti: still no acls (I've restarted hal and also issued a ck-launch-session) [13:48] seb128: cool. I've seen some action on the bug. [13:48] oh, interesting. according to debian packages, libgdl-gnome-1-0 still exists - but an old version. [13:49] it's uninstallable and NBS [13:49] * slangasek sharpens the axe while he waits for python-gnome2-extras to build [13:50] Hobbsee: right, nbs is not cleaned if there is still some packages depending on the binaries [13:50] pitti: is /usr/share/hal/fdi/policy/10osvendor/ the correct location for my fdi file? [13:50] seb128: in debian, it appears. It's gone in ubuntu, apparently. [13:51] slangasek: I kicked the builds after pygtk built, now you might want to ask pitti to score higher those [13:51] prio bumped to 5000 [13:51] pitti: danke [13:51] * Hobbsee want's pitti's version of buildd.py. [13:51] geser: yes, looks good [13:52] mdz: committed (rev2902) thx [13:52] Hobbsee: hm, you are right; it doesn't actually *work* [13:52] pitti: good. so i'm not going mad! [13:54] * Hobbsee sighs at seb. I get build failure mails for a reason. [13:54]