[00:00] simply by restarting all the dowwnloads and deleting everything before [00:00] You should have uninstalled the RIAA plugin. [00:00] i cant belive we ship that [00:00] (That was a (poor attempt at) a joke.) [00:00] * jdong looks [00:01] ogra: what did you click to cause that to happen? [00:01] so i have a ton of torrents that already were downloaded startig to DL again and wiping my folders [00:01] (not trying to imply PEBKAC, just trying to understand what happened) [00:01] jdong, i added another torrent without wiping the list *indisde* of transmission (the .torrent files were long gone) [00:02] ogra: oh did that other torrent contain same files or something? [00:02] jdong, well, might be PEBKAC that i didnt wipe the list in tranmission [00:02] nope [00:02] that one was a short movie [00:02] ogra: that's weird [00:02] i simply didnt use trasmission since the last DLs [00:02] * jdong hasn't seen that happen yet [00:02] and I've used transmission pretty regularly. [00:02] hmm... [00:03] if you can reproduce the workflow that causes this to happen, that'd be awesome [00:03] it sounds like a pretty nasty bug [00:03] yup [00:03] 'm quite shocked [00:03] or "usability unfeature" [00:03] I've never seen it delete anything. [00:03] heh [00:03] god thing you have backup :-) [00:03] good even [00:03] hardlinks, man. hardlinks. [00:03] Nafallo, i copied them all to my server [00:03] they sound sexy and prevent bad things from happening :) [00:04] but the actual dirs were emptied [00:04] I haven't seen it delete anything either, though I've never gone through those steps. [00:04] ogra: so you simply added a torrent and data disappeared? [00:06] well, step 1 download someting to your desktop ... step 2 dont touch transmission for two or three weeks after DL has finished ... step 3 delete the .torrent files step 4 DL a new torrent, notice that transmission has all the old ones listed, note it starts over with the old ones as well, find the dire empty just being refilled with some kb [00:06] *dirs [00:07] its no harm. i copied all the old stuff, but its still quite weird [00:07] ogra: odd... I swear I do that all the time and don't witness data loss [00:07] do the torrents get listed in tranmission after they finished for you ? [00:07] that sounds like logic :-) [00:08] yes [00:08] ogra: You sure you haven't previously removed those folders? [00:08] yes [00:08] ok I've attempted to reproduce it [00:08] minus step 2 of course [00:08] nothing seems to have happened [00:08] heh [00:08] no torrent files == empty torrent files == no files :-P [00:08] Nafallo, hmm [00:09] this sounds like a REALLY nasty bug and I'm interested in finding it [00:09] perhaps talk to charles next time he appears [00:10] jdong: Not to distract you, but you mentioned I could remind you to take a look at bug #195052 once hardy was released. So...here's a reminder :) [00:10] Launchpad bug 195052 in inkscape "Latex formula does not work on Ubuntu Hardy" [Low,Confirmed] https://launchpad.net/bugs/195052 [00:11] JohnPhys: yes, thanks for the reminder. [00:12] jdong: No problem, thanks! I believe a debdiff has been attached to that bug report lately to take care of the issue. [00:12] jdong, well, i didnt lose anything since i copied to my mediaserver yet and its 1am here and i have a conf call in the morning, i'll try to investigate that tomorrow later [00:12] ogra: thank you [00:12] JohnPhys: I commented on the bug... the debdiff is only slightly incorrect for an update [00:13] JohnPhys: I assume the person who prepared the debdiff would like upload credit for it, so I've asked him on the bug to update his debdiff to reflect stable versioning policies [00:14] jdong: Thanks! It's much appreciated! [00:14] JohnPhys: sure thing :) [03:59] crimsun: I'm creating ~ubuntu-core-dev/pulseaudio/hardy for hardy pulseaudio development, so that intrepid development can occur concurrently with fixing issues in hardy. === akafurious|Afk is now known as akafurious [04:33] TheMuso: ok. So "trunk" can have revs 20-24 reverted. [04:47] Does anyone know if anything’s being done about the IO/scheduling problem? [05:07] crimsun: Ok. [05:21] kees: do you know if Gutsy is vulnerable to CVE-2008-0007? [05:21] i.e. git http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=f5871b9016c0ebce8acc58f7a230adcb9bd89577 [05:23] kees: i.e. bug 187275; looks like it's still open :-/ [05:23] Launchpad bug 187275 in linux "[linux-source] several local vulnerabilities" [Medium,Triaged] https://launchpad.net/bugs/187275 [05:24] jdong: yeah, still open -- we've been planning a kernel update for this coming week, which will include that fix. [05:40] kees: Ok, cheers :) [06:37] good morning [06:41] morning [06:41] just the man I wanted to see [06:42] hi LaserJock [06:42] * jdong wonders the thoughts going through dholbach's mind... [06:43] jdong: hm? [06:43] 01:41 < LaserJock> just the man I wanted to see [06:43] that should trigger the fight-or-flight thing ;-) [06:43] jdong: oh... I'm sure it's going to be fine :) [06:50] bdmurray: do you know about recent pylpbugs breakage? [06:50] File "/usr/lib/python2.5/site-packages/launchpadbugs/tasksbase.py", line 283, in get_current [06:50] raise AttributeError, "There is no row of the info-table linked to this bugreport (%s)" %self._url [06:50] AttributeError: There is no row of the info-table linked to this bugreport (https://launchpad.net/bugs/123456/+text) [06:50] Launchpad bug 123456 in xine-lib "podcast crashes amarok" [Undecided,Confirmed] [07:05] Good morning [07:14] bdmurray: I think it'd make sense to get the fix for bug 215043 SRUed - it fixed the breakage above too [07:14] Launchpad bug 215043 in python-launchpad-bugs "comment.attachments crashes in HTML connector" [Undecided,Fix committed] https://launchpad.net/bugs/215043 [07:18] bdmurray: nevermind what I just said [07:18] bdmurray: it's just a very weird bug happening - check out http://paste.ubuntu.com/10161 [07:19] no, it's not weird - please just ignore what I said [07:19] * dholbach gets more coffee === hunger_t is now known as hunger [07:38] Good morning [07:41] good morning pitti [07:42] hi pitti [07:42] hi Tonio_ [07:42] hey dholbach :) [07:44] Hi pitti [07:53] hmm [07:54] Teeworlds still hasnt shown up in the new queue yet >_< [07:55] Been in unstable for a while now [08:25] Any particular reason why perl's priority was dropped to standard? [08:30] Hmm... Maybe debconf's lack of Depends: perl is the actual culprit. [08:33] hi soren [08:33] soren: btw, do you plan to merge dpkg again? [08:33] pitti: cjwatson's doing it this time. [08:33] soren: Guillem Jover offered to help with this [08:33] soren: ah, ok; just wanted to make sure you knew about Guillem's offer [08:34] Oh, sure. [08:35] pitti: So... about perl. IIUIC, changing packages' priority is a manual process, correct? [08:36] pitti: Stupid question, how do I list sessions for polkit? [08:36] soren: yes, I think so; but it has been standard in hardy already [08:36] StevenK: ck-list-sessions [08:36] StevenK: (it's ConsoleKit) [08:36] pitti: Hmm.. You're right. apt-cache show here shows it as important. That's odd. [08:37] * [08:37] *very* odd indeed. [08:38] pitti: Oh, duh. That would explain why I couldn't find it. :-/ [08:39] Perhaps the package itself says it's important, but it's overridden in the archive's Packages file.. [08:39] No, that says standard, too. [08:39] What on earth could make "apt-cache show perl" say "priority: important"? [08:41] perl-base is Essential: yes, I didn't think perl was [08:41] The problem is that debootstrapping Intrepid fails right now, because libc6's postinst ends up failing due to lack of Utils/Hash.pm. [08:42] (it uses debconf) [08:43] Oh! [08:43] perl-base contains fields.pm, which seems to need Utils::Hash. [08:43] and the latter is in perl-modules. [08:43] that's a bug in perl packaging itself then [08:44] Indeed. [08:44] man debootstrap [08:44] doh... [08:55] pitti: I'm trying to determine why USB keys don't automount on UME -- can you just spit out a few hints for me to check? [08:56] StevenK: do you use nautilus on those beasts? [08:56] StevenK: in hardy, nautilus now does the automounting, not g-v-m any more [08:56] pitti: Ahhhh. No nautilus. [08:57] StevenK: can you mount them manually? with gnome-mount? [08:59] pitti: gnome-mount -m /dev/sdb doesn't mount it [08:59] StevenK: try gnome-mount -vbd /dev/sdb [08:59] Right. -m is the wrong option. [09:00] gnome-mount -d /dev/sdb does work [09:00] ok, so it's really just the lack of an automounter [09:02] pitti: So UME should use g-v-m? [09:03] StevenK: well, that's the problem; automounting was disabled in gvm, since it conflicts to nautlus [09:03] StevenK: I think you might want to take a look at ivman [09:03] pitti: Ah, we could enable it specifically for lpia? [09:04] StevenK: either that, or you guys are happy with ivman; drops a few gnome dependencies, too [09:04] pitti: MSG people moved back to gvm [09:04] They reenabled it [09:04] And they fixed it for the new HAL :) [09:04] ah, I see [09:04] lool: how do you mean? current version should work fine with 0.5.11? [09:05] It does not; let me grab their changes [09:10] pitti: http://people.ubuntu.com/~lool/96_fix_for_new_hal.patch [09:12] lool: hm, that looks like basically reverting 00_disable_media_handling.patch ? [09:13] there are no hal specific changes in that patch [09:13] lool: btw, the latest upstream version has this 'disabling' patch applied already [09:16] meh, intltool/libxml-parser-perl dependency issue in intrepid seems to cause FTBFS all over the place [09:17] pitti, hi [09:17] hi tkamppeter [09:18] pitti, can you upload system-config-printer and foo2zjs for me (see your mail)/ [09:18] tkamppeter: yes, I'll do it [09:18] thanks [09:19] pitti: Yes, it reverts the disabling and fixes a couple of things [09:19] pitti: They should have used two patches instead of one [09:19] And I also said to remove patches they want to disable instead of adding a reverted patch IIRC [09:20] pitti: I think this part is the relevant one: [09:20] - { "block", block_device_added }, [09:20] + { "volume", block_device_added }, [09:21] I think they sent that upstream now [09:21] In fact we did it with Michael while I was sitting next to him [09:21] Hmm no, we sent the hal changes not the gvm ones [09:23] pitti: Anyway, StevenK tried ivman out and it worked for him; we're likely to stick to that if we're happy with it [09:23] pitti: You can check with Michael Frey if you want more details on what they changed in gvm for the new hal [09:24] lool: ah, thanks for the heads-up [09:25] ivman looks lighter than gvm. [09:25] It's what to do about unmounting that escapes me [09:25] Good point [09:26] StevenK: but g-v-m doesn't do that either [09:26] In all cases we need some UI that will call pmount/gnome-mount to umount devices [09:26] unmounting needs to happen manually [09:26] Right, exactly. We have no UI. [09:26] \o/ [09:27] StevenK: MSG has been evaluating pcmanfm and rox (rox-filer); we should poke them on the topic, perhaps it's related [09:27] lool: Okay. [09:28] pcmanfm has "# Built-in volume management (mount/umount/eject through HAL)" [09:29] Rox doesn't look like it has that [09:40] soren: depends: perl from debconf is *wrong*; please don't do that. This is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479202. [09:40] Debian bug 479202 in perl-base "fields tries to use Hash::Util" [Unknown,Open] [09:40] cjwatson: Oh, I wasn't going to :) [09:41] pitti: yeah, I know about Guillem's offer, though in the event I didn't need it (I found Ian and got him to explain a couple of obscure triggers bits) [09:41] anyway, bank holiday today, so ... [09:41] cjwatson: ah, thanks; enjoy! [09:41] cjwatson: I thought triggers were in sid now? [09:41] pitti: they are, but I had to verify the merge as it wasn't byte-for-byte [09:42] and in fact I did find one or two things left out, which I'll be forwarding to Guillem [09:43] cjwatson, go away ! its your free day [09:43] don't worry, I'm going to be not at home for much of the day :) [09:43] :) === RAOF_ is now known as RAOF [10:08] tkamppeter: new s-c-p> yay, that looks much cleaner now! [10:15] pitti: about bug 221399: even though only 3 days have elapsed, we have 5 acks and it is just a rebuilt; can we shove it already to -updates? [10:15] Launchpad bug 221399 in rkward "Not working in hardy x64" [Medium,Confirmed] https://launchpad.net/bugs/221399 [10:23] norsetto: yes, that's fine [10:23] pitti: thanks! [10:29] <\sh> pitti, do you have any paperwork why pybaz was removed in hardy? [10:31] norsetto: does Debian have a new version [10:31] ? [10:31] pitti: yes [10:32] rkward | 0.4.9a-1 | intrepid/universe | source, lpia [10:32] norsetto: ah, so that should be fixed in intrepid, too (once it actually builds, that is) [10:33] <\sh> argl... [10:33] pitti: ok, I'll open a new task and verify that it builds correctly [10:33] pitti: even though its a different issue, for Intrepid we have R 2.7 [10:35] * \sh blames people just filing removal reports, without having a proper notification in the real source package [10:36] norsetto: it already had an intrepid task, I closed it [10:37] pitti: ah, I guess LaserJock opened it [10:37] \sh: bah, I wonder where soyuz stores/displays the removal log [10:37] <\sh> pitti, is it possible to improve canonicals remove package script from archive to let it search for reverse-build-deps, and warn even before removal of a package? ;) [10:37] <\sh> pitti, https://bugs.edge.launchpad.net/ubuntu/+source/bazaar/+bug/214955 <- here [10:37] Launchpad bug 214955 in vcs-load-dirs "remove bazaar package from hardy" [Undecided,Fix released] [10:38] \sh: neither bigjools nor cprov are online ATM :/ [10:38] <\sh> pitti, I found it via google [10:38] \sh: we often do search for reverse dependencies [10:38] it's not integrated into the actual soyuz script, though [10:39] <\sh> pitti, it would be good to do so ... and to resolve those buggers before the actual removal ;) [10:39] agreed [10:43] pitti: Do you want http://people.ubuntu.com/~ubuntu-archive/removals.txt, or is there another one? [10:44] wgrant, \sh: ^ that's the one that was used up to a few months ago [10:44] There's something there from two weeks ago... [10:44] I thought they made it log there again after that feature was removed a couple of months back. [10:46] <\sh> wgrant, it's not correct this file ;) [10:50] asac: I recommend for hardy-proposed that we build nspluginwrapper on i386 and readd its libflashsupport dependency. That seems to be the least invasive change. [10:52] crimsun: tough decision [10:52] hi there ubuntu-devs. nice work you are doing ;) [10:52] i agree that we want nspluginwrapper for i386 though. [10:52] but for -proposed :/ [10:53] i am trying to rebuild the libusb-0.1.12 source package using dpkg-buildpackage. i installed all build deps (especially jade), but get a lot of jade errors of "undefined elements". what is going on here? might the build dependancies of the package be wrong? any idea how to fix it? (asked on #ubuntu some minutes ago, but no answer as expected) [10:53] asac: well, we could go with -backports, then [10:55] (please just tell me if this is not the right place to ask..) [10:55] berzerka: does the package actually stop building, or does it just spit out the errors? [10:56] pitti: it aborts. dpkg-buildpackage: failure: debian/rules build gave error exit status 2 [10:56] morning [10:56] berzerka: eww, that sounds like a genuine bug then [10:56] the errors are of the kind: jade:../../doc/manual.sgml:12:17:E: element "BOOK" undefined [10:57] for a huge bunch of elements (he stops after 200 since this is the maximum numbers of jade errors reported) [10:57] berzerka: is that hardy? [10:57] i think there is some jade-module build-dep missing.. [10:57] berzerka: weird, though, it built just fine in intrepid some days ago: https://edge.launchpad.net/ubuntu/+source/libusb/2:0.1.12-10 [10:57] asac, yes [10:58] and it built fine in hardy as well [10:58] pitti: It's not unheard of for packages to go crazy with a dirty build environment... [10:58] but last time it was built on hardy was 2007-11-23 [10:58] right [10:58] pitti: hmm maybe you have (pre-)installed the dep i am missing? [10:58] might be a missing build-conflicts: perhaps [10:58] berzerka: the buildds just install Build-Depends: (and Build-Depends-Indep:), nothing else [10:59] build-deps were either jade or openjade, tried both with the same result [10:59] pitti: i don't get you, you mean the automated build bots? [10:59] berzerka: yes [11:00] i see.. [11:00] strange, then [11:00] can i confirm wether i have an up-to-date, "clean" hardy install here? [11:01] berzerka: you could try to build using pbuilder to be sure [11:01] asac: never heard of it. i will read up... [11:04] i have only "hardy" references in sources.list, lsb_release tells me 8.04 hardy and aptitude full-upgrade returns nothing, so i conclude i have an up-to-date hardy installation. [11:09] what's going on? i did pbuilder --create, and he began installing a hube bunch of system-packages? err... the man-page said nothing about that. well hopefully the required deps are installed at least. [11:10] ah i see, this is for the chroot environment, right? they are not installed on my system but in the base.tgz chroot-environment.. [11:10] berzerka: it just creates a tarball for a chroot environment [11:10] berzerka: exactly [11:13] is a virtualbox module rebuild planned for the kernel in -proposed ? [11:13] (assuming that has to go through SRU as well etc) [11:15] hmmm, anyone understand what the problem is here: http://launchpadlibrarian.net/14215953/buildlog_ubuntu-intrepid-amd64.gnomeradio_1.7-5ubuntu1_FAILEDTOBUILD.txt.gz [11:18] I built before uploading and it was fine. I rebuilt now and its fine, those deps all install ok in my pbuilder intrepid chroot [11:18] norsetto: I think intltool or one of its dependencies cannot be installed [11:19] norsetto: intltool/libperl-blabla? yes, that seems to hit pretty much every intrepid upload ATM [11:19] tasty, because i just uploaded dput. [11:19] pitti: arghhh [11:19] pitti: what's hte problem with them? [11:19] I haven't checked [11:19] * pitti is on hardy and will stay for another 3 montsh [11:20] pitti: lucky you :-) [11:20] pitti: wuss :P [11:20] pitti: where's your sense of adventure? [11:21] Yeah. Intrepid's fun. [11:21] Hobbsee: I am on the 'fix hardy harder until 8.04.1' team :) [11:21] pitti: oh yeah, that's right. i guess you're exempt, then.... [11:22] * pitti spends about two hours on the SRU queue per day these days... [11:22] ouch! [11:22] well, that includes sponsoring, etc. [11:22] FYI - the new AbiWord package is up [11:23] assuming nobody sees further problems, it should be ready for hardy and intrepid [11:23] intrepid and hardy-backports? [11:24] likely [11:24] Or is there some evil plot to do huge version bumps in -updates? [11:24] hardy-backports is a good choice at first, and after some time we should discuss moving to hardy-updates [11:25] wgrant: well, this case is a bit spethial; it didn't get finished in time for hardy final [11:25] pitti, please only with enough testing [11:25] Before hardy it was discussed 8.04.1 [11:25] pitti, the classmate ships it by default [11:25] ogra: absolutely [11:25] pitti: So I saw. [11:25] It was happening sos close to the end :( [11:25] and it shouldnt add deps different des as well [11:25] *deps [11:25] ogra: not without your consent then :) [11:26] gracias :) [11:26] using pbuilder the package builds successfully! (but i am unable to locate the resulting .deb files) [11:27] look in /var/cache /pbuilder/result [11:27] (without space indeed) [11:27] how can this be? is my base install broken? [11:28] berzerka: /var/cache/pbuilder/result -> .debs [11:28] berzerka: you probably have a lot more packages installed, teh build might conflict with one [11:28] this was a gutsy install which i upgraded to hardy. [11:29] but shouldn't dpkg-buildpackage have told me so when checking the build-deps? [11:29] berzerka: yes; packages can create Build-Conflicts:, but apparently this one does't [11:30] berzerka: Build conflicts are moderately unlikely to get noticed; many people always build in a chroot and even if they don't they may never run into the issue. [11:31] pitti: soo, this seems to really be a (minor) bug in the package.. i guess you guys would like it fixed. now i got to find out what the difference between my install and the chroot base system is.. [11:31] berzerka: thank you! [11:32] how can i check which version of jade has been installed in the base.tgz? [11:32] berzerka: there's probably a lot, but not so many java related ones [11:32] berzerka: the versions are probably identical, but your normal system has a lot more packages installed [11:33] berzerka: you can 'pbuilder login' and play in the chroot [11:33] berzerka: (changes won't be preserved by default) [11:33] pitti: nice, thanks [11:35] pitti: inside the pbuilder shell, where do i find my source-package directory? [11:35] pitti: i want to try to dpkg-buildpackage from in here, first. [11:35] berzerka: normally it's not there; you can apt-get source it again, or use some mount --bind tricks [11:35] pitti: alright [11:36] berzerka: it's not a very comfortable chroot for interactive working; pbuilder is mainly designed to build packages automatically [11:36] pitti, thank you for uploading, but it seems that the buildds is currently not able to build s-c-p due to one of the dependencies not getting installed: [11:36] The following packages have unmet dependencies: [11:36] libxml-parser-perl: Depends: libwww-perl but it is not going to be installed [11:36] Depends: perlapi-5.8.8 but it is not installable [11:37] * norsetto wonders where he did see that already .... [11:37] tkamppeter: [12:19] norsetto: intltool/libperl-blabla? yes, that seems to hit pretty much every intrepid upload ATM [11:38] tkamppeter's looks slightly differnet, but it might be related to the perl issue [11:38] * pitti cnat' tpye toady [11:41] <\sh> we have also other issues ... tried to upgrade from hardy to intrepid chroot..and it fails for libpam-foosomething and other stuff [11:42] pitti: if i try to dpkg-buildpackage, i get unresolved build dependancies in the chroot env. dpkg -l doesn't list them too... Unmet build dependencies: debhelper (>= 5.0.22) autotools-dev pkg-config docbook-dsssl jade | openjade. those are about the same deps i was missing in my install. [11:42] berzerka: yes, you need to do apt-get build-dep [11:42] ah i see [11:43] berzerka: the pbuilder chroot only has the minimal package set (essential and required) [11:46] ScottK: http://launchpadlibrarian.net/14092249/unison_2.27.57-1~hardy1_source.changes -- (1) new unison is in intrepid now, (2) the bug number is wrong, and I can't find a matching one, (3) if hardy final's version is totally broken, this should be an SRU, not a backport [11:46] ScottK: I rejected the package for now [11:50] I guess we will have kde4 only in intrepid? [11:51] <\sh> will kde4.1 will be released in time? [12:17] pitti: i resolved it... [12:17] pitti: as i see it, docbook has to be added as an explicit build dependancy. [12:18] \sh: That's the plan. [12:19] pitti: i had docbook not installed. libusb has only docbook-dsssl as build-dependancy. docbook-dsssl depends on docbook | docbook-xml. since i had docbook-xml installed (don't know why), docbook hasn't been installed transitively. [12:19] pitti: It's not a question of unison being broken as incompatible. With what's in the repositories, you can sync among Dapper through Hardy machines, but not with any boxes with the current version. [12:19] unison has a history of incompatible on the wire protocol changes. [12:20] ScottK: ah, I see; but shouldn't it be an automated backport still? [12:20] pitti: after installing docbook, it works now. does one of you take care of adding docbook to the build-deps of libusb or should i file a bug for it? or do you see another problem/solution? :) [12:20] pitti: Now yes, but last week we didn't have it yet. [12:20] berzerka: I don't know exactly, but IIRC there was some weird problem with the docbook dependencies; asac, do you remember? [12:21] pitti: If you could do an automated backport of unison Intrepid -> Hardy that would be great. [12:21] ScottK: 2.27.57-1~hardy1 ? [12:22] ScottK: done === BenC__ is now known as BenC === rraphink is now known as raphink [12:33] pitti: Thanks. [13:04] pitti, slangasek, about bug 219999 [13:04] Launchpad bug 219999 in foomatic-filters "[Hardy SRU request] foomatic-rip does not handle enumerated-choice options with choices "True" and "False" correctly, leading to Duplex on most Ricoh printers not working" [High,Fix committed] https://launchpad.net/bugs/219999 [13:05] tkamppeter: Did you see Debian Bug 479397 [13:05] Debian bug 479397 in wnpp "RFA: gutenprint -- printer drivers for CUPS" [Normal,Open] http://bugs.debian.org/479397 [13:05] I thought you might be interested. [13:07] pitti, slangasek, is it needed to have this fixed in Intrepid before it get an SRU for Hardy? I am thinking about replacing the current foomatic-filters already by version 4.0 which is written in C and not in Perl (and also fixes the bug). So it will take some time to the next foomatic-filters package. [13:07] <\sh> ScottK, or the wish ;) [13:08] Someone ought to pick it up it seems and the more print stuff is managed in common between Debian/Ubuntu the better off both distros will be, IMO. [13:12] ScottK, thenkas for the info. I am not an official Debian Developer, so I cannot upload directly into Debian. What I can do is to have the packaging managed in a common SVN repo where I make the Ubuntu packages from and someone of Debian only takes snapshots from there to have Debian packages. This way it works with HPLIP currently. The rpos are hosted at Debian. [13:13] tkamppeter: You don't need to be a DD to maintain stuff in Debian (I maintain several packages there). [13:13] That sounds sane though. === gnomefre1k is now known as gnomefreak [13:39] pitti: will you take care of the bug or shall i commit a report for now? [13:41] pitti: i mean, docbook seems to be definitely required, so i don't see why one shouldn't just add it as an explicit build dependancy. [13:41] hm maybe i'll just wait for asac to respond.... [13:48] berzerka: re (sorry, was at lunch) [13:48] berzerka: the most effective place to report that would be a Debian bug IMHO [13:50] tkamppeter: well, the package is already in hardy-proposed, so that should be answer enough :) [13:50] tkamppeter: ideally the patch would be uploaded to intrepid right now, then that bug is done, and doesn't block on the rewrite [13:50] tkamppeter: but for #219999 the important blocker is now to collect testing feedback [13:51] tkamppeter: there is none at all so far, so we cannot move it to -updates [13:52] pitti: i am really not confident with reporting a bug which i encounter in ubuntu to the debian devs. does ubuntu completely mirror the debian repositories, or are versions/dependancies managed on its own? if yes, this is a ubuntu bug i would say. one could check wether the same problem exists in the debian repositories, then there would, by chance, exist the same bug in debian as in ubuntu. [13:53] berzerka: for what you said the bug is not the missing build-dep on dokbook, is the alternative build-deps that doesn't work [13:55] norsetto: docbook-dsssl depends on docbook | docbook-xml. you mean the error is the dependancy on docbook-xml? (since the package doesn't seem to fully supply what is required..) [13:55] berzerka: yes, note also that our libusb and docbook-dsssl are unchanged from Debian [13:57] okay the error seems to exist in debian unstable, too.. [13:58] docbook-xml only suggests docbook and not requires it, but (falsely) satisfies the build-dependancy of libusb. [13:59] berzerka: yes, if it is really required for dokbook to be a build-depends, than yes, it should be added as an explicit dependency and not to be relied upon being dragged in as a secondary one [13:59] okay then. i will report a bug at bugs.debian.org. i hope they won't recognize that this error actually stems from a ubuntu system, cause i fear to (rightly) get flamed in that case... [14:00] berzerka: why should you? We even have usertags for that [14:00] you're unlikely to be flamed for reporting a Ubuntu bug to Debian [14:00] * berzerka doesn't know about usertags [14:00] but okay, if you say so. [14:01] thank you all very much, i'm glad this issue is resolved, and i can go on debugging libusb :) [14:01] berzerka: https://wiki.ubuntu.com/Bugs/Debian/Usertagging [14:02] norsetto: thanks. so i should tag with origin-ubuntu and hardy? [14:03] berzerka: thanks a lot for your effort! [14:03] hardy doesn't seem to be really relevant here.. [14:03] (right) [14:03] berzerka: the packages are mostly straight imported from Debian [14:03] docbook-* and jade*, that is [14:07] hmm ... whats the problem? building libusb* still? [14:07] alright. very helpful you are in here. next time i have a real, distro-related problem i will check back here, #ubuntu is not that helpful in those respects, busy with explaining the user interface.. [14:07] asac: everything resolved, i guess. [14:08] pitti, thanks for the info, testing is so far based only on my daily printing which does not show any regression (I use the patched Hardy package currently and not foomatic-rip 4.0). [14:08] tkamppeter: there must be someone else who also has an affected printer? [14:08] berzerka: ok thanks. [14:08] asac: problem was: i had docbook-xml installed. docbook-dsssl is a build-dep, which depends on docbook OR docbook-xml. but docbook seems to be actually required (and is only suggested by docbook-xml). i will file a bug at debian, the problem exists also in sid. [14:08] tkamppeter: anyway, if you are using the actual binaries from hardy-proposed, please state your own test results in the bug [14:08] tkamppeter: (thanks) [14:10] pitti, I do not have a printer which is affected, I have tested the fix itself by printing into a file when I did the fix for upstream and also when I tested whether the patch has applied correctly to the Ubuntu packages. [14:10] tkamppeter: I guess we'll just wait for the bug reporters then? [14:11] My daily printing is a regression test and shows up to now that the patch does not break anything else in the printing workflow. [14:11] tkamppeter: if none of them answers, the problem can hardly be so pressing [14:11] tkamppeter: ah, that's a good data point to have, though; can you mention this in the bug, please? [14:11] tkamppeter: I mean the regression testing on other modesl [14:12] The original reporter is George Liu from Ricoh (the author of the affected PPD files). [14:13] I have sent mail to him asking to test, but he did not answer yet. [14:26] i used ubuntu-bug -p hal [14:26] and it didn't attach a device tree dump or anything [14:27] who do i nag to fix that? [14:47] * soren kicks apt-cacher === cr3_ is now known as cr3 === Tonio__ is now known as Tonio_ [14:48]