=== ember_ is now known as ember [00:50] Keybuk: MoM is marking changelogs as jaunty instead of karmic [01:05] i found a severe glitch in ubuntu for athlon64xp cpu machines [01:05] the same glitch is in windows xp [01:06] mass storage devices with a boot partition on them lose power via usb 2.0 as soon as the kernel loads [01:06] causing the kernel to halt loading [01:08] Keal: you should start by filing a bug [01:12] is there a way to force apt to redownload all of the currently installed packages? [01:12] apt-get -d install $(dpkg --get-selections | awk '{print $1}') seems to not do it [01:13] apt-get -d --reinstall ? [01:13] oh /me tries that [01:14] Something like rm -r /var/cache/apt; aptitude -d install '~i'? [01:15] it seems the apt-get -d --reinstall is doing the trick... i just need to create a local repo of a currently installed system. it seems apt-move needs a fully populated /var/cache/apt/archives folder though [01:20] Keal, that would be an issue related to a specific motherboard chipset, not the CPU [01:43] roll call [01:48] where can I get a copy of the libdvdcss library? [01:49] i can't seem to find the LINUX version with a google search [01:50] !libdvdcss [01:50] For multimedia issues, this page has useful information: https://help.ubuntu.com/community/RestrictedFormats - See also https://help.ubuntu.com/9.04/musicvideophotos/C/video.html - But please use free formats if you can: https://help.ubuntu.com/community/FreeFormats [01:50] un erstood [01:51] >understood [01:51] stupid keyboard [01:51] there's a script that will install it for you, too [01:51] in libdvdread4. However, i think that page will tell you more [01:52] oh, it points directly to medibuntu now [01:58] hobbsee, thanks for the tip on the libdvdcss [01:58] Anon: you're welcome [01:59] i guess I'll see you guys later. [01:59] and thanks for giving version 9.04 the ability to use my sprint wireless air card [01:59] :) [01:59] now i can finally get rid of windows [01:59] later === ssd7_ is now known as ssd7 [03:11] can someone point me to some documentation regarding install time package detection with dpkg/apt? [03:22] pace_t_zulu: what do you mean [03:22] i am working on a fix for https://bugs.launchpad.net/ubuntu/+source/matplotlib/+bug/301007 [03:22] Ubuntu bug 301007 in matplotlib "python-matplotlib: missing package dependency (python-tk)" [Undecided,Confirmed] [03:23] !ubottu [03:23] Hi! I'm #ubuntu-devel's favorite infobot, you can search my brain yourself at http://ubottu.com/factoids.cgi - Usage info: http://wiki.ubuntu.com/UbuntuBots [03:25] pace_t_zulu: it looks like there is a fix as far as packaging is concerned [03:25] pace_t_zulu: why not try: import Tkinter, except: try: import ...? [03:26] pace_t_zulu: to do an auto backend, you don't need package detection - that would be slow. Instead just try importing the various python modules [03:26] try: [03:26] e.g. [03:26] import tkbackend [03:26] are you referring to this fix? http://launchpadlibrarian.net/26327836/matplotlib_0.98.5.2-1ubuntu4.debdiff [03:26] return tkbackend [03:26] except ImportError: [03:26] pass [03:26] try: [03:26] import gtkbackend [03:26] return gtkbackend [03:26] except ImportError: [03:26] pass [03:26] etc [03:27] right, what he said, but in fewer words. :) do it at runtime, not install time, because packages can change later [03:27] and check for the python packages, not debian packages. What if I easy_install something? [03:29] lifeless thank you [03:30] geofft: If you easy_install something, the Debian packaging system can't help you. [03:31] sure... that's an argument to do this check outside of the Debian packaging system :) [03:31] for example, I can easy_install something into ~. I can't do that to a Debian package [03:31] the point is that dpkg -l python-tk is not the same as try: import Tkinter, and the latter is what you actually care about [03:33] Sure. [03:33] this is a UX problem i am trying to address... i agree that a backend fix is optimal [03:34] pace_t_zulu: If you're trying to fix a Debian package, use the Debian packaging system. Just add it as a depends. [03:34] ScottK: it is already a depend [03:34] Then it's not missing. I don't understand. [03:34] * ScottK goes to read the actual bug and not just the title. [03:35] ScottK: problem is that the python-tk depend is ORed with python-gtk2 which is available on ubuntu systems [03:35] Er, can't you add a patch to it to do the try/import test if /etc/matplotlibrc doesn't exist? [03:35] but the default backend is set to python-tk [03:35] (and not install an /etc/matplotlibrc) [03:35] so the python-tk should have an exclusive depend [03:36] for a quick fix... but i agree that a more optimal fix should be implemented next [03:36] its been quick fixed [03:36] lifeless: it has not [03:36] the quick fix for ubuntu is incompatible with a quick fix for kubuntu is incompatible with a quick fix xubuntu [03:36] OK. I read the bug. I understand it now. [03:36] python-tk is not installed with python-matplotlib [03:36] because they all want a different backend [03:36] lifeless: exactly [03:36] so it has been quick fixed. You can't quick fix it any more. Do the real fix. [03:37] there are a lot of different ideas about how to be fixed [03:37] its probably about as much time as has been spent discussing it here to do it. [03:37] lifeless: that debdiff that i provided has not been accepted [03:38] lifeless: i'm fine with that... do you think it should be implement at the backend? [03:38] ok so i don't know if i am the moron or if doko is... bug 373911 [03:38] Launchpad bug 373911 in gcj-4.4 "gcj fails to build OOo 3.1.0 on i386/lpia due to claim that libgcj.spec missing" [High,Fix released] https://launchpad.net/bugs/373911 [03:40] he's telling me to use openjdk for building OOo which I already do (except for ia64 which was due to openjdk bugs) so I close the bug after telling him as much... he reopens the bug AGAIN telling me the same thing without addressing the fact that I already told him I am using openjdk [03:40] so either i am having a severe reading comprehension issue or he is, lol [03:41] pace_t_zulu: an auto backend was proposed; and the bug seems to claim there is an upstream bug for that already [03:42] doko: ping... you are confusing the hell out of me wrt 373911 [03:43] lifeless: i still think that short term an ubuntu4 should be created that depends 'python-tk' and ubuntu5 can do the proper fix [03:43] * calc bbl [03:44] pace_t_zulu: have you had much luck convincing people of that? [06:43] Good morning [06:44] Good morning pitti. [06:45] dtchen: right, I was following along; let's revert the patch, unless you find a better solution; thank you! [06:45] ScottK: hey, how are you? had a nice weekend? [06:46] pitti: Not bad. It was Mother's Day here on Sunday, so that was a big day at our house. [06:46] I worked 6PM to 2AM last week and I'm still trying to get my clock re-adjusted (thus am up at ~2am). [06:48] here, too [06:48] ScottK: ugh, recently came from Europe or so? :-) [06:49] pitti: No, just had some testing I was involved with and that was the only time we could get all the necessary facilities. [06:54] good morning [07:00] * pitti hugs dholbach [07:00] Keybuk: good morning [07:00] * dholbach hugs pitti back === TheMuso_ is now known as TheMuso [07:12] Keybuk: would you mind doing a git update in udev-extra ubuntu branch? I uploaded usbutils 0.82 yesterday (new build dep) and committed running the build tests (I added one to upstream git yesterday) === tkamppeter_ is now known as tkamppeter [07:27] TheMuso: Hi. The policykit merge was already done. I've also included a patch which would have allowed a SRU to go ahead. See bug #372599. [07:27] Launchpad bug 372599 in policykit "Merge policykit 0.9-3" [Wishlist,Confirmed] https://launchpad.net/bugs/372599 [07:27] Having that said, would you like to take care of that SRU as well, please? [07:28] * iulian wonders what he should do with that bug. [07:28] iulian: hrm I don't remember seeing any policykit bugs. [07:28] Set its status to Fix released or Invalid? [07:28] for merging [07:28] * TheMuso checks again [07:29] iulian: sorry, I totally and utterly missed it. I'll deal with that bug. [07:30] TheMuso: No problem, thanks! [07:39] asac: I was going to propose udev-extras for main today, to switch keymap handling from hal to it [07:39] asac: that will bring the modem prober to main as well [07:40] asac: I wondered, how could n-m use the modem prober in jaunty with udev-extras still being in universe? did it copy the code? [07:42] asac: ah, apparently so; could we try using the ones from udev-extras in karmic soon? [07:42] robert_ancell: good work on the gcalctool merge/update [07:43] dholbach: cheers [07:57] Hi all [08:01] hey lool, good morning! [08:02] Hey pitti! [08:45] hey everybody :) [08:45] doko: around? [08:51] hey didrocks [08:53] hello djsiegel_ === djsiegel_ is now known as davidsiegel [09:39] pitti, hi [09:39] hi takm [09:40] hi tkamppeter [09:41] pitti: Can you upload CUPS to Debian and Ubuntu? I have done a one-line patch to fix three bugs. This one will also be an SRU. === dpm_ is now known as dpm [09:41] tkamppeter: will do [09:44] pitti, is the last SRU of CUPS already in -updates [09:45] tkamppeter: see "rmadison cups", it is [09:46] tkamppeter: you forgot to bzr add the new patch; please do, commit, and push [09:48] pitti, done [09:48] TheMuso: patch sent off [09:49] lifeless: thanks [09:50] tkamppeter: the ps2write patch doesn't look like an appropriate SRU [09:50] tkamppeter: if you change the gs backend, that has a high regression potential, doesn't it? [09:55] Is this a good time to upgrade to karmic? Anything I should be careful with or hold back? [09:55] (/me returns from holidays and wants to jump into karmic) [09:59] lool: works pretty well; UXA might be a bit unstable if you enable it, but it's not by default [09:59] pitti, perhaps we let it go into Karmic and wait for a month to see whether it causes any bug reports. If it does not cause bug reports there, we SRU it? WDYT? [09:59] tkamppeter: it would help certainly, but switching the entire implementation is still regression prone [10:00] tkamppeter: if there's a focused workaround for the particular affected driver/printer model, this would be more appropriate [10:07] pitti, bug 361772 has the foomatic-db-engine SRU as workaround, the Ricoh PPDs I will soon update on OpenPrinting, so this bug is not a problem. bug 369503 shows that the PostScript of pswrite is not compatible with a proprietary Canon driver, at least for some PDF files. We can provide tha alternative pdftops to the individual users here, bug 362186 shows that the PostScript of pswrite is incompatible with the PostScript interpreter [10:07] of some HP printers, we could tell the users to use PCL-XL mode here. [10:07] Launchpad bug 361772 in foomatic-db-engine "black squares appearing instead of some letters when printing" [Undecided,In progress] https://launchpad.net/bugs/361772 [10:07] Launchpad bug 369503 in cups "Evince and Firefox fails to print but OpenOffice prints normaly in Jaunty" [Undecided,Triaged] https://launchpad.net/bugs/369503 [10:07] pitt WDYT? [10:07] Launchpad bug 362186 in cups "Spurious lines on print outs" [Medium,Triaged] https://launchpad.net/bugs/362186 [10:08] * ogra sees lots and lots of users that haed probs with their manually edited menu.lst, didnt know what to do when update-manager/debconf asked and ended up with only the old .lst file that just boots their intrepid kernel ... [10:08] i wonder if we should have a spec about a way to improve that, seems ucf in that case is a bit strictr [10:08] *strict [10:09] (or rather "not userfriendly enough") [10:15] tkamppeter: Is that something they can influence, by picking another driver? [10:16] ogra: last time this came up, Steve reckoned the current situation was pretty close to the best we could do given grub's shoddy update-grub design, and that switching to grub2 was a better long-term approach [10:16] we might not be that far off the latter [10:17] ah, if thats a possibility even better, i just notice that about 10% of the upgrade probs i see on IRC or in lists are menu.lst related ... people often get advised to edit the kernel lines directly so there are many where the question comes up [10:17] (or even tools that edit the file the wrong way) [10:24] pitti, for the incompatibility of HP's PS interpreter with pswrite output they could switch to the pxlmono driver. Currently, this does not happen automatically, but I also do not know which HP printers have the problem (LJ 1320 and LJ 4050 have the problem according to bug report, my LJ 3390 and LJ P3005 do not have the problem). [10:24] Keybuk: hal with libblkd uploaded, FYI; so the only remaining thing is redhat-cluster [10:24] pitti: sorry, NM does not use the modem prober from udev-extras. it ships its own modem-prober; so at best remove it from udev-extras for the time being [10:24] asac: oh, that's not just a copy? [10:24] pitti: no. the udev-extras thing was an experiment afaik [10:25] pitti, for the incompatibility with the Canon driver one will need the ps2write device. [10:25] asac: if it should permanently live in n-m, then we should remove it from udev-extras completely IMHO [10:25] TheMuso: please read my patch; if you're happy with it we could just land it in karmic ;) [10:25] asac: (and I agree that it would make sense to keep it in NM) [10:25] lifeless: will have a look in a bit. [10:26] pitti: i will check with Dan, for now i would think it should be removed ... it might do harm [10:26] by probing some modem ports its not supposed to probe etc. [10:26] asac: thanks; indeed it should just be probed once, and the code should just live in one place [10:28] TheMuso: thanks [10:29] hm, i wish i didn't need to restart my printer every print [10:32] tkamppeter: hm, current cups test suite hangs on "Waiting for jobs to complete..." [10:32] tkamppeter: that worked in the previous upload [10:42] lifeless: that looks ok to me. I've not had a lot to do with the isw code so I don't know it that well, so if it works for users with older signatures, and newer signatures, thats fine. I have ICH8 here, and can try your patch as part of dmraid for reading a pair of disks I can use for testing, but will do that tomorrow. [10:43] TheMuso: cool [10:43] TheMuso: I can't see how I would have broken older disks :) [10:43] lifeless: Neither can I, but it doesn't hurt to test. [10:43] * TheMuso doesn't use dmraid at all, but ensures he has spare disks available for testing. :) [10:43] use as in use full-time. [10:44] cool [10:44] thanks [10:47] tkamppeter: can you please try to build current cups on current karmic? test suite fails pretty badly (and hangs in sid) [10:56] directhex: Congrats on MOTY! [10:56] *MOTU [10:58] pitti, strange, as botth changes which I did after your 1.3.10 update seem to be harmless, or can perhaps one of them have torn down the tests? I could build the whole thing on Jaunty. [10:58] tkamppeter: could also be newer ghostscript in karmic/sid, etc>? [10:59] * TheMuso sighs. Even though mdadm 3 will have support for isw metadata, it won't support others, which means a combination os dmraid and mdadm will have to be used. [11:00] pitti, I did not replace Ghostscript by something newer after Jaunty. Did there come a new Ghostscript from Debian? [11:00] tkamppeter: no, apparently not [11:00] TheMuso: Does that at least solve the reconstruction problem? [11:00] StevenK: For isw it will. [11:01] StevenK: as it is now, only isw can be reconstructed with dmraid and even then I'm not sure how thats supposed to work. [11:01] TheMuso: Score! [11:01] TheMuso: have you looked at the 2.4 isw kernel module? [11:01] *fun* [11:01] lifeless: yeah [11:01] lifeless: no [11:02] <\sh> moins [11:07] could someone rescore python-apt on armel ? [11:08] as well as nautilus-share [11:09] and totem [11:10] * StevenK waits for ogra to ask for * [11:10] heh [11:10] these three for now, just checking what breaks openoffice [11:10] seems thats the last one holding up livecd-rootfs on armel [11:11] <\sh> ogra: when do you have time to visit KA? we need to celebrate :) [11:11] \sh, probably on my way back from barcelona [11:11] ogra: trying to [11:11] (going by car, should be easy to drop by in KA) [11:12] * ogra hugs Hobbsee [11:12] <\sh> ogra: please do :) just tell me when that is :) I need to plan my life a bit different now :) [11:13] tkamppeter: hah, I get a lot of gs segfaults in kern.log indeed [11:13] \sh: Next 18 years: raise child; After that: everything else [11:14] \sh, oh, yeah, congrats btw :D [11:14] right. What magic runes do I have to do to make launchpad happy this time? [11:14] <\sh> StevenK: oh well...raising child and taking care of family ==> prio 1 :) then work and universe and then the rest :) [11:14] <\sh> ogra: thx :) [11:15] Hobbsee: You need to sacrafice a rubber chicken on the stroke of 9pm with a silver handled knife [11:15] StevenK: heh. Seems like it [11:15] Hobbsee: what is it unhappy with [11:15] Rescoring https://launchpad.net/ubuntu/+source/nautilus-share/0.7.2-5/+build/989902 (armel). [11:15] Unable to request rescore on armel. [11:15] lifeless: ^ [11:15] i've regenerated my LP cookie [11:15] cprov: ^ [11:16] * ogra guesses there was not enough sugar in the cookie ... LP likes it sweet :) [11:16] Estimated build start: 2009-05-12 [11:16] Heh [11:17] Hobbsee: apparently I am, what's the value you want to set ? [11:18] hight++ [11:18] ah, damn [11:18] *high even [11:18] the syntax has changed - it needed to be ~/.lpcookie.txt now, not just ~/.lpcookie, which was what my logs had [11:18] lifeless, cprov: sorry for the noise [11:19] Hobbsee: np [11:21] ogra: all tweaked [11:21] thanks a lot [11:22] y/w [11:22] * Hobbsee adds the new version to her ~/UsefulCommands [11:23] pitti, I have also many gs segfaults. Which gs drivers is the CUPS test suite using? [11:23] tkamppeter: I don't know by heart [11:26] seb128, do you plan to switch RB from libnautilus-burn to brasero in karmic ? (it currently ftbfs on armel because of the nautilus dep) [11:27] no opinion on the topic [11:27] but it should not be an issue right now [11:27] what is the issue exactly? [11:28] pitti, there is a queue using rastertohp in the test suite, so the cups device of GS is crashing. [11:28] The following packages have unmet dependencies: [11:28] libnautilus-burn-dev: Depends: libeel2-dev but it is not installable [11:28] seb128, ^^ [11:28] from http://launchpadlibrarian.net/26525134/buildlog_ubuntu-karmic-armel.rhythmbox_0.12.1-0ubuntu1_FAILEDTOBUILD.txt.gz [11:28] did nautilus-cd-burner ftbfsed too? [11:28] (yes i know its eel's fault, but i was curious) [11:28] no it's not [11:28] that's a deprecated lib and it's not used nowadays [11:28] oh [11:29] it has been cleaned in karmic [11:29] I expect your issue is that nautilus-cd-burner didn't build on armel [11:29] it did 8 hours ago in fact [11:29] i see no further trace of nautilus on http://qa.ubuntuwire.com/ftbfs/ ... but havent checked all nautilus builds yet, nautilus-share was clearly sitting and not even built yet, not sure about the other nautilus packages, just going through them [11:29] ogra: did you apt-get update? [11:30] ogra: should be fixed since 6 hours ago or so [11:30] on the buildd ? [11:30] https://edge.launchpad.net/ubuntu/+source/nautilus-cd-burner/2.25.3-0ubuntu2/+build/978020 [11:30] ah, k, so a give back will fix it [11:30] it should [11:30] good, thanks [11:30] you're welcome [11:30] :) [11:33] pitti: For me also the pdftops filter segfaults, but this is the filter written in C which comes from CUPS 1.3.10. [11:40] cjwatson: a build failure is baffling me [11:41] cjwatson: it honestly looks like dpkg hasn't applied the full diff.gz [11:50] Keybuk: Keybuk: would you mind doing a git update in udev-extra ubuntu branch? I uploaded usbutils 0.82 yesterday (new build dep) and committed running the build tests (I added one to upstream git yesterday) [11:50] ooh, your stuff got merged? [11:50] 3044c4e ok? [11:50] Keybuk: I committed it myself with Kay's approval [11:50] Keybuk: 3044c4e ack [11:51] Keybuk: also, asac said that we should not install the modem prober for now, since it's already in NM [11:51] Keybuk: unless you want to do that, I can work on it later [11:51] modem-probe is empty now, no? [11:51] oh right, that was modem-modeswitch [11:51] hrm, no mvo today ? [11:52] ogra: holiday [11:52] Keybuk: ok, thanks [11:52] gah [11:52] ogra: holiday this week [11:52] * pitti -> physiotherapy and lunch, back in ~ 1 hour [11:52] * ogra wonders whom to poke for python-apt then :/ [11:55] Keybuk: oh? [11:55] cjwatson: looks like the diff.gz was corrupted [11:56] odd that it didn't bail if so [11:56] or was it corrupted such that that was justifiable? [11:59] I think that things were just missing from it [11:59] dpkg-source-- [11:59] since they're clearly in my working directory as changes ;) [11:59] regenerated it and it looks ok now === azeem_ is now known as azeem [12:39] jdstrand, kirkland: syncbugbot failed for me too. Regenerating my lpcookie fixed it though [12:42] james_w: there's an RT request open for diffstat [12:42] cjwatson: cool, thanks [12:56] asac: okay, so the modem prober went away in udev-extras; modem-modeswitch is still left; do you know whether that should/will move to nm as well? [13:00] Keybuk: whoops, missed new gperf build dep; I'll upload a new version [13:01] Keybuk: hm, can you please bzr push udev-extras? [13:04] pitti: will check on that. a bunch of drivers already do the modeswitch automatically afaik. so maybe this wont be needed at all. [13:04] asac: cool [13:05] asac: do you know whether the modem prober makes all those hal-info FDIs obsolete already? [13:05] asac: I wonder what's missing in order to drop them [13:05] pitti: weird "these branches have diverged" [13:05] Keybuk: did you pull first? I added a test suite call to debian/rules [13:05] ahh [13:05] I did pull [13:06] but of course, bzr pulled from the wrong place [13:06] pitti: in theory it makes them obsolete ... however, we still use them to tie-break if the modem prober is unsure [13:06] so said everything was fine [13:06] Keybuk: I told you in the morning, but I guess you weren't sufficiently caffeinated yet or so :) [13:06] pitti: I don't read IRC scrollback [13:06] pitti: you are looking in removing hal-info completely? or just the 10-modem.fdi? [13:07] asac: eventually it needs to go away completely [13:07] but of course we should remove stuff part by part, once we know that it can go [13:07] pitti: ok, pushed [13:08] pitti: i think we cannot remove 10-modem.fdi upstream ... we still need SRUs for hardy/intrepid for a while i guess [13:08] asac: yes, but we shoudl eventually stop shipping them in karmic [13:08] ./configure --without-modem or so [13:11] pitti, I have looked into the error_log of the test suite of CUPS. pdftops segfaults in job 4. [13:11] Keybuk: what do you do after a git import to get configure etc.? Just run autogen.sh in the ubuntu tree? or a make dist upstream, and untar into your package tree? [13:11] pitti: i will verify what exactly we are still using hal for ... i think there are some corner cases where having the fdi helps NM to tie-break, but that could be obsolete as we improved the modem prober considerably in the last few 0.7.1 commits - stay tune [13:12] asac: yeah, I wondered whether we should disable them early and ask for regression testing [13:12] pitti: autoreconf -i [13:12] Keybuk: great, will do that [13:12] usually bzr clean-tree first [13:12] already done [13:12] pitti: if you're talking about hal deprecation, pulseaudio still relies on it somewhat heavily, and upstream doesn't appear to be moving away from it just yet. [13:12] Keybuk: why not do that in debian/rules then, in build/ ? [13:13] TheMuso: right, I know; X.org input needs work as well [13:13] TheMuso: I guess there is a fair chance that we have to ship hal by default in karmic, but I'd like to see as many parts as possible migrated early [13:13] to minimize the structural changes in the lazy lizzard (LTS) [13:14] Ok, I'll see what upstream plans on doing. [13:14] pitti: I don't like putting that kind of thing in debian/rules [13:15] ooh, we can have orig.tar.bz2 now? [13:15] since it means you're uploading something that you haven't actually tested the build of [13:16] pitti: http://paste.ubuntu.com/169518/ [13:16] pitti: so removing hal would make all modems get deferred initialization ... looked at code, and i think it should be fine. [13:17] asac: it looks like only d) is the remaining concern then? [13:17] pitti: in any case. i think we shouldnt remove 10-modem.fdi [13:17] modemmanager uses hal atm and we want to experiment with that (hopefully moving it to udev as well) === rgreening_ is now known as rgreening [13:18] Keybuk: it doesn't like me when building in build/: make[4]: *** No rule to make target `keymaps/*', needed by `all-am'. Stop. [13:18] pitti: yeah. i checked ... d) shouldnt be a concern from what i see. its actually the right thing. however, if we could keep 10-modem.fdi until we have ported modemmanager to udev that would be precious [13:18] pitti: keymaps/* doesn't look like a valid taget? [13:18] asac: sure [13:19] pitti: you can't use wildcards like that ;) [13:19] ok i will tell you once we have made progress [13:19] Keybuk: keymap/Makefile.am has udevkeymap_DATA = keymaps/* [13:19] pitti: exactly, you can't use wildcards in make like that [13:19] that means a file *called* keymaps/* [13:20] Keybuk: $(shell ls keymaps/*) then? [13:20] pitti: Automake will forbid it [13:20] pitti: just list them [13:21] 27.3 Why doesn't Automake support wildcards? [13:21] Developers are lazy. [13:21] that's stupid [13:21] (and then with sensible rationale) [13:21] read that info page [13:21] having to explicitly list all files in a subdir? [13:22] pitti: then you'll end up accidentally distributing keymap~ [13:22] that reminds me why I ripped out the automake stuff from human-icon-theme and friends [13:22] keymap.orig [13:22] keymap.rej [13:22] etc. [13:22] meh [13:23] the usual rationale is "since you have to 'bzr add' the new file, you should also add it to Makefile.am as the same reflex" [13:26] pitti, if you run "filter/pdftops 1 1 1 1 "" test/testfile.pdf" from within the CUPS source directory (after compiling) you get a segfault in pdftops. [13:31] Keybuk: glob -> explicit list committed to trunk [13:32] Keybuk: and gperf build dep committed as well; could I ask you for another git pull? [13:34] pitti: pulled, merged, pushed [13:34] Keybuk: thanks [13:35] yay james_w [13:35] \o/ [13:36] Hello! I'm trying to get a fix for bug 345706 into Ubuntu main. This is the first time I have tried to get anything into Ubuntu main. [13:36] Launchpad bug 345706 in packagekit "CMake can't find QPackageKit by default" [Undecided,Triaged] https://launchpad.net/bugs/345706 [13:36] I have already done one mistake. (I assumed I needed permission from those responsible for the package before I could subscribe main sponsors) Could anyone check if I have done others or if there is anything I can do better (more details in the bug report etc)? [13:37] By the way: How long should a package be in Karmic before I can suggest a sru to jaunty? [13:39] i/wg 169 [13:39] (sorry) [13:39] sveinung__: which bugs is it? [13:39] tkamppeter: is that due to one of our patches? I know that it didn't happen in 1.3.10-1 [13:40] pitti: bug 345706 [13:40] Launchpad bug 345706 in packagekit "CMake can't find QPackageKit by default" [Undecided,Triaged] https://launchpad.net/bugs/345706 [13:40] sveinung__: you probably meant "mnemo"? [13:42] pitti: mnemo? [13:42] sveinung__: "mnemo| sveinung__: which bugs is it?" and you pinged me [13:42] aah [13:42] pitti: sorry about that [13:42] sveinung__: np :) [13:43] mnemo: bug 345706 [13:43] Launchpad bug 345706 in packagekit "CMake can't find QPackageKit by default" [Undecided,Triaged] https://launchpad.net/bugs/345706 [13:46] sveinung__: i think you should just preapre the sru debdiff, fixup the bug according to the SRU guidelines and subscribe the SRU team so they can give you feedback on what they feel is necessary (and whether this bug is suitable for SRU)... I assume you have read: https://wiki.ubuntu.com/StableReleaseUpdates#When etc right? im not part of that team but to me a dev tools bug seems non-critical? isnt most of the dev work done on karmic anyway? im no [13:49] Keybuk: *sigh* I committed another build fix to trunk, sorry; but this is the last one, it really works now [13:51] pitti: pulled, merged, pushed [13:51] * pitti hugs Keybuk [13:51] mnemo: the fix is not in Karmic yet. Point 1 of the procedure say that it should be there first. So was if I should fix anything in the report to get it into Karmic I was wondering now. :) [13:52] seems that "bzr-git" is really called "Keybuk" [13:56] sveinung__: I think that what mnemo means is, SRUs happen occasionally rather than often. [13:56] not just everything gets SRU'd; there needs to be a very good reason to make an SRU [13:59] asac: I would be grateful if you could process bug 374844, since I wrote it, and it affects you most (with n-m) [13:59] Launchpad bug 374844 in udev-extras "Please move to main" [Undecided,New] https://launchpad.net/bugs/374844 [14:00] pitti: Lennart's plan is to drop hal support in the Fedora 12 timeframe. Without seeing their release schedule I am not sure what this is yet, but I do know they release later than us. [14:00] asac: if possible, I'd like to get it into alpha-1, but if you are swamped, it's not that urgent [14:01] pitti: will do [14:01] will review today [14:01] bryce, hey there [14:04] seb128, oh, intresting now RB failed at a different point on armel ... seems it doesnt install libgnome2-dev, is there a build-dep missing somewhere ? [14:04] 6/c [14:05] Package libgnome-2.0 was not found in the pkg-config search path. [14:05] Perhaps you should add the directory containing `libgnome-2.0.pc' [14:05]